DBMS Helping material

Assignment no 3: Database Management System 2020
0 | P a g e
Government Post Graduate College Mandian Abbottabad
Assignment no 3
Submitted by:
Name: Zarlish Attique
Registration no: 187104
Subject: Database Management System
Department: Bioinformatics
Semester: 5th
Submitted to:
Teacher Name: Sir Ibrar Hussain
Department of Bioinformatics
Date of Submission: December 30,2020

1 | P a g e
ASSIGNMENT TOPIC
Q.1. Let a relation name TEACHER
having attributes T_Name, Gender, DOB, Sub_Handles, Schol_Name, and Schol_Location. Suppose the
table is in 1NF.
Answer the following questions shortly in bullets.10
a. If (T_Name, DOB) is key of TEACHER, is TEACHER IS 2NF?
b. If T_Name is key of TEACHER, is TEACHER in 2NF?
c. (T_Name, DOB) is key of TEACHER, all the attributes depend on the whole key, and only other FD
is "Schol_Name determines the Schol_Location uniquely". Is TEACHER in 2NF?
d. (T_Name, DOB) is key for TEACHER, all the attributes depends on the whole key, and only other FD
is "Schol_Name determines the Schol_Location uniquely". What is your opinion TEACHER is in 3NF?
e. T_Name is the key. If T_Name is the key for TEACHER, is TEACHER in 3NF?
Q.2. R(A, B, C, D, E) having FD's AB → C, CD → E, C → A, C → D, D → B.
The possible candidate keys for R are AB, AD, C
(a) write FD’s that violate 3NF. If any, then decompose Relation accordingly.
(b) Write FD's that violate BCNF. If any, then decompose R accordingly.10
Q.3 R(A, B, C, D) with FD's AB → C, AC → B, BC → A, B → D.
Determine all the keys of relation R. What is your opinion about the relation R is in BCNF explain?10
NQ.4. Make a distinct scenario of un-normalized table except given in lecture slides, show their
functional dependencies and different types of anomalies in it.20

2 | P a g e
Question no 1:
Let relation name TEACHER having attributes T_Name, Gender, DOB, Sub_Handles, Schol_Name,
and Schol_Location. Suppose the table is in 1NF.
Answer the following questions shortly in bullets.10
a. If (T_Name, DOB) is key of TEACHER, is TEACHER IS 2NF?
As it is defined that the relation TEACHER is in 1NF so first condition of the definition of 2NF is
executed by it. Let us test is it execute the second condition or not i.e there is no partial dependency
means all the nonkey attributes are fully functionally dependent on the key.
Situation 1: “The only time we have to concerned about 2NF is when the key is composite”
(Reference: as mention in the notes Lecture 8: Normalization). Here the key is composite that is it
is combination of two attributes Teacher_Name, DOB and 2NF addresses to removing duplicative
data. So, in this case it’s not in 2NF.
Situation 2: As partial functional dependency occurs only in relation with there are composite
keys. Or we can say there is more probability of partial dependency when there is composite key.
So, in this case may (when no partial dependency) or may not (when partial dependency) be in
2NF.
Note and Alarm: There is a redundancy issue that is redundancy anomaly due to the composite
keys. This information in Teacher_Name, DOB being duplicated and leads to redundancy.
b. If T_Name is key of TEACHER, is TEACHER in 2NF?
Because of the statement: “Clearly if a relation in 1NF and a key consist of single attribute
the relation is automatically in 2NF” (Reference: as mention in the notes Lecture 8:
Normalization). And here the T_Name is only the key that is mentioned and consist of single
attribute. So, Yes TEACHER is in 2NF.
Secondly from definition we can also validate it: First condition is it should be in 1NF as it is
mentioned. Second, for only single attribute (key) there is always full functional dependency. So,
here both the conditions fulfilled. So, we can say that the relation TEACHER is in 2NF.

