Types of Data Models: Conceptual, Logical, Physical, and Eleven Model Types Compared

"Types of data models" means two different lists. The first is a list of levels: conceptual, logical and physical. Each level describes the same data in more detail, from business terms down to storage. The second is a list of model types: hierarchical, network, relational, entity-relationship, dimensional, Data Vault, document, key-value, wide-column, graph and object. Each type is a different way of structuring data. A project uses both lists at once. You draw a conceptual model, then build a logical and physical model in one or more of the types.

The three levels: conceptual, logical, physical

Level	Question it answers	Audience	Example content
Conceptual	What things does the business care about, and how do they relate?	Business owners, architects	Customer places Order; Order contains Product
Logical	What attributes, keys and rules does each thing have, independent of any product?	Data architects, analysts	Order(order_id PK, customer_id FK, order_date); one Customer has many Orders
Physical	How is it stored in this database?	Engineers, DBAs	orders table, BIGINT key, index on customer_id, partitioned by month

The idea of separating levels dates to the 1970s. An ANSI/X3/SPARC study group's 1975 interim report described an architecture of three levels, external, conceptual and internal, that map onto each other. The group's framework was later published by Tsichritzis and Klug in Information Systems 3(3), pp. 173–191 (1978). The description of the 1975 report here follows Partridge et al. (2025), section 5.4, which traces that history.

The modern conceptual/logical/physical trio is not the same as the ANSI/SPARC trio. ANSI/SPARC's external level is a user's view of the data. Its internal level is storage. Today's logical model has no exact ANSI/SPARC equivalent. The shared idea is data independence: a change in storage should not force a change in what users see.

Hierarchical and network models

The hierarchical model stores data as a tree. Each child record has exactly one parent. IBM's IMS is one implementation. IBM's documentation compares hierarchical and relational databases using a dealership sample: Dealer is the root segment, Model is its child, and Order, Sales and Stock sit under Model. You cannot insert an Order segment without it being a child of a specific Model segment.

Dealer (root)
  └─ Model
       ├─ Order
       ├─ Sales
       └─ Stock

The network model relaxes the one-parent rule. A record can be linked to several owners, so the structure is a graph of records rather than a tree. Programs navigate from record to record along the stored links.

Use either today only when you maintain a system already built on one. New designs do not start here.

Relational model

E. F. Codd proposed the relational model in "A relational model of data for large shared data banks", Communications of the ACM 13(6), June 1970, pp. 377–387. The paper's first sentence states the goal: "Future users of large data banks must be protected from having to know how the data is organized in the machine." Codd criticized the "tree-structured files or slightly more general network models" of the time. He named three dependencies to remove: ordering dependence, indexing dependence and access path dependence.

Data is held in relations (tables) of rows and columns. Relationships are expressed by matching key values, not by stored pointers. Normalization removes redundancy, so each fact is stored once.

CREATE TABLE customer (
  customer_id  BIGINT PRIMARY KEY,
  name         TEXT NOT NULL
);

CREATE TABLE orders (
  order_id     BIGINT PRIMARY KEY,
  customer_id  BIGINT NOT NULL REFERENCES customer(customer_id),
  order_date   DATE NOT NULL
);

Use it for transactional systems where many applications share data, integrity rules matter, and queries are not all known in advance.

Entity-relationship model

Peter Chen introduced the entity-relationship (ER) model in "The entity-relationship model: toward a unified view of data", ACM Transactions on Database Systems 1(1), March 1976, pp. 9–36. The abstract describes it as a data model that "incorporates some of the important semantic information about the real world," with "a special diagrammatic technique" for database design. Chen proposed it as a basis for unifying the network, relational and entity set models.

An ER model has entities (Customer, Order), attributes (name, order_date) and relationships with cardinality (one Customer places many Orders). It is usually drawn, not stored.

Use it for conceptual and logical modeling before choosing a database. An ER model translates directly into relational tables.

Dimensional model (star schema)

The dimensional model organizes data for analysis rather than for transactions. The Kimball Group says star schemas "characteristically consist of fact tables linked to associated dimension tables."

• A fact table "contains the numeric measures produced by an operational measurement event in the real world."
• Dimension tables "are usually wide, flat denormalized tables with many low-cardinality text attributes."

Kimball's four-step design process is: select the business process, declare the grain, identify the dimensions, identify the facts. The grain states what one fact row represents.

