DBMS UNIT-4 LONGS

IV-Essay Questions 1. Consider schema R = (A, B, C, G, H, I)

and the set F of functional dependencies {A → B, A → C, CG
→ H, CG → I, B → H}. Compute the closure and Compute the
Candidate keys of the schema.
 1A) Schema R=(A,B,C,G,H,I)R = (A, B, C, G, H,
I)R=(A,B,C,G,H,I)
 Functional Dependencies
F={A→B,A→C,CG→H,CG→I,B→H}

Step 1: Compute Closures

We need to find the closure of attributes to determine the
candidate keys.
Try closure of A:
Compute A+A^+A+:
 Start with {A}
 A→Bso add B → {A, B}
 A→C so add C → {A, B, C}
 Now, {C, G} needed for CG → H and CG → I. We only
have C, not G.
 B → H, and we have B, so add H → {A, B, C, H}
No more rules apply.
A⁺ = {A, B, C, H}
Not covering all R attributes (G, I missing).
Thus, A is NOT a candidate key.

Try closure of CG:

Compute (CG)+(CG)^+(CG)+:
 Start with {C, G}
 CG→Hso add H → {C, G, H}
 CG→Iso add I → {C, G, H, I}
We have C, G, H, I — missing A, B.
Cannot reach A or B → CG is NOT a candidate key.

Try closure of AG:

Compute (A,G)+(A, G)^+(A,G)+:
 Start with {A, G}
 A→Bso add B → {A, G, B}
 A→Cso add C → {A, G, B, C}
 {C, G} → H, so add H → {A, G, B, C, H}
 {C, G} → I, so add I → {A, G, B, C, H, I}
Now we have {A, B, C, G, H, I} = all attributes.
Thus, AG is a candidate key.

Try closure of other combinations:

Check if A alone can become a key if we add a minimal
number of attributes.
Since A+={A,B,C,H} earlier, missing G and I.
We needed G to reach CG, which then gives H and I.
Thus, we needed to pair A with G.

Try closure of BG:

Compute (B,G)+(B, G)^+(B,G)+:
 Start with {B, G}
 B→H so add H → {B, G, H}
No path to C, I, or A.
Thus, BG is NOT a candidate key.

Try closure of CAG:

Compute (C,A,G)+(C, A, G)^+(C,A,G)+:
 Start with {C, A, G}
 A → B, so add B → {C, A, G, B}
 A → C (already have C)
 CG → H, so add H → {C, A, G, B, H}
 CG → I, so add I → {C, A, G, B, H, I}
Full R covered.
But C is redundant here because A and G were enough.
Thus, AG is still the minimal key.
Step 2: Final Answer
✅ Candidate Key(s): {A, G}

Summary:
 AG is a candidate key.
 A⁺ = {A, B, C, H}
 CG⁺ = {C, G, H, I}
 AG⁺ = {A, B, C, G, H, I} = all attributes

2. Discuss Fourth Normal Form by taking a Suitable example

2A) Definition:
A relation is in Fourth Normal Form (4NF) if it is in Boyce-
Codd Normal Form (BCNF) and has no multi-valued
dependencies (MVDs).
A multi-valued dependency happens when, for a single
attribute, there are multiple independent values of another
attribute.
In such cases, we need to separate the repeating groups into
different relations.

Formal Condition:
A relation R is in 4NF if, for every non-trivial multi-valued
dependency X↠YX \twoheadrightarrow YX↠Y in R, X is a
superkey.

Example:
Suppose a university records the following information:
 A Student can enroll in multiple Courses.
 A Student can have multiple Hobbies.
Relation:
Student_Info(Student_ID,Course,Hobby)
Data:
Student_ID Course Hobby
1 Math Painting
1 Science Painting
1 Math Chess
1 Science Chess
 Student 1 is enrolled in both Math and Science.
 Student 1 has hobbies Painting and Chess.
Notice:
 Courses and Hobbies are independent of each other for
the same student.
 Thus, there are multi-valued dependencies:
o Student_ID↠CourseStudent
 o Student_ID↠HobbyStudent
This violates 4NF.

