Preliminaries - Database Design and Relational Theory - page 10

A glance at the figure is sufficient to show what's wrong with this design: It's redundant , in the sense that
every tuple for supplier S1 tells us S1 has status 20, every tuple for supplier S2 tells us S2 has status 30, and so on. 8
And design theory tells us that not designing the database in the obvious way will lead to such redundancy, and tells
us also (albeit implicitly) what the consequences of such redundancy will be. In other words, design theory is
largely about reducing redundancy, as we'll see. (As an aside, I remark that—partly for such reasons—the theory
has been described, perhaps a little unkindly, as a good source of bad examples .)
Now, if design theory really does just bolster up your intuition, then it might be (and indeed has been)
criticized on the grounds that it's really all just common sense anyway. By way of example, consider relvar STP
again. As I've said, that relvar is obviously badly designed; the redundancies are obvious, the consequences are
obvious too, and any competent human designer would “naturally” avoid such a design, even if that designer had no
explicit knowledge of design theory at all. But what does “naturally” mean here? What principles are being applied
by that human designer in opting for a more “natural” (and better) design?
The answer is: They're exactly the principles that design theory talks about (the principles of normalization,
for example). In other words, competent designers already have those principles in their brain, as it were, even if
they've never studied them formally and can't put a name to them or articulate them precisely. So yes, the
principles are common sense—but they're formalized common sense. (Common sense might be common, but it's
not always easy to say exactly what it is!) What design theory does is state in a precise way what certain aspects of
common sense consist of. In my opinion, that's the real achievement—or one of the real achievements, anyway—of
the theory: It formalizes certain commonsense principles, thereby opening the door to the possibility of
mechanizing those principles (that is, incorporating them into computerized design tools). Critics of the theory often
miss this point; they claim, quite rightly, that the ideas are mostly just common sense, but they don't seem to realize
it's a significant achievement to state what common sense means in a precise and formal way.
As a kind of postscript to the foregoing, I note that common sense might not always be that common anyway.
The following lightly edited extract from a paper by Robert R. Brown of Hughes Aircraft 9 illustrates the point. The
author begins by giving “a simplified real example”—his words—involving an employee file (with fields for
employee number, employee name, phone number, department number, and manager name) and a department file
(with fields for department number, department name, manager name, and manager's phone number), all with the
intuitively obvious meanings. Then he continues:
The actual database on which this example is based had many more files and fields and much more redundancy. When
the designer was asked his reasons for such a design, he cited performance and the difficulty of doing joins. Even though
the redundancy should be clear to you in my example, it was not that evident in the design documentation. In large
databases with many more files and fields, it is impossible to find the duplications without doing extensive information
analysis and without having extended discussions with the experts in the user organizations.
Incidentally, there's another quote I like a lot—in fact, I used it as an epigraph in SQL and Relational
Theory —that supports my contention that practitioners really do need to know the theoretical foundations of their
field. It's from Leonardo da Vinci (and is thus some 500 years old!), and it goes like this (I've added the boldface):
Those who are enamored of practice without theory are like a pilot who goes into a ship without rudder or compass and
never has any certainty where he is going. Practice should always be based upon a sound knowledge of theory.
8 You might notice another problem, too: The design can't properly represent suppliers like supplier S5 who currently supply no parts at all.
Such “update anomalies” are discussed in Chapter 3.
9 Robert R. Brown: “Database Systems in Engineering: Key Problems, and Potential Solutions,” in the proceedings of a database symposium held
in Sydney, Australia (November 15th-17th, 1984).