Case Description

You have been introduced to the Mountain View Community Hospital (MVCH) case in the preceding
chapters. This chapter continues the case, with special emphasis on logical design for the relational data
model. Although the hospital will continue to evaluate newer technology (e.g., object-oriented
databases, XML, and XML databases), it is expected that relational technology will continue to dominate
its systems development over the next few years.

The assistant administrator at MVCH has asked you to review the data used in the patient billing and
accounting systems. Occasional errors have been discovered in patient statements and the patient
records maintained by the hospital. As part of this effort, you have selected four user views for analysis.
Simplified versions of these views are shown in MVCH Figures 4-1 through 4-4 and described briefly
here:

 Patient bill (MVCH Figure 4-1) This statement is presented to the patient (or patient
representative) when the patient is discharged. Assume that each item on the bill has a unique
description and that the charge for a particular item may vary from one patient to another.

 Room utilization report (MVCH Figure 4-2) This is a daily report that is distributed to qualified
personnel. The information can also be retrieved online by a qualified staff member. It shows
the status of each room and bed location in the hospital and is used primarily for scheduling and
tracking the utilization of facilities. The Location column in this report records the room number
and bed location in the room. The Accom column indicates the type of accommodation (PR =
private, SP = semiprivate).
 Patient display (MVCH Figure 4-3) This display is presented on demand to any qualified doctor,
nurse, or other staff member. Assume that for each location there is a unique telephone
number.

 Daily physician report (MVCH Figure 4-4) This report is prepared daily for each physician on the
staff of MVCH. It shows the patients who have been treated on that day by the physician and
the name of the treatment (or procedure). To simplify the analysis, assume that each patient
may receive only one treatment from a given physician on a given day. (We ask you to comment
on this assumption later.)
 a. Using the normalization steps described in this chapter, develop a set of 3NF relations for each
of the four user views.
b. For each user view, draw a relational schema for the 3NF relations you developed in Case
Exercise 1a. Be sure to show the functional dependencies and referential integrity constraints
for each schema.
c. Merge the relations for the four user views into a single set of 3NF relations, using the guidelines
presented in this chapter. Draw a single relational schema for the four user views and show the
referential integrity constraints.
d. Suggest any refinements to the design in Case Exercise 1c that would promote data quality and
integrity.
e. How would you change your approach to accommodate the rule that a patient may receive
multiple treatments from a given physician on a given day?

Solution

Normalization:

 The process used to minimize data redundancy and dependency in a relational database is
known as normalization.
 The database table is divided into two or more tables and defines the relationship between
those tables.
 If the modifications, deletion or updates occur in one table, the other tables in database get
updated by just propagating it.
 In a relational database, the tables with no redundant data and less null values are considered
as efficient table.
 Because, having redundant data and more null values increases the storage space and wastage
of memory is imminent.
 Null values cause a problem for data integrity and produces more error in the database.
 If the wasted storage space and null values which cause data integrity hazards are minimized, a
highly optimized relational database can be designed.
 The project team should consider using normalization when designing the database, which is the
best source to optimize data storage efficiently, because, it reduces the data storage space and
provides data integrity.

Note:

 In the diagrams, to indicate primary and foreign keys notational conventions are used.
o The attributes noted with underlined name are primary key values.
o The attributes noted with italics letters are foreign key values.
The following user views are converted into 3NF relations, and the relational schema for the 3NF
relations are drawn and show functional dependencies and referential integrity constraints.

 Patient bill
 Room utilization report
 Patient Display
 Daily Physician Report

a) Convert the user views to 3NF relations for the following:

Third normal form:
 For the third normal form the first and basic requirement is that the model should be in
the first and second normal form.
 The value of any non-primary key attributes will not depend on any other non-primary
key attributes.
o If any non-primary key attributes are dependent on any other non-primary key
attribute then it should moved or deleted.
o It is termed as transitive dependency.

The 3NF relations are developed from the relation who is decomposed from the user views.

Patient bill:

Before normalization:

The diagram given below gives the description for the patient bill. It describes the stage before
the normalization of the patient bill. The user view is converted into a relation and it is shown
below:
After normalization in 3NF:

The diagram given below gives the description for the patient bill. It describes the stage after the
normalization of the patient bill. The third normal form has been used in this case.

 In this, a new relation should be created from the above relations, which is not
normalized, which is used to connect the old and new entities to provide the
relationship.
 The relations created here are INVOICE, ACCOUNT, PATIENT, PATIENT CHARGES and
