Data Model¶

A formal information-system structure that declares data types, attributes, relationships, integrity rules, and permitted operations at a stated conceptual, logical, or physical level.

Version: v1 · 2026-08-30 · History
Domain-specific #: 1622
Origin domain: computer science

Core Idea¶

A data model is a formal system for describing what data an information system can represent and how that data may be organized, related, constrained, and manipulated. The term operates at two linked levels: a modeling formalism, such as the relational or entity–relationship model, and a particular application model expressed with that formalism, such as Customers, Orders, and Products. A valid entry must declare which level it means.

Data models mediate between a domain and stored or exchanged representations. Codd's relational model introduced relations, operations, and integrity concerns while separating logical representation from machine organization.^[1] Chen's entity–relationship model made entities, relationships, and attributes explicit for conceptual design.^[2] ANSI/SPARC distinguished external, conceptual, and internal schemas, clarifying that one subject can have several modeling levels.^[3] The abstraction is broader than a diagram or schema file: it includes a vocabulary of constructs, semantics, constraints, and allowed operations.

Structural Signature¶

Sig role-phrases:

the modeled domain — the real or institutional subject whose data distinctions matter
the modeling formalism — relational, entity–relationship, object, graph, document, or another declared family
the data types or entity kinds — classes of recordable things
the attributes — typed properties attached to those kinds
the relationships — permitted associations among instances
the integrity constraints — rules excluding invalid representational states
the manipulation semantics — operations or query constructs licensed by the model
the abstraction level — conceptual, logical, external/view, or physical commitments
the mapping — traceability between domain meaning, model constructs, and implementation

Recognition test. Ask whether the artifact declares a coherent representational vocabulary, structural and integrity rules, and a level. A picture of entities with no semantics, a file layout with no domain mapping, or a pile of values with no declared constraints is not yet a complete data model.

What It Is Not¶

Not the data itself. The model specifies admissible structure; an instance populates it.
Not merely a database schema. A schema is an expression of a model for one system and level, while the data model may include the underlying formalism and cross-level mappings.
Not a data structure in the algorithmic sense. Lists, trees, and hash tables organize memory around operation costs; a data model organizes domain information and integrity.
Not an ontology automatically. Ontologies typically emphasize formally interpreted concepts and inference; many data models are designed for storage and manipulation without that semantic commitment.
Not a process model. It represents information state and permissible operations, not necessarily workflow sequence or organizational responsibility.

Scope of Application¶

Data models are used in database design, enterprise architecture, application integration, APIs, data warehouses, metadata registries, scientific information systems, and interchange standards. Conceptual models capture domain commitments independently of technology. Logical models translate those commitments into a formalism such as relations and keys. Physical models add storage, indexing, partitioning, or platform choices.

The ANSI/SPARC framework's external, conceptual, and internal levels remain a canonical articulation of viewpoint separation.^[3] ISO/IEC 11179 standards further demonstrate that entities, relationships, attributes, data elements, and datasets require explicit metadata definitions and registration structures in interoperable environments.^[4]

Clarity¶

The abstraction makes disagreements diagnosable. Two teams may use the same words but disagree about entity identity; agree on entities but disagree on relationship cardinality; or agree logically while using different physical storage. Labeling the model level prevents a physical optimization from masquerading as a conceptual truth.

A data model also separates structural validity from factual correctness. A record can satisfy every type and key constraint while containing a false real-world value. Conversely, an accurate observation can fail ingestion because it violates an overly narrow model.

Manages Complexity¶

The model compresses many individual records into reusable commitments. Instead of reasoning separately about every customer-order pair, designers state entity, key, cardinality, and integrity rules once. Query and update operations can then rely on those invariants. Codd's relational closure is a strong example: relation-to-relation operations preserve the logical kind of result.^[1]

Compression has costs. The model discards details not represented, fixes boundaries around identity, and may privilege one organizational viewpoint. Evolution therefore requires migration, compatibility policy, and governance rather than merely adding a field.

Abstract Reasoning¶

Suppose Customer has key customer_id, Order has key order_id, and each Order references one Customer. The model licenses checks: duplicate customer keys are invalid; an order with a nonexistent customer violates referential integrity; multiple orders may map to one customer if the declared cardinality permits it. These deductions follow without inspecting application code.

At the conceptual level, replacing a customer's database identifier need not change the real-world identity relation. At the physical level, adding an index need not change logical query meaning. These invariance tests are the practical value of separating levels.

Knowledge Transfer¶

Literal transfer occurs across databases, APIs, messages, and metadata registries when domain types, relations, constraints, and mappings remain explicit. A relational model and a graph model can express overlapping domains while licensing different primitive operations; translation must preserve declared semantics rather than just field names.

The broad lesson “map a domain into a constrained formal medium” belongs to Representation. Calling a rhetorical sketch a data model imports technical authority unless it defines data-bearing constructs, integrity, and manipulation at a stated level. The catalog's prime Schema concerns a cognitive organizing pattern rather than the technical database use of the word “schema,” so it is a surface neighbor but not a superclass here.

Examples¶

