Day 2

Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

DEPARTMENT OF

COMPUTER SCIENCE & ENGINEERING

Day-2
DBMS ASSIGNMENT

Name: HARSHIT BANGA UID: 21BCS5678

Branch: BE-CSE Section: IOT_630-B

Date: 06-01-24 Subject: DBMS

1. Given Given the relation schema R = (A, B, C, D, E) and functional dependencies Fc = {


A → BC CD → E B → D E → A } determine that (B, D) is in BCNF.

To determine if the relation schema R = (A, B, C, D, E) with functional dependencies Fc =


{ A → BC, CD → E, B → D, E → A } is in Boyce-Codd Normal Form (BCNF), we need to
check if all the functional dependencies in Fc satisfy the BCNF condition.
BCNF states that for every non-trivial functional dependency X → Y (where X does not
functionally determine Y), the determinant (X) must be a superkey.
Let's consider the functional dependency B → D:
B → D (Given)
Here, B is the determinant, and D is the determined attribute.
To check if B is a superkey:
From the given functional dependencies, we have:
A → BC (implies A → B and A → C)
B→D
E→A
Closure of B: B+ = {B, D}
B+ contains D, which means B → D satisfies the BCNF condition.
Therefore, (B, D) is in BCNF since the determinant (B) is a superkey, and the functional
dependency B → D holds.

2. Let consider Schema R = ABCD, F = {A -> B, B -> C, AC -> D}. Find Normal Form and
convert it into 3rd NF.

Candidate key: {A}


Step 1: nothing
Step 2: Minimal F’ = {A -> B, B -> C, A -> D}
Step 3: create relations:
For A->B, create a relation R1(A,B)
For B->C, create a relation R2(B,C)
For A->D, create a relation R3(A,D)
Step 4: do nothing
Step 5: do nothing, since candidate key A is in A->B
DEPARTMENT OF
COMPUTER SCIENCE & ENGINEERING

3. There is a company wherein employees work in more than one department. They store
the data like this:

emp_id emp_nationality emp_dept dept_type dept_no_of_emp


1001 Austrian Production and planning D001 200
1001 Austrian Stores D001 250
1002 American design and technical support D134 100
1002 American Purchasing department D134 600
Functional dependencies in the table above:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no_of_emp}
Candidate key: {emp_id, emp_dept}
Find Highest NF and Convert it into BCNF.

Given functional dependencies:


emp_id → emp_nationality
emp_dept →{dept_type,dept_no_of_emp}
Candidate key: {emp_id, emp_dept}
The candidate key {emp_id, emp_dept} is a minimal set of attributes that can uniquely identify
each tuple in the table.
Now, to convert the table into BCNF, we need to ensure that each functional dependency in the
table satisfies the condition where the determinant (left-hand side) is a superkey.
emp_id emp_nationality emp_dept dept_type dept_no_of_emp
1001 Austrian Production and planning D001 200
1001 Austrian Stores D001 250
1002 American Design and technical support D134 100
1002 American Purchasing department D134 600
Since the candidate key is {emp_id, emp_dept}, let's check if the given functional dependencies
satisfy BCNF:
1. emp_id→emp_nationalityemp_id→emp_nationality
• This holds, as the determinant emp_id is a part of the candidate key.
2. emp_dept→{dept_type,dept_no_of_emp}emp_dept→{dept_type,dept_no_of_emp}
• This also holds, as emp_dept is part of the candidate key.
Both functional dependencies satisfy BCNF as the determinant on the left side of each
dependency is a part of the candidate key.
Therefore, the given table is already in BCNF since all functional dependencies satisfy the
BCNF condition. No further normalization is required in this case.
DEPARTMENT OF
COMPUTER SCIENCE & ENGINEERING

4. Consider a Relation R has ten attributes ABCDEFGHIJ. Fields of R contain only atomic
values. R = {AB◻C, AD->GH BD-> EF A-> I H->J}. Find the following relation is in
which normal form. If it is in 1st NF then convert it into 2nd NF.
The given relation R has attributes ABCDEFGHIJ with functional dependencies:

