Implementing a Temporal Database on Top of a Conventional Database: Mapping of the Data Model and Data Definition Management 1

Implementing a Temporal Database on Top of a Conventional Database: Mapping of the Data Model and Data Definition Management 1 Patrícia Nogueira Hübler Nina Edelweiss Instituto de Informática - Universidade Federal do Rio Grande do Sul Porto Alegre RS Brasil {hubler, nina}@inf.ufrgs.br Abstract Researches concerning Temporal Databases are being developed for more than 20 years. However, very few implemented systems are available. Several temporal data models were proposed, extending traditional data models in a way to capture also the temporal features. A feasible way of implementing a Temporal Database is using a conventional commercial database mapping the temporal data model to it. This mapping shall provide the explicit representation of the temporal information related to the intended temporal data model. A Temporal Management System is presented in this paper. Data and rules related to a temporal data model are managed by this system, implemented on a conventional DBMS. 1 Introduction The need of representing temporal features can be identified in several application domains, like geographical information systems, electronic document management and manufacture systems. Applications usually require the knowledge of the information s evolution, implying the storage of different states of information, including past values and future previews. This led to the development of researches concerning temporal aspects in information systems. Temporal databases allow the storage and the recovery of all the states assumed by an object during its lifetime, thus recording its evolution with time [9, 10, 16, 20, 25]. To provide this feature, temporal timestamps are added do data, representing the transaction time (TT moment when the information is stored in the database) and/or the validity time (VT time when the information is valid in the application). When both timestamps are used the result is a bitemporal database. Temporal information may be added to data in three different levels: to each attribute s value, to a tuple, or to the whole database. Usually attributes are timestamped, but mixed representations may be used for instance, to timestamp an object and represent it s lifetime, the whole object (tuple) may be timestamped, besides the timestamping of it s attributes. Timestamps may present the form of timepoints (the temporal instant when the value begins it s validity), temporal intervals (representing the whole temporal validity) or temporal elements (disjunct sets of temporal intervals) [13]. Several temporal data models were proposed [1, 5, 11, 17, 19, 24], extending traditional data models (relational, entity-relationship, objectorientated) in a way to capture also temporal feature. However, very few implemented temporal systems are available. 1 This work was partially supported by CNPq Brasil.

The implementation of a temporal database may be achieved mapping the temporal data model to a conventional database, as related in recent researches [2, 3, 4, 12, 18, 22, 21, 23]. However, little attention has been given to the temporal evolution rules of data during updates. A special strategy is required to provide the management of historic data, keeping this as independent as possible from the user. The operations managing temporal databases are the same used to manage conventional databases (insert, delete, update). However, additional operations are needed to maintain correctly historic information, usually controlled by temporal logic rules. This paper presents a Temporal Management System, implementing a temporal data model on top of a commercial database. The system implements the temporal object-oriented model TF- ORM (Temporal Functionality in Objects with Roles Model). This model presents, in addition to bitemporal timestamping, integrity and state transition rules modelling the temporal evolution. The mapping of the state transition rules is emphasised. To explain the adopted way of managing temporal data, a detailed analysis of how the management operations may be implemented in conventional databases, concerning the whole set of temporal database types, is also presented. The paper is structured as follows. Section 2 presents some examples of implementations of temporal data models on top of conventional DBMS. Section 3 analyses how temporal data implemented in conventional databases may be managed, including proposals of how some undefined situations may be solved. The TF-ORM data model is briefly presented in section 4. Section 5 presents the Temporal Management System, implementing TF-ORM on a conventional database (Oracle), and section 6 concludes the paper. 2 Implementing Temporal Databases on top of Conventional DBMS Due to the fact that a completely temporal DBMS is not yet available, the implementation of a temporal database may be done on top of a conventional database, providing a suitable mapping between the two data models. The temporal timestamps, implicit in the temporal database, are represented as explicit attributes. Operation management in temporal databases presents special features, in a way to preserve historical data. As the conventional DBMS does not behave as a temporal DBMS, the operation management shall be adapted. Operation implementation depends on the underlying database resources, and on the possibility of representing temporal evolution rules to control data integrity. According to the temporal data model to be implemented and to the DBMS available resources, three different implementation levels are identified [4]. The first level (Level 1) DBMS do not support rules to control data integrity, which must be implemented by application programs. In Level 2 the DBMS support rules, but there are still some features of the data model, such as the messages in object-oriented models, must be implemented through applications programs. And in Level 3 the DBMS support every feature of the data model to be implemented. Several experiences mapping temporal data models to conventional databases have been recently developed, showing the feasibility of this approach. However, analysing the realised experiences, it can be realised that not all the features of the temporal data model are conveniently represented. Relational databases are the most popular commercial databases nowadays, and therefore they are the most often used to implement temporal databases. Special attributes are used to represent the timestamps (TT, VT, or bitemporal). Several examples of this kind of implementation may be found in recent works. Simonetto [18] proposes the representation of temporal aspects in a database logic project, keeping the management of temporal data hidden from those users who are not interested in temporal data. This was achieved using only the TT as timestamp. Cavalcanti [4] implemented the TF-ORM data model on INGRES. Further implementations are TimeDB [22], a relational DBMS based on the SQL query language, developed using SICSTus Prolog, and ORES Project [21], that aimed to implement a Temporal

