Download Chapter 5 Logical Database Design and the Relational Model

Chapter 5
79
Chapter 5 Logical Database Design and the Relational Model
Chapter Objectives
The purpose of this chapter is to describe in depth the major steps in logical
database design, with more emphasis on the relational model. Logical database design is
the process of transforming the conceptual data model (described in Chapters 3 and 4)
into a logical data model. First, we provide a concise description of the relational data
model, including the properties of relations. Next, we describe and illustrate the various
types of integrity constraints associated with the relational model. This section
introduces SQL table definitions, and the concept of well-structured relations. We then
provide a detailed description of the process of transforming EER diagrams into relations.
Next, we define normalization and describe the steps in normalizing relations. The
chapter concludes with a discussion of merging relations, and techniques for dealing with
typical issues that arise during this process.
Specific student learning objectives are included in the beginning of the chapter.
From an instructor's point of view, the objectives of this chapter are to:
1.
Show students the position of logical database design within the overall database
development process. This is a key chapter in the textbook, since students will
begin to see how their databases will be implemented.
2.
Provide students with a solid understanding of the relational data model, including
the properties of relations, integrity constraints, and well-structured relations.
3.
Discuss the principles and detailed steps involved in mapping EER diagrams to
relations. Computer-assisted techniques are often used to speed up this process,
but students should still understand the principles involved.
4.
Provide students with a firm grasp on the principles of functional dependencies,
determinants, and related concepts of normalization.
5.
Emphasize why normalization is important to stable database design with the
relational, and then present a concise description of the various normal forms and
the normalization process.
6.
Discuss some of the anomalies that arise when merging relations, and how to
apply the principles we have learned to address these anomalies.
Classroom Ideas
1.
2.
3.
Motivate the need for logical database design. We sometimes start by showing
the students the conceptual data model (E-R diagrams) for Pine Valley Furniture
Company (Figure 3-22). Emphasize that this E-R diagram must be transformed
through logical database design before it can be implemented.
Review the position of logical database design in the overall database
development process (see Figure 2-5). You might want to discuss who in the
organization is usually responsible for this step, and what CASE tools might be
appropriate.
Discuss the relational data model, using Figures 5-1 through 5-4 as examples.
80
4.
5.
6.
7.
8.
9.
10.
11.
Modern Database Management, Sixth Edition
Introduce the important integrity constraints in the relational model using Figures
5-4 and 5-5 and Table 5-1. Emphasize that these constraints will be enforced by
the DBMS, but must first be specified by the designer.
Introduce SQL table definitions (Figure 5-6). Show how these definitions specify
the referential integrity constraints that are diagrammed in Figure 5-5.
Illustrate how anomalies can occur when relations are not well structured, using
Figures 5-2b and 5-7. Emphasize the fact that much real-world data (including
relational data) are not well structured.
Discuss the process of transforming EER diagrams to relations (Figures 5-8
through 5-22). We suggest you reinforce these concepts by asking your students
(in teams of two) to perform Exercise 6a in class immediately following the
discussion.
Preview the steps in normalization using Figure 5-23. You will want to use this
figure again to summarize normalization at the end of your discussion.
Discuss the concepts of functional dependencies, determinants, and candidate
keys. Start with your own examples on the board, then have your students give
additional examples. Summarize using Figure 5-23.
Discuss first through third normal forms, using Figures 5-24 through 5-26.
Additional normal forms (BCNF and 4NF) are presented in Appendix B, if time
permits.
We strongly suggest for you to ask your students to work in small teams on one or
more chapter-end exercises (Exercises 3 and 4 work well for this purpose).
Answers to Review Questions
1.
2.
Define each of the following terms:
a.
Determinant. The attribute on the left-hand side of the arrow in a
functional dependency.
b.
Functional dependency. A constraint between two attributes or two sets of
attributes.
c.
Transitive dependency. A functional dependency between two (or more)
nonkey attributes.
d.
Recursive foreign key. A foreign key in a relation that references the
primary key values of that same relation.
e.
Normalization. The process of decomposing relations with anomalies to
produce smaller, well-structured relations.
f.
Composite key. A primary key that consists of more than one attribute.
g.
Relation. A named, two-dimensional table of data.
h.
Normal form. A state of a relation that results from applying simple rules
regarding functional dependencies (or relationships between attributes) to
that relation.
i.
Partial functional dependency. A functional dependency in which one or
more nonkey attributes (such as Name) are functionally dependent on part
(but not all) of the primary key.
j.
Enterprise Key. A primary key whose value is unique across all relations.
f well-structured relation
Chapter 5
3.
4.
5.
81
e anomaly
a functional dependency
j determinant
g composite key
d 1NF
h 2NF
i 3NF
c recursive foreign key
k relation
b transitive dependency
Contrast the following terms:
a.
Normal form; normalization. Normal form is a state of a particular
relation regarding functional dependencies, while normalization is the
process of decomposing relations with anomalies to produce smaller, wellstructured relations.
b.
Candidate key; primary key. A primary key is an attribute (or
combination of attributes) that uniquely identifies a row in a relation.
When a relation has more than one such attribute (or combination of
attributes), each is called a candidate key. The primary key is then the one
chosen by users to uniquely identify the rows in the relation.
c.
Functional dependency; transitive dependency. A functional dependency
is a constraint between any two attributes (or two sets of attributes), while
a transitive dependency is a functional dependency between two or more
non-key attributes.
d.
Composite key; recursive foreign key. A composite key is a primary key
that consists of more than one attribute, while a recursive foreign key is a
foreign key in a relation that references the primary key values of that
same relation.
e.
Determinant; candidate key. A determinant is on the left-hand side of the
arrow in a functional dependency, while a candidate key uniquely
identifies a row in a relation.
f.
Foreign key; primary key. A primary key uniquely identifies each row in a
relation while a foreign key is a primary key in another table.
Six important properties of relations are:
a.
Each relation in a database has a unique name.
b.
An entry at the intersection of each row and column is atomic (or single
valued).
c.
Each row is unique.
d.
Each attribute within a table has a unique name.
e.
The sequence of columns is insignificant.
f.
The sequence of rows is insignificant.
Describe two properties that must be satisfied by candidate keys:
a.
Unique identification: for every row, the value of the key must uniquely
identify that row.
b.
Nonredundancy: no attribute in the key can be deleted without destroying
the property of unique identification.
82
6.
7.
8.
9.
10.
Modern Database Management, Sixth Edition
Three types of anomalies in tables:
a.
Insertion anomaly: a new row cannot be inserted unless all primary key
values are supplied.
b.
Deletion anomaly: deleting a row results in losing important information
not stored elsewhere.
c.
Modification anomaly: a simple update must be applied to multiple rows.
Fill in the blanks.
a.
second
b.
first
c.
third
A well-structured relation is a relation that contains a minimum amount of
redundancy and allows users to insert, modify, and delete the rows in a table
without errors or inconsistency. Well-structured relations are important because
they promote database integrity.
Describe how the following components of an E-R diagram are transformed to
relations:
a.
Regular entity type: each entity type is transformed to a simple relation.
Each simple attribute of the entity type becomes an attribute of the
relation.
b.
Relationship (1:M): a relation is created for each of the two entity types
participating in the relationship. The primary key attribute of the entity on
the one-side of the relationship becomes a foreign key in the relation on
the many-side of the relationship.
c.
Relationship (M:N): a new relation is created to represent this
relationship. The primary key for each of the participating entity types is
included in this new relation.
d.
Relationship (supertype/subtype): a separate relation is created for the
supertype and each of its subtypes. The primary key of the supertype is
assigned to each subtype, as well as attributes that are unique to the
subtype.
e.
Multivalued attribute: a new relation is created to replace the multivalued
attribute. The primary key of this new relation consists of two attributes:
the primary key of the original relation, plus the multivalued attribute
itself.
f.
Weak entity: a new relation is created corresponding to the weak entity.
The primary key of this relation consists of the primary key of the owner
relation, plus the partial identifier of the weak entity type.
g.
Composite attribute: the simple component attributes of the composite
attribute are included in the new relation.
Four typical problems in merging relations:
a.
Synonyms: two (or more) attributes have different names but the same
meaning. Solution: convince users to standardize on a single name.
b.
Homonyms: a single attribute has more than one meaning.
Solution: create new attribute names that capture the separate meanings.
c.
Transitive dependency: merging relations produces transitive
dependencies.
Chapter 5
11.
12.
13.
14.
15.
16.
17.
18.
83
Solution: create 3 NF relations by removing the transitive dependency.
d.
Supertype/ subtype: may be implied by content of existing relations.
Solution: create new relations that explicitly recognize this relationship.
Three conditions that imply a relation is in second normal form:
a.
The primary key consists of a simple attribute.
b.
No nonkey attributes exist in the relation.
c.
Every nonkey attribute is functionally dependent on the full set of primary
key attributes.
Integrity constraints enforced in SQL CREATE TABLE commands:
a.
Entity integrity: enforced by NOT NULL clause.
b.
Referential integrity: enforced by FOREIGN KEY REFERENCES
statement.
Relationships between entities are represented by foreign key values in one
relation that match primary key values in another relation.
A 1:M unary relationship is represented by a recursive foreign key whose values
reference the primary key values of the same relation.
An M:N ternary relationship is represented by a new associative relation whose
primary key consists of the primary key attributes of the participating entity types.
All of the non-key attributes of a relation are functionally dependent on the
primary key of that relation.
A foreign key must not be null when the minimum cardinality is one.
Primary keys can be transformed into Enterprise keys to eliminate key ripple
effects as a database evolves.
Answers to Problems and Exercises
1.
Transforming E-R diagrams to relations:
a.
EMPLOYEE
Employee_ID
Employee_Name
Address
EMPLOYEE
Employee_ID
Skill
b.
FLIGHT
Flight_No
Date
No_of_Passengers
Date_Employed
84
Modern Database Management, Sixth Edition
c.
EMPLOYEE
Employee_ID
Employee_Name
COMPLETION
Employee_ID
Course_ID
Date_Completed
COURSE
Course_ID
Course_Title
d.
EMPLOYEE
Employee_ID
Employee_Name
CERTIFICATE
Certificate_No
Employee_ID
COURSE
Course_ID
Course_Title
e.
COURSE
Course_ID
Course_Title
Course_ID
Prereq_ID
Course_ID
Date_Completed
Chapter 5
85
f.
MOVIE
Movie_Name
VIDEO TAPE
Copy_No
Movie_Name
g.
PRODUCT
Product_ID
Product_ID
2.
Effective_Date
Price
Transforming EER diagrams to relations:
a.
VEHICLE
Vehicle_ID
Price
Make
Model
Engine_Displacement
CAR
C_Vehicle_ID
No_of_Passengers
TRUCK
T_Vehicle_ID
Car_Type
Capacity
86
Modern Database Management, Sixth Edition
b.
RESPONSIBLE PHYSICIAN
Physician_ID
PATIENT
Patient_ID
Admit_Date
Physician_ID
OUTPATIENT
O_Patient_ID
Checkback_Date
RESIDENT PATIENT
R_Patient_ID Date_Discharged
BED
Bed_ID
BedID
Chapter 5
87
c.
PART
Part_No
Description
Location
Manufactured?
MANUFACTURED PART
M_Part_No
PURCHASED PART
P_Part_No
SUPPLY LINE
P_Part_No
Supplier_ID
Unit_Price
SUPPLIER
Supplier_ID
Supplier_Name
PURCHASED?
Quantity_on_Hand
88
Modern Database Management, Sixth Edition
d.
PERSON
SSN
Name
Address
Date_of_Birth
Sex
EMPLOYEE
E_SSN
Salary
Date_Hired
FACULTY
F_SSN
STAFF
Rank
Position
S_SSN
ALUMNUS
A_SSN
DEGREES
A_SSN
Degree
Year
Date
STUDENT
ST_SSN
Major_Department
GRADUATE
GS_SSN
UNDERGRADUATE
Test_Score
US_SSN
Class_Standing
Chapter 5
89
e.
STUDENT
Student_ID
Student_Name
REGISTRATION
Student_ID
Course_ID
Section_No
Semester
SECTION
Course_ID
Section_No
Semester
COURSE
Course_ID
Course_Name
QUALIFICATION
Course_ID
Faculty_ID
Date_Qualified
ASSIGNMENT
Faculty_ID
Course_ID
Section_No
FACULTY
Faculty_ID
3.
Faculty_Name
The normal form for the relations are:
a.
3NF
b.
3NF
c.
2NF
CLASS (Course_No, Section_No, Room)
ROOM (Room, Capacity)
Semester
90
Modern Database Management, Sixth Edition
d.
4.
5.
1NF
COURSE (Course_No, Course_Name)
CLASS (Course_No, Section_No, Room)
ROOM (Room, Capacity)
3NF relations for Millennium College are:
OBJECT(OID,Object_Type)
INSTRUCTOR (OID,Instructor_Name, Instructor_Location)
COURSE (OID.Course_No, Course_Title, Instuctor_Name)
STUDENT (OID,Section_No, Student_Name, Major)
OUTCOME (OID,Student_No, Course_No, Grade)
Transforming an E-R diagram to relations (parts a and b)
CUSTOMER
Customer_ID
Customer_Name
Customer_Address
CARD ACCOUNT
Account_ID
Expiration_Date
Card_Type
Customer_ID
DEBIT CARD
D_Account_ID
Bank_No
C_Account_ID
Current_Balance
CHARGES
Merchant_ID
C_Account_ID
Date
MERCHANT
MERCHANT_ID
Merchant_Address
Amount
Chapter 5
91
part c: using an enterprise key
OBJECT
OID
Object_Type
CUSTOMER
OID
Customer_ID
Customer_Name
Customer_Address
Account_ID
Expiration_Date
Card_Type
Customer_OID
D_Account_OID
Bank_No
C_Account_OID
Current_Balance
Merch_OID
C_Account_ID
Date
Amount
Merch_ID
Merch_Address
CARD_ACCOUNT
OID
DEBIT_CARD
OID
CREDIT_CARD
OID
CHARGES
OID
MERCHANT
OID
92
6.
Modern Database Management, Sixth Edition
Transforming Table 5-2 to relations:
a.
PART SUPPLIER
Part_No
1234
1234
5678
5678
5678
b.
c.
Description
Logic Chip
Logic Chip
Memory Chip
Memory Chip
Memory Chip
Vendor_Nam
Fast Chips
Smart Chips
Fast Chips
Quality Chips
Smart Chips
Part_No
Vendor_Name
Part_No, Vendor_Name
Address
Cupertino
Phoenix
Cupertino
Austin
Phoenix
Unit_Cost
10.00
8.00
3.00
2.00
5.00
Description
Address
Unit_Cost
Insert anomaly: we cannot insert a new vendor unless we also include a
part number.
Delete anomaly: if we delete part information, we also lose information
about a vendor who supplies that part.
Modification anomaly: if a vendor address changes, we have to modify all
records (or rows) for that vendor.
d.
Part_No
e.
f.
Description
Vendor_Name
1NF
PART SUPPLIER
Part_No
Description
Part_No
Vendor_Name
Vendor_Name
Address
Unit_Cost
Addres
Unit_Cost
Chapter 5
7.
93
Transforming Table 5-3 to relations:
a.
Student
_ID
Student
_Name
b.
c.
Campus
_Address
Major
Course
_Title
Course_I
Instructor
_Name
1NF
STUDENT
Student_ID
Student_Name
Campus_Address
REGISTRATION
Student_ID
COURSE_ID
Grade
COURSE
COURSE_ID
Course_Title
Instructor_Name
INSTRUCTOR
Instructor_Name
Instructor_Location
Major
Instructor
_Location
Grade
94
Modern Database Management, Sixth Edition
d.
STUDENT
Student_ID
Student_Name
Campus_Address
Major
REGISTRATION
Student_ID
Course_ID
Grade
COURSE
Course_ID
Course_Title
Instructor_Name
INSTRUCTOR
Instructor_Name
Instructor_Location
8.
attribute version:
EMPLOYEE
Employee_ID
Employee_Name
SKILL
Employee_ID
Skill_Code
Skill_Title
Skill_Type
Chapter 5
95
relationship version:
EMPLOYEE
Employee_ID
Employee_Name
POSSESSES
Employee_ID
Skill_Code
SKILL
Skill_Code
Skill_Title
Skill_Type
The attribute version of the 3NF relations is similar to Figure 5-10. However, we have a
much clearer definition of a primary key in this version. One main advantage of the
relationship version is that we do not have to store skill_title and skill_type many times.
If a skill title was changed or types were reclassified, this would make things much easier
since update anomalies are eliminated.
Suggestions for Field Exercises
1. For this exercise, we suggest you interview at least two organizations: a
manufacturing company and a service sector organization (you may choose to
combine this exercise with Field Exercise 2 in Chapter 4). First, determine what
methodology (if any) each uses for conceptual design: E-R diagrams, object
diagrams, etc. Then determine how these models are transformed to logical data
models (relational schema, object-oriented designs, etc.). To what extent are these
activities automated through the use of CASE tools? If the target data model is
relational, determine the role of normalization: who is responsible for normalization,
to what level is it performed, and how are users involved (if at all) in these activities?
2. We suggest you first perform this exercise as an in-class exercise with student
participation in the process. Bring a copy of your own document to class, and ask the
students to volunteer a document as well. This provides students with valuable
“hands-on” experience in the bottom-up design process.
3. For this exercise you may choose to assign a sample relational schema (such as
Figure 6-13b or 6-19b) as a basis for comparing the CASE tools.
4. This exercise is really a continuation of Exercise 2 above, now possibly applied to a
more complex document. Use a report (or other document) that has detail lines and
requires the use of normalization skills.
96
Modern Database Management, Sixth Edition
Project Case
Project Questions
1.
2.
3.
4.
Mountain View Community Hospital will continue to use relational technology
for several reasons:
a.
The present IS staff is trained and experienced in using this technology.
b.
The present relational systems are stable and support existing operations
quite well.
c.
Conversion to newer technology would be costly and would entail a
number of risks.
Yes, Mountain View Community Hospital should use normalization in designing
its relational database. Normalization helps avoid anomalies that impair data
quality.
Entity integrity and referential integrity are important:
a.
Entity integrity helps assure that two real-world entities (such as patient or
tests) are not confused.
b.
Referential integrity helps assure that one real-world entity (such as a test
result) is not lost or disassociated from its owner entity (such as patient).
All users of data in the organization should be consulted during the normalization
process to ensure that the meaning and usage of data have been understood
correctly.
Project Exercises
(See the next page)
Chapter 5
1.
97
Relational schemas for Mountain View Community Hospital.
a.
Schema for E-R diagram (Exercise 2, Chapter 3):
WARD
Ward_No
Ward_Name
Employee_No
ASSIGNED
Ward_No
Employee_No
Hours
EMPLOYEE
Employee_No
Employee_Name
BED
BED_NO
Ward_No
Room_No
PATIENT_NO
PATIENT
Patient_No
Patient_Name
Physician_ID
Physician_ID
Treatment_No
PERFORMS
Patient_No
TREATMENT
PHYSICIAN
Physician_ID
Treatment_No
Physician_Name
CONSUMES
Patient_No
Item_No
Date
Quantity
ITEM
Item_No
Results
Description Unit_Cost
TREATMENT_NAME
98
Modern Database Management, Sixth Edition
b.
Schema for EER diagram (Exercise 1, Chapter4):
PERSON
PERSON_ID
Name
Address
City_State_Zip
Birth_Date
PATIENT
PA_PERSON_ID
Contact_Date
PH_PERSON_ID
PHYSICIAN
PH_PERSON_ID
Pager_No
Specialty
VOLUNTEER
V_Person_ID
Skill
EMPLOYEE
Date_Hired
E_Person_ID
NURSE
N_Person_ID
Certificate
Name
STAFF
S_Person_ID
Job_Class
TECHNICIAN
T_Person_ID
Skill
LAB ASSIGN
T_Person_ID
Name
LABORATORY
Name
Location
CARE CENTER
Name
Location
Phone
Chapter 5
To PATIENT
99
RESIDENT
R_Person_ID
Date_Admitted
OUTPATIENT
O_Person_ID
(OTHER)
BED
Bed_No
Room_No
R_Person_ID
VISIT
O_Person_ID
2.
3.
4.
Date
Comments
The functional dependencies are diagrammed in the above figures.
All of the relations are 3NF.
First, we will create enterprise keys for the E-R diagram:
OBJECT
OID
Object_Type
WARD
OID
Ward_No
Ward_Name
Employee_OID
Ward_OID
Employee_OID
Hours
Employee_No
Employee_Name
Bed_No
Ward_OID
ASSIGNED
OID
EMPLOYEE
OID
BED
OID
Room_No
Patient_OID
to
Patient
100
Modern Database Management, Sixth Edition
PATIENT
OID
Patient_No
Patient_Name
Physician_OID
Patient_OID
Physician_OID
Treatment_OID
Physician_ID
Physician_Name
Treatment_No
Treatment_Name
Patient_OID
Item_OID
Date
Item_No
Description
Unit_Cost
PERFORMS
OID
Results
PHYSICIAN
OID
TREATMENT
OID
CONSUMES
OID
ITEM
OID
Quantity
Chapter 5
101
EER Diagram:
OBJECT
OID
Object_Type
PERSON
OID
Person_ID
Name
Address
Birth_Date
City_State_Zip
Phone
PATIENT
OID
PA_PERSON_OID
Contact_Date
PH_OID
PH_PERSON_OID
Pager_No
Speciality
PHYSICIAN
OID
VOLUNTEER
OID
V_PERSON_OID
Skill
OID
E_PERSON_OID
Date_Hired
OID
N_PERSON_OID
EMPLOYEE
NURSE
Certificate
CARE_OID
to
CARE_CENTER
STAFF
OID
S_PERSON_OID
Job_Class
T_PERSON_OID
Skill
TECHNICIAN
OID
102
Modern Database Management, Sixth Edition
LAB_ASSIGN
OID
to TECHNICIAN
LAB_OID
TECH_OID
LABORATORY
OID
Location
Name
to NURSE
CARE CENTER
OID
Location
Name
to PATIENT
RESIDENT
OID
R_PERSON_OID
Date_Admitted
to PATIENT
OUTPATIENT
OID
O_PERSON_OID
(Other)
OID
Bed_No
Room_No
RES_OID
OID
OUTPATIENT_OID
Date
Comments
BED
VISIT
Chapter 5
5.
103
Following are some sample CREATE TABLE commands. Please note, in order
for these to work correctly in Oracle, they must be executed in the order specified
in this solution.
a.
E-R diagram:
CREATE TABLE OBJECT
(OID
VARCHAR2(5) Primary Key,
Object_Type VARCHAR2(20));
CREATE TABLE EMPLOYEE
(OID
VARCHAR2(5) Primary Key,
Employee_NO
VARCHAR2(5),
Employee_Name
VARCHAR2(20),
Foreign Key (OID) References Object(OID));
CREATE TABLE WARD
(OID
VARCHAR2(5) Primary Key,
Ward_NO
VARCHAR2(5),
Ward_Name
VARCHAR2(20),
Employee_OID
VARCHAR2(5) references EMPLOYEE(OID),
Foreign Key (OID) References OBJECT(OID));
CREATE TABLE ASSIGNED
(OID
VARCHAR2(5) Primary Key,
WARD_OID
VARCHAR2(5) references WARD(OID),
EMPLOYEE_OID VARCHAR2(5) references EMPLOYEE(OID),
Hours
NUMBER(4,2),
Foreign Key (OID) References OBJECT(OID));
CREATE TABLE PHYSICIAN
(OID
VARCHAR2(5) Primary Key,
Physician_ID
VARCHAR2(5),
Physician_Name
VARCHAR2(20),
Foreign Key (OID) References OBJECT(OID));
CREATE TABLE PATIENT
(OID
VARCHAR2(5) Primary Key,
Patient_No
VARCHAR2(5),
Patient_Name
VARCHAR2(20),
PHYSICIAN_OID VARCHAR2(5) references PHYSICIAN(OID),
Foreign Key (OID) References OBJECT(OID));
104
Modern Database Management, Sixth Edition
CREATE TABLE BED
(OID
VARCHAR2(5) Primary Key,
Bed_No
VARCHAR2(3),
Ward_OID
VARCHAR2(5) references WARD(OID),
Room_No
VARCHAR2(5),
Patient_OID
VARCHAR2(5) references PATIENT(OID),
Foreign Key (OID) References OBJECT(OID));
CREATE TABLE TREATMENT
(OID
VARCHAR2(5) Primary Key,
Treatment_No
NUMBER(5),
Treatment_Name
VARCHAR2(20),
Foreign Key (OID) References OBJECT(OID));
CREATE TABLE PERFORMS
(OID
VARCHAR2(5) Primary Key,
PATIENT_OID
VARCHAR2(5) references PATIENT(OID),
PHYSICIAN_OID VARCHAR2(5) references PHYSICIAN(OID),
TREATMENT_OID VARCHAR2(5) references TREATMENT(OID),
RESULTS
VARCHAR2(20),
Foreign Key (OID) References OBJECT(OID));
CREATE TABLE ITEM
(OID
VARCHAR2(5) Primary Key,
Item_No
VARCHAR2(5),
Description
VARCHAR2(20),
Unit_Cost
NUMBER(5,2),
Foreign Key (OID) References OBJECT(OID));
CREATE TABLE CONSUMES
(OID
VARCHAR2(5) Primary Key,
PATIENT_OID
VARCHAR2(5) references PATIENT(OID),
ITEM_OID
VARCHAR2(5) references ITEM(OID),
DATE
DATE,
QUANTITY
NUMBER(5),
Foreign Key (OID) References OBJECT(OID));
Chapter 5
b.
EER diagram:
CREATE TABLE OBJECT
(OID
VARCHAR2(5) Primary Key,
Object_Type VARCHAR2(20));
CREATE TABLE PERSON
(OID
VARCHAR2(5) Primary Key,
Person_ID VARCHAR2(5),
Name
VARCHAR2(20),
Address
VARCHAR2(30),
Birth_Date Date,
City
VARCHAR2(20),
State
VARCHAR2(2),
Zip
VARCHAR2(10),
Phone
VARCHAR2(14),
foreign key (OID) references OBJECT(OID));
CREATE TABLE PHYSICIAN
(OID
VARCHAR2(5) Primary Key,
PH_PERSON_OID VARCHAR2(5) references PERSON(OID),
Pager_No
VARCHAR2(14),
Speciality
VARCHAR2(20),
foreign key (OID) references OBJECT(OID));
CREATE TABLE PATIENT
(OID
VARCHAR2(5) Primary Key,
PA_PERSON_OID VARCHAR2(5) references PERSON(OID),
Contact_Date
Date,
PH_OID
VARCHAR2(5) references Physician(OID),
foreign key (OID) references OBJECT(OID));
CREATE TABLE VOLUNTEER
(OID
VARCHAR2(5) Primary Key,
V_PERSON_OID VARCHAR2(5) references PERSON(OID),
Skill
VARCHAR2(20),
foreign key (OID) references OBJECT(OID));
CREATE TABLE EMPLOYEE
(OID
VARCHAR2(5) Primary Key,
E_PERSON_OID
VARCHAR2(5) references PERSON(OID),
Date_Hired
Date,
foreign key (OID) references OBJECT(OID));
105
106
Modern Database Management, Sixth Edition
CREATE TABLE CARE_CENTER
(OID
VARCHAR2(5) Primary Key,
Name
VARCHAR2(20),
Location
VARCHAR2(20),
foreign key (OID) refences OBJECT(OID));
CREATE TABLE NURSE
(OID
VARCHAR2(5) Primary Key,
N_PERSON_OID VARCHAR2(5) references EMPLOYEE(OID),
Certificate
VARCHAR2(2),
CARE_OID
VARCHAR2(5) references CARE_CENTER(OID),
foreign key (OID) references OBJECT(OID));
CREATE TABLE STAFF
(OID
VARCHAR2(5) Primary Key,
S_PERSON_OID
VARCHAR2(5) references EMPLOYEE(OID),
Job_Class
Number(2),
foreign key (OID) references OBJECT(OID));
CREATE TABLE TECHNICIAN
(OID
VARCHAR2(5) Primary Key,
T_PERSON_OID
VARCHAR2(5) references EMPLOYEE(OID),
Skill
VARCHAR2(10),
foreign key (OID) references OBJECT(OID));
CREATE TABLE LABORATORY
(OID
VARCHAR2(5) Primary Key,
Name
VARCHAR2(20),
Location
VARCHAR2(20),
foreign key (OID) references OBJECT(OID));
CREATE TABLE LAB_ASSIGN
(OID
VARCHAR2(5) Primary Key,
TECH_OID
VARCHAR2(5) references TECHNICIAN(OID),
LAB_OID
VARCHAR2(5) references LABORATORY(OID),
foreign key (OID) references OBJECT(OID));
CREATE TABLE RESIDENT
(OID
VARCHAR2(5) Primary Key,
R_PERSON_OID VARCHAR2(5) references PATIENT(OID),
Date_Admitted
Date,
foreign key (OID) references OBJECT(OID));
Chapter 5
107
CREATE TABLE OUTPATIENT
(OID
VARCHAR2(5) Primary Key,
O_PERSON_OID VARCHAR2(5) references PATIENT(OID),
foreign key (OID) references OBJECT(OID));
CREATE TABLE BED
(OID
VARCHAR2(5) Primary Key,
Bed_No
VARCHAR2(5),
Room_No
VARCHAR2(5),
RES_OID
VARCHAR2(5) references RESIDENT(OID),
foreign key (OID) references OBJECT(OID));
CREATE TABLE VISIT
(OID
VARCHAR2(5) Primary Key,
O_PERSON_OID VARCHAR2(5) references OUTPATIENT(OID),
Date
Date,
Comments
VARCHAR2(50),
foreign key (OID) references OBJECT(OID));
6.
You can use this exercise (or a selected subset) to illustrate the problems of
merging relations described in the chapter. You can also use this exercise to
anticipate the design of a data warehouse that consolidates user views (see
Chapter 11).