Must each attribute appear only once?

No. The union condition permits overlap between component schemas.

Is the property about keeping all rows?

No. It concerns the schema's attributes; row-level information preservation requires other analysis.

Can a field be deliberately removed?

Yes, if requirements change, but that is not attribute preservation with respect to the unchanged original schema.

AI Glossary / Data engineering and architecture / Intermediate

Attribute Preservation Property

Definition

The attribute preservation property requires the relation schemas in a decomposition to contain, collectively, every attribute of the original relation schema. If R is decomposed into R1 through Rn, their attribute sets must have union R. It ensures that no original column is simply omitted, but does not by itself ensure that the original rows can be reconstructed correctly.

What it means

Database normalization often replaces one wide relation with several smaller relations. Attribute preservation is the basic coverage check: every original attribute must have a place in the new design.

For R(A, B, C), the decomposition R1(A, B) and R2(B, C) preserves attributes because their union is A, B, C. The shared B appears in both schemas, which is allowed. The property does not require each attribute to appear exactly once.

The term concerns attribute sets, not a migration's row counts, data values or display labels. A schema can retain all its columns across tables yet lose important associations between their values. Those associations are addressed by additional properties, especially lossless join.

How it works

List the original schema's attributes and the attributes in each proposed component. Form the set union of the component attributes and compare it with the original set. In a decomposition of R, each component is itself a subset of R, and the union should equal R.

If an attribute is missing, decide where it belongs before accepting the decomposition. If a migration intentionally removes an obsolete field, record that as a deliberate change of requirements rather than claiming preservation of the original schema.

After coverage, analyze lossless join: does joining the projected component relations reproduce exactly the valid original relation? Also analyze dependency preservation: can the original constraints be enforced through the component dependencies without reconstructing the full relation?

These tests answer different questions. A checklist of column names cannot prove either of the latter properties. Likewise, matching a few sample query results is useful testing but not a general proof for all valid data permitted by the constraints.

Three practical examples

A designer checks that splitting a customer-order relation into customer and order relations leaves every original attribute represented.
A migration reviewer compares the source attribute inventory with the proposed normalized schemas before examining joins and constraints.
An AI-assisted schema tool reports an omitted status field instead of presenting the decomposition as complete merely because the remaining tables look well organized.

Think of it this way

Think of dividing a document into folders while checking that every labeled section goes into at least one folder. This verifies that no section heading was forgotten.

The analogy has a limit: preserving the sections does not necessarily preserve how their pages were related. If page references are lost, assembling the folders may create the wrong story. Database attribute preservation similarly needs a separate check that relationships between values can be reconstructed without inventing combinations.

Worked example

All columns present, but the join is wrong

Consider an invented relation R(A, B, C) containing two rows: (a1, b1, c1) and (a2, b1, c2). Assume no additional dependency makes B determine A or C.

Projecting onto R1(A, B) gives (a1, b1) and (a2, b1). Projecting onto R2(B, C) gives (b1, c1) and (b1, c2). The schemas preserve attributes because {A, B} union {B, C} equals {A, B, C}.

However, joining on B produces four rows. Besides the original two, it produces (a1, b1, c2) and (a2, b1, c1). Every column survived, but the original pairing of A with C did not.

This counterexample shows why attribute preservation alone is insufficient. Additional valid constraints might justify a particular decomposition, but they must be stated and checked. Simply observing that the components share B is not enough to prove losslessness.

Illustrative case study

A fictional training company asks an assistant to split a wide enrollment record into learner, course and participation tables. The first proposal places every field except cancellation reason. The coverage review catches that omission before a migration is attempted.

The revised proposal includes the field, but the team continues reviewing identity and joins. It checks that participation records link to the correct learner and course and that repeated enrollments are not merged accidentally. Small examples include a learner taking the same course in two different sessions.

The case illustrates a useful sequence: first ensure every required attribute has a home, then verify that the schema retains the intended facts and constraints. Coverage alone does not complete the design review.

Common misconceptions and mistakes

Preserving all attributes guarantees a lossless decomposition. The worked example preserves columns while introducing spurious joined rows.
An attribute appearing in two component schemas violates preservation. Shared attributes are allowed and often support reconstruction.
Attribute preservation and dependency preservation mean the same thing. One checks column coverage; the other concerns preserving enforceable dependency rules.

Business use

Attribute preservation is a practical first check when normalizing a schema, replacing a legacy database or reviewing generated designs. An attribute inventory helps business owners notice fields that technical teams might regard as unimportant but reporting or operations still need.

Map attributes by meaning, not just spelling. Renamed fields, split representations and combined fields require explicit mappings; those transformations go beyond the simple set-union test. Document them rather than treating similar names as proof of equivalent information.

For AI projects, include evaluation labels, timestamps and provenance fields in the inventory. Losing one can leave a dataset apparently usable while undermining later interpretation. Follow coverage checks with constraints, sample reconstructions and tests of the questions users must still be able to answer.

Check your understanding

Does decomposing R(A, B, C, D) into R1(A, B) and R2(B, C) preserve attributes?

Answer: No. D is absent from the union of the component schemas. Adding a place for D fixes coverage, but lossless join and dependency preservation still require separate checks.

Related terms

Relation Schema
Decomposition
Functional dependency
Normalization
Schema migration
projection
lossless join
dependency preservation

Learn next

Read lossless-join decomposition. Draw a three-column relation with two rows, project it into two schemas and join the results manually to distinguish column coverage from preservation of row associations.

Lossless join decomposition

Sources

Emory University, Second Normal Form and decomposition: https://www.cs.emory.edu/~cheung/Courses/377/Syllabus/9-NormalForms/2NF-2.html. Primary teaching notes state that a decomposition contains every original attribute.

Emory University, Lossless decomposition: https://www.cs.emory.edu/~cheung/Courses/377/Syllabus/9-NormalForms/New/lossless.html. Primary teaching material on reconstruction conditions.

Emory University, Decompositions that preserve Functional Dependencies: https://www.cs.emory.edu/~cheung/Courses/377/Syllabus/9-NormalForms/FD-preserve.html. Primary distinction concerning dependency enforcement. The counterexample and training-company case are original illustrations.

Previous: Attribute-based extraction Next: Attribute sampling