Why is it also called the union rule?

It takes the set union of the determined attributes while keeping the same determinant.

Is it one of the three basic Armstrong axioms?

In the standard presentation it is a derived rule, provable from the basic axioms.

Yes. Set union includes any shared attribute once; disjointness is not required.

AI Glossary / Data engineering and architecture / Intermediate

Additive Rule

Definition

The additive rule, also called the union rule, is an inference rule for functional dependencies in relational database theory. If the same set of attributes X determines Y and also determines Z, then X determines the combined set Y union Z. It combines dependency statements, not database rows or numerical values.

What it means

A functional dependency says that any two valid rows agreeing on the determining attributes must also agree on the determined attributes. If EmployeeID determines Department and EmployeeID determines Office, then EmployeeID determines the pair Department and Office.

The word additive refers to collecting the right-hand attribute sets under a shared determinant. It does not mean adding the values in those columns. The rule is also unrelated to SQL UNION, which combines compatible query results.

Dependencies describe rules for valid data, not just patterns in one extract. A sample with one row per employee may happen to satisfy many dependencies that the business does not guarantee. Applying the additive rule to unjustified assumptions produces an unjustified design conclusion, even though the inference rule itself is sound.

How it works

Write the dependencies as X → Y and X → Z. The rule yields X → YZ, where juxtaposition denotes set union. Repeated attributes appear only once because these are sets.

The reasoning follows the definition directly. Choose any two rows with equal X values. The first dependency requires them to agree on Y; the second requires them to agree on Z. Therefore they agree on every attribute in the combined set.

The additive rule can be derived from Armstrong's axioms, rather than requiring a separate assumption about data. The standard basic axioms are reflexivity, augmentation and transitivity. Distinguish derived rules from basic axioms.

The reverse decomposition rule splits X → YZ into X → Y and X → Z. These transformations can help organize dependency sets and reason about attribute closures, keys and normalization. They do not, by themselves, prove that the determinant is a minimal key.

Three practical examples

A database designer combines ProductCode → ProductName and ProductCode → Unit into ProductCode → ProductName, Unit when these are valid product rules.
A data governance team records that a versioned policy identifier determines both its owner and its effective date, keeping the version qualification explicit.
A schema analysis tool groups several dependencies with the same determinant into one statement before further dependency reasoning.

Think of it this way

Think of an official reference number that reliably identifies both a document's title and its issuing department. If those two facts are each fixed by that reference number, the number also identifies their pair.

The analogy depends on the reference number's meaning. If numbers are reused across years, the year may need to join the determinant. The inference cannot repair a reference scheme that fails to identify a stable record, nor does it say the title identifies the reference number in reverse.

Worked example

Combining valid dependencies

Consider an invented catalog relation with attributes ItemID, Name, Unit and Supplier. Its stated rules include ItemID → Name and ItemID → Unit. The additive rule gives ItemID → Name, Unit.

Suppose two rows have ItemID K7. Under these rules, both must give the same Name and Unit. One could list Supplier S1 and the other Supplier S2 without contradicting either dependency, because no dependency from ItemID to Supplier has been stated.

It would therefore be incorrect to conclude ItemID → Name, Unit, Supplier using the additive rule. The supplier attribute has no supporting premise.

Likewise, the combined dependency does not imply Name, Unit → ItemID. Two distinct items may share a name and unit. A dependency's direction matters, and combining right-hand attributes does not make the relationship reversible.

Illustrative case study

A fictional equipment directory uses AssetTag → Location and AssetTag → Custodian as design assumptions. An analyst combines them correctly, then notices that historical records show several locations for one tag.

The team discovers that the intended relation stores assignments over time, not just the current assignment. It revisits the model and defines the appropriate version or validity-period representation before declaring dependencies. It does not treat the additive rule as evidence that legitimate history should be deleted.

The case shows that a logically correct inference can expose an incorrect modeling assumption. Time, identifier reuse and the intended meaning of a row must be settled before inferred dependencies guide normalization or data cleaning.

Common misconceptions and mistakes

The additive rule adds numerical column values. It combines sets of attributes on the right of dependency statements.
Dependencies with unrelated determinants can always be merged under either determinant. The rule requires the same determining set in both premises.
A combined dependency proves a candidate key. A candidate key must determine every attribute and be minimal; neither condition follows automatically from an arbitrary combined dependency.

Business use

The additive rule helps make data rules concise and inspectable. Teams can compare what an identifier is expected to determine against what a schema actually stores. This is useful when consolidating metadata from several departments or analyzing a proposed redesign.

For AI-assisted database design, require the assistant to state its premises. A suggested key or normalization step should be justified by business dependencies, with temporal scope and exceptions explained. Merely observing a clean sample is weaker evidence than a documented invariant.

Separate inference from enforcement. A dependency written in a design document does not automatically become a database constraint. Decide how the chosen schema, keys, validation and update procedures will maintain the intended rules, then test contradictory records deliberately.

Check your understanding

Given AccountID → Region and AccountID → ServiceTier, what does the additive rule establish?

Answer: AccountID → Region, ServiceTier. It does not establish the reverse dependency or determine other unstated attributes.

Related terms

Functional dependency
Candidate key
Normalization
union rule
Armstrong's axioms
augmentation
transitivity
decomposition rule
attribute closure

Learn next

Read functional dependencies and attribute closure. Write three justified dependencies with one determinant, combine their right-hand sets and identify which remaining attributes still lack a derivation.

Sources

Silberschatz, Korth and Sudarshan, Database System Concepts, relational design slides: https://www.db-book.com/Previous-editions/db4/slide-dir/ch7-2.pdf. Primary textbook materials state the union rule and its derivability.

Database System Concepts, practice answers: https://www.db-book.com/db6/practice-exer-dir/8s.pdf. Primary author materials provide an Armstrong-axiom proof.

Emory University, Functional Dependencies: https://www.cs.emory.edu/~cheung/Courses/377/Syllabus/9-NormalForms/FuncDepend1.html. Primary teaching notes explain the two-row definition. The catalogue and equipment cases are original illustrations.

Previous: Additive regression Next: Additive value function