Solution (Decomposition):
We split into two relations:
1. Student_Course(Student_ID,Course)
Student_ID Course
1 Math
1 Science
2. Student_Hobby(Student_ID,Hobby)Student\
_Hobby(Student\_ID,
Hobby)Student_Hobby(Student_ID,Hobby)
Student_ID Hobby
1 Painting
1 Chess
Now:
 No multi-valued dependencies exist in either table.
 Both tables are in 4NF.

Why 4NF is Important?

 It removes redundancy caused by independent multi-
valued facts.
  It prevents anomalies during insertions, deletions, and
updates.
 It ensures cleaner and more efficient database design.

🔥 Final Points:
 4NF removes unwanted multi-valued dependencies.
 Decomposition results in lossless and dependency-
preserving relations.
 It is stricter than BCNF.

3. Describe loss less join property of Schema

Decomposition
3A) Definition:
When a relation is decomposed into two or more sub-
relations, the lossless join property ensures that when we
join these sub-relations back together, we get exactly the
original relation without any extra or missing data.
In short:
Decomposition is lossless if no information is lost after
splitting and rejoining.

Formal Condition:
A decomposition of relation RRR into R1R_1R1 and
R2R_2R2 is lossless if at least one of these conditions
holds:
 (R1∩R2)→R1
 (R1∩R2)→R2
That means the common attributes between R1R_1R1 and
R2R_2R2 must uniquely identify either R1 or R2

Example:
Suppose we have a relation:
Student(Student_ID,Name,Course)Student(Student\_ID,
Name, Course)Student(Student_ID,Name,Course)
We decompose it into:
 R1(Student_ID,Name)
 R2(Student_ID,Course)
Here:
 Common attribute = Student_IDStudent\_IDStudent_ID
Student_ID → Name (from original FD)
 Student_ID → Course (from original FD)
Student_ID uniquely identifies both parts, the join will
reconstruct the original Student table without loss.
Thus, this decomposition is lossless.

Why is Lossless Join Important?

 It guarantees data integrity.
 It ensures no accidental duplication or loss of
information during decomposition.
 It maintains correct results for queries after
decomposition.

Quick Diagram:
Original Relation → Decompose → Sub-relations → Join →
Get back Original Relation
✅ (If Lossless)
❌ (If Lossy — wrong or incomplete data)

🔥 Final Points:
 Lossless decomposition preserves data perfectly.
 Common attribute must be a key for at least one sub-
relation.
 It is critical for database normalization.

4. State and explain Third normal form with an example

4A) Definition:
A relation is in Third Normal Form (3NF) if:
1. It is in Second Normal Form (2NF), and
2. No non-prime attribute is transitively dependent on the
primary key.
In simple words:
In 3NF, every non-key attribute must depend only on the
key, and nothing but the key.

Formal Condition:
A relation is in 3NF if, for every functional dependency
X→YX \to YX→Y:
 X→Y is a trivial dependency (Y ⊆ X), OR
 X Is a superkey, OR
 Each attribute in Y is a prime attribute (part of some
candidate key).

Example:
Consider a relation:
Employee(Emp_ID,Emp_Name,Dept_ID,Dept_Name)
Functional Dependencies:
 Emp_ID→Emp_Name,Dept_ID
 Dept_ID→Dept_Name
Primary Key: Emp_ID
Problem:
 Emp_ID → Dept_ID (fine, direct dependency)
 Dept_ID → Dept_Name (Dept_Name depends on
Dept_ID, not directly on Emp_ID → transitive
dependency)
Thus, this relation is NOT in 3NF.
Solution (Decomposition):
Split into two relations:
1. Employee(Emp_ID,Emp_Name,Dept_ID)
2. Department(Dept_ID,Dept_Name)
Now:
 In Employee, every non-prime attribute (Emp_Name,
Dept_ID) depends only on Emp_ID.
 In Department, Dept_Name depends only on Dept_ID.
Thus, both are in 3NF!

Why is 3NF Important?

 It removes redundancy caused by transitive
dependencies.
 It avoids anomalies during Insert, Update, and Delete