ITEM.
 By assumption and using some constraints the attributes are allocated to each relation.
The user view is converted into a 3NF relation and it is shown below:

Explanation:

 In the INVOICE relation,

o A relation does not have any repeating attributes.
o The non-key attributes are dependent on primary key InvoiceNbr.
o There is only functional dependency and no transitive dependency.
o Therefore, the relation is in 3NF.

 In the ACCOUNT relation,

o A relation does not have any repeating attributes.
 o The non-key attribute is dependent on primary key AcountNbr.
o There is no transitive dependency, it contains only functional dependency.
o Therefore, the relation is in 3NF.

 In the PATIENT relation,

o A relation does not have any repeating attributes.
o The non-key attributes are dependent on primary key PatientNbr.
o There is only functional dependency and no transitive dependency.
o Therefore, the relation is in 3NF.

 In the PATIENT CHARGES relation,

o A relation does not have any repeating attributes.
o The non-key attributes depend on InvoiceNbr and ItemCode.
o There is no transitive dependency.
o Therefore, the relation is in 3NF.

 In the ITEM relation

o A relation does not have any repeating attributes.
o The non-key attribute Description is dependent on primary key ItemCode.
o There is only functional dependency and no transitive dependency.
o Therefore, the relation is in 3NF.

Room utilization report:

Before normalization:

The diagram given below gives the description for the patient bill. It describes the stage before
the normalization of the room utilization report. The user view is converted into a relation and it
is shown below:
After normalization in 3NF:

The diagram given below gives the description for the patient bill. It describes the stage after the
normalization of the room utilization report. The third normal form has been used in this case.

 In this, a new relation should be created from the above relations which is not
normalized, which is used to connect the old and new entities to provide the
relationship.
 The relations created here are ROOM, OCCUPANCY, PATIENT and DISCHARGE.
 By assumption and using some constraints the attributes are allocated to each relation.
The user view is converted into a 3NF relation and it is shown below:

Explanation:

 In the ROOM relation,

o A relation does not have any repeating attributes.
o The non-key attributes are dependent on primary key Location.
o There is only functional dependency and no transitive dependency.
o Therefore, the relation is in 3NF.

 In the OCCUPANCY relation,

o A relation does not have any repeating attributes.
 o The non-key attribute PatientNbr is dependent on primary key DateAdmitted.
o There is no transitive dependency, it contains only functional dependency.
o Therefore, the relation is in 3NF.

 In the PATIENT relation,

o A relation does not have any repeating attributes.
o The non-key attribute PatientName is dependent on primary key PatientNbr.
o There is only functional dependency and no transitive dependency.
o Therefore, the relation is in 3NF.

 In the DISCHARGE relation,

o A relation does not have any repeating attributes.
o The non-key attribute ExpDateDischarged is dependent on primary key attribute
DateAdmitted.
o There is no transitive dependency.
o Therefore, the relation is in 3NF.

Patient Display:

Before normalization:

The diagram given below gives the description for the patient bill. It describes the stage before
the normalization of the patient display. The user view is converted into a relation and it is
shown below:
The diagram given below gives the description for the patient bill. It describes the stage after the
normalization of the patient display. The third normal form has been used in this case.

 In this, a new relation should be created from the above relations which is not
normalized, which is used to connect the old and new entities to provide the
relationship.
 The relations created here are ROOM, ADMISSION, and PATIENT.
 By assumption and using some constraints the attributes are allocated to each relation.
The user view is converted into a 3NF relation and it is shown below:
Explanation:

 In the ROOM relation,

o A relation does not have any repeating attributes.
o The non-key attribute Ext is dependent on primary key Location.
o There is only functional dependency and no transitive dependency.
o Therefore, the relation is in 3NF.

 In the ADMISSION relation,

o A relation does not have any repeating attributes.
o The non-key attributes are dependent on primary key DateAdmitted.
o There is no transitive dependency, it contains only functional dependency.
o Therefore, the relation is in 3NF.

 In the PATIENT relation,

o A relation does not have any repeating attributes.
o The non-key attributes in the relation are functionally dependent on primary
key PatientNbr.
o There is only functional dependency and no transitive dependency.
o Therefore, the relation is in 3NF.

Daily physician report:

Before normalization:

