Functional Dependence An attribute A is functionally dependent on attribute(s) B if: given a value b for B there is one and only one corresponding value a for A (at a time). b2b2 b3b3 a1a1 b1b1

Example: functional dependence All sales representatives in a given pay class have the same commission rate. SalesRepNumberNamePayClassCommission

Normal Forms  A set of conditions on table structure that improves maintenance. Normalization removes processing anomalies:  Update  Inconsistent Data  Addition  Deletion

Normal Forms All attributes depend on the key, the whole key and nothing but the key. 1NFKeys and no repeating groups 2NFNo partial dependencies 3NFAll determinants are candidate keys 4NFNo multivalued dependencies

6 EXAMPLE PLAYERIDPOSITIONPLAYER_NA ME COACHCoach City 01ForwardRonaldoJoeLondon 02MidfieldZidaneEdMadrid 03ForwardRooneyPeteManchester 04GoalCassilasJimBarcelona 05ForwardFabregasJoeLondon 01MidfieldRonaldoEdMadrid Player_id Coach Position Player Name City Transitive Dependency Partial Functional Dependencies

1st Normal Form  Table has a primary key  Table has no repeating groups  Anomalies in 1 st normal form  Inserting  We cannot enter the fact that a player information until his position is known  Solved in 2 nd Normal form  Cannot Enter a Coach and City information with an assigned player and position  Solved in 3 rd Normal Form  Deleting  If we Delete Player id 03 we loose information about coach “Pete”.  Solved in 3 rd Normal Form  Updating  If coach Joe moves from London to Amsterdam,we have to search for all relevant tuples and update them  Will be solved in 3 rd Normal Form

8 Second Normal Form  A relation R is in 2 NF if and only if it is in 1NF and every non-key attribute is fully dependent on the primary key  Partial functional dependency: one or more non-key attributes are functionally dependent on part of the primary key PLAYERI D Player Name 01Ronaldo 02Zidane 03Rooney 04Cassilas 05Fabregas PLAYERIDPOSITIONCOACHCoach City 01ForwardJoeLondon 02MidfieldEdMadrid 03ForwardPeteManchester 04GoalJimBarcelona 05ForwardJoeLondon 01MidfieldEdMadrid

9 Anomalies (2 NF)  Inserting  We cannot insert Coach and City Information unless Player id and Position is identified.  Deleting  If we Delete Player id 03 we loose information about coach “Pete”.  Updating  If coach Joe moves from London to Amsterdam,we have to search for all relevant tuples and update them  Will be solved in 3 rd Normal Form

10 Third Normal Form  A relation is in 3 NF if and only if it is in 2 NF and every non-key attribute is non-transitively dependent on the primary key  Transitive Dependency: functional dependency between two or more non-key attributes in a relation PLAYERIDPlayer Name 01Ronaldo 02Zidane 03Rooney 04Cassilas 05Fabregas PLAYERIDPOSITIONCOACH 01ForwardJoe 02MidfieldEd 03ForwardPete 04GoalJim 05ForwardJoe 01MidfieldEd CoachCoach City JoeLondon EdMadrid PeteManchester JimBarcelona

Normalization 1NFKeys & no repeating groups 2NF1NF & all attributes depend on all key components 3NF2NF & all determinants are candidate keys  Pros: Improves maintenance for database changes  Cons: Tends to slow down retrieval

Transforming E-R Diagrams into Relations  Foreign Key  An attribute that appears as a nonprimary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation  Referential Integrity  An integrity constraint specifying that the value (or existence) of an attribute in one relation depends on the value (or existence) of the same attribute in another relation Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.12

Transforming E-R Diagrams into Relations (Continued)  It is useful to transform the conceptual data model into a set of normalized relations  Steps: 1.Represent entities 2.Represent relationships 3.Normalize the relations 4.Create Tables Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.13

Transforming E-R Diagrams into Relations (continued) 1. Represent Entities  Each regular entity is transformed into a relation  The identifier of the entity type becomes the primary key of the corresponding relation  The primary key must satisfy the following two conditions a.The value of the key must uniquely identify every row in the relation b.The key should be non-redundant Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.14

Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.15

Transforming E-R Diagrams into Relations (continued) 2. Represent Relationships  Binary 1:N Relationships  Add the primary key attribute (or attributes) of the entity on the one side of the relationship as a foreign key in the relation on the right side  The one side migrates to the many side Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.16

Transforming E-R Diagrams into Relations (continued) 2. Represent Relationships (continued)  Binary or Unary 1:1  Three possible options: a. Add the primary key of A as a foreign key of B b. Add the primary key of B as a foreign key of A c. Both  Binary and higher M:N relationships  Create another relation and include primary keys of all relations as primary key of new relation Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.17

Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.18

Transforming E-R Diagrams into Relations (continued)  Unary 1:N Relationships  Relationship between instances of a single entity type  Utilize a recursive foreign key  A foreign key in a relation that references the primary key values of that same relation  Unary M:N Relationships  Create a separate relation  Primary key of new relation is a composite of two attributes that both take their values from the same primary key Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.19

Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall 9.20