1. The Relational Model and Normalization (1)
IS 240 – Database Management
Lecture #7 – Prof. M. E. Kabay, PhD, CISSP
Norwich University
M. E. Kabay, PhD, CISSP
Copyright © 2002 M. E. Kabay All rights reserved.

2. Copyright © 2002 M. E. Kabay. All rights reserved.
Topics
Intro to DB Design
Relational Model
Definitions
Functional Dependencies
Keys
Uniqueness
Homework
Copyright © 2002 M. E. Kabay All rights reserved.

3. Intro to DB Design: Kroenke Part III, Chapter 5
Need a language for thinking about entity relationships
How can they be modeled using general concepts of database tools?
Equivalent to developing program design using pseudocode
Can translate designs into real code more easily than by working only with compilers or DBMS
Normalization helps to sort out information in ways that can easily be handled in DBMS
Copyright © 2002 M. E. Kabay All rights reserved.

4. Relational Model: Definitions
Different terminologies used by mathematicians, information technologists (IT) and users to describe information relationships
Math: relation, attribute, tuple; cell = attribute X tuple
IT: file (or dataset), field, record; cell = field X record
Users: table, column, row; cell = column X row
Copyright © 2002 M. E. Kabay All rights reserved.

5. Copyright © 2002 M. E. Kabay. All rights reserved.
Definitions (cont’d)
Row
Column
Cell
Table
Copyright © 2002 M. E. Kabay All rights reserved.

6. Copyright © 2002 M. E. Kabay. All rights reserved.
Definitions (cont’d)
Record
Field
File
Cell
Copyright © 2002 M. E. Kabay All rights reserved.

7. Copyright © 2002 M. E. Kabay. All rights reserved.
Definitions (cont’d)
Tuple
Attribute
Relation
Cell
Copyright © 2002 M. E. Kabay All rights reserved.

