A guest post from our summer student William Brookes, who now returns to Part II Mathematics after doing some great work with Course Tools during his eight weeks at CARET.
I have come to the end of a very enjoyable 2 months working on the Course Tools project. I have learnt more than I am ever likely to need about the intricate structures of various degrees at Cambridge and how you can combine and convert between different Courses and Parts.
The simplistic structure I envisaged for degrees was that Lectures/Practicals make up Courses which make up Parts (what’s a Part at Cambridge?) which make up Degrees. Lectures seem to be in a single course, whereas courses and parts can be in multiple parts and degrees. In addition, multiple departments can be involved in running a course or a part.
I wanted to be able to require certain information about different levels of the degree (Lectures need times and days of the week, degrees need information for prospective students) so decided to make a relational database with each level as a table. Where there was a need for multi-parenting, I added an additional join table which allows many joins to be made.
Upon collecting data, I found not all degrees fitted neatly into my original structure. Part Engineering IIA groups its courses into “Engineering Areas” which is important for specialisation (you must take 6 courses from your specialist area). Course Biochemistry and Molecular Biology IB divides the lectures in it into groupings. I felt my database needed to be able to store this information as it is important to the structure of the course.
To solve this, I could have added additional tables to the database for each of these groupings, with associated join tables (what’s a join table?). This would create multiple routes through the hierarchy and make it less clear where data should be stored. I aimed to use the fact that lectures and courses are only in a single grouping to avoid restructuring my database. Instead I added them as an additional field, which both allowed the structure to be stored without complicating the database. I also created a join table between Parts so I could record that a Part allowed you to do another Part. This is particularly useful as Cambridge aims to enable students to switch between courses simply, and this helps to see it.
My structure caused a few issues during implementation. In Natural Sciences, you specialise as you progress, choosing 4 courses in IA, 3 in IB and 1 in II. From this progression, one would expect something like History and Philosophy of Science II to be a course, however it comprises of things that are structurally courses and it is a whole year’s work. I therefore made the Part II NST into parts in their own right. This fits structurally, and Physical Sciences II contains courses from NST IB so were it a course it would be a course within a course which would not fit within my system. This brings up issues as I am defining things by their structure rather than what they should naturally be.
In addition, lots of the groupings of courses are called things like “course” or “option”. This created problems in identifying them, as groupings do not have a unique identifier. Part Physical Sciences II, for example, contains 2 groupings in it both called “option”. The best way I could find to attempt to avoid this is to say groupings are the same if the courses are included in the same parts, else they are different. However this is not a satisfactory solution.
Kuali Student’s nested hierarchy avoids the issues in difficult structures and is able to do any groupings necessary without needing a change to the database. It uses templates for different things and so creating a whole new structure is simply a case of creating new templates. A current issue that arrises from Kuali is that it does not permit courses to be multi-parented by departments. This is highly unsatisfactory for modelling the Cambridge structure.
After much studying of the structure of courses at Cambridge, I have come to appreciate the level to which it is designed to aid the students. Much effort is put into allowing students options to change and flexibility in their courses. While this may complicate any models of structure, it is a valuable service.
My conclusion about a design for a way of storing the data is that a rigid, hardwired structure is not a good solution, as it forces things to comply and has to fudge awkward cases. It cannot adjust well to potential changes in structure in the future and some structures may arise that do not fit. A solution like Kuali will solve such structural problems so is likely to be a good solution, but due to the vagueness of the structure great care is required in implementation.