Well, here we go again.  I am making my final preparations again for my “How to Design a Relational Database” pre-conference seminar coming up at PASS. If you want to know what the “official” abstract is, you can find it here and if you are already convinced and have credit card in hand, click here and register before the price goes up more. If you have already registered but not for my (or any other) pre-con, you can always add on the precon!

So you can read the abstract, but what to expect? First off, expect to not sit in one spot while I drone on and on for 7 hours of lecture or code samples (not that I couldn’t go 7 hours straight just lecturing, and it would be a little bit easier to plan, I assure you). I plan to limit lecture to 3 hours in four sections:

Section 1: Introduction with a bit of history

We start with just enough introduction to the materials, the stuff you need to do *before* you design, and introduction to the history of the craft to make sure we are all on the same page.

Section 2: Modeling and structures

Next I will cover the fundamental building blocks of relational databases, like tables, columns, keys, etc; and how to create a data model of the constructs.  This is by far the largest part of the lecture, and by the end we should all be on the same page as to what goes into the database, if not exactly “how” the final product should look.

We will stop at this point, and I will  get out my modeling camera (that sounded a LOT more glamorous than it will turn out to be) and we will do some modeling on paper, eliciting you (assuming you have gotten out someone’s checkbook and paid the entrance fee AND actually shown up 🙂 to provide the parts of the database, and we will all decide what should go into the model.

This initial model will be VERY simple, but it will help me to decide how to proceed with the rest of the day’s exercises (based on the class size, acoustics, etc.) Every exercise can be done in teams or as a class…

Section 3: Model Standardization (Normalization)

Next up, we will talk about the kinds of things you need to do to the model to prepare the model to be implementable by truly analyzing the structures to see if they make “sense” within the confines of the relational model. It is always interesting to me that most models are somewhat normalized, but people think that normalizing makes things slower. And the misconceptions about the higher normal forms make even less sense…

Once we are done, we will start the exercises. The first exercise is planned as a full class exercise, where I will man the data model (first on paper, then in a modeling tool), and elicit input from the class, in a manner that make sure everyone gets a say.

Then we will certainly break up into small teams and build a final model on paper, which I will bring up to the projector and we will discuss the different solutions.

Section 4: Physical Modeling Overview

Assuming we still have time, we will take the last 40 minute and cover turning the model into a “real” database. Data types, domain implementations, constraints, testing, etc will be covered.

Due to the limitations of the 7 hour format, and a *strong* preference of previous classes towards actually doing some design, there are topics we won’t cover. But honestly, if you can get the basic design correct and make the model
look like what the final model needs to, the rest is kind of gravy.

What I really love about doing all of the designs is that we really get the flavor of a real design meeting. A few differing opinions, a few ideas I hadn’t planned for, and a few argumentative types who really want their own way. But none of the arguments so far have gotten out of hand, and they have all been very much like the typical data modeling meeting.

So after reading this, if you are still confused if you are in the target demographic for my pre-con, I will present on my twitter feed with a hashtag of #drsql_precon_demo what I feel to be the target audience. Some of them will be silly, and some will be serious, but if you all show up we are going to have ourselves one heck of a good time.