Everything you always wanted to know…

An early vision of a connected database

Otlet can be considered a pioneer in the field of databases. He aimed to gather together all the world's knowledge and classify it.

The 'Mundaneum' is considered a milestone in the history of databases and also as a little-known antecedent to the Internet. Otlet's epic vision deserves to be better known. Introduce students to Paul Otlet's amazing utopian vision for his Mundaneum.

1. Allow students 10 minutes for intense research on the topic. Ask them to find out who Paul Otlet was, when he lived and his vision for his Mundaneum. It will be expected that students will gravitate immediately to Wikipedia. Allow this for the first few minutes. Then emphasise that a goal of their limited research time is to discover the most useful site for explaining and demonstrating Otlet’s Mundaneum.
2. Conduct a class discussion based on their research.
   • Ask students if any had ever heard of the Mundaneum. Suggest they survey adults over the next day to find anyone who has heard of it.
   • Discuss Otlet’s attempt to collect and store different types of media. Which types did he consider?
3. Provide the following link to the Mundaneum's own site (unless it has been discovered by students already) and allow time for discussion – Mapping Knowledge 1910–1944.

Note: Parts of the Mundaneum have been preserved as a museum in a converted department store in Mons in Belgium.

Databases are easily the most pervasive and widely used of computer-based applications. They touch our lives each day, yet few know how to create one.

In this lesson, students design, build and evaluate their own database and perform queries and build reports based on it.

The first prerequisite in any discussion of the social implications of databases is an understanding of how one is designed and used and what a database can do. The second is to appreciate the often unforeseen and unintended results of the aggregation of databases.

1. Ask students:

   What would be the best method for you to use if you wished to gather data on everyone in this class? Try using the pose, pause, pounce, bounce method here to ensure maximum focus and participation.

2. Discuss various techniques with the class.
   • Explain that techniques can be classified in categories: qualitative methods and quantitative methods.
   • Asking open-ended questions using an interview can be considered qualitative, whereas asking for responses using yes or no answers are closed questions and is a quantitative method.
3. Identify strengths and weaknesses of various methods for collecting data. Consider:
   • online surveys
   • face-to-face interviews
   • phone interviews
   • observation
   • blog entries in response to a posting
   • phone logs
   • browser history
   • online webcam systems.

   It may be useful for learners to create a graphic organiser to compare and contrast some of the various methods for collecting data.

4. Discuss strategies to ensure the privacy and security of survey data, for example, using numbers rather than names as identifiers; password protecting files to reduce risks of modifying data; and using CAPTCHA™ to confirm human responses.
5. While participating in this whole-class discussion, encourage students to develop a set of questions they would like to ask members of the class.
   • Issues of privacy should arise and should be addressed as they do.
   • Consideration of how qualitative responses should be translated into data should be addressed.
   • Discussion of interface design and user needs should be discussed.

It is desirable that students are proficient at designing and populating a relational database. However, you should ensure all students are at least proficient at creating a flat file database.

1. Discuss with students the design requirements for the following task:

   Design a database which will enable the members of your class to enter school and personal particulars.

2. Ask students: What would be the purpose of such a database? How might it be misused by:
   • a student
   • a teacher
   • an adult visiting the computer room after class
   • an unauthorised person online.
3. Ask students:
   • What tables might we need?
   • What tables might be linked (assuming a relational database)? For example, separate subject table with HT name; staffroom location; subjects offered; separate sport table with training coach and competition details.
   • Which school and personal particulars should be chosen for fields?
   • Are any of these inappropriate? Suggest examples of other fields some people might consider inappropriate.
   • Which fields should be optional?
   • Which fields should be compulsory?
   • What will be the data types of each field?
   • Where should fields be placed?
   • What should the tab order of fields?
   • What expected searches are likely to be required?
   • What types of reports are likely to be required?
   • Which fields will require sorts performed on them?
   • Discuss possible design and layout approaches.
   • Should a separate screen be designed for columnar display?

   It may be effective to model this thinking out loud with learners so they can share and make visible their thinking, creating a database as you go, exploring the pitfalls and possibilities and ensuring an agreed approach.

4. Ask students to consider what design features should be used to make the database interface as effective as possible.
   • The predictable error here is to create an overly ornate design with excessive use of fonts, styles, poor field placement and field tab order.
   • Demonstrate examples of superior online database input interfaces.
5. Explain that their database will be peer evaluated based on two criteria: technical and design. This feedback will form the basis for improvements in functionality, accessibility, usability and aesthetics. Discuss with students:
   • What criteria make a database technically excellent?
   • What criteria make a database excellent in design and user-friendliness?

6. Ask students to design a database to satisfy requirements emerging from the class discussion (with teacher assistance).

   The main table for the database must include the following information:

   • gender
   • phone number
   • subjects studied at school
   • year of enrolment at present school
   • country of origin
   • favourite subject
   • favourite music
   • favourite sport
   • band/musician
   • hobby
   • sporting interests
   • career interests
   • serial number automatically to each entry (the student ID number).

   Students should:

   • devise at least one table to relate to the main one (eg separate subject table with HT name, staffroom location, subjects offered; separate sport table with training, coach and comp details)
   • anticipate later sorting requirements
   • take advantage of and include pre-defined lists
   • require some fields to have unique entries
   • require that some fields never be left empty
   • require that one field will give the student ID as a serial number with an increment of 1. If possible, start at '9****', where **** indicates the current year.

   Peer feedback

7. After designs have been completed, students move from computer to computer, entering their details into each database.
8. Ask students to evaluate each database using the worksheet strips from the Database evaluation sheet. They record a score from 1 to 5 for technical and 1 to 5 for design. Print enough for each student to evaluate every other student's database.
   • The evaluation strip includes the workstation ID and allows students to record a strength and to suggest one improvement.
   • Emphasise students should be providing feedback that is specific and helpful and that is hard on content but not on the person who created it. Read more about peer critique in this formative assessment strategy. This will lead to authentic feedback. It also means, when reviewing the feedback, the student will see if there is a common theme emerging from repeated comments.
   • The strips are then placed it in a central ballot box.
9. When the students have completed their evaluations, the ballot box is emptied and the slips are collated and allocated to the appropriate workstations.
   • Each student averages their score on their slips to produce a score out of 10. This may take up to 60 minutes.
   • They circle the suggested improvements they plan to incorporate into the next iteration of their database.
10. Hold a class discussion after finishing to determine which were the features which made certain student databases easier to use.
11. Ask students to improve their databases in response to the suggestions from peer feedback.

Show students how to query databases and produce reports.

Queries are far more useful than simple searches on a table. A search is able to help you find the name of a person, but a query could find every person who likes maths, is female and plays soccer. A well-designed query can deliver information you might not be able to find just by looking through your tables.

1. Ask students to produce queries and reports using their own populated databases to answer the following:

   Report: 'Subjects'

   • Which subject was the most popular?
   • List the favourite subjects with the total times each was chosen.

   Report: 'Careers'

   • What was the most popular female career choice and most popular male career choice?

   Report: 'Custom'

   • A report designed by the student
2. Place all class names in a box and have each student draw out the name of another student in the class. They swap if they get their own!
   • They now go to that student's database and perform the same queries.
3. Ask students to write a brief report noting the following:
   1. Similarities and differences between results in two databases
   2. Strengths and weaknesses of the (now hopefully revised and improved) interfaces of their database and that of their peer.