DBMS to support a friendly and efficient management of temporal data, using the INGRES database. Object-oriented databases have also been used to implement temporal databases. [3] presents an implementation of the TOODM data model on O 2, aiming to ally the basic functions of temporal management to schema evolution and object management. The TOOBIS project - Temporal Object-Oriented Databases in Information System [23] supports the representation and query of temporal data. The TF-ORM data model was implemented by Arruda in O 2 [2], and by Cavalcanti in Postgres [4]. All these implementations focus only on the mapping of the data model and of the timestamps to the underlying database. The management of temporal information, according to the evolution rules, is not analysed. The Temporal Management System presented in this paper implements a temporal data model on top of a conventional database, mapping not only the values and timestamps to the underlying data model, but also the state transition rules. A relational database was selected due to the fact of being largely used in practice. 3 Data Management in Temporal Databases Data management in conventional databases is performed using the insert, update, delete and select operations. All the commercial databases implement these operations. Update and delete operations may be executed on any tuple when the user is allowed to do it. Integrity constraints maintain the database integrity. In temporal databases the same management operations (insert, update, delete and select) are used. However, their implementation is not exactly the same. In update operations the past value is not simply substituted by the new one, because the whole past of data shall be maintained. Both values keep stored in the database, timestamped with proper time values. A delete operation in temporal databases is executed as a logical exclusion. As all the past values shall be preserved, the delete operation is represented through the timestamp, ending its lifetime. Physical exclusion of data may eventually be performed, deleting information that became irrelevant in the application. This operation is called vacuuming, and is seldom performed, only when decreasing the volume of stored data is necessary. When some data is physically removed from the database, the past history is changed and some adaptation may be necessary to keep the database consistent. Considering the removal of a past value, three alternative actions may be executed: (1) The value that was valid immediately prior to the deleted values will continue valid during the time the excluded value was valid; (2) The next valid value will have its beginning anticipated to the beginning of the removed value; or (3) A new defined value may use the temporal interval of the removed one. In the sequence of this paper, delete operation will be analysed considering only logical exclusion. Temporal databases also present integrity constraints, represented as rules that insure the temporal data consistency. These rules are different according to the type of implemented temporal database: Transaction Time Database (TTDB), Valid Time Database (VTDB) or Bitemporal Database (BTDB). Each one of the management operations is analysed in the next subsections, for each temporal database type, analysing how they shall be implemented when a conventional database is used. Based on this analysis, the set of operations to be used to implement in a specific temporal database on top of a conventional database can be defined. The database designer has to decide additionally if new information may be defined only for the present time, or also corresponding to past and future times. This analysis proved to be was necessary during the

implementation of the Temporal Management System presented in this paper, to define how the management operations should be performed. The results, however, may be used to implement any temporal database management system on top of a conventional database. 3.1 Transaction Time Database In TTDBs data may be retrieved according to the time it was inserted in the database. The main advantage of this kind of database is the temporal transparency to a user, because the timestamp is automatically added by the DBMS. To aid the analysis of the operation management in this kind of temporal database, a symbolic example is presented in Figure 1: the value A was inserted in the database at time (TT) 1, and was valid until time 2 when a new valid (B) was defined. A third value (C) is defined at time 3 and keeps valid until now. Figure 1 TTDB: an example. 3.1.1 Insert and Update operations in a TTDB. The insertion of a value for an attribute in a TTDB is executed according to the type of timestamp used in this database timepoint, temporal interval or temporal element. The first definition of a value for an attribute is defined by an insert operation. Further values for the same attribute are defined by update operations. - Timepoint. The instant when the transaction takes place is added to the value. Only the beginning of the validity of a value is known the first time a value is defined for an attribute. This value will last until an update operation defines a new value. As in temporal databases a new value never overwrites an old one, updates result in new insert operations, with corresponding TT timestamps. The lifespan of a value is defined by the difference of TT timestamps of two values defined for the same attribute (Table 1). - Temporal Interval. The timestamp is composed of two temporal values the time when the value was defined (initial TT) and the time when the value ended its validity (final TT). When a new value is defined, the final TT receives a value informing that it is valid until a new value is defined (like null). And when a new value is defined, the last valid value s final TT is completed with the time in which the new information is defined, decreased of one unit of the used temporal granularity (Table 2). - Temporal Element. In TTDB that use temporal elements as timestamps, an insert operation is executed in a similar way as when temporal intervals are used. The only different case is when a value already existent is inserted, with a different temporal interval, resulting in disjunct intervals of validity. When different values are inserted, the operation is executed the same way as the former one. Table 1 Insert TTDB Timepoints Code Address TT 001 Olive Av., 400 01/12/1998 002 Apple Str., 500 10/01/2000......... Table 2 Insert TTDB Temporal Intervals Code Address Initial_TT Final_TT 001 Olive Av., 400 01/12/1998 09/01/2000 002 Apple Str., 500 10/01/2000 Null............

