Graph Query Compilation in Relational Database Systems

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current solutions for executing graph queries in relational database management systems (RDBMS) face challenges such as high security concerns, high costs, and poor performance due to external specialized graph systems, external automatic translators, and manual query translations, which limit efficient execution of graph pattern matching queries within a single machine RDBMS.

Innovation Solution

The techniques described enable efficient compilation and execution of graph pattern queries within a single machine RDBMS by using a SQL/PGQ parser, semantic analyzer, and SQL translator to convert graph pattern queries into efficient SQL queries that can be executed by the relational engine, avoiding changes to the existing SQL engine and leveraging the native graph schema for optimizations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If external specialized graph systems are used to execute graph queries, then query execution capability is improved, but security concerns increase and costs increase

Engineering Contradiction:

Improvegraph query execution capabilityVSAvoidsecurity concerns

Core Design Contradiction:

ProductivityVSObject-affected harmful factors

Solution Approach 1:

The patent introduces an intermediary translation layer that converts graph queries into SQL queries, allowing the RDBMS to execute graph queries without directly exposing the graph database to external systems. This mediator approach maintains security while enabling graph query functionality.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent makes the RDBMS universal by enabling it to handle both traditional SQL queries and graph pattern matching queries through a unified query processing architecture, eliminating the need for separate specialized graph systems.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Productivity

If external specialized graph systems are used to execute graph queries, then query execution capability is improved, but implementation and deployment costs increase

Engineering Contradiction:

Improvegraph query execution capabilityVSAvoidimplementation and deployment costs

Core Design Contradiction:

ProductivityVSDevice complexity

Solution Approach 1:

The patent merges graph query processing capabilities into the existing RDBMS architecture, combining SQL processing and graph pattern matching into a single system. This eliminates the need for separate external graph systems and reduces implementation and deployment costs.

Inventive Principle:

Principle #5Merging (Combining)

3Ease of operation

If external automatic translators are used to convert graph queries to SQL, then ease of operation is improved, but query performance deteriorates

Engineering Contradiction:

Improveautomatic query translationVSAvoidquery execution performance

Core Design Contradiction:

Ease of operationVSSpeed

Solution Approach 1:

The patent performs preliminary actions by pre-compiling graph patterns into optimized SQL representations and pre-establishing the mapping between graph schema and relational schema. This preliminary preparation enables both automatic translation and high performance during query execution.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent replaces the mechanical translation process with an intelligent compilation approach that uses the native graph schema to generate optimized SQL queries automatically, eliminating the need for manual translation while maintaining high performance.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

4Manufacturing precision

If manual query translation is used to convert graph patterns to SQL, then query accuracy is improved, but ease of operation deteriorates and user burden increases

Engineering Contradiction:

Improvequery translation accuracyVSAvoiduser effort for translation

Core Design Contradiction:

Manufacturing precisionVSEase of operation

Solution Approach 1:

The patent replaces manual translation with an automated intelligent compilation system that leverages the native graph schema to accurately translate graph patterns into SQL. This automation maintains translation accuracy while eliminating user burden.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

Solution Approach 2:

The system performs self-service by automatically generating optimized SQL queries from graph patterns using the native graph schema, without requiring user intervention for translation. The system compiles and optimizes queries autonomously.

Inventive Principle:

Principle #25Self-service

5Productivity

If graph data is exported to external systems for processing, then graph query capability is improved, but data security deteriorates and ETL costs increase

Engineering Contradiction:

Improvegraph query processing capabilityVSAvoiddata security

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

Instead of exporting graph data out of the RDBMS to external systems, the patent inverts the approach by bringing graph query processing capabilities into the RDBMS. This allows graph queries to be executed on data that remains securely within the database system.

Inventive Principle:

Principle #13The other way round (Inversion)

Data Source

PatentUS11507579B2Efficient compilation of graph queries involving long graph query patterns on top of SQL based relational engine

Publication Date: 2022.11.22 ORACLE INT CORP

AI summary

Techniques support graph pattern matching queries inside a relational database management system (RDBMS) that supports SQL execution. The techniques compile a graph pattern matching query into a SQL query that can then be executed by the relational engine. As a result, techniques enable execution of graph pattern matching queries on top of the relational engine by avoiding any change in the existing SQL engine.