Temporal Database Management and the Representation of Temporal Dynamics

Temporal Database Management and the Representation of Temporal Dynamics Gove N. Allen and Salvatore T. March Carlson School of Management University of Minnesota Abstract Research in temporal database management has suggested that the Entity-Relationship (E-R) model lacks appropriate constructs for representing the dynamic nature of the real world. To make up for this claimed deficiency numerous structural extensions have been proposed. The notion that the fundamental E-R model is inadequate for representing the temporal nature of the world arises from the mistaken idea that an E-R model represents only a "snapshot" of reality. Practitioners have long used the E-R model without temporal extensions to design systems with rich support for temporality. This is accomplished by using entities to represent the events that cause state changes rather than by defining temporal attributes to record past states. While both approaches represent temporality, only the event approach represents why a particular state exists. This approach is consistent with research on the ontological foundations of information systems. Ontology suggests that events are a fundamental construct in information system representations. By treating events as entities we represent temporal dynamics without structurally extending the E-R model, thus retaining its simplicity and parsimony. 1. Introduction Numerous authors [Dey, et al., 1995; Gregersen and Jensen, 1999; Snodgrass, 2000;] rightly recognize the importance of representing the temporal aspects of data. Managers frequently must know not only the most current value of an attribute, but also its history. They require facts such as a specific customer's account balance on a specific date (e.g., on the date that customer was refused additional credit), or the length of time an employee has been at his or her current salary level, or the date on which an employee's salary was last changed, or the last date on which a stockout was experienced for a specific inventory item. Tansel, et al. [1993] summarize the problem when they characterize the difference between conventional databases and temporal databases. Conventional or static [Dean, 1989] databases reflect the most current state of the domain of interest. They are "updated from time to time; old data is deleted and new data inserted." Temporal databases reflect current state and state history in applications where "it is not appropriate to discard old information" [Gadia, 1988, p. 418]. Temporal databases [Ozsoyoglu and Snodgrass, 1995] typically allow a designer to differentiate temporal and non-temporal attributes. The temporal database maintains the state history of temporal attributes, using timestamps to specify the time during which a temporal attribute's value (state) is valid. While this structural approach to temporality is valuable for many applications it hides the true semantics of time in the application by focusing on state history and ignoring the events that cause state changes. Temporality in databases has arisen as a major problem not because of the nature of time or because of limitations to the E-R or relational models. It has arisen because data models and database schemas have been viewed as representing a snapshot of the world at a point in time [Kumar, et al., 1998; Ozsoyoglu and Snodgrass, 1995; Gadia 1998; Dey, et al., 1995; Tansel, et al. 1993]. Snodgrass [2000, p. 344] goes so far as to recommend that, "the temporal aspects of the application should be initially ignored when developing the conceptual schema." He further recommends a post hoc, structural approach to representing temporality in the database schema or the use of temporal extensions to the relational model. 1

We argue that for business applications a data model should not be viewed as a "snapshot of the real world at any point in time" nor should the temporal aspects of an application be left to post hoc analysis. A data model represents the semantics necessary to support a specific application's purpose. If that purpose includes temporality, then the temporal nature of the data must be represented in the data model. From an ontological perspective [Wand and Weber, 1990; Wand and Weber, 1993] time is not structural, but semantic. An event happens at a point in time and is recognized by the fact that it changes the state of a thing in the application domain resulting in a state history. A simple and parsimonious approach to representing time explicitly recognizes the events that cause state changes and ascribes to them the attributes they determine. What the structural approach views as "temporal" attributes are more properly represented as being determined by a set of events rather than as values intrinsic to the "things" involved in the event. Employee salary is often cited as an example of the need for temporal databases [Snodgrass, 2000]. Salary is initially interpreted to mean "employee's current salary" and is represented as a single-valued attribute of Employee, functionally dependent upon the employee's identifier. Later when it is determined that salary history must be maintained, the semantics of salary history are not analyzed, salary is simply declared to be a "temporal" attribute. In the temporal database approach a timestamp column (valid time) is added and a temporal functional dependency declared. That is, salary is declared to be functionally dependent upon the combination of the employee's salary and the timestamp. A new entry (row) is created when the value of salary is updated. In this way salary history is recorded but not the semantics of the events that cause it. We argue that if an application is required to track salary history for employees, then salary is not properly represented as an attribute of employee. It is rightly represented as an attribute of the event that causes the salary to change. Each change-salary event occurs at a point in time and is associated with exactly one employee. An employee's salary at any point in time is determined by the most recent change-salary event prior to that point in time. These semantics are lacking in the temporal database approaches. Each attribute of each entity has a value that is determined by a sequence of events [Wand and Weber, 1990]. Thus all attribute values are time-dependent. Even attributes such as customer number and social security number depend upon events (customer applies for an account, person registers with the U.S. government). In any particular application it may not be necessary or even possible to represent the events that cause specific state changes. If so, then the temporal database representation of state history is appropriate. We argue that the cause of state is significant in virtually every business application and should be represented semantically. We further argue that by representing events as entities, the constructs in the basic E-R model are sufficient to represent these semantics. Events are often recognized in traditional "static" data modeling when they have become "institutionalized" and are thus viewed as being "things." That is, when an artifact or document is routinely created to record "what happened" the document itself becomes the focus of analysis. In a hotel, for example, "Rental" is such an institutionalized event. Given the importance of rental events, hotels typically ascribe an identifier to each and record data such as the room that was rented, the person who rented the room, relevant dates, and the price paid on a "rental agreement" document. Rental becomes an entity. A temporal database approach to this application might view person and room as entities and rental as the state history of one or the other (or both) without explicitly representing why specific states occurred. When an event is recognized at the conceptual level, it is natural for an analyst to identify date (valid time and/or transaction time) as a required attribute and to follow a methodology to determine if there are additional attributes and relationships that should to be maintained for it (e.g., additional agents, 2

