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 strong claim! My argument goes like this:
As I explained in Chapter 5, a database, despite the name, isn’t really just a collection of data; rather, it’s a collection of facts, or in other words 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 are true instantiations of certain predicates. In the case of “Joe’s salary is 50K,” for example, the 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: A binary relation over two sets A and B is a subset of the cartesian product of A and B; in other words, it’s a set of ordered pairs (a,b), such that the first element a is a value from A and the second element b is a value ...
Get SQL and Relational Theory 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.