Abstract
This book has as its subtitle Normal Forms and All That Jazz. Clearly some explanation is needed! First of all, of course, I’m talking about design theory—database design theory, that is—and everybody knows that normal forms are a major component of that theory; hence the first part of the subtitle. But there’s more to that 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 seems to be riddled with terms and concepts that are hard 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 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.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsNotes
- 1.
At the same time it’s not as easy as you might think to say exactly what it is! See further discussion in Chapter 4.
- 2.
I remind you from the preface that throughout this book I use SQL and Relational Theory as an abbreviated form of reference to my book SQL and Relational Theory: How to Write Accurate SQL Code (3rd edition, O’Reilly, 2015).
- 3.
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. I hope that helps!
- 4.
For reasons that might or might not become clear later, the values shown in Fig. 1.1 differ in two small respects from those in other books of mine: First, the status for supplier S2 is shown as 30 instead of 10; second, the city for part P3 is shown as Paris instead of Oslo.
- 5.
If you don’t know what a relvar is, for now you can just take it to be a table in the usual database sense. See Chapter 2 for further explanation.
- 6.
This definition is deliberately a little simplified (though it’s good enough for present purposes). A better one can be found in Chapter 3, also in SQL and Relational Theory.
- 7.
Be aware, however, that other writers (a) use those terms logical design and physical design to mean something else and (b) use other terms to mean what I mean by those terms. Caveat lector.
- 8.
For obvious reasons, throughout this book I use T, not S, as an abbreviation for STATUS.
- 9.
You might notice another problem, too: The design can’t properly represent suppliers like supplier S5 who currently supply no parts at all. This problem and others like it are discussed in Chapter 3.
- 10.
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).
- 11.
However, I will at least give precise definitions of those familiar concepts for reasons of completeness. Since I’m sure they really are familiar, however, I’ll take the liberty of appealing to them from time to time even before we get to those definitions.
- 12.
The quote—which I’ve edited somewhat here (the italics are mine)—is taken from Codd’s paper “Extending the Database Relational Model to Capture More Meaning,” ACM Transactions on Database Systems 4, No. 4 (1979). E. F. (“Ted”) Codd was, of course, the inventor of the relational model. What’s more, he was also the person who first defined the concept of normalization in general, as well as the first three normal forms (1NF, 2NF, 3NF) in particular.
- 13.
The quote is from the preface to The Bertrand Russell Dictionary of Mind, Matter and Morals (ed., Lester E. Denonn; Citadel Press, 1993). I’ve edited it just slightly here.
- 14.
Actually, “the objects the DBMS has to deal with” are never relations in SQL!—except in the very special case in which the object in question is an SQL table with (a) just one column (and that column is properly named), (b) no duplicate rows, and (c) no nulls. Moreover, to comply with the prescriptions of the relational model, they should also (d) contain no pointers (see the answer to Exercise 2.2h in Chapter 2).
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2019 C. J. Date
About this chapter
Cite this chapter
Date, C.J. (2019). Preliminaries. In: Database Design and Relational Theory. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-5540-7_1
Download citation
DOI: https://doi.org/10.1007/978-1-4842-5540-7_1
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-5539-1
Online ISBN: 978-1-4842-5540-7
eBook Packages: Professional and Applied ComputingProfessional and Applied Computing (R0)Apress Access Books