resources, or location associated with the event). Utilizing standard E-R constructs to represent temporal dynamics in this way results in simple and understandable data models. The efficiency issues that motivate temporal relational systems can then be treated at the physical level rather than the conceptual level. 2. Temporal Database Foundations In a seminal book on temporal database research, theory, and implementation [Tansel, et al., 1993] some of the major researchers in the field have agreed on the fundamental motivating assumption of temporal database research stated as [Tansel, et al., 1993, preface]: Conventional databases were designed to capture the most recent data, that is, current data. As new values become available through updates, the existing data values are removed from the database. Such databases capture a snapshot of reality. Although conventional databases serve some applications well, they are insufficient for those in which past and/or future data are also required. What is needed is a database that fully supports the storage and querying of information that varies over time. To address this problem numerous modifications and structural extensions to the relational model and relational databases have been posed. These include the notion of temporal functional dependency [Wang, et al., 1995], techniques to facilitate temporal queries (e.g., [Dean, 1989; Gadia and Yeung, 1988]), extensions to the relational model and relational algebra (e.g. [Gadia, 1988; McKenzie and Snodgrass, 1987; Gadia, 1985]), and specific indexing algorithms to support temporal queries (e.g. [Kouramajian et al, 1994; Kumar,et al., 1998]). The complexity added by these extensions immediately suggests a need for temporal support at the conceptual level. In fact, about a dozen temporally extended entity-relationship models have been proposed [Gregersen and Jensen 1999; Dey, et al. 1995]. These all make modifications to the E-R model either by adding syntactic constructs or by changing the fundamental definition of existing constructs. These approaches are based on the assumption that the basic E-R model is inadequate to represent temporal dynamics. Dey, et al [1995, p. 306] summarize the prevailing view: The E-R model can at best represent a "snapshot" of the real world at any point in time; it does not contain specific constructs to model the dynamic aspects of the real world. As a result, the E-R model is an inadequate tool for temporal database design. We argue that, in fact, the basic constructs of the E-R model are sufficient to represent the rich semantics of temporality as follows. Sections 3 and 4 present an overview of current approaches to representing temporality in logical and conceptual database design. A fundamentally different approach is based on the ontological notion of events. Rather than making an attempt to record all of the states a system has experienced, this approach explicitly represents the events that cause the state changes. Section 5 discusses artifact analysis, a common data modeling technique. As discussed above, organizations often record data about specific types of events in artifacts (e.g., sales order documents, invoices, packing lists) that are naturally represented as entities. However, important events are not always recorded in documents. Hence, in Section 6 we suggest using an event analysis approach to model temporality [Denna, et al, 1993; McCarthy, 1982]. By identifying all relevant events and representing them as entities, the temporal dynamics of an application can be simply and parsimoniously represented without structurally extending the E-R or relational models. 3. Temporality in Logical Database Design Snoddgrass and Ahn [1985] define three aspects of time in databases which will be used throughout the remainder of this paper. 3

1. Valid Time: The time a fact represented in the database is true in the reality it represents, e.g., when a particular price became the current price of a product. 2. Transaction Time: The time a fact was recorded in the database, e.g., when that employee's record was inserted into the database. Transaction time is used to allow a system to remember its state at a particular point in time. 3. User-Defined Time: All time attributes values which are not interpreted by the database management system. For example, birth date does not refer to when a fact became valid in a database nor does it record when a fact was recorded. It is an attribute of an entity that happens to be a date. Snodgrass [2000] describes three fundamentally different approaches to implementing temporal databases in the relational model, tracking log, state table, and bitemporal. These effectively synthesize many of the approaches that have been proposed in the literature. In each case the approach to managing temporal data begins with a snapshot schema, which represents the current state of an organization. Each of the three provides a means to access past states (of the database or of the represented reality) at various points in the past. We use a simple employee table adapted from Dey et al. [1995] to compare these different approaches. Each employee is described by employee number, social security number, first name, last name, salary and department (Table 1). Table 1: A snapshot "employee" relation Emp # ssn LName FName salary Dept 3025 086630763 Lyons James 15K dept1 3089 579659458 Gordon Walden 25K dept1 3092 129548660 Charles Davis 18K dept2 3105 454625914 Eric Wood 23K dept1 3.1 The Tracking Log Approach The tracking log approach maintains both a current-state or snapshot table and a state-history or log table. The snapshot table holds the current state of employees names, departments, and salaries. The log table holds their state history. Hence, the log table is "append only" and has the same field structure as the current-state table but includes a timestamp field, typically representing transaction time (Table 2). Rows are generally copied from the snapshot table to the log table using a trigger. Table 2: A tracking log for the employee relation Emp # ssn LName FName salary dept timestamp 3025 086630763 Lyons James 15K dept1 1/8/95 3089 579659458 Gordon Walden 25K dept1 5/26/95 3092 129548660 Charles Davis 18K dept2 5/28/95 3105 454625914 Eric Wood 23K dept1 11/2/95 3025 086630763 Lyons James 25K dept1 1/15/98 3092 129548660 Charles Davis 18K dept3 8/22/98 3025 086630763 Lyons James 25K dept2 11/5/98 4

