Conceptual Data Model Explanation

A concept is a key idea that is both basic and critical to your audience. “Basic” means this term is probably mentioned many times a day in conversations with the people who are the audience for the model. “Critical” means the business would be very different or non-existent without this concept.

The majority of concepts are easy to identify and include concepts that are common across industries, such as Customer, Employee, and Product. An airline may call a Customer a Passenger, and a hospital may call a Customer a Patient, but in general they are all people who receive goods or services. Each concept will be shown in much more detail at the logical and physical phases of design. For example, the Customer concept might encompass the logical entities Customer, Customer Association, Customer Demographics, Customer Type, and so on.

Many concepts, however, can be more challenging to identify, as they may be concepts to your audience, but not to others in the same department, company, or industry. For example, Account would most likely be a concept for a bank and for a manufacturing company. However, the audience for the bank conceptual data model might also require Checking Account and Savings Account to be on their model, whereas the audience for the manufacturing conceptual data model might, instead, require General Ledger Account and Accounts Receivable Account to be on the model.

In our publishing data model, for example, an audience that needs to see the entire company on a conceptual may just require the entity Order, yet in communicating with the sales department, the Sales Conceptual Data Model will have more details, such as showing not only Order but also Order Line and Order Adjustment.

Concepts such as those in the preceding discussion are represented on a conceptual data model. A conceptual data model is a set of symbols and text representing the key concepts and rules binding these key concepts for a specific business or application scope, for a particular audience, that fits neatly on one page. Limiting the conceptual data model to one page is important because it forces the modeler and participants to select only key concepts. We can fit 20 concepts on one page, but not 500 concepts. A good rule of thumb, therefore, is to ask yourself if the audience for this model would include this concept as one of the top 20 concepts in their business. This will rule out concepts that are at too low a level of detail; they will appear in the more detailed logical data model. If you’re having trouble limiting the number of concepts, think about whether or not there are other concepts into which the ones you’re discussing could be grouped, such as grouping Order Line into Order. These higher concepts are the ones you should be including in the conceptual data model.

The conceptual data model includes concepts, their definitions, and the relationships that show how these concepts interact with each other. Unlike the logical and physical data models, as we will see, conceptual data models may contain many-to-many relationships. A sample conceptual data model appears in Figure 8.1.

In this diagram, the display preferences in ER/Studio have been changed to display the concept descriptions. To display definitions on the model choose View > Diagram And Object Display Options, or click on the icon , and then choose Definition as the display level.

Figure 8.1 Healthcare Facility Appointment Conceptual Data Model

Business Rules (listed in the order we would typically walk someone through the model):

·         Each Person may be a Provider, a Patient, or both a Provider and a Patient. Note that when the subtyping symbol does not have an ‘X’ in its center (as shown in Figure 8.1), it indicates that a member of the supertype can play more than one subtype role. This is called an inclusive (overlapping) subtype. For example, a particular person can be both a provider and a patient.

·         Each Provider is a Person.

·         Each Patient is a Person.

·         Each Provider may offer one or many Appointments.

·         Each Patient may make one or many Appointments.

·         Each Schedule may be consulted to set up one or many Appointments.

·         Each Department may accommodate one or many Appointments.

·         Each Appointment must involve one Provider, one Patient, one Department, and one Schedule.

Notice on the model in Figure 8.1, that concepts such as Patient and Provider are likely to be considered concepts throughout the healthcare industry. There are also slightly more detailed concepts on this model, such as Schedule and Appointment, which are considered basic and critical, and are therefore concepts for the particular audience for this conceptual data model. Yet these more detailed concepts may not be considered concepts within a different department, such as accounting and marketing, in this same healthcare company.

During the conceptual data modeling phase, documenting clearly and completely what each concept means is critical. All too often, we wait until it is too late in the development process to get definitions. Waiting too long usually leads to not writing definitions at all, or doing a rush job by writing quick definition phrases that have little or no usefulness. If the definitions behind the terms on a data model are nonexistent or poor, multiple interpretations of the concept become a strong possibility. Imagine a business rule on our model that states that an Employee must have at least one Benefits Package. If the definition of Employee is lacking, we may wonder, for example, whether this business rule includes job applicants and retired employees.

By agreeing on definitions at the conceptual level, the more detailed logical and physical analysis will go more smoothly and take less time. For example, definitions can address the question, “Does Customer include potential customers or only existing customers?” See the cartoon in Figure 8.2 for an example of what not to do.

Figure 8.2 Clarify key concept definitions early!

When the conceptual data model is complete, which includes concept definitions, it is a powerful tool that can provide a number of important business benefits:

·         Provides broad understanding. We can capture extremely complex and encompassing business processes, application requirements, and even entire industries on a single piece of paper. This enables people with different backgrounds and roles to understand and communicate with each other on the same concepts, agreeing on or debating issues.

·         Defines scope and direction. By visually showing concepts and their business rules, we can more easily identify a subset of the model to analyze. For example, we can model the entire Logistics department, and then scope out of this a particular logistics application that we would like to build. The broad perspective of a conceptual data model can help us determine how planned and existing applications will coexist. It can provide direction and guidance on what new functionality the business will need next.

·         Offers proactive analysis. By developing a high-level understanding of the application, there is a strong chance we will be able to identify important issues or concerns, saving substantial time and money later on. Examples include term definition differences and different interpretations of project scope.

·         Builds rapport between IT and the business. A majority of organizations have some issues of internal communication between the business and IT departments. Building a conceptual data model together is a great way to remove or reduce these communication barriers. On one occasion, a key business user and I sketched out a Consumer Affairs CDM, which not only increased my business understanding, but also led to a strong relationship with this key user.