ZEIT2301- Database Design Normalisation School of Engineering and Information Technology Dr Kathryn Merrick Bldg 16, Rm 212 (Thursdays and Fridays only)

Topic 08: Database Normalisation Designing a ‘good’ relational database Normal forms First normal form Second normal form Third normal form

A Motivating Example Suppose we want to develop a database of bike statistics for a program that permits users to find out whether or not each bike can stoppie.

A file for such data might be… Harley false Harley one pax false Honda true Honda one pax true Bike description Wheelbase Centre of mass height Coefficient of friction This column contains two types of data (bike type and number of passengers) This column contains duplicate (redundant) data Data in this column is not even bike dependent Can stoppie?

Relations Relations are data tables with rows and columns Row Column

Attributes Attributes are named columns of relations Out bike example has five attributes: Bike description WheelbaseCentre of mass height Coefficient of friction Can stoppie

Domains The domain of an attribute is the set of allowable values for that attribute Attribute domains in our bike example: AttributeDomain Bike descriptionAlphanumeric: size 60; WheelbaseNumeric: range [0-5] Centre of mass heightNumeric: range [0-5] Coefficient of frictionNumeric: range [0-1] Can stoppieBoolean: one of [true, false]

Records (Tuples) A record or tuple is one row of data in a relation Our bike example has four records Bike descriptionWheelbas e Centre of mass height Coefficient of friction Can stoppie Harley false Harley one pax false Honda true Honda one pax true

Relational Databases A relational database is a collection of normalised relations Normalisation is a technique for producing a set of tables that conform to desirable redundancy and integrity constraints There are three common normal forms: First normal form Second normal form Third normal form

First Normal Form (1NF) A table is in 1NF if: The intersection of every column and record contains only one value and It has a primary key attribute that uniquely identifies every record

Keys (Revision) Superkey: a column or set of columns that uniquely identifies a record in a relation Candidate key: a superkey with the minimum number of columns Primary key: the candidate key selected for identification purposes Foreign key: a column or set of columns in one table that matches a candidate key of another table

12 Decomposition to 1NF Remove multi-valued attributes Add a primary key

The bike example in 1NF Bike name Number of riders WheelbaseCentre of mass height Coefficient of friction Can stoppie Harley false Harley false Honda true Honda true Bike name* Number of riders* WheelbaseCentre of mass height Coefficient of friction Can stoppie Harley false Harley false Honda true Honda true

Second Normal Form (2NF) A table is in 2NF if: It is in 1NF and The values in each non-primary-key column depend on value in all primary key columns (ie: not a subset of the primary keys)

15 Decomposition for 2NF Remove non-primary key attributes that are not fully functionally dependant on the primary key Place them in a new relation with the part of the primary key on which they are functionally dependant (i.e. their determinant) Consider replacing compound primary keys with non- compound keys

16 Full Functional Dependency Examine the non key attributes in “creditRecord”: address employer interestRate limit From the FDs given, the attributes address, employer and interestRate are not dependent on the whole primary key The attribute limit is fully functionally dependent on the primary key creditRecord(customer, creditCard, address, employer, limit, interestRate)

The bike example in 2NF Bike name*Wheelbase Harley1.588 Honda1.458 Scenario ID* Bike name Number of riders Centre of mass height Coefficient of friction Can stoppie 1Harley false 2Harley false 3Honda true 4Honda true

Third Normal Form (3NF) A table is in 3NF if: It is in 1NF and It is in 2NF and The values in each non-primary-key column depend on values in only the primary key columns

19 Transitive Functional Dependency Cnsider a relation with attributes A, B, and C. If B is functional dependent on A (A  B), and C is functional dependent on B (B  C), then C is transitively dependent on A. A  B, B  C If any non-key attribute is transitively dependent on the primary key, the relation is not in 3NF.

The bike example in 3NF Bike name* Number of riders* Centre of mass height Harley Harley Honda Honda Road conditions* Coefficient of friction Icy0.1 Wet0.5 Dry0.9 Scenario ID* Bike name Number of riders Road conditions Can stoppie 1Harley1Dryfalse 2Harley2Dryfalse 3Honda1Drytrue 4Honda2Drytrue Bike name* Wheelbase Harley1.588 Honda1.458

