What this Learning Material is about

This Learning Material contains the following lessons

Lesson 6: Introduction to Entity Relationship Diagram

How to learn from this Learning Material

Here’s a simple guide for you in going about this Learning Materials

1. Set aside other tasks that will disturb you while enjoying the lesson.
2. Take your time in reading the content. You can download this file for
your future reference.
3. Have your notebook beside you, so that you can write important details
on it
4. Ask your parents/ guardian to assist you in using this Learning Material.

What are you expected to learn

After going through this Learning Material you are expected to:
1. Define entity relationship model
2. Identify the common entity relationship diagram symbols
3. Identify binary relationship and cardinality

Click to watch video on YouTube for more Info

Entity Relationship Diagram Tutorial (Video)

https://www.youtube.com/watch?v=QpdhBUYk7Kk

Entity Relationship Diagram Symbol (Video)

https://youtu.be/dUJp0Yoq5eg
Lesson 6 INTRODUCTION TO ENTITY RELATIONSHIP DIAGRAM

Entity Relationship Model

An E-R model is usually the result of systematic analysis to define and describe what is
important to processes in an area of a business. It does not define the business
processes; it only presents a business data schema in graphical form. It is usually
drawn in a graphical form as boxes (entities) that are connected by lines (relationships)
which express the associations and dependencies between entities. An ER model can
also be expressed in a verbal form, for example: one building may be divided into zero
or more apartments, but one apartment can only be located in one building.
An entity–relationship model (or ER model) describes interrelated things of interest in a
specific domain of knowledge. A basic ER model is composed of entity types (which
classify the things of interest) and specifies relationships that can exist
between entities (instances of those entity types).
Conceptual data model
This is the highest level ER model in that it contains the least granular detail but
establishes the overall scope of what is to be included within the model set.

Logical data model

A logical ER model does not require a conceptual ER model, especially if the
scope of the logical ER model includes only the development of a distinct
information system.
Physical data model
One or more physical ER models may be developed from each logical ER model.
The physical ER model is normally developed to be instantiated as a database.

When to draw ER Diagrams?

So, when do we draw ERDs? While ER models are mostly developed for designing
relational databases in terms of concept visualization and in terms of physical
database design, there are still other situations when ER diagrams can help. Here are
some typical use cases.
Database design - Depending on the scale of change, it can be risky to alter a
database structure directly in a DBMS. To avoid ruining the data in a production
database, it is important to plan out the changes carefully.
Database debugging - To debug database issues can be challenging, especially when
the database contains many tables, which require writing complex SQL in getting the
information you need.
Database creation and patching - Visual Paradigm, an ERD tool, supports a database
generation tool that can automate the database creation and patching process by
means of ER diagrams.
Aid in requirements gathering - Determine the requirements of an information system
by drawing a conceptual ERD that depicts the high-level business objects of the
system.
Common Entity Relationship Diagram Symbols

An ER diagram is a means of visualizing how the information a system produces is related. There
are five main components of an ERD:

Entities which are represented by rectangles. An entity is an object or concept about which you
want to store information.

A weak entity is an entity that must defined by a foreign key relationship with another entity as
it cannot be uniquely identified by its own attributes alone.

Actions, which are represented by diamond shapes, show how two entities share information in
the database.

In some cases, entities can be self-linked. For example, employees can supervise other
employees.
Attributes, which are represented by ovals. A key attribute is the unique, distinguishing
characteristic of the entity. For example, an employee's social security number might be the
employee's key attribute.

A multivalued attribute can have more than one value. For example, an employee entity can
have multiple skill values.

A derived attribute is based on another attribute. For example, an employee's monthly salary is
based on the employee's annual salary.

 Connecting lines, solid lines that connect attributes to show the relationships of
entities in the diagram.
 Cardinality specifies how many instances of an entity relate to one instance of
another entity. Ordinality is also closely linked to cardinality. While cardinality
specifies the occurrences of a relationship, ordinality describes the relationship
as either mandatory or optional. In other words, cardinality specifies the
maximum number of relationships and ordinality specifies the absolute
minimum number of relationships.
Binary Relationship and Cardinality

There are many notation styles that express cardinality.

A relationship where two entities are participating is called a binary

relationship. Cardinality is the number of instance of an entity from a relation that can be
associated with the relation.

 One-to-one: When only one instance of an entity is associated with the

relationship, it is marked as '1:1'. The following image reflects that only one
instance of each entity should be associated with the relationship. It depicts one-
to-one relationship.
  One-to-many: When more than one instance of an entity is associated with a
relationship, it is marked as '1:N'. The following image reflects that only one
instance of entity on the left and more than one instance of an entity on the right
can be associated with the relationship. It depicts oneto-many relationship.

 Many-to-one: When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can
be associated with the relationship. It depicts many-to-one relationship.

 Many-to-many: The following image reflects that more than one instance of an
entity on the left and more than one instance of an entity on the right can be
associated with the relationship. It depicts many-to-many relationship.

Participation Constraints

 Total Participation: Each entity is involved in the relationship. Total participation

is represented by double lines.
 Partial participation: Not all entities are involved in the relationship. Partial
participation is represented by single lines.
How to draw an ER diagram?
If you find it difficult to get started with drawing an ER diagram, don't worry. In this
section, we will give you some ERD tips. Try to follow the steps below to understand
how to draw an ER diagram effectively.
1. Make sure you are clear about the purpose of drawing the ERD. Are you trying
to present an overall system architecture that involves the definition of business
objects? Or are you developing an ER model ready for database creation? You
must be clear about the purpose to develop an ER diagram at the right level of
detail (Read the section Conceptual, Logical and Physical Data Models for
more details)
2. Make sure you are clear about the scope to model. Knowing the modeling
scope prevents you from including redundant entities and relationships in your
design.
3. Draw the major entities involved in the scope.
4. Define the properties of entities by adding columns.
5. Review the ERD carefully and check if the entities and columns are enough to
store the data of the system. If not, consider adding additional entities and
columns. Usually, you can identify some transactional, operational and event
entities in this step.
6. Consider the relationships between all entities and relate them with proper
cardinality (e.g A one-to-many between entity Customer and Order). Don't
worry if there are orphan entities. Although it's not common, it's legit.
7. Apply the technique of database normalization to re-structure the entities in a
way that can reduce data redundancy and improve data integrity. For example,
the details of the manufacturer might be stored under the Product entity initially.
During the process of normalization, you may find that the detail keeps
repeating records over records, then you can split it as a separate entity
Manufacturer, and with a foreign key that links between Product and
Manufacturer.
ERD Examples
Movie Rental System
Loan System
Online Shop
Using ERD with Data Flow Diagram (DFD)
 REFERENCES:
Books:
Database Management System 1
Applications Programming 2 SQL Database Organizations

Web Reference:

https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagram/

https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

https://youtu.be/dUJp0Yoq5eg