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

DBMS - Unit 3 (Relational Database Design)

Unit III covers the fundamentals of Relational Database Design, including the Relational Model, Codd's Rules, and various integrity constraints. It discusses the importance of normalization, decomposition, and functional dependencies in creating efficient database structures. The unit emphasizes the features of good relational design and the implications of poor design, alongside the processes of achieving different normal forms.

Uploaded by

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

DBMS - Unit 3 (Relational Database Design)

Unit III covers the fundamentals of Relational Database Design, including the Relational Model, Codd's Rules, and various integrity constraints. It discusses the importance of normalization, decomposition, and functional dependencies in creating efficient database structures. The unit emphasizes the features of good relational design and the implications of poor design, alongside the processes of achieving different normal forms.

Uploaded by

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

Unit III

Relational DataBase
Design
Unit III Contents

Relational Model: Basic concepts, Attributes and Domains,
CODD's Rules.

Relational Integrity: Domain, Referential Integrities,
Enterprise Constraints.

Database Design: Features of Good Relational Designs,
Normalization, Atomic Domains and First Normal Form,
Decomposition using Functional Dependencies, Algorithms
for Decomposition, 2NF, 3NF,BCNF.

CO Mapped : CO1, CO3

Dr. S.R.Khonde
Relational Model
The Relational model uses a collection of tables to
represent both data and the relationships among those data.
Tables are also known as relations.
Relation: made up of 2 parts:
Instance: a table, with rows and columns.
#rows =cardinality , #fields = degree / arity
Schema: specifies name of relation, plus name and type of
each column
E.g.: Students( sid: string, name: string, login: string,
age: integer, gpa: real)

Dr. S.R.Khonde
Relational Model Contd…

Dr. S.R.Khonde
Relational Model Contd…
Advantage:
Structural Independence
Its simple to navigate
Greater Flexibility
Better Security

Disadvantages
Performance
Data Complexity
Hardware and Software overhead
Physical Storage Consumption

Dr. S.R.Khonde
Components
 The relational model consists of three major components

 The set of relations and set of domains that defines the way
data can be represented (data structure)

 Integrity rules that define the procedure to protect the data


(data integrity)

 The operations that can be performed on data (data


manipulation)

Dr. S.R.Khonde
Codd's Rule
 Dr. Edgar Frank Codd was a computer scientist while
working for IBM he invented the relational model for
database management.

 Codd proposed thirteen rules (numbered zero to twelve) and


said that if a Database Management System meets these
rules, it can be called as a Relational Database Management
System.

 These rules are called as Codd's12 rules.

 Hardly any commercial product follows all.


Dr. S.R.Khonde
Codd's Rule Cont..
 Rule 0 : Foundation Rule

 Rule 1: Information Rule

 Rule 2: Guaranteed Access Rule

 Rule 3: Systematic Treatment of NULL Values

 Rule 4: Active Online Catalog

 Rule 5: Powerful and Well-Structured Language

 Rule 6: View Updating Rule


Dr. S.R.Khonde
Codd's Rule Cont..
 Rule 7: High-Level Insert, Update, and Delete Rule

 Rule 8: Physical Data Independence

 Rule 9: Logical Data Independence

 Rule 10: Integrity Independence

 Rule 11: Distribution Independence

 Rule 12: Non-Subversion Rule Dr. S.R.Khonde


Relational Integrity
 Integrity Constraint is a mechanism to prevent invalid
data entry into table to maintain the data consistency.

 Mainly used to provide security and consistency to the


database in various operations.

 Types of constraints
 Domain Integrity Constraint
 Entity Integrity Constraint
 Referential Integrity Constraint
 Enterprise Constraint
Dr. S.R.Khonde
Domain Integrity Constraint
 The domain constraint are considered as the most basic
form of integrity constraints.

 Domain integrity means it is the collection of valid set of


values for an attribute.

Constraints -
 Not Null
 Unique
 Default
 Check
Dr. S.R.Khonde
Entity Integrity Constraint
Primary Key Constraint –
 It uniquely identify each record in a table
 It does not allow NULL and duplicate values
 Combination of Not Null and Unique

A relation/table can have only one primary key, which


may consist of single or multiple fields. Dr. S.R.Khonde
Referential Integrity Constraint
Foreign Key
 A foreign key is an identifier in a table that matches the
primary key of a different table.

 The foreign key creates the relationship with a different


table, and referential integrity refers to the relationship
between these tables.

 It ensures the relationships between tables in a database


