Relational Databases and Web Integration. Week 7

Transcription

1 Relational Databases and Web Integration Week 7 c.j.pulley@hud.ac.uk

2 Key Constraints Primary Key Constraint ensures table rows are unique Foreign Key Constraint ensures no table row can have foreign key values that do not exist Ensure data integrity How are 1:1 etc. relationship constraints enforced?

3 An Example Consider the following table schema: Order ID Date Cust- ID Name Addr City State Zip Prod- ID Descr Price Quan Sub- Total TAX Total What happens when: we insert a new customer? we delete an invoice? we update a customers address?

4 Insert Anomaly Occurs when we have to insert unknown or null values for other data eg. adding contact information means we must add default invoice data Occurs when we are forced to insert extraneous data eg. adding an invoice means we must add contact information

5 Delete Anomaly Deleting row data causes other data to be lost eg. deleting invoice data causes address data to be lost catastrophic if we ve 1 customer and 1 invoice!

6 Update Anomaly Updating a selection of data causes all corresponding rows to need updating eg. updating a customers address forces all related rows to be updated!

7 Other Problems Duplication of data (eg. address data) Unnecessary data (eg. subtotal, TAX and total) Repeating groups of data (eg. columns containing lists of values) Normalization aims at solving all these issues

8 Functional Dependancy Given attributes X and Y, say there s a functional dependancy if there s only one possible value of Y for each possible value of X X Y Z Y Y Z Y X X Y Z 10 B1 C1 10 B2 C2 11 B4 C1 12 B3 C4 13 B1 C1 14 B2 B3 C4

9 Dependancies Functional Dependancy (good!) P (X,..) Transitive Dependancy (bad!) functional dependancy between P and Y via X P X Y

10 First Normal Form Table in 1NF iff table faithfully represents a relation column values drawn from the columns type (no multi-valued columns!) no columns can contain null no duplicate rows A table without a primary key can not be in 1NF! Technically, for 1NF, we should also insist that: the tables row order is insignificant and, the tables column order is insignificant.

11 1NF Example Customer ID First Name Surname Telephone Number 123 Rachel Ingram James Wright , Multi-valued 789 Maria Fernandez Customer ID First Name Surname Telephone Number 123 Rachel Ingram James Wright Data Duplication 456 James Wright Maria Fernandez

12 1NF Example Customer ID First Name Surname Telephone Number1 Telephone Number2 Telephone Number3 123 Rachel Ingram James Wright Maria Fernandez Repeating columns Some columns contain null

13 1NF Example Customer ID First Name Surname 123 Rachel Ingram 456 James Wright 789 Maria Fernandez Customer ID Telephone Number

14 Second Normal Form Table must be in 1NF 2NF iff given any candidate key, C, and any attribute, A, that is not part of a candidate key, then A functionally depends on the whole candidate key C. Recall, from the week 4 lectures, that a candidate key is a potential primary key (ie. minimal set of attributes that uniquely identifies each row of the table).

15 2NF Example Candidate key is (Employee, Skill) Current Work Location functionally dependent on Employee Employee Skill Current Work Location Jones Typing 114 Main Street Jones Shorthand 114 Main Street Jones Whittling 114 Main Street Roberts Light Cleaning 73 Industrial Way Ellis Alchemy 73 Industrial Way Ellis Juggling 73 Industrial Way Harrison Light Cleaning 73 Industrial Way

16 2NF Example Employee Skill Jones Typing Employee Current Work Location Jones Shorthand Jones 114 Main Street Jones Roberts Whittling Light Cleaning Roberts 73 Industrial Way Ellis Alchemy Ellis 73 Industrial Way Ellis Juggling Harrison 73 Industrial Way Harrison Light Cleaning Update anomalies prevented

17 Nothing to stop the same winner from ending up with different date of births. 2NF Example Here s a table in 2NF that still suffers from update anomalies Tournament Year Winner Winner Date of Birth Des Moines Masters 1998 Chip Masterson 14 March 1977 Indiana Invitational 1998 Al Fredrickson 21 July 1975 Cleveland Open 1999 Bob Albertson 28 September 1968 Des Moines Masters 1999 Al Fredrickson 21 July 1975 Indiana Invitational 1999 Chip Masterson 14 March 1977 Date of birth depends on Winner, which in turn depends on (Tournament, Year) - transitive dependancy.

18 Third Normal Form Table must be in 2NF No non-prime attribute is transitively dependent upon a candidate key

19 3NF Example Tournament Year Winner Des Moines Masters 1998 Chip Masterson Winner Winner Date of Birth Indiana Invitational 1998 Al Fredrickson Chip Masterson 14 March 1977 Cleveland Open 1999 Bob Albertson Al Fredrickson 21 July 1975 Des Moines Masters 1999 Al Fredrickson Bob Albertson 28 September 1968 Indiana Invitational 1999 Chip Masterson

20 Other Normal Forms Boyce-Codd Normal Form Fourth Normal Form Fifth Normal Form Domain/Key Normal Form Sixth Normal Form These other normal forms exist to eliminate various other anomalies that are rearely encountered in practice.