Skip to content
Software Architecture Guide

Conceptual Data Model Preparation for Logical and Physical Models

Explanation

Section titled “Explanation”

A conceptual data model is a high-level, abstract view of the business data. It shows entities (the things the business cares about), attributes (facts about them) and relationships between them. See Conceptual Data Model for the basics.

The last step of building it is a preparation step. The team checks the model before handing it on. The model is the base for two later models. The logical model refines it. The physical model then refines the logical one for a specific database technology. See Conceptual, Logical and Physical Data Model for the comparison.

What to check before handover

  • Coverage. Every business need should show up in the model. Validating the model with stakeholders helps find gaps and missed requirements.
  • Clear definitions. Each entity, attribute and relationship should be well defined.
  • Business rules. Engaging business stakeholders helps ensure the model meets their needs and captures accurate business rules.
  • Audience fit. The conceptual diagram shows only entities and relationships, written for a business audience.

What stays out

Technical detail belongs to later stages. Data types are fixed only in the physical model. Tables, columns and indexes also belong there. Normalization removes redundant data and improves data integrity. It is a typical refinement in the logical and physical stages, not in the conceptual model.

The blurry boundary

The line between conceptual and logical models is somewhat blurry. This makes it easy to add too much detail too early. Decide deliberately how much detail the conceptual model carries, and keep it at the business level.

Example

Section titled “Example”

A team models an online bookshop. The conceptual model has the entities Customer, Order and Book. Customer places Order, and Order contains Book. Before handover, the team walks through the model with sales staff. They notice that returns are missing, so they add a Return entity and its relationship to Order. The model contains no data types or tables. The database team can now refine it into the logical model and then the physical one.

Trade-offs

Section titled “Trade-offs”

More review before handover costs time and needs business people to take part. Skipping it risks carrying gaps into the logical and physical models, where they are harder to fix. Keeping the model free of technical detail makes it readable for the business. It also means technical questions wait until later stages. Because the conceptual and logical boundary is blurry, teams must agree on how much detail is enough.

Handover path from the conceptual model to the logical and physical models

Diagram source 
flowchart LR
  A[Conceptual model: entities, attributes, relationships] --> B[Review with stakeholders]
  B --> C[Logical model]
  C --> D[Physical model for a specific database]

Checks

Section titled “Checks”
  • The conceptual model was validated with business stakeholders, and found gaps were recorded.
  • The conceptual diagram shows only entities and relationships, in terms a business audience understands.
  • The conceptual model contains no data types, tables, columns or indexes.
  • The document states how the conceptual model is handed over to the logical and physical models.
Section titled “Related”

Sources

Section titled “Sources”