0% found this document useful (0 votes)
157 views9 pages

DBMS Questions

The document provides information about database management systems including topics covered such as normalization, Boyce Codd Normal Form, and multi-valued dependency. It also includes 6 questions with explanations of concepts like multi-valued dependency, decomposition of relations into third normal form and Boyce Codd normal form, functional dependencies, candidate keys, and different types of keys such as primary key, super key, candidate key, foreign key, and composite key.

Uploaded by

Kasyap Nani
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)
157 views9 pages

DBMS Questions

The document provides information about database management systems including topics covered such as normalization, Boyce Codd Normal Form, and multi-valued dependency. It also includes 6 questions with explanations of concepts like multi-valued dependency, decomposition of relations into third normal form and Boyce Codd normal form, functional dependencies, candidate keys, and different types of keys such as primary key, super key, candidate key, foreign key, and composite key.

Uploaded by

Kasyap Nani
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/ 9

DATABASE MANAGEMENT SYSTEMS

CSE-2004

Faculty : Dilip kumar choubey


Slot : D1

TOPICS :
Normalization
Boyce Codd Normal Form
Multi-Valued Dependency
Fourth Normal Form

Submitted by:
P.Radha krishna kasyap(18BCE0016)
S.Mahendra(18BCE0009)
M.Vivek Reddy(18BCE0718)
QUESTIONS:
Question 1:
What is Multi-valued Dependency?
A table is said to have multi-valued dependency, if the following
conditions are true,
1. For a dependency A → B, if for a single value of A, multiple value
of B exists, then the table may have multivalued dependency.
2. Also, a table should have at-least 3 columns for it to have a multi-
valued dependency.
3. And, for a relation R (A, B, C), if there is a multi-valued dependency
between, A and B, then B and C should be independent of each
other.
If all these conditions are true for any relation(table), it is said to
have multi-valued dependency.

Question 2:
Given relation R (W, X, Y, Z) and set of functional dependencies G= {Z
→W, Y →X Z, XW→Y}, where G is a minimal cover:
a) Decompose R into a set of relations in Third Normal Form.
b) Is your decomposition in part a) also in Boyce Codd Normal Form?
Explain your answer.
a. Possible keys: {Y}, {X, Z}, {W, X} R1= (Z, W), R2= (X, Y, Z), R3= (X, Y,
W)
b. Yes. In each of the three relations, the left side of the functional
dependencies that apply are super keys for the relation. Hence, all
three relations satisfy the definition of BCNF.
Question 3:
Suppose you are given a relation R with four attributes, ABCD. For
each of the following sets of FDs, assuming those are the only
dependencies that hold for R, do the following:
(a) Identify the candidate key(s) for R.
(b) Identify the best normal form that R satisfies (1NF, 2NF, 3NF, or
BCNF).
(c) If R is not in BCNF, decompose it into a set of BCNF relations that
preserve the dependencies.
1. C → D, C → A, B → C
2. B → C, D → A
3. ABC → D, D → A
4. A → B, BC → D, A → C
5. AB → C, AB → D, C → A, D → B
1.
(a) Candidate keys: B
(b) R is in 2NF but not 3NF.
(c) C → D and C → A both cause violations of BCNF. One way to
obtain a (lossless) join preserving decomposition is to decompose R
into AC, BC, and CD.
2.
(a) Candidate keys: BD
(b) R is in 1NF but not 2NF.
(c) Both B → C and D → A cause BCNF violations. The decomposition:
AD, BC, BD (obtained by first decomposing to AD, BCD) is BCNF and
lossless and join-preserving. Schema Refinement and Normal Forms
137
3.
(a) Candidate keys: ABC, BCD
(b) R is in 3NF but not BCNF.
(c) ABCD is not in BCNF since D → A and D is not a key. However if we
split up R as AD, BCD we cannot preserve the dependency ABC → D.
So, there is no BCNF decomposition.
4.
(a) Candidate keys: A
(b) R is in 2NF but not 3NF (because of the FD: BC → D).
(c) BC → D violates BCNF since BC does not contain a key. So we split
up R as in: BCD, ABC.
5.
(a) Candidate keys: AB, BC, CD, AD
(b) R is in 3NF but not BCNF (because of the FD: C → A).
(c) C → A and D → B both cause violations. So, decompose into: AC,
BCD but this does not preserve AB → C and AB → D, and BCD is still
not BCNF because D → B. So, we need to decompose further into:
AC, BD, CD. Now add ABC and ABD to get the final decomposition:
AC, BD, CD, ABC, ABD which is BCNF, lossless and join-preserving.
Question 4:
Consider a relation R with attributes ABCDE. Let the following FDs be
given: A → BC, BC → E, and E → DA. Similarly, let S be a relation with
attributes ABCDE and let the following FDs be given: A → BC, B → E,
and E → DA. (Only the second dependency differs from those that
hold over R.) You do not know whether or which other (join)
dependencies hold.
1. Is R in BCNF?
2. Is R in 4NF?
3. Is R in 5NF?
4. Is S in BCNF?
5. Is S in 4NF?
6. Is S in 5NF?
1.The schema R has keys A, E and BC. It follows that R is indeed in
BCNF.
2. R is also in 4NF (since the relation scheme has a single-attribute
key).
3. R is in 5NF because the schema does not have any JD (besides
those that are implied by the FD’s of the schema; but these cannot
violate the 5NF condition). Note that this alternative argument may
be used in some of the other parts of this problem as well.
4. The schema S has keys A, B and E. It follows that S is indeed in
BCNF.
5. S is also in 4NF (since the relation scheme has a single-attribute
key).
6.S is also in 5NF (since each key is a single-attribute key.)
Question 5:
What is Normalization?
Normalization is the process of efficiently organizing data in a
database. There are two goals of the normalization process:
eliminating redundant data (for example, storing the same data in
more than one table) and ensuring data dependencies make sense
(only storing related data in a table). Both of these are worthy goals
as they reduce the amount of space a database consumes and
ensure that data is logically stored.
Why it is requried?
Normalization reduces redundancy. Redundancy is the
unnecessary repetition of data. It can cause problems with storage,
reterival and updation of data. Redundancy can lead to:
▪ Inconsistencies:- errors are more likely to occur when facts
are repeated.
▪ Update anomalies:- inserting, modifying and deleting data
may cause inconsistencies. Inconsistency occurs when we
perform updation or deletion of data in one relation, while
forgetting to make corresponding changes in other relations.
During the process of normalization, you can identify
dependencies, which can cause problems when deleting or
updating. Normalization also helps to simplify the structure of the
tables. A fully normalized record consist of:
▪ A primary key that identifies that entity.
▪ A set of attributes that describe that entity.

