Student

Class Example

Lets draw our 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 rela tionship 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 relationshi p is therefore a 1 to Many relationship. The relationship can be read a couple of ways: 1) 2) 3) A student will belong to 1 class A class will have one or many students One or many students belong to the same class

At this point of the ERD design, we do not concentrate on what values / attribu tes (or columns) we will store about each entity. Lets add a Teacher to our diagram. Lets say that every teacher will have a reg ister class. A teacher can have only 1 register class and each register class w ill have 1 teacher.

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 regist er class have 1 teacher. So far we have added 3 entities (Student, Class, and Teacher). We have 2 relati onships (a 1:Many and a 1:1 relationship). There are a 3 d type of relationship t he Many to Many relationship. If we add a Subject Entity to the above we will encounter the Many: Many relatio nship. One student will take many subjects. One subject will have many student s. Or in other words, many students will take many subjects. Likewise, a teach er 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 alwa ys be unique and a many: many relationship will violate this rule. Also, when yo u get to the point where you implement your logical design into tables and integ rity 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 crow s foot on both side of the relationship that indicates t his Many to Many relationship. As we said above, we do not want Many: Many rela tionships, so we need to make a plan! Easy. We will introduce a Junction Entity . The Junction Entity will contain the primary key of both the entities of the m any: many relationship. In our example we will create a StudentSubject Junction Entity. In the diagram it will look like:

Now our Many:Many relationship is broken up into 2 x 1:Many relationships. The m any side of the relationship will always point to the Junction Entity on both si des. A student will have one or many studentSubjects. A studentSubject will h ave only 1 student. A subject will have one or many studentSubjects. A student Subect will have only 1 subject. Lets make this concept more clear with some real data. Our student table might contain the following data: StudentNumber (Primary Key) Name Address Telephone 101 Andre Pieterse 44 Church Street 555-5522 102 Adele Wright 103 Mansion Road 555-1012 103 Lindsey McDonald 92 Darwin Crescent 555-1234 104 Suzie Pienaar 102 Church Street 555-5592

Our subject table might contain the following data: SubjectCode (Primary Key)

Description M100 Mathematics 100 EM100 English Main Language 100 G101 Geography 101 CS100 Computer Science 100 FS102 French Second 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 t able. StudentNumber SubjectCode 101 M100 101 EM100 101 G101 102 M100 102 CS100 103 FS102 You can see that student 101 (Andre Pieterse) have the subjects M100, EM100, G10 1. Student 102 (Adele Wright) have M100 and CS100. Student 103 (Lindsey MacDon ald) have FS102. Our completed example ERD will look like:

The relationship between Teacher and Subject will also be a Many: Many relation ship and will therefore also require a Junction Entity - TeacherSubject in betwe en. That is all for this introduction to "Database Design - the ERD".