Databases Reference
In-Depth Information
Chapter 1
P r e l i m i n a r i e s
(On being asked what jazz is:)
Man, if you gotta ask, you'll never know
—Louis Armstrong (attrib.)
This topic has as subtitle
Normal Forms and All That Jazz
. Clearly some explanation is needed! First of all, of
course, I'm talking about design theory, and everybody knows normal forms are a major component of that theory;
hence the first part of my subtitle. But there's more to the theory than just normal forms, and that fact accounts for
that subtitle's second part. Third, it's unfortunately the case that—from the practitioner's point of view, at any
rate—design theory is riddled with terms and concepts that seem to be difficult to understand and don't seem to have
much to do with design as actually done in practice. That's why I framed the latter part of my subtitle in colloquial
(not to say slangy) terms; I wanted to convey the idea, or impression, that although we'd necessarily be dealing with
“difficult” material on occasion, the treatment of that material would be as undaunting and unintimidating as I could
make it. But whether I've succeeded in that aim is for you to judge, of course.
I'd also like to say a little more on the question of whether design theory has anything to do with design as
done in practice. Let me be clear: Nobody could, or should, claim that designing databases is easy. But a sound
knowledge of theory can only help. In fact, if you want to do design properly—if you want to build databases that
are as robust, flexible, and accurate as they're supposed to be—then you simply have to come to grips with design
theory. There's just no alternative: at least, not if you want to claim to be a professional. Design theory is the
scientific foundation for database design, just as the relational model is the scientific foundation for database
technology in general. And just as anyone professionally involved in database technology in general needs to be
familiar with the relational model, so anyone involved in database design in particular needs to be familiar with
design theory. Proper design is so important! After all, the database lies at the heart of so much of what we do in
the computing world; so if it's badly designed, the negative impacts can be extraordinarily widespread.
SOME QUOTES FROM THE LITERATURE
Since we're going to be talking quite a lot about normal forms, I thought it might be—well, not enlightening,
perhaps, but entertaining (?)—to begin with a few quotes from the literature. The starting point for the whole
concept of normal forms is, of course,
first
normal form (1NF), and so an obvious question is:
Do you know what
1NF is?
As the following quotes demonstrate (sources omitted to protect the guilty), a lot of people don't:
To achieve first normal form, each field in a table must convey unique information.
An entity is said to be in the first normal form (1NF) when all attributes are single valued.
A relation is in 1NF if and only if all underlying domains contain atomic values only.
If there are no repeating groups of attributes, then [the table] is in 1NF.
