Chapter 5: Modeling Complex Relationships Data Modeling and Database Design.

Chapter 5:Modeling Complex Relationships

Data Modeling and Database Design

Chapter 5 – Modeling Complex Relationships 2

Myths About Data Modeling Commonly Mistaken as Fact

Myth 1 Relationship types beyond degree 2 (binary) are rarely found in real-world applications, so they are not crucial for data modeling & database design

The Fact Designers in the real world often are not afforded an opportunity to consider relationship types beyond degree 2 during data modeling; the inadequacy of CASE tools renders the designer’s data modeling vision myopic!

Myth 2 Even complex real-world phenomena can be simplified and captured accurately using binary relationship types

The Fact Costly errors occur in database design when genuinely ternary (n-ary) relationships are inadvertently modeled as a set of binary relationships and vice versa

Myths About Data Modeling Commonly Mistaken as Fact (continued)

Myth 3 Complex business rules cannot be modeled using simple data modeling constructs like binary/unary relationships

The Fact Intricate modeling ideas can be employed to develop elegant and accurate database designs using simple data modeling constructs



Vignette 1• A college often offers many courses, and a college term may be

divided into four quarters (fall, winter, spring, and summer) during which one or more of these courses may be offered– Let us even say that in every quarter at, least 23 courses are

offered• The college also has several instructors, but not all instructors teach

during all quarters– Further, instructors are capable of teaching a variety of courses

that the college offers– If we wish, we can also state finer specifications such as the

minimum number of instructors teaching in a quarter, the minimum number of quarters in which an instructor teaches, etc.

• Tentatively, let us just say that at least one instructor teaches per quarter and that each instructor must teach at least one quarter


Which Instructor Teaches What Course in Which Quarter?

INSTRUCTOR COURSE

QUARTER

Can_teach

Teaches_during

Offered_during

m n

n

n

4

4

NameQualification Cname

Credits

Course#

Qtr_ref

Quarter

Rank

Year

Qtr_prefix

Figure 5.1 An initial ER diagram for Vignette 1


Can_teach Teaches_during Offered_during

Name Course# Name Quarter Course# Quarter

Pezman EE812 Pezman Fall EE330 Fall

Pezman EE832 Pezman Winter EE330 Spring

Pezman EE330 Pezman Spring EE330 Summer

Pezman EE430 Fite Fall EE340 Winter

Fite EE812 Fite Spring EE430 Fall

Fite EE430 Hall Winter EE430 Spring

Fite EE821 Hall Spring EE430 Summer

Hall EE821 Hall Summer EE812 Fall

Hall EE430 Cords Fall EE812 Spring

Hall EE812 Cords Winter EE821 Winter

Stansbury EE430 EE832 Winter

Cords EE340

Cords EE435

Figure 5.1: Sample Data Sets For Vignette 1


INSTRUCTOR COURSE

QUARTER

Can_teach

Teaches_during

Offered_during

m n

n

n

4

4

NameQualification Cname

Credits

Course#

Qtr_ref

Quarter

Rank

Year

Qtr_prefix

Teachesm n

Figure 5.2 A second ER diagram for Vignette 1

An Instructor Need Not Actually Teach What He or She Can Teach


Can_teach Teaches_during Offered_during Teaches

Name Course# Name Quarter Course# Quarter Name Course#

Pezman EE812 Pezman Fall EE330 Fall Pezman EE812

Pezman EE832 Pezman Winter EE330 Spring Pezman EE832

Pezman EE330 Pezman Spring EE330 Summer Pezman EE330

Pezman EE430 Fite Fall EE340 Winter Fite EE812

Fite EE812 Fite Spring EE430 Fall Fite EE430

Fite EE430 Hall Winter EE430 Spring Hall EE821

Fite EE821 Hall Spring EE430 Summer Hall EE430

Hall EE821 Hall Summer EE812 Fall Cords EE340

Hall EE430 Cords Fall EE812 Spring Cords EE435

Hall EE812 Cords Winter EE821 Winter

Stansbury EE430 EE832 Winter

Cords EE340

Cords EE435

Figure 5.2: Second Sample Data Sets For Vignette 1


INSTRUCTOR COURSE

QUARTER

Schedule(0,n) (0,m)

(1,p)

Rank NameQualification

Credits

Course#

Qtr_ref

Year

Qtr_prefix

Quarter

Can_teach

(1,q)(1,r)

Teaches_by According_to

Included_in

Cname

Note: A ternary relationship type is of degree three and is signified by three edges emanating from the relationship diamond to the participating entity types

Figure 5.3 The ternary relationship type Schedule

The Course(s) an Instructor Can Teach and the Course(s) an Instructor is Scheduled to Teach in Various Quarters Can Be Different


Can_teach Schedule Name Course# Name Course# Quarter Pezman EE812 Pezman EE812 Spring Pezman EE832 Pezman EE832 Winter Pezman EE330 Pezman EE330 Fall Pezman EE430 Pezman EE330 Spring Fite EE812 Fite EE812 Fall Fite EE430 Fite EE430 Fall Fite EE821 Fite EE430 Spring Hall EE821 Hall EE821 Winter Hall EE430 Hall EE430 Spring Hall EE812 Hall EE430 Summer Stansbury EE430 Cords EE340 Cords EE435

Figure 5.3: Sample Data Set


INSTRUCTOR SCHEDULE COURSE

QUARTER

Teaches_by According_to

Included_in

Figure 5.4 Modeling the ternary relationship type Schedule of Figure 5.3 as a base entity type

RankQualification Call# Room

No_of_students

Credits

CnameCourse#

Quarter

Qtr_ref

Year

Qtr_prefix

(1,n) (0,1) (1,1) (0,m)

(1,1)

(1,p)

Note: In this conceptualization it is possible to show that a course can be scheduled for a quarter without any instructor assignment (see the bolded 0 in the Teaches_by relationship connector to SCHEDULE). It is not possible to do the same in the design shown in Figure 5.3.

A Ternary Relationship Type May Lend Itself to be Modeled as a Base Entity Type


INSTRUCTOR COURSE

BOOK

Uses(0,n) (0,m)

(1,p)

Figure 5.5 The ternary relationship type Uses

Author

Title

Isbn#

Rank NameQualification

Credits

Cname

Course#

A Ternary Relationship Type That Does Not Lend Itself to be Modeled as a Base Entity Type


