SUBJECT: INFORMATION SYSTEMS 1 (INS15P0)

TOPIC: DEVELOPING ENTITY RELATION DIAGRAMS

LECTURER: DR. E.D. FRAUENSTEIN

Page 1 of 13
 1. INTRODUCTION

Developing Entity Relationship Diagrams (ERDs) is a crucial step in the process of creating a
database. An ERD serves as a visual representation of the data model, helping to organise and
structure the data in a logical and efficient manner. It allows us to identify entities, define their
relationships, and capture the attributes associated with each entity. This guide will provide you with
a comprehensive understanding of ERDs and their significance in database development.

Why are ERDs important? Well, imagine you're tasked with designing a database for a university.
Without an ERD, you would face challenges in understanding the relationships between various
entities such as students, courses, lecturers, and departments. You might struggle to determine how
these entities interact and what attributes are necessary to capture. This lack of clarity could result in
a poorly designed and inefficient database.

However, by developing an ERD, you gain a visual roadmap that clarifies the structure of the
database. Let's consider an example: the relationship between students and courses. An ERD would
illustrate that a student can be enrolled in multiple courses, while a course can have multiple
students. This many-to-many relationship becomes evident, allowing you to devise appropriate
strategies to handle it effectively, such as introducing an associative entity.

Moreover, an ERD assists in identifying the essential attributes associated with each entity. For
instance, in the university database, attributes like student name, ID, course code, instructor name,
and department details are crucial for data capture and retrieval. The ERD helps ensure that all
pertinent attributes are considered and included in the database design.

By developing an ERD before actually creating the database, you lay a solid foundation for a well-
structured, organised, and efficient system. It aids in capturing business requirements, understanding
data relationships, and ensuring data integrity. It also facilitates communication between
stakeholders, designers, and developers, as everyone can visually comprehend the database
structure.

In the following sections of this guide, we will delve into the step-by-step process of developing
ERDs, covering entity identification, relationship mapping, cardinality determination, attribute
identification, and more. By following these guidelines, you will be equipped to create effective ERDs
that serve as a blueprint for your database development endeavours.

Page 2 of 13
 2. COMPONENTS OF THE ERD

Entity

A data entity refers to anything, whether tangible or abstract, for which we intend to store data.
Entity types can be categorised into five classes: roles, events, locations, tangible things, or
concepts. For instance, entities such as an employee, payment, campus, or book fall into these
categories. Instances are specific examples of entities. For example, the instances of an employee
entity could be John Jones or Mary Smith's payment, and so on.

Relationship

A data relationship denotes a natural association that exists between one or more entities. For
instance, an example of a relationship is that employees process payments. Cardinality is used to
define the number of occurrences of one entity in relation to a single occurrence of the associated
entity. For example, an employee may process multiple payments or might not process any
payments, depending on the nature of their job.

Attribute

A data attribute represents a characteristic that is shared by all or most instances of a specific entity.
Synonyms for attribute include property, data element, and field. For example, attributes such as
Name, Address, Employee Number, and Pay Rate are all associated with the employee entity. A
primary key or identifier is an attribute or combination of attributes that uniquely identifies a single
instance of an entity. In other words, it distinguishes one instance from all others. For instance, the
Employee Number serves as a primary key for the Employee entity.

Page 3 of 13
 3. STEP-BY-STEP GUIDE TO CONSTRUCTING AN ENTITY RELATIONSHIP DIAGRAM

Identify the roles, events, locations, tangible things or concepts

1. Identify entities
about which the end-users want to store data.
Find the natural associations between pairs of entities using a
2. Find relationships
relationship matrix.
Put entities in rectangles and relationships on line segments
3. Draw rough ERD
connecting the entities.
Determine the number of occurrences of one entity for a single
4. Fill in cardinality
occurrence of the related entity.
Identify the data attribute(s) that uniquely identify one and only
5. Define primary Keys
one occurrence of each entity.
Eliminate Many-to-Many relationships and include primary and
6. Draw Key-Based ERD
foreign keys in each entity.
Name the information details (fields) which are essential to the
7. Identify attributes
system under development.
For each attribute, match it with exactly one entity that it
8. Map attributes
describes.
9. Draw fully attributed Adjust the ERD from step 6 to account for entities or
ERD relationships discovered in step 8.
Does the final Entity Relationship Diagram accurately depict
10. Check results
the system data?

