Databases Reference
In-Depth Information
attribute belongs to or refers to another foreign entity. Thus, RENTER*NAME
in RENTAL-AGREEMENT identifies which RENTER is renting the agreement;
and PROPERTY*STREET-ADDRESS, PROPERTY*TOWN-STATE-ADDRESS in
RENTAL-AGREEMENT identifies which PROPERTY is being rented. The use
of an asterisk in Exhibit 1 is for illustration purposes only. Typically, attribute
names do not contain an asterisk.
BEACH-PROPERTY and MOUNTAIN-PROPERTY share a special relation-
ship with PROPERTY, designated by the squared-off arrow connecting the
two to PROPERTY. BEACH-PROPERTY and MOUNTAIN-PROPERTY are each
subtypes of PROPERTY, representing the same real-world object but having
slightly different, more specific definitions and characteristics. They also
contain the foreign key PROPERTY*STREET-ADDRESS, PROPERTY*TOWN-
STATE-ADDRESS, identifying with which PROPERTY each is associated.
Some of the arrows in the diagram are double-headed, and others are
single-headed. The double-headed arrow represents a one-to-many rela-
tionship; for example, one RENTER may rent many RENTAL-AGREEMENTs,
and one PROPERTY may be rented through many different RENTAL-AGREE-
MENTs (although not for the same week). A single-headed arrow repre-
sents a one-to-one relationship-for example, a PROPERTY is listed as a
BEACH-PROPERTY or a MOUNTAIN-PROPERTY, but never as both.
A full data model consists of not only a diagram but specifications in a data
dictionary. For example, although there may be multiple RENTAL-AGREE-
MENTs for the same PROPERTY, they may not be for the same week; or, more
generally, they may not be for overlapping time periods. As mentioned
before, for two RENTAL-AGREEMENTs on the same PROPERTY (i.e., the same
PROPERTY*STREET-ADDRESS, PROPERTY*TOWN-STATE-ADDRESS), the
BEGIN-DATEs must be different (because PROPERTY*STREET-ADDRESS,
PROPERTY*TQWN-STATE-ADDRESS and BEGIN-DATE constitute an entity
identifier that uniquely identifies a RENTAL-AGREEMENT). However, a busi-
ness rule involving END-DATE must also be specified. For example, when a
new occurrence of RENTAL-AGREEMENT is inserted, the END-DATE must
be later than the BEGIN-DATE. Moreover, the END-DATE must precede the
BEGIN-DATEs of all existing RENTAL-AGREEMENTs having a BEGIN-DATE
later than the new RENTAL-AGREEMENT's BEGIN-DATE for RENTAL-
AGREEMENTs for the same property. Otherwise, the rental agreement is
inappropriate and does not make business sense. A database implementa-
tion of the model should reject insertion of such an occurrence.
Such business rules are specifications that preserve the integrity of the
data model by governing which values attributes may assume. True to the
data-driven philosophy, business rules are identified without consider-
ation for exactly how the system will produce reports or enforce edit crite-
ria. For now, the data and all of its relevant rules are analyzed indepen-
dently of information system requirements.
Search WWH ::
Custom Search