sales_fact (grain: one order line)	date_dim	product_dim	store_dim
date_key, product_key, store_key, quantity, net_amount	date_key, date, month, quarter, fiscal_year	product_key, sku, name, brand, category	store_key, store_name, city, region

Use it for reporting and BI layers, where users slice measures by business attributes. It denormalizes on purpose, so it is a poor fit for transactional writes.

Data Vault

Data Vault is a warehouse modeling method developed by Dan Linstedt. It splits data into three table types. The Data Vault Alliance's introduction describes them:

• Hubs hold business keys, such as a customer number.
• Links hold relationships between hubs, such as a transaction between a customer and a product.
• Satellites hold the descriptive attributes, with history kept over time.

hub_customer	link_customer_order	sat_customer_details
customer_hk, customer_number, load_date, record_source	link_hk, customer_hk, order_hk, load_date, record_source	customer_hk, load_date, name, segment, address

New sources add hubs, links or satellites instead of reworking existing tables. Linstedt writes that raw and business vault entities "should not, be directly accessed by data consumers." An information mart layer, which can include dimensional models, sits on top for users. Linstedt and Olschimke cover the model in "Data Vault 2.0 Modeling", a chapter of Building a Scalable Data Warehouse with Data Vault 2.0 (Morgan Kaufmann, 2015).

Use it for an integration layer that takes many changing sources and needs a full audit trail. Expect more tables and more joins than a star schema, and plan the marts that users will query.

Document model

A document database stores each record as a self-contained, nested structure, usually JSON or a binary form of it. MongoDB's documentation says "MongoDB stores data records as BSON documents," a binary representation of JSON with more data types. Documents are field-and-value pairs and can embed other documents. The maximum BSON document size is 16 mebibytes.

{
  "_id": 1001,
  "customer": { "id": 42, "name": "Acme Corp" },
  "order_date": "2026-10-01",
  "lines": [
    { "sku": "A-100", "qty": 2, "price": 19.50 },
    { "sku": "B-200", "qty": 1, "price": 75.00 }
  ]
}

Use it when an application reads and writes a whole aggregate at once, such as an order with its lines or a product with variable attributes. Data that many documents share, such as the customer name above, is copied into each one and must be kept in sync by the application.

Key-value model

A key-value store maps a unique key to a value that the database does not interpret. Amazon's Dynamo paper (SOSP 2007) describes the query model as "simple read and write operations to a data item that is uniquely identified by a key," with "no need for relational schema." Its interface exposes two operations, get() and put(). The paper lists shopping carts, session management and customer preferences among the services it was built for.

session:8f3a2c  ->  {"user_id": 42, "cart": ["A-100", "B-200"], "expires": 1792700000}

Use it for caches, sessions, feature flags and any lookup by a known key. Any query by something other than the key needs a second structure.

Wide-column model

Google's Bigtable paper (OSDI 2006) defines its data model as "a sparse, distributed, persistent multi-dimensional sorted map," indexed by row key, column key and timestamp. Rows can carry different columns.

Modeling is driven by queries. Apache Cassandra's data modeling guide says "data modeling is query-driven" and that joins are not supported, so required columns are grouped in one table and data is duplicated across tables. A partition key distributes data among nodes.

-- One table per query: "latest readings for a sensor"
CREATE TABLE readings_by_sensor (
  sensor_id   text,
  reading_ts  timestamp,
  value       double,
  PRIMARY KEY ((sensor_id), reading_ts)
) WITH CLUSTERING ORDER BY (reading_ts DESC);

Use it for very high write volumes with known access patterns, such as telemetry, event logs and time-ordered history per entity. A new query usually means a new table.

Graph model: property graph and RDF

Graph models store nodes and the relationships between them as first-class data. There are two families.

A property graph has labeled nodes and relationships, each carrying key-value properties. ISO/IEC 39075:2024, the GQL standard, was published on April 12, 2024. Its scope opens: "This document defines data structures and basic operations on property graphs." A pattern query in Cypher, a property-graph language, looks like this:

MATCH (c:Customer)-[:PLACED]->(o:Order)-[:CONTAINS]->(p:Product {sku: "A-100"})
RETURN c.name, o.order_date

