5 Examples of Conceptual Data Models

Are you a student or a beginning data modeler who wants to learn more about data modeling? Let’s start learning with the conceptual data model – the least detailed of the three models.

In this article, we’ll discuss the conceptual data model using some real-world examples.

As you know, data modeling is the process of describing real-world data – its relationships, features, and attributes – in a structured document like an ER (entity-relationship) diagram. The data model acts as a blueprint that the data architect will use to convert all the data involved in business processes into a database.

In data modeling, we go through three different stages:

1. Conceptual data model: The most abstract data model that describes the data elements without much detail.
2. Logical data model: A conceptual model with more technical details.
3. Physical data model: A logical model with all the details of the physical database (data types, constraints, indexes, schemas, etc.) added.

If you are interested in reading more about these data models, this detailed article is for you.

What Is the Conceptual Data Model? What Is It Used For?

The conceptual data model is the very first and the most abstract data model in the data modeling process. It is a high-level diagram that we use to define, describe, organize, and present data elements and their relationships with relatively few details. Conceptual data models contain only:

1. The real-world entities that are our main data elements.
2. Their relationships.

This model does not have technical details, such as attributes, data types, etc.

We use the conceptual data model to communicate with the different business people when defining the business requirements of the database and presenting concepts (e.g. for their feedback). We do not use these models to communicate with technical teams. Thus, we use simple terms in a conceptual data model. 

How to Implement a Conceptual Data Model in Vertabelo

Let’s use the Vertabelo online data modeler to demonstrate how to implement a conceptual data model. Its easy-to-use interface and modern features make creating an ER diagram for a basic purchasing model quite simple.

Vertabelo offers two types of diagrams: a logical diagram and a physical diagram. You can create both conceptual and logical models in the logical diagram because there is no clear line between those two models. When we add the technical details, we’ll have a logical data model, which we could use to create the physical data model – but we’ll save that for another article.

First, go to my.vertabelo.com and log in. Next, click on the Create New Document button.

You’ll see the popup menu pictured below. Click on the Create button next to Logical data model:

In the next screen, enter the name for your new logical data model.

I entered my database model name as “Database Model for Purchasing System”. After you enter your model’s name, click START MODELING.

Now you’re in Vertabelo’s user-friendly design environment. There are many shortcuts, buttons, and tools that make data modeling easier. We won’t go into all of them here, but I’ll show you just what you need to create a conceptual data model. If you want a detailed look, see this article explaining Vertabelo’s data modeling features.

What will I store in my purchasing system? The entities below are the real-world objects that I’ll need to track in my database. I think you’ll quickly understand what each entity represents:

• Purchasing Order
• Purchasing Order Item
• Stock Item
• Supplier
• Good Received Note

And these are the relationships between these entities:

• A Purchasing Order has many Purchasing Order Items A Purchasing Order Item can belong to only one Purchasing Order. That means the Purchasing Order and Purchasing Order Item entities have a one-to-many relationship.
• Many Purchasing Orders can be sent to one Supplier. Thus, there will be a one-to-many relationship between the Supplier and Purchasing Order And having a Supplier should be mandatory for all Purchasing Orders.
• One Purchasing Order Item should have one Stock Item, but one Stock Item may have zero or many Purchasing Order Items. That means that between Stock Item and Purchasing Order Item there is a one-mandatory-to-many-optional relationship.
• When ordered items are received for a Purchasing Order, we create a Good Received Note (GRN) for each Purchasing Order Item. Assuming ordered items for a Purchasing Order can be delivered by the supplier either at once or as split deliveries, a Purchasing Order Item can have zero or many Good Received Notes. However, one Good Received Note can belong to only one mandatory Purchasing Order Item. Thus, Purchasing Order Item and Good Received Note have a one-mandatory-to-many-optional relationship.

Now, I can add these entities and relationships to my conceptual diagram using Vertabelo. When you model a conceptual diagram with Vertabelo’s logical diagram tool, you need to disable errors and warnings related to leaving entities’ attributes and identifiers empty. To do that, go to Model Properties. Under Entity, disable the options No attributes (errors) and No identifier (warning), as shown below.

All done. Here is the conceptual data model for my purchasing system:

Let me show you a few examples of conceptual data models with a brief explanation of their business requirements.

Conceptual Data Model Examples, with ER Diagrams

1. Simple Employee Management System

This is an ER diagram of a conceptual data model for a simple employee management system. In this company, there are many departments and many employees in each department. Employees are assigned to different projects and can only work on one project at a time; some employees may not have been assigned to any projects. Each employee has a role (i.e. a job role); many employees can have the same role. Also, there may be vacant roles. Each employee has a login to access the company’s common network, but there are different user privileges.

