TimeLab The TAU Temporal Object Model - CiteSeerX

TimeLab Technical Report

The TAU Temporal Object Model TR-96-4 October 1996

Synopsis This report presents the TAU Temporal Object Model. The TAU Model is a high level data model that extends the ODMG Object Model in order to support temporal semantics. The basic concepts introduced by the TAU Model are valid time, transaction time, temporal objects, temporal extents, lifespans, temporal attributes, temporal relationships, property histories and temporal literals.

Authors Ioannis Kakoudakis Babis Theodoulidis

Document State Final

TABLE OF CONTENTS

1. Introduction 1 2. TAU Model design principles 1 3. Dimensions of Time 2 4. Types 2 4.1 Literal types......................................................................................................................... 3 4.1.1 Atomic Literals ........................................................................................................................3 4.1.2 Structured Literals...................................................................................................................4 4.1.3 Collection Literals ...................................................................................................................4

4.2 Object types......................................................................................................................... 4 4.2.1 Atomic object types..................................................................................................................5 4.2.2 Collection types .......................................................................................................................5

4.3 Abstract types...................................................................................................................... 5 4.4 The Full Built-in Type Hierarchy.......................................................................................... 6 5. Atomic Objects 6 5.1 Static state objects ............................................................................................................... 7 5.2 Transaction state objects ...................................................................................................... 7 5.3 Valid state objects................................................................................................................ 8 5.4 Bitemporal state objects..................................................................................................... 10 6. Modelling State-Properties 11 6.1 Property timestamping....................................................................................................... 11 6.2 Timestamp category........................................................................................................... 11 6.3 Attributes........................................................................................................................... 11 6.3.1 Static attributes .....................................................................................................................11 6.3.2 Transaction time attributes ....................................................................................................12 6.3.3 Valid time attributes ..............................................................................................................12 6.3.4 Bitemporal time attributes .....................................................................................................13

6.4 Relationships...................................................................................................................... 14 6.4.1 Static relationships ................................................................................................................15 6.4.2 Transaction time relationships ..............................................................................................16 6.4.3 Valid time relationships .........................................................................................................18 6.4.4 Bitemporal time relationships ................................................................................................19

7. Modelling Behavior-Operations 20 8. Inheritance 20 9. Extent 23 10. Object lifespan 24 10.1 Transaction time lifespan.................................................................................................. 24 10.2 Valid time lifespan............................................................................................................ 24 10.3 Example of lifespan.......................................................................................................... 25 11. Equality 26 12. Keys 28 13. Modelling histories 28 13.1 Transaction time histories................................................................................................. 28

13.2 Valid time histories.......................................................................................................... 30 13.3 Bitemporal time histories.................................................................................................. 31 14. Temporal object types 32 14.1 Transaction time object type - TT_Type........................................................................... 32 14.2 Valid time object types - VT_Type................................................................................... 33 14.3 Bitemporal object types - BT_Type.................................................................................. 34 15. Delete - Vacuum 35 16. Type Compatibility 36 17. Summary 38 18. Acknowledgements 38 19. References 38

LIST OF FIGURES

Figure 1: Full Set of Built-in Types........................................................................................... 6 Figure 2: Categories of objects in TAU Model.......................................................................... 7 Figure 3: Transaction time histories of the properties................................................................ 8 Figure 4: Representation of a valid time object.......................................................................... 9 Figure 5: Graphical representation of a bitemporal object........................................................ 10 Figure 6: Graphical representation of a bitemporal attribute.................................................... 14 Figure 7: Static one-to-many relationship................................................................................ 16 Figure 8: Transaction time one-to-many relationship............................................................... 18 Figure 9: Inheritance and temporal object types...................................................................... 21 Figure 10: Representation of Extent........................................................................................ 23 Figure 11: Graphical representation of a valid time lifespan..................................................... 26 Figure 12: Computers of manager M1.................................................................................... 27 Figure 13: Intersection and difference of histories.................................................................. 29 Figure 14: Deletion of a valid state object............................................................................... 34 Figure 15: Updating objects.................................................................................................... 37

The TAU Temporal Object Model Ioannis Kakoudakis, Babis Theodoulidis Department of Computation UMIST P.O. Box 88 Manchester M60 1QD United Kingdom tel: +44 0161 200 3309 fax: +44 0161 200 3309 email: {kakoud,babis}@co.umist.ac.uk http://timelab.co.umist.ac.uk

1. Introduction A data model is a set of concepts that can be used to describe the structure of a database [ELMNAV94]. The structure of a database includes data types, attributes, relationships, constraints and other constructs that should hold for the data. A data model also includes a set of basic operations for the manipulation of the database. Data models are classified in three main categories depending on the types of concepts they provide in order to describe the database structure. High level or conceptual data models provide concepts which encourage a developer to concentrate on the semantics of the application domain rather than the characteristics of the delivered system [GRITH82], whereas low-level or physical data models provide concepts that describe the details of how data is stored in the computer. The third category is the class of representational or implementation data models, which provide concepts that may be understood by end users but are not too far removed from the way data is organised within the computer [ELMNAV94]. The TAU Model which is presented in this report, is a high level data model that combines object database concepts with temporal database concepts. The basic constructs introduced by the TAU Model are valid time, transaction time, temporal objects, temporal extents, lifespans, temporal attributes, temporal relationships, property histories and temporal literals.

2. TAU Model design principles The design principles of the TAU Model are summarised as follows: • TAU Model should be a consistent, fully upwardly compatible extension of ODMG Object Model. • TAU Model should support both transaction time and valid time. • TAU Model should provide a set of appropriate constructs and mechanisms for modelling temporal objects and manipulating their evolution over time.

The TAU Temporal Object Model

• Temporal support should be optional on per atomic object type basis. • The time axis should always consider to be linear, discrete, bounded, and totally ordered. • TAU Model should support the Gregorian calendar. • TAU Model should support multiple granularities. • User-defined time support should include Timestamps, Timepoints, Intervals, Periods and Temporal-Elements. • TAU Model should be formally specified. The scope of the TAU Model design was restricted so that a coherent design is possible. In its current version TAU Model will not support object versioning, object migration, multiple calendars, and temporal indeterminacy.

3. Dimensions of Time In the proposed temporal database models, two time dimensions are of general interest: valid time and transaction time. The valid time of a fact is defined as the time when that fact is true in the modelled reality [JENSEN94A]. Valid times can belong in the past, present or future depending whether the fact was true in the past, is true at the present or it will become true in the future. Valid times are usually supplied by the user. Transaction time of a fact is defined as the time when that fact is current in the database and may be retrieved [JENSEN94A]. Transaction times are provided by the system and they cannot be changed. Additionally they are bounded between the database creation time and the current transaction time. The two time dimensions are orthogonal despite the fact that there are some application-dependent relationships between them [TSQL2]. For example consider the situation where a fact is recorded as soon as it becomes valid in reality. In this case the valid and transaction times of a fact are identical. TAU Model is bitemporal, i.e. it supports both valid time and transaction time. Furthermore temporal support is optional; the model provides the users with the ability to choose the temporal support for a model construct according to their needs. Facts can be associated with transaction time, valid time, both or none of them. This flexibility has as results: modelling power, storage economy and efficiency of query processing.

4. Types A type defines the state and behavior of its instances. The state of an instance is defined by a set of properties, i.e., attributes and relationships while the behavior of an instance is defined by a set of operations. When we don’t need to distinguish between the state and behavior of a type we refer to its characteristics. A type has one interface and one or more implementations. The interface specifies the external characteristics supported by instances of the type. These external characteristics consist of a set of properties and a set of operations. The implementation defines the internal aspects of the instances. It consists of data structures and a set of methods. The methods are procedure bodies that operate on the data structures to support the externally visible state and behavior defined in the interface. There is a method for each of the operations defined in the type's interface specification. In addition an implementation can includes methods that have no direct counterpart in the object's interface. The distinction between interface and implementation is termed as encapsulation. The following example is a sample interface definition for an object type in the syntax of TODL.

Page 2


bt_interface Product // type characteristics ( extent Products key Code vt_lifespan DAY ) // instance properties: { attribute Integer Code; vt_attribute String Name; bt_attribute Float Price; vt_relationship Department produced_by inverse Department::produces; bt_relationship Set is_bought_by inverse Customer::buys; // instance operations: Float PricePlusVat(Timepoint vtime); }

The combination of a type interface specification and a one of the implementations defined for the type is termed as class. TAU Model supports all the built-in types provided by the Object Model and extends their set by introducing new types with temporal semantics. The set of types can be decomposed into literal types and object types. The instances of literal types are called literals, while the instances of the object types are called objects.

4.1 Literal types Instances of literal types are immutable. Each literal has an identity which is represented by a bit pattern that encodes its value. Literal types can be decomposed into atomic literal types, structured literal types and collection literal types. 4.1.1 Atomic Literals Numbers and characters are examples of atomic literals. All instances of atomic literal types implicitly pre-exist, therefore there is no explicit create operation defined on them. The model supports the following atomic literal types:

Long Short Unsigned long Unsigned short Float Double Boolean Octet Char (character) String Enum (enumeration)

All the above types are all also supported by the ODMG Object Model.

Page 3


4.1.2 Structured Literals A structured literal, or simply structure, has a fixed number of elements, each of which has a variable name and can contain either a literal value or an object [GATTELL96]. The model supports the following structured literal types:

Date Time Timestamp Timepoint Interval Period

From the above structured literal types, the ODMG Object Model supports the types Date, Time, Timestamp and Interval. These types are defined as in ANSI SQL specification. Additionally, TAU Model supports the types Timepoint and Period. Timepoint refines the type Timestamp to include granularity. The Period type is used to represent an anchored duration of time that is, a duration of time with a starting and ending point. The full definition of these types can be found in [TAUTIME]. Developers can define additional structure types according to their needs. TAU Model supports the built-in type generator Struct, specified by the ODMG Object Model, which is used to define application structures. Structures may be freely composed. The model supports both structures of collections and collections of structures. 4.1.3 Collection Literals Instances of collection literal types are used to group distinct elements. Their elements can be of literal types or object types. The model supports the following collection literal types:

Set Bag List Array Temporal_Element

From the above collection literal types, the ODMG Object Model supports the types Set, Bag, List and Array. Each of these is a type generator, parameterized by the type shown within the angle brackets. Additionally, TAU Model supports the type Temporal_Element which is used to represent a finite union of periods. The full definition of theTemporal_Element can be found in [TAUTIME].

