UNIT -2

YCCE. Dept. of CSE

Page 1
UNIT-2 ENTITY-RELATIONSHIP MODEL

Introduction

ER Data Model is based on the real world objects and their relationship. In other words,
each and everything, either living or non-living things in this world forms the object in
database world. We identify all the required objects for our database requirement and give
the shape of database objects. Before putting them into database, it is very much essential to
understand the requirement properly and design them efficiently. It is like a foundation of
the building. For this purpose, we use ER diagrams where we plan the database pictorially.
ER diagram basically breaks requirement into entities, attributes and relationship. In this
unit we will discuss in detail about the E-R Data model and how to convert the E-R model
to relational tables.

Learning Objectives
After learning this unit you should be able to
• Define an entity and identify different types of entities
• Define an Attribute and A relationship
• Identify different types of Keys and Constraints
• Know the symbols used to represent the ER DiagramSymbols
• Understand the principles of Conversion of ER diagrams toRelations

Entity
In a database, we would be grouping only related data called attributes together and
storing them under one group name called Entity. In relational form an entity is
represented in a Table. This helps in identifying which data is stored where and under
what name. It reduces the time to search for a particular data in a whole database. Say, we
are creating a School database. Then what all things come into our mind? It is school,
students, teachers, subjects, class etc. If you observe what we have listed are items/names
which are part of school, but each of them having their own group of related information?
i.e.; Student has ID, name, address, DOB, class in which he is studying etc. for a Student.
Similarly, TEACHERS will have their ID, name, address subjects that they are teaching,
class which they are teaching etc. Hence each entity forms a group of related information
called attributes. In real world each and every object forms an entity. In short, all the
living and non-living things in the world form entity. One can consider all nouns as
entities, if that makes it simpler.
• Strong Entity: Entities having its own attribute(s) as primary key(s) are called
strong entity. For example, STUDENT has STUDENT_ID as primary key. Hence it is a
strong entity.
YCCE. Dept. of CSE
Page 2
 • Weak Entity: Entities which cannot form their own attribute as primary key are
known as weak entities. These entities will derive their primary keys from the
combination of its attribute and primarykey from its mapping entity.
Consider CLASS and SECTION entity. The SECTION has SECTION _ID and NAME as
its attribute. But SECTION _ID alone cannot be a primary key, since it fails to tell for
which course it is related to. We will not be uniquely identifying the course section by
this attribute alone. But if this attribute along with CLASS_ID gives the meaning for each
section and we can uniquelyidentify the sections.

Fig: Strong and Weak Entity

• Composite Entity: Entities participating in the many to many relationships are

called composite entity. In this case, apart from two entities that are part of relation, we
will one more hidden entity in the relation. We will be creating a new entity with the
relation, and create a primary key by using the primary keys of other two entities.
Consider the example, multiple students enrolled for multiple courses. In this case, we
create STUDENT and COURSE. Then we create one more table for the relation
‘Enrolment’ and name it as STUD_COURSE. Add the primary keys of COURSE and
STUDENT into it, which forms the composite primary key of the new table.

Fig: Composite Entity

• Recursive Entity: If a relation exists between the same entities, then such entities
are called as recursive entity. For example, mapping between manager and employee is

YCCE. Dept. of CSE

Page 3
 recursive entity. Here manager is mapped to the same entity Employee. HOD of the
department is another example ofhaving recursive entity.

Fig: Recursive Entity

Attribute

