Appendix A. The Relational Model
I believe quite strongly that if you think about the issue at the appropriate level of abstraction, you’re inexorably led to the position that databases must be relational. Let me immediately try to justify this very strong claim![173] My argument goes like this:
First of all, we saw in Chapter 5 that a database, despite the name, isn’t really just a collection of data; rather, it’s a collection of “true facts,” or (rather more respectably, since “facts” are supposed to be true by definition) true propositions—for example, the proposition “Joe’s salary is 50K.”
Propositions like “Joe’s salary is 50K” are easily encoded as ordered pairs—e.g., the ordered pair (Joe,50K), in the case at hand (where “Joe” is a value of type NAME, say, and “50K” is a value of type MONEY, say).
But we don’t want to record just any old propositions; rather, we want to record all propositions that happen to be true instantiations of certain predicates. In the case of “Joe’s salary is 50K,” for example, the pertinent predicate is “x’s salary is y,” where x is a value of type NAME and y is a value of type MONEY.
In other words, we want to record the extension of the predicate “x’s salary is y,” which we can do in the form of a set of ordered pairs.
But a set of ordered pairs is, precisely, a binary relation, in the mathematical sense of that term. Here’s the definition:
Definition: A (mathematical) binary relation over two sets A and B is a subset of the cartesian product of A
Get SQL and Relational Theory, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.