Conceptual Data Modeling

A conceptual data model should be employed to define and communicate high-level relationships between concepts/entities. In other words, they help an organization see their data – and the relationships between different types of data – in context.

Ideally, they will be visual representations of data in context that tell the story of how an organization operates in particular circumstances. This can help organizations avoid oversights that could cause significant problems down the line. For example, when building or acquiring a new customer relationship management (CRM) system, the need to distinguish between a prospect and a customer might not be clear. But without that distinction, a “new” prospect could actually be an employee of a company with an existing account.

A database that recognizes the distinction between a prospect and a customer also can be modeled to recognize any potential relationship between a new prospect and existing customer, allowing the record to be consolidated. This way, the sales rep(s) and support rep(s) have the context they need to work effectively.

Conceptual data models are used in the earlier stages of data modeling to organize and define concepts and rules based on use-case requirements. They are the least detailed of the three types of data models, but by no means does this make them less useful. In fact, one of the key benefits of conceptual data models is that they can be quickly comprehended and communicated to stakeholders outside the “tech” bubble.

Conceptual data models provide organizations with a starting point that should be evolved into more context rich diagrams as they move through the stages of data models. Through use-case analysis, use-case design  and database design, the complexity and level of detail will eventually peak with physical data models.

Bypassing the conceptual data modeling stage makes it far more likely for big-picture entity relationships to be missed – such as the customer/prospect distinction referenced above. Additionally, conceptual data models account for cardinality. Cardinality describes what an entity’s relationships to other entities may be, including one-to-one, one-to-many, or many-to-many.

Without conceptual data modeling, such an oversight becomes more likely, the deeper an organization is into the development cycle. This is because the big picture is often lost when teams are focused on design details and under the pressure of deadlines. By building the conceptual database model first, organizations can avoid such oversights and see that vague terminology, so the potential for relationships between entities is considered and defined ahead of time.

Some of the key benefits of conceptual data modeling include:

• Help define a common language and populate the business glossary: By providing a snapshot of concepts, entities and their relationships, gaps in terminology can be identified and oversights limited.
• Help shape the roadmap and define project scope: A conceptual model can help the relevant stakeholders better understand what is required to achieve their desired business outcomes from both a resource and time management perspective.
• Provide a basis for future models: Conceptual data modeling can be seen as the first step to more in-depth types of data modeling. Once the conceptual model is built, modelers can begin to introduce more context to the model. For a logical data model, that would be the data requirements of the database. For physical data modeling, the context would now include the specific database management system (DBMS) being modeled for.
• Foster an inclusive form of communication: Ensuring successful implementation requires stakeholder input from in and outside of the tech-bubble. Conceptual data models help foster this collaboration.