this pdf excerpt

More documents

Recommendations

Info

72 Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model Figure 3.10 Some relationship instances in the SUPPLY ternary rplalinnchin sel SUPPLIER SUPPLY PROJECT Relationships as Attributes. It is sometimes convenient to think of a relationship type in terms of attributes, as we discussed in Section 3.3.3. Consider the WORKS_FOR relationship type of Figure 3.9. One can think of an attribute called Department of the EMPLOYEE entity type where the value of Department for each EMPLOYEE entity is (a reference to) the DEPARTMENT entity for which that employee works. Hence, the value set for this Department attribute is the set of all DEPARTMENT entities, which is the DEPARTMENT entity set. This is what we did in Figure 3.8 when we specified the initial design of the entity type EMPLOYEE for the COMPANY database. However, when we think of a binary relationship as an attribute, we always have two options. In this example, the alternative is to think of a multivalued attribute Employee of the entity type DEPARTMENT whose values for each DEPARTMENT entity is the set of EMPLOYEE entities who work for that department. The value set of this Employee attribute is the power set of the EMPLOYEE entity set. Either of these two attributes-Department of EMPLOYEE or Employee of DEPARTMENT-can represent the WORKS_FOR relationship type. If both are represented, they are constrained to be inverses ofeach other.8 B. Thrs concept of representing relationship types as attributes is used in a class of data models called functional data models. In object databases (see Chapter 2O), relationships can be represented by reference attributes, either in one direction or in both directions as inverses, In relational databases (see Chapter 5), foreign keys are a type of reference attribute used to represent relationships. l1 : l2 le
..itionship ..i..ler the 'utc called : for each hich that ' :et of all ','c did in rt lor tne .rn attribtriamuls tor each partment. 'EE entity ,ployee of Jrc repre- "dl 3.4 Relationship Types, Relationship Sets, Roles, and Structural Constraints Role Names and Recursive Relationships. Each entity type that participates in .r relationship type plays a particular role in the relationship. The role name signi- :lcs the role that a participating entity ti-om the entity tvpe plirvs in each relationship :nstance, and helps to explain what the relationsl-rip means. For exanrple, in the WORKS-FOR relationship type, EMPLOYEE plays the role of entployee or worker and DEPARTMENT plays the role of departrnent or employer. I{ole names are not technically necessary in relationshipr types rvhere all the participrting entity types are distinct, since each participating entity type name can be r.is!'d as the role name. However, in some cases the -srinle entity type participates ;rrcrre than once in a relationship type in diJlbrent role,-s. In such cases the role name [..'comes essential for distinguishing the meaning of each participation. Such relarionship types are called recursive relationships. Figure 3.11 shows an example. I'he SUPERVISION relationship type relates an emplo,vee to a supervisor, where iroth ernployee and supervisor entities are members o[ the same EMPLOYEE entity rr'1re. |lgr.., the EMPLOYEE entitv rvpe pnrticipofes fh,ice in SUPERVISION: once in thr'role of supervisor'(or boss), and once in the role oI supervisee (or subordinate). F.rcl-r relationship instance r' in SUPERVISION associates two employee entities er .rnd e1, one of which plays the role of supervisor and the other the role of supervisee. I n Figure 3. I 1, the lines marked ' 1 ' represent the supervisor role, and those marked I' reprresent the supervisee role; hence, c, supervises e, and e-,, eo supervises cn and ,' , irDd eo supervises e I and eo. ln this example, each relationship instirnce must have trlo lines, one marked with'1'(supervisory) and the other with'2'(supervisee). EMPLOYEE SUPERVISION Figure 3.11 A recursive relationship SUPERVISION between EIVPLOYEE in the supervisor role (1) and EN/PLOYEE ln lhe subordinate role (2).
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: pes. Jme oan rt of visor the The hi
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 and 30: }.!r :lJnY F.' : the ) '.)nle nl-':
Page 31 and 32: '( .ipplied .:.tlrred, ' 'r each ,
Page 33 and 34: lr .3 1C ,1,.r' x - =FERS ' . :tast
Page 35: : t- Ft- I t T. &- F ,. t, p)' .tra

this pdf excerpt

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?