What would be your ideal first lecture in a databases course?

Question

As they say, you don't get a second chance to make a good first impression. Are you aware of any notes/slides appropriate for a first lecture in databases?

Answer 1

Similarities

For a first lesson, what you want to focus on are anchor points, i.e. how databases are something that's closely related to what students already know and understand.

The prime example here is Excel. We've all seen a data table at some point, e.g. your grades/report card from school are a data table, or your bank transaction history.
My SO is currently in the process of a career change in IT, and I suggested her to substitute "table" with "Excel file", and it really helps to understand the big (though certainly massively oversimplified) picture.

Understanding that, a database can easily be described as a folder of Excel files. This is again massively oversimplified, but enough for an introductory understanding of what a database's purpose is.

Note that you could also represent a database as a single Excel file with multiple sheets. However, for display purposes I prefer having my tables in separate windows, which is easier when working with separate Excel files. It's purely a visual decision.

---

A practical example

My favorite example, probably because it's what I was taught as a first example, is Blockbuster, i.e. a simple video renting service. It's an example that can be adapted to students' growing understanding of a database structure.

In a first version, you have a single table where each record represents a rental, with customer info (e.g. name), DVD info (e.g. movie title), and rental info (e.g. return date)

If a customer rents multiple videos at the same time, it quickly becomes cumbersome to have to repeat their personal information, which leads to version 2: separating the customer information into its own table, and referencing the specific customer (by ID) in the rentals table.

The same logic then also leads you to separating the video tapes into a table of their own, analogous to the customer example.

This three table structure is fairly straightforward, easy to develop from what was initially a single table, and it teaches most core concepts for database modeling: tables, columns, records, primary keys, foreign keys, and the basics of data normalization.

---

Database design is a theory, not a technology

It's interesting to note that you could, time permitting, demonstrate the above implementation of a video rental database using a literal folder of Excel files. This helps separate the distinct skills of designing a database (i.e. deciding the structure) and implementing a particular database system (e.g. SQL Server, Oracle, ...)

I strongly suggest separating the two, as the complexity of learning a particular system often distracts from students learning about and appreciating the theoretical database design skill.

Answer 2

First, be clear of the learning objectives. "Databases" could mean many things: 1 how to use a DB, eg retailer or wholesale parts supplier; 2 how to program (in x-language) using an RDBMS as backing-store; 3 DBA training; 4 and quite likely more... NB I am assuming RDBMS, and thus SQL (there are others!)

I major in vocational training with occasional forays into the tertiary world. Thus, the first-contact is often imbued with (complexity) anxiety and possibly motivational issues (I'm only here 'cos the boss said!). Practical "mastery" is very much the name of the game - extensive theory is only most useful to DBAs and similar!

1: Unless the client dictates the tool-set, I most usually employ MySQL. It is available for many PC OpSys and relatively easy to install on an institution's network, plus free for trainees to download to their own systems. There are other choices and this is not an advert! Another factor when choosing tools is whether you wish to use something 'more' than SQL, particularly for DDL activity and ERDs. MySQL-Workbench has proven manageable, even at the user-level. Oracle offers name-brand tools which do this, and more. See also Postgres, but remember that MS-SQL may require paid-licenses and has a somewhat different approach and syntax-requirements. Over the years, (cough) decades, I've discarded 'toys'. The tool MUST reflect the trainees' (eventual) work environment (NB such does NOT apply at high schools, where concepts>tools)!

2: A sample DB is another important consideration. The data should familiar to the trainees, as well as it offering a consistent schema applicable throughout (at least) this particular course (until 'schema' becomes the learning-objective). NB without limiting the trainees from either making or finding/downloading their own! However the 'Blockbuster' example (eg the older versions of Sakila), whilst familiar to us, may not suit today's tertiary cohorts (who download movies rather than visiting a rental bricks-and-mortar store and may have never even heard of that company!).

* Putting the two (immediately-above) considerations together, may invite us to consider some of the on-line/cloud offerings available, should one be compatible with your technical environment (and learning objectives); because one inherits the advantages of a 'package-deal' plus the technical challenges of installation and configuration (almost) disappear! (I have no such experience, and will welcome contributions)