21 “Codd’s Law of Normalization” Thou shalt depend upon the key (1NF), the whole key (2NF), and nothing but the key (3NF)!

22 Normalization Exercise: 1NF? member No namehomeCityhobbysportsportHQ 833ChangSydneycoin collectingNetballLyneham 834JonesCanberradrag racing, video games AFLEssendon 927WickenPerthvideo gamesAFLEssendon 968ApartiDarwincoin collecting, drag racing RugbyRandwick 972NixonPerthtiddlywinksNetballLyneham member(memberNo, name, homeCity, hobby, sport, sportHQ)

Session 1, Normalization Exercise: 1NF membe r No namehome CitysportsportHQ 833ChangSydneyNetballLyneham 834JonesCanberraAFLEssendon 927WickenPerthAFLEssendon 968ApartiDarwinRugbyRandwick 972NixonPerthNetballLyneham member(memberNo, name, homeCity,hobby, sport, sportHQ) memberHobby(memberNo, hobby) member No hobby 833coin collecting 834drag racing 834video games 927video games 968coin collecting 968drag racing 972tiddlywinks Both tables are in 1NF: All attributes are single valued and depend on PK

24 Normalization Exercise: 2NF? membe r No namehome CitysportsportHQ 833ChangSydneyNetballLyneham 834JonesCanberraAFLEssendon 927WickenPerthAFLEssendon 968ApartiDarwinRugbyRandwick 972NixonPerthNetballLyneham member(memberNo, name, homeCity, sport, sportHQ) FDs: memberNo  name, homeCity, sport, sportHQ sport  sportHQ Do all non-key attributes depend on the whole PK?

Session 1, Normalization Exercise: 2NF member No namehome CitysportsportHQ 833ChangSydneyNetballLyneham 834JonesCanberraAFLEssendon 927WickenPerthAFLEssendon 968ApartiDarwinRugbyRandwick 972NixonPerthNetballLyneham member(memberNo, name, homeCity, sport, sportHQ) FDs: memberNo  name, homeCity, sport, sportHQ sport  sportHQ Do all non-key attributes depend on the whole PK? PK is not composite. All attributes depend on the PK. Table is in 2NF

26 Normalization Exercise: 3NF? membe r No namehome CitysportsportHQ 833ChangSydneyNetballLyneham 834JonesCanberraAFLEssendon 927WickenPerthAFLEssendon 968ApartiDarwinRugbyRandwick 972NixonPerthNetballLyneham member(memberNo, name, homeCity, sport, sportHQ) FDs: memberNo  name, homeCity, sport, sportHQ sport  sportHQ Are there any transitive dependencies between non- key attributes?

Session 1, Normalization Exercise: 3NF member No namehome Citysport 833ChangSydneyNetball 834JonesCanberraAFL 927WickenPerthAFL 968ApartiDarwinRugby 972NixonPerthNetball member(memberNo, name, homeCity, sport) sport(sport, sportHQ) FDs: memberNo  name, homeCity, sport, sportHQ sport  sportHQ Decompose based on transitive dependencies. NB. Maintain a link between tables sportsportHQ NetballLyneham AFLEssendon RugbyRandwick

Session 1, Normalization Exercise: 3NF sport(sport, sportHQ) FDs: memberNo  name, homeCity, sport, sportHQ sport  sportHQ sport table: 1NF (all attributes single valued and dependant on PK) 2NF (attribute depends on the whole key) 3NF (no transitive dependencies between non- key attributes) sportsportHQ NetballLyneham AFLEssendon RugbyRandwick

29 Normalization Exercise: 2NF 3NF memberHobby(memberNo, hobby) member Nohobby 833coin collecting 834drag racing 834video games 927video games 968coin collecting 968drag racing 972tiddlywinks memberHobby table: 1NF: All attributes are single- valued 2NF: Table is all key. No non- key attributes so table is in 2NF 3NF: No non-key attributes so no transitive dependencies between them!

Summary After today’s lecture you should be able to: Design a normalised relational database in First normal form Second normal form Third normal form