| name | conceptual-data-modeling |
| description | Identifies business concepts, entities and relationships without premature physical design. Use when starting data architecture or aligning business language with information models. |
| aliases | ["conceptual-data-modelling","conceptual-data-model"] |
Conceptual Data Modelling
When to use
Use for business-facing models, BCM/value-stream-to-data translation, ontology input or domain concept clarification.
Objective
Produce a practical, concise, traceable architecture artefact that a coding agent can use to guide implementation or review.
Procedure
- Define scope and business questions.
- Extract concepts from capabilities, value streams, processes and language.
- Remove implementation-only items.
- Define each concept in business terms.
- Identify relationships with meaningful verbs.
- Distinguish entity, event, role, classification and value object.
- Link concepts to source artefacts and owners.
Required outputs
- Concept list with definitions
- Relationship list with verbs
- Exclusions and rationale
- Traceability to business artefacts
- Open questions
Best-practice alignment
Apply DAMA-DMBOK2-style separation of data governance, architecture, modelling, security, integration/interoperability, master/reference data, metadata and quality. For cloud/shared data, apply CDMC-style expectations: ownership, classification, entitlement/access evidence, lineage/provenance, lifecycle/retention, quality controls and auditable evidence.
Quality checks
- Concepts use business language.
- No physical tables, columns or system artefacts unless business-significant.
- Relationships are meaningful.
- Scope is explicit.
Avoid
Do not jump to physical schemas or over-normalise.
References
Verification
