Conversion of ERD into Normalized Tables

During Data Design, inputs from Data Modelling - Entity Relationship Diagram
(ERD) will also help arrive at the normalized tables. Let us try and understand
this concept with the help of an example. Consider the ERD given below.

Student Course Instructor

Attends / Attended by Handled by / Handles

Fig 1. ERD showing the relationship between Student, Course and Instructor

The above diagram shows 3 entities – Student, Course and Instructor. Entities,
as we know, always have data associated with it and Entities are derived from
the Datastores in Data Flow Diagram (DFD). Hence Entity represents data that is
to be stored for future use and the relationships shown in ERD should finally map
to database table relationship during Data Design or Normalization.

So every Entity shown in Fig 1 can be represented as a database table. Hence

from ERD itself we can understand that not only do we have to implement the
minimum number of tables as shown as entities but also we will understand the
relationship between these tables. Keeping this in mind, from the given example,
we should understand that the Instructor table and the Course table are related
and the Course table and the Student table are also related.

Now let us try and understand the Cardinality representation in any ERD. We
represent Cardinality as One – One, One – Many or Many – Many relationships.

One - One relationship representation

Imagine a resort is giving out Holiday Passes for free to Customers and because
passes are limited and offer is for limited period of time one Customer can
acquire only one Holiday Pass and all available holiday passes have to be given
out. Please look at the ERD for this scenario given below in Fig 2.

Customer Holiday Pass

can acquire / is acquired by

Fig 2. ERD showing the relationship between Customer and Holiday Pass

So while creating the Database tables from this ERD, we should understand
there should be minimum 2 tables – one for Customer data and the other for
Holiday Pass data. The next is representing the relationship. The relationship
shown in Fig 2 is a One – One relationship between Customer and Holiday Pass.
The primary data or key of one table should be added as foreign key in the other
table to complete the relationship.
So we are to represent Customer table as

Customer (Customer ID, Customer Name, Address)

And Holiday Pass as

Holiday Pass (PassNo., Name of Resort, Location)

representing the primary key of one table in the other table can be done in 2
ways –
Customer (Customer ID, Customer Name, Address, PassNo.)
Holiday Pass (PassNo., Name of Resort, Location)

(or)
Customer (Customer ID, Customer Name, Address)
Holiday Pass (PassNo., Name of Resort, Location, Customer ID)

If we are to populate these tables with data we will find no repeating primary key
data and so the tables stand acceptable in both cases shown above. As one
Holiday Pass can be taken by only one Customer and vice versa, the table data
can be represented as shown below.

(i) For Customer (Customer ID, Customer Name, Address, PassNo.):

Customer ID Customer Address PassNo

Name
1001 Emil Mumbai 12930
1002 John Panaji 98903

For Holiday Pass (PassNo., Name of Resort, Location):

PassNo. Name of Resort Location

12930 Coco Shimla
98903 Divine Ooty

(or)

(ii) For Holiday Pass (PassNo., Name of Resort, Location, Customer ID):

PassNo. Name of Resort Location Customer

ID
12930 Coco Shimla 1001
98903 Divine Ooty 1002

For Customer (Customer ID, Customer Name, Address):

 Customer ID Customer Address
Name
1001 Emil Mumbai
1002 John Panaji

Both the above options are correct . We need to select only one of these options
during Data Design and not both.

So finally, the general rule is that in a One to One Relationship of ERD, the
primary key of either table can be added to the other table.

One - Many relationship representation

Consider a Department that has many employees which is very simple to
understand. In a particular context, let us assume that both Department and
Employee details are relevant for future use, hence the Entities would be
Department and Employee and the ERD can be seen in Fig 3.

Department Employee

Has / Belongs to
Fig 3. ERD showing the relationship between Department and Employee

By the ERD we should understand, as explained earlier that we will have at least
2 tables – one for Department data and the other for Employee data. Now let us
understand how the cardinality will be represented when it comes to table design.

Suppose in the Department table we also include the primary key of Employee to
show the relationship and populate such a Department table with data, we must
remember that one Department record will have many Employee primary data as
per the ERD in Fig 3.

Hence for Department (Department ID, Department Name, Employee ID) the
table will look like this:

Department ID Department Name Employee ID

Fin Finance 123123
Fin Finance 234234
Fin Finance 134234
HR Human Resources 356432
HR Human Resources 243534
HR Human Resources 224456
The Department ID being the primary key for Department table, as you can see,
there are repeating groups. Hence such a table cannot be represented. On the
other hand, suppose we represent the Department ID in the Employee table, we
will get a different picture.

For Employee (Employee ID, Employee Name, Address, Department ID), after
populating the table, it will look like:

Employee ID Employee Address Department ID

Name
123123 Raj Palayam Fin
234234 Ramu Statue Fin
134234 Seena Thampanoor Fin
356432 Bibin GeneralHospital HR
243534 Remya Kariyavattom HR
224456 Janet Sreekaryam HR

The above given table proves to be acceptable as there are no repeating groups
and table seems to be normalized.

