Knowledge Hub

In the world of data and databases, the term entity is foundational yet often misunderstood. To build reliable data systems, it is essential to understand what an entity is and how it is structured. This chapter explores the concept of an entity and breaks it down into its three core components: Entity Type, Entity Attributed and Entity Instance.

Let’s decode it.

What Is an Entity?

An entity is anything that can be uniquely identified and described. In data modelling, an entity typically refers to a real-world object, person, concept, or event that holds relevance within a system, such as a student, a book, or a transaction.

Entities are the fundamental building blocks of structured data models. To model and manage them effectively, we categorize entities into two levels:

• Entity Type: the blueprint or template
• Entity Attribute: the properties
• Entity Instance: the real-world, data-filled object

1. Entity Type – The Blueprint

Table, Column and Rows are one of the most basics of Data World but it’s worth explaining.

Let’s try to understand with an example, let’s say family is a table, how? Consider, you have 6 members in your family i.e., Grandfather = 1, Grandmother = 1, Father = 1, Mother = 1, Son = 1, Daughter = 1

Above is a standard average traditional family for most of us. Now, each of above members will have Name, Relationship and Date of Birth, right? These details or information are called properties and attributes of each family member and are called Columns or Fields in a table.

Now, when we say Name of the eldest person in family is John, his relationship in family is Grandfather, and his Date of Birth is 1^st January 1950. These details or information about one person in a family is called a Row.

Same way, when we have details or information about all the family members, we can say, we have multiple rows.

Primary Key is also known as Pkey, and Foreign Key is also known as Fkey. These are one of the most important terms without which a proper Data Model cannot be created.

We have understood what a table is. Now, the next step is to understand, if there is more than one table then how to join both. In the topic ‘Tables, Columns and Rows’ we used an example of table ‘Family’. Let’s use the same table here with an additional column i.e., Birth Location.

Table Name: Family

Now let’s say, to save space in Family table as we can see ‘United State of America’ has been used many times so how about creating another table where let’s store lengthy country names and in Family tables, let use country code instead with there is another table called as Birth Location.

Table Name: Birth Location

Now, let’s update the Family table to reflect country code instead of country name.

Table Name: Family

Now, the problem is column ‘Birth Location’ have country code so how to find out which country name refer to ‘001’. Let’s declare ID in Birth_Location table as Pkey and Location_ID in Family table as Fkey.

Data Modelling is the practice of structuring, describing, and organizing information so it reflects real-world entities, relationships, rules, and contexts in a way that supports business operations, analytics, governance, and AI (Artificial Intelligence).

Most of us, are aware of only few Data Modelling techniques, but in reality, there are around 37 of those, shown in below diagram.

Data Modelling Concepts & Techniques

I will try not to go into details in this topic, as we will have separate topics for each of it. First, one must understand the concept of Normalization and Denormalization to get a grasp of data modelling world.

De-normalization: Surely, all of us has worked on Excel. Excel has columns and rows, as do tables in Databases. Consider having employee details in Excel with columns like employee ID, name, mobile number, address, salary, department etc. All this information related to one employee can be stored in one row which is a Denormalization data model.

Flow of all Data Modelling Concepts & Techniques

Data Modelling is a foundational concept in the field of data management and analytics. It involves creating different representations of data structures to support various business and technical requirements.

As mentioned, there are around 37 data modelling technique which can be categorized in 5 layers, mentioned below.

1. Business & Enterprise Modelling
2. Semantic & Information Modelling
3. Core Data Modelling
4. Specialized Techniques
5. Governance & AI Extensions

Let’s see how all data modelling techniques get arranged in these layers.

Business Modelling is the practice of understanding how an organization works as a whole. It explains how value is created, how work flows through the organization, who is involved at each step, and how decisions are made. At this stage, the focus is not on data, databases, or systems, but on the business itself. The aim is to clearly describe what the organization does and how it achieves its objectives.

The main goal of Business Modelling is to provide a complete and holistic view of the business. When this view is clear, it becomes much easier to align daily operations, management decisions, and supporting systems with the organization’s strategic goals. Without this shared understanding, systems and data solutions are often built in isolation and fail to support real business needs.

