Database Models Explained: Structures, Concepts, and Core Types

A database model is a formal framework that defines how data is structured, related, and constrained inside a database system. It specifies how entities, attributes, and relationships are organized at the logical level. Database models provide structural rules for designing schemas before physical implementation.

A database model is not a database product or deployment category. It focuses on logical data structure, not on database engines, platforms, or workloads. But they do provide the structural foundation for systems such as the Exasol Analytics Engine, where logical data design directly influences query execution and analytical performance.

Core elements defined by a database model include:

• how records are structured
• how relationships are represented
• how constraints are enforced
• how data dependencies are expressed

Different models use different structural patterns, such as tables, trees, graphs, or object structures. These patterns determine how relationships are stored and how queries navigate the data.

The table below summarizes the core classical database models and their structural characteristics.

Database Model	Structural Pattern	How Relationships Are Represented	Key Characteristic
Hierarchical	Tree	Parent–child links	Each child has one parent
Network	Graph	Explicit link sets between records	Records can have multiple parents
Relational	Tables	Primary and foreign keys	Declarative, set-based querying
Entity–Relationship	Diagram-based design	Entities and cardinality rules	Used for conceptual design
Object-Oriented	Objects and classes	Object references	Supports inheritance and encapsulation
Object-Relational	Tables with complex types	Keys plus structured types	Extends relational with object features

Database Models vs Database Types vs Schemas

The terms database model, database type, and database schema are related but not interchangeable. They describe different layers of database design and classification. Clear separation improves technical accuracy and aligns with foundational database concepts.

A database model defines the logical structure used to represent data and relationships. A database type classifies database systems by their overall architecture or storage approach. A database schema is the concrete structural definition created using a chosen model.

Term	Scope	What It Describes	Example
Database model	Conceptual / logical	Data structure and relationship pattern	Relational model, hierarchical model
Database type	System category	Class of database system	Relational database, graph database
Database schema	Implementation	Concrete table and field design	Customer table with columns and keys

One database type can implement a specific database model. For example, a relational database system implements the relational model. The schema then defines the exact tables, columns, keys, and constraints inside that system.

Levels of Data Modeling

Data modeling is performed in three levels: conceptual, logical, and physical. Each level describes the same data domain with a different degree of detail and technical specificity. These levels separate business structure from implementation details and guide the database design process step by step.

The database model defines the structural rules. The modeling levels define how precisely those rules are specified during design.

Conceptual Data Model

A conceptual data model describes the high-level structure of a data domain from a business perspective. It identifies main entities and the relationships between them without defining technical attributes or storage details.

This level focuses on meaning and scope, not implementation.

A conceptual model typically defines:

• core entities
• major relationships
• business concepts
• domain boundaries
• It does not define:
• columns or data types
• primary keys
• indexes
• constraints

Conceptual models are used during requirements analysis and early system design. They align stakeholders on what data exists and how major concepts relate.

Logical Data Model

A logical data model adds structural detail to the conceptual model. It defines attributes, keys, and relationship cardinality using the rules of a chosen database model, such as the relational or object-relational model.

This level is technology-independent but structurally precise.

A logical model typically defines:

• attributes per entity
• primary and foreign keys
• relationship cardinality
• normalization structure
• integrity constraints

It does not define:

• storage engines
• index types
• partitioning
• vendor-specific features

Logical models translate business concepts into formal data structures that can be implemented in different database systems.

Physical Data Model

A physical data model specifies how the logical model is implemented in a specific database system. It includes storage and performance details tied to a chosen platform.

This level is technology-dependent.

• A physical model typically defines:
• column data types
• index structures
• partitioning rules
• storage layout
• engine-specific constraints

It converts logical structures into executable database definitions such as DDL statements.

Core Database Models

Classical database models define the main structural patterns used to organize and relate data at the logical level. Each model uses a different representation method for entities and relationships. These models shaped early database systems and still influence modern database design.

The most established database models are:

• hierarchical
• network
• relational
• entity-relationship
• object-oriented
• object-relational

Each model differs in how it represents relationships, navigates data, and enforces structure.

Hierarchical Model

The hierarchical model organizes data in a tree structure. Each record has a single parent and can have multiple child records. Relationships follow a strict one-to-many pattern.

Data is stored as nested parent-child segments. Access paths are predefined and traversal follows the tree from root to leaves.

Structure characteristics:

• tree-shaped hierarchy
• single parent per child
• fixed navigation paths
• strong structural rigidity

Strengths:

• simple structure
• fast traversal along known paths
• predictable access patterns

Limitations:

• weak support for many-to-many relationships
• structural changes are difficult
• path-dependent queries

The hierarchical model appeared in early mainframe database systems and is still used in some configuration and directory structures.

Network Model

The network model extends the hierarchical model by allowing records to have multiple parents. It represents data as a graph structure rather than a strict tree.

Relationships are defined through explicit link sets between record types. A record can participate in multiple relationships simultaneously.

Structure characteristics:

• graph-based structure
• multiple parent relationships
• pointer-based navigation
• predefined relationship sets