3 | P a g e
c. (T_Name, DOB) is key of TEACHER, all the attributes depend on the whole key, and only other
Is TEACHER in 2NF?
Given scenario:
1. Key: T_Name, DOB and all attributes depends on whole key.
2. Also, FD is Schol_Name determines the Schol_Location uniquely.
Now in scenario one there is no partial dependency as mentioned that all attributes depend on
whole key (here statement remove all the confusion of composite key as it is not given in case
of part a of the question 1). Now we can say that yes, the relation TEACHER is in 2NF as
they fulfil both the requirements of the definition i.e., first it should be in 1NF, second of full
functional dependency.
Now in scenario two we have FD is Schol_Name determines the Schol_Location uniquely. As
here also determinant Schol_Name determines the dependent Schol_Location uniquely so we
can also say that there’s no partial dependency in it as well.
Conclusion: So, from above discussion it is concluded that the relation TEACHER is in second
normal form.
d. (T_Name, DOB) is key for TEACHER, all the attributes depends on the whole key, and only
other FD is "Schol_Name determines the Schol_Location uniquely". What is your opinion
TEACHER is in 3NF?
A relational table is in third normal form (3NF) if it is already in 2NF and every non-key column is non-
transitively dependent upon its primary key means all non-key attributes are functionally dependent only
upon the primary key. (Reference: as mention in the notes Lecture 8: Normalization).
Transitive dependency occurs when one non-key attribute determines another non-key attribute.
For third normal form we concentrate to eliminate transitive dependencies.
And here a non-key attribute Schol_Name determines the non-key attribute Schol_Location. So in
this case we can say that because of this transitive dependency the relation TEACHER is not in
3NF.

4 | P a g e
e. T_Name is the key. If T_Name is the key for TEACHER, is TEACHER in 3NF?
As the input to the normalization is always two things first a relation or Table or logical database
and second functional dependencies that is FDs, here only one key is given i.e T_Name.
So for 3NF the table should be in 2NF and there’s no transitivity dependency so here we can’t
check that concept because FDs are not mentioned.
There is one possibility that if we check it that is it in BCNF directly then it will be 100% in 3NF.
But for that also FDs are required that are not given or mentioned. But, as it has here only one key
if it is candidate key as well as it is primary key so we can say its BCNF and it is 100% in 3NF.
(Reference Lecture 20 DBMS)

5 | P a g e
Question no 2
R (A, B, C, D, E) having FD's AB → C, CD → E, C → A, C → D, D → B.
The possible candidate keys for R are AB, AD, C
(b) Write FD's that violate BCNF. If any, then decompose R accordingly.10
A relational table is in third normal form (3NF) if it is already in 2NF and every non-key column is
non-transitively dependent upon its primary key.
Step 1: Checkout for statement one i.e., first it should be in second normal form.
(2NF) if and only if it is in first normal form and all the non-key attributes (here E) are fully functionally
dependent on the key (A, B, C, D, E).
As input to the normalization is Logical data and FDs so (A, B, C, D, E) having FD's AB → C, CD → E,
C → A, C → D, D → B
For 2NF: There should be no partial dependency in the relation i.e here in the above table there is no
partial dependency i.e., here primary attributes are A, B, C, and D and, E depends upon on these attributes
it is non-key attribute here. So, first requirement is fulfilled.
Step 2: Checkout for statement two i.e., no transitive dependency.
Now checkout for second requirement, that there should be no transitive dependency means non-prime
attribute donot depend upon non-key attribute. So, here from FDs we can check
AB, AD and C are candidate keys
AB → C here, AB determine C no transitivity found.
CD → E here, CD determine E here also no transitivity found.
C → A here, C determine A here also no transitivity found.
C → D here, C determine D here also no transitivity found.
D → B here, D determine B: it means C determine B by transitivity rule. So, here also no
transitivity found.

6 | P a g e
Here E is only the non-key attribute as given determined by CD. Here C and D are key attributes which
determines E i.e dependent. So in all above cases there’s no transitive dependency found. So it fulfills the
second requirement as well so it is in 3NF and no FD violates the 3NF.
Conclusion: There is no FD that violates the third normal form for the given table and also for the given
conditions.
(b) Write FD's that violate BCNF. If any, then decompose R accordingly.
A relation is in Boyce-Codd normal form if and only if every determinant is a candidate key.
(Reference lecture 8: Normalization)
As given possible candidate keys for R are AB, AD, C
AB → C here, AB determine C
CD → E here, CD determine E
C → A here, C determine A
C → D here, C determine D
D → B here, D determine B: it means C determine B by transitivity rule.
As in part a, we concluded that the relation is in third normal form due to no transitivity but here the
relation will be in BCNF if determinant is a candidate key and candidate keys are given. So here.
Situation Arises
1. D → B is the functional dependency that violates the rule, here D is not a candidate key itself by
transitivity rule we can say that C determines B but here in BCNF we have to eliminate all these
concepts for consistency of the database.
Then decompose R accordingly.
Here the table is in 3NF but not in BCNF because of 5th FD i.e., D → B due to inference rule of
transitivity, it generates a new candidate key so, here we break the R.
R (A, B, C, D, E) as
ROLD (A, C, D, E) and RNEW (B, D)
Here the non-key attribute determining the part of the candidate key.So, from here we can make two tables
by decomposition of the relation in which D non-key attribute will be there and B will be there as it is
determined by D.