Hence the general rule is in a One to Many Relationship among Entities, the
primary key of the Entity that has the ‘One’ relationship should be added to
the data of the Entity that has the ‘Many’ relationship in ERD.

So, in a Department with many Employees and Employee unique to a

Department, in the Employee table the Department key is added. Likewise, if one
salesman sells many products that are sold by only that salesman then in the
Product-Sales table, the Salesman ID will be added; if one Instructor takes up
many Courses and a Course is taken by only one Instructor, then in the Course
table the Instructor ID will be added.

Many - Many Relationship representation

Imagine in a library, one Member can take many Books and one Book (assuming
that a Book has many copies) can be taken by many Members, then the ERD
would look like:

Member Book

Takes and Returns / Taken and Returned by

Fig 4. ERD showing the relationship between Member and Book

By now, we should have understood that when a ‘Many’ aspect comes we can
see repeating groups if we form the wrong relationships between tables, hence
we should realize by now that in a Many to Many relationship in ERD, the primary
key of one cannot be added directly into the other table. So here we would have
to create a third table for the purpose of normalization.

So we will have a Member Table as we have a Member Entity; we will also have
a Book table as we have the Book Entity. In addition to this, a Third table
Transaction can also be created. If we are to diagrammatically represent this, it
would look like:

Member Book

Transaction
(Issue / Return / Renew) can have / is made on
can make / made by
Fig 5. Diagram to show the refined relationship from Fig 4

As you can see in Fig 5, we have broken up the relationships shown in Fig 4. –
Many to Many into two ‘One to Many’ relationships, by introducing the third to-be
table Transaction. So a Member can make many Transactions and one
Transaction can be made by only one Member. Similarly, one Book can have
many Transactions (as assumed above - one Book has many copies) and one
Transaction can be made only on one Book (assuming that many Books are
taken through many separate Transactions).

Now we can create the tables by looking at the rule for One to Many Relationship
which we explained earlier. So for the ‘Many’ Relationship Entity we must
consider the ‘One’ Relationship primary key.

Hence the tables from ERD of Fig 4 will now look like this:

Member (Member ID, Member Name, Address, PhoneNo)

Book (Book ID, Book Name, Author, Publisher)
Transaction (Member ID, Book ID, Transaction Date, Status)

Let us now populate the tables with data.

Member ID Member Name Address PhoneNo

1 Praveen N. Parur 2312424
2 Anoop Aluva 2323311
3 Deepa Ernakulam 3423451

Book ID Book Name Author Publisher

1001 ABC Ralph ERT
1002 XYZ John ASD
1003 EFG Kenneth ZXC
 Member ID Book ID Transaction Status
Date
1 1002 12-Dec-08 Returned
1 1003 15-Jan-09 Issued
2 1001 18-Dec-08 Renewed

In the Transaction table, Member ID and Book ID are together taken as a

Composite Key. Hence there are no repeating groups and the tables are also
normalized.

So the general rule for Many to Many Relationships in ERD is to form the
tables we need to break the Many to Many into ‘One to Many’ or ‘One to
One’ relationships and then follow the corresponding rules, as explained
earlier, accordingly. A third table will be formed which will most probably
have two primary keys from the other two tables to form a composite key.

Coming back to Fig 1, let us try and covert this ERD into its corresponding tables.
We will break the ERD to understand what the individual tables will look like.

Course Instructor

Handled by / Handles
Fig 1.1 ERD showing the relationship between Course and Instructor

This is a ‘One to Many’ Relationship and hence in the ‘Many’ relationship Entity
table Course we must include the primary key of Instructor.

So the initial tables that are arrived at from this ERD (Fig 1.1):

Course (Course ID, Course Name, Instructor Name)

Instructor (Instructor Name, Instructor Location)

Now let us look at the other part of the ERD in Fig 1.

Student Course

Attends / Attended by

Fig 1.2 ERD showing the relationship between Student and Course

This is a ‘Many to Many’ Relationship and hence we need to break this further
and include a third table while doing Data Design. We can break this relationship,
as explained earlier into ‘One – many’ or ‘One – One’ relationships (which ever is
relevant to the problem statement and assumptions taken) and include the third
Relationship Table. So in addition to Student and Course tables, we can a third
table named Registration and the relationship between Student and Registration
and between Course and Registration will both be One to Many. Hence the
Registration table will have a primary key from Student table and a primary key
from Course Table and these primary keys can act as Composite key in
Registration table. So the tables that can be derived from ERD given in Fig 1.2
are:

Student (Student ID, Student Name, Major)

Course (Course ID, Course Name, Instructor Name) – this table that has
Instructor Name was explained earlier.
Registration (Student ID, Course ID, Grade) – here Grade will be a separate
attribute of Registration table.

So the final tables arrived at from the ERD given in Fig 1 are:

• Student (Student ID, Student Name, Major)

• Course (Course ID, Course Name, Instructor Name*)
• Instructor (Instructor Name, Instructor Location)
• Registration (Student ID, Course ID, Grade)

Arriving at the tables from ERD is a simple process and you can verify this by
also arriving at the tables for the corresponding case by following the Rules of
Normalization.