• The characteristics of an entity are called attributes. Ex. Roll no, name, marks,
etc are the attributes of an entity student.
• An attribute is a descriptive property of an entity
• An attribute can have single value or multiple value or range of values.
• In addition, each attribute can contain certain type of data like only numeric
value, or only alphabets, or combination of both, or date or negative or positive
values etc.
Depending on the values that an attribute can take, it is divided intodifferent type.
1. Simple Attribute
These kinds of attributes have values which cannot be divided further. For example,
STUDENT_ID attribute which cannot be divided further. Passport Number is unique value
and it cannot be divided.
2. Composite Attribute
This kind of attribute can be divided further to more than one simple attribute. For example,
address of a person. Here address can be further divided as Door#, street, city, state and pin
which are simple attributes.
3. Derived Attribute
Derived attributes are the one whose value can be obtained from other attributes of entities in
the database. For example, Age of a person can be obtained from date of birth and current date.
Average salary, annual salary, total marks of a student etc are few examples of derived
attribute.
4. Stored Attribute
The attribute which gives the value to get the derived attribute are called Stored Attribute. In
example above, age is derived using Dateof Birth. Hence Date of Birth is a stored attribute.
5. Single Valued Attribute
These attributes will have only one value. For example, EMPLOYEE_ID, passport#, driving
license#, SSN etc have only single value for a person.
YCCE. Dept. of CSE
Page 4
 6. Multi-Valued Attribute
These attribute can have more than one value at any point of time. Manager can have more
than one employee working for him, a person can have more than one email address, and
more than one house etc is the examples.
7. Simple Single Valued Attribute
This is the combination of above four types of attributes. An attribute can have single value at
any point of time, which cannot be divided further. For example, EMPLOYEE_ID – it is
single value as well as it cannot be divided further.
8. Simple Multi-Valued Attribute
Phone number of a person, which is simple as well as he can have multiple phone numbers is
an example of this attribute.
9. Composite Single Valued Attribute
Date of Birth can be a composite single valued attribute. Any person can have only one
DOB and it can be further divided intodate, month and year attributes.
10. Composite Multi-Valued Attribute
Shop address which is located two different locations can be considered as example of this
attribute.
11. Descriptive Attribute
Attributes of the relationship is called descriptive attribute. For example, employee works for
department. Here ‘works for’ is the relation between employee and department entities. The
relation ‘works for’ can have attribute DATE_OF_JOIN which is a descriptive attribute.

Fig: Attributes of the STUDENT entity type

Keys
• An important constraint on the entities of an entity type is the key or
uniqueness constraint on attributes.
• A key is an attribute (also known as column or field) or a combination of

YCCE. Dept. of CSE

Page 5
 attribute that is used to identify records.
• Sometimes we might have to retrieve data from more than one table, in
those cases we require to join tables with the help of keys.
• The purpose of the key is to bind data together across tables without
repeating all of the data in every table
• Such an attribute is called a key attribute, and its values can be used to
identify each entity uniquely.
• For example, the Name attribute is a key of the COMPANY entity type
because no two companies are allowed to have thesame name.
• For the PERSON entity type, a typical key attribute is
Social Security Number.
• Sometimes, several attributes together form a key, meaning that the combination
of the attribute values must be distinct for each entity.
• If a set of attributes possesses this property, we can define a composite attribute
that becomes a key attribute of the entity type.
The various types of key with e.g. in SQL are mentioned below,(For examples let suppose we
have an Employee Table with
attributes ‘ID’ , ‘Name’ ,’Address’ , ‘Department_ID’ ,’Salary’)
4.1 Types of Keys
(a) Super Key - An attribute or a combination of attribute that is used toidentify the records
uniquely is known as Super Key. A table can have many Super Keys.
Examples of Super Keys:
• ID
• ID, Name
• ID, Address
• ID, Department_ID
• ID, Salary
• Name, Address
• Name, Address, Department_ID and so on.
As any combination which can identify the records uniquely will bea Super Key.
(b) Candidate Key - It can be defined as minimal Super Key or irreducible Super Key. In
other words an attribute or a combination of attribute that identifies the record uniquely but
none of its proper subsets can identify the records uniquely.
Examples of Candidate Key:
• Code
• Name, Address
For above table we have only two Candidate Keys (i.e. Irreducible Super Key) used to identify
the records from the table uniquely. Code Key can identify the record uniquely and similarly
combination of Name and Address can identify the record uniquely, but neither Name nor
Address can be used to identify the record uniquely as it might be possible that we have two

