What is an entity? 

An entity is anything about which information is recorded. Entities are represented in tables where the rows are individual instances of the entities, and the columns are their attributes. 

 

| Image: What is an entity? |  

Entities can be: 

• A Person, for example an EMPLOYEE, STUDENT, PATIENT 
• A Place, for example a STORE, WAREHOUSE 
• An Object, for example a MACHINE, PRODUCT, CAR 
• An Event, for example a SALE, REGISTRATION, RENEWAL 
• A Concept, for example an ACCOUNT, COURSE 

What is an attribute? 

Attributes are what we want to know about the entities. 

 

| Image: What is an attribute? |  

Please note the below:

• Each attribute can only hold one value at a time. 
• Each entity needs a unique identifier (key). 
• Each attribute must depend upon the key. 

Entities and Relationships  

In order to identify the entities and their relationships, we need to look for the NOUNS & VERBS in the requirements where: 

NOUNS are entities 

VERBS are relationships 

Let’s take a look at an Airline System as an example: 

A Passenger buys a Ticket to travel on an Aircraft which carries out a Flight from one Airport to another Airport.  

The entities in this example are the nouns Passenger, Ticket, Aircraft, Flight, Airport and their relationships are the verbs Travel and Carry out. 

Cardinality 

Cardinality specifies the number of each entity that is involved in the relationship.  

There are three types of cardinality: 

1. One to one (1:1). For example, 1 man is married to 1 woman. 

1. One to many (1:M) is used to relate 1 instance of entity A with many instances of entity B. An instance of entity A can have many matching instances of entity B, and an instance of entity B has 1 matching instance of entity A. For example, 1 manager manages many employees, each employee is managed by 1 manager. 

1. Many to many (M:M) is used to relate many instances of entity A with many instances of entity B. An instance of entity A can have many matching instances of entity B, and an instance of entity B can have many matching instances of entity A. For example, a student attends many courses, and a course is taken by many students. 

Going back to our Airline System example, we can now identify the below types: 

• If we assume that the Ticket is for a single Flight, this is a one-to-one (1:1) type of cardinality. 
• If the flight has many tickets applying, this would be a one-to-many (1:m) type of cardinality. 
• It is important to note that the relationships can be expressed differently in each direction. 
• In a Universal Modelling Language (UML) diagram, we specify the cardinality along our relationship edge: 

 

| Image: UML diagram example| 

Cardinality is controlled by defined Business Rules, so we can have: 

One passenger can buy multiple tickets 

Or 

One passenger can travel on one ticket 

Cardinality in this example depends on the definition of Passenger; we can think of the passenger as a traveller linked to a specific ticket or we can think of a passenger as a customer. What’s the business rule in this case? We would specify the cardinality according to our business rule. 

 

| Image: The cardinality in our Airline example|  

Let’s see below some diagrams representing entity relationships. You will be given more information and the chance to practise using diagram tools during your live event.  

 

| Image: Representing entity relationships in ERD using UML notation. | 

   

| Image: Representing entity relationships in ERD using IEM notation. | 

 

 

| Image: Example of an entity-relationship diagram in the Chen notation.  | 

 

 

| Image: The same 1: M relationship between PAINTER and PAINTING represented in two different notations. | 

The 1: M relationship is ideal in database design. 

Next, you are going to be introduced to the three data model types. 

When you’re ready, select the vertical Learning Path button to continue.