Session 9, 10 & 11

E-ERD, DBMS Problems and Normalization Approach

21st

THU, SAT , WED , 23rd , 27th July 2011

1
Prashant Barge, SIOM

Todays Agenda

E-ERD concept Database Vs. DBMS

DBMS Problems
Normalization Approach

2
Prashant Barge, SIOM

*
Draw ERD for 1. Employee is Supervisor, Manager and Staff. Also Staff if Permanent and Ad-hoc

2. For Vehicle Registration database, vehicle may be Two or Three or Four Wheeler. Owner may be Person or Bank or Organization. 3. For a College database, student is UG, G or PG.

The basic concepts of ER modelling is not powerful enough for some complex applications... We require some additional semantic modelling concepts:

* Specialisation* SuperClass & SubClass * Attribute Inheritance * Generalisation * Categorisation * Aggregation

*
This is the process of maximising the differences between members of an entity by identifying their distinguishing characteristics.

* Staff(staff_no,name,address,dob) * Manager (Role) * Secretary(w_skills) * Sales_personnel (sales_area, car_allowance)

*
manages Department works for Sales Personnel Staff Manager Secretary

*Here

we have shown that the manages relationship is only applicable to the Manager subclass, whereas the works_for relationship is applicable to all staff. *It is possible to have subclasses of subclasses.

Subclasses and Superclasses

a
a

subclass entity type is a specialised type of superclass entity type

subclass entity type represents a subset or subgrouping of superclass entity types instances undergraduates and postgraduates subclasses of student superclass are

e.g.

Attribute Inheritance

subclasses inherit properties (attributes) of their

superclasses

 Specialisation
the process of defining a set of more specialised entity types of an entity type

Generalisation
the process of defining a generalised entity type from a set of entity types

 Disjoint Constraint
Disjoint Overlap

Participation Constraint
Total Participation Partial Participation

 Disjointness
Overlap Disjoint
the same entity instance is a member of only one subclass of the specialization

the same entity instance may be a member of more than one subclass of the specialization

Completeness
Total
every entity instance in the superclass must be a member of some subclass in the specialisation

Partial
an entity instance in the superclass need not be a member of any subclass in the specialisation

*
given name STUDENT family studno

Total Participation with Disjoint d

STAFF
1 year

tutor

m undergraduate thesis title postgraduate

payroll no

name STAFF

length of service

Partial Participation with Overlap O

level grade

ACADEMIC

TECHNICAL

ADMIN

project

name

PERSON

address O salary fee

Overlap

EMPLOYEE

STUDENT

Overlap
thesis

Disjoint

RESEARCH

TEACHING POST GRAD UNDER GRAD

Overlap

LECTURING

TUTORS

SUPERVISOR

FINAL YEAR

Course no

project

*a single superclass/subclass relationship with more than one

superclass, where the superclasses represent different entity types (sometimes with different keys)

PERSON

COMPANY

personid

compid

U
duration of ownership

OWNER

*
1. Create a relation for superclass
2. Create a relation for each subclass such that: {primary_key of superclass} U {attributes of subclass}

Option A

3. key for subclass is (primary_key of superclass)

given name STUDENT family studno

d
year undergraduate thesis title postgraduate

Option B

1. Create a relation for each subclass such that:

{primary_key U {attributes of superclass} of superclass} U {attributes of subclass}

key for each relation is (primary_key of superclass)

given name STUDENT

family studno

d
year undergraduate thesis title postgraduate

Option C 1. Create one relation such that:

{primary_key U {attributes of superclass} of superclass} U {attributes
of all subclasses}

U {type attribute}

key for subclass is (primary_key of superclass)

given name STUDENT family studno

d
year undergraduate thesis title postgraduate

1.STAFF(payrollno,name,lengthofservice) ACADEMIC(payrollno,level)
payroll no name STAFF

TECHNICAL(payrollno,project)

ADMIN(payrollno,grade)
length of service

2.ACADEMIC(payrollno,name,lengthofservice,

O
level grade

level) TECHNICAL(payrollno,name,lengthofservice, project) ADMIN(payrollno, name, lengthofservice, grade) 3.STAFF(payrollno, name, lengthofservice, level,

ACADEMIC

TECHNICAL

ADMIN

project,grade,type1,type2,type3) STAFF(payrollno, name, lengthofservice, level, project,grade,type)

project

type = power set of classes

*
name address O salary fee PERSON

EMPLOYEE

STUDENT

O thesis RESEARCH TEACHING 1-2 O POST GRAD

UNDER GRAD

year = 3

LECTURING

TUTORS

SUPERVISOR

FINAL YEAR

