Database Reference
In-Depth Information
CLUB_MEMBER
MemberNumber
MemberName
Phone
Email
LOCKER
LockerNumber
LockerRoom
LockerSize
Figure 5-16
Data Model for the 1:1
Relationship in Figure 5-15
because the relationship line is dashed. Also, the absence of a crow's foot indicates that the
relationship is 1:1.
Regarding minimum cardinality, every club member shown in the form has a locker and
every locker shown in the report is assigned to a club member, so it appears that the relation-
ship is mandatory to mandatory. However, this form and report are just instances; they may
not show every possibility. If the club allows social, nonathletic memberships, then not every
club member will have a locker. Furthermore, it is unlikely that every locker is occupied; there
must be some lockers that are unused and nonallocated. Accordingly, Figure 5-16 shows this
relationship as optional to optional, as indicated by the small circles on the relationship lines.
By ThE Way
How do you recognize strong entities? You can use two major tests. First,
does the entity have an identifier of its own? If it shares a part of its identi-
fier with another entity, then it is an ID-dependent entity and is therefore weak. Second,
does the entity seem to be logically different from and separate from the other entities?
Does it stand alone, or is it part of something else? In this case, a CLUB_MEMBER and
a LOCKER are two very different, separate things; they are not part of each other or of
something else. Hence, they are strong.
Note also that a form or report shows only one side of a relationship. Given entities A
and B, a form can show the relationship from A to B, but it cannot show the relationship
from B to A at the same time. To learn the cardinality from B to A, you must examine a
second form or report, ask the users, or take some other action.
Finally, it is seldom possible to infer minimum cardinality from a form or report.
Generally, you must ask the users.
1:N Strong Entity Relationships
Figure 5-17 shows a form that lists the departments within a company. The company has
many departments, so the maximum cardinality from COMPANY to DEPARTMENT is N. But
what about the opposite direction? To determine if a department relates to one or N compa-
nies, we need to examine a form or report that shows the relationship from a department to
a company. However, assume that no such form or report exists. Also assume that the users
never view company data from the perspective of a department. We cannot ignore the issue
because we need to know whether the relationship is 1:N or N:M.
In such a case, we must ask the users or at least make a determination by thinking about
the nature of the business setting. Can a department belong to more than one company? Is
a department shared among companies? Because this seems unlikely, we can reasonably as-
sume that DEPARTMENT relates to just one COMPANY. Thus, we conclude the relationship is
1:N. Figure 5-18 shows the resulting data model. Note that the many side of the relationship is
indicated by the crow's foot next to DEPARTMENT.
Considering minimum cardinality, we do not know if a COMPANY must have a
DEPARTMENT or if a DEPARTMENT must have a COMPANY. We will definitely need to ask
Search WWH ::
Custom Search