OSMIS Technical Specification

Database Specification

3.1 Design Overview

The database design is based on a traditional entity-relational model. Some effort was put into developing a design that would be easy to add to, and modify for use in non-South African countries. However, there is clearly a trade-off with a heavily generalised design, with respect to ease of use and development. A design that is very general may become difficult to work with and understand, and is also likely to incur higher computational overheads. On the other hand a very specific design may be fast and easy to work with, but difficult to add to later.

The compromise chosen applies the following principles:

Some Implementation Notes
  1. Database tables are specified as either containing static data or read-write data. In the former case, the tables are populated with data when the system is installed and are never updated by the system (they may be updated administratively if the static data needs to be changed). In the latter case, the tables hold normal transactional data and may be read from and written to.
  2. The naming convention <tablename>PA has been used to name tables that contain data relevant to a specific academic year. PA stands for per annum.
  3. There is no direct link from learners to educators. Thus to represent the concept of registration classes and/or class teacher, a subject called Registration should be created. Then each class educator should be allocated a registration subject and the corresponding learners should be allocated that subject if they belong to the educator's class.
  4. The concept of subject levels (i.e. HG, SG, LG, OG) is still an outstanding issue. Currently it is implemented at the learner level. That is, an educator teaches a particular subject (with no regard for subject level) and the learners that take that subject, take it at a specific subject level. How well this maps to the real world still needs to be determined.
  << Previous Up
Next >>