Business rules & good data definitions

The model is just business rules, drawn

Before you draw a single box, understand where the boxes come from. An entity-relationship (E-R) model is a logical, technology-independent picture of an organization's data — entities, relationships, and attributes — and every line of it is a business rule made visible. A crow's foot on a relationship is the business saying "a customer may place many orders." A mandatory bar is the business saying "every order must belong to a customer." So the real input to modeling is a clean set of business rules.

A business rule is a statement that defines or constrains some aspect of the business — it asserts business structure or controls the behavior of the business. Two facts about rules drive everything in this chapter:

1. Businesspeople own the rules; the analyst surfaces them. You do not invent business rules — the organization already operates under them. Your job is to interview, read the policy manuals and contracts, and ask who / what / when / where / why / how until vague "business ramblings" become precise, checkable statements.
2. Rules are gathered iteratively. Initial statements are imprecise. You refine them by asking "Is this always true? Are there exceptions? Can there be many? Do we need history or just the current value?" — and the act of drawing the diagram itself surfaces rules nobody had stated.

The seven properties of a good business rule

A business rule is well-formed when it is declarative, precise, atomic, consistent, expressible, distinct, and business-oriented. Read each as a test you can apply:

• Declarative — states what the policy is, not how it is enforced (no code, no procedure).
• Precise — has exactly one interpretation among all stakeholders.
• Atomic — states one indivisible thing. This is the most commonly violated property: a rule with "and"/"or" in it is really two rules and must be split.
• Consistent — does not contradict any other rule.
• Expressible — can be written in structured natural language.
• Distinct — not redundant with another rule.
• Business-oriented — stated in business terms, owned and modifiable only by businesspeople.

Term vs fact (and why it matters)

Good definitions rest on two building blocks:

• A term is a word or phrase with a specific business meaning — customer, section, reservation. Terms are the vocabulary that becomes your data names.
• A fact is an association between two or more terms, written as a simple declarative statement — and a fact adds no constraint.

Worked example. Take the statement "A customer may request a model of car from a rental branch on a particular date." That is a fact: it associates the terms customer, model, rental branch, and date. It becomes entity types and a relationship on the diagram. Now add "A customer may not request two models on the same date." That is not part of the fact — it is a separate constraint (a different business rule), and it shows up as cardinality and supplemental documentation, not as a new box. Folding the constraint into the fact would produce a non-atomic, imprecise rule. Keeping facts and constraints separate is exactly what lets the diagram stay clean: facts → entities and relationships; constraints → cardinalities and notes.

Finally, a usable definition of a term starts with "An X is…", states the unique characteristic of each instance, makes explicit what is included and excluded, and stands alone (it never embeds another definition). Getting definitions right — what exactly is a "Student"? — is often the hardest part of modeling, because the same word means different things in different departments.