Normalization is based on the analysis of functional dependencies. Functional dependency is a constraint between two attributes or two sets of attributes.

For any relation R, attribute B is functionally dependent on attribute A if, for every valid instance of A, that value of A uniquely determines the value of B Dutka and Hanson

1.

2.

A functional dependency of B on A is represented by an arrow, as follows A B. An attribute may be functionally dependent on two (or more) attributes. Common Examples of functional dependencies SSN Name, Address, Birthdate. A persons name, address and birthdate are functionally dependent on that persons Social Security Number. VIN Make, Model, Color. The make, model and color of a vehicle are functionally dependent on the vehicle identification number.

Determinant the attribute on the left-hand side of the arrow in a functional dependency. (SSN ,VIN) Candidate Key an attribute, or combination of attribute that uniquely identifies a row in a relation. A candidate key must satisfy the ff:

Unique identification. For every row, the value of the key must uniquely identify that row. This property implies that each nonkey attribute is functionally dependent on that key. Nonredundancy. No attribute in the key can be deleted without destroying the property of unique identification.

PERSON(SSN, Name, Address, Birthdate). SSN is the only determinant in this relation. All of the other attributes are functionally dependent on SSN. Therefore SSN is a candidate key and (since there are no other candidate key) also is the primary key.

Normalization is the process of decomposing relations with anomalies to produce smaller, well-structured relations. Normal Form a state of a relation that results from applying simple rules regarding functional dependencies (or relationships between attributes) to that relation.

First Normal Form (1NF). Any multivalued attributes (also called repeating groups) have been removed, so there is a single value (possibly null) at the intersection of each row and column of the table. For a DB to be 1NF, every table must have 2 properties:

Each column (field) must contain only one value. There cannot be repeating columns of associated data.

To make DB 1NF compliant:

1. 2. 3.

Identify any field that contains multiple pieces of information Break up any field found in Step 1 into separate fields Double-check that all new fields created in Step 2 pass the 1NF.
ACCOUNTING_DB Invoice_Number Invoice_Date Invoice_Amount Invoice_Description Date_Invoice_Paid Client_Name Client_Street_Add

ACCOUNTING_DB Invoice_Number Invoice_Date Invoice_Amount Invoice_Description Date_Invoice_Paid Client_Information Expense_Amount Expense_Category_and Description Expense_Date
1NF

Client_City Client_State Client_Zip Client_Phone Expense_Amount Expense_Category Expense_Description Expense_Date

To normalize the DB, you must remove redundant pieces of information such as client and expense data to their own tables.
INVOICE Invoice_Number Invoice_Date Invoice_Amount Invoice_Description Date_Invoice_Paid EXPENSE Expense_Amount Expense_Category Expense_Description Expense_Date CLIENT Client_Name Client_Street_Add Client_City Client_State Client_Zip Client_Phone

Second Normal Form (2NF) any particular dependencies have been removed. To make a DB 2NF compliant: Identify any fields that do not relate directly to the primary key. Create new tables accordingly. Assign or create new primary keys Repeat steps 1-3 Create the requisite foreign keys indicating the relationships.

1.

2. 3. 4. 5.

CLIENT PK Client_ID INVOICE PK Invoice_Number Invoice_Date Invoice_Amount Invoice_Description Date_Invoice_Paid EXPENSE Expense_Amount Expense_Category Expense_Description Expense_Date Client_Name Client_Street_Add Client_City Client_State Client_Zip Client_Phone

INVOICE assign Invoice_Number as PK CLIENT create Client_ID as PK

INVOICE PK Invoice_Number Invoice_Date Invoice_Amount Invoice_Description Date_Invoice_Paid EXPENSE PK Expense_ID Expense_Amount Expense_Description Expense_Date PK

CLIENT PK Client_ID Client_Name Client_Street_Add Client_City Client_State Client_Zip Client_Phone EXPENSE_CATEGORY Expense_Category_ID Expense_Category

EXPENSE split into two tables EXPENSE and EXPENSE_CATEGORY EXPENSE assign Expense_ID as PK EXPENSE_CATEGORY assign Expense_Category_ID as PK

