Databases Reference
In-Depth Information
relational model, at least in part. In other words, it would be inconsistent to agree with the relational model in
general but not to agree with the design theory that's based on it.)
The overall objective of logical design is to achieve a design that's (a) hardware independent, for obvious
reasons; (b) operating system and DBMS independent, again for obvious reasons; and finally, and perhaps a little
controversially, (c) application independent (in other words, we're concerned primarily with what the data is, rather
than with how it's going to be used). Application independence in this sense is desirable for the very good reason
that it's normally—perhaps always—the case that not all uses to which the data will be put are known at design
time; thus, we want a design that'll be robust, in the sense that it won't be invalidated by the advent of application
requirements that weren't foreseen at the time of the original design. Observe that one important consequence of
this state of affairs is that we aren't (or at least shouldn't be) interested in making design compromises for physical
performance reasons. Design theory should never be driven by performance considerations.
Back to design theory as such. As we'll see, that theory includes a number of formal theorems, theorems that
provide practical guidelines for designers to follow. So if you're a designer, you need to be familiar with those
theorems. Let me quickly add that I don't mean you have to know how to prove those theorems (though in fact the
proofs are often quite simple); what I mean is, you have to know what the theorems say—i.e., you have to know the
results—and you have to be prepared to apply those results. That's the nice thing about theorems: Once
somebody's proved them, their results become available for anybody to use whenever they need to.
Now, it's sometimes claimed, not entirely unreasonably, that all design theory really does is bolster up your
intuition . What do I mean by this remark? Well, consider the suppliers-and-parts database. The obvious design for
that database is the one illustrated in Fig. 1.1; I mean, it's “obvious” that three relvars are necessary, that attribute
STATUS belongs in relvar S, that attribute COLOR belongs in relvar P, that attribute QTY belongs in relvar SP, and
so on. But why exactly are these things obvious? Well, suppose we try a different design; suppose we move the
STATUS attribute out of relvar S, for example, and into relvar SP (intuitively the wrong place for it, since status is a
property of suppliers, not shipments). Fig. 1.2 below shows a sample value for this revised shipments relvar, which
I'll call STP to avoid confusion: 7
│ S1 │ 20 │ P1 │ 300 │
│ S1 │ 20 │ P2 │ 200 │
│ S1 │ 20 │ P3 │ 400 │
│ S1 │ 20 │ P4 │ 200 │
│ S1 │ 20 │ P5 │ 100 │
│ S1 │ 20 │ P6 │ 100 │
│ S2 │ 30 │ P1 │ 300 │
│ S2 │ 30 │ P2 │ 400 │
│ S3 │ 30 │ P2 │ 200 │
│ S4 │ 20 │ P2 │ 200 │
│ S4 │ 20 │ P4 │ 300 │
│ S4 │ 20 │ P5 │ 400 │
Fig. 1.2: Relvar STP—sample value
7 For obvious reasons I use T, not S, as an abbreviation for STATUS, here and throughout this topic.
Search WWH ::

Custom Search