Context graph

Building Context Graphs for Operational Databases

Published: February 3, 2026

Alekh Jindal

Share this post

LinkedInXFacebook

The data pain

Enterprises rely on operational databases for their day-to-day business, including things like products, services, orders, payments, and so on. Naturally, the data in these operational databases can help improve the business in several ways. The current practice is to transform the operational data into data warehouses (ETL or ELT) and make it available for business analytics and reporting. Unfortunately, this is a tedious task involving complex data pipelines and manual report creation. While newer AI tools can help create the reports automatically, moving data around is painful, and so most organizations end up transforming only a small subset of their operational data into data warehouses. As a result, they lack the full picture and miss out on valuable business opportunities.

Accessing operational data directly is challenging for business users. Schemas in operational databases are designed as systems of record, capturing data in a native, developer-friendly form rather than a business-friendly one. The data itself is raw and massive, having bypassed traditional warehousing transformations. This information must be translated before business users can make sense of it. The key question, then, is whether AI can bridge this gap, connecting operational data directly to business users without the heavy lifting of data warehousing.

Rise of context graphs

Context graphs can serve as the intermediate translation layer for business users and AI agents to talk to their operational databases. Such a layer needs to simplify the operational data and provide a persistent memory for AI to leverage reliably. This would include things like identifying the relationships between different parts of the data, elevating the nomenclature to data and business semantics, providing a consistent way to query in natural language, and incorporating past decisions and actions taken on that data, among others. Clearly, such a context must be automated, fast, and above all accurate.

Tursio builds context graphs for operational databases, such as SQL Server, PostgreSQL, Oracle, etc. It leverages a proprietary join inference algorithm to automatically connect the tables within any database, simplifies schema elements to make them better understandable in natural language, and generates the basic elements needed for consistent query processing (dimensions, measures, timeseries, dates, ontologies, value types, aspects, aggregate rules, default measures, samples, etc.). Given that operational databases are the most prized assets of a company, Tursio is completely on-premises. Furthermore, Tursio makes the context graph practical along the following lines:

Business Context

Most organizations have a BI tool for the business users, with Power BI being the dominant BI tool in enterprises. The reports in Power BI capture the business logic as Data Analysis Expression (DAX), which becomes critical for business users to operate. Tursio supports ingesting DAX from the VPAX files, augmenting the context graph with business context that’s already built. Likewise, Excel is the most popular spreadsheet for expressing business logic. Tursio allows importing Excel files and querying them seamlessly like any other datasets.

Historical Context

Databases already support a wide range of applications within an organization. Application developers have defined data models and business logic to meet their needs, and leveraging this historical context is critical to understanding how the data is used today. Tursio uses a proprietary, dialect-agnostic query history parser that works across T-SQL, PL/SQL, and other SQL variants. It leverages historical queries to enrich the context graph with operational data definitions and semantics.

Consistent Context

Enterprises typically work with between two and five database vendors. This could be for legacy reasons or due to application needs. Tursio provides a single pane to generate context graphs for each database, with a consistent translation layer across all systems, eliminating the need to manage disparate tools and workflows. Over time, this evolves into a single, connected context graph that interoperates across all sources of operational data.

Example Scenarios

We now discuss a few scenarios of building context graphs on operational databases:

  1. CRM/ERP applications. Microsoft Dynamics is a leading application suite for CRM and ERP functions and is powered by SQL Server for on-premises deployments. The underlying SQL Server unifies sales, services, and operational processes and can provide valuable insights into customer engagements. Unfortunately, business users must rely on experts to build SSRS or Power BI reports before they can access valuable operational data in SQL Server. Inferring context directly from SQL Server and making it searchable can remove this bottleneck.
  2. Core banking platforms. Symitar is the most widely adopted core banking platform in the credit union industry, managing the operational data that powers day-to-day business across all branches. This data holds significant potential for member insights and service personalization. However, Symitar’s hierarchical, account-centric schemas require expert report writers and analysts to extract insights. A context graph bridges this gap, connecting Symitar’s operational data with the business users who need answers.
  3. Distributed NoSQL systems. Cassandra is a popular NoSQL database for highly scalable, write-intensive applications, where it serves as the system of record for operational data. While connecting different pieces of information in Cassandra can yield significant business value, querying it is complex and typically requires expert users who deeply understand the data model and can write custom scripts. Mediating Cassandra data through a context graph makes this operational data accessible to business users.

Takeaways

Making data self-serve across an organization is quickly becoming the new norm, and this requires natural language to become the modern language for data, instead of T-SQL, PL/SQL, or others. Operational databases struggle with natural language because they are deeply embedded within organizations and therefore need a context graph as the translation layer to elevate data access to the business users.

Tursio builds such context graphs automatically for a variety of operational databases, accelerating organizations with an accurate and reliable search layer. Once inferred, however, context graphs can still contain ambiguities. We will discuss how to detect and manage ambiguities in our next post.

 

Bring search to your
workflows

See how Tursio helps you work faster, smarter, and more securely.

Contact us

cube leftcube right