Auto-Generated Ontologies and Taxonomies from Relational Database Schemas

This page is adapted from my book, Enterprise Intelligence, Relational Models are Ontologies, page 111.

In the journey toward a truly intelligent enterprise—one with an Enterprise Knowledge Graph (EKG) that reasons over curated BI, domain expertise, and real-time data—the hardest part isn’t always building the graph from scratch. Often, the richest starting material already sits in your relational databases: schemas that quietly encode business reality through tables, keys, and relationships.

Consider Figure 1, a simple dimensional model for stock quotes (a classic Fact-Dimension setup):

  • The central FactQuotes table (①) captures transactional events with columns like StockID (FK to DimStocks), TraderID (FK to DimTraders), DateTime, Quote (value), and Unit (③, implying measurement nuance).
  • It connects via foreign keys (e.g., ①) to dimension tables DimStocks (StockID as PK, plus TickerSymbol and Name) and DimTraders (TraderID as PK, plus Name and ParentTraderID).
  • Deeper semantics emerge beyond plain FKs: FactQuotes is classified as a kind of Event (②), quotes are associated with a unit of measurement (③), identifiers link to unique primary keys, DimTraders include a hierarchical ParentTraderID (⑤) forming a taxonomy of trader relationships, and overall structure ties products/stocks to events via classification and description arcs.
Figure 1 – Sample of a typical relational database schema.

At first glance, this looks like “just” a database schema—optimized for queries, joins, and analytics. But it’s already an informal ontology, formed from the data modelers who created this schema. Tables act as classes (Event, Product/Stock, Trader); columns as properties (has Quote, identified by TickerSymbol); foreign keys as object properties (belongs to Trader, has many Quotes); and the ParentTraderID hints at inheritance or hierarchical classification.

Relational schemas are proto-ontologies—they define entities, relationships, and constraints, just not in a machine-reasonable, semantic form. They’re “relational” in the loose sense (keys link tables), but lack the rich expressivity of OWL/RDF: no explicit “is-a-kind-of” for classification, no formal units/taxonomies, no inference rules.

Automating this doesn’t require fantastically complicated code. With data model views (DMV), LLMs as semantic translators and Python magic (this is probably simple enough for an LLM to generate the code)—we can start lifting these schemas into proper ontologies and taxonomies.

Figure 2 – Processing the tables and columns.
  1. Parse the schema (tables, columns, PK/FK constraints, data types).
  2. Map basics automatically: Tables → Classes, Columns → Data Properties, FKs → Object Properties.
  3. Enrich semantically: Infer “is-a-kind-of” from naming patterns or metadata (ex. FactQuotes as subclass of Event); detect hierarchies (ParentTraderID → taxonomic parent-child); add units/domains from column metadata or documentation.
  4. Iterate with LLM assistance (private endpoint, zero-retention): Prompt for refinements like “Given this FK chain and column names, suggest OWL axioms for classification and measurement units.”
  5. Output a seed ontology (OWL/TTL) + taxonomy (hierarchical classes) that feeds your EKG—grounded in real enterprise data, not abstract theory.

The result isn’t perfect (schemas often hide nuances), but it’s a massive accelerator: bootstrap your EKG from what you already have, then refine with SME input, BI insights, and story-like narratives (as we’ve discussed). No more starting from blank pages—your databases become the living seed for symbolic reasoning.This bridges the old world (efficient relational ops) and the new (semantic inference, LLM orchestration). It’s a pragmatic step toward enterprises where knowledge isn’t siloed in tables or prompts—it’s explicitly modeled, evolvable, and sovereign.