Education and Research

We enable you to leverage knowledge anytime, anywhere!

RDBMS - Bridge Course

Ver. No.:4.0
ER/CORP/CRS/DB07SC/003

ER/CORP/CRS/TBD Ver. No.: 0.1 Copyright © 2008, Infosys Technologies Ltd.

General Guideline

© (2008) Infosys Technologies Ltd.

This document contains valuable confidential and proprietary information of Infosys.

Such confidential and proprietary information includes, amongst others, proprietary
intellectual property which can be legally protected and commercialized. Such
information is furnished herein for training purposes only. Except with the express
prior written permission of Infosys, this document and the information contained
herein may not be published, disclosed, or used for any other purpose.

Copyright © 2008, Infosys Technologies Ltd. 2

Confidential Information

 This Document is confidential to Infosys Technologies Limited. This document

contains information and data that Infosys considers confidential and
proprietary (“Confidential Information”).
 Confidential Information includes, but is not limited to, the following:
 Corporate and Infrastructure information about Infosys
 Infosys’ project management and quality processes
 Project experiences provided included as illustrative case studies
 Any disclosure of Confidential Information to, or use of it by a third party, will
be damaging to Infosys.
 Ownership of all Infosys Confidential Information, no matter in what media it
resides, remains with Infosys.
 Confidential information in this document shall not be disclosed, duplicated or
used – in whole or in part – for any purpose other than reading without specific
written permission of an authorized representative of Infosys.
 This document also contains third party confidential and proprietary
information. Such third party information has been included by Infosys after
receiving due written permissions and authorizations from the party/ies. Such
third party confidential and proprietary information shall not be disclosed,
duplicated or used – in whole or in part – for any purpose other than reading
without specific written permission of an authorized representative of Infosys.

Copyright © 2008, Infosys Technologies Ltd. 3

Course Objectives

 Introduction of basic RDBMS concepts

 Familiarization with SQL

Copyright © 2008, Infosys Technologies Ltd. 4

Session Plan (1of 2)
Day1
• Traditional Approach, Why DBMS, People Using DBMS
• Data Models
• RDBMS, Keys
• ER Modeling
• Normalization

Day2
• Introduction to SQL and SQL Plus
• DDL
• DML
•Aggregate Functions
•Group By and Having clause

Copyright © 2008, Infosys Technologies Ltd. 5

Session Plan (2 of 2)
Day 3
• Joins
• Independent Sub Queries
• Correlated Sub queries
• Use of EXISTS and NOT EXISTS
 Views
• DCL

Copyright © 2008, Infosys Technologies Ltd. 6

References
 E&R Course Material of RDBMS for Foundation Program

 Henry F Korth, Abraham Silberschatz, “Database system concepts”,

McGraw-Hill International editions, Computer Science Series(1991),
Second ed.,

 Elmasri, Navathe, "Fundamentals of Database Systems",

Addison Wesley, Third ed

 C.J.Date, "An introduction to Database Systems", Narosa Publications, Sixth

ed.,

Copyright © 2008, Infosys Technologies Ltd. 7

Education and Research
We enable you to leverage knowledge anytime, anywhere!

RDBMS Bridge Course Day1

ER/CORP/CRS/TBD Ver. No.: 0.1 Copyright © 2008, Infosys Technologies Ltd.

Session Plan
 Traditional File Approach
 Advantages of a DBMS
 Relational Model Basics
 Keys
 Conceptual Design
 ER Modelling
 ER Modelling Notations
 Normalization

Copyright © 2008, Infosys Technologies Ltd. 9

Traditional Method of Data Storage

Loan_Processing Transaction_Processing
Fixed_Deposit_Processing
(Application Program) (Application Program)
(Application Program)

File System

Customer_Details.dat Customer_Loan.dat Customer_Fixed_Deposit.dat Customer_Transaction.dat

Copyright © 2008, Infosys Technologies Ltd. 10

The Database Technology

Database Management System

• Collection of interrelated files and set of programs which allows users to access and
modify files
• Primary Goal is to provide a convenient and efficient way to store, retrieve
and modify information
• Layer of abstraction between the application programs and the file system

