Database Reference
In-Depth Information
foot is used, and hence use just a single “|” for “exactly one”. In contrast to our convention,
Finkelstein uses the combination “
|” to mean “optional but will become mandatory”, which
is really a dynamic rather than static constraint—this is excluded from our metaschema.
Some IE versions support an
exclusive-or constraint
, shown as a black dot connecting
the alternatives. Figure 1 depicts the situations where each employee holds a citizenship card
or a work visa, but not both. Underlying this example, there are two associations:
Employee
holds CitizenshipCard
;
Employee holds WorkVisa
. The exclusive-or constraint applies to the fi rst
roles of these two associations. Although the roles spanned by this constraint are individu-
ally optional, their disjunction is collectively mandatory. This is misleadingly depicted by a
minimum multiplicity of 1 on the roles at the other end, where the pattern appears as “1 1”
or “1 n”, although it actually means “0 1” or “0 n” individually. This practice prevents the
use of the notation from being adapted to cover simple exclusion constraints.
Our metaschema (see later) assumes predicate readings are allowed after the dot. If
the predicate reading must be displayed before the dot, the xor constraint can apply only
to roles from associations with the same predicate text. In that case, we can't express an
xor constraint such as:
each
Employee drives
a
Car
or
catches
a
Bus
but not both
. This
restriction does not apply to Barker ER, UML, or ORM. In IE (and Barker ER) the same
association role may be spanned by at most one exclusive-or constraint. This restriction
does not apply to ORM or to UML.
Subtyping
schemes for IE vary. Sometimes Euler diagrams are used, adding a blank
Subtyping
compartment for “Other”. Sometimes directed acyclic graphs are used, possibly including
subtype relationship names and multiplicity constraints (e.g., MaleEmployee and FemaleEm-
ployee in Figure 1). There is no formal support for subtype defi nitions. Multiple inheritance
may or may not be supported, depending on the version.
All our metaschemas use the notation of ORM, a conceptual modeling method that
views the world as a set of objects (entities or values) that play roles (parts in relationships,
which may be unary, binary or longer). For example, you are now playing the role of being
awake (a unary relationship involving just you), and also the role of reading this chapter (a
binary relationship between you and this chapter). An entity in ORM corresponds to a non-
lexical object (e.g., a country), and a value to a lexical object (e.g., a country code). A role
in ORM is a part played in an association, which may be unary, binary or
n
-ary. The main
structural difference between ORM and ER or UML is that ORM excludes attributes as a
base construct, treating them instead as a derived concept. For example,
Person.birthdate
is
modeled in ORM using the fact type:
Person was born on Date
. For an overview of ORM see
Halpin (1998a; 1998b), and for a detailed treatment see Halpin (2001a). For an in-depth
discussion of how ORM is implemented in a Microsoft tool, see Halpin, Evans, Hallock,
and MacLean (2003). Many technical discussions of ORM variants are available (e.g., De
Troyer & Meersman, 1995; ter Hofstede, 1993; ter Hofstede, Proper, & Weide, 1993).
An ORM metamodel for IE is shown in Figure 2. Entity types are shown as named ellipses,
and must have a reference scheme, i.e., a way for humans to refer to instances of that type.
Simple reference schemes may be shown in parenthesis (e.g., “
(
name
)
”), as an abbreviation
of the relevant injective association, e.g.,
EntityType
has
EntityTypeName
. Value types need
no reference scheme, and are shown as named, dashed ellipses. A predicate is shown as an
ordered set of one or more role boxes, together with at least one predicate reading. Here we
have two unary associations (e.g.,
Attribute is mandatory
) and several binary associations,
for which readings in both directions may be shown, separated by a slash “/”.