operations.
 It improves data consistency and storage efficiency.

🔥 Final Points:
 3NF removes transitive dependency.
 It preserves functional dependencies.
 3NF is a balance between good normalization and good
performance.
5. Define BCNF. How does BCNF differ from 3NF? Explain
with an example
5A) Definition:
A relation is in Boyce-Codd Normal Form (BCNF) if, for
every non-trivial functional dependency X→YX \to YX→Y,
XXX must be a superkey.
In short:
In BCNF, left-hand side of every functional dependency
must be a superkey.

Difference between BCNF and 3NF:

Aspect 3NF BCNF
Not compulsory if Superkey is
Superkey
dependent attribute always
condition
is a prime attribute compulsory
Functional and
Only functional
Handles transitive
dependencies
dependencies
Yes (stricter form
Stricter? No (less strict)
of 3NF)
Redundancy
Possible Some redundancy
almost fully
Redundancy might remain
eliminated
✅ Every BCNF relation is in 3NF, but not every 3NF relation
is in BCNF.
Example:
Consider relation:
R(Student_ID,Course_Code,Instructor)
Functional Dependencies:
 Student_ID,Course_Code→Instructor
 Instructor→Course_Code
Candidate Key: (Student_ID, Course_Code)

Check 3NF:
 (Student_ID, Course_Code) → Instructor (Fine — LHS is a
superkey)
 Instructor → Course_Code
o Instructor is not a superkey.
o But Course_Code is a prime attribute (part of the
candidate key).
Thus, satisfies 3NF.

Check BCNF:
 Instructor → Course_Code
o Instructor is not a superkey. Thus, NOT in BCNF.

Solution (Decomposition):
Split R into two relations:
1. R1(Instructor,Course_Code)
2. R2(Student_ID,Instructor)
Now:
 In R1, Instructor → Course_Code (Instructor is key here)
 In R2, Student_ID + Instructor can determine
Course_Code if needed
Thus, both relations are now in BCNF!

🔥 Final Points:
 BCNF removes all redundancy caused by functional
dependencies.
 BCNF demands stronger normalization than 3NF.
 In BCNF, every dependency must start from a superkey.

6. Discuss in detail about all the Functional Dependencies

with appropriate examples
6A) Definition:
A functional dependency (FD) is a relationship between
two sets of attributes in a relation.
If X→Y it means that for each value of X, there is exactly
one value of Y.
In simple words:
"X determines Y" — knowing X, we can uniquely find Y.
Types of Functional Dependencies:
1. Trivial Functional Dependency
 A functional dependency is trivial if Y⊆XY \subseteq
XY⊆X.
 It always holds naturally.
Example:
In relation R(A,B)
A,B->B→A is trivial because A is a part of (A, B).

2. Non-Trivial Functional Dependency

 A functional dependency is non-trivial if Y is not a
subset of X
 It carries real meaning in database design.
Example:
In relation R(A,B)
A→B is non-trivial because B is not part of A.

3. Completely Non-Trivial Functional Dependency

 A special case where X and Y have no common
attributes.
Example:
A→B and A and B are completely different.

4. Partial Functional Dependency

 When an attribute depends on part of a composite
primary key (not the whole key).
 Happens only in relations with composite keys.
Example:
Relation: R(Student_ID,Course_Code,Instructor)
Primary Key: (Student_ID, Course_Code)
Student_ID→InstructorStudent is a partial dependency
because only part (Student_ID) determines Instructor.

5. Full Functional Dependency

 If an attribute depends on the whole composite key, not
just a part.
Example:
Student_ID,Course_Code→Grade
Grade depends on both Student_ID and Course_Code
together.

6. Transitive Dependency
 When A→B and B→C imply A→C
 B is an intermediate dependency.
Example:
Emp_ID→Dept_ID
Thus, Emp_ID→Dept_Name (transitive).

🔥 Final Points:
 Functional dependencies help to normalize the
database.
 They remove redundancy and maintain data integrity.
 They are the backbone for 2NF, 3NF, BCNF, and beyond.

7. State and explain First normal form with an example

