ERP Knowledge Graphs and LLM Embeddings for Data Discovery

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing ERP systems face challenges in providing efficient access to customer data for machine learning model development due to cryptic database table names, numerous tables and views, lack of descriptive metadata, and the absence of natural language interfaces, making it difficult to identify relevant data for model generation.

Innovation Solution

Utilizing a knowledge graph with human-readable names and descriptive information, combined with a large language model (LLM) to generate embeddings, enables easy identification and retrieval of relevant data by transforming and embedding metadata from ERP systems, allowing developers to generate machine learning models effectively.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If developers explore database tables and views to locate relevant data, then data can be accessed for machine learning model development, but the process becomes time-consuming and difficult due to cryptic table names, numerous tables and views, and lack of descriptive metadata

Engineering Contradiction:
Improvedata access efficiencyVSAvoidtime to identify relevant data
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent introduces a natural language interface as an intermediary between developers and the ERP database system. This interface translates human-readable queries into database operations, eliminating the need for developers to directly navigate cryptic table names and structures. The intermediary layer provides descriptive metadata and contextual information that bridges the gap between business concepts and database implementation details.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces the mechanical process of manually exploring database tables and views with an automated natural language processing system. Instead of requiring developers to systematically search through database metadata and understand table relationships, the system uses language models to interpret queries and automatically locate relevant data, substituting manual mechanical exploration with intelligent automation.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Reliability

If ERP systems use standardized database table names and structures, then data consistency and system reliability are improved, but data findability and ease of access deteriorate due to cryptic non-descriptive names

Engineering Contradiction:
Improvedata consistencyVSAvoiddata findability
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent applies local quality by providing different types of names for different purposes: standardized technical names for database operations and human-readable descriptive names for user interaction. The system maintains the original cryptic table names for reliability while adding layered descriptive metadata (titles, descriptions, business context) that provides local human-readable quality where needed for ease of access.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent adds another dimension to database object identification by introducing multiple levels of description beyond simple table names. Instead of relying solely on one-dimensional technical identifiers, the system creates multi-dimensional access points including natural language descriptions, business context, and semantic relationships, allowing users to locate data through multiple descriptive dimensions rather than memorizing technical names.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

3Ease of operation

If comprehensive metadata descriptions are added to all database tables and views, then data accessibility and understanding are improved, but system complexity and maintenance burden increase

Engineering Contradiction:
Improvedata accessibilityVSAvoidmetadata management complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent applies preliminary action by pre-generating comprehensive metadata descriptions, titles, and contextual information for all database objects during system initialization or data extraction phases. This preliminary enrichment of metadata allows the natural language interface to function effectively without requiring ongoing manual metadata management, as the descriptive information is prepared in advance and maintained automatically.

Inventive Principle:
Principle #10Preliminary action

4Loss of information

If developers search for complementary data across different platforms, then complete information can be gathered, but the process becomes more complex and time-consuming due to scattered data locations

Engineering Contradiction:
Improvecompleteness of dataVSAvoidtime to gather comprehensive information
Core Design Contradiction:
Loss of informationVSLoss of time

Solution Approach 1:

The patent merges scattered data from multiple ERP platforms and sources into a unified natural language interface. The system consolidates complementary information that would otherwise be distributed across different tables, views, and platforms, allowing developers to access complete information through a single integrated query interface rather than searching multiple separate locations.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentEP4641435A1Large language models and knowledge graphs for enterprise resource planning systems
Publication Date: 2025.10.29 SAP SE
  • EP4641435A1 patent drawingFigure 1
  • EP4641435A1 patent drawingFigure 2
  • EP4641435A1 patent drawingFigure 3

AI summary

In an example embodiment, a knowledge graph is used to provide human-readable names and further contextual and descriptive information of data in database views and tables. This makes this information findable, accessible, identifiable, and reusable, and enables the re-use of such information across use cases. Further, an LLM is used to generate descriptive information that can then be used to generate embeddings to compare natural language questions provided by developers with objects in an ERP.