Page 161 -

146 NGUYEN AND DILLON
Order (number) . . . is made Date (dd/mm/yyyy) . . .
Order (number) . . . is for Customer (ID) . . .
Customer (ID) . . . has Name . . .
Customer (ID) . . . is on Phone (code) . . .
Product (code) . . . has Name . . .
Product (code) . . . has UnitPrice ($) . . .
Order (number) . . . for Product (code) . . . has Quantity (nr+) . . .
(A more stringent standard would require the second-to-last fact type to be written as “Product
(code) . . . has unit price MoneyAmount ($) . . .”)
The third elementary fact type represents a fact or relationship between type Customer and
type Name. Type Customer is an entity type. Its instances are nonlexical objects, and they are
identified by lexical objects IDs. Type Name is a value type. Its instances are lexical objects and
are therefore self-identifying. Every entity type is required to have a reference scheme (e.g., ID
is the reference scheme for Student). The elementary fact types can be graphically represented in
a conceptual schema diagram as shown in Figure 9.2.
A number of constraints can be applied to the elementary fact types, the most important among
them being the uniqueness constraints. These constraints are represented by arrows such as those
shown in Figure 9.2. The arrow over the elementary fact type F1, for example, indicates that a
Customer can have at most one Name. As a more complicated example, the arrow over fact type
F7 (which is broken into two parts) indicates that each combination of Order and Product can
have at most one Quantity.
With the elementary fact types and uniqueness constraints defined, the following simplified
procedure can be applied to map the conceptual schema to a relational schema: (1) First, put in
the same table all the fact types that are attached to the same object with a key of length 1; and
(2) then, put each of the remaining fact types in a separate table.
Applying that procedure, we get the tables:
Customer (ID, Name, Phone)
Product (Code, Name, UnitPrice)
Order (OrderNr, Date, CustomerID)
OrderedQuantity (OrderNr, ProductCode, Quantity)

In addition to the basic concepts above, ORM provides a rich collection of graphical constraints.
Apart from the internal uniqueness constraints that we have seen, there are other constraints such
as: external uniqueness constraints (that apply to more than one fact type), mandatory constraints,
value constraints, frequency constraints, subset constraints, equality constraints, exclusion con-
straints, and so on. Furthermore, due to the availability of the elementary fact types, which allows
us to make well-defined statements, we can express any other static constraints, if we need to, as
predicates in predicate calculus. These are known as textual constraints.
Earlier it was remarked that ORM provides models that are capable of evolving in a stable
manner. As a simple illustration, suppose that in the example above, the price of a product is
determined by contracts the supplier makes with the customers; that is, the price of a product
may vary from customer to customer. Then, all we have to do with the ORM model is to replace
the fact type “Product . . . has UnitPrice . . .” with a ternary fact type “Product . . . for Customer
. . . has UnitPrice . . . .” With an entity-relationship or object-oriented model, we would need to
remove an attribute from the class Product, and add a new class and some relationships to represent