The primary key of the log table is the combination of the timestamp field plus the primary key of the snapshot table. The granularity of the timestamp is determined by the user and may take the form of any of the date/time data types supported by the target DBMS. This approach does not necessarily represent past states of reality only past states of the table. If it was discovered that the value of James Lyons salary on 1/8/95 was really 16K, there would be no means to correct the error since by convention the log table is append only. Furthermore, representing deletions in the log table is problematic because it must record the fact that the row that no longer exists at a point in time. Hence, if deletions are permitted on the snapshot table, the log table must include still another column to indicate the kind of operation that was performed. 3.2 State-Table Approach Another way to maintain the past states is to create state tables. In this approach, snapshot tables are modified to include fields that indicate the period during which the values are valid. Under current relational standards (SQL-92) this requires one field to indicate the start of the time period and another to indicate the end of the period. Alternatively this could be accomplished by a date field and a duration field. In this approach the user must decide which type of time to record, valid time or transaction time. The tradeoff is between the ability to represent past states of reality and past states of the system. Table 3 shows the employee relation modified to be a state table. Table 3: An employee state table Emp # ssn LName FName salary dept start_date stop_date 3025 086630763 Lyons James 15K dept1 1/8/95 1/15/98 3089 579659458 Gordon Walden 25K dept1 5/26/95 3092 129548660 Charles Davis 18K dept2 5/28/95 8/22/98 3105 454625914 Eric Wood 23K dept1 11/2/95 3025 086630763 Lyons James 25K dept1 1/15/98 11/5/98 3092 129548660 Charles Davis 18K dept3 8/22/98 3025 086630763 Lyons James 25K dept2 11/5/98 The use of null for stop_date is one approach to indicate that particular tuples are still current. The intervals indicated in the start_date and stop_date fields can be opened or closed intervals; however, the formulation of the queries to extract data from the relation depends on this decision. Because this approach does not require an additional table, the resulting schema is simpler than in the tracking-log approach. However, if this approach is taken to create transaction-time state tables that is the semantics of the start_date and stop_date fields are taken to mean the time the change was made to the system, views can be implemented to allow existing snapshot legacy applications to support temporality without modifying any application code. When this approach is taken the primary key cannot be specified as a mere combination of fields. Because no employee can have two different salaries for any overlapping periods of time, the primary key constraint must check the range between the start_date and the stop_date for periods of duplicity. This cannot be enforced by the SQL-92 UNIQUE constraint, but must be implemented using triggers or assertions. Bitemporal Approach In the previous two approaches analysts are required to choose between recording valid time (thus representing past states of the world) and recoding transaction time (thus representing past states of the system). The bitemporal approach allows the system to keep track of both. This is accomplished by modifying the original snapshot table by adding four timestamps: a beginning and ending valid time as 5

well as a beginning an ending transaction time. The granularity of the two ranges need not be the same. An example bitemporal table is shown in table 4. Table 4: A bitemporal employee table Emp # ssn LName FName salary dept valid_start valid_stop Txn_start txn_stop 3025 086630763 Lyons James 15K dept1 1/8/95 1/15/98 1/10/95 1/22/98 3089 579659458 Gordon Walden 25K dept1 5/26/95 5/29/95 3092 129548660 Charles Davis 18K dept2 5/28/95 8/22/98 6/22/95 9/2/98 3105 454625914 Eric Wood 23K dept1 11/2/95 11/12/95 3025 086630763 Lyons James 25K dept1 1/15/98 11/5/98 1/15/98 1/25/98 3092 129548660 Charles Davis 18K dept3 8/22/98 8/23/98 3025 086630763 Lyons James 25K dept2 11/5/98 11/7/98 If the first row in this excerpt from a bitemporal employee table represents the first record for James Lyons then it represents his initial values for this organization the values that were true when he was hired. Thus he was hired on January 8, 1995; however, this fact was not represented in the system until January 10, 1995. This means that on January 9, James worked for the company, but the information system did not know it. The bitemporal approach is an attempt to allow users to ask the question was James Lyons an employee on January 9, 1995 and to ask the question as of January 9, 1999 did this system know that James Lyons was an employee and get different answers. The bitemporal table suffers from the same tuple identification problems as the state table. Other Approaches There are still other approaches to implementing temporal databases that can be achieved within the SQL/92 standard. An early approach was proposed by Clifford and Warren [1981]. In this approach one field is added to identify periods of time termed state intervals during which all data values in the table remained constant (the start and end dates of state intervals are defined in another table) and another field to indicate if the row existed during that state interval. This approach requires each row that ever existed to be represented at each interval. That is, each time the value of any attribute in any tuple is changed, the current values of all the records from the corresponding snapshot must be recorded with the new state interval. A state-interval representation of the example employee table is illustrated in Table 5. Table 5: A state-interval table state Emp # exists? ssn LName FName salary dept interval 1 3025 1 086630763 Lyons James 15K dept1 1 3089 0 null null null null null 1 3092 0 null null null null null 1 3105 0 null null null null null 2 3025 1 086630763 Lyons James 15K dept1 2 3089 1 579659458 Gordon Walden 25K dept1 2 3092 0 null null null null null 2 3105 0 null null null null null 3 3025 1 086630763 Lyons James 15K dept1 3 3089 1 579659458 Gordon Walden 25K dept1 3 3092 1 129548660 Charles Davis 18K dept2 3 3105 0 null null null null Null 4 3025 1 086630763 Lyons James 15K dept1 4 3089 1 579659458 Gordon Walden 25K dept1 4 3092 1 129548660 Charles Davis 18K dept2 4 3105 1 454625914 Eric Wood 23K dept1 6

