Understanding and Identifying Entities

1. What Is an Entity?

Before we can find entities, we need a clear definition. At its core, an entity is a 'thing' of significance in the world that we want to model and store data about.

The following short video provides a concise and clear definition.

As the video explains, an entity is a real-world object that can be uniquely identified. This is a key point. If you can't distinguish one instance of a thing from another, it may not be a good candidate for an entity.

Entities can be:

• Physical objects: Employee, Student, Product, Car
• Conceptual objects: Course, Sale, Loan, BankAccount

In the relational model we discussed previously, each of these entities will eventually be represented by a table (a relation). The characteristics that describe an entity (like a student's name or a course's title) will become the attributes (columns) of that table.

2. A Framework for Identifying Entities

Identifying entities from a business description can seem subjective, but there are established guidelines to make the process more systematic. An effective database model focuses on the core concepts of the business itself, not on technical artifacts like reports or systems.

The following article offers a set of practical rules for identifying strong, meaningful entities.

Let's summarize the key rules from the article that will help us find entities:

1. Entities are singular nouns. When describing a business process, the nouns often represent the key entities. We use the singular form (e.g., Customer, not Customers) because the entity represents the type of thing, not the entire collection.
2. Entities exist in the real world of the business. A good entity is a concept central to the business's operation, like Product or Order. Things like SalesReport are outputs or artifacts, not core entities themselves.
3. Entities are countable. This is a powerful test. You should be able to say, "The business has many..." of that entity. For example, "The business has many customers" makes sense. "The business has many invoicings" does not. This test helps separate true entities from processes or abstract concepts.
4. Attributes are not entities. A common mistake is to model a characteristic of an entity as an entity itself. "Customer Name" isn't an entity; it's a fact you know about the Customer entity. "Account Balance" describes an Account. The countability test helps here too: you can't have "three account balances" as standalone things.

With these rules in mind, let's apply them to a practical example.

3. Practical Application: A Language School Database

The best way to learn this skill is by doing it. We'll use a business scenario for a language school and walk through the process of identifying its core entities.

The following reading provides the business requirements and then demonstrates how to extract the entities.

Let's retrace the author's steps, applying the rules we just learned.

Step 1: Analyze the business requirements.

Here's the core text:

"The International Language School... offers language classes for corporate clients... The School employs teachers, each of whom may teach multiple courses. Clients offer courses to their employees, who have the option to participate. ... Participants in the courses are employees of the client companies..."

Step 2: Identify candidate entities (the nouns).

From a quick reading, we can pull out the following nouns: School, classes/courses, clients, teachers, employees/participants.

Step 3: Refine the list using our rules.

Let's test our candidates:

• Client, Teacher, Course, Participant: These are all singular nouns. They are real-world concepts for the school. They are all countable (the school has many clients, teachers, etc.). They are not just attributes of something else. These are strong candidates.
• Employee vs. Participant: The text states that "Participants... are employees". From the school's perspective, their relationship is with the Participant in a course. Employee is the role that person has at the client's company. For our database, Participant is the more accurate and relevant entity.
• School: The text refers to "The International Language School". In this scenario, there is only one school. While we could have a table to store the school's address and phone number, it's not a list of things in the same way Client or Teacher is. It represents the entire system. For now, we'll focus on the entities that have multiple instances.

Step 4: Finalize the entity list.

Our refined list of entities is:

• Client
• Teacher
• Course
• Participant

This matches the conclusion in the article. This process of identifying nouns and then filtering them with a set of rules is a reliable method for the first stage of database design.

4. Quick Exercise

Now it's your turn. Read the following short scenario and identify the main entities.

A small public library system owns many books and lends them to members. The library needs to keep track of its collection of books, including who wrote each book. It must also record which member has borrowed which book and when it is due to be returned.

List the nouns that you think represent the core entities for this library system.

Conclusion

In this lesson, we took the first concrete step in database design: identifying entities. We moved from the abstract structure of a table to defining what real-world concepts those tables should represent.

Here are the main takeaways:

• An entity is a distinct and identifiable object, concept, or event in the real world that a business needs to store information about.
• Entities are the foundation of a database model and typically become the tables in the final database.
• You can systematically identify entities by looking for singular, countable nouns that represent core concepts of the business, while distinguishing them from simple attributes.

Now that we know how to identify the main subjects of our database, the next logical question is: "What specific information do we need to store about each entity?" In our next lesson, we will answer this by exploring attributes. We will also refine our understanding of entities by distinguishing between an entity type (the blueprint, like Customer) and an entity instance (a specific record, like John Smith).