Equivalence Of Fd Sets - Learning Module

Loading content...

0/241

Equivalent Sets

The Equivalence Question

In database design, functional dependencies (FDs) capture the essential constraints that govern how data relates within a schema. However, a critical observation emerges when working with FDs in practice: multiple different sets of functional dependencies can express exactly the same semantic constraints.

This raises a fundamental question that lies at the heart of normalization theory: When do two sets of functional dependencies represent the same thing?

Consider a real-world analogy: two different legal contracts might use entirely different wording, structure, and clause arrangements—yet impose identical obligations on all parties. To determine if they are legally equivalent, you need a systematic method to compare their actual implications, not just their surface syntax. The same challenge exists in database theory.

What You Will Learn

By the end of this page, you will understand the formal definition of equivalent FD sets, be able to explain why different FD sets can have identical logical power, recognize the importance of equivalence in database design optimization, and distinguish syntactic differences from semantic differences in FD sets.

Why Equivalence Matters

Before diving into formal definitions, let's understand why the concept of FD set equivalence is absolutely essential to database theory and practice.

The Problem of Multiple Representations

When designing a database or analyzing an existing schema, you might discover functional dependencies in several ways:

From domain experts — Business analysts describe rules like "each employee has exactly one department"
From existing data — Data profiling tools extract patterns from actual records
From documentation — Previous designers left behind FD specifications
From inference — You derive new FDs using Armstrong's axioms

Each source might express constraints differently. An expert might say EmployeeID → DepartmentID, while another source says EmployeeID → DepartmentID, EmployeeName (having observed both dependencies together). Are these different? Do they impose different constraints?

Syntactic vs. Semantic Difference

Two FD sets can look dramatically different on paper (syntactic difference) yet impose exactly the same constraints on all possible relation instances (semantic equivalence). Confusing these concepts leads to unnecessary redesigns, missed optimizations, and incorrect normalization decisions.

Critical Applications of Equivalence Testing

Understanding FD set equivalence enables several crucial database design activities:

Practical Applications

•Canonical Cover Computation — Reducing an FD set to its minimal equivalent form eliminates redundancy and simplifies normalization. This requires proving that the reduced set is equivalent to the original.
•Schema Comparison — When migrating between databases or consolidating systems, you must verify that different FD representations impose the same constraints.
•Normalization Verification — After decomposing a relation, you need to confirm that the FDs preserved by the decomposition are equivalent to (or cover) the original dependencies.
•Design Optimization — Identifying equivalent but simpler FD sets can reduce the number of constraints to enforce, lowering database overhead.
•Theoretical Proofs — Many database algorithms require proving that certain FD set transformations preserve equivalence.

Formal Definition of Equivalent FD Sets

We now establish the rigorous mathematical definition of equivalent functional dependency sets. This definition is the foundation upon which all equivalence testing algorithms are built.

Definition: Equivalence of FD Sets

Two sets of functional dependencies, F and G, defined over the same set of attributes U, are equivalent (denoted F ≡ G) if and only if they determine exactly the same set of functional dependencies.

Formally:

$$F \equiv G \iff F^+ = G^+$$

where F⁺ and G⁺ denote the closures of F and G respectively—the complete set of all functional dependencies that can be derived from F (or G) using Armstrong's axioms.

Understanding the Definition

The key insight is that equivalence is defined in terms of logical consequence, not syntactic similarity. Two FD sets are equivalent if every FD that follows from one also follows from the other, and vice versa. The closures F⁺ and G⁺ represent all possible implications of each set.

Why Closures?

The closure F⁺ contains all FDs that are logically implied by F. If F = {A → B, B → C}, then F⁺ includes:

All FDs in F: A → B, B → C
All derived FDs: A → C (by transitivity), A → BC (by union), AB → C, etc.
All trivial FDs: A → A, AB → A, ABC → BC, etc.

The closure can be enormous—exponential in the number of attributes. Computing and comparing full closures is computationally expensive. This motivates the efficient testing methods we'll develop later.

Alternative Characterization

