C.J. Date > Quotes

“An Introduction to Database Systems”
― C.J. Date

“■ Types are (sets of) things we can talk about.
■ Relations are (sets of) things we say about the things we can talk about.

(There is a nice analogy here that might help you appreciate and remember these important points: Types are to relations as nouns are to sentences.) Thus, in the example, the things we can talk about are employee numbers, names, department numbers, and money values, and the things we say are true utterances of the form “The employee with the specified employee number has the specified name, works in the specified department, and earns the specified salary.”

It follows from all of the foregoing that:
1. Types and relations are both necessary (without types, we have nothing to talk about; without relations, we cannot say anything).
2. Types and relations are sufficient, as well as necessary—i.e., we do not need anything else, logically speaking.
3. Types and relations are not the same thing. It is an unfortunate fact that certain commercial products—not relational ones, by definition!—are confused over this very point.”
― C.J. Date, An Introduction to Database Systems

“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.”
― C.J. Date, Database Design and Relational Theory: Normal Forms and All That Jazz

“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.”
― C.J. Date, Database Design and Relational Theory: Normal Forms and All That Jazz

“...since there is so much confusion surrounding it in the industry. You will often hear claims to the effect that relational attributes can only be of very simple types (numbers, strings, and so forth). The truth is, however, that there is absolutely nothing in the relational model to support such claims. ...in fact, types can be as simple or as complex as we like, and so we can have attributes whose values are numbers, or strings, or dates, or times, or audio recordings, or maps, or video recordings, or geometric points (etc.).

The foregoing message is so important‒and so widely misunderstood‒that we state it again in different terms:

The question of what data types are supported is orthogonal to the question of support for the relational model.”
― C.J. Date, An Introduction to Database Systems

“...SQL is very far from being the “perfect” relational language—it suffers from numerous sins of both omission and commission. ...the overriding issue is simply that SQL fails in all too many ways to support the relational model properly. As a consequence, it is not at all clear that today's SQL products really deserve to be called “relational” at all! Indeed, as far as this writer is aware, there is no product on the market today that supports the relational model in its entirety. This is not to say that some parts of the model are unimportant; on the contrary, every detail of the model is important, and important, moreover, for genuinely practical reasons. Indeed, the point cannot be stressed too strongly that the purpose of relational theory is not just “theory for its own sake”; rather, the purpose is to provide a base on which to build systems that are 100 percent practical. But the sad fact is that the vendors have not yet really stepped up to the challenge of implementing the theory in its entirety. As a consequence, the “relational” products of today regrettably all fail, in one way or another, to deliver on the full promise of relational technology.”
― C.J. Date, An Introduction to Database Systems

“The Golden Rule:

No update operation must ever assign to any database a value that causes its database predicate to evaluate to FALSE.”
― C.J. Date, An Introduction to Database Systems

“...note that relational systems require only that the database be perceived by the user as tables. Tables are the logical structure in a relational system, not the physical structure. At the physical level, in fact, the system is free to store the data any way it likes—using sequential files, indexing, hashing, pointer chains, compression, and so on—provided only that it can map that stored representation to tables at the logical level. Another way of saying the same thing is that tables represent an abstraction of the way the data is physically stored—an abstraction in which numerous storage level details (such as stored record placement, stored record sequence, stored data value representations, stored record prefixes, stored access structures such as indexes, and so forth) are all hidden from the user.

... The Information Principle: The entire information content of the database is represented in one and only one way—namely, as explicit values in column positions in rows in tables. This method of representation is the only method available (at the logical level, that is) in a relational system. In particular, there are no pointers connecting one table to another.”
― C.J. Date, An Introduction to Database Systems