The diagram given below gives the description for the patient bill. It describes the stage before
the normalization of the daily physician report. The user view is converted into a relation and it
is shown below:
After normalization in 3NF:

The diagram given below gives the description for the patient bill. It describes the stage after the
normalization of the daily physician report. The third normal form has been used in this case.

 In this, a new relation should be created from the above relations which is not
normalized, which is used to connect the old and new entities to provide the
relationship.
 The relations created here are PHYSICIAN, TREATS, PATIENT, and PROC LOCATION.
 By assumption and using some constraints the attributes are allocated to each relation.
The user view is converted into a 3NF relation and it is shown below:

Explanation:

 In the PHYSICIAN relation,

o A relation does not have any repeating attributes.
o The non-key attribute does not depend on other non-key attribute in the
relation.
o There is no transitive dependency.
 o Therefore, the relation is in 3NF.

 In the TREATS relation,

o A relation does not have any repeating attributes.
o The non-key attributes are dependent on primary key ProcedureDate.
o There is no transitive dependency, it contains only functional dependency.
o Therefore, the relation is in 3NF.

 In the PATIENT relation,

o A relation does not have any repeating attributes.
o The non-key attribute in the relation PatientName is functionally dependent on
primary key PatientNbr.
o There is only functional dependency and no transitive dependency.
o Therefore, the relation is in 3NF.

 In the PROC LOCATION relation,

o A relation does not have any repeating attributes.
o The non-key attribute does not depend on other non-key attribute in the
relation.
o There is no transitive dependency.
o Therefore, the relation is in 3NF.

b) Draw relational schema with functional dependencies and show referential integrity

The relational schema for the third normal form relations is shown below with the functional
dependencies and referential integrity constraints.

Functional dependency:
 An association between two attributes or two set of attributes in a same relational
database table which is having some constraints is known as functional dependency.
 In a table one attribute is functionally dependent on another attribute to take one value.

Referential integrity:

 Referential integrity is supported by RDBMS (Relational Database Management System).

 Relational database is basically a collection of the tables where every table has a specific
key assigned to it; which is known as primary key.
 The values in the each row of a table are unique. Two tables are related to each other
with the help of foreign key.
 Referential integrity is a special feature of RDBMS, which ensures the data entered by
the user is valid and consistent.
 It is done with the help of primary and foreign key, which links the tables together and it
checks whether the values are correctly synchronized.

Patient bill:

The patient bill user view is converted into 3NF relations, the functional dependencies and
the referential integrity in the relations are shown below.

Explanation:

In the INVOICE relation,

 InvoiceNbr, AccountNbr, InvoiceDate, DueDate, DateAdmitted, DateDischarged are

its attributes.
 InvoiceNbr is the primary key attribute.
 AccountNbr is the foreign key attribute and it refers ACCOUNT relation to get any
values.

Functional dependency in INVOICE relation:

  AccountNbr, InvoiceDate, DueDate, DateAdmitted, DateDischarged are functionally
dependent on InvoiceNbr.

In the ACCOUNT relation,

 AccountNbr and PatientNbr are its attributes.

 AccountNbr is the primary key attribute.
 PatientNbr is the foreign key attribute and it refers PATIENT relation to get any
values.

Functional dependency in ACCOUNT relation:

 PatientNbr is functionally dependent on AccountNbr.

In the PATIENT relation,

 PatientNbr, PatientName, PatientAddress, City, State, and Zip are its attributes.
 PatientNbr is the primary key attribute.

Functional dependency in PATIENT relation:

 PatientName, PatientAddress, City, State, and Zip are functionally dependent on

PatientNbr.

In the PATIENT CHARGES relation,

 InvoiceNbr, ItemCode, and Charge are its attributes.

 InvoiceNbr and ItemCode are the foreign key attribute and it refers INVOICE and
ITEM relations to get any values.

Functional dependency in PATIENT CHARGES relation:

 ItemCode and Charge are functionally dependent on InvoiceNbr.

In the ITEM relation,

 Description and ItemCode are its attributes.

 ItemCode is the primary key attribute.
Functional dependency in ITEM relation:

 Description is functionally dependent on ItemCode.

Room utilization report:

The room utilization report user view is converted into 3NF relations, the functional
dependencies and the referential integrity in the relations are shown below.

Explanation:

In the ROOM relation,

 Accom and Location are its attributes.

 Location is the primary key attribute.

Functional dependency in ROOM relation:

 Accom is functionally dependent on Location.

