Relational Database

Design

COMPILED BY: RITURAJ JAIN

 The Banking Schema
„ branch = (branch_name, branch_city, assets)

„ customer = ((customer_id,
_ customer_name,
_ customer_street,
_

customer_city)

„ account = (account_number, balance)

„ depositor = (customer_id, account_number)

„ loan = (loan_number, amount)

„ borrower = (customer_id, loan_number)

 Pitfalls in Relational Database Design

„ Relational database design requires that we find a “good” collection of

relation schemas. A bad design may lead to

z Repetition of Information.

z Inability to represent certain information.

„ Design Goals:

z Avoid redundant data

z Ensure that relationships among attributes are represented

z Facilitate the checking of updates for violation of database

integrity constraints.
 Example
„ Consider the relation schema for loan:
Lending-schema = (branch-name, branch-city, assets,
customer-name, loan-number, amount)
B name
B_name B city
B_city assets Cust name
Cust_name L no
L_no Amount
Coll_Road Nadiad 9000000 Ajay L 21 21000
Coll_Road Nadiad 9000000 Suresh L 23 26500
C G Road
C.G. R d Ah d b d
Ahmedabad 2574000 Suresh
S h L 43 2300
Raj Marg Surat 2563000 Ajay L 100 74500
Raj Marg Surat 2563000 Rakshita L 45 100000

„ Redundancy:
z Data for branch-name, branch-city, assets are repeated for each loan that a
branch makes
z Wastes space
z Complicates updating, introducing possibility of inconsistency of assets value
„ Null values
z Cannot store information about a branch if no loans exist
z Can use null values, but they are difficult to handle.
 Goal — Devise a Theory for the Following

„ Decide whether a particular relation R is in “good” form.

„ In the case that a relation R is not in “good” form,

form decompose it into a
set of relations {R1, R2, ..., Rn} such that

z each
h relation
l ti iis iin good
d fform

z the decomposition is a lossless-join decomposition

 Decomposition
„ Decompose the relation schema Lending
Lending-schema
schema into:
Branch-schema = (branch-name, branch-city,assets)
B_name B_city assets Cust_name
Coll_Road Nadiad 9000000 Ajay
Coll_Road Nadiad 9000000 Suresh
C.G. Road Ahmedabad 2574000 Suresh
Raj Marg Surat 2563000 Ajay
Raj Marg Surat 2563000 Rakshita

Loan-info-schema
Loan info schema = (customer
(customer-name
name, loan-number
loan number,
branch-name, amount)
Cust_name L_no Amount
Ajay L 21 21000
Suresh L 23 26500
Suresh L 43 2300
Aj
Ajay L 100 74500
Rakshita L 45 100000
 Decomposition
„ Sometimes it is required to reconstruct loan relation from the Branch-schema
Branch schema
and Loan-info-schema: so we can do this by

Branch-schema
Branch schema Loan-info-schema
Loan info schema

B_name B_city assets Cust_name L_no Amount

Coll_Road Nadiad 9000000 Ajay L 21 21000
Coll_Road Nadiad 9000000 Ajay L 100 74500
Coll_Road Nadiad 9000000 Suresh L 23 26500
Coll_Road Nadiad 9000000 Suresh L 43 2300
C.G. Road Ahmedabad 2574000 Suresh L 23 26500
C.G. Road Ahmedabad 2574000 Suresh L 43 2300
Raj Marg Surat 2563000 Ajay L 21 21000
Raj Marg Surat 2563000 Ajay L 100 74500
Raj Marg Surat 2563000 Rakshita L 45 100000

„ Which customer are borrowers of from which branch? (lost information)

 Decomposition

„ In the last example we are not able to identify which customers are

borrower from which branch.

„ because of this loss of information

„ This type of decomposition is called lossy decomposition.

„ A decomposition that is not a lossy-join decomposition is called lossless

join decomposition.
decomposition

„ So lossy join decomposition is a bad database design

design..
 Decomposition

„ All attributes of an original schema (R) must appear in the decomposition

(R1, R2, R3, …… Rn):

R = R1 ∪ R2 ∪ R3 ..............∪ Rn

„ Lossless-join decomposition.

For all possible relations r on schema R

r = ∏R1 (r) ∏R2 (r) ∏R3 (r) ……….. ∏Rn (r)

What is Normalization?

Source: Infosys Campus Connect Study Material

 Need for Normalization
Student_Course_Result Table

• Data Duplication • Insert Anomaly

• Delete Anomaly • Update Anomaly
Source: Infosys Campus Connect Study Material
 Need for Normalization
• Duplication of Data – The same data is listed in multiple lines of the
database
• Insert Anomaly – A record about an entity cannot be inserted into the
table without first inserting information about another entity – Cannot enter a
student details without a course details
• Delete Anomaly – A record cannot be deleted without deleting a record
about
b t a related
l t d entity.
tit Cannot
C t delete
d l t a course details
d t il without
ith t deleting
d l ti allll off
the students’ information.
• Update Anomaly – Cannot update information without changing
information in many places. To update student information, it must be
updated for each course the student has placed
 Desirable Properties of Decomposition
1 We'll take another look at the schema
1.
Lending-schema = (B_name, assets, B_city, L_no, cust_name,amount)
which we saw was a bad design.
g

2. The set of functional dependencies we required to hold on this schema

was:
B_name → assets B_city
L_no
_ → amount B_name
_

3. If we decompose it into
Branch--schema = (B_name
Branch (B_name,, assets, B_city
B_city))
Loan--info
Loan info--schema = (B_name
(B_name,, L_no
L_no,, amount)
Borrow--schema = (cust
Borrow ((cust_name
cust
cust_name,
name, L_no)
L no)
L_no
no)
we claim this decomposition has several desirable properties.
 Desirable Properties of Decomposition

a) Lossless Decomposition

b) Dependency Preservation

c) Repetition of information
 Desirable Properties of Decomposition