Copyright © 2008, Infosys Technologies Ltd. 11

Where does the DBMS fit in?

Loan_Processing Transaction_Processing
Fixed_Deposit_Processing
(Application Program) (Application Program)
(Application Program)

DBMS

File System

Customer_Loan
Customer_Details Customer_Transaction
Customer_Fixed_Deposit

Bank Database

Copyright © 2008, Infosys Technologies Ltd. 12

Difference Between File and DBMS
Operations
File system Interface DBMS Interface

End User End User

Application Programs Application Programs

Interface through Query (SQL)

Interface through high level language
SELECT * FROM Customer_Details
READ CUSTOMER_DETAILS-FILE AT END
STOP RUN
DBMS

Operating System Operating System

(Disk Manager, File Manager) (Disk Manager, File Manager)

Customer_Details file Customer_Details table

Customer_Loan file Customer_Loan table

File System (Disk Storage) Database(Disk Storage)

Copyright © 2008, Infosys Technologies Ltd. 13

Advantages of a DBMS

 Data independence

 Reduction in data redundancy

 Better security

 Better flexibility

 Effective data sharing

 Enforces integrity constraints

 Enables backup and recovery

Copyright © 2008, Infosys Technologies Ltd. 14

Relational model basics
 Data is viewed as existing in two dimensional tables known as relations

 A relation (table) consists of unique attributes (columns) and tuples (rows)

 Tuples are unique

 Sometimes the value to be inserted into a particular cell may be unknown, or

it may have no value. This is represented by a NULL

 Null is not the same as zero, blank or an empty string

 Relational Database: Any database whose logical organization is based on

relational data model.
 RDBMS: A DBMS that manages the relational database.

Copyright © 2008, Infosys Technologies Ltd. 15

Keys in Relational Model

 Candidate key
A Candidate key is a set of one or more attributes(minimal) that can
uniquely identify a row in a given table.
 Primary Key
During the creation of the table, the Database Designer chooses one
of the Candidate Key from amongst the several available, to uniquely
identify row in the given table.
 Alternate Key
The candidate key that is chosen to perform the identification task is called
the primary key and the remaining candidate keys are known as alternate
keys.
No of Alternate Keys = No of Candidate Keys - 1
 Super Key
Any superset of a candidate Key is a super key.

Copyright © 2008, Infosys Technologies Ltd. 16

Key and Non-key Attributes in
Relational Model
 Key Attributes
The attributes that participate in the Candidate key are Key
Attributes
 Non-Key Attributes
 The attributes other than the Candidate Key attributes in a
table/relation are called Non-Key attributes.
OR
 The attributes which do not participate in the Candidate key.

Copyright © 2008, Infosys Technologies Ltd. 17

Example

Given a relation
Trainee(Empno, FirstName, LastName, Email, PhoneNo)

Candidate key:
{Empno},{Email},{PhoneNo},{FirstName,LastName}

Primary key:
{Empno}

Alternate Key:
{Email},{PhoneNo},{FirstName,LastName}

Super Key:
{Empno},{Empno,PhoneNo},{Email,FirstName}, etc…

Copyright © 2008, Infosys Technologies Ltd. 18

Exercise on Key attributes

Given a relation R1(X,Y,Z,L) and the following attribute(s) can

uniquely identify the records of relation R1.

1)X
2)X,L
3)Z,L

Identify the following in relation R1?

Candidate Key(s)
Primary Key
Alternate Key
Key attribute(s)
Non-key attribute(s)

Copyright © 2008, Infosys Technologies Ltd. 19

Foreign Key

 Foreign key
• A Foreign Key is a set of attribute (s) whose values are required to match
values of a column in the same or another table.

DEPT EMP
(Parent /Master/Referenced Table) (Child /Referencing Table)
DeptNo DName EmpNo EName EDeptNo
D1 IVS 1001 Elsa D1
D2 ENR 1002 John D2
1003 Maria Null
1004 Maida D1
 Point to remember
 Foreign key values do not (usually) have to be unique.
 Foreign keys can also be null .

