AI Glossary / Data engineering and architecture / Intermediate

Identifier Domain

Definition

An identifier domain is the defined set and representation of values used to identify entities or records in a particular context. It may be implemented as a reusable database domain or type, or documented as a logical identifier convention. Examples include customer identifiers or document-version identifiers. The phrase is context-dependent and should not be confused with an internet domain name or a complete identity-management system.

What it means

An identifier is meaningful within a scope. Customer 125 in one system need not be the same customer as 125 in another. A domain can specify format and allowed values, but uniqueness, referential integrity, and assignment rules require additional mechanisms. Choosing an integer type for identifiers does not make every integer a valid existing customer, nor does it prove that two assigned identifiers represent different real-world people.

How it works

Define what the identifier identifies, its scope, representation, allowed values, and lifecycle. Decide whether it is assigned centrally, generated by an application, imported from another system, or constructed from several components. Enforce suitable type and format rules, then use keys and references to enforce relationships where appropriate. Preserve the domain's semantics across interfaces. A database CREATE DOMAIN feature can help reuse constraints, but a named domain alone does not implement all identity rules or prevent every accidental cross-domain comparison.

Three practical examples

• Customer integration: an import keeps SourceSystem and CustomerID together so identical local numbers from different systems are not merged accidentally.
• Content management: document and document-version identifiers are distinguished because one identifies a continuing document and the other a specific revision.
• AI provenance: dataset examples retain stable source-record identifiers with their documented scope, allowing a reviewer to trace an observation back to its origin.

Think of it this way

Think of a ticket number printed together with the name of the event. Number 42 at one event is different from number 42 at another. The analogy is limited because software identifiers can be composite, generated across systems, and retained long after the original record changes. The printed number also does not prove that the ticket is valid; validity depends on the issuing system and its records.

Worked example

System A has customer identifiers 00125 and 00126, while system B has customer identifier 00125 for a different customer. A merged table using only CustomerID would create a collision. Using the pair (SourceSystem,CustomerID) preserves A/00125, A/00126, and B/00125 as distinct source identities. If leading zeros are meaningful in the identifier contract, converting 00125 to integer 125 changes its representation and may break matching with the source. A format rule accepting five digits can reject malformed values, but it cannot establish that 00999 was actually issued. A foreign key to a valid customer register can address existence within the database, while entity resolution remains a separate task if A and B sometimes describe the same person.

Illustrative case study

Fictional example: Alder Publishing imports article identifiers from two editorial systems. One uses numbers local to each publication, and the other uses globally assigned strings. The team documents each domain and creates an explicit mapping into the new catalog. It retains source identifiers instead of assuming numerical equality implies the same article. This invented case illustrates scope management; it does not claim that any particular generation scheme is universally collision-free or that mapping identifiers automatically resolves duplicate content.

Common misconceptions and mistakes

Do not assume identifiers must be positive integers or that arithmetic on them is meaningful. Do not infer uniqueness from a format or field name. Avoid reusing retired identifiers for new entities when historical references would become ambiguous. Also distinguish identifier value from descriptive attributes: a person's name or an article title can change and may not be unique. Some systems use natural keys successfully, but their stability and scope must be justified rather than assumed.

Business use

A clear identifier domain improves integrations, traceability, and schema design. Document formatting, case sensitivity, leading-zero treatment, allowed characters, uniqueness scope, and reuse policy. Test exports and spreadsheet handling that may alter identifiers unintentionally. For AI systems, preserve the distinction between entity identifiers, event identifiers, and content hashes. They support different questions about identity and duplication. Establish how identifiers are mapped across systems and how unresolved or conflicting mappings are recorded for review.

People also ask

Does a named identifier domain enforce uniqueness?

Not by itself. A unique or primary-key constraint, or another suitable assignment mechanism, is needed.

Can identifiers be text?

Yes. The appropriate representation follows the identifier contract, not a preference for numeric storage.

Does the same identifier value always mean the same entity?

Only within the relevant scope and lifecycle rules; values from different domains can coincide.

Check your understanding

A field accepts exactly six digits. Does that prove every accepted value identifies an existing account?

Answer: No. The format rule validates representation. Existence and uniqueness require separate checks against the account system and its identifier-assignment rules.

Related terms

• Domain Constraint
• Primary key
• Surrogate key
• Natural key
• Foreign key
• composite identifier
• namespace
• entity resolution
• object identifier
• data lineage

Learn next

write an identifier contract for one source system, including scope and reuse rules. Test leading zeros, mixed case, missing values, and identical values from another source. Then distinguish the checks that validate format, uniqueness, existence, and real-world entity equivalence.

• Missing values

More in Data engineering and architecture

• Hypercube (communication pattern) - A hypercube communication pattern organizes exchanges between computing processes as if the processes occupied the corners of a multidimensional cube.
• Hyperjacking - Hyperjacking is malicious control or subversion of a hypervisor, the software layer that manages virtual machines.
• Identification (information) - Identification, in an information-management context, is the ability to distinguish and refer to a particular entity or information item without ambiguity...
• Identity column - An identity column is a database column whose values can be generated automatically when new rows are inserted.
• Imageability - Imageability is the capacity of something to evoke a mental image. The meaning depends on context.
• Imieliński - Lipski algebra - Imieliński - Lipski algebra refers to a family of theoretical treatments that extend relational querying to databases containing incomplete information.

Sources

Sources: SAP/Sybase SQL Anywhere 12, Create domains, https://infocenter.sybase.com/help/topic/com.sybase.help.sqlanywhere.12.0.0/dbusage/createdomain-sql.html ; PostgreSQL, Domains, https://www.postgresql.org/docs/18/domains.html ; PostgreSQL 18, Constraints, https://www.postgresql.org/docs/18/ddl-constraints.html . Primary documentation search excerpts consulted for an identifier-domain example and separate domain/key constraints. The entry uses a broad logical meaning; the historical SQL Anywhere integer example is not presented as a universal identifier requirement.

Previous: Identification (information) Next: Identity and access management