Get Well Pharmacists, Inc. has numerous pharmacies across the state of Ohio. A pharmacy dispenses medication to patients. It is imperative that the records at Get Well, Inc. always have the data on which of its pharmacies dispensed what medication to which patient.

In addition, every pharmacy stocks numerous different medicines and the same medicine is carried in several pharmacies. A patient often takes one or more medicines, and the fact that the same medicine may be used by at least one and often many patients can also be a meaningful relationship.

Finally, a pharmacy typically has one or more patients as customers, and some patients use one or more pharmacies. To make the story a little more interesting, let us impose another business rule (V2R1) that a particular physician prescribes a certain medication to a specific patient.

Vignette 2 – Get Well Pharmacists, Inc.


PATIENT

PHARMACY

MEDICATION

PHYSICIAN

Dispenses

Figure 5.6 Two ternary relationship types Dispenses and Prescribes

Prescribes

Pat_name Occupation

Insurance

Patient_id

Pharm# Location

Working_hrs

Day

TimeFrom

To

Price Expiration_dt

Med_code Med_name

List_price

Dosage Frequency

Experience

Physician# Name Phone

Speciality

(1,q)

(1,p)

(0,n)

(0,r) (0,s)

(1,m)

An ER Diagram For Vignette 2: Alternative 1


PATIENT

PHARMACY

MEDICATION

PHYSICIAN

Dispenses

Figure 5.7 Representing the Prescribes relationship type as the PRESCRIPTION base entity type

Age

Pat_name Occupation

Insurance

Patient_id

Pharm# Location

Working_hrs

Day

TimeFrom

To

Price Expiration_dt

Med_code Med_name

List_price

Experience


Speciality

Receives

PRESCRIPTION

Is_for

Writes

Prescription# Date

(1,q) (0,n)

(1,p)

Dosage Frequency

(0,r)

(1,1)(1,1)

(0,s)

(1,1)

(1,m)

An ER Diagram For Vignette 2: Alternative 2


Madeira College, originally introduced in Vignette 1, has students as well. Students must declare a major field of study and in fact can enroll in up to three different majors. Every major has some students.

The advising office of the college has staff specially trained in advising in each major. An advisor is restricted to two majors by training. Every major has exactly two trained advisors. A student can have multiple advisors for each major he or she enrolls in, but must have at least one advisor per major.

Therefore, it is imperative that information is recorded about which advisor advises which student for what major.

Vignette 3 – More on Madeira College


ADVISOR STUDENTAdvising

MAJORTrained_in Enrolling

(1,2)

(2,2) (1,q)

(1,3)

(1,m) (1,p)

(1,n) Stu_idStu_name

MajorExperience

Name Phone#

Major_nameCollege

Department

Trainer

Trainee

Advisor Advisee

Enrollee

Enroller

(a)ER diagram for the scenario described in Vignette 3

Note: The “Advisee” edge of the Advising relationship type indicates that a student must be related to at least 1 {major, advisor} pair and may be related to up to p {major, advisor} pairs. (e.g., SID 123 in Figure 5.8b has three different major/advisor combinations and SID 345 also has three different major/advisor combinations but only two different majors and two different advisors).

Figure 5.8a: The Relationship Types for Vignette 3


Advising Stu_id Major_name Name 123 Physics Hawking 123 Music Mahler 123 Chemistry Kouri 456 Literature Michener 789 Music Bach 678 Physics Hawking 456 Music Bach 345 Physics Kouri 345 Physics Hawking 345 Chemistry Kouri

Sample Data For the Advising Relationship in Figure 5.8a


A New Business Rule (V3R1)

An advisor may advise a student for only one major

Another New Business Rule (V3R2)

No more than one advisor may advise the same student for the same major

Vignette 3 – Two New Business Rules


ADVISOR STUDENTAdvising

MAJORTrained_in Enrolling

(1,2)

(2,2) (1,q)

(1,3)

(1,m) (1,1)

(1,n) Stu_idStu_nameName Phone#

Major_nameCollege

Department

Enrollee

Enroller

Advisee

Trainer

Trainee

Advisor

Advised_for

(a)

Experience Major

Figure 5.9 Changing the maximum cardinality of the “Advisee” edge in Figure 5.8a from p to 1

A Student May Have as Many as 3 Majors; But, Has Exactly One Advisor and That Too For No More Than One Major


Advising*

Stu_id Major_name Name 123 Physics Hawking 123 Music Mahler 123 Chemistry Kouri 456 Literature Michener 789 Music Bach 678 Physics Hawking 456 Music Bach 345 Physics Kouri 345 Physics Hawking 345 Chemistry Kouri

Note: A student is restricted to one major/advisor combination. *Removal of shaded rows from the data set enforces the restriction of one major/advisor pair per student

(b)

The Effect of Restricting a Student to One {Major, Advisor} Pair


Table 5.1 Revised Advising data set

Note: An advisor is limited to advising a student in only one major.

*Removal of shaded row enables a constraint that limits an advisor to advising a student in only one major.

Advising* Stu_id Major_name Name

123 Physics Hawking 123 Music Mahler 123 Chemistry Kouri 456 Literature Michener 789 Music Bach 678 Physics Hawking 456 Music Bach 345 Physics Kouri 345 Physics Hawking 345 Chemistry Kouri

(b)

Vignette 3 – More on Madeira College (continued)


Figure 5.10 The relationship type I n-charge_of with the cluster entity type COUNSELI NG

ADVISORSTUDENT

MAJOR

Stu_id

Major_name

College

DepartmentIn_charge_of

(1,1)

COUNSELING

(1,n)

Is

Takes_charge

Counseling(1,m)

(1,p)Counseled

Counselor

Name

Cluster Entity Type



Figure 5.10The relationship type I n_charge_of with the cluster entity type COUNSELI NG

ADVISORSTUDENT

MAJOR

Stu_idName

Major_name

College

DepartmentIn_charge_of

(1,1)

COUNSELING

(1,n)

Is

Takes_charge

Counseling

Business Rule V3R1: An advisor may advise a student f or only one major

A student may have multiple advisors;A student may also have multiple majors (max = 3)But, a student may not have the same advisor f or more than one major

A {Student, Advisor} pair can be related to only one major, while a major can be related to many such pairs

I n other words:

An advisor may advise a student f or only one major – V3R1;But, a student can have multiple advisors f or the same major

