0% found this document useful (0 votes)
12 views

Day 7 Normalization For Relational Databases

Uploaded by

Marnie Omar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views

Day 7 Normalization For Relational Databases

Uploaded by

Marnie Omar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 72

Normalization for

Relational Databases

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe


Database Development Process

Business Information Requirements

Conceptual Data Business view


Modeling

Logical Database Systems view


Design

Physical Database
Build

Operational Database
CS 450 ERD Conventions

attribute Cardinality (degree)

empnum

key
M 1

EMPLOYEE Works For DEPARTMENT

entity relationship

Participation Requirements
(optionality)
Terminology

CONCEPTUAL LOGICAL
(Business view) (Systems view)

ANALYSIS DESIGN

ENTITY TABLE

RELATIONSHIP FOREIGN KEY

ATTRIBUTE COLUMN

UNIQUE PRIMARY KEY


IDENTIFIER UNIQUE KEY
ER diagram to Table

The database can be represented using


the notations, and these notations can
be reduced to a collection of tables.

In the database, every entity set or


relationship set can be represented in
table.
converting the ER diagram to the table
converting the ER diagram to the table

• Entity type becomes a table.


• In the given ER diagram, LECTURE, STUDENT, SUBJECT
and COURSE forms individual tables.
• All single-valued attribute becomes a column for the table.
• In the STUDENT entity, STUDENT_NAME and
STUDENT_ID form the column of STUDENT table.
• A key attribute of the entity type represented by the
primary key.
• In the given ER diagram, COURSE_ID, STUDENT_ID, are
the key attribute of the entity.
converting the ER diagram to the table
• The multivalued attribute is represented by a separate
table.
• In the student table, a hobby is a multivalued attribute. we
create a table STUD_HOBBY with column name
STUDENT_ID and HOBBY. Using both column to create a
composite key.
• Composite attribute represented by components.
• student address is a composite attribute. It contains CITY,
PIN, DOOR#, STREET, and STATE. In the STUDENT table,
these attributes can merge as an individual column.
• Derived attributes are not considered in the table.
• In the STUDENT table, Age is the derived attribute. It can be
calculated at any point of time by calculating the difference
between current date and Date of Birth.
converting the ER diagram to the table
Appropriate Mapping Cardinality

• Evidently, the real-world context in which the relation set


is modeled determines the Appropriate Mapping
Cardinality for a specific relation set.
• We can combine relational tables with many involved
tables if the Cardinality is one-to-many or many-to-one.
• One entity can be combined with a relation table if it has
a one-to-one relationship and total participation.
• Two entities can be combined with their relation to form
a single table if both of them have total participation.
• We cannot mix any two tables if the Cardinality is many-
to-many. (store it in a separate table)
• https://www.javatpoint.com/dbms-mapping-constraints
Normalization of Relations

■ Normalization:
■ The process of decomposing unsatisfactory "bad" relations by
breaking up their attributes into smaller relations

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 13


First Normal Form
■ Disallows


■ composite attributes multivalued attributes

Remedies
■ Create a separate field/table for each set of
related data.
Identify each set of related data with a primary
key

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 14


Normalization into 1NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe


REMOVing redundant
Tables Violating First Normal Form
PART (Primary Key) WAREHOUSE
P0010 Warehouse A, Warehouse B, Warehouse C
P0020 Warehouse B, Warehouse D

Really Bad Set-up!


Table Conforming to 1NF

PART WAREHOUSE
(Primary Key) (Primary Key) QUANTITY
P0010 Warehouse A 400

P0010 Warehouse B 543

P0010 Warehouse C 329

P0020 Warehouse B 200

P0020 Warehouse D 278


Example 1: Table Violating 1NF

Instructor First Name Last Name Phone Number


