A hypothetical M:M student schedule example

Transcription

1 A hypothetical : student schedule example We are interested in creating a relationship between two tables: Student and Class Section. We want to be able to be able to have students register for different class sections for scheduling purposes and need to assign individual students to individual class sections. Using a relational DB approach, we create separate tables for each group of related entities one table contains all the student information (the attributes dealing specifically with students) and one table containing all the class section information (attributes dealing specifically with class section). We want to be able to update the information in one table without having to manually change the information in the other table. For example, using tables I can add, delete, or edit student information and not have to change any information in the course section table. Student Table Student ID LastName FirstName Address Concentration 234 Jones Sally 2 ain Street Finance 256 Smith Bob 689 South Street IS 6532 Simpson Bart 75 Springfield Lane Accounting 2233 Winter Kelly 987 ain Street Finance denotes that there can be, or are, more entities Primary Key (PK) every table UST have a PK attribute. Each row in each table UST have a unique PK value that uniquely IDs each and every record. It cannot be repeated or left blank. CRN Designation Section CourseName BSAD 4 A anagement Information Systems BSAD 4 B anagement Information Systems BSAD 4 C anagement Information Systems BSAD 80 A anagerial Finance BSAD 80 B anagerial Finance BSAD 90 A Business Policy denotes that there can be, or are, more entities To create a relationship between the two tables (link the tables), we must create a foreign key (FK) attribute. We do this by using the primary key attribute from the table on the side of the relationship as a foreign key in the table on the many side of the relationship. The connectivity of the relationship (whether it is :, :, or :) and which side of the relationship is the side and which side is the many side depends on the actual or practical relationship between the two tables. The relationship depends on how things work or is structured in reality.

2 I will show three different examples for illustration (only is correct):. : 2. : 3. : NOTE: for our purposes in this class, the FK always goes on the many side of a : relationship. : (a one-to-many relationship) with a class section containing many students CLASS SECTION Contains Registers for STUDENT Each class section can contain,2, n (many) instances of a student entity (the individual students). THIS PART OF THE RELATIONSHIP AKES SENSE Each student can register for ONLY one instance of a class section entity. THIS PART OF THE RELATIONSHIP IS NOT WHAT WE WANT! IT AKES NO SENSE We create a relationship by using the primary key (PK) attribute from the one side of the relationship (course table) as a foreign key (FK) attribute on the many side of the relationship (student table). CRN (course reference number) is the PK attribute in the Class Section table. We repeat that attribute in the Student Table. So, CRN becomes the Foreign Key (FK) in the Student table. Student Table Student LastName FirstName Address Concentration CRN ID 234 Jones Sally 2 ain Street Finance Smith Bob 689 South Street IS Simpson Bart 75 Springfield Lane Accounting Winter Kelly 987 ain Street Finance CRN Designation Section CourseName BSAD 4 A anagement Information Systems BSAD 4 B anagement Information Systems BSAD 4 C anagement Information Systems BSAD 80 A anagerial Finance BSAD 80 B anagerial Finance BSAD 90 A Business Policy RED = PKs, BLUE = FK 2

3 Using the : relationship the PHYSICAL STRUCTURE of the database allows each student in the Student table to only register for one course. In the Student table there is no more room to add additional courses for each student. Why don t we just add more CRN fields? What is the problem with this approach? Student Table Student LastName FirstName Address Concentration CRN# CRN#2 ID 234 Jones Sally 2 ain Street Finance Smith Bob 689 South Street IS Simpson Bart 75 Springfield Accounting Lane 2233 Winter Kelly 987 ain Street Finance Let s switch the relationship around and look at the reverse situation: : (still a : relationship, we are just switching which table is on the one side and which table is on the many side) CLASS SECTION Contains Registers for STUDENT Each class section can contain ONLY one instance of student. THIS PART OF THE RELATIONSHIP IS NOT WHAT WE WANT! IT AKES NO SENSE Each student can register for,2, n (many) instances of class section. THIS PART OF THE RELATIONSHIP AKES SENSE Each table still has the same PK, but now a FK goes in the Class Section table (it is now on the many side of the relationship. CRN Student Designation Section CourseName ID BSAD 4 A anagement Information Systems BSAD 4 B anagement Information Systems BSAD 4 C anagement Information Systems BSAD 80 A anagerial Finance BSAD 80 B anagerial Finance BSAD 90 A Business Policy 3

4 Student Table Student ID LastName FirstName Address Concentration 234 Jones Sally 2 ain Street Finance 256 Smith Bob 689 South Street IS 6532 Simpson Bart 75 Springfield Lane Accounting 2233 Winter Kelly 987 ain Street Finance : The correct relationship is a : relationship that allows students to register for more than one instance of class section and allows class section to contain more than one instance of a student CLASS SECTION Contains Registers for STUDENT We are NOT going to place a FK in both tables in the : case because that will still not allow us to model the relationship in an accurate way. What should be done WHEN EVER YOU HAVE A :, YOU UST CREATE A NEW TABLE (called a junction, joining, or link table) BREAK UP THE : INTO 2 SEPARATE : RELATIONSHIPS Student Can be listed on Each line lists Schedule Line Item Each line lists Can be listed on Class Section The new joining table should be named appropriately. What does the table do? The table provides a line-by-line matching of one instance of class section and one instance of student. The new joining table could be named Schedule Line Item because it will match one student ID with one CRN on each line of the table (a class schedule). It could also be called something like Class Section Line Item because it will give a line-byline listing of each student ID in each class section. The joining table ALWAYS provides a line-by-line matching of a single instance in one table to a single instance in another table. This works because each student ID value can be repeated many times AND each CRN value can be repeated many times using a composite PK. 4

5 Student Table Student ID LastName FirstName Address Concentration 234 Jones Sally 2 ain Street Finance 256 Smith Bob 689 South Street IS 6532 Simpson Bart 75 Springfield Lane Accounting 2233 Winter Kelly 987 ain Street Finance CRN Designation Section CourseName BSAD 4 A anagement Information Systems BSAD 4 B anagement Information Systems BSAD 4 C anagement Information Systems BSAD 80 A anagerial Finance BSAD 80 B anagerial Finance BSAD 90 A Business Policy Schedule Line Item Table Student ID CRN Schedule Line Item Table has PK and 2 FKs PK: Student_ID + CRN (this is a composite key) FK: Student_ID is the foreign key in the Schedule Line Item table to the Student table FK: CRN is the foreign key in the Schedule Line Item table to the Class Section table The Primary key for the new joining table (in this case called Schedule Line Item Table) is a COPOSITE KEY using both Student_ID and CRN together. Each field is also a Foreign Key back to the original table. THIS IS A NEW TABLE THAT IS CREATED SPECIFICALLY TO RESOLVE THE : RELATIONSHIP 5

6 The foreign keys (FK) are Student_ID from Student table and Course_ID from Course table In this case, we can use each foreign key and combine them together to make a unique COPOSITE Primary Key (PK) attribute. Alternatively, we could create a new field like Schedule Line Item ID (or something to that affect) to serve as the PK attribute. This prevents students from registering more than once for same class. Why do this? You should be able to see how flexible the Schedule Line Item Table is. This new table can be called a joining, junction, or link Table Don t repeat student or course info on multiple lines Can easily edit the joining table data without changing the student or course data 6