Cluster Entity Type



Table 5.2 Advising data: Next revision

Note: A student is limited to only one advisor in one major. *Row shaded allows the restriction that limits a student to only one advisor in each major to be enforced.

Advising Data Set* SID Major Advisor

123 Physics Hawking 123 Music Mahler 123 Chemistry Kouri 456 Literature Michener 789 Music Bach 678 Physics Hawking 456 Music Bach 345 Physics Kouri 345 Physics Hawking 345 Chemistry Kouri

(b)



ADVISORSTUDENT

MAJOR Enrolling(1,q)

(1,3)

Figure 5.11 The relationship type Assignment with the cluster entity type ENROLLMENT

Stu_idStu_name

MajorEmp_id

Phone#

ENROLLMENT

Assignment

Major_nameCollege

Department

Enrollee

Enroller

Name

A student may enroll in up to three majors and a major can enroll many students; however, no more than one advisor can be assigned to the same student for the same major

Business Rule (V3R2)

No more than one advisor may advise the same student for the same major



ADVISORSTUDENT

MAJOR Enrolling(1,q)

(1,3)

Figure 5.12 Two cluster entity types: COUNSELI NG and ENROLLMENT

Stu_idStu_name

MajorEmp_id

Name

Phone#

ENROLLMENT

Assignment

(1,r

)

Major_nameCollege

Department

In_charge_of

(1,1)

Trained_in

COUNSELING

(2,2)

(1,2) Enrollee

EnrollerTrainer

Trainee

Adv

ise

(1,1

)

(1,n)

Is

Takes_charge

Assign

ed_t

o

Counseling(1,m)

(1,p)Counseled

Counselor

Exactly one advisor per enrollment and exactly one major per counseling



Entity Clustering

• Entity clustering is a useful abstraction to present an ER diagram at a broader level of conceptualization

• The technique enables a bottom-up consolidation of natural groupings of entity types

• A cluster entity type literally emerges as a result of a grouping operation on a collection of entity types and relationship(s) among them

• Some database design applications lend themselves to a repeated roll-up to higher levels of abstractions through clustering and provide an opportunity to conceptualize a layered set of ER diagrams

Entity Clustering (continued)

• A layered set of ERDs can be especially useful for large database design projects where the different layers within the Presentation Layer ER diagram can be used to inform the end-user hierarchy (e.g., executives, managers, staff, etc.)

• Even for an office staff working at the detail level of a business, a layered presentation can facilitate a quicker understanding of the semantics captured by the design when presented through a cascading set of ER diagrams



Vignette 4Vignette 3 demonstrated the use of a new ER modeling grammar construct, namely, the cluster entity type using a simple example. In the vignette that follows a slightly more complex entity clustering is demonstrated.

Surgeons perform surgeries on patients to treat illnesses. Also, a surgery event pertains to a certain surgery type, and there can be numerous surgeries of a certain surgery type. Suppose there is a need to keep track of which surgeons perform what surgery(ies) on which patient(s) to treat what illness(es) for insurance purposes.

In fact, the primary insurance covers such treatments. However, all treatments are not necessarily covered by insurance.

TREATMENTPRIMARY_

INSURANCECovers

(1,n)(0,1)

Figure 5.13(b)TREATMENT is a Roll-up of a cluster entity type

Policy_no

Company_name

Face_value


PATIENT

ILLNESS

SURGEON

Performs

(a)A cluster entity type, TREATMENT containing more than one relationship types

Gender Age

Pat_name OccupationPatient_id

Ill_code Ill_name

Experience


Speciality

Symptoms

TheatreSupport_staff

SURGERY

Includes

SURGERY_TYPE

Anotamy

Code

Name

Event_seq

(0,q) (1,n)

(1,m)

(0,p)

(0,n)

(1,1)

TREATMENT

CoversPRIMARY_

INSURANCE

(1,n)

(0,1)Policy_no

Company_name

Face_value

- - - - - - - -

Special_needSeq#

Date

Figure 5.13 Modeling Vignette 4 with a cluster entity type

Base entity type TREATMENT exploded as a cluster entity type

Vignette 4 (continued)


INSTRUCTOR COURSE

QUARTER

Offering(0,n) (0,m)

(1,p)

Figure 5.14 An example of the cluster entity type SECTI ON emerging as a product of a quarternary relationship type

Employee_id NameQualification

Credits

Name

Course#

Quarter

Year

Qtr_prefix

Qtr_name

TIME_SLOTPeriod

Start

End

SECTION

Room#

(0,q)



INSTRUCTOR COURSE

QUARTER

Offering(0,n) (0,m)

(1,p)

Figure 5.15 An alternate representation of the cluster entity type SECTI ON(TI ME_SLOT reduced f rom a base entity type to a mandatory multi-valued attribute of Off ering)

Note: The semantics of the cluster entity type has changed.

NameQualification

Credits

Course#

Quarter

Year

Qtr_prefix

Qtr_nameName

Room#

Start End

Timeslot

SECTION

Employee#



INSTRUCTOR COURSE

QUARTER

Offering(0,n) (0,m)

(1,p)

Figure 5.16 The quintary relationship type Off ering


Credits

Name

Course#

Quarter

Year

Qtr_prefix

Qtr_name

TIME_SLOTPeriod

Start

EndCLASS_ROOM

Location

Room#

Bldg#

Capacity

(0,q) (0,r)

SECTION

A richer conceptualization of a course SECTION



INSTRUCTOR COURSE

QUARTER

Offering(0,n) (0,m)

(1,p)

Figure 5.17 Reducing Off ering in Figure 5.16 to a ternary relationship type with a mandatory multi-valued attribute Section

Note: The semantics of the relationship type has changed

NameQualification

Credits

Course#

Quarter

Year

Qtr_prefix

Qtr_name

Name

Section

Time_slot

From To

Location

Room# Bldg#

Employee_id

SECTION



INSTRUCTOR COURSE

QUARTER

Offering(0,m)

(1,p)

Employee_id

Name

Qualification

Credits

Name

Course#

Quarter

Year

Qtr_prefix

Qtr_name

CLASS_ROOM

Location

Room#

Bldg#

Capacity

Section#-----------

Time_slot

From To

Teaching(0,n)

Teaches

(1,1)

INSTRUCTOR COURSE

QUARTER

Offering(0,m)

(1,p)