123 Ali Baba 215-000-1212
222 Mikey Mouse 215-000-1212
215-111-1212
215-222-1212
555 Donald Duck 312-000-1212
312-111-1212
312-222-1212
Example 1: Table Not Violating 1NF
Instructor First Name Last Name Phone Number
123 Ali Baba 215-000-1212
222 Mikey Mouse 215-000-1212
222 Mikey Mouse 215-111-1212
222 Mikey Mouse 215-222-1212
555 Donald Duck 312-000-1212
555 Donald Duck 312-111-1212

It violates other normal forms, though.


Example 2: Table Violating 1NF

Product ID Color Price


1 Black, Red $15
2 Yellow, Purple $20
5 White, Green $40
Example 2: Table Not Violating 1NF

Product ID Color Price


1 Black $15
1 Red $15
2 Yellow $20
2 Purple $20
5 White $40
5 Green $40

It violates other normal forms, though.


Second Normal Form – 2NF

•Usually used in tables with a multiple-field primary key


(composite key)

MAIN POINT –
Eliminate redundant data in a table
Create separate tables for sets of values that apply to
multiple records
Table Violating 2NF
PART WAREHOUSE WAREHOUSE
(Primary Key) (Primary Key) QUANTITY ADDRESS

P0010 Warehouse A 400 1608 New Field Road

P0010 Warehouse B 543 4141 Greenway Drive

P0010 Warehouse C 329 171 Pine Lane

P0020 Warehouse B 200 4141 Greenway Drive

P0020 Warehouse D 278 800 Massey Street


Table Violating 2NF

PART WAREHOUSE WAREHOUSE


(Primary Key) (Primary Key) QUANTITY ADDRESS

P0010 Warehouse A 400 1608 New Field Road

P0010 Warehouse B 543 4141 Greenway Drive

P0010 Warehouse C 329 171 Pine Lane

P0020 Warehouse B 200 4141 Greenway Drive

P0020 Warehouse D 278 800 Massey Street


- Each non-key field relates to the entire primary key (Quantity)

- Any field that does not relate to the primary key is placed in a separate table
(wherehouse address)
Tables Conforming to 2NF

PART_STOCK TABLE
PART (Primary Key) WAREHOUSE (Primary Key) QUANTITY
P0010 Warehouse A 400
P0010 Warehouse B 543
P0010 Warehouse C 329
P0020 Warehouse B 200
P0020 Warehouse D 278
WAREHOUSE TABLE
1

WAREHOUSE (Primary Key) WAREHOUSE_ADDRESS
Warehouse A 1608 New Field Road
Warehouse B 4141 Greenway Drive
Warehouse C 171 Pine Lane
Warehouse D 800 Massey Street
Table Violating 2NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 27


Tables Conforming to 2NF
Third Normal Form – 3NF

Usually used in tables with a single- field primary


key , Records do not depend on anything other than
a table's primary key.
Each non-key field is a fact about the key
Values in a record that are not part of that record's key do
not belong in the table.
Rule of Thumb
In general, any time the contents of a group of fields may
apply to more than a single record in the table, consider
placing those fields in a separate table.
Table Violating 3NF (SINGLE KEY)

EMPLOYEE_DEPARTMENT TABLE

EMPNO
FIRSTNAME LASTNAME WORKDEPT DEPTNAME
(Primary Key)

000290 John Parker E11 Operations

000320 Ramlal Mehta E21 Software Support

000310 Maude Setright E11 Operations


3rd Normal Form
■ GUIDELINE 1: Only foreign keys should be used to refer to
other entities
Entity and relationship attributes should be kept apart as
much as possible.

■ Attributes of different entities (EMPLOYEEs, DEPARTMENTs,


■ PROJECTs) should not be mixed in the same relation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 31


Tables Conforming to Third
Normal Form
EMPLOYEE TABLE

EMPNO (Primary Key) FIRSTNAME LASTNAME WORKDEPT

000290 John Parker E11

000320 Ramlal Mehta E21

000310 Maude Setright E11

DEPARTMENT TABLE ∞
1

DEPTNO (Primary Key) DEPTNAME

E11 Operations

E21 Software Support


Table Violating 3NF

Dlocation is a multivalued attribute that caused


