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.