Entity–relationship conceptual model. A library model declares Book, Copy, Person, and Loan; Copy instantiates one Book; Loan connects one Copy to one Person over an interval. Cardinalities distinguish a bibliographic work from its physical copies. Chen's formalism was designed to express exactly such entities, relationships, attributes, and design semantics.^[2]

Relational logical model. Tables Customer(customer_id, name) and Order(order_id, customer_id, total) use primary and foreign keys. The model maps a conceptual one-to-many relationship into relation schemas and constraints. A join reconstructs customer-order association without embedding physical pointers.

Physical variation. Adding a B-tree on Order.customer_id changes access cost but not logical membership or referential integrity. If the “model change” only changes index placement, it is physical, not conceptual.

Structural Tensions¶

Expressiveness versus enforceability: rich domain semantics can exceed what the platform can validate. Diagnostic: which commitments are machine-enforced and which remain documentation?
Stability versus evolution: consumers need stable meaning, while domains and regulations change. Diagnostic: which identity and integrity invariants must survive migration?
Normalization versus access locality: reducing redundancy can increase joins and operational coupling. Diagnostic: is a duplicate value uncontrolled inconsistency or a deliberate materialized projection?
Shared model versus viewpoint plurality: one canonical model aids integration but can erase legitimate local distinctions. Diagnostic: are differences mere vocabulary, or do stakeholders require incompatible identities?
Autonomy versus Representation: Representation captures structure-preserving presentation in a medium. Diagnostic: do manipulation semantics, integrity, modeling level, and domain mapping leave a stable data-management residual?

Structural–Framed Character¶

Data Model is mixed. Its formal constraints are structural, but selection of entities, boundaries, names, and authoritative sources reflects institutional purposes. The model is human-designed and can encode policy, though its validity rules operate mechanically once fixed. Its vocabulary travels among information systems rather than arbitrary substrates. Its character: a formal representation whose shape is partly constituted by organizational framing.

Structural Core vs. Domain Accent¶

What is skeletal. Select a bounded domain, define typed elements and relations, impose constraints, and map representations across levels.

What is domain-bound. Entities, attributes, keys, schemas, queries, integrity constraints, and conceptual/logical/physical levels are information-system commitments.

Why this is not a prime. Representation carries the portable mapping skeleton. The named data-model identity requires technical data semantics and lifecycle. Cross-domain “models” without those roles are related only generically. Cognitive Schema is not invoked as the portable skeleton merely because database engineering reuses the word “schema.”

Data Model instantiates Representation by mapping selected domain entities, relations, and constraints into a formal information-system medium that supports operational use. Representation is therefore the minimal literal DAG parent. Relational Model is a strict domain subtype, while Context Model is a specialized sibling focused on changing environmental context. The technical phrase “database schema” is retained as domain vocabulary but does not make the catalog's cognitive Schema prime a parent.

Relationships to Other Abstractions¶

Current abstraction Data Model Domain-specific

Parents (1) — more general patterns this builds on

Data Model is a kind of Representation Prime

Data Model instantiates Representation by mapping selected domain entities, relations, and constraints into a formal information-system medium that supports operational use.

Children (1) — more specific cases that build on this

Measure (Data Warehouse) Domain-specific is a kind of Data Model

Data Model is the proposed immediate parent.

Hierarchy path (1) — routes to 1 parentless root

Data Model → Representation → Abstraction

Neighborhood in Abstraction Space¶

Data Model sits in a sparse region of the domain-specific corpus (61^st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Document Models, Mapping & Maintenance (20 abstractions)

Nearest neighbors

Specification language — 0.87
Knowledge organization system — 0.87
Data Class — 0.86
Primitive Obsession — 0.86
Data Extraction Through Prompting — 0.86

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With¶

Schema (cognitive prime). It organizes perception or thought through an internal pattern. Tell: is the structure a cognitive organizing frame, or an information-system formalization with data operations and integrity?
Relational Model. It is one formal data-model family. Tell: is tuple-and-relation algebra constitutive or merely one implementation choice?
Database schema. It is a concrete declaration for a database. Tell: is the discussion about one implemented schema or the modeling system and domain commitments?
Data structure. It optimizes in-memory operations. Tell: are performance costs or domain semantics primary?
Ontology. It formalizes conceptual meaning and inference. Tell: is semantic entailment required, or only data organization and integrity?
Context model. It represents changing situation for adaptive behavior. Tell: is temporally valid context the defining subject?

References¶

[1] E. F. Codd, “A Relational Model of Data for Large Shared Data Banks”, Communications of the ACM 13 (1970): 377–387. registry ↩a ↩b

[2] Peter P.-S. Chen, “The Entity-Relationship Model—Toward a Unified View of Data”, ACM Transactions on Database Systems 1 (1976): 9–36. registry ↩a ↩b

[3] ANSI/X3/SPARC Study Group, “Interim Report: Study Group on Data Base Management Systems 75-02-08”, FDT—Bulletin of ACM SIGMOD 7(2), 1975. registry ↩a ↩b

[4] ISO/IEC, ISO/IEC 11179-1:2023—Metadata Registries, Part 1: Framework, 2023; and ISO/IEC 11179-4:2004—Formulation of Data Definitions, 2004. registry ↩