Employee_id

NameQualification

Credits

Name

Course#

Quarter

Year

Qtr_prefix

Qtr_name

CLASS_ROOM

Location

Room#

Bldg#

Capacity

Teaching(0,n)

Teaches

(1,1)

(a)I ncorrect representation of Teaching relationship type

(b)Correct representation of Teaching relationship type

Taught_by

SECTION

SECTION

Taught_by

(0,q)

(0,q)

Section

Section#-----------

Time_slot

From To

Section

Figure 5.18 Prohibition of “team-teaching” modeled in the Teaching relationship type

A course section is taught by only one instructor – i.e., no team-teaching of course sections



COURSE

QUARTER

Offering(0,m)

(1,p)

Figure 5.20 STUDENT enrolled in a course Off ering using a TEXTBOOK modeled as a quintary relationship type

Credits

Name

Course#

Quarter

Year

Qtr_prefix

CLASS_ROOM

Location

Room#

Bldg#

Capacity

Qtr_name

TEXTBOOK

STUDENT(1,q)

(0,r)

(0,n)

Title

Isbn#

Author

Stu_idStu_name Major

Note: This ER diagram allows a course section in a quarter when held in one classroom to use one book for one student and to use a different book for another student. This does not reflect the intended semantics of the story.

Section#-----------

Time_slot

From To

Section



COURSE

QUARTER

Offering(0,m)

(1,p)

Credits

Name

Course#

Quarter

Year

Qtr_prefix

Qtr_name

CLASS_ROOM

Location

Room#

Bldg#

Capacity

Enroll(1,n) (1,m)

SECTION

(0,q)

Section#-----------

Time_slot

From To

Section

Figure 5.21 A more sensible rendition of the design intended in Figure 5.20

STUDENT

Stu_id

Stu_name

Major

Use

TEXTBOOK (0,n)

(0,m)

Author

Title

Isbn#



INSTRUCTOR

QUARTER

Offering

(1,p)

Figure 5.22 ER diagram for Madeira College - The rest of the story

NameQualification

Quarter

Year

Qtr_prefix

Employee_id

COURSE

Qtr_name

UseTeaching

Enroll

Offering

STUDENT

TEXTBOOK

CLASS_ROOM

(1,n)

(1,m)

(0,m)

(0,n)

(0,m) (1,1)

Author

Title

Isbn#

Stu_idStu_name

Major

Course# NameCredits

Location

Room#

Bldg#

Capacity

SECTION

(0,m) (1,1)

(0,4)

Section#-----------

Time_slot

From To

Section

Note: A course section can be held in only one classroom and can be taught by only one instructor



Companies often use consultants on a contract basis to do some work and often have different types of boilerplate contracts that can be simply reviewed on a year-to-year basis

COMPANY CONSULTANTContract

LocationSize

NameLocation

SizeName

(0,n) (1,m)

Client Contractor

ContractContract#

Year

Figure 5.23 Contract as a binary relationship type

Note: COMPANY and CONSULTANT are identical entity types (same set of attributes)



COMPANY

LocationNameSize

Contract

Client(0,n)

(1,m)Contractor

Contract

Contract#

Year

Figure 5.24 Contract as a recursive relationship type


LocationSize

NameLocation

SizeName

(0,n) (1,m)

Client Contractor

ContractContract#

Year

Figure 5.23 Contract as a binary relationship type

Since COMPANY and CONSULTANT in Figure 5.23 are identical entity types meaning a consultant is also a company, the relationship type Contract can be modeled as a recursive relationship type.



COMPANY

LocationNameSize

Contract

Client(0,n)

(1,m)Contractor

Contract# Year

Contract

Linked_with

PROJECT

(1,1)

(0,n)

Pno

Pname

Location

Note: ER modeling grammar does not permit an edge connecting two relationship types

Figure 5.25a I ncorrect representation of the Linked_with relationship type



COMPANY

LocationNameSize

Contract

Client(0,n)

(1,m)Contractor

Contract# Year

Contract

Linked_with

PROJECT

(0,n)

CONTRACT

(1,1)

PnoPname

Location

Figure 5.25b I nvolving the cluster entity type CONTRACT in the Linked_with relationship type



A flight may connect to several other flights in an airport. Thus, flight connection information is crucial to the airline and its passengers.

Note that a particular flight connection must happen in an airport (not in mid-air), and that too in only one airport.



FLIGHT

Flight#

Connect

Flight(0,n)

(0,m)Connects_flight

Is_at

AIRPORT

(1,1)

(0,n)

OriginDestination

Note: ER modeling grammar does not permit an edge connecting two relationship types

Day------

Flight_gateConnect_gate

Connect_time

Connection

Ap_code Ap_name

City

Figure 5.26a Syntactically incorrect representation of the I s_at relationship type



FLIGHT

Flight#

Connect

Flight(0,n)

(0,m)Connects_flight

Is_at

AIRPORT

(0,n)

OriginDestination

Day------

Flight_gateConnect_gate

Connect_time

(1,1)

Figure 5.26b Syntactically correct representation of the I s_at relationship type

FLIGHT_CONNECTION

Connection

Ap_code Ap_name

City



EMPLOYEE PLANT

Works_in

Manages

(100, n)

(1,1)

(0,1)

Fname

Gender

Emp#

SalaryAddress

Name

Lname

Minit

Date_hired

Pl_name

Pnumber

Budget

Building

No_of_employeesMgr_start_dt

Name_tag

No_of_dependents

(1,1)

Worker Employer

Manager

Managed_by

Figure 5.27 The Works_ in and Manages relationship types f rom Figure 3.5

What if we have a business rule that stipulates: In order for an employee to manage a plant the same employee must work for the same plant?



Weak Relationship Types

• An inter-relationship constraint arises in many real-world situations when two relationship types are linked by:– An event precedence sequence or

– A condition precedence sequence

• A weak relationship type in the ER modeling grammar facilitates modeling such inter-relationship constraints

• A weak relationship can be inclusion-dependent on another relationship

Or• Two weak relationships can be exclusion-dependent

on each other


Dependencies in Weak Relationship Types

• Inclusion Dependency vs. Exclusion Dependency• While inclusion dependency indicates a subset

relationship between a regular relationship type and a weak relationship type, exclusion dependency can be used to model scenarios of mutual exclusion between relationship types


Revisit - Bearcat