courseno

project

Prashant Barge, SIOM

20

Database Management System (DBMS)

Systems software that facilitates the management of a database.

E.g. Oracle, Access, SQL Server

The software that organises data into records in one or more databases and allows organising, accessing and sorting of the data in a variety of formats.

21

Relational DBMS (RDBMS)

Most commonly used DBMS. Data elements are stored in different tables made up of rows and columns. Relates data in different tables through the use of common data element(s) / attributes.

22

Database Approach
Advantages

Program-data independence Minimal data redundancy Improved data consistency Improved data sharing Increased productivity of application development Enforcement of standards Improved data quality Improved data accessibility and responsiveness Reduced maintenance
23

3 Level Architecture
user a user i/program j program x

sub-schema a sub-schema i sub-schema z conceptual schema physical schema

Databa ses 24

External Users and Applications view of data Conceptual Logical Data Model Physical Physical data Model
25

 External (Sub) Schema defines the external view of data as seen by a user or program
Conceptual Schema defines the logical view of data as seen by all technical users and programs Physical (Internal) Schema defines the physical view of data as seen by a DBMS
26

DBMS Models
1. Hierarchy Model 2. Network Model 3. Relational DBMS 4. Object Oriented Model -

27

Prashant Barge, SIOM

DBMS Models
1. Hierarchy Model (1960s) Data in a tree structure, Parent Child Relationships Which is one to many, Restricts a child segment to having only one parent segment

28

Prashant Barge, SIOM

DBMS Models
2. Network Model
Conference on Data Systems Languages (CODASYL) formally defined the network model in 1971. basic data modeling construct in the network model is the set construct. A set consists of an owner record type, a set name, and a member record type. A member record type can have that role in more than one set, hence the multi-parent concept is supported. An owner record type can also be a member or owner in another set.
29
Prashant Barge, SIOM

DBMS Models
3. Relational DBMS Relational model developed by E.F. Codd. The data and relations between them are organized in tables. A table is a collection of records and each record in a table contains the same fields. Certain fields are designated as keys.
30
Prashant Barge, SIOM

Properties of Relational Tables:

Values Are Atomic Each Row is Unique Column Values Are of the Same Kind The Sequence of Columns is Insignificant The Sequence of Rows is Insignificant Each Column Has a Unique Name

31

Prashant Barge, SIOM

DBMS Models
4.

Object Oriented Model

For Complex Relationships

UML Easy to Maintain and Change Improved Productivity

Prashant Barge, SIOM

32

Metadata
Data that describe the properties or characteristics of data. Some of these properties include data definitions, data structures and rules or constraints. Item name, the data type, length, minimum and maximum allowable values (where appropriate) and a brief description of each data item. Metadata allow database designers and users to understand what data exist, what the data mean. Data without clear meaning can be confusing, misinterpreted.
33

Metadata
E.g. Data Item Name Type Name Character ID Number Dept Character Age Integer Name Character Manager Number Value Length Min Max 30 9 10 2 18 60 15 9

Description Employee Name Employee No. Dept. No. Employee Age Dept. Name Mgr. Emp. No.

Employee No. (ID) unique Manager is an employee of the organisation

34

Database Approach
Disadvantages DBMS are more vulnerable than file-based system because of the centralised nature of a large integrated database. If a failure occurs the recovery process is more complex and some times may results in lost transactions. Hardware, software and personnel cost are higher for DBMS.

35

Session 11

Prashant Barge, SIOM

36

Normalization Approach There are many types / levels of normalized forms existing in a database environment
Unnormalized Form (UNF) First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF)
These are some advanced normal forms used rarely.

Boyce-Codd Normal Form (BCNF) Fourth Normal Form (4NF) Fifth Normal Form (5NF)

 It

is the process of Decomposing unsatisfactory relations/ user views into smaller relations
It is process of analysis of functional dependency between attributes / data items of user views

Its an another approach for Conceptual data model which in turn can be mapped to any one of the data model like
Hierarchical Network Relational

What is the need of Normalization ?

Reduce Data Redundancy Reduce Data Storage Space Reduce Inconsistency of Data Reduce Update Costs Improve Flexibility

Example : STUDENTS Relation for maintained by Academic coordinator

Student

Info

Card

Roll No Name Course Phone Number Major Subject Professor Grade

Student ( Roll_No, name, course, phone_no, Major_subject, Prof, grade )

Different constraints

*Students Roll No should be unique *A student can join many courses *A particular student has a single phone number, and single
major Subject

*A course is taught by only one Professor *One grade is given to a student for a particular course

Constraints

Constraints Restricts / guides the design of the Data Bases So Very imp to understand the constraints

