Concept: Conceptual Data Modeling
The conceptual data model depicts the important entities and their relationships to explore the domain concepts with project stakeholders that define the scope of the problem to be addressed by the system solution.
Relationships
Main Description

Introduction

Conceptual data modeling represents the initial stage in the development of the design of the persistent data and persistent data storage for the system. In many cases, the persistent data for the system are managed by a relational database management system (RDBMS). The business and system entities identified at a conceptual level from the business models and system requirements will be evolved through the use-case analysis, use-case design, and database design tasks into detailed physical table designs that will be implemented in the RDBMS. 

The data model typically evolves through the following three general stages:

  • Conceptual-This stage involves the identification of the high level key business and system entities and their relationships that define the scope of the problem to be addressed by the system. These key business and system entities are defined using the modeling elements of the UML profile for business modeling included in the Business Analysis Model and analysis class model elements.
  • Logical-This stage involves the refinement of the conceptual high level business and system entities into more detailed logical entities. These logical entities and their relationships can be optionally defined in a Logical Data Model as described in Guideline: Data Modeling.
  • Physical-This stage involves the transformation of the logical  design into detailed and optimized physical database table designs. The physical stage also includes the mapping of the database table designs to tablespaces and to the database component in the database storage design.

The tasks related to database design span the entire software development lifecycle.  For projects that use business modeling to describe the business context of the application, database design may start at a conceptual level with the identification of Business Actors and Business Use Cases in the Business Use-Case Model, and the Business Workers and Business Entities in the Business Analysis Model.  For projects that do not use business modeling, the database design might start at the conceptual level with the identification of System Actors and System Use Cases in the Use-Case Model.

The figure below shows the set of Conceptual Data Model elements that reside in the Business Models, Requirements Models, and the Analysis Model.

 Conceptual Data Modeling Elements

The following sections describe the elements of the Business Models, Use-Case Model, and Analysis Model that can be used to define the initial Conceptual Data Model for persistent data in the system.

Conceptual Data Modeling Elements

Business Models

Business Use-Case Model

The Business Use-Case Model consists of Business Actors and Business Use Cases. The Business Use Cases represent key business processes that are used to define the context for the system to be developed. Business Actors represent key external entities that interact with the business through the Business Use Cases. The figure below shows a very simple example Business Use-Case Model for an online auction application.



Business Use Case Model

As entities of significance to the problem of space for the system, Business Actors are candidate entities for the Conceptual Data Model.  In the example above, the Buyer and Seller Business Actors are candidate entities for which the online auction application must store information.

Business Analysis Model

The Business Analysis Model contains classes that model the Business Workers and Business Entities identified from analysis of the workflow in the Business Use Case. Business Workers represent the participating workers that perform the actions needed to carry out that workflow.  Business Entities are "things" that the Business Workers use or produce during that workflow. In many cases, the Business Entities represent types of information that the system must store persistently. 

The figure below shows an example sequence diagram that depicts Business Workers and Business Entities from one scenario of the Business Use Case titled "Provide Online Auction" for managing an auction.

 Sequence Diagram

In this simplified example, the Auction Manager object represents a Business Worker role that will likely be performed by the online auction management system itself.  The Auction and Auction Item objects are Business Entities that are used or produced by the Auction Manager worker acting as an agent for the Seller and Buyer Business Actors.  From a database design perspective, the Auction and Auction Item Business Entities are candidate entities for the Conceptual Data Model. 

Requirements and Analysis Models

For projects that do not perform business modeling, the Requirements (System Use Case) and Analysis Models contain model elements that can be used to develop an initial Conceptual Data Model.  For projects that use business modeling, the business entities and relationships identified in the Business Analysis Models are refined and detailed in the Analysis Model as Entity Classes.  

System Use-Case Model

The System Use-Case Model contains System Actors and System Use Cases that define the primary interactions of the users with the system. The System Use Cases define the functional requirements for the system.

From a conceptual data modeling perspective, the System Actors represent entities external to the system for which the system might need to store persistent information. This is important in cases where the System Actor is an external system that provides data to and/or receives data from the system under development.  System Actors can be derived from the Business Actors in the Business Use-Case Model and the Business Workers in the Business Analysis Model. 

The figure below depicts the Business Use-Case Model for the online auction system. In this model, the Buyer and Seller Business Actors are now derived from a generic User Business Actor. A new System Actor named Credit Service Bureau has been added to reflect the need to process payments through an external entity. This new System Actor is another candidate entity for the Conceptual Data Model.



 Business Use Case Model