Database Reference
In-Depth Information
CLASS
YACHT_DESIGN
HOUSE_MODEL
ClassName
DesignName
ModelName
NumberHours
Description
Description
Length
Beam
NumberStateRooms
NumberHeads
Description
NumberBedrooms
SquareFootage
GarageSize
SECTION
ClassName
SectionNumber
YACHT
DesignName
HullNumber
HOUSE
ModelName
HouseNumber
ClassDays
Time
Professor
LicenseNumber
State
DateManufactured
DateSold
SalesPrice
Street
City
State
Zip
Figure 5-30
Three Archetype/Instance
Pattern Examples
Other examples of archetype/instances are shown in Figure 5-30. One familiar example
concerns classes and sections of classes. The class is the archetype, and the sections of the
class are instances of that archetype. Other examples involve designs and instances of designs.
A yacht manufacturer has various yacht designs, and each yacht is an instance of a particular
design archetype. In a housing development, a contractor offers several different house mod-
els, and a particular house is an instance of that house model archetype.
As with all ID-dependent entities, the parent entity is required. The child entities (here
SECTION, YACHT, and HOUSE) may or may not be required, depending on application
requirements.
Logically, the child entity of every archetype/instance pattern is an ID-dependent entity.
All three of the examples in Figure 5-30 are accurate representations of the logical structure
of the underlying data. However, sometimes users will add additional identifiers to the in-
stance entity and in the process change the ID-dependent entity to a weak entity that is not
ID-dependent.
For example, although you can identify a SECTION by class name and section, colleges
and universities often will add a unique identifier to SECTION, such as ReferenceNumber. In
that case, SECTION is no longer an ID-dependent entity, but it is still existence dependent on
CLASS. Hence, as shown in Figure 5-31, SECTION is weak but not ID-dependent.
A similar change may occur to the YACHT entity. Although the manufacturer of a yacht
may refer to it by specifying the hull number of a given design, the local tax authority may re-
fer to it by State and LicenseNumber. If we change the identifier of YACHT from (HullNumber,
DesignName) to (LicenseNumber, State), then YACHT is no longer ID-dependent; it becomes a
weak, non-ID-dependent entity.
Similarly, although the home builder may think of a home as the third house constructed
according to the Cape Codd design, everyone else will refer to it by its address. When we change
the identifier of HOUSE from (HouseNumber, ModelName) to (Street, City, State, Zip), then
HOUSE becomes a weak, non-ID-dependent entity. All of these changes are shown in Figure 5-31.
By ThE Way
Data modelers continue to debate the importance of weak, non-ID-
dependent entities. Everyone agrees that they exist, but not everyone
agrees that they are important.
First, understand that existence dependence influences the way we write database
applications. For the CLASS/SECTION example in Figure 5-31, we must insert a new
Search WWH ::
Custom Search