Professional Documents
Culture Documents
Normalization Why?
All relations are not equal Tables not normalized experience issues known as modification problems
Insertion problems
Difficulties inserting data into a relation
Modification problems
Difficulties modifying data into a relation
Deletion problems
Difficulties deleting data from a relation
Deletion Anomaly
If you delete any row, you delete information about both the machine and the repair
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Modification Anomalies
The EQUIPMENT_REPAIR table before and after an incorrect update operation on AcquisitionCost for Type = Drill Press:
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Normalization
Normalization is a process of analyzing a relation to ensure that it is well formed More specifically, if a relation is normalized (well formed), rows can be inserted, deleted, or modified without creating update anomalies
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Normalization Review:
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Should we store these two tables as they are, or should we combine them into one table in our new database?
Normal Forms
Relations are categorized as a normal form based on which modification anomalies or other problems that they are subject to:
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Normal Forms
1NF A table that qualifies as a relation is in 1NF 2NF A relation is in 2NF if all of its nonkey attributes are dependent on all of the primary key [focus is on composite primary keys] 3NF A relation is in 3NF if it is in 2NF and has no determinants except the primary key Boyce-Codd Normal Form (BCNF) A relation is in BCNF if every determinant is a candidate key
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
BCNF
Boyce-Codd Normal Form (BCNF) A relation is in BCNF if every determinant is a candidate key I swear to construct my tables so that all nonkey columns are dependent on the key, the whole key and nothing but the key, so help me Codd.
Normalization Review:
Definition Review
Determinant
The attribute that can be used to find the value of another attribute in the relation The right-hand side of a functional dependency
StudentID (StudentName, DormName, DormRoom)
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Normalization Review:
Definition Review II
Candidate key
The value of a candidate key can be used to find the value of every other attribute in the table A simple candidate key consists of only one attribute A composite candidate key consists of more than one attribute
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
What is the primary key? What are the candidate keys? What are the non-keyed attributes?
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Simple Examples
Remember the question:
Is every determinant a candidate key or are all nonkey columns dependent on the key, the whole key and nothing but the key?
Normalization Example
(StudentID) (StudentName, DormName, DormCost) What are the determinants? Does StudentID determine Student Name? Does Student ID determine Dorm Name? Does Student ID determine Dorm cost? Probably not more likely Dorm Name does If so, Dorm Name is a determinate of Dorm cost Is StudentID a candidate key? Is Dorm Name a candidate key?
Is every determinant a candidate key Are all nonkey columns dependent on the key, the whole key and nothing but the key?
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Normalization Example
(StudentID)
However, if
(DormName)
Then DormCost should be placed into its own relation, resulting in the relations:
(StudentID) (DormName)
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Normalization Example
(AttorneyID,Cl ientID)
ATTORNEY (ClientName, AttorneyID MeetingDate, Duration) ClientID ClientName MeetingDate Duration
However, if
(ClientID) (ClientName)
Then .
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Then ClientName should be placed into its own relation, resulting in the relations:
(AttorneyID,C lientID)
(ClientID)
SCHEDULE AttorneyID ClientID MeetingDate Duration
(MeetingDate, Duration)
(ClientName)
CLIENT ClientID ClientName
Is this in 1NF?
Characteristics of 1NF
Characteristics
Table Format No repeating groups Primary key (PK) identified
Steps to 1NF
1. Eliminate repeating groups.
Present data in a tabular format, where each cell has a single value and there are no repeating groups.
Repeating Groups
Do you see the repeating group in this table?
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Steps to 1NF
2. Identify the Primary Key (PK)
At a first glance the AIRCRAFT_NUMBER seems a good candidate for a PK, but would not uniquely identify all of the remaining row attributes. The combination of AIRCRAFT_NUMBER and PILOT_NUMBER is a PK candidate that will uniquely identify all row attributes.
Table in 1NF
Identify Dependencies
AIRCRAFT_NUMBER, PILOT_NUMBER --> AIRCRAFT_NAME, PILOT_NAME, MISSION_CLASS, FLYING_HOUR, COST_HOUR
Primary Key (PK) dependency. The PK is also a composite key.
Identify Dependencies
PILOT_NUMBER --> PILOT_NAME
Partial dependency ... pilot name is only dependent on a part of the composite AIRCRAFT_NUMBER, PILOT_NUMBER key.
Create relationships between these new tables and their predecessors through the use of foreign keys.
http://databases.about.com/od/specificproducts/a/2nf.htm
Steps to 2NF
Notice how moving partial dependencies separates into key components
AIRCRAFT PILOT FLYING HOURS
Steps to 2NF
Assign dependent attributes to each key component
AIRCRAFT ( AIRCRAFT_NUMBER,
AIRCRAFT_NAME )
3-38
3-39
3-40
Are all determinants candidate keys? Often when in 3NF, also in BCNF
Steps to BCNF
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Another Example
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
FD: ItemNumber (Type, AcquisitionCost) RepairNumber (ItemNumber, Type, AcquisitionCost, RepairDate, RepairAmount)
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
SKU_DATA (SKU, SKU_Description, Buyer) BUYER (Buyer, Department) Where BUYER.Buyer must exist in SKU_DATA.Buyer
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
Multivalued Dependencies
A multivalued dependency occurs when a determinant determines a particular set of values:
Employee Degree Employee Sibling PartKit Part
Multivalued Dependencies
KROENKE and AUER - DATABASE CONCEPTS (3rd Edition) 2008 Pearson Prentice Hall
References
Example for AirPilot:
http://dotnet.org.za/willy/archive/2008/04/10/ta king-a-step-back-database-normalisation-1nf2nf-3nf-bcnf-and-4nf-part-1.aspx
Good reference
http://www.bkent.net/Doc/simple5.htm