8. Constraints of the Relational Model
Each cell contains a single value (no lists, tables, arrays)
All instances of an attribute (field, column) must be instances of the same quality; e.g.,
License number – and not VINS or color
Height – and not weight or eye-color
Salary – and all yearly or all monthly totals
Every attribute (field, column) is uniquely identified (same name in all tuples (records, rows)
Every tuple (record, row) is unique
Order of attributes and tuples is arbitrary – many designs are functionally equivalent
Copyright © 2002 M. E. Kabay All rights reserved.

9. Functional Dependencies
Relationship among attributes that
Permits one to determine the value of one attribute . . .
. . . given the value of another attribute
Examples
Student_ID allows student to find out the current GPA
Part_Number leads to current inventory
Clinical_Code allows insurance carrier to determine fee to be paid to doctor
Copyright © 2002 M. E. Kabay All rights reserved.

10. Functional Dependencies (cont’d)
Representing a functional dependency
“Part_Number functionally determines Part_Cost”
“Part_Number determines Part_Cost”
“Part_Cost is dependent on Part_Number”
“Part_Number  Part_Cost”
In general, we say that a determinant determines the dependent attribute.
Determinant  dependent attribute
Copyright © 2002 M. E. Kabay All rights reserved.

11. Functional Dependencies (cont’d)
There is theoretically an N:1 relationship between determinant and dependant attribute
A Part_Number determines exactly one Part_Cost
However, it is normal to expect that many different Part_Numbers may have the same particular Part_Cost
Another formulation states that attribute X determines attribute Y, then X:Y::N:1
It is also possible that X:Y::1:1; e.g.,
Patient_ID  SSN (in theory)
Copyright © 2002 M. E. Kabay All rights reserved.

12. Functional Dependencies (cont’d)
A functional dependency may involve more than two attributes; e.g.,
if Extended_Price = Part_Price X Quantity_Ordered, then
“Extended price is functionally dependent on part price and quantity ordered.”
(Part_Price, Quantity_Ordered) Extended_Price
Other examples:
(State, Car_Reg#)  Owner_Name
(Patient_ID, Admission_Date)  (Room#, Bed#)
Copyright © 2002 M. E. Kabay All rights reserved.

13. Functional Dependencies (cont’d)
Functional dependencies are directional
If A  (B,C) we say that A determines both B and C; or in other words,
A  B and A  C
However, suppose (D,E) F
Then it does not follow that D  F
nor that E  F
E.g., if (Stock_Name, Date)  Stock_Price one cannot assert
That knowing the Stock_Name alone tells us the Stock_Price, nor
That knowing the Date alone tells us the Stock_Price
Copyright © 2002 M. E. Kabay All rights reserved.

14. Copyright © 2002 M. E. Kabay. All rights reserved.
Keys
A group of one or more attributes (fields, columns) that uniquely identifies a tuple (records, row) is called a key; e.g.,
In a hospital DB, Doctor_ID might identify all the current attributes of a physician including name, address, SSN, specialty (or specialties), and so on; this would be the key
But a patient record might be constructed to reflect the current admission; in which case Patient_ID and Admission_Date might be required to identify the current record uniquely; the key would be (Patient_ID,Admission_Date)
Copyright © 2002 M. E. Kabay All rights reserved.

15. Copyright © 2002 M. E. Kabay. All rights reserved.
Keys (cont’d)
Every relation has at least one key
No record (tuple, row) may duplicate another
Many relations have several possible keys
Determining which attributes or combinations of attributes are keys requires analysis of the business model
There is no “answer at the back of the book”
Analyst must find out what the users do with their data – e.g., do they care about historical records or only about the current status? [Explain why this matters.]
Copyright © 2002 M. E. Kabay All rights reserved.

16. Copyright © 2002 M. E. Kabay. All rights reserved.
Normalization
Not all relations are equally useful
Some cause problems when we add, delete or change part of the data in the relations
Modification Anomalies
Essence of Normalization
Classes of Relations
Copyright © 2002 M. E. Kabay All rights reserved.

17. Modification Anomalies
Suppose we have a record that stores information about a client who has bought something at our store
Client#
Client_Name
Client_Address
Client_Phone
Item#
Item_Name
Item_Price
Date_Purchased
But what if we want to get rid of old client records without losing the Item#, Item_Name and Item_Price?
How do we handle changing the price of an item without altering historical records?
What do we do to manage the attributes of an item that no one has bought?
Copyright © 2002 M. E. Kabay All rights reserved.

18. Copyright © 2002 M. E. Kabay. All rights reserved.
Deletion Anomaly
Patient record has information about Doctor_ID, Doctor_Name, Doctor_Phone etc.
So what happens when we delete the last patient record that contains information about a particular doctor?
Garage mechanic stores Auto_Name, Auto_VIN, Repair_type, Repair_type_cost
So how does the mechanic remember the cost of changing a muffler if she deletes the last record that happens to contain information about that type of repair?
Copyright © 2002 M. E. Kabay All rights reserved.

19. Copyright © 2002 M. E. Kabay. All rights reserved.
Insertion Anomaly
A factory DB has a relation that groups Part#, Part_Name, Part_Cost, Inventory_Bin#, Bin_location, Bin_Capacity, Quantity_on_hand
How would one add information about a part that has not yet been assigned a bin#?
How would one handle information about a part that gets assigned to two separate bins at different parts of the factory?
Could one add information about a new bin without actually having a part assigned to it?
Copyright © 2002 M. E. Kabay All rights reserved.

20. Referential Integrity
A DB used to handle information about library books includes a relation between many books and specific publishers. One publisher may be related to many books but each book has only one publisher.
What problems will occur if the record for the last book from a publisher is deleted? Should this delete publisher information?
Should it be possible to delete the record for a publisher even though there are many books left from that publisher?
These rules are described as referential integrity constraints or inter-relation constraints
Copyright © 2002 M. E. Kabay All rights reserved.

21. Copyright © 2002 M. E. Kabay. All rights reserved.
Homework
Study Kroenke’s Chapter 5 pp 121 – 127 thoroughly using the full SQ3R method.
Prepare for class on Tuesday the 17th of February 2004 by doing the SQ phases of SQ3R on pages of Chapter 5. We will complete our introduction to normalization on Tuesday. This is difficult material, so STUDY.
By Thursday 19 Feb 2004 – for 10 points
Write out the answers to questions 5.1 to 5.10 and submit them at the start of class
By Thursday 26 Feb 2004 – for up to 6 extra points,
Write out and submit the answers to question 5.24 parts a through f
Copyright © 2002 M. E. Kabay All rights reserved.

22. Copyright © 2002 M. E. Kabay. All rights reserved.
DISCUSSION
Copyright © 2002 M. E. Kabay All rights reserved.