Copyright © 2008, Infosys Technologies Ltd. 20

Foreign Key

 Foreign key

Demos

 Points to remember
 A Foreign Key is a set of attributes of a table, whose values are
required to match values of some Candidate Key in the same or
another table
 The constraint that values of a given Foreign Key must match the
values of the corresponding Candidate Key is known as
Referential constraint
 A table which has a Foreign Key referring to its own Candidate
Key is known as Self-Referencing table

Copyright © 2008, Infosys Technologies Ltd. 21

Education and Research
We enable you to leverage knowledge anytime, anywhere!

Database Design Techniques

ER/CORP/CRS/TBD Ver. No.: 0.1 Copyright © 2008, Infosys Technologies Ltd.

Database Design Techniques

Top down Approach

Top down starts by defining the data sets and then define the data
elements within those sets. As a result of this method, you generally
end up with redundant information in one or more tables.

Some references call this Entity - Relationship modeling.

Bottom Up approach
Bottom up starts by defining the required attributes and then grouping
them to form the entities. Another term used for this method is
normalization from functional dependencies.

Copyright © 2008, Infosys Technologies Ltd. 23

Education and Research
We enable you to leverage knowledge anytime, anywhere!

ER Modeling
-Top down Approach

24
ER/CORP/CRS/TBD Ver. No.: 0.1 Copyright © 2008, Infosys Technologies Ltd.
ER modeling
 ER modeling: A graphical technique for understanding and organizing the
data independent of the actual database implementation.

 Entity: Any thing that may have an independent existence and about which
we intend to collect data.
Also known as Entity type. E.g.: Trainee

 Relationships: Associations between entities. E.g.: Trainee belongs to a

Batch

 Attributes: Properties/characteristics that describe entities.eg: Trainee

Name, BatchName, DOB, Address, etc.

Copyright © 2008, Infosys Technologies Ltd. 25

Entity Types
 Regular Entity: Entity that has its own key attribute (s).

E.g.: Employee, student ,customer, policy holder etc.

 Weak entity: Entity that depends on other entity for its existence and
doesn’t have key attribute (s) of its own

E.g. : spouse of employee

Copyright © 2008, Infosys Technologies Ltd. 26

Attributes
 The set of possible values for an attribute is called the domain of
the attribute
Example:
 The domain of attribute marital status is having four values:
single, married, divorced or widowed.

 The domain of the attribute month is having twelve values ranging

from January to December.

 Key attribute: The attribute (or combination of attributes) that is

unique for every entity instance
 E.g.: the account number of an account, the employee id of an
employee etc.

Copyright © 2008, Infosys Technologies Ltd. 27

Attribute Type

Types of Attributes Definition Example

Simple attribute Cannot be divided into simpler Gender of the
components employee
Composite attribute Can be split into components Date of joining of the
employee
Single valued Can take on only a single value for Age of the employee
each entity instance
Multi-valued Can take up many values Skill set of the
employee
Stored Attribute Attribute that need to be stored Date of joining of the
permanently employee

Derived Attribute Attribute that can be calculated Years of service of the

based on other attributes. employee

Copyright © 2008, Infosys Technologies Ltd. 28

Degree of a Relationship

 Degree: the number of entity types involved

» One Unary
» Two Binary
» Three Ternary

E.g.: employee manager-of employee is unary

employee works-for department is binary
customer purchase item, shop keeper is a ternary
relationship

Copyright © 2008, Infosys Technologies Ltd. 29

Cardinality

 Relationships can have different connectivity

 one-to-one (1:1)
 one-to-many (1:N)
 many-to- One (M:1)
 many-to-many (M:N)

E.g.:
Employee head-of department (1:1)
Lecturer offers course (1:N) assuming a course is taught by a single
lecturer
Student enrolls course (M:N)

Copyright © 2008, Infosys Technologies Ltd. 30

Relationship Participation
 Total : Every entity instance must be connected through the relationship to
another instance of the other participating entity types

 Partial: All instances need not participate

E.g.: Employee Head-of Department

