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. Chen's entity–relationship model made entities, relationships, and attributes explicit for conceptual design.

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.

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. ISO/IEC 11179 standards further demonstrate that entities, relationships, attributes, data elements, and datasets require explicit metadata definitions and registration structures in interoperable environments.

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.

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.

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.

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.

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