Modeling Temporal Dynamics for Business Systems1in the development and verification of data models. Furthermore it maintains modeling parsimony and facilitates the representation of

Journal of Database Management, 14(3), 21-36, July-Sept 2003 21

Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without writtenpermission of Idea Group Inc. is prohibited.

Modeling Temporal Dynamics forBusiness Systems1

Gove N. Allen, Tulane University, USASalvatore T. March, Vanderbilt University, USA

ABSTRACT

Research in temporal database management has viewed temporal dynamics from a structuralperspective, posing extensions to the Entity-Relationship (E-R) model to represent the statehistory of time-dependent attributes and relationships. We argue that temporal dynamics aresemantic rather than structural and that the existing constructs in the E-R model are sufficientto represent them. Practitioners have long used E-R models without temporal extensions todesign systems with rich support for temporality by modeling both things and events as entities— a practice that is consistent with the original presentation of the E-R model. This approachsupports methodologies that leverage narrative and human cognitive processing capabilitiesin the development and verification of data models. Furthermore it maintains modelingparsimony and facilitates the representation of causality — why a particular state exists.

Keywords: Conceptual modeling, Entity-Relationship models, temporal databases, temporaldata models, time semantics, event representation

INTRODUCTION

Numerous authors recognize theimportance of representing the temporal,or time-dependent, aspects of businessdata. These include Dey, Barron, andStorey (1995), Ozsoyoglu and Snodgrass(1995), Etzion, Jajodia, and Sripada (1998),Gregersen and Jensen (1999), Snodgrass(2000), and March and Allen (2003).Managers frequently must know not onlythe most current data but also historical

data. They require facts such as:

· a specific customer’s account balanceon a specific date (e.g., on the date thatcustomer was refused additional credit)and the transaction history that lead tothat balance,

· the length of time an employee has beenat his or her current salary level and thehistory of salary reviews and salarychanges, and

22 Journal of Database Management, 14(3), 21-36, July-Sept 2003


· the last date on which a stock-out wasexperienced for a specific inventory itemand the history of sales and purchasesfor that item.

Business systems increasingly requiresupport for temporality. In a seminal bookon temporal database research, theory, andimplementation Tansel et al. (1993) statethe motivating assumption of temporaldatabase research as follows,“Conventional databases were designed tocapture the most recent data, that is, currentdata. As new values become availablethrough updates, the existing data valuesare removed from the database. Suchdatabases capture a snapshot of reality.Although conventional databases servesome applications well, they are insufficientfor those in which past and/or future dataare also required. What is needed is adatabase that fully supports the storage andquerying of information that varies overtime” (preface). Depending on the domainof interest, simply representing time-varying information may not be sufficientto meaningfully reconstruct its history. Itmay be necessary to represent the causesof those variations.

Numerous extensions to the relationalmodel and relational databases have beenposed seeking to better manage thetemporal nature of business information.These include the notion of temporalfunctional dependency (Wang, et al.,1997), techniques to facilitate temporalqueries (Dean, 1989; Gadia and Yeung,1988), extensions to the relational modeland relational algebra (Gadia, 1988;McKenzie and Snodgrass, 1987), andindexing algorithms to support temporalqueries (Kouramajian et al., 1994; Kumar,etal., 1998). The complexity added by theseextensions immediately suggests a need fortemporal support at the conceptual level.Over a dozen temporal Entity-Relationship

(E-R) models have been proposed(Gregersen and Jensen, 1999; Dey, et al.,1995). These extend the E-R model byadding syntactic constructs and changingthe fundamental definitions of existingconstructs. They are based on theassumption that, “The E-R model can atbest represent a ‘snapshot’ of the realworld at any point in time; it does notcontain specific constructs to model thedynamic aspects of the real world. As aresult, the E-R model is an inadequate toolfor temporal database design” (Dey, et al.,1995, p. 306).

Temporality has arisen as a majorproblem in data representations notbecause of limitations to the E-R orrelational models but because databasedesign approaches have viewed datamodels as representing only a snapshot ofthe world at a point in time and recommendignoring the temporal aspects of theapplication during initial data modeling(Snodgrass, 2000). Temporality isaddressed in a post hoc, structural mannerby identifying “temporal attributes” in asnapshot model and using a temporalDBMS to maintain state history for thoseattributes.

We contend that a data model shouldnot be so viewed nor should the temporalaspects of an application be left to posthoc analysis. A data model represents thesemantics necessary to support a specificapplication’s purpose. If that purposeincludes temporality, then the temporalnature of the data must be represented inthe data model. Time is an integral part ofthe semantics of most business systemsand should not be treated as a simplestructural addition. Its semantics shouldbe modeled. Furthermore, merelyrepresenting the state history of temporalattributes is often semantically deficient.



