Multi-Dimensional Data Model for Efficient OLAP Updates

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

OLAP systems face inefficiencies in updating and recalculating large, multi-dimensional data sets due to their geometric growth in summary data, leading to computationally expensive processes and the need for overnight batch recalculations, which hinder interactive updating and support for ad hoc analysis.

Innovation Solution

A multi-dimensional data model is employed, organizing data into blocks with summary information, dependency, and change information, allowing for efficient updating and recalculation by propagating changes without referencing all dependents, and enabling 'what if' scenarios through change logging and dependency checking.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If data are organized in multi-dimensional blocks with summary information for OLAP analysis, then ad hoc analysis capability is improved, but updating and recalculation becomes computationally expensive due to geometric growth in summary data

Engineering Contradiction:
Improvead hoc analysis capabilityVSAvoidupdating and recalculation efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent segments the multi-dimensional data cube into hierarchical levels (detail level, intermediate levels, summary level). Each level contains only the summary data necessary for that level, rather than storing all possible aggregations. This segmentation reduces the total volume of summary data that must be maintained and updated, directly addressing the computational expense problem while preserving ad hoc analysis capability through the hierarchical structure.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system pre-calculates and stores summary information at multiple hierarchical levels before it is needed for analysis. When updates occur, only the affected levels need recalculation rather than the entire data cube. This preliminary organization of data at appropriate granularity levels enables fast query response for ad hoc analysis while limiting the scope of recalculation during updates.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If all summary data are recalculated during updates, then data consistency is improved, but the time required for updating increases with the size of the data set

Engineering Contradiction:
Improvedata consistencyVSAvoidupdating time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies local quality by maintaining different levels of summary detail in different parts of the hierarchical structure. When an update occurs, only the local portions of the hierarchy that are affected by the change need to be recalculated. The system identifies and updates only the specific summary levels and dimensions impacted by the change, rather than performing a global recalculation of all summary data. This localized approach preserves data consistency where needed while minimizing unnecessary recalculation time.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The hierarchical segmentation allows the system to divide the recalculation task into manageable segments corresponding to different levels of the hierarchy. Update operations can be propagated selectively through the hierarchy, recalculating only the segments that contain affected data. This segmentation breaks the monolithic recalculation process into smaller, parallelizable units, reducing total updating time while maintaining consistency through controlled propagation of changes.

Inventive Principle:
Principle #1Segmentation

3Speed

If interactive updating is enabled for fast response, then user responsiveness is improved, but handling large data sets becomes infeasible due to computational complexity

Engineering Contradiction:
Improveinteractive response timeVSAvoidcomputational complexity
Core Design Contradiction:
SpeedVSDevice complexity

Solution Approach 1:

The patent introduces a temporal dimension to the data model by organizing summary data hierarchically across time periods (detail transactions, daily summaries, weekly summaries, monthly summaries, etc.). This dimensional organization allows the system to answer ad hoc analysis queries across multiple time granularities without requiring full recalculation. Interactive updates can be applied at the appropriate temporal level, and the hierarchical structure automatically propagates changes upward, enabling fast interactive response even for large data sets by operating on summarized rather than detailed data.

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

Solution Approach 2:

The system performs preliminary aggregation of detailed transactions into summary data at multiple hierarchical levels before interactive analysis is needed. This pre-computation creates a layered structure where interactive queries can operate on pre-aggregated summaries rather than raw transactions. When updates occur during interactive sessions, the system recalculates only the affected summary levels, leveraging the pre-established hierarchy to maintain fast response times without requiring full recalculation of the entire data set.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS7647356B2Methods and apparatus for facilitating analysis of large data sets
Publication Date: 2010.01.12 ORACLE INT CORP
  • US7647356B2 patent drawing
  • US7647356B2 patent drawing
  • US7647356B2 patent drawing

AI summary

Methods and apparatus are described for updating a database using a multi-dimensional data model in which data corresponding to the database are organized in multi-dimensional blocks. Each block has summary information associated therewith corresponding to a current state of evolution of the associated block. Dependency information is maintained in the data model which identifies data dependencies within and among the blocks. Change information is maintained which identifies changes made to particular ones of the blocks and times at which the changes were made. The database is updated with reference to the dependency information, the summary information, and the change information. At least some of the blocks are updated without reference to all dependents thereof. In some implementations, the underlying database may be a relational database, the data from the relational database being mapped to the multi-dimensional data model.