Strengths:

• supports many-to-many relationships
• more flexible than hierarchical model
• efficient for complex relationship graphs

Limitations:

• complex schema design
• navigation logic is tightly coupled to structure
• difficult query formulation

The network model improved relationship flexibility but increased modeling and query complexity.

Relational Model

The relational model was first formalized in E. F. Codd’s relational model paper, which introduced the concept of representing data as sets of tuples with defined relationships.

The relational model represents data as tables composed of rows and columns. Relationships are defined through keys and constraints rather than physical pointers.

Each table represents an entity or relationship. Rows represent records. Columns represent attributes. Relationships are enforced through primary and foreign keys.

Structure characteristics:

• table-based structure
• key-driven relationships
• declarative query model
• set-based operations

Strengths:

• strong mathematical foundation
• flexible query capabilities
• clear constraint enforcement
• model independence from access paths

Limitations:

• joins can be expensive at scale
• complex object structures require decomposition
• strict schema requirements

The relational model remains the dominant logical model in database design and underpins SQL-based systems.

Entity–Relationship Model

The entity–relationship (ER) model is a conceptual modeling framework used to design logical database structures. It represents data using entities, attributes, and relationships.

It is primarily a design model, not a storage model. ER diagrams are used to define structure before converting it into a relational or other logical schema.

Structure characteristics:

• entity types
• attribute sets
• relationship types
• cardinality rules

Strengths:

• clear visual representation
• strong design communication tool
• supports early modeling stages
• maps well to relational schemas

Limitations:

• not directly executable
• requires transformation into another logical model
• diagram complexity grows quickly

The ER model is widely used during conceptual and logical database design.

Object-Oriented Model

The object-oriented model stores data as objects that combine attributes and behavior. Objects are grouped into classes and support inheritance and encapsulation.

Relationships are represented through object references rather than foreign keys.

Structure characteristics:

• object identity
• class hierarchies
• inheritance
• method binding

Strengths:

• natural fit for object-oriented applications
• supports complex data structures
• reduces object-relational mapping layers

Limitations:

• weaker standardization
• complex query models
• limited adoption compared to relational systems

This model is used in object database systems and specialized applications.

Object-Relational Model

The object-relational model extends the relational model with object-oriented features. It keeps table structures while adding support for complex types and inheritance.

It combines relational foundations with richer data representations.

Structure characteristics:

• relational tables
• user-defined types
• nested structures
• inheritance support

Strengths:

• compatible with relational querying
• supports complex data types
• reduces schema fragmentation

Limitations:

• increased schema complexity
• vendor-specific extensions
• portability differences

Object-relational modeling appears in advanced relational systems that support extended type systems.

How Database Models Represent Relationships

A core function of any database model is to define how relationships between data elements are represented and constrained. The structure of these relationships determines how data can be queried, navigated, and validated.

Different database models use different mechanisms to express relationships. Some rely on structural hierarchy, others on keys, pointers, or object references.

Relationship Cardinality

Cardinality defines how many instances of one entity can relate to another. It describes the quantitative constraint between entity types.

Common cardinality patterns include:

• one-to-one (1:1)
• one-to-many (1:N)
• many-to-many (M:N)

In the relational model, cardinality is enforced using primary and foreign keys. In hierarchical models, cardinality is implied by the tree structure. In network models, explicit relationship sets define cardinality.

Clear cardinality definition prevents ambiguity in data interpretation and enforces structural consistency.

Keys and Identifiers

Keys uniquely identify records and establish relationships between them. They are central in relational and object-relational models.

Key types include:

• primary keys
• foreign keys
• candidate keys
• composite keys

A primary key uniquely identifies a record within a table. A foreign key references a primary key in another table to establish a relationship.

In pointer-based models such as hierarchical and network models, relationships are navigated through predefined structural links rather than foreign key constraints.

Referential Integrity

Referential integrity ensures that relationships remain valid over time. It prevents orphaned records and inconsistent references.

In relational systems, referential integrity is enforced through foreign key constraints. In hierarchical models, parent-child structure inherently restricts invalid references. In network models, relationship sets define allowed link structures.

Referential integrity supports consistency and predictability in query results.

Normalization and Dependency Control

Normalization organizes relational structures to reduce redundancy and eliminate undesirable data dependencies. It relies on formal rules derived from the relational model.

Normalization addresses:

• update anomalies
• insertion anomalies
• deletion anomalies
• functional dependencies

Other database models manage redundancy differently. Hierarchical and network models embed relationships structurally. Object-oriented models encapsulate data within object boundaries.

Normalization improves structural clarity and reduces data inconsistency in relational schemas.

Navigation vs Declarative Access

Database models also differ in how relationships are accessed.

Hierarchical and network models use navigational access. Queries follow predefined structural paths.

The relational model uses declarative access. Queries specify conditions and allow the system to determine execution strategy.

This distinction affects flexibility, abstraction level, and schema evolution.

Strengths and Limitations of Major Database Models

Each database model defines a different structural approach to organizing data. These structural choices influence flexibility, query behavior, schema evolution, and relationship handling.