Step 1. Identify Entities

A data entity refers to anything, whether tangible or abstract, for which we intend to store data. Entity
types can be categorised into five classes: roles, events, locations, tangible things, or concepts. The
most effective approach to identifying entities is to involve system owners and users, requesting
them to identify the elements they wish to capture, store, and produce information about. Another
method for identifying entities is to examine the forms, files, and reports generated by the existing
system. For example, in a student registration form, entities could include Student (a role), Course
(an event), Instructor (a role), Advisor (a role), Room (a location), and so on.

Page 4 of 13
Step 2. Find Relationships

Natural associations exist between pairs of entities. To identify these relationships, we can create a
relationship matrix by listing the entities down the left column and across the top of a table. At the
intersection of two related entities, an active verb can be filled in. Each row and column should have
at least one relationship listed. If an entity associated with a row or column does not interact with the
rest of the system, it may be worth questioning its inclusion in the system. For example:

A student is enrolled in one or more courses

subject verb objects

The provided example demonstrates a relationship between the Student entity and the Course entity.
The verb "Enrolled" signifies the association between a student and the courses they are enrolled in.

Step 3. Draw Rough ERD

Using rectangles for entities and lines for relationships, we can draw an ERD.

Step 4. Fill in Cardinality

For each end of the connector that joins rectangles, it is necessary to include a symbol indicating the
minimum and maximum number of instances of the adjacent rectangle for one instance of the
rectangle at the other end of the relationship line. The placement of these numbers can be confusing.

The first symbol represents the minimum number of instances required for the entity joining the
connector to be related to a given instance of the entity on the other side of the relationship. It can be
0 to indicate that it is possible for no instances of the entity to be related, 1 if at least one instance is
necessary, or omitted if more than one instance is required.

For example, in the case of a course, more than one student must be enrolled for the course to run,
but it is possible for a particular instructor to have no students (if they are on leave).

The second symbol denotes the maximum number of instances of the entity joining the connector for
each instance of the entity on the other side of the relationship. If there is only one such instance, the
symbol is 1. If there are more than 1, the symbol is represented by a crow's foot opening towards the
rectangle.

Page 5 of 13
When reading the cardinality like a sentence, the first entity represents the subject, the relationship
acts as the verb, and the cardinality after the relationship describes the number of direct objects (the
second entity). For example:

A student is enrolled in one or more courses

subject verb objects

Here are some examples of ERD connectives used in constructing the diagram

Page 6 of 13
Step 5. Define Primary Keys

For each entity, it is necessary to identify a unique primary key that allows instances of that entity to
be distinguished from one another. In many cases, a single field or property can serve as the primary
key, such as a Student ID. However, there are instances where the identifier consists of a
combination of fields or attributes. For example, a course may require a department identifier, a
course number, and often a section number to form a unique identifier. Similarly, a Room entity may
necessitate a Building Name and a Room Number to establish a unique identifier.

When representing the entity along with its attributes, the primary key is typically underlined to
indicate its uniqueness.

Step 6. Draw Key-Based ERD

Upon reviewing the rough draft ERD, we may encounter relationships that are non-specific or many-
to-many, indicated by crows feet on both ends of the relationship line. Such relationships can pose
challenges when implementing the related entities as data stores or data files since each record
would require an indefinite number of fields to maintain the many-to-many relationship.

Fortunately, we can resolve this issue by introducing an additional entity known as an associative
entity for each many-to-many relationship. The name of the new associative entity will be a
hyphenated combination of the names of the two original entities involved. It will possess a
concatenated key comprised of the keys from these two entities. The associative entity will have a 1-
1 relationship with each of its parent entities, and each parent entity will retain the same relationship
with the associative entity that they had with each other prior to introducing the associative entity.
The original relationship between the parent entities will be removed from the diagram.

Page 7 of 13
The key-based ERD will not contain any many-to-many relationships, and each entity will have its
primary and foreign keys listed beneath the entity name within its rectangle.

Step 7. Identify Attributes

A data attribute refers to a characteristic that is common to all or most instances of a particular entity.
During this step, our objective is to identify and name all the attributes that are essential to the
system under study, without assigning them to specific entities yet. The most effective approach is to
analyse the forms, files, and reports currently used by the system users. We can physically circle
each data item on a paper copy of these documents. Items that will not be transferred to the new
system, extraneous information like signatures, and constant information that remains the same for
all instances of the form (e.g., company name and address) should be crossed out. The remaining
circled items represent the attributes we require. It is crucial to validate these attributes with the
system users, as sometimes forms or reports may be outdated.