3.1.2 Remove operation in a TTDB. Remove operations result in new insert operations in place of removing a value of the database, its validity time is ended. According to the used timestamp, this operation is executed as follows. - Timepoint. As the value is timestamped only with the TT, there is no way of representing the ending of its validity. However, there are two ways of defining this. The first one is to use an additional attribute informing the state of an information, like A active (informing that the value is valid) and I inactive (representing that the value was logically removed from the database). The second way is to use a kind of null value for the attribute, beginning at the time the value should be removed. - Temporal Interval. The remove operation is executed just ending the validity time (final TT) of the value. The actual TT is used as final TT of this value. - Temporal Element. The same treatment is given to this operation as for temporal intervals. 3.2 Valid Time Databases VTDB use the validity time as timestamp the time when the correspondent value is valid in real world. Each time a value is inserted in the database, the user must inform the correspondent validity time explicitly. Operations on such a database are performed at a slightly differently way as on the previous one. 3.2.1 Insert and Update operations in a VTDB. The insertion of a value in a VTDB is treated according the type of timestamp used in this database. - Timepoint. The timepoint represents the beginning of the validity of the correspondent value. This validity time (VT) may be some time in the past, the actual moment (present) or some time in the future. In update operations, as past values are already stored in the database, several different situations may occur according to the informed VT and the previous values for this attribute: a) VT of the new value is bigger than all the other VTs The new value will begin to be valid at this time, ending the validity of the previous one. Two different situations may occur. Figure 2(a) represents the valid values for a symbolic attribute. An update operation (X, 3) defining a new value X valid at time 3 is represented in Figure 2(b) the validity of value B is ended when this new value begins. If, however, the update operation concerns only the validity time (the same value is defined again, with a new VT), as (B, 3) represented in Figure 2(c), the beginning of the validity of this value is updated. The consequence of this operation is that the validity of the value A is extended until the new beginning of the value B. The last operation is intended to correct a past valid time. Figure 2 Update operation in VTDB b) VT of the new value is equal to the last defined VT This update is intended to correct a previously misinformed value. The database manager shall remove the previous value, and substitute it with the new one, to avoid the existence of two different values with the same VT timestamp, which would lead to an inconsistent state in the database. c) VT of the new value is smaller than the last defined VT This operation is affected by the value that is being defined, that may be equal or not to the last valid value. In case it is different,

the update operation may be performed in two different ways. The first one is to substitute the last valid value by the new one, corresponding to the correction of the last defined value and its VT. The second possible treatment for this operation is to end the validity of the new defined value when the last one begins its validity, corresponding to the insertion of a new value for this attribute during an interval limited by previously defined values. When the new value is equal to the last valid value, the operation represents the correction of this values validity start. d) VT of the new value is equal to the VT of some previous value This definition may also be interpreted in two different ways. The first one is to consider this operation to be intended to correct the whole database from this timepoint on, removing all the values with VTs after the new one. Or, alternatively, to implement the correction of only one value, and substitute the value that had that VT by the new one. e) VT of the new value within some previous validity interval The execution of this operation depends on the value defined for the attribute. If this value is equal to the next valid value, the operation represents the update of the VT of this value, which will begin sooner. In Figure 3, B was valid starting at time 2, and the update (B, 1.5) anticipates its validity to 1.5. When a new value is defined, like (X, 1.5), the manager may define the new value as valid until a new one becomes valid, as in Figure 4(a). He can also interpret this update as the correction of the database starting at that timepoint, and remove all the values with bigger VTs, as in Figure 4(b). Figure 3 VT update Figure 4 Two treatments for value update - Temporal Interval. When VTDBs are used, the user must inform the two limits of the temporal validity interval. Depending on the already existent validity intervals, the following situations may occur: a) The last valid interval has an open upper bound (is valid until a new value is defined) and the validity of the new defined value begins during the previous one The beginning of the validity of the new value will end the validity of the precious one. This is represented in the database closing the validity interval of the previous value. As an example, suppose a database in which the last valid interval is (A,20,>>), where the symbol >> represents the open interval. When the new value (X,30, >>) is inserted, the interval of the value A is closed by the DBMS with a value equal to the beginning of the new values interval, decreased by one unit of the used temporal granularity, for instance, (A,20,29). b) The validity interval of the new value begins after the ending of the last valid value When the new interval is exactly adjacent to the previous one, there is a continuous evolution of the data, as represented in Figure 5(a). However, a new interval may be defined leaving behind intervals where no value is defined, as in Figure 5(b), where the value B ended its validity on time 30, and the new defined value X only begins to be valid on time 35. Consequently, there is no valid value for this attribute during the interval [31, 34].

