Database Reference
In-Depth Information
Figure 7: Naming of roles, predicates, and fact types in ORM
could be defi ned to be both an entity type and a fact type, or all fact types could be defi ned
to be object types. If an unnested entity type has a simple reference scheme (e.g., Country
has CountryCode), this may be abbreviated by displaying a reference mode (e.g., Code) in
parentheses the object type name. Reference modes may be classifi ed into different kinds to
control the automatic expansion of a reference mode to its underlying relationship type.
Figure 7 shows one way to metamodel naming of fact types, predicates, and roles in
ORM. To save space, derivation rules are omitted. The arity of a fact type is its number of
roles, so it is derivable. ORM fact types may be of any arity: unary (e.g.,
Person smokes
)
,
binary (e.g.,
Person drives Car
), ternary (e.g.,
Person imported Car from Country
), and so
on. As in logic, a predicate corresponds to an ordered set of roles covering a single fact
type; hence each predicate provides one way to traverse the roles of a fact type. Fact types
themselves are essentially unordered, but must have at least one predicate defi ned. Each
predicate is identifi ed by a surrogate identifi er, not by a name, since different predicates may
have the same name (e.g., “has”). Each role is identifi ed by a surrogate identifi er, and also
has a unique position within its predicate. A role may also be given a name (e.g., “player”).
Within a given fact type, the same role name may apply to at most one role (unless the fact
type is declared symmetric; e.g., Person is sibling of Person). Globally the same role name
may appear in different fact types. Roles in the same fact type are co-roles of one another. A
role is a far role of an object type if and only if it has a co-role that is played by that object
type. To ensure that role path specifi cations are unambiguous, we require that for any given
object type, the names of its far roles must be distinct unless the fact type has been declared
symmetric (textual rule 1).
Each fact type may be regarded as an unordered set of roles, with one or more ways to
traverse its roles. For example, given the fact type comprised of the role set {r1, r2, r3}, we
might traverse its roles in the order (r1, r2, r3) or the order (r1, r3, r2), etc. Since a traversal
corresponds to a permutation (or ordered set) of the roles in the fact type, each fact type
with n roles (n > 0) may have up to n! traversals declared by the user. Each such traversal
has at least one reading (we allow multiple readings to cater for aliases). The join-equality
constraint (circled “=”) indicates that the sets of (role, predicate) pairs projected from the
