Republic of the Philippines

Technological University of the Philippines

College of Industrial Technology
Manila

Entity Relationship Diagram

In partial fulfillment for the requirements of

MIT 595:
Database

Submitted to:

JULIUS SARENO

Submitted by:

Joseph Daniel S. Liu

June 28, 2017

 ENTITY RELATIONSHIP DIAGRAM
I. INTRODUCTION
II. ENTITY RELATIONSHIP DIAGRAM
1. Entity Types
2. Relationship Types
2. 1. Degree of the Relationship Types
3. Attributes
4. Key
5. Cardinality and Participation Constraints
III. APPLICATION
IV. REFERENCES
 INTRODUCTION
As stated by Navathe (2011), database is a group of related data that can be saved
and has understood meaning. It is designed, built and populated with data for a specific
purpose. Defining a database involves specifying the data types, structures and
constraints of the data to be stored in database.
In planning a database, modelling concepts of the Entity-Relationship Model /
Diagram (ERD) is applied. In conceptualizing the ERD of a certain organization, the data
administrator, the responsible for physical database design, considers the different
system requirements, operations, identifying the entities of a certain organization and the
relationship of a certain entities among the organization. Chen notation is used in
interpreting entities and relationship modelling that uses rectangles that represent entities
type and diamonds to represent relationships.

Entity Relationship Diagram

1. Entity Types
Entity type is a group of objects with the same properties, which are identified by
the enterprise as having an independent existence. It can be objects with a physical
existence or objects with a conceptual or abstract existence.
Physical Existence
Staff Part
Property Supplier
Customer Product

Conceptual Existence
Viewing Sale
Inspection Work Experience

Table 1. 1. Examples of entities with a physical and conceptual existence.

Diagrammatic representation of entity types usually shown as a rectangle labeled
with the name of entity, which is normally in singular noun, the first letter of each word is
upper-cased.

Instructor Student

Figure 1. 1. Visual representation of the Instructor and Student entity types.

 2. Relationship Types
It is a set of associations between one or more participating entity types. Each
relationship type is given a name that describes its function.

Relationship name

Instructor Teaches Student

Figure 2. 1. Instructor teaches student

Each relationship type is depicted as a diamond-shape connecting the associated

entity type, labeled with the name of the relationship. A relationship is named using a verb
or a short phrase including a verb. The relationship name should be unique for a given
ER model.
2. 1. Degree of Relationship Types
The entities involved in a particular relationship type are referred to as participants
in the relationship. The number of participants in a relationship type is called the degree
of the relationship. It indicates the number of entity types involved in a relationship.

Binary is a relationship of degree two. As shown in the figure 2.1.1. below, the
entity type Person has a relationship to the books, which is the loan, a person can loan
zero or more books, but it depends upon the limit of the system.

Person Loans Books

Figure 2.1.1. Binary Relationship of an ER model of a library system.

Ternary is a relationship of degree three. The figure 2.1.2 illustrates the connection
of three entities type namely Doctor, Patient and Drug. The doctor prescribes drug to the
patient, and the patient can receive drug prescription to a specific doctor.
 Doctor Prescribes Patient

Drug

Figure 2.1.2. Ternary degree of relationship between the entity types, Doctor,
Patient and Drug
Recursive relationship (unary) is a relationship type where the same entity type
participates more than once in different roles.

Subject
Is
prerequisite
for

Figure 2.1.3. Recursive relationship of Course Subject

The figure 2.1.3 shows the recursive relationship of the Subject entity type. For
example, in a course curriculum, it is a requirement to pass a subject that serves as a
pre-requisite subject to take up a higher year subject. For us to interpret it in a ERD model,
we can say that a subject can be a pre-requisite to another subject just like figure 2.1.3.

3. Attributes
Attributes are the properties of a particular entity types. It holds the values that
describe the entity and represent the main part of the data stored in the database. A
relationship type that associates entities can also have attributes similar to those of an
entity type. Attributes can be classified as simple or composite; single-valued or multi-
valued; or derived. Oval shape is used when interpreting attributes in graphical form.
 Customer ID Places

Customer StreetNo

Customer Name Address

Barangay

City

Figure 3. 1. A segment of an ERD depicting the Customer entity type with attributes.
Simple attribute is an attribute composed of a single component with an
independent existence. These attributes cannot be further subdivided into smaller
components and it sometimes called atomic attributes. For example, LastName is a
single-valued attribute of a student and cannot be further subdivided. In figure 3.1,
CustomerName is a simple attribute.
Composite attribute is defined as an attribute that composed of multiple
components, each with an independent existence. These attributes can be further divided
to yield smaller components with an independent existence of their own.
For example, an address attribute can be subdivided into the following attributes:
address
street
barangay
city
province

