Loading...
What is a knowledge graph?
Why do we need formal knowledge representation?
Moving beyond the limitations of relational databases
The smartest way to organise, connect and make the most of your data.
When it comes to understanding the impact of knowledge graphs, a comparison with relational databases inevitably arises.
Relational databases have been the cornerstone of information storage and management for over five decades. However, when we face the challenge of representing complex knowledge and enabling machines to reason over it, fundamental limitations emerge — not as flaws in implementation, but as restrictions inherent to the relational paradigm itself.
Unlike relational databases — which organise information into tables with predefined rows and columns, establish relationships through foreign keys and require costly join operations for complex queries — knowledge graphs represent information as interconnected entities that naturally reflect the way we understand the world.
The limits of the relational paradigm in the knowledge era
Consider a seemingly straightforward medical scenario: determining whether a patient requires intensive monitoring. In a traditional relational system, we would have perfectly normalised tables for patients, symptoms, diagnoses and protocols, with referential integrity guaranteed. But the knowledge that "a diabetic patient presenting cardiac symptoms requires intensive monitoring" does not reside in the tables — it lives in the application code, scattered across stored procedures, business logic and validation rules. Every developer must correctly understand and implement these semantic relationships, and every change to the medical criteria requires code to be modified and redeployed. This implicit semantics constitutes the first major limitation of the relational paradigm.
Relational databases store data, not meaning
The relationship between a "Medications" table and a "Contraindications" table is, as far as the system is concerned, simply a foreign key with integrity constraints. The fact that certain medications should not be administered simultaneously, or that some contraindications are absolute while others are relative, is knowledge that lives outside the data model — invisible to the machine and vulnerable to inconsistent interpretation.
Structural flexibility and the ability to integrate heterogeneous information
Schema flexibility is a crucial distinction. Relational databases require a rigid, predefined schema where any structural change can be complex and costly. Knowledge graphs, by contrast, offer far greater flexibility, allowing new types of relationships and properties to be added without modifying the existing structure.
This adaptability makes a knowledge graph naturally extensible, evolving alongside our needs and the knowledge domain it represents. When an organisation discovers new relevant dimensions of information, a knowledge graph can absorb them without friction, whereas a traditional relational system would require complicated structural modifications.
In short, the structural rigidity of relational databases is a significant obstacle. Adding a new type of relationship between existing entities requires schema changes that can cascade throughout the entire system. If we discover that we need to model how certain symptoms "suggest" diagnoses with varying degrees of probability, we cannot simply add this knowledge — we must redesign tables, migrate data and update all dependent logic. The relational model, optimised for predefined and stable structures, resists the organic evolution of knowledge.
Inference capability and, by extension, unsupervised reasoning
Even more fundamental is the capacity for automatic inference — the ability to generate new knowledge from existing data. For a knowledge graph to be considered as such in the fullest sense, it is essential that new information can be inferred from the units of information that make it up (represented as triples). Unlike relational databases, which only store and retrieve data efficiently, knowledge graphs — by applying logical rules defined in the ontology — can deduce facts that are not explicitly stored, enabling the discovery of hidden patterns, the inference of new relationships and semantic contextualisation.

A relational database can tell us that Juan is a cardiologist and that cardiology is a medical speciality, but it cannot deduce that Juan is a doctor. This inference — trivial for a human — requires explicit code in the system. When inference chains become more complex (if Juan treats María and María has arrhythmia, can the system deduce that Juan treats patients with cardiac conditions?), the amount of code required grows exponentially, and with it, the likelihood of inconsistencies and errors.
No closed-world assumption
The Closed World Assumption that governs relational databases creates a particular epistemological rigidity. Anything not explicitly stored is treated as false, not unknown. If there is no record indicating that a medication is safe during pregnancy, the system assumes it is not. This binary logic does not reflect the reality of medical knowledge, where the absence of information is not the same as negative information, and where knowledge evolves continuously with new discoveries.
Semantic interoperability
Semantic interoperability between systems becomes near impossible. When two hospitals need to share information, mapping fields between databases is not enough. One may classify hypertension as a cardiovascular disease while the other categorises it as a metabolic disorder.
Without an explicit, machine-readable representation of what each concept means, integration requires constant human intervention and error-prone translations.
These limitations are not theoretical — they are deeply practical. In domains such as medicine, scientific research, knowledge engineering or business intelligence, where the value lies not just in storing facts but in understanding relationships, drawing conclusions and evolving knowledge, the relational paradigm begins to show its seams.
The answer to these challenges does not mean abandoning relational databases, which remain optimal for their original purpose. It means recognising that representing and reasoning over complex knowledge requires a different paradigm — one where meaning is explicit, inference is automatic, and the evolution of knowledge is natural. This is the space that formal ontologies and languages such as OWL are designed to fill, providing the bridge between the efficiency of structured storage and the richness of semantic reasoning.
The direct consequence of having explicit semantics is the ability to infer new knowledge. In this way, machines can reason over knowledge in a manner similar to how humans do, discovering implicit information from explicit facts.
It is not about storing data, but about describing a domain in such a way that a machine can understand its relationships and constraints.
| Relational databases | Knowledge graph |
| Organise information into tables with predefined rows and columns. | Represent information as nodes (entities) and edges (relationships). |
| Relationships between data are established through foreign keys. | Allow more flexible and direct connections between data. |
| Queries involving multiple relationships require costly join operations. | Handle connections more efficiently, as relationships are explicitly represented as edges. |
| Store data, not meaning. | Implicit semantics. |
| Require a rigid, predefined schema. | Offer greater flexibility, allowing new types of relationships and properties to be added without modifying the existing structure. |
| No inference capability. | Inference capability. |
| Closed-world assumption. | No closed-world assumption. |
| Limited interoperability. | Semantic interoperability. |