• AB -> C
• AD -> GH
• BD -> EF
• A -> I
• H ->J

First, let's check if the relation is in the First Normal Form (1NF). For a relation to be in 1NF,
all attributes must contain atomic values, and there shouldn't be any multivalued or composite
attributes.
Looking at the functional dependencies, the presence of AB -> C and AD -> GH suggests
that attributes C and GH are dependent on combinations of attributes rather than individual
attributes. This implies that the attributes contain non-atomic values.
To convert this relation to 2NF, we need to decompose it such that each attribute is fully
functionally dependent on the primary key.
Given the functional dependencies, it seems like the attributes {AB} form a candidate key
since AB -> C and AD -> GH exist.
Decomposition into 2NF:
1. Create two relations:
- Relation 1: (AB, C)
- Relation 2: (AD, GH)
Both relations satisfy 2NF, as the attributes in each relation are fully functionally dependent
on their respective candidate keys.
Therefore, by decomposing the given relation into two relations {(AB, C), (AD, GH)}, we
achieve 2NF compliance.
5. In below table, find this relation is in 1st Normal form or Not. If below table is not in 1st
NF then convert it into 1NF?

ID Name Courses
1 A c1, c2
DEPARTMENT OF
COMPUTER SCIENCE & ENGINEERING

2 E c3
3 M c2, c3
The given table seems to violate the First Normal Form (1NF) due to the Courses column
containing multiple values separated by commas. To convert this table into 1NF, we need to
ensure that each cell of the table contains atomic values.

To achieve 1NF, we'll need to split the Courses column so that each row contains only a single
value for each attribute.

Here's the conversion:

Original Table:

ID Name Courses
1 A c1, c2

2 E c3
3 M c2, c3

Modified Table in 1NF:

ID Name Courses
1 A c1,

1 A c2
2 E c3
3 M c2
3 M c3

Now, each row in the modified table has atomic values in the Courses column, adhering to the
First Normal Form. The table is in 1NF as each cell contains a single atomic value.

6. Consider the following relational schema:


Suppliers(sid:integer, sname:string, city:string, street:string)
Parts(pid:integer, pname:string, color:string)
DEPARTMENT OF
COMPUTER SCIENCE & ENGINEERING

Catalog(sid:integer, pid:integer, cost:real)


Assume that, in the suppliers relation above, each supplier and each street within a city has a
unique name, and (sname, city) forms a candidate key. No other functional dependencies are
implied other than those implied by primary and candidate keys. Find normal form?
From the given information, we can identify the following:
• Suppliers: Candidate key = {sname, city}
• Parts: No specific candidate key mentioned
• Catalog: A composite key from (sid, pid)

Now, let's analyze each table's normal form:


Suppliers Table:
• Candidate Key: {sname, city}
• No additional functional dependencies provided
• No non-prime attributes

The Suppliers table appears to be in at least the Third Normal Form (3NF). The candidate
key has been identified, and there seem to be no transitive dependencies or non-prime
attributes.
Parts Table:
• Candidate Key: Not explicitly mentioned
• No additional functional dependencies provided
• Without a specified candidate key or additional functional dependencies, it's
challenging to determine the normal form for the Parts table accurately.

Catalog Table:
• Composite Key: (sid, pid)
• The Catalog table has a composite key from sid and pid, which appears to be a
candidate key for this table. Without additional information on functional
dependencies, we can't deduce further about its normal form accurately.

Based on the given information:


• Suppliers table appears to be at least in 3NF.
• Parts and Catalog tables' normal forms cannot be precisely determined without more
information on candidate keys and functional dependencies.
DEPARTMENT OF
COMPUTER SCIENCE & ENGINEERING

To ensure normalization, it's crucial to verify the functional dependencies and candidate keys
for each table explicitly. Normalization aims to minimize redundancy and dependency
anomalies by organizing data into well-structured relations, adhering to the desired normal
form.

You might also like