Boolean and Missing: What Are They Good For?
RelationalAI is built on knowledge graphs, which rarely use null and boolean values. And yet, Rel, RelationAI’s declarative modeling language, has a
Missing data type to represent
null values, and a
Bool type to represent
false boolean values.
Let’s explore the role null and boolean values play in a dataset and learn when to use
Bool types in Rel.
Consider a database of invoices for a company.
You might want to store purchase orders associated with an invoice. But not every client uses purchase orders, so you record those with a null value — perhaps as
NULL in a SQL table or as
null in a JSON document. Maybe you need to track whether or not the invoice has been paid. You record that as a
false boolean value.
The resulting table of invoices in a SQL database might look something like this:
boolean values have in common?
Both concepts represent the presence, or lack thereof, of a fact.
NULL represents the absence of a purchase order.
false represent whether or not a payment has been received. The presence, or non-presence, of a fact determines which value is assigned.
The question is: if a fact is not present, does it need to be in your data?
In a knowledge graph, nodes representing entities in a model are related by edges representing the various relationships between those entities.
For example, an
Invoice entity can be related to a
PurchaseOrder entity via an edge labeled
has_purchase_order, and a Payment entity via a
n a knowledge graph, you don’t need to store
NULL values or keep track of
false. Missing data simply isn’t there. If an
Invoice has no
PurchaseOrder, there’s no
has_purchase_order edge. If an
Invoice hasn’t been paid, there’s no
With so much emphasis on knowledge graphs, it may seem contradictory to have
Bool values in Rel, but sometimes you really do need them.
For more information on modeling graphs, see Data Modeling: Graph Normal Form (opens in a new tab).
When you ingest data into RelationalAI’s Relational Knowledge Graph System (RKGS) (opens in a new tab), you create a representation of that data in Rel.
Representations of data need to be high-fidelity. That is, you should be able to reconstruct the original data from the Rel representation. This means that Rel needs a way to represent null and boolean values.
For example, an invoice might be ingested from a JSON document:
In Rel, this JSON document gets represented as the following relation:
missing value is the only primitive value of the
Missing type. The
Bool type has two primitive values:
Having values of type
Bool in Rel allows you to export relations as JSON, if needed. And you can accurately reconstruct data that has been ingested. But you usually won’t use
Bool types in your models.
Recursive Computations in Rel
We are excited to announce the latest enhancements to our Relational Knowledge Graph System (RKGS) that substantially improve the performance of certain recursive computations.
Declarative Quantum Computing
All businesses regularly confront difficult decisions. Even when these decisions are constrained (perhaps by budgets) and the cost implications of the decisions are complex, optimization algorithms may nevertheless provide decisions that minimize cost and maximize benefit. Unfortunately, optimization can become very difficult as the number of decisions increases and this makes it an excellent use-case for quantum computing. Declarative languages like RelationalAI’s Rel make the integration of quantum optimizers simple.