5 3025 1 086630763 Lyons James 25K dept1 5 3089 1 579659458 Gordon Walden 25K dept1 5 3092 1 129548660 Charles Davis 18K dept2 5 3105 1 454625914 Eric Wood 23K dept1 6 3025 1 086630763 Lyons James 25K dept1 6 3089 1 579659458 Gordon Walden 25K dept1 6 3092 1 129548660 Charles Davis 18K dept3 6 3105 1 454625914 Eric Wood 23K dept1 7 3025 1 086630763 Lyons James 25K dept2 7 3089 1 579659458 Gordon Walden 25K dept1 7 3092 1 129548660 Charles Davis 18K dept3 7 3105 1 454625914 Eric Wood 23K dept1 Although this approach dramatically simplifies the process of querying temporal data (because each entity is represented at each interval) its size requirements make it practical only for trivial databases. The previous approaches all comply with first normal form (1NF) each tuple contains only atomic attributes. These approaches are collectively labeled tuple-versioning approaches to temporal design Some relational temporal data models have been proposed which relax the 1NF constraint allowing multivalued attributes (e.g. [Gadia and Vaishnav, 1985; Clifford and Tansel, 1985]). These approaches are collectively laveled attribute-versioning approaches to temporal design. Table 6 shows the employee table expressed using this multi-valued attribute approach (assuming that only salary and department have temporal concern): Table 6: A multi-valued attribute temporal employee" relation Emp # ssn LName FName salary dept 3025 086630763 Lyons James {<15K (1/8/95,1/15/98]>, <25K (1/8/95, now]>} {<dept1 (1/8/95,11/5/98]>, <dept2 (11/5/98, now,]>} 3089 579659458 Gordon Walden {<25K (2/26/95, now]>} {< dept1 (2/26/95, now]>} 3092 129548660 Charles Davis {<18K (2/28/95, now]>} {<dept2 (2/28/95,8/22/98]>, <dept3 (8/22/98, now,]>} 3105 454625914 Eric Wood {<23K (11/2/95, now]>} {< dept1 (11/2/95, now]>} Because this approach allows multiple values for each temporal attribute it allows the database to maintain the desirable quality of having a single tuple represent a single entity in the real world. However, the use of multi-valued attributes is problematic under current relational database management standards. Each of these approaches attempts to capture the past states of reality for certain portions of the logical data model (relational schema). The need to represent multiple states at the logical level has spawned a number of extensions at the conceptual (E-R) level. Two examples are discussed in the next section. 4. Temporality in Conceptual Database Design Proposed modifications to the E-R model to support these state-history approaches to logical database design have been varied. A recent survey [Gregersen and Jensen, 1999] has identified ten distinct versions of temporally extended E-R models. Fundamentally, these models all attempt to accomplish the same task to provide a conceptual level view of entities to record multiple states of snapshot tables. Here we discuss one approach that is generally representative of the others. Originally presented at the 10 th International Conference on the Entity-Relationship Approach (Tauzovich, 1991), the Temporal ER 7

Model (TER) is an extension of the binary E-R model. In actuality, this approach is composed of two models. The first is a temporally enhanced E-R model. The second is a conversion of the first model to a traditional E-R model, which is then converted to a relational database schema. The model focuses on temporality of relationships. It does not explicitly address temporality of specific attributes. Figure 1 shows a TER diagram with employee, department and salary entities. Figure 1: TER Diagram amount first name last name emp_id name dept_id SALARY S[1,1] S[0,1] S[1,n] S[1,1] EMPLOYEE L[1,n] L[0,n] L[1,n] L[1,n] DEPARTMENT birth date hours/week This model make one major change to the traditional E-R model it replaces the notion of minimum and maximum cardinality with snapshot and lifetime minimum and maximum cardinalities. Thus the S[1,1] near the SALARY entity indicates that each employee has a (snapshot) minimum and a (snapshot) maximum of one salary at a time. The L[1,n] near the SALARY entity indicates that each employee has a (lifetime) minimum of one and a (lifetime) maximum of many values of salary over time. The TER diagram is converted to an ER diagram based on the need to access past states of the relationships. If there is no desire to access past states, then the relationship is rendered with the snapshot cardinality, i.e., as a "static" representation. If the history is expected to be accessed relatively infrequently compared to the current sate, then two entities are added, one for the current state (having a start_date attribute) and one for history (having both start_date and end_date attributes), each having the appropriate cardinalities. If the history is expected to be accessed about as frequently as the current state, then only one entity is added (again having start_date and end_date attributes). Both current and past states are represented by this entity. This ER diagram is then mapped to relations in the standard way. The most complex case for the relationship between EMPLOYEE and DEPARTMENT is shown in Figure 2. The date attributes added to the model can represent valid time or transaction time (others could be added to represent both). The same approach would be followed for the relationship between EMPLOYEE and SALARY. 8

Figure 2: ER diagram form the TER diagram requiring occasional access to history start date first name last name emp_id [1,1] EMPLOYEE [1,1] EMP_DEPT [1,n] [1,1] name dept_id DEPARTMENT birth date [1,1] hours/week [1,n] EMP_DEPT_HIST [1,n] [1,1] start date end date TER extends the E-R model by differentiating snapshot and lifetime relationship cardinalities. It then provides a mapping to a standard E-R diagram that mirrors a temporally partitioned state-table implementation. In contrast, the Temporal Event Entity Relationship Model (TEERM) [Dey, et al., 1995] chooses to not represent state tables as entities. Rather it adds event, temporal relationship, quasi-static relationship, temporal attribute, quasi-temporal attribute, and causal arrows as a new syntactic constructs. It redefines the symbols for relationship and attribute to be static relationship and static attribute. The approach then provides rules that designate how the new and redefined constructs are mapped to a first-normal-form, temporal-relational implementation. Figure 3 shows a TEERM diagram including the events Hire, Pay-raise and Transfer that represent the temporal dynamics of employees and departments. Figure 3: TEERM Diagram signing bonus S Hire R first name last name salary Pay-raise name dept_id EMPLOYEE R (1,*) assigned (1,1) to DEPARTMENT R birth date emp_id hours/week R Transfer These events are not entities. A circled R on the line that connects event to entity indicates that the connected event can recur for the entity. The circled S indicates that an event is singular for a particular 9

