Chris Date and the Relational Model (2014)
red-gate.com
red-gate.com
As for Date, he is a gem:
"Thank you for saying my writing style is “coherent”! But I think I can explain that, too. The truth is, I’m a rather slow learner. As a consequence, I think I can be a good teacher, because I can identify places where students are likely to have trouble."
I have learned so much from him.
> Looking back it seems such a simple idea to replace the hierarchical structures used to build databases with tables of rows and columns
> First of all, XML structures are fundamentally hierarchic; thus, all of the intrinsic difficulties with hierarchies that we experienced all those years ago-with IBM’s IMS product in particular-are rearing their ugly head again.
What I mean: the relational model has replaced existing hierarchical models. Isn't that proof by practice that the underlying mathematical model (set theory, predicate logic) is extraordinarily well suited to cover data structuring and information modeling in computer science. And, yes, hierarchies are also first-class citizens in relational models and can scale beautiful.
Even the developments, yes, "hypes" of recent years and decades such as NoSQL or knowledge graphs and graph databases have not fundamentally shaken this, but we are increasingly seeing a return to the proven relational model. Hence "history repeating".
Maybe. Maybe not. The only practical example we keep seeing is implementations centred around SQL which, while loosely based on the relational model, notably does not have relations. Without relations – the idea that sits at the very core of the relational model – you don't technically have a relational database (even if we colloquially call it as such).
So while, in theory, the relational model should work just as well, practice hasn't attempted to prove that at scale. Not since Postgres was first created has anyone really even tried to implement the relational model, and Postgres soon gave up on the idea and moved to SQL too. It may be that tables are actually better for practical use and that the relational model would fall down flat if we ever gave it a serious go.
I would love it if you could add some practical example.
Basically, SQL does not constrain one to a strict mathematical relational model since you can have ordering, duplicates, nulls etc.
I think most people would say that C doesn't have message passing. Being able to use the facilities provided by the language ecosystem to build message passing / relations on top is at another level.
Subset. You can build relations on top of tables, but not tables on top of relations. SQL falls short of the mathematical model. As it pertains to the topic at hand, whether or not that is significant is not something we have tried very hard to prove in practice.
A Table is a Relation encoded as a set of tuples resulting from the cartesian product of values from multiple sets each of which is from a domain.
Tables are a weaker form of Relations and hence a superset except for the "ordering" characteristic when it can be considered a subset.
Right. As before, you cannot build a table on top of a relation. You can build a relation on top of a table, though.
> Tables are a weaker form of Relations
Yes, exactly, hence it being a subset.
Of course you can; it is in the very definition of the Table which is a manifestation of a Relation. Relationships (which can also be mathematical Relations) across Tables/Views are a different thing.
> hence it being a subset.
No, all Relations are Tables but not all Tables are Relations because of ordering, duplicates, nulls.
You said multiple relations earlier, which is what the comment was in reply to. Why the fliply-flopping?
> Relationships
Relation, not relations, not relationships. The struggle is real.
> all Relations are Tables
Yes, that's right, a relation is a table with additional constraints – a superset. Although not a strict superset as it does not carry ordering forward.
> You said multiple relations earlier, which is what the comment was in reply to. Why the fliply-flopping?
Read my definition above again; I said "multiple sets" and NOT "multiple relations" which is a very different thing. You understood it wrong.
> Relation, not relations, not relationships. The struggle is real.
Only for you. I have been very clear in the usage of my terms above. A Table encodes a Relation. Additionally, when you do a JOIN across Tables you are manifesting a "Relationship" (English usage) which may/may not result in a Mathematical Relation.
> a relation is a table with additional constraints – a superset.
No, If there are additional constraints on set A than on set B then A cannot be a superset of B but a subset.
But the relational model works and has been proven, independent of SQL.
Hell, even Datomic.