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: v2 · 2026-09-19 · History
Domain-specific #: 1622
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering

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.

How would you explain it like I'm…

Toy Shop Rules

Imagine setting up a toy shop and deciding the rules first: every toy has a name and a price, every customer has a name, and a customer can buy toys. Those rules say what you can keep track of and how things connect. A data model is the rules like that for what a computer system can store.

Blueprint for Information

A data model is a plan that describes what information a computer system can hold and how that information is organized and connected. For a store, it might say there are customers, orders, and products, and that each order belongs to one customer. The word is used in two ways: for a general style of making such plans, like organizing everything into tables, and for one particular plan made in that style, like the store's plan. It also includes rules, such as "every order must have a customer," and what you are allowed to do with the data.

Formal Data Description System

A data model is a formal system for describing what data an information system can represent and how that data can be organized, related, constrained, and manipulated. The term works at two linked levels, and you need to say which one you mean. One level is a modeling formalism, like the relational model (data in tables) or the entity-relationship model (entities, relationships, and attributes). The other is a specific application model built with that formalism, such as one describing Customers, Orders, and Products. Data models sit between the real-world domain and how data is actually stored or exchanged. A data model is more than a diagram or a schema file: it includes a vocabulary of building blocks, their meaning, the constraints, and the operations allowed.

A data model is a formal system for describing what data an information system can represent and how it may be organized, related, constrained and manipulated. The term operates at two linked levels: a modeling formalism (for example the relational or entity-relationship model) and a particular application model expressed in that formalism (for example Customers, Orders and Products); a valid use must declare which level it means. Data models mediate between a domain and its stored or exchanged representations. Codd's relational model introduced relations, operations and integrity concerns and separated logical representation from physical machine organization. Chen's entity-relationship model made entities, relationships and attributes explicit for conceptual design. The ANSI/SPARC architecture distinguished external, conceptual and internal schemas, showing that one subject can be modeled at several levels. A data model is broader than a diagram or schema file: it comprises a vocabulary of constructs, their semantics, constraints and permitted 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.”

This entry is a kind of Representation.

Data Model instantiates Representation by mapping selected domain entities, relations, and constraints into a formal information-system medium that supports operational use. Relational Model is a narrower kind within the same domain, while Context Model is a specialized relative focused on changing environmental context. The technical phrase “database schema” is domain vocabulary and does not make the cognitive Schema a broader form of this entry.

Relationships to Other Abstractions¶

Current abstraction Data Model Domain-specific

Parents (1) — outgoing typed relations

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 (3) — abstractions linked here by typed relations

Entity–attribute–value model Domain-specific is a kind of Data Model

An entity-attribute-value model is a data model specialized for sparse and runtime-variable attributes.
Measure (Data Warehouse) Domain-specific is a kind of Data Model

Data Model is the broader abstraction this entry instantiates.
OLAP Cube Domain-specific is a kind of Data Model

An OLAP cube is a logical data model specialized by dimension-member measure coordinates and valid selectable aggregate views.

Hierarchy path (1) — routes to 1 parentless root

Data Model → is a kind of Representation → presupposes Abstraction

Neighborhood in Abstraction Space¶

Data Model sits in a moderately populated region (43^rd percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Property Ontology & Code Smells (18 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25

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 Show verification details

[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 Show verification details

[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 ↩