What it shows:
A high-level, completely technology-agnostic map of the core business “things” (Entities) and the rules governing how they relate to each other (e.g., “One Project contains many System Models”). It does not show database tables, primary keys, or data.
Why it’s needed:
Vocabulary alignment and business rule enforcement. For greenfield or custom builds, this proves to the data owners that the business rules are fully understood before a single line of SQL is written or a database is provisioned.
When to use it:
Highly recommended for Custom Application Development, data warehousing projects, or complex integrations where the delivery team is actively designing the data structure or defining a new data model.
When NOT to use it:
Generally best to omit for standard COTS deployments (like CRM or ERP packages). The internal data relationships inside vendor-packaged software are not externally controlled or designed. The vendor dictates the schema, making a conceptual data design exercise redundant.
Example:
