What is the Truth and Who Owns the Truth?
It seems like a very simple question, "What is the truth and who owns that truth?"
Does a database hold the truth? This article, The Relational Model Is Not Enough: Who Owns the Truth in the Battle Over Types and Constraints, point out that "it depends".
Fundamentally, a database is a mechanical system for storing and enforcing truth. That system provides a way to persist storage, a way to get information out of that storage (e.g. query), and a bunch of other details like indexing to make things fast, transactions to manage quality, a way to get things into the database, constraints, query execution, concurrency, durability, security, versioning). The fundamental building blocks of a database are:
- Data and data types
- Structures and structure types
- A database schema that specifies what a good structure looks like
Then, someone can ask a question of the database; "What is true, right now, and under what constraints?"
Data and data types and the schema that specifies what a good structure looks like tend to be enforced by the database. But the article above asks the question, Where should structure types and integrity constraints live, and who enforces them?
A simple example of a structure type is financial statement as contrast to a different structure type such as an invoice. Obviously, the structure of an invoice and the structure of a financial statement are different; they are different types of structures.
A simple example of an integrity constraint is something like "Assets = Liabilities + Equity". This is a fundamental constraint of any accounting system.
The book, The Third Manifesto: Databases, Types, and the Relational Model by database pioneers C. J. Date and Hugh Darwen, points out that implementations of relational theory in relational databases have some notorious design flaws which lead to "accidental complexity" Some examples of these notorious design flaws which lead to accidental complexity include:
- Duplicate rows in the database are allowed and have to be dealt with when querying the database
- Databases can contain NULL values which leads to logic other than TRUE and FALSE (only TRUE and FALSE exist in logic) that have to then be dealt with in applications using the database
- Database fields (the columns in a table) can be referred to by their position in the table as opposed to always having to refer to them using their name
- There are no restrictions in a database for converting one structure type to some other structure type even when it makes no sense (e.g. is illogical) to do so
The fourth bullet point points out another problem with the implementation of relational databases. Current relational database implementations the boundary between the logical abstraction and the physical implementation are intermingled. An example of this is the TABLE.
In formal relational theory, the logical construct is a relation variable. A relation variable is a purely mathematical construct: an unordered set of rows (a.k.a. tuples) with named, typed attributes, governed by declarative logical constraints.
Software developers and relational database engines implemented frequently treat a TABLE as a physical file or container on a disk drive. Basically, the logical abstraction and the physical implementation are conflated which makes managing both the logic and the physical implementation harder.
Further, these physical containers called TABLES which store logical information cannot be explicitly typed by the subject matter experts that put information into and get information out of the typical relational database. These domain related types need to be managed by the subject matter experts and that management is best done within the database itself, not as a separate process.
There is a lot more, but I will mention one final defect. Current relational database implementations do not follow the notion of relational closure. Relational closure is the foundational mathematical property stating that the output of every relational operation is itself a relation. Because relational closure is not enforced, arbitrary composition and arbitrary nesting are allowed in current relational database implementations. This causes the possibility of illogical structures and increases accidental complexity which then must be dealt with by software applications and therefore the software developers building those applications.
Saying this another way; when relational closure is enforced and therefor holds; creating a projection (output) of any typed structure is enforced at the level of the creation of the view of the input typed structures which are wrapped (encapsulated) with constraints or other restrictions which enforce the logic of the types of structures. Meaning, it is impossible to build illogical structures because the constraints of the types of structures are enforced by the database engine without the need for special, and potentially inconsistent, construction by software developers.
Strict adherence to relational theory, as per The Third Manifesto, is a philosophical choice. Certain databases have made that choice. The article points out TypeDB and Datomic. To that list I would also add TerminusDB. And there are other graph databases tools for implementing knowledge graphs such as Stardog, GraphDB, RDfox, Fluree, Asami, XTDB, and some others. Modern Prolog has all the pieces to build a database system.
One final thought is worth mentioning. A knowledge graph is a semantic model of meaning; it becomes a database only when paired with a system that enforces truth, constraints, and transactions. Keep in mind that in a knowledge graph:
- Truth is described.
- Meaning is modeled.
- Inference is possible.
- Constraints are optional.
In a database:
- Truth is enforced.
- Constraints are law.
- Transactions are authoritative.
- History is preserved or controlled.
A knowledge graph is a semantic map. A database is a truth engine. There are a lot of different ways to implement a knowledge graph or implement a database. Epistemic risk must be managed. To do that you need governance. You need provenance. You need traceability/trackability.
Life is full of tradeoffs. Those tradeoffs should be consciously managed. If those tradeoffs are not understood, then they cannot be managed.
Additional Information:
Comments
Post a Comment