Chapter 01 · From Requirements to Data Models
Facts, Rules, Scope, and Assumptions
Separate facts from rules, define scope, surface assumptions, and build a decision log that keeps a data model explainable.
Learning outcomes
A model becomes trustworthy when readers can tell which statements are observed facts, which are business rules, which parts of the domain are intentionally excluded, and which decisions are temporary assumptions. This lesson gives you a lightweight discipline for recording all four.
Separate instance facts, structural facts, and business rules.
Define modeling scope so the schema does not accidentally absorb the entire organization.
Record assumptions and unresolved questions instead of hiding them in implementation.
Trace rules to constraints, transactions, or application logic.
Facts describe; rules restrict
A fact says something that can be true about the domain: “Work order 1842 belongs to asset A-91.” A rule restricts the set of allowed facts: “Every work order must belong to exactly one registered asset.” The distinction matters because rules often become schema constraints or transaction checks.
| Statement | Type | Possible representation |
|---|---|---|
| Technician 17 is assigned to work order 1842. | Instance fact | Row in an assignment table. |
| A work order can have several assignments over time. | Structural fact | One-to-many relationship. |
| An assignment end time cannot precede its start time. | Business/integrity rule | CHECK constraint where supported. |
| A closed work order cannot receive new part usage. | State-transition rule | Transaction/service rule, possibly enforced with database logic. |
Rules have different enforcement homes
Not every rule is best enforced in exactly the same place. Some are local to one value or row; some span tables; some depend on workflow state; some need external systems. Good design identifies the rule first and then chooses the strongest practical enforcement point.
Domain rule
Quantity must be positive. Often a column or row constraint.
Referential rule
Part usage must reference an existing part and work order. Foreign keys fit naturally.
Cross-row rule
Only one active primary assignment per order. May need a partial unique index or transaction logic.
Workflow rule
Closed orders cannot return to “in progress” without reopening authorization. Usually transaction/application logic.
Define scope before discovering endless entities
Real organizations contain customers, invoices, employees, payroll, warehouses, vendors, tax rules, marketing campaigns, legal documents, and thousands of other concepts. A single database project should not model everything merely because those concepts exist.
For WorkshopHub version 1, a reasonable scope might be:
- customer and asset registration;
- repair work orders and technician assignments;
- parts consumed on work orders;
- operational status and timestamps needed for turnaround reports.
Explicitly out of scope might be payroll, vendor purchasing, accounting ledgers, marketing leads, and fleet route optimization. Those systems may integrate later without belonging to the first bounded model.
Scope determines what must be authoritative here and what can remain a reference to another system. Without scope, the model grows by accident.
Assumptions are temporary constraints on uncertainty
Suppose no stakeholder is available to answer whether asset ownership history is required. You still need to progress. Record an assumption rather than burying it in a schema choice:
A-07 — For version 1, each asset has one current customer owner.Open question: must previous ownership be retained?Impact if wrong: replace customer_id on asset with an ownership-history entity.This is much safer than silently adding customer_id and later presenting it as if the business had approved the rule.
Use a decision log
A data-model decision log can be very small. What matters is traceability.
| ID | Decision / assumption | Reason | Impact |
|---|---|---|---|
| D-01 | Technician assignments are historical entities. | Managers require previous assignments. | Add assignment timestamps; do not store only current technician. |
| D-02 | Asset serial uniqueness is manufacturer-scoped. | Stakeholder confirmed duplicate serials across manufacturers exist. | Unique key on (manufacturer_id, serial_number). |
| A-07 | Only current asset owner retained in v1. | History requirement unresolved. | Potential future migration. |
Invariants are the most valuable rules
An invariant is a condition that must remain true whenever the system reaches a committed state. Invariants deserve special attention because they define valid data.
- Every work order references exactly one asset.
- Part-use quantity is greater than zero.
- An assignment's
ended_atis null while active and never earlier thanstarted_at. - A work order's closing timestamp is present when and only when the order is closed.
Later chapters will connect invariants to keys, constraints, transactions, and isolation. For now, practice stating them in plain language.
Practice: classify the statements
Classification exercise
- “Part P-18 was used twice on work order 1842.”
- “A work order must have at least one customer-visible problem description.”
- “Payroll is not part of the repair database.”
- “We assume one active primary technician per order until operations confirms team handling.”
Review the answers
The first is an instance fact. The second is a rule. The third is a scope boundary. The fourth is an assumption with an unresolved validation step. All four belong in the modeling process, but they should not be confused with each other.
Summary and next lesson
Facts describe the domain; rules constrain valid facts; scope declares what this model is responsible for; assumptions make uncertainty explicit. A model with a decision log is easier to review, change, and defend. The next lesson introduces conceptual, logical, and physical models so these decisions can be expressed at the correct level of abstraction.
References
- C. J. Date, Database Design and Relational Theory.
- Martin Fowler, Analysis Patterns.
- Eric Evans, Domain-Driven Design.
- ISO/IEC 9075 SQL standard family for relational constraints and database behavior.