INVOICE PK Invoice_Number FK Client_ID Invoice_Date Invoice_Amount Invoice_Description Date_Invoice_Paid EXPENSE PK Expense_ID FK Expense_Category_ID Expense_Amount Expense_Description Expense_Date PK

CLIENT PK Client_ID Client_Name Client_Street_Add Client_City Client_State Client_Zip Client_Phone EXPENSE_CATEGORY Expense_Category_ID Expense_Category

INVOICE assign Client_ID as FK EXPENSE assign Expense_Category_ID as FK

Third Normal Form (3NF) any transitive dependencies have been removed. To make a DB 3NF compliant: Identify any fields that violate the 3NF rule. Create new tables or move fields accordingly. Assign or create new primary and foreign keys, if necessary. Double-check the design for 1NF, 2NF and 3NF compliance.

1. 2. 3.

4.

INVOICE PK Invoice_Number FK Client_ID Invoice_Date Invoice_Amount Invoice_Description Date_Invoice_Paid Contact_Name Contact_Email

CLIENT PK Client_ID Client_Name Client_Street_Add Client_City Client_State Client_Zip Client_Phone EXPENSE_CATEGORY

EXPENSE PK Expense_ID FK Expense_Category_ID Expense_Amount Expense_Description Expense_Date

PK

Expense_Category_ID Expense_Category

INVOICE PK Invoice_Number FK Client_ID Invoice_Date Invoice_Amount Invoice_Description Date_Invoice_Paid EXPENSE PK Expense_ID FK Expense_Category_ID Expense_Amount Expense_Description Expense_Date PK

CLIENT PK Client_ID Client_Name Client_Street_Add Client_City Client_State Client_Zip Client_Phone Contact_Name Contact_Email EXPENSE_CATEGORY Expense_Category_ID Expense_Category

EMPLOYEE1 Emp_ID Name Dept_Name Salary

EMPLOYEE2

Emp_ID

Course_Title

Name

Dept_Name

Salary

Date_Completed

Emp_ID, Course_Title Date_Completed Emp_ID Name, Dept_Name, Salary

The primary key for EMPLOYEE2 is the composite key Emp_ID, Course_Title. Therefore the nonkey attributes Name, Dept_Name, and Salary are functionally dependent on part of the primary key (Emp_ID) but on Course_Title. Partial functional dependency a functional dependency in which one or more nonkey attributes are functionally dependent on part (but not all) of the primary key.

SALES Cust_ID 8023 9167 7924 6837 8596 7018 Name Anderson Bancroft Hobbs Tucker Eckersley Arnold Salesperson Smith Hicks Smith Hernandez Hicks Faulb SALES Cust_ID Name Salesperson Region Region South West South East West North

Region is functionally dependent on Salesperson and Salesperson is functionally dependent on Cust_ID. Therefore there is a transitive dependency.

Transitive dependency A functional dependency between two (or more) non key attribute. Solution: Decompose to another table.
SALES Cust_ID Name Salesperson SPERSON Salesperson Region

Emp_ID

Name

Dept_Name

Salary

Course_Title

Date_Completed

100

Simpson Beeton Lucero Davis

Marketing Accounting Info Sys. Finance

48000 52000 43000 55000

SPSS Surveys Tax Acc SPSS C++

6-19-200X 10-7-200X 12-8-200X 1-12-200X 4-22-200X

140 110

190

Multivalued attribute is an attribute that may take on more than one value for a given entity instance.

Boyce/Codd Normal Form Any remaining anomalies that results from functional dependencies have been removed. Fourth Normal Form any multivalued dependencies have been removed. Fifth Normal Form Any remaining anomalies have been removed.

Convert this user view to a set of 3NF relations using an enterprise key. Assume the following:

An instructor has a unique location. An student has a unique major. A course has a unique title.
TINY COLLEGE CLASS LIST Fall Semester 200X Course No: Course Title: Instructor Name: Instructor Location: STUDENT NO. 38214 40875 51893 IS 460 Database Norma L. Form B 104 STUDENT NAME Bright Cortez Edwards IS CS IS MAJOR A B A GRADE