1. Relation A B C D E F 1NF? 2NF? 3NF? Relation1 A B Relation2 A* C D E* Help me Codd!! Relation3 E F Normalisation Reading: Connolly and Begg 13 & 14 (4th ed),

2. Normalisation From this… …to this In 3+ easy(?) steps

3. What is normalisation? A method for database design – Theory examines how “good” is a schema? – Transform non-normalised schemas – Minimise storage Takes a set of attributes and derives the relational model – By separating out the required tables Completely different approach to ERM – But should get the same result A minimum of 3 steps are used: For each stage, the normal form gets stronger (i.e. removes redundancy) so less open to update anomalies All based on functional dependencies

4. Functional Dependency Underpins normalisation process If every value of column A uniquely determines the value in column B, then – B is functionally dependent on A (B depends on A) – A determines B, or, formally, A  B (A is called the determinant) For example, – EmpID  Age, Dept (A  B,C) Employee ID, Project  Role (X, Y  Z) – Note multiple attributes are often involved EmpID Project Age Dept Dsize Budget Role

5. Rules for functional dependency A  B does NOT automatically mean B  A – E.g. student ID  name but not name  ID Transitive dependency: If A  B and B  C then A  C Many other rules – E.g. if X,Y  Z but X  Z also – In this case Z is partially dependent on X,Y “Transitive” and “partial” dependency are two key concepts of the normalisation process

6. A Question for you! EmpID Project Age Dept Dsize Budget Role E1 P233D210100Analyst E1 P133D210200Prog. E2 P134D510200Prog. E2 P234D520100Analyst Which functional dependency is violated by the data? A B C D

7. Unnormalised Form Relation contains: – non-atomic attribute values non-atomic values ID Employee Salary Project 1 Grey 31000A 2 Brown 35000B,C 3 White 55000A,B,C 4 Black 47000A,C Violation of 1NF

8. First Normal Form Permits only single (atomic) attribute values ID Employee Salary 1 Grey 31000 2 Brown 35000 3 White 55000 4 Black 47000 ID (fk) Project Budget 1A10 2B5 2C5 3A5 3B5 3C5 4A10 4C5 Remove Repeating Group along with primary key from other Table ID Employee Salary Project Budget 1Grey31000A10 2Brown35000B5 2Brown35000C5 3White55000A5 3White55000B5 3White55000C5 4Black47000A10 4Black47000C5 redundancyRepeating

9. Full Functional Dependency (FFD) X  Y is FFD – if removal of any attribute from X removes the dependency X  Y is partially dependent – if removal of attribute from X leaves the dependency intact 2NF test – involves testing for partial dependency on the PK (therefore PK MUST be composite to test for 2NF) Relation R is in 2NF if: – every non-primary-key attribute in R is FFD on the primary key of R Second Normal Form

10. So which FD’s are violating 2NF? “Second Normalised” by: – removing non-primary-key attributes and forming a FFD on appropriate part of primary key 2NF EmpID Project Age Dept Dsize Budget Role {EmpID,Age, Dept, Dsize}{EmpID*, Project*, Role} {Project, Budget}

11. Third Normal Form Remove Transitive Dependency Conditions – A non-primary-key attribute Z is transitively dependent on primary key X if: X  Y; Y  Z (Y attribute provides the transition to the PK) [EmpID* Project* Role] [Project Budget] [EmpID Age Dept Dsize] A B C Which of the above could have transitive dependency? D None of the above

12. Here is an un-normalised Table Ord# Date Cust#NameProd# Desc Qty Supplier Tel 112/1/01 1Jones1Disk3X101 112/1/01 1Jones2CD5Y223 213/1/01 2Black1Disk1X101 213/1/01 2Black2CD1Y223 213/1/01 2Black3Mouse1X101 313/1/01 1Jones3Mouse1X101

13. Normalise it to 1NF Ord# Date Cust#Name 1 12/1/011Jones 2 13/1/012Black 3 13/1/011Jones Ord# Date Cust#NameProd# Desc Qty Supplier Tel 112/1/01 1Jones1Disk3X101 112/1/01 1Jones2CD5Y223 213/1/012Black1Disk1X101 213/1/012Black2CD1Y223 213/1/012Black3Mouse1X101 313/1/011Jones3Mouse1X101 Ord#Prod#DescQty Supplier Tel 11Disk3X101 12CD5Y223 21Disk1X101 22CD1Y223 23Mouse1X101 33Mouse 1X101 fk

14. Ord# Date Cust#Name 1 12/1/011Jones 2 13/1/012Black 3 13/1/011Jones Ord#Prod#DescQty Supplier Tel 11Disk3X101 12CD5Y223 21Disk1X101 22CD1Y223 23Mouse1X101 33Mouse 1X101 Already in 2NF Prod#DescSupplier Tel 1DiskX101 2CDY223 3Mouse X101 Ord#Prod# Qty 113 125 211 221 231 331 Now we normalise this to 2NF remembering to test on the PK for any partial dependency fk

