Chapter 4

'''

Chapter 4 The Enhanced E-R Model and Business Rules

Chapter Overview The purpose of this chapter is to present some important extensions to the E-R model (described in Chapter 3) that are useful in capturing additional business meaning. In particular, e describe t o t!pes of extensions to the E-R model. "irst, the enhanced entit!-relationship (EER) model includes constructs for supert!pe#subt!pe relationships. $econd, the inclusion of ne notation for business rules allo s the designer to capture a broader range of constraints on the data model than ere pre%iousl! a%ailable. Chapter Objectives $pecific student ob&ecti%es are included in the beginning of the chapter. From an instructors point of view, the objectives of this chapter are to: '. Introduce the concept of supert!pe#subt!pe relationships, and prepare the student to recogni(e hen to use these relationships in data modeling. ). *escribe the use of speciali(ation (top-do n perspecti%e) and generali(ation (bottom-up perspecti%e) as complementar! techni+ues for defining supert!pe#subt!pe relationships. 3. Introduce notation for specif!ing both completeness constraints and dis&ointness constraints hen modeling supert!pe#subt!pe relationships. ,. -elp students gain sufficient perspecti%e so that the! recogni(e hen to use (and hen not to use) supert!pe#subt!pe relationships in realistic business situations. .. *escribe the basic premises of a business rules paradigm. /. *escribe a simple frame or0 for categori(ing business rules. 1. Introduce notation for modeling t!pical operational constraints that can be incorporated in !our EER diagram. 2. *iscuss the uni%ersal data model. Key Terms 3ction 3ction assertion 3nchor ob&ect 3ttribute inheritance Completeness constraint Corresponding ob&ect *eri%ation *eri%ed "act *is&oint rule *is&ointness constraint Enhanced entit!-relationship (EER) model Entit! cluster 4enerali(ation 5%erlap rule 6artial $peciali(ation rule $peciali(ation $tructural assertion $ubt!pe $ubt!pe discriminator $upert!pe $upert!pe#subt!pe hierarch! Total speciali(ation rule 7ni%ersal data model

'')

Modern Database Management, Ninth Edition

Classroom deas '. ). 3. ,. .. /. 1. 2. >. '?. ''. Introduce the concept of supert!pes and subt!pes ith a familiar example, such as 8E-IC9E (subt!pes are C3R, TR7C:, $78, etc.). Introduce the basic notation for supert!pe#subt!pe relationships ("igure ,-'). 7se this notation to represent the example !ou introduced in ('). Introduce !our students to all three t!pes of notation. *iscuss the E;695<EE example ith subt!pes ("igure ,-)). 7se this figure to introduce the example of attribute inheritance. 7se "igure ,-3 to discuss the t o ma&or reasons for introducing supert!pe#subt!pe relationships= uni+ue attributes among subt!pes, and uni+ue subt!pe relationships. Contrast generali(ation and speciali(ation using "igures ,-, and ,-.. -a%e !our students suggest other examples that use each of these techni+ues. Introduce the completeness constraint using "igure ,-/. 4i%e other examples here either the total speciali(ation rule or the partial speciali(ation rule is more appropriate. *iscuss the dis&ointness constraint and related notation using "igure ,-1. "or reinforcement, ha%e the students or0 6roblem 1 (6roblems and Exercises) in class. Introduce notation for a subt!pe discriminator ("igures ,-2 and ,->). *iscuss h! a different notation is re+uired for the t o cases sho n in these figures. *iscuss entit! clustering and illustrate ith "igures ,-'3 and ,-',. Re%ie the extended example of a supert!pe#subt!pe hierarch! sho n in "igure ,-'?. "or reinforcement, as0 the students to or0 problem ) (6roblems and Exercises) in class. Re%ie uni%ersal data models and discuss ho these are being used more idel! toda!. Consider in%iting an industr! guest spea0er to discuss ho these uni%ersal data models are utili(ed in his#her compan!. If !our students ha%e access to computers during !our class session, brea0 the students into small groups and ha%e them complete 6roblem @ Exercise '/ then report bac0 to the large class ith their findings. *iscuss the classification of business rules sho n in "igure ,-'2. 4i%e examples for each t!pe of rule. *iscuss the notion of structural assertions, and illustrate ith examples sho n in "igure ,'>. Introduce the notion of action assertions, and illustrate ith the examples sho n in "igure ,-)?. "or this example, sho ho the business rule is captured ith notation on the diagram. 3s0 !our students for examples of other business rules the! ha%e encountered recentl! in their or0, school, or home experience. $ee if the! can diagram these rules using the notation pro%ided in this chapter.

'). '3. ',. '..

Chapter 4

''3

!nswers to Review "uestions '. *efine each of the follo ing terms= a. upert!pe" 3 generic entit! t!pe that has a relationship ith one or more subt!pes. b. ubt!pe" 3 subgrouping of the entities in an entit! t!pe that is meaningful to the organi(ation. c. pecia#i$ation" The process of defining one or more subt!pes of the supert!pe, and forming supert!pe#subt!pe relationships. d. Entit! c#uster" 3 set of one or more entit! t!pes and associated relationships grouped into a single abstract entit! t!pe. e. tructura# assertion" 3 statement that expresses some aspect of the static structure of the organi(ation. f. %nchor object" 3 business rule (a fact) on hich actions are limited. g. ubt!pe discriminator" 3n attribute of the supert!pe hose %alues determine the target supert!pe or subt!pes. h. &ota# specia#i$ation ru#e" $pecifies that each entit! instance of the supert!pe must be a member of some subt!pe in the relationship. i. 'enera#i$ation" The process of defining a generali(ed entit! t!pe from a set of more speciali(ed entit! t!pes. &. Disjoint ru#e" $pecifies that if an entit! instance (of the supert!pe) is a member of one subt!pe, it cannot simultaneousl! be a member of t o (or more) subt!pes. 0. (ver#ap ru#e" $pecifies that an entit! instance can simultaneousl! be a member of t o (or more) subt!pes. l. %ction assertion" 3 statement of a constraint or control on the actions of the organi(ation. m. )niversa# data mode#: 3 generic or template data model that can be reused as a starting point for a data modeling pro&ect. ;atch the follo ing terms and definitions= h supert!pe 0 entit! cluster i structural assertion a subt!pe & speciali(ation d anchor ob&ect f action l subt!pe discriminator c attribute inheritance b o%erlap rule e corresponding ob&ect g deri%ed fact

).

'',

Modern Database Management, Ninth Edition

3.

Contrast the follo ing terms= a. upert!pe* subt!pe" 3 supert!pe is a generali(ed entit! t!pe that has one or more subt!pes, hile a subt!pe is a subgrouping of the entities in a supert!pe. b. 'enera#i$ation* specia#i$ation" 4enerali(ation is the process of defining a generali(ed entit! t!pe from a set of more speciali(ed entit! t!pes, hile speciali(ation is the process of defining one or more subt!pes of the supert!pe. c. %nchor object* corresponding object" 3n anchor ob&ect is a business rule on hich actions are limited, hereas a corresponding ob&ect influences the abilit! to perform an action on another business rule. d. Disjoint ru#e* over#ap ru#e. Aith the dis&oint rule an instance of a supert!pe must be a member of onl! one subt!pe at a gi%en time. Aith the o%erlap rule an instance of a supert!pe ma! simultaneousl! be a member of t o or more subt!pes. e. tructura# assertionB action assertion" 3 structural assertion expresses the static structure of an organi(ation hereas an action assertion is a statement of control on the actions of an organi(ation. f. &ota# specia#i$ation ru#e* partia# specia#i$ation ru#e" Aith the total speciali(ation rule, each instance of the supert!pe must be a member of some subt!pe in the relationship. Aith the partial speciali(ation rule, an instance of the supert!pe is allo ed not to belong to an! subt!pe. g. +%,&-*+%,&- ,(.E= In a uni%ersal data model, 63RT< represents persons and organi(ations independent of the roles the! pla! hereas 63RT< R59E contains information about a part! for an associated role. T o conditions that indicate a designer should consider using supert!pe#subt!pe relationships= a. There are attributes that appl! to some (but not all) of the instances of an entit! t!pe. b. There are relationships that appl! to some (but not all) of the instances of an entit! t!pe. The reasons for entit! clustering are= a. Complex enterprise- ide E-R diagram. b. 3bilit! to ha%e a hierarchical decomposition of data model. c. *esire to focus part of the model on an area of interest to some communit! of users. d. 3bilit! to create se%eral different entit! clusters each ith a different focus. 3n example of a supert!pe#subt!pe relationship= The supert!pe 6ER$5C has man! possible subt!pes= ;39E, "E;39E, IC"3CT, TEEC34ER, etc, assuming these different t!pes of persons ha%e some hat different attributes or participate in different relationships. In an organi(ational context, 6ER$5C ma! ha%e subt!pes of E;695<EE, C5CTR3CT5R, C7$T5;ER, 8EC*5R, ;3C34ER, etc.

,.

..

/.

Chapter 4

''.

1.

4i%e an example of a(n)= a. $tructural assertion= a person is a customer of a store. b. 3ction assertion= a customer must ha%e a credit limit greater than (ero in order to charge a purchase. 3ction assertions can be classified in three a!s. Each of the three a!s has se%eral t!pes associated ith it= a. Dased on the t!pe of result from the assertion= i. Condition= states that if something is true, than another business rule ill appl!. ii. /ntegrit! constraint= states something that must al a!s be true. iii. %uthori$ation= states a pri%ilege. b. Dased on the form of the assertion= i. Enab#er: if true, leads to the existence of the corresponding ob&ect. ii. &imer: enables or creates an action. iii. E0ecutive: causes the execution of one or more actions. c. Dased on the rigor of the assertion= i. Contro##ing: states that something must or must not happen. ii. /nf#uencing: items of interest for hich a notification must occur. 3n example of an enabler action assertion= an order can be entered into the s!stem once the customerEs credit has been %erified. 3n example of an executi%e assertion= assign a contract number to a %endor the first time that the %endor supplies ra materials to 6ine 8alle! "urniture. 3ttribute inheritance is the propert! that subt!pe entities inherit %alues of all attributes of their supert!pe(s). This propert! is important because it ma0es it unnecessar! to include supert!pe attributes redundantl! ith subt!pes. 4i%e examples of= a. $upert!pe#subt!pe relationship here the dis&oint rule applies= 6ER$5C has subt!pes ;39E and "E;39E. b. $upert!pe#subt!pe relationship here the o%erlap rule applies= 6ER$5C has subt!pes IC$TR7CT5R and $T7*ECT. The t!pes of business rules that are normall! captured in an EER diagram include terms, relationship constraints, and supert!pe#subt!pe relationships (see "igure ,-''). The purpose of a subt!pe discriminator is to determine the target subt!pe (or subt!pes) for each instance of a supert!pe. 3 pac0aged data model is most useful hen one can easil! customi(e it to the specific business (that is, the organi(ation is %er! similar to other organi(ations for the same industr! or purpose or the functional area is roughl! the same as that functional area in other organi(ations). 3s long as the pac0aged data model is for the t!pe of business or functional area, then it can generall! be customi(ed. The amount of customi(ation depends upon the t!pes of speciali(ed business rules in place for the organi(ation.

2.

>. '?. ''.

').

'3. ',. '..

''/

Modern Database Management, Ninth Edition

'/.

F#ote to instructor= 3fter registering (free) at Dill InmonEs site ith an e-mail and pass ord, !ou need to select the *ata ;odels lin0. $e%eral models are a%ailable for re%ie .G T o pac0aged data models appear as possible candidates for adaptation to the 68"C situation. The 68"C appears to combine elements from both the $39E$ and ;3C7"3CT7RIC4 pac0aged data models. The $39E$ data model ould need to be modified to include 68"C sales territories and salespersons. The $39E$ data model might also ha%e to be ad&usted to reflect 8endor pro%ision of Ra ;aterials that 68"C assembles into 6roducts that are sold. The $39E$ data model ould also need to trac0 68"C emplo!ees and s0ills. The ;3C7"3CT7RIC4 data model appears to capture the 68"C data related to transforming Ra ;aterial into 6roducts, but seems to lac0 the trac0ing of the 5rder and $ales data. 5%erall, the $39E$ pac0aged data model seems to be the most promising for adaptation to 68"CEs situation.

'1.

3 subt!pe#supert!pe hierarch! is useful hen !ou ha%e se%eral subt!pes that are also supert!pes. 3n example ould be for ban0 accounts. 3t the first le%el, !ou can ha%e sa%ings, chec0ing and loans. 7nderneath loans, there are se%eral subt!pes, including personal, auto, home, etc. 3 member of a supert!pe is al a!s a member of at least one subt!pe hen the rule of total speciali(ation applies to an EER*. a. 3n order contains man! products and a product can be part of man! orders. This fact is sho n as the orderHline associati%e entit! in "igure ,-'). b. 3n emplo!ee can be either management or union, but not both. This is sho n b! a subt!pe#supert!pe relationship in "igure ,-'). c. 3 union emplo!ee can or0 in man! or0 centers and a or0 center can ha%e man! union emplo!ees. This is sho n b! the Aor0sHin relationship in "igure ,'). d. 3 regular customer does business in a sales territor!, hile a national customer does not do business in a particular sales territor!. This is sho n in the subt!pe#supert!pe relationship for Customer in "igure ,-'). e. 3n emplo!ee can ha%e man! s0ills. This is sho n as a multi%alued attribute in "igure ,-').

'2. '>.

)?.

3 fe deri%ed facts for 6ine 8alle! "urniture= a. 3n order is supplied b! one or more suppliers. This can be deri%ed from the orderHline, uses and supplies relationships in "igure ,-'). b. The order total is calculated b! adding the product of the +uantit! times the price for each orderHline for a gi%en order. c. 3n order is produced in one or more or0 centers. This can be deri%ed from the producedHin relationship and orderHline associati%e entit! in "igure ,-'). d. 3n order is or0ed on b! one or more emplo!ees. This can be deri%ed from the producedHin relationship, the orderHline associati%e entit! and the or0s in

Chapter 4

''1

relationship in "igure ,-'). e. 3n order includes one or more product lines. This can be deri%ed from the orderHline associati%e entit! and the includes relationship in "igure ,-'). $olutions to %roblems and E&ercises '. 3n example listing follo s for a 4R3*73TE $T7*ECT= 3ttribute Came $$C Came 3ddress 4ender *ateHofHDirth ;a&orH*ept TestH$core *ata 8alue 13/->,-'2?) Iessica Iames ). 9a0e *r. ;edford 5R >.'?/ female 5ct. )3, '>/1 Computer $cience >2/

''2

Modern Database Management, Ninth Edition

).

Chapter 4

''>

3. 6lease note that the problem does not explicitl! state that $0ill is a multi%alued attribute. 4i%en the fact that examples in the text ha%e s0ill as a multi%alued attribute, e ha%e made this assumption here also. EER Cotation=

')?

Modern Database Management, Ninth Edition

3) 8isio Cotation=

Chapter 4

')'

'))

Modern Database Management, Ninth Edition

3) $ubt!pes inside $upert!pes Cotation

Chapter 4

')3

,. #ote= 3gain, e ha%e assumed that $0ill is a multi%alued attribute. $tandard EER Cotation=

'),

Modern Database Management, Ninth Edition

,) 8isio Cotation=

Chapter 4

').

,) $ubt!pes inside $upert!pes Cotation=

')/

Modern Database Management, Ninth Edition

.. Co, none of the %ehicle classifications has a uni+ue attribute or a uni+ue relationship. Instead, 8ehicle categor! li0el! should be an attribute of the 8ehicle entit! t!pe. /a.

/b.

Chapter 4

')1

/c.

/d.

')2

Modern Database Management, Ninth Edition

1. $tandard EER Cotation=

1) 8isio Cotation=

Chapter 4

')>

'3?

Modern Database Management, Ninth Edition

1) $ubt!pe in $upert!pe Cotation=

Chapter 4

'3'

2.

a. $ample definitions= E;695<EE= a person ho has signed an emplo!ment agreement or contract ith the compan!, -57R9< E;695<EE= an emplo!ee hose pa! is based on number of hours or0ed. $393RIE* E;695<EE= an emplo!ee ho recei%es a fixed salar! each pa! period. C5C$79T3CT= an emplo!ee ho has signed an emplo!ment contract and hose pa! is based on an agreed billing rate. Emplo!eeHCumber= an emplo!eeEs social securit! number. Emplo!eeHCame= an emplo!eeEs name consisting of first name, middle initial, and last name. 3ddress= an emplo!eeEs home address, consisting of street address, cit!, state, and (ip code. *ateH-ired= the date hen an emplo!ee signed an emplo!ment agreement or contract. -ourl!HRate= the pa! rate (J#hour) for an hourl! emplo!ee. 3nnualH$alar!= the base annual salar! for a salaried emplo!ee. $toc0H5ption= the annual compensation (shares#!ear) of compan! stoc0 for a salaried emplo!ee. ContractHCumber= the number on the emplo!ment contract signed b! a consultant. DillingHRate= the compensation (J#hour or other stated period) on the emplo!ment contract signed b! a consultant. b. $ample integrit!-constraint action assertions= Emplo!eeHCumber= Each emplo!ee must ha%e a uni+ue emplo!ee number. Emplo!eeHCame= Each emplo!ee must ha%e a name. 3ddress= Each emplo!ee must ha%e an address. *ateH-ired= Each emplo!ee must ha%e a date of hire earlier than or e+ual to toda!Es date. -ourl!HRate= -ourl! emplo!ees must ha%e an hourl! rate hich must be bet een J' and J'??. 3nnualH$alar!= $alaried emplo!ees must ha%e an annual salar! bet een J' and J>>>,>>>. $toc0 5ption= $alaried emplo!ees must ha%e a %alue for stoc0 option bet een ? and '?,???. DillingHRate Consultants must ha%e a billing rate bet een J? and J>>>. ContractHCumber Consultants must ha%e a contract number.

'3)

Modern Database Management, Ninth Edition

>. a. and b.

'?.

Chapter 4

'33

a. 3nchor ob&ect= resident patient b. Corresponding ob&ect= responsible ph!sician ''. Dusiness rule= K3 student ma! attend a concert onl! if that student has completed his# her home or0L= a. and b.

c.

3nchor ob&ect= student Corresponding ob&ect= -asHcompleted (home or0)

').

a. $ample definitions= 63TIECT= a person ho has been admitted to the hospital, or to a treatment program administered b! the hospital. 57T63TIECT= a person ho has been admitted to a program of treatment administered b! the hospital. RE$I*ECT 63TIECT= a person ho has been admitted for a sta! in the hospital and assigned to a bed location. RE$65C$ID9E 6-<$ICI3C= a ph!sician ho has formall! admitted to patient to the hospital. DE*= a hospital bed located ithin a room in the hospital. IsHcaredHfor= the relationship bet een a ph!sician and a patient admitted to the hospital b! that ph!sician. IsH3ssigned= the relationship bet een a resident patient and the hospital bed to hich that patient is assigned. 6atientHI*= a patientEs social securit! number. 6atientHCame= a patientEs first and last name. 3dmitH*ate= the date hen a patient as most recentl! admitted to the hospital or to a treatment program. Chec0bac0H*ate= the date hen an outpatient is scheduled for a return %isit.

'3,

Modern Database Management, Ninth Edition

*ateH*ischarged= the date hen a resident patient as discharged follo ing the most recent sta! in the hospital. 6h!sicianHI*= a uni+ue identification number for an admitting ph!sician. DedHI*= a uni+ue identification number for each hospital bed.

Chapter 4

'3.

b.

$ample integrit! constraint action assertion= 6atientHI* Each patient must ha%e a uni+ue patient I*. 6atientHCame Each patient must ha%e a first and last name. 3dmitH*ate Each patient must ha%e an admit date hich is a date no greater than toda!. Chec0bac0H*ate Each outpatient must ha%e a chec0bac0 date hich is greater than or e+ual to toda!Es date and can be null. The chec0bac0Hdate cannot be before the admitHdate. *ateH*ischarged Each resident patient must ha%e a discharge date. The date discharged cannot be before the admitHdate. 6h!sicianHI* Each responsible ph!sician must ha%e a uni+ue ph!sician id. DedHI* Each bed must ha%e a uni+ue bed I*.

'3. a. Decause onl! regular customers (as opposed to national customers) do business in a sales territor!, then not all instances of the customer entit! cluster do business in a selling unit. -o e%er, because all sales territories do business ith at least one regular customer, then all sales territories do business ith at least one instance of a customer entit! cluster. b. The attributes of item ould be the attributes of 6R5*7CT and 6R5*7CT 9ICE from "igure 3-))= 6roductHI*, 6roductH*escription, 6roductH"inish, $tandardH6rice, 6roductHlineHI*, 6roductH9ineHCame. c. The attributes of material ould be the attributes of R3A ;3TERI39, $upplies, $7669IER, and 8EC*5R from "igure 3-))= 8endorHI*, 8endorHCame, 8endorH3ddress, ContractHCumber, $uppl!H7nitH6rice, ;aterialHI*, 7nitHofH;easure, ;aterialHCame, $tandardHCost.

'3/

Modern Database Management, Ninth Edition

',. E-R *iagram from Chapter 3 6roblem 1 ith Entit! Clusters=

Chapter 4

'31

'32

Modern Database Management, Ninth Edition

', (continued) The $alesH7nit cluster can be used b! people onl! interested in ho the business is managed, ithout concern for the properties listed. The 6ropert!H9isting cluster can be used b! people ho are interested in propert! that is currentl! listed or ho o ns that propert!. '.. E-R *iagram from Chapter 3, 6roblem ') ith Entit! Clusters= There are three entit! clusters= 6ro&ectH*etail, Emplo!eeH*etail, and *eptH*etail. 6ro&ectH*etail contains the set of entities that ould be used b! one interested in the pro&ect ithout concern for the specific emplo!ees on the pro&ect. 3n assumption is that the onl! concern from the pro&ect side is to trac0 emplo!ee s0ills and location, not indi%idual emplo!ees. The Emplo!eeH*etail cluster ould be of most %alue to the user ho as interested in hat s0ills specific emplo!ees ha%e as ell as location. 5ther details are a%ailable in this cluster, such as marriage. This cluster as chosen since one can then isolate emplo!ee information ithout loo0ing at pro&ect information. The *eptH*etail cluster as chosen since one might not be concerned about %endors, ho e%er one might ant to 0no hat department a gi%en emplo!ee or0s for. In the same a!, one might ant specifics about %endors ithout needing information about emplo!ees or pro&ects.

Chapter 4

'3>

',?

Modern Database Management, Ninth Edition

Chapter 4

','

'/.

#otes to instructor= $tudent ans ers ma! %ar! depending upon their interpretation of the exercise situation. The solutions presented here are representati%e of possible ans ers, gi%en certain assumptions. These notes are presented here for !our reference=

a) 3n alternati%e solution could be to set 5R43CIM3TI5C as a supert!pe ith ICTERC39 and ENTERC39 subt!pes. -o e%er, the exercise does not indicate uni+ue attributes or special relationships bet een the proposed subt!pes and an! other entities, thus no supert!pesubt!pe hierarch! is sho n in these solutions. ;ore +uestions ould need to be as0ed of the end users to determine the appropriate model for this situation. b) 3nother possible solution to this exercise ould be to create a supert!pe of 63RT< ith subt!pes of 6ER$5C and 5R43CIM3TI5C. There is significant o%erlap of attributes bet een these t o entit! t!pes that could suggest such a solution. EER Cotation=

',)

Modern Database Management, Ninth Edition

'/) 8isio Cotation=

Chapter 4

',3

'/) $ubt!pes ithin $upert!pes Cotation=

',,

Modern Database Management, Ninth Edition

'1. F#ote to instructor= This 6roblem @ Exercise has a different ritten scenario than a similar one in
Chapter 3. The plural Kre+uested &udgment characteristicsL in Chapter 3 is semanticall! different than this exerciseEs Kre+uested &udgment characteristicL hich results in the alternate model solution sho n belo . This ma! be useful to point out to students regarding the importance of pa!ing attention to fine details hile modeling data.G

#otes' ') 6ersonHorH5rg attribute denotes 6erson or 5rgani(ation t!pe of 9egal Entit!. There is no reason to sho 6erson and 5rgani(ation as subt!pes of 9egal Entit!, as there are no special attributes or relationships identified. )) The same legal entit! cannot be both a 6laintiff and *efendant in the same Case. 3) 3lthough *E"EC*3CT has no other uni+ue attributes, it is re+uired as a subt!pe to sho the parties in%ol%ed in a C3$E. "urther, the *E"EC*3CT subt!pe is necessar! to sho the DroughtH3gainst role that is necessar! to defining the parties in a C3$E.

Chapter 4

',.

'2. EER Cotation

',/

Modern Database Management, Ninth Edition

'2) 8isio Cotation=

Chapter 4

',1

'2) $ubt!pe ithin $upert!pe Cotation=

',2

Modern Database Management, Ninth Edition

'>. EER Cotes (for all notations)= ') 3 C5C$79T3CT is either a Dusiness or Technical consultant, not both. EER Cotation=

Chapter 4

',>

'>) 8isio notation=

'.?

Modern Database Management, Ninth Edition

'>) $ubt!pe ithin $upert!pe Cotation=

Chapter 4

'.'

)?. a. $ample *efinitions C5C$79T3CT= a person ho has signed an emplo!ment agreement or contract ith the compan!, and ho is on the compan! pa!roll. D7$ICE$$ C5C$79T3CT= a consultant ho pro%ides an estimate to a customer. TEC-CIC39 C5C$79T3CT= a consultant ho pro%ides securit! ser%ices to a customer. C7$T5;ER= a business that re+uires securit! ser%ices. 95C3TI5C= one or more places of business for a customer. $ER8ICE= a securit! ser%ice that can be performed. Estimates= a ritten estimate prepared b! a business consultant for a location. $er%icesH6erformed= actual ser%ices performed b! a technical consultant at one location. EmpHI*= a consultantEs emplo!ee id. *egree= a consultantEs academic training. Dusiness Experience= a business consultantEs business experience. Tech $0ills= a technical consultantEs experience. Co%erage= ho much of an area a ser%ice co%ers for a gi%en location.
b. $ample integrit!-constraint

action assertions= EmpHI*= each consultant must ha%e a uni+ue emplo!ee id. Emplo!eeHCame= each consultant must ha%e a name. 3ddress= each consultant must ha%e an address. *egree= consultants can ha%e one, none or man! degrees. Dusiness Experience= business consultants can ha%e one, none or man! t!pes of business experience. "or each t!pe of experience, e also record the !ears. 3mount= both ser%icesHperformed and estimates can ha%e a dollar %alue associated ith the ser%ice or estimate.

'.)

Modern Database Management, Ninth Edition

)'. a.

b.

Chapter 4

'.3

c.

d.

'., e.

Modern Database Management, Ninth Edition

Chapter 4

'..

)).

#otes' ') 3 6ER$5C, in his#her E;695<;ECT, ma! hold multiple 65$ITI5Cs or not !et ha%e an assigned 65$ITI5C (this is sho n ith the ?=; cardinalit! near 65$ITI5C from E;695<;ECT). )) 3 65$ITI5C might initiall! be unfilled, or o%er time, ma! be filled ith multiple E;695<;ECT instances of 6ER$5Cs (this is sho n ith the ?=; cardinalit! near E;695<;ECT from 65$ITI5C).

'./

Modern Database Management, Ninth Edition

)3.

#otes (or EER)' ') ;emberHT!pe %alues are 4olf or Con-4olf. )) $ocial and Tennis members are considered Con-4olf members. 3 $ocial member has a 4olfHRoundsH9imit of ) and TennisHCourtsO P C. 3 Tennis member has a 4olfHRoundsH9imit of , and TennisHCourtsOP<. 3 4olf member has a 4olfHRoundsH9imit of >>> and TennisHCourtsOP<. 3) 4olf membersE %isits are trac0ed onl! if the! bring a guest. ,) If a 4uest becomes a ;ember, then 4uest records are archi%ed out of the database. .) ;emberH*ate trac0s the membership date of the ;ember.

Chapter 4

'.1

),.

#otes (or EER)' ') 5 ners ish to 0no the attendance and priceHcharged for each TI;E$95T (i.e., there is a charge ith an attendance to see e%er!thing sho n on a $CREEC in the same TI;E$95T). )) ;o%ieH$e+HCo trac0s the se+uence in hich mo%ies are sho n in the TI;E$95T (e.g., in a timeslot there might be t o trailers, follo ed b! t o commercials, follo ed b! a feature film, and closed ith a commercial).

'.2

Modern Database Management, Ninth Edition

$u**estions (or +ield E&ercises '. Common examples of EER constructs= a. $upert!pe#subt!pe relationships. 3s0 !our students to tr! to tr! to find an example of each of the rules described in the chapter= dis&oint, o%erlapping, partial speciali(ation, and total speciali(ation. 3lso, for each example, ha%e !our students identif! a candidate subt!pe discriminator. 3s0 !our students to &ustif! the use of supert!pe#subt!pe relationships for each of these examples, using the guidelines stated in the chapter. b. Dusiness rules. "or each example, as0 !our students to first state the rule using structured English (follo ing the format described in the chapter), then dra an ER diagram segment ith the rule superimposed on the diagram. ). Ae suggest that !ou use this exercise as a continuation of "ield Exercise ) in Chapter 3. 3s0 !our students to determine hether supert!pe#subt!pe relationships are formall! modeled in the corporate E-R diagrams. 3lso, as0 !our students to determine ho business rules are stated and enforced b! each organi(ation. 3. Ae suggest !ou assign this exercise in con&unction ith "ield Exercise , in Chapter 3. ,. "ollo ing are se%eral +uestions that can be used to structure this report= a. -o are business rules definedO b. Ah! are business rules important to an organi(ationO c. Ahat are alternati%e methods for capturing and expressing business rulesO d. Ahat ad%antages can an organi(ation reali(e b! formall! capturing business rulesO .. 5ne good place for students to begin ould be to perform a google search on business rules engine soft are. This ill bring them to se%eral sites, such as .tcs.com /. 5ne good Aeb site for students to go to in their research is .uni%ersaldatamodels.com

Chapter 4

'.>

%roject Case Case Questions '. <es, the abilit! to model supert!pe#subt!pe relationships is li0el! to be %er! important for a hospital. 3 modern hospital is a triumph of speciali(ation. ;an! hospital entities are li0el! to ha%e subt!pes, for example= ITE;= possible subt!pes are $uppl!, Item, and 6rescription Item 63TIECT= possible subt!pes are Inpatient and 5utpatient TE$T= possible subt!pes are $can and Dlood test 6R5CE*7RE= possible subt!pes are Diops! and $urgical <es, the business rules paradigm can be used for competiti%e ad%antage. Dusiness rules allo a business to change its processes and procedures +uic0l! in responding to en%ironmental changes. -ospitals are under intense cost pressures and ne go%ernment regulations. 6rocess impro%ements and regulations, if implemented through clear business rules, ill ma0e it easier to react to changes. <es, the entit! 8I$IT (scheduled for outpatients) is clearl! a ea0 entit!. 3 hospital has man! business rules. T o examples are the follo ing= a. 3 patient cannot be admitted to the hospital ithout a referral from a responsible ph!sician. b. 3 nurse can be reassigned to a different care center onl! b! permission of the nurse in charge of the care center here the nurse is presentl! assigned. 3 uni%ersal data model for ;ountain 8ie Communit! -ospital ould or0 out ell, since hospital applications are +uite common. 5f course, there ould still need to be customi(ation. 5ne &ustification ould be to loo0 at the cost %ersus the cost sa%ings from de%eloping a database application completel! from scratch.

).

3. ,.

..

'/?

Modern Database Management, Ninth Edition

Case Exercises '. F#ote to instructor= Ahen assigning this exercise to students, be sure to allo a sufficient amount of time for completion. The case scenario is fairl! complex and ill encourage students to do a lot of thin0ing and experimenting prior to de%eloping a or0able diagram. *ue to the large si(e of the diagram, and the necessar! notes to the diagram, this solution is presented in three parts= notes, diagram ( ithout attributes displa!ed), and a KdiagramL of the entities ith all attributes displa!ed.G Dusiness Rules#Cotes for EER* (diagram on next page)= '. 5nl! one entr! for the 6atientEs Emergenc! Contact Information is stored in the database. ). 5nl! the primar! insurance information for the 6atient is stored in the database. $econdar! insurance information (if pro%ided b! the 6atient) ill be stored in paper files. 3. Referring#6rimar! Care 6h!sician Contact information is stored as part of the 6-<$ICI3C entit! in the database. ,. ;8C- ants to trac0 the histor! of all %olunteer assignments ithin the facilit!, thus there is a need to use an associati%e entit! (859H$ER8H-I$T5R<) to trac0 o%er time the %arious %olunteer assignments, and each assignmentEs super%isor, as ell as the total amount of hours or0ed on each assignment. $ome A5R:H7CITs do not ha%e 8597CTEERs, thus a ?=; cardinalit! is re+uired on its relationship ith the associati%e entit!. .. 3 8597CTEER ma! be super%ised b! an E;695<EE or a 6-<$ICI3C at one time. 5nl! one of these Ksuper%isionL relationships is acti%e at one point in time, although both are sho n on the diagram. /. ;8C- ants to trac0 8597CTEER information at the point of application, thus it is possible that a 8597CTEER instance ma! not !et ha%e a corresponding instance of 859H$ER8H-I$T5R< in the database s!stem (this is h! there is a ?=; cardinalit! nearest the 859H$ER8H-I$T5R< associati%e entit! on the relationship from 8597CTEER). 1. 3 Registered Curse (RC) ma! direct one, none, or se%eral 9icensed 6ractical Curses (96Cs)B a single 96C ill be directed b! onl! one RC. ;8C- ishes to trac0 these RC direction responsibilities for accountabilit! and +ualit! control purposes ithin the hospital. 2. 3 "loater nurse is not assigned to a C3REHCECTER, thus this is h! there is a ?=; cardinalit! sho n near C3REHCECTER on the 3ssigned relationship. If discussion ith end users indicate additional attributes or relationships that are associated ith "loater nurses, then an alternati%e solution could be to establish a "953TER subt!pe entit! on the diagram. The addition of this "953TER subt!pe could allo the cardinalit! of the 3ssigned relationship for the C7R$E supert!pe to be changed to '=;. >. $0ill is modeled as a multi%alued attribute of TEC-CICI3C as it onl! relates to this entit! and has no additional characteristics mentioned in the case. 7nder different assumptions, an alternati%e solution could be to model $0ill as its o n entit! t!pe ith a relationship to TEC-CICI3C (and possibl! other entit! t!pes in the model). '?. 5nl! current $T3"" and TEC-CICI3C assignments to A5R:HCECTERs are necessar! for this case. ''. 5nl! current DE* to RE$I*ECT associations are necessar! in the database.

Chapter 4

'/'

CE'= EER* (Cote= attributes b! entit! are sho n on next pageB attributes omitted here to conser%e space)

'/) CE'= 3ttributes listed b! entit!

Modern Database Management, Ninth Edition

Chapter 4

'/3

). 3 clear approach is to establish t o relationships bet een RC and C3REHCECTER= *a!HinHcharge, CightHinHcharge. $ee proposed re%ision to diagram belo .

'/,

Modern Database Management, Ninth Edition

3. "ollo ing are some sample definitions= a. Entit! t!pes= %hysician- a person ho is licensed to practice medicine in this state. %atient- a person ho has been admitted to ;ountain 8ie Communit! -ospital or ho is currentl! being treated as an outpatient b! the hospital. Employee- a person ho has an emplo!ment agreement ith the hospital and ho is on the hospital pa!roll. Care center- an organi(ational unit that performs a related set of ser%ices directed to ard patient care. b. 3ttributes= 6ersonHI*- a uni+ue identifier for each person that does not %iolate pri%ac! guidelines such as those outlined in -I633 (e.g., not social securit! number). DirthH*ate- month, da!, and !ear a person as born. $pecialt!- a ph!sicianEs or nurseEs area of practice. 9ocation- the floor number and hospital ing for a or0 unit in the hospital (e.g., care center or diagnostic unit). c. Relationships= 6ro%ided- associates a resident patient ith a hospital bed. $cheduled- associates an outpatient ith an instance of a %isit to the hospital. ,. 63RT<= 6erson and 5rgani(ation#"acilit! 63RT<R59E= There are 6ersonRoles= 6atient, 6h!sician, Emplo!ee, 8olunteer. Aithin Emplo!ee there are additional roles= Curse, $taff and Technician. Aithin 6atient, there are additional roles= Resident and 5utpatient. 63RT<RE93TI5C$-I6= There are 6erson-to-6erson relationships= 6atient to 6h!sician There are also 6erson to 5rgani(ation= Curse to CareHCenterB $taff, Technician to Aor0H7nit. E8ECT$= Communication e%ents include in-person, e-mail and correspondence. Transactions e%ents include orders and tests. 6RI5RIT<HT<6E= If a patient is acute, then his status ill be resident. $T3T7$T<6E= Ahen a patient is discharged. E8ECTR59E= 6atient, Curse, 6h!sician. R59ET<6E= 6erson or 5rgani(ation. .. 3 8597CTEER ma! ha%e one E;ER4ECC< C5CT3CT. 3n E;ER4ECC< C5CT3CT ma! be for more than one 8597CTEER. 3 8597CTEER must ha%e exactl! t o RE"ERECCE$. 3 RE"ERECCE can act as a reference for more than one 8597CTEER. 3 8597CTEER must ha%e exactl! one last E;695<ER. 3n E;695<ER can emplo! more than one 8597CTEER. 3 8597CTEER ma! ha%e pre%ious %olunteer experience.

Chapter 4

'/.

3 8597CTEER ma! ha%e one or more $0ills. 3 8597CTEER also ma! ha%e no $0ills. 3 8597CTEER ma! ha%e one or more -obbies. 3 8597CTEER also ma! ha%e no -obbies. 3 8597CTEER ma! ha%e one or more Interests. 3 8597CTEER also ma! ha%e no Interests. 3 8597CTEER ma! spea0 one or more 9anguages (in addition to English). 3 8597CTEER ma! ha%e one or more TI;E$95T preferences. 3 TI;E$95T ma! be chosen b! one or more 8597CTEER$.

/.

The rule can be restated as follo s= K"or a nurse to be appointed nurse-in-charge of a care center, that nurse must possess an RC certificate.L

a. b.

3nchor ob&ect= nurse (entit!) Corresponding ob&ect= RC Certificate (entit!).

1. <ou can perform a side-b!-side comparison to sho ho the EER diagram pro%ides a more detailed and complete statement of re+uirements for the hospital. "or example, the EER diagram includes information about technicians as ell as %olunteers. %RO,ECT !$$ -#ME#T$ 6'. 3 6ER$5C can be a 63TIECT, 6-<$ICI3C, E;695<EE or 8597CTEER. 3n instance of 6ER$5C ma! be more than one of these.

'//

Modern Database Management, Ninth Edition

3 63TIECT ma! be onl! a RE$I*ECT 63TIECT or an 57T63TIECT and cannot be both. 3C 57T63TIECT is scheduled for one or more 8I$ITs. 3n 57T63TIECT can also be scheduled for no 8I$ITs. 3 8I$IT is for onl! one 57T63TIECT. 3C E;695<EE ma! onl! be a C7R$E, $T3"" or TEC-CICI3C and cannot be more than one of these. 3 C7R$E ma! be onl! a Registered Curse (RC) or 9icensed 6ractical Curse (96C) and cannot be both. 3n RC ill direct the or0 of one, none, or man! 96Cs= 96CEs or0 ill be directed b! onl! one RC. 3 TEC-CICI3C is assigned to one or more *I34C5$TICH7CITs. 3 *I34C5$TICH7CIT has one or more TEC-CICI3C$. 3 "3CI9IT< can contain one or more A5R:H7CITs or ma! contain no A5R:H7CITs. 3 A5R:H7CIT is part of one and onl! one "3CI9iT<. Currentl! defined A5R:H7CITs include C3REHCECTERs and *I34C5$TICH7CITs. 3 C3REHCECTER has at least one, and usuall! man! C7R$Es assigned to it. Each C3REHCECTER has one RC assigned as a nurseHinHcharge for the da! shift, and one RC assigned as a nurseHinHcharge for the night shift. $ome C7R$Es are floaters and are not assigned to a particular C3REHCECTER and ill or0 for more than one C3REHCECTER o%er timeB non-floater C7R$Es are assigned to a particular C3REHCECTER. 3 C3REHCECTER ma! contain one or more beds or ma! contain not DE*$, 3 DE* is contained in onl! one C3REHCECTER. 3 *I34C5$TICH7CIT performs one or more TRE3T;ECTs. 3 TRE3T;ECT is performed b! onl! one *I34C5$TIC 7CIT. 3 DE* is assigned to one RE$I*ECT 63TIECT or no RE$I*ECT 63TIECTs. 3 RE$I*ECT 63TIECT is assigned to one DE*. 3 6-<$ICI3C admits one or more 63TIECTs or admits no 63TIECTs. 3 63TIECT is admitted b! onl! one 6-<$ICI3C. 3 6-<$ICI3C ma! refer one or more 63TIECTs or ma! refer no 63TIECTs. 3 63TIECT must be referred b! one 6-<$ICI3C. 3 63TIECT ma! consume man! ITE;$ or ma! consume no ITE;$. 3n ITE; is consumed b! one or more 63TIECT$ or ma! be consumed b! no 63TIECT$. 3n ITE; is supplied b! one or more 8EC*5Rs. 3 8EC*5R ma! suppl! one or more items or ma! suppl! no ITE;s.

Chapter 4

'/1

3 6-<$ICI3C ma! rite one or more 5R*ERs or ma! rite no 5R*ERs for one 63TIECT. 3n 5R*ER is ritten b! one 6-<$ICI3C. 3n 5R*ER ma! consist of one or more ITE;s or no ITE;s. 3n ITE; ma! be part of one or more 5R*ER$ or ma! be part of no 5R*ER$. 3n 5R*ER ma! consist of one or more TRE3T;ECT$ or no TRE3T;ECTs. 3 TRE3T;ECT ma! be part of one or more 5R*ERs, or no 5R*ERs. 3 6-<$ICI3C ma! complete one or more *I34C5$E$ for one or more 63TIECTs. 3 *I34C5$I$ is Completed for one 63TIECT b! one 6-<$ICI3C.

'/2

Modern Database Management, Ninth Edition

6).

F#ote to instructor= Ahen assigning this exercise to students, be sure to allo a sufficient amount of time for completion. The case scenario is fairl! complex and ill encourage students to do a lot of thin0ing and experimenting prior to de%eloping a or0able diagram. *ue to the large si(e of the diagram, and the necessar! notes to the diagram, this solution is presented in three parts= notes, diagram ( ithout attributes displa!ed), and a KdiagramL of the entities ith all attributes displa!ed.G

Dusiness Rules#Cotes for EER* (diagram on next page)= '. 5nl! one entr! for the 6atientEs Emergenc! Contact Information is stored in the database. ). 5nl! the primar! insurance information for the 6atient is stored in the database. $econdar! insurance information (if pro%ided b! the 6atient) ill be stored in paper files. 3. Referring#6rimar! Care 6h!sician Contact information is stored as part of the 6-<$ICI3C entit! in the database. ,. ;8C- ants to trac0 the histor! of all %olunteer assignments ithin the facilit!, thus there is a need to use an associati%e entit! (859H$ER8H-I$T5R<) to trac0 o%er time the %arious %olunteer assignments, and each assignmentEs super%isor, as ell as the total amount of hours or0ed on each assignment. $ome A5R:H7CITs do not ha%e 8597CTEERs, thus a ?=; cardinalit! is re+uired on its relationship ith the associati%e entit!. .. 3 8597CTEER ma! be super%ised b! an E;695<EE or a 6-<$ICI3C at one time. 5nl! one of these Ksuper%isionL relationships is acti%e at one point in time, although both are sho n on the diagram. /. ;8C- ants to trac0 8597CTEER information at the point of application, thus it is possible that a 8597CTEER instance ma! not !et ha%e a corresponding instance of 859H$ER8H-I$T5R< in the database s!stem (this is h! there is a ?=; cardinalit! nearest the 859H$ER8H-I$T5R< associati%e entit! on the relationship from 8597CTEER). 1. 3 Registered Curse (RC) ma! direct one, none, or se%eral 9icensed 6ractical Curses (96Cs)B a single 96C ill be directed b! onl! one RC. ;8C- ishes to trac0 these RC direction responsibilities for accountabilit! and +ualit! control purposes ithin the hospital. 2. 3 "loater nurse is not assigned to a C3REHCECTER, thus this is h! there is a ?=; cardinalit! sho n near C3REHCECTER on the 3ssigned relationship. If discussion ith end users indicate additional attributes or relationships that are associated ith "loater nurses, then an alternati%e solution could be to establish a "953TER subt!pe entit! on the diagram. The addition of this "953TER subt!pe could allo the cardinalit! of the 3ssigned relationship for the C7R$E supert!pe to be changed to '=;. >. $0ill is modeled as a multi%alued attribute of TEC-CICI3C as it onl! relates to this entit! and has no additional characteristics mentioned in the case. 7nder different assumptions, an alternati%e solution could be to model $0ill as its o n entit! t!pe ith a relationship to TEC-CICI3C (and possibl! other entit! t!pes in the model). '?. 5nl! current $T3"" and TEC-CICI3C assignments to A5R:HCECTERs are necessar! for this case. ''. 5nl! current DE* to RE$I*ECT associations are necessar! in the database. '). 3 C7R$E prepares one, none, or man! 3$$E$$;ECTs of 63TIECTsB 3 63TIECT recei%es one to man! 3$$E$$;ECTs o%er time. '3. 3ssessmentHI* is uni+ue (surrogate) identifier for 3$$E$$;ECT. ',. 3 *I34C5$TICH7CIT is defined to include 9abs and other hospital A5R:H7CITs that perform procedures, tests, and treatments re+uired b! 5R*ERs. 3 *I34C5$TICH7CIT performs one to man! TRE3T;ECTsB 3 TRE3T;ECT is performed b! one *I34C5$TICH7CIT.

Chapter 4

'/>

'1?

Modern Database Management, Ninth Edition

Chapter 4

'1'

63. F#ote to instructors= $tudent ans ers ma! %ar! slightl!B these issues are presented as a possible representation of issues hich ma! be identified. 3n in-class comparison#contrast of selected student ans ers to this assignment and that from the prior chapter ould be a good hands-on exercise for exploring the upcoming chapter . topic of merging issues (homon!ms, s!non!ms, transiti%e dependencies, and supert!pe#subt!pe relationships). Comparing#contrasting the diagrams could lead to a useful discussion of the importance of understandin* the meanin* o( the data in order to resol%e issues and ensure appropriate capture of the end userEs data re+uirements.G $ome issues that come up during the merging= - $hould there be a relationship bet een *I34C5$TICH7CIT and TEC-CICI3CO - 3re items consumed b! both resident patients as ell as outpatientsO (diagram sho s current assumption is Q<esE) - Ahat needs to be done to the data model to allo for follo up care for discharged patients. - Ae 0ept the 3dmits relationship bet een 63TIECT and 6-<$IC3C in place of the Responsible used in the original EER model (Case Exercise ', Chapter ,)B is this a correct understanding of the relationship, or is another relationship re+uired to sho the Responsible associationO - Ae assumed that the C7R$E subt!pe (both RC and 96C) participates in the 3$$E$$;ECT of 63TIECTs and reflects the same relationship as sho n b! the E;695<EE relationship to 3$$E$$;ECT in Chapter 3. *o other E;695<EE subt!pes (e.g., $T3"" or TEC-CICI3C) prepare such 3$$E$$;ECTsO *o both t!pes of C7R$Es prepare 3$$E$$;ECTsO - Ae assumed that a *I34C5$TICH7CIT is defined to include 9abs and other hospital A5R:H7CITs that perform procedures, tests, and treatments re+uired b! 5R*ERs. Is this a correct assumption or are there other A5R:H7CITs that need to be trac0ed in the databaseO - In chapter 3, a business rule as indicated that E;695<EEs are 3ssigned to C3REHCECTERs and that -oursHAor0ed needed to be trac0ed for each such assignment in the database. Ae interpreted this to mean the C7R$E subt!pe in the chapter , EER diagram and ha%e added the -oursHAor0ed attribute to the ;=C 3ssigned relationship in the diagram. - In chapter 3, the identifier for the DE* ea0 entit! as described as a composite identifier including DedHCo, CareHCenterHI*, and RoomHCo. In chapter ,, the identifier for the DE* ea0 entit! as described as a composite identifier including DedHCo and RoomHCo. The correct identifier needs to be %alidated ith the end users and finali(ed in the EER diagram listing of entities.