86 Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model operation narr-res initially for the logical operations that are expected to be applied to individual objects of a class, as shown in Figure 3.16. As the design is refined, n.rore details are added, such as the exact argulnent types (parameters) for each operation, plus a functional description of each operation. UML has functiort tlescriptiorrs and seqtrence diagrams to specify some of the operation details, but these are beyond the scope of our discussion. Chapter 12 will introduce some of these diagrams. Weak er-rtities can be modeled using the construct called qualified association (or qualified aggregation) in UML; <strong>this</strong> can represent both the identifring relationship and the partial ke,v, which is placed in a box attached to the owner class. This is illustrated by the DEPENDENT class and its qualified aggregation to EMpLOyEE in Figure 3.16. The partial key Dependent_name is called the discriminator in UML termir-rology, since its value distinguishes the objects associated with (related to) the same EMPLOYEE. Qualified associations are not restricted to modelins weak entities, and they can be used to n-rodel other situations in UML. 3.9 Relationship Types of Degree Higher Than Two In Section 3.4.2 we defined the degree of a relationship type as the number of participating entity types and called a relatior-rship type of degre e Iwo binary and a relationship type of degree three ternary.ln <strong>this</strong> section, we elaborate on the differences between binary and higher-degree relationships, when to choose higher-degree or binary relationships, and constraints on higher-degree relationships. 3.9.1 Choosing between Binary and Ternary (or Higher-Degree) Relationships The ER diagram notation fbr a ternary relationship type is shown in Figure 3.17(a), which displays the schema for the SUPPLY relationship type that was displayed irt the instance level in Figure 3.10. Recall that the relationship set of SUPPLY is a set of relationshipr instances (s, j, p), r,vhere s is a SUPPLIER who is currently supplying a PARTp to a PROJECT.i. In general, a relationship type R of degree n will have ir edges in an ER diagram, one connecting R to each participating entity type. Figure 3.17(b) shows an ER diagrarn for the three binary relatior-rship types CAN_SUPPLY, USES, and SUPPLIES. ln general, a ternary reiationship type represer.rts different infbrrnation than do three binary relationship types. Consider the tl-rree binary relationship types CAN_SUPPLY, USES, and SUPPLIES. Suppose that CAN SUPPLY, betrveen SUPPLIER and PART, includes an instance (s,p) whenever supplier s cotr strpply partp (to any project); USES, between PROJECT and PART, ir-rcludes an instance (.1,p) whenever project/ uses partp; and SUPPLIES, between SUPPLIER rrnd PROJECT, includes an instance (s, j) whenever supplier s supplies some part to project j. The existence of three relationship instances (s,p),( j,p), and (s,7) in CAN_SUPPLY, USES, and SUPPLIES, respectively, does not necessarily imply
'( .ipplied .:.tlrred, ' 'r each , ' ,'tcttotl r -.1:, but -- -.rnre of ltion (or :.. , 'llshiP : . . illus- P- - vEE in r terh- "11- - :()) the t-- t r : -s 8llti- 'l par- .l rela- :ences -ree or : r (O/; .cd at , set of .ing a cdges tvpes :epre- :.r the -l that --never . ]ART, ,i:\\reen _'..plies : . alld :ntply (a) (b) (c) 3.9 Relationship Types of Degree Higher Than Two- Figure 3.17 Ternary relationship types, (a) The SUPPLY relationship. (b) Three binary relationships "ot equivalent to SUPPLY (c) SUPPLY represented as a weak entity type. that an instance (s, j, p) exists in the ternary relationship SUPPLY, because Ihe meaning is differenr. It is often tricky to decide whether a particular relationship should be represented as a relationship type of degree n or should be broken down into several relationship types of smaller degrees. The designer must base <strong>this</strong> decision on the semantics or meaning of the particular situation being represented. The typical solu-
- Page 1 and 2: .-" clrapter 3 Data Modeling Using
- Page 3 and 4: luy the 'ilSe ER '{L) r-Se 'il re )
- Page 5 and 6: t diaiional sually nrc of create ro
- Page 7 and 8: 't ---,--:-.: JmoeI -_==-?' T :5o11
- Page 9 and 10: aJr. or a .lc vi.rlue, ()l hal\re a
- Page 11 and 12: .rre the ,.d into sofan .rsually it
- Page 13 and 14: )n cov- ,llue is r bcing rr.rlued t
- Page 15 and 16: pes. Jme oan rt of visor the The hi
- Page 17 and 18: ..itionship ..i..ler the 'utc calle
- Page 19 and 20: nbina- These _rs repployee s con- ,
- Page 21 and 22: lr. - ;ip'.-::.rl hh F* F | )r -ll
- Page 23 and 24: I ,' :i r€p- G. .'.iIlO[ ;i .::d
- Page 25 and 26: Ll,L2 rrilr 3.7.2 Proper Naming of
- Page 27 and 28: ., i:ed or ri :C\'€I3l TQ. and :;
- Page 29: }.!r :lJnY F.' : the ) '.)nle nl-':
- Page 33 and 34: lr .3 1C ,1,.r' x - =FERS ' . :tast
- Page 35: : t- Ft- I t T. &- F ,. t, p)' .tra