This program simulated the function of a database for a University. The data included:
- Courses and their codes including Credit Point Value and Student Quota.
- Region codes.
- Student details including Name, ID Number, Registration Year, Region and Courses.
- Staff details including Name, Staff Number and Tutor/Counsellor details.
The specificaton also showed constraints imposed upon the system. e.g.
- Staff members may only be Tutors/Counsellors for students within the same region.
- Students can do no more than 180 pts per year.
The hierarchical nature of the program showed second-level menus. This provided for access control to restrict user views. This access control was further reinforced by the required use of passwords. In this way the data was protected, allowing each user access to the data appropriate to that user.
Using particular forms allows a user to update data appropriate to that user. Once updated, this data was available to be viewed through other forms by other users.
These user views should be thought of as Application Processes . The processing of data pertinent to a specific user view to perform a given task.
Performing a number of updates to effect a given function is known as a transaction.
Data displayed in some of the forms, particularly the Admin form, is derived data. That is data that has been counted or calculated (derived) from input data aka Operational Data.
Comments, suggestions, ideas to
Stuart Banner