7 | P a g e
Question no 3
Q.3 R(A, B, C, D) with FD's AB → C, AC → B, BC → A, B → D.
Determine all the keys of relation R. What is your opinion about the relation R is in BCNF explain?10
DETERMINE ALL THE KEYS OF RELATION R OPINION ABOUT THE RELATION R IS IN
BCNF EXPLAIN
Given relation and Functional Dependencies (FDs)
R (A, B, C, D) with FD's AB → C, AC → B, BC → A, B → D.
Check the first Functional dependency: Taking closure of the determinant AB.
(AB)+
=ABCD
Here, AB determined itself through reflexive property. Then AB can determine C and B can determine D.
So, as AB determine all the attributes in R so it can be a candidate key because it uniquely identifies the
attributes.
Check the second Functional dependency: Taking closure of the determinant AC.
(AC)+
=ACBD
Here, AC determined itself through reflexive property. Then AC can determine B and B can determine D.
So, as AC also determine all the attributes in R so it can be a candidate key because it uniquely identifies
the attributes.
Check the third Functional dependency: Taking closure of the determinant BC.
(BC)+
=BCDA
Here, BC determined itself through reflexive property. Then BC can determine A and B can determine D.
So, as BC also determine all the attributes in R so it can be a candidate key because it uniquely identifies
the attributes.
Check the fourth Functional dependency: Taking closure of the determinant B.
(B)+
=BDCA
Here, B determined itself through reflexive property. Then B can determine C and BC can determine A.

8 | P a g e
So, as B also determine all the attributes in R so it can be a candidate key because it uniquely identifies
the attributes.
Note: But here in B as candidate key here it act as a composite key with others that’s how we can determine
its R with dependents.
Candidate key set= {AB, AC, BC, B}
Primary key – One of the candidate key chosen as primary key by database designer.
Super key -- A set of attributes that uniquely identifies a tuple within R.
Conclusion-- From the above discussion it is concluded that the given relation is in BCNF as “A relation
is in Boyce-Codd normal form if and only if every determinant is a candidate key” (Reference lecture
slides: Normalization). So here every determinant is a candidate key. So, we can say that the given relation
R (A, B, C, D) with FD's AB → C, AC → B, BC → A, B → D are in Boyce-Codd normal form.

