The Relational Model and Normalization (3) IS 240 – Database Management Lecture # Prof. M. E. Kabay, PhD, CISSP Norwich University

2 Copyright © 2004 M. E. Kabay. All rights reserved. Topics Domain-Key Normal Form Going from Attributes to Relations Database Optimization Next Class – Review to Date Homework Note: Your handouts are 3 per page today because you should take lots of notes during the class – this is critically important material

3 Copyright © 2004 M. E. Kabay. All rights reserved. Domain-Key Normal Form Definition A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains. Constraint Any rule about attributes that can be judged true or false given the data at hand Constraints may not include time- dependent data; e.g., This months sales figures must be greater than last months

4 Copyright © 2004 M. E. Kabay. All rights reserved. DK/NF (contd) Key: Unique identifier of a tuple (row, record) Domain: two descriptions Physical description: The list of all allowed values of an attribute (column, field); e.g., Invoice_number begins with a 4-digit number indicating the year and terminates with a 4-digit number from 0000 to 9999 indicating the sequence number in the list of invoices for that year. Logical description: The meaning of the attribute in business terms: e.g., Invoice_number is the unique identifier for an invoice. A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

5 Copyright © 2004 M. E. Kabay. All rights reserved. DK/NF (contd) There is no algorithm known for converting relations to DK/NF Use intuition and practice Process for putting a relation into DK/NF: Define relations so that every constraint follows logically from the choice of keys and domains. Kroenke gives 3 examples pp STUDENT PROFESSOR STUDENT_ADVISOR A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

6 Copyright © 2004 M. E. Kabay. All rights reserved. Another Example: Rock Music Database College radio station wants to keep track of all the rock music played on air to answer questions such as When was the last time we played this cut? This CD? This band? On which show? Which DJ played it? How often have we played this cut / CD / band in the last period on show? Any show? What bands has a particular musician played with? What albums do we have from a particular band? What albums does a particular musician play on? What cuts does a particular musician play on?

7 Copyright © 2004 M. E. Kabay. All rights reserved. Music DB (contd) Entities: Musician Band Album Cut DJ Show A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

8 Copyright © 2004 M. E. Kabay. All rights reserved. Music DB (contd) Musician Artist_Name Birth_Date Death_Date Biographical_Notes A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

9 Copyright © 2004 M. E. Kabay. All rights reserved. Music DB (contd) Band_Name Date_Formed Date_Disbanded Date_Artists_Changed?? Band_Notes A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

10 Copyright © 2004 M. E. Kabay. All rights reserved. Music DB (contd) Album Album_Name Album_ID Date_Released Total_Minutes Number_Cuts A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

11 Copyright © 2004 M. E. Kabay. All rights reserved. Music DB (contd) Cut Cut_Name Album_ID Cut_Minutes A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

12 Copyright © 2004 M. E. Kabay. All rights reserved. Music DB (contd) DJ DJ_ID DJ_Name DJ_Joined DJ_Left DJ_Notes A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

13 Copyright © 2004 M. E. Kabay. All rights reserved. Music DB (contd) Show Show_Name Show_Date Show_Time DJ_ID A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

14 Copyright © 2004 M. E. Kabay. All rights reserved. Music DB (contd) Relations M:N MusicianBandAlbumCut M:N DJShow 1:NM:N Relational links: Musician_Band Band_Album Album_Cut Cut_Show DJ_Show Basic Entities: Musician Band Album Cut DJ Show M:N MusicianBand

15 Copyright © 2004 M. E. Kabay. All rights reserved. Going from Attributes to Relations 1:1 Relationships N:1 Relationships M:N Relationships Multi-value Dependencies

16 Copyright © 2004 M. E. Kabay. All rights reserved. 1:1 Relationships A B and B A then A:B::1:1 Student_ID SSN (in theory) SSN Student ID A uniquely identifies X and B uniquely identifies X then A:B::1:1 Student_ID DNA_Fingerprint SSN DNA_Fingerprint Then Student_ID SSN and SSN Student_ID Therefore Student_ID:DNA_Fingerprint::1:1 A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

17 Copyright © 2004 M. E. Kabay. All rights reserved. 1:1 Relationships Put 1:1 attributes in the same relation at least once in the database Any other attributes that are determined by either of the original attributes may be added to that relation E.g., Student_ID, SSN, Student_Name, Student_Home_Address, Student_Etc. A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

18 Copyright © 2004 M. E. Kabay. All rights reserved. N:1 Relationships If A B but NOT B A, then A:B::N:1 E.g., suppose a DJ may host several shows but a show has only one DJ; Then Show DJ but not DJ Show For DK/NF, all constraints are defined by keys Therefore every determinant must be a key E.g., the relation DJ_SHOW has SHOW as a key but not DJ Why? A relation is in DK/NF if every constraint on the relation is a logical consequence of keys and domains.

19 Copyright © 2004 M. E. Kabay. All rights reserved. M:N Relationships If neither A B nor B A, then A:B::M:N Therefore both attributes must be a compound key Why? May add attributes that are determined by (A,B) E.g., for Cut_Show, where any cut can be on any show, one would add Date_Played and Time_Played, which are functionally dependent on Cut and Show Do not add attributes that are dependent on only one of the parts of the key E.g, would not add Album_Name, which depends on Cut and Band, neither of which is determined by (Cut_Show)

20 Copyright © 2004 M. E. Kabay. All rights reserved. Multi-value Dependencies When analyzing M:N relations, think about themes as the purpose for a relation Do not mix themes E.g., in rock-music DB, Would be a mistake to put detailed information about cuts into the Album relation Why?

21 Copyright © 2004 M. E. Kabay. All rights reserved. Database Optimization Normalization is not an absolute Normalization is a technique to avoid difficulties Can be reversed when appropriate Useful For specific purposes De-Normalization Violating some of the principles of normalization for a good reason Controlled Redundancy May be useful for performance reasons

22 Copyright © 2004 M. E. Kabay. All rights reserved. De-Normalization Think about DJ relation DJ_ID, DJ_Name, DJ_Joined, DJ_Left, DJ_Notes Theoretically, a DJ could leave and join several times Thus we might break the relation into two parts: DJ_ID, DJ_Name, DJ_Notes DJ_ID, DJ_Joined, DJ_Left However, these events may be rare enough that we dont get much benefit from the normalization – waste of effort

23 Copyright © 2004 M. E. Kabay. All rights reserved. Controlled Redundancy Notice the Album and Cut relations in the rock-music DB Album contains Total_Minutes Cut contains Cut_Minutes Why bother having the Total_Minutes field in the Album dataset? Could easily compute total from list of all the cuts in the album So whats the advantage of keeping this computed field in the Album dataset?

24 Copyright © 2004 M. E. Kabay. All rights reserved. Review to Date Tue 25 February 2003 Review of all the material we have discussed in Chapters 1, 2, 3, and 5 Come prepared to answer questions round- robin (every student answers a question in turn) Remember that your mid-term, take-home exam will be distributed on Thursday the 27 th of Feb.

25 Copyright © 2004 M. E. Kabay. All rights reserved. Homework Finish studying Chapter 5 in detail Review all the material in Chapters 1, 2, 3, & 5 REQUIRED: For submission at the start of class On Thursday 27 th of February, Complete Group 1 questions 5.18 to 5.26 for 9 points total

26 Copyright © 2004 M. E. Kabay. All rights reserved. DISCUSSION