It may be necessary to identify andexplicitly describe the events that causestate changes rather than simply recordingwhat past states have been. For example,in an accounting application it is notsufficient to represent the fact that acustomer’s account balance changed from$10,000 to $8,000 on September 1, 2002.The cause of that change must also berepresented. Was the change due to apayment or a return or a credit or anegotiated settlement? Explicitlyrepresenting events such as receivepayment, receive return, issue credit, andnegotiate settlement provide that causalexplanation. Such a representation isconsistent with the E-R model (Chen,1976), which defines an entity as a “thingor event” that is important to the domainbeing modeled. Such event entities enablethe reconstruction of the history of thedomain including changes and the eventsthat caused them. Hence they are thefoundation of an accurate and explicitrepresentation of the causal aspects oftemporality.

By representing events as entities thetemporal dynamics of an application canbe simply and parsimoniously representedwithout structurally extending the E-Rmodel. Organizations often create formaldocuments (artifacts) to record data aboutspecific events (e.g., sell, pick, pack, ship,invoice). Such artifacts are naturallyrepresented as entities in a data model.However, documents are not alwayscreated for all important events. Hence,event analysis (McCarthy, 1982; Denna,et al, 1993; Geerts and McCarthy, 2002)provides a practical approach to modelingtemporality. We argue that focusing onevents aids an analyst in determining andvalidating those aspects of temporaldynamics that are important for theapplication domain.

TEMPORALITY IN LOGICALAND CONCEPTUAL DATABASEDESIGN

Two approaches have been proposedfor representing temporality in relationaldatabases, tuple-versioning and attribute-versioning. Tuple versioning retains firstnormal form relations (Snodgrass, 2000)while attribute versioning uses non-firstnormal form relations (Gadia and Vaishnav,1985; Clifford and Tansel, 1985). Eachbegins with a snapshot schema,representing the current state of anorganization, and provides a means to storepast states of temporal attributes (usingtuples or attributes, respectively).

Proposed modifications to the E-Rmodel to support these state-historyapproaches to logical database design arevaried. A recent survey by Gregersen andJensen (1999) identified ten temporallyextended E-R models. These all begin withthe notion that the basic E-R modelrepresents only current state. Hence theyadd various constructs to denote whenstate history must be maintained. Herewe discuss two such approaches, theTemporal Entity-Relationship Model (TER)(Tauzovich, 1991) and Temporal Event-Entity-Relationship Model (TEERM) (Dey,et al., 1995). TER is an extension of thebinary E-R model. It is composed of twomodels. The first is a temporally enhancedE-R model. The second is a conversion ofthat model into a traditional E-R model,which is then converted to a relationaldatabase schema. TER focuses ontemporality of relationships. It does notexplicitly address temporality of attributes.Figure 1 shows a TER diagram withemployee, department and salary entities.

TER makes one major change to thebasic E-R model—it replaces the notion



of minimum and maximum cardinality withsnapshot and lifetime minimum andmaximum cardinalities. Thus the S[1,1]above the relationship arc near theSALARY entity indicates that eachemployee has a (snapshot) minimum anda (snapshot) maximum of one salary at anypoint time. The L[1,n] below it indicatesthat each employee has a (lifetime)minimum of one and a (lifetime) maximumof many salaries over time.

The TER diagram is converted to anE-R diagram based on the need to accesspast states of the relationships. If there isno need to access past states, then therelationship is rendered with the snapshotcardinality, i.e., as a static representation.If history is accessed relatively infrequentlycompared to the current sate, then twoentities are added, one for the current state(having a start_date attribute) and one for

history (having both start_date andend_date attributes), each having theappropriate cardinalities. If history isaccessed about as frequently as the currentstate, then only one entity is added (againhaving start_date and end_date attributes).Both current and past states arerepresented by this entity. It is not specifiedif the date attributes represent valid time(when the change occurred) ortransaction time (when the change wasrecorded in the database). The temporalrelationship between Employee andDepartment is similarly developed. Theresulting E-R diagram is then mapped torelations in the standard way. The mostcomplex case for the relationship betweenEMPLOYEE and DEPARTMENT isshown in Figure 2.

TER extends the E-R model bydifferentiating snapshot and lifetime

EMPLOYEESALARY DEPARTMENTS[1,1] S[0,1] S[1,n] S[1,1]L[1,n]L[1,n]L[1,n] L[0,n]

hours/weekbirth date

first name last name emp_id dept_idnameamountFigure 1: TER Diagram

Figure 2: ER diagram from the TER diagram requiring occasional access to history

[1,1]

EMPLOYEE


first name last name emp_id

DEPARTMENT

dept_idname

[1,n]

[1,1] EMP_DEPT

start date

EMP_DEPT_HIST

end datestart date

[1,n]

[1,1]

[1,n]

[1,1]

[1,1]



relationship cardinalities. In contrast, theTemporal Event Entity Relationship Model(TEERM) (Dey et al., 1995) adds semanticconstructs for: event, temporalrelationship, quasi-static relationship,temporal attribute, quasi-temporalattribute, and causal arrows. It redefinesthe standard symbols for relationships andattributes to be static relationships andstatic attributes, respectively. It providesrules designating how the new andredefined constructs are mapped to a first-no rma l - fo rm, t empora l - r e l a t iona limplementation. Figure 3 shows a TEERMdiagram including the events Hire, Pay-raise and Transfer that represent thetemporal dynamics of employees anddepartments.

