Can value-based identity use more than one attribute?

Yes. A combination can identify an entity when individual fields cannot.

Is a title usually sufficient evidence of identity?

Not without a domain rule establishing the required uniqueness and stability.

Does a surrogate key eliminate business duplicates?

No. It distinguishes stored records, but duplicate-entity detection still needs appropriate rules and evidence.

AI Glossary / Data engineering and architecture / Advanced

Value-Based Identity

Definition

Value-based identity distinguishes entities using selected attribute values that carry meaning in the modeled domain. In the natural-key design context used here, a natural attribute or combination of attributes serves as the identifying key. This differs from assigning a separate identifier solely to distinguish each entity. The chosen values must genuinely identify the intended entity within the stated scope; matching arbitrary descriptive fields is not enough.

What it means

A resource might be identified by the combination of publisher code and that publisher's local resource code. Neither field needs to be globally unique on its own if the combination is unique under the business rules. This is an identity decision, not merely a convenient search filter. In an original AI catalog, two resources with the same title may still be different resources. Conversely, two incoming records with the same valid identifying combination may describe the same resource even if one has a corrected title. The interpretation depends on the domain's actual identification rules.

How it works

The designer selects attributes whose combination identifies an entity, defines their scope and equality rules, and enforces the corresponding constraints. PostgreSQL documents primary keys spanning one or more columns, with uniqueness and non-null requirements, and foreign keys that maintain references. Those mechanisms can implement a chosen value-based identification rule, but they cannot prove that the rule matches the business. Before adoption, check whether the values can change, be reassigned or collide across organizations. A generated surrogate key is another design option, but it does not remove the need to recognize valid business duplicates.

Three practical examples

A publisher catalog identifies a resource by publisher code together with a publisher-assigned local code.
An AI import assistant matches incoming records using an approved composite key rather than merging resources by title similarity.
A data-design review checks whether an apparent natural identifier remains unique across the full geographic or organizational scope.

Think of it this way

Imagine finding a seat using a section label and a seat number. Seat 12 alone is ambiguous when several sections each have a seat 12. Section B together with seat 12 identifies a place within the venue's seating plan. The analogy illustrates contextual, composite identification. If several venues are included, the rule needs the venue context too; an identifier's usefulness depends on the scope in which it is unique.

Worked example

Consider an original fictional catalog with three resources identified by (PublisherCode, LocalCode): (P1, A7), (P1, A8) and (P2, A7). Assume publisher codes are unique in this catalog, each publisher assigns one local code per resource, and codes are not reused within the reporting scope. The three pairs identify three resources. LocalCode A7 occurs twice, so using it alone would incorrectly merge the first and third resources. An incoming record for (P1, A7) with a corrected description refers to the first resource under the stated rule; it does not introduce a fourth identity. An incoming record for (P2, A8) introduces a new combination and could represent a fourth resource once its validity is verified. If P1 later changes A7 to A9, the application needs an explicit policy for references and continuity. A key-value change is not, by itself, evidence that a new real-world resource has been created.

Illustrative case study

In a fictional AI publishing platform, an import process deduplicates records by local code and accidentally combines resources from two publishers. Reviewers reproduce the error using A7 from P1 and P2. They confirm the publisher-specific coding rules, adopt the composite identification rule and inspect affected records before repairing the merge. They also document how code changes and retired codes should be handled. The assistant may suggest candidate matches, but it does not override the approved identity rule using title similarity. The scenario illustrates correcting an incomplete scope assumption, not proof that natural keys are always preferable to separate generated identifiers.

Common misconceptions and mistakes

Value-based identity does not require comparing every visible attribute. A carefully chosen identifying combination may be enough. Nor does matching a name prove identity; names can repeat or change. Another mistake is treating uniqueness in a small sample as a permanent business guarantee. A key that is unique within one publisher may collide when catalogs are combined. Reassigning old codes can also confuse historical references. Finally, adding a surrogate identifier does not automatically detect duplicate real-world entities: distinct generated values can still be assigned to duplicate records unless the business rules are checked separately.

Business use

For an AI-assisted catalog or integration, define identity before automating matching, merging or updates. In the fictional publisher catalog, record the scope of local codes and whether reuse is permitted. Test cross-publisher collisions and corrections, not just clean examples from one source. Plan how references, historical versions and external links behave if identifying values change. Choose natural or surrogate keys based on these requirements and the storage design. This reduces the risk that a convenient matching field becomes an unexamined identity policy that silently combines different resources or duplicates the same one.

Check your understanding

How many resources do the three toy pairs identify?

Answer: Three.

Why is A7 insufficient by itself?

Answer: It appears under two different publishers.

Does correcting the description for (P1, A7) create a new identity under the rule?

Answer: No.

What must be considered if its local code changes?

Answer: Reference handling and continuity of the real-world entity.

What unsupported assumption would make this example unsafe?

Answer: Assuming publisher codes or local codes are unique and unreused without checking the stated scope.

Related terms

Natural key
Composite key
Surrogate key
Candidate key
object identity
entity resolution

Learn next

Choose a fictional catalog and propose a natural identifying combination. Create examples that repeat each individual field while keeping the full combination unique. Then introduce a code correction and a code-reuse case. Explain how the design preserves references and distinguishes continuity from creation of a new entity.

Sources

PostgreSQL documentation, Constraints, including Primary Keys and Foreign Keys: https://www.postgresql.org/docs/current/ddl-constraints.html Andrea Bignamini, INAF-OATs, Data Model training, slide 56: https://indico.ict.inaf.it/event/2668/contributions/17113/attachments/7867/16240/Data%20Model.pdf . This instructor source supports the natural-key scope used here. The publisher-code example, seating analogy and AI import scenario are original educational illustrations. Database constraints implement a selected rule; they do not independently establish the correctness of its business meaning.

Previous: Value alignment Next: Value imputation