Temporal Entity-Relationship Models -- a Survey <s> Design Criteria and Evaluation of the Models <s> A question that always arises when dealing with temporal information is the granularity of the values in the domain type. Many different approaches have been proposed; however, the community has not yet come to a basic agreement. Most published temporal representations simplify the issue which leads to difficulties in practical applications. In this paper, we resolve the issue of temporal representation by requiring two domain types (event times and intervals), formalize useful temporal semantics, and extend the relational operations in such a way that temporal extensions fit into a relational representation. Under these considerations, a database system that deals with temporal data can not only present consistent temporal semantics to users but perform consistent computational sequences on temporal data from diverse sources. <s> BIB001 </s> Temporal Entity-Relationship Models -- a Survey <s> Design Criteria and Evaluation of the Models <s> Abstract If a computer system is to deal with temporal semantics, it must understand the nature of time and have the ability to accept and reason with time-related facts. This reasoning ranges from the knowledge and use of the chronological nature of a given calendar system, to the more complex nature of inductive reasoning between related events and time periods. This paper investigates the handling of time as it has been applied to the fields of data modelling and artificial intelligence. Systems using the techniques are investigated. Significant features and properties are then extracted and examined where they are pertinent to systems capable of modelling temporal data. <s> BIB002 </s> Temporal Entity-Relationship Models -- a Survey <s> Design Criteria and Evaluation of the Models <s> In valid-time indeterminacy, it is known that an event stored in a temporal database did in fact occur, but it is not known exactly when the event occurred. An extension of the tuple-timestamped temporal data model, called the possible chronons data model, is presented to support valid-time indeterminacy. In the possible chronons data model, each event is represented with a set of possible chronons, delimiting when the event might have occurred and a probability distribution over the set. The TQuel query language is extended using constructs that specify the user's credibility in the underlying valid-time data and the user's plausibility in the relationships among that data. A formal tuple calculus semantics is outlined, and it is shown that this semantics reduces to the determinate semantics on determinate data. > <s> BIB003
In Sections 2.2 to 2.10, we described all temporal ER models known to us. It is a common characteristic that few or no speci c requirements to the models were given by their designers. To compare and better understand the models, this section de nes a comprehensive set of design criteria for temporal ER models and evaluates the models against these criteria. We h a ve c hosen to also evaluate the EER model against the criteria. When doing so, the model will be treated as a temporal model, capturing time through timestamp attributes. We h a ve i d e n ti ed a total of 19 design criteria covering time semantics, model semantics, temporal functionality, and user-friendliness. The criteria are numbered C1 through C19. With each criterion de ned, we indicate its source, if possible. We have attempted to only include criteria that have an objective basis for being evaluated. Together, the criteria identify important aspects of designing a temporal ER model. The possible outcomes of an evaluation of a model with respect to each criterion will be stated explicit together with the de nition of each criterion, unless the possible outcomes are N.A., Yes, a n d No. Figures 23, BIB002 , and 25 present the results of the evaluations of evaluating the models with respect to criteria C1{C3, C4{C13, and C14{C19, respectively. C1|Time Dimensions with built-in Support Valid and transaction time are general|rather than application speci c|aspects of all database facts. As such, they are prime candidates for being built into a temporal ER model that is to be used for both analysis and database design. Being orthogonal and independent aspects of database facts, it is possible to support the two times independently. Support for these times may take di erent shapes and may be more or less elaborate. Another kind of time exists, namely the so-called user-de ned time (UDT). This refers to \support" for temporal aspects with no built-in support in the model. User-de ned times are supported when time-valued attributes are available. These are then employed for giving temporal semantics|not captured in data model, but only externally, by the database designer|to the the ER diagrams. We will say that a time is supported simply if some support has been documented. The possible outcomes of evaluating a model against this criterion are UDT, VT, TT, and N.A. (and combinations of VT and TT). For a model to beconsidered temporal, at least one time dimension must be supported. Almost all the models support valid time. The only model that does not is the EER model that only supports user-de ned time. All the models support user-de ned time. Transaction time is supported by only TempEER. That is, the valid-time aspect of a database application seems to be regarded as the most interesting aspect to support, thereby aiming at high-delity modeling of the mini-world. C2|New Temporal Constructs Two general approaches to providing temporal support exist. With implicit temporal support, explicit timestamp attributes are \hidden" in the temporal semantics of the modeling constructs. For example, no timestamp attributes are necessary on a temporal relationship type to indicate that the instances of the type record their variation over time. With this approach, it is possible to obtain a temporal ER model without adding any new syntactical constructs to the ER model. Rather, the existing ER constructs are simply made temporal by changing their semantics. For example, ordinary relationship types are given temporal semantics, making their instances record variation over time, rather than just single states. It is also possible with this approach to retain the existing ER constructs and their semantics and add new temporal constructs to capture the time-varying information. The new notation for a temporal relationship type in MOTAR is an example. The extent o f t h e c hanges made to the ER model may range from minor changes to a total rede nition of the model. With explicit temporal support, the semantics of the existing ER constructs are retained. With this approach, timestamp attributes are explicit. Any new modeling constructs are notational shorthands introduced to make the modeling of temporal aspects more convenient. Nearly all the models have added new temporal constructs. Some of the models have changed the semantics of the ordinary ER model constructs entirely. These models are TEER and TempEER. Other models have retained the old ER constructs and have added new temporal constructs. These models include TERM, MOTAR, ERT, TER and TempRT. RAKE does not add any new constructs to the ER model instead, it introduces notational shorthands for certain patterns made up of ordinary ER constructs. However, we will consider these notational shorthands to be temporal constructs. One model has both changed the semantics of the ER constructs and added new temporal constructs, namely STEER. The speci c names of the added constructs can be seen in the third column of Figure 23 (they are mentioned in the order in which they are introduced in this paper). The EER model has not added any new constructs|it captures time solely through timestamp attributes. The models with mandatory use of the temporal constructs are TEER, STEER, TempEER and TER. TEER and TempEER have c hanged the semantics of all the original ER model constructs to be temporal. STEER has|besides making the original ER constructs temporal|added new temporal constructs to the model. Since TER has replaced the ordinary cardinality constraints with two new ones, and it is mandatory to specify the constraints, it becomes mandatory to use the temporal constructs, even if the users later decide to only record a single state of data. The models that have retained the ordinary ER constructs and have added new temporal construct have optional use of temporal constructs. Thus, it is possible to mix temporal and non-temporal constructs in these models that include MOTAR, ERT, and TempRT. TERM has optional use of history structures and history patterns since all attributes (inclusive the existence and roles attributes) can be declared as constant. RAKE also has optional use of the temporal constructs since these are notational shorthands for patterns made up of ordinary ER constructs. Since the EER model has not added new constructs, N.A. is the result of evaluating the model against this criterion. the utility of the model. Possible outcomes include N.A., instant, interval, a n d temporal element. All three data types mentioned may encode validity for durations, and the instant d a t a t ype may also encode validity for single instants of time. In the former case, instants have associated interpolation functions (see Criterion C8). The impact of which data types are available is dependent on whether the model under consideration is used solely as a design model or is also used as an implementation model, complete with database instances and a query language. The models that timestamp with instants include RAKE (events), TERM, MOTAR, and TER. The models RAKE, TERM, ERT, TempEER, and TempRT timestamp with intervals. The models TEER and STEER timestamp with temporal elements. Finally, this criterion is not applicable to the EER model, since it does not support valid time. C5|Data Types Supported for Transaction Time As valid and transaction time have di erent semantics, the timestamp types available for the two times may di er. The possible outcomes are as for valid time. TempEER is the only model that supports transaction time. The timestamp used for transaction time in TempEER is instants (that encode durations). N.A. is indicated in the gure for all the other models. C6|Support for Multiple Granularities It may bethat the temporal variability of di erent objects in the mini-world are captured using times of di erent granularities  BIB001  . They should then also be captured in the database using these di erent granularities. For example, the granularity of a minute may be used when recording the actual working hours of employees, while the granularity of a day may beused when recording the department assignments of employees. Notice that this criterion relates to valid time. There are two models in which it is possible, at the conceptual level, to specify the granularity o f the timestamps. In MOTAR, the user is allowed to specify the frequency of the recording of periodic attributes. In TERM, atomic histories can have di erent time domains. The rest of the models only brie y state that the granularity of the timestamps should besuitable for speci c applications and hence postpone the choice of granularity to the logical design phase. C7|Support for Temporal (Im-) Precision The temporal variability of di erent objects in the mini-world may be known with di erent precisions  BIB003   . Although some imprecision may becaptured using multiple granularities, granularities are not a general solution. For example, the variability of an attribute may berecorded using timestamps with the granularity of a second, but the varying values may only beknown to the precision of 5 seconds of the recorded value. This phenomenon may b e p r e v alent and important to capture in scienti c and monitoring applications that store measurements made by instruments. The only model which support temporal precision is TERM, where it is possible to specify precision on the timestamps (and also the values of attributes).