All of today’s mainstream database products support the SQL language, and relational theory is what SQL is supposed to be based on. But are those products truly relational? Sadly, the answer is no. This book shows you what a real relational product would be like, and how and why it would be so much better than what’s currently available.

With this unique book, you will:

- Learn how to see database systems as programming systems
- Get a careful, precise, and detailed definition of the relational model
- Explore a detailed analysis of SQL from a relational point of view

There are literally hundreds of books on relational theory or the SQL language or both. But this one is different. First, nobody is more qualified than Chris Date to write such a book. He and Ted Codd, inventor of the relational model, were colleagues for many years, and Chris’s involvement with the technology goes back to the time of Codd’s first papers in 1969 and 1970. Second, most books try to use SQL as a vehicle for teaching relational theory, but this book deliberately takes the opposite approach. Its primary aim is to teach relational theory as such. Then it uses that theory as a vehicle for teaching SQL, showing in particular how that theory can help with the practical problem of using SQL correctly and productively.

Any computer professional who wants to understand what relational systems are all about can benefit from this book. No prior knowledge of databases is assumed.

30, and is located in city Madrid. To sum up: A given relvar R contains, at any given time, all and only the tuples that represent true propositions (true instantiations of the relvar predicate for R) at the time in question—or, at least, that’s what we always assume in practice. In other words, in practice we adopt what’s called The Closed World Assumption. Here’s a definition: Definition: Let relvar R have predicate P. Then The Closed World Assumption (CWA) says (a) if tuple t appears in

(3rd edition, Addison-Wesley, 2007), the database isn’t really just “a container for relation variables,” even though we usually talk about it as if it were. Rather, it’s a variable in its own right! After all, it can certainly be updated—and that means it’s a variable by definition. Logically speaking, in other words, the database in its entirety is one (typically rather large) variable in itself, which we might call a dbvar. To put the matter another way, database relvars are really an illusion

Chapter 1, I said the operators supported in connection with any given type T must include the equality comparison operator, because without it we couldn’t even tell whether a given value v is an element of a given set S.[86] I also said the comparison v1 = v2 must give TRUE if and only if v1 and v2 are the very same value (and are thus of the same type, necessarily), and hence that if some operator Op is such that Op(v1) ≠ Op(v2), then v1 = v2 must give FALSE. How does SQL match up to these

most readers,[114] but I’ll define them here for the record: Definition: The union of sets S1 and S2 (in symbols, S1 ∪ S2, sometimes pronounced “S1 cup S2”) is the set of objects x such that x is an element of S1 or S2 or both: { x : x ∈ S1 OR x ∈ S2 } Definition: The intersection of sets S1 and S2 (in symbols, S1 ∩ S2, sometimes pronounced “S1 cap S2”) is the set of objects x such that x is an element of both S1 and S2: { x : x ∈ S1 AND x ∈ S2 } The set theory difference operator is

Third Manifesto as such and the Tutorial D language. (Please note in passing that Tutorial D is not part of the Manifesto as such but is merely one possible language that can be used to explain the ideas of the Manifesto.) The book also contains some proposals for upgrading Tutorial D to industrial strength. Note: The website www.thethirdmanifesto.com gives information regarding a variety of existing Tutorial D implementations, as well as other projects related to the Manifesto. See also