Traditionally, semantic data models have not supported the modeling of behavior. We present an event modeling approach that can be used to extend semantic data models like the entity-relationship model and the functional data model. We model an event as a two-sided phenomenon that is seen as a totality of an information object and a change agent. When an event is modeled as an information object it is comparable to an entity that exists only at a specific point in time. It has attributes and can be used for querying and specification of constraints. When an event is modeled as a change agent it is comparable to an executable transaction schema. Finally, we briefly compare our approach to object-oriented approaches based on encapsulated objects.
Key Terms: Conceptual Modeling, Events, Information Objects, Change Agents, Dynamic Constraints, Event Patterns.
Semantic data models like the functional model (Shipman 1981), SDM (Hammer et al. 1981), and Telos (Mylopoulos 1992) have been created in order to support the modeling of structure. So far, the ER model (Chen 1976) is the most successful semantic data model. It has evolved into a de facto standard for conceptual database design. During the years it has been extended with generalization/specialization hierarchies and aggregation structures in order to enhance its modeling power (Batini et al. 1992).
Traditionally, semantic data models have not supported the modeling of behavior and most of the recent work on event modeling in conceptual models is based on the notion of encapsulated objects. We present an approach to behavioral modeling where events are modeled in a way that makes them first-class citizens in the same way as entities.
We model events as two-sided phenomena. First, we model events as information objects in Section 2. Second, we model events as change agents in Section 3. In Section 4 we illustrate the use of event patterns. In section 5 we briefly compare our event modeling approach to approaches based on the object-oriented paradigm..
When events are modeled as information objects they can be seen as entity-like phenomena. Events can be related to entities and to attribute values. In order to model such relationships we extend a binary entity-relationship model with event sets.
An entity is an immutable surrogate that exists in a specific time interval. An entity set is a named, time-varying set of entities. In structure diagrams entity sets are symbolized by named rectangles. An event is an immutable surrogate that exists at a specific point time. An event set is a named, time-varying set of events. In structure diagrams event sets are symbolized by named circles. A value set is a named set of values from a specified domain like String, Integer, Boolean etc. Value sets are symbolized by dotted rectangles. Binary relationships are used to relate entities to values and to relate entities to entities. Relationship sets are symbolized by straight lines.
The structure diagram in Figure 1 represents a schema for a library database. The lines with inclusion symbols symbolize subset constraints. For example, each Book entity is an Item entity, i.e., the entity set Book is a subset of the entity set Item.
Figure 1. Structure diagram for library database.
Each Borrower entity represents one library borrower. Each Book entity represents one library book. Book entities can be related to Borrow events and Return events.
Our model does not support inheritance. However, a similar effect is obtained because a specific entity (or event) can be member of more than one set. For example, a specific entity may participate in a Sell event as an Item entity and at the same time have a Title attribute as a Book entity.
The arrows indicate participation constraints. For example, Borrower
Book is a 1:1 relationship set that relates Borrower and Book. Black arrows symbolize mandatory participation. For example, each Return event must be related to exactly one Book entity.
The following sets illustrate sets illustrate possible populations of entity sets, event sets, and relationship sets.
Borrower = {e1, e2, e3}
Book = {e4, e5, e6}
Borrow = {ev1, ev2, ev3}
Return = {ev4, ev5}
Borrower
Borrow
Return
Borrower
Book
Borrower
Book
All event sets are subsets of the universal event set Event as illustrated in Figure 2. The event set Event has one mandatory attribute, Time, that models the execution time for events.
Figure 2. All event sets are subsets of Event.
The subset relationships in Figure 2 imply that all events have Time attributes as Event events.
All entity sets are subsets of the universal entity set Event as illustrated in Figure 3. The entity set Entity has two attributes, Begin and Start, that models the existence time for entities. In Section 4 we illustrate how these attributes can be derived from the time attributes of the events that create and destroy entities.
Figure 3. All entity sets are subsets of Entity.
The subset relationships in Figure 3 imply that all entities have Begin and End attributes as Entity entities.
Events can be used as the basis for constraint specification when they are modeled as information objects. We use a specification example from a library to illustrate this (Bækgaard 1997).
Figure 4. Library book.
In Figure 4 the life-cycles of Book entities have been constrained in terms of temporal relationships between event sets. The specification in Figure 4 implies that the first event in which a Book entity participates must be a Buy event as an Item entity. A particular Book entity can participate in at most one Buy event. Then, the Book entity can participate in an alternating sequence of Borrow and Return events starting with a Borrow event. In-between the Borrow and Return events the Book entity can participate in Reserve events. Finally, the Book entity can participate once in a Sell event as an Item entity.
Figure 5. Library borrower.
The specification in Figure 5 implies that the first event in which a Borrower entity participates must be a Register event. The Borrower entity can participate in a register event once. Then, the Borrower entity can participate in any sequence of Borrow, Return, and Reserve events. The number of currently borrowed books is not allowed to exceed 10. Finally, the Borrower entity can participate once in a Quit event if all borrowed books have been returned.
In order to specify events that modify the population of a structure diagram we need a notation that makes it possible to refer to the population of a structure diagram. Therefore, we introduce a notation for path expressions and paths.
We assume that the library database is populated as follows.
Borrower = {e1, e2, e3}
Book = {e4, e5, e6}
Borrow = {ev1, ev2, ev3}
Return = {ev4, ev5}
Borrower
Borrow
Return
Borrower
Book
Borrower
Book
The expression Borrower is a path expression of length 1 and the expression BorrowerName is a path expression of length 2. We use two different but related interpretations of path expressions.
If we use a set-value interpretation the path expression Borrower evaluates to the following path set.
{e1[Borrower], e2[Borrower], e3[Borrower]}
The path expression BorrowerName evaluates to the following path set.
{e1[Borrower]:"John"[Name],
e2[Borrower]:"Linda"[Name],
e3[Borrower]:"Jim"[Name]}.
We use the following convention to define a truth-value interpretation of path expressions: False = { }. Truth-value interpretations are useful because they facilitate the specification of update conditions. The following examples illustrate the use of truth-value interpretations of path expressions.
Borrower
Book
When a path expression is used as a Boolean expression a truth-value interpretation is used. Otherwise, a set-theoretic interpretation is used.
A TELL command has an effect part (TELL) and a input/condition part (WHERE). Path expressions that occur in the TELL part are evaluated using a set-value interpretation. Path expressions that occur in the WHERE part are evaluated using a truth-value interpretation. Every combination of free variables that makes the WHERE part true is used to instantiate the TELL part. When the path expressions in the TELL part are evaluated the resulting sets are added to the database.
The following TELL command creates a new Borrower entity and relates it to the Name element "Gail". NewEntity is a function that returns a new unique entity.
TELL Borrower(X),
Borrower(X)
WHERE X = NewEntityY = "Gail
The effect of this command is illustrated in the following updated sets where the new entity e9 has been added to Borrower and e9"Gail" has been added to BorrowerName. Consequently, the expression BorrowerName("Gail") evaluates to true.
Borrower = {e1, e2, e3, e9}
Borrower
The following command relates the keyword "data model" to all books that are related to the keyword "conceptual model".
TELL Book(X)
WHERE Book(X)
Y = "data model"
Z = "conceptual model"
Informally, this command is executed as follows. For any X such that X"conceptual model" Î BookKeyword, X"data model" will be added to BookKeyword.
The effect of this command is illustrated in the following updated relationship set.
Book
e6
An UNTELL command has an effect part (UNTELL) and a input/condition part (WHERE). Path expressions that occur in the UNTELL part are evaluated using a set-value interpretation. Path expressions that occur in the WHERE part are evaluated using a truth-value interpretation. Every combination of free variables that makes the WHERE part true is used to instantiate the TELL part. When the path expressions in the UNTELL part are evaluated the resulting sets are removed from the database.
The following command deletes all books that are related to the keyword "conceptual model".
UNTELL Book(X),
Book(X)
WHERE Book(X)
Y = "conceptual model"
The effect of this command is illustrated in the following updated entity and relationship sets.
Book = {e4}
Book
An event specification has the following form.
EVENT <event signal>
DO <command list>
The informal semantics of an event specification is as follows. The EVENT part defines the initiation criterion for execution of an event. The DO part defines the action that is performed when an event is executed. The actions are defined in terms of update commands. Parameters are transferred from the EVENT part to the DO part.
A Borrow event can be defined in the following way. NewEntity is a function that returns a new unique entity.
EVENT Borrow (X: Borrower, Y: Book)
DO TELL Borrow(W),
Borrower(X)
Borrow(W)
Event(W)
WHERE W = NewEvent
A Borrow event is initiated by an event signal on the form Borrow(X, Y) where X is a Borrower entity and Y is a Book entity. The effect of a Borrow event is that a new Borrow event is generated and related to the participating entities and to the Time value NOW.
A Return event can be defined in the following way. Its semantics are similar to the semantics of the Borrow event specification.
EVENT Return (X : Borrower, Y : Book)
DO TELL Return(W),
Borrower(X)
Return(W)
Event(W)
WHERE W = NewEvent
In many modeling situations the event sets are related pair-wise in the sense that they create/destroy entities or relationships. For example, Buy events create Item entities whereas Sell events destroy Item entities. Furthermore, for a specific Buy-Item-Sell triple, (b, i, s), the Begin and End attributes of i (as Entity) is identical to the Time attributes of b (as Event) and s (as Event), respectively. This is illustrated in Figure 6.
Figure 6. Derived existence times.
Figure 7 illustrates how relationships can be derived in terms of event pairs.
Figure 7. Derived relationship.
Figure 7 states that the execution of a Borrow event creates a BorrowerBook relationship that exists until the corresponding Return event occurs.
The similarity of the specifications of Borrow and Return events in Section 3 strongly indicates that it might be useful to identify patterns of such specifications. The two specifications are identical in the sense that they take two entities as arguments, creates a new event that is related to the input entities and the current time. This points to the pattern in Figure 8.
Figure 8. Event specification pattern.
Whenever an event type conform to a pattern like the one in Figure 8 it is not to explicitly specify the event as an change agent. The specification can be derived from the pattern.
We have presented a modeling approach that supports the specification of events as a combination of information objects and change agents. Events are specified as first-class citizens with independent existence in the same way as entities.
In recent years the notion of object-orientation has been imported from the world of programming languages to the world of conceptual models (Kim et al. 1989), (Zdonik et al. 1990), (Kim 1995). Like semantic data models many object-oriented models support the modeling of structure in terms of generalization/specialization hierarchies and aggregation structures. However, the object-oriented models use encapsulated objects to support the modeling of behavior.
An encapsulated object is a totality of an object identifier, a state, and a behavior. The object identifier is used to distinguish the objects from each other. The state is represented by a set of attributes that are hidden to the external observer. The behavior is represented by a set of methods or services that defines the interface as seen by an external observer.
When encapsulated objects are used for the modeling of events an object class can be defined for each type of modeled events. For example, an object class, Return, can be defined in such a way that each Return object represents one return event. One method, ReturnEvent, can be used to model return events as change agents. A set of attributes and a corresponding set of display methods can be used to model return events as information objects.
It is possible to use an object-oriented modeling language for the implementation of the event concept that we have discussed in this paper. It is, however, necessary to be aware of the following points.
The modeling of behavior is a primary concern in the object-oriented paradigm. However, within this paradigm behavioral modeling is strongly coupled to individual objects. Such an approach is well suited to support strong encapsulation but as indicated by the preceding three points it is not well suited for the modeling of events as information objects and change agents in a symmetric way.
Batini, C., S. Ceri and S. B. Navathe (1992), Conceptual Database Design. An Entity-Relationship Approach, USA, Benjamin/Cumings.
Bækgaard, L. (1997), "Transaction-Based Specification of Database Evolution," 16th International Conference on Conceptual Modeling (ER'97), Los Angeles, California, USA.
Chen, P. P. (1976), "The Entity-Relationship Model - Towards a Unified View of Data," ACM Transactions of Database Systems, 1: 9-36.
Hammer, H. and D. McLeod (1981), "Database Description with SDM. A Semantic Database Model," ACM Transactions of Database Systems, 6(3): 351-386.
Kim, W., Ed. (1995), Modern Database Systems. The Object Model, Interoperability, and Beyond, Addison-Wesley.
Kim, W. and F. H. Lochocsky, Eds. (1989), Object-Oriented Concept, Databases, and Applications, ACM Press, Addison-Wesley Publishing Company.
Mylopoulos, J. (1992), "Conceptual Modeling and Telos," Conceptual Modeling, Databases, and CASE. An Integrated View of Information Systems. P. Loucopoulos and R. Zicari, John Wiley & Sons.
Shipman, D. W. (1981), "The Functional Data Model and the Data Language DAPLEX," ACM Transactions on Database Systems, 6(1): 140-173.
Zdonik, S. B. and D. Maier, Eds. (1990), Readings in Object-Oriented Database Systems. California, Morgan Kaufmann Publishers, Inc.