Dependency Preservation

Definition

A decomposition of a relation is said to be dependency preserving if every functional dependency in the original relation can be enforced by enforcing dependencies on the individual decomposed relations, without needing to join them back together.

More formally, if a relation schema $R$ with functional dependency set $F$ is decomposed into schemas $R_1, R_2, ..., R_n$ , then the decomposition is dependency preserving if the union of the projections of $F$ onto each $R_i$ implies all dependencies in $F$ . In other words, the constraints can be checked locally on the smaller relations.

This property is highly desirable because it allows the DBMS to validate data efficiently and maintain consistency without expensive joins.

Main Content

1. First Concept: Functional Dependencies and Their Role

A functional dependency expresses a rule of the form $X \rightarrow Y$ , meaning that if two rows agree on attribute set $X$ , they must also agree on attribute set $Y$ .
Functional dependencies are the basis for identifying redundancy, deciding normalization steps, and ensuring data integrity in relational schemas.

In dependency preservation, the key question is whether these rules remain enforceable after decomposition.

Example:
Consider a relation:

Student(StudentID, StudentName, DepartmentID, DepartmentName)

Functional dependencies:

StudentID -> StudentName, DepartmentID
DepartmentID -> DepartmentName

If this relation is decomposed into:

StudentInfo(StudentID, StudentName, DepartmentID)
DepartmentInfo(DepartmentID, DepartmentName)

Then both dependencies can be checked separately:

StudentID -> StudentName, DepartmentID in StudentInfo
DepartmentID -> DepartmentName in DepartmentInfo

This decomposition is dependency preserving.

2. Second Concept: Decomposition and Dependency Preservation

Decomposition is the process of breaking a large relation into two or more smaller relations, usually to reduce redundancy and avoid update anomalies.
Not every decomposition preserves dependencies, even if it is lossless.

A decomposition is useful only when it achieves both:

1. Lossless join

— no information is lost when tables are recombined.

2. Dependency preservation

— all original constraints can still be enforced locally.

A decomposition that is lossless but not dependency preserving may force the database to perform joins every time it wants to verify a constraint, which is inefficient and impractical.

Example of non-preserving decomposition:
Let relation be:

R(A, B, C)
FDs:

A -> B
B -> C

Decompose into:

R1(A, B)
R2(B, C)

Here:

A -> B is preserved in R1
B -> C is preserved in R2

This looks good, but consider if the original dependency set also required A -> C. That dependency is implied by the original FDs, but it is not directly enforceable in a single relation. If an update happens independently, checking all constraints may require joining R1 and R2.

This shows that preservation is not just about storing attributes separately; it is about retaining enforceable rules.

3. Third Concept: Why Dependency Preservation Matters in Normalization

In normalization, especially when converting to 3NF or BCNF, decomposition is performed to reduce anomalies such as insertion, deletion, and update anomalies.
However, normalization can sometimes split dependencies across relations, making constraint checking more expensive.

Dependency preservation is important because:

It avoids costly joins for constraint checking.
It allows the DBMS to enforce integrity rules table by table.
It improves performance and simplifies database maintenance.

Comparison with BCNF:
BCNF gives stronger normalization and removes more redundancy than 3NF, but BCNF decompositions are not always dependency preserving.
3NF is often preferred in practical database design because it can be both lossless and dependency preserving.

Illustration:
Suppose a relation is decomposed into:

Original:      R(A, B, C)
Dependencies:  A -> B
               B -> C

Decompose into:
               R1(A, B)
               R2(B, C)

To enforce A -> C, the system may need to combine R1 and R2. If the dependency were preserved, that extra step would not be needed.

So, dependency preservation is a balance between theoretical normalization and practical enforcement of rules.

Working / Process

1. Identify all functional dependencies in the original relation

Start with the set of attributes and determine the dependencies that describe the data.
These dependencies represent the business rules of the schema.

2. Decompose the relation into smaller relations

Apply normalization principles such as 3NF or BCNF.
Ensure the decomposition is at least lossless so data is not destroyed during joins.

3. Check whether each original dependency can be enforced locally

Project the original dependencies onto each decomposed relation.
If every dependency from the original set can be derived from the union of these projected dependencies, the decomposition is dependency preserving.

A simple way to visualize this is:

Original relation R(A, B, C)
FDs: A -> B, B -> C

Decompose into:
R1(A, B)
R2(B, C)

Check:

- A -> B in R1
- B -> C in R2

If every original FD is checkable like this, preservation exists.

If one dependency requires attributes from multiple relations to verify, the decomposition is not dependency preserving.

Advantages / Applications

Efficient constraint enforcement

Functional dependencies can be checked directly on the smaller tables without joins.

Improved database performance

Less overhead is needed when inserting, updating, or validating records.

Simpler integrity management

Database administrators and DBMS systems can maintain rules more easily when they are preserved after decomposition.

Useful in schema design

Helps designers choose between 3NF and BCNF based on practical needs.

Prevents anomalies while keeping rules enforceable

Supports good normalization without losing the ability to maintain data consistency.

Summary

Dependency preservation means original functional dependencies can still be enforced after decomposition.
It is important because it avoids costly joins and keeps integrity checking simple.
In practice, it helps balance normalization with efficient database design.
Important terms to remember: functional dependency, decomposition, lossless join, normalization, 3NF, BCNF, dependency preservation