data redundancy  1st NF but violates 3rdNF
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Normalization into 3NF
Table Violating 3NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 35


Example States for EMP_DEPT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 36


Tables Conforming to
Third
Normal Form
More Examples
Table in First Normal Form
–Data in Smallest Parts

Adv-
Student# Advisor# AdvisorFName AdvisorLName Class#
Room
1022 10 Susan Jones 412 101-07

1022 10 Susan Jones 412 143-01

1022 10 Susan Jones 412 159-02

4123 12 Anne Smith 216 101-07

4123 12 Anne Smith 216 159-02

4123 12 Anne Smith 216 214-01


•Is table in 2NF?
–What is the key?

Adv-
Student# Advisor# AdvisorFName AdvisorLName Class#
Room
1022 10 Susan Jones 412 101-07

1022 10 What Susan


do we notice?Jones 412 143-01
•Advisor fields depend on Student#
1022 10 Susan Jones 412 159-02

4123 12 Anne Smith 216 101-07

4123 12 Anne Smith 216 159-02

4123 12 Anne Smith 216 214-01

2011 10 Susan Jones 412 101-07


Tables in Second Normal Form
–Redundant Data Eliminated

Table: Registration
Table: Students

Adv- Student# Class#


Student# Advisor# AdvFirstName AdvLastName
Room
1022 101-07
1022 10 Susan Jones 412

1022 143-01
4123 12 Anne Smith 216
1022 159-02
2011 10 Susan Jones 412
4123 201-01

4123 211-02

4123 214-01
•Tables Registration in 2NF
•Who about the Students?

Table: Registration
Table: Students

Adv- Student# Class#


Student# Advisor# AdvFirstName AdvLastName
Room
1022 101-07
1022 10 Susan Jones 412

1022 143-01
4123 12 Anne Smith 216
1022 159-02
2011 10 Susan Jones 412
4123 201-01

4123 211-02
What is the candidate key for Students?
4123 214-01
Table: Registration

Student# Class#

1022 101-07
Table: Students
1022 143-01
Student# Advisor#
1022 159-02

1022 10 4123 201-01

4123 12 4123 211-02

2011 10 4123 214-01


•Tables in 2NF & 3NF Table: Registration

Student# Class#
Table: Advisors
1022 101-07
Adv-
Advisor# AdvFirstName AdvLastName
Room
1022 143-01
10 Susan Jones 412
1022 159-02

12 Anne Smith 216 4123 201-01

Table: Students 4123 211-02

4123 214-01
Student# Advisor#

1022 10

4123 12

2011 10
Table in First Normal Form
EmpID Project Time on Last First Dept Dept Name
Number Project Name Name Code
EN1-26 30-T3 25% Breen Sean TW Technical Writing

EN1-26 30-TC 40% Breen Sean TW Technical Writing

EN1-26 31-T3 30% Breen Sean TW Technical Writing

EN1-33 30-T3 50% Guya Amy TW Technical Writing

EN1-33 30-TC 35% Guya Amy TW Technical Writing

EN1-33 31-T3 60% Guya Amy TW Technical Writing

EN1-36 35-TC 90% Roslyn Liz AC Accounting


Tables in Second Normal Form

Table: Employees and Projects Table: Employees


EmpID Project Time on EmpID Last First Dept Dept Name
Number Project Name Name Code
EN1-26 30-T3 25% EN1-26 Breen Sean TW Technical Writing

EN1-26 30-T3 40% EN1-33 Guya Amy TW Technical Writing

EN1-26 31-T3 30% EN1-36 Roslyn Liz AC Accounting

EN1-33 30-T3 50%

EN1-33 30-TC 35% Are they in 3NF?


EN1-33 31-T3 60%

EN1-36 35-TC 90%


Dept Name actually depends on Dept
Code, which in turn depends on the key
EmpID.
Tables in Third Normal Form

Table: Employees_and_Projects Table: Employees


