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

Content
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

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.

Artefact

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..

Artefact
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.

Artefact
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!

Peerwise
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

Artefact
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.

Artefact:
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.