4.2 Object types Instances of object types are mutable objects. An object’s identity uniquely distinguishes the object from all other objects within the domain in which the object was created. This identity is referred to as an object identifier (or Object_Id). Changing the values of the attributes of an object, or the relationships in which it participates, does not change the identity of the object. Object types consist of atomic object types and collection types. All object types have the following interface, which is implicitly inherited by the definition of all user-defined object types: interface Object { Boolean same_as(Object o2); Object copy(); }

Page 4


The same_as operation allows the identity of any two objects to be compared. The operation copy copies the value of the current object into a new object which is returned by the operation. The operation signatures used in this chapter have the following form: operation_name([argument {,argument}]) [->result]

where: {symbol} means a sequence of 0 or more symbol(s) [symbol] means an optional symbol argument ::= argument_name: argument_type result::=result_name: result_type

4.2.1 Atomic object types Atomic object types are user-defined types. The model does not provide direct instantiable atomic object types. Instead it provides types that define built-in characteristics and semantics to be included in the user-defined types. Atomic object types can be decomposed into static object types, transaction time object types, valid time object types and bitemporal time object types. The model defines their built-in characteristics in the following types (see section14):

S_Type TT_Type VT_Type BT_Type

Types that have been declared as S_Type are termed as static object types while their instances are termed as static state objects. S_Type corresponds to the type Atomic_object specified by the ODMG Object Model and it does not have any temporal aspects. Types that have been declared as TT_Type are termed as transaction time object types while their instances are termed as transaction state objects. TT_Type provides transaction time facilities. Types that have been declared as VT_Type are termed as valid time object types while their instances are termed as valid state objects. VT_Type provides valid time facilities. Types that have been declared as BT_Type are termed as bitemporal time object types while their instances are termed as bitemporal state objects. BT_Type provides bitemporal time facilities, i.e. both transaction and valid time. Because their temporal facilities types that have been declared as TT_Type, VT_Type or BT_Type are termed as temporal object types. 4.2.2 Collection types The model supports the following collection types:

Set Bag List Array

The above types are all also supported by the ODMG Object Model. Collection types behave the same as the collection literal types, except that they are mutable and their instances are associated with an object identifier.

4.3 Abstract types Types are classified into two categories depending on whether they are directly instantiable or not. The types that are directly instantiable are called concrete types while the types that are not directly instantiable are called abstract types. Abstract types only define characteristics inherited by their subtypes, they do not define an implementation. For example, consider a company that produces only

Page 5


computers, monitors and integrated systems. In this case Computer, Monitor and System would be concrete types while their supertype Product would be an abstract type. TODL does not explicitly denote whether a type is abstract or concrete.

4.4 The Full Built-in Type Hierarchy Figure 1 shows the full set of built-in types supported by TAU Model. The type hierarchy of ODMG Object Model has been extended with the types that have the symbol on their left.

¦

Literal_type Atomic_literal Long Short Unsigned long Unsigned short Float Double Boolean Octet Char String Enum Collection_literal Set Bag List Array Temporal_Element Structured_literal Structure Date Time Timestamp Timepoint Interval Period

¦

¦ ¦

Object_Type Atomic_object S_Type TT_Type VT_Type BT_Type Collection Set Bag List Array

¦ ¦ ¦

Figure 1: Full Set of Built-in Types

5. Atomic Objects Atomic objects are the basic modelling primitives. Figure 2 shows all the object categories supported by TAU Model, their types, the time dimensions that they support and what kind of properties they may include. For more information about the properties see section 6. Transaction state, valid state and bitemporal state objects have special temporal semantics and are termed astemporal objects.

Page 6


Object category Static state objects Transaction state objects Valid state objects Bitemporal state objects

Type

Support

Properties

S_Type

None TT VT TT, VT

static TT, static VT, static BT, VT, TT, static

TT_Type VT_Type BT_Type

TT = transaction time, VT = valid Time BT= bitemporal time

Figure 2: Categories of objects in TAU Model

5.1 Static state objects Static state objects are instances of a type that has been declared as S_Type. They are the objects that ODMG supports and they don’t have any special temporal semantics. The properties of static state objects can only be static properties. The assumptions for static objects regarding time are: 1. Static state objects exist in the database from the database creation time ct until now. 2. Static state objects exist in the modelled reality from the infinite past until the infinite future, i.e. their valid time lifespan is(beginning, forever) . 3. The values of their properties are current in the database and may be retrieved during (ct, now). Additionally we assume that these values are valid in the modelled reality from the infinite past until the infinite future.

5.2 Transaction state objects Transaction state objects are instances of a type that has been declared as TT_Type and they support transaction time facilities. Every transaction state object is associated with a lifespan, termed as transaction time lifespan, that denotes the time when the object is active in the database and may be retrieved. A property of a transaction state object can be either transaction time property or static property. A transaction time property holds a set of values. Each value is associated with a period, termed as transaction time timestamp, that denotes the time when the value is current in the database and may be retrieved. A set of data values and their timestamps represents the transaction time history of the property. From another viewpoint, we can say that transaction state objects do not have a static state. Instead, they have a set of states that are associated with a period of existence in the database. This set is termed as transaction time history of the object’s state. The assumptions for transaction state objects regarding time are: 1. Transaction state objects exist in the modelled reality from the infinite past until the infinite future, i.e., their valid time lifespan is(beginning, forever) . 2. The values of their properties (static and/or transaction time) are valid in the modelled reality from the infinite past until the infinite future. 3. The values of their static properties are current in the database and may be retrieved during the transaction time lifespan of the object that contains them. Example Consider a valid time object type MComputer with the following interface definition in the syntax of TODL:

Page 7


typedef Struct Address { String Address, String City, String Post_Code, String Country } tt_interface Person // type properties: (extent Persons) { // instance properties: attribute String fname; // first name attribute String lname; // last name tt_attribute Address address; tt_attribute String phone; attribute Date birthday; // instance operations: Integer age(); }

Figure 3 represents the evolution of an instance of the type Person over transaction time. OID tt_lifespan fname lname

P1

[t1, now)

John

address

phone

birthday

Smith {< [t1, t2) , >, {, ’22/06/57’ , < [t2, t3) , >, 2 3 < [t3, now) , >} }

Figure 3: Transaction time histories of the properties The object’s transaction time lifespan is [t1, now). This means that the object created in the database at the time t1 and it is still active and may be retrieved. The columns that correspond to the transaction time attributes address and phone include the transaction time histories of these properties. For example during the period [t3, t4) in the database was stored that the current person had phone number 23456 while at the present it is unknown (nil).

5.3 Valid state objects Valid State objects are instances of a type that has been declared as VT_Type and they support valid time semantics. Every valid state object is associated with a lifespan, termed as valid time lifespan, that denotes the time when the object exists in the modelled reality. A property of a valid state object can be either valid time property or static property. A valid time property holds a set of values. Each value is associated with a timestamp (period or timepoint), termed as valid time timestamp, that denotes the time when the value is valid in the modelled reality. A set of data values and their timestamps represents the valid time history of the property. From another viewpoint we can say that valid state objects do not have a static state. Instead, they have a set of states that are associated with a valid period of existence in the modelled reality. This set is termed as valid time history of the object’s state. The assumptions for valid state objects regarding time are: 1. Valid state objects exist in the database from its creation time until now i.e. their transaction time lifespan is (ct,now) 2. The values of their properties are current in the database and may be retrieved during(ct,now). 3. The values of their static properties are valid in the modelled reality during the valid time lifespan of the object that contains them.

Page 8


Example Consider a valid time object type MComputer with the following interface definition in the syntax of TODL: vt_interface MComputer ( extent MComputers vt_lifespan MONTH ) { vt_attribute String CPU; vt_attribute Unsingned Short Memory; vt_attribute Unsingned Short HD; relationship Manager is_used_by; inverse Manager:: uses; }

Figure 4 shows three different representations of an instance of MComputer. CM1 is the object identifier while M1 represents another OID that serves as a relationship with an instance of Managers. Figure 4(a) represents the valid time histories of the properties. We can see that the attribute Memory has value 4 during the period [’02/1990’,’11/1995’) and 8 during [’11/1995’,’11/1996’). The static relationship used_by has the same value M1 during all the lifespan. Figure 4(b) is a graphical representation of the object while Figure 4(c) represents the history of the object’s state. We can see that CM1 has five different states during its lifespan. OID

lifespan

CPU

Memory

used_by

HD

M1

CM1 [‘2/1994’,’11/1996’) {, {, {,

, } } }

(a) Valid Time Histories of the properties attribute CPU

i286

i386

Memory

i486

4

HD

8

275

560

used_by

M1 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12

1994

1995

1996

now

time

(b) Graphical representation STATE 1 Period CPU

STATE 2

STATE 3

STATE 4

STATE 5

[‘02/1994’,’03/1995’) [’03/1995’,06/1995’) [‘6/1995’,’11/1995’) [’11/1995’,’03/1996’) [’03/1996’,’10/1996’) i286

i386

i386

i386

i486

Memory

4

4

4

8

8

HD

275

275

560

560

560

used_by

M1

M1

M1

M1

M1

(c) Valid time history of the object’s state

Figure 4: Representation of a valid time object

Page 9


5.4 Bitemporal state objects Bitemporal state objects are instances of a type that has been declared as BT_Type and they support both transaction and valid time facilities. Every bitemporal state object is associated with two lifespans, a transaction time lifespan and a valid time lifespan. The transaction time lifespan denotes the time when the object is active in the database and may be retrieved while the valid time lifespan denotes the time when the object exists in the modelled reality. A property of a bitemporal state object can be valid time, transaction time, bitemporal or static property. A bitemporal property holds a set of values. Each value is associated with two timestamps, a transaction time timestamp and a valid time timestamp. A set of data values and their timestamps represent the bitemporal history of the property. Bitemporal state objects do not have a static state. Instead, they have a set of states that are associated with two periods. The first denotes the period of existence in the database, while the second denotes the period of existence in the modelled reality. The set of object’s states with their associated periods is termed as bitemporal history of object’s state. The assumptions for bitemporal state objects regarding time are: 1. The values of their static properties are current in the database and may be retrieved during the object’s transaction time lifespan. Additionally we assume that these values are valid in the modelled reality during the valid time lifespan. 2. The values of their transaction time properties are valid in the modelled reality during the object’s valid time lifespan. 3. The values of their valid time properties are current in the database and may be retrieved during the transaction time lifespan. Example Figure 5 represents the evolution of a bitemporal object over the two time dimensions. Consider that the object has three bitemporal properties named PA, PB and PC. The domains for these properties are: {A1, A2,…} for PA, {B1, B2,…} for PB and {C1, C2,…} for PC.

Figure 5: Graphical representation of a bitemporal object