entity. Thus, Figure 3 expresses a business rule that a particular employee may only be hired once. The notation for temporal attribute (e.g. salary ) and temporal relationship (e.g. assigned to ) indicate that state history must be maintained. The dashed arrows indicate causality and are used to specify business rules. In this model, events have identity, attributes, relationships with other entities, and a form of cardinality. In virtually every respect, they behave as entities; however, several new constructs are proposed to implement them. We agree that it is important to identify events, but argue that representing them as entities (instead of by new constructs) clarifies the semantics of the application without sacrificing the simplicity of the E-R model. An examination of databases implemented without enlightenment form academic research on temporal databases reveals that this approach has been used for decades to address temporality. We will refer to this approach as the artifact approach to temporal design, and discuss its use and implications next. 5. The Artifact Approach to Temporal Design Practitioners have long used E-R models to represent these rich semantics at the conceptual level. Consider, for example, a simple Accounts Receivable (A/R) application. From a business perspective, invoices are sent to customers when goods or services are delivered. Customers make payments for those goods or services. Discounts may be given for prompt payment and interest may be charged if payment is not received in a timely manner. Furthermore, customers often require a "statement of account" that shows all of their transactions for a specified period of time along with a running account balance, calculated from those transactions. In such an application it is critical to track the business transactions (events) over time. That is, the semantics of time must be explicitly represented. Figure 4 shows a simple E-R model for such an application. Figure 4: Event Diagram (selected attributes) t_no type amount datet c_no name address A/R_TRANSACTION [0,n] [1,1] CUSTOMER city state zip A customer participates in zero or more A/R Transactions. Each A/R Transaction must have exactly one participating customer. In this simple illustration, Customer is identified by customer number (c_no) and is described by the attributes name, address, city, state, and zip. A/R Transaction is identified by transaction number (t_no) and is described by the attributes type, date, and amount. From an accounting perspective there are at least two types of transactions, debits (when delivered goods or services are invoiced) and credits (when payments are made or credit is given for returned goods or services). We argue that such a data model explicitly represents all of the necessary temporal dynamics of the application without requiring semantic constructs beyond those of the basic E-R model. The diagram alone, however, is not sufficient to specify all of the semantics of the application. As with all E-R 10

diagrams, the meaning of each entity and attribute must be explicitly defined. One important aspect of an entity definition is its membership criteria, particularly its temporal aspects. In this example, Customer is defined as "any person or organization to which goods or services have ever been provided or are intended to be provided, even if that entity has ceased to exist legally." A/R Transaction is defined as "any customer debit or credit exchanges that have ever occurred." Customer attributes are defined as the most current values available for that customer (the implications of this definition will be discussed below). A/R Transaction attributes are defined as follows. T_no is a system generated identification number. type has three legal values DI (debit invoice), CP (credit payment), and CM (credit memo). date is the date on which the transaction is recognized and amount is the amount of the transaction (positive for debits and negative for credits). Note that there are several additional transaction dates that could be maintained, representing both actual time and transaction time. These include the date the transaction was postmarked, the date the corresponding business document was produced, or the date the transaction was recorded in the information system. Any or all of these may be important for the semantics of the application. The data modeler must determine which of these or other date related data are required. Each required date must be represented by an attribute in the data model. Developers routinely develop these kinds of applications that support temporality without extensions of the E-R model or the relational model. They do this quite naturally in situations where the business process generates artifacts that represent the causal events of the system. Thus an invoice, a remittance advice, and a credit memo are all documents that record events that change a customer s account balance. These things are generalized to the well-understood accounting concept of a transaction, which is implemented at the conceptual level. Clearly, this approach uses traditional E-R constructs (which map to traditional relational constructs) to model a system that supports temporality. If the assumption that snapshot representations are all the modeling approach supports is accepted, then this application might view customer A/R balance as an attribute of Customer and disregard the A/R transactions altogether. At any given point in time, a customer has an A/R balance. Typically users need to know the current A/R balance, but may also need to know its history. Hence, a temporal database or temporal data model would specify customer A/R balance as a "temporal attribute." Each time a transaction occurred, its value would be updated and its history maintained structurally. While this enables the production of customer statements, it misses the true semantic of the application. It records only the fact that the balance changed. It does not differentiate types of transactions, which explain why the balance changed. A snapshot perspective is inappropriate for this application. Customer A/R account balance is clearly not a "temporal attribute." It is the cumulative result of a set of transaction events and its value at any point in time can be calculated from the customer's related transactions. The representation of events is necessary and sufficient to provide the full range of its temporality. However, this may not be feasible from an implementation perspective. For efficiency reasons customer A/R balance may be maintained as a data item (column) describing Customer 1 and the transaction history may be truncated to a more manageable length of time (and removed transactions archived for the requisite legal period). There are a number of implementation alternates. The customer A/R balance may, for example, contain the "balance forward" from archived transactions, it may contain the "current balance," or the balance forward may be implemented as a special transaction type. In any case balance history can be reproduced for the period 1 We note that the Object-Orientation (OO) principle of encapsulation greatly simplifies migrating from one implementation to the other. In an OO representation Customer_A/R_Balance is a method of Customer. Objects needing to know the value send that message to the appropriate Customer object. How that object determines the value is hidden or encapsulated within the object. 11