QUESTION 6:

Explain the various keys in DBMS.


Primary Key: The primary key of a relational table uniquely
identifies each record in the table. It can either be a normal
attribute that is guaranteed to be unique (such as Social Security
Number in a table with no more than one record per person) or it
can be generated by the DBMS. Primary keys may consist of a single
attribute or multiple attributes in combination.
Examples: Imagine we have a STUDENTS table that contains a
record for each student at a university. The student’s unique
student ID number would be a good choice for a primary key in the
STUDENTS table. The student’s first and last name would not be a
good choice, as there is always the chance that more than one
student might have the same name.
Super Key: A super key is a combination of attributes that can be
uniquely used to identify a database record. A table might have
many super keys. Candidate keys are a special subset of super keys
that do not have any extraneous information in them.
Examples: Imagine a table with the fields <Name>, <Age>, <SSN>
and <Phone Extension>. This table has many possible super keys.
Three of these are <SSN>, <Phone Extension, Name> and <SSN,
Name>. Of those listed, only <SSN> is a candidate key, as the others
contain information not necessary to uniquely identify records.
Candidate Key: A candidate key is a combination of attributes that
can be uniquely used to identify a database record without any
extraneous data. Each table may have one or more candidate keys.
One of these candidate keys is selected as the table primary key.
In the relational model of databases, a candidate key of
a relation is a minimal super key for that relation; that is, a set of
attributes such that
1. the relation does not have two distinct tuples with the same
values for these attributes (which means that the set of
attributes is a superkey)
2. there is no proper subset of these attributes for which (1)
holds (which means that the set is minimal).
Since a relation contains no duplicate tuples, the set of all its
attributes is a superkey if NULL values are not used. It follows that
every relation will have at least one candidate key.
The candidate keys of a relation tell us all the possible ways we can
identify its tuples. As such they are an important concept for the
design database schema.
Foreign Key: A foreign key is a field (or fields) that points to the
primary key of another table. The purpose of the foreign key is to
ensure referential integrity of the data. In other words, only values
that are supposed to appear in the database are permitted.
For example, say we have two tables, a CUSTOMER table that
includes all customer data, and an ORDERS table that includes all
customer orders. The constraint here is that all orders must be
associated with a customer that is already in the CUSTOMER table.
In this case, we will place a foreign key on the ORDERS table and
have it relate to the primary key of the CUSTOMER table. This way,
we can ensure that all orders in the ORDERS table are related to a
customer in the CUSTOMER table. In other words, the ORDERS
table cannot contain information on a customer that is not in the
CUSTOMER table.
The structure of these two tables will be as follows:
Table CUSTOMER
column name characteristic
SID Primary Key
Last_Name
First_Name
Table ORDERS
column name characteristic
Order_ID Primary Key
Order_Date
Customer_SID Foreign Key
Amount
In the above example, the Customer_SID column in the ORDERS
table is a foreign key pointing to the SID column in the CUSTOMER
table.
Composite Key : A composite key is a key that uses more than one
column to identify the data as opposed to a single column. This can
sometimes be more useful than assigning each row an arbitrary
value to use as a key such as an auto number field.

You might also like