DBMS

Topperworld.in

ER Model

⚫ ER model stands for an Entity-Relationship model. It is a high-level data

model. This model is used to define the data elements and relationship for a
specified system.

⚫ It develops a conceptual design for the database. It also develops a very

simple and easy to design view of data.

⚫ In ER modeling, the database structure is portrayed as a diagram called an

entity-relationship diagram.

©Topperworld
DBMS

❖ Entity

An entity may be any object, class, person or place. In the ER diagram, an entity
can be represented as rectangles.

Consider an organization as an example- manager, product, employee,

department etc. can be taken as an entity.

1. Strong entity: This type of entity has a primary key attribute which
uniquely identifies each record in a table. In the ER diagram, a strong
entity is usually represented by a single rectangle.

2. Weak entity: An entity does not have a primary key attribute and
depends on another strong entity via foreign key attribute. In the ER
diagram, a weak entity is usually represented by a double rectangle.

©Topperworld
DBMS

❖ Attribute

The attribute is used to describe the property of an entity. Eclipse is used to

represent an attribute.

For example, id, age, contact number, name, etc. can be attributes of a student.

➢ Simple attribute: An attribute which contains an atomic value and

cannot be divided further is called a simple attribute.

For example, Gender and Salary of a person. It is also represented by an oval.

➢ Key attribute: An attribute which can uniquely identify an entity in an

entity set is called a key attribute. It represents a primary key in the ER
diagram. In an Entity-Relationship diagram, the key attribute is denoted by
an oval with an underlying line.

For example, employee_id will be unique for each employee.

©Topperworld
DBMS

➢ Composite attribute: An attribute which is a combination of two or

more simple attributes is called a composite attribute. In an Entity-
Relationship diagram, it is represented by an ellipse, and that ellipse
comprises of other ellipses.

For example, the Name attribute of an employee entity type consists of First
name, Second name, and Last name.

©Topperworld
DBMS

➢ Derived attribute: An attribute which can be derived from other

attributes is called a derived attribute. In an entity-relationship diagram,
these attributes are represented by a dashed oval shape.

For example, employee_age is a derived attribute as it changes over time and

can be derived from another attribute DOB (Date of birth).

➢ Multi-valued attribute: An attribute which contains more than one

value for a given entity.

For example, an employee can have more than one mobile number and email
address.

©Topperworld
DBMS

❖ Relationship
• A relationship in Entity-Relationship Model is used to describe the relation
between two or more entities.
• It is represented by a diamond shape in the ER diagram.
For example, student study in college, employee works in a department. Here,
‘study in’ and ‘works in’ are the relationships.

Degree of Relationship
A relationship where a number of different entity set participate is called as
degree of a relationship.
Degree of relationship can be categorized into the following types:

1. Unary Relationship

2. Binary Relationship

3. Ternary Relationship

4. n-ary Relationship

1.Unary Relationship: A relationship where a single entity set participates

is called as a unary relationship.

For example, In a company, an employee manages or supervises another

employee.

2.Binary Relationship: When two entity set participates in a relationship is

called a binary relationship.

It is further categorized into four types:

©Topperworld
DBMS

One-to-One Relationship: When one entity from an entity set A is

associated with another entity of entity set B and vice versa. Such type of
relationship is called one to one relationship.

One-to-Many Relationship: When one entity from an entity set A is

associated or linked with multiple entities of entity set B, then it is called a
one-to-many relationship.

©Topperworld
DBMS

Many-to-One Relationship: When more than one entities from an

entity set A is associated with one entity of entity set B, then it is called a
many-to-one relationship.

Many-to-Many Relationship: When more than one entity from an

entity set A is associated with many entity of an entity set B. Such types of
relationship are called a many-to-many relationship.

4.Ternary Relationship: When three entity set participates in a

relationship, is called a ternary relationship.

©Topperworld
DBMS

5.n-ary Relationship: When more than three entity set involves in a

relationship is called an n-ary relationship.

❖ Notation of ER diagram

Database can be represented using the notations. In ER diagram, many

notations are used to express the cardinality. These notations are as follows:

❖ ER Design Issues

• In the previous sections of the data modeling, we learned to design an ER

diagram.
• We also discussed different ways of defining entity sets and relationships
among them.

©Topperworld
DBMS

• We also understood the various designing shapes that represent a

relationship, an entity, and its attributes.
• However, users often mislead the concept of the elements and the design
process of the ER diagram.
• Thus, it leads to a complex structure of the ER diagram and certain issues
that does not meet the characteristics of the real-world enterprise model.
• Here, we will discuss the basic design issues of an ER database schema in
the following points:

1) Use of Entity Set vs Attributes

✓ The use of an entity set or attribute depends on the structure of the real-
world enterprise that is being modelled and the semantics associated
with its attributes.
✓ It leads to a mistake when the user use the primary key of an entity set
as an attribute of another entity set.
✓ Instead, he should use the relationship to do so.
✓ Also, the primary key attributes are implicit in the relationship set, but
we designate it in the relationship sets.

2) Use of Entity Set vs. Relationship Sets

✓ It is difficult to examine if an object can be best expressed by an entity

set or relationship set.
✓ To understand and determine the right use, the user need to designate a
relationship set for describing an action that occurs in-between the
entities.

©Topperworld
DBMS

✓ If there is a requirement of representing the object as a relationship set,

then its better not to mix it with the entity set.

3) Use of Binary vs n-ary Relationship Sets.

✓ Generally, the relationships described in the databases are binary

relationships.

✓ However, non-binary relationships can be represented by several binary

relationships.

✓ For example, we can create and represent a ternary relationship 'parent'

that may relate to a child, his father, as well as his mother. Such
relationship can also be represented by two binary relationships i.e,
mother and father, that may relate to their child.

✓ Thus, it is possible to represent a non-binary relationship by a set of

distinct binary relationships.

4) Placing Relationship Attributes

✓ The cardinality ratios can become an affective measure in the placement

of the relationship attributes.
✓ So, it is better to associate the attributes of one-to-one or one-to-many
relationship sets with any participating entity sets, instead of any
relationship set.
✓ The decision of placing the specified attribute as a relationship or entity
attribute should possess the charactestics of the real world enterprise
that is being modelled.

©Topperworld
DBMS

❖ Problems with ER Model

• The ER model is incomplete as any other data model.

• It is necessary to understand the reason for its incompleteness because
only then can we develop approaches to overcome the model's
limitations.
• Sometimes, a problem known as a connection trap occurs due to the
misinterpretation of the meaning of certain relationships.

There are two main types of connection models are:

1. Fan Traps

2. Chasm Traps

Both Fan and Chasm traps occur when it becomes impossible to retrieve all the
necessary information needed from the entire diagram.

©Topperworld
DBMS

1) Fan Traps

• An ER model that represents a relationship between entity occurrences is

ambiguous. Such a model is said to be in a fan trap.
• A fan trap may exist where two or more one-to-many relationships fan
out from the same entity.
• The structure is of the form many to one/ one to many. To understand
the fan trap problem, let us consider an example of a company where
each department can have offices in different cities.

• Each employee is associated with a single department because each

employee works in only one department.
• However, the departments are associated with multiple locations
because departments can have offices in difficult cities. To understand the
problem more clearly, let us examine some occurrences of relationships
using a value for the primary key attributes of EMPLOYEE, DEPARTMENT,
AND LOCATION entities.
• A problem arises if we want to determine which employee works at which
location. For example. If we want to know in which city does Vikram
works.

©Topperworld
DBMS

• We can only determine that the employee Vikram works in either

Amritsar or Mumbai from the current structure. The inability to answer
the question specifically is because of mutual exclusion of Employee and
Location entity occurrences with department entity.
• We can resolve this fan trap by reconstructing the ER model so that they
now represent the correct association between these entities.
• With this reconstruction, we can now answer where employee Vikaram
works? From the above, it is clear that employee Vikram works at the
Amritsar location and in the accounting department.

2) Chasm Traps

A chasm trap is another problem with the ER model, which occurs when a
pathway does not exist in all the related entities. A chasm trap may exist where
there are one or more relationships with a minimum multiplicity of zero forming
part of the pathway between related entities.

A problem arises when we want to know which lockers are available in a branch.
Here, we consider an example of a bank where a single branch has one or more

©Topperworld
DBMS

customers who avail zero or more lockers to keep their belongings. We also
assume that a customer uses not all customers avail locker and not all lockers.
Now let us examine some occurrences of the relationships using a value for the
primary key attributes of Bank_branch, Customer, and Locker entities to
understand the problem more clearly.

Suppose we want to know which bank's branch locker L212 is available. We will
be unable to find the answer as locker L212 has not yet been allocated. The
inability to answer these questions is a result of a chasm trap. It would be
considered a loss of information.

To solve this problem, we need to identify the missing relationship that relates
the bank_branch entity with the locker entity it offers. This ensures that all the
times the lockers associated with each bank_branch are known, including those
lockers that have yet not been allocated.

The ER diagram on adding this relationship would look like

©Topperworld
DBMS

Now let us examine the occurrences of the relationships using the values for the
primary key attribute of the given entities.

©Topperworld