What Is a Data Model? Definition, Types and Examples

A data model is a structured description of the data a system stores: what it keeps information about, which details it records, and how those pieces relate to each other. It is usually drawn as a diagram and serves as the blueprint for a database - the shared picture that developers, analysts and business stakeholders agree on before any table is created.

This guide explains what a data model contains, the three types of data models, and how one example changes as it moves from a business sketch to a database-ready design.

What Is a Data Model?

Think of a data model as a map of your information. Just as an architect draws a floor plan before building a house, a data model describes the structure of data before it is stored. Every data model is built from the same few elements:

• Entities - the things you store data about, such as a customer, an order or a product. In a database, entities become tables. See what is a database entity.
• Attributes - the details recorded for each entity, such as a customer's name or email. In a database, attributes become columns.
• Relationships - how entities are connected, for example "a customer places orders". Relationships have a cardinality: one-to-one, one-to-many or many-to-many.
• Keys and constraints - the rules that keep data valid: primary keys identify each record, foreign keys link records, and constraints such as NOT NULL or UNIQUE limit what can be stored.

Why Data Models Matter

• A shared language: business people and developers review the same diagram, so misunderstandings surface before they are built into the database.
• Fewer costly changes: fixing a relationship in a data model takes minutes; fixing it in a production database with years of data takes far longer.
• Data quality: keys, constraints and normalization designed into the model prevent duplicate and inconsistent data.
• Documentation: a current data model tells new team members, auditors and integration partners how the data is organized.

The Three Types of Data Models

Data models are usually created at three levels of detail. Each level answers a different question and serves a different audience. The diagrams below show the same online-shop example - customers, addresses, countries, categories and orders - at each level.

1. Conceptual Data Model

A conceptual data model is the bird's-eye view. It shows the main entities and the relationships between them, in business terms, with no technical detail. Its audience is business stakeholders and domain experts, and its question is: what are we storing data about?

Learn how to create a conceptual data model step by step.

2. Logical Data Model

A logical data model adds structure: every entity gets its attributes and keys, and every relationship gets its cardinality. It is still independent of any database system, so it can model many-to-many relationships directly. Its audience is data architects and analysts, and its question is: how is the data organized?

Learn how to create a logical data model and convert it to a physical one.

3. Physical Data Model

A physical data model describes how the data is actually stored in a specific database, such as PostgreSQL, Oracle or SQL Server. It adds data types, nullability, indexes and database-specific objects like domains or composite types. Many-to-many relationships are resolved into junction tables - note the customer-category table below. Its audience is developers and DBAs, and its question is: how do we build it?

A physical data model can be drawn from scratch or generated from an existing database by reverse engineering, and it can generate the SQL that creates the database.

Conceptual vs. Logical vs. Physical Data Model

Data Model Examples

The online-shop diagrams above are a small data model example. For a larger, real-world one, see the sports tournament data model for PostgreSQL, which covers teams, players, matches and standings, table by table.

More diagrams are collected on the ER diagram samples page.

Other Types of Data Models

Conceptual, logical and physical describe the level of detail. Data models are also grouped by the structure they use:

• Relational data model - data in tables of rows and columns linked by keys. The basis of PostgreSQL, MySQL, Oracle, SQL Server and SQLite.
• Dimensional data model - fact and dimension tables arranged in star or snowflake schemas, used in data warehouses for reporting.
• Document data model - nested, JSON-like documents, used by MongoDB and other NoSQL databases.
• Graph data model - nodes and edges, suited to highly connected data such as social networks or recommendations.
• Hierarchical data model - parent-child trees, one of the oldest approaches. See hierarchy modeling.

NoSQL Data Models

NoSQL databases take a more flexible approach. Instead of spreading data across many tables, a document database such as MongoDB often embeds related data inside one document. Here is the same online shop as a MongoDB data model: addresses are embedded in the customer document, and products are embedded in each order.

Read more about NoSQL data modeling, or design MongoDB schemas visually in Moon Modeler.

How to Create a Data Model

1. Gather requirements: talk to the people who use the data and list the questions the system must answer.
2. Identify entities: pick out the nouns - customer, order, product - and draw them as a conceptual data model.
3. Define relationships: connect the entities and decide the cardinality of each relationship.
4. Add attributes and keys: turn the sketch into a logical data model with attributes, primary keys and foreign keys.
5. Normalize: remove redundancy so every fact is stored in one place.
6. Choose the database and refine: create the physical data model with data types, indexes and constraints for the target system, then generate the SQL.

A data modeling tool makes these steps faster and less error-prone. Luna Modeler supports conceptual, logical and physical data models for PostgreSQL, MySQL, MariaDB, SQL Server, Oracle and SQLite. It can reverse engineer existing databases, keep the model in sync with them, and generate SQL scripts and documentation.

Try Luna Modeler free