A data model is a structured representation that defines how data is organized, stored, and related within a system, typically visualized as diagrams showing entities and their relationships. A data model is most commonly represented as a diagram, with shapes representing entities and arrows showing the relationship between entities.
For an e-commerce business, entities might be products, orders, customers and customer addresses. An order consists of one customer and one customer address and can contain one or more products.
The data modeling process begins in the early stages of a project to create a shared model and language for designers, developers, data scientists and others. Data models can evolve to become more detailed (e.g., into a database schema) and are used to ensure that designers, developers and database administrators understand the requirements of a software application and how data can be accessed and stored.
Data models can prevent errors: they help project participants identify errors, false assumptions and misunderstandings before the software application is developed. Developers reference a data model when communicating and coordinating with database designers and database administrators. Data models help an organization decide how data will be stored, accessed, utilized and updated, and are foundational to sound data governance practices.
Types of Data Models
The three types of data models range from high-level (e.g., conceptual data model) to detailed and specific (e.g., physical data model).
Conceptual Data Model
The conceptual data model shows entities and their relationships. The intended audience for a conceptual data model is non-technical users on the business side. It shows entities and relationships as determined by the business.
Logical Data Model
The logical data modeldescribes entities and relationships at a more detailed level, but is not associated with a particular database system. The intended audience for a logical data model is technical staff (e.g., database designers, application developers) and used as a basis to create a physical data model.
Physical Data Model
The physical data model contains the highest level of technical detail. It outlines how the entities and relationships will be implemented in a particular database system. In a relational database system, the physical data model is used to create the tables and fields that represent entities. It is used by technical staff to create and manage the database itself.
The Data Modeling Process
In a typical process, the project team progresses through each data model, starting with a conceptual data model, followed next by a logical data model and then a physical data model. Consistency of the entities and relationships should be maintained across each model.
In addition to these types of data models, there are four primary approaches: hierarchical, relational, network and entity relationship (E-R).
Hierarchical Data Model
A hierarchical data model is shaped like a tree, with a few entities at the top (i.e., parents) and child entities that flow downward from the top. Extensible Markup Language (XML), which defines rules for encoding documents in human-readable and machine-readable formats employs a hierarchical data model. XML documents contain a root element that is the parent (or ancestor) of all subsequent elements. Elements in an XML document can contain sub-elements with text and attributes.
Relational Data Model
The relational data model is based on a set of tables. Each table contains fields. Those fields that are common across tables can be used to “join” two or more tables. The relational data model is implemented in relational database systems and data warehouses such as Oracle. Structured Query Language (SQL) is a widely-used mechanism for generating queries and writing data to relational databases.
Network Data Model
The network data model was designed as a flexible way to represent entities and their relationships. Unlike the tree-based representation of the hierarchical data model, the network data model employs a graph with edges and nodes. The network data model allows for each entity to have multiple parents and children.
Entity Relationship (E-R) Data Model
The entity relationship (E-R) data model uses a graphical approach that shows entities and relationships in an entity-relationship diagram. The diagram typically represents entities as squares or rectangles, with lines drawn between them to denote relationships. When implemented in a relational database, each row in a table is an instance of an entity type, while each field in that table is an instance of an attribute type.
Choosing a data modeling approach
The four approaches above are alternatives, not a sequence — a project adopts the one whose structure matches its dominant queries. Two questions drive the choice: what shape the relationships take (a strict tree, many-to-many links, or something in between), and who consumes the model — an application that needs fast record lookups, or analysts who need flexible joins. A wrong choice rarely produces an immediate error. It produces rework, when the queries nobody anticipated turn out to be the ones the business asks most.
| Approach | Best for | Why it fits | Failure mode if misapplied |
|---|---|---|---|
| Relational | Business records with many-to-many relationships — customers, orders, products | Fields shared across tables join them, so any combination can be queried without redesign | Forcing deeply nested or rapidly changing structures into tables produces sprawling join tables that slow every query |
| Hierarchical | Data with one natural parent per record — product catalogs, org charts, XML documents | Traversal follows a fixed path from parent to children, which storage can optimize | A child that needs two parents forces duplication, and duplicated records drift out of sync |
| Network (graph) | Data whose value sits in the connections — social links, recommendations, identity graphs | Entities hold multiple parent and child links, so relationships are traversed directly instead of reconstructed with joins | Used for plain tabular reporting, the extra structure adds overhead while answering nothing extra |
| Entity relationship (E-R) | Design-time communication, before a database exists | The diagram lets business and technical staff agree on entities and relationships before implementation cost begins | Treating the diagram as the finished implementation skips the physical decisions — data types, indexes, constraints — that make it run |
Most estates mix approaches rather than commit to one: a relational core for transactional records, a document store for nested payloads such as event logs or product configurations, and E-R diagrams at design time regardless of what gets built. The test is not which approach is correct in the abstract, but which one keeps the questions the business actually asks from requiring a redesign.
The three model types and the four approaches answer different questions, and a project needs both. The type states how much detail the model carries — conceptual for scope, logical for structure, physical for implementation — while the approach states the structure the data itself takes. A project moves through all three types while holding one approach: a retail team sketches a conceptual model of customers and orders, refines it into a logical model, and implements it as a physical model in a relational database, whose tables stay relational down to the column definitions.
How a data model fails
A data model fails quietly. Nothing breaks on the day a design decision goes wrong; the cost arrives later, as queries that cannot be written, joins that return wrong answers, and a rebuild scheduled mid-project. Five failure modes account for most of the damage.
Entity sprawl. Each team names its own version of the same thing — “customer” in the CRM, “user” in the product database, “contact” in the email tool. Joins multiply to reconcile them, and every new source adds another mapping. The fix is a single naming authority: one definition per entity, owned by one role, with duplicates retired rather than left in place alongside the canonical version.
Modeling the report instead of the business. A model built to reproduce one dashboard encodes that dashboard’s assumptions. The first question it did not anticipate — a cohort view, a new channel — forces a redesign. Entities should be modeled at their natural grain: one row per order, per event, per customer. Reports then become queries instead of schema changes.
Premature physical detail. Fixing data types, indexes and partition schemes before query patterns are known bakes guesses into the structure, and changing them later means migrations on live data. Physical decisions belong after access patterns are observable — the conceptual and logical layers exist precisely to hold the design open until then.
Undocumented semantics. A field named status holding the value 3 means nothing without a definition, and two systems will assign it two meanings. When definitions live in people’s heads, the model stops being the shared language it exists to be. Definitions belong next to the model, versioned with it.
Over-abstraction. Generic entities — “party”, “agreement”, “item” — feel flexible and read as nothing. New developers cannot tell which rules apply to which entity, so they route around the model, and the workarounds become the real schema. Model the domain’s actual vocabulary; abstraction earns its place only when two entities genuinely share behavior.
How a data model changes over time
Data models are living artifacts. Sources change the fields they send, the business adds entities, and the grain that answered last year’s questions proves too coarse for this year’s. A model that cannot absorb those changes gets bypassed by shadow models built around it — a slower way of failing.
Changes divide into two classes. Additive changes — a new entity, a new optional attribute — are cheap: existing consumers ignore what they do not read. Breaking changes — repurposing a field, tightening an optional attribute into a required one, changing a table’s grain — break every consumer built against the old shape. Treating the model as a contract keeps the difference manageable: version it, deprecate fields before deleting them, and tell consumers about a change before it ships, not after.
Unmanaged change has a name: schema drift. A source system adds a field, renames one, or switches a format, and the model no longer describes the data actually arriving. Downstream, values land in the wrong columns or drop silently, and the first visible symptom is usually a metric that stops reconciling. The countermeasures are ownership and reconciliation: one person is responsible for the model’s accuracy, source schemas are compared against the model on a schedule, and an unexpected field raises a question instead of disappearing.
How often the model is revised follows the development rhythm around it. Teams practicing agile development revise the model in each iteration as requirements surface, rather than freezing it upfront and discovering the gaps in production. Models also shrink as well as grow: entities outlive their purpose, and a dead entity left in place invites someone to fill it. A changelog recording what was added, changed and retired keeps the model legible to the next reader.
FAQ
Why is a data model important for business applications?
A data model serves as a blueprint that ensures all stakeholders—designers, developers, and database administrators—share a common understanding of how data is organized and related. It prevents costly errors and misunderstandings by catching false assumptions before development begins. Without a clear data model, applications risk data inconsistencies, integration failures, and difficulty scaling as business requirements evolve.
What is the difference between a logical and physical data model?
A logical data model describes entities, attributes, and relationships in detail but remains independent of any specific database technology. A physical data model translates the logical model into the technical specifications required by a particular database system, including table structures, data types, indexes, and constraints. The logical model focuses on what data is needed, while the physical model defines how it will be stored and accessed.
How do data models relate to customer data platforms?
Customer data platforms rely on well-designed data models to unify customer data from multiple sources into coherent, queryable profiles. The data model defines how entities like customers, transactions, events, and product interactions relate to each other, enabling accurate data ingestion and identity resolution. A robust data model is essential for ensuring that the CDP can integrate structured and unstructured data into a reliable single source of truth through effective data integration.
What is the difference between a data model and a database schema?
A data model is the abstract design of how data relates; a database schema is that design implemented in one specific system. The model works at the business level — entities such as customers and orders, their attributes, and the relationships between them. The schema translates those decisions into tables, columns, data types and constraints for a particular database. One model can underlie several schemas: two systems can implement the same design differently, each in its own way.
Who owns and maintains a data model?
A data architect or data engineer typically owns the data model, but maintaining it is a shared responsibility. The owner keeps entities, attributes and relationships consistent across the conceptual, logical and physical layers, and decides on proposed changes. Database administrators maintain the physical implementation, application developers flag where the model no longer fits their features, and business stakeholders confirm the entities still match how the business works. Without one owner, changes arrive uncoordinated and the model drifts out of date.
Related Terms
- Semi-Structured Data — Data format (JSON, XML) that bridges structured and unstructured models
- Data Pipeline — Infrastructure that moves data according to the rules defined by the data model
- Data Lakehouse — Modern storage architecture that combines data lake flexibility with warehouse structure
- Data Validation — Ensuring data conforms to the constraints and rules specified in the data model