A circled “R” on the line thatconnects an event to an entity indicatesthat the connected event can recur for theentity. The circled “S” indicates that anevent is singular for a particular entity.Thus, Figure 3 expresses the business rulesthat a hire event relates an employee anda department, that a particular employee

may only be hired once, and that adepartment may hire many employees.Temporal attributes (e.g., “salary”) andtemporal relationships (e.g., “assigned to”)are boxed to indicate that their statehistories must be maintained. The dashedarrows indicate causality and are used tospecify business rules. In this model,events have identity, attributes,“relationships” with other entities, and aform of cardinality. In virtually everyrespect, they behave as entities; however,several new constructs are proposed toimplement them.

We agree that it is important toidentify events, but argue that representingthem as entities instead of by newconstructs clarifies the semantics of theapplication without sacrificing the simplicityof the E-R model. An examination ofdatabases implemented withoutenlightenment from academic research ontemporal databases reveals that thisapproach is frequently used in practice toaddress temporality. We will refer to thisas the artifact approach to temporal design,

Figure 3: TEERM Diagram

DEPARTMENT(1,*) (1,1)

Figure 3: TEERM Diagram


first name last name

emp_id

dept_idname

Hire

TransferR

S R

R

EMPLOYEE assignedto

salary Pay-raise

R

signing bonus



and discuss its use and implications next.THE ARTIFACT APPROACH TOTEMPORALITY

Practitioners have long used E-Rmodels to represent temporal semantics atthe conceptual level. Consider, forexample, a simple Accounts Receivable(A/R) application. From a businessperspective, invoices are sent to customerswhen goods or services are delivered,customers make payments for those goodsor services, and credits may be issued ifgoods are returned or damaged in delivery.These are events for which organizationstypically create artifacts (standard businessforms or documents) used in normalbusiness processes. When a customerrequires a “statement of account” theappropriate invoices, payments, and creditsmust be accessed. Hence it is critical totrack the business transactions (events)over time. That is, the semantics of timemust be explicitly represented. Figure 4shows a simple E-R model for such anapplication. A customer participates inzero or more A/R Transactions (e.g.,invoices, payments, credits). Each A/RTransaction must have exactly oneparticipating customer. In this simpleillustration, Customer is identified bycustomer number (c_no) and is describedby the attributes name, address, city, state,

and zip. A/R Transaction is identified bytransaction number (t_no) and is describedby the attributes type, date, and amount.From an accounting perspective there areat least two types of transactions, debits(when delivered goods or services areinvoiced) and credits (when payments aremade or credit is given for returned goodsor services).

We argue that such a data modelexplicitly represents all of the necessarytemporal dynamics of the applicationwithout requiring semantic constructsbeyond those of the basic E-R model. Thediagram alone, however, is not sufficientto specify all of the semantics of theapplication. As with all E-R diagrams themeaning of each entity and attribute mustbe explicitly defined as must the processing(rules) necessary to reconstruct thedomain history. One important aspect ofan entity definition is its membershipcriteria, particularly its temporal aspects.In this example, Customer is defined as“any person or organization to which goodsor services have ever been provided or areintended to be provided, even if that entityhas ceased to exist legally.” A/RTransaction is defined as “any customerdebit or credit exchange that has everoccurred.”

Customer attributes are defined as“the most current values available for that

CUSTOMER[0,n] [1,1]

zipcity

c_no addressname

A/R_TRANSACTION

typet_no

state

amount date

Figure 4: ER Model Based on Existing Documents (A/R Transaction)



customer.” Hence the events affecting acustomer’s attributes and their statehistories are deemed to be outside the scopeof the system. A/R Transaction attributesare defined as follows. t_no is a systemgenerated identification number. “type”has three legal values DI (debit invoice),CP (credit payment), and CM (creditmemo). “date” is the date on which thetransaction is recognized and “amount” isthe amount of the transaction (positive fordebits and negative for credits).

Note that there are numerousadditional “transaction dates” that could bemaintained, representing both actual timeand transaction time. These include, forexample, the date the transaction waspostmarked, the date the correspondingbusiness document was produced, and thedate the transaction was recorded in theinformation system. Any or all of thesemay be important for the semantics of theapplication. The data modeler mustdetermine which of these or other daterelated data are required. Each requireddate should be represented by an attributein the data model.

Developers routinely developapplications that support temporalitywithout extending the E-R model or therelational model. They do this quitenaturally in situations where businessprocesses generate artifacts that representthe causal events of the system. Thus aninvoice, a remittance advice, and a creditmemo are all documents that record eventsthat change a customer’s account balance.These are generalized to the well-understood accounting concept oftransaction, which is represented at theconceptual level.