9 | P a g e
Question no 4
Make a distinct scenario of un-normalized table except given in lecture slides, show their functional
dependencies and different types of anomalies in it.20
Declaration: Font size of the table is so small because tables was made in the PowerPoint and then the JPEG is inserted over here.
A DISTINCT SCENARIO OF UN-NORMALIZED TABLE
Unnormalized form (UNF), also known as an unnormalized relation or non-first normal form (NF2
), is a
simple database data model (organization of data in a database) lacking the efficiency of database
normalization. An unnormalized data models will suffer from data redundancy errors, where multiple
values and / or complex data structures can be stored in a single field or attribute, or where fields can
be duplicated within a single table. And can depend on many types of bugs that causes inconsistency of
the database. (Definition Reference: https://en.wikipedia.org/wiki/Unnormalized_form)
In the following scenario the un-normalized relation with normalization process has been
discussed.
The RELATION WEEKLYRECIEPT an unnormalized relation thoroughly explains the stages of
the normalization process that how the unnormalized data model can be processed to remove all
the inconsistencies. The approach adopted for the normalization is analysis approach, whereby a
single large table i.e WEEKLYRECIEPT is assumed involving all the attributes required in the
system.
Attributes required for WEEKLYRECIEPT are Request_ID, Request_Day, Client_ID,
Client_Name, Client_Address, Item_ID, Item_Statement, Item_Completion, Rate_per_Unit,
Request_Quantity.
Later, the table is decomposed into smaller tables by considering the FDs existing in the system.
So, the example also explains the transforming of real-world scenarios into FDs.
Table:Unnormalized table: WEEKLYRECIEPT(Request_ID, Request_Day, Client_ID, Client_Name, Client_Address,
Item_ID, Item_Statement, Item_Completion, Rate_per_Unit, Request_Quantity)

10 | P a g e
THE FUNCTIONAL DEPENDENCIES IN THE SYSTEM
Functional Dependency (FD) is a constraint that determines the relation of one attribute to another
attribute in a Database Management System. Functional Dependency helps to maintain the quality of
data in the database. It plays a vital role to find the difference between good and bad database design.
List of The Functional Dependencies In The System
A functional dependency is denoted by an arrow "→". The functional dependency of X on Y is represented
by X → Y.
Here: X represents the Right-Hand Side and Y represents the Left-Hand Side.
One Right hand side determinant is present while on Left hand side dependent is present.
First Functional dependency in WEEKLYRECIEPT:
Request_ID Request_Day, Client_ID, Client_Name, Client_Address.
Here in the first FD from Request_ID we can determine or functionally determine the values of
Request_Day, Client_ID, Client_Name, and Client_ Address.
Second Functional dependency in WEEKLYRECIEPT:
Item_ID Item_Statement, Item_Completion, Rate_per_unit.
In the second FD from Item_ID we can determine or functionally determine the values of Item_Statement,
Item_Completion and Rate_per_unit.
Third Functional dependency in WEEKLYRECIEPT:
Client_ID Client_Name, Client_ Address.
In the third FD from Client_ID we can determine or functionally determine the values of Client_Name,
and Client _Address.
Fourth Functional dependency in WEEKLYRECIEPT:
Request_ID, Item_ID Request_Quantiy.

11 | P a g e
In the fourth FD from Request_ID, Item_ID we can determine or functionally determine the value of
Request_Quantiy.
Figure: Pictorial representation of all the functional dependencies in the relation i.e Full Functional Dependencies,
Partial dependencies and Transitive dependencies.
Full Functional Dependencies
This means that it meets the requirements of First Normal Form (1NF), and all non-key attributes
are fully functionally dependent on the primary key.
Here in WEEKLYRECIEPT all the non-key attributes Request_Day, Client_ID, Client_Name,
Client_Address, Item_Statement, Item_Completion, Rate_per_Unit and Request_Quantity are
fully functional dependent on primary keys Request_ID and Item_ID. As shown in the figure.
Partial Dependencies
Partial dependency means that a nonprime attribute is functionally dependent on part of a candidate
key. (A nonprime attribute is an attribute that's not part of any candidate key.)
Here nonprime attribute Request_Day, Client_ID, Client_Name, Client _Address are functionally
dependent on part of a candidate key i.e Request_ID.
Request_ID Request_Day, Client_ID, Client_Name, Client _Address.
Here another nonprime attributes Item_Statement, Item_Completion, Rate_per_unit are functionally
dependent on part of a candidate key i.e Item_ID.

12 | P a g e
Transitive Dependencies
Transiitve dependencies occurs when a non-key attribute determine another non-key attribute.
Here a non-key attribute Client_ID determine another non-key attribute Client_Name and Client_
Address.
TYPES OF ANOMALIES IN THE SYSTEM
Anomalies are the errors or wrong state of the database. These anomalies naturally occur and result in
data that does not match the real-world the database purports to represent.
Four types of anomalies:
There are four types of Anomalies in the system i.e., Redundancy Anomalies, Update Anomalies, Insertion
Anomalies, and Deletion Anomalies.
1. Redundancy Anomalies
First there is a redundancy issue in the figure it still contains considerable redundancy for example client
ID client name and client actress for Zarlish Attique are recorded in three rows at least in the table as a
result of these redundancies manipulating the data in the table can be difficult and causes other types of
anomalies as well.
2. Insertion Anomalies
If the client calls and request another item be added to her request ID 2 new row must be inserted in which
the request_day and all of client information must be repeated .this may lead to the data entry errors .for
example the Client_Name may be entered as Zarlish Attique.
3. Deletion Anomolies
Third is the deletion anomaly if the client calls and request the cupcakeliners be deleted from her
Request_ID 1, this row must be deleted from the relation and we lost the information concerning this
items_completion as paper and price 290.
4. Update Anomolies

13 | P a g e
Fourth one is update anomaly if find daraz.pk is a part of price adjustment increases the price of cup_cake
liners item_ID 6 to 330 this change must be recorded in all rows containing that item there are two such
rows.
Figure: Different types of anomalies in the system WEEKLYRECIEPT.
STEP 1: TRANSFORMATION INTO FIRST NORMAL FORM (1NF)
A relation is in the first normal form if and only if every attribute in every tuple contains an atomic value
and there is no multivalued attributes or repeating groups in the relation. (Reference: Normalization
Lecture: slides)
Now it means there are two constraints applied to the table that is unnormalized table that is
WEEKLYRECIEPT.
1. First there should no repeating groups in the relation.
2. A primary key should be defined which is uniquely identified each row in a relation.
Removing repeating values for getting Atomic values
In a unnormalized table Request_ID 1 contain three repeating groups corresponding to the three items on
that request. So for this we form a table filling relevant data values into previously vacant cells of the
table. By Applying this procedure to the table WEEKLYRECIEPT yields a the new table as.
Table: Shows an unnormalized relation that we taken for our study.

14 | P a g e
Table: A table is I first normal form where each cell contains an atomic values i.e., no repeating groups are there.
Conclusion: The table is in 1NF.
STEP 2: TRANSFORMATION INTO SECOND NORMAL FORM (2NF)
A relation is in second normal form (2NF) if and only if it is in first normal form and all the non-key
attributes are fully functionally dependent on the key (Reference: Normalization Lecture: slides)
We can remove many of the redundancies and anomalies in the table by converting it into the second
normal form.
A relation is in the second normal form if it is in the first normal form and contain no partial dependencies
as in the table following partial dependencies are there
Partial Dependencies
Here nonprime attribute Request_Day, Client_ID, Client_Name, Client _Address are functionally
dependent on part of a candidate key i.e Request_ID.
Request_ID Request_Day, Client_ID, Client_Name, Client _Address.
Here another nonprime attributes Item_Statement, Item_Completion, Rate_per_unit are functionally
dependent on part of a candidate key i.e Item_ID.
the first of these partial dependency states that the day on an request is uniquely determined by the request
number and has nothing to do with the item ID and samw for the item ID.
So, for this
1. we can create a new relation for each primary key attribute or combination of attributes that is
determinant in partial dependency. That attribute is the primary key in the new relation

15 | P a g e
2. Move the non key attributes that are dependent on this primary key attribute or attributes from the
old relation to the new relation
3. So from this a new relation is generated and all the partial dependencies will be removed
Now two tables are formed i.e CLIENT_SIDE and ITEM to remove the partial dependencies and one new
table REQUEST_SIDE for removal of the redundancy issue.
Table: CLIENT_SIDE
Table: ITEM and REQUEST_SIDE.
Figure: Overall the steps in the second normal form.

16 | P a g e
STEP 3: TRANSFORMATION INTO THIRD NORMAL FORM (3NF)
A relational table is in third normal form (3NF) if it is already in 2NF and every non-key column is non-
transitively dependent upon its primary key. In other words, all non-key attributes are functionally
dependent only upon the primary key.
Here the transitive dependencies are given
Transitive Dependencies
Here a non-key attribute Client_ID determine another non-key attribute Client_Name and Client_
Address.
Now the client name and address are uniquely identified by the client ID but the client ID is not a part of
the primary key. Here, transitive dependencies create unnecessary redundancy that may lead to the type
of enormities
For example, in the CLIENT_SIDE table requires data name and address be reentered every time a client
submits a new request regardless of how many times they have been enter previously
Removing transitive dependencies
we can easily remove transitive dependencies from the relation by means of three step procedure
1. For each non key attribute our set of attributes that is determinant in a relation create a new relation
that attribute becomes the primary key of the new relation
2. Second move all the attributes that are functionally dependent on the attribute from the old to the
new relation.
3. Leave the attribute which serves as the primary key in their relation in the old relation to serve as
a foreign key that allows you to associate two relations.
The results of applying these steps to the relation CLIENT_SIDE we can made relation named CLIENT
has been created to receive the component of the transitive dependency.

17 | P a g e
Table: Removing all the transitive dependencies and relation decomposition.
The determinant CLIENT_ID becomes the primary key of this relation and the attribute name and address
are move to the relation CLIENT_SIDE, REQUEST and the attribute CLIENT_ID remains as foreign key
in that relation. This allow us to associate a request with the client who submitted the request indicated
this relation are now in 3rd normal form.
OVERALL NORMALIZING THE UNNORMALIZED TABLE THE WEEKLYRECIEPT
RESULTED IN CREATION OF FOUR RELATION (MADE IN POWERPOINT
APPLICATION SOFTWARE)

18 | P a g e
References:
References are present along with the sentences from where it has taken.

DBMS Helping material

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DBMS Helping material

Similar to DBMS Helping material (20)

More from ZarlishAttique1

More from ZarlishAttique1 (7)

Recently uploaded

Recently uploaded (20)

DBMS Helping material