of time covered by the remaining A/R transactions. These are design decisions made for efficiency reasons. They do not reflect the semantics of the application. Temporal queries can easily be created to produce a customer's account balance at any point in time. For example if the data model in Figure 4 is implemented directly in relations then the following query can be used to produce the account balance for customer number 1234 on June 1, 1995, SELECT c_no, SUM(amount) FROM Customer, A/R_Transaction WHERE Customer.c_no = A/R_Transaction.c_no and date <= '06/01/1995' GROUP BY c_no Of course this query becomes slightly more complicated if for efficiency reasons the transaction history is truncated. An event representation (facilitated by the existence of institutional artifacts) is a natural choice an A/R application where the transactions affecting customer A/R balance are obvious and well documented. It is extremely unlikely that an analyst would choose to represent A/R balance as a temporal attribute without maintaining the underlying transaction (event) data. We recognize that data model in Figure 4 does not fully represent the temporal aspects of this application. While the data model recognizes that customers participate in A/R Transactions, it fails to represent a number of other events involving customers, choosing to represent only the "cumulative effects" or "resultant state" caused by these events. As discussed above, all attribute values of an entity are the result of the event history of that entity. Customer number, for example is the result of the event that caused the customer to be added to the system. There could be a number of such events as potential customers are identified from a number of different sources. The analyst must determine which events need to be tracked in the information system and, for each such event, what descriptors are important to maintain. Failure to represent the important underlying events often results in implementations that do not meet the real system requirements. The values of customer name and address (including city, state, and zip code) are determined by events in the world. A customer name or address change may be caused by a marriage or job change (for customers who are individuals) or by a merger or acquisition (for corporate customers). They may be caused by a bankruptcy or reorganization. How far back in the causal chain an information system can and should go depends on the needs of the application. It is unlikely that an information system would maintain the entire event history of the real world or even a limited domain of discourse. The analyst must determine what must be explicitly represented. Taking an event, rather than a snapshot perspective enables an analyst to ask intelligent questions and make intelligent decisions about such requirements. The analyst may choose to represent only the cumulative effects of certain types of events. It is certainly simpler to take a static, snapshot view. However, the analyst must recognize that doing so limits the fidelity of the data model created and thus of the system designed to implement it. For example, representing name and address as attributes of Customer explicitly specifies that state history will not be maintained. Hence, the system will not support inquiry or analysis of past customer name and address states. If this is not sufficient for the business needs, then they should not be represented in this way. In situations where the set of causal events is not available to the system, or information about those events is not desired, then temporality can be represented as a set of state histories as discussed in any of the tuple-versioning or attribute-versioning approaches. 12

6. The Event Approach to Temporal Design Unlike the artifact approach, the event approach does not rely on existing documents to represent past states. Instead, this approach seeks to formally identify and record the events that change the state of the system being modeled. This approach has its foundation in the work of McCarthy [1982] and Denna et al. [1993]. The event approach to temporal design is fundamentally different from virtually all approaches in the literature on temporal databases because it does not seek to record past states of a system; instead, it seeks to record the events that change state. In many respects, it is similar to the artifact approach; however, it differs in that artifacts are never incorporated in the model. If all information processing was instantaneous and storage was unlimited, the event approach would not maintain state at all. The state at any point in time would be calculated by applying the relevant events to impute the state desired. Of course, in a world of scarce resources (among them processing speed and storage space) this is not practical, thus the event approach allows for the maintenance of various states such as current state or beginning state. To begin our discussion of the event approach, we identify the events that establish the state of the employee table shown in Table 1. Recall that our snapshot table has six attributes: Emp#, ssn, LName, FName, salary, and dept. An employee is created and assigned to a department by the hire event. This event establishes the beginning values for each of the attributes in the employee table for the newly hired employee. An event structure for the data represented in Table 1 is illustrated in Figure 5. Figure 5: Event Diagram (selected attributes) name dept_id salary first name last name emp_id DEPARTMENT [1,1] [1,n] HIRE [1,n] [1,1] EMPLOYEE birth date hours/week An event analysis, however, facilitates the identification of additional facts related to the event, enabling an analyst to more fully determine the application requirements. For example, events not only happen at a point in time (we will leave the discussion of whether events are instantaneous or happen over a period of time for another paper), they also happen at a particular location. There is generally at least one agent who initiates or is involved in the event. There are often resources consumed by the event or required for the event to transpire. To the extent that these other items of information are of interest, they need to be recorded with the event. If the users of the system need also to determine when specific facts were recorded in the system, transaction time can be added as well. Figure 6 is a model that shows the same event as in Figure 5, but with more information about the event. 13

Figure 6: Event Diagram (more attributes) name dept_id location salary signing bouns first name last name emp_id DEPARTMENT [1,1] [1,n] HIRE [1,n] [1,1] new employee [0,n] [1,1] hiring employee EMPLOYEE valid time transaction time birth date hours/week This model more completely represents the "hire" event that establishes a person as an employee. There are analogous promote, transfer, raise pay, quit, and fire events. Each could be represented as a separate entity or they could be abstracted to a single entity called employment change with an attribute to indicate the type of event. Either way, this approach models the events that cause state change rather than the sequence of states that have existed in the system. The natural byproduct of this approach is that the resulting database has information about why a particular employee has a particular salary. Perhaps more importantly, by recording data at the event level, the system has data in a more elementary from which can be used later to query states that have become important but were not anticipated at the time the system was developed. For example, consider an inventory management system that is initially modeled to maintain the state history of quantity on hand for each product. Since quantity on hand for any product is a value that changes because of many different events, the information available in the event approach is substantially richer than that available in any of the state-history approaches. In each of the state-history approaches, when a product is received (or made), a new record is entered into some table (generally termed product or product history) to indicate the increase to quantity on hand with corresponding valid-time and transaction-time attributes. Likewise, when a product is sold a new record is entered indicating the decrease. In the event approach, the events that change the quantity on hand attribute are recorded. Thus, the fact that a product is received is recorded. The fact that a product is sold is recorded. The fact that a product is shipped is recorded. For convenience or efficiency, a quantity on hand attribute may be maintained to indicate the current state, but the history of the value would be recorded implicitly in the event data. This distinction becomes important when the state of interest changes. Suppose that users of the system needed to answer questions about quantity on hand partitioned differently than when the system was designed. Instead of recognizing a quantity on hand as a value which represents the quantity available for purchase, users needed to know quantity on hand as the physical amount of inventory on the shelf (regardless of whether it is committed to an order) and quantity committed as the amount of product which has been sold but not shipped. In all state-history approaches to representing temporality, a new attribute (quantity committed) would need to be created and the old quantity on hand would take on different semantics. Furthermore, the system would be powerless to distinguish between the two values for any time interval before the new attribute was created. Conversely, in the event approach, a new attribute for quantity committed would be added to represent the current value (if it were accessed often enough to merit the maintenance) but no change would be required to the temporal structure. This dynamic is always evident in situations where several different events interact to change the state of a particular attribute (or set of attributes). In situations such as inventory control where sales, shipments, receipts, manufacturing and shrinkage all combine to yield a single value for the attribute quantity on hand recording state histories rather than events dramatically limits the information available from the 14

