A hypothetical M:M 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
1234
Jones
Sally
12 Main Street
1256
Smith
Bob
689 South Street
6532
Simpson
Bart
75 Springfield Lane
2233
Winter
Kelly
987 Main Street
… denotes that there can be, or are, more entities
Concentration
Finance
MIS
Accounting
Finance
Primary Key (PK) – every table MUST have a PK attribute. Each row in each table MUST have a
unique PK value that uniquely IDs each and every record. It cannot be repeated or left blank.
Class Section Table
CRN
Designation Section
CourseName
445678
BSAD 141
A
Management Information Systems
445679
BSAD 141
B
Management Information Systems
445680
BSAD 141
C
Management Information Systems
459807
BSAD 180
A
Managerial Finance
458767
BSAD 180
B
Managerial Finance
453332
BSAD 190
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 “1
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 1:1, 1:M, or M:M) and which side of the
relationship is the “1 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.
1
I will show three different examples for illustration (only 1 is correct):
1. 1:M
2. M:1
3. M:M
NOTE: for our purposes in this class, the FK always goes on the many side of a 1:M
relationship.
1:M (a one-to-many relationship) with a class section containing many students
CLASS
SECTION


M
Contains
1
Registers for
STUDENT
Each class section can contain 1,2,…n (many) instances of a student entity (the
individual students). THIS PART OF THE RELATIONSHIP MAKES 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 MAKES 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
ID
1234
Jones
Sally
1256
Smith
Bob
6532
Simpson
Bart
2233
Winter
Kelly
….
Class Section Table
CRN
Designation Section
445678
BSAD 141
A
445679
BSAD 141
B
445680
BSAD 141
C
459807
BSAD 180
A
458767
BSAD 180
B
453332
BSAD 190
A
….
RED = PKs, BLUE = FK
Address
Concentration
CRN
12 Main Street
689 South Street
75 Springfield Lane
987 Main Street
Finance
MIS
Accounting
Finance
445678
445678
459807
453332
CourseName
Management Information Systems
Management Information Systems
Management Information Systems
Managerial Finance
Managerial Finance
Business Policy
2
Using the 1:M 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
ID
1234
Jones
1256
Smith
6532
Simpson
2233
FirstName
Address
Concentration
CRN#1
CRN#2
Sally
Bob
Bart
12 Main Street
689 South Street
75 Springfield
Lane
987 Main Street
Finance
MIS
Accounting
445678
445678
459807
453332
459807
445680
Winter
Kelly
Finance
453332
445680
….
________________________________________________________________________
Let’s switch the relationship around and look at the reverse situation:
M:1 (still a 1:M relationship, we are just switching which table is on the one side and
which table is on the many side)
CLASS
SECTION


Contains
M
1
Registers for
STUDENT
Each class section can contain ONLY one instance of student. THIS PART OF THE
RELATIONSHIP IS NOT WHAT WE WANT! IT MAKES NO SENSE
Each student can register for 1,2,…n (many) instances of class section. THIS PART
OF THE RELATIONSHIP MAKES 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.
Class Section Table
CRN
Student
ID
445678 1234
445679 1256
445680 6532
459807 2233
458767 6532
453332 1234
….
Designation
Section
CourseName
BSAD 141
BSAD 141
BSAD 141
BSAD 180
BSAD 180
BSAD 190
A
B
C
A
B
A
Management Information Systems
Management Information Systems
Management Information Systems
Managerial Finance
Managerial Finance
Business Policy
3
Student Table
Student ID LastName FirstName
Address
Concentration
1234
Jones
Sally
12 Main Street
Finance
1256
Smith
Bob
689 South Street
MIS
6532
Simpson
Bart
75 Springfield Lane
Accounting
2233
Winter
Kelly
987 Main Street
Finance
….
________________________________________________________________________
M:M
The correct relationship is a M:M 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
M
Contains
CLASS
SECTION
M
Registers for
STUDENT
We are NOT going to place a FK in both tables in the M:M 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 M:M, YOU MUST CREATE A NEW TABLE (called a junction,
joining, or link table)
BREAK UP THE M:M INTO 2 SEPARATE 1:M RELATIONSHIPS
Can be listed on M
Student
1
Each line
lists
Each line
1
lists
Schedule
Line Item M
Can be listed
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
Student Table
Student ID LastName
1234
Jones
1256
Smith
6532
Simpson
2233
Winter
….
FirstName
Sally
Bob
Bart
Kelly
Class Section Table
CRN
Designation Section
445678
BSAD 141
A
445679
BSAD 141
B
445680
BSAD 141
C
459807
BSAD 180
A
458767
BSAD 180
B
453332
BSAD 190
A
….
Schedule Line Item Table
Student ID
CRN
1234
445678
1234
459807
1234
453332
6532
445679
6532
458767
6532
453332
….
Address
12 Main Street
689 South Street
75 Springfield Lane
987 Main Street
Concentration
Finance
MIS
Accounting
Finance
CourseName
Management Information Systems
Management Information Systems
Management Information Systems
Managerial Finance
Managerial Finance
Business Policy
Schedule Line Item Table has 1 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 COMPOSITE 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 M:M
RELATIONSHIP
5
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
COMPOSITE 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