Virtual Infocube Mediation Layer for Data Model Integration

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Enterprises face challenges in integrating disparate data access mechanisms when transitioning from one data model to another, such as from an infocube to a relational database, leading to the loss of useful applications and front-end interfaces.

Innovation Solution

The implementation of a virtual infocube that transitions automatically from an infocube interface to a relational database interface, using metadata-driven processing to generate SQL queries and translate answer sets, allowing seamless data access and integration between the two models.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If an enterprise transitions from an infocube data model to a relational database data model, then the enterprise can handle larger volumes of information more effectively, but the enterprise loses the ability to use front-end interfaces and applications associated with the infocube model

Engineering Contradiction:

Improvevolume of informationVSAvoidintegration of data access mechanisms

Core Design Contradiction:

Quantity of substanceVSAdaptability or versatility

Solution Approach 1:

The patent introduces a mediation layer that sits between the infocube interface and the relational database. This intermediary component receives queries from the infocube interface, translates them into appropriate relational database queries, and returns results in the expected format. This allows the enterprise to maintain familiar infocube front-end interfaces while actually storing and processing data in a relational database, thus resolving the contradiction between handling larger information volumes and maintaining interface compatibility.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates a universal data access mechanism that can handle both infocube-style queries and relational database operations through a single integrated system. The translation layer provides multi-functionality by supporting multiple data access patterns and interface types, allowing the enterprise to benefit from both the infocube interface paradigm and the relational database capabilities without being forced to choose one over the other.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Productivity

If an enterprise switches its underlying data model from infocube to relational database, then the enterprise can scale to handle increased information volume, but the enterprise must relinquish useful applications and interfaces it has grown skilled in

Engineering Contradiction:

Improveinformation management capabilityVSAvoidtime to retrain and redevelop applications

Core Design Contradiction:

ProductivityVSLoss of time

Solution Approach 1:

The patent creates a virtual copy of the infocube interface layer that operates over the relational database backend. This copy maintains the familiar interface paradigm and application structure, allowing users to continue working with existing applications without retraining. The translation layer copies the infocube query interface semantics and translates them into relational database operations, preserving user productivity while enabling the transition to a more scalable data model.

Inventive Principle:

Principle #26Copying

3Ease of operation

If an enterprise maintains infocube front-end interfaces after transitioning to a relational database, then user familiarity and application continuity are preserved, but the ability to integrate disparate data access mechanisms is limited

Engineering Contradiction:

Improveuser familiarity with interfacesVSAvoidintegration architecture

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

The patent segments the data access architecture into distinct layers: the infocube interface layer, the translation/mediation layer, and the relational database layer. This segmentation allows each layer to be optimized independently - the interface layer maintains user familiarity, the translation layer handles the complexity of integration, and the database layer provides scalable storage. By separating concerns in this way, the system achieves both ease of operation and manageable complexity.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS8108335B2Techniques for integrating disparate data access mechanisms

Publication Date: 2012.01.31 TERADATA US INC

AI summary

Techniques for integrating disparate data access mechanisms are provided. A user attempts data access against an infocube and its data access mechanism. Transparently, that access attempt is translated into a format recognized and processed by a relational database access mechanism to produce results. The results are then translated from a relational database format back to an infocube format and presented to the user within the infocube's data access mechanism.