7A) Definition:
A relation is in First Normal Form (1NF) if:
 Every attribute contains only atomic (indivisible) values.
 Each record must be unique.
 No repeating groups or arrays are allowed.
In simple words:
In 1NF, the table should look like a proper grid — each cell
should have only one value, not a set or list.

Rules for 1NF:

 Each column must have atomic values.
 All entries in a column must be of the same type.
 Each row must be uniquely identifiable (usually using a
primary key).

Example:
Suppose we have a relation:
Student_ID Name Subjects
1 Varun Math, Physics
2 Akash Chemistry
 Problem: In the "Subjects" column, multiple subjects are
stored together (not atomic).
 Thus, NOT in 1NF.

Convert to 1NF:
We split multiple values into separate rows:
Student_ID Name Subject
1 Varun Math
1 Varun Physics
2 Akash Chemistry
✅ Now:
 Each field contains only one value.
 The table follows 1NF.

Why is 1NF Important?

 It avoids confusion during querying and updating.
 It simplifies database operations.
 It is the first step toward higher normalization (2NF, 3NF,
etc.).
🔥 Final Points:
 1NF demands atomic values.
 No multi-valued or nested attributes allowed.
 It sets a proper table structure.

8. Discuss the concept of Surrogate Key with an example

8A) Definition:
A Surrogate Key is an artificial, system-generated key used
to uniquely identify each record in a table.
It does not have any business meaning — it’s just used
internally by the database.
In simple words:
A surrogate key is a unique ID that has no connection to
real-world data.

Characteristics of Surrogate Keys:

 It is usually a simple integer (like 1, 2, 3...).
 It is unique for each row.
 It is not derived from application data.
 Changes in business logic do not affect surrogate keys.
 Databases can automatically generate surrogate keys
(like AUTO_INCREMENT in MySQL).
Example:
Suppose we have a table storing employee information:
Employee_ID (Surrogate Key) Name Department
1 Varun HR
2 Akash Finance
3 Priya Marketing
Here:
 Employee_ID is a surrogate key.
 It uniquely identifies each employee.
 It has no meaning outside the database — it’s just a
number.

Surrogate Key vs Natural Key:

Surrogate Key Natural Key
Artificial and meaningless Based on real-world data
Comes from application
Database-generated
data
May change if business
Never changes
changes
Best for performance and Useful for simple small
scalability systems

Why Use a Surrogate Key?

 Simplifies joins between tables.
 Improves performance of indexes.
 Protects against changes in real-world data.

🔥 Final Points:
 Surrogate Keys are system-generated unique identifiers.
 They have no business meaning.
 They are useful for stability and performance in large
databases.

9. State and explain Second normal form with an example

9A) Definition:
A relation is in Second Normal Form (2NF) if:
1. It is already in First Normal Form (1NF), and
2. Every non-prime attribute is fully functionally
dependent on the entire primary key (not just part of
it).
In simple words:
2NF removes partial dependencies — non-key attributes
should depend on the whole key, not just part of it.

Key Terms:
 Prime Attribute: Attribute that is part of a candidate key.
 Partial Dependency: When an attribute depends only on
part of a composite primary key.

Example:
Suppose we have a relation:
Student_I Course_Cod Instructor_Nam Departmen
D e e t
1 CS101 Dr. Smith CS
2 MA101 Dr. John Math
Functional Dependencies:
 (Student_ID, Course_Code) → Instructor_Name
 Course_Code → Department
Primary Key: (Student_ID, Course_Code)

Problem:
 Department depends only on Course_Code (a part of
the composite key).
 This is a partial dependency, so the relation is NOT in
2NF.

How to Convert to 2NF:

Decompose the relation into two tables:
1. Student_Course(Student_ID,Course_Code,Instructor_Na
me)
2. Course(Course_Code,Department)
Now:
 In Student_Course, all non-prime attributes
(Instructor_Name) depend on the whole primary key.
 In Course, Department depends only on Course_Code.
✅ Thus, both relations are in 2NF.

Why is 2NF Important?

 It eliminates partial dependencies.
 It reduces data redundancy.
 It makes the database easier to maintain.

