Scribd
Upload
4 views

DB Lecture 7. Data Normalization

This document covers data normalization in database management, detailing the transformation of EER diagrams into relations and the mapping of various types of relationships. It emphasizes the importance of achieving well-structured relations to avoid data anomalies such as insertion, deletion, and modification issues. The document also outlines the steps to reach third normal form and the significance of functional dependencies and keys in the normalization process.

Uploaded by

739709833safwan
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
4 views

DB Lecture 7. Data Normalization

This document covers data normalization in database management, detailing the transformation of EER diagrams into relations and the mapping of various types of relationships. It emphasizes the importance of achieving well-structured relations to avoid data anomalies such as insertion, deletion, and modification issues. The document also outlines the steps to reach third normal form and the significance of functional dependencies and keys in the normalization process.

Uploaded by

739709833safwan
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 25

Database Management

Design 1
LECTURE 6: DATA
NORMALIZATION
DONE BY:
ENG. GAWHAR GAMAL
Transforming EER Diagrams
into Relations (cont.)

 Mapping Unary Relationships


 One-to-Many–Recursive foreign key in the same relation.
 Many-to-Many–Two relations:
 One for the entity type.
 One for an associative relation in which the primary key has two
attributes, both taken from the primary key of the entity.
Figure 4-17 Mapping a unary 1:N relationship

(b)
EMPLOYEE
relation with
recursive
foreign key
Figure 4-18 Mapping a unary M:N relationship

(a) Bill-of-materials
relationships (unary M:N)

(b) ITEM and


COMPONENT
relations
Transforming EER Diagrams
into Relations (cont.)

 Mapping Ternary (and n-ary) Relationships


 One relation for each entity and one for the associative
entity.
 Associative entity has foreign keys to each entity in the
relationship.
Figure 4-19 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with associative entity


Figure 4-19 Mapping a ternary relationship (cont.)

b) Mapping the ternary relationship PATIENT TREATMENT

Remember This is why But this makes a It would be


that the treatment date very better to create a
primary key and time are cumbersome surrogate key
MUST be included in the key… like Treatment#.
unique. composite
primary key.
Transforming EER Diagrams
into Relations (cont.)

 Mapping Supertype/Subtype Relationships


 One relation for supertype and for each subtype.
 Supertype attributes (including identifier and subtype discriminator) go
into supertype relation.
 Subtype attributes go into each subtype; primary key of supertype
relation also becomes primary key of subtype relation.
 1:1 relationship established between supertype and each subtype, with
supertype as primary table.
Figure 4-20 Supertype/subtype relationships
Figure 4-21
Mapping supertype/subtype relationships to relations

These are implemented as one-to-one


relationships.
Data Normalization

 Primarily a tool to validate and improve a logical design so that


it satisfies certain constraints that avoid unnecessary
duplication of data.
 The process of decomposing relations with anomalies to
produce smaller, well-structured relations.
Well-Structured Relations

 A relation that contains minimal data redundancy and allows users


to insert, delete, and update rows without causing data inconsistencies.
 Goal is to avoid anomalies:
 Insertion Anomaly: adding new rows forces user to create duplicate data.
 Deletion Anomaly: deleting rows may cause a loss of data that would be
needed for other future rows.
 Modification Anomaly: changing data in a row forces changes to other
rows because of duplication.
General rule of thumb: A table should not pertain to
more than one entity type.
Example–Figure 4-2b

Question–Is this a relation? Answer–Yes: Unique rows and


no multivalued attributes

Question–What’s the primary key? Answer–Composite: EmpID, CourseTitle


Anomalies in this Table

 Insertion: can’t enter a new employee without having the employee take a class
(or at least empty fields of class information).
 Deletion: if we remove employee 140, we lose information about the existence of
a Tax Acc class.
 Modification: giving a salary increase to employee 100 forces us to update
multiple records.

Why do these anomalies exist?


Because there are two themes (entity types) in this
one relation. This results in data duplication and
an unnecessary dependency between the entities.
Figure 4.22 Steps in normalization

It is important that a database reach third normal form. Boyce-Codd, fourth, and fifth are of
theoretical interest, but not generally considered vital for qualifying as a set of well-
structured relations.
Functional Dependencies and Keys

 Functional Dependency: The value of one attribute (the


determinant) determines the value of another attribute
 Candidate Key:
 A unique identifier. One of the candidate keys will become the primary
key.
 E.g., perhaps there is both credit card number and SS# in a table…in this
case both are candidate keys.
 Each non-key field is functionally dependent on every candidate key.
First Normal Form

 No multivalued attributes.
 Every attribute value is atomic.
st
 Fig. 4-25 is not in 1 Normal Form (multivalued attributes) → it
is not a relation.
 Fig. 4-26 is in 1st Normal form.
 All relations are in 1st Normal Form.
st
Table with multivalued attributes, not in 1 normal form

Note: This is NOT a relation.


Table with no multivalued attributes and unique rows, in
st
1 normal form

Note: This is a relation, but not a well-structured one.


Anomalies in this Table

 Insertion: if new product is ordered for order 1007 of existing customer,


customer data must be re-entered, causing duplication
 Deletion: if we delete the Dining Table from Order 1006, we lose
information concerning this item’s finish and price
 Update: changing the price of product ID 4 requires update in multiple
records

Why do these anomalies exist?


Because there are multiple themes (entity types)
in one relation. This results in duplication and an
unnecessary dependency between the entities.
Second Normal Form

 1NF PLUS every non-key attribute is fully


functionally dependent on the ENTIRE primary key
 Every non-key attribute must be defined by the entire key,
not by only part of the key.
 No partial functional dependencies.
Figure 4-27 Functional dependency diagram for INVOICE

➔
OrderID OrderDate, CustomerID, CustomerName, CustomerAddress
➔
CustomerID CustomerName, CustomerAddress
➔
ProductID ProductDescription, ProductFinish, ProductStandardPrice
➔
OrderID, ProductID OrderQuantity
nd
Therefore, NOT in 2 Normal Form
Figure 4-28 Removing partial dependencies

Getting it into
Second Normal
Form

Partial dependencies are removed, but there


are still transitive dependencies
Third Normal Form

 2NF PLUS no transitive dependencies (functional


dependencies on non-primary-key attributes)
 Note: This is called transitive, because the primary key is a
determinant for another attribute, which in turn is a determinant
for a third
 Solution: Non-key determinant with transitive dependencies
go into a new table; non-key determinant becomes primary key in
the new table and stays as foreign key in the old table
Figure 4-29 Removing partial dependencies

Transitive dependencies are removed.

Figure 4-30 shows the result


of normalization, yielding four
separate relations where
initially there was only one.

You might also like