Clearly, this approach uses traditionalE-R constructs (which can be mapped totraditional relational constructs) to modela system that supports temporality.

Conversely a snapshot representationwould view customer A/R balance as a“temporal” attribute of Customer,potentially ignoring the A/R transactionsthat cause it to change. Each time atransaction occurs, its value would beupdated and its history maintainedstructurally. While this enables theproduction of customer balance andbalance history, it misses the true semanticsof the application required for theproduction of customer statements. Itrecords only the fact that the balancechanged. It does not differentiate types oftransactions, which explain why thebalance changed (e.g., credit versuspayment). That is, a customer statementrequires a transaction history not just abalance history.

Hence a snapshot perspective isinappropriate for this application.Customer A/R account balance is not justa “temporal attribute.” It is the cumulativeresult of a set of transaction events and itsvalue at any point in time is determinedfrom those transactions. Therepresentation of events is necessary andsufficient to provide the full range of itstemporality. However, for efficiencyreasons customer A/R balance may bemaintained as a (calculated) data item(column) describing Customer and thetransaction history may be truncated to amanageable length of time with removedtransactions archived for the requisite legalperiod. There are a number ofimplementation alternatives. The A/Rbalance data item may, for example,contain the “balance forward” fromarchived transactions, it may contain the“current balance,” or the balance forwardfrom archived transactions may beimplemented as a special transaction type.In any case transaction history can bereproduced for the period of time covered



by the remaining A/R transactions. Theseare design decisions made for efficiencyreasons. They do not reflect the semanticsof the application.

Temporal queries can easily becreated to produce a customer’s accountbalance at any point in time. For exampleif the data model in Figure 4 is implementeddirectly in relations then the following SQLquery can be used to produce the accountbalance for customer number 1234 on June1, 2002 (this query becomes slightly morecomplicated if for efficiency reasons thetransaction history is truncated):

SELECT c_no, SUM(amount)FROM Customer, A/R_TransactionWHERE Customer.c_no = A/R_Transaction.c_noand date <= ’06/01/2002'and Customer.c_no=1234

An event representation, facilitatedby the existence of institutional artifacts, isa natural choice for an A/R applicationwhere the transactions affecting customerA/R balance are obvious and welldocumented. It is extremely unlikely thatan analyst would choose to represent A/Rbalance as a temporal attribute withoutmaintaining the underlying transaction(event) data. In situations where the setof causal events is not available to thesystem or where information about thoseevents is not needed, then temporality can

be represented as a set of state historiesas discussed in the temporal data modelingapproaches. However, when users needto understand “why” a particular stateexists, then events must be recorded insome manner.

THE EVENT APPROACH TOTEMPORALITY

Unlike the artifact approach, theevent approach does not rely on existingdocuments to represent temporaldynamics. Instead, this approach seeks toformally identify the events that causestate-changes and the “things” that areaffected in the system being modeled. Inthis view things and events are inextricablyintertwined. Things do not exist withoutevents and events do not exist withoutthings. Events cause things to change state.The event approach has its foundation inthe work of McCarthy (1982), Geerts andMcCarthy (2002), and Denna et al. (1993).It is fundamentally different from virtuallyall approaches in the literature on temporaldatabases because it does not seek toidentify temporal attributes or relationshipsor to record past states of a system.Instead, it seeks to identify and representall events that occur and the “things”(resources, agents) affecting and affectedby them. When documents exist for all

EMPLOYEEHIRE [1,n] [1,1][1,n][1,1]



DEPARTMENT

dept_idname salary

Figure 5: ER Model Based on Events



important events, the resultant data modelmay be indistinguishable from that producedusing the artifact approach. However, itdiffers from the artifact approach in that itexplicitly analyzes the (economic)resources, events, and agents thatconstitute business processes, not theartifacts that represent them.

Furthermore, McCarthy, as anaccountant, recognized the inherent dualityof economic events within an organization— for every debit there must be a balancingcredit. Wand and Weber (1995) recognizea similar notion with the concept of stableand unstable states. When an event occursthat causes the system to move to anunstable state, at least one other event mustoccur to move the system back to a stablestate. For example, the event “customerplaces order” causes the system to enteran unstable state. Although, strictlyspeaking, no economic (financial) event hasoccurred the organization has an obligationto fulfill that customer’s order. In this waythe existence of an unfilled customer orderinitiates the order fulfillment businessprocesses. This process culminates in the

delivery of and payment for the orderedgoods, a stable state in which all obligationsfor the order have been fulfilled. Althoughit may not be important for the implementedinformation system to track all of the eventsthat happen in such a business process ananalyst must identify all of them in order tomake that determination.

Consider the events that occur withrespect to employment within anorganization. Managers in the HumanResources area are familiar with eventssuch as hire, promote, transfer, reviewperformance, quit, terminate, etc. and thebusiness rules associated with them. Anemployee is “created” (or more specificallythe employee “role” is created for aperson) and assigned to a department by a“hire” event. This event establishes theinitial values for the employee’s attributesand relationship as illustrated in Figure 5.It also creates an obligation or an unstablestate in the sense that an employee isemployed for some purpose - the employeeis obligated to work; the organization isobligated to evaluate that work, etc. Theanalyst must determine which events are

