The Relational Model and Normalization (3) IS 240 – Database Management Lecture #9 2004-02-19 Prof. M. E. Kabay, PhD, CISSP Norwich University [email protected].

The Relational Model and

Normalization (3)

IS 240 – Database ManagementLecture #9 2004-02-19

Prof. M. E. Kabay, PhD, CISSP

Norwich University

[email protected]

mailto:[email protected]

2 Copyright © 2004 M. E. Kabay. All rights reserved.

Topics

Domain-Key Normal FormGoing from Attributes to RelationsDatabase OptimizationNext 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


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.”

ConstraintAny rule about attributes that can be

judged true or false given the data at handConstraints may not include time-

dependent data; e.g.,“This month’s sales figures must be

greater than last month’s”


DK/NF (cont’d)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 relationis a logical consequence of keys and domains.”


DK/NF (cont’d)

There is no algorithm known for converting relations to DK/NFUse 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. 135-139STUDENTPROFESSORSTUDENT_ADVISOR



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 <specified> period on <this> 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?


Music DB (cont’d)

Entities:MusicianBandAlbumCutDJShow



Music DB (cont’d)

MusicianArtist_NameBirth_DateDeath_DateBiographical_Notes



Music DB (cont’d)

Band_NameDate_FormedDate_DisbandedDate_Artists_Changed??Band_Notes



Music DB (cont’d)

AlbumAlbum_NameAlbum_IDDate_ReleasedTotal_MinutesNumber_Cuts



Music DB (cont’d)

CutCut_NameAlbum_IDCut_Minutes



Music DB (cont’d)

DJDJ_IDDJ_NameDJ_JoinedDJ_LeftDJ_Notes



Music DB (cont’d)

ShowShow_NameShow_DateShow_TimeDJ_ID



Music DB (cont’d)Relations

M:NMusician Band

Album CutM:N

DJ Show1:N

M:N

M:N

Relational links:Musician_BandBand_AlbumAlbum_CutCut_ShowDJ_Show

Basic Entities:MusicianBandAlbumCutDJShow

M:NMusician Band


Going from Attributes to Relations

1:1 RelationshipsN:1 RelationshipsM:N RelationshipsMulti-value Dependencies


1:1 Relationships

A B and B A then A:B::1:1Student_ID SSN (in theory)SSN Student ID

A uniquely identifies X and B uniquely identifies X then A:B::1:1Student_ID DNA_FingerprintSSN DNA_FingerprintThen Student_ID SSN and

SSN Student_IDTherefore Student_ID:DNA_Fingerprint::1:1



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.



N:1 Relationships

If A B but NOT B A, then A:B::N:1E.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 keysTherefore every determinant must be a key

E.g., the relation DJ_SHOW has SHOW as a key but not DJ

Why?



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)


Multi-value Dependencies

When analyzing M:N relations, think about themes as the purpose for a relationDo not mix themes

E.g., in rock-music DB, Would be a mistake to put detailed

information about cuts into the Album relation

Why?


Database Optimization

Normalization is not an absoluteNormalization is a technique to avoid

difficultiesCan be reversed when appropriate

UsefulFor specific purposes

De-NormalizationViolating some of the principles of

normalization for a good reasonControlled Redundancy

May be useful for performance reasons


De-Normalization

Think about DJ relationDJ_ID, DJ_Name, DJ_Joined, DJ_Left,

DJ_NotesTheoretically, a DJ could leave and join

several timesThus we might break the relation into two

parts: DJ_ID, DJ_Name, DJ_NotesDJ_ID, DJ_Joined, DJ_Left

However, these events may be rare enough that we don’t get much benefit from the normalization – waste of effort


Controlled Redundancy

Notice the Album and Cut relations in the rock-music DBAlbum contains Total_MinutesCut 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 albumSo what’s the advantage of keeping this

computed field in the Album dataset?


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 27th of Feb.


Homework

Finish studying Chapter 5 in detailReview all the material in Chapters 1, 2, 3, & 5REQUIRED:

For submission at the start of classOn Thursday 27th of February, Complete Group 1 questions 5.18 to 5.26

for 9 points total


DISCUSSION

The Relational Model and Normalization (3) IS 240 – Database Management Lecture #9 2004-02-19 Prof. M. E. Kabay, PhD, CISSP Norwich University [email protected].

Documents

logical consequence

music db contd dj dj

id cut

dknf contd key

music db contd band

id date

band band

music db contd album