Relational.AI, a company you may not yet know about, is delivering something truly innovative and impressive to the IT world. To explain its importance, it may help if we quickly review the history of data and software…
Going as far back as the late 1970s, when commercial computing was in its infancy, there was a dispute as to whether we should build systems and applications in a “data-oriented” or “process-oriented” manner—which has continued to this. Allow me to elaborate.
The Data-Oriented World
Fans of relational database viewed the world as “data-oriented.” To build systems you defined structure of the data domain in a way that suited a relational database. You didn’t worry about having to write programs to query data, you used an easily learned query language, SQL, and told the database what you wanted. It worked out the best way to get the data and passed it to you. Spreadsheets embodied the same kind of approach. You poured data into a structure and then told the spreadsheet how to calculate other data values you wanted and you did it all without writing a line of code. Sure, you had to learn how to write a few functions, but that wasn’t programming.
If relational databases had a good forms capability you could create transactions and write a good part of many business applications without sullying your hands with programming code. Relational database was the flagship of the data-oriented world and proved very effective in corporate computing. It dominated the database market almost from the moment it surfaced.
The Process-Oriented World
In contrast, the “process-oriented” thinkers see the world from the perspective of procedural programming languages. Such languages, especially the low-level ones like C++ and C# can achieve just about anything. The big idea of the process-oriented world took flight with the advent of “object-orientation.” This defined data as the kernel of an object—an object that also embodied all processes that could act on that data. Most programming languages now employ it. It conferred many excellent benefits.
Yet, while the relational model provoked database products to converge, enabling the portability of data from one product to another, object orientation didn’t provoke convergence at all. Instead, programming languages bred like rampant rabbits. It is estimated that there currently exists about 9000 programming languages—about 50% more than the number of human languages—it’s a technical Tower of Babel.
Nevertheless, we should not be too harsh on the process-oriented world. Its first gifts to the world were the operating systems that made computing possible. And pretty much all the technology for web-sites, the multitude of useful open source products (Hadoop, Spark, Kafka, et al.) and pretty much all the AI software that has set the world alight in recent years were delivered by the process-oriented world.
A Marriage of Inconvenience
The Relational model of data was not the final word. There was an obvious mismatch between it and the programming world in terms of how the two sides viewed data. This mismatch—called the “impedance mismatch”—arose from the fact that object oriented programming languages did use the data structures in which relational databases stored the data. Thus work was required at the interface between them so that the difference could be resolved without damage to the database or the application.
However that was not the biggest problem for relational database. It was becoming increasingly clear the relational data model was horribly limited. The problem was simply this. It was incapable of capturing most of the meaning of data—and while it adhered to its table-oriented form it was never going to.
Conceptually, we can put it like this: meaning derives from the relationships in what is called an “ontology.” This is a graph-like structure that records the relationship between words. The relational database was incapable or handling metadata in such a structure.
So, having laid out the plot, let’s cut to the chase. Relational.AI goes a long way towards fixing that knowledge-deficit problem. It improves the relational model. It does this by providing what it calls a “relational knowledge graph” of the database data. In effect it captures the meaning that the database didn’t capture and never could have captured.
One of the goals of the relational model was to create a business application environment where you could tell the computer what to do without telling it how to do it. This is “declarative logic” which is not programming in the conventional sense. You had something called “an optimizer” that worked out the details of how to do something.
This worked with queries, but failed to extend to the extensive area of business logic. Relational.AI provides that missing link. It can be thought of as a database for business logic. Requests are written to it in its declarative language, called REL and it runs its own optimizer to process them.
And it is agnostic as far as databases go. It’s happy to sit alongside any datastore as long as it can interface to the data schema.
If you are wondering, in practical terms, what you win here, it is development speed. Business people can understand the knowledge graph. So it considerably reduces the misunderstandings between business folk and developers that usually plague the corporate computer world. Realtional.AI makes the business model of the database explicit to business people!
According to Bob Muglia, a board member of Relational.Ai and previously CEO of Snowflake, the point is this: People who really understand the business can see what is happening.