Database Reference
In-Depth Information
VEHICLE has a unique identifier of its own and does not need to be identified by its relation to
AUTO_MODEL.
This is an interesting situation. VEHICLE has an identity of its own and therefore is not
ID-dependent. Yet the VEHICLE is an AUTO_MODEL, and if that particular AUTO_MODEL
did not exist, the VEHICLE itself would never have existed. Therefore, VEHICLE is now a
weak
but non-ID-dependent entity
.
Consider
your
car—let's say it is a Ford Mustang just for the sake of this discussion.
Your individual Mustang is a VEHICLE, and it exists as a physical object and is identified
by the VIN that is required for each licensed automobile. It is
not
ID-dependent on AUTO_
MODEL, which in this case is Ford Mustang, for its identity. However, if the Ford Mustang
had never been created as an AUTO_MODEL—a logical concept that was first designed
on paper—your car would never have been built because
no
Ford Mustangs would ever
have been built! Therefore, your physical individual VEHICLE would not exist without a
logical AUTO_MODEL of Ford Mustang, and in a data model (which
is
what we're talking
about), a VEHICLE cannot exist without a related AUTO_MODEL. This makes VEHICLE
a weak but non-ID-dependent entity. Most data modeling tools cannot model non-ID-
dependent entities. So, to indicate such situations, we will use a nonidentifying relation-
ship with a note added to the data model indicating that the entity is weak, as shown in
Figure 5-11(b).
The ambiguity of the Weak Entity
Unfortunately, an ambiguity is hidden in the definition of a
weak entity
, and this ambiguity is
interpreted differently by different database designers (as well as different textbook authors).
The ambiguity is that in a strict sense, if a weak entity is defined as any entity whose presence
in the database depends on another entity, then any entity that participates in a relationship
having a minimum cardinality of one to a second entity is a weak entity. Thus, in an academic
database, if a STUDENT must have an ADVISER, then STUDENT is a weak entity because a
STUDENT entity cannot be stored without an ADVISER.
This interpretation seems too broad to some people. A STUDENT is not physically de-
pendent on an ADVISER (unlike an APARTMENT to a BUILDING), and a STUDENT is not
logically dependent on an ADVISER (despite how it might appear to either the student or the
adviser), and, therefore, STUDENT should be considered a strong entity.
To avoid such situations, some people interpret the definition of weak entity more
narrowly. They say that to be a weak entity an entity must logically depend on another en-
tity. According to this definition, APARTMENT is a weak entity, but STUDENT is not. An
APARTMENT cannot exist without a BUILDING in which it is located. However, a STUDENT
can logically exist without an ADVISER, even if a business rule requires it.
We agree with the latter approach. Characteristics of ID-dependent and non-ID-
dependent weak entities, as used in this topic, are summarized in Figure 5-12.
Subtype Entities
The extended E-R model introduced the concept of
subtypes
. A
subtype
entity is a special case
of another entity called its
supertype
. Students, for example, may be classified as undergradu-
ate or graduate students. In this case, STUDENT is the supertype, and UNDERGRADUATE
and GRADUATE are the subtypes.
Figure 5-12
Summary of ID-Dependent
and Non-ID-Dependent
Weak Entities
• A weak entity is an entity whose existence depends on another entity.
• An ID-dependent entity is a weak entity whose identifier includes the identifier of
another entity.
• Indentifying relationships are used to represent ID-dependent entities.
• Some entities are weak, but not ID-dependent. Using data modeling tools, they
are shown with nonidentifying relationships, with separate documentation
indicating they are weak.
Search WWH ::
Custom Search