Page 10


6. Modelling State-Properties The state of an object includes all of the properties of the object plus the current values of each of these properties. A property is an inherent or distinctive characteristic that contributes to making an object uniquely that object [BOOCH94]. A type defines a set of properties through which users can access, and in some cases directly manipulate, the state of instances of the type. The model supports two kinds of properties named attribute and relationship.

6.1 Property timestamping In the literature regarding temporal object oriented databases, two approaches have been proposed for the incorporation of time in data models: property timestamping and object timestamping. In the first case a time value is associated to each time varying property of an object, while in the second case a time value is associated to the whole object. TAU Model adopts the property timestamping for two main reasons [EDELWEISS94C]: 1. Time varying properties of an object can change asynchronously over time. To keep such changes, if we adopt the object timestamping, we have to record all object values when a change occurs, which causes unnecessary repetition of information. 2. The time varying properties of an object can have different granularities.

6.2 Timestamp category A property is said to be timestamped if there is a time value, termed as timestamp, associated with its values. The interpretation of that time value defines the timestamp category of the property. TAU Model supports three categories of timestamps named transaction time, valid time and bitemporal element. A Transaction time timestamp denotes the time when the associated with it value is current in the database and may be retrieved. A valid time timestamp denotes the time when the value is valid in the modelled reality, whereas a bitemporal element timestamp is a combination of a transaction and a valid time timestamp.

6.3 Attributes An attribute is a data-valued characteristic of one type. An attribute’s type can be either a literal type or an object type. In the first case, an attribute’s value will be a literal while in the second it will be an object identifier. Attributes are not "first class" objects i.e., an attribute itself is not an object and therefore does not have an object identifier. It is not possible to define attributes of attributes, relationships between attributes or subtype-specific operations for attributes. The model defines on attributes built-in operations through which users can retrieve and modify their values. Attributes are classified into static, transaction time, valid time and bitemporal time attributes. 6.3.1 Static attributes Static attributes correspond to the attributes supported by the ODMG Object Model, and they do not have any special temporal semantics. Static attributes can be defined in the interface of every atomic object type. For example the static object type Person might contain the following static attribute definitions: attribute String Name; attribute enum gender {male,female};

The following built-in operations are defined on static attributes:

Page 11


set_value(new_value: T)

(1)

get_value() -> existing_value: T

(2)

(1) The set_value operation gives the attribute a new value, replacing its previous one. The user can set the current value of the attribute as "no value" by invoking the operation set_value(nil). (2) The get_value operation returns the current value of the attribute.

6.3.2 Transaction time attributes Each value of a transaction time attribute is associated with a period, termed as transaction time timestamp, that denotes the time when the value is current in the database and may be retrieved. A set of data values and their timestamps represents the transaction time history of the attribute (see section 13.1). Transaction time attributes can be defined in the interface of a transaction time object type or a bitemporal time object type. For example the bitemporal time object type Product might contain the following transaction time attribute definitions: tt_attribute Short Code; tt_attribute String Name;

The following built-in operations are defined on transaction time attributes:

set_value(value: T)

(1)

get_value(tt: Temporal_Element) -> tt_h: TT_History

(2)

(1) The set_value operation gives the attribute a new value by adding to its transaction time history a new element (value, [t1, now)) where t1 is the transaction time when the operation was invoked and now has the meaning "until changed". This setting has the interpretation that the database from the timepoint t1 has stored that the attribute’s value is value until changed by some later transaction. The next set_value(value2), invoked at transaction time t2, will modify the above element to (value, [t1, t2)) and it will add a new element (value2, [t2,now)) in the

attribute’s transaction time history. (2) The get_value operation returns the transaction time history of the attribute during the temporal element tt that was supplied as argument. If during the tt the attribute has not value it returns nil. The default value for tt is now i.e. the operation will return the transaction time

history of the attribute that corresponds to the current value. 6.3.3 Valid time attributes Each value of a valid time attribute is associated with a timestamp (period or timepoint), termed as valid time timestamp, that denotes the time when the value is valid in the modelled reality. In a valid time attribute declaration, users can specify an appropriate granularity for the valid time timestamps. The granularity denotes the precision to which the timestamps are stored and can be represented. A set of data values and their timestamps represents the valid time history of the attribute. Valid time attributes can be defined in the interface of a valid time object type or a bitemporal time object type. For example the bitemporal time object type Product might contain the following valid time attribute definition: vt_attribute Float Price; In the above definition, the pair denotes that the valid time timestamp associated with each value is of type Period and it has granularity DAY. The following built-in operations are defined on

valid time attributes:

set_value(new_value: T, vt: Timepoint_or_Period)

(1)

get_value(vt: Temporal_Element) -> vt_h: VT_History

(2)

Page 12


(1) The set_value operation gives the attribute a new value by adding to its valid time history a new element (new_value, vt) where vt is the value’s valid time in the modelled reality. With this setting the database records that the attribute’s value during the time vt in the modelled reality is new_value. If the attribute had a previous value during sometime of vt this value will be overwritten by the new one. The argument vt can be of type Period or Timepoint depending on

the definition of the attribute. (2) The get_value operation returns the valid time history of the attribute during the temporal element vt that supplied as argument. If during vt the attribute has not value it returns nil. The default value for vt is (beginning, forever), i.e. the operation will return the whole valid time

history of the attribute. 6.3.4 Bitemporal time attributes Each value of a bitemporal time attribute is associated with two timestamps, a transaction time timestamp and a valid time timestamp. In a bitemporal time attribute declaration, users can specify an appropriate granularity for the valid time timestamps. A set of data values and their timestamps represent the bitemporal history of the attribute. Bitemporal time attributes can be defined only in the interface of a bitemporal time object type. For example the bitemporal time object type Computer might contain the following bitemporal time attribute definitions: bt_attribute String CPUType; bt_attribute Short Memory;

The following built-in operations are defined on bitemporal time attributes:

set_value(new_value: T, vt: Timepoint_or_Period)

(1)

get_value(tt: Temporal_Element, vt: Temporal_Element) -> bt_h: BT_History

(2)

(1) The set_value operation gives the attribute a new value by adding to its bitemporal time history a new element (new_value, [CURRENT_TIMEPOINT, now), vt). This setting has the

interpretation that the database from the current timepoint has stored that the attribute’s value, during the time vt in the modelled reality, isnew_value. (2) The get_value operation returns the bitemporal time history of the attribute during transaction time tt and valid time vt . The default values are: (beginning, forever) for the vt and now for tt.

Example The table below contains a sequence of updates on a bitemporal attribute. Consider that the first update occurred at transaction time t1. Transaction time

Action

Comment

t1

set_value( i286, [present, now) )

new value

t3


new value

t5


new value

t7

set_value( i386, [t5, t 7) )

correction

t8

set_value( i386, [t2,t4) )

correction

t9

set_value(i486, [t5,t7) )

correction

t10

set_value(i586, [present, now) )

new value

t12

set_value( i486, [t10,now) )

t13

set_value( nil, [present, forever) )

correction + new value clear value

Page 13


Figure 6 represents graphically the evolution of that property over the two time dimensions. Valid Time now t13 t12 t11

i586

t10 t9 t8 t7 t6 i486 t5 t4 i386 t3 t2 i286 t1

O

t1

t2

t3

t4

t5

t6

t7

t8

t9

t 10

t11

t12

t13 now

Transaction Time

Figure 6: Graphical representation of a bitemporal attribute

6.4 Relationships A relationship is defined between two atomic object types. Relationships can be thought as abstract entities which allow objects to reference each other. Relationships may be uni-directional or bi-directional. A uni-directional relationship exists in only a single direction, allowing a traversal from one object to another but no traversal in the reverse direction. A bi-directional relationship allows traversal in both directions. When a relationship is established along a bi-directional relationship, that relationship is automatically created in both directions. The model supports one-to-one, one-to-many, and many-to-many relationships. A one-to-one relationship allows one object to be related to one another object (e.g., the relationship spouse is modelled as a one-to-one relationship between instances of type Person). A one-to-many relationship allows a single object to be related to many objects in one direction while in the reverse direction an object may be related to only a single object (e.g., when modelling a department, the department might have many employees while each employee is working in only one department). One-to-one and one-to-many relationships may be uni-directional or bi-directional. A many-to-many relationship allows each object to be related to many objects in both directions of the relationship (e.g., modelling the relationship between customers and products might use a many-to-many, bi-directional relationship. A customer may have bought many products while a product can be bought by more than one customers). A many-to-many relationship is always bi-directional. Relationships maintain referential integrity. Referential integrity ensures that objects do not contain references to deleted objects. Referential integrity can be automatically provided for bi-directional relationships. Given a bi-directional relationship, when an object is deleted, all related objects can be found and have their relationships to the deleted object removed. Uni-directional relationships can not be assured of referential integrity

Page 14


The operations defined on relationship parties and their traversal paths depend on the traversal path’s cardinality. To be more specific, when in a type definition, the traversal path of a relationship has cardinality “one”, operations are defined to create, delete and traverse the relationship. On the other hand, when the traversal path has cardinality “many” the traversal path additionally supports operations to create, delete and traverse many relationships simultaneously. Relationships are classified into static, transaction time, valid time and bitemporal time relationships depending on their temporal aspects. 6.4.1 Static relationships Static relationships correspond to the relationships supported by the ODMG Object Model, and they do not have any special temporal semantics. They can be defined between two atomic object types. One-to-many and many-to-many static relationships may have ordering semantics. Ordered relationships are modelled with lists while unordered relationships are modelled with either sets or bags. The following built-in operations are defined on static relationships: Traversal path with cardinality "one"

add_one_to_one(o2: Object_Type)

(1)

remove_one_to_one()

(2)

traverse() ->to: Object_Type

(3)

Traversal path with cardinality "many"

add_one_to_one(o2: Object_Type)

(1)

add_one_to_many(s: set)

(2)

remove_one_to_one(o2: Object_Type)

(3)

remove_one_to_many(s: set)

(4)

remove_all()

(5)

traverse() ->s: set

(6)

Example The following example illustrates the semantics of the static relationships, the use of the built-in operators defined on them and how is ensured the referential integrity. Consider a company which provides its managers with computers. Each manager can use many computers simultaneously but a computer can be used only by one manager at time. In this example the relationship between managers and computers is modelled as a static one-to-many relationship. bt_interface Manager{ … relationship Set uses; inverse MComputer::is_used_by … }; tt_interface MComputer { … relationship Manager is_used_by; inverse Manager:: uses; … };

The table below shows a scenario of updates on relationships between the managers M1, M2 and the computers MC1, MC2, MC3. The first column denotes the transaction time when the update took