YCCE. Dept. of CSE

Page 6
 employees with similar name or two employees from the same house.

(c)rimary Key - A Candidate Key that is used by the database designer for unique
identification of each row in a table is known as Primary Key. A Primary Key can consist of
one or more attributes of a table.
Example of Primary Key: Database designer can use one of the Candidate Key as a Primary
Key. In this case we have "Code” and "Name, Address” as Candidate Key, we will consider
"Code” Key as a Primary Key as the other key is the combination of more than one attributes.
(d) Foreign Key - A foreign key is an attribute or combination of attribute in one base table
that points to the candidate key (generally it is the primary key) of another table. The purpose
of the foreign key is to ensure referential integrity of the data i.e. only values that are
supposed to appear in the database are permitted.
Examples of Foreign Key –
Let consider we have another table i.e. Department Table with Attributes “Department_ID”,
“Department_Name”, “Manager_ID”, ”Location_ID” with Department_ID as an Primary
Key. Now the Department_ID attribute of Employee Table (dependent or child table) can be
defined as the Foreign Key as it can reference to the Department_ID attribute of the
Departments table (the referenced or parent table), a Foreign Key value must match an
existing value in the parent table or be NULL.
(e)Composite Key - If we use multiple attributes to create a Primary Key then that Primary
Key is called Composite Key (also called a Compound Key or Concatenated Key).
Examples of Composite Key: if we have used “Name, Address” asa Primary Key then it will
be our Composite Key.
(f) Alternate Key - Alternate Key can be any of the Candidate Keys except for the Primary
Key.
Examples of Alternate Key is “Name, Address” as it is the only other Candidate Key which
is not a Primary Key.
(g) Secondary Key - The attributes that are not even the Super Key but can be still
used for identification of records (not unique) are known as Secondary Key.
Examples of Secondary Key can be Name, Address, Salary, Department_ID etc. as they can
identify the records but they might not be unique.

Relationship
• There are several implicit relationships among the various entity types.
• In fact, whenever an attribute of one entity type refers to another entity type, some
relationship exists.
• For example, the attribute Manager of department refers to an employee who
manages the department.
• In the ER model, these references should not be represented as relationships or
YCCE. Dept. of CSE
Page 7
 relation. There is a relation “borrower” in the entities customer and account which can be
shown as follows:

Degrees of Relationship
In a relationship two or more number of entities can participate. The number of entities who
are part of a particular relationship is called degrees of relationship. If only two entities
participate in the mapping, then degree of relation is 2 or binary. If three entities are involved,
then degree of relation is 3 or ternary. If more than 3 entities are involved then the degree of
relation is called n-degree orn-nary.

Cardinality of Relationship
How many number of instances of one entity is mapped to how many number of instances of
another entity is known as cardinality of a relationship. In a ‘studies’ relationship above, what
we observe is only one Student X is studying in on Class Y. i.e.; single instance of entity
student mapped to a single instance of entity Class. This means the cardinality between
Student and Class is 1:1.

Based On the Cardinality

One-to-One (1:1): As we saw in above example, one instance of the entity is mapped to
only one instance of another entity.
Consider, HOD of the Department. There is only one HOD in one department. That is there is
1:1 relationship between the entityHOD and Department.

Fig: One-to-One (1:1) relationship

One-to-Many (1: M): As we can guess now, one -to- many relationship has one instance
of entity related to multiple instances of another entity. One manager manages multiple
employees in his department. Here Manager and Employee are entities, and the relationship
is one-to-many. Similarly, one teacher teaches multiple classes are also a 1: M relationship.

Fig: One-to-Many (1: M) relationship

YCCE. Dept. of CSE

Page 8
 Many-to-Many (M: N): This is a relationship where multiple instances of entities are related
