Chapter :-4 (English)

1. Functional Dependencies (FDs)

Functional Dependencies (FDs)

A functional dependency describes a relationship between attributes (columns) in a relational database table.

Definition

A functional dependency X → Y means:

If two rows have the same value for attribute set X, they must also have the same value for attribute set Y.

In other words, X determines Y.

Examples

1.   In Student(ID, Name, Major):

o   ID → Name, Major

§  The ID uniquely determines the student's name and major.

2.   In Employee(EmpID, Department, Manager):

o   Department → Manager

§  Each department has one manager.

Advantages of Functional Dependencies

1. Basis for Normalization

FDs are the foundation for database normalization (1NF → BCNF).
They help identify how attributes relate, allowing designers to eliminate redundancy and anomalies.

2. Reduce Data Redundancy

By using FDs to guide normalization, you minimize duplicate data, saving storage and improving consistency.

3. Prevent Update, Insert, and Delete Anomalies

FDs ensure the schema is structured so that:

• Updating data does not require multiple inconsistent changes.
• Inserting partial information is less problematic.
• Deleting a row doesn’t remove essential data.

4. Improve Data Integrity

FDs enforce deterministic relationships (e.g., StudentID → StudentName) ensuring accurate and reliable data.

5. Improve Query Efficiency (in well-designed schemas)

Though sometimes normalization adds joins, FDs can help design schemas that balance efficiency and correctness.

 

Disadvantages of Functional Dependencies

1. Difficult and Time-Consuming to Discover

FDs must be identified accurately, which often requires deep knowledge of business rules.
Incorrect or missing FDs lead to poor schema design.

2. Over-Normalization Can Hurt Performance

Strictly applying FDs to normalize to high normal forms can lead to:

• Many small tables
• More joins
• Slower queries in read-heavy systems

3. Not Always Obvious or Expressible

Some dependencies are:

• Business-rule-driven (not inherent in data)
• Hard to formalize (e.g., cross-field semantic rules)
• Changing over time

4. FD Theory Doesn’t Handle All Constraints

FDs cannot express:

• Multi-valued dependencies
• Temporal rules
• Conditional or exception-based constraints

Other constraint types (MVDs, TGDs, CHECK constraints, etc.) must be used.

5. Potential for Misapplication

If designers use FDs incorrectly:

• They may split tables unnecessarily
• Or fail to split when needed

Both lead to inefficient or inconsistent databases.