Normalization NORMALIZATION. Primary keys (contd.) Primary keys

Transcription

1 Normalization NORMALIZATION R L A Ellis Primary keys and foreign keys Functional dependencies Anomalies and their causes First, second, and third normal forms Examples: sitter database Hardware store database Video store database Primary keys A primary key is an attribute, or a collection of attributes, whose value(s) uniquely identify each row in a relation. A primary key must be minimal (that is, must not contain unnecessary attributes). Student Activity Fee 50 Swimming 50 We assume that a student is allowed to participate in at most one activity. The primary key in the above table is Student. Primary keys (contd.) What if we allow the students to participate in more than one activity? Student Activity Fee 00 Golf Swimming Golf 65 In this table, the two attributes {Student,Activity} constitute the primary key. A multi-attribute primary key is called a composite key.

2 Foreign keys A foreign key is an attribute, or a collection of attributes, in a relation, whose values match the values of a primary key in some relation. the STATE and CITY relations on the next slide. Primary key in STATE relation: StateAbbrev Primary key in CITY relation: {StateAbbrev,City} Foreign key in CITY relation: StateAbbrev STATE relation Foreign keys (contd.) State Abbrev State Union StateBird State Population CT Connecticut 5 American robin 3,287,6 MI Michigan 26 robin 9,295,297 SD South Dakota 40 pheasant 696,004 TN Tennessee 6 mocking bird 4,877,85 TX Texas 28 mocking bird 6,986,50 CITY relation: State Abbrev City City Population CT Hartford 39,739 CT Madison 4,03 CT Portland 8,48 MI Lansing 27,32 SD Madison 6,257 SD Pierre 2,906 TN Nashville 488,374 TX Austin 465,622 TX Portland 2,224 STATE = {StateAbbrev, State, Union, StateBird, StatePopulation} CITY = {StateAbbrev, City, CityPopulation} Functional dependencies Functional dependencies (contd.) A functional dependency is a relationship among attributes. Attribute B is functionally dependent on attribute A if, given a value of attribute A, the value of attribute B is uniquely defined. Attribute A is the determinant of attribute B if attribute B is functionally dependent on attribute A. In the STATE relation above, StateAbbrev is a determinant of all other attributes. A dependency diagram is a pictorial representation of all functional dependencies in a database. An attribute is represented by a rectangle. An arrow is drawn from the rectangle for attribute A to the rectangle for attribute B whenever attribute A is the determinant of attribute B. In the STATE relation, the attribute State is also a determinant of other attributes. In the CITY relation above, the attributes StateAbbrev and City together are a determinant of the attribute CityPopulation. 2

3 Functional dependencies (contd.) Students sports activity I consists of the relation ACTIVITY = {Student, Activity, Fee} Student Activity Fee Students sports activity II consists of the relation ACTIVITY = {Student, Activity, Fee} Partial Dependencies A partial dependency is a functional dependency in which the determinant is a part of the primary key. ACTIVITY = {Student, Activity, Fee} The dependency between the attributes Activity and Fee is a partial dependency. Student Activity Fee Student Activity Fee Transitive Dependency A transitive dependency is a functional dependency in which none of the attributes involves attributes of a primary key. ACTIVITY = {Student, Activity, Fee} The dependency between the attributes Activity and Fee is a transitive dependency. Student Activity Fee Anomalies Anomalies are problems caused by bad database design. Problems mean here: undesirable irregularities of relations (tables). Three types of anomalies: Insertion anomaly Deletion anomaly Update anomaly ACTIVITY = {Student, Activity, Fee} 3

4 Insertion anomaly Deletion Anomaly Student Activity Fee 00 Golf Swimming Golf 65 An insertion anomaly occurs when a row cannot be added to a relation, because not all data is available. We want to store the fact that scuba-diving costs $75, but cannot enter this fact into the table until a student takes up scuba-diving. Student Activity Fee 00 Golf Swimming Golf 65 A deletion anomaly occurs when data is deleted from a relation, and unintentionally other critical data are lost. By deleting the activity skiing for student 00, the fact that skiing costs $200 is lost. Update Anomaly Student Activity Fee 00 Golf Swimming Golf 65 An update anomaly occurs when the DBMS must make multiple changes to reflect a single attribute change. If the cost of swimming changes, then all entries where Activity=swimming must be changed. Redundant data Partial dependencies Causes of anomalies Student Activity Fee 00 Golf Swimming Golf 65 Student Activity Fee 4

5 Causes of anomalies (contd.) Transitive dependencies Removing anomalies Break a table into two tables to remove anomalies. Student Activity Fee 50 Swimming 50 Student Activity Fee Student Activity Activity Fee Student Activity Fee Observe that the above relations do not show any of the anomalies. We have not lost any information by breaking the table. Good database design principles Good database design principles (contd.) No redundancy: A field is stored in only one table, unless it happens to be a foreign key. Replication of foreign keys is permissible, because they allow two tables to be joined together. No partial dependencies: The dependency diagram of any relation in the database should contain no partial dependencies. Normalization: The process of eliminating partial and transitive dependencies. As we normalize relations, larger tables are split into smaller tables with a common foreign key field. There are six normal forms. No transitive dependencies: The dependency diagram of any relation in the database should contain no transitive dependencies. 5