Figure 5 Update operation validity interval after the former one c) The new defined values validity interval begins at the same time as another already existent validity interval In this case the DBMS shall take care of adapting the previous information, to prevent temporal inconsistency. Depending on the duration of this interval, different semantics for this definition may be identified. If the new validity interval ends during the intersected interval, the operation may represent the correction of the value of part of the interval of the previous one, adapting only the beginning of the former interval to the moment after the new one ends its validity. If the new valid interval has an upper bound equal to the end of other values validity interval, the operation will simply substitute the previous value by the new one. This case can be extended when the new value interval overlaps more than one of the already existent intervals. The new value is defined, the previous values that have their validity intervals completely overlapped are simply excluded from the database, and the last one may have the beginning of its validity interval postponed. The extreme case would be when the new value presents as open interval, intending to be valid until a new value is defined all the values from the beginning of the new one shall be deleted from the database, corresponding to the correction of all these values. d) The new values validity interval begins during the validity interval of a previously defined value Similar to the last presented case, but beginning during the other values interval, this situation also requires a correction of the database to be executed by the DBMS. When the intersection of the new value interval is only with one of the defined intervals, the previous value keeps valid on the two remaining intervals before and after the new value, as exemplified in Figure 6(a). When the new interval intersects multiple intervals, the new definition shall prevail, and only the remaining parts of the interval, before and after the new one are maintained, as in Figure 6(b). This may imply the complete exclusion of values from the database. And when the new interval has an open upper bound, the part of the interval before it s beginning is kept, and the next values are all deleted, as in Figure 6(c). Figure 6 Update operation validity interval overlapping other intervals - Temporal Element. The management of insert and update operations in VTDBs when temporal elements are used is similar to the one used for temporal intervals. When update operations are used, each new defined temporal interval shall be analysed according to the already defined temporal intervals. Eventually, past information shall be physically updated by the DBMS to prevent temporal inconsistency. 3.2.2 Remove operation in VTDB. Remembering that in temporal databases only logical removals are allowed, the management of the remove operation is performed by the DBMS adapting timestamps. The update operation shall always inform the temporal reach of this removal during a defined temporal interval or from a given timepoint on. According to the used timestamp, this operation shall be performed differently. - Timepoint. When timepoints are used, only the beginning of information s validity is stored in the database. A solution to implement this operation is to insert a kind of null value in the database, with the timepoint corresponding to the end of the validity of the information.

- Temporal Interval and Temporal Elements. When valid time intervals are used as timestamps (temporal intervals or temporal elements), the remove operation is performed adapting the correspondent timestamps. This is done in a similar way as for the update operation, differing only by the fact that no new value is defined; only the validity interval of the already defined values is adapted. It may occur that a new insertion takes place, when the interval in which the value shall be removed is within the correspondent validity time the remaining validity intervals (before and after the removed one) shall be preserved. 3.3 Bitemporal Databases Both timestamps VT and TT are used in bitemporal databases. Only the VT must be informed by the user. This leads to a special treatment for the operations management. 3.3.1 Insert and Update operations in Bitemporal Databases. As both timestamps are used, the temporal inconsistencies identified in several possible update situations do not occur in this kind of database. Even if the validity intervals intersect already existent validity intervals, the existence of the transaction interval defines when each value is valid. Consequently, information is never removed from the database. 3.3.2 Remove operation in Bitemporal Databases. This operation shall be executed in a similar way as in VTDBs, only adding the correspondent transaction time. When timepoints are used, a kind of null value shall be defined, to inform when the value stopped to be valid. This null value may also be used with temporal intervals, associated to the interval in which the information shall be removed. 4 The TF-ORM Data Model TF-ORM (Temporal Functionality in Objects with Roles Model) [7, 94] is a temporal object-oriented data model. This model differs from other temporal object-oriented data models by the use of the role concept. Several roles may be defined for each class, expressing different behaviours that an object of this class can present. Instances of these roles are dynamically instantiated during the existence of an object. As an example, a person in a hospital (represented as an instance of a class Person) may play the roles of patient, doctor, nurse, etc. An object is still an instance of only one class, but it can play different roles during its lifetime (the same person may evolve from the nurse role to the doctor role). The same object may also present two or more roles at the same time (a doctor may also be a patient of the hospital). In addition, an object can have more than one instance of the same role at the same time (as when a doctor works in two different hospitals). Three different class types can be defined: (i) resource classes, modelling information and resources; (ii) process classes, representing the processes to be executed with this information and the resources; and (iii) agent classes, representing the persons that carry out the processes. The three class types are modelled in a similar way. Each role is defined by: A name, unique in the corresponding class. Static properties (having the same value all over the instances lifetime) and dynamic properties (when they may assume different values with time), the last being timestamped with transaction and validity time. A set of abstract states the role can assume while playing this role.