The comparison below evaluates core structural characteristics. It does not evaluate specific database products.

Model	Structural Pattern	Relationship Handling	Schema Flexibility	Query Approach
Hierarchical	Tree	Parent-child links	Low	Navigational
Network	Graph with link sets	Explicit pointer relationships	Moderate	Navigational
Relational	Tables	Foreign keys and joins	High (with constraints)	Declarative
Entity–Relationship	Diagram-based design	Modeled via cardinality	High at design stage	Not executable
Object-Oriented	Objects and classes	Object references	High within object hierarchy	Object-based
Object-Relational	Tables with complex types	Keys plus structured types	Moderate–High	Declarative

Flexibility

The relational model separates logical structure from physical access paths. This increases flexibility when schemas evolve. The network and hierarchical models tie structure closely to navigation paths, which reduces adaptability.

Object-oriented models allow nested and complex structures but may reduce interoperability across systems.

Relationship Complexity

The hierarchical model restricts each child to one parent. The network model supports multiple parent relationships but requires explicit link definitions.

The relational model supports many-to-many relationships using associative tables. The ER model formalizes relationship types before schema implementation.

Schema Evolution

Relational schemas can evolve through controlled constraint changes and normalization adjustments. Hierarchical and network schemas are more rigid because structural relationships are embedded in navigation paths.

Object-relational extensions introduce additional complexity when altering type hierarchies.

Query Abstraction

Navigational models require predefined traversal paths. Queries depend on structural design.

The relational model abstracts traversal logic through declarative queries. The user specifies conditions rather than navigation order.

This separation increases logical independence from physical storage decisions.

Database Models in the Database Design Process

Database models guide the structure of data throughout the design lifecycle. They provide the formal rules used to transform business requirements into logical and physical data structures. Extensive research on database modeling and theory is documented in academic repositories such as the DBLP computer science bibliography.

The database design process typically follows a staged progression from abstract representation to executable schema.

Requirements Analysis

Design begins with identifying business entities, relationships, and constraints. At this stage, no specific database model is implemented. The goal is to define:

• core data objects
• relationship rules
• integrity requirements
• data lifecycle constraints

The output is domain understanding rather than technical schema design.

Conceptual Modeling

The conceptual data model translates requirements into structured entity and relationship representations. The entity–relationship model is commonly used at this stage.

Conceptual modeling defines:

• entity types
• relationship types
• cardinality
• participation constraints

It establishes structural clarity without committing to a specific database system.

Logical Modeling

Logical modeling applies a chosen database model, such as the relational or object-relational model. Entities and relationships are mapped into formal structures that follow model-specific rules.

Logical modeling defines:

• attributes
• keys
• normalization rules
• relationship implementation strategy

At this stage, the database model determines how relationships are expressed and constrained.

Physical Design

Physical design converts the logical model into executable definitions. It incorporates implementation details specific to a database system.

Physical design defines:

• column data types
• indexing strategy
• storage allocation
• partitioning
• constraint enforcement mechanisms

Although implementation details vary, the structural logic remains derived from the selected database model.

Model Influence Across Stages

The selected database model affects:

• how relationships are represented
• how constraints are enforced
• how queries are formulated
• how schemas evolve over time

A clear separation between conceptual, logical, and physical modeling maintains structural consistency and reduces redesign effort.

Common Misconceptions About Database Models

Database models are often confused with database systems, schemas, or storage technologies. These misunderstandings blur the distinction between logical structure and system implementation.

Clarifying these differences improves precision in database design and system selection.

Misconception 1: A Database Model Is a Database Product

A database model is not a software system or database engine. It defines the logical structure used to organize and relate data.

A relational database system implements the relational model. The model defines tables, keys, and constraints. The system executes queries and manages storage.

Model = structural rules.
System = implementation of those rules.

Misconception 2: Relational Database Means Relational Model Only

The relational model is a logical framework based on tables and key constraints. A relational database system implements that framework.

Some systems extend the relational model with object features or specialized storage optimizations. The logical model remains relational even when physical behavior differs.

Misconception 3: Schema and Model Are the Same

A database model defines structural principles. A schema applies those principles to a specific domain.

For example:

• The relational model defines tables and keys.
• A customer schema defines specific tables such as Customers, Orders, and Products.

The schema is an instance of the model.

Misconception 4: Modern Databases Do Not Use Classical Models

Modern systems still rely on foundational modeling principles. Even document and graph databases define structured patterns for representing entities and relationships.

Classical models such as relational, hierarchical, and network models established the structural logic that modern systems refine or extend.

Misconception 5: Database Models Define Performance

A database model defines logical structure, not performance behavior. Performance depends on:

• indexing strategy
• query planning
• storage engine
• hardware resources

The model influences query formulation and constraint enforcement but does not directly determine execution speed.

Misconception 6: One Model Fits All Data

Each database model enforces structural constraints. Some support flexible schemas, others enforce strict structure. Selecting a model depends on how relationships and dependencies must be represented.

No single database model is universally optimal for all data domains.