DBMS

Mapping ERD to Tables

2/6/2015

Why an ERD?
Why is good database design important? Or, why do you need to create an ERD?
To come up with a good database design, Start with pen-and-paper, or in technological terms - start by
designing the ERD.
The ERD is a model that shows the logical layout of your database. Spend a lot of time and effort to
create a good logical design, and you will reap the fruits for years to come. A good database design with
a bad application is a lot better than a bad database with a good application!
You want your data to be reliable, available, accurate, secure, relevant, consistent, and guaranteed of
solid integrity (all the principles of Information Management). The priorities of these will differ
depending on the implementation, but by doing a proper ERD, you can ensure that on a database level you
can meet all these requirements.
Advantages of proper database design:
-

Very little or no redundant data will be stored (save on space and performance)
The database will support both planned and unplanned (ad hoc) queries for data retrieval
Database structure is easy to maintain and to modify.
A good design will document itself. A new person looking at the ERD will understand what is
going on.
The ERD will help to maintain good and consistent naming standards. (For example: You will
not call something a SHIP_NO in one place and BOAT_NO or SHIP_NUMBER in another place)
The Application that works form the database will be easier to develop.

Creating an Entity Relationship (ER) Diagram

Student Class Example

Our entities: The entities Student and Class are represented with a rectangle. (Think about this class as
your register class when you were at school. ) The relationship are drawn with a line between Student and
Class. Notice the crows foot at the side of the Student entity. The crows foot indicate many. This
relationship is therefore a 1 to Many relationship. The relationship can be read a couple of ways:
1) A student will belong to 1 class
2) A class will have one or many students
3) One or many students belong to the same class
Lets add a Teacher to our diagram. Lets say that every teacher will have a register class. A teacher can
have only 1 register class and each register class will have 1 teacher.

Benard Ondiek - IAT

DBMS

Mapping ERD to Tables

2/6/2015

Notice the line between the Class and Teacher. You will see that this is a 1 to 1 relationship (no crow's
foot). One teacher has 1 register class. One register class have 1 teacher.
So far we have added 3 entities (Student, Class, and Teacher). We have 2 relationships (a 1:Many and a
1:1 relationship). There are a 3d type of relationship the Many to Many relationship.
If we add a Subject Entity to the above we will encounter the Many: Many relationship. One student will
take many subjects. One subject will have many students. Or in other words, many students will take
many subjects. Likewise, a teacher will teach one or many subjects and the same subject will be taught by
one or many teachers.
We do not want Many: Many relationships in our diagram. (Primary keys must always be unique and a
many: many relationship will violate this rule. Also, when you get to the point where you implement your
logical design into tables and integrity you will understand the problem with many: many relationships).
If we would draw the Student Subject as many: many it will look like this:

You will notice the crows foot on both side of the relationship that indicates this Many to Many
relationship.
we do not want Many: Many relationships, so we need to introduce a Junction Entity. The Junction
Entity will contain the primary key of both the entities of the many: many relationships. In our example
we will create a StudentSubject Junction Entity. In the diagram it will look like:

Benard Ondiek - IAT

DBMS

Mapping ERD to Tables

2/6/2015

Now our Many:Many relationship is broken up into 2 x 1:Many relationships. The many side of the
relationship will always point to the Junction Entity on both sides. A student will have one or many
studentSubjects. A studentSubject will have only 1 student. A subject will have one or many
studentSubjects. A studentSubect will have only 1 subject.

Mapping ERD to Table .

Our completed example ERD will look like:

The relationship between Teacher and Subject will also be a Many: Many relationship and will therefore
also require a Junction Entity - TeacherSubject in between.
Our student table might contain the following data:
StdNumber
(Primary Key)
101
102
103
104

Name

Address

Telephone

Ken Wako
Mercy Bahati
Jane Wangoi
Elvis Mwatela

45 NairobiWest
100 Juja Road
92 Muthurwa
202 Church Road

555-5522
555-1012
555-1234
555-5592

Our subject table might contain the following data:

Benard Ondiek - IAT

DBMS

Mapping ERD to Tables

SubjectCode
(Primary Key)
M100
EL100
G101
CS100
FL102

2/6/2015

Description
Mathematics 100
English Language 100
Geography 101
Computer Science 100
French Language 102

Now, in our Junction Table (StudentSubject) we will join our Student and Subject table. StudentNumber
and subjectCode combined will be the primary key in this table.
StudentNumber
101
101
101
102
102
103

SubjectCode
M100
EL100
G101
M100
CS100
FL102

You can see that student 101 (Ken Wako) have the subjects M100, EL100, G101. Student 102 (Mercy
Bahati) have M100 and CS100. Student 103 (Lindsey MacDonald) have FL102.

Benard Ondiek - IAT