Step 8. Map Attributes

During this step, our task is to associate each attribute with exactly one entity. Sometimes, an
attribute may seem applicable to more than one entity (e.g., Name). In such cases, it is necessary to
add a modifier to the attribute name to ensure uniqueness (e.g., Customer Name, Employee Name,
etc.), or determine which entity the attribute "best" describes. If there are attributes that do not have
corresponding entities, it is possible that we have overlooked an entity and its associated
relationships. It is important to identify these missed entities and add them to the relationship matrix
at this stage.

Step 9. Draw Fully-Attributed ERD

If new entities and attributes were introduced in Step 8, it is necessary to redraw the ERD. During the
redraw, an effort should be made to rearrange the entities to minimise crossing lines. Placing entities
with the most relationships in the middle can help achieve this. If you are utilising a tool like Systems
Architect, redrawing the diagram becomes relatively easy.

Even if no new entities are added to the Key-Based ERD, it is still important to include the attributes
in the Non-Key Data section of each entity's rectangle. By adding these attributes, they are
automatically incorporated into the repository. This ensures that when we utilise the entity to design
the new system, all its attributes will be readily available.

Page 8 of 13
Step 10. Check Results

It is essential to review the fully-attributed ERD from the perspective of the system owner or user.
Ensure that the diagram is clear and easily understandable. Check the Cardinality pairs to verify that
the relationships are accurately represented. Additionally, carefully examine the list of attributes
associated with each entity to ensure that no important attributes have been omitted.

Taking the system owner or user viewpoint helps in evaluating the clarity and comprehensibility of
the diagram. By reviewing the Cardinality pairs, we ensure that the relationships are correctly
represented and align with the intended system behaviour. Checking the attributes associated with
each entity guarantees that all relevant information has been captured and nothing vital has been
overlooked.

EXAMPLE

A company comprises multiple departments, with each department run by a supervisor. Employees
must be assigned to at least one department, but they may be assigned to multiple departments.
Additionally, every employee must be assigned to at least one project. However, it is possible for an
employee to be on vacation and not assigned to any projects.

The essential data fields include: department names, project names, supervisor and employee
names, supervisor and employee numbers, and a unique project number.

Page 9 of 13
1. Identify Entities

The entities in this system include Department, Employee, Supervisor, and Project. It may be
tempting to consider Company as an entity, but in this case, it is considered a false entity because it
has only one instance. True entities should have more than one instance.

2. Find Relationships

We construct the following Entity Relationship Matrix:

ENTITIES Department Employee Supervisor Project

Department is assigned run by
Employee belongs to is assigned
Supervisor runs
Project uses

3. Construct rough ERD

Establish connections between entities whenever a relationship is indicated in the Entity Relationship
Matrix.

Page 10 of 13
4. Fill in Cardinality

From the description of the problem we see that:

 Each department has exactly one supervisor.

 A supervisor is in charge of one and only one department.
 Each department is assigned at least one employee.
 Each employee works for at least one department.
 Each project has at least one employee working on it.
 An employee is assigned to 0 or more projects.

5. Define Primary Keys

The primary keys are Department Name, Supervisor Number, Employee Number, Project Number.

6. Draw Key-Based ERD

There are two many-to-many relationships in the rough ERD mentioned above, namely between
Department and Employee and between Employee and Project. Therefore, to properly represent
these relationships, we require associative entities, namely Department-Employee and Employee-
Project.

For the Department-Employee associative entity, the primary key is a concatenated key consisting of
the Department Name and Employee Number.

Page 11 of 13
Similarly, for the Employee-Project associative entity, the primary key is a concatenated key formed
by combining the Employee Number and Project Number.

7. Identify attributes

The only attributes indicated are the names of the departments, projects, supervisors and
employees, as well as the supervisor and employee NUMBER and a unique project number.

Page 12 of 13
8. Map attributes

Attribute Entity Attribute Entity

Department Name Department Supervisor Number Supervisor
Employee Number Employee Supervisor Name Supervisor
Employee Name Employee Project Name Project
Project Number Project

9. Draw Fully Attributed ERD

10. Check Results

The final ERD seems to effectively model the data in this system.

Page 13 of 13