Recall that in Bearcat Incorporated, business rules indicate that a plant has employees and some plant employees hold the position of managers of these plants. Let us now change this rule as follows.

All employees need not be working at the plants because some are in the corporate office and others are in the regional offices of Bearcat Incorporated.

However, we are not presently interested in modeling activities anywhere other than in the plants. Also, a plant manager should be a plant employee.


EMPLOYEE PLANT

Works_in

Manages

(100, n)

(1,1)

(0,1)

Fname

Gender

Emp#

SalaryAddress

Name

Lname

Minit

Date_hired

Pl_name

Pnumber

Budget

Building

No_of_employees

Mgr_start_dt

Name_tag

No_of_dependents

(0,1)

Worker Employer

Manager

Managed_by

Figure 5.28 Manages as a (condition-precedent) weak relationship type

“Works_in” precedes “Manages”

Business rule: In order for an employee to manage a plant, the same employee must work for the same plant

Manages is said to be “inclusion-dependent” on Works_in since in order for a relationship Manages to exist between a plant and an employee, a Works_in relationship must exist between the same employee and the same plant

Revisit – Bearcat (continued)


INSTRUCTOR COURSECan_teach

NameQualification NameCourse#

Employee_id

Credits

Teaches

(1,n) (1,m)

(2,q)(1,r)

Figure 5.29 Teaches as a (condition-precedent) weak relationship type

Let’s revisit Vignette 1: In order for an instructor to teach a course, he or she should be capable of teaching that course

Teaches is “inclusion-dependent” on Can_teach

Let’s Revisit…


PATIENT

PHARMACY

MEDICATION

Figure 5.30 Dispenses as an (event-precedent) weak relationship type

Age

Pat_name Occupation

Insurance

Patient_id

Pharm#

LocationWorking_hrs

DayFrom

To

Price

Expiration_dt

Med_codeMed_name

List_price

(1,q)

(1,p)

(0,n)

Time

Stocks

On_hand On_order

Lead_time

Dispenses

(0,m)

(2000,r)

Gender

Note: It is also possible to view this as a condition-precedent weak relationship based on the storyline.

Let’s revisit Vignette 2: A medication must be stocked by a pharmacy before it can be dispensed to a patient

Dispenses is “inclusion-dependent” on Stocks

Let’s Revisit… (continued)


CUSTOMER VEHICLERents

NameGender MakeVehicle_id

Drv_License#

Type

Returns

(1,m) (0,n)

(1,m)(0,n)

Figure 5.31 Returns as an (event-precedent) weak relationship type

Returns is “inclusion-dependent” on Rents

In order to return a vehicle, a customer should have rented the same vehicle



EMPLOYEE

DEPENDENT

BCU_ACCOUNT

Dependent_of

Held_by_D

Held_by_E

Note: The exclusive arc indicates that the relationship types Held_by_E and Held_by_D are mutually exclusive – i.e., Held_by_E and Heled_by_D are mandatorily exclusive.

(0,m)

(0,1)

(0,n)

(1,1)

(0,m)

(0,1)

Figure 5.32 An excerpt f rom Bearcat I ncorporated demonstrating the use of exclusive arc

Business Rule: A joint-account between an employee and a dependent is prohibited



EMPLOYEE

DEPENDENT

BCU_ACCOUNT

(0,m)

(0,1)

(0,n)

(1,1)

(0,m)

(0,1)

Held_by_E

Held_by_D

Dependent_of

Figure 5.33 The exclusive arc of Figure 5.32 portrayed using exclusion dependency between weak relationship types

Business Rule: A joint-account between an employee and a dependent is prohibited

Held_by_E and Held_by_D are exclusion-dependent on each other – hence no directional arrow



NURSE SURGERY_SKILL SURGERY_TYPENurse_skill Req_skill(1,m) (0,n) (0,p) (1,q)

Assigned_to

Figure 5.34 A weak relationship type inclusion-dependent on a composite relationship type

(0,r) (1,s)

Emp_id GradeName

S_code

Name Anat_locationSkill_code NameLevel

Inclusion Dependency in a Composite RelationshipType

Business rule: In order for a nurse to be assigned to a surgery type, that nurse should have the surgery skills that the surgery type requires

Assigned_to is inclusion-dependent on the composite (intersection) of Nurse_skill and Req_skill


RESTAURANT FOOD_ITEM BANQUET(0,m) (1,n) (1,n) (0,p)

Can_cater(50,q) (7,r)

Id

Name Address

RatingCuisine

Caters Contains

Product_code

Food_typeCost

Invoice_no Address

Bill_to

Figure 5.35 A weak relationship type inclusion-dependent on a composite relationship type: A second example

Inclusion Dependency in a Composite Relationship Type – 2nd Example

Business rule: A restaurant can cater to a banquet only if that restaurant caters food items that are on the banquet’s menu

Can_cater is inclusion-dependent on the composite (intersection) of Caters and Contains


RESTAURANT BANQUET FOOD_ITEM(0,m) (1,n) (1,n) (0,p)

Capable_of_preparing(100,q) (17,r)

Id

Name Address

RatingCuisine

Product_code

Food_typeInvoice_no

Address Bill_to

Caters

Cost

Contains

(b)A composite of two weak relationship types inclusion-dependent on a relationship Type

Inclusion Dependency in a Composite Relationship Type – 3rd Example

Business rule: A restaurant can cater to a banquet only if that restaurant is capable of preparing food items that are on the banquet’s menu

The composite (intersection) of Caters and Contains inclusion-dependent on capable_of_preparing


PROFESSOR

AUTHOR REVIEWERPAPER

O

Writes Referees

U U

Figure 5.36 An ER diagram depicting a professor as an author and reviewer of papers

(1,p) (1,q) (1,r)(2,5)

Book_titleSpecialty_area

SsnoName University

Manuscript# Title No_pages



Figure 5.37 An example of exclusion dependency in an ER diagram

PROFESSOR

AUTHOR REVIEWERPAPER

O

(1,p) (1,q) (1,r)(2,5)

Conflict_of_interest

(0,n) (0,m)

NameSsno Address

Book_title Speciality_areaTitleManuscript# No_pages

Writes Referees

Adapted From: Dey, Storey and Barron (1999)

Note: Conflict_of_interest and (Writes Referees) are mutually exclusive.

