Conceptual Data Model

flowchart LR
  party["Party"]
  cust["Customer"]
  supp["Supplier"]
  prod["Product"]
  order["Order"]
  ship["Shipment"]
  inv["Invoice"]
  pay["Payment"]
  loc["Location"]

  cust -->|"is a"| party
  supp -->|"is a"| party
  cust -->|"places"| order
  order -->|"is for"| prod
  supp -->|"supplies"| prod
  order -->|"is fulfilled by"| ship
  ship -->|"is sent to"| loc
  order -->|"is billed on"| inv
  inv -->|"is settled by"| pay

What it is

The business's nouns and the sentences connecting them. No attributes, no cardinality notation, no keys, no tables. Ten to fifteen boxes is the right size — if it needs thirty, the scope is a programme rather than a system.

Its purpose is agreement on vocabulary before anyone designs anything. The "Party" supertype in the example is typically where the first real argument happens, because half the organisation has been treating customer and supplier as unrelated while the same legal entity is both.

When you produce it

First, in discovery, and again at the start of a merger integration when two organisations discover they mean different things by "account".

Who reads it

Business stakeholders, who must be able to read it without training — that is the test. Architects and data modellers, who take it forward into logical and physical models.

What good looks like

• Relationship labels read as sentences in one direction.
• Supertypes are used where the business genuinely has them, and not otherwise.
• Every box is a thing the business names out loud.
• One page. Fifteen boxes at most.

Common mistakes

• Adding attributes, at which point it is a logical model and the business stops reading it.
• Modelling the current systems' tables rather than the business's concepts.
• Skipping it and going straight to an ERD, which locks in one system's vocabulary before anyone has agreed it.