Database Reference
In-Depth Information
heuristics in ORM is to consider each fact type, and ask whether it needs to be treated in a
snapshot or historical way. For example, consider the fact type:
BookCopy has CopyNr
.
Although in the real world, instances of this fact type come into being at a given time (e.g.,
when assigned by the librarian), the recording of time stamp information for this fact type
is not of interest to the users of the library application (as confi rmed in interview sessions).
Hence the ORM model excludes any temporal information about this fact type. In contrast,
DEMO's ontological approach includes time stamps for all production events.
A fourth difference is that ORM provides
formal derivation rules
for relevant derived
fact types. This makes it possible to automatically generate application code to enforce the
rules. For example, consider the four derived properties listed at the bottom of the DEMO
state model in Figure 4. Although precise, they are not expressed in a formal language, so
are not executable. Although a derivation rule for computing a person's age is included in
the ORM model, this applies only to those members who supply their birth dates. The library
decided not to require all applicants to provide their birth date (this is left optional), allow-
ing other ways to establish age (e.g., by visual inspection of the applicant). In contrast, the
DEMO model assumes that birth dates are always known, and its derivation rule is based
on this assumption.
Unlike a person's age, the determination of fi nes for overdue loans is always con-
sidered to be of interest to the system, as is the recording that such fi nes were paid. Unlike
the DEMO model's single derivation rule for incurred fi nes, the ORM model includes two
derivation rules, one to allow the computation at any instant for unpaid fi nes, and one to
record fi nes that were actually paid (see Figure 8). The ORM model captures explicitly all
decisions about what history to record in the information system.
In addition to enabling the formal capture of more information than DEMO state
models, ORM provides
modeling procedures
and
formal transformation theorems
to assist
modelers to create conceptual models and map them to implementation code. Details on
ORM's conceptual schema design procedure and transformation theorems may be found in
Halpin (2001a). Of particular interest in this regard is ORM's use of data use cases (samples
of required information) to seed the model. For example, concrete instances of data required
from an as-is or to-be library system can be extremely helpful for specifying an initial model.
But this practice requires the use of value-based identifi cation schemes (at least tentative
ones) for the entities involved, an aspect ignored by DEMO.
For the above reasons, ORM appears to provide a useful supplement to DEMO, of-
fering ways to fl esh out state models to complete, executable data models, and providing
further procedures to help in the modeling process itself.
POSSIBLE BENEFITS OF DEMO FOR ORM
ORM is a method for information modeling, in particular for developing conceptual
database schemas. Although ORM can be used to model manual and/or automated informa-
tion systems, it is especially useful for specifying an executable schema for a fully automated
information system (AIS). Because of its data-oriented focus, ORM covers only part of the
scope of a business system (BS). This section investigates what DEMO can add to ORM
in this respect.
The fi rst addition provided by DEMO is the distinction between a BS and an AIS,
which DEMO treats as an automated realization of the I-system discussed earlier (see