Employee: partial
Department: total

Copyright © 2008, Infosys Technologies Ltd. 31

Education and Research
We enable you to leverage knowledge anytime, anywhere!

ER Modeling - Notations

ER/CORP/CRS/DB07SC/003 Ver. No.: 4.0 Copyright © 2008, Infosys Technologies

ER Modeling -Notations

Entity An Entity is an object or concept about

which business user wants to store
information.
A weak Entity is dependent on another
Entity
Entity to exist. Example Order Item depends
upon Order Number for its existence.
Without Order Number it is impossible to
identify Order Item uniquely.
Attribute Attributes are the properties or
characteristics of an Entity

A key attribute is the unique, distinguishing

Attribute
characteristic of the Entity

A multi-valued attribute can have more

Attribute than one value. For example, an employee
Entity can have multiple skill values.

Copyright © 2008, Infosys Technologies Ltd. 33

ER Modeling -Notations

Attribute
A derived attribute is based on another attribute.
For example, an employee's monthly salary is
based on the employee's basic salary and House
rent allowance.

Relationships illustrate how two entities share

Relationship
information in the database structure.

To connect a weak Entity with others, you

Relationship
Relationship
should use a weak relationship notation.

Copyright © 2008, Infosys Technologies Ltd. 34

ER Modeling -Notations
Customer Cardinality specifies how many instances of an
Entity relate to one instance of another Entity.
1 M,N both represent ‘MANY’ and 1 represents
‘ONE’ Cardinality

1 M
Account Transaction

In some cases, entities can be self-

linked. For example, employees can
supervise other employees
Employee

Copyright © 2008, Infosys Technologies Ltd. 35

Composite attribute

floor building

DOB
Name Address

E# Designation
Employee

Copyright © 2008, Infosys Technologies Ltd. 36

Unary Relationship

Manages
Employee

Copyright © 2008, Infosys Technologies Ltd. 37

Role names
 Role names may be added to make the meaning more explicit

subordinate

Manages
Employee

Manager

Copyright © 2008, Infosys Technologies Ltd. 38

Binary Relationship

Works
Employee Department
for

Copyright © 2008, Infosys Technologies Ltd. 39

Ternary Relationship

Medicine

Doctor Prescription Patient

Copyright © 2008, Infosys Technologies Ltd. 40

Relationship participation

1 head 1
Employee department
of

l otal
partia T

Copyright © 2008, Infosys Technologies Ltd. 41

Attributes of a Relationship

Medicine

Number of days

dosage

Doctor Prescription Patient

Copyright © 2008, Infosys Technologies Ltd. 42

Weak entity

E# Id name
----

1 has N dependant
Employee

The dependant entity is represented by a double lined rectangle and

the identifying relationship by a double lined diamond

Copyright © 2008, Infosys Technologies Ltd. 43

Case Study – ER Model For a college
DB
Assumptions :

 A college contains many departments

 Each department can offer any number of courses
 Many instructors can work in a department
 An instructor can work only in one department
 For each department there is a Head
 An instructor can be head of only one department
 Each instructor can take any number of courses
 A course can be taken by only one instructor
 A student can enroll for any number of courses
 Each course can have any number of students

Copyright © 2008, Infosys Technologies Ltd. 44

Steps in ER Modeling

 Identify the Entities

 Find relationships

 Identify the key attributes for every Entity

 Identify other relevant attributes

 Draw complete E-R diagram with all attributes including Primary Key

 Review your results with your Business users

Visit the following link for more information

10 Easy Steps to Create an ER Diagram in VISIO 2000
Copyright © 2008, Infosys Technologies Ltd. 45
Steps in ER Modeling
Step 1: Identify the Entities

 DEPARTMENT

 STUDENT

 COURSE

 INSTRUCTOR

Copyright © 2008, Infosys Technologies Ltd. 46

Steps in ER Modeling

Step 2: Find the relationships

 One course is enrolled by multiple students and one student enrolls for multiple
courses, hence the cardinality between course and student is Many to Many.

 The department offers many courses and each course belongs to only one