EMPLOYEE [1,1]

[1,1]



DEPARTMENT

dept_idname

[0,n] [1,1]new employee

hiring employeeHIRE

[1,n][1,n]

initialsalary

transactiontime

valid time

locationsigningbonus

REVIEW

[0,n]

reviewsalary

transactiontime

valid time

[0,n]

[1,1] [1,1]

reviewing employee

Figure 6: A More Complete Event ER Model



within the scope of the information systemunder development. In particular, it maybe important to recognize that an eventoccurred, even if the event did not result inany changes (e.g., an employee salaryreview with no salary change).

An event analysis facilitates theidentification of additional facts related tothe event. That is, events address thequestion of “why” a change occurred.Events not only happen at a point in time(when); they also happen at a location(where Denna et al., 1993); there aregenerally agents or actors who initiate orare involved in the event (who); there areoften resources consumed by the event orrequired for the event to transpire (whatand how). To the extent that these otheritems of information are of interest, theymust be represented in the data model. Foreach event, then, an analyst must determinethe associated resources, agents, andlocations. This provides a checklist forassuring that the relevant informationrequirements are more completelydetermined.

If the users of the system need alsoto know when an event occurred (validtime) and when event data were recordedin the system (transaction time) both shouldbe included in the data model. Figure 6shows a more complete eventrepresentation as in Figure 5, includingadditional hire event information (location,signing bonus, valid and transaction time,and the employee responsible for managingthe hire event) and the additional event,review, occurring when an employee isreviewed.

This model includes all of the temporalaspects modeled in the TER and TEERMdiagrams in Figures 2 and 3, respectively.The one-to-many relationship between hireand employee represents the temporalnature of employees working in

departments as in the lifetime manyrelationship between employee anddepartment in the TER model and the hireand transfer events in the TEERM model.The review entity represents the lifetimemany relationship between employee andsalary in the TER model and the Pay-raiseevent in the TEERM model.

Once the creation or “coming to be”event (Bunge, 1977) is established for anemployee it is appropriate to analyzeadditional events that cause changes in theemployee’s identified attributes andrelationships (properties) relevant to thedomain under investigation. This enablesthe analyst to derive the “narrative” of thebusiness application, evoking humancognitive processes related to problemsolving and sense making (Robinson andHawpe, 1986; Pillemer, 1998). Therepresentation “tells the story” of theemployee through events such as hire,transfer, promotion, performance review,quit, and terminate. Each event is aseparate entity, possibly interconnected inan abstraction hierarchy and interrelatedthrough temporal constraints, e.g., anemployee cannot participate in aperformance review after a terminateevent unless there is an intervening hireevent. In any case, this approach modelsthe events that cause state change ratherthan merely the sequence of past statesand produces a more understandablerepresentation for users and analysts.

A natural byproduct of this approachis that the resulting database hasinformation about why a state exists.Perhaps more importantly, by recordingdata at the event level, the system has datain an elementary from which can be usedlater to query states that have becomeimportant but were not anticipated at thetime the system was developed. Forexample, consider an inventory



management system that is initiallymodeled to maintain the state history ofquantity on hand for each product. Sincequantity on hand for any product is a valuethat changes because of many differentevents, the information available in theevent approach is substantially richer thanthat available in any of the state-historyapproaches. In the state-history approach,when a product is received (or made), ahistory is retained to indicate the changeto quantity on hand with correspondingvalid-time and, perhaps transaction-time,likewise when a product is sold.

In the event approach, the events thatchange the quantity on hand are recorded.Thus, the fact that a product is received isrecorded. The fact that a product is soldis recorded. The fact that a product isshipped is recorded. For convenience orefficiency, a quantity on hand attribute maybe represented to indicate the current state,but its history would be recorded implicitlyin the event data. This distinction becomesimportant when the “state of interest”changes. Suppose that users of the systemredefine quantity on hand from “quantityavailable for purchase” to “physical amountof inventory on the shelf” (regardless ofwhether it is committed to an order) andrequire quantity committed defined as “soldbut not yet shipped.” In a state-historyapproach, a new attribute, quantitycommitted, would need to be created andthe old attribute, quantity on hand, wouldtake on different semantics. Furthermore,the system would be powerless todistinguish between the two values for anytime before the new attribute was created.In the event approach, quantity committedcan be calculated from the relevant eventswith no change to the temporal structure.This elucidates a critical distinctionbetween business systems and othersystems which may be better suited to the

attribute versioning approach of mosttemporal database research.

