Conceptual Data Modelling: Start With Business Use Cases

A business analysis approach to data modelling

Successful business analysis requires understanding of business. One of the essential tools for understanding a business is a conceptual data model.

Even though conceptual models are relatively easy to understand and create, business analysts do not use them enough.

This article will discuss how to use the information in a use case diagrams to create a conceptual data model.

Definition

A conceptual data model is a structured business view of the data required to support business processes, record business events, and track related performance measures.

Conceptual models establish business knowledge and name key business entities and relationships between them.

They enforce consistent business terminology and identify the concepts that exist independent of any technology implementations.

Challenge

One of the challenges that business analysts and architects face in creating conceptual models is that business stakeholders do not want to spend time “diagramming”.

While they acknowledge the value of process models, creating other diagrams may be perceived as a nice-to-have activity, or something that technology people do.

If an analyst requests a meeting with key stakeholders “to create a conceptual data model” without sufficient background or a trust factor, they may not get sufficient support and participation.

The use case approach

A more subtle approach may work in this case. The analyst can start by engaging stakeholders in defining business use cases.

A business use case is a way in which a customer or some other interested party can make use of the business system to get the result they want.

The concept of a business use case is well understood.

A project initiation requires an agreement of use cases in scope.

Defining and confirming business use cases with stakeholders is a legitimate request with a clear value.

A smart analyst will extract a lot of useful information from this exercise, including the main components required to start building a conceptual data model. And once the draft is created, it will be much easier to expand on.

Let’s consider how it can be done.

Defining use cases

A business use case defines what a business persona (actor) does to achieve a specific business goal.

An actor is an entity that interacts with business system and has an interest in a specific outcome.

Each use case must be associated with an actor and expressed as a “verb + noun” combination, indicating an action and the object or goal of the action.

Let’s illustrate with a simple use case diagram below, using a catering company for our case study. At the conceptual level, it is not necessary to indicate system boundaries. The focus must be on what each actor needs , regardless of what technology is in place to support it.

Now, we can examine the diagram to discover business entities.

An entity is a person, organization, object, or concept about which information is stored.

It is the easiest to start with actors — people, roles, departments or organizations.

You do not have to create a separate entity per actor — first, think in categories.

In this model, observe four actors: Customer, Sales, Service Representative and Meal Manager.

For simplicity, start by categorizing them as internal and external entities — Customers and Employees. Is it sufficient to have one entity to represent Employees?

In conceptual data modelling, always start from a simpler model, and then judge whether it requires more granularity to achieve its purpose.

Now, consider the objects (nouns) in the use cases. What are they?

An Order, a Proposal, an Account, a Menu, and Ingredients.

Each of these objects is a candidate entity for the conceptual model.

Some of the entities clearly have a relationship captured in the use case diagram — for instance, Customer and Order.

Remember that the use case diagram may not contain all required information — or may be incomplete in the first place.

Building the model

Step 1. The first version of the model can be just a collection of placeholder entities. The main goal of this version will be to trigger more discussion and elicit essential information.

This model is quite incomplete. However, seeing these key entities on a page will generate questions about connections between them.

These connections will become relationships in the conceptual data model.

A relationship is a dependency or an association between two entities.

As the business analyst discovers relationships, additional questions will need to be asked to confirm the cardinality of each relationship.

Cardinality refers to the number of instances of one entity related to instances of another entity.

You can start with this simple notation to capture cardinality in a conceptual model.

It can be expanded to note optional vs. mandatory relationships, but going that far is not needed in conceptual modelling.

When working with business stakeholders, focus on simplicity of models, so that you don’t lose stakeholder attention and interest.

You will need a few iterations to find missing relationships and understand relationship cardinalities.

Let’s go through a few more steps together.

Step 2. Elaborate on customers placing orders. This is a relationship between Customer and Order entities.

A customer may place more than one order — this will inform the cardinality of one side of the relationship.

What about the other side of the relationship?

Can an order be associated with multiple customers, or only one?

Can someone be called a customer before they place the first order?

The answer will be captured as the cardinality on the other side of the relationship.

Here is what it may look like:

Step 3. As you learn more about use cases, you may discover entity attributes.

An attribute is a characteristic or trait that describes the entity.

Observe in the use case diagram that an Order may be changed by a Customer or a Service Representative.

Ask: what may change? A delivery address? Is that an attribute of an Order or a Customer?

Can a Customer have more than one address? Should it be a separate entity?

What else can change? A delivery date? Sounds like another attribute.

A word of caution — don’t get stuck at this point trying to capture an exhaustive list of all attributes — this can be done in a logical model.

Only capture the main attributes that support understanding of concepts.

Step 4. As you continue discovering more information, start analyzing what is an attribute, and what is a different entity.

For example, one of the ways to change an order is to include another dish.

Does this mean that an Order can consist of multiple dishes?

And that each dish likely has a name and some other attributes?

Time to add another entity, Dish, to the model.

How does the Ingredient fit into this picture? Is it the same as a Dish? No?

A Dish will include multiple Ingredients? Capture this too.

What is a Menu? A list of all Dishes available to order?

Clearly a Menu consists of multiple Dishes.

Is each Dish only listed in the Menu once?

Yes, but there are different Menus — for lunch and for dinner.

With this knowledge, you are ready to create the next revision of the model:

Step 5. There is more to clarify, but as the model fills in, the gaps are easier to identify.

How are Proposals managed? Does each Proposal relate to a specific Employee who will receive a commission when it’s converted to a new account?

What is the relationship between a Customer and an Account: can a Customer have more than one? How is Account different from a Customer?

At this point, the conversation may also mention identifiers — for example, is Customer Number the same as Account Number? If not, what exactly does each one represent?

Unique identifiers of each entity can be captured as key attributes in the model. They are often referred to as primary keys. When working on conceptual models, don’t worry about foreign keys — stay at the conceptual level.

Let’s reveal the next iteration of the model that indicates some key identifiers:

How far does the analyst need to go with the conceptual data model? Not so far that the diagram requires a plotter to be printed.

The goal is to understand the essential business concepts.

The intricate details, foreign keys and resolution of many-to-many relationships can be captured in logical models, by a data architect or a designer.

A conceptual model at the analysis stage provides other benefits:

• Understanding what the business is about
• Establishing consistent terminology
• Identifying requirements gaps
• Detecting missed one-to-many relationships, such as one customer to many addresses in this example
• Flagging potential problem areas, such as the lack of clarity between a customer and an account — are these different concepts, or only one?

An experienced business analyst can use the model as a way of questioning and clarifying the gaps — it may prove much more efficient with a picture.

Modelling is an effective communication tool. A business analyst able to create conceptual data models has a strategic advantage.

Additional analysis and modelling tools help confirm the business model and its current state.

Validating and clarifying information can lead to detecting gaps, missed requirements, and problems that must be resolved.

From stakeholder management perspective, once you start exposing your audience to the new types of diagrams, your business partners will become more interested and accepting, especially if a modelling exercise helps to uncover a gap.

With this stakeholder support, and applying the principles of the BA mindset, the business analyst will be much better positioned to create a shared understanding of business requirements.

Based on the article that first appeared on the DataManagementU.com blog.

To practice creating conceptual models, check out this video.

Website | Contact | Training | Mentorship | Courses | Job Interview Clinic | Books | Downloads | LinkedIn | YouTube | Instagram | Twitter