The messages the role can receive or send. Human decisions are represented in agent classes as incoming messages. State transition rules and constraint rules that define the dynamic evolution of an object. These rules model the temporal behaviour of an object playing a specific rule, and must be analysed by the DBMS during data definition. Temporal information are associated to all the instances (class and role instances) - the instance's creation and destruction time, and the time instants in which the instance's activity was suspended and resumed. These temporal information are stored in special pre-defined properties and can be used by the query language [8] to retrieve information. Pre-defined properties are inherited from a superclass Object, from which all the TF-ORM defined classes are sub-classes. Each class presents a special role, the base role, where the global properties inherited by all other roles and the initial characteristics of the other roles are described. The TF-ORM model supports specialisation and aggregation mechanisms, with the possibility of inheriting roles, or redefining them. Each class presents a special role, called Base_Role, where the properties inherited by all the other roles of the class are defined, together with the rules that control the role instantiation. An example of the TF-ORM definition language for the agent class Person is the following: agent class( PERSON, < Base_role, static properties = { (birth, date),... } dynamic properties = { (name, string),... } rules = {...} >, < Patient, static properties = { (code, string),...} dynamic properties = { (occupation, string),... } states = { newpatient, active, } messages = { insertinitialvalues (Code:string, Sex:{F,M}, Birth:date, ) from CONTROL.PatientCtrl,... }, decisions = { new_name (name: string), }, rules = { init: state(newpatient), msg(insertinitialvalues (Code, Sex, Birth, )) state(active); (not exists Rid (value(rid, code) = Code)),... } >, < Doctor,... >, < Nurse,... > ) 4.1 The TF-ORM Rules State transition rules and constraints may be defined in the Base_Role, applying to all the instances of roles of this class, or within any other role, being specific to the instances of this role. 4.1.1 State transition rules. State transition rules define the valid transitions among the states defined for this role. The general form of this rule is the following: R1: state(s 1), msg (m 1) state(s 2), msg(m 2); < condition > The state transition is executed when the instance is in state s 1, receives the message m 1 (or, eventually, a set of messages), and only if the condition is satisfied. The state transition changes the instances state to s 2 and the message m 2 (or a set of messages) is sent. Agent class decisions may be used in these rules as incoming messages. Alternative constructions of this rule may be used: The initial state s 1 is not defined the rule is executed every time the message m 1 arrives, provided the condition is valid, independently of the actual instances state. The incoming message m 1 is not defined the transition takes place each time the state s 1 is reached, depending only on the condition validity.