database. Additionally, changes in the way users want to view data require changes to the database structure. Since the event approach seeks to record the events in their elemental form, changes to the way users want to view data do not often mandate changes to the database structure; rather, they require new queries or views to combine the event data to meet the new information requirements. When the E-R models resulting from the event approach to temporal design are implemented, all of the normal forms generally accepted by the logical database community can be maintained. In addition, the event approach allows analysts to use the desired version of the E-R model because it does not require special modeling notation. The result is an approach to modeling temporality that can be immediately implemented by analysts using all the tools with which they are familiar. 7. Discussion It is clear that by modeling events, rich temporality can easily be implemented without extensions to either the E-R model or the relational model. The temporal database research which has yielded the tuple- and attribute-versioning approaches to representing temporality add substantial complexity to database design. Perhaps more significantly, it treats time as a special dimension over which values vary. What will be the response when values are determined to vary over some other dimension? Will new database methodologies, modeling approaches, and languages be needed to support them? Consider an example from Sales Order Processing. Suppose products are sold from inventory and the price of each product is fixed at a point in time but can change over time. When a customer places an order, the price for each product is its "current price." Since prices can change over time it is possible that by the time the sales order is invoiced, the current price of a product may have changed. The invoice, of course, must reflect the price at the time the order was placed. A snapshot data model for this application is illustrated in Figure 7. Figure 7: Snapshot product table Product Name No. 2 pencil Blue ball-point pen Yellow highlighter Price.16.26.55 This table is clearly inadequate for the events for application semantics described above. An eventoriented approach explicitly recognizes price-change events and includes a Price_Change entity having the attributes price and date_established. The current price is simply that of the most recent Price_Change event. At invoice time the price of the product at the time of the order can be obtained from the Price_Change entity as seen in Figure 8. Figure 8: Event diagram for price history product_name price Date_established PRODUCT [1,1] [1,n] PRICE_CHANGE 15

Virtually all temporal E-R models [Gregersen and Jensen, 1999] define additional constructs such as special symbols or annotations for time-varying attributes or relationships (e.g. figure 3). We argue that such constructs do not substantively add to the expressiveness of the E-R model, but add rather only to its complexity. We argue that the events should be represented as entities and treated uniformly as entities when the data model is evaluated and mapped to an implementation. If special constructs are added to deal with the time dimension (as suggested by current research in temporal database management), then tuples or attributes could be allowed different values depending on the time of interest. This time dimension can be represented by a cube (Tansel, et. al, 1993, p. 2) as seen in figure 9. Figure 9: Product time cube Tuple Time Product Name No. 2 pencil Blue ball-point pen Yellow highlighter Price.16.26.55.14.24.52.12.25.50.10.19.45.08.14.47 Attribute This figure shows time treated as a separate dimension as is done by most current research about managing temporal data. But what if price varies over some other dimension? We use the semantics of quantities to illustrate this issue. Suppose that products have price-break quantities. That is, ignoring the temporal dimension, the price of a product is determined by the quantity ordered. These semantics frequently exist in contracts or promotions or even as a regular pricing policy. Substituting a PriceBreak entity for the PriceChange event entity and break-quantity for date_established results in an analogous data model for the representation of price (Figure 10). Figure 10: E-R diagram for price history product_name price break_quantity PRODUCT [1,1] [1,n] PRICE_BREAK At invoice time the price of the product at the quantity ordered can be obtained from the PriceBreak entity. In this case the semantics of quantity are exactly analogous to the semantics of time. In fact, the third dimension of quantity could be represented in a manner analogous to figure 9. The product quantity cube is shown in figure 11. 16

