This action might not be possible to undo. Are you sure you want to continue?
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 Attends / Attended by Course Handled by / Handles Instructor
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 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.
. PassNo. Location. the table data can be represented as shown below. (i) For Customer (Customer ID. 12930 98903 Name of Resort Location Coco Divine Shimla Ooty Customer ID 1001 1002 For Customer (Customer ID..So we are to represent Customer table as Customer (Customer ID. Address. Location): PassNo. Name of Resort. Address): . Address) And Holiday Pass as Holiday Pass (PassNo.): Customer ID 1001 1002 Customer Name Emil John Address Mumbai Panaji PassNo 12930 98903 For Holiday Pass (PassNo. Name of Resort. 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. Name of Resort.. Address. Name of Resort. Customer Name. Location) (or) Customer (Customer ID. Location. Customer Name.. Customer Name. Customer Name. 12930 98903 Name of Resort Location Coco Shimla Divine Ooty (or) (ii) For Holiday Pass (PassNo. Address) Holiday Pass (PassNo.. Customer Name. Location) representing the primary key of one table in the other table can be done in 2 ways – Customer (Customer ID.) Holiday Pass (PassNo. Name of Resort. PassNo. Customer ID): PassNo.
So finally.Customer ID 1001 1002 Customer Name Emil John Address Mumbai Panaji Both the above options are correct . as you can see. hence the Entities would be Department and Employee and the ERD can be seen in Fig 3. 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. Department Name. One . we must remember that one Department record will have many Employee primary data as per the ERD in Fig 3. ERD showing the relationship between Department and Employee Employee By the ERD we should understand. 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. let us assume that both Department and Employee details are relevant for future use.Many relationship representation Consider a Department that has many employees which is very simple to understand. Hence for Department (Department ID. Department Has / Belongs to Fig 3. Now let us understand how the cardinality will be represented when it comes to table design. the general rule is that in a One to One Relationship of ERD. We need to select only one of these options during Data Design and not both. On the . the primary key of either table can be added to the other table. In a particular context. as explained earlier that we will have at least 2 tables – one for Department data and the other for Employee data. there are repeating groups. Hence such a table cannot be represented.
hence we should realize by now that in a Many to Many relationship in ERD. 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. In addition to this. Many . in a Department with many Employees and Employee unique to a Department. if one Instructor takes up many Courses and a Course is taken by only one Instructor. a Third table . So here we would have to create a third table for the purpose of normalization. after populating the table. For Employee (Employee ID. we will also have a Book table as we have the Book Entity. Employee Name. So. the Salesman ID will be added. we should have understood that when a ‘Many’ aspect comes we can see repeating groups if we form the wrong relationships between tables. in the Employee table the Department key is added. it will look like: Employee ID Employee Name 123123 Raj 234234 Ramu 134234 Seena 356432 Bibin 243534 Remya 224456 Janet Address Palayam Statue Thampanoor GeneralHospital Kariyavattom Sreekaryam Department ID Fin Fin Fin HR HR HR The above given table proves to be acceptable as there are no repeating groups and table seems to be normalized. then in the Course table the Instructor ID will be added. if one salesman sells many products that are sold by only that salesman then in the Product-Sales table. So we will have a Member Table as we have a Member Entity.other hand. ERD showing the relationship between Member and Book By now. the primary key of one cannot be added directly into the other table. one Member can take many Books and one Book (assuming that a Book has many copies) can be taken by many Members. Address. then the ERD would look like: Member Book Takes and Returns / Taken and Returned by Fig 4. Hence the general rule is in a One to Many Relationship among Entities. we will get a different picture. suppose we represent the Department ID in the Employee table.Many Relationship representation Imagine in a library. Likewise. Department ID).
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). Parur Aluva Ernakulam PhoneNo 2312424 2323311 3423451 Book ID 1001 1002 1003 Book Name ABC XYZ EFG Author Ralph John Kenneth Publisher ERT ASD ZXC . PhoneNo) Book (Book ID. Publisher) Transaction (Member ID. If we are to diagrammatically represent this. Book Name. Diagram to show the refined relationship from Fig 4 As you can see in Fig 5. Address. Status) Let us now populate the tables with data. Hence the tables from ERD of Fig 4 will now look like this: Member (Member ID. So for the ‘Many’ Relationship Entity we must consider the ‘One’ Relationship primary key.Transaction can also be created. one Book can have many Transactions (as assumed above . Now we can create the tables by looking at the rule for One to Many Relationship which we explained earlier. So a Member can make many Transactions and one Transaction can be made by only one Member. we have broken up the relationships shown in Fig 4. Book ID. Author. Member ID 1 2 3 Member Name Praveen Anoop Deepa Address N. Member Name. Transaction Date. Similarly. – Many to Many into two ‘One to Many’ relationships. it would look like: Member Book Transaction (Issue / Return / Renew) can make / made by can have / is made on Fig 5. by introducing the third to-be table Transaction.
Course Name.Member ID 1 1 2 Book ID 1002 1003 1001 Transaction Date 12-Dec-08 15-Jan-09 18-Dec-08 Status Returned Issued Renewed In the Transaction table. So the initial tables that are arrived at from this ERD (Fig 1.2 ERD showing the relationship between Student and Course 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. accordingly. Instructor Name) Instructor (Instructor Name. We will break the ERD to understand what the individual tables will look like.1): Course (Course ID.1 ERD showing the relationship between Course and Instructor 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. let us try and covert this ERD into its corresponding tables. Hence there are no repeating groups and the tables are also normalized. So in addition to Student and Course tables. Member ID and Book ID are together taken as a Composite Key. 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. 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. we can a third . Instructor Location) Now let us look at the other part of the ERD in Fig 1. Student Attends / Attended by Fig 1. Course Handled by / Handles Fig 1. as explained earlier. We can break this relationship. 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.
Course Name. Major) Course (Course ID. Registration (Student ID. Student Name. Student Name. Instructor Name) – this table that has Instructor Name was explained earlier. Instructor Name*) Instructor (Instructor Name. . So the final tables arrived at from the ERD given in Fig 1 are: • • • • Student (Student ID. Course ID. Course ID.2 are: Student (Student ID. 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. 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. Major) Course (Course ID. Course Name. So the tables that can be derived from ERD given in Fig 1. Instructor Location) Registration (Student ID. Grade) – here Grade will be a separate attribute of Registration table.table named Registration and the relationship between Student and Registration and between Course and Registration will both be One to Many.