Page 15


place, the second describes the situation, while the third column includes the operations that were used to update the database. TT

Comments

t1

M1 uses the computers MC1 and MC2

M1.add_one_to_many(set)

t2

M1 does not use MC1

M1.remove_one_to_one(MC1)

t3

M1 uses the computer MC3

M1. add_one_to_one(MC3)

t4

M2 uses the computer MC1

M2. add_one_to_one(MC1)

TT = [t1, t2 )

Action

MC1

TT = [t2 , t3)

MC1

is_used_by

M1

M1 uses

...

is_use d_by

uses

MC2

MC1

TT = [t3, t4)

...

is_use d_by

MC2

MC1

TT = [t4 , now) d_by is_use

M2

M2 uses

MC2

...

uses

MC2

...

y is_used_b

is_used_by

M1

M1 uses

...

is_use d_by

uses

MC3

...

is_use

d_by

MC3

Figure 7: Static one-to-many relationship Figure 5 shows snapshots of the database at different transaction times. When a user creates a new traversal path, the inverse path is created automatically. Conversely, when a user deletes a traversal path the inverse path is also deleted automatically. The operation M1.traverse() invoked sometime during the period [t1, t2) returns the set {MC1, MC2}. The same operation invoked sometime during the period [t3, t4) returns the set {MC2, MC3}. 6.4.2 Transaction time relationships A transaction time relationship between two atomic object types T1 and T2, defines a set of associations among instances of these types over transaction time. Each transaction time relationship is associated with a transaction time timestamp, which denotes the time when the relationship exists in the database. When an atomic object type T1 defines a transaction time relationship TTR with an atomic object type T2 then instances of T1 are associated with a transaction time history of the relationship TTR. For each instance o 1 of T1, transaction time history of the relationship TTR is defined to be the set of pairs , where OID is the object identifier of an instance of T2 that has ever participated to a relationship with o1, and tt is the transaction time timestamp of this relationship.

Page 16


Transaction time relationships can be defined between transaction state object types, bitemporal state object types or mixed. One-to-one, one-to-many, and many to many transaction time relationships are supported. When a type defines a transaction time relationship with cardinality “one”, its instances can participate to more than one relationship at different transaction times but not simultaneously (the same transaction time). On the other hand, if the transaction time relationship has cardinality “many” this constrain does not apply, i.e. instances can participate to more than one relationships at the same transaction time. Transaction time relationships define the same built-in operations as the static relationships except the operation traverse. Although these operators have the same definition, they have different semantics because transaction time relationships maintain transaction time histories. To be more specific, when an object o1 participates in a new transaction time relationship with an object o2 at transaction time t 1, a new element < o2.OID, [t1, now) >1 is added to its transaction time history of this relationship. On the other hand, when the relationship between these objects is removed, the above element is updated to where t 2 is the transaction time when the removal took place. For traversal paths with cardinality either "one" or "many", the traverse operator is defined as traverse(tt:Temporal_Element)-> tt_h: TT_History. It takes as argument a temporal element tt and returns the transaction time history of the relationship reduced to those transaction times specified by tt. Example This example illustrates how the transaction time relationships are modelled and the differences between them and the static relationships. Consider the example of the previous section (6.4.1), only this time the relationship between managers and computers is modelled as a transaction time one-tomany relationship. bt_interface Manager{ … tt_relationship Set uses inverse MComputer::is_used_by; … }; tt_interface MComputer { … tt_relationship Manager is_used_by inverse Manager:: uses; … };

Figure 8 shows a snapshot of the database after the transaction time t4. The rectangle on the relationships represent their transaction time timestamp. Instances of the type MComputer even if their traversal path has cardinality one, they can participate to more than one relationship but not simultaneously. The operation M1.traverse([t1,now)) returns the transaction time history {,,} while the operation MC1.traverse([t1,now)) returns {,}.

1

now has the meaning "until change"

Page 17


MC1

TT = [t4,now)

M3 M1

uses

s use

