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
Chapter 5 – Modeling Complex Relationships 3
Chapter 5 – Modeling Complex Relationships 4
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
Chapter 5 – Modeling Complex Relationships 5
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
Chapter 5 – Modeling Complex Relationships 6
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
Chapter 5 – Modeling Complex Relationships 7
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
Chapter 5 – Modeling Complex Relationships 8
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
Chapter 5 – Modeling Complex Relationships 9
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
Chapter 5 – Modeling Complex Relationships 10
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
Chapter 5 – Modeling Complex Relationships 11
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
Chapter 5 – Modeling Complex Relationships 12
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
Chapter 5 – Modeling Complex Relationships 13
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.
Chapter 5 – Modeling Complex Relationships 14
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
Chapter 5 – Modeling Complex Relationships 15
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
Physician# Name Phone
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
Chapter 5 – Modeling Complex Relationships 16
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
Chapter 5 – Modeling Complex Relationships 17
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
Chapter 5 – Modeling Complex Relationships 18
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
Chapter 5 – Modeling Complex Relationships 19
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
Chapter 5 – Modeling Complex Relationships 20
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
Chapter 5 – Modeling Complex Relationships 21
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
Chapter 5 – Modeling Complex Relationships 22
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)
Chapter 5 – Modeling Complex Relationships 23
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
Vignette 3 – More on Madeira College (continued)
Chapter 5 – Modeling Complex Relationships 24
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
Vignette 3 – More on Madeira College (continued)
Chapter 5 – Modeling Complex Relationships 25
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)
Vignette 3 – More on Madeira College (continued)
Chapter 5 – Modeling Complex Relationships 26
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
Vignette 3 – More on Madeira College (continued)
Chapter 5 – Modeling Complex Relationships 27
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
Vignette 3 – More on Madeira College (continued)
Chapter 5 – Modeling Complex Relationships 28
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
Chapter 5 – Modeling Complex Relationships 29
Chapter 5 – Modeling Complex Relationships 30
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
Chapter 5 – Modeling Complex Relationships 31
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
Physician# Name Phone
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)
Chapter 5 – Modeling Complex Relationships 32
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)
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 33
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#
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 34
INSTRUCTOR COURSE
QUARTER
Offering(0,n) (0,m)
(1,p)
Figure 5.16 The quintary relationship type Off ering
Employee_id NameQualification
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 35
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 36
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 37
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 38
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#
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 39
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 40
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)
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 41
COMPANY
LocationNameSize
Contract
Client(0,n)
(1,m)Contractor
Contract
Contract#
Year
Figure 5.24 Contract as a recursive relationship type
COMPANY CONSULTANTContract
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.
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 42
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 43
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 44
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.
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 45
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 46
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
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 47
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?
Vignette 4 (continued)
Chapter 5 – Modeling Complex Relationships 48
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
Chapter 5 – Modeling Complex Relationships 49
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
Chapter 5 – Modeling Complex Relationships 50
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.
Chapter 5 – Modeling Complex Relationships 51
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)
Chapter 5 – Modeling Complex Relationships 52
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…
Chapter 5 – Modeling Complex Relationships 53
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)
Chapter 5 – Modeling Complex Relationships 54
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
Let’s Revisit… (continued)
Chapter 5 – Modeling Complex Relationships 55
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
Let’s Revisit… (continued)
Chapter 5 – Modeling Complex Relationships 56
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
Let’s Revisit… (continued)
Chapter 5 – Modeling Complex Relationships 57
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
Chapter 5 – Modeling Complex Relationships 58
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
Chapter 5 – Modeling Complex Relationships 59
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
Chapter 5 – Modeling Complex Relationships 60
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
Let’s Revisit… (continued)
Chapter 5 – Modeling Complex Relationships 61
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
Chapter 5 – Modeling Complex Relationships 62
INSTRUCTOR COURSE
BOOK
Uses(0,n) (0,m)
(1,p)
Figure 5.38 The ternary relationship type Uses
Author
Title
Isbn#
Employee_id NameQualification
Credits
Name
Course#
Decomposing n-ary Relationships
Chapter 5 – Modeling Complex Relationships 63
INSTRUCTOR COURSE
Credits
Course#
Selects AdoptsUSE
Finds
BOOK
(0,n) (1,1) (1,1) (0,m)
(1,1)
(1,p)
Name
Employee_id NameQualification
Isbn#
Title
Author
Figure 5.39 Decomposition of the ternary relationship type Uses to the gerund entity type USE
Decomposing n-ary Relationship Types
Chapter 5 – Modeling Complex Relationships 64
COMPANY CONSULTANTContract
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)
Chapter 5 – Modeling Complex Relationships 65
COMPANY CONSULTANT
LocationSize LocationName
(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
COMPANY CONSULTANTContract
LocationSize LocationName
(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
Decomposing n-ary Relationship Types (continued)
Chapter 5 – Modeling Complex Relationships 66
(a)'Retainer' as an attribute of Contracts independent of the multi-valued attribute Contract
COMPANY CONSULTANT
LocationSize LocationName
(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
COMPANY CONSULTANTContract
LocationSize LocationName
(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.
Decomposing n-ary Relationship Types (continued)
Chapter 5 – Modeling Complex Relationships 67
COMPANY CONSULTANT
LocationSize LocationName
(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)
LocationSize LocationName
(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
Decomposing n-ary Relationship Types (continued)
Chapter 5 – Modeling Complex Relationships 68
COMPANY CONSULTANTHas ReciprocatesAGREEMENT(0,n) (1,1) (1,1) (1,m)
LocationSize LocationName
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.
Decomposing n-ary Relationship Types (continued)
Chapter 5 – Modeling Complex Relationships 69
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
Chapter 5 – Modeling Complex Relationships 70
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)
Chapter 5 – Modeling Complex Relationships 71
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
_
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 72
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 73
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
(b)An instance diagram for the design shown in Figure 5.49a
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 74
LIBRARY BOOKMember_of Borrowed_by(1,1) (1,n)(1,m) (1,1)
Phone#Name Author
Title Call#Library_id Name
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
(b)An instance diagram for the design shown in Figure 5.50a
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 75
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 76
LIBRARY BOOKMember_of Borrowed_by(1,1) (1,n)(1,m) (0,1)
Phone#Name Author
Title Call#Library_id Name
Location
Figure 5.52 An example of a chasm trap
m1
m2
m3
m4
m5
Member_of
(b)An instance diagram for the design shown in Figure 5.52a
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 77
LIBRARY BOOKMember_of Borrowed_by(1,1) (1,n)(1,m) (0,1)
Phone#Name Author
Title Call#Library_id Name
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
(b)An instance diagram for the design shown in Figure 5.53a
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 78
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 79
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 80
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
Decomposing a Weak Relationship Type (continued)
Chapter 5 – Modeling Complex Relationships 81
Cougar Medical Associates
• See book
Chapter 5 – Modeling Complex Relationships 82
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)
Chapter 5 – Modeling Complex Relationships 83
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
Cougar Medical Associates (continued)
Chapter 5 – Modeling Complex Relationships 84
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#
Cougar Medical Associates (continued)
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
Cougar Medical Associates (continued)
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
Cougar Medical Associates (continued)
Chapter 5 – Modeling Complex Relationships 87
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
Cougar Medical Associates (continued)
Chapter 5 – Modeling Complex Relationships 88
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
Chapter 5 – Modeling Complex Relationships 89
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.
Top Related