Databases Reference
In-Depth Information
And one more (this time with a “helpful” response):
> It's not clear to me what “normalized” means. Can you be specific about what normalization rules you are
> referring to? In what way is my schema not normalized?
Normalization: The process of replacing duplicate things with a reference to the original thing.
For example, given “john is-a person” and “john obeys army,” one observes that the “john” in the second sentence is a
duplicate of “john” in the first sentence. Using the means provided by your system, the second sentence should be stored
as “ - >john obeys army.”
A NOTE ON TERMINOLOGY
As I'm sure you noticed, the quotes in the previous section were expressed for the most part in the familiar “user
friendly” terminology of tables, rows, and columns (or fields). In this topic, by contrast, I'll tend to favor the more
formal terms relation , tuple (usually pronounced to rhyme with couple ), and attribute . I apologize if this decision
on my part makes the text a little harder to follow, but I do have my reasons. As I said in SQL and Relational
Theory: 1
I'm generally sympathetic to the idea of using more user friendly terms, if they can help make the ideas more palatable.
In the case at hand, however, it seems to me that, regrettably, they don't make the ideas more palatable; instead, they
distort them, and in fact do the cause of genuine understanding a grave disservice. The truth is, a relation is not a table, a
tuple is not a row, and an attribute is not a column. And while it might be acceptable to pretend otherwise in informal
contexts—indeed, I often do exactly that myself—I would argue that it's acceptable only if we all understand that the
more user friendly terms are just an approximation to the truth and fail overall to capture the essence of what's really
going on. To put it another way, if you do understand the true state of affairs, then judicious use of the user friendly
terms can be a good idea; but in order to learn and appreciate that true state of affairs in the first place, you really do need
to come to grips with the formal terms.
To the foregoing, let me add that (as I said in the preface) I do assume you know exactly what relations , attributes ,
and tuples are!—though in fact formal definitions of these constructs can be found in Chapter 5.
There's another terminological matter I need to get out of the way, too. The relational model is, of course, a
data model. Unfortunately, however, this latter term has two quite distinct meanings in the database world. 2 The
first and more fundamental one is this:
Definition: A data model (first sense) is an abstract, self-contained, logical definition of the data structures,
data operators, and so forth, that together make up the abstract machine with which users interact.
This is the meaning we have in mind when we talk about the relational model in particular: The data structures in
the relational model are relations, of course, and the data operators are the relational operators projection, join, and
1 I remind you from the preface that throughout this topic I use SQL and Relational Theory as an abbreviated form of reference to my topic SQL
and Relational Theory: How to Write Accurate SQL Code (2nd edition, O'Reilly, 2012).
2 This observation is undeniably correct. However, one reviewer wanted me to add that the two meanings can be thought of as essentially the
same concept at different levels of abstraction.
Search WWH ::




Custom Search