The outgoing message m 2 is not defined the state transition takes place without sending any message. The final state s 2 is not defined the rule is executed only sending one or multiple messages, without really occurring a state transition. The condition is not defined the state transition takes place depending only on the initial state and incoming messages. In the previous example, the rule init is executed when the instance is in state newpatient, receives the message insertinitialvalues and the condition (not exists Rid (value(rid, code) = Code) is valid. The condition guarantees that the value informed for the Code of the patient (past as a parameter of the incoming message) is unique in the database. 4.1.2 Integrity rules. The integrity rules shall always be satisfied by all the instances of a class/role. They are represented in TF-ORM in the following way: R1: constraint ( < pre-condition > < post-condition > ) This rule states that, each time the pre-condition is satisfied, the same shall occur with the postcondition. Inconsistent states of the database are this way detected. Integrity rules defined within a role shall be checked each time that a state transition is executed. When they are defined in the Base_Role, they shall be verified each time that a state transition occurs in any of the roles. If the constraint is not satisfied, the previous values of the database prior to this transition shall be restored, undoing the transition. 5 Mapping and Managing TF-ORM on Oracle The need of implementing a DBMS supporting TF-ORM led to the solution of using a conventional database, mapping the temporal model to it, and managing the data definition according to the TF-ORM rules. This section describes how a TF-ORM manager was implemented on the conventional database Oracle. The choice of Oracle was defined by the possibility of supporting the TF-ORM rules, due to the existence of special mechanisms like triggers, stored procedures, stored functions and views. Besides this, Oracle is a very popular commercial database. The use of a relational database to implement an object-oriented database is not a new solution, requiring only a suitable mapping between the two different data models. This paper adds the explicit representation of the temporal data model timestamps, thus implementing a temporal database. Another important characteristic of Oracle is the already available manipulation of dates, necessary to implement a temporal data model. As TF-ORM uses both the transaction and the validity times as timestamps, a bitemporal database is implemented. To simplify the query evaluation, temporal intervals were used as timestamps in place timepoints. No restriction of temporal definition was made (past, present and future times may be defined). The operation management is executed by specific procedures that update the database according to the manipulated tables, using triggers to prevent user actions. The general structure of the TF-ORM manager is presented in Figure 7. The manager receives the schema information in two files, generated by a specification tool, the TF-ORM Specification Builder [6]. This tool initially supports a user during the specification, and guarantees that no inconsistent information is defined. The generated specification is then divided in two files, the first one containing the classes and roles, and their properties, and the second one containing all the rules that were defined, associated to the classes/roles to which they belong. The TF-ORM Manager begins analysing the classes and roles file, mapping all the defined classes, roles and their properties to Oracles tables, as explained below. Figure 8 details the internal structure of the TF-ORM Manager, showing how each one of the TF-ORM information is represented in Oracle.

Figure 7 TF-ORM Manager general structure 5.1 Classes and roles mapping Figure 8 TF-ORM mapping to Oracle The mapping of TF-ORM to relational databases is based on the one proposed in [4]. A table (named BASE table) is defined for each class, and for each role of a class. In this table the static properties of the class/role are represented, together with the class/role identifier. The class identifier (OId) performs the union of all the tables representing the roles of this class. Each dynamic property is mapped to a separate table, containing the values defined for the attribute together with the temporal timestamps, explicitly represented as attributes, and the class or role identifier to relate this attribute to the correspondent class/role. Being a bitemporal data model, the temporal attributes represent the beginning and ending of the transaction time (t_timei and t_timef), and of the valid time (v_timei and v_timef). An example is presented in Table 3, representing the dynamic property City.

Table 3 Dynamic property representation OId City t_timei t_timef v_timei V_timef 001 Porto Alegre 01/12/1998 09/01/2000 01/01/1999 31/12/1999 001 Gramado 10/01/2000 null 01/01/2000 Null 002 Canela 01/01/1999 31/12/1999 01/01/1999 30/11/1999 To allow the retrieval of all the objects evolution history, the manager stores the states assumed by class and role instances in special tables, using the same structure as for dynamic properties. The class and role instances timestamps, representing the evolution of the whole instance, are stored in additional tables, relating the class/role identifier to the timestamps. There is one table for the history of all class instances and another for the role instances. Analysing these, the creation time of the instance may be retrieved, together with and its lifetime (Table 4 presents the objects lifetime table). Table 4 Objects lifetime table 5.2 Messages and decisions mapping Oid t_timei t_timef v_timei v_timef 001 10/01/1998 null 01/01/1998 null 002 01/01/1999 09/01/2000 01/01/1999 09/01/2000 003 10/10/1999 null 10/10/1999 null Messages and decisions of a TF-ORM schema trigger the state transitions, modelling the instances evolution. They were implemented using Oracle s stored procedures and views. Stored procedures were used to implement messages that result in insert, update and remove operations. Messages and decisions that represent a selection on the database were implemented as views. This approach was used due to the flexibility for a user when he needs to restrict the scope of a query. 5.2.1 Automatic method mapping. Different classes/roles may be manipulated at the same time by a TF-ORM message. An automatic message interpreter was defined, with the aim of turning this mapping transparent to a user. The interpreter initially gets information concerning the static and dynamic properties of classes and roles, to link the identified properties of a message to the corresponding class/role. To make this possible, the message attributes shall present the same name as defined properties. The interpreter gets these information directly from the class and role file, constructed by the specification tool. After this, the interpreter is able to generate these messages in the database, through stored procedures and views. As an example, consider the following message of the example presented in section 3: insertinitialvalues (Code: string, Sex: {F,M}, Birth: date, Name: string, Address: string, City: string, Phone: string, Fax: string, Occupation: string, Religion: string, Education: string) from CONTROL.PatientCtrl, The automatic mapping of this message would be almost impossible because the manager would not know which would be the operations to be implemented, and which tables would be involved in these operations. He gets these information from the definition file. Knowing that the message belongs to the role Patient from the class Person, the corresponding properties can be identified, together with the tables in which they are represented. However, this does not inform which are the operations to be performed according to this message. To allow an automatic mapping, a standard naming of messages may be used. For instance, a solution may be the following: all messages shall present the name beginning with one of the following prefix: - Insert, for messages that aim to insert values to all the arguments, and these shall present the same name as the correspondent properties; - Update, for update operations; - Delete, to remove properties values, in fact implemented as finishing their lifetime; and

- Select, to represent retrieval operations. Messages that select information from the database will be implemented using Oracle views, to improve the flexibility. Additional information is added to a view that is not present in the original message, as transaction and validity times. The Oracle operators GREATEST and LEAST are used to identify, respectively, the latest and the earliest date from a set of dates. An example, the implementation of the above message in Oracle is the following: CREATE procedure insertinitialvalues(oid number, Rid number, Code number, Sex varchar2, Birth date, Name varchar2, Address varchar2, City Varchar2, Phone varchar2, Fax varchar2, Occupation varchar2, Religion varchar2, Education varchar2) as begin insert into person values(oid,sex,birth,null); insert into person_name values(oid,name,sysdate,null,sysdate,null); insert into person_end values(oid,address,sysdate,null,sysdate,null); insert into pessoa_cidade values(oid,city,sysdate,null,sysdate,null);... end; In the same way procedures are automatically defined, the views may also be created. The original message shall be analysed, to identify the involved tables. An example of a view implementation is the following: CREATE VIEW retrieve_patient(oid, rid, code, sex, birth, name, address, city, phone, fax, occupation, religion, education, t_timei, t_timef, v_timei, v_timef) AS SELECT p.oid, pa.rid,pa. code,pa. p.sex, p.birth, pn.name, pe.address, pc.city, pf.phone, pfa.fax, pp.occupation, pr.religion, ped.education, pm.moradia, GREATEST(pn.v_timei,pe.v_timei,pc.v_timei,pu.v_timei,pf.v_timei,pfa.v_timei,pp.v_timei,pr.v_timei,ped.v_timei, pm.v_timei), LEAST(pn.v_timef,pe.v_timef,pc. v_timef,pu. v_timef,pf. v_timef,pfa. v_timef,pp. v_timef,pr. v_timef,ped. v_timef,pm. v_timef), GREATEST(pn.t_timei,pe. t_timei,pc. t_timei,pu. t_timei,pf. t_timei,pfa. t_timei,pp. t_timei,pr. t_timei,ped. t_timei,pm. t_timei), LEAST(pn.t_timef,pe. t_timef,pc. t_timef,pu. t_timef,pf. t_timef,pfa. t_timef,pp. t_timef,pr. t_timef,ped. t_timef,pm. t_timef) FROM person p,patient pa,person_name pn,person_address pe,person_city pu,person_phone pf,person_fax pfa,patient_occupation pp,patient_religion pr,patient_education WHERE p.oid = pa.oid AND p.oid = pn.oid AND p.oid = pe.oid AND p.oid = pu.oid AND p.oid = pf.oid AND p.oid = pfa.oid AND pa.rid = pp.rid AND pa.rid = pr.rid AND pa.rid = ped.rid AND pa.rid = pm.rid ; 5.3 Rule mapping Only state transition rules were initially implemented, due to the fact that constraint rules may always be always be represented as state transition rules. Triggers are used to represent the state transition rules. However, they do not allow the complete representation of the state transition rules, because several tables should be manipulated at the same time. For this reason, triggers are used only on the rules that aim to maintain the integrity of the database. Procedures may be used to represent state transition rules in a very easy and clear way, but they do not provide the required triggering hability. This shall be simulated through application programs, accessing the database. When a procedure is called through a declaration of the database, parameters are used to receive and return values, and other procedures may be fired, even triggers may be used. Suppose the following state transition rule: R1: State(S1), Msg(M1) State(S2), Msg(M2); < condition > This rule is implemented as follows: State(S1) Is implemented through a special attribute that identifies the state of a tuple. These states are implemented through constraints already existent in the database, as check constraints.

Msg(M1) The messages M1(s) are created by procedures, when the insert, update and remove operations are concerned, or by views, for select operations. State(S2) is the update of the State attribute. To change the instance s state, an update operation is performed, on the state table of the considered instance. Msg(M2) Represents the set of messages that shall be sent. These messages are directed to the user, but may also be implemented as new procedures and views that will perform further operations. The operations addressed in this paper are messages that trigger a specific rule, allowing the update of properties and the mapping of transition state rules of the TF-ORM data model. Once the manager defines all the messages and states, they shall be linked to represent the real structure of the state transition rule. This may be done in two different ways. The first one is to define an additional procedure, in which the structure of the rule is defined, starting the other procedures and verifying the involved states there is no freedom in this type of implementation, once the mapping is directed to the correct sending of messages. The second way is to let the application execute the transition, which is a better option, leading to a more flexible implementation. This last option was used in the manager presented in this paper. 6 Conclusion Researches in temporal database implementation showed that such databases might be implemented on top of conventional databases, mapping the temporal features to explicit attributes representing time. Some experiences were done implementing the TF-ORM data model on different databases [2, 4, 15]. The mapping of the static and dynamic properties, allied to classes and roles, showed to be possible. However, data definition management was not considered, and the rule management was not performed. This paper presents the implementation of a TF-ORM manager, on top of the conventional database Oracle. Rules are analysed and data temporal consistency is assured. The development of this manager was based on a detailed analysis of how the data management shall be implemented in the different types of temporal databases. Only the relational features of Oracle were used. This decision was based on the fact that relational databases are largely used, leading thus to a system with a great flexibility, which can be adapted to other relational databases with very little effort. Messages and decisions were implemented using procedures and visions, allowing their exact representation in the database. The implementation of the TF-ORM rules could not be realised using only the database resources. The user shall provide additional information to allow the rule management. However, all the components of the rule were defined using procedures. Triggers were used to create rules to assure the database temporal consistency. The presented TF-ORM manager is part of an integrated environment implementing TF- ORM. This environment includes not only the already mentioned specification tool, but also a query tool [14], that translates queries expressed in the TF-ORM query language to SQL. References [1] ANTUNES, D. C.; HEUSER, C. A.; EDELWEISS, N. TempER: uma abordagem para modelagem temporal de banco de dados. Revista de Informática Teórica e Aplicada, v.4, n.1, p.49-85, 1997. Porto Alegre: Instituto de Informática da UFRGS, 1997. [2] ARRUDA, E. H. P. Um Modelo de Implementação da Linguagem TF-ORM para o SGBD O 2. Porto Alegre: CPGCC da UFRGS, 1994. (TI - 408). [3] BRAYNER, Â. R. A.; MEDEIROS, C. B. Incorporação do tempo em um SGBD orientado a objetos. Anais do 9 0 Simpósio Brasileiro de Banco de Dados, São Carlos, SP, 1994.

[4] CAVALCANTI, J. M. B et al. Uma abordagem para a implementação de um modelo temporal orientado a objetos usando SGBDs relacionais. Anais do 10 o Simpósio Brasileiro de Banco de Dados, Recife, PE, outubro 1995. [5] CLIFFORD, J.; CROCKER, A. The historical relational data model (HRDM) and algebra based on lifespans. IEEE Transactions on Software Engineering, v.14, n.7, July 1988. [6] DEMARTINI, G.; EDELWEISS, N. Ferramenta de Especificação TF-ORM e Mapeamento para um Banco de Dados Relacional. Porto Alegre: PPGC da UFRGS, 2000. (Relatório de Pesquisa 307). [7] EDELWEISS, N.; Oliveira, J.P.M.; PERNICI, B. An Object-Oriented Temporal Model. Proceedings of the 5 th International Conference on Advanced Information Systems Engineering - CAISE 93, Paris, 1993. Heidelberg: Springer-Verlag, 1993. p.397-415. LNCS 685. [8] EDELWEISS, N. Modelagem de Aspectos Temporais de Sistemas de Informação. 9 a Escola de Computação, Recife, PE, 1994. 162p. [9] EDELWEISS, N. Bancos de Dados Temporais: Teoria e Prática. In: XVII Jornada de Atualização em Informática, do XVIII Congresso Nacional da Sociedade Brasileira de Computação, v.2. Ed.: H.P. MOURA. Anais Recife: Sociedade Brasileira de Computação, 1998. p.225-282. [10] ETZION, O.; JAJODIA, S.; SRIPADA, E. (Eds.) Temporal Databases: Research and Practice. Berlin: Springer-Verlag, 1998. LNCS 1399. [11] ELMASRI, R.; WUU, G. T. J. A temporal model and query language for EER databases. In: Temporal Databases: Theory, Design, and Implementation. Bridge Parkway: Benjamin/Cummings, 1993. p. 212-229. [12] HÜBLER, P. N.; EDELWEISS, N.; CARVALHO, T. P. Implementação de um banco de dados temporal utilizando um SGBD convencional. Anais da XXV Conferencia Latinoamericana de Informatica - CLEI 99, 30 agosto a 3 de setembro, 1999, Asunción, Paraguai. p.99-110. [13] JENSEN, C. S. et al. The Consensus Glossary of Temporal Database Concepts - February 1998 Version. In: Temporal Databases Research and Practice. O. Etzion, S. Jajodia and S. Sripada (eds.) Berlin- Heidelberg: Springer-Verlag, 1998. p. 367-405. [14] MORO, M. M.; EDELWEISS, N. Interface de Consultas TF-ORM para Oracle. A ser publicado nos Anais da XXVI Conferencia Latinoamericana de Informatica CLEI 2000, 18-22, Cidade do Mexico, México, outubro, 2000. [15] OLIVEIRA, J.P.M. et al. On the Implementation of an Object-Oriented Temporal Model using Object-Oriented and Relational DBMSs. Workshop Proceedings of the 6 th Database and Expert Systems Applications Conference DEXA 95, London, U.K, 1995. p.35-44. [16] ÖZSOYOGLU, G.; SNODGRASS, R. T. Temporal and real-time databases: a survey. IEEE Transactions on Knowledge and Data Engineering, New York, v.7, n.4, p.513-532, Aug.1995. [17] SARDA, N. L. Extensions to SQL for historical databases. IEEE Transaction on Knowledge and Data Engineering, v.2, n.2, June 1990. [18] SIMONETTO, E. O. Uma Proposta para a Incorporação de Aspectos Temporais no Projeto Lógico de Bancos de Dados, em SGBDs Relacionais. Porto Alegre: Pontifícia Universidade Católica do Rio Grande do Sul, 1998. Dissertação de Mestrado. [19] SNODGRASS, R. The Temporal query language Tquel. ACM Transactions on Database Systems, New York, v.12, n.2, p.247-298, June 1987. [20] TANSEL, A. U. Et al (Eds.) Temporal Databases: Theory, Design, and Implementation. Bridge Parkway: Benjamin/Cummings, 1993. [21] THEODOULIDIS, B. The ORES temporal databases management system. SIGMOD Record (ACM Special Interest Group on Management of Data), v.23, n.2, p.511-511, June 1994. [22] TIME DB, A Temporal Relational DBMS. Available at: http://www.timeconsult.com/software/software.html. (1999). [23] TOOBIS - Temporal Objects-Oriented Databases in Information Systems. Available at: http://www.di.uoa.gr/~toobis/description.html. (2000). [24] WUU, G. T. J; DAYAL, U. Uniform Model for Temporal and Versioned Object-Oriented Databases. In: Temporal Databases: Theory, Design, and Implementation. Bridge Parkway: Benjamin/Cummings, 1993. p. 230-247. [25] ZANIOLO, C. et al. Advanced Database Systems. San Francisco: Morgan Kaufmann Publishers, 1997. 574p.