An equivalent and often more practical way to express equivalence uses the notion of covering:

Equivalence Definition
// Equivalence defined via mutual covering
F ≡ G   ⟺   (F covers G) ∧ (G covers F)
 
// Where "F covers G" means:
∀ (X → Y) ∈ G⁺ : (X → Y) ∈ F⁺
 
// In practical terms:
F covers G ⟺ every FD derivable from G is also derivable from F

This mutual covering characterization is foundational—it converts the problem of comparing infinite closure sets into checking whether each set's FDs can be derived from the other.

Building Intuition Through Examples

Abstract definitions become concrete through worked examples. Let's examine several cases that illustrate when FD sets are (or aren't) equivalent.

Example 1: Obvious Equivalence Through Transitivity

Consider a relation with attributes {A, B, C} and two FD sets:

FD Set F

•A → B
•B → C

FD Set G

•A → B
•B → C
•A → C

Analysis: G contains an extra FD (A → C) that F doesn't explicitly list. However, A → C can be derived from F using transitivity:

A → B (given in F)
B → C (given in F)
Therefore, A → C (transitivity)

Every FD in G is either in F or derivable from F. Conversely, every FD in F is clearly in G. Thus F⁺ = G⁺, and F ≡ G.

Key Insight

Adding an FD that is already logically implied by the existing FDs creates an equivalent set. This is the foundation for removing redundant FDs when computing canonical covers.

Example 2: Non-Equivalence Due to Missing Implication

Consider attributes {A, B, C} with:

FD Set F

•A → B

FD Set G

•A → B
•A → C

Analysis: G contains A → C, but there is no way to derive A → C from F. The only FD in F is A → B, and neither B nor A alone implies C. Using Armstrong's axioms on F:

From A → B alone, we can derive:
- A → A (reflexivity)
- A → B (given)
- A → AB (union/augmentation)
- AA → B (augmentation) which simplifies to A → B
- And similar trivial variations

None of these yield A → C. Since G implies A → C but F does not, F ≢ G (F and G are not equivalent).

Example 3: Equivalence Through Decomposition

Consider attributes {A, B, C} with:

FD Set F

•A → BC

FD Set G

•A → B
•A → C

Analysis: F has a single FD with a composite right-hand side, while G has two FDs with singleton right-hand sides.

From F: A → BC implies A → B and A → C (decomposition rule)
From G: A → B and A → C imply A → BC (union rule)

Each set can derive all FDs in the other, so F ≡ G.

This example demonstrates a crucial property: FDs with composite right-hand sides can always be replaced by singleton right-hand side FDs without changing the closure. This is fundamental to canonical cover computation.

Using Attribute Closure for Equivalence Testing

Computing full closures F⁺ and G⁺ to check if F⁺ = G⁺ is theoretically correct but practically infeasible—the closures can contain exponentially many FDs. Instead, we use attribute closures as an efficient tool.

Key Theorem: Equivalence via Attribute Closure

F ≡ G if and only if, for every FD (X → Y) ∈ F, we have Y ⊆ X⁺ᴳ (the attribute closure of X under G), AND for every FD (X → Y) ∈ G, we have Y ⊆ X⁺ᶠ (the attribute closure of X under F).

In other words:

Every FD in F must be derivable from G (check using G's attribute closure)
Every FD in G must be derivable from F (check using F's attribute closure)

Attribute Closure Algorithm
Pseudocode
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function ATTRIBUTE_CLOSURE(X, FDSet):
    // Computes X⁺ under the given FD set
    // X: set of attributes
    // FDSet: set of functional dependencies
    
    closure = X  // Start with X itself
    
    repeat:
        previous_closure = closure
        
        for each (A → B) in FDSet:
            if A ⊆ closure:       // If we have all of A
                closure = closure ∪ B  // Add B to closure
        
    until closure = previous_closure  // Fixed point reached
    
    return closure

Worked Example: Testing Equivalence

Let U = {A, B, C, D} and consider:

F = {A → B, B → C, C → D}
G = {A → B, A → C, A → D, B → C, C → D}

To test if F ≡ G, we verify mutual coverage.

Step 1: Check if G covers F (all FDs in F derivable from G)

Checking if each FD in F is derivable from G
FD in F	Compute X⁺ under G	Is Y ⊆ X⁺?	Result
A → B	{A}⁺ᴳ = {A, B, C, D}	B ⊆ {A,B,C,D}? Yes	✓ Covered
B → C	{B}⁺ᴳ = {B, C, D}	C ⊆ {B,C,D}? Yes	✓ Covered
C → D	{C}⁺ᴳ = {C, D}	D ⊆ {C,D}? Yes	✓ Covered

Step 2: Check if F covers G (all FDs in G derivable from F)

Checking if each FD in G is derivable from F
FD in G	Compute X⁺ under F	Is Y ⊆ X⁺?	Result
A → B	{A}⁺ᶠ = {A, B, C, D}	B ⊆ {A,B,C,D}? Yes	✓ Covered
A → C	{A}⁺ᶠ = {A, B, C, D}	C ⊆ {A,B,C,D}? Yes	✓ Covered
A → D	{A}⁺ᶠ = {A, B, C, D}	D ⊆ {A,B,C,D}? Yes	✓ Covered
B → C	{B}⁺ᶠ = {B, C, D}	C ⊆ {B,C,D}? Yes	✓ Covered
C → D	{C}⁺ᶠ = {C, D}	D ⊆ {C,D}? Yes	✓ Covered

Since all FDs in each set are derivable from the other, F ≡ G.

Notice that G contains explicitly what F derives implicitly (A → C, A → D). The sets look different but impose identical constraints.

Efficiency Note

This method requires computing attribute closure once for each FD's left-hand side. With n FDs and m attributes, this is O(n × m × |FDSet|)—polynomial time, far more efficient than computing exponential-sized full closures.

Mathematical Properties of Equivalence

FD set equivalence is an equivalence relation in the mathematical sense. This means it satisfies three fundamental properties, which have practical implications for database design.

Property 1: Reflexivity

Every FD set is equivalent to itself: F ≡ F

This is trivially true since F⁺ = F⁺.

Property 2: Symmetry

If F ≡ G, then G ≡ F

If F⁺ = G⁺, then G⁺ = F⁺. The definition is symmetric.

Property 3: Transitivity

If F ≡ G and G ≡ H, then F ≡ H

If F⁺ = G⁺ and G⁺ = H⁺, then F⁺ = H⁺.

Equivalence Classes

Because FD set equivalence is an equivalence relation, it partitions all possible FD sets into equivalence classes. Every FD set in a class has the same closure. This means we can choose any representative from the class—ideally the simplest one (the canonical cover).

Additional Important Properties

Beyond the basic equivalence relation properties, several other properties are important for practical applications.

Key Properties of FD Set Equivalence

•Decomposition Preservation — If F ≡ G, and we decompose A → BC to A → B and A → C in F to get F', then F' ≡ F ≡ G. The union and decomposition rules preserve equivalence.
•Redundancy Independence — Adding or removing redundant FDs (those derivable from others) doesn't change the equivalence class. This is the basis for canonical cover computation.
•Superkey Preservation — Equivalent FD sets identify exactly the same superkeys. If X is a superkey under F, then X is a superkey under any G with F ≡ G.
•Candidate Key Preservation — Equivalent FD sets have identical candidate keys. This ensures normalization decisions based on one FD set apply to all equivalent sets.
•Normal Form Invariance — If a relation is in 3NF (or BCNF) under F, it remains so under any G with F ≡ G. Normal form status is a property of the equivalence class, not individual FD sets.

Proof Sketch: Superkey Preservation

If X is a superkey under F, then X⁺ᶠ = U (X functionally determines all attributes under F).

Since F ≡ G implies F⁺ = G⁺, we have X ⊆ X⁺ᶠ = X⁺ᴳ.

Wait—we need to be careful. The closure of the FD set (F⁺) is different from attribute closure (X⁺ᶠ). However, X⁺ᶠ = U means U ⊆ X⁺ᶠ, which means X → A for every attribute A in U is in F⁺. Since F⁺ = G⁺, these same FDs are in G⁺, so X → A for all A, thus X⁺ᴳ = U, and X is a superkey under G. □

Visualizing FD Set Equivalence

A graphical perspective can help solidify understanding of FD set equivalence. Consider the following conceptual diagram showing how different FD sets can inhabit the same equivalence class.

Converting Mermaid diagram...

The diagram illustrates that F, G, and H all belong to the same equivalence class—they have identical closures and thus impose identical constraints. The canonical cover (the minimal representative) is typically chosen for practical use.

In contrast, F' belongs to a different equivalence class because its closure contains different FDs (specifically, A → D is not derivable from F, G, or H if D is a distinct attribute not determined by C in those sets).

Lattice View

Another useful visualization is the lattice of attribute closures. For a given FD set, we can plot the closure of each subset of attributes:

Attribute Closures Under F = {A→B, B→C}
Attribute Set X	Closure X⁺
{}	{}
{A}	{A, B, C}
{B}	{B, C}
{C}	{C}
{A, B}	{A, B, C}
{A, C}	{A, B, C}
{B, C}	{B, C}
{A, B, C}	{A, B, C}

Two FD sets are equivalent if and only if they produce identical attribute closure tables. This provides a comprehensive (though computationally intensive) way to verify equivalence.

Common Misconceptions About Equivalence

Students and practitioners often develop incorrect intuitions about FD set equivalence. Let's address the most common misconceptions.

Misconceptions to Avoid

•Misconception: Same number of FDs means equivalent — WRONG. {A → B} and {B → A} have the same cardinality but are not equivalent (they impose completely different constraints).
•Misconception: Subset implies non-equivalence — WRONG. F can be a proper subset of G while F ≡ G. Example: {A → B, B → C} ⊂ {A → B, B → C, A → C}, yet they're equivalent.
•Misconception: Same attributes on LHS/RHS means equivalent — WRONG. {A → B, B → A} is not equivalent to {A → B} even though both involve only A and B. The first set makes A and B equivalent (interchangeable), the second doesn't.
•Misconception: Equivalence can be checked by inspection — WRONG. Even simple FD sets require systematic closure computation. Intuition fails for anything beyond trivial cases.
•Misconception: Equivalence depends on actual data — WRONG. FD set equivalence is a purely logical property independent of any specific relation instance. It's about what constraints are imposed, not what data satisfies them.

The Safe Approach

Whenever you need to determine if two FD sets are equivalent, systematically compute attribute closures for each FD's left-hand side and verify coverage in both directions. Never trust intuition for non-trivial FD sets.

Summary: Understanding Equivalent Sets

We have established the foundation for understanding when two functional dependency sets impose identical constraints on a relation schema. Let's consolidate the essential concepts.

Key Takeaways

•Equivalence is semantic, not syntactic — Two FD sets are equivalent (F ≡ G) if and only if they have identical closures: F⁺ = G⁺.
•Mutual coverage defines equivalence — F ≡ G if F covers G (every FD in G is derivable from F) and G covers F (every FD in F is derivable from G).
•Attribute closure enables efficient testing — Rather than computing full closures, we check if each FD's RHS is in the attribute closure of its LHS under the other set.
•Equivalence is an equivalence relation — It satisfies reflexivity, symmetry, and transitivity, partitioning FD sets into equivalence classes.
•Equivalent sets preserve database properties — Superkeys, candidate keys, and normal forms are identical for all equivalent FD sets.
•Practical applications abound — Canonical covers, schema comparison, normalization verification, and design optimization all rely on equivalence testing.

What's Next:

Now that we understand what it means for FD sets to be equivalent, the next page explores the cover concept in depth. We'll examine what it means for one FD set to cover another (a weaker condition than equivalence) and how this asymmetric relationship is used in normalization algorithms.

Page Complete

You now understand the formal definition and properties of equivalent FD sets. This foundation is essential for computing canonical covers, verifying decompositions, and making sound database design decisions. Next, we'll explore the cover concept and its role in practical FD set manipulation.

Equivalent Sets

The Equivalence Question

This raises a fundamental question that lies at the heart of normalization theory: When do two sets of functional dependencies represent the same thing?

What You Will Learn

Why Equivalence Matters

Before diving into formal definitions, let's understand why the concept of FD set equivalence is absolutely essential to database theory and practice.

The Problem of Multiple Representations

When designing a database or analyzing an existing schema, you might discover functional dependencies in several ways:

From domain experts — Business analysts describe rules like "each employee has exactly one department"
From existing data — Data profiling tools extract patterns from actual records
From documentation — Previous designers left behind FD specifications
From inference — You derive new FDs using Armstrong's axioms

Syntactic vs. Semantic Difference

Critical Applications of Equivalence Testing

Understanding FD set equivalence enables several crucial database design activities:

Practical Applications

•Canonical Cover Computation — Reducing an FD set to its minimal equivalent form eliminates redundancy and simplifies normalization. This requires proving that the reduced set is equivalent to the original.
•Schema Comparison — When migrating between databases or consolidating systems, you must verify that different FD representations impose the same constraints.
•Normalization Verification — After decomposing a relation, you need to confirm that the FDs preserved by the decomposition are equivalent to (or cover) the original dependencies.
•Design Optimization — Identifying equivalent but simpler FD sets can reduce the number of constraints to enforce, lowering database overhead.
•Theoretical Proofs — Many database algorithms require proving that certain FD set transformations preserve equivalence.

Formal Definition of Equivalent FD Sets

We now establish the rigorous mathematical definition of equivalent functional dependency sets. This definition is the foundation upon which all equivalence testing algorithms are built.

Definition: Equivalence of FD Sets

Formally:

$$F \equiv G \iff F^+ = G^+$$

where F⁺ and G⁺ denote the closures of F and G respectively—the complete set of all functional dependencies that can be derived from F (or G) using Armstrong's axioms.

Understanding the Definition

Why Closures?

The closure F⁺ contains all FDs that are logically implied by F. If F = {A → B, B → C}, then F⁺ includes:

All FDs in F: A → B, B → C
All derived FDs: A → C (by transitivity), A → BC (by union), AB → C, etc.
All trivial FDs: A → A, AB → A, ABC → BC, etc.

Alternative Characterization

An equivalent and often more practical way to express equivalence uses the notion of covering:

Equivalence Definition
// Equivalence defined via mutual covering
F ≡ G   ⟺   (F covers G) ∧ (G covers F)
 
// Where "F covers G" means:
∀ (X → Y) ∈ G⁺ : (X → Y) ∈ F⁺
 
// In practical terms:
F covers G ⟺ every FD derivable from G is also derivable from F

This mutual covering characterization is foundational—it converts the problem of comparing infinite closure sets into checking whether each set's FDs can be derived from the other.

Building Intuition Through Examples

Abstract definitions become concrete through worked examples. Let's examine several cases that illustrate when FD sets are (or aren't) equivalent.

Example 1: Obvious Equivalence Through Transitivity

Consider a relation with attributes {A, B, C} and two FD sets:

FD Set F

•A → B
•B → C

FD Set G

•A → B
•B → C
•A → C

Analysis: G contains an extra FD (A → C) that F doesn't explicitly list. However, A → C can be derived from F using transitivity:

A → B (given in F)
B → C (given in F)
Therefore, A → C (transitivity)

Every FD in G is either in F or derivable from F. Conversely, every FD in F is clearly in G. Thus F⁺ = G⁺, and F ≡ G.

Key Insight

Adding an FD that is already logically implied by the existing FDs creates an equivalent set. This is the foundation for removing redundant FDs when computing canonical covers.

Example 2: Non-Equivalence Due to Missing Implication

Consider attributes {A, B, C} with:

FD Set F

•A → B

FD Set G

•A → B
•A → C

Analysis: G contains A → C, but there is no way to derive A → C from F. The only FD in F is A → B, and neither B nor A alone implies C. Using Armstrong's axioms on F:

From A → B alone, we can derive:
- A → A (reflexivity)
- A → B (given)
- A → AB (union/augmentation)
- AA → B (augmentation) which simplifies to A → B
- And similar trivial variations

None of these yield A → C. Since G implies A → C but F does not, F ≢ G (F and G are not equivalent).

Example 3: Equivalence Through Decomposition

Consider attributes {A, B, C} with:

FD Set F

•A → BC

FD Set G

•A → B
•A → C

Analysis: F has a single FD with a composite right-hand side, while G has two FDs with singleton right-hand sides.

From F: A → BC implies A → B and A → C (decomposition rule)
From G: A → B and A → C imply A → BC (union rule)

Each set can derive all FDs in the other, so F ≡ G.

Using Attribute Closure for Equivalence Testing

Key Theorem: Equivalence via Attribute Closure

In other words:

Every FD in F must be derivable from G (check using G's attribute closure)
Every FD in G must be derivable from F (check using F's attribute closure)

Attribute Closure Algorithm
Pseudocode
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function ATTRIBUTE_CLOSURE(X, FDSet):
    // Computes X⁺ under the given FD set
    // X: set of attributes
    // FDSet: set of functional dependencies
    
    closure = X  // Start with X itself
    
    repeat:
        previous_closure = closure
        
        for each (A → B) in FDSet:
            if A ⊆ closure:       // If we have all of A
                closure = closure ∪ B  // Add B to closure
        
    until closure = previous_closure  // Fixed point reached
    
    return closure

Worked Example: Testing Equivalence

Let U = {A, B, C, D} and consider:

F = {A → B, B → C, C → D}
G = {A → B, A → C, A → D, B → C, C → D}

To test if F ≡ G, we verify mutual coverage.

Step 1: Check if G covers F (all FDs in F derivable from G)

Checking if each FD in F is derivable from G
FD in F	Compute X⁺ under G	Is Y ⊆ X⁺?	Result
A → B	{A}⁺ᴳ = {A, B, C, D}	B ⊆ {A,B,C,D}? Yes	✓ Covered
B → C	{B}⁺ᴳ = {B, C, D}	C ⊆ {B,C,D}? Yes	✓ Covered
C → D	{C}⁺ᴳ = {C, D}	D ⊆ {C,D}? Yes	✓ Covered

Step 2: Check if F covers G (all FDs in G derivable from F)

Checking if each FD in G is derivable from F
FD in G	Compute X⁺ under F	Is Y ⊆ X⁺?	Result
A → B	{A}⁺ᶠ = {A, B, C, D}	B ⊆ {A,B,C,D}? Yes	✓ Covered
A → C	{A}⁺ᶠ = {A, B, C, D}	C ⊆ {A,B,C,D}? Yes	✓ Covered
A → D	{A}⁺ᶠ = {A, B, C, D}	D ⊆ {A,B,C,D}? Yes	✓ Covered
B → C	{B}⁺ᶠ = {B, C, D}	C ⊆ {B,C,D}? Yes	✓ Covered
C → D	{C}⁺ᶠ = {C, D}	D ⊆ {C,D}? Yes	✓ Covered

Since all FDs in each set are derivable from the other, F ≡ G.

Notice that G contains explicitly what F derives implicitly (A → C, A → D). The sets look different but impose identical constraints.

Efficiency Note

Mathematical Properties of Equivalence

FD set equivalence is an equivalence relation in the mathematical sense. This means it satisfies three fundamental properties, which have practical implications for database design.

Property 1: Reflexivity

Every FD set is equivalent to itself: F ≡ F

This is trivially true since F⁺ = F⁺.

Property 2: Symmetry

If F ≡ G, then G ≡ F

If F⁺ = G⁺, then G⁺ = F⁺. The definition is symmetric.

Property 3: Transitivity

If F ≡ G and G ≡ H, then F ≡ H

If F⁺ = G⁺ and G⁺ = H⁺, then F⁺ = H⁺.

Equivalence Classes

Additional Important Properties

Beyond the basic equivalence relation properties, several other properties are important for practical applications.

Key Properties of FD Set Equivalence

•Decomposition Preservation — If F ≡ G, and we decompose A → BC to A → B and A → C in F to get F', then F' ≡ F ≡ G. The union and decomposition rules preserve equivalence.
•Redundancy Independence — Adding or removing redundant FDs (those derivable from others) doesn't change the equivalence class. This is the basis for canonical cover computation.
•Superkey Preservation — Equivalent FD sets identify exactly the same superkeys. If X is a superkey under F, then X is a superkey under any G with F ≡ G.
•Candidate Key Preservation — Equivalent FD sets have identical candidate keys. This ensures normalization decisions based on one FD set apply to all equivalent sets.
•Normal Form Invariance — If a relation is in 3NF (or BCNF) under F, it remains so under any G with F ≡ G. Normal form status is a property of the equivalence class, not individual FD sets.

Proof Sketch: Superkey Preservation

If X is a superkey under F, then X⁺ᶠ = U (X functionally determines all attributes under F).

Since F ≡ G implies F⁺ = G⁺, we have X ⊆ X⁺ᶠ = X⁺ᴳ.

Visualizing FD Set Equivalence

A graphical perspective can help solidify understanding of FD set equivalence. Consider the following conceptual diagram showing how different FD sets can inhabit the same equivalence class.

Converting Mermaid diagram...

Lattice View

Another useful visualization is the lattice of attribute closures. For a given FD set, we can plot the closure of each subset of attributes:

Attribute Closures Under F = {A→B, B→C}
Attribute Set X	Closure X⁺
{}	{}
{A}	{A, B, C}
{B}	{B, C}
{C}	{C}
{A, B}	{A, B, C}
{A, C}	{A, B, C}
{B, C}	{B, C}
{A, B, C}	{A, B, C}

Two FD sets are equivalent if and only if they produce identical attribute closure tables. This provides a comprehensive (though computationally intensive) way to verify equivalence.

Common Misconceptions About Equivalence

Students and practitioners often develop incorrect intuitions about FD set equivalence. Let's address the most common misconceptions.

Misconceptions to Avoid

•Misconception: Same number of FDs means equivalent — WRONG. {A → B} and {B → A} have the same cardinality but are not equivalent (they impose completely different constraints).
•Misconception: Subset implies non-equivalence — WRONG. F can be a proper subset of G while F ≡ G. Example: {A → B, B → C} ⊂ {A → B, B → C, A → C}, yet they're equivalent.
•Misconception: Same attributes on LHS/RHS means equivalent — WRONG. {A → B, B → A} is not equivalent to {A → B} even though both involve only A and B. The first set makes A and B equivalent (interchangeable), the second doesn't.
•Misconception: Equivalence can be checked by inspection — WRONG. Even simple FD sets require systematic closure computation. Intuition fails for anything beyond trivial cases.
•Misconception: Equivalence depends on actual data — WRONG. FD set equivalence is a purely logical property independent of any specific relation instance. It's about what constraints are imposed, not what data satisfies them.

The Safe Approach

Summary: Understanding Equivalent Sets

We have established the foundation for understanding when two functional dependency sets impose identical constraints on a relation schema. Let's consolidate the essential concepts.

Key Takeaways

•Equivalence is semantic, not syntactic — Two FD sets are equivalent (F ≡ G) if and only if they have identical closures: F⁺ = G⁺.
•Mutual coverage defines equivalence — F ≡ G if F covers G (every FD in G is derivable from F) and G covers F (every FD in F is derivable from G).
•Attribute closure enables efficient testing — Rather than computing full closures, we check if each FD's RHS is in the attribute closure of its LHS under the other set.
•Equivalence is an equivalence relation — It satisfies reflexivity, symmetry, and transitivity, partitioning FD sets into equivalence classes.
•Equivalent sets preserve database properties — Superkeys, candidate keys, and normal forms are identical for all equivalent FD sets.
•Practical applications abound — Canonical covers, schema comparison, normalization verification, and design optimization all rely on equivalence testing.

What's Next:

Page Complete