Business Modelling concentrates on the “what” and the “how” of the business. It looks at business processes, roles, responsibilities, rules, and policies. It helps answer questions such as: What activities are performed? Who performs them? What decisions are taken, and based on what rules? Because of this, Business Modelling is usually the first step before moving into information modelling and data modelling. It establishes where data is created, how it flows, and how it is ultimately used.

Process Modelling, often referred to as Business Process Modelling (BPM), is the practice of describing how work is carried out step by step inside an organization. It visually represents workflows, activities, and decision points so that everyone can clearly understand how a process starts, how it moves forward, and how it ends. Unlike Business Modelling, which explains the business at a high level, Process Modelling focuses on the actual flow of work.

The main goal of Process Modelling is to analyse and improve business processes. By clearly documenting each step, organizations can identify delays, unnecessary work, repeated tasks, or unclear responsibilities. Once these issues are visible, processes can be standardized, improved, or automated to achieve better efficiency and consistency while staying aligned with organizational objectives.

Process Modelling provides a structured way to document how work moves across people, systems, and departments. It shows who performs each task, when decisions are made, and how work is handed over from one role to another. Because of this, Process Modelling often acts as a bridge between business requirements and system design. It is commonly used as a foundation for automation, compliance checks, and process improvement initiatives.

BPMN, which stands for Business Process Model and Notation, is a standardized visual language used to represent business processes. While Process Modelling explains the steps of a workflow, BPMN defines how those steps are drawn and represented so that everyone reads the process in the same way. Its purpose is to remove ambiguity and provide a clear, consistent way to describe how work flows through an organization.

The primary goal of BPMN is to create a common language that can be understood by both business stakeholders and technical teams. Business users can read BPMN diagrams to validate whether a process reflects how the organization actually works, while technical teams can use the same diagrams to configure workflow systems or automation tools. This shared understanding reduces miscommunication between business and IT.

BPMN builds on the ideas of Process Modelling by introducing a defined set of symbols and rules. These symbols represent common process elements such as activities, events, decision points, and responsibilities. For example, tasks represent work being performed, events show when a process starts or ends, and gateways represent decisions such as approvals or rejections. Swimlanes are used to show who is responsible for each task, such as a person, role, or department. Because these symbols are standardized, BPMN diagrams look familiar and consistent across organizations and industries.

Domain-Driven Design, commonly known as DDD, is an approach to modelling and system design that starts by deeply understanding the business domain. The term domain refers to the problem area the business is working in, such as banking, healthcare, education, or retail. DDD Modelling focuses on capturing the key business concepts, rules, and meanings, and making sure both business people and technical teams talk about them in the same way.

The main goal of DDD Modelling is to ensure that system design closely reflects real business needs. Instead of designing systems based only on technical convenience, DDD encourages teams to model software around how the business actually operates. When done correctly, the system grows naturally alongside the business, rather than becoming disconnected from it.

A central idea in DDD is the creation of a shared or ubiquitous language. This means that the same terms are used consistently by business experts, analysts, and developers. When a business person says “approved loan,” the developer and the analyst understand exactly what that term means, without needing further clarification. This shared language reduces misunderstandings and makes collaboration much easier.

Enterprise Data Modelling is the practice of creating a single, high-level view of data for the entire organization. Instead of looking at data system by system or project by project, it looks across all business areas and defines how key data concepts are understood at an enterprise level. The purpose is to make sure the organization has a shared understanding of its most important data.

The main goal of Enterprise Data Modelling is to provide a consistent framework for managing data across the whole enterprise. When this framework exists, different departments and systems can work together more easily. Data becomes easier to integrate, compare, and trust, because everyone is working from the same definitions.

This modelling approach brings together data from different subject areas such as customers, products, finance, and operations into one unified model. Rather than allowing each system to define data in its own way, Enterprise Data Modelling defines common entities and relationships that apply everywhere. Because of this, it acts as a strategic blueprint rather than a detailed design for a single application.