Database Reference
In-Depth Information
Semester
325
Entity not yet
related to any
other entity
Major
Department
Course
MajorNum
DepartmentCode
CourseNum
DepartmentCode (FK)
Description
DepartmentCode (FK)
DepartmentName
CourseTitle
NumCredits
has prereq
is prereq
Prereq
CourseNum (FK)
DepartmentCode (FK)
CourseNum/1 (FK)
DepartmentCode/1 (FK)
Advises
Ofice
MajorNum (FK)
StudentNum (FK)
OficeNum
Phone
FacultyNum (FK)
Faculty
FacultyNum
LastName
FirstName
Street
City
State
Zip
CurrentRank
StartDate
OficeNum (FK)
DepartmentCode (FK)
Student
StudentNum
LastName
FirstName
LocalStreet
LocalCity
LocalState
LocalZip
PermStreet
PermCity
PermState
PermZip
FIGURE A-10
Cumulative design after User View 2
Report card: At the end of each semester, the system must produce a report card for
each student. Report cards are fairly complicated documents in which the appropriate underlying relations
are not immediately apparent. In such a case, it
User View 3
—
s a good idea to first list all the attributes in the report card
and assign them appropriate names, as shown in Figure A-11. After identifying the attributes, you should list
the functional dependencies that exist between these attributes. The information necessary to determine
functional dependencies must ultimately come from the user, although you can often guess most of them
accurately.
'
NOTE
Notice that there are duplicate names in the list. CreditsEarned, for example, appears three times: once for the course, once for
the semester, and once for the cumulative number of credits earned by the student. You could assign these columns different
names at this point. The names could be CreditsEarnedCourse, CreditsEarnedSemester, and CreditsEarnedCumulative. Alter-
natively, you could assign them the same name with an explanation of the purpose of each one in parentheses, as shown in
Figure A-11. Of course, after you have determined all the tables and assigned columns to them, you must ensure that the
column names within a single table are unique.
