Database Reference
In-Depth Information
Post grades: For each section of each course, the system must post the grades that are indicated on the
class list submitted by the instructor and produce a grade verification report. (Posting the grades is the for-
mal term for the process of entering the grades permanently in the students
320
computerized records.)
Purge: Marvel College retains section information, including grades earned by the students in each sec-
tion, for two semesters following the end of the semester, then the system removes this information. (Grades
assigned to students are retained by course but not by section.)
'
MARVEL COLLEGE INFORMATION-LEVEL DESIGN
You should give some consideration to the overall requirements before you apply the method to the individ-
ual user requirements. For example, by examining the documents shown in Figures A-1 through A-6, you
may have identified the following entities: department, major, faculty member, student, course, and semester.
NOTE
Your list might include the section and grade entities. On the other hand, you might not have included the semester entity. In
the long run, as long as the list is fairly reasonable, what you include won
'
t make much difference. In fact, you may remember
that this step is not even necessary. The better you do your job now, however, the simpler the process will be later on.
After identifying the entities, you assign a primary key to each one. In general, this step will require
some type of consultation with users. You may need to ask users directly for the required information, or you
may be able to obtain it from some type of survey form. Assume that having had such a consultation, you
created a relation for each of these entities and assigned them the following primary keys:
Department (DepartmentCode,
Major (MajorNum,
Faculty (FacultyNum,
Student (StudentNum,
Course (DepartmentCode, CourseNum,
Semester (SemesterCode,
Note that the primary key for the Course table consists of two attributes, DepartmentCode (such as CS)
and CourseNum (such as 153), both of which are required. The database could contain, for example, CS 153
and CS 353. Thus, the department code alone cannot be the primary key. Similarly, the database could con-
tain ART 101 and MUS 101, two courses with the same course number but with different department codes.
Thus, the course number alone cannot be the primary key either.
Now you can begin examining the individual user views as stated in the requirements. You can create
relations for these user views, represent any keys, and merge the new user views into the cumulative design.
Your first task is to determine the individual user views. The term user view never appeared in the list of
requirements. Instead, Marvel College provided a general description of the system, together with a collection of
report requirements and another collection of update requirements. How do these requirements relate to user
views?
Certainly, you can think of each report requirement and each update requirement as a user view, but
what do you do with the general description? Do you think of each paragraph (or perhaps each sentence) in
the report as representing a user view, or do you use each paragraph or sentence to furnish additional infor-
mation about the report and update requirements? Both approaches are acceptable. Because the second
approach is often easier, it is the approach you will follow in this text. Think of the report and update
requirements as user views and when needed, use the statements in the general description as additional
information about these user views. You will also consider the general description during the review process
to ensure that your final design satisfies all the functionality it describes.
