Data modeling (was: BCNF)

Jerry Stuckle:

>BTW - when I'm designing a database, I always start with sample data
>and what it means. Actual building tables doesn't start until much
>later.

Exactly.

When I need to design a database (with the intention of creating an application that is going to support business processes), coding tables and fields is the easy part.
The fun part consists of sessions with main end users, who happen to more-or-less know their processes, data and requirements. Not seldomly, especially when they have never done this before and have no idea of entities and relationships, I start off with teaching them the basics of ER modeling:
- boxes represent "things you talk about and have properties" (like a customer with name, address and Twitter account, or an article with description, color and size)
- lines represent "their relationship"
- "1" and "n" represent "how many of one 'box' relate to how many of the other 'box'
Interestingly, many of them find it an eye opener to look at their data that way. Once they get a feel for how that works, the more complicated n:m relationship is coming into play.

Only at that point, when they feel somewhat comfortable with this (usually takes an hour or two of playing and practicing with HalloWorld-like example cases), the sessions go into their real world cases.
This is what I consider not only the fun part, but also the Hard Work of 'database design'. It is very satisfying to see a result (ER model of a relevant part of their business) that every participant not only agrees with, but that can even be explained and presented by these main end users themselves.

Surely, when it comes to actually coding the tables, plenty of minor detail questions still arise. But these can now be discussed easily, because the users _understand_ those questions and discussions.

-- 
Erick