I participated in the Database Disciplinary Commons in Computing Education project with academics from other Universities in the UK. The project was led by Sally Fincher (University of Kent) and Richard Cooper (University of Glasgow). This page is the starting point for my portfolio, which describes the module, Introduction to Database Development, which I taught during the first semester of session 2009/10.The material is organised under a set of headings, corresponding to the tabs below.

Philosophy of teaching

I came into teaching computing by a rather circuitous route, which started with a year of studying computer science as an elective subject during a degree in physics. Having discovered that I foung this more interesting than the main subject, it would have been sensible to change at that point. So, I continued with the physics and spent quite a few years in a research career much of which was spent looking for excuses to write software to analyse or control something.Having seen the light eventually, I have been doing this now for about ten years. So what sort of philisophy of teaching have I developed in that time? Well, I'm not sure if this constitutes a philosophy, but here are a couple of random thoughts which seem important to me.

Due to an unfortunate habit of volunteering for things, I've been involved in teaching quite a variety of subjects, including databases (obviously), programming, networking, system administration, web development, HCI... It seems to me that students, probably encouraged by the modular system, regard their courses as a collection of isolated entities, to be passed and then, probably, forgotten. They don't see, and are probably not encouraged to see, the links and dependencies between modules. A database is a useful thing, but only as part of some kind of information system, which will probably need to be programmed, will probably communicate over a network, will run on an operating system, may have a web front end designed according to HCI principles, and so on. I think it's important to emphasise these links, to make use of a little bit of knowledge about one topic in the learning of another. For that reason, I rather like the philosophy of the course within which my Commons module is delivered. The idea is to deliver short modules which introduce computing topics by explaining the part they play in an overall case study computer system. It's an idea which is difficult to put into practice, but I hope that we do make some connections in the students' minds as we go along.

Possibly the most important thing that I've learned, and continue to learn, is that Other People Have Good Ideas. Working closely with colleagues on the design and delivery of a course is one way of sharing ideas, but this is not always the way things work within a university. There are other ways, though. For me, the Disciplinary Commons project has been a fantastic opportunity to talk to people teaching the same kind of topics to different students in different environments, and to learn about how they do things. The portfolios from previous Commons projects are a hugely valuable source of ideas and of prompts for thinking about my own teaching - I think I now appreciate the value of these more having been involved in the process myself. I hope this portfolio, along with the others in the Database Disciplinary Commons, turns out to be an example of "useful sharing"..

Portfolio materials

  • Context
  • Content
  • Instructional Design
  • Delivery
  • Assessment
  • Evaluation

Institutional context
Saltire CentreGlasgow Caledonian University was formed in 1993 with the aim of providing non-elitist, high quality education and training to a wide and diverse range of students. It is the newest of the three universities in the city of Glasgow, and has a greater focus on teaching and widening access than the older institutions. Students come from a wide range of social and educational backgrounds. The university has the advantage of a city centre location, with excellent transport links. GCU has gained a reputation for providing excellent experience for international students, who are mainly enrolled on postgraduate programmes. Lke the other Glasgow universities has a high proportion of local students on its undergraduate programmes.

Course context
My Introduction to Database Development (INTDD)module is included within a suite of programmes offered within the School of Engineering and Computing at GCU. It is part of a group of modules which are common to the first year of all computing programmes at GCU: Computing (Web Systems Development), Computing (Information Systems Development), Games Software Development, Games Design, Networking and IT Management for Business. For some of these programmes, INTDD is the first of a sequence of modules on databases, while for others it is the only time in their course that students will study databases.

The philosophy of the common first year modules was to provide a 'flavour' of a representative range of topics and roles within the industries likely to be of interest to graduates from the programmes. In addition to databases, there are modules on systems developmnet, programming, web development, computer architecture, networking, games design and, media content creation. Students enrol on a named programme, but have the opportunity to switch at the end of the first year, hopefully having then gained an insight into what is involved in their chosen path of study. The consequence of this approach is that most of these modules are short, 10 credit modules (most modules in other years of the programmes are 20 credits) which are delivered over 6 weeks. It was intended to build much of the teaching on different modules round their contribution to a common "case study" system which would emphasis how the different aspects and roles fit together. This has proved difficult to implement in practice, but the INTDD module does tie in closely with system development and programming modules in particular to emphasise the idea of a database as a vital component in a computer system. One of the lab activities (lab 4) in particular was designed to link databases with Java programming.


Lectures are all delivered in a large lecture theatre, M001. Labs take place in computer labs, each of which can accommodate a maximum of 20 students. A number of different labs are used, and there is some variation in the facilities available, for example projector, whiteboard. Tutorials take place in small class rooms with no student computers. Each classroom has a lecturer computer and projector.
Computer lab Lecture theatre

These prospectus pages give general descriptions of the computing programmes and the subjects studied within each one through the levels..

Prospectus (extract)

Module descriptor
The content of the INTDD module is determined initially by the module descriptor, validated along with the suite of programmes on which it is delivered. The descriptor says that the module:

"provides an introduction to Database technologies. These technologies include basic Relational Data Modelling concepts and practice, and simple data querying. Students will develop and query a simple database which provides a specific functional element of an information system"

The module descriptor also defines the intended learning outcomes of the module, stating that at the end of the module students should be able to:

- Describe the basic principles of the relational data model
- Define and create tables for a simple database  
- Create forms for entering data into the database
- Define simple queries and reports to retrieve information from the database

The content of what is taught on the INTDD module is designed to interpret and satisfy these statements and to work with the opportunities afforded by and constraints imposed by the course context. There is considerable scope for interpretation here - for example, what range of techniques fall within the scope of "simple queries"

A benefit of the context is that the students have completed a module immediately before this one which introduces computer systems development, including analysis and design using UML. INTDD starts from the point of view that a model of the data in a system has been devised, in the form of a UML class diagram, and that the database developer's role is to turn this conceptual model into a relational database. A more formal approach to data modelling, including ERM, is provided in a later module. A major constraint is the 6 week time frame for the module, including all assessment.

The actual content was chosen with the following ideas in mind:

  • students should gain from this module a working knowledge of the key aspects of developing and working with databases to a level which will provide a useful skillset even for those who will not study databases further
  • students should learn SQL from the start - it's possibly the single most useful skill they can have
  • students should learn principles, not about a single database product or toolset
  • students should learn to view a database as a component or tier of an information system

The content is organised in 6 sections, to be delivered roughly one per week

1. Databases and database design

What is a database?
Databases vs. Database Management Systems
Relational and other database systems
Databases and enterprise information systems
The language of relational databases – SQL
Popular relational database systems
Designing a database
The  data model
From data model to relational database

2. Creating a database

Designing the database schema
Representing Classes and Attributes
Data types
Additional constraints
Choosing the right fields
Implementing a table in SQL
Inserting data into a table
Primary keys
Representing relationships
Altering a table

3. Getting data out: database queries

Queries and use cases
The GCUTours database tables
Queries in Access
Project operations
Select operations
Date formats in queries

4. Improving the database design

Database normalisation
Problems with un-normalised data
Functional dependencies
Normalisation and normal forms
First normal form (or 1NF)
Second Normal Form (2NF)
Third normal form (3NF)
Summing up the first three normal forms
Higher normal forms
When to use normalisation

5. Doing more with queries

Improving query performance with indexes
Joining tables
Different kinds of join
Data definition queries
Insert queries
Update queries
Delete queries
Parameter queries

6. Building applications

Types of application
Master-detail forms
User interaction in forms
Connecting to a database

Materials and books
I don't require students to buy a particular book, particularly for a short module, althoughh I do make recommendations for background reading. I have made liberal use of the following excellent books in making up lecture notes and tutorials:

Beginning Database Design: From Novice to Professional  (Clare Churcher, Apress, ISBN 1-59059-769-9) - provides good coverage of much of the module content as well as background on using UML techniques for data modelling
Head First SQL (Lynn Beighley, O'Reilly, ISBN 0-596-52684-9) - there are some great learning activities in this book, some of which I have adapted for my tutorials.


This is the full module descriptor. This is one of many representations of the module which exist within the university. This diagram, which is based on an activity we did at a Disciplinary Commns meeting, summarises these.

Choice of database
Unlike programming, there is no issue about choice of langauge with databses at this level - we teach SQL. In principle, it is possible to use any database system as a platform for teaching SQL. There are practical issues associated with the choice of database system, fro example:

  • ease of deployment in labs and on students' own computers
  • ease of use of database management and querying tools
  • peculiarities in SQL support and syntax

Several options were considered, including mySQL, Oracle, SQL Server and others. In the end, Access won because it's on all the computers in the university, students can get it free, databases are contained in single, easily transportable files, you can create and execute SQL queries, and all the tools are provided within a single application. In making that decision, we have to live with some, non-standard syntax and data types, lack of SQL script support and the lack of a sense of working with a client-server environment. To counter this, it was emphasised throughout to students that they were learning about databases, not about Access, and the features of standard SQL and other databases were discussed. However, I will revisit this choice in future as I'm not completely sure that the benefits do outweigh the drawbacks.

Learning activities
The design and sequence of the learning activities for INTDD is constrained by the number of students and the timetable. Lectures are timetabled for all students together (about 120) in a large lecture theatre. Labs are in computer labs with a maximum of 20 spaces, and tutorials are in traditional classrooms. Lectures were on Monday and Friday - Friday was a two-hour slot, which is in excess of most people's concentration span for listening to me, so this was usually not fully used.

Lab activities were designed to give students opportunities fo pratice techniqies covered previously in lectures, while tutorials were based on tasks designed to highlight or provoke discussion of issues around those techniques. The short timescale effectively limited these to four weeks, as in the first week most students had only had an introductory one hour lecture., while the last week was used exclusively for assessment, which had to be completed within the teaching weeks. In the first week there was a lab introducing the 'nuts and bolts' of using Access, while the tutorial was a discussion of a data modeling scenario linking this module to the UML content of a previous module.

It wasn't possible in the time available to cover all major topics to the same extent in both labs and tutorials. As a result, for example, normalisation was covered in lecture and tutorial only, whlle join queries were covered in lecture and lab only..

Selected teaching materials:
lab and tutorial activities for lecture 2 (creating a database), showing the contrasting emphasis in these two types of learning activity
lab activity (lab 4) showing linkage to integrated case study and Java programming module

Teaching context
There are typically 100-120 students taking the module. Contact time is timetabled in a fairly traditional way, with lecture, lab and tutorial sessions. Timetabling is quite inflexible as within a 12 week semester two 6 week modules run consecutively and need to share the same schedule. Students are placed in small groups for labs and tutorials (computer labs are restricted to 20 students) - in this session there were 7 groups. Each module has a member of staff who is a module leader who has responsibility for the module. Timetabling does not readily accommodate team teaching. There is support in the department in terms of teaching assistants but this was limited in the case of this particular module. As a result, one member of staff delivered lectures, tutorials to 7 groups separately and supervised labs for 5 groups separately. Lectures were timetabled as 2-hour slots.

VLE/Web site
All module information and teaching/assessment materials are made available to students through the Blackboard Virtual Learning Environment (VLE). Some content is hosted on a separate website which is accessible through Blackboard or directly. Blackboard is also used for submission of coursework through its Digital Dropbox feature, and for some online assessment/evaluation.

Sequence and Timing
The module is delivered over six weeks, which is effectively five weeks as the final week is used exclusively for assessment. The aim of my teaching schedule is to deliver material in lectures which can be practiced and discussed in lab and tutorial exercises which follow on. There is one lab and one tutorial exercise in each of the first five weeks. The relationship between lecture content and labs/tutorials is illustrated in the diagram below. In practice, this aim is quite difficult to achieve, as that would mean that all lecture material would need to be covered before the labs in week 5. Also, as the cohort is split into small groups for labs and tutorials, then in any given week some groups will have their labs/tutorials before that week's lecture while some are after the lecture. As a result, the last two labs include material which students may not yehave set en in a lecture. However, students seem to cope with this with the support of the lab activity sheets and the lecture notes which are made available in advance.

sequence of activities

I recorded my thoughts each week during delivery in a weblog. The artefact here is a copy of the weblog posts.


Practical assignment
Most of the learning outcomes of the module are practical in nature, which is reflected in the way the module is assessed. The choice of assessment instruments is also influenced by the overal programme assessment strategy which suggests that first year modules in the forst semester should be assessed by coursework only.

The form of the main assessment is pretty straightforward - I intend that students completing this module should be able to create a database (which is something they are likely to need to do in project work later on), so the assignment is essentially "create a database". Looking in a bit more detail, the starting point of the task is a simple UML class diagram, from which the students have to:

  • design a relational database schema
  • create a database using appropriate fields, keys and constraints, using SQL
  • create test data and use it to test correct storage and constraints
  • create SQL queires to extract specified data from the database
  • create a form and report

The first step requires students to show an understanding of the relational model and the way in which it can be used to represent a conceptual model. This involves mapping associations, which may be one-to-one, one-to-many or many-to-many, to database tables. This is done as a written exericse in class, and contributes a proportion of the summative assessment mark. It is also a formative assessment as feedback is given before students go on to implement their database design as a working database. This avoids the likely situation where some students would start to build the database from a flawed design.

Students are given approximately two weeks to complete the assignment., in their own time and in supervised class time in week 6.. One problem with practical coursework assignments done out of class time is the possibility of collusion. This is mitigated to some extent by requiring students to create their own test data, which helps to ensure that submissions are individual, while giving some occasionally disturbing insights into the interests and thought processes!

Students are encouraged to participate in the Peerwise system during this module. This participation contributes part of the overall module mark.

With Peerwise, students develop multiple-choice questions with associated explanations and contribute them to PeerWise. These questions are then available to other students in the course and can be answered for revision purposes, critiqued and discussed, and rated for difficulty and quality. Access to Peerwise has been provided by the University of Auckland, New Zealand To gain full credit, students are required to do the following:

  • post 5 or more questions to the Peerwise system
  • answer 10 or more questions which have been posted by other students

Coursework specifications: part 1 (written exercise) and part 2 (assignment).

Formal evaluation
All module leaders are required to complete a Module Monitoring Form at the end of the academic year. This form requires the following information to be provided:

  • module statistics and student performance
  • commentary on the above
  • commentary on student feedback
  • external assessor feedback
  • commentart on e-learning
  • commentary on links with other modules
  • relevant staff development, KTP and research activities
  • module improvement plan
  • commentary on examples of good practice

These forms are considered by a relevant Subject Group within the department and collated to produce a subject group monitoring report.

Student feedback
Students are encouraged to complete a Module Evaluation Questionnaire for each module. There is also a Staff-Student Consultative Group (SSCG) which meets each semester and provides student feedback on issues through student representatives. The information, if any, provided by these is very general in nature.

More specific feedback from students was obtained within lab classes. At the end of each lab session students were asked to complete a reflection task, delivered through Blackboard. Each task consisted of three questions, either short answer or multiple choice, designed to elicit information aboutm, for example, about what students identified as the important aspects of their learning in that lab. The responses to these are useful in evaluating student attitudes to specific topics and activities and possible problem areas with their learning.

The (anonymous) responses and statistics from the lab reflections are presented in the following files:

Lab 1 reflection
Lab 2 reflection
Lab 3 reflection
Lab 4 reflection
Lab 5 reflection

There's quite a lot of information in here, which will be useful for the next delivery. For example, in lab 5 there was quite a bit of consistency in the answers to "which was the most difficult question", so I can look at those to see whether the teaching needs to change to help with these. One interesing point - students actually quite like solving problems by creating and running SQL queries - lab 3 (a set of query problems) was identified by 66% of students as the one they enjoyed the most.