IM Ch04 Entity Relationship Modeling Ed11

Chapter 4 Entity Relationship (ER) Modeling
Chapter 4
Entity-Relationship (ER) Modeling
Discussion Focus
This chapter attempts to present a fairly balanced view of Entity-Relationship Modeling. ne the one
hand! a pragmatic foc"s on the aspects of the ER# that directly impact the design and implementation
of the database m"st be considered. n the other hand! properly doc"menting the b"siness needs that
the database m"st s"pport is e$"ally important. Therefore! we present both Crow%s &oot and Chen
notation ER#s and disc"ss the differences between them. Crow%s &oot tends to be more pragmatic!
while Chen notation has greater semantic content. ne e'ercise that we have fo"nd very val"able for
o"r st"dents is after wor(ing with both notations is to have the st"dents engage in a disc"ssion of the
strengths and wea(nesses of the different notations.
)mong the points of comparison that we foc"s on in class are*
+n both notations! entities are modeled the same.
)ttrib"tes are modeled differently , in ovals with Chen notation and in an attrib"te bo' with
Crow%s &oot.
+dentifiers are modeled the same.
-ingle-val"ed attrib"tes are modeled the same.
Chen notation disting"ishes m"lti-val"ed attrib"tes with a do"ble-line. however! Crow%s &oot
notation does not disting"ish m"lti-val"ed attrib"tes. This can be attrib"ted to the pragmatism
of Crow%s &oot notation , if yo" wo"ldn%t implement the design with a m"lti-val"ed attrib"te!
then don%t draw the design with a m"lti-val"ed attrib"te.
Chen notation disting"ishes derived attrib"tes with a dotted attrib"te line. however Crow%s &oot
notation does not disting"ish derived attrib"tes.
Chen notation commonly "ses specific minim"m and ma'im"m cardinalities. -pecific
minim"m and ma'im"m cardinalities are almost never "sed in practice with Crow%s &oot
notations! which is why in practice most people who "se Crow%s &oot notation refer to
connectivity as ma'im"m cardinality and participation as minim"m cardinality.
/oth notations typically disting"ish wea( entities. however! as a pec"liarity of the M- 0isio
tool! wea( entities are implied thro"gh relationship strength.
-t"dent%s tend to catch on to the notations rather $"ic(ly. however! giving them some simple modeling
tas(s where the data model components (entities! attrib"tes! etc.) are already identified that merely
re$"ire them to apply the notation can be very helpf"l.
ne very important iss"e that often conf"ses st"dents is the resol"tion of M*1 relationships into 2*M
relationships. 3e have "sed Microsoft 0isio 4rofessional to create the ER#s in the te't and in this
man"al. 1ote that ER#s are done at the concept"al level. 5owever! M- 0isio has an implementation
foc"s. Therefore! M*1 relationships are not directly s"pported. +nstead! the designer is limited to
modeling 2*2 and6or 2*M relationships.
77
)ltho"gh M*1 relationships may properly be viewed in a relational database model at the conceptual
level! such relationships should not be implemented! beca"se their e'istence creates "ndesirable
red"ndancies. Therefore! M*1 relationships m"st be decomposed into 2*M relationships to fit into the
ER framewor(. &or e'ample! if yo" were to develop an ER model for a video rental store! yo" wo"ld
note that tapes can be rented more than once and that c"stomers can rent more than one tape.
To ma(e the disc"ssion more interesting and to address several design iss"es at once! e'plain to the
st"dents that it seems reasonable to (eep in mind that newly arrived tapes that have 8"st been entered
into inventory have not yet been rented and that some tapes may never be rented at all if there is no
demand for them. Therefore! C9-TMER is optional to T)4E. )ss"ming that the video store only
rents videos and that a C9-TMER entry will not e'ist "nless a person coming into the video store
act"ally rents that first tape! T)4E is mandatory to C9-TMER. n the other hand! if the store has
other services! s"ch as selling movies or games! then a C9-TMER entry co"ld e'ist witho"t having
rented a video. +n which case! a T)4E is optional to C9-TMER. 1ote that this disc"ssion incl"des a
very brief description of the video store%s operations and some b"siness r"les. The relationship between
c"stomers and tapes wo"ld th"s be M*1! as shown in &ig"re +M4.2.
Figure IM4.1 The M! Relationship
)s yo" disc"ss the presentation in &ig"re +M4.2! note that the ER# reflects two b"siness r"les*
2. ) C9-TMER may rent many T)4Es.
:. ) T)4E can be rented by many C9-TMERs.
The M*1 relationship depicted in &ig"re +M4.2 m"st be bro(en "p into two 2*M relationships thro"gh
the "se of a bridge entity! also (nown as a composite entity. The composite entity! named RE1T); in
the e'ample shown in &ig"re +M4.:! m"st incl"de at least the primary (ey components (C9-<19M
and T)4E<C#E) of the two entities it bridges! beca"se the RE1T); entity=s foreign (eys m"st point
to the primary (eys of the two entities C9-TMER and T)4E.
7>
Figure IM4." Deco#position o$ the M! Relationship
-everal points abo"t &ig"re +M4.: are worth emphasi?ing*
The RE1T); entity=s 4@ co"ld have been the combination T)4E<C#E A C9-<19M. This
composite 4@ wo"ld have created strong relationships between RE1T); and C9-TMER and
between RE1T); and T)4E. /eca"se this composite 4@ was not "sed! it is a candidate (ey.
+n this case! the designer made the decision to "se a single-attrib"te 4@ rather than a composite
4@. 1ote that the RE1T); entity "ses the 4@ RE1T<19M. +t is "sef"l to point o"t that single-
attrib"te 4@s are "s"ally more desirable than composite 4@s , especially when relationships
m"st be established between the RE1T); and some , as yet "nidentified , entity. (Bo" cannot
"se a composite 4@ as a foreign (ey in a related entityC) +n addition! a composite 4@ ma(es
$"eries less efficient , a point that will become clearer in Chapter 22! D#atabase 4erformance
T"ning and E"ery ptimi?ation.F
1ote the placement of the optional symbols. Because a tape that is never rented will never show
up in the RENTAL entity, RENTAL has become optional to TAPE. That%s why the optional
symbol has migrated from C9-TMER to the opposite side of RE1T);. )lso! note the
addition of a few attrib"tes in each of the three entities to ma(e it easier to see what is being
trac(ed.
/eca"se the M*1 relationship has now been decomposed into two 2*M relationships! the ER
model shown in &ig"re +M4.: is can be implemented. 5owever! it may be "sef"l to remind yo"r
st"dents that DimplementableF is not necessarily synonymo"s with DpracticalF or D"sef"l.F
(3e=ll modify the ER# in &ig"re +M4.: after some additional disc"ssion.)
Remind the students that the relationships are read from the 1 side to the M side. Therefore!
the relationships between C9-TMER and RE1T); and between T)4E and RE1T); are
read as
C9-TMER generates RE1T);
T)4E enters RE1T);
(Compare these relationships to those generated by the two b"siness r"les above &ig"re
+M4.2).)
The dashed relationship lines indicate wea( relationships. +n this case! the RE1T); entity=s
primary (ey is RE1T<19M , and this 4@ did not "se any attrib"te from the C9-TMER and
T)4E entities.
The (implied) cardinalities in &ig"re +M4.: reflect the rental transactions. Each rental transaction! i.e.!
each record in the RE1T); table! will reference one and only one c"stomer and one an only one tape.
The (simplifiedC) implementation of this model may th"s yield the sample data shown in the database in
&ig"re +M4.G. The database%s relational diagram is shown in &ig"re +M4.4.
7H
Figure IM4.% The Ch&4'Rental Data(ase Ta(les
The relational diagram that corresponds to the design in &ig"re +M4.: is shown in &ig"re +M 4.4.
Figure IM4.4 The Ch&4'Rental Data(ase Relational Diagra#
>I
The Ch&4'Rental database=s T)4E and RE1T); tables contain some attrib"tes that merit additional
disc"ssion.
The T)4E<C#E attrib"te val"es incl"de a DtrailerF after the dash. &or e'ample! note that the
third record in the T)4E table has a 4@ val"e of R:G4J-:. The DtrailerF indicates the tape copy.
&or e'ample! the D-:F trailer in the 4@ val"e R:G4J-: indicates the second copy of the *nce
9pon a Midnight /ree?yF tape. -o why incl"de a separate T)4E<C4B attrib"teK This
decision was made to ma(e it easier to generate $"eries that ma(e "se of the tape copy val"e.
(+t=s m"ch more diffic"lt to "se a right-string f"nction to DstripF the tape copy val"e than simply
"sing the T)4E<C4B val"e. )nd DsimpleF "s"ally translates into DfastF in a $"ery
environment , DfastF is a good thingC
The RE1T); table "ses two dates* RE1T<#)TE<9T and RE1T<#)TE<RET9R1. This
decision leaves the RE1T<#)TE<RET9R1 val"e n"ll "ntil the tape is ret"rned. 1at"rally!
s"ch n"lls can be avoided by creating an additional table in which the ret"rn date is not a named
attrib"te. 1ote the following few chec(-in and chec(-o"t transactions*
RE!T'!)M TR*!+'T,-E TR*!+'D*TE
2IIJI Chec(ed-o"t 2I-Lan-:I24
2IIJI Ret"rned 22-Lan-:I24
2IIJ2 Chec(ed-o"t 2I-Lan-:I24
2IIJ2 Ret"rned 22-Lan-:I24
2IIJ: Chec(ed-o"t 22-Lan-:I24
2IIJG Ret"rned 2I-Lan-:I24
... ..... .....
... ..... .....
The decision to leave the RE1T<#)TE<RET9R1 date in the RE1T); table , and leaving its
val"e n"ll "ntil the tape is ret"rned is ,again , "p to the designer! who eval"ates the design
according to often competing goals* simplicity! elegance! reporting capability! $"ery speed!
inde' management! and so on. (Remind yo"r st"dents that they! too! sho"ld be able to eval"ate
s"ch decisions as they gain database design (nowledge.)
Discuss /ith your students that Figure IM4.40s data(ase is not 1uite ready $or pri#e ti#e. &or
e'ample! its str"ct"re allows c"stomers to rent only one tape per rental transaction. Therefore! yo"%d
have to generate a separate rental transaction for each tape rented by a c"stomer. (+n other words! if a
c"stomer rents five tapes at a time! yo"%d have to generate five separate rentals.) Clearly! the design
wo"ld be m"ch improved by e'panding it to incl"de rental lines! as is done in &ig"re +M4.J.
>2
Figure IM4.2 I#ple#enta(le 3ideo Rental ERD
!4TE
*s you discuss the ERDs in Figure IM4.25 note the use o$ optionalities. For e6a#ple5 a tape #ay
(e in the rental in7entory5 (ut there is no guarantee that any custo#er /ill e7er rent it. In
short5 a tape that has ne7er (een rented /ill not sho/ up in any rental transaction5 thus ne7er
appearing in a RE!T'8I!E entity. There$ore5 RE!T'8I!E is optional to T*-E.
9enerally5 i$ a relationship has not (een de$ined as #andatory or cannot reasona(ly (e
assu#ed to (e #andatory5 it is considered to (e optional.
:hat role does the ER diagra# play in the design process;
) completed ER diagram is the act"al bl"eprint of the database. +ts composition m"st reflect an
organi?ation%s operations acc"rately if the database is to meet that organi?ation%s data re$"irements. +t
forms the basis for a final chec( on whether the incl"ded entities are appropriate and s"fficient! on the
attrib"tes fo"nd within those entities! and on the relationships between those entities. +t is also "sed as a
final crosschec( against the proposed data dictionary entries. The completed ER diagram also lets the
designer comm"nicate more precisely with those who commissioned the database design. &inally! the
completed ER diagram serves as the implementation g"ide to those who create the act"al database. +n
short! the ER diagram is as important to the database designer as a bl"eprint is to the architect and
b"ilder.
>:
*ns/ers to Re7ie/ <uestions
1. :hat t/o conditions #ust (e #et (e$ore an entity can (e classi$ied as a /ea= entity; 9i7e an
e6a#ple o$ a /ea= entity.
To be classified as a wea( entity! two conditions must be met*
2. The entity m"st be e'istence-dependent on its parent entity.
:. The entity m"st inherit at least part of its primary (ey from its parent entity.
&or e'ample! the (strong) relationship depicted in the te't=s &ig"re 4.2I shows a wea( C;)--
entity*
2. C;)-- is clearly e'istence-dependent on C9R-E. (Bo" can=t have a database class "nless a
database co"rse e'ists.)
:. The C;)-- entity=s 4@ is defined thro"gh the combination of C;)--<-ECT+1 and
CR-<C#E. The CR-<C#E attrib"te is also the 4@ of C9R-E.
The conditions that define a wea( entity are the same as those for a strong relationship between an
entity and its parent. +n short! the e'istence of a wea( entity prod"ces a strong relationship. )nd if
the entity is strong! its relationship to the other entity is wea(. (1ote the solid relationship line in the
te't=s &ig"re 4.2I.)
@eep in mind that whether or not an entity is wea( "s"ally depends on the database designer=s
decisions. &or instance! if the database designer had decided to "se a single-attrib"te as shown in
the te't=s &ig"re 4.>! the C;)-- entity wo"ld be strong. (The C;)-- entity=s 4@ is
C;)--<C#E! which is not derived from the C9R-E entity.) +n this case! the relationship
between C9R-E and C;)-- is wea(. (1ote the dashed relationship line in the te't=s &ig"re 4.>.)
>o/e7er5 regardless o$ ho/ the designer classi$ies the relationship ? /ea= or strong ? C8*++
is al/ays e6istence-dependent on C4)R+E.
". :hat is a strong (or identi$ying) relationship5 and ho/ is it depicted in a Cro/@s Foot ERD;
) strong relationship e'ists when en entity is e'istence-dependent on another entity and inherits at
least part of its primary (ey from that entity. The 0isio 4rofessional software shows the strong
relationship as a solid line. +n other words! a strong relationship e'ists when a wea( entity is related
to its parent entity. (1ote the disc"ssion in $"estion 2.)
>G
%. 9i7en the (usiness rule Aan e#ployee #ay ha7e #any degrees5B discuss its e$$ect on
attri(utes5 entities5 and relationships. (Hint Re#e#(er /hat a #ulti7alued attri(ute is and
ho/ it #ight (e i#ple#ented.)
-"ppose that an employee has the following degrees* /)! /-! and M/). These degrees co"ld be
stored in a single string as a m"ltival"ed attrib"te named EM4<#EMREE in an EM4;BEE table
s"ch as the one shown ne't*
EM-'!)M EM-'8!*ME EM-'DE9REE
2:G Carter ))! //)
2:4 =-hans(i //)! M/)! 4h.#.
2:J Lones )-
2:N rte? /-! M-
)ltho"gh the preceding sol"tion has no obvio"s design flaws! it is li(ely to yield reporting
problems. &or e'ample! s"ppose yo" want to get a co"nt for all employees who have //) degrees.
Bo" co"ld! of co"rse! do an Din-stringF search to find all of the //) val"es within the
EM4<#EMREE strings. /"t s"ch a sol"tion is c"mbersome from a reporting point of view. E"ery
simplicity is a val"able thing to application developers , and to end "sers who li(e ma'im"m $"ery
e'ec"tion speeds. #atabase designers o"ght to pay some attention to the competing database
interests that e'ist in the data environment.
ne , very poor , sol"tion is to create a field for each e'pected val"e. This Dsol"tion is shown ne't*
EM-'!)M EM-'8!*ME EM-'DE9REE1 EM-'DE9REE" EM-'DE9REE%
2:G Carter )) //)
2:4 =-hans(i //) M/) 4h.#.
2:J Lones )-
2:N rte? /- M-
This Dsol"tion yields n"lls for all employees who have fewer than three degrees. )nd if even one
employee earns a fo"rth degree! the table str"ct"re m"st be altered to accommodate the new data
val"e. (ne piece of evidence of poor design is the need to alter table str"ct"res in response to the
need to add data of an e'isting type.) +n addition! the $"ery simplicity is not enhanced by the fact
that any degree can be listed in any col"mn. &or e'ample! a /) degree might be listed in the second
col"mn! after an Dassociate of arts ())) degree has been entered in EM4<#EMREE2. ne might
simplify the $"ery environment by creating a set of attrib"tes that define the data entry! th"s
prod"cing the following res"lts*
EM-'!)M EM-'8!*ME EM-'** EM-'*+ EM-'C* EM-'C+ EM-'CC* EM-'M+ EM-'MC* EM-'-hD
2:G Carter O O
2:4 =-hans(i O O O
2:J Lones O
2:N rte? O O
This Dsol"tionF clearly proliferates the n"lls at an ever-increasing pace.
>4
The only reasonable sol"tion is to create a new #EMREE entity that stores each degree in a separate
record! this prod"cing the following tables. (There is a 2*M relationship between EM4;BEE and
#EMREE. 1ote that the EM4<19M can occ"r more than once in the #EMREE table. The
#EMREE table=s 4@ is EM4<19M A #EMREE<C#E. This sol"tion also ma(es it possible to
record the date on which the degree was earned! the instit"tion from which it was earned! and so on.
Ta(le na#e EM-84,EE
EM-'!)M EM-'8!*ME
2:G Carter
2:4 =-hans(i
2:J Lones
2:N rte?
Ta(le na#e DE9REE
EM-'!)M DE9REE'C4DE DE9REE'D*TE DE9REE'-8*CE
2:G )) May-2HHH ;a(e -"mter CC
2:G //) )"g-:II4 9. of Meorgia
2:4 //) #ec-2HHI 9. of Toledo
2:4 M/) May-:II2 9. of Michigan
2:4 4h.#. #ec-:IIJ 9. of Tennessee
2:J )- )"g-:II: 0aldosta -tate
2:N /- #ec-2H>H 9. of Misso"ri
2:N M- May-:II: 9. of &lorida
1ote that this sol"tion leaves no n"lls! prod"ces a simple $"ery environment! and ma(es it
"nnecessary to alter the table str"ct"re when employees earn additional degrees. (Bo" can ma(e the
environment even more fle'ible by naming the new entity E9);+&+C)T+1! th"s ma(ing it
possible to store degrees! certifications! and other "sef"l data that define an employee=s
$"alifications.)
4. :hat is a co#posite entity5 and /hen is it used;
) composite entity is generally "sed to transform M*1 relationships into 2*M relationships.
(Review the disc"ssion that accompanied &ig"res +M4.G thro"gh +M4.J.) ) composite entity! also
(nown as a bridge entity! is one that has a primary (ey composed of m"ltiple attrib"tes. The 4@
attrib"tes are inherited from the entities that it relates to one another.
>J
2. +uppose you are /or=ing /ithin the $ra#e/or= o$ the conceptual #odel in Figure <4.2.
Figure <4.2 The Conceptual Model $or <uestion 2
9i7en the conceptual #odel in Figure <4.2
a. :rite the (usiness rules that are re$lected in it.
Even a simple ER# s"ch as the one shown in &ig"re E4.J is based on many b"siness r"les.
Ma(e s"re that each b"siness r"le is written on a separate line and that all of its details are
spelled o"t. +n this case! the b"siness r"les are derived from the ER# in a Dreverse-
engineeringF proced"re designed to doc"ment the database design. +n a real world database
design sit"ation! the ER# is generated on the basis of b"siness r"les that are written before the
first entity bo' is drawn. (Remember that the b"siness r"les are derived from a caref"lly and
precisely written description of operations.)
Miven the ER# shown in &ig"re E4.J! yo" can identify the following b"siness r"les*
2. ) c"stomer can own many cars.
:. -ome c"stomers do not own cars.
G. ) car is owned by one and only one c"stomer.
4. ) car may generate one or more maintenance records.
J. Each maintenance record is generated by one and only one car.
N. -ome cars have not (yet) generated a maintenance proced"re.
7. Each maintenance proced"re can "se many parts.
(Comment* ) maintenance proced"re may incl"de m"ltiple maintenance actions!
each one of which may or may not "se parts. &or e'ample! 2I!III-mile chec(
may incl"de the installation of a new oil filter and a new air filter. /"t tightening
an alternator belt does not re$"ire a part.)
>. ) part may be "sed in many maintenance records.
(Comment* Each time an oil change is made! an oil filter is "sed. Therefore! many
oil filters may be "sed d"ring some period of time. 1at"rally! yo" are not "sing
the same oil filter each time , b"t the part classified as Doil filterF shows "p in
many maintenance records as time passes.)
>N
1ote that the apparent M*1 relationship between M)+1TE1)1CE and 4)RT
has been resolved thro"gh the "se of the composite entity named M)+1T<;+1E.
The M)+1T<;+1E entity ens"res that the M*1 relationship between
M)+1TE1)1CE and 4)RT has been bro(en "p to prod"ce the two 2*M
relationships shown in b"siness r"les H and 2I.
H. Each maintenance proced"re generates one or more maintenance lines.
2I. Each part may appear in many maintenance lines. (Review the comment in
b"siness r"le >.)
)s yo" review the b"siness r"les H and 2I! "se the following two tables to show some sample
data entries. &or e'ample! ta(e a loo( at the (simplified) contents of the following
M)+1TE1)1CE and ;+1E tables and note that the M)+1T<19M 2III2 occ"rs three times
in the ;+1E table*
+a#ple M*I!TE!*!CE Ta(le Data
M*I!T'!)M M*I!T'D*TE
2III2 2J-Mar-:I24
2III: 2J-Mar-:I24
2IIIG 2N-Mar-:I24
+a#ple 8I!E Ta(le Data
M*I!T'!)M 8I!E'!)M 8I!E'DE+CRI-TI4! 8I!E'-*RT 8I!E')!IT+
2III2 2 Replace f"el filter &&-I2J 2
2III2 : Replace air filter )&-22>7 2
2III2 G Tighten alternator belt 1) I
2III: 2 Replace taillight b"lbs /9-:24J :
2IIIG 2 Replace oil filter &-:22G 2
2IIIG : Replace air filter )&-22>7 2
b. Identi$y all o$ the cardinalities.
The 0isio-generated Crow=s &oot ER#! shown in &ig"re E4.J! does not show cardinalities
directly. +nstead! the cardinalities are implied thro"gh the Crow=s &oot symbols. Bo" might write
the cardinality (I!1) ne't to the M)+1T<;+1E entity in its relationship with the 4)RT entity to
indicate that a part might occ"r D1F times in the maintenance line entity or that it might never
show "p in the maintenance line entity. The latter case wo"ld occ"r if a given part has never
been "sed in maintenance.
D. :hat is a recursi7e relationship; 9i7en an e6a#ple.
) rec"rsive relationship e'ists when an entity is related to itself. &or e'ample! a C9R-E may be a
prere$"isite to a C9R-E. (-ee -ection 4.2.2I! DRec"rsive Relationships!F for additional
e'amples.
>7
E. >o/ /ould you (graphically) identi$y each o$ the $ollo/ing ERM co#ponents in a Cro/@s
Foot #odel;
The answers to $"estions (a) thro"gh (d) are ill"strated with the help of &ig"re E4.7.
FI9)RE <4.E Cro/@s Foot ERM Co#ponents
a. an entity
)n entity is represented by a rectangle containing the entity name. (Remember that! in ER
modeling! the word PentityP act"ally refers to the entity set.)
The Crow=s &oot ER# , as represented in 0isio 4rofessional , does not disting"ish among the
vario"s entity types s"ch as wea( entities and composite entities. +nstead! the Crow=s &oot ER#
"ses relationship types , strong or wea( , to indicate the nat"re of the relationships between
entities. &or e'ample! a strong relationship indicates the e'istence of a wea( entity.
) composite entity is defined by the fact that at least one of the 4@ attrib"tes is also a foreign
(ey. Therefore! the 0isio Crow=s &oot ER#=s composite and wea( entities are not differentiated
, whether or not an entity is wea( or composite depends on the definition of the b"siness r"le(s)
that describe the relationships. +n any case! two conditions m"st be met before an entity can be
classified as wea(*
2. The entity m"st be e'istence-dependent on its parent entity
:. The entity m"st inherit at least part of its primary (ey from its parent entity.
>>
(. the cardinality (&5!)
Cardinalities are implied thro"gh the "se of Crow=s &oot symbols. &or e'ample! note the
implied (I!1) cardinality in &ig"re E4.7.
c. a /ea= relationship
) wea( relationship e'ists when the 4@ of the related entity does not contain at least one of the
4@ attrib"tes of the parent entity. &or e'ample! if the 4@ of a C9R-E entity is CR-<C#E
and the 4@ of the related C;)-- entity is C;)--<C#E! the relationship between C9R-E
and C;)-- is wea(. (1ote that the C;)-- 4@ does not incl"de the CR-<C#E attrib"te.) )
wea( relationship is indicated by a dashed line in the (0isio) ER#.
d. a strong relationship
) strong relationship e'ists when the 4@ of the related entity contains at least one of the 4@
attrib"tes of the parent entity. &or e'ample! if the 4@ of a C9R-E entity is CR-<C#E and
the 4@ of the related C;)-- entity is CR-<C#E A C;)--<-ECT+1! the relationship
between C9R-E and C;)-- is strong. (1ote that the C;)-- 4@ incl"des the CR-<C#E
attrib"te.) ) strong relationship is indicated by a solid line in the (0isio) ER#.
F. Discuss the di$$erence (et/een a co#posite =ey and a co#posite attri(ute. >o/ /ould each (e
indicated in an ERD;
) composite (ey is one that consists of more than one attrib"te. +f the ER diagram contains the
attrib"te names for each of its entities! a composite (ey is indicated in the ER diagram by the fact
that more than one attrib"te name is "nderlined to indicate its participation in the primary (ey.
) composite attrib"te is one that can be s"bdivided to yield meaningful attrib"tes for each of its
components. &or e'ample! the composite attrib"te C9-<1)ME can be s"bdivided to yield the
C9-<&1)ME! C9-<+1+T+);! and C9-<;1)ME attrib"tes. There is no ER convention that
enables "s to indicate that an attrib"te is a composite attrib"te.
G. :hat t/o courses o$ action are a7aila(le to a designer /hen encountering a #ulti7alued
attri(ute;
The disc"ssion that accompanies the answer to $"estion G is valid as an answer to this $"estion.
1&. :hat is a deri7ed attri(ute; 9i7e an e6a#ple.
) derived attrib"te is an attrib"te whose val"e is calc"lated (derived) from other attrib"tes. The
derived attrib"te need not be physically stored within the database. instead! it can be derived by
"sing an algorithm. &or e'ample! an employee=s age! EM4<)ME! may be fo"nd by comp"ting the
integer val"e of the difference between the c"rrent date and the EM4<#/. +f yo" "se M- )ccess!
yo" wo"ld "se +1T((#)TE() , EM4<#/)6GNJ).
-imilarly! a sales cler(%s total gross pay may be comp"ted by adding a comp"ted sales commission
>H
to base pay. &or instance! if the sales cler(%s commission is 2Q! the gross pay may be comp"ted by
EM4<MR--4)B R +10<-);E-S2.I2 A EM4</)-E4)B
r the invoice line item amo"nt may be calc"lated by
;+1E<TT); R ;+1E<91+T-S4R#<4R+CE
11. >o/ is a relationship (et/een entities indicated in an ERD; 9i7e an e6a#ple5 using the
Cro/@s Foot notation.
9se &ig"re E4.7 as the basis for yo"r answer. 1ote the distinction between the dashed and solid
relationship lines! then tie this distinction to the answers to $"estion 7c and 7d.
1". Discuss t/o /ays in /hich the 1M relationship (et/een C4)R+E and C8*++ can (e
i#ple#ented. (Hint Thin= a(out relationship strength.)
1ote the disc"ssion abo"t wea( and strong entities in $"estions 7c and 7d. Then follow "p with this
disc"ssion*
The relationship is implemented as strong when the C;)-- entity=s 4@ contains the C9R-E
entity=s 4@. &or e'ample!
C9R-E(CR+'C4DE! CR-<T+T;E! CR-<#E-CR+4T+1! CR-<CRE#+T-)
C;)--(CR+'C4DE! C8*++'+ECTI4!! C;)--<T+ME! C;)--<4;)CE)
1ote that the C;)-- entity=s 4@ is CR-<C#E A C;)--<-ECT+1 , and that the CR-<C#E
component of this 4@ has been DborrowedF from the C9R-E entity. (/eca"se C;)-- is
e'istence-dependent on C9R-E and "ses a 4@ component from its parent (C9R-E) entity! the
C;)-- entity is wea( in this strong relationship between C9R-E and C;)--. The 0isio Crow=s
&oot ER# shows a strong relationship as a solid line. (-ee &ig"re E4.2:a.) 0isio refers to a strong
relationship as an identifying relationship.
Figure <4.1"a +trong C4)R+E and C8*++ Relationship
HI
-ample data are shown ne't*
Ta(le na#e C4)R+E
CR+'C4DE CR+'TIT8E CR+-DE+CRI-TI4! CR+'CREDIT+
)CCT-:22 /asic )cco"nting )n introd"ction to acco"nting. Re$"ired of all
b"siness ma8ors.
G
C+--G>I #atabase Techni$"es + #atabase design and implementation iss"es. 9ses
C)-E tools to generate designs that are then
implemented in a ma8or database management
system.
G
C+--4HI #atabase Techni$"es ++ The second half of C+--G>I. /asic 3eb database
application development and management iss"es.
4
Ta(le na#e C8*++
CR+'C4DE C8*++'+ECTI4! C8*++'TIME C8*++'-8*CE
)CCT-:22 2 >*II a.m. , H*GI a.m. T-Th. /"siness G:J
)CCT-:22 : >*II a.m. , >*JI a.m. M3& /"siness G:J
)CCT-:22 G >*II a.m. , >*JI a.m. M3& /"siness 4I:
C+--G>I 2 22*II a.m. , 22*JI a.m. M3& /"siness 42J
C+--G>I : G*II p.m. , G*JI a.m. M3& /"siness GH>
C+--4HI 2 2*II p.m. , G*II p.m. M3 /"siness GH>
C+--4HI : N*II p.m. , 2I*II p.m. Th. /"siness GH>
The relationship is implemented as wea when the C;)-- entity=s 4@ does not contain the
C9R-E entity=s 4@. &or e'ample!
C9R-E(CR+'C4DE! CR-<T+T;E! CR-<#E-CR+4T+1! CR-<CRE#+T-)
C;)--(C8*++'C4DE! CR-<C#E! C;)--<-ECT+1! C;)--<T+ME! C;)--<4;)CE)
(1ote that CR-<C#E is no longer part of the C;)-- 4@! b"t that it contin"es to serve as the &@
to C9R-E.)
The 0isio Crow=s &oot ER# shows a wea( relationship as a dashed line. (-ee &ig"re E4.2:b.) 0isio
refers to a wea( relationship as a non!identifying relationship.
Figure <4.1"( :ea= C4)R+E and C8*++ Relationship
H2
Miven the wea( relationship depicted in &ig"re E4.2Gb! the C;)-- table contents wo"ld loo( li(e
this*
Ta(le na#e C8*++
C8*++'C4DE CR+'C4DE C8*++'+ECTI4! C8*++'TIME C8*++'-8*CE
:22J2 )CCT-:22 2 >*II a.m. , H*GI a.m. T-Th. /"siness G:J
:22J: )CCT-:22 : >*II a.m. , >*JI a.m. M3& /"siness G:J
:22JG )CCT-:22 G >*II a.m. , >*JI a.m. M3& /"siness 4I:
G>I42 C+--G>I 2 22*II a.m. , 22*JI a.m. M3& /"siness 42J
G>I4: C+--G>I : G*II p.m. , G*JI a.m. M3& /"siness GH>
4HI42 C+--4HI 2 2*II p.m. , G*II p.m. M3 /"siness GH>
4HI4: C+--4HI : N*II p.m. , 2I*II p.m. Th. /"siness GH>
The advantage of the second C;)-- entity version is that its 4@ can be referenced easily as a &@ in
another related entity s"ch as E1R;;. 9sing a single-attrib"te 4@ ma(es implementation easier.
This is especially tr"e when the entity represents the D2F side in one or more relationships. In
general5 it is ad7isa(le to a7oid co#posite -Hs /hene7er it is practical to do so.
1%. >o/ is a co#posite entity represented in an ERD5 and /hat is its $unction; Illustrate the
Cro/@s Foot #odel.
The label PcompositeP is based on the fact that the composite entity contains at least the primary
(ey attrib"tes of each of the entities that are connected by it. The composite entity is an important
component of the ER model beca"se relational database models sho"ld not contain M*1
relationships , and the composite entity can be "sed to brea( "p s"ch relationships into 2*M
relationships.
Remind st"dents to heed the advice given in the answer to the previo"s $"estion. That is! a7oid
co#posite -Hs /hene7er it is practical to do so. 1ote that the C;)-- entity str"ct"re shown in
&ig"re E4.2:b is far better than that of the C;)-- entity str"ct"re shown in &ig"re E4.2:a.
-"ppose! for e'ample! that yo" want to design a class enrollment entity to serve as the DbridgeF
between -T9#E1T and C;)-- in the M*1 relationship defined by these two b"siness r"les*
) st"dent can ta(e many classes.
Each class can be ta(en by many st"dents.
+n this case! yo" co"ld create a (composite) entity named E1R;; to lin( C;)-- and -T9#E1T!
"sing these str"ct"res*
-T9#E1T(+T)'!)M! -T9<;1)ME TTTT..)
E1R;;(+T)'!)M! C8*++'!)M! E1R;;<MR)#E TTT)
C;)--(C8*++'C4DE! CR-<C#E! C;)--<-ECT+1! C;)--<T+ME! C;)--<4;)CE)
Bo"r st"dents might arg"e that a composite 4@ in E1R;; does no harm! since it is not li(ely to
be related to another entity in the typical academic database setting. )ltho"gh that is a good
observation! yo" wo"ld r"n into a problem in the event that might trigger a re$"ired relationship
between E1R;; and another entity. +n any case! yo" may simplify the creation of f"t"re
H:
relationships if yo" create an DartificialF single-attrib"te 4@ s"ch as E1R;;<19M! while
maintaining the -T9<19M and C;)--<19M as &@ attrib"tes. +n other words*
E1R;;(E!R488'!)M! -T9<19M! C;)--<19M! E1R;;<MR)#E TTT)
The E1R;;<19M attrib"te val"es can easily be generated thro"gh the proper "se of -E; code
or application software! th"s eliminating the need for data entry by h"mans.
The "se of composite vs. single-attrib"te 4@s is worth disc"ssing. Composite 4@s are fre$"ently
enco"ntered in composite entities and yo"r st"dents will see that M- 0isio will generate composite
4@s a"tomatically when yo" classify a relationship as strong. Composite 4@s are not DwrongF is
any sense! b"t minimi?ing their "se does ma(e the implementation of m"ltiple relationships simple
T -imple is generally a good thingC
HG
!4TE
Cecause co#posite entities are $re1uently encountered in the real /orld en7iron#ent5 /e
continue to use the# in the te6t and in #any o$ our e6ercises and e6a#ples. >o/e7er5 the
/ords o$ caution a(out their use should (e repeated $ro# ti#e to ti#e and you #ight as=
your students to con7ert such co#posite entities.
;et=s e'amine another e'ample of the "se of composite entities. -"ppose that a tr"c(ing company
(eeps a log of its tr"c(ing operations to (eep trac( of its driver6tr"c( assignments. The company
may assign any given tr"c( to any given driver many times and! as time passes! each driver may be
assigned to drive many of the company%s tr"c(s. -ince this M*1 relationship sho"ld not be
implemented! we create the composite entity named ;M whose attrib"tes are defined by the end-
"ser information re$"irements. +n this case! it may be "sef"l to incl"de ;M<#)TE!
TR9C@<19M! #R+0ER<19M! ;M<T+ME<9T! and ;M<T+ME<+1.
1ote that the ;M%s TR9C@<19M and #R+0ER<19M attrib"tes are the driver ;M%s foreign
(eys. The TR9C@<19M and #R+0ER<19M attrib"te val"es provide the bridge between the
TR9C@ and #R+0ER! respectively. +n other words! to form a proper bridge between TR9C@ and
#R+0ER! the composite ;M entity m"st contain at least the primary (eys of the entities connected
by it.
Bo" might thin( that the combination of the composite entity=s foreign (eys may be designated to
be the composite entity%s primary (ey. 5owever! this combination will not prod"ce "ni$"e val"es
over time. &or e'ample! the same driver may drive a given tr"c( on different dates. )dding the date
to the 4@ attrib"tes will solve that problem. /"t we still have a non-"ni$"e o"tcome when the same
driver drives a given tr"c( twice on the same date. )dding a time attrib"te will finally create a
"ni$"e set of 4@ attrib"te val"es , b"t the 4@ is now composed of fo"r attrib"tes* TR9C@<19M!
#R+0ER<19M! ;M<#)TE! and ;M<T+ME<9T. (The combination of these attrib"tes yields
a "ni$"e o"tcome! beca"se the same driver cannot chec( o"t two tr"c(s at the same time on a given
date.)
Cecause #ulti-attri(ute -Hs #ay (e di$$icult to #anage5 it is o$ten ad7isa(le to create an
Aarti$icialB single-attri(ute -H5 such as 849'!)M5 to uni1uely identi$y each record in the
849 ta(le. ()ccess "sers can define s"ch an attrib"te to be an Da"ton"mberF to ens"re that the
system will generate "ni$"e ;M<19M val"es for each record.) 1ote that this sol"tion prod"ces a
;M table that contains two candidate (eys* the designated primary (ey and the combination of
foreign (eys that could have served as the primary (ey.
H4
3hile the preceding sol"tion simplifies the 4@ definition! it does not prevent the creation of
d"plicate records that merely have a different ;M<19M val"e. 1ote! for e'ample! the first two
records in the following table*
849'!)M 849'D*TE TR)CH'!)M DRI3ER'!)M 849'TIME'4)T 849'TIME'I!
2II2J 2:-Mar-:I24 G::4JG 2:2J I7*2> a.m. I4*:G p.m.
2II2N 2:-Mar-:I24 G::4JG 2:2J I7*2> a.m. I4*:G p.m.
2II27 2:-Mar-:I24 J4JJN7 2:H> I>*2: a.m. IH*2J p.m.
To avoid s"ch d"plicate records! you can create a uni1ue inde6 on TR9C@<19M A
#R+0ER<19M A ;M<#)TE A ;M<T+ME<9T.
Composite entities may be named to reflect their component entities. &or e'ample! an employee
may have several ins"rance policies (life! dental! accident! health! etc.) and each ins"rance policy
may be held by many employees. This M*1 relationship is converted to a set of two 2*M
relationships! by creating a composite entity named EM4<+1-. The EM4<+1- entity m"st contain
at least the primary (ey components of each of the two entities connected by it. 5ow many
additional attrib"tes are (ept in the composite entity depends on the end-"ser information
re$"irements.
14. :hat three (o$ten con$licting) data(ase re1uire#ents #ust (e addressed in data(ase design;
#atabase design m"st reconcile the following re$"irements*
a. #esign elegance re$"ires that the design m"st adhere to design r"les concerning n"lls! derived
attrib"tes! red"ndancies! relationship types! and so on.
b. +nformation re$"irements are dictated by the end "sers
c. perational (transaction) speed re$"irements are also dictated by the end "sers.
Clearly! an elegant database design that fails to address end "ser information re$"irements or one
that forms the basis for an implementation whose "se progresses at a snail%s pace has little practical
"se.
12. Crie$ly5 (ut precisely5 e6plain the di$$erence (et/een single-7alued attri(utes and si#ple
attri(utes. 9i7e an e6a#ple o$ each.
) single -val"ed attrib"te is one that can have only one val"e. &or e'ample! a person has only one
first name and only one social sec"rity n"mber.
) simple attrib"te is one that cannot be decomposed into its component pieces. &or e'ample! a
person%s se' is classified as either M or & and there is no reasonable way to decompose M or &.
-imilarly! a person%s first name cannot be decomposed into meaningf"l components. (+n contrast! if
a phone n"mber incl"des the area code! it can be decomposed into the area code and the phone
n"mber. )nd a person%s name may be decomposed into a first name! an initial! and a last name.)
+ingle-7alued attri(utes are not necessarily si#ple. &or e'ample! an inventory code
534R+L:G24J may refer to a classification scheme in which 53 indicates 5ardware! 4R indicates
4rinter! +L indicates +n(8et! and :G24J indicates an inventory control n"mber. Therefore!
HJ
534R+L:G24J may be decomposed into its component parts... even tho"gh it is single-val"ed. To
facilitate prod"ct trac(ing! man"fact"ring serial codes m"st be single-val"ed! b"t they may not be
simple. &or instance! the prod"ct serial n"mber T14J-:M:G22IH2J4G:2 might be decomposed this
way*
T1 R state R Tennessee
4J R plant n"mber J
-: R shift :
M:G R machine :G
22 R month! i.e.! 1ovember
IH R day
2J4G:2 R time on a :4-ho"r cloc(! i.e.! 2J*4G*:2! or G*4G p.m. pl"s :2 seconds.
1D. :hat are #ulti7alued attri(utes5 and ho/ can they (e handled /ithin the data(ase design;
The answer to $"estion G is 8"st as valid as an answer to this $"estion. Bo" can a"gment that
disc"ssion with the following disc"ssion*
)s the name implies! m"lti-val"ed attrib"tes may have many val"es. &or e'ample! a person%s
ed"cation may incl"de a high school diploma! a :-year college associate degree! a fo"r-year college
degree! a Master%s degree! a #octoral degree! and vario"s professional certifications s"ch as a
Certified 4"blic )cco"nting certificate or a Certified #ata 4rocessing Certificate.
There are basically three ways to handle m"lti-val"ed attrib"tes -- and two of those three ways are
bad*
2. Each of the possible o"tcomes is (ept as a separate attrib"te within the table. This
sol"tion is "ndesirable for several reasons. &irst! the table wo"ld generate many n"lls for
those who had minimal ed"cational attainments. 9sing the preceding e'ample! a person
with only a high school diploma wo"ld generate n"lls for the :-year college associate
degree! the fo"r-year college degree! the Master%s degree! the #octoral degree! and for
each of the professional certifications. +n addition! how many professional certification
attrib"tes sho"ld be maintainedK +f yo" store two professional certification attrib"tes!
yo" will generate a n"ll for someone with only one professional certification and yo"%d
generate two n"lls for all persons witho"t professional certifications. )nd s"ppose yo"
have a person with five professional certificationsK 3o"ld yo" create additional
attrib"tes! th"s creating many more n"lls in the table! or wo"ld yo" simply ignore the
additional professional certifications! thereby losing informationK
:. The ed"cational attainments may be (ept as a single! variable-length string or character
field. This sol"tion is "ndesirable beca"se it becomes diffic"lt to $"ery the table. &or
e'ample! even a simple $"estion s"ch as Phow many employees have fo"r-year college
degreesKP re$"ires string partitioning that is time-cons"ming at best. f co"rse! if there
is no need to ever gro"p employees by ed"cation! the variable-length string might be
acceptable from a design point of view. 5owever! as database designers we (now that!
sooner or later! information re$"irements are li(ely to grow! so the string storage is
probably a bad idea from that perspective! too.
HN
G. &inally! the most fle'ible way to deal with m"lti-val"ed attrib"tes is to create a
composite entity that lin(s employees to ed"cation. /y "sing the composite entity! there
will never be a sit"ation in which additional attrib"tes m"st be created within the
EM4;BEE table to accommodate people with m"ltiple certifications. +n short! we
eliminate the generation of n"lls. +n addition! we gain information fle'ibility beca"se we
can also store the details (date earned! place earned! etc.) for each of the ed"cational
attainments. The (simplified) str"ct"res might loo( li(e those in &ig"re E4.2N ) and /.
Figure <4.1Da The Ch&4'<uestions Data(ase Ta(les
H7
Figure <4.1D( The Ch&4'<uestions Relational Diagra#
/y loo(ing at the str"ct"res shown in &ig"res E4.2Na and E4.2Nb! we can tell that the
employee named Romero earned a /achelor%s degree in 2H>H! a Certified 1etwor(
4rofessional certification in :II:! and a Certified #ata 4rocessing certification in :II4. +f
Randall were to earn a Master%s degree and a Certified 4"blic )cco"ntant certification later!
we merely add another two records in the EM4<E#9C table. +f additional ed"cational
attainments beyond those listed in the E#9C)T+1 table are earned by any employee! all
we need to do is add the appropriate record(s) to the E#9C)T+1 table! then enter the
employee%s attainments in the EM4<E#9C table. There are no n"lls! we have s"perb $"ery
capability! and we have fle'ibility. 1ot a bad set of design goalsC
The database design on which &ig"res E4.2Na and E4.2Nb are based is shown in &ig"re
E4.2Nc.
Figure <4.1Dc The Cro/@s Foot ERD $or the Ch&4'<uestions Data(ase
!4TE
Discuss /ith the students that the design in Figure <4.1Dc sho/s that an e#ployee
#ust #eet at least one educational re1uire#ent5 (ecause EM-'ED)C is not optional
to EM-84,EE. Thus each e#ployee #ust appear at least once in the EM-'ED)C
ta(le. *nd5 gi7en this design5 so#e o$ the educational attain#ents #ay not yet (een
earned (y e#ployees5 (ecause the design sho/s EM-'ED)C to (e optional to
ED)C*TI4!. In other /ords5 so#e o$ the ED)C*TI4! records are not necessarily
re$erenced (y any e#ployee. (In the original M! relationship (et/een EM-84,EE
and ED)C*TI4!5 EM-84,EE #ust ha7e (een optional to ED)C*TI4!.)
H>
The $inal $our 1uestions are (ased on the ERD in Figure <4.1E.
FI9)RE <4.1E The ERD For <uestions 1EI"&
1E. :rite the ten cardinalities that are appropriate $or this ERD.
The cardinalities are indicated in &ig"re E4.27sol.
FI9)RE <4.1Esol The Cardinalities
1F. :rite the (usiness rules re$lected in this ERD.
The following b"siness r"les are reflected in the ER#*
) store may place many orders. (1ote the "se of DmayF , which is reflected in the R#ER
optionality.)
)n order m"st be placed by a store. (1ote that -TRE is mandatory to R#ER. +n this
ER#! the order environment apparently reflects a wholesale environment.)
HH
)n order contains at least one order line. (1ote that R#ER<;+1E is mandatory to
R#ER! and vice-versa.)
Each order line is contained in one and only one order. (#isc"ssion* )ltho"gh a given item ,
s"ch as a hammer , may be fo"nd in many orders! a specific hammer sold to a specific store
is fo"nd in only one order.)
Each order line has a specific prod"ct written in it.
) prod"ct may be written in many orders. (#isc"ssion* Many stores can order one or more
specific prod"cts! b"t a prod"ct that is not in demand may never be sold to a store and will!
therefore! not show "p in any order line -- note that R#ER<;+1E is optional to
4R#9CT. )lso! note that each order line may indicate more than one of a specific item.
&or e'ample! the item may be DhammerF and the n"mber sold may be 2 or :! or JII. The
R#ER<;+1E entity wo"ld have at least the following attrib"tes* R#ER<19M!
R#;+1E<19M! 4R#<C#E! R#;+1E<4R+CE! R#;+1E<E9)1T+TB. The
R#ER<;+1E composite 4@ wo"ld be R#ER<19M A R#;+1E<19M. Bo" might add
the derived attrib"te R#;+1E<)M91T! which wo"ld be the res"lt of m"ltiplying
R#;+1E<4R+CE and R#;+1E<E9)1T+TB.)
) store may employ many employees. (#isc"ssion* ) new store may not yet have any
employees! yet the database may already incl"de the new store information T location!
type! and so on. +f yo" made the EM4;BEE entity mandatory to -TRE! yo" wo"ld have
to create an employee for that store before yo" had even hired one.)
Each employee is employed by one (and only one) store.
)n employee may have one or more dependents. (#isc"ssion* Bo" cannot re"uire an
employee to have dependents! so #E4E1#E1T is optional to EM4;BEE. 1ote the "se of
the word DmayF in the relationship.)
) dependent m"st be related to an employee. (#isc"ssion* +t ma(es no sense to (eep trac( of
dependents of people who are not even employees. Therefore! EM4;BEE is mandatory to
#E4E1#E1T.)
1G. :hat t/o attri(utes #ust (e contained in the co#posite entity (et/een +T4RE and
-R4D)CT; )se proper ter#inology in your ans/er.
The composite entity m"st at least incl"de the primary (eys of the entities it references. The
combination of these attrib"tes may be designated to be the composite entity%s (composite) primary
(ey. Each of the (composite) primary (ey%s attrib"tes is a foreign (ey that references the entities for
which the composite entity serves as a bridge.
)s yo" disc"ss the model in &ig"re E4.27sol! note that an order is represented by two entities!
R#ER and R#ER<;+1E. 1ote also that the -TRE=s 2*M relationship with R#ER and the
R#ER=s 2*M relationship with R#ER<;+1E reflect the concept"al M*1 relationship between
-TRE and 4R#9CT. The original b"siness r"les probably read*
) store can order many prod"cts
) prod"ct can be ordered by many stores.
2II
"&. Descri(e precisely the co#position o$ the DE-E!DE!T /ea= entity@s pri#ary =ey. )se proper
ter#inology in your ans/er.
The #E4E1#E1T entity will have a composite 4@ that incl"des the EM4;BEE entity=s 4@ and
one of its attrib"tes. &or e'ample! if the EM4;BEE entity=s 4@ is EM4<19M! the #E4E1#E1T
entity=s 4@ might be EM4<19M A #E4<19M.
"1. The local city youth league needs a data(ase syste# to help trac= children that sign up to
play soccer. Data needs to (e =ept on each tea# and the children that /ill (e playing on each
tea# and their parents. *lso5 data needs to (e =ept on the coaches $or each tea#. Dra/ the
data #odel descri(ed (elo/.
Entities re1uired Tea#5 -layer5 Coach5 and -arent.
*ttri(utes re1uired
Tea# Tea# ID nu#(er5 Tea# na#e5 and Tea# colors.
-layer -layer ID nu#(er5 -layer $irst na#e5 -layer last na#e5 and -layer age.
Coach Coach ID nu#(er5 Coach $irst na#e5 Coach last na#e5 and Coach ho#e phone
nu#(er.
-arent -arent ID nu#(er5 -arent last na#e5 -arent $irst na#e5 >o#e phone nu#(er5
and >o#e *ddress (+treet5 City5 +tate5 and JI- Code).
The $ollo/ing relationships #ust (e de$ined
Tea# is related to -layer.
Tea# is related to Coach.
-layer is related to -arent.
Connecti7ities and participations are de$ined as $ollo/s
* Tea# #ay or #ay not ha7e a -layer.
* -layer #ust ha7e a Tea#.
* Tea# #ay ha7e #any -layers.
* -layer has only one Tea#.
* Tea# #ay or #ay not ha7e a Coach.
* Coach #ust ha7e a Tea#.
* Tea# #ay ha7e #any Coaches.
* Coach has only one Tea#.
* -layer #ust ha7e a -arent.
* -arent #ust ha7e a -layer.
* -layer #ay ha7e #any -arents.
2I2
* -arent #ay ha7e #any -layers.
This is a great e'ercise in that it opens "p possibilities for several disc"ssion points. The concept"al
ER# prior to placement of foreign (eys and the resol"tion of the M*1 relationship is shown in
&ig"re E4.:2a.
FI9)RE <4."1a Conceptual ERD $or <uestion "1
The most apparent iss"e that m"st be resolved is the M*1 relationship. This is necessary so that foreign
(eys can be appropriately placed thro"gho"t the data model. The revised ER# with properly placed
foreign (eys is shown in &ig"re E4.:2b.
2I:
FI9)RE <4."1( ERD /ith $oreign =eys $or <uestion "1
This sol"tion! however! still leaves an interesting $"estion abo"t the Team<Colors attrib"te. 3hat if
teams have more than one color as is implied by the pl"ral PcolorsP being "sed by the b"siness "sersK
;et%s consider three options* 2) leave it as is (as if Team<Colors is a single-val"ed attrib"te)! :) create
m"ltiple attrib"tes within the TE)M entity! or G) create a new C;R table.
Team<Colors may be left as a single attrib"te if it is determined thro"gh disc"ssion with the b"siness
"sers that they are not concerned with dealing with the different colors individ"ally. &or e'ample! they
will never be interested to (now how many teams have the color /l"e as one of their team colors! then
we may choose to implement the design as given above. 5owever! if the "sers are interested! or foresee
the possibility that at some time in the f"t"re they may become interested! in addressing the different
colors for a given team individ"ally! then we m"st modify the above design to accommodate this need.
+f we determine that all teams have the same n"mber of colors! and no team now or in the f"t"re will
ever have more than that n"mber of colors! then we may modify the design by adding additional
attrib"tes in the TE)M entity. &or e'ample! if all teams! now and forever! will always have e'actly two
team colors then we may prod"ce the design shown in &ig"re E4.:2c.
2IG
FI9)RE <4."1c ERD /ith t/o tea# colors $or <uestion "1
This is a reasonable sol"tion given the ass"rance that all teams now and forever will have e'actly two
team colors. ) problem arises! however! if we cannot rely on that ass"rance. +f some teams have fewer
colors! then o"r design will lead to an increased n"mber of n"lls. +f a team ever has more than two
colors! we will have to modify the str"ct"re of the database after it has been b"ilt to add another team
color attrib"te. This change in str"ct"re may re$"ire changes in the front-end applications so that they
can properly address this new attrib"te. To avoid these potentially serio"s modifications in the f"t"re!
we can re-design the database with a more rob"st str"ct"re that can handle any n"mber of team colors
witho"t f"t"re modifications to the database or the front-end applications. The design with a separate
table to handle the m"lti-val"ed Team<Colors attrib"te is shown in &ig"re E4.:2d.
2I4
FI9)RE <4."1d ERD /ith Color ta(le $or <uestion "1
-ro(le# +olutions
1. )se the $ollo/ing (usiness rules to create a Cro/@s Foot ERD. :rite all appropriate
connecti7ities and cardinalities in the ERD.
a. * depart#ent e#ploys #any e#ployees5 (ut each e#ployee is e#ployed (y one
depart#ent.
(. +o#e e#ployees5 =no/n as Aro7ers5B are not assigned to any depart#ent.
c. * di7ision operates #any depart#ents5 (ut each depart#ent is operated (y one di7ision.
d. *n e#ployee #ay (e assigned #any proKects5 and a proKect #ay ha7e #any e#ployees
assigned to it.
e. * proKect #ust ha7e at least one e#ployee assigned to it.
$. 4ne o$ the e#ployees #anages each depart#ent5 and each depart#ent is #anaged (y only
one e#ployee.
g. 4ne o$ the e#ployees runs each di7ision5 and each di7ision is run (y only one e#ployee.
2IJ
The answers to problem 2 (all parts) are incl"ded in &ig"re 44.2.
Figure -4.1 -ro(le# 1 ERD +olution
)s yo" disc"ss the ER# shown in &ig"re 44.2! note that this design reflects several "sef"l feat"res
that become especially important when the design is implemented. &or e'ample*
The )--+M1 entity is shown to be optional to the 4RLECT. This decision ma(es sense
from a practical perspective! beca"se it lets yo" create a new pro8ect record witho"t having
to create a new assignment record. (+f a new pro8ect is started! there will not yet be any
assignments.)
The relationship e'pressed by D#E4)RTME1T employs EM4;BEEF is shown as
mandatory on the EM4;BEE side. This means that a #E4)RTME1T m"st have at least
one EM4;BEE in order to have departmental stat"s. 5owever! #E4)RTME1T is
optional to EM4;BEE! so an employee can be entered witho"t entering a departmental
&@ val"e. +f the e'istence of n"lls is not acceptable! yo" can create a D1o assignmentF
record in the #E4)RTME1T table! to be referenced in the EM4;BEE table if an
employee is not assigned to a department.
1ote also the implications of the 2*2 DEM4;BEE manages #E4)RTME1TF
relationship. The flip side of this relationship is that Deach #E4)RTME1T is managed by
one EM4;BEEF. (This latter relationship is shown as mandatory in the ER#. That is!
each department must be managed by an employeeC) Therefore! one of the EM4;BEE
table=s 4@ values m"st appear as the &@ value in the #E4)RTME1T table. (Cecause this
is a 11 relationship5 the inde6 property o$ the EM-'!)M FH in the DE-*RTME!T
ta(le #ust (e set to Auni1ue.B)
2IN
)ltho"gh yo" o"ght to approach a 2*2 relationship with ca"tion , most 2*2 relationships
are the res"lt of a misidentification of attrib"tes as entities , the 2*2 relationships reflected
in the DEM4;BEE manages #E4)RTME1TF and DEM4;BEE r"ns #+-+-+1F are
appropriate. These 2*2 relationships avoid the data red"ndancies yo" wo"ld enco"nter if
yo" d"plicated employee data , s"ch a names! phones! and e-mail addresses , in the
#+0+-+1 and #E4)RTME1T entities.
)lso! if yo" have m"ltiple relationships between two entities -- s"ch as the DEM4;BEE manages
#E4)RTME1TF and D#E4)RTME1T employs EM4;BEEF relationships , yo" m"st ma(e s"re
that each relationship has a designated primary entity. &or e'ample! the 2*2 relationship e'pressed
by DEM4;BEE manages #E4)RTME1TF re$"ires that the EM4BEE entity be designated as
the primary (or DfirstF) entity. +f yo" "se 0isio to create yo"r Crow=s &oot ER#s! &ig"re 44.G show
how the 2*2 relationship is specified. +f yo" "se some other C)-E tool! yo" will discover that it!
too! is li(ely to re$"ire similar relationship specifications.
". Create a co#plete ERD in Cro/@s Foot notation that can (e i#ple#ented in the relational
#odel using the $ollo/ing description o$ operations. >ot :ater (>:) is a s#all start-up
co#pany that sells spas. >: does not carry any stoc=. * $e/ spas are set up in a si#ple
/arehouse so custo#ers can see so#e o$ the #odels a7aila(le5 (ut any products sold #ust
(e ordered at the ti#e o$ the sale.
>: can get spas $ro# se7eral di$$erent #anu$acturers.
Each #anu$acturer produces one or #ore di$$erent (rands o$ spas.
Each and e7ery (rand is produced (y only one #anu$acturer.
E7ery (rand has one or #ore #odels.
E7ery #odel is produced as part o$ a (rand. For e6a#ple5 Iguana Cay +pas is a
#anu$acturer that produces Cig Clue Iguana spas5 a pre#iu#-le7el (rand5 and 8aLy
8iLard spas5 an entry-le7el (rand. The Cig Clue Iguana (rand o$$ers se7eral #odels5
including the CCI-D5 an F1-Ket spa /ith t/o D-hp #otors5 and the CCI-1&5 a 1&"-Ket spa
/ith three D-hp #otors.
E7ery #anu$acturer is identi$ied (y a #anu$acturer code. The co#pany na#e5
address5 area code5 phone nu#(er5 and account nu#(er are =ept in the syste# $or
e7ery #anu$acturer.
For each (rand5 the (rand na#e and (rand le7el (pre#iu#5 #id-le7el5 or entry-le7el)
are =ept in the syste#.
For each #odel5 the #odel nu#(er5 nu#(er o$ Kets5 nu#(er o$ #otors5 nu#(er o$
horsepo/er per #otor5 suggested retail price5 >: retail price5 dry /eight5 /ater
capacity5 and seating capacity #ust (e =ept in the syste#.
Figure -4." -ro(le# " ERD +olution
2I7
%. The Mones(urgh County Cas=et(all Con$erence (MCCC) is an a#ateur (as=et(all association.
Each city in the county has one tea# as its representati7e. Each tea# has a #a6i#u# o$ 1"
players and a #ini#u# o$ G players. Each tea# also has up to three coaches (o$$ensi7e5
de$ensi7e5 and physical training coaches). During the season5 each tea# plays t/o ga#es
(ho#e and 7isitor) against each o$ the other tea#s. 9i7en those conditions5 do the $ollo/ing
a. Identi$y the connecti7ity o$ each relationship.
(. Identi$y the type o$ dependency that e6ists (et/een CIT, and TE*M.
c. Identi$y the cardinality (et/een tea#s and players and (et/een tea#s and city.
d. Identi$y the dependency (et/een coach and tea# and (et/een tea# and player.
e. Dra/ the Chen and Cro/@s Foot ERDs to represent the MCCC data(ase.
$. Dra/ the )M8 class diagra# to depict the MCCC data(ase.
The Chen ER# sol"tion is shown in &ig"re 44.GChen. (The Crow=s &oot sol"tion is shown after the
disc"ssion.)
2I>
Figure -4.%Chen The MCCC Chen ERD
To help the st"dents "nderstand the ER diagram%s components better! note the following
relationships*
The main components are TE)M and M)ME.
Each team plays each other team at least twice.
To play a game! two teams are necessary* the home team and the visiting team.
Each team plays at least twice* once as the home team and once as the visiting team.
Miven these relationships! it becomes clear that TE)M participates in a recursive M*1 relationship
with M)ME. The relationship between TE)M and M)ME becomes clearer if we list some
attrib"tes for each of these entities. !ote that the TE*M'!)M appears t/ice in a 9*ME
record once as a 9*ME'>4ME'TE*M and once as a 9*ME'3I+IT'TE*M.
9*ME entity TE*M entity
M)ME<+# TE)M<C#E
M)ME<#)TE TE)M<1)ME
M)ME<5ME<TE)M C+TB<C#E
M)ME<0+-+T<TE)M
M)ME<5ME<-CRE
M)ME<0+-+T<-CRE
+mplementation of this sol"tion yields the relational diagram shown in &ig"re 44.GR#. (+f yo"
implement this design in Microsoft )ccess! note that )ccess will generate a virt"al table named
TE)M<2 to indicate that two relationships e'ist between M)ME and TE)M. :e created a
2IH
data(ase na#ed Ch&4'MCCC'31 to illustrate this design i#ple#entation.
Figure -4.%RD The MCCC Relational Diagra#5 3ersion 1
The sol"tion shown in &ig"re 44.GChen yields a database that enables its "sers to trac( all games.
&or e'ample! a simple $"ery , based on the two relationships between TE)M and M)ME yields
the o"tp"t shown in &ig"re 44.G-. (3e have created only a few records to show the res"lts for
games 2 and : played by teams named /ears! Rattlers! -har(s! and Tigers! respectively.)
Figure -4.%+4 The MCCC Data(ase 9a#e +u##ary 4utput5 3ersion 1
)s yo" e'amine the design and its implementation , chec( the relational diagram in &ig"re 44.GR#
-- note that this sol"tion "ses synonyms! beca"se the TE)M<19M shows "p in M)ME twice* once
as the M)ME<5ME<TE)M and once as the M)ME<0+-+T<TE)M. Miven the "se of these
synonyms! the M)ME entity also becomes very c"mbersome str"ct"rally as yo" decide to trac(
more game data. &or e'ample! if yo" wanted to (eep trac( of r"ns! hits! and errors! yo" wo"ld have
to have one set of each for each of the two teams , all in the same record. Clearly! s"ch a str"ct"re
22I
is "ndesirable* the "se of synonyms re$"ires the addition of two new attrib"tes , one for the home
team and one for the visiting team -- for each additional characteristic yo" want to trac(.
To eliminate the str"ct"ral problem disc"ssed in the previo"s paragraph! yo" can let each game be
represented by two entities* M)ME and M)ME<;+1E. &ig"re 44.GR#: shows the str"ct"res of
these two entities in a segment of the revised relational diagram. 3e have added a ;C)T+1
entity to specify the act"al location of the game , (nowing that a game is played in 1ashville is not
s"fficiently specific. 4layers! coaches! and spectators o"ght to (now where in 1ashville the game is
played.
Figure -4.%RD" The Re7ised MCCC Data(ase Relational Diagra#
!4TE
<uite aside $ro# the $act that /e ought to =no/ /here in each city any gi7en ga#e is played5
the 84C'ID attri(ute in 9*ME re$ers to a 84C*TI4! entity that /as created to #a=e the
data(ase #ore $le6i(le (y per#itting the use o$ #ultiple locations in each city. *lthough this
capa(ility /as not required (y the pro(le# description ? each city only $ields one tea# at this
point ? is 7ery li=ely that additional tea#s /ill (e organiLed in the $uture.
9ood design $irst ensures that current re1uire#ents are #et. This design does that. Cut good
design also anticipates the reasona(ly e6pected changing dyna#ics o$ the data(ase
en7iron#ent. This re7ised design does that5 too.
*dditional $le6i(ility is gained (y the use o$ the 9*ME entity. For e6a#ple5 i$ you /ant to
trac= the assign#ent o$ re$erees in each o$ the ga#es5 you can easily create a REFEREE
entity in a M! relationship /ith the 9*ME entity. (* re$eree #ay re$eree #any ga#es and
#any re$erees re$eree each ga#e.) This M! relationship #ay then (e trans$or#ed into t/o
222
1M relationships through the use o$ a co#posite entity5 perhaps na#ed REF'9*ME.
Finally5 point out to the students that the relationship (et/een the ne/ly created 9*ME and
9*ME'8I!E entities is structurally si#ilar to the (y no/ $a#iliar relationship (et/een
I!34ICE and I!3'8I!E entities.
The completed database design is implemented as shown in the Crow=s &oot ER# in &ig"re
44.GC&.
22:
Figure -4.%CF The MCCC Cro/@s Foot ERD
22G
Figure -4.%)M8 The MCCC )M8 Class Diagra#
224
!4TE
,ou #ay /onder /hy /e e6a#ined this solution in such detail. (The sa#ple
i#ple#entation is sho/n in the data(ase na#ed Ch&4'MCCC'3ersion".) *$ter all5 #ere
ga#es hardly see# to #erit this le7el o$ data(ase design attention.
*ctually5 there is the pro7er(ial #ethod in the #adness. The (as=et(all ? or any other
ga#e en7iron#ent -- is li=ely to (e $a#iliar to your students. There$ore5 it (eco#es easier
$or you to sho/ the design and i#ple#entation o$ recursi7e relationships ? /hich are
actually rather co#ple6 things. Fortunately5 e7en co#ple6 design issues (eco#e
#anagea(le in a $a#iliar data en7iron#ent.
Recursi7e relationships are co##on enough ? or should (e ? to #erit attention and the
de7elop#ent o$ e6pertise in their i#ple#entation. In #any #anu$acturing industries5
incredi(ly detailed part trac=ing is #andatory. For e6a#ple5 the i#ple#entation o$ the
recursi7e relationship A-*RT contains -*RTB is especially desira(le in the a7iation
#anu$acturing (usinesses. +uch (usinesses are re1uired (y $ederal la/ to #aintain
a(solute parts tracing records. I$ a co#ple6 part $ails5 it #ust (e possi(le to $ollo/ all the
trails to all the co#ponent parts that #ay ha7e (een in7ol7ed in the part@s $ailure.
4. Create an ERD (ased on the Cro/@s Foot #odel5 using the $ollo/ing re1uire#ents
*n I!34ICE is /ritten (y a +*8E+RE-. Each sales representati7e can /rite #any
in7oices5 (ut each in7oice is /ritten (y a single sales representati7e.
The I!34ICE is /ritten $or a single C)+T4MER. >o/e7er5 each custo#er can ha7e
#any in7oices.
*n I!34ICE can include #any detail lines (8I!E)5 each o$ /hich descri(es one product
(ought (y the custo#er.
The product in$or#ation is stored in a -R4D)CT entity.
The product@s 7endor in$or#ation is $ound in a 3E!D4R entity.
NOTE
The ERD #ust re$lect (usiness rules that you are $ree to de$ine (/ithin reason). Ma=e sure
that your ERD re$lects the conditions you re1uire. Finally5 #a=e sure that you include the
attri(utes that /ould per#it the #odel to (e success$ully i#ple#ented.
The Crow=s &oot ER# sol"tion is shown in &ig"re 4.4.
22J
Figure -4.4 The Cro/@s Foot ERD +olution $or -ro(le# 4
22N
!4TE
Heep in #ind that the preceding ER diagra# re$lects a set o$ (usiness rules that #ay easily
(e #odi$ied. For e6a#ple5 i$ custo#ers are supplied 7ia a co##ercial custo#er list5 #any o$
the custo#ers on that list /ill not (yetN) ha7e (ought anything5 so I!34ICE /ould (e
optional to C)+T4MER. :e are assu#ing here that #any 7endors can supply a product
and that each 7endor can supply #any products. The -R4D)CT #ay (e optional to
3E!D4R i$ the 7endor list includes potential 7endors $ro# /hich you ha7e not (yet)
ordered anything. +o#e products #ay ne7er sell5 so 8I!E is optional to -R4D)CT...
(ecause an unsold product /ill ne7er appear in an in7oice line. ,ou #ay also /ant to sho/
the students ho/ the co#posite entities #ay (e represented at the $inal i#ple#entation
le7el. For e6a#ple5 8I!E is sho/n as /ea= to I!34ICE5 (ecause it (orro/s the in7oice
nu#(er as part o$ its pri#ary =ey and it is e6istence-dependent on I!34ICE. The #odi$ied
ER diagra# is sho/n ne6t. The point o$ this e6ercise is that the design0s $inal iteration
depends on the e6act nature o$ the (usiness rules and the desired le7el o$ i#ple#entation
detail.
2. The >udson Engineering 9roup (>E9) has contacted you to create a conceptual #odel /hose
application /ill #eet the e6pected data(ase re1uire#ents $or the co#pany@s training
progra#. The >E9 ad#inistrator gi7es you the description (see (elo/) o$ the training group@s
operating en7iron#ent. (Hint: +o#e o$ the $ollo/ing sentences identi$y the 7olu#e o$ data
rather than cardinalities. Can you tell /hich ones;)
The >E9 has 1" instructors and can handle up to %& trainees per class. >E9 o$$ers $i7e
*d7anced Technology courses5 each o$ /hich #ay generate se7eral classes. I$ a class has $e/er
than ten trainees5 it /ill (e canceled. There$ore5 it is possi(le $or a course not to generate any
classes. Each class is taught (y one instructor. Each instructor #ay teach up to t/o classes or
#ay (e assigned to do research only. Each trainee #ay ta=e up to t/o classes per year.
9i7en that in$or#ation5 do the $ollo/ing
a. De$ine all o$ the entities and relationships. ()se Ta(le 4.4 as your guide.)
The 5EM entities and relationships are shown in Table 44.Ja.
Ta(le -4.2a The Co#ponents o$ the >E9 ERD
E!TIT, RE8*TI4!+>I- C4!!ECTI3IT, E!TIT,
+1-TR9CTR teaches 2*M C;)--
C9R-E generates 2*M C;)--
C;)-- is listed in 2*M E1R;;
TR)+1EE is written in 2*M E1R;;
)s yo" e'amine the s"mmary in Table 44.Ja! it is reasonable to ass"me that many of the
relationships are optional and that some are mandatory. (Remember a point we made earlier*
when in do"bt! ass"me an optional relationship.)
227
) C9R-E does not necessarily generate a class d"ring each training period. (-ome
co"rses may be ta"ght every other period or d"ring some other specified time frames.
Therefore! it is reasonable to ass"me that C;)-- is optional to C9R-E.
Each C;)-- m"st be related to a C9R-E. (The class m"st cover designated co"rse
materialC) Therefore! C9R-E is mandatory to C;)--.
-ome instr"ctors may teach a class every other period or even rarely. Therefore! it is
reasonable to ass"me that C;)-- is optional to +1-TR9CTR d"ring any enrollment
period. This optionality ma(es sense from an implementation point of view! too. &or
e'ample! if yo" appoint a new instr"ctor! that instr"ctor will not , yet , have ta"ght a
class.
1ot all trainees are li(ely to be enrolled in classes d"ring some time period. +n fact! in a
real world setting! many trainees are li(ely to get informal Don the 8obF training witho"t
going to formal classes. Therefore! it is reasonable to ass"me that E1R;; is optional
to TR)+1EE.
Bo" cannot create an enrollment record witho"t having a trainee. Therefore! TR)+1EE
is mandatory to E1R;;. (#isc"ssion point* 3hat abo"t ma(ing TR)+1EE optional to
E1R;;K +n any case! optional relationships may be "sed for operational reasons!
whether or not they are directly derived from a b"siness r"le.)
1ote that a real world database design re$"ires the e'plicit recognition of each relationship=s
characteristics. 3hen in do"bt! as( the end "sersC
(. Descri(e the relationship (et/een instructor and class in ter#s o$ connecti7ity5 cardinality5
and e6istence-dependence.
/oth $"estions (a) and (b) have been addressed in the ER diagram shown in &ig"re 44.4b.
22>
Figure -4.2( The >E9 ERD
)s yo" disc"ss &ig"re 44.Jb! (eep the disc"ssion in part (a) in mind. )lso! note the following
points*
) trainee can ta(e more than one class! and each class contains many (2I or more)
trainees! so there is a M*1 relationship between TR)+1EE and C;)--. (Therefore! a
composite entity is "sed to serve as the bridge between TR)+1EE and C;)--.)
) class is ta"ght by only one instr"ctor! b"t an instr"ctor can teach "p to two classes.
Therefore! there is a 2*M relationship between +1-TR9CTR and C;)--.
&inally! a C9R-E may generate more than one C;)--! while each C;)-- is based
on one C9R-E! so there is a 2*M relationship between C9R-E and C;)--.
These relationships are all reflected in the ER diagram shown in &ig"re 44.4b. 1ote the optional
and mandatory relationships*
To e'ist! a C;)-- m"st have TR)+1EEs enrolled in it! b"t TR)+1EEs do not
necessarily ta(e C;)--es. (-ome may ta(e Pon the 8ob training.P)
)n +1-TR9CTR may not be teaching any C;)--es d"ring some enrollment periods.
&or e'ample! an instr"ctor may be assigned to d"ties other than training. 5owever! each
C;)-- m"st have an +1-TR9CTR.
+f an ins"fficient n"mber of people sign "p for a C;)--! a C9R-E may not generate
any C;)--es! b"t each C;)-- m"st represent a C9R-E.
22H
!4TE
The sentences O>E9 has t/el7e instructors.O and O>E9 o$$ers $i7e ad7anced
technology courses.O are not re$lected in the ER diagra#. Instead5 they represent
additional in$or#ation concerning the 7olu#e o$ data (nu#(er o$ entities in an entity
set)5 rather than in$or#ation concerning entity relationships.
Cecause the >E9 description in -ro(le# 4 lea7es roo# $or di$$erent interpretations
o$ optional vs. #andatory relationships5 /e li=e to gi7e the student the (ene$it o$ the
dou(t. There$ore5 unless the question or problem description is sufficiently precise to
leave no doubt about the existence of optional/mandatory relationships5 /e (ase the
student grade on t/o criteria
1. :as the (asic nature o$ the relationship ? 115 1M5 or M! ? selected and
displayed properly;
". 9i7en the student@s rendering o$ such a relationship5 are the cardinalities
appropriate;
Bo" can add s"bstantial detail to the ER# by incl"ding sample attrib"tes for each of the entities.
9sing 0isio 4rofessional! yo" can also let yo"r st"dent declare the nat"re , wea( or strong , of
the relationships among the entities. &inally! remind yo"r st"dents that the order in which the
attrib"tes appear in each entity is immaterial. Therefore! the (composite) 4@ of the can be
written as either C;)--<C#E A TR1<19M or as TR1<19M A C;)--<C#E. That=s why
it is also immaterial which one of the foreign (ey attrib"tes is &@2 or &@:.
)s yo" disc"ss the ER# shown in &ig"re 44.Jb! note that the basic components of this problem
are fo"nd in the te't=s &ig"re 4.GJ. 1ote also that the E1R;; entity in &ig"re 44.Jb "ses a
composite 4@ (TR1<19M A C;)--<C#E) and that! therefore the relationships between
E1R;; and C;)-- and TR)+1EE are strong. &inally! disc"ss the reason for the wea(
relationship between C9R-E and C;)-- , the C;)-- entity=s 4@ (C;)--<C#E) does
not DborrowF the 4@ of the parent C9R-E entity. +f the C;)-- entity=s 4@ had been
composed of CR-<C#E A C;)--<-ECT+1! the relationship between C9R-E and
C;)-- wo"ld have been strong.
Discussion Review the te't to show the two possible relationship strengths between C9R-E
and C;)--. Emphasi?e that the choice of the 4@ component(s) is "s"ally a designer option! b"t
that single-attrib"te 4@s tend to yield more design options than composite 4@s. Even the
composite E1R;; entity can be modified to have a single-attrib"te 4@ s"ch as
E1R;;<19M. Miven that choice! C;)--<C#E A TR1<19M constit"te a candidate (ey ,
C;)--<C#E and TR1<19M contin"e to serve as foreign (eys to C;)-- and TR)+1EE!
respectively. Miven the latter scenario! yo" can create a ("ni$"e) composite inde' to prevent
d"plicate enrollments.
D. *uto#ata Inc. produces specialty 7ehicles (y contract. The co#pany operates se7eral
depart#ents5 each o$ /hich (uilds a particular 7ehicle5 such as a li#ousine5 a truc=5 a 7an5 or
an R3.
2:I
Ce$ore a ne/ 7ehicle is (uilt5 the depart#ent places an order /ith the purchasing depart#ent
to re1uest speci$ic co#ponents. *uto#ata@s purchasing depart#ent is interested in creating a
data(ase to =eep trac= o$ orders and to accelerate the process o$ deli7ering #aterials.
The order recei7ed (y the purchasing depart#ent #ay contain se7eral di$$erent ite#s. *n
in7entory is #aintained so that the #ost $re1uently re1uested ite#s are deli7ered al#ost
i##ediately. :hen an order co#es in5 it is chec=ed to deter#ine /hether the re1uested ite#
is in in7entory. I$ an ite# is not in in7entory5 it #ust (e ordered $ro# a supplier. Each ite#
#ay ha7e se7eral suppliers.
9i7en that $unctional description o$ the processes encountered at *uto#ata@s purchasing
depart#ent5 do the $ollo/ing
a. Identi$y all o$ the #ain entities.
(. Identi$y all o$ the relations and connecti7ities a#ong entities.
c. Identi$y the type o$ e6istence dependency in all the relationships.
d. 9i7e at least t/o e6a#ples o$ the types o$ reports that can (e o(tained $ro# the
data(ase.
The initial Crow=s &oot ER# is shown in &ig"re 44.Ninit. The disc"ssion preceding &ig"re 44.Nrev
e'plains why the revision was made.
2:2
Figure -4.Dinit Initial *uto#ata Cro/@s Foot ERD
)s yo" e'plain the development of the Crow=s &oot ER# shown in &ig"re 44.Ninit! several points
are worth stressing*
The R#ER and R#<;+1E entities are perfect reflections of the +10+CE and
+10<;+1E entities the st"dents have enco"ntered before. This (ind of 2*M relationship is
$"ite common in a b"siness environment and yo" will see it rec"r thro"gho"t the boo( and
in its many problems. 1ote that the R#<;+1E entity is wea(! beca"se it inherits part of its
4@ from its R#ER DparentF entity. Therefore! the DcontainsF relationship between
R#ER and R#<;+1E is properly shown as an identifying (strong) relationship. (The
relationship line is solid! rather than dashed.) &inally! note that R#<;+1E is mandatory to
R#ER. it is not possible to have an R#ER that does not contain at least one order line.
)nd! of co"rse! R#ER is mandatory to R#<;+1E! beca"se an R#<;+1E occ"rrence
cannot e'ist witho"t referencing an R#ER.
The R#ER entity is shown as optional to #E4)RTME1T! indicating that it is $"ite
possible that a department has not (yet) placed an order. )side from the fact that s"ch an
optionality ma(es common sense! it also ma(es operational sense from a database point of
view. &or e'ample! if the R#ER entity were mandatory to the #E4)RTME1T entity! the
creation of a new department wo"ld re$"ire the creation of an order! so yo" might have to
create a Dd"mmyF order when yo" create a new department. )lso! (eep in mind that an
2::
order cannot be written by a department that does not (yet) e'ist.
1ote also that the 0E1#R may not (yet) have received and order! so R#ER is optional
to 0E1#R. The 0E1#R entity may contain vendors who are simply potential s"ppliers
if items and yo" may want to have s"ch potential vendors available 8"st in case yo"r D"s"alF
vendor(s) r"n(s) o"t of items that yo" need.
The other optionalities sho"ld be disc"ssed! too , "sing the same basic scenarios that were
described in b"llets : and G.
!4TE
In this presentation5 the relationship (et/een 3E!D4R and ITEM is sho/n as 1M.
There$ore5 each 7endor can supply #any ite#s5 (ut only one 7endor can supply each ite#.
I$ it is possi(le $or ite#s to (e supplied (y #ore than one 7endor5 there is a M!
relationship (et/een 3E!D4R and ITEM and this relationship /ould ha7e to (e
i#ple#ented through a co#posite ((ridge) entity. *ctually5 such an M! relationship is
speci$ied in the (rie$ description o$ the *uto#ata co#pany@s data en7iron#ent. There$ore5
the $ollo/ing Figure -4.Dre7 #ore accurately re$lects the pro(le# description.
Figure -4.Dre7 Re7ised *uto#ata Cro/@s Foot ERD
2:G
E. )nited >elpers is a nonpro$it organiLation that pro7ides aid to people a$ter natural disasters.
Cased on the $ollo/ing (rie$ description o$ operations5 create the appropriate $ully la(eled
Cro/@s Foot ERD.
Indi7iduals 7olunteer their ti#e to carry out the tas=s o$ the organiLation. For each
7olunteer5 their na#e5 address5 and telephone nu#(er are trac=ed. Each 7olunteer #ay (e
assigned to se7eral tas=s during the ti#e that they are doing 7olunteer /or=5 and so#e
tas=s re1uire #any 7olunteers. It is possi(le $or a 7olunteer to (e in the syste# /ithout
ha7ing (een assigned a tas= yet. It is possi(le to ha7e tas=s that no one has (een assigned.
:hen a 7olunteer is assigned to a tas=5 the syste# should trac= the start ti#e and end ti#e
o$ that assign#ent.
For each tas=5 there is a tas= code5 tas= description5 tas= type5 and a tas= status. For
e6a#ple5 there #ay (e a tas= /ith tas= code A1&15B description o$ Aans/er the telephone5B
a type o$ Arecurring5B and a status o$ Aongoing.B There could (e another tas= /ith a code
o$ A1&"5B description o$ Aprepare 2&&& pac=ages o$ (asic #edical supplies5B a type o$
Apac=ing5B and a status o$ Aopen.B
For all tas=s o$ type Apac=ing5B there is a pac=ing list that speci$ies the contents o$ the
pac=ages. There are #any di$$erent pac=ing lists to produce di$$erent pac=ages5 such as
(asic #edical pac=ages5 child care pac=ages5 $ood pac=ages5 etc. Each pac=ing list has a
pac=ing list ID nu#(er5 pac=ing list na#e5 and a pac=ing list description5 /hich descri(es
the ite#s that ideally go into #a=ing that type o$ pac=age. E7ery pac=ing tas= is
associated /ith only one pac=ing list. * pac=ing list #ay not (e associated /ith any tas=s5
or #ay (e associated /ith #any tas=s. Tas=s that are not pac=ing tas=s are not associated
/ith any pac=ing list.
-ac=ing tas=s result in the creation o$ pac=ages. Each indi7idual pac=age o$ supplies that
is produced (y the organiLation is trac=ed. Each pac=age is assigned an ID nu#(er. The
date the pac=age /as created5 and total /eight o$ the pac=age is recorded. * gi7en
pac=age is associated /ith only one tas=. +o#e tas=s (e.g.5 Aans/er the phonesB) /ill not
ha7e produced any pac=ages5 /hile other tas=s (e.g.5 Aprepare 2&&& pac=ages o$ (asic
#edical suppliesB) /ill (e associated /ith #any pac=ages.
The pac=ing list descri(es the ideal contents o$ each pac=age5 (ut it is not al/ays possi(le
to include the ideal nu#(er o$ each ite#. There$ore5 the actual ite#s included in each
pac=age should (e trac=ed. * pac=age can contain #any di$$erent ite#s5 and a gi7en ite#
can (e used in #any di$$erent pac=ages.
For each ite# that the organiLation pro7ides5 there is an ite# ID nu#(er5 ite# description5
ite# 7alue5 and ite# 1uantity on hand stored in the syste#. *long /ith trac=ing the
actual ite#s that are placed in each pac=age5 the 1uantity o$ each ite# placed in the
pac=age #ust (e trac=ed too. For e6a#ple5 a pac=ing list #ay state that (asic #edical
pac=ages should include 1&& (andages5 4 (ottles o$ iodine5 and 4 (ottles o$ hydrogen
pero6ide. >o/e7er5 (ecause o$ the li#ited supply o$ ite#s5 a gi7en pac=age #ay include
only 1& (andages5 1 (ottle o$ iodine5 and no hydrogen pero6ide. The $act that this pac=age
includes (andages and iodine needs to (e recorded along /ith the 1uantity o$ each that is
included. It is possi(le $or the organiLation to ha7e ite#s donated that ha7e not (een
included in any pac=age yet5 (ut e7ery pac=age /ill contain at least one ite#.
2:4
The ER# for 9nited 5elpers is shown in &ig"re 44.Na.
FI9)RE -4.Ea )nited >elpers ERD
This problem! however! does leave room for interesting disc"ssion with the st"dents regarding the
need to verify re$"irements with the b"siness "sers. +n fact! getting una#(iguous b"siness r"les
can be one of the most diffic"lt parts of the design process. +n this problem! the potential for a
relationship between the pac(ing list (;+-T) and the items (+TEM) stoc(ed by the organi?ation can
be a so"rce for disc"ssion. -t"dents may envision that a ;+-T can specify many +TEMs and an
+TEM can be specified in many ;+-Ts. This wo"ld imply the need for a M*1 relationship between
+TEM and ;+-T. 5owever! the b"siness "sers may not intend for the pac(ing list to be that specific.
2:J
&or e'ample! the pac(ing list may specify that P: liter of iodineP sho"ld be incl"ded in a given type
of pac(age witho"t specifying whether it sho"ld be two 2-liter bottles of iodine or fo"r JIIml
bottles of iodine. 1ote that P2-liter bottle of iodineP and PJIIml bottle of iodineP wo"ld have to be
separate entity instances in +TEM beca"se they have different val"es. +f it is the case that the
pac(ing list is intentionally generic in its description of the ideal contents! then a relationship
between ;+-T and +TEM wo"ld not be appropriate.
F. )sing the Cro/@s Foot #ethodology5 create an ERD that can (e i#ple#ented $or a #edical
clinic5 using at least the $ollo/ing (usiness rules
a. * patient can #a=e #any appoint#ents /ith one or #ore doctors in the clinic5 and a
doctor can accept appoint#ents /ith #any patients. >o/e7er5 each appoint#ent is #ade
/ith only one doctor and one patient.
(. E#ergency cases do not re1uire an appoint#ent. >o/e7er5 $or appoint#ent #anage#ent
purposes5 an e#ergency is entered in the appoint#ent (oo= as Aunscheduled.B
c. I$ =ept5 an appoint#ent yields a 7isit /ith the doctor speci$ied in the appoint#ent. The
7isit yields a diagnosis and5 /hen appropriate5 treat#ent.
d. :ith each 7isit5 the patient@s records are updated to pro7ide a #edical history
e. Each patient 7isit creates a (ill. Each patient 7isit is (illed (y one doctor5 and each doctor
can (ill #any patients.
$. Each (ill #ust (e paid. >o/e7er5 a (ill #ay (e paid in #any install#ents5 and a pay#ent
#ay co7er #ore than one (ill.
g. * patient #ay pay the (ill directly5 or the (ill #ay (e the (asis $or a clai# su(#itted to an
insurance co#pany.
h. I$ the (ill is paid (y an insurance co#pany5 the deducti(le is su(#itted to the patient $or
pay#ent.
The ER# sol"tion is shown in &ig"re 44.>.
2:N
Figure -4.F The Medical Clinic@s Cro/@s Foot ERD
2:7
Case +olutions
G. The ad#inistrators o$ Tiny College are so pleased /ith your design and i#ple#entation o$
their student registrationPtrac=ing syste# that they /ant you to e6pand the design to include
the data(ase $or their #otor 7ehicle pool. * (rie$ description o$ operations $ollo/s
* (rie$ description o$ operations $ollo/s
Faculty #e#(ers #ay use the 7ehicles o/ned (y Tiny College $or o$$icially sanctioned
tra7el. For e6a#ple5 the 7ehicles #ay (e used (y $aculty #e#(ers to tra7el to o$$-ca#pus
learning centers5 to tra7el to locations at /hich research papers are presented5 to transport
students to o$$icially sanctioned locations5 and to tra7el $or pu(lic ser7ice purposes. The
7ehicles used $or such purposes are #anaged (y Tiny College@s TFC+ (Tra7el Far Cut
+lo/ly) Center.
)sing reser7ation $or#s5 each depart#ent can reser7e 7ehicles $or its $aculty5 /ho are
responsi(le $or $illing out the appropriate trip co#pletion $or# at the end o$ a trip. The
reser7ation $or# includes the e6pected departure date5 7ehicle type re1uired5 destination5
and na#e o$ the authoriLed $aculty #e#(er. The $aculty #e#(er arri7ing to pic= up a
7ehicle #ust sign a chec=out $or# to log out the 7ehicle and pic= up a trip co#pletion
$or#. (The TFC+ e#ployee /ho releases the 7ehicle $or use also signs the chec=out $or#.)
The $aculty #e#(er@s trip co#pletion $or# includes the $aculty #e#(er@s identi$ication
code5 the 7ehicle@s identi$ication5 the odo#eter readings at the start and end o$ the trip5
#aintenance co#plaints (i$ any)5 gallons o$ $uel purchased (i$ any)5 and the Tiny College
credit card nu#(er used to pay $or the $uel. I$ $uel is purchased5 the credit card receipt
#ust (e stapled to the trip co#pletion $or#. )pon receipt o$ the $aculty trip co#pletion
$or#5 the $aculty #e#(er@s depart#ent is (illed at a #ileage rate (ased on the 7ehicle
type (sedan5 station /agon5 panel truc=5 #ini7an5 or #ini(us) used. (Hint Do not use #ore
entities than are necessary. Re#e#(er the di$$erence (et/een attri(utes and entitiesN)
*ll 7ehicle #aintenance is per$or#ed (y TFC+. Each ti#e a 7ehicle re1uires #aintenance5
a #aintenance log entry is co#pleted on a prenu#(ered #aintenance log $or#. The
#aintenance log $or# includes the 7ehicle identi$ication5 a (rie$ description o$ the type o$
#aintenance re1uired5 the initial log entry date5 the date on /hich the #aintenance /as
co#pleted5 and the identi$ication o$ the #echanic /ho released the 7ehicle (ac= into
ser7ice. (4nly #echanics /ho ha7e an inspection authoriLation #ay release the 7ehicle
(ac= into ser7ice.)
*s soon as the log $or# has (een initiated5 the log $or#@s nu#(er is trans$erred to a
#aintenance detail $or#Q the log $or#@s nu#(er is also $or/arded to the parts depart#ent
#anager5 /ho $ills out a parts usage $or# on /hich the #aintenance log nu#(er is
recorded. The #aintenance detail $or# contains separate lines $or each #aintenance ite#
per$or#ed5 $or the parts used5 and $or identi$ication o$ the #echanic /ho per$or#ed the
#aintenance ite#. :hen all #aintenance ite#s ha7e (een co#pleted5 the #aintenance
detail $or# is stapled to the #aintenance log $or#5 the #aintenance log $or#@s co#pletion
date is $illed out5 and the #echanic /ho releases the 7ehicle (ac= into ser7ice signs the
$or#. The stapled $or#s are then $iled5 to (e used later as the source $or 7arious
#aintenance reports.
TFC+ #aintains a parts in7entory5 including oil5 oil $ilters5 air $ilters5 and (elts o$ 7arious
types. The parts in7entory is chec=ed daily to #onitor parts usage and to reorder parts
2:>
that reach the A#ini#u# 1uantity on handB le7el. To trac= parts usage5 the parts
#anager re1uires each #echanic to sign out the parts that are used to per$or# each
7ehicle@s #aintenanceQ the parts #anager records the #aintenance log nu#(er under
/hich the part is used.
Each #onth TFC+ issues a set o$ reports. The reports include the #ileage dri7en (y
7ehicle5 (y depart#ent5 and (y $aculty #e#(ers /ithin a depart#ent. In addition5 7arious
re7enue reports are generated (y 7ehicle and depart#ent. * detailed parts usage report is
also $iled each #onth. Finally5 a 7ehicle #aintenance su##ary is created each #onth.
9i7en that (rie$ su##ary o$ operations5 dra/ the appropriate (and $ully la(eled) ERD. )se
the Chen #ethodology to indicate entities5 relationships5 connecti7ities5 and cardinalities.
The sol"tion is shown in &ig"re 44.H.
2:H
Figure -4.G The Tiny-College TFC+ Maintenance ERD
2GI
1&. During pea= periods5 Te#porary E#ploy#ent Corporation (TEC) places te#porary
/or=ers in co#panies. TEC@s #anager gi7es you the $ollo/ing description o$ the (usiness
TEC has a $ile o$ candidates /ho are /illing to /or=.
I$ the candidate has /or=ed (e$ore5 that candidate has a speci$ic Ko( history.
(!aturally5 no Ko( history e6ists i$ the candidate has ne7er /or=ed.) Each ti#e the
candidate /or=s5 one additional Ko( history record is created.
Each candidate has earned se7eral 1uali$ications. Each 1uali$ication #ay (e earned (y
#ore than one candidate. (For e6a#ple5 it is possi(le $or #ore than one candidate to
ha7e earned a CC* degree or a Microso$t !et/or= Certi$ication. *nd clearly5 a
candidate #ay ha7e earned (oth a CC* and a Microso$t !et/or= Certi$ication.)
TEC o$$ers courses to help candidates i#pro7e their 1uali$ications.
E7ery course de7elops one speci$ic 1uali$icationQ ho/e7er5 TEC does not o$$er a course
$or e7ery 1uali$ication. +o#e 1uali$ications ha7e #ultiple courses that de7elop that
1uali$ication.
+o#e courses co7er ad7anced topics that re1uire speci$ic 1uali$ications as
prere1uisites. +o#e courses co7er (asic topics that do not re1uire any prere1uisite
1uali$ications. * course can ha7e se7eral prere1uisites. * 1uali$ication can (e a
prere1uisite $or #ore than one course.
Courses are taught during training sessions. * training session is the presentation o$ a
single course. 47er ti#e5 TEC /ill o$$er #any training sessions $or each courseQ
ho/e7er5 ne/ courses #ay not ha7e any training sessions scheduled right a/ay.
Candidates can pay a $ee to attend a training session. * training session can
acco##odate se7eral candidates5 although ne/ training sessions /ill not ha7e any
candidates registered at $irst.
TEC also has a list o$ co#panies that re1uest te#poraries.
Each ti#e a co#pany re1uests a te#porary e#ployee5 TEC #a=es an entry in the
4penings $older. That $older contains an opening nu#(er5 a co#pany na#e5 re1uired
1uali$ications5 a starting date5 an anticipated ending date5 and hourly pay.
Each opening re1uires only one speci$ic or #ain 1uali$ication.
:hen a candidate #atches the 1uali$ication5 the Ko( is assigned5 and an entry is #ade
in the -lace#ent Record $older. That $older contains an opening nu#(er5 a candidate
nu#(er5 the total hours /or=ed5 etc. In addition5 an entry is #ade in the Ko( history $or
the candidate.
*n opening can (e $illed (y #any candidates5 and a candidate can $ill #any openings.
TEC uses special codes to descri(e a candidate@s 1uali$ications $or an opening. The list
o$ codes is sho/n in Ta(le -4.1&.
2G2
T*C8E -4.1& TEC <)*8IFIC*TI4! C4DE+
C4DE DE+CRI-TI4!
-EC-4J -ecretarial wor(! at least 4J words per min"te
-EC-NI -ecretarial wor(! at least NI words per min"te
C;ER@ Meneral cler(ing wor(
4RM-0/ 4rogrammer! 0is"al /asic
4RM-CAA 4rogrammer! CAA
#/)-R) #atabase )dministrator! racle
#/)-#/: #atabase )dministrator! +/M #/:
#/)--E;-ER0 #atabase )dministrator! M- -E; -erver
-B--2 -ystems )nalyst! level 2
-B--: -ystems )nalyst! level :
13-10 1etwor( )dministrator! 1ovell e'perience
3#-C& 3eb #eveloper! Cold&"sion
TEC@s #anage#ent /ants to =eep trac= o$ the $ollo/ing entities
C4M-*!,
4-E!I!9
<)*8IFIC*TI4!
C*!DID*TE
M4C'>I+T4R,
-8*CEME!T
C4)R+E
+E++I4!
9i7en that in$or#ation5 do the $ollo/ing
a. Dra/ the Cro/@s Foot ERDs $or this enterprise.
(. Identi$y all possi(le relationships.
c. Identi$y the connecti7ity $or each relationship.
d. Identi$y the #andatoryPoptional dependencies $or the relationships.
e. Resol7e all M! relationships.
The sol"tions for problems 2Ia-2Ie are shown in &ig"re 44.2I.
2G:
Figure -4.1& TEC +olution ERD
To help the st"dents "nderstand &ig"re 44.2I=s ER diagram%s components better! the following
disc"ssion is li(ely to be "sef"l*
Each CM4)1B may list one or more 4E1+1Ms. /eca"se we will maintain CM4)1B
data even if a company has not (yetC) hired any of TEC%s candidates! 4E1+1M is an
2GG
optional entity in the CM4)1B lists 4E1+1M relationship.
4E1+1M is e'istence-dependent on CM4)1B! beca"se there cannot be an opening
"nless a company lists it. +f yo" decide to "se the CM4)1B primary (ey as a component
of the 4E1+1M%s primary (ey! yo" have satisfied the conditions that will allow yo" to
classify 4E1+1M as a wea( entity and the relationship between CM4)1B and
4E1+1M will be strong or identifying. +n other words! the 4E1+1M entity is wea( if its
4@ is the combination of 4E1+1M<19M and CM4<C#E. (The CM4<C#E
remains the &@ in the 4E1+1M entity.)
1ote that there is a 2*M relationship between CM4)1B and 4E1+1M! beca"se a company
can list m"ltiple 8ob openings. The ne't table segment shows that the 3E-T Company has two
available 8ob openings and the E)-T Company has one available 8ob opening. 1at"rally! the
act"al table wo"ld have additional attrib"tes in it , b"t we=re merely ill"strating the behavior of
the 4@ components here.
C4M-'C4DE 4-E!I!9'!)M
3est 2
3est :
East 2
5owever! if the 4E1+1M=s 4@ is defined to be a single 4E1+1M attrib"te s"ch as a uni"ue
4E1+1M<19M! 4E1+1M is no longer a wea( entity. 3e have decided to "se the latter
approach in &ig"re 44.2I. (+f yo" "se Microsoft )ccess to implement this design!
4E1+1M<19M may be declared as an a"ton"mber.) !ote that this decision causes the
relationship (et/een C4M-*!, and 4-E!I!9 to (e /ea=. (The relationship line is
dashed.) +n this case! the CM4<C#E attrib"te wo"ld contin"e to be the &@ pointing to the
CM4)1B table! b"t it wo"ld no longer be a part of the 4E1+1M entity 4@. The ne't table
segment shows what s"ch an arrangement wo"ld loo( li(e*
4-E!I!9'!)M C4M-'C4DE
2II:J 3est
2II:N 3est
2II:7 East
-imilarly! the relationship between 4;)CEME1T and 4E1+1M may be defined as strong
or wea(. 3e have "sed a wea( relationship between 4E1+1M and 4;)CEME1T.
) 8ob candidate may have had many 8obs -- remember that TEC is a temp employer.
Therefore! a candidate may have many entries in 5+-TRB. /"t (eep in mind that a
candidate may 8"st have completed 8ob training and! therefore! may not have had 8ob
e'perience (i.e.! no 8ob history) yet. +n short! 5+-TRB is optional to C)1#+#)TE.
To enable TEC or its clients to trace the entire employment record of any candidate! it is
reasonable to e'pect that the 5+-TRB entity also records the 8ob(s) held by the candidate
before that candidate was placed by TEC. nly the portion of the 8ob history created thro"gh
TEC placement is reflected in the 4;)CEME1T entity. Therefore! 4;)CEME1T is
optional to 5+-TRB.
2G4
The semantics of the problem seem to s"ggest that the 5+-TRB is an entity that e'ists in a
2*2 relationship with 4;)CEME1T. )fter all! each placement generates one (and only one)
entry in the candidate=s history.
/eca"se each placement m"st generate an entry in the 5+-TRB entity! one wo"ld
reasonably concl"de that 5+-TRB is mandatory to 4;)CEME1T. 1ote that
4;)CEME1T is red"ndant! beca"se a 8ob placement obvio"sly creates a 8ob history entry.
5owever! s"ch a red"ndancy can be 8"stified on the basis that 4;)CEME1T may be "sed
to trac( 8ob placement details that are of interest to TEC management.
5+-TRB is clearly e'istence-dependent on C)1#+#)TE. it is not possible to ma(e an
entry in 5+-TRB witho"t having a C)1#+#)TE to generate that history. Miven this
scenario! the C)1#+#)TE entity=s primary (ey may be "sed as one of the components of
the 5+-TRB entity%s primary (ey! th"s ma(ing 5+-TRB a wea( entity.
Each C)1#+#)TE may have earned one or more E9);+&+C)T+1s. )ltho"gh a
company may list a $"alification! there may not be a matching candidate beca"se it is
possible that none of the candidates have this $"alification. &or instance! it is possible that
none of the available candidates is a 4ascal programmer. Therefore! C)1#+#)TE is
optional to E9);+&+C)T+1. 5owever! many candidates may have a given $"alification.
&or e'ample! many candidates may be CAA programmers. @eep in mind that each
$"alification may be matched to many 8ob candidates! so the relationship between
C)1#+#)TE and E9);+&+C)T+1 is M*1. This relationship m"st be decomposed into
two 2*M relationships with the help of a composite entity we will name E#9C)T+1. The
E#9C)T+1 entity will contain the $"alification code! the candidate identification! the
date on which the candidate earned the $"alification! and so on. ) few sample data entries
might loo( li(e this*
<)*8'C4DE C*!D'!)M ED)C'D*TE
4RM-0/ 4GJ> 2:-#ec-II
4RM-CAA 4GJ> IJ-Mar-IG
#/)-R) 4GJ> :G-1ov-I2
#/)-#/: :22G I:-L"n->J
#/)-R) :22G :N-Lan-I:
1ote that the preceding table contents ill"strate that candidate 4GJ> has three listed
$"alifications! while candidate :22G has two listed $"alifications. 1ote also that the
$"alification code #/)-R) occ"rred more than once. Clearly! the 4@ m"st be a
combination of E9);<C#E and C)1#<19M! th"s ma(ing the relationships between
E9);+&+C)T+1 and E#9C)T+1 and between E#9C)T+1 and C)1#+#)TE
strong. In this e6a#ple5 the ED)C*TI4! entity is (oth /ea= and co#posite.
2GJ
!4TE
I$ you use 3isio to create the ERD5 you only enter the ED)C'D*TE colu#n in the
ED)C*TI4! entity. Do not type the $oreign =ey attri(utes under the colu#n
headings ? 3isio /ill auto#atically create the FH entries as you declare the
relationships.
In this ERD5 select the relationships (et/een <)*8IFIC*TI4! and ED)C*TI4!
and (et/een ED)C*TI4! and C*!DID*TE to (e strong5 thus ensuring that the
relationship lines /ill (e solid5 rather than dashed. The <)*8'C4DE and the
C*!D'!)M /ill auto#atically (e inserted as -Hs and as FHs in the ED)C*TI4!
entity. I$ you declare the <)*8'C4DE and the C*!D'!)M attri(utes in the
ED)C*TI4! entity and you then create the relationship lines5 3isio /ill /rite
duplicate <)*8'C4DE and the C*!D'!)M attri(utes into the ED)C*TI4!
entity as -Hs and FHs. Clearly5 this result is undesira(le i$ the entity is i#ple#ented
as a ta(le.
Follo/ this si#ple rule !e7er declare a FH in an entity (y creating it yoursel$. 8et
3isio /rite all the FHs as you esta(lish the relationships.
Each 8ob 4E1+1M re$"ires one E9);+&+C)T+1! and any given $"alification may fit
many openings! th"s prod"cing a 2*M relationship between E9);+&+C)T+1 and
4E1+1M. &or e'ample! a 8ob opening for a CAA programmer re$"ires an applicant to have
the CAA programming $"alification! b"t there may be many 8ob openings for CAA
programmersC 5owever! a $"alification does not re$"ire an opening. ()fter all! if there is no
listing with a CAA re$"irement! a candidate who has the CAA $"alification does not match
the listingC) Therefore! 4E1+1M is optional to E9);+&+C)T+1.
+n the ER# shown in &ig"re 44.2Ia! we decided to define the 4E1+1M entity=s 4@ to be
4E1+1M<19M. This decision produces a non-identi$ying (/ea=) relationship
(et/een 4-E!I!9 and <)*8IFIC*TI4!. 5owever! if yo" want to ens"re that there
cannot be a listed opening "nless it also lists the re$"ired $"alification for that opening! the
4E1+1M is e'istence-dependent on E9);+&+C)T+1. +f yo" then decide to let the
4E1+1M entity inherit E9);<C#E from E9);+&+C)T+1 as part of its 4@!
4E1+1M is properly classified as a wea( entity to E9);+&+C)T+1.
ne or more candidates may fill a listed 8ob opening. )lso! (eep in mind that! d"ring some
period of time! a candidate may fill many openings. (TEC s"pplies temporaries! rememberK)
Therefore! the relationship between 4E1+1M and C)1#+#)TE is M*1. 3e will
decompose this M*1 relationship into two 2*M relationships! "sing the composite entity
named 4;)CEME1T as the bridge between C)1#+#)TE and 4E1+1M.
/eca"se a candidate is not necessarily placed! 4;)CEME1T is optional to C)1#+#)TE.
-imilarly! since an opening may be listed even when there is no available candidate!
4;)CEME1T is optional to 4E1+1M.
2GN
11. )se the $ollo/ing description o$ the operations o$ the RC'Charter" Co#pany to co#plete
this e6ercise.
The RC'Charter" Co#pany operates a $leet o$ aircra$t under the Federal *ir Regulations
-art 1%2 (air ta6i or charter) certi$icate5 en$orced (y the F**. The aircra$t are a7aila(le $or
air ta6i (charter) operations /ithin the )nited +tates and Canada.
Charter co#panies pro7ide so-called AunscheduledB operationsRthat is5 charter $lights ta=e place
only a$ter a custo#er reser7es the use o$ an aircra$t to $ly at a custo#er-designated date and ti#e
to one or #ore custo#er-designated destinations5 transporting passengers5 cargo5 or so#e
co#(ination o$ passengers and cargo. * custo#er can5 o$ course5 reser7e #any di$$erent charter
$lights (trips) during any ti#e $ra#e. >o/e7er5 $or (illing purposes5 each charter trip is reser7ed
(y one and only one custo#er. +o#e o$ RC'Charter"@s custo#ers do not use the co#pany@s
charter operationsQ instead5 they purchase $uel5 use #aintenance ser7ices5 or use other
RC'Charter" ser7ices. >o/e7er5 this data(ase design /ill $ocus on the charter operations only.
Each charter trip yields re7enue $or the RC'Charter" Co#pany. That re7enue is generated
(y the charges that a custo#er pays upon the co#pletion o$ a $light. The charter $light
charges are a $unction o$ aircra$t #odel used5 distance $lo/n5 /aiting ti#e5 special custo#er
re1uire#ents5 and cre/ e6penses. The distance $lo/n charges are co#puted (y #ultiplying
the round-trip #iles (y the #odel@s charge per #ile. Round-trip #iles are (ased on the actual
na7igational path $lo/n. The sa#ple route traced in Figure -4.1& illustrates the procedure.
!ote that the nu#(er o$ round-trip #iles is calculated to (e 1%& S "&& S 1F& S %G& T G&&.
FI9)RE -4.11a R4)!D-TRI- MI8E DETERMI!*TI4!
Depending on /hether a custo#er has RC'Charter" credit authoriLation5 the custo#er #ay
-ay the entire charter (ill upon the co#pletion o$ the charter $light.
2G7
-ay a part o$ the charter (ill and charge the re#ainder to the account. The charge a#ount
#ay not e6ceed the a7aila(le credit.
Charge the entire charter (ill to the account. The charge a#ount #ay not e6ceed the
a7aila(le credit.
Custo#ers #ay pay all or part o$ the e6isting (alance $or pre7ious charter trips. +uch
pay#ents #ay (e #ade at any ti#e and are not necessarily tied to a speci$ic charter trip. The
charter #ileage charge includes the e6pense o$ the pilot(s) and other cre/ re1uired (y F*R
1%2. >o/e7er5 i$ custo#ers re1uest additional cre/ not re1uired (y F*R 1%25 those custo#ers
are charged $or the cre/ #e#(ers on an hourly (asis. The hourly cre/-#e#(er charge is
(ased on each cre/ #e#(er@s 1uali$ications.
The data(ase #ust (e a(le to handle cre/ assign#ent. Each charter trip re1uires the use o$
an aircra$t5 and a cre/ $lies each aircra$t. The s#aller piston engine-po/ered charter aircra$t
re1uire a cre/ consisting o$ only a single pilot. 8arger aircra$t (that is5 aircra$t ha7ing a gross
ta=eo$$ /eight o$ 1"52&& pounds or #ore) and Ket-po/ered aircra$t re1uire a pilot and a
copilot5 /hile so#e o$ the larger aircra$t used to transport passengers #ay re1uire $light
attendants as part o$ the cre/. +o#e o$ the older aircra$t re1uire the assign#ent o$ a $light
engineer5 and larger cargo-carrying aircra$t re1uire the assign#ent o$ a load#aster. In short5 a
cre/ can consist o$ #ore than one person and not all cre/ #e#(ers are pilots.
The charter $light@s aircra$t /aiting charges are co#puted (y #ultiplying the hours /aited (y
the #odel@s hourly /aiting charge. Cre/ e6penses are li#ited to #eals5 lodging5 and ground
transportation.
The RC'Charter" data(ase #ust (e designed to generate a #onthly su##ary o$ all charter
trips5 e6penses5 and re7enues deri7ed $ro# the charter records. +uch records are (ased on the
data that each pilot in co##and is re1uired to record $or each charter trip trip date(s) and
ti#e(s)5 destination(s)5 aircra$t nu#(er5 pilot (and other cre/) data5 distance $lo/n5 $uel usage5
and other data pertinent to the charter $light. +uch charter data are then used to generate
#onthly reports that detail re7enue and operating cost in$or#ation $or custo#ers5 aircra$t5
and pilots. *ll pilots and other cre/ #e#(ers are RC'Charter" Co#pany e#ployeesQ that is5
the co#pany does not use contract pilots and cre/.
F*R -art 1%2 operations are conducted under a strict set o$ re1uire#ents that go7ern the
licensing and training o$ cre/ #e#(ers. For e6a#ple5 pilots #ust ha7e earned either a
Co##ercial license or an *irline Transport -ilot (*T-) license. Coth licenses re1uire
appropriate ratings. Ratings are speci$ic co#petency re1uire#ents. For e6a#ple
To operate a #ultiengine aircra$t designed $or ta=eo$$s and landings on land only5 the
appropriate rating is ME85 or Multiengine 8andplane. :hen a #ultiengine aircra$t can
ta=e o$$ and land on /ater5 the appropriate rating is ME+5 or Multiengine +eaplane.
The instru#ent rating is (ased on a de#onstrated a(ility to conduct all $light operations
/ith sole re$erence to coc=pit instru#entation. The instru#ent rating is re1uired to
operate an aircra$t under Instru#ent Meteorological Conditions (IMC)5 and all such
operations are go7erned under F*R-speci$ied Instru#ent Flight Rules (IFR). In contrast5
2G>
operations conducted under Agood /eatherB or visual $light conditions are (ased on the
F*R 3isual Flight Rules (3FR).
The type rating is re1uired $or all aircra$t /ith a ta=eo$$ /eight o$ #ore than 1"52&&
pounds or $or aircra$t that are purely Ket-po/ered. I$ an aircra$t uses Ket engines to dri7e
propellers5 that aircra$t is said to (e tur(oprop-po/ered. * tur(opropRthat is5 a tur(o
propeller-po/ered aircra$tRdoes not re1uire a type rating unless it #eets the 1"52&&-
pound /eight li#itation.
*lthough pilot licenses and ratings are not ti#e-li#ited5 e6ercising the pri7ilege o$ the license
and ratings under -art 1%2 re1uires (oth a current medical certificate and a current Part 1!
chec"ride. The $ollo/ing distinctions are i#portant
The #edical certi$icate #ay (e Class I or Class II. The Class I #edical is #ore stringent
than the Class II5 and it #ust (e rene/ed e7ery si6 #onths. The Class II #edical #ust (e
rene/ed yearly. I$ the Class I #edical is not rene/ed during the si6-#onth period5 it
auto#atically re7erts to a Class II certi$icate. I$ the Class II #edical is not rene/ed /ithin
the speci$ied period5 it auto#atically re7erts to a Class III #edical5 /hich is not 7alid $or
co##ercial $light operations.
* -art 1%2 chec=ride is a practical $light e6a#ination that #ust (e success$ully co#pleted
e7ery si6 #onths. The chec=ride includes all $light #aneu7ers and procedures speci$ied in
-art 1%2.
!onpilot cre/ #e#(ers #ust also ha7e the proper certi$icates in order to #eet speci$ic Ko(
re1uire#ents. For e6a#ple5 load#asters need an appropriate certi$icate5 as do $light attendants. In
addition5 cre/ #e#(ers such as load#asters and $light attendants5 /ho #ay (e re1uired in
operations that in7ol7e large aircra$t (#ore than a 1"52&&-pound. ta=eo$$ /eight and passenger
con$igurations o7er 1G) are also re1uired periodically to pass a /ritten and practical e6a#. The
RC'Charter" Co#pany is re1uired to =eep a co#plete record o$ all test types5 dates5 and results
$or each cre/ #e#(er5 as /ell as pilot #edical certi$icate e6a#ination dates.
In addition5 all $light cre/ #e#(ers are re1uired to su(#it to periodic drug testingQ the
results #ust (e trac=ed5 too. (!ote that nonpilot cre/ #e#(ers are not re1uired to ta=e pilot-
speci$ic tests such as -art 1%2 chec=rides. !or are pilots re1uired to ta=e cre/ tests such as
load#aster and $light attendant practical e6a#s.) >o/e7er5 #any cre/ #e#(ers ha7e licenses
andPor certi$ications in se7eral areas. For e6a#ple5 a pilot #ay ha7e an *T- and a load#aster
certi$icate. I$ that pilot is assigned to (e a load#aster on a gi7en charter $light5 the load#aster
certi$icate is re1uired. +i#ilarly5 a $light attendant #ay ha7e earned a co##ercial pilot@s
license. +a#ple data $or#ats are sho/n in Ta(le -4.1%.
2GH
T*C8E -4.11 +*M-8E D*T* F4RM*T+
-art * Tests
TE+T C4DE TE+T DE+CRI-TI4! TE+T FRE<)E!C,
1 -art 1%2 Flight Chec= D #onths
" Medical5 Class 1 D #onths
% Medical5 Class " 1" #onths
4 8oad#aster -ractical 1" #onths
2 Flight *ttendant -ractical 1" #onths
D Drug test Rando#
E 4perations5 /ritten e6a# D #onths
-art C Results
EM-84,EE TE+T C4DE TE+T D*TE TE+T RE+)8T
1&1 1 1"-!o7-1% -ass-1
1&% D "%-Dec-1% -ass-1
11" 4 "%-Dec-1% -ass-"
1&% E 11-Man-14 -ass-1
11" E 1D-Man-14 -ass-1
1&1 E 1D-Man-14 -ass-1
1&1 D 11-Fe(-14 -ass-"
1"2 " 12-Fe(-14 -ass-1
-art C 8icenses and Certi$icates
8ICE!+E 4R CERTIFIC*TE 8ICE!+E 4R CERTIFIC*TE DE+CRI-TI4!
*T- *irline Transport -ilot
Co## Co##ercial license
Med-1 Medical certi$icate5 class 1
Med-" Medical certi$icate5 class "
Instr Instru#ent rating
ME8 Multiengine 8and aircra$t rating
8M 8oad#aster
F* Flight *ttendant
24I
-art D 8icenses and Certi$icates >eld (y E#ployees
EM-84,EE 8ICE!+E 4R CERTIFIC*TE D*TE E*R!ED
1&1 Co## 1"-!o7-G%
1&1 Instr "F-Mun-G4
1&1 ME8 G-*ug-G4
1&% Co## "1-Dec-G2
11" F* "%-Mun-&"
1&% Instr 1F-Man-GD
11" 8M "E-!o7-&2
-ilots and other cre/ #e#(ers #ust recei7e recurrency training appropriate to their /or=
assign#ents. Recurrency trainin# is (ased on an F**-appro7ed curriculu# that is Ko(-
speci$ic. For e6a#ple5 pilot recurrency training includes a re7ie/ o$ all applica(le -art 1%2
$light rules and regulations5 /eather data interpretation5 co#pany $light operations
re1uire#ents5 and speci$ied $light procedures. The RC'Charter" Co#pany is re1uired to
=eep a co#plete record o$ all recurrency training $or each cre/ #e#(er su(Kect to the
training.
The RC'Charter" Co#pany is re1uired to #aintain a detailed record o$ all cre/ credentials
and all training #andated (y -art 1%2. $he company must "eep a complete record of each
requirement and of all compliance data.
To conduct a charter $light5 the co#pany #ust ha7e a properly #aintained aircra$t a7aila(le.
* pilot /ho #eets all o$ the F**@s licensing and currency re1uire#ents #ust $ly the aircra$t
as -ilot in Co##and (-IC). For those aircra$t that are po/ered (y piston engines or
tur(oprops and ha7e a gross ta=eo$$ /eight under 1"52&& pounds5 single-pilot operations are
per#itted under -art 1%2 as long as a properly #aintained autopilot is a7aila(le. >o/e7er5
e7en i$ F*R -art 1%2 per#its single-pilot operations5 #any custo#ers re1uire the presence o$
a copilot /ho is capa(le o$ conducting the $light operations under -art 1%2.
The RC'Charter" operations #anager anticipates the lease o$ tur(oKet-po/ered aircra$t5 and
those aircra$t are re1uired to ha7e a cre/ consisting o$ a pilot and copilot. Coth pilot and
copilot #ust #eet the sa#e -art 1%2 licensing5 ratings5 and training re1uire#ents.
The co#pany also leases larger aircra$t that e6ceed the 1"52&&-pound gross ta=eo$$ /eight.
Those aircra$t can carry the nu#(er o$ passengers that re1uires the presence o$ one or #ore
$light attendants. I$ those aircra$t carry cargo /eighing o7er 1"52&& pounds5 a load#aster
#ust (e assigned as a cre/ #e#(er to super7ise the loading and securing o$ the cargo. $he
database must be desi#ned to meet the anticipated additional charter crew assi#nment capability.
a. 9i7en this inco#plete description o$ operations5 /rite all applica(le (usiness rules to
esta(lish entities5 relationships5 optionalities5 connecti7ities5 and cardinalities. (Hint: )se
the $ollo/ing $i7e (usiness rules as e6a#ples5 /riting the re#aining (usiness rules in the
sa#e $or#at.)
* custo#er #ay re1uest #any charter trips.
242
Each charter trip is re1uested (y only one custo#er.
+o#e custo#ers ha7e not (yet) re1uested a charter trip.
*n e#ployee #ay (e assigned to ser7e as a cre/ #e#(er on #any charter trips.
Each charter trip #ay ha7e #any e#ployees assigned to it to ser7e as cre/ #e#(ers.
(. Dra/ the $ully la(eled and i#ple#enta(le Cro/@s Foot ERD (ased on the (usiness rules
you /rote in -art a o$ this pro(le#. Include all entities5 relationships5 optionalities5
connecti7ities5 and cardinalities.
The following b"siness r"les can be derived from the description of operations*
) c"stomer may re$"est many charter trips.
Each charter trip is re$"ested by only one c"stomer.
-ome c"stomers have not (yet) re$"ested a charter trip.
Every charter trip is re$"ested by at least one c"stomer.
)n employee may be assigned to serve as a crew member on many charter trips.
Each charter trip may have many employees assigned to it to serve as crew members.
)n employee may not yet have been assigned to serve as a crew member on any charter trip.
) charter trip may not yet have any employee assigned to serve as a crew member.
Each c"stomer may ma(e many payments.
-ome c"stomers have not made any payments yet.
Every payment is made by only one c"stomer.
Every payment m"st have been made by a c"stomer.
) payment may be toward many charter trips.
) payment may not be in reference to any charter trip.
Every charter trip m"st have a payment made.
Each charter trip has only one payment.
Every charter trip involves the "se of a single aircraft.
Every charter trip re$"ires at least one aircraft.
)n aircraft may be "sed for many charter trips.
)n aircraft may not yet have been "sed for any charter trip.
Each aircraft is only one model airplane.
Every aircraft has a model designation.
)n airplane model is not re$"ired to be associated with any aircraft that the company owns.
The company may own many aircraft of a given model.
) given flight assignment may be given to many crew members.
-ome flight assignments may not have ever been given to any crew member.
Every crew member assignment is associated with a flight assignment.
Every crew member assignment is associated with only one flight assignment.
)n employee may have ta(en many tests.
-ome employees may have ta(en no tests yet.
) test may be ta(en by many employees.
) test may not have been ta(en by any employee yet.
24:
Each employee has one 8ob with the company.
Every employee has only one 8ob with the company.
) 8ob may be done by many employees.
) 8ob may be c"rrently "nfilled and not be associated with any employee.
)n employee may be a pilot! and every pilot is an employee.
) pilot may have earned many ratings.
-ome pilots have not earned any rating yet.
) rating may be earned by many pilots.
-ome ratings are not held by any pilots.
) pilot may have many licenses.
) pilot may not have any license yet.
) license may be held by many pilots.
) license may not be held by any pilot yet.
Every employee can have many $"alifications.
-ome employees do not have any $"alifications.
Each $"alification can be held by many employees.
-ome $"alifications are not held by any employee.
The completed ER# is shown in &ig"re 44.22b.
24G
Figure -4.11( The RC'Charter" Flight Depart#ent Cro/@s Foot ERD
244

IM Ch04 Entity Relationship Modeling Ed11

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

IM Ch04 Entity Relationship Modeling Ed11

Caricato da

Copyright:

Formati disponibili

Chapter 4 Entity Relationship (ER) Modeling

Potrebbero piacerti anche