Business rule: I n order f or a reviewer to referee a paper written by an author, a confl ict of interest relationship cannot exist between the reviewer and the author and vice versa

Exclusion Dependency in a Composite Relationship Type


INSTRUCTOR COURSE

BOOK

Uses(0,n) (0,m)

(1,p)

Figure 5.38 The ternary relationship type Uses

Author

Title

Isbn#


Credits

Name

Course#

Decomposing n-ary Relationships


INSTRUCTOR COURSE

Credits

Course#

Selects AdoptsUSE

Finds

BOOK

(0,n) (1,1) (1,1) (0,m)

(1,1)

(1,p)

Name


Isbn#

Title

Author

Figure 5.39 Decomposition of the ternary relationship type Uses to the gerund entity type USE

Decomposing n-ary Relationship Types



LocationSize Location

Size

Name

(0,n) (1,m)

Client Contractor

ContractContract#

Year

(a)Contract as a binary relationship type with a multi-valued attribute

Name

Name

Contract#

(b)Decomposition of the relationship type Contract in Figure 5.40a to a gerund entity type CONTRACT

COMPANY CONSULTANT

LocationSize LocationName

(0,n) (1,m)

Client ContractorExecute

CONTRACTContract------------

Year

(1,1) Document

Size

Figure 5.40 Decomposition of a relationship type with a multi-valued attribute

Decomposing n-ary Relationship Types (continued)


COMPANY CONSULTANT


(0,n) (1,m)

Client Contractor

(b)Decomposition of the relationship type Contract in Figure 5.41a to a gerund entity type CONTRACT

Execute

CONTRACT

Name

Contract_yr---------------

Contract#

Year

(a)'Retainer' as an additional attribute in the composite multi-valued attribute 'Contract'

Contract

Retainer

Size

Retainer

Contract_yr---------------

Contract#

Year

(1,1) Document



(0,n) (1,m)

Client Contractor

Name

Size

Figure 5.41 Decomposition of a relationship type with a partial key in a multi-valued attribute



(a)'Retainer' as an attribute of Contracts independent of the multi-valued attribute Contract

COMPANY CONSULTANT


(0,n) (1,m)

Client Contractor

(b)I ncorrect* fine-granular decomposition of the ERD in Figure 5.42a

Execute

CONTRACT

Name

Size

Contract_yr---------------

Contract#

Year

Retainer

(1,1) Document

Contract_yr---------------

Contract#

Year

Contract

Retainer



(0,n) (1,m)

Client Contractor

Name

Size

Figure 5.42 ERD with a single-valued as well as a multi-valued attribute of a relationship type

* Retainer as an attribute of the identif ying relationship type does not convey the semantics implied in Figure 5.42a.



COMPANY CONSULTANT


(0,n) (1,m)

Client Contractor

(a)'Retainer' as an attribute of Retains independent of CONTRACT, a mapping of the

multi-valued attribute Contract in Figure 5.42a

Execute

CONTRACT

Name

Size

Contract_yr---------------

Contract#

Year

Retainer

Retains

Agreement

COMPANY CONSULTANTHas ReciprocatesAGREEMENT(0,n) (1,1) (1,1) (1,m)


(b)A fi ne-granular decomposition of the design in Figure 5.43a

RetainerName

Size

Execute

CONTRACT

Year

Contract_yr---------------

Contract#

(0,p)

(1,1)

(0,p)

(1,1)

Figure 5.43 A two step decomposition of the design shown in Figure 5.42a



COMPANY CONSULTANTHas ReciprocatesAGREEMENT(0,n) (1,1) (1,1) (1,m)


Figure 5.44 An alternative design f or the ER diagram in Figure 5.43b

RetainerName

Size

CONTRACT

Year

Contract_yr---------------

Contract#

Signs Honors

(0,p)

(1,1) (1,1)

(0,q)

Note: CONTRACT is a weak entity type with two ‘independent’ identifying parents - viz., COMPANY and CONSULTANT – not a gerund entity type emerging from the relationship between the two.



INSTRUCTOR COURSECan_teach

NameQualification NameCourse#

Employee_id

Credits

Teaches

(1,n) (1,m)

(2,q)(1,r)

Figure 5.45 Teaches as a condition-precedent weak relationship type

U

_Note: Weak relationship type Teaches depicts inclusion dependency Teaches Can_teach.

Decomposing a Weak Relationship Type


INSTRUCTOR COURSEAble_to ReciprocatesCAN_TEACH(1,n) (1,1) (1,1) (1,m)

Figure 5.46 Decomposition of the weak relationship type Teaches using the EER construct, Specialization

TEACHING

Lined_up Entails

Employee_id NameQualification Course# Name

Credits

(2,q)

(1,1) (1,1)

(1,r)

U

Note: Partial specialization of CAN_TEACH as TEACHING enforces the inclusion dependency Teaches Can_teach shown in Figure 5.45.

U

_

TEACHING has existence dependency on the gerund entity type CAN_TEACH

Decomposing a Weak Relationship Type (continued)


INSTRUCTOR COURSEAble_to Reciprocates

CAN_TEACH

(1,n)(1,1) (1,1)

(1,m)

Figure 5.47 Decomposition of the weak relationship type Teaches: An alternative design

TEACHING

Lined_up Entails

Employee_id NameQualification Course# Name

Credits

(2,q)

(1,1) (1,1)

(1,r)

Note: The inclusion dependency (Teaches Can_teach) of Figure 5.45 decomposed using a basic ER construct - a (1:1) relationship type.

Only-if

(1,1)

(0,1)

U

_



PATRON LIBRARY BOOKMember_of Available_in(1,1) (1,n) (1,m) (1,1)

Membership# Phone#Name Author

Title Call#Library_id Name

Location

Figure 5.48 An example of a f an trap

m1

m2

m3

m4

m5

Member_of

(b)An instance diagram for the design shown in Figure 5.48a

PATRON LIBRARY

k1

k2

k3

k4

k5

k6

a1

a2

a3

a4

a5

a6

Available_in BOOK

p1

p2

p3

p4

p5

l1

l2

l3

(a)An ER diagram exemplif ying a relationship f an

Note: Relationship types Member_of and Available_in fanning-out from LIBRARY



BOOKBorrowed_by(1,n) (1,1)

Phone#Name Author

Title Call#

Figure 5.49 An alternative solution f or the design shown in Figure 5.48


PATRON

k1

k2