remain accurate by applying constraints to prevent users
or applications from entering inaccurate data or pointing
to data that doesn't exist.
Dr. S.R.Khonde
Referential Integrity Constraint
For referential integrity to hold in a relational database,
any column in a base table that is declared a foreign key can
contain either a null value, or only values from a parent
table's primary key.

Dr. S.R.Khonde
Enterprise Constraint
 It is also referred as Semantic Constraints.
 They are additional rules specified by users or database
administrators.
 These rules are depending upon the requirements and
constraints of the business for which the database system
is being maintained.

 eg. A class can have maximum 30 students


 eg. A teacher can teach maximum 2 subject a semester
 eg. A employee can work on max 5 projects at a time

Dr. S.R.Khonde
Relational Database Design
Basic elements of design process:

 Defining the problem or objective


 Researching the current database
 Designing the data structures
 Constructing database relationships
 Implementing rules and constraints
 Creating database views and reports
 Implementing the design

Dr. S.R.Khonde
Features of Good Relational Design
 Reduce redundancy
 Easy access to data
 More accuracy and integrity of information
 Data entry, updates and deletions should be efficient.

Bad Database design may lead to:


 Repetition of information
 Inability to represent certain information
 Consist of anomalies – Insertion, Deletion ,
Updation /Modification
Dr. S.R.Khonde
Anomalies
Emp_no Name Salary Branch_no Branch_add

105 Mohan 15,000 B001 Calcutta

108 Sohan 21,000 B001 Calcutta

109 Ruchika 29,000 B002 Delhi

115 Sourabh 18,000 B001 Calcutta

116 Mitalee 35,000 B002 Delhi

117 Ganesh 40,000 B003 Mumbai

Dr. S.R.Khonde
Normalization
 Normalization is a database design technique which is
used to organize the tables in such a manner that it should
reduce redundancy and dependency of data.
 It divides larger tables to smaller tables and links these
smaller tables using their relationships.

 Types of Normalization-
 First Normal Form (1NF)
 Second Normal Form (2NF)
 Third Normal Form (3NF)
 Boyce-Codd Normal Form (BCNF)
 Fourth Normal Form (4NF) Dr. S.R.Khonde
Decomposition
Definition -
The decomposition of a relation schema
R = {A1,A2,...,An}
is its replacement by a set of relation schemes
{R1, R2, ..., Rm}

such that
Ri⊆R for 1≤ i ≤ m
and R1 ∪ R2 ∪.... ∪ Rm = R

Dr. S.R.Khonde
Decomposition Example
R = { Emp_no, name, salary, branch_no, branch_add}

Decompose into

R1 = {Emp_no, name , salary}


R2 = {branch_no, branch_add}

Where R1⊆ R and R2⊆ R and R1∪ R2 = R

Dr. S.R.Khonde
Decomposition Example
STDINF ={Name,Course,Ph_No,Major,Prof,Grade}

Decompose

Student = {Name, Ph_No, Major}


Teacher = {Course, Prof }
Course = {Name, Course, Grade}

Dr. S.R.Khonde
Functional Dependency
 The attributes of a relation is said to be dependent on
each other when an attribute of a table uniquely
identifies another attribute of the same table. This is
called functional dependency.

 If attribute A of a relation uniquely identifies the


attribute B of same relation then it can represented as
A→ B
which means attribute B is functionally dependent on
attribute A.

Dr. S.R.Khonde
Functional Dependency
R = { Emp_no, name, salary, branch_no, branch_add}

Functional Dependencies – {emp_no → name, emp_no → salary,


emp_no → branch_no,
branch_no → branch_add}

R = {Name, Course, Ph_No, Major, Prof, Grade}

Functional Dependencies – {name → ph_no,


Name → major,
Course → prof,
Name,course → grade }
Dr. S.R.Khonde
Dependencies and Logical Implications
Consider
relation schema - R
Set of FDs – F
then any functional dependency
x→ y
is said to be logically implied from F if that
FD can be logically derived from FDs,
satisfied on relation schema R
F |= x→y

Dr. S.R.Khonde
Inference or Armstrong's Axioms
F1 : Reflexivity : x → x
F2 : Augmentation :
x → y |= xz → yz
F3 : Transitivity :
x → y and y → z |= x → z
F4 : Additivity :
x →y and x →z |= x → yz
F5 : Projectivity :
x → yz |= x → y and x → z
F6 : Pseudotransitivity :
x → y and yz → w |= xz → w
Dr. S.R.Khonde
Example
Eg – R=(A,B,C,D) and F = {A →B, A→C, BC→D}

Using additivity rule A →B and A→C will be


