ENTITY RELATIONSHIP DIAGRAM

Components of an ER Diagram
These are the three key components of an ER Diagram

1. Entity
2. Attribute
3. Relationship

Entity
An entity can be a real-world object, that is
easily identifiable and distinguishable from
others.
For example, in a school database,
students, teachers, classes, and
the courses offered can be considered
entities. The entities have attributes that
give them their identity. If we have a Student table (Roll_no, Student_name, Age,
Mobile_no) then each student in that table is an entity and
can be uniquely identified by their Roll Number (Roll_no).

Entity Type
The entity type is a collection of the entity
having similar attributes.

In the Student table example, we have

each row as an entity and they have
common attributes i.e. each row has its
own value for attributes Roll_no, Age,
Student_name and Mobile_no.
So, we can define the STUDENT table as So, an entity type in an ER diagram is defined by
an entity type because it is a collection of a name(here, STUDENT) and a set of attributes(here,
Roll_no, Student_name, Age, Mobile_no).
entities having the same attributes.

Types of Entity Type

Strong Entity Type
1/9
 Weak Entity Type

Strong Entity Type: Strong entities are those entity types that have a key attribute .
A rectangle represents it.
The primary key helps in identifying each entity uniquely.

Weak Entity Type : Weak entity type doesn't have a key attribute. They can't be identified
on their own. It depends upon some other strong entity for its distinct identity.
Using real-life examples;
a) There can be children only if the parent exits.
b) There can be a room only if the building exits.

A double-outlined rectangle represents a weak entity . The relationship between a weak

entity type and a strong entity type is called an identifying relationship. It is shown with
a double-outlined diamond instead of a single-outlined diamond.

Entity Set
Entity Set is a collection of entities of the same entity type. In the above example of
the STUDENT entity type, a collection of entities from the Student entity type would form
an entity set.

In the table above, two entities (2, Angel, 19, 8709054568) and ( 4, Analisa, 21, 9847852156) form an entity set.
We can form an entity set by taking three entities from the table. E1 (2, Angel, 19, 8709054568) , E2 ( 3, Priya, 20,
9864257315) and E3 ( 4, Analisa, 21, 9847852156).
Similary, we can form any combination of the entity set using any of the entities from the entity type 'STUDENT'.
Also, we can understand that if we take all the records to the entity set we get the entity type 'STUDENT'.
So, we can say that the entity type is the superset of the entity set .

2/9
Note : In the E-R model we don't represent the data but the structure or schema.
When we convert the E-R model to a relational model then data can be stored in a tuple
(row) and hence, represented as an entity .

Attribute
Entities are represented by means of their properties, called attributes . All attributes
have values. For example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example,
a student's name cannot be a numeric value. It has to be alphabetic. A student's age
cannot be negative, etc.

Types of Attributes
Simple attribute
Simple attributes are atomic values, which cannot be divided further. For example,
a student's phone number has an atomic value of 11 digits.
Key attribute
A key attribute uniquely identifies an entity
instance.
It is implemented as either a primary key
or a foreign key.
NB : Other attributes other than the key To represent a Key attribute, the attribute name inside
the Ellipse is underlined.
attribute are non-key attributes.

3/9
Composite attribute
Composite attributes consist of more than
one simple attribute.
Composite attributes are represented by
ellipses that are connected with another
ellipse.
For example, a student's full name may
have first_name and last_name.

A composite attribute is the attribute, which also has

attributes.
Derived attribute
Derived attributes do not exist in
the physical database. Their values are
derived from other attributes present in
the database.
For example, average_salary should not
be saved directly in the database, since it
can be derived.
Age can also be derived from
data_of_birth.
To represent a derived attribute, another dotted ellipse is
created inside the main ellipse.
It can also be represented by a dotted or dashed ellipse.
Multi-value attribute
Multi-value attributes may contain more
than one value. For example, a person
can have more than one phone number,
email address, etc.

A Double Ellipse, one inside another, represents

the attribute that can have multiple values.
These attribute types can come together in a way like:
simple single-valued attributes
simple multi-valued attributes
composite single-valued attributes
composite multi-valued attributes

4/9
 Mandatory and Optional attributes
Mandatory attribute : An attribute whose
value cannot be null

Optional attribute : An attribute that

the value can be null

Relationship
The association among entities is called a relationship.
For example, an employee works_at a department, and a student enrols in a course.
Here, works_at and enrols are called relationships.

Entity relationships can be Cardinal or Ordinal.

These two notations are used to further define relationships.

Relationship Set
A set of relationships of a similar type is called a relationship set.
Like entities, a relationship can have attributes. These attributes are called descriptive
attributes .

Ordinality
Ordinality describes the relationship as optional or mandatory.
If the ordinality is zero, it means that it is possible to have none of the entities.
Ordinality specifies the absolute minimum number of relationships.

Cardinalities
Cardinality is the numerical mapping between entities.
It defines the number of entities in one entity set that can be associated with a certain
number of entities from another set via a relationship set.

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

5/9
Cardinality specifies the maximum number of relationships
One-to-one
One entity from entity set A can be
associated with at most one entity of entity
set B and vice versa.
This is not what you will usually see in
real-world relationships. However, such Example: If there are two entities ‘Person’ (Id, Name, Age,
a relationship is used for security Address)and ‘Passport’(Passport_id, Passport_no). So,
each person can have only one passport and each
purposes. passport belongs to only one person.
One-to-many
One entity from entity set A can be
associated with more than one entity of
entity set B.
However, an entity from entity set B can
be associated with at most one entity.
Example: If there are two entity types ‘Customer’ and
This relationship is the most common ‘Account’ then each ‘Customer’ can have more than one
relationship found. ‘Account’ but each ‘Account’ is held by only one ‘Customer’.

Many-to-one
More than one entity from entity set A can
be associated with at most one entity of
entity set B. However, an entity from entity
set B can be associated with more than
one entity from entity set A. If we see the example above (one-to-many) the other way
i.e. many Account is associated with one Customer then we
can say that it is a many-to-one relationship.
Many-to-many
One entity from A can be associated with
more than one entity from B and vice
versa.
A many-to-many relationship can be seen
as two one-to-many relationships linked by
a 'linking table' or 'associate table'.
Example: If there are two entity types,
‘Customer’ and ‘Product’, then each
customer can buy more than one product.
A product can be bought by many
customers.
Now, to understand the concept of the linking table here, we can have the ‘Order ’ entity
as a linking table that links the ‘Customer ’ and ‘ Product ’ entities.
We can break this many-to-many relationship into two one-to-many relationships. First,
each ‘ Customer ’ can have many ‘ Order ’ whereas each ‘ Order ’ is related to only one ‘
Customer ’.
Second, each ‘ Order ’ is related to only one Product whereas there can be many Orders
for the same Product .

6/9
In the table above, the concept of linking can be understood if we consider all
the attributes of the entities 'Customer', 'Order' and 'Product'.
We can see that the primary key of both the 'Customer' and 'Product' entities are included
in the linking table i.e. 'Order' table. The keys act as foreign keys while referring to
the respective table from the 'Order' table.

7/9