k3

k4

k5

k6

b1

b2

b3

b4

b5

b6

Borrowed_by BOOK

p1

p2

p3

p4

p5

(a)An ER diagram exemplif ying a relationship f an

PATRON

Membership#

LIBRARY

Library_id NameLocation

Available_in(1,1) (1,m)

LIBRARY

l1

l2

l3

a1

a2

a3

a4

a5

a6

Available_in

Note: Relationship types Borrowed_by and Available_in fanning-in to BOOK



LIBRARY BOOKMember_of Borrowed_by(1,1) (1,n)(1,m) (1,1)

Phone#Name Author


Location

Figure 5.50 Resolution of the f an trap present in Figures 5.48 and 5.49

m1

m2

m3

m4

m5

Member_of


PATRON

k1

k2

k3

k4

k5

k6

b1

b2

b3

b4

b5

b6

Borrowed_by BOOK

p1

p2

p3

p4

p5

(a)An ER diagram exemplif ying a relationship hierarchy

PATRON

Membership#

LIBRARY

l1

l2

l3

Note: Relationship types Member_of and Borrowed_by neither fanning-in to nor fanning-out of PATRON



VEHICLE MUSICIAN INSTRUMENTOwned_by Played_by(1,1) (1,n) (1,m) (1,1)

Lic-plate# ModelYear

Type NameName Age

Experience

Figure 5.51 A relationship f an semantically irrelevant as a f an trap




Phone#Name Author


Location

Figure 5.52 An example of a chasm trap

m1

m2

m3

m4

m5

Member_of


PATRON

k1

k2

k3

k4

k5

k6

b1

b2

b3

b4

b5

Borrowed_by BOOK

p1

p2

p3

p4

p5

(a)An ER diagram exemplif ying a relationship hierarchy with a partial participation

PATRON

Membership#

LIBRARY

l1

l2

l3




Phone#Name Author


Location

Figure 5.53 Final design f ree of connection traps f or the scenario specified

PATRON

Membership#

Available_in

(1,1)(1,n)

m1

m2

m3

m4

m5

Member_of


PATRON

k1

k2

k3

k4

k5

k6

b1

b2

b3

b4

b5

Borrowed_by BOOK

p1

p2

p3

p4

p5

LIBRARY

l1

l2

l3

a6

a5

a4

a3

a2

a1

Available_in

(a)ER diagram in Figure 5.52a augmented by the relationship type Available_ in



VENDOR

PROJECTSupplies

(1,n)

(1,m)

(a)A ternary relationship type Supplies in a semantic trap

Name Qualification

Budget

Proj#Address

Location

Frequency

PRODUCT(1,p)

Specification

PricePart#

VENDOR

PROJECTUses

(1,1)

(1,m)

Figure 5.54 Demonstration of a semantic trap

Name Qualification

Budget

Proj#

Address

Location

Frequency

PRODUCT(1,p)

Specification

PricePart#

INVENTORY

Supplies(1,n)

(b)A revised design of Figure 5.54a eliminating the semantic trap



RESTAURANT FOOD_ITEM BANQUET(0,m) (1,n) (1,n) (0,p)

Can_cater(50,q) (7,r)

Id

Name Address

RatingCuisine

Caters Contains

Product_code

Food_typeCost

Invoice_no Address

Bill_to

(a)A weak relationship type inclusion-dependent on a composite relationship type

Figure 5.55 (a) Inclusion dependency in composite relationship types: Example 1



RESTAURANT BANQUET FOOD_ITEM(0,m) (1,1) (1,n) (0,p)

Capable_of_preparing(100,q) (17,r)

Id

Address

RatingCuisine

Product_code

Food_typeInvoice_no

Address Bill_to

Figure 5.55 (b) I nclusion dependency in a composite relationship types: Example 2

Caters

Cost

Contains

(b)A composite of two weak relationship types inclusion-dependent on a relationship Type



Cougar Medical Associates

• See book


U

SALARIED_EMPLOYEE

NURSE

SURGEON

PHYSICIAN

PERSON

PATIENT

O

d

Speciality

Speciality

Ssno

U

UU

U

U

NameGender Address

Phone#

Emp#

Salary

Con_typeCon_years

Grade

Yrs_experience

Figure 5.56 Presentation Layer ER diagram for Cougar Medical Associates - Stage 1

CLINIC_PERSONNEL

d

Cougar Medical Associates (continued)


CLINIC_PERSONNEL

NURSE SURGEON PHYSICIAN

PERSON

PATIENT

O

d

Speciality

Speciality

Ssno

U

UU

U

U

NameGender Address

Phone#

Emp#

Con_typeCon_years

Grade

Yrs_experience

Figure 5.57 Presentation Layer ER diagram for Cougar Medical Associates Stage 1 (An alternative design)

SUPPORT_STAFF

U

SalarySalary

Salary



CLINIC_PERSONNEL

NURSE SURGEON PHYSICIAN

PERSON

O

d

Speciality

Speciality

Ssno

U

U

U

U

U

NameGender Address

Phone#

Emp#

Con_typeCon_years

Grade

Yrs_experience

Figure 5.58 Presentation Layer ER diagram for Cougar Medical Associates - Stage 2

PATIENT

PERSONAL_INFO

MEDICAL_INFO

A

U

Birthdate

Blood_sugar

Blood_type

Cholesterol

Triglyceride

HDL

LDL

Allergy

Code

Description

11 Ch_ratio

Heart_risk

Total_cholesterol

SUPPORT_STAFF

Salary

USalary

Salary

Patient#


Chapter 5 – Modeling Complex Relationships 85U

CLINIC_PERSONNEL

MEDICAL_CORPORATION

NURSE

SURGEON

PHYSICIAN

CLINIC_OWNER

PERSON

ILLNESS

PATIENT MEDICATION

PERSONAL_INFO

IN_PATIENT

MEDICAL_INFO

Attends

SURGERY_TYPE

PCP*

Surg_sch

Prescribes

O

d

UInteracts

Suffers

UA

U

Patient#

Birthdate

Blood_sugar

Blood_type

Cholesterol

Triglyceride

HDL

LDL

Allergy

Code

Description

Special_Needs

S_code

Theatre

Surg_date

Speciality

Speciality

Headquarters

Corp_name

Percent_own

SsnoCode

Severity

DosageFrequency

Med_code

U

U

U

