Is this the same as set complement?

It uses attribute-set subtraction, but the full rule makes a statement about multivalued dependencies in a specified relation.

Does it prove that a decomposition preserves every constraint?

No. A broader design review must examine lossless reconstruction and the preservation of relevant dependencies.

Can the complement contain several attributes?

Yes. Those attributes form one group. The rule does not automatically establish that the members of that group are mutually independent.

AI Glossary / Data engineering and architecture / Advanced

Complementation Rule

Definition

The complementation rule is an inference rule for multivalued dependencies in relational databases. If X multidetermines Y within a relation R, then X also multidetermines the attributes remaining after X and Y are removed from R.

What it means

A multivalued dependency expresses independence between groups of attributes for a fixed value of another group. For example, a product's available colors might vary independently of its available sizes. If every offered color is available in every offered size, the table contains all the corresponding combinations for that product.

Complementation describes the same independence from the other side. If the color choices are independent of sizes, the size choices are independent of colors. The relation's complete attribute set is essential: the “other side” means all remaining attributes together.

This does not say a product has only one color or one size. Nor does it say that an arbitrary product catalog must offer every possible combination. Independence is a business assumption that must be established before applying the rule.

How it works

Write X →→ Y for the original multivalued dependency. Let Z = R − (X ∪ Y), meaning the attributes belonging to neither X nor Y. The complementation rule gives X →→ Z.

To apply it, list every attribute in R, mark those in X and Y, and retain the unmarked attributes as a group. Do not silently remove attributes just because they seem unimportant. The dependency concerns the whole relation under discussion.

The row-based explanation is symmetrical. For two rows agreeing on X, the dependency requires rows exchanging the Y and Z portions while keeping X fixed. Calling Y the varying side or Z the varying side describes the same required combinations. It is a logical property of allowed relations, not a command that automatically inserts missing rows.

Three practical examples

1. Product options: where colors and sizes really are independently offered for each product, a designer can describe either side as multidependent on the product identifier.

2. Event planning: if an event's supported languages and meal choices can be combined freely, an analyst can express the language independence or the meal independence. A restricted language-meal package would invalidate that premise.

3. AI schema review: a model proposes splitting a wide configuration table into independent option lists. A reviewer writes the multivalued dependency and its complement, then checks whether real configurations obey the assumed combinations before accepting the split.

Think of it this way

Think of a menu with two independent choices: a drink and a snack. If every listed drink can accompany every listed snack, looking down the drink list or across the snack list describes the same freedom. The analogy stops working if some pairings are forbidden. Database complementation likewise depends on the actual independence rule, not merely on having two lists.

Worked example

Take R(Product, Colour, Size). For product P7, the allowed colors are blue and white, and the allowed sizes are small, medium and large. Assume all combinations are offered.

The table contains six rows: blue-small, blue-medium, blue-large, white-small, white-medium and white-large, each with Product = P7. Product →→ Colour holds. Removing Product and Colour from R leaves Size, so complementation gives Product →→ Size.

Now suppose white-large is not offered. Keeping the other five rows does not satisfy the original independence assumption. The blue-large and white-small records would require white-large when their color and size portions are exchanged. Complementation does not authorize inventing that unavailable item.

The calculation shows both the inference and its boundary. Six combinations follow from the stated independent choice sets; they are not a universal requirement for all product tables.

Illustrative case study

Illustrative fictional case: Seabrook Kits stores Kit, Finish, Accessory and Region in one catalog. An assistant assumes finishes are independent of everything else and recommends separate lists for finishes, accessories and regions.

A designer checks the proposed dependency Kit →→ Finish. Its complement is Kit →→ {Accessory, Region}, treating the last two attributes together. It does not establish that accessories and regions are independent of each other.

The business confirms that accessories have regional restrictions. The team retains the accessory-region pairings and separately evaluates finish independence. This fictional case shows why “the remaining attributes” must stay grouped; it does not claim that complementation alone selects a complete final database design.

Common misconceptions and mistakes

Do not replace the double arrow with a functional-dependency arrow: independent multiple values do not imply a single value. Do not read “complement” as all values absent from the database; the operation here concerns attribute sets.

Do not split a multi-attribute complement into separate dependencies without justification. Do not transfer the rule to a different schema while ignoring its changed attribute universe. Finally, a complete-looking sample may be accidental. Confirm that the business intends the dependency to hold for future allowed records.

Business use

Use the rule when discussing multivalued dependencies, redundancy and fourth normal form. It can make an independence assumption easier for stakeholders to inspect by expressing both sides explicitly.

For an AI-generated model, ask for a small valid example and a deliberately forbidden combination. If the proposed decomposition recreates the forbidden combination when joined, the independence assumption needs revision. Keep that counterexample in the design notes so later developers understand why certain attribute pairings must remain associated.

Check your understanding

In R(A, B, C, D), A →→ B holds. What does complementation establish?

Answer: A →→ {C, D}. Remove A and B from the complete attribute set. You cannot infer A →→ C and A →→ D separately from complementation alone.

Related terms

Learn next

Practice identifying the full attribute universe before applying complementation. Next, compare a table containing every permitted combination with one containing a deliberate restriction. Then study fourth normal form and why independent facts may be represented in separate relations.

Fourth Normal Form

Sources

Silberschatz, Korth and Sudarshan, Database System Concepts, Advanced Relational Database Design, complementation and multivalued dependencies: https://www.db-book.com/online-chapters-dir/28.pdf

Elmasri and Navathe, teaching material on multivalued dependencies and fourth normal form: https://eecs.csuohio.edu/~sschung/cis611/ENACh11-Further-Dependencies_Chap16.pdf

Sibel Adali, Rensselaer Polytechnic Institute, database normalisation course notes, requirements and dependency interpretation: https://www.cs.rpi.edu/~sibel/csci4380/fall2018/course_notes/normalization.html

The catalogue examples are original illustrations.

Previous: Complementary literals Next: Complementizers