to multiple instances of another entity. A relationship between TEACHER and STUDENT is
many- to- many. How? Multiple Teachers teach multiple numbers of Students.
Similarly, above example of 1:1 can be M: N!! Surprised? Yes, it can be M: N relationship,
provided, how we relate these two entities. Multiple Students enroll for multiple
classes/courses makes this relationship M: N. The relationship 'studies' and 'enroll' made the
difference here. That means, it all depends on the requirement and how we are relating the
entities.

Fig: Many-to-Many (M: N) Relationship

Constraints
This represents how an entity is involved in the relation. That means, if all the entity values
are participating in any relation, then it is called total participation. If only few values of an
entity are partof relation, then it is a partial participation.
For example, ‘Employee Works for a Department’. Here all the employees work for one or
the other department. No employees are left without department. Hence all the employees
are participating in this relation. Thus, participation of employee is total participation.
But individual Department will not have all the employees. Each department will have only
few groups of employees working. Hence partial participation of department is seen here.

ER Diagram Symbols
Since ER diagram is the pictorial representation of real worldobjects, it involves various
symbols and notation to draw the diagrams. Let us see one by one below.
Entity: Rectangles are used to represent the entity in the diagram.Name of the Entity is
written inside the rectangle.

Fig: Entity Types

A strong entity is represented by simple rectangle as shown above.
A weak entity is represented by two rectangles as shown below.

Fig: Weak Entity Sets

YCCE. Dept. of CSE
Page 9
 Attribute: An oval shape is used to represent an attribute. Name of the attribute is written
inside the oval shape and is connected to its entity by a line.

Multi-value attributes are those which can take up more than one values are represented by
double oval shapes.

Derived attributes are those which can be derived from other attributes are represented by
oval shapes with dashed lines.

A composite attribute is an attribute that has two or more simple attributes as its components.
Each simple attribute is represented by an oval shape, but these attributes will be connected to
its parent attribute called composite attribute forming a tree structure.
The below mentioned figure, gives the representation of composite attribute, here address of
a student.

Fig: Example of attributes

Primary Key: An underline to the attribute name is put to represent the primary key. The key
attribute of the weak entity is represented by dashed underline.

Relationship: A diamond shape is used to show the relationship between the entities. A
mapping with weak entity is shown using double diamond. Relationship name will be written
inside them.

Cardinality of Relationship: Different developers use different notation to represent the

YCCE. Dept. of CSE

Page 10
 cardinality of the relationship. Not only for cardinality, but for other objects in ER diagram
will have slightly different notations. But main difference is noticed in the cardinality. For not
to get confused with many, let us see two types of notations for each.

One-to-One relation: - A one-to-one relationship is represented by adding ‘1’ near the

entities on the line joining the relation. In another type of notation one dash is added to the
relationship line at both ends.

One-to-Many relation: A one-to-many relationship is represented by adding ‘1’ near the

entity at left hand side of relation and ‘N’ is written near the entity at right side. Other type of
notation will have dash at LHS of relation and three arrow kind of lines at the RHS of relation
as shown below.

Many-to-Many relation: A one-to-many relationship is represented by adding ‘M’ near the

entity at left hand side of relation and ‘N’ is written near the entity at right side. Other type
ofnotation will have three arrow kinds of lines at both sides of relation as shown below.

Participation Constraints: Total participation constraints are shown by double lines and
partial participations are shown as singleline.

Let us create a simple ER diagram for a STUDENT database. What is the requirement of this
database?
‘Student attends class. Each class is divided into one or more sections. Each class will have
its own specified subjects. Students have to attend all the subjects of the class that he attends’.

Now let us identify what are the entities? STUDENT, CLASS, SECTION, SUBJECT are
the entities. Attributes of these entities are not specified here. But we know what could be
the entities of each of the entities. We can list them as below at this point of time.

YCCE. Dept. of CSE

Page 11
 STUDENT CLASS SECTION SUBJECT

STUDENT_ID CLASS_ID SECTION_ID SUBJECT_ID

STUDENT_NAME CLASS_NAME SECTION_NAME SUBJECT_NAME

ADDRESS

DOB
AGE

