Making Data Models Readable - High-Performance Web Databases: Design, Development, and Deployment - page 248

Exhibit 16-11. Oracle unique identifiers.

, but this is not part of
the unique identifier, so it does not have the short line crossing the rela-
tionship. Each line is partially solid and partially dashed, according to the
rules for optionality described previously. (Each

Note that is also related to

COURSE OFFERING TEACHER

must be

COURSE OFFERING

related to one and to one , but that each and COURSE TEACHER COURSE TEACHER

may or may not be related to a .)

COURSE OFFERING

IDEF1X, on the other hand, takes a more dramatic approach. If a relation-
ship participates, the entire line is changed from a dashed line to a solid
line, and the entity box so identified is changed from having square corners
to having round corners. The identified entity is considered to be concep-
tually different from those still having the square corners. It is called a
“dependent entity.” An example is shown in Exhibit 12. The relationship
between

and is solid because it is part of

COURSE COURSE OFFERING COURSE OFFER-

's unique identifier, while the relationship between and

ING TEACHER COURSE

is dashed. The round corners for dependence happen if any of its
relationships are identifying.

OFFERING

In addition, IDEF1X describes the unique identifier yet one more time by
using the language of relational database design. Relationships are explic-
itly (if redundantly) shown as foreign keys, identified by “(fk).” The unique
identifier is referred to as a “primary key” and is shown above the line in
the entity box. If the relationship participates in a primary key, the foreign
key implied by the relationship is shown accordingly.

This places great emphasis on the concept of dependence, but it is ques-
tionable whether this is either meaningful to any users viewing the model,
or if it in any way changes the response of system designers, who only