y ed_b is_us y ow) d_b [t4, n us e _ s i t2) [t1,

) [t1, now uses uses [t3, n ow)

MC2

by is_used_

is_us ed_b y

MC3

Figure 8: Transaction time one-to-many relationship 6.4.3 Valid time relationships A valid time relationship between two atomic object types T1 and T2, defines a set of associations among instances of these types in the modelled reality. Each valid time relationship is associated with a valid time timestamp, which denotes the time when the relationship exists in the modelled reality. In a valid time relationship declaration, users can specify an appropriate granularity for the valid time timestamps. When an atomic object type T1 defines a valid time relationship VTR with an atomic object type T2 then instances of T1 are associated with a valid time history of the relationship VTR. For each instance o1 of T1, valid time history of the relationship VTR is defined to be the set of pairs , where OID is the object identifier of an instance of T2, that has ever participated in a relationship with o1, and vt is the valid time timestamp of this relationship. Valid time relationships can be defined between valid state object types, bitemporal state object types or mixed. One-to-one, one-to-many, and many-to-many valid time relationships are supported. When a type defines a valid time relationship with cardinality one, its instances can participates in more than one relationship at different valid times but not simultaneously (the same valid time). On the other hand, if the valid time relationship has cardinality many this constrain does not apply, i.e., instances can participates in more than one relationship at the same valid time. The following built-in operations are defined on static relationships: Traversal path with cardinality "one"

add_one_to_one(o2: Object_Type, vt: Timepoint_or_Period)

(1)

remove_one_to_one(vt: Temporal_Element)

(2)

traverse(vt: Temporal_Element) ->vt_h: VT_History

(3)

Traversal path with cardinality "many"

add_one_to_one(o2: Object_Type, vt: Timepoint_or_Period)

(1)

add_one_to_many(s: set, vt: Timepoint_or_Period)

(2)

remove_one_to_one(o2: Object_Type, vt: Temporal_Element)

(3)

remove_one_to_many(s: set, vt: Temporal_Element)

(4)

remove_all(vt: Temporal_Element)

(5)

traverse(vt: Temporal_Element) -> vt_h: VT_History

(6)

Page 18


Example The relationship between departments and employees can be modelled as a valid time one-to-many relationship with granularity day. The types Department and Employee might contain the following relationship definitions: vt_interface Department{ … vt_relationship Set employs; inverse Employee::works_for … }; bt_interface Employee { … vt_relationship Department works_for; inverse Department:: employs; … };

6.4.4 Bitemporal time relationships Each bitemporal time relationship is associated with two timestamps, a transaction time timestamp and a valid time timestamp. The transaction time timestamp denotes the time when the relationship exists in the database while the valid time timestamp denotes the time when the relationship exists in the modelled reality. In a bitemporal time relationship declaration, users can specify an appropriate granularity for the valid time timestamps. When an atomic object type T1 defines a bitemporal time relationship BTR with an atomic object type T2 then instances of T1 are associated with a bitemporal time history of the relationship BTR. For each instance o 1 of T1, bitemporal time history of the relationship BTR is defined to be the set of triples , where OID is the object identifier of an instance of T2, that has ever participated to a relationship with o 1, while tt and vt are the transaction time timestamp and the valid time timestamp of this relationship respectively. Bitemporal time relationships can be defined only between bitemporal state object types. One-to-one, one-to-many, and many-to-many valid time relationships are supported. When a type defines a bitemporal time relationship with cardinality one then for a given transaction time tt, its instances can participate in more than one relationship at different valid times but not at the same valid time. On the contrary, if the valid time relationship has cardinality many this constraint does not apply, i.e., for a given transaction time tt instances can participate in more than one relationship at the same valid time. Bitemporal time relationships define the same built-in operations as the valid time relationships except the operation traverse. Although these operators have the same definition, they have different semantics because bitemporal time relationships maintain bitemporal time histories. To be more specific, when an object O1 participates in a new bitemporal time relationship with an object O2 at transaction time tt1 and valid time [vt1, vt2), a new element is added to its bitemporal time history of this relationship. The operation remove_one_to_one(o2, vt), invoked at transaction time tt2, will modify the above element to and it will add a new element . For traversal paths with cardinality either "one" or "many", the traverse operator is defined as traverse(tt:Temporal_Element, vt:Temporal_Element)-> bt_h: BT_History. It takes two arguments which represent the transaction time and the valid time and returns the bitemporal time history of the relationship reduced to these times.

Page 19


Example In a company, the relationship between its customers and the products that they have ever purchased, can be modelled as a bitemporal time many-to-many relationship. The types Customer and Product might contain the following relationship definitions: bt_interface Customer{ … bt_relationship Set has_ purchased; inverse Product::has_be_bought_by; … }; bt_interface Product { … bt_relationship Set has_be_ purchased_by; inverse Customer:: has_bought; … };

7. Modelling Behavior-Operations Behavior is how an object acts and reacts, in terms of its state changes and message passing [BOOCH94]. In a type definition, the behavior of its instances is specified as a set of operation signatures. Each signature consists of the name of the operation, the name and the type of its arguments, the type of the returned value and the names of any exceptions the operation can raise. For example, the type Employee might contain the following operation signatures: Short age(); Float annual_income (); void fire() raises (no_such_employee); void move(String new_address);

The model does not support operations that exist independent of a type, or operations defined on two or more types. Both TAU Object Model and ODMG Object Model, adopt the specification for operations defined by OMG CORBA.

8. Inheritance Types may be organised into a graph of subtypes and supertypes. A subtype inherits all of the characteristics of its supertypes. It may also define additional characteristics that apply only to its instances. An instance of the subtype supports all of the state and behavior of the supertype as well as new state and/or behavior unique to its more specialised nature. The type/subtype relationship is also called is-a-relationship (ISA relationship) or generalisation - specialisation relationship. A subtype can “refine” the properties and operations it inherits to specialise them to the behavior and range of state values appropriate for instances of the subtype. The model allows the following three kinds of refinements: In a subtype S, the type of an inherited property can be subtype of the corresponding property type defined on the supertype of S. 1. In a subtype S, the type of the value returned by an inherited operation can be subtype of the corresponding type defined on the supertype of S. 2. In a subtype, the implementation of an inherited operation can be redefined to reflect more specialised needs.

Page 20


By default, a subtype belongs in the same temporal category as its supertype. For example a subtype of a valid time object type is also declared as valid time object type. However the model allows a subtype to specialise the temporal category of its supertype. To be more specific, static object types are allowed to have as subtypes transaction, valid or bitemporal time object types, while transaction or valid time object types are allowed to have as subtypes bitemporal time object types. In addition, a subtype can specialise the temporal semantics of an inherited property. In this case a static property can be refined to a transaction, valid or bitemporal property, while a transaction or valid time property can be refined to a bitemporal time property. The table in Figure 9 shows how the model supports inheritance among temporal object types. The first column contains the atomic object types and the second their allowed subtypes. For each allowed subtype the corresponding rows in the third column denote the allowed property (attribute or relationship) temporal refinements. For example a static object type (S_Type) can have as subtype a bitemporal object type (BT_Type). This subtype can refine an inherited static property (S_Property) to a TT_Property, VT_Property or a BT_Property. Type S_Type

Allowed Subtypes *

S_Type

None

S_Property

VT_Type

S_Property

TT_Type* BT_Type

VT_Type

*

VT_Type BT_Type

BT_Type

*

È TT_Property È VT_Property S_Property È TT_Property S_Property È VT_Property S_Property È BT_Property S_Property È TT_Property S_Property È TT_Property S_Property È VT_Property S_Property È BT_Property TT_Property È BT_Property S_Property È VT_Property S_Property È TT_Property S_Property È VT_Property S_Property È BT_Property VT_Property È BT_Property S_Property È TT_Property S_Property È VT_Property S_Property È BT_Property TT_Property È BT_Property VT_Property È BT_Property

TT_Type BT_Type

TT_Type

Property temporal refinements

BT_Type*

default, Property = Attribute or Relationship

Figure 9: Inheritance and temporal object types An object can be used whenever an instance of one of its supertypes is expected. This implication of inheritance is termed as substitutability [BFG96]. If T2 is a subtype of T1, then an object of type T2 can be assigned to an object of type T1, but the reverse is not possible. In the case that T2 has more temporal dimensions than T1 (e.g., T2 is declared as BT_Type while T1 as S_Type) and an instance of T2 must be seen as instance of T1, the following rules apply: 1. In order to eliminate the transaction time dimension, the object’s state is restricted to transaction time equal with the timepoint now.

Page 21


2. In order to eliminate the valid time dimension, the object’s state is restricted to valid time equal with the timepoint now. The above rules are applied in both the object’s lifespan and the temporal refined properties. These rules are also used when T1 and T2 have the same temporal dimensions but T2 includes temporal refined inherited properties. The model supports multiple inheritance, that means a type can have more than one supertype. This raises the possibility that a type will inherit characteristics that have the same name (but different semantics) from two different supertypes. This form of name clash is handled by requiring the inheriting type to redefine the name of one of the inherited characteristics. In the case of multiple inheritance a subtype supports all the temporal dimensions supported by its supertypes. For example if a subtype T3 has as supertypes a type declared as TT_Type and a type declared as VT_Type then, by necessity, T3 will be declared as BT_Type. Example Consider a database that records integrated systems consisting of a monitor and a computer each. Monitors are modelled by the type Monitor declared as transaction time object type while computers are modelled by the type Computer declared as valid time object type. The type System, used to model systems, is declared as subtype of both Monitor and Computer; therefore it will be, by necessity, bitemporal time object type. tt_interface Monitor { tt_attribute String VDUType … }; vt_interface Computer { vt_attribute String CPUType … }; bt_interface System: Monitor, Computer { bt_attribute String VDUType // refined from Monitor bt_attribute String CPUType // refined from Computer bt_attribute Boolean Server? … };

Consider an instance S1 of the type System. Because the substitutability, S1 can be seen also as an instance of the type Monitor or the type Computer. In the case that S1 must be seen as an instance of Computer it must eliminate the transaction time dimension because the type Computer is declared as VT_Type. This is done by restricting the object’s state to transaction time equal with the timepoint now. If the value of attribute S1.CPUType was S1. CPUType = { , … , , , , }

after the restriction it will be coerced to S1[VT]. CPUType = { , , }

Page 22


9. Extent The set of all instances of a given type is termed extent. If an object is an instance of the type T, then it will by necessity, be a member of the extent of T. The extent of a type is a subset of the extent of its supertypes. If type T is a subtype of type S, then the extent of T will be a subset of the extent of S. An object that is an instance of type T is also an instance of type S if S is a supertype of T. Figure 10 represents a type hierarchy (left) and the corresponding extents (right). The type Product is an abstract type and is not directly instantiable. Products

Product

Monitors

abstract

Computers

C1 C2

Computer

M1 S1

Monitor

M2 C3 S2 C4

System

M3

Systems

Figure 10: Representation of Extent In a temporal database, the set of instances of a type can vary over time. Therefore TAU Model extends the nontemporal definition of the extent to include temporal aspects. The set of the instances of a type A that exist sometime during a period p is termed as temporal extent of the type A during the period p. The temporal extent can be specialised to transaction time extent, valid time extent or bitemporal time extent. Transaction time extent of a type A during a period p, is the set of the instances of the type A that exist in the database sometime during the period p. For example, the transaction time extent of the type Products during the period [1985, 1987) includes the products that existed in the database sometime during the period [1985, 1987). Because the assumption that static and valid state objects exist in the database from its creation time until now, the transaction time extent of types that have been declared as S_Type or VT_Type is the same as their static extent. Valid time extent of a type B during a period p, is the set of the instances of the type B that exist in the modelled reality sometime during the period p. For example, the valid time extent of the type Products during the period [1990, 1993) includes the products that exist in the modelled reality sometime during the period [1990, 1993). Because the assumption that static and transaction state objects exist in the modelled reality from the infinite past until the infinite future, the valid time extent of types that have been declared as S_Type or TT_Type is the same as their static extent. Additionally, when we refer to the valid time extent of a type that has been declared as BT_Type we assume that transaction time spans from the database creation time until now. Bitemporal time extent of a type C during the periods p1 (transaction time) and p2 (valid time) is the set of the instances of the type C that exist in the database sometime during the period p1 and (the same time) the database has recorded that they exist in the modelled reality sometime during the period p2. For example the bitemporal time extent of the type Products during the periods [1985,1987) (transaction time) and [1990,1993) (valid time) includes the products that existed in the database sometime during the period [1985,1987) during which the database has recorded that they exist in the modelled reality sometime during the period [1990, 1993).

Page 23


The nontemporal notion of extent defined in the Object Model is still applicable to the temporal types. The nontemporal (or static) extent of a temporal type P, includes all the instances of the type P that have ever existed in the database.

10. Object lifespan In the literature regarding temporal databases, lifespan represents the time period during which an object exists. TAU Model specialises the concept of lifespan to transaction time lifespan and valid time lifespan.

10.1 Transaction time lifespan Transaction time lifespan (or TT_Lifespan) is a built-in attribute for each transaction or bitemporal state object, that represents the time when the object exists in the database. The type of the TT_Lifespan is temporal element, that is, a finite union of periods. The first timepoint of the TT_Lifespan is equal with the object’s creation time. TT_Lifespan is system maintained, i.e. the user cannot modify it directly. Instead the model defines the built-in operations kill and vacuum, on both TT_Type and BT_Type, which have side effects on the TT_Lifespan. These operators are described in detail below. To retrieve the TT_Lifespan, the model defines, on both TT_Type and BT_Type, the built-in operator tt_lifespan() that returns a temporal element which represents the object’s TT_Lifespan. According to the model, a transaction or bitemporal state object can have disjoint periods of existence in the database. Each contiguous period of existence is called an incarnation [CLIFFORD88]. A transaction or bitemporal state object is said to be killed if the end point of its TT_Lifespan belongs in the past. If the end point of an object’s TT_Lifespan is equal to now then the object is known as active. The user can kill active objects by calling the built-in operation kill(), defined on both TT_Type and BT_Type. The effect of the kill operation is to terminate the most recently incarnation of the active object. For example if the object’s TT_Lifespan was {[t1,t2), [t3,t4) ,…, [t5,now)} the kill operation will modify it to {[t1,t2), [t3,t4), …, [t5,tk)} where tk is a timepoint equal to the transaction time when the object was killed. The action which makes a killed object become active again is called reincarnation [CLIFFORD88]. The user can reincarnate a killed object by calling the built-in operation activate() defined on both TT_Type and BT_Type. The effect of the activate operation on a killed object is to modify its TT_Lifespan by adding a new period [ta, now) where ta is the transaction time when the activate operation was invoked.

10.2 Valid time lifespan Valid time lifespan (or VT_Lifespan) is a built-in attribute, for each valid or bitemporal state object, that represents the time when the object exists in the modelled reality. In the case of valid state objects, the type of the VT_Lifespan is temporal element while in the case of bitemporal objects the structure of the VT_Lifespan is more complex and is described in Chapter 6. During the object creation, the default value for the VT_Lifespan is (beginning, forever) which means always in the past, present and future. The user has the ability to define explicitly the value of the VT_Lifespan when he creates an object by giving appropriate values in the arguments of the object constructor. The user has also the ability to change the value of the lifespan later by calling the appropriate built-in operation. To modify the VT_Lifespan the model defines, on both VT_Type and BT_Type, the following built-in operations:

VT_LifespanAdd(te: Temporal_Element)

(1)

Page 24


VT_LifespanRemove(te: Temporal_Element)

(2)

VT_LifespanSet (te: Temporal_Element)

(3)

(1) The VT_LifespanAdd operation adds to the VT_Lifespan the temporal element te. (2) The VT_LifespanRemove subtracts from the VT_Lifespan the temporal element te. (3) The VT_LifespanSet replaces the current VT_Lifespan with the temporal elementte.

The above operations follow the semantics defined on the built-in operators of the type Temporal_Element. The valid time of the timestamped properties is constrained to be subset or equal to the VT_Lifespan of the object to which they belong. Therefore the operations VT_LifespanRemove and VT_LifespanSet “normalise” (if it is necessary) the histories of the object’s timestamped properties to be consistent with the new VT_Lifespan. To retrieve the VT_Lifespan of valid state objects, the model defines on VT_Type the built-in operation vt_lifespan() that returns a temporal element which represents the object's VT_Lifespan. On bitemporal state objects, VT_Lifespan depends on the transaction time. In other words, the same bitemporal state object can have different VT_Lifespan at different transaction times. To retrieve the VT_Lifespan of bitemporal state objects, the model defines on BT_Type the built-in operation vt_lifespan(t: Timepoint). This operation takes as argument a timepoint t which represents the desirable transaction time and returns a temporal element that represents the object's VT_Lifespan at the given transaction time t.

10.3 Example of lifespan The following example illustrates the decision to model both TT_Lifespan and VT_Lifespan as temporal elements and not as contiguous periods. It also illustrates how work the built-in operators that effect lifespans. Consider a company which produces computers. In the database, computers are modelled as a bitemporal object type Computer. The table below shows a scenario of decisions taken by the company regarding a computer C1. The first column denotes the date that the decision was taken, the second describes the situation, while the third column includes the operations that was used to update the DB. Date

Comments

Action

1/1/95

create( C1, ['1/6/95', forever), …) The company plans to produce a new computer C1 starting from the next summer.

1/2/95

The company changes it’s initial plan, and decides to start the production of C1 from the next Autumn. The plan fails and the company decides not to produce C1.

C1.VT_LifespanRemove( ['1/6/95','1/8/95') ) or C1.VT_LifespanSet( ['1/8/96', forever) )

1/4/95

Finally, the company decides to produce C1 starting from the beginning of the next year.

C1.activate() C1.VT_LifespanSet( ['1/1/96', forever) )

1/3/96

While the company is producing C1, it plans to stop the production during the next Summer.

C1.VT_LifespanRemove( ['1/6/96', '1/9/96') )

1/3/95

C1.kill()

Page 25


Figure 11 shows a graphical representation of the VT_Lifespan. The current VT_Lifespan of the C1 can be retrieved through the operation C1.vt_lifespan(now) and it’s value is {[’1/1/96’, ’1/6/96’), [’1/9/96’, forever)}. The TT_Lifespan of C1 can be retrieved through the operation C1.tt_lifespan() and it’s value is {[’1/1/95’, ’1/3/95’), [’1/4/95’,now)}. Valid time forever 1/9/96 1/6/96 1/1/96 1/9/95

C1 does not exist in the DB (killed)

1/6/95

beginning

1/1/95

1/2/95

1/3/95

1/4/95

1/3/96

now Transaction

time

Figure 11: Graphical representation of a valid time lifespan

11. Equality TAU Model supports the following notions of equality among objects: • Equality by identity: Two objects are equal by identity if they have the same object identifier, i.e., they are the same object. • Shallow value equality: Two objects are shallow value equal, if they have the same attribute values and the same relationships respectively. In the case of temporal objects, two temporal objects are shallow value equal if their lifespans are equal and the histories of their states are also equal respectively. That means that they have equal states (equal attribute values and the same relationships) during all the time periods that are included in their lifespans. TAU Model defines the following additional notions of equality between temporal objects: • Instantaneous-value equality: Two temporal objects are instantaneous-value equal if there exist a time period (of the intersection of their lifespans) during which they have equal states. • Weak-value equality: Two temporal objects are weak-value equal if they have ever had equal states (not necessary during the same period). • Common-times equality: Two temporal objects are common times equal if they have equal states during the time specified by the intersection of their lifespans. In the literature to be found on object orientation, there is another notion of equality named deepvalue equality. According that two objects are deep-value equal if they have the same attribute values and their relationships are referred respectively to objects with equal states recursively. TAU Model does not support that notion of equality directly. However, users can define explicitly different notions of equality according to their needs.

Page 26


Example Figure 12 shows some instances of the type MComputer. The value M1 represents an Object_Id that serves as a relationship with an instance of Managers which has that Object_Id. The instances CM1 and CM2 are shallow value equal because they have equal lifespans and equal states (equal attribute values and the same relationship) during all the time periods that are included in their lifespans. The instances CM2 and CM3 are instantaneous-value equal because they have equal states during the period [’03/1996’,’06/1996’). The instances CM3 and CM4 are weak-value equal because the state of CM3 during the period [’08/1996’,’12/1996’) is equal with the state of CM4 during the period [’08/1995’,’06/1996’) . OID

lifespan

CPU

Memory

HD

used_by

CM1 [‘2/1994’,’11/1996’) {, {, {,

M1

, } } } CM2 [‘2/1994’,’11/1996’) {, {, {,

M1

, } } } CM3

[‘05/1995’,now)

{, {, {, }

M1

, } }

CM4

[‘08/1995’,now)

{}

{}

{,

M1

}

attribute

CM1,CM2

CPU

i286

i386

Memory

i486

4

HD

8

275

used_by

560 M1

01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12

1994

1995

1996

now

time

attribute CPU

i486

CM3

Memory

i586

8

HD

16

560

used_by

32 800

M1 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12

1994

1995

1996

now

time

now

time

attribute CPU Memory

i586

CM4

16

HD

800

used_by

1170 M1

01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12

1994

1995

1996

Figure 12: Computers of manager M1

Page 27


12. Keys In some cases, the individual instances of a type can be uniquely identified by the value they carry for some property (attribute or relationship) or set of properties. These properties or sets of properties are termed keys. Single keys are keys that consist of a single property. Compound keys consist of a set of properties. The keys of a type must be time invariant, that means that timestamped properties cannot form or participate in keys.

13. Modelling histories Histories are used to capture the evolution of properties over time. The model defines three history types named TT_History, VT_History and BT_History. History types are modelled as immutable collections. It is not possible to define subtypes of a history type or to declare attributes to take as their value instances of a history type.

13.1 Transaction time histories Transaction time histories are used to model the evolution of a property over transaction time. The model specifies their characteristics in a type named TT_History. There is no explicit create operation defined on TT_History. New instances are created through the get_value operation, defined on the type TT_Attribute, through the traverse operations, defined on the type TT_Relationship, or through specific operations defined on TT_History. The type TT_History has the following characteristics: Access Methods

tt_history()->tt_h: set< struct(value: Type, tt: Period) >

(1)

tt_timeslice( tt: Temporal_Element ) -> tt_h: TT_History

(2)

t_select( predicate: String) -> tt_h: TT_History

(3)

always( predicate: String, tt: Temporal_Element ) ->b: Boolean

(4)

sometime(predicate: String, tt: Temporal_Element ) ->b: Boolean

(5)

contains_element? (e: Type) -> b: Boolean

(6)

is_empty? () -> b: Boolean

(7)

to_set() -> set

(8)

TT() -> te: Temporal_Element

(9)

Description (1) The operation tt_history() returns a set of pairs (value, transaction time timestamp) that represents the transaction time history. (2) The tt_timeslice operation performs a transaction time timeslice on the history. It takes as argument a temporal element tt, and returns a new instance of TT_History that contains only the elements whose their timestamp overlaps withtt. (3) The t_select operation performs a temporal selection on the history. It returns a subset of the current history that contains only the elements that satisfy the predicate. If there is no element that satisfies the predicate, it returns an empty history. (4) Returns TRUE if all the elements of the current history, that their timestamp overlap with the parameter tt, satisfy the predicate; FALSE otherwise. (5) Returns TRUE if at least one element of the current history, that its timestamp overlaps with the parameter tt, satisfies the predicate; FALSE otherwise.

Page 28


(6) Returns TRUE if the history contains the element e; FALSE otherwise. (7) Verifies whether the current history is empty or not. (8) Converts the history to a set of values. (9) Returns a temporal element that is the union of the timestamps that correspond to the

elements of the history. Built-in operations

intersection(tt_h2: TT_History) -> tt_h3: TT_History

(1)

difference(tt_h2: TT_History) -> tt_h3: TT_History

(2)

Description (1) The intersection operation intersects two histories, the current history and tt_h2, and returns the result in a new history tt_h3. (2) The difference operation finds the difference between two histories, the current history and tt_h2, and returns the result in a new history tt_h3.

Example Let tt_a1 and tt_a2 be two transaction time attributes that take integers as values. Let also tt_h1 and tt_h2 be their corresponding transaction time histories. Figure 13 shows a representation of the two histories, tt_h1 and tt_h2, their intersection and their difference. Time

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15 t16 t17 t18 t19 t20

600

tt_h1

600

tt_h2

800

650

800

600

tt_h1.intersection(tt_h2)

tt_h1.difference(tt_h2)

700

600

800 700

800

Figure 13: Intersection and difference of histories Built-in operators for Comparisons

is_subset? ( tt_h2: TT_History ) -> b: Boolean

(1)

is_proper_subset? ( tt_h2: TT_History ) -> b: Boolean

(2)

is_superset? ( tt_h2: TT_History ) -> b: Boolean

(3)

is_proper_superset? ( tt_h2: TT_History ) -> b: Boolean

(4)

shallow_eq( tt_h2: TT_History ) -> b: Boolean

(5)

commonT_eq( tt_h2: TT_History ) -> b: Boolean

(6)

instant_eq( tt_h2: TT_History ) -> b: Boolean

(7)

weak_eq( tt_h2: TT_History ) -> b: Boolean

(8)

Description (1) The is_subset? operation establishes whether the current history is subset of the historytt_h2. (2) The is_proper_subset? operation establishes whether the current history is a proper subset of the history tt_h2. A proper subset means that the current history is included in the history tt_h2

but not equal to it.

Page 29


(3) The is_superset? operation establishes whether the current history is a superset of the history tt_h2. (4) The is_proper_superset? operation establishes whether the current history is a proper superset of the history tt_h2. A proper superset means that the history tt_h2 is included in the current

history but not equal to it. (5) The shallow_eq operation establishes whether the current history is shallow-value equal with tt_h2. Two transaction time histories are shallow-value equal if they have the same elements. (6) The commonT_eq operation establishes whether the current history is common-times equal with tt_h2. Two transaction time histories tt_h1 and tt_h2 are shallow-value equal if the

values of their elements are respectively equal during the intersection of the temporal elements tt_h1.TT() and tt_h2.TT(). (7) The instant_eq operation establishes whether the current history is instantaneous-value equal with tt_h2. Two transaction time histories are instantaneous-value equal if there exists a time

period during which their elements have equal values. (8) The weak_eq operation establishes whether the current history is weak-value equal with tt_h2.

Two transaction time histories are weak-value equal if there are at least two elements, one of each history, that have equal values.

13.2 Valid time histories Valid time histories are used to model the evolution of a property over valid time. The model specifies their characteristics in a type named VT_History. There is no explicit create operation defined on VT_History. New instances are created through the get_value operation, defined on the type VT_Attribute, through the traverse operations, defined on the type VT_Relationship, or through specific operations defined on VT_History. The VT_History type has the following characteristics: Access Methods

vt_history()->vt_h: set< struct(value: Type, vt: Period) >

(1)

vt_timeslice( tt: Temporal_Element ) -> vt_h: VT_History

(2)

t_select( predicate: String) -> vt_h: VT_History

(3)

always( predicate: String, vt: Temporal_Element ) ->b: Boolean

(4)

sometime(predicate: String, vt: Temporal_Element ) ->b: Boolean

(5)


(6)


(7)

to_set() -> set

(8)

VT() -> te: Temporal_Element

(9)

Built-in operations

intersection(vt_h2: VT_History) -> vt_h3: VT_History

(1)

difference(vt_h2: VT_History) -> vt_h3: VT_History

(2)

Built-in operators for Comparisons

is_subset? ( vt_h2: VT_History ) -> b: Boolean

(1)

is_proper_subset? ( vt_h2: VT_History ) -> b: Boolean

(2)

is_superset? ( vt_h2: VT_History ) -> b: Boolean

(3)

is_proper_superset? ( vt_h2: VT_History ) -> b: Boolean

(4)

Page 30


shallow_eq( vt_h2: VT_History ) -> b: Boolean

(5)

commonT_eq( vt_h2: VT_History ) -> b: Boolean

(6)

instant_eq( vt_h2: VT_History ) -> b: Boolean

(7)

weak_eq( vt_h2: VT_History ) -> b: Boolean

(8)

13.3 Bitemporal time histories Bitemporal time histories are used to model the evolution of a property over both transaction and valid times. The model specifies their characteristics in a type named BT_History. There is no explicit create operation defined on BT_History. New instances are created through the get_value operation, defined on the type BT_Attribute, through the traverse operations, defined on the type BT_Relationship, or through specific operations defined on BT_History. The BT_History type has the following characteristics: Access Methods

bt_history()->bt_h: set

(1)

tt_timeslice( tt: Temporal_Element ) -> bt_h: BT_History

(2)

vt_timeslice( vt: Temporal_Element ) -> bt_h: BT_History

(3)

t_select( predicate: String) -> bt_h: BT_History

(4)

tt_always( predicate:String, tt: Temporal_Element ) ->b: Boolean

(5)

vt_always( predicate:String, vt: Temporal_Element ) ->b: Boolean

(6)

tt_sometime(predicate: String, tt: Temporal_Element ) ->b: Boolean

(7)

vt_sometime(predicate: String, tt: Temporal_Element ) ->b: Boolean

(8)


(9)


(10)

to_set(tt: Timepoint) -> set

(11)

TT() -> te: Temporal_Element

(12)

VT(tt: Timepoint) -> te: Temporal_Element

(13)

Description (1) The bt_history operation returns a set of triples (value, transaction time, valid time) that represents the bitemporal history. (2) The tt_timeslice operation performs a transaction time timeslice on the history. It takes as argument a temporal element tt, and returns a new instance of BT_History that contains only the elements whose transaction time timestamp overlaps withtt. (3) The vt_timeslice operation performs a valid time timeslice on the history. It takes as argument a temporal element vt, and returns a new instance of BT_History that contains only the elements whose valid time timestamp overlaps withtt. (4) The t_select operation performs a temporal selection on the history. (5) Returns TRUE if all the elements of the current history, that their transaction time timestamp overlaps with the parameter tt, satisfy the predicate; FALSE otherwise. (6) Returns TRUE if all the elements of the current history, that their valid time timestamp overlaps with the parameter vt , satisfy the predicate; FALSE otherwise. (7) Returns TRUE if at least one element of the current history, that its transaction time timestamp overlaps with the parameter tt, satisfies the predicate; FALSE otherwise.

Page 31


(8) Returns TRUE if at least one element of the current history, that its valid time timestamp overlaps with the parameter vt , satisfies the predicate; FALSE otherwise. (9) Returns TRUE if the history contains the element e; FALSE otherwise. (10) Verifies whether the current history is empty or not. (11) Converts the history to a set of values. The returned set contains the values of the elements that their transaction time timestamp includes the timepointtt given as argument. (12) Returns a temporal element that is the union of the transaction time timestamps that

correspond to the elements of the history. (13) Returns a temporal element that is the union of the valid time timestamps that correspond to the elements of the history that their transaction time timestamp includes the timepointtt.

Built-in operations

intersection(bt_h2: BT_History) -> bt_h3: BT_History

(1)

difference(bt_h2: BT_History) -> bt_h3: BT_History

(2)

Built-in operators for Comparisons

is_subset? ( bt_h2: BT_History ) -> b: Boolean

(1)

is_proper_subset? ( bt_h2: BT_History ) -> b: Boolean

(2)

is_superset? ( bt_h2: BT_History ) -> b: Boolean

(3)

is_proper_superset? ( bt_h2: BT_History ) -> b: Boolean

(4)

shallow_eq( bt_h2: BT_History ) -> b: Boolean

(5)

commonT_eq( bt_h2: BT_History ) -> b: Boolean

(6)

instant_eq( bt_h2: BT_History ) -> b: Boolean

(7)

weak_eq( bt_h2: BT_History ) -> b: Boolean

(8)

14. Temporal object types In this section the characteristics of the temporal object types are specified.

14.1 Transaction time object type - TT_Type Instances of types that have been declared as TT_Type are mutable, transaction state objects. A type that has been declared as TT_Type can define only static or transaction time properties i.e., its properties can be declared as attribute, tt_Attribute, relationship, tt_Relationship. The following built-in characteristics are defined on typeTT_Type: Access Methods

tt_lifespan() -> Temporal_Element

(1)

tt_timeslice( te: Temporal_Element ) -> tt_o: TT_Type

(2)

Description (1) Returns the transaction time lifespan. (2) Performs transaction time timeslice on the object. It returns a new transaction state object tt_o.

Built-in Operations

kill()

(1)

Page 32


activate()

(2)

vacuum( te: Temporal_Element )

(3)

Description (1) If the object is already "killed", it does nothing otherwise it "kills" the object by setting the tt_lifespan.end to CURRENT_TIMEPOINT. (2) If the object is "active", it does nothing otherwise it "activates" the object by adding a period [CURRENT_TIMEPOINT, now] to the transaction time lifespan. (3) It actually deletes all the information regarding the current object which is stored in the database during the time specified by the temporal element te. In addition, it removes the temporal element te from the object’s transaction time lifespan.

Built-in operations for Comparisons

shallow_eq( tt_o2: TT_Type ) -> b: Boolean

(1)

commonT_eq( tt_o2: TT_Type ) -> b: Boolean

(2)

instant_eq( tt_o2: TT_Type ) -> b: Boolean

(3)

weak_eq( tt_o2: TT_Type ) -> b: Boolean

(4)

Description These operations establish respectively whether the current object is shallow value, common times, instant value or weak value equal with the object tt_o2 given as argument. The equality by identity is examined by the operationsame_as? inherited from Object_Type.

14.2 Valid time object types - VT_Type Instances of types that have been declared as VT_Type are mutable, valid state objects. A type that has been declared as VT_Type can define only static or valid time properties i.e., its properties can be declared as Attribute, VT_Attribute, Relationship, VT_ Relationship. The following built-in characteristics are defined on type VT_Type: Access Methods

vt_lifespan() -> Temporal_Element

(1)

vt_timeslice( te: Temporal_Element ) -> vt_o: VT_Type

(2)

Description (1) Returns the valid time lifespan. (2) Performs valid time timeslice on the current object and returns a new valid state object vt_o .

Built-in Operations

vt_lifespanSet( te: Temporal_Element )

(1)

vt_lifespanAdd( te: Temporal_Element )

(2)

vt_lifespanRemove( te: Temporal_Element )

(3)

delete( te: Temporal_Element )

(4)

Description (1) The vt_lifespanSet operation replaces the vt_lifespan of the current object with the temporal element te given as a parameter. (2) The vt_lifespanAdd operation adds the temporal element te to the vt_lifespan of the current

object.

Page 33


(3) The vt_lifespanRemove operation subtracts the temporal element te from the vt_lifespan of the

current object. If after an update of the lifespan the new lifespan become empty i.e., the expression vt_lifespan.has_periods().is_empty?==TRUE, then the operation removes the whole the object from the database and frees the storage used by its representation. The object will be removed from any relationships in which it participated. If the object was an instance of a type for which an extent is being maintained, the object will be removed from that extent. (4) The delete operation deletes all the parts of all the property histories that overlap with the temporal element te given as a parameter. The delete operation does not modify the vt_lifespan of the object.

Example Figure 14 shows an instance of a type MComputer, declared as VT_Type, before and after a deletion during a given temporal element. CM1 before deletion

attribute CPU

i286

i386

Memory

i486

4

HD

275

used_by

i586

8 560

M1

M2

M3

CM1.delete( Temporal_Element( [beginning,’11/1994’) + [07/1996,forever) ) )

CPU

i286

CM1

i386

after deletion

Memory

8

275

HD

560 M2

used_by

−∞

i486

4

M3

01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12

1994

1995

1996

+∞

time

vt_lifespan before and after deletion

Figure 14: Deletion of a valid state object Built-in operations for Comparisons

shallow_eq( vt_o2: VT_Type ) -> b: Boolean

(1)

commonT_eq( vt_o2: VT_Type ) -> b: Boolean

(2)

instant_eq( vt_o2: VT_Type ) -> b: Boolean

(3)

weak_eq( vt_o2: VT_Type ) -> b: Boolean

(4)

Description These operations establish respectively whether the current object is shallow value, common times, instant value or weak value equal with the object tt_o2 given as argument. The equality by identity is examined by the operationsame_as? inherited from Object_Type.

14.3 Bitemporal object types - BT_Type Instances of types that have been declared as BT_Type are mutable, bitemporal state objects. The following built-in characteristics are defined on typeBT_Type: Access Methods

tt_lifespan() -> Temporal_Element

(1)

vt_lifespan(t: Timepoint ) -> Temporal_Element

(2)

Page 34


tt_timeslice( te: Temporal_Element ) -> bt_o: BT_Type

(3)

vt_timeslice( te: Temporal_Element ) -> bt_o: BT_Type

(4)

Description (1) Returns the transaction time lifespan. (2) This operation takes as argument a timepoint t which represents the desirable transaction time

and returns a temporal element that represents the object’s valid time lifespan at the given transaction time t. (3) Performs transaction time timeslice on the object. It returns a new bitemporal state object bt_o. (4) Performs valid time timeslice on the object. It returns a new bitemporal state object bt_o.

Built-in Operations

vt_lifespanSet( te: Temporal_Element )

(1)

vt_lifespanAdd( te: Temporal_Element )

(2)

vt_lifespanRemove( te: Temporal_Element )

(3)

delete( te: Temporal_Element )

(4)

kill()

(5)

activate()

(6)

vacuum( te: Temporal_Element )

(7)

Built-in operations for Comparisons

shallow_eq( bt_o2: BT_Type ) -> b: Boolean

(1)

commonT_eq( bt_o2: BT_Type ) -> b: Boolean

(2)

instant_eq( bt_o2: BT_Type ) -> b: Boolean

(3)

weak_eq( bt_o2: BT_Type ) -> b: Boolean

(4)

15. Delete - Vacuum Static and valid state objects do not support any transaction time facilities. This means that logical deletions on their properties are transformed into physical deletions. Conversely, all logical updates including deletions, on transaction or bitemporal properties defined on a transaction or a bitemporal state object are transformed into insertions at the physical level. This causes transaction and bitemporal time histories to grow continuously. Some good reasons are mentioned in [TSQL2] why physical deletions are a highly desirable capability in a general database context: “In order to guarantee continuous operation, physical deletion capabilities are necessary. It must be possible to delete data that are no longer needed, or when additional space needs to be freed for more important data. Next, the efficiency of query processing generally degrades as tables grow. For this reason, means of controlling the table sizes are highly desirable. Finally, many countries have strict laws that require the ability to delete certain records of previous history (while requiring that other records be retained). Customers may demand that no information about them exist in some database. Other laws may require that certain records be kept for a fixed duration of time. For example, information related to personal income tax must, in some countries, be retained by the citizens for five years. Business policies also pose similar requirements.” In the TAU Model, physical deletions on transaction and bitemporal state objects are supported through the built-in operation vacuum defined on both TT_Type and BT_Type.

Page 35


Transaction and bitemporal state objects are removed from the database when the expression o.tt_lifespan.has_periods().is_empty? evaluates to TRUE, i.e. their transaction time lifespan becomes empty. Users can “empty” the transaction time lifespan through the operation vacuum. Analogously, valid state objects are removed from the database when the expression o.vt_lifespan.has_periods().is_empty? evaluates to TRUE, i.e. their valid time lifespan becomes empty. Users can “empty” the valid time lifespan through the operation delete. If the object is an instance of a type for which an extent is being maintained, removing the object from the database will also remove the object from the extent of the type of which it was an instance. In addition, its object identifier is not reused. Figure 15 summarises all the supported object updates regarding deletions, vacuuming and lifespan modifications.

16. Type Compatibility TAU Model is strongly typed and follows the compatibility rules specified by the ODMG Object Model. “Two objects or literals have the same type if and only if they have been declared to be instances of the same named type. Objects or literals that have been declared to be instances of two different types are not of the same type, even if the types in question define the same set of properties and operations. Type compatibility for objects follows the subtyping relationships defined by the type hierarchy. If TS is a subtype of T, then an object of type TS can be assigned to a variable of type T, but the reverse is not possible. No implicit conversions between types are provided by the Object Model. Two atomic literals have the same type if they belong to the same set of literals. No implicit conversions are provided for structured literals.”

Page 36


Object Type Update Type Static Delete the value of a property Delete oid

Comments

Remove the whole object (oid) from the database.

Action o.A.set_value( nil) or o.R.remove_one_to_one() o.delete()

Transaction Update TT Lifespan State Kill the object

Not possible from the user. TT Lifespan is system maintained If the object is already "killed", it o.kill() does nothing otherwise it "kills" the object by setting the tt_lifespan.end to CURRENT_TIMEPOINT o.vacuum( te: Temp_Elem ) Vacuuming parts of the This action will not effect the static properties but it will object’s TT_History modify the tt_lifespan and the histories of the tt_properties.

Vacuuming parts of the Not possible. TT_History of a property Remove the whole object (oid) Delete oid

o.tt_lifespan.has_periods().is_empty?

from the database.

Valid State Update VT_Lifespan

In case of Remove, this action will modify the histories of the vt_properties (normalisation)

Deleting parts of the object’s VT_History Deleting parts of the VT_History of a property Delete oid

This action will not effect the static properties.

Bitemporal Update TT_Lifespan State Update current VT_Lifespan

Not possible from the user. TT Lifespan is system maintained

o.A.set_value( nil, Temp_Elem) This action applies to a vt_attribute or a vt_relationship. or o.R.remove_one_to_one(Temp_Elem) o.vt_lifespan.has_periods().is_empty? Remove the whole object (oid) from the database.

In case of Remove, this action will modify the histories of the valid time and the bitemporal properties (normalisation) Vacuuming parts of the This action will not effect the static or the vt_properties but it object’s TT_history will modify the tt_lifespan and the histories of the tt and bt properties. Vacuuming parts of the Not possible.

tt_history of a property Deleting parts of the object’s current vt_history Deleting parts of the current vt_history of a property Delete oid

o.vt_lifespanSet( te: Temp_Elem ) o.vt_lifespanAdd(te: Templ_Elem ) o.vt_lifespanRemove(te:Temp_Elem) o.delete( te: Temp_Elem )

o.vt_lifespanSet( te: Temp_Elem ) o.vt_lifespanAdd(te: Templ_Elem ) o.vt_lifespanRemove(te:Temp_Elem) o.vacuum( te: Temp_Elem )

This action will modify the valid time and bitemporal property histories.

o.delete( te: Temp_Elem )

This action applies to a valid time or bitemporal property.

o.A.set_value( nil, Temp_Elem) or o.R.remove_one_to_one(Temp_Elem)

Remove the whole object (oid) from the database.

o.tt_lifespan.has_periods().is_empty?

Figure 15: Updating objects

Page 37


17. Summary The TAU Temporal Object Model is a high level data model that extends the ODMG Object Model in order to support temporal semantics. The basic concepts introduced by the TAU Model are valid time, transaction time, temporal objects, temporal extents, lifespans, temporal attributes, temporal relationships, property histories and temporal literals. The TAU Model supports all the constructs and the semantics of the ODMG Object Model, e.g. objects, object identifiers, literals, collections, inheritance, extents, keys etc. According to the model, atomic object types can be decomposed into static object types, transaction time object types, valid time object types and bitemporal time object types. The model adopts the property timestamping. Properties, i.e. attributes and relationships, are classified into three categories namely, transaction time, valid time and bitemporal time properties, depending on their temporal support. Temporal properties are associated with histories which capture the evolution of their values over time. Property histories fall into three categories, namely transaction time histories, valid time histories and bitemporal time histories. Instances of the types transaction time object type, valid time object type and bitemporal time object type are termed temporal objects because of their special temporal support. The model extends the nontemporal definition of the extent to include temporal aspects. The set of the instances of a type A that exist sometime during a period p is termed as temporal extent of the type A during the period p. The temporal extent can be specialised to transaction time extent, valid time extent or bitemporal time extent. Temporal objects are associated with lifespans. A lifespan represents the time period during which an object exists. They are specialised into transaction time lifespans and valid time lifespans. The model extends the notions of equality found in ODMG Object Model, namely equality by identity and shallow value equality with other three notions: instantaneous-value equality, weak-value equality and common-time equality. In the TAU Model, physical deletions on transaction and bitemporal state objects are supported through the built-in operation vacuum defined on both TT_Type and BT_Type.

18. Acknowledgements The work presented here was investigated within the TAU Project and the thesis [KAKOUDAKIS96]. Additional investigation on part of the TAU Project has been carried out also in thesis [HANIAS96]. We would like to thank Aziz Ait-Braham and Kostantinos Hanias for useful fruitful discussions that have helped to clarify many of the ideas presented here.

19. References [BFG96] Elisa Bertino, Elena Ferrari and Giovanna Guerrini, “A Formal Temporal Object-Oriented Data Model”, Proceedings of the 5th International Conference on Extending Database Technology (EDBT), Avignon, France, 1996 [BOOCH94] Booch G. 1994. Object-Oriented Analysis and Design. Benjamin/Cummings Publishing Company.

Page 38


[CLIFFORD88] J. Clifford and A. Croker, “Objects in Time”, IEEE Data Engineering, vol. 7, no. 4, 1988, pp. 189-196. [EDELWEISS94C] N. Edelweiss, J.P.M. Oliveira, J.M.V. Castilho, E. Peressi, A. Montanari and B. Pernici, “T-ORM: Temporal aspects in objects and roles”. [ELMNAV94] Elmasri R, Navathe S, Fundamentals of Database Systems (2nd Edition), The Benjamin/Cummings Publishing Company, 1994. [GATTELL96] R.G.G Gattell (ed), “The Object Database standard: ODMG-93”, Release 1.2, Morgan Kaufman Publishers, San Francisco, 1996. [GRITH82] Van Griethuysen J.J., et al (eds), “Concepts and Terminology of the Conceptual Shema and the Information Base”, Report ISO TC97/SC5N695/WG3, 1982 [HANIAS96] K. Hanias, A Calculus and a query language gor the TAU Temporal Object Model, UMIST, Computation Department, 1996. [JENSEN94A] C. S. Jensen, J. Clifford, R. Elmasri, S. K. Gadia, P. Hayes and S. Jajodia (eds), “A Glossary of Temporal Database Concepts”, sigmod, vol. 23, no. 1, 1994, pp. 52-64. [KAKOUDAKIS96] I. Kakoudakis, The TAU Temporal Object Model. MPhil Thesis, UMIST, Computation Department, 1996. [TAUTIME] I. Kakoudakis, B. Theodoulidis “The TAU Time Model”. TR no. TR-96-5, UMIST, Manchester, UK, 1996. [TSQL2] R. Snodgrass (ed.): The TSQL2 Temporal Query Language, Kluwer Academic Publishers, 1995.

Page 39

TimeLab The TAU Temporal Object Model - CiteSeerX

TimeLab The TAU Temporal Object Model - CiteSeerX

Suggest Documents

The COCOON Object Model - CiteSeerX

The COCOON Object Model - CiteSeerX

Navigational Accesses in a Temporal Object Model

Spatio-Temporal Data Management Using Object ... - CiteSeerX

Visual exploration of temporal object databases - CiteSeerX

Visual exploration of temporal object databases - CiteSeerX

A Temporal Expansion to the Multimedia Object Model in OMEGA

The Object-Stacking Model for Structuring Object-Based ... - CiteSeerX

The Java Object Model

Model-based temporal object verification using video - Image

A Temporal Evolutionary Object-Oriented Data Model and its Query ...

Object models with temporal constraints

A Structural Object Programming Model, Architecture ... - CiteSeerX

A database model for object dynamics - CiteSeerX

Experiences with Object Oriented Model-Driven ... - CiteSeerX

Dynamic Object Model and Adaptive Workflow - CiteSeerX

Model-Driven Development - From Object-Oriented ... - CiteSeerX

Fan Shape Model for Object Detection - CiteSeerX

A Graph-Oriented Object Database Model - CiteSeerX

Integrating Temporal Logics and Model Checking ... - CiteSeerX

A Temporal Ratio Model of Memory - CiteSeerX

A Relational Model for Temporal Logic - CiteSeerX

Vacuity Detection in Temporal Model Checking - CiteSeerX

A mechanistic model of tau amyloid aggregation based on ... - CiteSeerX