Transactional Database Using Compressed Inverted Indices

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current database systems, particularly relational databases, lack adequate support for natural language text and flexible data models, leading to performance penalties and inefficiencies in handling transactions with large amounts of data, especially in applications requiring rich data modeling and full-text search capabilities.

Innovation Solution

A method for performing transactions on a database that uses a non-updatable index structure based on compressed inverted indices, allowing for efficient storage and querying of data entities with natural language text, while maintaining data consistency and reducing the semantic gap between data and queries, by employing a modifiable data store and a static data store to manage transactions and updates.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If relational databases are optimized for OLTP applications with simple data models, then transaction processing speed is improved, but support for rich flexible data models and natural language text is insufficient

Engineering Contradiction:
Improvetransaction processing speedVSAvoidsupport for flexible data models and natural language
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The database system is segmented into multiple specialized components: an OLTP engine for transaction processing, an OLAP engine for analytical processing, and a full-text search engine for text processing. Each component is optimized for its specific function while working together through a unified architecture, allowing the system to simultaneously achieve high transaction speed and support for flexible data models with natural language capabilities

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent creates a universal database system that can handle multiple application domains (OLTP, OLAP, full-text search) within a single platform. The system provides a unified query language and common data model that works across all engine types, eliminating the need for separate specialized systems while maintaining optimization for each function

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If XML databases use hierarchical access views with declarative query specifications, then flexibility in data representation is improved, but performance penalty occurs and natural language support is missing

Engineering Contradiction:
Improveflexibility in data representationVSAvoidquery performance
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent introduces an intermediary layer that translates declarative XML-based queries into optimized execution plans. This intermediary component parses the high-level query specification, transforms it into efficient access operations, and coordinates with the underlying data storage structures, thereby maintaining query flexibility while eliminating performance penalties through intelligent query optimization

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If graph databases are implemented without legacy restrictions, then flexibility in data modeling is improved, but maturity in query processing and transaction support is insufficient

Engineering Contradiction:
Improveflexibility in data modelingVSAvoidtransaction support and query processing maturity
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements a dynamic database system where the data model can adapt its structure and behavior based on the operation being performed. The system dynamically switches between different processing modes (transactional, analytical, text search) and can modify query execution strategies in real-time based on data characteristics and performance requirements, combining graph flexibility with mature transaction processing

Inventive Principle:
Principle #15Dynamics

4Adaptability or versatility

If full-text systems are used for natural language processing, then text search capability is improved, but support for transactions and flexible data models is lost

Engineering Contradiction:
Improvenatural language text search capabilityVSAvoidtransaction support
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent merges full-text search capabilities with transactional database processing by integrating the full-text engine into the transactional processing pipeline. This allows text search operations to be performed as part of regular transactions, maintaining ACID properties while providing powerful natural language processing capabilities. The unified architecture enables text-based queries to participate in transactional workflows with proper commit, rollback, and concurrency control

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentEP2467791B1Method for performing transactions on data and a transactional database
Publication Date: 2021.04.28 OPEN TEXT SOFTWARE
  • EP2467791B1 patent drawingFigure 1
  • EP2467791B1 patent drawingFigure 2
  • EP2467791B1 patent drawingFigure 3

AI summary

The present invention provides a method for performing transactions on data entities in a database and a transactional database. The database comprises an ordered set of data stores with at least one static data store, wherein said static data store uses an index structure based on a non-updatable representation of an ordered set of integers according to the principle of compressed inverted indices. The method allows to generate a modifiable data store when the performed transaction comprises an insert, update or delete operation, to execute operations of the transaction on the ordered set being present at the time when the transaction has been started and, if present, on the modifiable data store and to convert data stores to a new static data store, The insert, update or delete operation are executed on the modifiable data store which is the only data store modifiable for the transaction.