Why fact-based modeling

The problem with attributes

Draw an entity in almost any modeling notation and the tool immediately asks you for its attributes. So you write them down: a Person has a name, a birth date, an email address, a department. It feels like recording facts. It is not. It is a series of commitments about structure, made at the exact moment you know least about the domain.

Each commitment can be wrong in a way that is expensive later:

• An attribute turns out to be many-valued. A person has two email addresses. The attribute becomes a table, and every query and every screen that touched it changes.
• An attribute turns out to need its own properties. You need to know when the person joined that department. The attribute becomes a relationship with a date on it.
• An attribute turns out to be an entity. Departments need budgets and heads of their own, so what was a string becomes a thing.
• An attribute cannot be constrained. "Exactly one of email or phone must be present" is not something an attribute list can say, so it moves into prose or code.

None of these are exotic. They are the ordinary course of a project. The problem is not that the first model was careless; it is that the notation forced a decision before the information needed to make it existed.

What ORM does instead

ORM has no attributes at all. There are objects, and there are the roles they play in relationships. That is the entire vocabulary. "Person works for Company" is a fact type with two roles; so is "Person has EmailAddress". Nothing is subordinate to anything else.

Because nothing was demoted to an attribute, the four changes above stop being structural. Adding a second email address means erasing a uniqueness bar. Recording when someone joined a department means objectifying the fact type and hanging a date off it. Promoting Department to an entity type with its own facts means changing one shape. The model absorbs the change instead of being reshaped by it — this is what people mean when they call ORM semantically stable.

The part that actually changes how you work

The attribute-free structure is what makes ORM technically attractive. Verbalization is what makes it useful on a Tuesday afternoon with a domain expert in the room.

Because every fact type is a sentence with holes in it, and every constraint is a statement about those sentences, the whole model can be read aloud:

Each Person works for exactly one Company.
It is possible that more than one Person works for the same Company.

An accountant cannot review an ER diagram. An accountant can absolutely tell you that the first sentence is wrong because contractors work for two agencies at once. You have just found a modeling error in the cheapest possible place — before any code, in a conversation — and the fix is to remove one uniqueness bar.

This is the loop the method is built around, and it is worth stating plainly because it is easy to nod at and then not do:

1. State the facts in sentences, using real examples from real reports.
2. Draw them.
3. Read the model back as sentences and check them against the examples.
4. Correct, and repeat.

Populating with examples

The second thing ORM gives you is the ability to test a model with data before a database exists. Each fact type can be populated with sample rows — real ones, taken from the report you are modeling. A constraint you are unsure about becomes a concrete question: can this column combination ever repeat? Show the expert two rows that would violate the constraint and ask whether they could both be true.

ER and UML diagrams cannot be populated this way, because an attribute is not a table you can fill in. This sounds like a small thing. In practice it is the difference between a model you believe and a model you have merely drawn.

What it costs

Honesty requires the other side. ORM diagrams are larger than ER diagrams — often two or three times the shapes for the same domain, because every attribute becomes a fact type with its own roles and constraints. On a wall-sized schema this is a real cost, and it is why ORM tools support views and why summary ER diagrams are sometimes generated from an ORM model for communication.

The trade is deliberate: more shapes on the page, fewer decisions taken on faith. If you are sketching something you will throw away next week, that trade is bad. If you are designing something that other systems will depend on for a decade, it is the whole point.