Database Reference
In-Depth Information
The portion of this user view that is not already present in the cumulative design concerns the primary
and alternate schedule codes that students request. A table to support this portion of the user view must
contain both a primary and an alternate schedule code. The table must also contain the number of the stu-
dent making the request. Finally, to allow the flexibility of retaining this information for more than a single
semester to allow registration for more than a semester at a time, the table must also include the semester in
which the request is made. This leads to the following relation:
333
RegistrationRequest (StudentNum, PrimaryCode, AlternateCode, SemesterCode)
For example, if student 381124188 were to request the section with schedule code 2345 and then
request the section with schedule code 2396 as an alternate for the FA13 semester, the row (381124188,
2345, 2396, "FA13") would be stored. The student number, the primary schedule code, the alternate schedule
code, and the semester code are required to uniquely identify a particular row.
Q&A
Question: Determine the tables and keys required for User View 7. Merge the result into the cumulative
design and draw the E-R diagram for the new cumulative design.
Answer: Figure A-16 shows the new cumulative design. Notice that two relationships join the Section table to
the RegistrationRequest table, so you must name each of them. In this case, you use “primary” and “alter-
nate,” indicating that one relationship relates a request to the primary section chosen and that the other
relationship relates the request to the alternative section when there is one.
