Database Reference
In-Depth Information
ORM
Figure 5 shows part of a simplifi ed ORM metaschema for ORM. As for our metaschemas
for IE and Barker ER, we have simplifi ed naming schemes by assuming the metaschema
can be instantiated by just one model at a time (ignoring reuse of model components across
multiple models), and by ignoring namespaces within a model. The populatable types are
object types (e.g., Person, Country), fact types (e.g., Person was born in Country), and roles
(e.g., being born in a country). The main kinds of business rules are constraints (e.g.,
each
Person was born in
at most one
Country), derivation rules (e.g., FactType.arity =
count
each
Role
that
is in FactType), and subtype defi nitions (e.g.,
each
MalePerson
is a
Person
who
is of Gender 'M'). In addition to having surrogate identifi ers, object types have names,
fact types have readings (verbalizations) derived by concatenating object type names with
predicate readings (see later), roles may have names (see later), and business rules have
names and verbalizations.
The subtype defi nitions below the diagram formally defi ne each subtype in terms of
roles played by their supertype. If subtypes collectively exhaust their supertype, this may
be displayed as a circled dot. If subtypes are mutually exclusive, this may be displayed as
a circled “X”. These subtyping completeness and exclusion constraints may be overlaid to
form a “lifebuoy” or partition symbol, as shown. In ORM, such subtyping constraints are
derivable from formal subtype defi nitions and other constraints. Subtypes and derived fact
types should be well defi ned by rules. To save space, some obvious subtype defi nitions may
be omitted from now on.
Figure 5: ORM metaschema fragment for ORM populatable types and business rules
