Relational Theory for Computer Professionals

Chapter 9. Database Design

I don’t do design, normally

—Anon.: Where Bugs Go

As noted in Chapter 7, Codd’s introduction of the relational model paved the way for research into numerous aspects of database management. One such aspect was, and still is, database design; in fact, design theory is now an extremely rich field, with an extensive literature of its own. That theory concerns itself with questions such as the following: What exactly is it that constitutes, or characterizes, a “good” database design? And how can such a “good” design be achieved? Of course, we can only scratch the surface of such matters here; but, just as with transactions (the subject of the previous chapter), a certain degree of familiarity with database design—or database design theory, rather—is essential to a basic understanding of what database technology in general is all about.

So design theory is certainly part of relational theory in general; however, it isn’t part of the relational model as such. Rather, it’s a separate theory that builds on top of that model. In fact, the relational model as such doesn’t care how well—or how badly!—the database is designed (neither does Tutorial D, a fortiori, and the same goes for SQL): So long as the database is at least relational, meaning it abides by The Information Principle, then all of the concepts of the relational model do still apply, and in particular all of the operators of the relational algebra do still work. Thus, if the database is badly designed, ...