CLASS_ID

SECTION_ID

What are the relationships we have? ‘Attends’, ‘has section’, ‘have subjects’ and ‘studies
subjects’ are the relations here. With this knowledge of requirement, we can draw the ER
diagram as below.

Fig: Example ER Diagram with Entities, Attribute, and Relationships

Observe the diagram carefully. Did we miss or drew it correctly? Are we missing anything
on the diagram? Is it inferring correct requirement? What are our observations?
• Age attribute can be derived from DOB. Hence we have to draw dashed oval.
• Address is a composite attribute. We have to draw its sub attributes too. So that

YCCE. Dept. of CSE

Page 12
 we will be very clear about his address details.
• If we see the SECTION entity, by section id, will we be able get the section that
student attends? There is no relation mentioned between Student and Section. But
Section is mapped only with Class. What do we understand from this? Section is a
weak entity. Hence we have to represent it properly.
• If we look at ‘attends’ relationship between STUDENT and CLASS, we can
have ‘Joining Date’ and ‘Total Number of Hours’ attributes. But it is an attribute of
relation. We have toshow them in the diagram.
• Since each class is having different subjects and Students attends those subjects,
we can modify the relation ‘studies’ to ‘has’ relation on the relation ‘attends’.

Now the diagram will change to reflect all above points.

Fig: Example ER Diagram with Strong Entities, Weak Entities, andSimple attribute,
Composite Attribute, Keys and Relationships etc.

Is the above diagram is a complete diagram? No, we have not added the cardinality and
participation in the diagram.
Participation Constraints
• All the Students attend any one of the class, but class can have only certain

YCCE. Dept. of CSE

Page 13
 group of students. Hence total participation of Students and partial participation of
class in ‘Attends’relation.
• All the class has section and all the section has class. Hence both are total
participation.
• All the Students study some of the subject’s specific for their class and each class
has only some group of subjects. Hence partial participation of both STUDENT and
CLASS. Each subject will be studied by some students and it will be part of some
class. Hence this also partial participation.
•
Cardinalities of All the Relationship
• Each Student attends only one class at a time. Hence it is a 1:1 relation.
• Each class has one or more sections. Hence it can be considered as 1: N
relation.
• Each student attends many subjects and each class has manysubjects. Hence it
is a 1: N relation.
Note: If you look at STUDENT and CLASS relationship as many Students attend one class,
then it would be an M: 1 relation. It is allup to the developer, how he looks at the
requirement.

Fig: A Complete ER diagram for simple Student database

YCCE. Dept. of CSE

Page 14
 Now it is a complete ER diagram for simple Student database including the essential
components of ER Model.

Conversion of ER diagram to Relations

As the database grows, the ER diagram representation becomes more complex and
crowded. It is creates a difficult situation to understand the requirement and their structure as
a whole. Similarly, if ER diagram is represented at very high level, it again creates a
difficulty in understanding the system. But representation at high level and till the minute
levels is very necessary to understand the system well.
These concepts are well defined by some extended concepts called generalization and
specialization. Sometimes, we would have divided the entities into two or more entities
to be more accurate in design. But when compared to the whole database or user, it can be
combined to one entity. Such a process is called as aggregation.

Once designing ER diagram is complete, we need to put it into logical structure. But how it
can be done? Let us discuss this in thelast section.
Generalization
• The refinement from an initial entity set into successive levels of entity sub groupings
represents a top-down design process in which distinctions are made explicit.
The design process may also proceed in a bottom-up manner, in which multiple entity sets
are synthesized into a higher-level entity set on the basis of common features. The database
designer may have first identified a customer entity set with the attributes name, street, city,
and customer-id, and an employee entity set with the attributes name, street, city, employee-
id, and salary. There are similarities between the customer entity set and the employee
entity set in the sense that they have several attributes in common. This commonality can
be expressed by generalization, which is a containment relationship that exists between a
higher-level entity set and one or more lower-level entity sets. In our example, person is the
higher- level entity set and customer and employee are lower-level entity sets.
• Higher- and lower-level entity sets also may be designated by the terms super class and
subclass, respectively. The person entity set is the super class of the customer and employee
subclasses.
• For all practical purposes, generalization is a simple inversion of specialization. We
will apply both processes, in combination, in the course of designing the E-R schema for
an enterprise. In terms of the E-R diagram itself, we do not distinguish between
specialization and generalization. New levels of entity representation will be distinguished
(specialization) or synthesized (generalization) as the design schema comes to express fully
the database application and the user requirements of the database.