a) Lossless Decomposition

How can we decide whether a decomposition is lossless?

„ Let R be a relation schema.

„ Let F be a set of functional dependencies on R.

„ Let R1 and R2 form a decomposition of R.

„ The decomposition
p is a lossless-join
j decomposition
p of R if at least

one of the following functional dependencies are in F+:

( ) R1 ∩ R2 → R1
(a)
(b) R1 ∩ R2 → R2
 Example
a) Lossless Decomposition
„ R = (A, B, C)

F = {{A → B, B → C))
z Can be decomposed in two different ways
„ R1 = (A, B), R2 = (B, C)

z Lossless-join decomposition:
R1 ∩ R2 = {B} and B → BC
z Dependency preserving
„ R1 = (A, B), R2 = (A, C)

z Lossless-join decomposition:
R1 ∩ R2 = {A} and A → AB
z Not dependency preserving
(cannot check B → C without computing R1 R2)
 Desirable Properties of Decomposition
a) Lossless Decomposition

Example:

„ First we decompose Lending-schema into Branch-schema and

Loan-info-schema

Lending-schema = (B_name, assets, B_city, L_no, cust_name,amount)

Branch-schema = (B_name, B_city, assets)

Loan-info-schema = (B_name, cust_name, L_no, amount)

B name Æ assets B_city,

„ B_name B city the augmentation rule for functional
dependencies implies that B_name → B_name assets B_city

„ Since Branch-schema ∩ Loan-info-schema = B name

B_name, our
decomposition is lossless join.
 Desirable Properties of Decomposition
a) Lossless Decomposition

Example Continue:

„ Next we decompose Loan-info-schema into Loan-schema and

Borrow-schema

Loan-info-schema = (B_name, cust_name, L_no, amount)

Loan-schema = (B_name, L_no, amount)

Borrow-schema = (cust_name, L_no)

„ As L_no
L no is the common attribute,
attribute and
L_no → L_no amount B_name

„ This is also a lossless-join decomposition

decomposition.
 Desirable Properties of Decomposition
b) Dependency Preservation

‰ Check that updates to the database do not result in illegal relations

‰ Better to check updates without having to compute natural joins.

‰ To know whether joins must be computed, we need to determine what

functional dependencies may be tested by checking each relation
individually.

‰ Let F be a set of functional dependencies on schema R. Let {R1,R2, . .

.,Rn} be a decomposition of R.

‰ The restriction of F to Ri is the set of all functional dependencies(

denoted as Fi) in F+ that include only attributes of Ri.
 Desirable Properties of Decomposition
b) Dependency Preservation

