Scribd
Upload
338 views6 pages

Partial Dependency and Transitive Dependency in DBMS

Uploaded by

moazmizan666
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
338 views6 pages

Partial Dependency and Transitive Dependency in DBMS

Uploaded by

moazmizan666
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

Partial Dependency in DBMS

In Database Management Systems (DBMS), a partial dependency occurs when a non-key


attribute (i.e., an attribute that is not part of the primary key) is dependent on part of a
composite primary key, rather than the whole composite key. This situation arises when a table
has a composite primary key (a primary key consisting of more than one column).

Partial dependency violates the rules of Second Normal Form (2NF), as all non-key attributes
should be fully dependent on the entire primary key, not just part of it.

Example of Partial Dependency

Consider the following table Student_Enrollments, where the composite primary key consists
of both Student_ID and Course_ID:

Student_ID Course_ID Student_Name Course_Name Instructor


101 C101 Alice Math Prof. Smith
101 C102 Alice English Prof. Johnson
102 C101 Bob Math Prof. Smith
103 C103 Charlie History Prof. Adams

Here, the composite primary key is (Student_ID, Course_ID), which uniquely identifies each
row.

Partial Dependency Issue:

 Student_Name depends only on Student_ID, not on the entire composite key


(Student_ID, Course_ID). This is a partial dependency.
 Course_Name and Instructor depend only on Course_ID, not on the entire composite
key. These are also partial dependencies.

These partial dependencies violate the 2NF rule, which requires all non-key attributes to be
fully dependent on the whole primary key.

Solution: Removing Partial Dependencies

To bring the table into 2NF and remove partial dependencies, we split the original table into two
or more tables, ensuring that each non-key attribute depends entirely on its corresponding key.

faculty of computer science and digital innovation 1


Step 1: Create a Student table based on the partial dependency of Student_Name on
Student_ID:

Student_ID Student_Name
101 Alice
102 Bob
103 Charlie

Step 2: Create a Course table based on the partial dependency of Course_Name and
Instructor on Course_ID:

Course_ID Course_Name Instructor


C101 Math Prof. Smith
C102 English Prof. Johnson
C103 History Prof. Adams

Step 3: Create an Enrollment table to store the relationships between Student_ID and
Course_ID, which will act as the bridge table between the two entities:

Student_ID Course_ID
101 C101
101 C102
102 C101
103 C103

Final Tables after Normalization (2NF)

Now, the data is organized into three tables:

1. Student Table:

 This table stores the Student_ID and Student_Name, ensuring that


Student_Name is fully dependent on the primary key Student_ID.

Student_ID Student_Name
101 Alice
102 Bob

faculty of computer science and digital innovation 2


Student_ID Student_Name
103 Charlie

2. Course Table:

 This table stores the Course_ID, Course_Name, and Instructor, ensuring that
Course_Name and Instructor are fully dependent on the primary key
Course_ID.

Course_ID Course_Name Instructor


C101 Math Prof. Smith
C102 English Prof. Johnson
C103 History Prof. Adams

3. Enrollment Table:

 This table holds the composite relationship between Student_ID and Course_ID,
ensuring that the relationship between students and courses is maintained without
any partial dependencies.

Student_ID Course_ID
101 C101
101 C102
102 C101
103 C103

Benefits of Removing Partial Dependencies:

 Reduced Redundancy: Student names and course details no longer repeat in the original
table. Each piece of data is stored only once in its respective table.
 Improved Data Integrity: By splitting the table, the chance of update anomalies is
reduced. If a student changes their name, for instance, it needs to be updated in only one
place (in the Student table).
 Avoiding Anomalies: Insertion, update, and deletion anomalies are minimized. For
example, removing a student's enrollment won't delete the course information by
accident.

Transitive Dependency in DBMS


faculty of computer science and digital innovation 3
A transitive dependency occurs in a database when a non-prime attribute (i.e., an attribute
that is not part of the primary key) depends on another non-prime attribute, rather than
depending directly on the primary key. This creates an indirect relationship between attributes,
which can lead to redundancy and update anomalies.

To put it simply, a transitive dependency exists when:

 A → B → C:

 Attribute A (which is part of the primary key) determines attribute B (a non-prime


attribute).
 B, in turn, determines another non-prime attribute C.

In a properly normalized table (in 3NF), transitive dependencies are removed to prevent
redundancy and improve the efficiency of database updates.

Example of Transitive Dependency

Initial Table:

Consider an Employee_Department table that stores information about employees, their


departments, and department locations.

Employee_ID Employee_Name Dept_ID Dept_Name Dept_Location


101 Alice D001 HR New York
102 Bob D001 HR New York
103 Charlie D002 Finance London
104 David D003 IT San Francisco

 Primary Key: Employee_ID


 Non-prime Attributes: Employee_Name, Dept_ID, Dept_Name, Dept_Location

In this table:

 Dept_ID determines Dept_Name and Dept_Location (i.e., Dept_ID → Dept_Name,


Dept_Location).
 Employee_ID determines Dept_ID (i.e., Employee_ID → Dept_ID).

This means there is a transitive dependency because:

faculty of computer science and digital innovation 4


 Employee_ID → Dept_ID → Dept_Name, Dept_Location

The non-prime attributes Dept_Name and Dept_Location depend on Dept_ID, which is a non-
prime attribute, not directly on Employee_ID. This is a violation of the rules of 3NF.

Problems Caused by Transitive Dependency:

 Redundancy: The same department information (Dept_Name, Dept_Location) is


repeated for every employee in that department.
 Update Anomaly: If the location of a department changes, you must update multiple
rows. If you miss one, the database becomes inconsistent.
 Deletion Anomaly: If an employee is deleted and they are the only one from a
department, the department information is also lost.

Solution: Remove Transitive Dependency

To remove the transitive dependency, we need to split the table into two or more smaller tables.
This ensures that non-prime attributes depend only on the primary key.

Normalization (Convert to 3NF)

1. Employee Table: Store information about employees, including the department they
belong to.

Employee_ID Employee_Name Dept_ID


101 Alice D001
102 Bob D001
103 Charlie D002
104 David D003

2. Department Table: Store department-related information separately.

Dept_ID Dept_Name Dept_Location


D001 HR New York
D002 Finance London
D003 IT San Francisco

Explanation:

faculty of computer science and digital innovation 5


 Now, the Employee Table only contains information about employees and their
department IDs. There is no redundancy.
 The Department Table stores department information. Since this data is stored only
once for each department, updating the department location requires changing just one
row, thus avoiding update anomalies.
 There is no transitive dependency because Dept_Name and Dept_Location are stored in a
separate table, and they directly depend on the primary key Dept_ID in the Department
Table.

By separating the tables, we have removed the transitive dependency, bringing the database to
3NF. This design reduces redundancy, prevents anomalies, and ensures data integrity.

faculty of computer science and digital innovation 6

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy