Skip to content

GitLab

Last edited by Sorrel Harriet
Page history

term 1 revision

Term 1 Lab Revision (27th April 2018)

This lab session is a structured revision session, intended to help you prepare for your exam.

Please register your attendance at this lab, even if accessing it from home. Password for registermate is revislab (valid for 27th April).

The tasks (if attempted in earnest) aim to strengthen both your knowledge and your exam technique.

You should form a group of 4 initially, splitting groups of 2 for tasks 2 and 3. Please inform the lab assistant if you would like to be placed in a group.

Task 1: Mark a question against a pre-defined scheme

In this task, you are being given some fake answers to a real past exam question, along with a mark scheme for the question. The mark scheme is reminiscent of those which will be referred to when marking your exam papers.

  • In your groups, mark each of the responses with reference to the rubric
  • Try to judge the depth of a response. Has the respondent always explained each point they have made?
  • Were you always able to understand what the respondents were expressing?

The Question

The software startup company you work for has recently been commissioned to develop a web application for a tattoo parlour. The app is intended to allow clients to view examples of artists' work, and book appointments with their chosen artist.

  1. Your line manager has advised you to use the MySQL DBMS for this application. Design a simple relational schema for the application. Use an appropriate form of notation, such as an ER diagram. Indicate which MySQL datatypes each field in the schema will use, and, where applicable, indicate where any integrity constraints will be applied. [10]
  2. Another developer in your team suggests that MongoDB would offer a more 'scalable' back-end solution than MySQL. What type of database is MongoDB, and why do you think they consider it a more 'scalable' solution than MySQL? [4]
  3. The application middleware will be written in Python. You suggest that, with careful design, it would be possible to port between MySQL and MongoDB at a later date. Suggest ways in which this could be accomplished and with minimal need for rewriting code. For full marks you should explain how and why any techniques or principles you've identified are beneficial. [6]

The mark scheme

  1. Marks to be awarded for:
    • Appropriate tables, consistently named (1-2)
    • Appropriate fields, consistently named (1-2)
    • Appropriate notation (and legibility) (1)
    • Indication of appropriate integrity constraints, including at least 2 foreign key constraints, and primary keys in all tables (1-3)
    • Appropriate data types indicated (1-2)
  2. Marks for any of the following or other salient point, to a maximum of 4 marks:
    • MongoDB is a document-based data store OR
    • MongoDB is a 'Not Only SQL'/non-relational solution (1)
    • Document-based data stores lend themselves better to horizontal scaling as discrete documents are easily distributed across multiple servers. MySQL does not scale well without sharding logic being built into the application (2)
    • MongoDB supports data replication, which can help the system maintain efficiency as the userbase grows and there are more simultaneous connections to the database (2)
    • MongoDB is better adapted for dealing with big data and analytical types of database queries, which would be required when analysing large sets of learner data (2)
    • NOSQL data tends to be serialized by column, which may make query performance increase if the data set is large. (2)
  3. Marks may be awarded for any of the following or other salient point, to a maximum of 6:
    • The app should be written with portability in mind (1)
    • Logic should be separate from presentation (1)
    • There would be 'separation of concerns', meaning parts of the app that serve a related purpose are developed and maintained separately. This makes it possible to change/upgrade part of an app without the need to rewrite all other parts. (1-3)
    • Adopting OOP paradigm and creating classes to encapsulate data and behaviour associated with objects of a given type would improve portability. (1-3)
    • Python provides different APIs for interfacing with each type of database (Pymongo, MySQL Connector). (1)
    • Adopting MVC architecture (Model-View-Controller) means objects in the application are categorised as model (meaning they process data), view (meaning objects a user interacts with), or controller (meaning objects which communicate new or changed data to model objects). If implemented correctly, theoretically, only the controller objects would need rewriting, assuming the data stayed the same. (1-4)

Response A

  2. MongoDB is a more scalable solution because you can distribute data across many nodes in a cluster. You can keep adding more nodes as your data set increases.
  3. I would suggest they adopt the MVC design pattern which means Model-View-Controller. You would only need to change the model because the rest would still work with any database. You could also use a framework like Django because that already has MVC pattern so you can switch back-end easily. It is also Object-Oriented which means you can change individual bits of the application as the requirements change without changing everything. It also uses templates which keep your HTML separate from the logic.

Response B

  2. MongoDB is a more scalable solution because it stores data as binary JSON. Documents also have flexible structure so you can change it later if you get more data.
  3. I would suggest keeping the codebase really tidy and well commented to make it easier to change things later, especially if another developer was working on it. I would say they should write a function to handle the database connection, and others for fetching the data, so only these functions would need updating and the rest of the application could stay the same. They should make sure that the way they model the data in Mongo documents is similar to the way they did it in MySQL, probably making collections synonymous with tables.

Task 2: Devise a mark scheme

  • Still in your group of 4, pick one of the questions from Tuesday's 'Question Carousel', or another from a Past Paper
  • Split into 2 groups of 2
  • Working in your pair, study the following question and prepare a mark scheme for it. Your mark scheme will take into account the marks available for each part of the question. It should consider a range of likely acceptable answers, providing a model answer where appropriate.

Aim to spend at least 30 mins on this task, as you will be spending ~30 minutes per long question in the exam.

Task 3: Answer the question!

Still in your pair, have a go at writing what you think ought to be a model answer for the question (it should only take a few minutes this time). Write it on a separate sheet of paper.

Task 4: Mark a question!

  • Now swap your answer with the other members of your original group.
  • Mark the other pair's response against YOUR mark scheme

This ought to take at least 10 minutes if you do it carefully.

Task 5: Share the marks

  • Reconvene with your original group
  • Break the news to the other pair - how did they do against your mark scheme?
  • Look at each others' schemes and discuss their respective differences
  • Where you disagree, have a good old debate about it!

Bonus round

Repeat the process for another question. Your group could even make up its own question! If you do that, why not share it on the Practice Questions forum?