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