Information Models and Data Models: From Business Concepts to Database Design
Organizations need more than a place to store data. They also need a shared understanding of what the data represents, how different concepts relate to one another, and how those concepts should eventually be implemented in a database.
Information models and data models address different parts of this problem:
- An information model describes business concepts and their meaning at a high level.
- A data model translates those concepts into progressively more detailed structures that can eventually be implemented in a database.
This article covers:
- Information models and data models
- Conceptual, logical, and physical modeling
- Entities, attributes, relationships, and cardinality
- Entity-relationship diagrams
- Relational and hierarchical models
- Normalization, keys, and constraints
- Logical and physical data independence
What Is an Information Model?
An information model is an abstract representation of the information used within a particular domain or organization.
It describes:
- Important business concepts
- Properties of those concepts
- Relationships between concepts
- Business rules and constraints
- Operations that may be performed on the information
- The meaning and context of the information
An information model focuses primarily on semantics: what the information means.
For example, a library information model might contain the following concepts:
- Book
- Author
- Borrower
- Book copy
- Loan
- Publisher
It may also define rules such as:
- An author can write multiple books.
- A book can have multiple authors.
- A library can own several copies of the same book.
- A borrower can have multiple active loans.
- Every loan must be associated with one borrower and one book copy.
At this stage, it is unnecessary to decide:
- Which database product will be used
- What the table names will be
- Which indexes should be created
- Where the database files will reside
- How records will be partitioned
The goal is to create a shared understanding of the domain before making implementation decisions.
Why Information Models Matter
Different departments may use the same word to mean different things.
For example, the term customer could mean:
- Anyone who created an account
- Someone who completed a purchase
- A company with an active contract
- An individual receiving a service
- A household rather than a person
An information model makes these meanings explicit.
It helps organizations:
- Establish consistent terminology
- Resolve ambiguous business definitions
- Document business rules
- Identify important entities
- Understand relationships between domains
- Improve communication between stakeholders
- Reduce implementation misunderstandings
- Support data governance and integration
Business analysts, subject-matter experts, data architects, and organizational stakeholders commonly participate in its development.
What Is a Data Model?
A data model formally describes how data is organized and related within an information system.
Depending on its level of detail, a data model may define:
- Entities
- Attributes
- Relationships
- Data types
- Identifiers
- Primary and foreign keys
- Cardinality
- Constraints
- Tables and columns
- Indexes
- Storage and partitioning decisions
Data modeling converts business requirements into structures that software and database systems can implement.
A data model is therefore not limited to a final collection of database tables. It can exist at several levels of abstraction, from a high-level domain representation to a DBMS-specific design.
IBM describes data modeling as a progression from conceptual through logical to physical models, with each stage adding implementation detail while retaining the original business requirements. IBM’s data-modeling overview provides a current summary of these three levels.
Information Models and Data Models Compared
| Aspect | Information model | Data model |
|---|---|---|
| Primary focus | Meaning and business context | Organization and representation of data |
| Detail level | Usually highly abstract | Ranges from conceptual to physical |
| Main questions | What information exists and what does it mean? | How should the data be structured and implemented? |
| Typical content | Concepts, properties, relationships, rules | Entities, attributes, keys, tables, data types, indexes |
| Technology dependence | Usually technology-neutral | Physical models may be DBMS-specific |
| Typical users | Business analysts and domain experts | Data architects, database designers, and developers |
| Main purpose | Create shared understanding | Guide database and system implementation |
The distinction is useful, but terminology varies among organizations and modeling frameworks. Some organizations use conceptual data model for a representation that others might call an information model.
The important issue is not the label. It is knowing which questions the model is intended to answer.
The Three Levels of Data Modeling
Data models are commonly developed at three levels:
- Conceptual model
- Logical model
- Physical model
Each level introduces additional detail.
Conceptual Data Model
A conceptual model provides the highest-level representation of the domain.
It normally identifies:
- Major entities
- Important relationships
- Essential business rules
- General scope of the system
A conceptual library model might show:
AUTHOR ── writes ── BOOK
BOOK ── has ── BOOK COPY
BORROWER ── receives ── LOAN
LOAN ── concerns ── BOOK COPYIt generally does not specify:
- Exact attribute data types
- Database tables
- Indexes
- Foreign-key syntax
- Storage engines
- Partitioning strategies
The conceptual model is especially useful for discussions with business stakeholders because it avoids unnecessary technical details.
Logical Data Model
A logical model adds the details required to define the data structure while remaining independent of a particular database product.
It may specify:
- Entities
- Attributes
- Candidate identifiers
- Primary keys
- Relationships
- Cardinalities
- Optional and mandatory participation
- Data types at a general level
- Normalization rules
A logical representation of an author might be:
AUTHOR
----------------
author_id
first_name
last_name
emailA book might be:
BOOK
----------------
book_id
title
publication_year
isbn
publisher_idA logical model can identify relationships and keys without specifying whether the final system will use PostgreSQL, MySQL, Oracle Database, or another DBMS.
Physical Data Model
A physical model provides an implementation-ready database design.
It may define:
- Actual table and column names
- DBMS-specific data types
- Primary-key definitions
- Foreign-key constraints
- Unique constraints
- Indexes
- Default values
- Check constraints
- Partitioning
- Storage parameters
- Naming conventions
- Performance-related design decisions
Example:
CREATE TABLE author (
author_id BIGINT GENERATED ALWAYS AS IDENTITY,
first_name VARCHAR(100) NOT NULL,
last_name VARCHAR(100) NOT NULL,
email VARCHAR(254),
CONSTRAINT pk_author
PRIMARY KEY (author_id),
CONSTRAINT uq_author_email
UNIQUE (email)
);This implementation includes technical details that would not normally appear in the conceptual model.
From Business Requirement to Database
Consider this business statement:
A book may have multiple authors, and an author may write multiple books.
Information or Conceptual Level
AUTHOR many-to-many BOOKLogical Level
A many-to-many relationship is resolved through an associative entity:
AUTHOR
- author_id
- first_name
- last_name
BOOK
- book_id
- title
- isbn
BOOK_AUTHOR
- book_id
- author_id
- author_orderPhysical Level
CREATE TABLE book_author (
book_id BIGINT NOT NULL,
author_id BIGINT NOT NULL,
author_order INTEGER,
CONSTRAINT pk_book_author
PRIMARY KEY (book_id, author_id),
CONSTRAINT fk_book_author_book
FOREIGN KEY (book_id)
REFERENCES book (book_id),
CONSTRAINT fk_book_author_author
FOREIGN KEY (author_id)
REFERENCES author (author_id)
);The business concept remains the same, but each modeling stage represents it with greater technical precision.
Entities and Attributes
Entities and attributes are fundamental components of data models.
Entity
An entity represents a distinguishable concept, object, person, place, event, or transaction.
Examples include:
- Customer
- Product
- Employee
- Book
- Loan
- Payment
An entity type describes the general category, while an entity instance represents one specific occurrence.
For example:
Entity type: BOOK
Entity instance: The book with ISBN 978-0-123456-78-9Attribute
An attribute describes a property of an entity.
The BOOK entity might have:
- Book ID
- Title
- ISBN
- Publication year
- Language
- Publisher
In a relational implementation, an entity often becomes a table and its attributes often become columns. This mapping is common but not universal; one conceptual entity may sometimes require several physical tables.
Relationships
A relationship describes how entities are associated.
Examples include:
- A customer places an order.
- An employee belongs to a department.
- An author writes a book.
- A borrower receives a loan.
- A loan covers a book copy.
Relationships may also have their own attributes. For example, the relationship between an author and a book might include author_order, indicating the order in which authors appear.
Cardinality
Cardinality indicates how many instances of one entity may relate to instances of another.
One-to-One
PERSON 1 ─── 1 PASSPORTOne person is associated with at most one passport in the modeled context, and each passport belongs to one person.
One-to-Many
CUSTOMER 1 ─── many ORDEROne customer can place multiple orders, while each order belongs to one customer.
Many-to-Many
AUTHOR many ─── many BOOKAn author can write multiple books, and a book can have multiple authors.
In a relational database, the many-to-many relationship is normally implemented with an associative table such as book_author.
Entity-Relationship Diagrams
An entity-relationship diagram, or ERD, visually represents:
- Entities
- Attributes
- Keys
- Relationships
- Cardinalities
- Participation constraints
A simplified library ERD might be represented as:
AUTHOR
- author_id [PK]
- first_name
- last_name
|
| writes
|
BOOK_AUTHOR
- book_id [PK, FK]
- author_id [PK, FK]
- author_order
|
| identifies authors of
|
BOOK
- book_id [PK]
- title
- isbn
- publisher_id [FK]ERDs can exist at conceptual, logical, or physical levels. Their amount of detail depends on their purpose and audience. IBM’s ERD overview distinguishes conceptual, logical, and physical ER diagrams in this way.
The Entity-Relationship and Relational Models
The entity-relationship model and relational model serve related but different purposes.
Entity-Relationship Model
The ER model is commonly used to represent:
- Entities
- Attributes
- Relationships
- Cardinality
- Business constraints
It is especially useful during conceptual and logical design.
Relational Model
The relational model represents data using relations, commonly implemented as tables consisting of rows and columns.
In relational terminology:
| Relational concept | Common database term |
|---|---|
| Relation | Table |
| Tuple | Row |
| Attribute | Column |
| Domain | Permitted set or type of values |
| Key | Identifier for rows or relationships |
Current PostgreSQL documentation describes relational tables as structures containing rows and typed columns. PostgreSQL table documentation provides a straightforward implementation example.
How the Models Work Together
An ER diagram is frequently transformed into a relational schema:
- Entities become tables.
- Attributes become columns.
- Identifiers become primary keys.
- One-to-many relationships use foreign keys.
- Many-to-many relationships become associative tables.
Therefore, the ER model is not simply a competing replacement for the relational model. It is often used to design the concepts and relationships that the relational schema will implement.
Hierarchical Data Models
A hierarchical data model organizes records into a tree structure.
Each child record has one parent, while a parent can have multiple children.
Example:
LIBRARY
├── FICTION
│ ├── BOOK A
│ └── BOOK B
└── NONFICTION
├── BOOK C
└── BOOK DHierarchical models can work well when the domain naturally follows parent-child relationships, such as:
- File systems
- Organizational structures
- Product categories
- XML documents
- Geographic hierarchies
Limitations
Strict tree structures make some relationships difficult to represent.
For example, a book with several authors introduces a many-to-many relationship that does not fit naturally into a single-parent hierarchy. Representing it may require duplication, cross-references, or application-specific logic.
Important Distinction
A hierarchical model is a logical way of organizing relationships. It should not be described merely as the physical implementation of an information model.
A hierarchical model can be implemented using different physical storage techniques, just as a relational model can.
Keys in Relational Modeling
Keys identify records and connect tables.
Primary Key
A primary key uniquely identifies each row.
BOOK.book_idForeign Key
A foreign key references a key in another table.
BOOK.publisher_id → PUBLISHER.publisher_idCandidate Key
A candidate key is any minimal attribute or combination of attributes capable of uniquely identifying a row.
For a book, possible candidate keys might include:
- Internal
book_id - ISBN, when it is present and unique within the modeled scope
Composite Key
A composite key consists of multiple columns.
BOOK_AUTHOR(book_id, author_id)Together, these values uniquely identify an author’s association with a book.
Constraints and Business Rules
A model must represent more than data fields. It should also capture rules that protect data integrity.
Examples include:
- Every loan must reference an existing borrower.
- A return date cannot precede the checkout date.
- ISBN values must be unique when supplied.
- A book copy must be associated with exactly one title.
- A loan cannot have a negative renewal count.
A physical relational schema can enforce these rules with:
PRIMARY KEYFOREIGN KEYUNIQUENOT NULLCHECK- Application or procedural logic
Example:
CREATE TABLE loan (
loan_id BIGINT PRIMARY KEY,
borrower_id BIGINT NOT NULL,
copy_id BIGINT NOT NULL,
checkout_date DATE NOT NULL,
due_date DATE NOT NULL,
return_date DATE,
CONSTRAINT chk_loan_due_date
CHECK (due_date >= checkout_date),
CONSTRAINT chk_loan_return_date
CHECK (
return_date IS NULL
OR return_date >= checkout_date
)
);Normalization
Normalization is a relational design process used to reduce unnecessary duplication and prevent modification anomalies.
Suppose one table stores:
| loan_id | borrower_name | borrower_email | book_title | due_date |
|---|---|---|---|---|
| 9001 | Maria Chen | maria@example.com | Data Systems | 2026-09-01 |
| 9002 | Maria Chen | maria@example.com | SQL Basics | 2026-09-04 |
The borrower’s details appear repeatedly. If the email address changes, multiple rows must be updated.
A normalized design separates the information:
BORROWER
- borrower_id
- borrower_name
- borrower_email
BOOK
- book_id
- book_title
LOAN
- loan_id
- borrower_id
- book_id
- due_dateNormalization can improve integrity and maintainability. However, the degree of normalization should reflect the workload. Analytical systems sometimes use deliberate denormalization to make frequent queries simpler or faster.
Schema and Instance
Two related database concepts are schema and instance.
Schema
A schema defines the structure of the data:
- Tables
- Columns
- Data types
- Keys
- Relationships
- Constraints
A schema is comparable to a blueprint.
Instance
A database instance, in this context, refers to the actual data stored at a particular moment.
For example, the schema defines a BOOK table. The current collection of book rows is the table’s present state.
The schema changes relatively infrequently, while the stored records may change continuously.
The Three-Schema Perspective
Data independence is easier to understand through three abstraction levels.
External Level
The external level contains user- or application-specific views.
A librarian might see:
book title
borrower name
due dateA financial employee might see:
fine amount
payment status
payment dateBoth views can be derived from the same underlying database.
Conceptual Level
The conceptual level describes the overall logical database structure:
- Entities
- Attributes
- Relationships
- Constraints
It represents the integrated organizational view without specifying physical storage details.
Internal Level
The internal level describes how the DBMS stores and accesses the data:
- Files
- Pages
- Indexes
- Partitions
- Compression
- Record layouts
- Access paths
These layers help insulate users and applications from implementation changes.
Logical Data Independence
Logical data independence is the ability to change the conceptual schema without requiring corresponding changes to every external view or application.
Examples may include:
- Adding a new optional attribute
- Separating one entity into multiple logical structures
- Introducing a new relationship
- Adding an entity that existing applications do not use
Suppose an application reads a stable borrower_summary view. The underlying model may be reorganized while the view preserves the interface expected by the application.
Logical data independence is difficult to achieve perfectly because major conceptual changes can affect application meaning and behavior.
Physical Data Independence
Physical data independence is the ability to change internal storage structures without changing the conceptual schema or application interface.
Examples include:
- Adding an index
- Moving data to different storage
- Changing a partitioning strategy
- Compressing a table
- Reorganizing database files
- Changing an access path
For example, a database administrator might add an index:
CREATE INDEX idx_loan_due_date
ON loan (due_date);Queries can continue using the same tables and columns. The application does not need to know how the DBMS accelerates the lookup.
Physical Storage Independence
The source transcript presents physical storage independence as a third, separate category. In most database architecture discussions, moving or reorganizing data across storage devices is treated as an example of physical data independence.
Therefore, the clearer classification is:
- Logical data independence
- Physical data independence
Changes to physical devices, file placement, and storage layouts normally belong to the second category.
Why Data Independence Matters
Data independence allows systems to evolve with less disruption.
Benefits include:
- Reduced application maintenance
- Easier performance tuning
- Greater infrastructure flexibility
- Safer database evolution
- Separation of business meaning from storage technology
- Longer application life
- Lower migration costs
Without appropriate abstraction, even a small database change could require modifications throughout every dependent application.
A Practical Modeling Workflow
A practical data-modeling process can follow these steps:
1. Define the Domain
Determine the organizational area and problem being modeled.
Library lending and inventory2. Gather Business Requirements
Interview stakeholders and document important rules.
A borrower may check out multiple book copies.
A book copy can have only one active loan.3. Create an Information or Conceptual Model
Identify the major concepts and relationships.
BOOK, AUTHOR, COPY, BORROWER, LOAN4. Build the Logical Model
Add attributes, identifiers, cardinalities, and normalized relationships.
5. Validate with Stakeholders
Confirm that terminology, rules, and relationships reflect the real domain.
6. Create the Physical Model
Select table names, database data types, constraints, and indexes.
7. Implement and Test
Create the database and test:
- Data integrity
- Query correctness
- Transaction behavior
- Performance
- Security controls
8. Maintain the Model
Update the model as business requirements and technical systems change.
A data model should be treated as living documentation rather than a one-time diagram.
Key Takeaways
- Information models describe the meaning of business information at a high level.
- Data models describe how that information is organized and represented.
- Modeling commonly progresses through conceptual, logical, and physical levels.
- Entities represent distinguishable concepts, while attributes describe them.
- Relationships connect entities, and cardinality specifies how many instances may participate.
- ER diagrams can represent conceptual, logical, or physical models.
- ER models frequently support the design of relational schemas.
- Hierarchical models organize data as parent-child trees but can struggle with many-to-many relationships.
- Primary keys identify rows, while foreign keys connect related tables.
- Normalization reduces avoidable duplication and modification anomalies.
- Logical data independence separates external views from conceptual changes.
- Physical data independence separates logical database structures from storage implementation.
- Storage relocation is generally an example of physical data independence, not a separate third category.
Conclusion
Information and data models bridge the gap between how an organization understands its domain and how a database stores that domain’s data.
An information model establishes shared concepts, meanings, relationships, and business rules. Conceptual and logical data models refine those ideas into a precise structure. A physical model then translates that structure into tables, columns, keys, constraints, indexes, and other implementation details.
Maintaining clear separation between these levels makes database systems easier to understand, validate, implement, and change.
One-sentence summary: Information models define the meaning of organizational concepts, while conceptual, logical, and physical data models progressively transform those concepts into an implementable database design.