CHAPTER 3

What are entities?

Concepts of interest

Who, What, When, Where, Why, and How

Entities abound

As I walked around the room to see if any students had questions, I noticed someone in the last row had already finished the exercise. I walked over to where she was sitting and, looking over her shoulder, noticed only a handful of boxes on the page. The large box in the center contained the word ‘Manufacturing’. I asked her for her definition of ‘Manufacturing’. “Manufacturing is the production process of how we turn raw materials into finished goods. All the manufacturing steps are in this box.”

The data model boxes (also known as ‘entities’), however, are not designed to represent or contain processes. Instead, they represent the concepts that are used by the processes. The Manufacturing entity on her model was eventually transformed into several other entities, including Raw Material, Finished Goods, Machinery, and Production Schedule.

This chapter defines the concept of an entity and discusses the different categories (Who, What, When, Where, Why, and How) of entities. Entity instances are also defined. The three different levels of entities, subject area, logical, and physical, are also explained, as well as the concepts of a weak versus a strong entity.

Entity Explained

An entity represents a collection of information about something that the business deems important and worthy of capture. A noun or noun phrase identifies a specific entity. It fits into one of several categories - who, what, when, where, why, or how. Table 3.1 contains a definition of each of these entity categories along with examples.

Entity instances are the occurrences or values of a particular entity. Think of a spreadsheet as being an entity, with the column headings representing the pieces of information about the entity. Each spreadsheet row containing the actual values represents an entity instance. The entity Customer may have multiple customer instances, with names Bob, Joe, Jane, and so forth. The entity Account can have instances of Bob’s checking account, Bob’s savings account, Joe’s brokerage account, and so on.

Table 3.1 Definitions and examples of entity categories

Careful consideration of the context and scope of a data model is required when identifying entities. For example, a data model created for an organization’s Payroll department is very likely to have an entity called Employee; within the context of Payroll, this is likely to be acceptable. However, within the wider perspective of the organization, we recognize that an Employee is actually a Person fulfilling a particular role, one of perhaps many roles that are of interest. We only have to extend the context of the model from Payroll to Human Resources to introduce people who aren’t employees. David Hay describes this issue very well in his book “Enterprise Model Patterns: Describing the World” (Hay, 2011, p. 25):

“There are problems with defining EMPLOYEE as an entity... - common trap for the unwary. What you have in the word “employee” is a common name for something including in its meaning not just the thing itself, but also its relationship to something else. A PERSON is a human being with specific characteristics, whether employed by anyone or not. An EMPLOYEE, on the other hand, is a PERSON who has established a relationship of employment with an ORGANIZATION.”

Entity Types

The beauty of data modeling is that you can take the same information and show it at different levels of detail depending on the audience. In this book we discuss the three levels of detail: subject area, logical, and physical. Entities are components of all three levels.

For an entity to exist at a subject area level, it must be both basic and critical to the business. What is basic and critical depends very much on the concept of scope. At a universal level, there are certain subject areas common to all companies, such as Customer, Product, and Employee. Making the scope slightly narrower, a given industry may have certain unique subject areas. Phone Number, for example, will be a valid subject area for a telecommunications company, but perhaps not for other industries, such as manufacturing. Each company may have subject areas that are unique to its business or its way of doing business. For example, Complaint could be a subject area for a consumer affairs department. Person and Company could be valid subject areas in our business card example.

Entities at a logical level represent the business at a more detailed level than at the subject area level. In general, a subject area entity represents many logical model entities. Examining the subject area Address in more detail could produce a large number of logical entities, including Email Address, Web Address, and Mailing Address.

At a physical level, the entities correspond to database tables. The rigor applied to the logical model is reversed, at times, to make applications perform well or to manage space more efficiently. Web Address and Email Address could be logical entities that translate directly into physical tables. However, if there is a reporting requirement to view all virtual address information, we may decide to combine both Web Address and Email Address into the same physical entity. With very large volumes of data, we might also decide to break up Email Address into several physical entities, each of a more manageable size. So at times, one logical entity can break down into several physical tables, and even more frequently, one physical table can be created from many logical entities.

An entity is shown on diagrams as a rectangle with its name inside. Figure 3.1 contains several entities from our gelato store.

Figure 3.1 Sample entities

Notice that there are two types of rectangles: those with straight corners, such as Ice Cream Flavor and Ice Cream Size, and those with rounded edges, such as Ice Cream Order. Without introducing archaic data modeling jargon, it is enough to know that in most tools, the rectangles with straight right angle corners are strong and those with rounded corners are weak.

Strong entities stand on their own. They represent one occurrence of a person, place, or thing, independent of any other entities. In order to find the information about a particular Customer, for example, its Customer Identifier could be used to retrieve it from the database. “This is Bob, Customer Identifier 123.” An Ice Cream Flavor of ‘Chocolate’ might be retrieved with ‘C’. An Ice Cream Size of ‘2 Scoops’ might be retrieved with simply the number ‘2’.

Weak entities need to rely on at least one other entity. This means you cannot retrieve an entity instance without referring to an entity instance from another entity. For example, Ice Cream Order might be retrieved by an Ice Cream Flavor or Ice Cream Size, in combination with something within Ice Cream Order such as a Sequence Number.

A data model is a communication tool. Distinguishing strong from weak entities on the model helps us understand the relationships and dependencies between entities. For example, a developer reading a data model showing that Ice Cream Order is a weak entity that depends on Ice Cream Flavor, would develop the application program to ensure that an ice cream flavor is present before orders for it are placed. That is, ‘Chocolate’ must be available as a flavor in the software system before an order for chocolate ice cream may be placed.

EXERCISE 3: Defining Subject Areas

List three subject areas in your organization. Does your organization have a single, agreed-upon definition for each of these subject areas? If not, why not? Can you achieve a single definition for each subject area?