YCCE. Dept. of CSE

Page 15
 Fig: Specialization and generalization

Specialization
• An entity set may include sub groupings of entities that are distinct in some way from
other entities in the set.
• For instance, a subset of entities within an entity set may have attributes that are not
shared by all the entities in the entity set. The E-R model provides a means for representing
these distinctive entity groupings.
• Consider an entity set person, with attributes name, street, and city. A person may be
further classified as one of the following:
• Customer
• Employee
• Each of these person types is described by a set of attributes that includes all the
attributes of entity set person plus possibly additional attributes.
• For example, customer entities may be described further by the attribute customer-id,
whereas employee entities may be described further by the attributes employee-id and salary.
• The process of designating sub groupings within an entity set is called specialization.
• The specialization of person allows us to distinguish among persons according to
whether they are employees or customers.
• As another example, suppose the bank wishes to divide accounts into two categories,
checking account and savings account. Savings accounts need a minimum balance, but the
YCCE. Dept. of CSE
Page 16
 bank may set interest rates differently for different customers, offering better rates to favored
customers.
• Checking accounts have a fixed interest rate, but offer an overdraft facility; the overdraft
amount on a checking account must be recorded.
• The bank could then create two specializations of account, namely savings-account and
checking-account.
• As we saw earlier, account entities are described by the attributes account-number and
balance.
• The entity set savings-account would have all the attributes of account and an additional
attribute interest-rate.
• The entity set checking-account would have all the attributes of account, and an
additional attribute overdraft-amount.
• We can apply specialization repeatedly to refine a design scheme. For instance, bank
employees may be further classified as one of the category such as Officer, Teller, Secretary,
etc.
• Each of these employee types is described by a set of attributes that includes all the
attributes of entity set employee plus additional attributes. For example, officer entities may
be described further by the attribute office-number, teller entities by the attributes station-
number and hours-per-week, and secretary entities by the attribute hours-per-week. Further,
secretary entities may participate in a relationship secretary-for, which identifies which
employees areassisted by a secretary.
• An entity set may be specialized by more than one distinguishing feature. In our
example, the distinguishing feature among employee entities is the job the employee
performs. Another, coexistent, specialization could be based on whether the person is a
temporary (limited-term) employee or a permanent employee, resulting in the entity sets
temporary- employee and permanent-employee. When more than one specialization is
formed on an entity set, a particular entity may belong to multiple specializations. For
instance, a given employee may be a temporary employee who is a secretary.
In terms of an E-R diagram, specialization is depicted by a triangle component labeled ISA.
The label ISA stands for "is a” and represents, for example, that a customer "is a” person.
The ISA relationship may also be referred to as a super class- subclass relationship. Higher-
and lower-level entity sets are depicted as regular entity sets—that are, as rectangles
containing the name of the entity set.

Aggregation
• One limitation of the E-R model is that it cannot express relationships among
relationships.
• To illustrate the need for such a construct, consider the ternary relationship works-on,
which we saw earlier, between a employee, branch and job.
• Now, suppose we want to record managers for tasks performed by an employee at a

YCCE. Dept. of CSE

Page 17
 branch; that is, we want to record managers for (employee, branch, job) combinations. Let
us assume that there isan entity set manager.
• One alternative for representing this relationship is to create a quaternary relationship
manages between employee, branch, job, and manager. (A quaternary relationship is
required—a binary relationship between manager and employee would not permit us to
represent which (branch, job) combinations of an employee aremanaged by which manager.)
• Using the basic E-R modeling constructs, we obtain the E-R diagram as follows:

Fig: E-R diagram with redundant relationships

• It appears that the relationship sets works-on and manages can be combined into one
single relationship set.
• Nevertheless, we should not combine them into a single relationship, since some
employee, branch, job combinations many not have a manager.
• There is redundant information in the resultant figure, however, since every employee,
branch, job combination in manages is alsoin works-on.
• If the manager were a value rather than a manager entity, we could instead make
manager a multi valued attribute of the relationship works-on.
• But doing so makes it more difficult (logically as well as in execution cost) to find, for
example, employee-branch-job triples for which a manager is responsible. Since the manager
is a managerentity, this alternative is ruled out in any case.
• The best way to model a situation such as the one just described isto use aggregation.
• Aggregation is an abstraction through which relationships are treated as higher-level

YCCE. Dept. of CSE

Page 18
 entities.
• Following figure shows a notation for aggregation commonly used to represent the
above situation.

Fig: E-R diagram with aggregation

Transform ER Diagram into Tables

Since ER diagram gives us the good knowledge about the requirement and the mapping of
the entities in it, we can easily convert them as tables and columns. i.e.; using ER
diagrams one can easily create relational data model, which is nothing but the logical view of
the database.
There are various steps involved in converting it into tables and columns. Each type of entity,
attribute and relationship in the diagram takes their own depiction here. Consider the ER
diagram below and will see how it is converted into tables, columns and mappings.

Fig: Transform ER Diagram into Tables

YCCE. Dept. of CSE
Page 19
 Rules of Converting ER-Diagrams into table
The basic rules for converting the ER diagrams into tables is are as follows.
1. 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. In the below diagram, STUDENT, COURSE, LECTURER and
SUBJECTS forms individual tables.

2. Concert 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. In the STUDENT Entity, STUDENT_ID, STUDENT_NAME form the columns of
STUDENT table. Similarly, LECTURER_ID, LECTURER_NAME form the columns of
LECTURER table. And so on.

3. Convert the Key attributes in the ER diagram to the Primary keys of the table. In diagram
above, STUDENT_ID, LECTURER_ID, COURSE_ID and SUB_ID are the key attributes of the
entities. Hence we consider them as the primary keys of respective table.
4. Declare the foreign key column, if applicable.
In the diagram, attribute COURSE_ID in the STUDENT entity is from COURSE entity.
Hence add COURSE_ID in the STUDENT table and assign it foreign key constraint.
COURSE_ID and SUBJECT_ID in LECTURER table forms the foreign key column. Hence
by declaring the foreign key constraints, mapping between the tables are established.

5. Any multi-valued attributes are converted into new table.

A hobby in the Student table is a multi valued attribute. Any student can have any number of
hobbies. So we cannot represent multiple values in a single column of STUDENT table. We
need to store it separately, so that we can store any number of hobbies, adding/ removing /
deleting hobbies should not create any redundancy or anomalies in the system. Hence we
create a separate table STUD_HOBBY with STUDENT_ID and HOBBY as its columns. We
create a composite key using both the columns.

6. Any composite attributes are merged into same table as different columns.
In the diagram above, Student Address is a composite attribute. It has Door#, Street, City,
State and Pin. These attributes are merged into STUDENT table as individual columns.

7. One can ignore derived attribute, since it can be calculated at any time.
In the STUDENT table, Age can be derived at any point of time by calculating the difference
between Date of Birth and current date. Hence we need not create a column for this attribute.
It reduces the duplicity in the database.
These are the very basic rules of converting ER diagram into tables and columns, and
assigning the mapping between the tables. Table structure at this stage would be as below:
YCCE. Dept. of CSE
Page 20
 Let us see some of the special cases.