In business systems, the largemajority of the “states of interest” areartificially defined to be summaries ofspecific sequences of events. Unlikenatural systems in which events occur tobring about observable states of things,these artificially defined states (such asprofit, expenses, and quantity available forsale) cannot be observed and must beimputed from a set of observed events. Innatural systems, the observed state is oftenthe result of very complex (and ill-understood) transformation functionsinvolving a very large number of oftenunobservable events. For systems thattrack the health of individuals over time,state-versioning systems are veryappropriate because all of the events thatbring about the state of an individual’shealth are not observable. Moreover, therelationship between those events and theobserved health is not perfectly understood.In such a system, seeking to record eventsand then using those events to calculatepast states for individuals’ health is simplyimpossible. Instead, state is recorded as itis observed as kept as a state history. Thisapproach is quite adequate for such asystem because 1) state is observed, 2)events are not always observed, and 3) therelationship between state and events iscomplex and unclear. In business systems,just the opposite is true. State is most oftennot observable, but the events that causestate are. More importantly, the relationshipbetween the events and the state is simpleand very clearly understood because it isdefined. In many cases, the definition ofstates is generally accepted as a matter ofstandard business terminology. Forexample, the state termed “revenue” issimply the sum of sales for a given periodof time. The manner in which events



combine to yield other states needs to bedocumented in some fashion. Clearly, suchdocumentation lies outside the scope of theE-R model.

In situations such as inventory controlwhere sales, shipments, receipts,manufacturing and shrinkage all combineto yield a single value for the attribute“quantity on hand” recording state historiesrather than events dramatically limits theinformation available from the database.Additionally, changes in the way users wantto view data require changes to thedatabase structure. Since the eventapproach seeks to record the events in theirelemental form, changes to the way userswant to view data do not often mandatechanges to the database structure; rather,they require new queries or views tocombine the event data to meet the newinformation requirements.

Analysts and designers choose howan information system will represent things,states, and events according to the domainof interest. Determining the current stateof a thing from an event sequence requiresthe specification of the transformation(function) for each state and event in thesequence (Wand and Weber, 1995). Whensuch transformation functions are invertiblethen the state-history and the eventrepresentations are equivalent. Often,however, the transformation function doesnot have an inverse; the same state historycan be generated from different sets ofevents. In this case the designer mustdetermine the appropriate representation.An information system can be designed tocapture and maintain only the current stateof the things of interest when state-history,events, and transformation functions aredeemed to be outside the scope of interest.At the opposite extreme an informationsystem can be designed to capture andmaintain data about all of the events in

which a thing is involved and thetransformation functions relevant for athing and calculate its current state andstate-history when needed. Frequentlysome middle ground is most appropriatewhere some combination of state, event,and transformation function data ismaintained.

Consider, for example, the GeneralLedger of a company. A General Ledgerhas some number of Accounts (things).Suppose each Account has threeproperties (attributes), “name” specifyingthe text to be used to describe the account,“type” designated as Asset, Liability,Capital, Revenue, or Expense, and“balance” specifying the current dollarvalue ascribed to that account. Theaccount name is specified once when theaccount is created and may be changedwhen deemed necessary. It may or maynot be important to keep track of the historyof that attribute. It is very unlikely that aninformation system would record thebusiness event or transformation functionthat lead to the change. Account type isalso specified when an account is created,however, it is not allowed to change.

When business events (transactions)affecting the financial position of thecompany occur, accounting practicerequires the effects of those events onappropriate account balances to berecorded. These transactions are recordedas debits and credits. The transformationrule is simple and invertible. For Assetand Expense accounts, account balance isthe sum of debits minus the sum of credits.For Liability, Capital, and Revenueaccounts, account balance is the sum ofcredits minus the sum of debits. A GeneralLedger system required to report accountbalances may record transactions (events)or it may maintain only the current balance(the state resulting from applying the



transactions). In both cases thetransformation function must be applied.In the former design the transformation isapplied on the output side, using recordedtransactions to calculate the balance whenneeded. It requires maximal storage andprocessing but provides maximumflexibility. In the latter design thetransformation is applied on the input side,updating the recorded data when atransaction occurs. It requires minimalstorage space and minimal processing atreport time. However, it does not allowfor causal analysis of the General Ledgerapplication and is clearly an inappropriatedesign for auditing purposes. A typicalGeneral Ledger design includescomponents of both. The value of“balance” is recorded for each account ata specified point in time (e.g., at year end)and transactions (events) are recorded fromthat point in time to the present.

In business information systems, weobserve events but often definetransformation rules to create artificial,unobservable states which are often ofprimary interest. For example, virtually allfinancial data regarding a company’sperformance are artificial states definedby transformation rules that aggregateevents in various ways. A company’srevenue for a period is defined as the sumof the price of all goods or services soldduring that period. Revenue cannot bedirectly observed. It is only through theapplication of the transformation rule to aset of events that a value for revenue canbe determined. The same is true forexpenses, assets, shareholders’ equity andmany other financial attributes of anorganization. Only the very few measuresof a company’s performance have statesthat can be directly observed, e.g., physicalinventory, bindings, equipment. However,even in those cases the value of those

