Abstract
An early version of this appendix appeared as a foreword to the book Oracle SQL Developer Data Modeler for Database Design Mastery, by Heli Helskyaho (Oracle Press, 2015), and a revised and considerably expanded version of that foreword subsequently appeared on the O’Reilly website (http://www.oreilly.com/data/free/what-is-database-design-anyway.csp). But it struck me that it would serve very well in the present book as a kind of broad overview of what database design is all about. Since it’s much less formal in tone than most of this book, however, I decided to relegate it to an appendix. My thanks to Heli, Oracle Press, and O’Reilly for allowing me to republish the material here in its present form.
Note: There’s naturally some overlap between what follows and material in the body of the book, but I’ve done my best to keep that overlap to a minimum.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
I’ve replaced the links in the original Wikipedia entry by italicized words and phrases, as in (e.g.) data model and database. Otherwise the extracts are quoted verbatim.
- 2.
Since as I’ve said this appendix is deliberately fairly informal, I’ve decided to stay with the SQL terminology of tables, rows, and columns throughout in place of the relational terminology of relations, tuples, and attributes.
- 3.
Given the context, it’s reasonable to assume that (a) by storage, the writer here means physical storage specifically, and (b) by tables, he or she means base tables specifically. Whether these terms ought to have these meanings is a very different matter!
- 4.
I say this knowing full well that today’s SQL products do provide a variety of options for hashing, partitioning, indexing, clustering, and otherwise organizing the data as represented in physical storage. Despite this state of affairs, I still consider the mapping from base tables to physical storage in those products to be fairly direct. For that very reason, in fact, elsewhere I’ve labeled those products “direct image systems.” For further explanation of this term, and much further discussion of such matters, see my book Go Faster! The TransRelationalTMApproach to DBMS Implementation (Ventus, 2002, 2011; available as a free download from http://bookboon.com).
- 5.
But see the book mentioned in footnote 4, Go Faster! The TransRelationalTMApproach to DBMS Implementation, for a description of a system in which that automatic derivation does in fact occur.
- 6.
Of course, the body of this book is that place!
- 7.
A more detailed explanation can be found in Chapter 2.
- 8.
I note in passing that some writers regard table predicates as just a special case of business rules—there’s no consensus on the point. But there’s certainly much more to business rules in general than just the table predicates as such.
- 9.
Actually I’m not sure that money values in general should be represented (at least as far as the user is concerned) in any particular currency—rather, I think it should be possible for the user to deal with such values in whatever currency he or she chooses (see Chapter 16, footnote 3). On the other hand, given that currency conversion rates can and do fluctuate, the same value in one currency might correspond to different values in another at different times. More study is required.
- 10.
It would be, rather, an inconsistency—in the normal English sense of that word—between the data in the database, on the one hand, and the pertinent constraint, on the other.
- 11.
By redundancy here I mean, more specifically, redundancy that’s understood by the system to be redundancy.
- 12.
As you can see, the constraint in question is defined by means of a CREATE ASSERTION statement in SQL. For some reason, SQL sometimes (but not always!) calls constraints assertions. As for that AS POINTLESS specification, it’s pointless, but it’s required by the rules of the SQL standard. PS: It might help to point out that “all employees in the same department earn the same salary” means that table EMP is subject to a functional dependency (FD) from department number to salary.
- 13.
In fact, you can prove that you can prove that 1 = 0! See Appendix B.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2019 C. J. Date
About this chapter
Cite this chapter
Date, C.J. (2019). What Is Database Design, Anyway?. In: Database Design and Relational Theory. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-5540-7_18
Download citation
DOI: https://doi.org/10.1007/978-1-4842-5540-7_18
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