Database Reference
In-Depth Information
Usually, constraints on derived fact types are themselves derivable. However, further
constraints can be explicitly added to them (e.g., the value constraint on NrOnLoanItems).
This provides a convenient and powerful way to declare various business rules that are
awkward to express on base fact types.
Figure 9 shows basic subschemas for the topic and shipment areas. If a topic has an
International Standard Book Number (ISBN), the library records this as well. These sub-
schemas are straightforward, so should need no further explanation.
POSSIBLE BENEFITS OF ORM FOR DEMO
As explained earlier, the DEMO approach uses a state model to declare the “essential”
fact types and rules pertaining to the real world objects in the application domain. A state
model is specifi ed using an object-fact diagram supplemented by an object property table.
Figure 4 shows the state model for the library application. Collectively, Figure 6, Figure
8 and Figure 9 provide an ORM model for the library application. A comparison between
these two models reveals some important differences.
An ORM model is intended to capture all the fact types that are of interest in the ap-
plication domain, as well as all static business rules (constraints and derivation rules that
apply to each individual state of the information system) that need to be enforced. ORM
models are also formal, so that they can be automatically transformed into implementation
models. For these reasons, ORM models tend to be more complete and precise than cor-
responding DEMO state models.
The fi rst major addition provided by ORM models is their
inclusion of at least one
identifi cation scheme for each entity type
. For example, in Figure 6 we see that each loan
is identifi ed by a loan number, and each topic copy is identifi ed by a barcode. In addition,
we see that each topic copy can be identifi ed by combining the call number of its topic with
a copy number. Any reference scheme that is to be used in the application is considered
relevant. Apart from being needed for the operation of the information system, such iden-
tifi cation schemes enable the modeler to use real examples when populating fact types for
validation purposes (as shown in Figure 5). This makes it much easier to decide whether
the model accurately refl ects the application domain. As DEMO considers the choice of any
identifi cation scheme as non-essential, this kind of information is ignored.
The second major difference is that ORM models typically
capture more constraints
.
For example, the DEMO-SM ignores any dependency between the unary fact types PE05
(
BookCopy has been returned
) and PE04 (
Loan has ended to exist
) because this is
captured in the OM (and consequently in the PM). To enforce the dependency, the ORM
model includes a subset constraint between the loan-return and loan-end fact types to ensure
that each returned loan is classifi ed as ended. In general, ORM's constraint language is more
powerful (e.g., see Halpin, 2002b).
A third addition provided by ORM models is that
all temporal aspects are declared
explicitly
. For example, consider the DEMO unary fact type PE04:
Loan has started to
exist
. Like any other DEMO fact type, this has an implicit time stamp. In ORM, this is
explicitly modeled using the fact type:
Loan was issued on Date
. This goes beyond the
DEMO representation by including the
granularity
of the time stamp—in this case, day,
rather than, for example, minute or second. This granularity choice is uncovered by inspec-
tion of sample requirements or by discussion with the domain expert. One of the design