observables is calculated based on events,e.g., when purchased, legal depreciationfunctions.

CONCLUSIONS AND FUTURERESEARCH

The fundamental purpose of a datamodel is to faithfully represent the realityof the business system under investigation.If the business system requires only a singlestate (presumably the most recent staterecorded in the database), then a static datamodel is adequate. If it requires state-history, then the data model must reflectthat history. If it requires a causal historythen events must be represented. Weargue that event semantics are sufficientfor representing the temporal dynamics ofbusiness systems and that adding additionalconstructs or treating temporal dynamicsstructurally as suggested by currenttemporal database research obscuresrather than elucidates the semantics of theapplication. Temporality is semantic notstructural. Representing events is a naturalmechanism for representing the semanticsof temporality.

Virtually all data are temporal in thesense that they reflect the effects of eventsthat have occurred in the world. While itmay not be necessary to represent all ofthese events in a data model, failure torecognize this fact can lead to significanterrors of omission in the determination andrepresentation of information systemrequirements. We have argued that anevent analysis can provide an appropriateframework for addressing this issue.

Because the event approachrepresents events rather than states,implementing an events design can beprocessor and storage intensive. Becauseof the predominance of current state overother states in most database applications,



current state is often maintained in parallelwith the event stream. This allows quickaccess to the most recent data; however,it does little for past states. One area offuture research is to determine efficientalgorithms for summarizing an eventstream. Some of the work on the physicalimplementation of temporal databases mayhave direct implications in this area.Tsotras, et al. (1995), for example, identifyindexing schemes that efficientlyreconstruct state at a point in time bysummarizing changes to state values.Additional research in this area is needed.

Whenever a database records twoviews of the same reality (as is the casewhen a system maintains both an eventstream and current state) there is thepossibility that the database is internallyinconsistent. That is, the summarized eventstream may show one state, while themaintained current state may show another.This “state anomaly” is obviously anundesirable condition. One way to avoid itis to disallow application programs fromupdating current state, instead through theuse of triggers in an active databaseenvironment, enable the DBMS to maintaincurrent state. However, this requires thattransformation functions be specified intwo places — first in the system used tosummarize an event stream and second inthe definition of the triggers that maintaincurrent state. Research is needed toidentify ways to specify the relationshipbetween an event and state variables onceand to allow that specification to be usedto compute past states as well as tomaintain current state.

Data models that represent eventsare very different from those that representstates and state history. It is unclear if oneof these models is easier for analysts andusers to understand or if there is nodifference. Further, it is unclear if a

business system is more easily modeledusing either approach or if businessmanagers are better able to validate onerepresentation or the other. Although someresearch has been conducted in this area(Allen, 2001) published results areinconclusive—clearly more research isneeded.

END NOTE

1 This paper is an extension ofresearch originally published in (March andAllen, 2003).

REFERENCES

Allen, Gove N. (2001). The Effectof Event Organization in DatabaseRepresentations on User Data RetrievalPerformance, Ph. D. Dissertation.University of Minnesota, Minneapolis.

Bunge, M. (1977). Ontology I: theFurniture of the World, volume 3 ofTreatise on Basic Philosophy. Boston: D.Reidel Publishing Company.

Chen, P. P-S. (1976). The Entity-Relationship Model - Toward A UnifiedView Of Data. ACM Transactions onDatabase Systems, 1(1), 9-36.

Clifford, J., & Tansel, A. U. (1985).On An Algebra For Historical RelationalDatabases: Two Views. Proceedings ofACM-SIGMOD 1985 InternationalConference on Management of Data,Austin, Texas. New York: ACM Press, pp.247-267.

Dean, T. (1989). Using TemporalHierarchies to Efficiently Maintain LargeTemporal Databases. Journal of theACM, 36(4), 687-718.

Denna, E., Cherrington, J.O., Andros,D. & Hollander, A. (1993). Event-DrivenDatabase Solutions. Homewood, IL:



Business One Irwin.Dey, D., Barron, T., & Storey, V.

(1995). A Conceptual Model for theLogical Design of Temporal Databases.Decision Support Systems, (15), 305-321.

Etzion, O., Jajodia, S. & Sripada, S.(Eds.) (1998). Temporal Databases:Research and Practice. Berlin: Springer-Verlag.

Gadia, S. K. & Vaishnav, J. (1985).A Query Language for a HomogenousTemporal Database. Proceedings of the4th Annual ACM SIGACT-SIGMODSymposium on Principles of DatabaseSystems, Portland, Oregon. New York:ACM Press, pp. 51-56.

Gadia, S., & Yeung, C. (1988). AGeneralized Model for a RelationalTemporal Database. Proceedings of theACM SIGMOD Conference onManagement of Data, Chicago, Illinois.New York: ACM Press, pp. 251-259.

Gadia, S. (1988). A HomogeneousRelational Model and Query Languages forTemporal Databases. ACM Transactionson Database Systems, (13)4, 418-448.

