Normalization Of Deviance - Maryland Patient Safety Center · Normalization Of Deviance
Normalization Consolidated 2003
-
Upload
kanagavalli-narayanan -
Category
Documents
-
view
45 -
download
0
Transcript of Normalization Consolidated 2003
![Page 1: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/1.jpg)
![Page 2: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/2.jpg)
The purpose of normailization Functional Dependencies The Process of Normalization First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF) Boyce-Codd Normal Form (BCNF) Fourth Normal Form (4NF) Fifth Normal Form (5NF) Domain Key Normal Form (DKNF)
![Page 3: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/3.jpg)
![Page 4: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/4.jpg)
A properly normalized database should have the following characteristics Scalar values in each fields Absence of redundancy. Minimal use of null values. Minimal loss of information.
![Page 5: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/5.jpg)
Database normalization is the process of removing redundant data from the tables to improve storage efficiency, data integrity, and scalability.
The process of normalization is a formal method that identifies relations based on their primary or candidate keys and the functional dependencies among their attributes.
Normalization generally involves splitting existing tables into multiple ones, which must be re-joined or linked each time a query is issued.
![Page 6: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/6.jpg)
Unnormalized – There are multivalued attributes or repeating groups
First Normal Form (1NF) – No multivalued attributes or repeating groups. Second Normal Form (2NF)1 NF plus no partial dependencies Third Normal Form (3NF)- 2 NF plus no transitive dependencies Boyce-Codd Normal Form (BCNF) Fourth Normal Form (4NF) Fifth Normal Form (5NF) Domain Key Normal Form (DKNF)
Levels of Normalization R
edundancy
Num
ber
of T
able
s
Com
plex
ity
![Page 7: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/7.jpg)
Levels of Normalization
Each higher level is a subset of the lower level Each higher level is a subset of the lower level
DKNF
1NF
2NF
3NF
4NF
5NF
![Page 8: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/8.jpg)
Edgar F. Codd first proposed the process of normalization and what came to be known as the 1st normal form in his paper A Relational Model of Data for Large Shared Data Banks Codd stated:“There is, in fact, a very simple elimination procedure which we shall call normalization. Through decomposition non-simple domains are replaced by ‘domains whose elements are atomic (non-decomposable) values.’”
![Page 9: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/9.jpg)
In the relational model, methods exist for quantifying how efficient a database is. These classifications are called normal forms (or NF), and there are algorithms for converting a given database between them.
Edgar F. Codd originally established three normal forms: 1NF, 2NF and 3NF. There are now others that are generally accepted, but 3NF is widely considered to be sufficient for most applications. Most tables when reaching 3NF are also in BCNF (Boyce-Codd Normal Form).
![Page 10: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/10.jpg)
ClientNo cName propertyNo pAddress rentStart rentFinish rent ownerNo oName
CR76John
kay
PG4
PG16
6 lawrence
St,Glasgow
5 Novar Dr,
Glasgow
1-Jul-00
1-Sep-02
31-Aug-01
1-Sep-02
350
450
CO40
CO93
Tina Murphy
Tony Shaw
CR56Aline
Stewart
PG4
PG36
PG16
6 lawrence
St,Glasgow
2 Manor Rd,
Glasgow
5 Novar Dr,
Glasgow
1-Sep-99
10-Oct-00
1-Nov-02
10-Jun-00
1-Dec-01
1-Aug-03
350
370
450
CO40
CO93
CO93
Tina Murphy
Tony Shaw
Tony Shaw
Repeating group = (propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName)
![Page 11: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/11.jpg)
TitleTitle Author1Author1 AuthorAuthor22
ISBNISBN SubjectSubject PagesPages PublisherPublisher
Database Database System System ConceptsConcepts
Abraham Abraham SilberschatzSilberschatz
Henry Henry F. KorthF. Korth
00729588630072958863 MySQL, MySQL, ComputersComputers
11681168 McGraw-HillMcGraw-Hill
Operating Operating System System ConceptsConcepts
Abraham Abraham SilberschatzSilberschatz
Henry Henry F. KorthF. Korth
04716946650471694665 ComputersComputers 944944 McGraw-HillMcGraw-Hill
![Page 12: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/12.jpg)
This table is not very efficient with storage.
This design does not protect data
integrity.
Third, this table does not scale well.
![Page 13: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/13.jpg)
In Table 1, there are two violations of 1NF: First, There is more than one author field, Second, The subject field contains more
than one piece of information. With more than one value in a single field, it would be very difficult to search for all books on a given subject.
![Page 14: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/14.jpg)
A table is considered to be in 1NF if all the fields contain only scalar values (as opposed to list of values).
How to Decompose?1. Place all items that appear in the repeating
group in a new table2. Designate a primary key for each new table
produced. 3. Duplicate in the new table the primary key
of the table from which the repeating group was extracted or vice versa.
![Page 15: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/15.jpg)
STUDENT
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
![Page 16: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/16.jpg)
Option 1: Make a determinant of the repeating group (or the multivalued attribute) a part of the primary key.
STUDENT
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Composite Primary Key
![Page 17: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/17.jpg)
Option 2: Remove the entire repeating group from the relation. Create another relation which would contain all the attributes of the repeating group, plus the primary key from the first relation. In this new relation, the primary key from the original relation and the determinant of the repeating group will comprise a primary key.
STUDENT
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
![Page 18: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/18.jpg)
STUDENT_COURSE
Stud_ID Course Units
101 MSI 250 3
101 MSI 415 3
125 MSI 331 3
STUDENT
Stud_ID Name
101 Lennon
125 Jonson
![Page 19: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/19.jpg)
Table 2
TitleTitle AuthorAuthor ISBNISBN SubjectSubject PagesPages PublisherPublisher
Database System Database System ConceptsConcepts
Abraham Abraham SilberschatzSilberschatz
00729588630072958863 MySQLMySQL 11681168 McGraw-HillMcGraw-Hill
Database System Database System ConceptsConcepts
Henry F. KorthHenry F. Korth 00729588630072958863 ComputersComputers 11681168 McGraw-HillMcGraw-Hill
Operating System Operating System ConceptsConcepts
Henry F. KorthHenry F. Korth 04716946650471694665 ComputersComputers 944944 McGraw-HillMcGraw-Hill
Operating System Operating System ConceptsConcepts
Abraham Abraham SilberschatzSilberschatz
04716946650471694665 ComputersComputers 944944 McGraw-HillMcGraw-Hill
![Page 20: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/20.jpg)
Now there are two rows for a single book. Additionally, violating the Second Normal Form…
A better solution to the problem would be to separate the data into separate tables- an Author table and a Subject table to store the information, removing that information from the Book table:
![Page 21: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/21.jpg)
ClientNopropertyNo
cNamepAddress
rentStart rentFinish rent ownerNo oName
CR76 PG4John
Kay
6 lawrence
St,Glasgow1-Jul-00 31-Aug-01 350 CO40
Tina Murphy
CR76 PG16John
Kay
5 Novar Dr,
Glasgow1-Sep-02 1-Sep-02 450 CO93
Tony Shaw
CR56 PG4Aline
Stewart
6 lawrence
St,Glasgow1-Sep-99 10-Jun-00 350 CO40
Tina Murphy
CR56 PG36Aline
Stewart
2 Manor Rd,
Glasgow10-Oct-00 1-Dec-01 370 CO93
Tony Shaw
CR56 PG16Aline
Stewart
5 Novar Dr,
Glasgow1-Nov-02 1-Aug-03 450 CO93
Tony Shaw
![Page 22: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/22.jpg)
ClientNo
cName
CR76 John Kay
CR56Aline Stewart
ClientNo
propertyNo
pAddress
rentStart
rentFinish
rent
ownerNo
oName
CR76 PG4
6 lawrence
St,Glasgow
1-Jul-0031-Aug-01
350
CO40Tina Murphy
CR76 PG165 Novar Dr,
Glasgow
1-Sep-02
1-Sep-02450
CO93Tony Shaw
CR56 PG4
6 lawrence
St,Glasgow
1-Sep-99
10-Jun-00
350
CO40Tina Murphy
CR56 PG362 Manor Rd,
Glasgow
10-Oct-00
1-Dec-01370
CO93Tony Shaw
CR56 PG165 Novar Dr,
Glasgow
1-Nov-02
1-Aug-03450
CO93Tony Shaw
1NF ClientRental relation with the second approach
![Page 23: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/23.jpg)
With the second approach, the repeating group (property rented details) is removed by placing the repeating data along with a copy of the original key attribute (clientNo) in a separte relation.
Client (clientNo,cName) PropertyRentalOwner (clientNo, propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName)
![Page 24: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/24.jpg)
Subject_IDSubject_ID SubjectSubject
11 MySQLMySQL
22 ComputersComputers
Author_IDAuthor_ID Last Last NameName
First First NameName
11 SilberschSilberschatzatz
AbrahamAbraham
22 KorthKorth HenryHenry
ISBNISBN TitleTitle PagesPages PublisherPublisher
00729588007295886363
Database Database System System ConceptsConcepts
11681168 McGraw-HillMcGraw-Hill
04716946047169466565
Operating Operating System System ConceptsConcepts
944944 McGraw-HillMcGraw-Hill
Subject Table
Author Table
Book Table
![Page 25: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/25.jpg)
Each table has a primary key, used for joining tables together when querying the data. A primary key value must be unique with in the table (no two books can have the same ISBN number), and a primary key is also an index, which speeds up data retrieval based on the primary key.
Now to define relationships between the tables
![Page 26: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/26.jpg)
ISBNISBN Author_IDAuthor_ID
00729588630072958863 11
00729588630072958863 22
04716946650471694665 11
04716946650471694665 22
ISBNISBN Subject_IDSubject_ID
00729588630072958863 11
00729588630072958863 22
04716946650471694665 22
Book_Author Table
Book_Subject Table
![Page 27: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/27.jpg)
![Page 28: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/28.jpg)
Full functional dependency indicates that if A and B are attributes of a relation, B is fully functionally dependent on A if B is functionally dependent on A, but not on any proper subset of A.
A functional dependency AB is partially dependent if there is some attributes that can be removed from A and the dependency still holds.
![Page 29: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/29.jpg)
Multivalued Attributes (or repeating groups): non-key attributes or groups of non-key attributes the values of which are not uniquely identified by (directly or indirectly) (not functionally dependent on) the value of the Primary Key (or its part).
STUDENT
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
![Page 30: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/30.jpg)
Partial Dependency – when an non-key attribute is determined by a part, but not the whole, of a COMPOSITE primary key.
CUSTOMER
Cust_ID Name Order_ID
101 AT&T 1234
101 AT&T 156
125 Cisco 1250
Partial Dependency
![Page 31: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/31.jpg)
Transitive Dependency – when a non-key attribute determines another non-key attribute.
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Transitive Dependency
![Page 32: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/32.jpg)
If one set of attributes in a table determines another set of attributes in the table, then the second set of attributes is said to be functionally dependent on the first set of attributes.
![Page 33: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/33.jpg)
Main characteristics of functional dependencies in normalization
• Have a one-to-one relationship between attribute(s) on the left- and right- hand side of a dependency;
• hold for all time;
• are nontrivial.
![Page 34: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/34.jpg)
For a table to be in 2NF, there are two requirements The database is in first normal form All nonkey attributes in the table must be functionally
dependent on the entire primary key
Note: Remember that we are dealing with non-key attributes
Example 1 (Not 2NF) Scheme {Title, PubId, AuId, Price, AuAddress}
1. Key {Title, PubId, AuId}2. {Title, PubId, AuID} {Price}3. {AuID} {AuAddress}4. AuAddress does not belong to a key5. AuAddress functionally depends on AuId which is a
subset of a key
Second Normal Form (2NF)
![Page 35: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/35.jpg)
Example 2 (Not 2NF) Scheme {City, Street, HouseNumber, HouseColor,
CityPopulation}1. key {City, Street, HouseNumber}2. {City, Street, HouseNumber} {HouseColor}3. {City} {CityPopulation} 4. CityPopulation does not belong to any key.5. CityPopulation is functionally dependent on the City which is a
proper subset of the key
Example 3 (Not 2NF) Scheme {studio, movie, budget, studio_city}
1. Key {studio, movie}2. {studio, movie} {budget}3. {studio} {studio_city}4. studio_city is not a part of a key 5. studio_city functionally depends on studio which is a proper
subset of the key
Second Normal Form (2NF)
![Page 36: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/36.jpg)
1. If a data item is fully functionally dependent on only a part of the primary key, move that data item and that part of the primary key to a new table.
2. If other data items are functionally dependent on the same part of the key, place them in the new table also
3. Make the partial primary key copied from the original table the primary key for the new table. Place all items that appear in the repeating group in a new table
Example 1 (Convert to 2NF)
Old Scheme {Title, PubId, AuId, Price, AuAddress}
New Scheme {Title, PubId, AuId, Price}
New Scheme {AuId, AuAddress}
2NF - Decomposition
![Page 37: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/37.jpg)
Example 2 (Convert to 2NF)
Old Scheme {Studio, Movie, Budget, StudioCity}
New Scheme {Movie, Studio, Budget}
New Scheme {Studio, City}
Example 3 (Convert to 2NF)
Old Scheme {City, Street, HouseNumber, HouseColor, CityPopulation}
New Scheme {City, Street, HouseNumber, HouseColor}
New Scheme {City, CityPopulation}
2NF - Decomposition
![Page 38: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/38.jpg)
Second normal form (2NF) is a relation that is in first normal form and every non-primary-key attribute is fully functionally dependent on the primary key.
The normalization of 1NF relations to 2NF involves the removal of partial dependencies. If a partial dependency exists, we remove the function dependent attributes from the relation by placing them in a new relation along with a copy of their determinant.
![Page 39: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/39.jpg)
As the First Normal Form deals with redundancy of data across a horizontal row, Second Normal Form (or 2NF) deals with redundancy of data in vertical columns.
![Page 40: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/40.jpg)
Publisher_IDPublisher_ID Publisher NamePublisher Name
11 McGraw-HillMcGraw-Hill
ISBNISBN TitleTitle PagesPages Publisher_IDPublisher_ID
00729588630072958863 Database System Database System ConceptsConcepts
11681168 11
04716946650471694665 Operating System Operating System ConceptsConcepts
944944 11
Publisher Table
Book Table
![Page 41: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/41.jpg)
STUDENT
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Composite Primary Key
![Page 42: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/42.jpg)
Goal: Remove Partial Dependencies
STUDENT
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Composite Primary Key
Partial Dependencies
![Page 43: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/43.jpg)
Remove attributes that are dependent from the part but not the whole of the primary key from the original relation. For each partial dependency, create a new relation, with the corresponding part of the primary key from the original as the primary key.
STUDENT
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
![Page 44: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/44.jpg)
CUSTOMER
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
STUDENT_COURSE
Stud_ID Course_ID
101 MSI 250
101 MSI 415
125 MSI 331
COURSE
Course_ID Units
MSI 250 3.00
MSI 415 3.00
MSI 331 3.00
STUDENT
Stud_ID Name
101 Lennon
101 Lennon
125 Johnson
![Page 45: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/45.jpg)
In this example there exists a one-to-many relationship between the book table and the publisher. A book has only one publisher, and a publisher will publish many books. When there is a one-to-many relationship, a foreign key is placed in the Book Table, pointing to the primary key of the Publisher Table.
The other requirement for Second Normal Form is that there cannot be any data in a table with a composite key that does not relate to all portions of the composite key.
![Page 46: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/46.jpg)
Third normal form (3NF) requires that there are no functional dependencies of non-key attributes on something other than a candidate key.
A table is in 3NF if all of the non-primary key attributes are mutually independent
There should not be transitive dependencies
![Page 47: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/47.jpg)
Goal: Get rid of transitive dependencies.
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Transitive Dependency
![Page 48: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/48.jpg)
Remove the attributes, which are dependent on a non-key attribute, from the original relation. For each transitive dependency, create a new relation with the non-key attribute which is a determinant in the transitive dependency as a primary key, and the dependent non-key attribute as a dependent.
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
![Page 49: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/49.jpg)
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID
111 Mary Jones 1
122 Sarah Smith 2
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
DEPARTMENT
Dept_ID Dept_Name
1 Acct
2 Mktg
![Page 50: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/50.jpg)
The functional dependencies for the Client, Rental and PropertyOwner relations are as follows:
Clientfd2 clientNo cName (Primary Key)
Rentalfd1 clientNo, propertyNo rentStart, rentFinish (Primary Key)fd5 clientNo, rentStart propertyNo, rentFinish (Candidate key)fd6 propertyNo, rentStart clientNo, rentFinish (Candidate key)
PropertyOwnerfd3 propertyNo pAddress, rent, ownerNo, oName (Primary Key)fd4 ownerNo oName (Transitive Dependency)
![Page 51: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/51.jpg)
The resulting 3NF relations have the forms:
Client (clientNo, cName)Rental (clientNo, propertyNo, rentStart, rentFinish)PropertyOwner (propertyNo, pAddress, rent, ownerNo)Owner (ownerNo, oName)
![Page 52: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/52.jpg)
ClientNo cNameCR76 John Kay
CR56 Aline Stewart
ClientClientNo propertyNo rentStart rentFinishCR76 PG4 1-Jul-00 31-Aug-01
CR76 PG16 1-Sep-02 1-Sep-02
CR56 PG4 1-Sep-99 10-Jun-00
CR56 PG36 10-Oct-00 1-Dec-01
CR56 PG16 1-Nov-02 1-Aug-03
Rental
propertyNo pAddress rent ownerNo
PG4 6 lawrence St,Glasgow 350 CO40
PG16 5 Novar Dr, Glasgow 450 CO93
PG36 2 Manor Rd, Glasgow 370 CO93
PropertyOwner
ownerNo oName
CO40 Tina Murphy
CO93 Tony Shaw
Owner
Figure 7 2NF ClientRental relation
![Page 53: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/53.jpg)
Boyce-Codd normal form (BCNF)A relation is in BCNF, if and only if, every determinant is a candidate key.
The difference between 3NF and BCNF is that for a functional dependency A B, 3NF allows this dependency in a relation if B is a primary-key attribute and A is not a candidate key, whereas BCNF insists that for this dependency to remain in a relation, A must be a candidate key.
![Page 54: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/54.jpg)
fd1 clientNo, interviewDate interviewTime, staffNo, roomNo (Primary Key)fd2 staffNo, interviewDate, interviewTime clientNo (Candidate key)fd3 roomNo, interviewDate, interviewTime clientNo, staffNo (Candidate key)fd4 staffNo, interviewDate roomNo (not a candidate key)
As a consequece the ClientInterview relation may suffer from update anmalies.For example, two tuples have to be updated if the roomNo need be changed for staffNo SG5 on the 13-May-02.
ClientNo interviewDate interviewTime staffNo roomNoCR76 13-May-02 10.30 SG5 G101
CR76 13-May-02 12.00 SG5 G101
CR74 13-May-02 12.00 SG37 G102
CR56 1-Jul-02 10.30 SG5 G102
Figure 8 ClientInterview relation
ClientInterview
![Page 55: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/55.jpg)
To transform the ClientInterview relation to BCNF, we must remove the violating functional dependency by creating two new relations called Interview and SatffRoom as shown below,
Interview (clientNo, interviewDate, interviewTime, staffNo)StaffRoom(staffNo, interviewDate, roomNo)
ClientNo interviewDate interviewTime staffNoCR76 13-May-02 10.30 SG5
CR76 13-May-02 12.00 SG5
CR74 13-May-02 12.00 SG37
CR56 1-Jul-02 10.30 SG5
staffNo interviewDate roomNoSG5 13-May-02 G101
SG37 13-May-02 G102
SG5 1-Jul-02 G102
Interview
StaffRoom
Figure 9 BCNF Interview and StaffRoom relations
![Page 56: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/56.jpg)
Multi-valued dependency (MVD) represents a dependency between attributes (for example, A, B and C) in a relation, such that for each value of A there is a set of values for B and a set of value for C. However, the set of values for B and C are independent of each other.
A multi-valued dependency can be further defined as being trivial or nontrivial. A MVD A > B in relation R is defined as being trivial if
• B is a subset of A or• A U B = R
A MVD is defined as being nontrivial if neither of the above twoconditions is satisfied.
![Page 57: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/57.jpg)
Fourth normal form (4NF) A relation that is in Boyce-Codd normal form and containsno nontrivial multi-valued dependencies.
![Page 58: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/58.jpg)
Fifth normal form (5NF)A relation that has no join dependency.Fifth normal form is satisfied when all tables are broken into as many tables as possible in order to avoid redundancy. Once it is in fifth normal form it cannot be broken into smaller relations without changing the facts or the meaning.
![Page 59: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/59.jpg)
Lossless-join dependencyA property of decomposition, which ensures that no spurious tuples are generated when relations are reunited through a natural join operation.
Join dependencyDescribes a type of dependency. For example, for a relation R with subsets of the attributes of R denoted as A, B, …, Z, a relation R satisfies a join dependency if, and only if, every legal value of R is equal to the join of its projections on A, B, …, Z.
![Page 60: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/60.jpg)
The relation is in DKNF when there can be no insertion or deletion anomalies in the database.
Domain Key Normal Form (DKNF)
![Page 61: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/61.jpg)
The ClientRental relation has the following functional dependencies:
fd1 clientNo, propertyNo rentStart, rentFinish (Primary Key)fd2 clientNo cName (Partial dependency)fd3 propertyNo pAddress, rent, ownerNo, oName
(Partial dependency)fd4 ownerNo oName (Transitive Dependency)fd5 clientNo, rentStart propertyNo, pAddress, rentFinish, rent, ownerNo, oName (Candidate key)fd6 propertyNo, rentStart clientNo, cName, rentFinish (Candidate key)
![Page 62: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/62.jpg)
After removing the partial dependencies, the creation of the three new relations called Client, Rental, and PropertyOwner
ClientNo cNameCR76 John Kay
CR56 Aline Stewart
ClientClientNo propertyNo rentStart rentFinishCR76 PG4 1-Jul-00 31-Aug-01CR76 PG16 1-Sep-02 1-Sep-02CR56 PG4 1-Sep-99 10-Jun-00CR56 PG36 10-Oct-00 1-Dec-01CR56 PG16 1-Nov-02 1-Aug-03
Rental
propertyNo pAddress rent ownerNo oName
PG4 6 lawrence St,Glasgow 350 CO40 Tina Murphy
PG16 5 Novar Dr, Glasgow 450 CO93 Tony Shaw
PG36 2 Manor Rd, Glasgow 370 CO93 Tony Shaw
PropertyOwner
Client (clientNo, cName)Rental (clientNo, propertyNo, rentStart, rentFinish)PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName)
2NF ClientRental relation
![Page 63: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/63.jpg)
ISBN Title ISBN Publisher Publisher Address
BOOK
ISBN Title Publisher Address
All attributes are directly or indirectly determined
by the primary key; therefore, the relation is
at least in 1 NF
![Page 64: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/64.jpg)
ISBN Title ISBN Publisher Publisher Address
BOOK
ISBN Title Publisher Address
The relation is at least in 1NF. There is no COMPOSITE
primary key, therefore there can’t be partial dependencies.
Therefore, the relation is at least in 2NF
![Page 65: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/65.jpg)
ISBN Title ISBN Publisher Publisher Address
BOOK
ISBN Title Publisher Address
Publisher is a non-key attribute, and it determines Address, another non-key attribute.
Therefore, there is a transitive dependency, which means that
the relation is NOT in 3 NF.
![Page 66: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/66.jpg)
ISBN Title ISBN Publisher Publisher Address
BOOK
ISBN Title Publisher Address
We know that the relation is at least in 2NF, and it is not in 3 NF. Therefore, we conclude that the relation is in 2NF.
![Page 67: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/67.jpg)
ISBN Title ISBN Publisher Publisher
Address
BOOK
ISBN Title Publisher Address
In your solution you will write the following justification:
1) No M/V attributes, therefore at least 1NF
2) No partial dependencies, therefore at least 2NF
3) There is a transitive dependency (Publisher Address), therefore,
not 3NFConclusion: The relation is in 2NF
![Page 68: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/68.jpg)
Product_ID Description
ORDER
Order_No Product_ID Description
All attributes are directly or indirectly determined by the
primary key; therefore, the relation is at least in 1 NF
![Page 69: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/69.jpg)
Product_ID Description
ORDER
Order_No Product_ID Description
The relation is at least in 1NF. There is a COMPOSITE Primary Key (PK)
(Order_No, Product_ID), therefore there can be partial dependencies. Product_ID, which is a part
of PK, determines Description; hence, there is a partial dependency. Therefore, the relation is not
2NF. No sense to check for transitive dependencies!
![Page 70: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/70.jpg)
Product_ID Description
ORDER
Order_No Product_ID Description
We know that the relation is at least in 1NF, and it is not in 2 NF.
Therefore, we conclude that the relation is in 1 NF.
![Page 71: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/71.jpg)
Product_ID Description
ORDER
Order_No Product_ID Description
In your solution you will write the following justification:
1) No M/V attributes, therefore at least 1NF
2) There is a partial dependency (Product_ID Description), therefore
not in 2NFConclusion: The relation is in 1NF
![Page 72: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/72.jpg)
PART
Part_ID Descr Price Comp_ID No
Part_ID Description Part_ID Price Part_ID, Comp_ID No
Comp_ID and No are not determined by the primary key; therefore, the relation is NOT in 1 NF. No sense
in looking at partial or transitive dependencies.
![Page 73: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/73.jpg)
Part_ID Description Part_ID Price Part_ID, Comp_ID No
PART
Part_ID Descr Price Comp_ID No
In your solution you will write the following justification:
1) There are M/V attributes; therefore, not 1NF
Conclusion: The relation is not normalized.
![Page 74: Normalization Consolidated 2003](https://reader031.fdocuments.us/reader031/viewer/2022012922/55170449497959a0308b45bd/html5/thumbnails/74.jpg)