Database Reference
In-Depth Information
existence of these things and facts. The gray-colored boxes depict external object classes.
They contain objects that play a role in the business processes, but their existence is deter-
mined by transactions other than those in the CM. The white-colored boxes depict internal
object classes. The objects in these classes are created in the mentioned transactions. For
the classes Membership, Loan, and Shipment, this is obvious. For BookCopy, these are the
topics delivered in shipments to the library.
The diamond shaped fact types are the production fact types that also appear in the
Transaction Result Table of Figure 3. These fact types link the conceptual schema of the
production world to the transactions that change the state of the production world. Consider
the creation and termination of loans. There are two 'normal' fact types: “the membership
of L is M” and, “the topic copy of L is C”. A uniqueness constraint holds for the role of the
loan in both fact types: a loan always relates to at most one membership and one topic copy.
A mandatory constraint also holds for Loan in both fact types. Hence a loan always relates
to exactly one membership and one topic copy. Therefore, the fact types “the membership
of L is M” and “the topic copy of L is C” are
existentially dependent
on Loan.
existentially dependent
A new loan can be conceived of (and in a simulation game be generated), but that
doesn't mean that it actually exists yet. In order to come into being, an event of type PE04
is needed. This event has a time stamp (the point in time at which it occurs). By defi nition
this is the point in time at which the transaction T04 concerning L has successfully been
completed (Dietz, 2003a). The loan ends its existence by an event of type PE06. During the
lifetime of the loan, an event of type PE07 may occur (late return fi ne payment).
ORM
This section briefl y explains the basic ORM graphical symbols, and then provides an
ORM model for the library application. Object-Role Modeling is so-called because it views
the universe of discourse (application domain) as a set of
objects
(non-lexical entities or
lexical values) that play
roles
(parts in relationships). ORM stores all data in simple
fact
types
, catering for unary, binary, and longer relationships, and allowing all fact structures to
be easily populated with sample data to help validate business rules. Unlike ER and UML,
ORM makes no use of attributes.
Graphically, object types are depicted as named ellipses (solid for entity types, and
dotted for value types). As in logic, a
predicate
is a proposition with object-holes in it. In
ORM, a predicate is treated as an ordered set of one or more roles, each of which is depicted
as a box, which may optionally be named. A fact type is formed by applying a predicate to
the object types that play its roles. Fact types in ORM must be given one or more readings.
The
arity
of a predicate is its number of roles. For discussion purposes, each fact type may
be populated by entries in a sample fact table that includes one column for each role of the
fact type.
The ORM model in Figure 5 includes three object types (
Movie
,
Person
and
Sex
)
and fi ve fact types:
Movie is banned
;
Movie is based on Movie
;
Movie was directed
by Person
;
Movie was reviewed by Person
;
Person is of Sex
. Inverse readings are
supplied for two associations:
Person directed Movie
;
Person reviewed Movie
. One role
is named (“
director
”). Simple identifi cation schemes may be abbreviated in parentheses. For
example,
Movie(Nr)
abbreviates the injective (1:1 into) association
Movie has MovieNr
.
For simplicity, we assume that persons in this domain may be identifi ed by name. In this
