1-M关系数据库设计

Question

I'm trying to come up with a database design for the following scenario.

Student can register to a Programme, at a given time student can have only one registered programme.However, he/she must be able to change the registered programme at any given time (including registering to a new programme). Ultimately, student can be registered to multiple programme but he must have only 1 active programme.

I think it should be a 1-M relationship but how to handle this "1 active programme at a given time" situation?

Answer 1

Your student table will have the ProgramID in relation to the Program table for example that he/she chooses and would be the current program. Now, every time he/she change his/her program that ProgramID will change however there will be a ProgramHistory to record the changes.

So possible table would be Student , Program , ProgramHistory .

Example :

Student

StudentID    Lastname    Firstname   Gender  ProgramID
------------------------------------------------------
101          Smith       Jason       M       1
102          Jones       Kate        F       2

Program

ProgramID    ProgramName
------------------------------
1            Computer Science
2            Nursing
3            Electrical Engineering

ProgramHistory

ID         ProgramID    StudentID    Semester    Year
-----------------------------------------------------
1          3            101          Spring      2014
2          2            102          Fall        2014
3          1            101          Fall        2014

Answer 2

To allow for tracking of the history of program enrollment, you need to have a ProgramHistory table that is the intersection of a many-to-many relationship between Student and Program

There are a couple of ways to ensure that there is only one active program at one time for a given student.

One way would be to put an active_program_key column in your student table and make it a foreign key to the Program table. This is probably not the best alternative, since it requires denormalizing data and the resulting duplication might result in data inconsistencies unless you take significant steps to avoid them.

Another option using declarative constraints is to create a unique index on the ProgramHistory table that includes the student_key and the enrollment_date . This ensures that a student can only enroll in once per given date. The active program will be the record with the latest date for any given student.

This second option is simple and avoids duplicating any data. In fairness, the query to retrieve current student enrollments will be slightly more complicated. As always, design is about trade-offs.

Assuming that students can change programs at just about any time (ie not just between semesters) then you want to have a program_start_date in your ProgramHistory table.