RDBMS UNIT – 2

ER Diagrams, Naming Conventions, and Design

Issues

 Here, we will discuss the various Design issues

that can arise while designing an ER diagram.

1. Choosing Entity set vs Attribute

Here we will discuss how choosing an entity set vs an attribute can change
the whole ER design semantics.

To understand this lets take an example, let’s say we have an entity set
Student with attributes such as student-name and student-id.

Now we can say that the student-id itself can be an entity with the
attributes like student-class and student-section.

Now if we compare the two cases, in the first case we can say that the
student can have only one student id, however in the second case when we
chose student id as an entity it implied that a student can have more than
one student id.

2. Choosing Entity Set vs. Relationship Sets

It is hard to decide that an object can be best represented by an entity set

or relationship set.

To decide the perfect choice between these two (entity vs relationship), the
user needs to understand whether the entity would need a new
relationship if a requirement arise in future, if this is the case then it is
better to choose entity set rather than relationship set.

Let’s take an example to understand it better: A person takes a loan

from a bank, here we have two entities person and bank and their
relationship is loan.

This is fine until there is a need to disburse a joint loan, in such case a new
relationship needs to be created to define the relationship between the two

1
individuals who have taken joint loan. In this scenario, it is better to choose
loan as an entity set rather than a relationship set.

3. Choosing Binary vs n-ary Relationship Sets

In most cases, the relationships described in an ER diagrams are binary.

The n-ary relationships are those where entity sets are more than two, if
the entity sets are only two, their relationship can be termed as binary
relationship.

The n-ary relationships can make ER design complex, however the good
news is that we can convert and represent any n-ary relationship using
multiple binary relationships.

This may sound confusing so lets take an example to understand: how

we can convert an n-ary relationship to multiple binary relationships.

Now let’s say we have to describe a relationship between four family

members: father, mother, son and daughter.

This can easily be represented in forms of multiple binary relationships,

father-mother relationship as “spouse”, son and daughter relationship as
“siblings” and father and mother relationship with their child as “child”.

4. Placing Relationship Attributes

The cardinality ratio in DBMS can help us determine in which scenarios

we need to place relationship attributes.

It is recommended to represent the attributes of one to one or one to many

relationship sets with any participating entity sets rather than a
relationship set.

For example, if an entity cannot be determined as a separate entity rather

it is represented by the combination of participating entity sets. In such
case it is better to associate these entities to many-to-many relationship
sets.

2
 The basic rules for converting the ER diagrams
into Relational Database ( tables) are-
 Convert all the Entities in the diagram to tables. All the entities
represented in the rectangular box in the ER diagram become
independent tables in the database.
 All single valued attributes of an entity is converted to a column of
the table. All the attributes, whose value at any instance of time is
unique, are considered as columns of that table
 Key attribute in the ER diagram becomes the Primary key of the
table.
 Declare the foreign key column, if applicable
 Any multi-valued attributes are converted into new table
 Any composite attributes are merged into same table as different
columns.
 One can ignore derived attribute, since it can be calculated at any
time.

3
Definition:

The ABC COMPANY PVT LTD., database keeps track of a company’s

employees, departments, and projects. The company is organized into
departments. Each department has a unique name, a unique number, and a
particular employee who manages the department. We keep track of the
start date when that employee began managing the department. A
department may have several locations. A department controls a number of
projects, each of which has a unique name, a unique number, and a single
location. We store each employee’s name, Social Security number, address,
salary, sex (gender), and birth date. An employee is assigned to one
department, but may work on several projects, which are not necessarily
controlled by the same department. We keep track of the current number
of hours per week that an employee works on each project. We also keep
track of the direct supervisor of each employee (who is another employee).
We want to keep track of the dependents of each employee for insurance
purposes. We keep each dependent’s first name, sex, birth date, and
relationship to the employee

4
  Design an ER diagram for the following scenario:
A COMPANY Database

In our example, we specify the following relationship types:

MANAGES, a 1:1 relationship type between EMPLOYEE and DEPARTMENT.

EMPLOYEE participation is partial. DEPARTMENT participation is not clear
from the requirements. We question the users, who say that a department
must have a manager at all times, which implies total participation. The
attribute Start_date is assigned to this relationship type.

WORKS_FOR, a 1:N relationship type between DEPARTMENT and

EMPLOYEE. Both participations are total.

CONTROLS, a 1:N relationship type between DEPARTMENT and PROJECT.

The participation of PROJECT is total, whereas that of DEPARTMENT is
determined to be partial, after consultation with the users indicates that
some departments may control no projects.

SUPERVISION, a 1:N relationship type between EMPLOYEE (in the supervi-

sor role) and EMPLOYEE (in the supervisee role). Both participations are
determined to be partial, after the users indicate that not every employee is
a supervisor and not every employee has a supervisor.

WORKS_ON, determined to be an M:N relationship type with attribute

Hours, after the users indicate that a project can have several employees
working on it. Both participations are determined to be total.

DEPENDENTS_OF, a 1:N relationship type between EMPLOYEE and

DEPENDENT, which is also the identifying relationship for the weak entity
type DEPENDENT. The participation of EMPLOYEE is partial, whereas that
of DEPENDENT is total.

5
 It displays the COMPANY ER database schema as
an ER diagram. We now review the full ER
diagram notation.
 Entity types such as EMPLOYEE, DEPARTMENT, and PROJECT are
shown in rectangular boxes.
 Relationship types such as WORKS_FOR, MANAGES, CONTROLS,
and WORKS_ON are shown in diamond-shaped boxes attached to the
participating entity types with straight lines.
 Attributes are shown in ovals, and each attribute is attached by a
straight line to its entity type or relationship type.
 Component attributes of a composite attribute are attached to the
oval representing the composite attribute, as illustrated by the Name
attribute of EMPLOYEE.
 Multivalued attributes are shown in double ovals, as illustrated by
the Locations attribute of DEPARTMENT.
 Key attributes have their names underlined.
 Derived attributes are shown in dotted ovals, as illustrated by
the Number_of_employees attribute of DEPARTMENT.
 Weak entity types are distinguished by being placed in double
rectangles and by having their identifying relationship placed in
double diamonds, as illustrated by the DEPENDENT entity type and
the DEPENDENTS_OF identifying relationship type.
 The partial key of the weak entity type is underlined with a dotted
line.
 The cardinality ratio of each binary relationship type is specified by
attaching a 1, M, or N on each participating edge.
 The cardinality ratio of DEPARTMENT: EMPLOYEE in MANAGES is
1:1, whereas it is 1: N for DEPARTMENT: EMPLOYEE in WORKS_FOR,
and M:N for WORKS_ON.

6
  The participation constraint is specified by a single line for partial
participation and by double lines for total participation (existence
dependency).
 We show the role names for the SUPERVISION relationship type
because the same EMPLOYEE entity type plays two distinct roles in
that relationship. Notice that the cardinality ratio is 1:N from
supervisor to supervisee because each employee in the role of
supervisee has at most one direct supervisor, whereas an employee
in the role of supervisor can supervise zero or more employees.

Reference Link (DBMS – ER Diagram to Table Conversion) :

https://beginnersbook.com/2021/07/dbms-er-diagram-to-
table-conversion/