FactumChapter 10 of 10
Pitfalls and a checklist
The mistakes that recur, and what to verify before you map the model to anything.
Modeling from the database backwards
The most common failure is not a notation error. It is drawing the tables you already intend to build, and using ORM to decorate them. The symptom is easy to spot: object types that correspond one-to-one with planned tables, every fact type functional, no m:n anywhere, and a suspicious number of types called SomethingHeader or SomethingDetail.
The fix is to go back to step 1 and read facts off a real report. If you have no report, you are not ready to model.
Making everything mandatory
Mandatory dots are added defensively — of course a person has a name, of course an order has a customer. But mandatory means the system refuses to know about an object that lacks the fact, which is a much stronger claim, and it is usually contradicted by the first week of real data entry. Ask "can this exist in our records before we know that?" for each dot.
Overusing "has"
A schema where every predicate reads "has" has lost most of the value of verbalization. "Person has Date" tells you nothing; "Person was born on Date" tells you what the fact means, and makes a wrong constraint obvious when you read it aloud. Whenever you type "has", spend five seconds looking for the real verb.
Value types doing an entity's job
If you find yourself parsing a value — splitting '69-301' into a building and a room,
or reading a prefix out of a code — you have an entity type modeled as a string. Give it a proper
reference scheme, composite if necessary, as chapter 3 describes.
Subtypes without definitions
A subtype with no rule saying who belongs to it is a category, not a subtype. Either write the defining sentence in terms of facts already in the model, or replace the subtype with a fact type recording the category. Chapter 8 has the test.
N-ary fact types that should be binaries
A ternary is right when its three roles are genuinely irreducible — a booking of a room on a day, a score in a subject in a semester. It is wrong when it bundles independent facts about one object, and the uniqueness pattern gives it away: a constraint that misses two roles means the fact type splits. Run the arity check rather than trusting your instinct.
Forgetting that m:n still needs a constraint
"Many-to-many" is not the absence of a rule. A spanning uniqueness constraint says the same pair is not recorded twice, which is usually what you mean and is not automatic. A fact type with no uniqueness constraint at all permits unlimited duplicates.
Constraining today's data instead of the rules
Sample data is evidence, not law. Every value in a sample being distinct does not make the role unique; it may just be a small sample. Use the population to generate the question, then ask the domain expert to answer it. The useful form is always: "here are two rows — could both be true?"
A checklist before mapping
Run through this before generating a schema from the model. Factum checks the mechanical ones for you and reports them in the Problems panel; the rest need a human.
| Check | Why |
|---|---|
| Every entity type has a reference scheme | Otherwise there is no way to refer to an instance, and the mapper invents a surrogate key |
| Every fact type has a uniqueness constraint | Without one, the same fact may repeat without limit |
| Every n-ary uniqueness constraint spans at least n−1 roles | A narrower one means the fact type is not elementary |
| Every role is attached to an object type | An unattached role cannot be populated or mapped |
| Every fact type has a reading that verbalizes well | The verbalization is the specification; if it reads badly, nobody will check it |
| Every optional role has been questioned | Optional roles are where subtypes hide |
| Every mandatory role has been questioned | Mandatory is a strong claim about what the system may know |
| Every subtype has a definition | Otherwise it is a category, not a subtype |
| Every fact type can be populated from real data | An unpopulatable fact type was invented, not observed |
| The verbalization has been read by a domain expert | This is the entire point of the method |
Where to go next
Draw something real. The method does not become useful by being read about — it becomes useful the first time a verbalized sentence makes a domain expert say "no, that's not right".
From here: Mapping rules covers turning the model into a relational or property graph schema; the reference lists every constraint and validation rule; and Halpin and Morgan's Information Modeling and Relational Databases is the full treatment this book compresses.