🔥 Final Points:
 2NF = 1NF + no partial dependency.
 Non-prime attributes must depend on the entire key.
 Helps to make databases more consistent and efficient.

10. Describe Multi Valued Functional Dependency with

an example.
10A) Definition:
A Multivalued Functional Dependency (MVD) occurs
when, for a single value of attribute AAA, there can be
multiple independent values of attribute BBB and
attribute CCC, and they are not related to each other.
It is denoted as:
A↠B
In simple words:
If knowing A, you can list multiple B values, independent of
other attributes, then AAA multi-determines BBB.

Key Points:
 MVDs deal with sets of values, not single values.
 They typically occur when two attributes are
independent but depend on the same key.
 MVDs are crucial for achieving Fourth Normal Form
(4NF).

Example:
Consider a table storing information about students, their
hobbies, and their languages:
Student_ID Hobby Language
1 Painting English
1 Painting Hindi
1 Dancing English
1 Dancing Hindi
Here:
 A student can have multiple hobbies.
 A student can speak multiple languages.
 But hobbies and languages are independent of each
other.
Thus:
 Student_ID↠Hobby
 Student_ID↠Language
✅ It is a multivalued dependency.

Important:
If a relation has a non-trivial MVD, it can lead to
unnecessary repetition.
Hence, we decompose the relation into two tables:
1. Student_Hobby(Student_ID,Hobby)
2. Student_Language(Student_ID,Language)
✅ Now, no redundancy and the design is ready for Fourth
Normal Form (4NF).

🔥 Final Points:
 MVD represents multiple independent values related to
a single attribute.
 It causes repetition if not handled properly.
 It is removed by 4NF decomposition.
 11. Explain about dependency preserving
decomposition with an example
11A) Definition:
A dependency-preserving decomposition is one where all
the functional dependencies (FDs) that hold in the original
relation are also preserved in the decomposed relations. This
means that after decomposition, we can still enforce all the
original FDs without needing to join the decomposed tables.
In simple words:
A decomposition is dependency-preserving if the original
constraints can be recovered by looking at the decomposed
tables individually (without needing joins).

Key Characteristics:
 Preserves FDs: All original functional dependencies are
represented in the decomposed schema.
 No Need for Joins: You can enforce all original FDs
without needing to perform a join between the
decomposed relations.
 Reduces Redundancy: Decomposition helps eliminate
redundancy and update anomalies.

Example:
Consider a relation R(A,B,C,D)with the following functional
dependencies:
1. A→B
 2. C→D
3. A,C→D
Step 1: Decompose the Relation
We decompose R(A,B,C,D) into two relations:
1. R1(A,B)
2. R2(C,D)
Now, let's check if the decomposition is dependency-
preserving:
 Original FDs:
o A→B→ Preserved in R1(A,B)
o C→D → Preserved in R2(C,D)
o A,C→D C→D → Not directly preserved, but we can
see that A→B in the decomposed relations enforce
the FD.
In this case, all the functional dependencies are preserved
without requiring a join, so the decomposition is
dependency-preserving.

Step 2: Why is Dependency Preservation Important?

 Efficiency: If the decomposition is dependency-
preserving, we can ensure that the data is consistent
and valid without needing to re-join tables or recompute
constraints.
  Simplicity: It simplifies querying, validation, and
consistency checks by avoiding extra operations like
joins.
 Integrity Maintenance: It ensures that data integrity (via
FDs) is maintained after decomposition.

Example of a Non-Dependency-Preserving Decomposition:

If we decompose R(A,B,C,D)into:
1. R1(A,B)
2. R2(A,C)
In this case, the is not preserved in the decomposed
relations, because there's no table that directly enforces this
dependency. We would need to perform a join to enforce all
the dependencies. Hence, this decomposition is not
dependency-preserving.

🔥 Final Points:
 Dependency-Preserving means all FDs in the original
relation are maintained in the decomposed tables.
 It ensures data consistency and validity without extra
complexity (like joins).
 If FDs are not preserved, the integrity constraints could
break down, requiring additional work.