The Crow's Foot
Almost every "our reporting is unreliable" complaint is a data modelling failure wearing a BI costume. The boxes and lines decide which questions your business can ever ask — and they are drawn long before anyone writes a query.
Claims reports 1,247 open claims. Finance reports 1,190. Same database, same morning, and when you read both queries they are each correct. Nobody has made a mistake. What is actually going on?
How does a claim's status work?
A claim moves between open, closed and reopened over its life.
How does a claim relate to coverage?
A storm claim can hit buildings cover and contents cover at once.
How do you model people?
The person claiming is often also the person insured.
Two right answers
When two teams count the same thing differently, the fix is not a third query — it is deciding what the entity is. Have both teams draw the model separately; where the boxes differ is where the business disagrees, and it will not be settled in BI.
Discovered at go-live
Cardinality errors are cheap on paper and brutal in production. "One per claim" becomes "sometimes several" the first week you meet a real storm event — and by then there is data in the wrong shape to migrate.
Their model, your questions
Buying a system means buying its entity model. Ask for the ERD before the demo and check it against the questions you actually need answered — the demo will only show you the ones it is shaped for.
Garbage shape in
No model, warehouse or assistant can retrieve a fact the schema cannot represent. A history
overwritten by an UPDATE is not slow to query — it is gone, and no
amount of tooling downstream brings it back.
Draw the boxes before anyone writes SQL, and draw them in front of the people who will use the answers. If two people draw the same domain differently, you have found the real disagreement — and it was never about the report. Every question your organisation will want to ask for the next decade is either possible or impossible in the diagram you sketch this afternoon.