‰ F1,F2, . . .,Fn is the set of dependencies of decomposed relations.

‰ F’ = F1 U F2 U . . . U Fn

‰ When a relational schema R defined by functional dependency F is

decomposed into {R1,R2, . . .,Rn}, each functional dependency should be
testable by at least one of Ri.

‰Formally, let F+ be the closure F and let F’+ be the closure of

dependencies covered by Ri.

‰ F+ == F’+ for dependency preservation

preservation..
 Testing for Dependency Preservation
b) Dependency Preservation
compute F+
for each schema Ri in D do
begin
Fi := the restriction of F+ to Ri ;
end
F’ := φ
for each restriction Fi do
begin
F’ = F’ U Fi
end
compute F’+ ;
if ( F’+ = F+ ) then
th return
t (t )
(true)
else return (false);
 Testing for Dependency Preservation
b) Dependency Preservation

Lending-schema = (B_name, assets, B_city, L_no, cust_name,amount)

Decomposed into these schemas:

Branch--schema = ((B_name
Branch B_name,, assets, B_city
B_city))
Loan--info
Loan info--schema = ((B_name
B_name,, L_no,
L_no, amount)
B
Borrow
Borrow--schema
h = (cust_name
(cust_name,
t , L_no
L
L_no)
)

Decomposition of Lending-schema is dependency preserving.

B_name Æ assets B_city

L_no
L no Æ amount B_name
B name
 Desirable Properties of Decomposition
c) Repetition of Information

‰ Our decomposition does not suffer from the repetition of information

problem.
bl

‰ Branch and loan data are separated into distinct relations.

‰ Thus we do not have to repeat branch data for each loan.

‰ If a single loan is made to several customers, we do not have to repeat

the loan amount for each customer.

‰ This lack of redundancy is obviously desirable.

‰ We will see how this may be achieved through the use of normal
forms.
Functional dependency

Source: Infosys Campus Connect Study Material

Functional dependency

Source: Infosys Campus Connect Study Material

Functional dependency

Source: Infosys Campus Connect Study Material

Dependency Diagram

Source: Infosys Campus Connect Study Material

Full Dependency

Source: Infosys Campus Connect Study Material

Partial Dependency

Source: Infosys Campus Connect Study Material

Transitive Dependency

Source: Infosys Campus Connect Study Material

 First Normal Form
„ Domain is atomic if its elements are considered to be indivisible units

z Examples of non-atomic domains:

 Set of names, composite attributes

 Identification numbers like CS101 that can be broken up into parts

„ A relational schema R is in first normal form if the domains of all attributes of R

are atomic

„ Non-atomic values complicate storage and encourage redundant (repeated)

storage of data
First Normal Form (Cont’d)

Source: Infosys Campus Connect Study Material

 Example … Without Normalization
S
Student_Course_Result
C Table

Source: Infosys Campus Connect Study Material

 Source: Infosys Campus Connect Study Material
Table in 1NF Student_Course_Result Table
 First Normal Form Example

Course_Pref_Table
Course Pref
Dept Prof
Course Course dept
Course_dept
101 CS
Rajiv 102 CS
103 EC
CE 101 CS
102 CS
Mahesh
103 EC
104 EC
101 CS
CL Ruchika 103 EC
106 EE
103 EC
104 EC
IT Rajesh 106 EE
102 CS
105 EE
 First Normal Form Example
Course_Pref_Table
Course Pref Table
Dept Prof Course Course_dept
CE Rajiv 101 CS
CE Rajiv 102 CS
CE Rajiv 103 EC
CE Mahesh 101 CS
CE Mahesh 102 CS
CE Mahesh 103 EC
CE Mahesh 104 EC
CL Ruchika 101 CS
CL Ruchika 103 EC
CL Ruchika 106 EE
IT Rajesh 103 EC
IT Rajesh 104 EC
IT Rajesh 106 EE
IT Rajesh 102 CS
IT Rajesh 105 EE
Second normal form: 2NF

Source: Infosys Campus Connect Study Material

 Prime Vs Non