Geerts, G. & McCarthy, W. E.(2002). An Ontological Analysis of thePrimitives of the Extended-REA EnterpriseInformation Architecture. TheInternational Journal of AccountingInformation Systems, (3)1, 1-16.

Gregersen, H. & Jensen, C. S.(1999). Temporal Entity-RelationshipModels - A Survey. IEEE Transactionson Knowledge and Data Engineering,(11)3, 464-497.

Kouramajian, V., Kamel, I., Elmasri,R., & Waheed, S. (1994). The Time Index+:An Incremental Access Structure forTemporal Databases. Proceedings of theThird International Conference onInformation and KnowledgeManagement, Gaithersburg, Maryland.New York: ACM Press, pp. 296-303.

Kumar, A., Tsotras, V., & Faloutsos,C. (1998). Designing Access Methods forBitemporal Databases. IEEETransactions on Knowledge and DataEngineering, 10(1), 1-20.

March, S. T. and Allen, G. N. (2003).Temporal On the Representation ofTemporal Dynamics. In: Siau, K. (Ed.)Advances in Database Management (pp.37-53). Hershey: Idea Group Publishing,2003.

McCarthy, W. E. (1982). The REAAccounting Model: A GeneralizedFramework for Accounting Systems in aShared Data Environment. TheAccounting Review, 58(3), 554-578.

McKenzie, E. & Snodgrass, R.(1987). Extending the relational algebra tosupport transaction time. Proceedings ofthe ACM SIGMOD Conference onManagement of Data, San FranciscoCalifornia, New York: ACM Press, pp.467-478.

Ozsoyoglu, G. & Snodgrass, R.(1995). Temporal and Real-TimeDatabases: A Survey. IEEE Transactionson Knowledge and Data Engineering,7(4), 513-532.

Pillemer, D. B. (1998). MomentousEvents, Vivid Memories, Cambridge, MA:Harvard University Press.

Robinson, J. A. and Hawpe, L.(1986). Narrative thinking as a heuristicprocess. In: T. R. Sarbin (Ed.), NarrativePsychology: The Storied Nature ofHuman Conduct (pp. 111-125). New York:Prager Publishers.

Snodgrass, R. (2000). DevelopingTime-Oriented Database Applications inSQL. San Francisco: Morgan Kaufmann.

Tansel, A., Clifford, J., Gadia, S.,Jajodia, S., Segev, A., & Snodgrass, R.(1993). Temporal Databases: Theory,Design, and Implementation. RedwoodCity, CA: Benjamin/Cummings.



Tauzovich, B. (1991). TowardTemporal extensions of the Entity-Relationship Model. Proceedings of the10th International Conference on EntityRelationship Approach, San Mateo,California: E-R Institute, pp. 136-179.

Tsotras, V., Gopinath, B., & Hart, G.(1995). Efficient Management of Time-Evolving Databases. IEEE Transactionson Knowledge and Data Engineering,

Gove N. Allen holds bachelors and masters degrees in Accountancy from BrighamYoung University. For three years, Dr. Allen operated a small consulting firm specializingin client/server database management and design, and the surrounding technologies,winning contracts from both state and federal government agencies as well as providingtraining and development services for major corporations such as Sony, AT&T, Sprint,Hewlett Packard, Micron, Intel, and American Express. More recently, he developed(and continues to support) WebSQL.org, a site for teaching database management thatallows dynamic execution of Structured Query Language against Oracle and MicrosoftSQL Server databases through a simple web interface. Dr. Allen received his Ph.D.from the University of Minnesota in 2001 and currently serves as an assistant professorof e-business and information systems at Tulane University’s A. B. Freeman School ofBusiness.

Salvatore T. March is the David K. Wilson Professor of Management at the OwenGraduate School of Management, Vanderbilt University. He received a BS in IndustrialEngineering, MS and PhD degrees in Operations Research from Cornell University.His teaching responsibilities and research interests are in Information SystemDevelopment, Conceptual Modeling, Distributed Database Design, Electronic Commerce,and Object-Oriented Development Tools and Methodologies. His research has appearedin journals such as ACM Computing Surveys, ACM Transactions on DatabaseSystems, Communications of the ACM, IEEE Transactions on Knowledge and DataEngineering, The Journal of MIS, Journal of Database Management, andInformation Systems Research. He served as the Editor-in-Chief of ACM ComputingSurveys and as an Associate Editor for MIS Quarterly. He is currently a Senior Editorfor Information Systems Research and an Associate Editor for Decision SciencesJournal, Journal of Database Management, Information Systems and e-BusinessManagement, and Information Systems Frontiers.

7(4), 591-607.Wand, Y. & Weber, R. (1995). On

the Deep Structure of Information Systems.Information Systems Journal, (5), 203-233.

Wang, X., Bettini, C., Brodsky, A.,& Jajodia, S. (1997). Logical Design forTemporal Databases with MultipleGranularities. ACM Transactions onDatabase Systems, 22(2), 115-170.