6 Good database design principles (contd.) First Normal Form First Normal Form (NF) Second Normal Form (2NF) Third Normal Form (3NF) Boyce Codd Normal Form (BCNF) Fourth Normal Form (4NF) Fifth Normal Form (5NF) A relation is said to be in the first normal form (NF) if it does not contain any repeating section. CLIENT relation with repeating sections. Vet Vet Type 273 Barbara Hennesey 27 Vet 2 3 Sam Hoober Tom Bird Dog Hamster 459 Vernon Noordsy 3 Care 2 Charlie Cat 8005 Sandra Amidon 27 Vet 2 Beefer Kirby Dog Cat 82 Helen Wandzell 24 srus 3 Kirby Dog First Normal Form (contd.) The CLIENT relation without repeating sections Vet Vet Type 273 Barbara Hennessey 27 Vet Sam Bird Barbara Hennessey 27 Vet Hoober Dog Barbara Hennessey 27 Vet Tom Hamster Vernon Noordsy 3 Care Charlie Cat 8005 Sandra Amidon 27 Vet Beefer Dog Sandra Amidon 27 Vet Kirby Cat 82 3 Helen Wandzell 24 srus Kirby Dog Second Normal Form A NF relation is said to be in the second normal form (2NF) if it does not contain any partial dependencies. Partial dependencies are eliminated by new relations. Partial dependencies in the relation CLIENT = {,,, Vet, Vet,, Type} partial Vet Vet Type transitive 6

7 Second Normal Form (contd.) To convert to second normal form, create new relations so that each attribute is functionally dependent upon the entire primary key. There are now no partial dependencies. The field is replicated, but it is a foreign key. The relation still has some anomalies. Vet transitive Type Vet Third normal form A 2NF relation is said to be in third normal form (3NF) if it does not contain any transitive dependencies. Transitive dependencies are eliminated by new relations. [In the third normal form, each determinant is a primary key] Conversion of CLIENT relation to 3NF. CLIENTS = {,, Vet} PETS = {,,, Type} VETS = {Vet, Vet} Third normal form (contd.) Third normal form (contd.) Vet Note that the tables can be joined to yield a table in the first normal form. The and Vet fields are replicated, but they are both foreign keys. Type Vet Vet CLIENT database in the third normal form. Vet 273 Barbara Hennessey Vernon Noordsy Sandra Amidon Helen Wandzell 24 Vet Vet 27 Vet 3 Care 24 srus Type 273 Sam Bird Hoober Dog Tom Hamster Charlie Cat 8005 Beefer Dog Kirby Cat 82 3 Kirby Dog 7

8 Hardware Store Database The ORDERS relation Hardware Store Database (contd.) The ORDERS relation in the first normal form: Cust Cust Descr Quantity Numb Code Date Price /22/94 Williams Hammer Screwdriver $8.99 $ /22/94 Johnson Clipper Screwdriver Crowbar Saw $8.22 $44.45 $.07 $ /22/94 Lorenzo Hammer $ /22/94 Kopiusko Saw Screwdriver $4.99 $ /23/94 Johnson Cordless drill $34.95 Cust Cust Descr Quantity Numb Code Date Price /22/94 Williams Hammer $ /22/94 Williams Screwdriver $ /22/94 Johnson Clipper $ /22/94 Johnson Screwdriver $ /22/94 Johnson Crowbar $ /22/94 Johnson Saw $ /22/94 Lorenzo Hammer $ /22/94 Kopiusko Saw $ /22/94 Kopiusko Screwdriver $ /23/94 Johnson Cordless drill $34.95 Hardware Store Database (cont.) Dependency diagram of the ORDERS relation in NF Hardware Store Database (contd.) Conversion of ORDERS relation to 3NF partial Numb Descr Quant Descr Price Numb Descr Cust Code Date Cust Price Quantity transitive partial Dependency diagram of the ORDERS relation in 2NF Quantity Numb Descr Descr Price Cust Cust Cust Numb Code Date Code Table relationships for the hardware store database Numb Cust Code Date Cust transitive 8

9 Video Store Database The CUSTOMER relation Customer Phone Last First Address City State Zip Code Johnson Martha 25 Main St. Alvaton KY Smith Jack 873 Elm St. Bowling KY 420 Green Washington Elroy 95 Easy St. Smith s KY 427 Grove Adams Samuel 746 Brown Dr. Alvation KY Steinmetz Susan 5 Speedway Dr.Portland TN The RENTAL-FORM relation Trans Rent Customer Video Copy# Title Rent Date 4/8/ :SpaceOdyssey $.50 4/8/ Clockway Orange $ /8/ Hpscotch $ /8/ Apocalypse Now $ /8/ Clockwork Orange $ /8/ Luggage of the Gods $ Video Store Database (contd.) A customer can rent multiple videos as part of the same transaction however, the Video fields will be different for each video. Multiple copies of the same video are allowed the copy# field stores the number of the copy. Video rental charge depends on the title and not on the day. Video Store Database (contd.) Dependency diagram for the video store database. Video Store Database (contd.) Dependency diagram for the video store database in 3NF Customer Phone Address City State ZipCode Customer Phone Address City State ZipCode Trans Rent Date Customer Video Title Rent Trans Rent Date Customer Video Copy# Title Rent Trans Video Copy# Table relationships for the video store database 9

10 Boyce Codd Normal Form A relation is said to be in Boyce Codd Normal Form (BCNF) if each determinant is a primary key (or at least a candidate key). Guidelines for Database Design Create an Enhanced E-R diagram: Identify the entities involved in the database. Identify the attributes relevant for each entity and determine an identifier. Define relationships between entities. Ensure that all the required database processing can be done using the defined relations. Transform the E-R diagram to a relational schema. Normalize the relations by splitting them into smaller ones. Check for redundancy merge redundant relations. 0