A Relational State
Roll No Name 101 Rohit Course CS203 Ph-No 696453 Major Comp. Prof. Rajat Grade A

102
101 103 103 101 104

Nath
Rohit Martin Martin Rohit Baxter

CS303
CS328 CS303 CS503 CS492 CS379

427739
696453 388518 388518 696453 831803

Chemi.
Comp. Physics Physics Comp. English

Bharat
Rajat Bharat Shyam Criss Roid

B
B A C B C

PROBLEMS

Redundancy Update Anomalies Insertion Anomalies Deletion Anomalies

Redundancy Of Data

Roll No
101 102

Name
Rohit Nath

Course
CS203 CS303

Ph-No
696453 427739

Major
Comp. Chemi.

Prof.
Rajat Bharat

Grade
A B

101
103 103 101 104

Rohit
Martin Martin Rohit Baxter

CS328
CS303 CS503 CS492 CS379

696453
388518 388518 696453 831803

Comp.
Physics Physics Comp. English

Rajat
Bharat Shyam Criss Roid

B
A C B C

Update Anomalies- Phone no. changed

Roll No 101 102 101 103 103 101 Name Rohit Nath Rohit Martin Martin Rohit Course CS203 CS303 CS328 CS303 CS503 CS492 Ph-No 696453 427739 696453 388518 388518 696453 Major Comp. Chemi. Comp. Physics Physics Comp. Prof. Rajat Bharat Rajat Bharat Shyam Criss Grade A B B A C B

104

Baxter

CS379

831803

English

Roid

Roll No 101 102 101 103 103 101

Name Rohit Nath Rohit Martin Martin Rohit

Course CS203 CS303 CS328 CS303 CS503 CS492 CS500

Ph-No 696453 427739 696453 388518 388518 696453

Major Comp. Chemi. Comp. Physics Physics Comp.

Prof. Rajat Bharat Rajat Bharat Shyam Criss Roid

Grade A B B A C B C

Insertion Anomalies New Course entry

Deletion Anomalies course info may get lost

Name Rohit Course CS203 Ph-No 696453 Major Comp. Prof. Rajat Grade A

Nath
Rohit

CS303
CS328

427739
696453

Chemi.
Comp.

Bharat
Rajat

B
B

Martin

CS303

388518

Physics

Bharat

Martin
Rohit Baxter

CS503
CS492 CS379

388518
696453 831803

Physics
Comp. English

Shyam
Cross Rod

C
B C

* Functional Dependence

*These are type of constraints on Relations *Express facts about the enterprise that
we are modeling with the database

Identifying Functional Dependence

There is no algorithmic / scientific method of identifying dependency. We have to use our common sense / observation and judgment to specify dependencies.

Dependency Diagram
Name Roll No Phone Major Grade Course

Prof.

Key Attributes

Problems in the STUDENT relation schema can be resolved by DECOMPOSITION

Normalization

*Is

an attempt to eliminate/minimize the problems occurring due to data redundancy

*Is

an attempt Decomposition.

for

Good

Database

Design

using

(U NF)
This is also called a flat file
There
are no composite and multi valued attributes, and describes one property.

A Database Schema is in UNF if every Relational

Schema included in the Database Schema is in UNF.

STUDENTS Info Sheet Roll No 101 102 101 103 103 101 104 Name Rohit Nath Rohit Martin Martin Rohit Baxter Course CS203 CS303 CS328 CS303 CS503 CS492 CS379 Ph-No 696453 427739 696453 388518 388518 696453 831803 Major Comp. Chemi. Comp. Physics Physics Comp. English Prof. Rajat Bharat Rajat Bharat Shyam Criss Roid Grade A B B A C B C

Student ( Roll No, Name, Course, Ph.No, Major, Prof, Grade)

This relation is in UNF

FIRST NORMAL FORM (1 NF)

A relation is said to be in 1 NF if it is already in UNF and it

has no Repeating Groups

If Each attribute is Primitive A

Database Schema is in 1NF if every Relational Schema included in the Database Schema is in 1NF.

Removed Repeating Group

Roll No 101 102 101 103 103 101 104 Course CS203 CS303 CS328 CS303 CS503 CS492 CS379 Prof. Rajat Bharat Rajat Bharat Shyam Cross Rod Grade A B B A C B C

Roll No Name

Ph No

Major

101
102 103 104

Rohit
Nath Martin Baxter

696453
427739 388518 831803

Comp
Chemi Phy Eng

1. Student ( Roll No, Name, Ph No, Major ) 2. Student_Course ( Roll No, Course, Prof, Grade )

These relations are in 1NF

SECOND NORMAL FORM (2NF)

*A relation is said to be in 2NF if it is in 1NF and it has no

Partial Dependency
*i.e.
non-key attributes are fully functionally dependent on the key attribute(s).

*If the key has more than one attribute then no non-key

attributes should be functionally dependent on a part of the key attributes.

*Dependency Diagram
Grade depends on both while Prof is associated fully on course (partial key attribute)

Roll No

Grade
Prof.

Course

Key Attributes

Partial Dependencyleads Data Redundancy and Anomalies

Roll No

Grade

Course

Prof.
This can be solved by means of DECOMPOSITION

Key Attributes

Name Roll No Phone Major Course *Dependency Diagram Prof. Grade

Key Attributes

Name Roll No Phone Major Course *Dependency Diagram Prof. Grade

Key Attributes

Name Roll No Phone Major Course *Dependency Diagram Prof. Grade

Key Attributes

* STUDENT Relation IN 2NF

1. Student (Roll No, Name, Phone, Major)

2. Result (Roll No, Course, Grade) 3. Course (Course, Prof.)

1. Student (Roll No, Name, Phone, Major)

Roll No to Name, Phone and major dependency are being preserved in the STUDENT relation.

* STUDENT Relation IN 2NF

2. Result (Roll No, Course, Grade)

Roll no to Course and Grade dependency is being preserved in the RESULT relation

*STUDENT Relation IN 2NF

3. Course (Course, Prof.)

Phone

Name

Course to Prof. is being preserved in the Course relation Major

* STUDENT Relation IN 2NF Grade

STUDENT Relation after 2NF

1. Student (Roll No, Name, Phone, Major)

2. Result (Roll No, Course, Grade) 3. Course (Course, Prof.)

Class work : Hostel info relation Student ( Roll no, Name, Dept., Year, Hostel )
Roll No 1784 1648 1768 1848 1682 1485 Name Rohit Shyam Kiran Maya Gopal Jinu Depart. Physics Chemistry Zoology Geology English Botany Year 1 1 2 2 3 4 Hostel Ganga Ganga Kaveri Kaveri Periyar Nila

This relation is in 2NF

Roll No

Name

Dept.

Year

Hostel

1784
1648 1768 1848 1682 1485

Rohit
Shyam Kiran Maya Gopal Jinu

Physics
Chemistry Zoology Geology English Botany

1
1 2 2 3 4

Ganga
Ganga Kaveri Kaveri Periyar Nila

Key Attribute

Non-Key Attributes

Roll No
1784 1648

Name
Rohit Shyam

Dept.
Physics Chemistry

Year
1 1

Hostel
Ganga Ganga

1768 1848 1682 1485

Kiran Maya Gopal Jinu

Zoology Geology English Botany

2 2 3 4

Kaveri Kaveri Periyar Nila

Key Attribute

Non-Key Attributes

Roll Name No 1784 Rohit 1648 Shyam

Dept..

Year Hostel 1 1 2 2 3 4 Ganga Ganga Kaveri Kaveri Periya r Nila

Physics Chemist ry 1768 Kiran Zoology Functionally 1848 Mayadetermines Geology 1682 Gopal English 1485 Jinu Botany

*STUDENT Relation
Student ( Roll No, Name, Dept., Year, Hostel )

So a Dependency existing between the Year and the Hostel

Dependency Diagram

Name Key Attribute Depart. Roll No Year

We are in trouble

Hostel

This is Transitive Dependency

Redundancy of Data
Roll No 1784 1648 1768 1848 1682 1485 Name Rohit Shyam Kiran Maya Gopal Jinu Depart. Physics Chemistry Zoology Geology English Botany Year 1 1 2 2 3 4 Hostel Ganga Ganga Kaveri Kaveri Periyar Nila

Redundancy of Data
Roll No 1784 1648 1768 1848 Name Rohit Shyam Kiran Maya Depart. Physics Chemistry Zoology Geology English Botany Year 1 1 2 2 3 4 Hostel Ganga Ganga Kaveri Kaveri Periyar Nila

So there will be 1682 Gopal Insertion, Update 1485 Jinu & Delete Anomalies

THIRD NORMAL FORM (3NF)

*The

relation is in 3NF and all attributes in a relation schema are functionally dependent only on the key attribute.

3NF Relations
1. Student_dept (Roll No, Name, Dept., Year)
2. Hostel (Year, Hostel)

3NF
1. Student_dept (Roll No, Name, Depart., Year) 2. Hostel (Year, Hostel)

In 3NF we are eliminating nonkey attribute related functional dependence called Transitive Dependency

* Thank You