Reviewing a Model with Domain Experts and Developers

Learning outcomes

A data model is not validated because the designer can explain it. It is validated when domain experts recognize the business correctly, developers can implement the invariants, and representative scenarios—including awkward edge cases—fit without contradictions. Effective model reviews therefore combine diagrams with concrete stories, sample data, rules, and implementation questions.

A model review is not a presentation

The goal is not to prove the model is correct. The goal is to make defects easy to discover before they become migrations, production bugs, duplicate data, or impossible reporting requirements.

Choose the right reviewers

Different reviewers expose different classes of defect:

Prepare a review packet

Do not begin by sharing a 100-table physical ERD with no context. A useful packet includes:

• scope and non-goals;
• glossary of important terms;
• conceptual subject-area diagram;
• logical diagram for the area being reviewed;
• key business rules and invariants;
• three to ten representative scenarios;
• known ambiguities/open decisions;
• sample records or example payloads.

Review the vocabulary first

If participants disagree about what “customer,” “owner,” “account,” “asset,” or “assignment” means, detailed schema discussion will be unstable. Begin with terms:

• Is a Customer a legal organization, a billing account, or a person?
• Can one organization have multiple customer accounts?
• Does owner mean legal owner, current responsible party, or registrant?
• Is a Technician a subtype of Employee?

Record definitions in a shared glossary and use them consistently in the model.

Read every important relationship aloud

For WorkshopHub:

1. A Customer may own zero or many Assets.
2. Every Asset has exactly one current Customer owner.
3. An Asset may have zero or many WorkOrders.
4. Every WorkOrder services exactly one Asset.
5. A WorkOrder may have zero or many Assignments while open.
6. Every Assignment belongs to exactly one WorkOrder and one Technician.

Ask the domain expert to challenge each word: “may,” “every,” “current,” “exactly,” “one,” and “many.”

Scenario walkthroughs

Static diagrams hide lifecycle errors. Walk through real scenarios:

Scenario A — new asset

A customer registers an asset that has never needed service. Can the model represent the asset without a work order?

Scenario B — multi-technician repair

Two technicians work on the same repair at overlapping times with different roles. Can the model store both assignments without numbered columns?

Scenario C — ownership transfer

The asset is sold to another customer. Does the business need only current ownership, or must previous ownership remain queryable?

Scenario D — corrected serial number

A serial number was typed incorrectly. Can it change without changing the identity of the physical asset?

Use counterexamples deliberately

If someone proposes “email uniquely identifies a customer,” ask:

• Can a shared company email represent several contacts?
• Can a customer change email?
• Can a customer exist before an email is known?
• Can an old email later be reused?

Counterexamples test whether a candidate key or cardinality is actually guaranteed, rather than merely common.

Review invariants

An invariant is a rule that must remain true. WorkshopHub examples:

Every WorkOrder references an existing Asset.Every Assignment references an existing WorkOrder and Technician.ended_at is NULL or ended_at >= started_at.PartUsage.quantity > 0.A closed WorkOrder has a closed_at timestamp.A serial number is unique within manufacturer when present.

For each invariant, ask where it will be enforced: database constraint, transaction logic, workflow transition, asynchronous validation, or some combination.

Separate semantic questions from implementation questions

These are semantic:

• Can an asset have multiple owners at the same time?
• Can a technician be assigned twice to the same work order?
• Can work-order status return from closed to in-progress?

These are implementation questions:

• integer or UUID surrogate keys?
• which B-tree indexes?
• PostgreSQL enum or reference table?
• which ORM mapping?

Resolve semantics first. Implementation decisions depend on them.

Use sample data to expose grain

“Grain” means what one row represents. Ask reviewers to fill in sample records.

WorkOrderAssignment------------------------------------------------------assignment_id   501work_order_id   1842technician_id   17role            primarystarted_at      2026-08-10T09:00ended_at        2026-08-10T11:30

Then ask: if the technician returns after lunch, is that a second assignment row, a time-entry child row, or an update to the same assignment? The answer determines the row grain and keys.

Review deletion and history explicitly

Ask what “delete” means for each major entity:

• Can a Customer with historical work orders be physically deleted?
• Can a Part be removed from the catalog after it was used historically?
• Can a Technician be deleted after employment ends?
• Should an incorrect Assignment be deleted or voided/audited?

Retention requirements often turn naive cascade deletion into a serious defect.

Review time semantics

For every “current” relationship, ask whether history matters:

If historical answers matter, overwriting a single current value may be insufficient.

Implementation review with developers

Once semantics are agreed, developers should challenge:

• which operations must be atomic;
• which unique constraints prevent duplicate requests;
• which relationships are required at creation time versus later workflow states;
• which identifiers appear in APIs;
• which migrations will be needed for existing data;
• which queries are performance-critical;
• which constraints are expressible directly in the DBMS.

Capture decisions, not just meeting notes

A useful decision log records:

Decision:  Asset has one current owner in v1.Reason:  Co-ownership is out of current product scope.Consequence:  asset.customer_id is mandatory.Open follow-up:  Historical ownership is required for audit and will be  modeled before production migration.

This makes assumptions visible and revisitable.

Review findings should produce model changes

Classify findings:

• semantic defect — model contradicts domain;
• missing rule — rule exists but is not represented;
• ambiguity — business has not decided yet;
• implementation risk — semantics are clear but enforcement/migration is difficult;
• documentation issue — model is correct but unreadable or poorly named.

Assign an owner and close the loop before treating the model as approved.

A practical review checklist

Chapter 4 capstone review

For WorkshopHub, prepare two diagrams:

1. a conceptual diagram for Customer, Asset, WorkOrder, Technician, Part, Assignment, and PartUsage;
2. a logical diagram showing keys and the resolved associative entities.

Then walk through these cases: new asset, repeat repair, two technicians on one job, technician reassignment, repeated part use, serial-number correction, customer ownership transfer, and work-order closure. Record any ambiguity that prevents a definitive cardinality or key decision.

Summary and next chapter

Chapter 4 completed the communication layer of data modeling. You can now express the same semantics using Crow's Foot, Chen, or UML-style notation, organize diagrams for readability, and review them with the people who know the domain and must implement it. Chapter 5 moves from conceptual/logical models into systematic relational mapping: entities to tables, relationships to foreign keys, many-to-many associations, inheritance, and complex attributes.

References

• Steve Hoberman, Data Modeling Made Simple.
• Martin Fowler, Analysis Patterns.
• Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems.
• Thomas Connolly and Carolyn Begg, Database Systems.