Data Model

Origin & evolution

The relational data model came first and reshaped everything after it. E.F. Codd's A Relational Model of Data for Large Shared Data Banks (Communications of the ACM, 1970) proposed describing data as relations, sets of tuples, governed by a formal algebra, and separated cleanly from how the bytes were stored. The decoupling of logical structure from physical layout was the breakthrough, and it won Codd the 1981 Turing Award.

Peter Chen built the bridge to design six years later. His The Entity-Relationship Model: Toward a Unified View of Data (ACM Transactions on Database Systems, 1976) introduced entities, attributes, and relationships as a diagrammable layer that humans could reason about before committing to tables. The ER model became the lingua franca of database design, and the distinction it drew, conceptual versus logical versus physical, still organises the field.

The model widened as storage diversified. Document, key-value, graph, and columnar stores each carry their own modelling assumptions🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference →, and domain-driven design reframed the question again: a data model should express the meaning of a business domain, not just its storage shape. The persistent tension is between a model that mirrors the domain and one that performs well on the chosen engine.

How it works in practice

A logistics startup models its domain before writing a migration. Shipments, parcels, addresses, and carriers become entities; a shipment has many parcels, a parcel has one current location, a carrier serves many routes. The model names cardinality and ownership: a parcel cannot exist without a shipment, an address can be shared.

This conceptual model then projects onto a Postgres schema, with foreign keys, indexes, and a denormalised read table for the tracking page. When the team later adds international customs data, they extend the model first and the schema second. The model is the contract; the schema is one realisation of it. Because the meaning lived in the model, the migration is a deliberate change rather than an archaeological dig through column names.

Data model vs. its neighbours

• Database schema🗄️Database SchemaEngineeringA database schema definitionView reference → is the physical or logical layout in a specific engine: tables, columns, types, constraints🔒ConstraintStrategyA constraint entityView reference →. The data model is the engine-independent description of meaning and structure. One data model can persist into different schemas.
• Domain entity📦Domain EntityEngineeringA DDD domain entityView reference → is a single concept inside the model, such as Shipment. The data model is the whole set of entities and the relationships between them. The entity is a noun; the model is the grammar.
• API contract🤝API ContractEngineeringAn API contract or specificationView reference → describes data in motion across a boundary, the shapes a service sends and accepts. A data model describes data at rest and at meaning. They overlap in the nouns they name and diverge in what they govern.

In the graph

In the Unified Product Graph, data_model🗃️Data ModelData & AnalyticsA data model or schema is a leaf in the Engineering and Platform region, anchored by the service⚙️ServiceEngineeringA deployable service or microserviceView reference →, and its home domain is data_analytics. The hierarchy edges bounded_context_persisted_in_data_modelBounded Contextpersisted inData Modelhierarchy and data_domain_modelled_in_data_modelData Domainmodelled inData Modelhierarchy place it under the conceptual boundaries that own it, while data_model_persisted_in_database_schemaData Modelpersisted inDatabase Schemacross-domain carries it down to the concrete store. That ordering encodes the field's central distinction: the model holds meaning, the schema holds bytes, and the edge between them records exactly how one becomes the other.