May 25, 2009 by Adriana Beal
Data modeling, a widely used technique in modern systems analysis and design, is described, in Wikipedia, as “a method used to define and analyze data requirements needed to support the business processes of an organization”. A common misconception is that data modeling is the same as database design. Even though the data modeler’s work will eventually lead to precise, detailed database designs,
a conceptual data model should not be confused with database design.
Many authors use the terms conceptual data model and logical data model interchangeably, but even though there is no clear boundary separating a conceptual data model from a logical data model, it is useful to treat them as separate notions, especially from a business analysis perspective:
| Conceptual data model | Logical data model | Physical data model |
| Explore high-level static business structures and concepts.
Emphasizes readability for non-technical people. Abstract, low level of detail. Focus on the most important entities, attributes, and relationships (issues such as cardinality, optionality, and data types may be skipped at this level). |
Provides a blueprint from which a physical database can be developed.
Defines the data tables, the data columns of those tables, and the relationships between tables. Includes fully normalized entities with all attributes defined, candidate keys to use for unique identification of each occurrence in every entity, many-to-many relationships translated into associative entities, and additional details, such as cardinality and whether relationships are optional or mandatory. |
Transforms the logical data model into a physical implementation using a specific DBMS product such as DB2, Oracle, or SQL Server. |
What is the conceptual data model used for?
Conceptual data models can be developed at the enterprise level and at the software application level. A conceptual data model is a useful reference during the requirements eliciting phase of a project:
- from a project management perspective, it helps establish the size of the effort (e.g., a project with 100 data entities in the conceptual data model will probably take longer to develop than another one with only 10).
- from the business’ perspective, it helps identify the people, things and concepts that are important for the business, and the relevant relationships among them.
- from a developer’s perspective, it serves as a basis for clarifying the data requirements and developing the logical data model.
Is a conceptual data model always needed in software development projects?
Requirements elicited from stakeholders of a project need to be complete and clear. The use of both textual and visual requirements models helps uncover missing, ambiguous, erroneous and conflicting requirements, and let stakeholders look at requirements from more than one angle. An experienced business analyst will select multiple models to help identify, communicate, and prioritize requirements. In most cases, adding a conceptual data model will provide richer insight into the requirements.
Many projects run into trouble because of the lack of a clear understanding of the data requirements. Missing requirements often lead to expensive and lengthy project delays, or require workarounds that diminishes the credibility of the application. For example, if the relationship between customer and mailing address is modeled as a one-to-one relationship, and it is discovered later that some customers may have multiple mailing addresses (requiring a one-to-many relationship), the project may have to incur the cost and delay associated with changing the database schema, or the business will have to resort to an undesired solution of adding multiple records for the same customer to avoid the database change.
At which point, in the requirements model roadmap, is the conceptual data model developed?
Typically, before creating a conceptual data model, the analyst will develop initial use cases to get a reasonable understanding of the problem that needs to be solved, and of the tasks the people who will use the system need to be able to perform. Based on the types of tasks that the system will have to support, the analyst can sketch a first data model for the problem. For example, a system used to manage a call taxi service might require the following tasks and related data:
| task | data that could be recorded |
| receive request | request number, customer name (or ID), pickup address and phone number, status of nearby subordinate taxis (occupied, off-duty, vacant). | dispatch driver | request number, assigned taxi registration number and vehicle model, driver’s name, estimated arrival time. |
As the business analyst walks through available use case descriptions and scenarios, she should continue to refine the conceptual data model, constantly asking herself what data is needed and is not yet represented in the data model.
References
Database DesignKnow It All
Toby J. Teorey et al. Morgan Kaufmann,November 2008.
Database Administration: The Complete Guide to Practices and Procedures
Craig S. Mullins. Addison-Wesley Professional, 2002.
Subscribe in a reader