15. So, any transitive dependency? Ord# Date Cust#Name 1 12/1/011Jones 2 13/1/012Black 3 13/1/011Jones Prod#DescSupplier Tel 1DiskX101 2CDY223 3Mouse X101 Ord#Prod#Qty 113 125 211 221 231 331 fk

16. Yes! But not in all ……………. Ord# Date Cust#Name 1 12/1/011Jones 2 13/1/012Black 3 13/1/011Jones Prod#DescSupplier Tel 1DiskX101 2CDY223 3Mouse X101 Prod#DescSupplier (fk) 1DiskX 2CDY 3Mouse X Ord# Date Cust# (fk) 1 12/1/011 2 13/1/012 3 13/1/011 Supplier Tel X101 Y223 Cust#Name 1Jones 2Black Ord#Prod#Qty 113 125 211 221 231 331 OK!

17. Final Decomposition Ord#{fk} Prod#{fk}Qty 113 125 211 221 231 331 Ord# Date Cust# (fk) 1 12/1/011 2 13/1/012 3 13/1/011 Cust#Name 1Jones 2Black Prod#DescSupplier (fk) 1DiskX 2CDY 3Mouse X Supplier Tel X101 Y223 Now in 3NF

18. The underlying E-R Model ….. Ord# Date Cust#NameProd# Desc Qty Supplier Tel 112/1/01 1Jones1Disk3X101 112/1/01 1Jones2CD5Y223 213/1/012Black1Disk1X101 213/1/012Black2CD1Y223 213/1/012Black3Mouse1X101 313/1/011Jones3Mouse1X101 CustomerOrder ProductSupplier 0..*1..1 0..* 1..11..* makes has despatches    How many tables would you get from mapping?

19. So Normalisation to 3NF is Normal!! Remember, 2NF and 3NF disallow partial and transitive dependencies respectively on the PK, otherwise they are open to update anomalies But ….. even at 3NF, a relation may be open to update anomalies on rare occasions due to redundancy too So we look briefly at these – Boyce-Codd – 4NF

20. Boyce-Codd NF Is a stronger normalised form then 3NF Definition: A relation is in BCNF, if and only if, every determinant is a candidate key And remember that a candidate key is any key that could become the PK of the relation (i.e. there may be competition for it!) Potential to violate BCNF comes from: – A relation containing at least 2 composite candidate keys – Or candidate keys overlapping (i.e. they have at least one attribute in common)

21. BCNF Example Consider the candidate keys for: Adapted from Connolly and Begg, 2005, 4 th ed. Page 420 clientNointerviewDateinterviewTimestaffNoroomNo CR7613/5/0810.30SG5G101 CR5613/5/0812.00SG5G101 CR7413/5/0812.00SG37G102 CR561/7/0810.30SG5G102 FD1 {PK}: clientNo, interviewDate  interviewTime, staffNo, roomNo FD2 {CK}: staffNo, interviewDate, interviewTime  clientNo FD3 {CK}: roomNo, interviewDate, interviewTime  staffNo, clientNo FD4: staffNo, interviewDate  roomNo PK is primary key and CK is candidate key. But what about FD4? It is not a CK

22. So new decomposition? clientNointerviewDate*interviewTimestaffNo* CR7613/5/0810.30SG5 CR5613/5/0812.00SG5 CR7413/5/0812.00SG37 CR561/7/0810.30SG5 interviewDatestaffNoroomNo 13/5/08SG5G101 13/5/08SG37G102 1/7/08SG5G102 So duplication in the room number is now eradicated

23. 4NF Comes from 2 multi- valued attributes in a relation E.g. for each value of A there is a set of values for B and a set for C, while B and C remain independent of each other Branch BranchNo staffName[1..*] ownerName[1..*] So if you model your databases from ERM’s this type of dependency should not arise.

24. Example of 4NF branchNostaffNameownerName C003AnneCarol C003DavidCarol C003AnneTina C003DavidTina branchNo*staffName C003Anne C003David branchNo*ownerName C003Carol C003Tina Note: if step 9 applied to multi-valued attributes then we should map this correctly and avoid such redundancy as the two tables on the right would be the result of the mapping! Adapted from Connolly and Begg, 2005, 4 th ed. Page 428

25. Normal Form Summary A Relation’s degree of normalisation Stronger in format at each stage – less vulnerable to update anomalies First Normal Form (1NF) – The relation has no non-atomic values – Or the relation has “no repeating group” 2 nd Normal Form (2NF) – The relation has no partial dependencies – All non-key attributes are fully functionally dependent on the PK 3 rd Normal Form (3NF) – The relation has no transitive dependencies Boyce-Codd – Every determinant is a candidate key 4NF – no multi-valued dependencies