Non--Prime Attributes
• An attribute of a relation R that belongs to any key of R is said to be a prime attribute and that
which doesn’t is a non-prime attribute
Report(S# C#,
Report(S#, C# StudentName,
StudentName DateOfBirth,
DateOfBirth CourseName,
CourseName PreRequisite,
PreRequisite DurationInDays,
DurationInDays
DateOfExam, Marks, Grade)

Source: Infosys Campus Connect Study Material

Second normal form: 2NF

Source: Infosys Campus Connect Study Material

Second normal form: 2NF

Source: Infosys Campus Connect Study Material

Second normal form: Table in 2NF

Source: Infosys Campus Connect Study Material

Second normal form: Table in 2NF

Source: Infosys Campus Connect Study Material

 Second normal form … Example
Example: The following relation is in First Normal Form, but not Second
Normal Form: Cust_Order_table

OrderNo Customer ContactPerson Total

1 Acme Widgets John Doe $134.23

2 ABC Corporation Fred Flintstone $521.24

3 Acme Widgets John Doe $1042.42

4 Acme Widgets John Doe $928 53

$928.53

OrderNo Customer Æ Total

Customer Æ ContactPerson
 Second normal form … Example
Customer table
Customer ContactPerson Customer Æ ContactPerson
Acme Widgets John Doe
ABC Corporation Fred Flintstone

Order_table
OrderNo Customer Total
1 Acme Widgets $134.23
OrderNo Customer Æ Total
2 ABC Corporation $521.24

3 Acme Widgets $1042.42

4 A
Acme Wid
Widgets $928 3
$928.53
 Boyce--Codd Normal Form
Boyce
A relation schema R is in BCNF with respect to a set F of functional dependencies if
for all functional dependencies in F+ of the form
α→β
where α ⊆ R and β ⊆ R, at least one of the following holds:

„ α → β is trivial (i.e., β ⊆ α)

„ α is a superkey for R

Example schema not in BCNF:

bor loan = ( customer_id,

bor_loan customer id loan
loan_number,
number amount )

because loan_number → amount holds on bor_loan but loan_number is not a

superkey
 Decomposing a Schema into BCNF
„ Suppose we have a schema R and a non-trivial dependency α → β causes a

violation of BCNF.

We decompose R into:

• (α U β )
• (R-(β-α))
„ In our example,

z α = loan_number

z β = amount

and bor_loan is replaced by

z ((α U β ) = ( loan_number,, amount )

z ( R - ( β - α ) ) = ( customer_id, loan_number )
 Decomposing a Schema into BCNF
„ Lending-schema = (B_name, assets, B_city, L_no, cust_name,amount)

B_name Æ assets B_city (not trivial and B_name is not a super key)
L_no Æ amount B_name (not trivial and L_no is not a super key)

Candidate key for this Schema is { L_no, cust_name}. This Schema is not in
BCNF form. So decompose this schema into below given two schemas

Branch--schema = (B_name,
Branch B_name, B_city,
B_city, assets)

Loan--info
Loan info--schema = (B_name,
B_name, cust_name,
cust_name, L_no,
L_no, amount)

„ B_name Æ assets B_city, the augmentation rule for functional dependencies

implies that B_name → B_name assets B_city

„ B_name is super key in Branch_schema.

 Decomposing a Schema into BCNF
Loan--info
Loan info--schema = (B_name,
B_name, cust_name,
cust_name, L_no,
L_no, amount)

L_no Æ amount B_name (not trivial and L_no is not a super key)

„ This Schema is not in BCNF form. So decompose this schema into below
given two schemas

Loan--schema = ((B_name
Loan B_name,, L_no,
L_no, amount)

Borrow--schema = ((cust_name
Borrow cust_name,, L_no)
L_no)

„ Both of these two schemas are in BCNF.

„ Decomposition of Lending--schema
Lending to all these three schema
Branch--schema
Branch schema, Loan
Loan--schema and Borrow
Borrow--schema having dependency
preservation and lossless decomposition.
 BCNF and Dependency Loss…Example
„ banker
banker--schema = ( branch-
branch-name, customer
customer--name, banker
banker--name)

banker--name Æ branch
banker branch--name

branch--name customer-
branch customer-name Æ banker
banker--name

„ Banker-schema is not in BCNF -- Why?

„ banker-name is not a super key. So decompose banker-schema…..

banker--branch
banker branch--schema = (banker
(banker--name, branch
branch--name)

customer--banker
customer banker--schema = (customer
(customer--name, banker
banker--name)

„ New schema in BCNF but only one dependency is preserves

banker--name Æ branch
banker branch--name

„ While other dependency is not preserve.

 Testing for BCNF
non trivial dependency α →β causes a violation of BCNF
„ To check if a non-trivial
1. compute α+ (the attribute closure of α), and
2. verify that it includes all attributes of R, that is, it is a superkey of R.
„ Simplified test: To check if a relation schema R is in BCNF, it suffices to check
only the dependencies in the given set F for violation of BCNF, rather than
checking
g all dependencies
p in F+.
z If none of the dependencies in F causes a violation of BCNF, then none of
the dependencies in F+ will cause a violation of BCNF either.
„ However,
H using
i only
l F is
i i
incorrect
t when
h t ti
testing a relation
l ti i
in a
decomposition of R
z Consider R = (A, B, C, D, E), with F = { A → B, BC → D}
 Decompose R into R1 = (A,B) and R2 = (A,C,D, E)
 Neither of the dependencies in F contain only attributes from
(A,C,D,E) so we might be mislead into thinking R2 satisfies BCNF.
 In fact, dependency AC → D in F+ shows R2 is not in BCNF.
 Testing Decomposition for BCNF
„ To check if a relation Ri in a decomposition of R is in BCNF,

z Eith test
Either t t Ri for
f BCNF with
ith respectt to th restriction
t the t i ti off F (i.e.
(i Fi) to
t Ri (that
(th t

is, all FDs in F+ that contain only attributes from Ri)

 Third Normal Form
„ A relation schema R is in third normal form (3NF) if for all:

α → β in F+
at least one of the following holds:

z α → β is trivial (i
(i..e., β ∈ α)

z α is a superkey for R

z Each attribute A in (β – α) is contained in a candidate key for R.

(NOTE:: each attribute may be in a different candidate key)

(NOTE

„ If a relation is in BCNF it is in 3NF (since in BCNF one of the first two

conditions above must hold).

„ Third condition is a minimal relaxation of BCNF to ensure dependency

preservation.
ti
Third Normal Form

Source: Infosys Campus Connect Study Material

 Third Normal Form

Note that 3NF is concerned with transitive dependencies which do not involve

candidate
did t keys.
k A 3NF relation
l ti with
ith more than
th one candidate
did t key
k will
ill clearly
l l

have transitive dependencies of the form:

primary_key Æ other_candidate_key Æ any_non

any_non--key_column
Third Normal Form

Source: Infosys Campus Connect Study Material

Third Normal Form

Source: Infosys Campus Connect Study Material

 Third Normal Form: Motivation

„ There are some situations where

z BCNF is not dependency preserving,

preserving and

z efficient checking for FD violation on updates is important

„ Solution: define a weaker normal form,

form called Third Normal Form (3NF)

z Allows some redundancy (with resultant problems; we will see examples

later)

z But functional dependencies can be checked on individual relations without

computing
p g a jjoin.

z There is always a lossless-join, dependency-preserving decomposition into

3NF.
 Testing for 3NF
„ Optimization: Need to check only FDs in F, need not check all FDs in F+.

p y α → β, if α is a superkey.
„ Use attribute closure to check for each dependency p y

„ If α is not a superkey, we have to verify if each attribute in β is contained in a

candidate key of R
 3NF Decomposition Algorithm
Let Fc be a canonical cover for F;
i := 0;
for each functional dependency α → β in Fc do
if none of the schemas Rj, 1 ≤ j ≤ i contains α β
then begin
i := i + 1;
1
Ri := α β
end
if none of the schemas Rj, 1 ≤ j ≤ i contains a candidate key for R
then begin
i := i + 1;
Ri := any candidate key for R;
end
return (R1, R2, ..., Ri)
 3NF Decomposition Algorithm (Cont.)

„ Above algorithm ensures:

z each relation schema Ri is in 3NF

z decomposition is dependency preserving and lossless

lossless-join
join
 3NF Decomposition: An Example
„ Relation schema:

cust_banker_branch = (customer_id employee_id, branch_name,

customer_id,, employee_id, branch_name, type )
„ The
Th functional
f ti l dependencies
d d i ffor thi
this relation
l ti schema
h are:
1. customer_id,, employee_id → branch_name
customer_id branch_name,, type
2
2. employee id → branch_name
employee_id branch name
3. customer_id,, branch_name → employee_id
customer_id
„ We first compute
p a canonical cover
z branch_name is extraneous in the r.h.s. of the 1st dependency
z No other attribute is extraneous, so we get FC =
customer_id,, employee_id → type
customer_id
employee_id → branch_name
customer_id,, branch_name → employee_id
customer_id
 3NF Decompsition Example (Cont.)
„ The for loop generates following 3NF schema:
(customer_id
customer_id,, employee_id,
employee_id, type )
(employee_id
employee_id,, branch_name)
branch_name)
(customer_id
customer_id,, branch_name,
branch_name, employee_id)
employee_id)
z Observe that (customer_id, employee_id, type ) contains a candidate key of the
original schema, so no further relation schema needs be added
„ If the FDs were considered in a different order, with the 2nd one considered after the 3rd,
(employee_id, branch_name)
would not be included in the decomposition because it is a subset of
(customer_id, branch_name, employee_id)
„ Minor extension of the 3NF decomposition algorithm: at end of for loop, detect and delete
schemas such as (employee_id,
schemas, (employee id branch_name),
branch name) which are subsets of other schemas
z result will not depend on the order in which FDs are considered
„ The resultant simplified 3NF schema is:
(customer id employee_id,
(customer_id, employee id type)
(customer_id, branch_name, employee_id)
 Comparison of BCNF and 3NF
„ Relations
R l ti i BCNF and
in d 3NF
z Relations in BCNF: no repetition of information
z R l i
Relations i 3NF:
in 3NF problem
bl off repetition
i i off information
i f i
„ Decomposition in BCNF and in 3NF

z It is always possible to decompose a relation into relations in 3NF and

 the decomposition is lossless
 dependencies are preserved
z It is always possible to decompose a relation into relations in BCNF
and
d
 the decomposition is lossless
 May some of the dependencies are not preserved.
 Multivalued Dependencies (MVDs)

„ Functional dependencies rule out certain tuples from appearing in a relation.

If A B, then we cannot have two tuples with the same A value but different B

values.

„ Multivalued dependencies do not rule out the existence of certain tuples.

Instead,, theyy require

q that other tuples
p of a certain form be p
present in the

relation.

„ Every functional dependency is also a multivalued dependency

 Multivalued Dependencies (MVDs)

„ Let R be a relation schema and let α ⊆ R and β ⊆ R. The multivalued

dependency

α →→ β

holds on R if in anyy legal

g relation r(R),
( ), for all p
pairs for tuples
p t1 and t2 in r such
that t1[α] = t2 [α], there exist tuples t3 and t4 in r such that:

t1[α] = t2 [α] = t3 [α] = t4 [α]

t3[β] = t1 [β]
t3[R – β] = t2[R – β]
t4 [β] = t2[β]
t4[R – β] = t1[R – β]
 MVD (Cont.)

„ Tabular representation of α →→ β
 MVD (Cont.)

„ Trivial MVD

If MVD X ÆÆ Y is satisfied by all relations whose schemas include X and Y, it is

called
ll d trivial MVD X ÆÆY is
t i i l MVD. i trivial
t i i l whenever
h
Inference Rules for Computing D+
Inference Rules for Computing D+
 Use of Multivalued Dependencies

„ We use multivalued dependencies in two ways:

1. To test relations to determine whether they are legal under a given set of

functional and multivalued dependencies

2. To specify constraints on the set of legal relations. We shall thus concern

ourselves only with relations that satisfy a given set of functional and

multivalued dependencies.

„ If a relation r fails to satisfy a given multivalued dependency, we can construct a

relations r′ that does satisfy the multivalued dependency by adding tuples to r.

 Merits of Normalization
„ Normalization
N li ti is i based
b d on a mathematical
th ti l foundation.
f d ti

„ Removes the redundancy to a greater extent. After 3NF, data redundancy is

minimized to the extent of foreign keys.

keys

„ Removes the anomalies present in INSERTs, UPDATEs and DELETEs.

Demerits of Normalization
„ Data
D t retrieval
ti l or SELECT operation
ti performance
f will
ill be
b severely
l affected.
ff t d

„ Normalization might not always represent real world scenarios.

Source: Infosys Campus Connect Study Material
Source: Infosys Campus Connect Study Material
Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan