1. Example Question–Is this relation Well Structured? Student
Reg_Num
Name
Program
CGPA
Course_Title
Completed
100
Umar
BICSE
3.4
DLD
24‐01‐2009
ICT Fund.
06‐05‐2009
140
Ali
BEE
3.6
Eng. Design
110
Usman
BIT
3.1
DB D & Imp
15‐02‐2010
190
Akbar
MSIT
0.0
150
Fatima
MSCSE
2.9
Net Sec
06‐01‐2009
Ad. Net Com
Student
Question–Is this a relation?
Answer–Yes: Unique rows and no multivalued attributes
Question–What’s the primary key?
Answer–Composite: Reg_Num, Course_Title
Question–Is this relation Well Structured?
ISE230 Normalization

2. Well‐Structured Relations
A relation that contains minimal data redundancy and allows users to insert, delete, and update rows without causing data inconsistencies
Goal is to avoid anomalies
Insertion Anomaly – adding new rows forces user to create duplicate data
Deletion Anomaly – deleting rows may cause a loss of data that would be needed for other future rows
Modification Anomaly – changing data in a row forces changes to other rows because of duplication
General rule of thumb: A table should not pertain to more than one entity type
ISE230 Normalization

3. Insertion Anomalies Consider these two records from STUDENT:
150
Fatima
MSCSE
2.9
Net Sec
06‐01‐2009
MCSE
Ad. Net Com
Suppose that we want to add a new student – the primary key for this relation is the combination of Reg_Num and Course_Title. Therefore, to insert a new row, the user must supply both these values (since primary keys cannot be null or nonexistent)
Can’t enter a new student without having the student take a class
This is an anomaly, since the user should be able to enter student data without supplying course data
ISE230 Normalization

4. Deletion and Modification Anomalies
Suppose that the data for a particular student are deleted from the table
This results in losing the information that this student completed a particular course
This results in losing the information that this course was offered – deletion anomaly
Example: If we remove student 140, we lose information about the existence of a Eng. Design class.
If student 150 changes the program, this must be recorded in both the rows of the table otherwise the data will be inconsistent – modification anomaly
ISE230 Normalization

5. Anomalies in the Tables
Why do these anomalies exist?
Because there are two themes (entity types) in this one relation. This results in data duplication and an unnecessary dependency between the entities
These anomalies indicate that STUDENT is not a well‐ structured relation
We should use normalization theory to divide STUDENT into multiple relations
For example one for STUDENT core information and the other one for student’s COURSE information to keep track of the course details.
ISE230 Normalization

6. Data Normalization
Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data
Redundancies in a table (such as more than one entry for each STUDENT) may result in errors and inconsistencies (anomalies) when the table is updated
The process of decomposing relations with anomalies to produce smaller, well‐structured relations
The formal process for deciding which attributes should be grouped together
ISE230 Normalization

7. Steps in Normalization
ISE230 Normalization

8. First Normal Form (1NF)
Each regular entity type in an ER diagram is transformed into a relation
The name given to the relation is generally the same as the entity type
Each simple attribute of the type becomes an attribute of the relation
The identifier of the entity type becomes the primary key of the corresponding relation
No multivalued attributes, every attribute value is atomic

9. Transformation Steps and Rules
Step 1: Map Regular Entities
Composite and Multi‐valued Attributes
Step 2: Map Weak Entities
Step 3: Map Binary Relationships
One to Many, Many to Many, One to One
Step 4: Map Associative Entities
Step 5: Map Unary Relationships
One to Many, and Many to Many
Step 6: Map Ternary (n‐ary) Relationships
Step 7: Map Supertype/Subtype Relationships

10. Transforming ERD to Relations
This can be done automatically by many CASE tools, but it is important to understand the process:
CASE tools often cannot model complex data relationships such as ternary relationships and supertype/subtype relationships.
For these situations you may have to perform these steps manually.
Sometimes alternative solutions exist, and you must choose the best
You must be able to quality check the CASE tool results

11. Example
Tables with no multi‐valued attributes and unique rows are in 1st normal form
This is valid relation in 1st normal form, but not a well‐structured one

12. Anomalies in this Table
Insertion – if new product is ordered for order 1007 of existing customer, customer data must be re‐entered, causing duplication
Deletion – if we delete the Dining Table from Order , we lose information concerning this item's finish and price
Update – changing the price of product ID 4 requires update in several records
Why do these anomalies exist?
Because there are multiple themes (entity types) in one relation. This results in duplication and an unnecessary dependency between the entities

13. Functional Dependencies and Keys
Functional Dependency: The value of one attribute (the
determinant) determines the value of another attribute.
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.
Candidate Key:
An attribute, or combination of attributes, that uniquely identifies a row in a relation.
One of the candidate keys will become the primary key
E.g. perhaps there is both credit card number and NIC# in a table…in this case both are candidate keys
Each non‐key field should be functionally dependent on every candidate key

14. Second Normal Form (2NF)
A relation is in 2NF if it is in 1NF plus every non‐key attribute is fully functionally dependent on the ENTIRE primary key.
Every non‐key attribute must be defined by the entire key, NOT by only part of the key.
Every relation whose primary key consists of just one attribute is automatically in Second Normal Form.
Every non‐key attribute is functionally depended on the full set of PK attributes.
No partial functional dependencies

15. Functional Dependency Diagram ‐ Invoice
Order_ID € Order_Date, Customer_ID, Customer_Name, Customer_Address
Customer_ID € Customer_Name, Customer_Address Product_ID € Product_Description, Product_Finish, Unit_Price Order_ID, Product_ID € Order_Quantity
Therefore, NOT in 2nd Normal Form

16. Getting it into Second Normal Form
Remove Partial Dependencies by splitting the relation into multiple relations where full dependency is achieved
Partial dependencies are removed, but there are still transitive dependencies

17. Third Normal Form
2NF PLUS no transitive dependencies (functional dependencies on non‐primary‐key attributes)
Note: This is called transitive, because the primary key is a determinant for another attribute, which in turn is a determinant for a third
Solution: Non‐key determinant with transitive dependencies go into a new table; non‐key determinant becomes primary key in the new table and stays as foreign key in the old table

18. Getting it into Third Normal Form
Transitive dependencies are removed

19. Words of Caution in Merging Relations
View Integration–Combining entities from multiple ER models into common relations
Issues to watch out for when merging entities from different ER models:
Synonyms–two or more attributes with different names but same meaning
Homonyms–attributes with same name but different meanings
Transitive dependencies–even if relations are in 3NF prior to merging, they may not be after merging
Supertype/subtype relationships–may be hidden prior to merging

20. Conclusion Summary Essential Reading Assignment What is Next?
Normalization is a tool to validate and improve a logical design so that it satisfies certain constraints that avoid
unnecessary duplication of data
Essential Reading
Modern Database Management (8th Ed.), Chapter 5
Assignment
□ Exercises: 7,8, 17, 18, 19, 22, 23
Find anomalies in Cricket DB and then Normalize.
What is Next?
Database Development Process
Course Review