Logic takes care of itself; all we have to do is look and see how it does it.
—Ludwig Wittgenstein: Tractatus Logico-Philosophicus (1922)
As I mentioned in Chapter 1, there’s an alternative to the relational algebra called the relational calculus. What this means is that queries, constraints, view definitions, and so forth can all be formulated in calculus terms as well as algebraic ones; sometimes, in fact, it’s easier to come up with a calculus formulation than an algebraic one, though the opposite can also be true.
What is the relational calculus? Essentially, it’s an applied form of predicate calculus (also known as predicate logic), tailored to the needs of relational databases. So the aims of this chapter are to introduce the relevant features of predicate logic (hereinafter abbreviated to just logic); to show how those features are realized in concrete form in the relational calculus; and, of course, to consider the relevant features of SQL as we go.
Incidentally, it follows from the above that a relational language can be based on either the algebra or the calculus. For example, Tutorial D is explicitly based on the algebra (which is why there aren’t many references to Tutorial D in this chapter), and both QUEL and Query-By-Example (see Appendix G) are explicitly based on the calculus. So which is SQL based on? The answer, regrettably, is partly both and partly neither ... When it was first designed, SQL was specifically intended to be different from both the algebra and the calculus (the latter explicitly, the former perhaps a little less so); indeed, such a goal was the prime motivation for the introduction of the SQL “IN subquery” construct. (The name SQL originally stood for Structured Query Language; the idea behind that name was precisely that SQL queries typically involved one SELECT - FROM - WHERE expression nested inside the WHERE clause of another such expression, and so on, recursively.) As time went on, however, it turned out that certain features of both the algebra and the calculus were needed after all, and the language grew to accommodate them. The consequence today is that some aspects of SQL are “algebra like,” some are “calculus like,” and some are neither—with the further consequence that, as I mentioned in passing in Chapter 6, most queries, constraints, and so on that can be expressed in SQL at all can in fact be expressed in numerous different ways.
Aside: The goal mentioned in the previous paragraph—the goal, that is, of making SQL different from both the algebra and the calculus—was based on what I regard as a fundamental misconception: namely, the idea that the algebra and calculus were both somewhat “user hostile.” But that perception was, I believe, founded on a confusion over syntax vs. semantics. Certainly the syntax in Codd’s early papers was a little daunting, based as it was on formal mathematical notation. But semantics is another matter; the algebra and the calculus both have (I would argue) very simple semantics, and it’s fairly easy, as many writers have demonstrated, to wrap that semantics up in syntax that’s very user friendly indeed. End of aside.