U

U

U

SURGERY_SKILL

Nurse_skill Req_skill

NameGender Address

Phone#

Emp#

Con_type

Con_years

Grade

Yrs_experience

Name

Anat_location

Category

Admit_date

Location

Nursing_unitRoom#

Bed#

Name

Q_on_hand

Q_on_order

Unit_cost

Ytd_usage

Description

Ch_ratio

Total_cholesterol

n

1

201

mn

nmm

n

mn n m

Skill_code Description

* PCP stands for Primary Care Physician.

Takes

Heart_risk

1 1

Figure 5.59 Presentation Layer ER diagram for Cougar Medical Associates – The genesis

SUPPORT_STAFF

Salary

Salary

Salary

Assigned_ton 1


Chapter 5 – Modeling Complex Relationships 86U

CLINIC_PERSONNEL

MEDICAL_CORPORATION

NURSE

SURGEON

PHYSICIAN

CLINIC_OWNER

PERSON

ILLNESS

PATIENT MEDICATION

PERSONAL_INFO

IN_PATIENT

MEDICAL_INFO

Attends

SURGERY_TYPE

PCP*

Surg_sch

Prescribed

Writes

O

d

UInteracts

Suffers

U A

U

Patient#

Birthdate

Blood_sugar

Blood_type

Cholesterol

Triglyceride

HDL

LDL

Allergy

Code

Description

Special_Needs

S_code

PRESCRIPTION

Theatre

Surg_date

Speciality

Speciality

Headquarters

Corp_name

Percent_own

SsnoCode

Severity

DosageFrequency

Med_code

U

U

U

U

U

U

SURGERY_SKILL

Nurse_skill Req_skill

Assigned_to

NameGender Address

Phone#

Emp#

Con_type

Con_years

Grade Yrs_experience

Name

Anat_location

Category

Admit_date

Location

Nursing_unitRoom#

Bed#

Name

Q_on_hand

Q_on_order

Unit_cost

Yfd_usage

Description

Ch_ratio

Total_cholesterol

n

1

20

1

mn

nmm

n

mn

mn n m

Skill_code Description

* PCP stands for Primary Care Physician.

m1

Takes

n 1

Heart_risk

1 1

Figure 5.60 Presentation Layer ER diagram For Cougar Medical Associates – Final

SUPPORT_STAFF

Salary

Salary

Salary



CLINIC_PERSONNEL

MEDICAL_CORPORATION

NURSE

SURGEON

PHYSICIAN

CLINIC_OWNER

PERSON

ILLNESS

PATIENT MEDICATION

PERSONAL_INFO

IN_PATIENT

MEDICAL_INFO

Attends

SURGERY_TYPE

PCP*

Writes

O

d

U

A

[X,10]Patient#

Birthdate[Dt,8]

[N,3]Blood_sugar

Blood_type[X,2]

Cholesterol

Triglyceride[N,3]

HDL[N,3]

LDL[N,3]

[A,3]Code

---------

Description[A,20]

Special_Needs[A,20]

[X,3]S_code

[A,15]Theatre

Surg_date[Dt,8]

[A,20]Speciality

Speciality[A,20]

[A,15]Headquarters[A,30]

Corp_namePercent_own

[N,2.1]

[X,9]Ssno

[A,3]Code

Med_code[A,3]

U

U

(0,n)

Requires

[A,30]Name

[A,1]Gender

[X,50]Address

[X,10]Phone#

[X,6]Emp#

[N,6]Salary

[A,20]Con_type

[N,1.1]Con_years

[A,20]Grade

[N,2]Yrs_experience

Name[A,30]

Anat_location[A,20]

Category[A,1]

Admit_date[Dt,8]

Location

Nursing_unit[N,1]

Room_num

Bed#[A,1]

Name[X,30]

[N,4]Q_on_hand

[N,4]Q_on_order

[N,3.2]Unit_cost

Yfd_usage[N,5]

[A,20]Description

(5,n)

(0,1)

Ch_ratio[N,1.2]

Total_cholesterol

[N,3]

[A,3]Skill_code

[A,20]Description

*PCP Stands for Primary Care Physician.

(0,m)

By

Has

NURSE_SKILL

Possessed_as

SURGERY_SKILL

Part_of Slated_forWorks_by

Causes

Subject_to

SUFFERIING

PRESCRIPTION

Issued_forIssued_to

INTERACTION

Subject_toSource_of

ALLERGY

Includes

Heart_risk[A,1]

SURG_SCH

REQ_SKILL

(1,m)

(1,1)(1,1)

(0,m)

Alloted_to

(1,1)

(1,1)

(1,n)

(1,1)

(1,1)

(1,1) (1,1)

(1,1) (1,1)

(1,1)(1,1)

MED_TAKEN

Is

(0,n) (0,m)

(0,n)

(1,1)(1,1)

(0,m)

(1,1)

(0,n)

1 1

(0,n)

(0,n)

(1,m)

(7,20)

(1,1)

(1,m)

(0,p)

(0,m) (0,n)

May_have

(0,1)

(2,n)

Wing[A,1]

Room#[N,2]

C

R

N

D

(1,1)

Figure 5.61 Fine-granular Design-Specifi c ER diagram for Cougar Medical Associates

Assignment

Has

(1,1)

(1,1)

Subject_to

Depends_on(1,m)

(1,n)

(0,1)

(0,1)

SUPPORT_STAFF [N,6]Salary

[N,6]Salary



Exercise: Schnaps Distillery

• A small rural distillery called “Kurt” is thinking about entering the e-commerce world by creating an Internet presence

• Since Kurt is low on budget, he wants to keep his Web site as basic as possible, but at the same time as effective as possible

• Kurt is very open to any suggestions regarding his Web site, but he has two stipulations: the Web site has to show off his products (and provide a functionality for customers to buy his products), and it has to have a guest book

• Further information available


Assignment

• A famous Greek shipping magnate, Stell, owns many container ships. Containers are collected at one port and delivered to another port. Customers pay a negotiated fee for the delivery of each container. Each ship has a sailing schedule that lists the ports the ship will visit over the next six months. The schedule shows the expected arrival and departure dates. The daily charge for use of each port is also recorded.

Chapter 5: Modeling Complex Relationships Data Modeling and Database Design.

Documents

Transcript of Chapter 5: Modeling Complex Relationships Data Modeling and Database Design.