One-to-one (data model)¶
A relationship cardinality in which each instance of either entity type is associated with at most one instance of the other, with optionality specified separately.
Core Idea¶
A one-to-one relationship in data modeling constrains two entity types so that each instance of (A) is associated with at most one instance of (B), and each (B) with at most one (A). The two maximum-one constraints are reciprocal; relaxing either side changes the relationship type.
Optionality is separate. A relationship may be exactly-one to exactly-one, zero-or-one to exactly-one, or zero-or-one on both sides. A mathematical bijection describes the total exactly-one case, but many database designs called one-to-one permit nonparticipating rows.
Cardinality expresses a rule of the modeled domain, not a pattern that happens to hold in a snapshot. Relational implementations commonly use a shared primary key or a foreign key with a uniqueness constraint, plus nullability and referential rules that encode the chosen minimum cardinalities.
Structural Signature¶
Sig role-phrases:
- Entity type A. Provides instances on one side of the modeled association. Constitutive endpoint. If altered: Merging A and B into one undifferentiated set can hide the relationship being constrained.
- Entity type B. Provides instances on the reciprocal side. Constitutive endpoint. If altered: The relationship cannot be assessed from A records alone.
- Maximum-one constraints. Forbid any A from linking to more than one B and any B from linking to more than one A. Identity-bearing bidirectional cardinality. If altered: Relaxing either direction produces one-to-many or many-to-one.
- Participation and enforcement. States zero-or-one versus exactly-one minima and implements uniqueness and referential integrity. Necessary implementation qualifier. If altered: Observed uniqueness without a schema constraint can be accidental and later violated.
What It Is Not¶
- Not accidental uniqueness. A small dataset can look one-to-one while the domain permits more links.
- Not necessarily a bijection. Optional participation can leave unmatched instances.
- Not one-to-many. Both directions must have a maximum of one.
- Not merely colocated columns. Schema placement does not itself express the semantic association.
Scope of Application¶
The cardinality applies when domain rules make two entity identities correspond uniquely in both directions.
- Entity–relationship models. Diagram endpoints record maximum and minimum participation.
- Relational schemas. Unique foreign keys or shared primary keys enforce reciprocal uniqueness.
- Vertical decomposition. Rare or sensitive attributes can be separated while preserving one identity.
- Extension tables. A subtype-specific row corresponds to at most one base row.
- Data integration. Cross-system identifiers can be asserted one-to-one only after domain validation.
Clarity¶
State both directional maximums and both minimums. Define the entity types and time horizon precisely, because identity rules can change cardinality. Show how uniqueness, nullability, and foreign keys enforce the model. Test counterexamples from the real domain rather than inferring rules from current rows.
Manages Complexity¶
The abstraction compresses two reciprocal uniqueness constraints and optionality into a relationship signature. It helps decide whether entities should be merged, split into extension tables, or linked, while preventing temporary data regularities from becoming false domain rules.
Abstract Reasoning¶
- Define A and B identities and the meaning of one instance on each side.
- Ask the maximum number of B instances valid for one A, then reverse the question.
- Specify minimum participation separately for each direction.
- Search domain history and edge cases for legitimate multiplicity.
- Implement and test uniqueness plus referential constraints matching the result.
Knowledge Transfer¶
Bidirectional maximum-one cardinality transfers across conceptual, logical, and physical models. The phrase becomes misleading when used for current row counts or one-way uniqueness only.
Examples¶
Canonical¶
A user account may have zero or one profile-settings row, and each settings row must belong to exactly one account; a unique non-null foreign key enforces the relationship.
Mapped back: entity type A → user account; entity type B → settings row; maximum-one constraints → one settings row per account and one account per row; participation and enforcement → optional A side, mandatory B side, unique foreign key.
Applied / In Practice¶
A person–brain example is modeled as exactly one in both directions only after the domain excludes transplantation history, anatomical anomalies, and alternative definitions of person or brain record.
Mapped back: entity type A → defined person instance; entity type B → defined brain instance; maximum-one constraints → reciprocal uniqueness; participation and enforcement → total participation under the stipulated domain.
Structural Tensions¶
T1: semantic rule vs. observed data. A clean snapshot cannot prove the domain forbids future multiplicity. Diagnostic: What counterexample is valid under the business meaning?
T2: separate tables vs. single entity. One-to-one decomposition can isolate concerns but add joins and lifecycle coordination. Diagnostic: Does separation represent distinct identity or implementation convenience?
T3: totality vs. optionality. Bijection language simplifies theory but can overstate required participation. Diagnostic: Which side may legitimately be absent?
Structural–Framed Character¶
One-to-one relationship is strongly structural and schema-framed. Evaluative weight: correctness and integrity matter. Human-practice-bound: entity definitions and business rules determine cardinality. Institutional origin: systems analysis and database design stabilize notation. Vocabulary travels: relation and uniqueness travel. Import versus recognize: literal use requires reciprocal maximum-one constraints. Its character: a bidirectional uniqueness rule with explicit optionality.
Structural Core vs. Domain Accent¶
Skeletal core. Two sets are related under reciprocal bounds on how many counterparts each element may have.
Domain-bound accent. Entity identities, optionality, keys, uniqueness, and referential integrity make the relation a data-model constraint.
Why not prime. Cardinality is portable, but this named abstraction belongs to database and systems modeling practice.
Instantiates / Related Primes¶
- Cardinality. Endpoint bounds classify the relationship.
- Constraint. Schema rules preserve the modeled maximums.
- Identity. Instance definitions determine whether uniqueness is meaningful.
- The approved root remains.
Neighborhood in Abstraction Space¶
One-to-one (data model) sits in a moderately populated region (60th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.
Family — Property Ontology & Code Smells (18 abstractions)
Nearest neighbors
- Associative Entity — 0.86
- Data Model — 0.85
- Foreign key — 0.85
- Principal type — 0.84
- Unit of Work — 0.84
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
- Bijection. Tell: It additionally requires total participation on both sides.
- Unique column. Tell: One field’s uniqueness does not by itself establish a two-entity relationship.
- One-to-many relationship. Tell: One endpoint permits multiple counterparts.
- Data coincidence. Tell: Current rows can be unique without a domain or schema constraint.
References¶
- Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/One-to-one_(data_model) (revision 1357481160).
- Preserved source candidate: https://web.archive.org/web/20180209164410/http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php
The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.