What is data modeling?
Data modeling creates a structured representation of the information an organization needs to store, manage and use.
A data model describes:
The entities an organization tracks
The attributes that describe each entity
The relationships between entities
The rules that keep data consistent
The structure of databases, files or data products
The way users and applications access data
For example, a retail business may model Customer, Order, Product and Payment as separate entities. The model shows how these entities relate to one another and which rules apply to each record.
Data modeling gives business and technical teams a shared reference for database design, data integration, data migration, reporting and data governance.
Core data modeling concepts
* Entities
An entity represents a person, object, event or business concept that the organization needs to store or manage.
Examples include:
Customer
Employee
Supplier
Product
Contract
Invoice
Shipment
Website session
Each entity should represent one clear concept. Combining unrelated concepts makes the model harder to understand and maintain.
* Attributes
Attributes describe the properties of an entity.
A Customer entity might include:
Customer ID
Name
Email address
Country
Registration date
Customer status
Each attribute needs a clear definition, format and owner. Teams should also decide whether it is required, how it is validated and how changes are recorded.
* Relationships
Relationships describe how entities connect.
Common relationship types include:
One-to-one
One-to-many
Many-to-many
A customer can have many orders, so the relationship between Customer and Order is one-to-many. A product can appear in many orders, while each order can contain many products. This creates a many-to-many relationship that usually requires an intermediate entity, such as Order Line.
* Keys and constraints
Keys identify records and connect entities.
A primary key uniquely identifies a record. A foreign key connects one entity to another. Constraints define rules such as:
A customer ID must be unique.
An order must belong to a customer.
A product price cannot be negative.
A required date cannot be empty.
A status must use an approved value.
These rules support consistency and data quality.
* Schemas
A schema describes the structure of data in a database, warehouse or application. It can define tables, columns, data types, keys, relationships and constraints.
Schema design should reflect business definitions as well as technical requirements. A field called status, for example, needs an agreed meaning and an approved list of values.
The 3 levels of data modeling
Data modeling usually progresses through 3 levels of detail.
1. Conceptual data model
The conceptual model gives a high-level view of the business domain. It identifies the main entities and their relationships without specifying database tables or technical implementation.
This model helps business stakeholders agree on what the organization needs to represent before discussing platforms or storage.
2. Logical data model
The logical model adds detail while remaining independent of a specific database engine.
It defines:
Attributes
Relationships
Identifiers
Data types
Business rules
Required and optional fields
A logical model can reveal duplicated concepts, missing relationships or unclear ownership before implementation begins.
3. Physical data model
The physical model describes how the data will be implemented in a specific technology.
It may include:
Tables
Columns
Data types
Primary keys
Foreign keys
Indexes
Partitions
Storage locations
Database-specific settings
Microsoft describes the physical model as the level that addresses the capabilities of a particular data engine, including storage details such as partitioning and indexing.
The physical model should follow the logical model while taking account of performance, security, cost and operational requirements.
Common data modeling techniques
Entity-relationship modeling
Entity-relationship modeling uses diagrams to show entities, attributes and relationships. It helps business analysts, architects and database designers agree on the structure before implementation.
ER diagrams also make cardinality visible. They show whether a relationship is one-to-one, one-to-many or many-to-many.
Normalization
Normalization organizes data into related structures and reduces unnecessary duplication.
A normalized model may store customer details in one table and order details in another. The relationship between them is managed through keys.
Normalization is often useful for transactional systems where records change frequently.
Denormalization
Denormalization combines or duplicates selected data to simplify queries or improve read performance.
It can be useful in reporting environments, data warehouses and analytical applications. The trade-off is additional duplication and a greater need for refresh and quality controls.
Dimensional modeling
Dimensional modeling structures data around facts and dimensions.
Fact tables store measurable events, such as sales or shipments.
Dimension tables describe the entities connected to those events, such as customers, products, locations or dates.
A star schema is a common dimensional design for data warehouses and analytics. Microsoft describes dimension tables as structures that represent the entities relevant to reporting and analytical requirements.
Data modeling and data architecture
Data modeling translates an architecture into usable structures.
A centralized architecture may use common enterprise entities, shared definitions and central control of key schemas. A federated model may let domains create their own models while requiring shared terms and interoperability rules. A data mesh may treat each domain’s model as part of a data product, with documentation, ownership and access conditions.
The selected centralized, federated or data mesh architecture affects:
Where models are created
Who approves changes
Which definitions are shared
How domains exchange data
How lineage is recorded
How data products are documented
How quality is measured
A data model should reflect both the technical structure and the operating model behind it.
These choices connect model design with the wider Data Strategy & Operating models of the organization. Ownership, shared definitions and technical structures need to support the same way of working across teams.
Data modeling best practices
Start with business questions
Define what the organization needs to understand, report or manage. The model should support real decisions and processes.
Use shared definitions
Terms such as Customer, Product, Revenue and Active Account need agreed meanings. Shared definitions reduce confusion between departments and systems.
Separate business and technical decisions
Agree on entities, relationships and rules before choosing table names, indexes or database settings. This keeps the logical model useful when the technology changes.
Document assumptions
Record why an entity exists, who owns it, how it is updated and which rules apply. Documentation helps future teams understand the model without reconstructing its logic from code.
Plan for change
New markets, products, regulations and applications can affect the model. Define how changes are requested, reviewed, tested and communicated.
Include quality and security
A model should identify sensitive attributes, access requirements, retention rules and quality checks. Security and compliance decisions are easier to apply when they are considered during design.
Conclusion
Data modeling gives an organization a shared way to describe its data, relationships and rules.
The main stages are conceptual, logical and physical modeling. Common techniques include entity-relationship modeling, normalization, denormalization and dimensional modeling.
The right approach depends on the data architecture, the business domain and the way teams will use the information. When data model design needs to support wider architecture or governance decisions, organizations can explore data strategy consulting.
