Lecture-8(a-b).ppt xx intro to management

Advanced Database Engineering
Advanced Database Engineering 1
1
Chapter 5:
Chapter 5:
Logical Database Design
Logical Database Design
and the Relational Model
and the Relational Model
Modern Database Management
Modern Database Management
7
7th
th
Edition
Edition
Jeffrey A. Hoffer, Mary B. Prescott,
Jeffrey A. Hoffer, Mary B. Prescott,
Fred R. McFadden
Fred R. McFadden

Chapter 5 Advanced Database Engineering
2
Data Normalization
Data Normalization
 Primarily a tool to validate and
Primarily a tool to validate and
improve a logical design so that it
improve a logical design so that it
satisfies certain constraints that
satisfies certain constraints that
avoid unnecessary duplication of
avoid unnecessary duplication of
data
data
 The process of decomposing
The process of decomposing
relations with anomalies to produce
relations with anomalies to produce
smaller,
smaller, well-structured
well-structured relations
relations

3
Well-Structured Relations
Well-Structured Relations
 A relation that contains minimal data redundancy
A relation that contains minimal data redundancy
and allows users to insert, delete, and update rows
and allows users to insert, delete, and update rows
without causing data inconsistencies
without causing data inconsistencies
 Goal is to avoid anomalies
Goal is to avoid anomalies
 Insertion Anomaly
Insertion Anomaly – adding new rows forces user to
– adding new rows forces user to
create duplicate data
create duplicate data
 Deletion Anomaly
Deletion Anomaly – deleting rows may cause a loss of
– deleting rows may cause a loss of
data that would be needed for other future rows
data that would be needed for other future rows
 Modification Anomaly
Modification Anomaly – changing data in a row forces
– changing data in a row forces
changes to other rows because of duplication
changes to other rows because of duplication
General rule of thumb: a table should not pertain to
more than one entity type

4
Example – Figure 5.2b
Example – Figure 5.2b
Question – Is this a relation? Answer – Yes: unique rows and no multivalued
attributes
Question – What’s the primary key? Answer – Composite: Emp_ID,
Course_Title
C++

5
Anomalies in this Table
 Insertion
Insertion – can’t enter a new employee without
– can’t enter a new employee without
having the employee take a class
having the employee take a class
 Deletion
Deletion – if we remove employee 140, we lose
– if we remove employee 140, we lose
information about the existence of a Tax Acc class
information about the existence of a Tax Acc class
 Modification
Modification – giving a salary increase to
– giving a salary increase to
employee 100 forces us to update multiple
employee 100 forces us to update multiple
records
records
Why do these anomalies exist?
Because there are two themes (entity types) into one
relation. This results in duplication, and an
unnecessary dependency between the entities

6
Functional Dependencies and Keys
Functional Dependencies and Keys
 Functional Dependency: The value of one
Functional Dependency: The value of one
attribute (the
attribute (the determinant
determinant) determines
) determines
the value of another attribute
the value of another attribute
 Candidate Key:
Candidate Key:
 A unique identifier. One of the candidate keys
A unique identifier. One of the candidate keys
will become the primary key
will become the primary key
 E.g. perhaps there is both credit card number and
E.g. perhaps there is both credit card number and
SS# in a table…in this case both are candidate keys
SS# in a table…in this case both are candidate keys
 Each non-key field is functionally dependent
Each non-key field is functionally dependent
on every candidate key
on every candidate key

7
Figure 5.22 -
Steps in
normalization

8
First Normal Form
First Normal Form
 No multivalued attributes
No multivalued attributes
 Every attribute value is atomic
Every attribute value is atomic
 Fig. 5-25
Fig. 5-25 is not
is not in 1
in 1st
st
Normal Form
Normal Form
(multivalued attributes)
(multivalued attributes) 
 it is not a relation
it is not a relation
 Fig. 5-26
Fig. 5-26 is
is in 1
in 1st
st
Normal form
Normal form
 All relations
