An overview of Data Algebra as a mathematical alternative to the relational model, explaining why Jabr Data Labs built its software around a single algebraic foundation rather than traditional table-based SQL thinking.
Lesson 2 | Lesson 3 | Lesson 4 | Lesson 5 | Lesson 6 | Lesson 7 | Lesson 8
Transcript
Slide 1: Thank you all for being here. My name is Robin Bloor, and over the next few minutes I’d like to introduce you to an idea that sits beneath everything we build at Jabr Data Labs — what we call data algebra. It is, I think, a genuinely different way of thinking about data, and my hope is that by the end you’ll see data the way we’ve come to see it: not as a scatter of incompatible formats, but as one thing, describable by one mathematics. Let me begin.
Slide 2: Consider the working life of anyone who deals with data today. A relational database for your tables. A document store for your JSON. A graph database for your networks. A key–value cache here, a vector store there. Each of these is a fine piece of engineering — but each speaks its own language, with its own query model, its own guarantees, and its own blind spots. We have grown so used to this fragmentation that we scarcely notice it. But it is a tax: every seam between two systems is a place where data must be copied, translated and reconciled — and where meaning quietly leaks away. I want to suggest to you this morning that this fragmentation is not, in fact, inevitable.
Slide 3: Here is the central idea, and it is a simple one to state. What if all of these shapes — the table, the document, the graph, the vector — were, underneath, the same kind of mathematical object? Not converted into one another, not bolted together, but genuinely the same thing, seen from different angles. If that were so, then a single set of operations could work across all of them, and the seams would simply disappear. That is the promise of data algebra. Everything else I’ll show you this morning is really just a careful unpacking of that one sentence.
Slide 4: I should say plainly where this comes from, because it is not something I invented one afternoon. Data algebra was invented and developed by my late friend and collaborator, Gary Sherman — a mathematician of real depth — and set out in the book we co-authored, The Algebra of Data. Gary is no longer with us, and I remain deeply indebted to him; a good deal of what I’ll show you is as much his as mine. What matters for you is this: the whole edifice is built on Zermelo–Fraenkel set theory with choice — ZFC — the same bedrock that underpins essentially all of modern mathematics. This is not a clever data format with a grand name. It is a rigorous algebra, derived carefully from first principles.
Slide 5: Let’s build it up from the bottom, because the foundation is genuinely small. The atom of data algebra is the couplet: nothing more than an ordered pair, which we write a arrow b. You can read it as a single directed fact — this points to that. ‘name’ points to ‘Ada’. ‘Employee 7’ points to ‘the sales department’. That is the whole of it. It looks almost too humble to build a database on — and yet, as we’ll see in a moment, everything else is made of couplets, in much the same way that all of arithmetic is, in the end, made of numbers.
Slide 6: From that atom we build a tower of just four levels, and this diagram is worth committing to memory, because the whole system lives inside it. A couplet is our atom, at the foot of the tower. Gather a set of couplets and you have a relation — the second level. Gather a set of relations and you have a clan — the third. And gather a set of clans and you have a horde — the fourth. Each level is simply a set of the things one level below: couplets, then sets of couplets, then sets of those, then sets of those again. In the notation of set theory it is G-cross-G, then its power set, then the power set of that, and once more. Four levels — and, quite remarkably, that turns out to be enough to describe every shape data takes.
Slide 7: Now let me connect this back to the shapes you use every day, because the abstraction pays off precisely here. A relation — a set of couplets — is what you would recognise as a single record, or a row, or a little graph of connections. A clan — a set of relations — is a table, or a document, or the result of a query. And a horde — a set of clans — is a whole database. The point I most want to land is this: a table and a document and a graph are not three different kinds of thing that we must awkwardly translate between. They are all clans and hordes — the very same objects, wearing different clothes. Once you truly see that, the walls between your data systems start to look less like laws of nature and rather more like historical accidents.
Slide 8: If the objects are uniform, then the operations can be too — and this is where the elegance becomes genuinely practical. Data algebra gives you a single set of operations: composition and transposition, which follow and reverse connections; the familiar set operations of union, intersection and difference; the natural join you already know from SQL; and a family called strictions, which restrict one object by another. The crucial property is that every one of these is defined just once and then lifts cleanly up the tower — the same union that combines two relations combines two clans, and two hordes. You do not learn one query language for tables, another for documents and a third for graphs. You learn the operations once, and they apply everywhere. For anyone who has spent a career switching mental gears between systems, that is a quiet revolution.
Slide 9: None of this would matter very much if it stayed on the page, so let me tell you what we have built on it. At the centre is JabrDB — a database engine that implements this algebra directly. Because its single model already spans tables, documents and graphs, it does the work that would otherwise take three separate systems, and it does it without the seams between them. Around JabrDB we’ve built a growing suite of native macOS applications — from spreadsheets right through to business intelligence — every one of them resting on the same mathematical foundation. It is, I’ll happily admit, an unusual way to build software: most companies start with the product and reach for the theory later, if at all. We did it precisely the other way round — and I’ve come to believe that starting from the mathematics is exactly what allows the pieces to fit together so cleanly.
Slide 10: So let me leave you with the very thought I began with. Data is not, at bottom, a collection of incompatible formats that we are condemned to shuffle endlessly between. It is one kind of thing — describable, precisely and completely, by one algebra of four levels and a handful of operations. That conviction is what the whole of Jabr Data Labs is built upon. If it has caught your interest, I would warmly encourage you to explore the algebra on our site, to read The Algebra of Data if you’d like the full account, and — above all — to be in touch, because I always enjoy talking with people who are curious about this. Thank you very much indeed for your time and your attention this morning; it has been a real pleasure to share this with you.