Mapping ERD to Tables


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 crow’s foot at the side of the Student entity. The crow’s 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


(Primary keys must always be unique and a many: many relationship will violate this rule. we do not want Many: Many relationships. a teacher will teach one or many subjects and the same subject will be taught by one or many teachers. Likewise. If we add a Subject Entity to the above we will encounter the Many: Many relationship. One subject will have many students. You will see that this is a 1 to 1 relationship (no crow's foot). many students will take many subjects. We do not want Many: Many relationships in our diagram. One teacher has 1 register class. One student will take many subjects.DBMS Mapping ERD to Tables 2/6/2015 Notice the line between the Class and Teacher. Class. Or in other words. In the diagram it will look like: Benard Ondiek . 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. So far we have added 3 entities (Student. In our example we will create a StudentSubject Junction Entity. There are a 3’d type of relationship  the Many to Many relationship. If we would draw the Student – Subject as many: many it will look like this: You will notice the crow’s foot on both side of the relationship that indicates this Many to Many relationship.IAT 2 . We have 2 relationships (a 1:Many and a 1:1 relationship). One register class have 1 teacher. 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). and Teacher).

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 . A studentSubject will have only 1 student. Mapping ERD to Table . The many side of the relationship will always point to the Junction Entity on both sides. 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 . A subject will have one or many studentSubjects.TeacherSubject in between.DBMS Mapping ERD to Tables 2/6/2015 Now our Many:Many relationship is broken up into 2 x 1:Many relationships.IAT 3 . A student will have one or many studentSubjects. A studentSubect will have only 1 subject.

Student 103 (Lindsey MacDonald) have FL102. in our Junction Table (StudentSubject) we will join our Student and Subject table. EL100. 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. Benard Ondiek .IAT 4 . StudentNumber and subjectCode combined will be the primary key in this table. Student 102 (Mercy Bahati) have M100 and CS100. G101.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.