department, hence the cardinality between department and course is One to Many.

 One department has multiple instructors and one instructor belongs to one and only
one department , hence the cardinality between department and instructor is one to
Many.

 Each department there is a “Head of department” and one instructor is “Head of

department “,hence the cardinality is one to one .

 One course is taught by only one instructor, but the instructor teaches many courses,
hence the cardinality between course and instructor is many to one.

Copyright © 2008, Infosys Technologies Ltd. 47

Steps in ER Modeling
Step 3: Identify the key attributes

 Deptname is the key attribute for the Entity “Department”, as it identifies the
Department uniquely.
 Course# (CourseId) is the key attribute for “Course” Entity.
 Student# (Student Number) is the key attribute for “Student” Entity.
 Instructor Name is the key attribute for “Instructor” Entity.

Step 4: Identify other relevant attributes

 For the department entity, the relevant attribute is location

 For course entity, course name,duration,prerequisite
 For instructor entity, room#, telephone#
 For student entity, student name, date of birth

Copyright © 2008, Infosys Technologies Ltd. 48

Steps in ER Modeling

Step 5: Draw the E-R diagram

ER diagram for the

University

Copyright © 2008, Infosys Technologies Ltd. 49

Education and Research
We enable you to leverage knowledge anytime, anywhere!

Normalization
-Bottom up approach

ER/CORP/CRS/TBD Ver. No.: 0.1 Copyright © 2008, Infosys Technologies Ltd.

What is Normalization?

Database design may have some amount of

 Inconsistency
 Uncertainty
 Redundancy

To eliminate these drawbacks some refinement has to be done on the

database. This Refinement process is called Normalization.

Copyright © 2008, Infosys Technologies Ltd. 51

Normalization

 It is Defined as a step-by-step process of decomposing a complex

relation into a simple and stable data structure.

 It is a formal process that can be followed to achieve a good

database design

 Also used to check that an existing design is of good quality

 The different stages of normalization are known as “Normal Forms”

 To accomplish normalization we need to understand the concept of

Functional Dependencies.

Copyright © 2008, Infosys Technologies Ltd. 52

Functional dependency
 In a given relation R, X and Y are attributes. Attribute Y is
functionally dependent on attribute X if each value of X
determines EXACTLY ONE value of Y, which is represented as X -
> Y (X can be composite in nature).

 We say here “x determines y” or “y is functionally dependent on x”

XY does not imply YX

 If the value of an attribute “Marks” is known then the value of an

attribute “Grade” is determined since MarksGrade

Copyright © 2008, Infosys Technologies Ltd. 53

Functional dependency

Types of functional dependencies:

 Full Functional dependency

 Partial Functional dependency
 Transitive dependency

Copyright © 2008, Infosys Technologies Ltd. 54

Functional Dependencies

Consider the following Relation

REPORT (STUDENT#,COURSE#, StudentName,CourseName, Marks,

Grade)

Description of the Attributes:

 STUDENT# - Student Number

 COURSE# - Course Number
 StudentName- Student Name
 CourseName - Course Name
 Marks - Scored in Course COURSE# by Student STUDENT#
 Grade - obtained by Student STUDENT# in Course COURSE#

Copyright © 2008, Infosys Technologies Ltd. 55