RDF (Resource Description Framework) is the W3C model. The RDF 1.1 Concepts Recommendation (February 25, 2014) says "an RDF graph is a set of RDF triples." Each triple has a subject, a predicate and an object, and subjects and predicates are IRIs, so identifiers are global across datasets.

<https://example.com/customer/42> <https://example.com/ns#placed> <https://example.com/order/1001> .

Use a property graph when queries follow relationships of variable depth, as in fraud rings, entitlements or dependency analysis. Use RDF when you need to merge data from many publishers under shared vocabularies and ontologies.

Object and object-relational models

The object model stores data as objects with identity, attributes and behavior, and supports inheritance, matching object-oriented programming languages. The idea appears in two common forms: object-relational mappers in application code, and object-relational features in the database.

PostgreSQL describes itself as "an object-relational database management system." It supports user-defined types and table inheritance:

CREATE TABLE cities (name text, population float, elevation int);
CREATE TABLE capitals (state char(2)) INHERITS (cities);

PostgreSQL's documentation warns that indexes, unique constraints and foreign keys apply only to single tables, not to inheritance children. Use object-relational features for type extensions. Model inheritance with ordinary tables unless you have tested those limits.

Comparison of data model types

Model	Structure	Relationships	Schema	Typical use
Hierarchical	Tree of segments	Parent-child, one parent	Fixed	Legacy mainframe transactions
Network	Graph of records	Stored links, many owners	Fixed	Legacy systems
Relational	Tables of rows	Key values, joins	Declared up front	Systems of record, OLTP
Entity-relationship	Diagram of entities	Named, with cardinality	Design-time only	Conceptual and logical design
Dimensional	Facts and dimensions	Fact keys to dimensions	Declared, denormalized	BI and reporting
Data Vault	Hubs, links, satellites	Link tables	Declared, additive	Auditable warehouse integration layer
Document	Nested JSON-like documents	Embedding or references	Flexible per document	Application aggregates, catalogs
Key-value	Key to opaque value	None in the database	None	Caches, sessions, lookups
Wide-column	Rows with sparse columns, partitioned	None; data duplicated per query	Declared per table	High-volume writes, time series
Property graph	Nodes and edges with properties	Stored edges	Optional	Variable-depth traversal
RDF	Subject-predicate-object triples	Predicates (IRIs)	Ontology, optional	Linked data, knowledge graphs
Object	Objects with identity and inheritance	References	Class definitions	OO-heavy applications, type extensions

Choose the model from the questions the data must answer

1. Start with a conceptual model. An ER diagram of the business entities is useful whatever database follows.
2. List the queries and writes. Ad hoc queries and multi-table transactions point to relational. A whole aggregate read by one key points to document or key-value. A few known queries at very high volume point to wide-column. Variable-depth paths point to graph.
3. Separate the operational model from the analytical one. Systems of record stay normalized. Reporting gets a dimensional model. Add a Data Vault layer between them only if you integrate many changing sources and need full history.
4. Count the copies. Document and wide-column designs duplicate data on purpose. Decide which system owns each fact and how copies are updated.
5. Keep the logical model when the physical one changes. A documented logical model lets you move from one database to another without rediscovering what the data means.

For storage and platform trade-offs, see Choosing the Right Database: SQL, NoSQL, and Distributed Trade-offs. For where these models sit in a wider platform, see The Modern Data Stack.

Frequently asked questions

What are the three types of data models? Conceptual, logical and physical. They are levels of detail for the same data. The conceptual model names business entities and relationships. The logical model adds attributes, keys and rules. The physical model specifies tables, types and indexes for one database.

Is an ER diagram the same as a relational model? No. Chen's ER model describes entities, attributes and relationships for design. Codd's relational model is how a database stores data in tables. ER diagrams are usually translated into relational tables.

What is the difference between a star schema and Data Vault? A star schema is built for users to query: facts with descriptive dimensions. Data Vault is built for integration and history: hubs, links and satellites. Users query an information mart layer on top of the vault, which can include star schemas.

Related Reading

• Enterprise Database Platforms
• Graph Database Platforms
• Cloud Data Warehouse
• Data Warehouse Automation
• Data Catalog & Metadata Management
• Choosing the Right Database: SQL, NoSQL, and Distributed Trade-offs
• The Modern Data Stack: Selecting the Right Tools for Your Data Platform
• Data Mesh vs. Data Fabric: Choosing the Right Architecture for Your Enterprise