Converting Weak Entity
Weak entity is also represented as table. All the attributes of the weak entity forms the
column of the table. But the key attribute represented in the diagram cannot form the primary
key of this table. We have to add a foreign key column, which would be the primary key
column of its strong entity. This foreign key column along with its key attribute column
forms the primary key of the table.

In our example above, SUBJECTS is the weak entity. Hence, we create a table for it. Its
attributes SUBJECT_ID and SUBJECT_NAME forms the column of this table. Although
SUBJECT_ID is represented as key attribute in the diagram, it cannot be considered as
primary key. In order to add primary key to the column, we have to find the foreign key first.
COURSE is the strong entity related to SUBJECT. Hence the primary key COURSE_ID of
COURSE is added to SUBJECT table as foreign key. Now we can create a composite
primary key out of COURSE_ID and SUBJECT_ID.

Fig: Creating a composite primary key out of COURSE_ID and SUBJECT_ID.

YCCE. Dept. of CSE

Page 21
 Representing 1:1 relationship
Imagine SUBJECT is not a weak entity, and we have LECTURER teaches SUBJECT
relation. It is a 1:1 relation. i.e.; one lecturer teaches only one subject. We can represent this
case in two ways
1. Create table for both LECTURER and SUBJECT. Add the primary key of LECTURER
in SUBJECT table as foreign key. Itimplies the lecturer name for that particular subject.
2. Create table for both LECTURER and SUBJECT. Add the primary key of SUBJECT in
LECTURER table as foreign key. Itimplies the subject taught by the lecturer.
In both the case, meaning is same. Foreign key column can be added in either of the table,
depending on the developer’s choice.

Fig: Representing 1:1 relationship

Representing 1: N relationship
Consider SUBJECT and LECTURER relation, where each Lecturer teaches multiple subjects.
This is a 1: N relation. In this case, primary key of LECTURER table is added to the
SUBJECT table. i.e.; the primary key at 1 cardinality entity is added as foreign key to N
cardinality entity

Fig: Representing 1: N relationship

Representing M: N relationship
Consider the example, multiple students enrolled for multiple courses, which is M: N
relation. In this case, we create STUDENT and COURSE tables for the entities. Create one
more table for the relation ‘Enrolment’ and name it as STUD_COURSE. Add the primary
keys of COURSE and STUDENT into it, which forms the composite primary key of the new
table.
YCCE. Dept. of CSE
Page 22
 That is, in this case both the participating entities are converted into tables, and a new table is
created for the relation between them. Primary keys of entity tables are added into new table
to form the composite primary key. We can add any additional columns, if present as
attribute of the relation in ER diagram.

Fig: Representing M: N relationship

Self Referencing 1: N relation

Consider the example of HOD and Lecturers. Here one of the Lecturers is a HOD of the
department. i.e.; one HOD has multiple lecturers working with him. In this case, we create
LECTURER table for the Lecturer entity. Create the columns and primary keys as usual. In
order to represent HOD, we add one more column to LECTURER table which is same
column as primary key, but acts as a foreign key. i.e.; LECTURER_ID is the primary key of
LECTURER table. We add one more column HOD, which will have LECTURER_ID of the
HOD. Hence LECTURER table will show HOD’s Lecturer ID for each Lecturer. In this case,
primary key column acts as a foreign key in the same table.

Fig: Self Referencing 1: N relation

Self Referencing M: N relation

Consider Student and Teacher example as ‘Manny students have Many Teachers teaching
the subjects’. Here relation between Student and Teacher is M: N. In this case, creates
independenttables for student and teacher, and set their primary keys.
Then we create a new table for the relationship ‘have’ as STUDENT_TEACHER, which will
have student and teacher combination, and any other columns if applicable. Basically,
student-teacher combination is the two primary key columns from respective tables, hence
establishing the relationship between them. Both the primary keys from both tables act as a

YCCE. Dept. of CSE

Page 23
 composite primary key in the new table. This reduces the storing of redundant data and
consistency in the database.

Fig: Self Referencing M: N relation

YCCE. Dept. of CSE

Page 24