Functional Dependencies- From the previous
example
 For each value of (Student# ,Course#), Marks obtained will be exactly
one value. So we observe the following Functional dependency

STUDENT# COURSE#  Marks

 For each value of Course# the name of the course will be exactly one
value. So we observe the following Functional dependency

COURSE#  CourseName,

 For each value of Marks the grade will be exactly one value. So we
observe the following functional dependency

Marks  Grade
Copyright © 2008, Infosys Technologies Ltd. 56
Full dependencies

X and Y are attributes.

X Functionally determines Y
Note: Subset of X should not functionally determine Y

Student#

Marks

Course#

Copyright © 2008, Infosys Technologies Ltd. 57

Partial dependencies
X and Y are attributes.
Attribute Y is partially dependent on the attribute X only if it is dependent
on a sub-set of attribute X.

We have both the functional dependency valid in our example

Student# Course# CourseName

Course# CourseName

So we can say that CourseName is partially dependent on Student#

Course#
Copyright © 2008, Infosys Technologies Ltd. 58
Transitive dependencies

X Y and Z are three attributes.

X -> Y
Y-> Z
=> X -> Z

Copyright © 2008, Infosys Technologies Ltd. 59

Need for Normalization

Lets observe the Online Retail Application Table

Microsoft Office
Excel 97-2003 Worksheet

Each row of the table Represents the information of a customer who has
purchased an item.

Copyright © 2008, Infosys Technologies Ltd. 60

Need for Normalization

In this Scenario
 Can we Insert the record of an item which has not been
purchased by any customer?
The table is not to maintain the
record of items but it is to keep the
record of purchase of item by
customers

Can we delete the record of item which has been purchased by only
one customer? There will be information
Loss for that item

How many rows we need to update if there is a change in

description of item? Depends upon the no
of times the item has
been purchased

How many times we need to store the description of an item if the

same item is purchased many times? Depends upon the no of times
the item has been purchased
Copyright © 2008, Infosys Technologies Ltd. 61
Need for Normalization

So we observe the following in the Un Normalized table:

 Insert , Delete, Update Anomaly
 Data Duplication

Copyright © 2008, Infosys Technologies Ltd. 62

First Normal Form: 1NF

 A relation schema is in 1NF :

 if and only if all the attributes of the relation R are

atomic in nature.

 Atomic: the smallest level to which data may be

broken down and remain meaningful

Copyright © 2008, Infosys Technologies Ltd. 63

Online Retail Application Tables –
1NF Normalized
Observation on Un Normalized Retail Application Table
Customerdetails, Itemdetails and PurchaseDetails are composite

Above observation violates 1NF definition

To bring it to 1NF we need to make the columns atomic

Microsoft Office
Excel 97-2003 Worksheet

Copyright © 2008, Infosys Technologies Ltd. 64

Second Normal Form: 2NF

 A Relation is said to be in Second Normal Form if and only if :

 It is in the First normal form, and
 No partial dependency exists between non-key attributes and
key attributes.

• An attribute of a relation R that belongs to the candidate key of R is said to

be a key attribute and that which doesn’t is a non-key attribute

To make a table 2NF compliant, we have to remove all the partial dependencies

Copyright © 2008, Infosys Technologies Ltd. 65

Second Normal Form : Example

Functional Dependencies of Retail Application Table

RetailApplicationTable( CustomerId, ItemId, CustomerName,
AccountNo,ItemName, UnitPrice, Class,QtyPurchased, NetAmount)

(i) CustomerId  CustName, AccountNo

(ii) ItemId  ItemName, UnitPrice, Class

(iii) CustId,ItemId QtyPurchased, NetPrice

(iv) UnitPriceClass

Copyright © 2008, Infosys Technologies Ltd. 66

Second Normal Form : Example (Cont..)

Key and Non Key Attributes of Retail Application Table

{CustomerId, ItemId} is Candidate key

Key Attributes: CustomerId,ItemId

Non Key Attribures: CustomerName,

AccountNo,
ItemName,
UnitPrice,
Class,
QtyPurchased,
NetAmount

Copyright © 2008, Infosys Technologies Ltd. 67

Second Normal Form : Example (Cont..)
Fully Functionally dependent on Key Attribute

CustomerId, ItemId QtyPurchased, NetPrice

Partial Dependency with respect to Key Attribute

CustomerId CustomerName,AccountNo,BankName

ItemId ItemName,UnitPrice,Class

No Dependency with respect to Key Attribute

UnitPrice Class

Copyright © 2008, Infosys Technologies Ltd. 68

Second Normal Form : Example (Cont..)
After removing the Partial dependencies on Key Attributes we get the below
tables which are in 2NF:

Customer
CustomerId CustomerName Accountno
1001John 1500012351
1002Tom 1200354611
1001John 2134724532

Item
ItemId ItemName UnitPrice Class
STN001 Pen 10A
BAK003 Bread 10A
GRO001 Poteto 20B

Copyright © 2008, Infosys Technologies Ltd. 69

Second Normal Form : Example (Cont..)

ItemPurchase
CustomerId ItemId QtyPurchased NetAmt
1001STN001 5 50
1002BAK003 1 10
1001GRO001 1 20

Copyright © 2008, Infosys Technologies Ltd. 70

Third Normal Form: 3 NF

A relation R is said to be in the Third Normal Form (3NF) if and only if

 It is in 2NF and
 No transitive dependency exists between non-key attributes and
key attributes through another non key attribute.

A B C

It should
be key
Attribute
It should be
non key
It should be
attribute
non key
attribute

To make a table 3NF compliant, we have to remove all such Transitive

Dependencies

Copyright © 2008, Infosys Technologies Ltd. 71

Third Normal Form : Example

Let us consider Item table obtained after bringing Retail Application table
in to 2NF:

ItemId UnitPrice

UnitPrice Class

ItemId UnitPrice Class

The above dependencies violates 3NF definition

Copyright © 2008, Infosys Technologies Ltd. 72

Third Normal Form : Example (Cont..)
After removing the transitive dependencies from the Item table we get
the following two table

Item
ItemId ItemName UnitPrice
STN001 Pen 10
BAK003 Bread 10
GRO001 Poteto 20

ItemClass
UnitPrice Class
10A
20B

Copyright © 2008, Infosys Technologies Ltd. 73

Merits of Normalization

 Normalization is based on a mathematical foundation.

 Removes the redundancy to a greater extent.

 After 3NF, data redundancy is minimized to the extent of foreign

keys.

 Removes the anomalies present in INSERTs, UPDATEs and

DELETEs.

Copyright © 2008, Infosys Technologies Ltd. 74

Demerits of Normalization

 Data retrieval or SELECT operation performance will be severely

affected.

 Normalization might not always represent real world scenarios.

Copyright © 2008, Infosys Technologies Ltd. 75

Summary

 Most of the application errors are because of miscommunication

between the application user and the designer and between the
designer and the developer.
 It is always better to represent business findings in terms of picture
to avoid miscommunication
 It is practically impossible to review the complete requirement
document by business users.
 An E-R diagram is one of the many ways to represent business
findings in pictorial format.
 E-R Modeling will also help the database design
 E-R modeling has some amount of inconsistency and anomalies
associated with it.

Copyright © 2008, Infosys Technologies Ltd. 76

Summary

 Normalization is a refinement process. It helps in removing

anomalies present in INSERTs/UPDATEs/DELETEs.

 Normalization is also called “Bottom-up approach”, because this

technique requires very minute details like every participating
attribute and how it is dependant on the key attributes, is crucial. If
you add new attributes after normalization, it may change the normal
form itself.

 There are four normal forms that were defined being commonly
used.

 1NF makes sure that all the attributes are atomic in nature.

 2NF removes the partial dependency.

Copyright © 2008, Infosys Technologies Ltd. 77
Summary – contd.

 3NF removes the transitive dependency.

 Too much of normalization adversely affects SELECT or

RETRIEVAL operations.

 It is always better to normalize to 3NF for INSERT, UPDATE and

DELETE intensive (On-line transaction) systems.

 It is always better to restrict to 2NF for SELECT intensive

(Reporting) systems.

 While normalizing, use common sense and don’t use the normal
forms as absolute measures.

Copyright © 2008, Infosys Technologies Ltd. 78

 Thank You

“The contents of this document are proprietary and confidential to Infosys Technologies Ltd. and may
not be disclosed in whole or in part at any time, to any third party without the prior written consent of
Infosys Technologies Ltd.”

“© 2008 Infosys Technologies Ltd. All rights reserved. Copyright in the whole and any part of this
document belongs to Infosys Technologies Ltd. This work may not be used, sold, transferred, adapted,
abridged, copied or reproduced in whole or in part, in any manner or form, or in any media, without the
prior written consent of Infosys Technologies Ltd.”

Copyright © 2008, Infosys Technologies 79

Ltd.