3: In the realm of presentation-aids, I've run-the-gamut. The issue of conveying information is complicated by extensive multi-table diagrams and multi-column tables requiring a high-resolution display - discounting many 'projectors'. Accordingly, these days I prefer to use a central projector for any notes, reminders, task-assignments (often coming out of an LMS), whilst slaving the students' machines to my demo-computer's screen. The multi-presentational advantages are paralleled by learners' physical movements, and thus feedback...

Cognitive Psychology: The cognitive theory [@Flater] is indisputable. However (and with any due apologies) herewith a vehement dispute to the use of spreadsheets for 'prior knowledge' (for exactly the same cog-psy reason!). The philosophies and objectives of DBs are radically-different from those of spreadsheets. In fact, I specifically warn trainees to put such analogies out of their minds. It may 'work' at first, but... many learning-difficulties later arise from mental-map dissonance caused by over-applying such "previous knowledge", instead of properly appreciating the relational paradigm. Because there is a code-then-run sequence of tasks (cf MS-Excel's type a formula, press Enter, see the answer), it seems that, in-practice, trainees rapidly appreciate even basic differences and are thus uninclined towards the analogy. Remember that even identifying a "cell" is different: in spreadsheets it is a column-letter and row-number combination, which is most dissimilar to SQL's select+projection algebra. (with apologies to MS-SQL users who may take advantage of the record-number facility, which is indeed a row-number even as it is not within international-standard SQL)

The basic presentation (and mental-model) of a database is exactly how we see the data presented by a command-line SQL query or a workbench tool - namely a "table". Few, of any category of trainee, are ever unhappy with this. If the sample-DB includes something like a list of Person, Product, Customer, etc, then the analogy and mental 'anchor-points' are readily transferable - and readily appreciated (and accumulated) in the learning mind.

Approach: Typically, my first class is either from start-of-day until tea-break, eg 0830~1000, or from then until lunch-break, eg 1025~1200. I have exactly one teaching-objective: that during that first break trainees will think, and hopefully discuss amongst themselves how much "easier" this is than they thought (usually with some sense of 'relief', cf anxiety)!

Accordingly, I 'slave' all student devices to mine, open the chosen tool, and demonstrate how to grab a single table and show it unadorned and unfiltered. Immediately I use terminology without first defining it, eg "table", "row", "column". Note that this is the reverse of the old, traditional, lecture approach of requiring trainees to absorb 'the lingo' first! I may not even display definitions of these terms, because they are readily apparent (make it 'homework' to read such guff, if desired...) Next, we can move to selection and projection (still with the single table). To use the traditional lesson-plan aphorism, 'by the end of this session', trainees appreciate being able to limit which data-items (columns) are displayed/avoid 'overload' and 'distraction'; and being able to limit the 'great, long list' to a useful and usable sub-set, eg all the customers in this town, products in this range, ...

As mentioned, "mastery": Accordingly, at each of the three stages, I stop demonstrating and invite the trainees to have-a-go (on their own devices). They are given an assignment which is almost word-for-word the previous demonstration, but either using a different table/fields or even the same table but with different selection/projection criteria (depends upon topic/sample dB, etc).

By then the time has gone, and it's an opportunity to listen to the break-chatter. Upon resuming, we have a solid base to either (depending upon your preferences/objectives) jump into some of the theory, or to extend the practical demonstration-led 'discovery' into such ideas as joining multiple-tables...

Conclusion: Hopefully this contribution is seen as an alternative approach to those of previous responses to your question; whilst at the same time not differing too widely from your own in terms of topical-coverage (possible differences relating to slightly different course/final objectives).

Regards =dn

NB there is NO intent of malice towards @Flater. Learning-success comes from the trainer/mento successfully 'marrying' all of the learning factors into a working and workable 'whole'. This includes the preferences and personalities involved. Whatever works for you/him/her/them/me/others, ie enables confident and capable 'graduates', is the right thing to do!