All relations are in 1
are in 1st
st
Normal Form
Normal Form

9
Table with multivalued attributes, not in 1st
normal form
Note: this is NOT a relation

10
Table with no multivalued attributes and unique rows, in 1st
normal form
Note: this is relation, but not a well-structured one

11
 Insertion
Insertion – if new product is ordered for order
– if new product is ordered for order
1007 of existing customer, customer data must
1007 of existing customer, customer data must
be re-entered, causing duplication
be re-entered, causing duplication
 Deletion
Deletion – if we delete the Dining Table from
– if we delete the Dining Table from
Order 1006, we lose information concerning this
Order 1006, we lose information concerning this
item's finish and price
item's finish and price
 Update
Update – changing the price of product ID 4
– changing the price of product ID 4
requires update in several records
requires update in several records
Why do these anomalies exist?
Because there are multiple themes (entity types) into
one relation. This results in duplication, and an
unnecessary dependency between the entities

12
Second Normal Form
Second Normal Form
 1NF PLUS
1NF PLUS every non-key attribute is
every non-key attribute is
fully functionally dependent on the
fully functionally dependent on the
ENTIRE primary key
ENTIRE primary key
 Every non-key attribute must be defined
Every non-key attribute must be defined
by the entire key, not by only part of the
by the entire key, not by only part of the
key
key
 No partial functional dependencies
No partial functional dependencies

13
Order_ID  Order_Date, Customer_ID, Customer_Name, Customer_Address
Therefore, NOT in 2nd
Normal Form
Customer_ID  Customer_Name, Customer_Address
Product_ID  Product_Description, Product_Finish, Unit_Price
Order_ID, Product_ID  Order_Quantity

14
Getting it into Second Normal
Getting it into Second Normal
Form
Form
Partial Dependencies are removed, but there
are still transitive dependencies

15
Third Normal Form
Third Normal Form

2NF PLUS
2NF PLUS no transitive dependencies
no transitive dependencies
(functional dependencies on non-primary-key
(functional dependencies on non-primary-key
attributes)
attributes)
 Note: this is called transitive, because the
Note: this is called transitive, because the
primary key is a determinant for another
primary key is a determinant for another
attribute, which in turn is a determinant for a
attribute, which in turn is a determinant for a
third
third
 Solution: non-key determinant with transitive
Solution: non-key determinant with transitive
dependencies go into a new table; non-key
dependencies go into a new table; non-key
determinant becomes primary key in the new
determinant becomes primary key in the new
table and stays as foreign key in the old table
table and stays as foreign key in the old table

16
Getting it into Third Normal Form
Getting it into Third Normal Form
Transitive dependencies are removed

17
Merging Relations
Merging Relations
 View Integration – Combining entities from multiple
View Integration – Combining entities from multiple
ER models into common relations
ER models into common relations
 Issues to watch out for when merging entities from
Issues to watch out for when merging entities from
different ER models:
different ER models:
 Synonyms – two or more attributes with different names
Synonyms – two or more attributes with different names
but same meaning
but same meaning
 Homonyms – attributes with same name but different
Homonyms – attributes with same name but different
meanings
meanings
 Transitive dependencies – even if relations are in 3NF prior
Transitive dependencies – even if relations are in 3NF prior
to merging, they may not be after merging
to merging, they may not be after merging
 Supertype/subtype relationships – may be hidden prior to
Supertype/subtype relationships – may be hidden prior to
merging
merging

18
Enterprise Keys
Enterprise Keys
 Primary keys that are unique in the whole
Primary keys that are unique in the whole
database, not just within a single relation
database, not just within a single relation
 Corresponds with the concept of an object
Corresponds with the concept of an object
ID in object-oriented systems
ID in object-oriented systems

19

Lecture-8(a-b).ppt xx intro to management

More Related Content

Similar to Lecture-8(a-b).ppt xx intro to management (20)

More from mee23nu (12)

Recently uploaded (20)

Lecture-8(a-b).ppt xx intro to management