Figure 11: Product quantity cube Tuple Quantity Product Name No. 2 pencil Blue ball-point pen Yellow highlighter Price.16.26.55.14.24.52.12.25.50.10.19.45.08.14.47 Attribute Quantity price breaks are common yet there is no call for special constructs or languages for "quantitysemantics" or "quantity-databases." Needless to say, we hope that such a call is never issued. Data models should be driven by the reality of the system being modeled. If the business system requires only a single state (presumably the most recent state recorded in the database), then a static data model is adequate. If the system requires history, then the data model must reflect that history. Representing events is a natural mechanism for doing so. We argue that event semantics are necessary and sufficient for representing temporal dynamics and that adding additional constructs or treating temporal dynamics structurally as suggested by current temporal database research obscures rather than elucidates the semantics of the application. Virtually all data values are temporally dependent in the sense that they reflect the effects of events that occur in the world. While it may not be necessary to represent all of these events in a data model, failure to recognize this fact can lead to significant errors of omission in the determination of information system requirements. 8. Future Research Because the event approach records events that cause entities to experience various states, accessing these states can be processor intensive. Because of the predominance of current state over other states in most database applications, current state is often maintained in parallel to the event stream. This allows quick access to the most recent data; however, it does little for past states. One area of future research is to determine efficient algorithms for summarizing an event stream. Some of the work on the physical implementation of temporal databases may have direct implications in this area. Tsotras, et al.,[1995] identify indexing schemes which efficiently reconstruct state at a point in time by summarizing changes to state values. More of this type of research in needed. Whenever a database records two views of the same reality (as is the case in an event-driven temporal database which also maintains a current state) there exists the possibility for the database to be internally inconsistent. That is, the summarized event stream may show one state, while the maintained current state may show another. This state anomaly is an undesirable condition and should be avoided. One way to avoid it is to disallow application programs from updating current state, instead through the use of triggers in an active database environment, enable the DBMS to maintain current state. However, this requires that the rules for how events affect state be specified in two places. First in the queries used to summarize an event stream and second in the definition of the triggers that maintain current state. 17

Research is needed to identify ways to specify the relationship between an event an state variables once and to allow that specification to be used to compute past states as well as to maintain current state. The event approach to designing databases which support temporality yields very different data models than do other approaches. It is unclear if these models are easier for analysts and users to understand, or if they are harder to understand or if there is no difference. Further, it is unclear if a database is more easily modeled using either approach. Empirical research should be conducted to determine if (and under what conditions) users and analysts are able to make better use of one or the other. References Clifford, J., and Tansel, A. U.: On an algebra for historical relational databases: two views. In Proceedings of ACM-SZGMOD 1985 InternutionulInternational Conference on Management of Data (Austin, Tex., May 1985). ACM, New York, 1985, pp. 247-267. Clifford, J., and Warren, D.: Formal semantics for time in databases. ACM Trans. Database Syst. 8: 214-264, 1981 Dean, T. : Using temporal hierarchies to efficiently maintain large temporal databases. J. ACM 36(4) pp. 687 718. 1989 Denna, E.,Cherrington, J.O., Andros, D., Hollander, A.: Event-Driven Database Solutions. Business One Irwin, Homewood, IL, 1993 Dey, D., Barron, T., and Storey, V.: A conceptual model for the logical design of temporal databases, Decision Support Systems, 15, pp 305-321, 1995. Gadia, S. K., Vaishnav, J.: A query language for a homogenous temporal database. In Proceedings of the 4 th Annual ACM SIGACT-SIGMOD Symposium on Principles of Database Systems (Portland, Ore., Mar. 1985). ACM, New York, pp. 51-56, 1985 Gadia, S., Yeung, C.: A generalized model for a relational temporal database. Proceedings of the conference on Management of Data, pp. 251 259, 1988 Gadia, S.: A homogeneous relational model and query languages for temporal databases. ACM Trans. Database Syst. 13, 4, pp. 418 448, 1998 Gadia, S.: A suitable relational model for temporal databases. Proceedings of the 1985 ACM thirteenth annual conference on Computer Science, p. 423, 1985 Gregersen, H., Jensen, C.S.: Temporal entity-relationship models - a survey. IEEE Transactions on Knowledge and Data Engineering 11(3) pp. 464-497, 1999 Kouramajian, V., Kamel, I., Elmasri, R., Waheed, S.: The time index+: an incremental access structure for temporal databases. Proceedings of the third international conference on Information and knowledge management, pp. 296 303, 1994 Kumar, A., Tsotras, V., Faloutsos, C.: Designing Access Methods for Bitemporal Databases. IEEE Transactions on Knowledge and Data Engineering, 10(1): pp.1-20, 1998 18

McCarthy, W.E.: The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review, 58(3):554-578, 1982 McKenzie, E., Snodgrass, R.: Extending the relational algebra to support transaction time. Proceedings of the ACM SIGMOD Annual Conference on Management of data, pp. 467-478, 1987 Ozsoyoglu, G., Snodgrass, R.: Temporal and Real-Time Databases: A Survey. IEEE Transactions on Knowledge and Data Engineering, 7(4): pp.513-532, 1995 Snodgrass, R., Ahn, I.: A taxonomy of time databases, Proceedings of the 1985 international conference on Management of data. pp. 236-246, 1985 Tansel, A; Clifford, J; Gadia, S; Jajodia, S; Segev, A; Snodgrass, R:. Temporal Databases : Theory, Design, and Implementation. Redwood City, CA : Benjamin/Cummings Pub., 1993 Tauzovich, B.: Toward Temporal extensions of the Entity-Relationship Model. Proc. 10 th Int l Conf. Entity Relationship Approach pp. 136-179, Oct-1991 Toman, D.: Point-Based Temporal Extensions of SQL and their Efficient Implementation. In O. Etzion, S. Jajodia, and S.Sripada (Eds.): Temporal Databases: Research and Practice, (LNCS) Springer- Verlag Berlin Heidelberg pp. 211-237 1998 Tsotras, V., Gopinath, B., Hart, G.: Efficient Management of Time-Evolvong Databases. IEEE Transactions on Knowledge and Data Engineering, 7(4): pp.591-607, 1995 Wand, Y., Wang, R.: Anchoring Data Quality Dimensions in Ontological Foundations. CommunicaitonsCommunications of the ACM, 39(11): 86-95,1996 Wang, X., Bettini, C., Brodsky, A., Jajodia, S.: Logical design for temporal databases with multiple granularities. ACM Trans. Database Syst. 22(2) pp. 115 170, 1997 19