DBDM Unit-3
DBDM Unit-3
Two Marks
1
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
The closure set of all functional dependency can be computed using basic
three rules which are also called as Armstrong's Axioms
4.Define normalization.
2
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
2) data dependencies are logical (all related data items are stored
together)
All the insertion, deletion and update anomalies are in INF relation.
3
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Or in other words
In other words 3NF can be defined as: A table is in 3NF if it is in 2NF and
for each functional dependency
X Y
4
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Boyce and Codd Normal Form is a higher version of the Third Normal
form.
A 3NF table which does not have multiple overlapping candidate keys is
said to be in BCNF.
When the table is in BCNF then it doesn't have partial functional
dependency as well as transitive dependency.
Hence it is true that if relation is in BCNF then it is also in 3NF.
There are two properties associated with decomposition and those are-
3 3NF can be obtained without sacrificing all Dependencies may not be preserved
dependencies. BCNF.
5 3NF can be achieved without loosing any For obtaining BCNF we may loose
information from the old table. some information from old table.
6
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
The SQL statement captures the information for above ER diageam as follows-
7
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
The SQL statement captures the information for relationship present in above
ER diagram as follows-
If a relationship set involves n entity sets and some m of them are linked
via arrows in the ER diagram, the key for anyone of these m entity sets
constitutes a key for the relation to which the relationship set is mapped.
Hence we have m candidate keys, and one of these should be designated
as the primary key.
There are two approaches used to convert a relationship sets with key
constraints into table.
Approach 1:
8
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
By this approach the relationship associated with more than one entities
is separately represented using a table. For example - Consider following
ER diagram. Each Dept has at most one manager, according to the key
constraint on Manages.
Here the constraint is each department has at the most one manager to manage
it Hence no two tuples can have same DeptID. Hence there can be a separate
table named Manages with DeptID as Primary Key. The table can be defined
using following SQL statement
Approach 2:
o The idea is to include the information about the relationship set in the
table corresponding to the entity set with the key, taking advantage of the
key constraint.
o This approach eliminates the need for a separate Manages relation, and
queries asking for a department's manager can be answered without
combining information from two relations.
o The only drawback to this approach is that space could be wasted if several
departments have no managers.
9
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
A weak entity can be identified uniquely only by considering the primary key of
der (owner) entity. Following steps are used for mapping Weka Entity Set to
Relational Mapping
10
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Method 1: All the entities in the relationship are mapped to individual tables
InventoryItem(ID, name)
Book(ID Publisher)
DVD(ID, Manufacturer)
Method 2: Only subclasses are mapped to tables. The attributes in the superdas
are duplicated in all subclasses. For example-
This method will introduce null values. When we insert a Book record in the
table the Manufacturer column value will be null. In the same way, when we
insert a DVD record in the table, the Publisher value will be null.
11
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Example
Redundancy
1) Redundant storage: Note that the information about DeptID, DeptName and
Deptloc is repeated.
12
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
2) Update anomalies:
In above table if we change DeptLoc of Pune to Chenna then
it will result inconsistency as for DeptID 101 the DeptLoc is
Pune. G otherwise, we need to update multiple copies of
DeptLoc from Pune to Chennai Hence this is an update
anomaly.
3) Insertion anomalies:
For above table if we want to add new tuple say (5,
EEE,50000) for DeptID 101 then it will cause repeated
information of (101, XYZ, Pune) will occur.
4) Deletion anomalies:
For above table, if we delete a record for EmpID 4, then
automatically information about the DeptID 102, DeptName
PQR and Deptloc Mumbai will get deleted and one may not be
aware about DeptID 102. This causes deletion anomaly.
--------------------------------------------------------------------------------------------------------
3.Discuss about Functional Dependencies with an example
Definition:
A functional dependency A->B in a relation holds if two tuples
having same value of attribute A also have the same value for
attribute B. It is denoted by A>B where A is called determinant and
B is called dependent.
Here
Roll->Name hold
But
Name->City does not hold
13
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Another example-
Consider a relation in which the roll of the student and his/her name is
stored as follows:
R N
1 AAA
2 BBB
3 CCC
4 DDD
5 EEE
Table which holds functional dependency i.e. R->N
Here, R->N is true. That means the functional dependency holds true here.
Because for every assigned RollNuumber of student there will be unique name.
For instance: The name of the Student whose RollNo is 1 is AAA. But if we get
two different names for the same roll number then that means the table does not
hold the functional dependency. Following is such table –
R N
1 AAA
2 BBB
3 CCC
1 XXX
2 YYY
Table which does not holds functional dependency
In above table for RollNumber 1 we are getting two different names - "AAA" and
"XXX". Hence here it does not hold the functional dependency.
Trivial FD:
The functional dependency A>B is trivial if B is a subset of A.
For example {A,B}->A
14
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Example
For the given below relation R(A,B,C,D,E) and its instance, check whether FDs
given hold or not. Give reasons.
A B C D E
a1 b1 c1 d1 e1
a1 b2 c1 d1 e1
a2 b2 c1 d2 e3
a2 b3 c3 d2 e2
For example,
i. The FD A>B does not hold because al has two different values bl and b2.
Similarly, a2 has two different values and those are b2 and b3.
ii. The FD B->C holds true.
iii. D->E does not hold true because d2 gives two different values e3 and e2.
iv. CD->E hold true as (cl,d1) gives el, (cl,d2) gives e3 and (c3,d2) gives e2. All
are uniquely identified.
15
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
The closure set of all functional dependency can be computed using basic
three rules which are also called as Armstrong's
Let us understand how to apply Armstrong's axioms for finding the closure
of set of functional dependencies-
Example -1
Solution:
Step1:
A gives A attribute itself by reflexivity. It is called trivial production.
A B and AC, Hence by union rule A BC
AB and B E, Hence by transitivity rule A E
(A)+={A,B,C,E}
16
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
(CD)+= {C,D,E,F}
Example -2
Step 2: As
Step 3:
Step 4:
CDE (given)
A E (transitive rule as ACD,
CDE hence AE)
Step 5:
Step 6:
17
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Step 7:
Step 8:
Step 9:
Thus any functional dependency with A, E, BC, or CD on the left hand side
of the arrow is in F+
Example-3
Give Armstrong's axioms and using it find the closure of following FD set
AB, ABC, DAC, DE
Solution
Step 1:
Consider the rules DAC and DE
D →ACE (Union rule)
18
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
19
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
20
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
21
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Before understanding the third normal form let us first discuss the concept of
dependency, super key and candidate key
Concept of Transitive Dependency
A functional dependency is said to be transitive if it is indirectly formed by two
functional dependencies.For exampe
XY
YZ
Superkeys
{RegID}
{RegID, RollNo}
{RegID Sname}
{RollNo Sname}
Candidate Keys
22
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
{RegID}
{RollNo}
Or in other words
In other words 3NF can be defined as: A table is in 3NF if it is in 2NF and for
each functional dependency
X Y
Here
Super keys: {sid}, {sid, sname}, {sid,sname, zipcode}, (sid, zipcode,cityname)...
and so on.
Candidate keys: (sid)
Non-Prime attributes: (sname, zipcode,cityname,state)
The dependencies can be denoted as
sidsname
sidzipcode
zipcodecityname
citynamestate
The above denotes the transitive dependency. Hence above table is not in 3NF.
We- can convert it into 3NF as follows:
23
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Student
Boyce and Codd Normal Form is a higher version of the Third Normal form.
This form deals with certain type of anomaly that is not handled by 3NF.
A 3NF table which does not have multiple overlapping candidate keys is said
to be in BCNF.
Or in other words,
24
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Enrollment Table
One student can enroll for multiple courses. For example, student with
sid=1 can enroll for C as well as Java.
There can be multiple teachers teaching one course for example course C
can be taught by both the teachers namely - Ankita and Archana.
The candidate key for above table can be (sid, course), because using
these two columns we can find
o (sid,course)->Teacher
o Teacher->course
To convert the above table to BCNF we must decompose above table into
Student and Course tables
25
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
sid Teacher
1 Arun
1 Ankita
2 Arun
3 Supriya
4 Archana
Teacher course
Arun C
Ankita Java
Arun C
Supriya C++
Archana C
26
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Decomposition is the process of breaking down one table into multiple tables.
We can decompose the above relation Schema into two relation schemas as
Employee (Eid, Ename, Age, City, Salary) and Department (Deptid, Eid,
DeptName) as follows
27
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Department Table
Debtid Eid Depname
28
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
Hence, the above table can be decomposed into two schema S and T as follow
Schema S
Name eid deptname Grade
Schema T
Grade Salary
2 8000
3 7000
4 7000
2 8000
There are two properties associated with decomposition and those are-
1) Loss-less join or non-loss decomposition:
29
B.Tech – AIDS II year/III Sem AD3391 DBDM –Unit-III
2) Dependency preservation:
Lossless Join
30