F |= A → BC

Using transitivity rule A → BC and BC → D will be


F |= A → D

Dr. S.R.Khonde
Closure of Functional Dependency
The set of functional dependencies and all logically implied
functional dependencies form a closure of F.
Denoted by F+

Eg – R=(A,B,C,D) and F = {A →B, A→C, BC→D}


F |= { A → BC , A → D}

F+ = { A →B, A→C, BC→D , A → BC , A → D }

Dr. S.R.Khonde
Closure of Attribute Set
It is a set of all attributes that are dependent on X and derived
using the FDs in F.
Denoted by X+

Algorithm to compute X+
X+ = X (where X is candidate key)
while (changes to X+ ) do
for each FD w → z in F do
begin
if w ⊆ X+ then
X+ = X+ ∪ z
end Dr. S.R.Khonde
Dependencies
Full Functional Dependency
Given a relation schema R and an FD x → y ,
y is fully functionally dependent on x
if there is no z,
where z is proper subset of x
such that z → y

Eg – F = { ab → c , b → c } where ab is CK
As c is depend on subset b
So c is not fully functionally dependent on ab
Dr. S.R.Khonde
Dependencies
Partial Dependency
Given an relation R with the functional dependencies F
defines on the attributes of R and
K as a candidate key,
if X is a proper subset of K and if F |= X → A ,
then A is said to be partially dependent on K.

Eg – F = { ab → c , b → c }
If ab is candidate key
Then as c is depend on subset b
So c is partially dependent on b
Dr. S.R.Khonde
Dependencies
Transitive Dependency

Given a relation schema R with Fds F


defines on the attributes X,Y, and A.
If the set of Fds contains X → Y and Y → A
then we can say that X → Y → A
so attribute A is transitively dependent on X.

Dr. S.R.Khonde
Example
R={ name, course, grade, ph_no, major, course_dept}

F = { course → course_dept
name → ph_no,
name → major,
name, course → grade }

Candidate Key – name,course

Find Full functional dependency and partial functional dependency?

Dr. S.R.Khonde
First Normal Form (1NF)
A relation is in First Normal Form if and only if the
domain of each attribute contains only atomic (indivisible)
values, and the value of each attribute contains only a
single value from that domain.

OR

An attribute (column) of a table cannot hold
multiple values.

It should hold only atomic values.

Dr. S.R.Khonde
First Normal Form (1NF)
Example: Suppose a company wants to store the names and contact
details of its employees.
emp_id emp_name emp_address emp_mobile

101 Herschel New Delhi 8912312390

102 Jon Kanpur 8812121212


9900012222

103 Ron Chennai 7778881212

104 Lester Bangalore 9990000123


8123450987

This table is not in 1NF as the rule says “each attribute of a table must have atomic
(single) values”, the emp_mobile values for employees Jon & Lester violates that rule.
Dr. S.R.Khonde
First Normal Form (1NF)
emp_id emp_name emp_address emp_mobile

101 Herschel New Delhi 8912312390

102 Jon Kanpur 8812121212

102 Jon Kanpur 9900012222

103 Ron Chennai 7778881212

104 Lester Bangalore 9990000123

104 Lester Bangalore 8123450987


Note: Using the First Normal Form, data redundancy increases, as there will be many columns
with same data in multiple rows but each row as a whole will be unique. Dr. S.R.Khonde
Second Normal Form (2NF)

A table is said to be in 2NF if the following conditions


hold:
 Table is in 1NF (First normal form)
 No Partial Dependency
 Every non-prime attribute should be functionally
dependent on prime attribute.

An attribute that is not part of any candidate key is known


as non-prime attribute.

Dr. S.R.Khonde
Second Normal Form (2NF) Cont..
Consider relation
R = {stu_name, course, ph_no, dept, grade }

F = { stu_name,course → grade,
stu_name → ph_no,
stu_name → dept }

Primary Key – stu_name,course

Is above relation in 2NF?


Dr. S.R.Khonde
Second Normal Form (2NF) Cont..
R = {stu_name, course, ph_no, dept, grade }

Decompose using functional dependencies


such that all functional dependencies preserve.

R1 = {stu_name, ph_no, dept }


R2 = {stu_name, course, grade }

Dr. S.R.Khonde
Second Normal Form (2NF) Cont..
R={manufacturer,Model,Model_name, Manu_country}

F = {manufacturer,model → model_name,
manufacturer → manu_country }

Key = {manufacturer,model}
Is in 2NF?
Decompose -

R1 = {manufacturer, model, model_name}


R2 = {manufacturer, manu_country}
Dr. S.R.Khonde
Third Normal Form (3NF)
For a relation to be in Third Normal Form, it must satisfy
following conditions :

 It should be in Second Normal form


 No non-prime attribute is transitively dependent on prime
key attribute (no transitive dependency)

Dr. S.R.Khonde
Third Normal Form (3NF) Cont..
R = {emp_id,emp_name,emp_zip,emp_city}
Key = {emp_id}
F = {emp_id → emp_name ,
emp_id → emp_zip,
emp_zip → emp_city }

Is the relation in 3NF ?


No, because of transitive dependency
emp_id → emp_zip → emp_city

Dr. S.R.Khonde
Third Normal Form (3NF) Cont..
R = {emp_id,emp_name,emp_zip,emp_city}

Decompose using functional dependency

R1 = {emp_id,emp_name,emp_zip}
R2 = {emp_zip, emp_city}

Dr. S.R.Khonde
Third Normal Form (3NF) Cont..
Example -
R = {course,prof,room,room_cap,enroll_limit}
Key = {course}
F = { course → prof,
course → room,
course → enroll_limit,
room → room_cap,
room → enroll_limit }

Is above relation in 3NF?


Dr. S.R.Khonde
Boyce Code Normal Form (BCNF)
BCNF is an extension of Third Normal Form on strict terms.
BCNF states that :

 The relation should be in 3NF


 For any functional dependency, X → A, X must be a super-
key.

Dr. S.R.Khonde
Boyce Code Normal Form (BCNF)
R = {emp_id,emp_dept, nationality, dept_type, dept_no }
Key = {emp_id}
F = { emp_id → emp_dept,
emp_id → nationality,
emp_dept →dept_type,
emp_dept → dept_no }

Is the relation in BCNF?


R1 = {emp_id, emp_dept,nationality}
R2 = {emp_dept, dept_type, dept_no}

Dr. S.R.Khonde
Boyce Code Normal Form (BCNF)
Example
R = { author, nationality, book_title, category, no_of_pages}
Key = {author}
F = {author →nationality,
Author → book_title,
book_title → category,
book_title → no_of_pages }

Is the above relation in BCNF?

Dr. S.R.Khonde
Decomposition Algorithm
These are two important properties associated with
decomposition.


Lossless Join

Dependency Preservation

Dr. S.R.Khonde
Decomposition Algorithm
Lossless Join -
A decomposition of a relation R into schemes Ri (1 ≤ i ≤n)
is said to be a lossless join decomposition or simply
lossless if for every relation (R) the natural join of the
projections of R gives the original relation R; i.e.,

R = R1 ⋈ R2 ⋈ ... ⋈ Rn

If R ⊆ R1 ⋈ R2 ⋈ ... ⋈ Rn then the decomposition is called


lossy.

Dr. S.R.Khonde
Decomposition Algorithm
Example: R
Model Price Category
Name
a11 100 Canon
s20 200 Nikon
a70 150 Canon

Model Category Price Category


Name
100 Canon
a11 Canon
200 Nikon
s20 Nikon
a70 Canon 150 Canon

Dr. S.R.Khonde
Decomposition Algorithm
R1 ⋈ R2 Model Price Category
Name
a11 100 Canon
a11 150 Canon
s20 200 Nikon
a70 100 Canon
a70 150 Canon

Model Price Category


R Name
a11 100 Canon
s20 200 Nikon
a70 150 Canon
Dr. S.R.Khonde
Decomposition Algorithm
Dependency Preserving
Given a relation R where F is a set of functional dependencies, R is
decompose into the relations R1,R2,...,Rn
with the functional dependencies
F1,F2,...,Fn

Then this decomposition of R is dependency preserving if the closure


of F1∪ F2 ∪ ... ∪ Fn is identical to F+

Dr. S.R.Khonde
Decomposition Theorem
A decomposition of relation R<(x,y,z),F> into R1<(x,y),F1>
and R2 <(x,z),F2> is:

a) dependency preserving if every functional dependency in


R can be logically derives from the functional
dependencies of R1 and R2 i.e. (F1 ∪ F2)+ = F+

b) is lossless if the common attribute x of R1 and R2 form a


key of at least one of these i.e. x →y or x→ z

Dr. S.R.Khonde
Decomposition Theorem
Example -
Let R(a,b,c) and F = {a→b }

Check weather above relation is lossless and dependency


preserving if decompose as

R1 (a,b) and R2 (a,c)

Dr. S.R.Khonde
END OF UNIT III

You might also like