In the OCCUPANCY relation,

 Location, DateAdmitted and PatientNbr are its attributes.

 DateAdmitted is the primary key attribute.
 Location and PatientNbr are the foreign key attribute and it refers to ROOM and
PATIENT relations to get any values.

Functional dependency in OCCUPANCY relation:

 PatientNbr is functionally dependent on Location and DateAdmitted.

In the PATIENT relation,

 PatientName and PatientNbr are its attributes.

 PatientNbr is the primary key attribute.

Functional dependency in PATIENT relation:

 PatientName is functionally dependent on PatientNbr.

In the DISCHARGE relation,

 PatientNbr, DateAdmitted and ExpDateDischarged are its attributes.

 DateAdmitted is the primary key attribute.
 PatientNbr is the foreign key attribute and it refers PATIENT relation to get any
values.

Functional dependency in DISCHARGE relation:

 ExpDateDischarged is functionally dependent on PatientNbr and DateAdmitted.

Patient Display:

The patient display user view is converted into 3NF relations, the functional dependencies
and the referential integrity in the relations are shown below.
Explanation:

In the ROOM relation,

 Ext and Location are its attributes.

 Location is the primary key attribute.

Functional dependency in ROOM relation:

 Ext is functionally dependent on Location.

In the ADMISSION relation,

 Location, DateDischarged, DateAdmitted and PatientNbr are its attributes.

 DateAdmitted is the primary key attribute.
 Location and PatientNbr are the foreign key attribute and it refers to ROOM and
PATIENT relations to get any values.

Functional dependency in ADMISSION relation:

 PatientNbr is functionally dependent on Location and DateAdmitted.

In the PATIENT relation,

 PatientNbr, PatientName, PatientAddress, City, State, and Zip are its attributes.
 PatientNbr is the primary key attribute.
Functional dependency in PATIENT relation:

 PatientName, PatientAddress, City, State, and Zip are functionally dependent on

PatientNbr.

Daily physician report:

The daily physician report user view is converted into 3NF relations, the functional
dependencies and the referential integrity in the relations are shown below.

Explanation:

In the PHYSICIAN relation,

 PhysicianID and PhysicianPhone are its attributes.

 PhysicianID is the primary key attribute.

Functional dependency in PHYSICIAN relation:

  PhysicianPhone is functionally dependent on PhysicianID.

In the TREATS relation,

 PhysicianID, PatientNbr, ProcedureDate and Procedure are its attributes.

 ProcedureDate is the primary key attribute.
 PhysicianID and PatientNbr are the foreign key attribute and it refers to PHYSICIAN
and PATIENT relations to get any values.

Functional dependency in TREATS relation:

 Procedure is functionally dependent on PhysicianID, PatientNbr, ProcedureDate.

In the PATIENT relation,

 PatientName and PatientNbr are its attributes.

 PatientNbr is the primary key attribute.

Functional dependency in PATIENT relation:

 PatientName is functionally dependent on PatientNbr.

In the PROC LOCATION relation,

 PatientNbr, ProcedureDate and Location are its attributes.

 ProcedureDate is the primary key attribute.
 PatientNbr is the foreign key attribute and it refers PATIENT relation to get any
values.

Functional dependency in PROC LOCATION relation:

 Location is functionally dependent on PatientNbr and ProcedureDate.

c) The four user relations are merged together as a single relation:
The merged relationships for the four user views into a solitary set of third normal form
relations are given below. It describes the relationship by showing the connection amongst all of
the view of the user.

d) Refinement for the Case Exercise 1C:

To promote data quality and data integrity in the Case Exercise 1C, one valid suggestion is to
include the surrogate primary key for the TREATS relation.

Surrogate primary key:

 A system assigned primary key in a relational database such as a serial number or any
other which is not derived from any data in the database is known as surrogate primary
key.
 It is deputy of the primary key and it will act as a primary key in the database and does
not have any other significance.
 The inclusion of surrogate key will manipulate the errors and there is no clause of
uncertainty. It gives a fine execution. The overall result is positive.

e) Change the rule to accommodate a patient to receive multiple treatments on a given day from
a specific physician

The approach to accommodate the rule that a patient may take multiple treatments from a
given doctor on a given day is done by two methods:

 An attribute Time can be added to the TREATS relation, which gives different times for
different treatments in a particular day.
 Another one is to include the surrogate primary key for the TREATS relation, which gives
a different serial number for each treatment.