To support these business requirements, I have designed the conceptual data model shown above. It has five entities (Employee, Department, Project, Role, and Login) that reflect the real-world entity information in the physical database. There are four relationships that support the described business scenario:

• Department_Employee: A one-mandatory-to-many-mandatory relationship.
• Project_Employee: A one-optional-to-many-mandatory relationship.
• Role_Employee: A one-mandatory-to-many-optional relationship.
• Employee_Login: A one-mandatory-to-one-mandatory relationship.

2.  Simple Order Management System

 

This is a conceptual data model for a simple order management system for a wholesale store. Customers send orders to the store, although some customers may not have sent any orders yet. An order has many order items, and each order item is for one product. There may be products that do not have an order. After gathering the products into an order, an invoice will be prepared for that order. An invoice has many invoice items, with one product in each invoice item.

This ER diagram shows how we’ll support the above business requirements. The model has six entities (Customer, Order, Order Item, Product, Invoice, and Invoice Item) that represent the real-world information in our physical database.

There are six relationships in this data model:

• Customer_Order: A one-mandatory-to-many-optional relationship.
• Order_Order Item: A one-mandatory-to-many-mandatory relationship.
• Product_Order Item: A one-mandatory-to-many-optional relationship.
• Order_Invoice: A one-mandatory-to-one-optional relationship.
• Invoice_Invoice Item: A one-mandatory-to-many-mandatory relationship.
• Product_Invoice Item: A one-mandatory-to-many-optional relationship.

It takes only a few minutes to create this conceptual data model in Vertabelo.

3.  Online Shopping App

This is an ER diagram for an online shopping app data model. Customers can sign up for the app, log into the system using their credentials, and shop online. When a customer starts looking for items, the app opens a shopping cart and adds a shopping cart item for each product that the customer adds to their cart. When the customer checks out, the app reads each shopping cart item’s details, updates the shopping cart header, and generates the final bill using the same information. The app also stores each customer’s shopping history.

This ER diagram contains four entities that reflect real-world object information in our physical database – Online Customer, Shopping Cart, Shopping Cart Item, and Product.

There are three relationships required to support the above business scenario:

• Online Customer_Shopping Cart: A one-mandatory-to-many-optional relationship.
• Shopping Cart_Shopping Cart Item: A one-mandatory-to-many-optional relationship.
• Product_Shopping Cart Item: A one-mandatory-to-many-optional relationship.

4.  Simple Library System

This conceptual diagram has been modeled for a Simple Library System, such as you might find in a school library. Students can register as members of the library. Members can borrow books. Each borrowed book is considered a loan. One loan can have only one book. A book can be in zero or one active loans and in zero or many past loans. A member can have zero or many loans (including active loans and past loans).

This is a simple conceptual diagram that has only three entities: Member, Loan, and Book. There are only two relationships:

• Member_Loan: A one-mandatory-to-many-optional relationship.
• Book_Loan: A one-mandatory-to-many-optional relationship.

5.  Hotel Reservation System

This is an ER diagram for a hotel reservation system. In this business scenario, hotels can be registered in the system and customers can reserve rooms in their preferred hotels. Each hotel has many rooms. A customer can make many reservations, and one reservation should belong to one customer. During their stay, a customer can get many services, which will be added to that reservation. When the customer checks out, the final bill is prepared based on their reservation records.

This conceptual data model has six entities (Hotel, Room, Reservation, Customer, Service, and Bill) and five relationships, as shown below:

• Hotel_Room: A one-mandatory-to-many-mandatory relationship.
• Room_Reservation: Each room can be in many reservations, including one active reservation and many past reservations. Each reservation can have one or many rooms. Therefore we have a many-mandatory-to-many-optional relationship between the Room and Reservation This can be simplified by creating an association between these entities in the logical diagram stage.
• Reservation_Service: A one-mandatory-to-many-optional relationship.
• Customer_Reservation: A one-mandatory-to-many-optional relationship.
• Customer_Bill: A one-mandatory-to-many-optional relationship.

What Did You Learn About Conceptual Data Modeling?

Data Modeling is the process of organizing real-world data under the scope of a business requirement in a structured manner. The various stages of data modeling – conceptual, logical, and physical models – are represented on documents used in the successive stages of the business system development process. The conceptual model is the least detailed; it is the very first model and the most abstract part of our data modeling process. We use this high-level model to start defining our concept and to communicate with non-technical user groups and business owners.

The logical model adds more technical detail (like data types) and the physical model adds database-specific information. In Vertabelo, you can generate a database from a physical model automatically. If you are interested in discovering more about what Vertabelo can do, see its documentation.

You can apply the concepts we talked about in this article to start your data modeling journey. We’d be happy to hear about your experiences in data modeling, so please share your thoughts in the comments below.