PRESENTSTION ON

NORMALIZATION

Presented By:-

Sanjeev kumar Akhilesh shukla Annuraj singh Imran khan

NormalizationNormalization theory is based on

the observation that relations with certain properties are more effective in inserting, updating and deleting data than other sets of relations containing the same data

Normalization is a multi-step process beginning with an “unnormalized” relation

IS 257 – Fall 2006

Normal FormsFirst Normal Form (1NF)Second Normal Form (2NF)Third Normal Form (3NF)Boyce-Codd Normal Form (BCNF)Fourth Normal Form (4NF)Fifth Normal Form (5NF)

IS 257 – Fall 2006

Normalization

IS 257 – Fall 2006

Boyce-Codd andHigher

Functional dependencyof nonkey attributes on the primary key - Atomic values only

Full Functional dependencyof nonkey attributes on the primary key

No transitive dependency between nonkey attributes

All determinants are candidate keys - Single multivalued dependency

Unnormalized RelationsFirst step in normalization is to

convert the data into a two-dimensional table

In unnormalized relations data can repeat within a column

IS 257 – Fall 2006

Types of anomaliesRedundancy

◦ Repeat info unnecessarily in several tuples

Update anomalies:◦ Change info in one tuple but not in another

Deletion anomalies:◦ Delete some values & lose other values too

Insert anomalies:◦ Inserting row means having to insert other,

separate info / null-ing it out

6

First Normal FormTo move to First Normal Form a

relation must contain only atomic values at each row and column.◦No repeating groups◦A column or set of columns is called

a Candidate Key when its values can uniquely identify the row in the relation.

IS 257 – Fall 2006

Second Normal FormA relation is said to be in Second

Normal Form when every nonkey attribute is fully functionally dependent on the primary key.◦That is, every nonkey attribute needs

the full primary key for unique identification

IS 257 – Fall 2006

Third Normal FormA relation is said to be in Third Normal

Form if there is no transitive functional dependency between nonkey attributes◦ When one nonkey attribute can be

determined with one or more nonkey attributes there is said to be a transitive functional dependency.

The side effect column in the Surgery table is determined by the drug administered ◦ Side effect is transitively functionally

dependent on drug so Surgery is not 3NFIS 257 – Fall 2006

Boyce-Codd Normal FormMost 3NF relations are also BCNF

relations.A 3NF relation is NOT in BCNF if:

◦Candidate keys in the relation are composite keys (they are not single attributes)

◦There is more than one candidate key in the relation, and

◦The keys are not disjoint, that is, some attributes in the keys are commonIS 257 – Fall 2006

Fourth Normal FormAny relation is in Fourth Normal

Form if it is BCNF and any multivalued dependencies are trivial

Eliminate non-trivial multivalued dependencies by projecting into simpler tables

IS 257 – Fall 2006

Fifth Normal FormA relation is in 5NF if every join

dependency in the relation is implied by the keys of the relation

Implies that relations that have been decomposed in previous NF can be recombined via natural joins to recreate the original relation.

IS 257 – Fall 2006

Dependencies Dependency theory is a subfield of database

theory which studies implication and optimization problems related to logical constraints, commonly called dependencies, on databases. The best known class of such dependencies are functional dependencies, which form the foundation of keys on database relations. Another important class of dependencies are the multivalued dependencies. A key algorithm in dependency theory is the Chase, and much of the theory is devoted to its study.

Functional Dependence

Name, dept_no, and dept_name are functionally dependent on emp_no. (emp_no -> name, dept_no, dept_name)

Skills is not functionally dependent on emp_no since it is not unique to each emp_no.

emp_no name dept_no dept_name skills1 Kevin Jacobs 201 R&D C1 Kevin Jacobs 201 R&D Perl1 Kevin Jacobs 201 R&D Java2 Barbara Jones 224 IT Linux2 Barbara Jones 224 IT Mac3 Jake Rivera 201 R&D DB23 Jake Rivera 201 R&D Oracle3 Jake Rivera 201 R&D Java

Employee (1NF)

Transitive Dependence

Dept_no and dept_name are functionally dependent on emp_no however, department can be considered a separate entity.

emp_no name dept_no dept_name1 Kevin Jacobs 201 R&D2 Barbara Jones 224 IT3 Jake Rivera 201 R&D

Employee (2NF)

Entity - Relationship Model

A logical design method which emphasizes simplicity and readability.

•Basic objects of the model are:• Entities• Relationships• Attributes

Entities

Data objects detailed by the information in the database.

• Denoted by rectangles in the model.

Employee Department

Attributes

Characteristics of entities or relationships.

• Denoted by ellipses in the model.

Name SSN

Employee Department

Name Budget

Relationships

Represent associations between entities.

• Denoted by diamonds in the model.

Name SSN

Employee Department

Name Budget

works in

Start date

Relationship Connectivity

Constraints on the mapping of the associated entities in the relationship.

• Denoted by variables between the related entities.• Generally, values for connectivity are expressed as “one” or

“many”

Name SSN

Employee Department

Name Budget

work 1N

Start date

Connectivity

Department Managerhas 11

Department Projecthas N1

Employee Projectworks on NM

one-to-one

one-to-many

many-to-many

Logical Design to Physical Design

Creating relational SQL schemas from entity-relationship models.

• Transform each entity into a table with the key and its attributes.

• Transform each relationship as either a relationship table (many-to-many) or a “foreign key” (one-to-many and many-to-many).

Entity tables

Transform each entity into a table with a key and its attributes.

Name SSN

Employeecreate table employee(emp_no number,name varchar2(256),ssn number,primary key (emp_no));

Foreign KeysTransform each one-to-one or one-to-many relationship as a “foreign key”.

• Foreign key is a reference in the child (many) table to the primary key of the parent (one) table.

create table employee(emp_no number,dept_no number,name varchar2(256),ssn number,primary key (emp_no),foreign key (dept_no) references department);

Employee

Department

has

1

N

create table department(dept_no number,name varchar2(50),primary key (dept_no));

Foreign Key

dept_no Name1 Accounting2 Human Resources3 IT

emp_no dept_no Name1 2 Nora Edwards2 3 Ajay Patel3 2 Ben Smith4 1 Brian Burnett5 3 John O'Leary6 3 Julia Lenin

Department

Employee

Accounting has 1 employee:Brian Burnett

Human Resources has 2 employees:Nora EdwardsBen Smith

IT has 3 employees:Ajay PatelJohn O’LearyJulia Lenin

Many-to-Many tables

Transform each many-to-many relationship as a table.

• The relationship table will contain the foreign keys to the related entities as well as any relationship attributes.

create table proj_has_emp(proj_no number,emp_no number,start_date date,primary key (proj_no, emp_no),foreign key (proj_no) references projectforeign key (emp_no) references employee);

Employee

Project

has

N

M

Start date

E-R Diagram

DFD

DFD

DFD

Batch time sheets

Verify/validate data

Error report

Prepare Payroll

employee

employee

employee

Accounts dept

Print payroll summary

Print paycheque & payslips

Weekly transactions

Valid weekly transactions

Employee No, hours worked

Employee no, hours worked, batch control totals

Employee no, hours worked

Invalid employee data, batch control totals Employee no,

hours worked

Name, pay rate, tax code, etc.

Employee no, hours worked

Employee no, hours worked

Each employee: Employee nos, pay, tax, etcTotals: pay, tax,etc

Employee no, pay, tax,etc.

Employee no, pay, tax,etc.

Each employee: Employee nos, pay, tax, etcTotals: pay, tax,etc