Normal Forms through BCNF CPSC 356 Database Ellen Walker Hiram College (Includes figures from...
-
Upload
lee-haynes -
Category
Documents
-
view
215 -
download
0
Transcript of Normal Forms through BCNF CPSC 356 Database Ellen Walker Hiram College (Includes figures from...
Normal Forms through BCNF
CPSC 356 Database
Ellen Walker
Hiram College
(Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)
Unnormalized Form
• A table that includes one or more repeating groups.
StudentName StudentClasses RoomNo Professor
Minnie Mouse
English 101
Psych 240
Accounting 110
BC
Gerst 120
Hins 209
H. Higgins
Lucy Van Pelt
Scrooge McD
Goofy Basketweaving 1
English 101
KC
BC
Daffy Duck
H. HIggins
First Normal Form (1NF)
• Each row, column intersection must have a single value– No composite attributes– No multivalued attributes
• Put the table into 1NF by repeating student names for each repeating group.
Example in 1NF
StudentName StudentClass RoomNo Professor
Minnie Mouse English 101 BC H. Higgins
Minnie Mouse Psych 240 Gerst. 120 Lucy van Pelt
Minnie Mouse Accounting 110 Hins. 209 Scrooge McD
Goofy Basketweaving KC Daffy Duck
Goofy English 101 BC H. Higgins
Example: FDs and Candidate Key
• Functional Dependencies– StudentClass -> RoomNo, Prof – Prof -> RoomNo
• Candidate Key– Since StudentName cannot be determined from
anything else, it must be part of the key. StudentClass gives the rest.
– StudentName, StudentClass -> all attributes
Second Normal Form (2NF)
• Every non primary key is fully functionally dependent on the primary key
• Full Functional Dependency– Attribute B depends on A, but not on any subset of
A
• In other words, the primary key determines every other attribute, but no subset of the primary key determines any other attribute!
Example is not 2NF
• Primary key is StudentName, StudentClass– StudentName must be included because it can’t
be derived from anything else– StudentClass distinguishes tuples of the same
student
• RoomNo and Prof are not Fully Functionally Dependent on primary key– StudentClass -> RoomNo, Prof
Going to 2NF
• Split the relation into (at least) 2 relations– One relation has the subset of the primary key and
all attributes that depend on it– The other relation has the rest of the attributes and
an appropriate foreign key
• In our example:– CourseInfo (StudentClass, RoomNo, Prof)– Student(StudentName, StudentClass)
Notation for functional dependency
• First row is the relational schema• Additional row for each dependency
– “down arrow” for left side– “up arrow” for right side
– Example goes here
• For 2NF, no dependency has down arrow for only part of the primary key.
• Non-key dependencies don’t matter, e.g. Prof->Room
Example 13.8 (p. 392)
Third Normal Form (3NF)
• Schemas in 3NF have no transitive dependencies of non-key attributes
• Transitive dependencies cause potential duplication in the relations
• A transitive dependency is when– A, B, and C are attributes in the relation– A->B and B->C– C is not an attribute of the relation’s key
Recognizing Transitive Dependencies
• If any attribute has both a down-arrow and an up-arrow (staffNo in example 13.8), then there is a transitive dependency.
• If the attribute is part of the relation’s key, the transitive dependency does not violate 3NF
• Any dependency between 2 non-keys will be transitive! (key->non-key1; non-key1-> non-key2)
• Therefore, assuming that every Prof has a favorite Room, we have– StudentCourse->Prof, Prof->RoomNo
From 2NF to 3NF
• Recognize transitive dependencies• Remove attributes involved in transitive
dependency to their own relation, leaving only a “foreign key” behind.
• Example:– CourseInfo (StudentClass, Prof)– Student(StudentName, StudentClass)– FavoriteRoom(Prof, RoomNo)
Summary of Normal Forms
Every attribute depends on • the key,• The whole key, • And nothing but the key!
Condition 1 describes the definition of key
Condition 2 describes 2NF
Condition 3 describes 3NF (or BCNF)
Boyce Codd Normal Form (BCNF)
• A relation is in BCNF if and only if every determinant is a candidate key
• A determinant is a set of attributes on which some other attribute is fully functionally dependent.
• Schemas that are 3NF but not BCNF are rare. They require– Two or more composite candidate keys– Candidate keys share at least one attribute
BCNF vs. 3NF
• BCNF if every FD X->Y satisfies one of the following conditions:– The FD is trivial (Y is subset of X)– X is a superkey
• 3NF if BCNF or the following is true:– Every attribute in X but not Y belongs to a
candidate key
BCNF Can Lose Dependencies
• When putting a relation into BCNF, it is possible that a functional dependency will not be preserved, because the related attributes will be split into separate relations.
• Tradeoff:– 3NF preserves all dependencies– BCNF prevents all redundancies
Example: Find 3NF, Is it BNF?
Student, Course, Semester -> Prof
Prof, Semester -> Course (Prof teaches 1 course / sem)
Course, Semester, Time -> Prof
Prof, Semester, Time -> Room, Course
Prof, Semester, Course, Time -> Room (redundant!)
Up / Down Arrow Form (Not 2NF)
Student Course Prof. Sem. Room Time
v v ^ v
^ v v
v ^ v v
^ v v ^ v
Find Candidate Keys
• Student, Semester, and Time have no up-arrow (cannot be determined by other attributes), so must be part of a candidate key
• Candidate keys:– Student, Course, Semester, Time– Student, Prof, Semester, Time
Remove Partial Dependencies
• Course depends only on Prof & Semester– R1: {Prof, Semester, Course}
• Room depends only on Prof, Semester and course; – R2: {Prof, Semester, Room, Time}
• Original with Room and Course removed– R3: {Student, Prof, Semester, Time}
2NF Partition (Also 3NF)
Course Prof. Sem
^ v v
Prof. Sem Room Time
v v ^ v
Student Prof. Sem Time
Unused Depen- dencies Below
v v ^ v
v ^ v v
Dependency Analysis
• No transitive dependencies– This is good news. We are in 3NF
• Some dependencies are “broken” – They do not connect attributes of a single relation– This is “non-dependency-preserving”
• If we join back the relations we created will we get the same information?– Yes, in this case– No, in general
Algorithm to Get 3NF
• Start with 1NF• Remove all violations of 2NF by
decomposition• Remove all violations of 3NF by further
decomposition• It’s possible you will break dependencies
Dependency Preserving 3NF
• First, massage the dependencies into a standard form (minimal cover):– Every right side is a single attribute– No attributes are redundant– No dependencies are redundant
• Next, create a relation for each of the revised dependencies (guaranteed 3NF because only one dependency per relation)
• Finally, create one more relation for the primary key, if it’s not already included in one of the others.
Another Algorithm to get 3NF
• Find minimal cover of FDs– Every FD has one attribute on right– No FD can be derived from other FDs in the set
• Combine FDs with same attributes on the left• Create a relation for each remaining FD• If no relation contains the original superkey for all
attributes, construct one relation with just the superkey
• This set is guaranteed to be 3NF and equivalent to the original relation
Finding Minimal Cover
• Split up the dependencies with multiple right sides– X->Y,Z becomes X->Y, X-> Z
• Check for redundant attributes on left side– Compute closure of each set that leaves out one attribute. If
it includes the right side, remove the extra attribute.
• Check for redundant dependencies– For each dependency, compute the closure of the set on the
left side against all the other dependencies except the one you’re testing. If you find the attribute on the right side in the closure, you can leave that dependency out.
Example: Single Right Sides
T1. Student, Course, Semester -> Prof
T2. Prof, Semester -> Course
T3. Course, Semester, Time -> Prof
T4. Prof, Semester, Time -> Room, Course
T5. Prof, Semester, Course, Time -> Room
T4 is split:T4a. Prof, Semester, Time -> Room
T4b. Prof, Semester, Time -> Course
Example: Finding Redundant Attributes
• Consider T1: Student, Course, Sem -> Prof– {Student, Course}+ = {Student, Course}– {Student, Sem}+ = {Student, Sem}– {Course, Sem}+ = {Course, Sem}
• Since Prof cannot be derived without all 3 attributes, T1 has no redundant attributes
• T2 and T3 and T4a are similar (no redundant attributes)
• T2 is T4b with Time removed; obviously Time is redundant and T4b can be removed from the set.
Example: Redundant Attributes in T5
• T5: Prof, Semester, Course, Time -> Room• {Prof, Semester, Time}+ = {Prof, Semester,
Time, Course, Room}– Prof, Semester, Time -> Room by T4a– Therefore, Course is redundant in T5– Removing Course from T5 makes it the same as
T4a
Example After Redundant Attribute Removal
T1. Student, Course, Semester -> Prof
T2. Prof, Semester -> Course
T3. Course, Semester, Time -> Prof
T4a. Prof, Semester, Time -> Room
Example: Remove Redundant Dependencies
T1. Student, Course, Semester -> Prof
//Not redundant (see next slide)
T2. Prof, Semester -> Course//Course cannot be derived any other way
T3. Course, Semester, Time -> Prof
//Not redundant (see next slide)
T4a. Prof, Semester, Time -> Room
//Room cannot be derived any other way
Show T1 is not Redundant
• Remove T1 from the set of dependencies• Compute {Student, Course, Semester}+ using
only T2, T3, and T4a– No left sides are satisfied by this combination, so
the closure is simply {Student, Course, Semester}
• Because Professor was not in the closure, T1 is not redundant
(Similar reasoning for T3)
Creating the Relations
• Each relation has all (and only) the attributes mentioned in one dependency;
R1 = { Student, Course, Semester, Prof }R2 = { Prof, Semester, Course }R3 = { Course, Semester, Time, Prof }R4 = { Prof, Semester, Time, Room }Since none of these contains a key for the
whole relation, we addR5 = { Student, Course, Semester, Time }
Evaluating the Result
• Every functional dependency from the closure affects exactly one relation in the schema– No dependencies are lost (this is dependency
preserving)
• At most one non-key attribute per relation, so a transitive dependency would have to lead back to a key attribute (as in R3)
• Therefore, our result is in 3NF and dependency preserving.
Result is Not BCNF
• The result is not BCNF because of the extra dependency in R3:– Course Semester Time Prof
– Prof, Semester -> Course
– It’s ok to have this dependency for 3NF, but not for BCNF.