Therefore, the values of the composite attribute is the concatenation of the values
of its subdivided simple attributes.

Single-valued attribute is an attribute that holds a single value for each

occurrence of an entity type. The single-valued attributes in the figure 3.1. are the
following:
a. Customer ID
b. Customer Name
 Multi-valued attribute is an attribute that can have many values associated with
it at any one point in time. As shown in figure 3.1, the multi-valued attribute there is the
address, because a customer might have two or more address, just like residential
address, work address and permanent address.
Derived attribute represents a value that is derivable form the value of a related
attribute or a set of attributes. In some cases, two or more attribute values are related. It
does not physically exist within the database, thus, derived by an algorithm or
computation. For example, Total cost can be derived by multiplying quantity ordered by
unit price. On the other hand, stored attributes are the attributes that is the basis of the
value of the derived attribute. As depicted in Figure 3.2. below, Age is a derived attribute
that was derived from the DateOfBirth attribute by subtracting it from the current date.
The DateOfBirth attribute is the stored attribute.

Age Person
DateOfBirth

Figure 3. 2. The stored attributes and derived attributes of the Person entity type.
4. Key
Key is an attribute that determines the values of other attributes within the entity.
A key might consist of more than one attribute. Superkey is any key that identifies each
entity uniquely.
Candidate key is the minimal set of attributes that uniquely identifies each
occurrence of an entity types. It also descried as a superkey without redundancies.
Primary key is the candidate key that is selected to uniquely identify each
occurrence of an entity types. It cannot contain null entries.
Composite key is a candidate key that consist of two or more attributes.
A strong entity type is not existence-dependent on some other entity type while
a weak entity type is existence-dependent on some other entity type.
5. Cardinality and Participation Constraints
Cardinality describes the maximum number of possible relationship occurrences
for an entity participating in a given relationship type. Minimum cardinality of a
relationship is the minimum number of instances of entity B that may be associated with
each instance of entity A while maximum cardinality of a relationship is the maximum
number of instances of entity B that may be associated with each instance of entity A.
Crows Foot Notation is used for depicting the cardinality and participation constraints.
 1 M
MOVIE Is Stocked
As
DVD

Figure 5.1. Relationship with cardinality constraints.

Participation determines whether all or only some entity occurrences participate
in given relationship. It represents whether all entity occurrences are involved in a
particular relationship, sometimes called, mandatory participation, or only some,
referred as optional participation.

PATIENT 1 M
Has PATIENT
Recorded
HISTORY

Figure 5.2. Patient has recorded patient history.

In the figure shown above, the patient always recorded as an instance of patient
history. The participation of the patient as related to the patient history is mandatory

EMPLOYEE Is Assigned
To PROJECT

Figure 5.3. Employee is assigned to project.

As stated in figure 5.3, an employee might be assigned or not to a certain project,
but a project cannot be created without any employee assigned to it. The relationship of
the entity type employee is optional in relation to entity type project, while the entity type
project is mandatory in connection with the entity type employee.
 APPLICATION
Entity Relationship Diagram/Model is diagrammatic representation of real objects,
persons, transactions and other operation present in an organization or institution as a
database design. In creating the ERD of a certain institution, the data administrator must
carefully consider the important entities and the right cardinalities of the relationship
between the entity types. The ERD is converted into relation model considering the
normalization operations to eliminate the redundancy problems that might arise. Some of
the systems that the ERD is applied are, hospital management systems, financial
accounting system, massive online roleplaying games, simulations, android applications,
gps, online reservations, etc.
 REFERENCES
Navathe, S., & Elmasri, R., (2011). Fundamental Database Systems 6th Edition.
Boston:Addison-Wesley Publishing.
Robbins, R. (1995). Database Fundamentals. Maryland,USA:John Hopskin University.
Design Elements ER diagram (Chen notation). Retrieved from
http://www.conceptdraw.com/diagram/chen-s-notation
Watt, A. Database Design. Retrieved from https://opentextbc.ca/dbdesign/
Naik, Shefali. (2016).What are the applications of ERD and normalization. Retrieved
fromhttps://www.researchgate.net/post/what_are_the_applications_of_ERD_and_
normalization