EmpID Project Time on EmpID Last First Dept
Number Project Name Name Code
EN1-26 30-T3 25%
EN1-26 Breen Sean TW
EN1-26 30-T3 40%
EN1-33 Guya Amy TW
EN1-26 31-T3 30%
EN1-36 Roslyn Liz AC
EN1-33 30-T3 50%

EN1-33 30-TC 35%


Table: Departments
EN1-33 31-T3 60%
Dept Code Dept Name
EN1-36 35-TC 90%
TW Technical Writing
AC Accounting
Example 3
• Un-normalized Table:

EmpID Name Manager Dept Sector Spouse/Children

285 Carl Smithers Engineering 6G


Carlson
365 Lenny Smithers Marketing 8G

458 Homer Mr. Burns Safety 7G Marge, Bart, Lisa, Maggie


Simpson
Table in First Normal Form
No more repeated fields
EmpID FName LName Manager Department Sector Dependent
285 Carl Carlson Smithers Engineering 6G

365 Lenny Smithers Marketing 8G

458 Homer Simpson Mr. Burns Safety 7G Marge

458 Homer Simpson Mr. Burns Safety 7G Bart

458 Homer Simpson Mr. Burns Safety 7G Lisa

458 Homer Simpson Mr. Burns Safety 7G Maggie


Second/Third Normal Form
Remove Repeated Data From Table Step 1

EmpID FName LName Manager Department Sector


285 Carl Carlson Smithers Engineering 6G
365 Lenny Smithers Marketing 8G
458 Homer Simpson Mr. Safety 7G
Burns

EmpID Dependent

458 Marge
458 Bart
458 Lisa
458 Maggie
Tables in Second Normal Form
Removed Repeated Data From Table
Step 2
EmpID FName LName ManagerID Dept Sector
285 Carl Carlson 2 Engineering 6G
365 Lenny 2 Marketing 8G
458 Homer Simpson 1 Safety 7G

We look for the transitive dependency.


EmpID Dependent
458 Marge ManagerI Manager
458 Bart D
458 Lisa 1 Mr.
Burns
458 Maggie
2 Smithers
Tables in Second Normal Form
How about 3NF?
Step 3
EmpID FName LName ManagerID Dept Sector
285 Carl Carlson 2 Engineering 6G
365 Lenny 2 Marketing 8G
458 Homer Simpson 1 Safety 7G

We look the transitive dependency.


EmpID Dependent
458 Marge If I know Dept, then
ManagerI I know
Manager
458 Bart ManagerID
D and Sector. If I
know EmpID then I know
458 Lisa 1 Mr.
Dept.
Burns
458 Maggie
2 Smithers
Tables in Third Normal Form
Employees Table
EmpID FName LName DeptCode
285 Carl Carlson EN
365 Lenny MK
458 Homer Simpson SF

Dependents Table
Department Table
EmpID Dependent
DeptCode Department Sector ManagerID
458 Marge EN Engineering 6G 2
458 Bart MK Marketing 8G 2
458 Lisa SF Safety 7G 1
458 Maggie
Mapping to schema with normalization

More Examples
Multivalued Attributes

Name

EMPLOYEE
• It is desirable to
Skill decompose multivalued
ID
attribute to a separate
entity. It might be a 1:N or
M:N relationship.

55
Mapping to
schema

Binary relationship places has no attributes then


Add Customer ID AS Foreign key in ORDER table ( 1 to M )
Mapping to schema

Binary relationship
places has ONE
attribute ORDERDATE
then create placement
table and NO changes
in CUTOMER & ORDER
tables
© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
Mapping to schema
Mapping to schema
STUDENT register COURSE

STAFF

64
Weak Entities

–Weak entity Primary key is partially or totally


derived from parent entity in relationship
© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
Recursive Relationships

• Example : Part contains part


• Contains relationship has one attribute “part_units_
needed
© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
Associative (Composite) Entities

• Also known as bridge entities


• Used to implement M:N relationships
• Composed of primary keys of each of the entities to be
connected
• May also contain additional attributes that play no role in
connective process
© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.

You might also like