Can two objects with identical attributes be different?

Yes. Their identities can be distinct even when their current values are equal.

Does changing an attribute always create a new identity?

No. A mutable object can retain identity while its state changes, according to the model.

Is an object identifier necessarily a universal real-world identifier?

No. Its scope, persistence, and portability depend on the system and application contract.

AI Glossary / Data engineering and architecture / Intermediate

Existence-Based Identity

Definition

Existence-based identity describes object identity that is independent of an object's current attribute values. Two objects can contain equal values and still be distinct objects, while one object can change its values and retain its identity. The phrase belongs to object-oriented data modeling and database discussions. It does not mean biometric identity verification or proof that a real-world person exists.

What it means

Imagine two equipment objects with the same model, color, and purchase date. They may represent two separate machines even though every listed attribute currently matches. Conversely, repairing one machine may change its condition and location without creating a different machine in the model. Existence-based identity separates the question “which object is this?” from “what values does it currently have?” That separation supports references that remain meaningful through state changes.

How it works

A system provides an identity mechanism, often represented by an object identifier or reference, and keeps it distinct from ordinary mutable properties. References can point to the same object even when those properties change. Creating a separate object with identical properties normally creates a separate identity unless an explicit operation says otherwise. Persistence, copying, deletion, and cross-system transfer require defined semantics. An identifier's scope and lifetime depend on the implementation; an internal object identifier should not automatically be assumed globally portable or permanent.

Three practical examples

Asset systems: two identical devices remain separate objects, each with its own service history and references.
Collaborative applications: several documents can reference one shared author object, and a name change need not require treating the author as a new object.
AI data management: two stored annotation objects may have identical text and labels while representing separate annotation events, so value equality alone should not merge their provenance.

Think of it this way

Think of two identical printed notebooks. Their covers and blank pages can be indistinguishable, yet they are two separate physical items. Writing in one changes its state without turning it into the other notebook. The analogy is limited because software identity is governed by a model and implementation, not physical continuity. Copying, exporting, or restoring an object needs explicit rules rather than relying on intuition about physical objects.

Worked example

A toy system creates objects O1 and O2, both with Name = “Pump” and Status = “Ready.” Their values match, but O1 and O2 are distinct identities. References R1 and R2 both point to O1, while R3 points to O2. Updating O1's status to “Inspection” means R1 and R2 still refer to O1 and observe its changed state under the system's access rules; O2 remains Ready. Creating O3 by copying O1's attributes does not automatically make O3 identical to O1. If a migration exports only Name and Status, it loses the information needed to reconstruct which references shared the same object. The migration must preserve or deliberately remap identity as well as values. These names are illustrative identifiers, not a specification of any vendor's identifier format.

Illustrative case study

Fictional example: Elm Design stores reusable component objects in several assemblies. A migration tool initially duplicates every referenced component, creating separate objects with matching properties. The assemblies still look correct, but later edits no longer affect the intended shared component. The team revises the migration to preserve shared identity through an explicit mapping. This invented case demonstrates the difference between copying values and preserving reference structure; it does not claim a measured migration result or require a particular database product.

Common misconceptions and mistakes

Do not confuse identity equality with value equality or deep equality. Do not assume an object's memory address is a suitable persistent identifier. Avoid claiming that relational databases cannot maintain stable business identity: relational designs can use keys, including surrogate keys, although their formal model and mechanisms differ from object identity. Also distinguish model identity from real-world entity resolution. Assigning two records different object identifiers does not prove that they describe different people or organizations.

Business use

The distinction matters in migrations, deduplication, shared structures, audit trails, and systems that track changing objects. Decide which things need stable identity and which are simply values, such as an amount or a color. Document whether copying creates a new object, whether references survive updates, and what happens when an object is deleted. For AI datasets, preserve event and source identity when identical content represents different observations. Content-based deduplication can be useful, but it should not silently erase meaningful provenance.

Check your understanding

Two references point to the same object, and a third points to a separate equal-valued object. If the shared object changes, must all three refer to the changed object?

Answer: No. The first two preserve their shared reference to that object; the third still identifies the separate object. Equal initial values did not establish shared identity.

Related terms

Deep Equality
Surrogate key
Aliasing (factorial experiments)
object identity
object identifier
reference
value equality
entity resolution
aliasing
object persistence
object-oriented database

Learn next

draw a small object graph containing one shared object and two separate equal-valued objects. Compare an identity-preserving export with a values-only copy. Then write the intended rules for updates, copying, deletion, and importing identifiers into another system.

Sources

Sources: The Object-Oriented Database System Manifesto, Object Identity, https://www.cs.cmu.edu/afs/cs/user/clamen/OODBMS/Manifesto/htManifesto/node4.html ; NIST, Proceedings of the Object-Oriented Database Task Group workshop, https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir4503.pdf ; Oracle, Introduction to Oracle Objects, https://docs.oracle.com/database/121/ADOBJ/adobjint.htm . Primary-source search excerpts consulted for identity independent of values and implementation identifiers. Oracle is a versioned example; object-copy and migration scenarios are original illustrations.

Previous: Exhaustive decomposition Next: Existence uncertainty