(57)【特許請求の範囲】
【請求項１】
トランザクションとレポートとの双方のデータベース情報を処理するコンピュータプログラムを実行するコンピュータシステムであって、前記コンピュータプログラムは、
行フォーマットで前記データベース情報を記憶するリレーショナルデータベース管理システムコンポーネントと、
列フォーマットで前記データベース情報を記憶する列指向データ処理コンポーネントと、
を有し、
前記リレーショナルデータベース管理システムコンポーネントと前記列指向データ処理コンポーネントとは前記データベース情報の一貫性のあるビューを共有し、
前記列指向データ処理コンポーネントは、クエリリクエストに応答して、前記列フォーマットで記憶される前記データベース情報に基づいて、クエリ応答を生成する、ことを特徴とするコンピュータシステム。
【請求項２】
前記リレーショナルデータベース管理システムコンポーネントは、データベース更新リクエストに応答して、前記行フォーマットで記憶される前記データベース情報を更新し、前記列指向データ処理コンポーネントに前記データベース更新リクエストを通知し、前記列指向データ処理コンポーネントは、前記列フォーマットで記憶される前記データベース情報を更新する請求項１に記載のコンピュータシステム。
【請求項３】
前記コンピュータプログラムは、
オンラインの分析処理クエリを集計呼出にマッピングし、前記列指向データ処理コンポーネントに前記クエリリクエストとして前記集計呼出を送信する仮想キューブインタフェースコンポーネントをさらに有する請求項１に記載のコンピュータシステム。
【請求項４】
前記行フォーマットで記憶される前記データベース情報と、前記列フォーマットで記憶される前記データベース情報とは、前記コンピュータシステムのメインメモリに記憶される請求項１に記載のコンピュータシステム。
【請求項５】
前記列指向データ処理コンポーネントは、
前記データベース情報に対応するメインデータを記憶するメインインデックスコンポーネントと、
更新された複数のデータベース情報に対応するデルタデータを記憶するデルタインデックスコンポーネントと、
判定基準に従って、前記メインインデックスコンポーネントに記憶される前記メインデータに、前記デルタインデックスコンポーネントに記憶される前記デルタデータをマージする監視コンポーネントと、
を有する請求項１に記載のコンピュータシステム。
【請求項６】
前記リレーショナルデータベース管理システムコンポーネントは、
複数のデータベーステーブルと、
インデックスオブジェクトのキューと、
前記複数のデータベーステーブルを管理し、インデックスオブジェクトの前記キューを管理し、かつファイルシステムと対話するカーネルと、
を有する請求項１に記載のコンピュータシステム。
【請求項７】
前記リレーショナルデータベース管理システムコンポーネントは、前記列指向データ処理コンポーネントと、デルタ更新アクセスを介して通信する請求項１に記載のコンピュータシステム。
【請求項８】
前記列指向データ処理コンポーネントは、前記リレーショナルデータベース管理システムコンポーネントと、永続データアクセスを介して通信する請求項１に記載のコンピュータシステム。
【請求項９】
前記列指向データ処理コンポーネントは、ネットワーク化された複数のコンピュータによって、実行される請求項１に記載のコンピュータシステム。
【請求項１０】
トランザクション及びレポートの双方のデータベース情報の処理方法をコンピュータが実行する方法であって、
行フォーマットで前記データベース情報を記憶するステップと、
列フォーマットで前記データベース情報を記憶するステップと、
データベース更新リクエストに応答して、前記行フォーマットで記憶される前記データベース情報を更新し、前記行フォーマットで記憶される前記データベース情報をロックし、前記列フォーマットで記憶される前記データベース情報を更新し、前記列フォーマットで記憶される前記データベース情報が更新された後に、前記行フォーマットで記憶される前記データベース情報をアンロックするステップと、
クエリリクエストに応答して、前記列フォーマットで記憶される前記データベース情報に基づいてクエリ応答を生成するステップと、
を有することを特徴とする方法。
【請求項１１】
コンピュータが読み出し可能な媒体において具現化され、トランザクションとレポートとの双方のデータベース情報を処理するコンピュータシステムによって実行されるコンピュータプログラムであって、
行フォーマットで前記データベース情報を記憶するリレーショナルデータベース管理システムコンポーネントと、
ネットワーク化された複数のコンピュータにより実行される列指向データ処理コンポーネントであって、前記ネットワーク化された複数のコンピュータに亘り列フォーマットでデータベース情報を記憶する列指向データ処理コンポーネントと、
を有し、前記リレーショナルデータベース管理システムコンポーネントは、データベース更新リクエストに応答して、前記行フォーマットで記憶される前記データベース情報を更新し、前記列指向データ処理コンポーネントに前記データベース更新リクエストを通知し、前記列指向データ処理コンポーネントは、前記列フォーマットで記憶される前記データ情報を更新し、
前記列指向データ処理コンポーネントは、クエリリクエストに応答して、前記列フォーマットで記憶される前記データベース情報に基づいて、クエリ応答を生成する、
ことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
〔関連出願の相互参照〕
本出願は、２００７年９月２１日に出願され、名称を「ＯＬＴＰデータをレポートするための、重複がないＥＴＬレスシステム及びその方法」という米国仮出願第６０／９９４８９３号の優先権を主張し、この米国仮出願は、参照することにより本明細書に包含される。
【０００２】
本発明は、データベースシステムに関する。具体的には、トランザクションデータベース、及びレポートデータベースに関する。
【背景技術】
【０００３】
本明細書で示唆されない限り、この章で説明されるアプローチは、本出願に係るクレームの先行技術ではなく、本章に包含されることをもって、先行技術として認めるものではない。
【０００４】
ビジネスインテリジェンス（ＢＩ）システムは、データへのアクセスを収集し、分析し、及び提供する広範な機能性を会社に提供する。データは、異機種環境の社内の多様なソースから収集され、可能な場合には、付加的な外部ソースから収集されて、統合された１組のデータを、情報及び有効なレポートの総合的基盤として作り出す。
【０００５】
ＢＩシステムのアーキテクチャの従来の最新技術は、統合された１組のデータを記憶する集中するデータウェアハウス（ＤＷ）、又は分散する多様なデータマート（data  marts）に基づいている。トランザクションシステムからデータを収集し、専用の記憶装置に移送する処理は、抽出、変換、ロード（extraction  transformation  and  loading、ＥＴＬ）と称される。ＥＴＬは、「ＢＩプロジェクトにおいて設計開発される非常に難解な処理である」（L. T. Moss and S. Atre, Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications at page 229 (Addison-Wesley, 2003)参照のこと）。Ankorionによると、ＥＴＬ処理は、従来から週に１度の頻度、又は月に１度の頻度で定期的に実行される（I. Ankorion, Change Data Capture - Efficient ETL for Real- Time Bl, DM Review Magazine (January 2005)参照のこと）。ＥＴＬは、システムが低負荷である期間にバッチジョブとして通常実行される。これは、低品質でのみ利用可能であろうデータの変換及び浄化が、多量のリソースを要するためである。これは、ＢＩシステムのデータは、必ずしも最新のデータではないことを意味し、問題となる事象にリアルタイムに反応しなければならない金融業などの会社にとっては、問題を引き起こす可能性がある。
【０００６】
Liang、及びYuを参照すると、ＢＩシステムの全てのデータをレプリケーション（replicate、複製）する必要はなく、対象のデータのみをレプリケーションする（W. Liang and J. X. Yu, Revisit on View Maintenance in Data Warehouses, in WAIM '01 : Proceedings of the Second International Conference on Advances in Web-Age Information Management at pages 203-21 1 (Springer-Verlag, London, UK, 2001 )参照のこと）。さらにまた、データを集計することによって、より高度なデータアクセス性能が達成される（K. Becker and D. D. A. Ruiz, An Aggregate-Aware Retargeting Algorithm for Multiple Fact Data Warehouses, in Yahiko Kambayashi and Mukesh K. Mohania (Wolfram Woβ, editor), DaWaK, volume 3181 of Lecture Notes in Computer Science (LNCS) at pages 118-128 (Springer-Verlag, Spain, September 2004)参照のこと）。このケースでは、集計レベルは、予め規定される。このため、いくつかの問題が生じる。第１に、ＢＩシステムにレプリケーションされていない情報が、クエリ（query）される可能性がある。第２に、集計レベルを規定するときに予見されていないものは、あるレベルの詳細なレポートを作成することができない可能性がある。このシナリオでは、特別なレポート（ユーザ自身が作成し、カスタマイズする特定のレポート）は、完全な情報基盤として可能ではなく、ソースシステムに記憶されるフィルタリングしたバージョンのデータの情報基盤として可能である。
【０００７】
ＯＬＴＰ（on-line  transactional  processing、オンライントランザクション処理）システムは、最新のデータを記憶するが、性能上の理由によってシステムによる効率的なレポートを実行することができない。ＯＬＡＰ（on-line  analytical  processing、オンライン分析処理）システムは、高機能なレポート能力を提供するが、必ずしも最新のデータを使用しない。共通のレポートアーキテクチャは、複雑かつリソース集約的なＥＴＬ（抽出、変換、及びロード）処理に依存する。ＥＴＬ処理では、システムが低負荷である間にバッチジョブ形式において、読み出しが最適化されたデータ構造にＯＬＴＰデータをレプリケーションする。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明に係る実施形態は、トランザクション及びレポートの双方のデータベース情報を処理するコンピュータプログラムを実行するコンピュータシステム、並びにその方法に関する。
【課題を解決するための手段】
【０００９】
本発明の１つの実施形態に従うコンピュータシステムは、トランザクション及びレポートの双方のデータベース情報を処理するコンピュータプログラムを実行する。コンピュータプログラムは、行フォーマットでデータベース情報を記憶するリレーショナルデータベース管理システムコンポーネントと、列フォーマットでデータベース情報を記憶する列指向データ処理コンポーネントとを有する。
【００１０】
データベース更新リクエストに応答して、リレーショナルデータベース管理システムコンポーネントは、行フォーマットで記憶されるデータベース情報を更新し、リレーショナルデータベース管理システムコンポーネントは、列指向データ処理コンポーネントにデータベース更新リクエストを通知し、列指向データ処理コンポーネントは、列フォーマットで記憶されるデータベース情報を更新する。
【００１１】
さらにまた、クエリリクエストに応答して、列指向データ処理コンポーネントは、列フォーマットで記憶されるデータベース情報に基づいて、クエリ応答を生成する。
【００１２】
本発明に係るコンピュータシステムの好適な実施形態は、従属する請求項に規定される。
【００１３】
また、本発明に係る１つの実施形態は、トランザクション及びレポートの双方のデータベース情報の処理方法をコンピュータが実行する方法であって、行フォーマットでデータベース情報を記憶するステップと、列フォーマットでデータベース情報を記憶するステップと、データベース更新リクエストに応答して、行フォーマットで記憶されるデータベース情報を更新し、行フォーマットで記憶されるデータベース情報をロックし、列フォーマットで記憶されるデータベース情報を更新し、列フォーマットで記憶されるデータベース情報が更新された後に、行フォーマットで記憶されるデータベース情報をアンロックするステップと、クエリリクエストに応答して、列フォーマットで記憶されるデータベース情報に基づいてクエリ応答を生成するステップとを有する方法である。
【００１４】
他の実施形態では、本発明は、トランザクション及びレポートの双方のデータベース情報の処理方法をコンピュータプログラムが実行するコンピュータシステムに関する。ここで、コンピュータプログラムは、行フォーマットでデータベース情報を記憶するリレーショナルデータベース管理システムコンポーネントと、複数のネットワークコンピュータからアクセスされる列フォーマットでデータベース情報を記憶する列指向データ処理コンポーネントを実行する複数のネットワークコンピュータとを有する。
【００１５】
データベース更新リクエストに応答して、リレーショナルデータベース管理システムコンポーネントは、行フォーマットで記憶されるデータベース情報を更新し、リレーショナルデータベース情報管理システムコンポーネントは、列指向データ処理コンポーネントにデータベース更新リクエストを通知し、列指向データ処理コンポーネントは、列フォーマットで記憶されるデータベース情報を更新する。
【００１６】
さらにまた、クエリリクエストに応答して、列指向データ処理コンポーネントは、列フォーマットで記憶されるデータベース情報に基づいて、クエリリクエストを生成する。
【発明の効果】
【００１７】
本発明に係る実施形態の１つの特徴は、ＯＬＴＰ（オンライントランザクション処理）システムと、ＯＬＡＰ（オンライン分析処理）システムとの間の従来の２分法（dichotomy）を解消することである。
【００１８】
本発明に係る実施形態の他の特徴は、抽出、変換、及びロード（ＥＴＬ）手順を除去することである。
【００１９】
本発明に係る実施形態の他の特徴は、更新されたデータによりレポートが実行できることである。
【００２０】
本発明に係る実施形態の他の特徴は、ＯＬＴＰシステムと、ＯＬＡＰシステムとが分離される従来のシステムと比較して、プログラムコードの量、及びプログラムコードをメンテナンスする労力が減少することである。
【００２１】
本発明に係る実施形態は、ＯＬＡＰシステムの短い応答時間を保つＯＬＴＰデータにより直接レポートするアーキテクチャを目的とする。そのために、ＥＴＬの間に通常実行されるデータ変換は、列指向メインメモリデータベースにおけるクエリ実行時に実行される。従来のレポートアーキテクチャに対して有利な点の１つは、更新データを提供でき、付加的なＯＬＡＰデータを記憶する必要がないことである。アーキテクチャは、ＳＡＰ（登録商標）のＥＲＰ（enterprise  resource  planning、経営資源計画）と、データウェアハウス（ＤＷ）製品とに基づく原型的な実施によって、有効になる。財務会計の分野からケーススタディを紹介し、これを使用して、従来の製品と性能を比較する。
【００２２】
以下の詳細な説明と、添付図面によって、本発明の特性と有利な点がより理解されるであろう。
【図面の簡単な説明】
【００２３】
【図１】本発明に係る実施形態に従うデータベースシステムのブロックを概略的に示す図である。
【図２】本発明に係る実施形態に従うデータベースシステムのブロックを概略的に示す図である。
【図３】行指向データ記憶と、列指向データ記憶の一例を示す図である。
【図４】水平分解、及び垂直分解の一例を示す図である。
【図５】本発明に係る実施形態に従うデータベースシステムを概略的に示す図である。
【図６】本発明に係る実施形態に従うデータベースシステムを概略的に示す図である。
【図７】本発明に係る実施形態に従うデータベースシステムを概略的に示す図である。
【図８】本発明に係る実施形態に従うデータベースシステムを概略的に示す図である。
【図９】本発明に係る実施形態に従うデータ処理方法のフローを概略的に示す図である。
【図１０】本発明の実施形態を実行するコンピュータシステムとネットワークとの一例のブロックを概略的に示す図である。
【発明を実施するための形態】
【００２４】
本明細書において、金融データのリアルタイムレポートのための技術を説明する。以下の説明では、説明のために、いくつかの例、及び特定の詳細が、本発明を完全に理解するために説明される。しかしながら、特許請求の範囲によって規定される本発明は、単独の例、又は以下に説明される他の特徴を組み合わせることによる特徴の一部、又は全てを包含することができ、さらに本明細書に記載される特徴、及び概念の変形、及び均等を包含することができることは、当業者には明らかになるであろう。
【００２５】
本発明は、列指向データ構造をメインメモリ技術に組み合わせて利用することに基づくアーキテクチャを提案する。このアーキテクチャにおいて、データ検索性能、及びデータ挿入性能は、迅速化され、分析システム及びトランザクションシステムは、同一のデータの組に対して機能することができる。本発明の１つの実施形態は、分析システムと、トランザクションシステムとの間のデータのレプリケーションを省略することを目的とする。先のＥＴＬ処理の一部としてのレポートに変換する特定のステップは、オンザフライ実行時に実行される。双方のシナリオについて１組のデータのみを維持することで、会社のデータの完全な組が利用可能になり、レポートに使用できるという有利な点を有する。
【００２６】
〔関連する研究〕
本発明の１つの実施形態は、レポートのための新たなリアルタイムアーキテクチャを導入する。それ故に、従来のＤＷアーキテクチャを理解することは有益である。したがって、これは、詳細に説明されることになる。その後に、トランザクションデータをレポート可能な従来のアーキテクチャが説明されることになる。
【００２７】
〔共通データウェアハウスアーキテクチャ〕
ＤＷシステムの一般的なアーキテクチャが、以下に説明される。InmonのＤＷシステムの特徴、すなわち、サブジェクト指向であり、統合され、時間により変化し、かつ不揮発性でなければならないウェアハウスのデータ（Inmon. Building the Data Warehouse, 3rd Edition. John Wiley & Sons, Inc., New York, NY, USA, 2002, p. 31を参照のこと）は、動作データと分析データとを分離するアーキテクチャをもたらした。オンライントランザクション処理（ＯＬＴＰ）システムは、リレーショナルモデル（Coddによる「A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13:377-387, June 1970」によって規定される）に従って、組織化される。すなわち、データは、一貫性を確保し、システムの日常の動作を実行するために、高度に標準化される。反対に、ＯＬＡＰシステムは、スタースキーマ、又はスノーフレークスキーマなどを使用するディメンジョンモデルに従って、データを組織化する。これは、主として最良のクエリ性能を得るためである。ＯＬＡＰシステムは、読み出し専用なため、データの一貫性はＯＬＴＰシステムよりも重要でないので、データ記憶が標準化されていないことは許容される。
【００２８】
これによって、以下のアーキテクチャをもたらす。ＤＷは、浄化と統合のためのデータ変換が適用される記憶エリアに様々なＯＬＴＰソースからデータを抽出するＥＴＬプロセッサを有する。この処理が完了すると、ＯＬＡＰエンジンがディメンジョンデータの記憶に対してクエリを実行できるように、ＥＴＬプロセッサは、ディメンジョンデータ記憶パラダイムに従って、データを記憶する。
【００２９】
ＢＩ技術の広がりとともに、このアーキテクチャは、データマート（data  marts）、又はオペレーショナルデータストア（ＯＤＳ）などの概念とともに広がってきている。データマートは、あるサブジェクトエリアでの性能を最適化するために、ＤＷを分散することを目的とする（W. H. Inmon. Building the Data Warehouse, 3rd Edition. John Wiley & Sons, Inc., New York, NY, USA, 2002参照のこと）。データマートの不利な点は、ＤＷが、企業の全ての関連データにおいて一貫した１つの目的のみを提供することである。これは、ＤＷシステムの当初の意図であった。ＯＤＳは、ＯＬＴＰデータを記憶するが、統合されたデータスキーマを使用する。つまり、データマッピング及びデータ浄化のＥＬＴステップは、データをＯＤＳに移動する前に適用される。これにより、レポートを処理できるデータのタイムラインが増加する。このため、従来のＤＷシステムと同様な特徴を有することになり、ＯＬＴＰとＯＬＡＰとの間の境界が不明確になる。以下、ＯＬＴＰデータにおいてのレポートに関連するアーキテクチャに焦点を当てていくことになる。
【００３０】
〔待ち時間を削減したレポートアーキテクチャ〕
上述のように、ＥＴＬ処理は、ＯＬＴＰシステムとＯＬＡＰシステムとを接続（切断）するＤＷアーキテクチャにおいて要点となる。１つの可能な最適化は、ＥＴＬを実行する間の間隔を最小限に短くすることであろう。マイクロバッチアプローチ（Microbatch  approaches、J. Adzic, V. Fiore, and S. Spelta. Data Warehouse Population Platform. Lecture Notes in Computer Science (LNCS), 2209, 2001参照のこと）などの主な不利な点は、頻繁にＥＴＬを実行することによるリソースの消費である。ＤＷのクエリ性能は、ＥＴＬ処理時間の間に大きな影響を受けるので、ＥＴＬ処理は、規定されるバッチウィンドウにおいてのみ実行すべきである。
【００３１】
トランザクションデータをリアルタイムにレポートするために、データ変換は、クエリの実行時に処理されてきた。したがって、データ変換をＥＴＬ処理とは別にするアーキテクチャが、提案されている。その代わりに、変換は、抽出及びロードの後に、ウェアハウスにおいて処理される。このような処理はそれぞれ、ＥＬＴと称される（L. Moss and A. Adelman. Data Warehousing Methodology. Journal of Data Warehousing, 5:23-31 , 2000参照のこと）。また、ビジネストランザクションレベル、又はデータベーストランザクションレベルにおいて、バルク処理（bulk  processing）をデルタ方式（handling  of  deltas）に置換するために、ＥＴＬのプッシュアーキテクチャ（push  architectures）が提案されている（R. Kimball and J. Caserta. The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning. John Wiley & Sons, Inc., New York, NY, USA, 2004, p. 427参照のこと）。さらにKimballは、ウェアハウスにおいて、履歴データと、最新データとを分離することを提案する。最新データは、上述のプッシュアーキテクチャを使用して、いわゆるリアルタイムパーティション（real-time  partition）で常にレプリケーションされる。そのためにＤＷは、履歴データにおけるクエリをさらに最適化することができる一方、企業における最新データもまたウェアハウスに記録される。Brobstは、上述のＥＴＬプッシュアーキテクチャを利用するように、標準的なメッセージ仲介業者の社会基盤（message  broker  infrastructures）を広げることを提案する（S. Brobst. Enterprise Application Integration and Active Data Warehousing. In Proceedings of Data Warehousing 2002, pages 15-23, Heidelberg, Germany, 2000. Physica-Verlag GmbH参照のこと）。これは、ウェアハウスのデータと関連があるメッセージに登録するメッセージバス（message  bus）にＤＷアダプタを接続することにより行われる。上述のＥＬＴの概念と同様に、必要なデータ変換は、ウェアハウスで処理される。存在するアプローチは、従来のバッチ指向のＥＴＬアーキテクチャよりもデータ捕捉の待ち時間が減少するが、ＯＬＴＰシステムにおける変更をＤＷにまで及ぼす必要がある。ここで、ＯＬＴＰシステムは、ディメンジョンデータモデルを使用して、一致して重複して記憶される。企業におけるレポートのリアルタイム性の観点から、ＯＬＴＰシステムとＯＬＡＰシステムとの間のレプリケーションは、最小限に抑制しなければならない。
【００３２】
上述する従来の物理的なＯＤＳと対照的に、仮想ＯＤＳの概念は、リクエストされた情報をクエリ実行時間に収集するプル指向性（pull-oriented）ＤＷアーキテクチャが説明される。ＯＤＳは、何れのデータを永続することなくＯＬＴＰシステム、又は第３者のシステムのダウンストリームクエリにＤＷクエリを変換するという意味では仮想的である。Inmonは、リソースシステムのデータが統合されていないときに、仮想的ＯＤＳアーキテクチャを使用することには限界があることに同意する（W. H. lnmon. Information Management: World-Class Business Intelligence. DM Review Magazine, March, 2000参照のこと）。これは、仮想ＯＤＳシステムは、データの統合を提供するために必要であるＥＴＬ変換を実行時に提供しないという事実のためである。これは、ＥＴＬ変換が高価であり、仮想ＯＤＳの機能拡張とエンドユーザの応答時間とのトレードオフによるためである。しかしながら、仮想ＯＤＳは、トランザクションデータのレポートアプローチに最も近い概念である。
【００３３】
〔ＯＬＴＰデータにおける高性能レポート〕
図１において、基本モデル化概念（Fundamental  Modeling  Concept、ＦＭＣ、A. Knopfel, B. Grone, and P. Tabeling. Fundamental Modeling Concepts: Effective Communication of IT Systems. John Wiley & Sons, Inc., May 2006参照のこと）を使用する、本発明に係る実施形態に従うデータベースシステム１００のブロックを概略的に示す。図１の実施形態は、データがトランザクションシステム以外の他のいずれのシステムにも記憶されないレポートアーキテクチャを導入する。このため、ＤＷシステムにおいてレプリケーションは生じないが、クエリ時にトランザクションシステム内のデータが直接アクセスする。
【００３４】
データベースシステム１００は、分析エンジン１０２と、仮想キューブ１０４と、メインメモリデータベース１０６と、データ記憶部１０８とを有する。データ記憶部１０８は、フラットデータファイルと、ＯＬＴＰデータと、マルチディメンジョンデータと、他のデータとを有する。分析エンジン１０２と、仮想キューブ１０４とは、ビジネスインテリジェンスシステムのコンポーネントであり、メインメモリデータベース１０６と、データ記憶部１０８とは、オペレーショナルシステムのコンポーネントである。
【００３５】
基本的に、データベースシステム１００は、メインメモリデータベース１０６を使用して、全てのデータにアクセスする。メインメモリ技術を使用することは、トランザクションデータについて直接レポートする応答時間を短縮するために、本発明の実施形態に従う解決法の１つの態様である。他の態様として、効率的な書き込みアクセスとともに高速な読み出しアクセスを提供するデータ構造を使用することが可能である。
【００３６】
〔オンザフライデータ変換〕
分析エンジン１０２は、仮想キューブ１０４を介してデータにアクセスする。仮想キューブ１０４は、ＤＷシステムにおける標準的なキューブが付与するインタフェースと同一の分析インタフェースを提供できる。これは、異なるメトリクスに関するスライシング（slicing）及びダイシング（dicing）とともに、階層のレベル間のドリリング（drilling）を含む。本発明の実施形態に従う１つの実施において、仮想キューブ１０４は、ＳＡＰ（登録商標）  ＢＩのＯＬＡＰエンジンに接続される。この結果、ＳＡＰ（登録商標）  ＢＩがサポートする全てのレポートのフロントエンドを使用して、ＯＬＴＰデータに対するクエリを起動できる。利用可能なフロントエンドは、ＨＴＭＬレポート、及びＭｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌ（登録商標）ベースのレポートを含む。ＳＡＰ（登録商標）  ＢＩの場合、所定のクエリは、このレポートフロントエンド内部で実行できる。このクエリは、（クエリ設計ツールを使用して）グラフ的に特定し、又はMultidimensional Expression（ＭＤＸ、http://msdn2.microsoft.com/en-us/library/ms145506.aspx参照のこと）を使用して特定できる。
【００３７】
ＤＷシステムにおける従来のキューブと比較すると、仮想キューブ１０４は、データを記憶しない。その代わりに、仮想キューブ１０４は、レポートの実行時に実行される関数を収集する。仮想キューブ１０４は、ＯＬＴＰデータを有する下層のメインメモリデータベース１０６への呼び出しを顕在化するレポートインタフェースをマッピングする。クエリは、ＯＬＡＰエンジン（分析エンジン１０２）に送信され、仮想キューブに対してＯＬＡＰクエリを実行する。仮想キューブ１０４は、受信するＯＬＡＰクエリを、ＯＬＴＰデータとともに使用するメインメモリデータベース１０６に対するクエリに変換する。ＯＬＡＰエンジン（分析エンジン１０２）にＯＬＴＰデータを直接提供するために、レポートによりクエリされるデータは、常に更新される。仮想キューブ１０４は、オンラインの分析処理クエリを集計呼出にマッピングし、クエリリクエストとして列指向データ処理コンポーネントに集計呼出を送信する仮想キューブインタフェースコンポーネントを有することができる。
【００３８】
メインメモリデータベース１０６のＯＬＴＰデータは、可能な限り最高級の粒度にできる。すなわち、メインメモリデータベース１０６のＯＬＴＰデータは、データが集計を含まないので、仮想キューブ１０４は、メインメモリデータベース１０６に対する集計リクエストが最も多いＯＬＡＰクエリをマッピングする。したがって、階層内部のあるレベルにリクエストされる集計は、オンザフライで作り出される。合計を記憶する必要はなく、全ての可能な集計値が先に計算され、（仮想キューブ１０４）のキューブ構造に記憶されることによってデータが急増する問題は回避される。
【００３９】
以下により詳細に説明されることになるケーススタディのシナリオの性能評価において、１０００万の科目に基づいて、作り出されている合計５０万個に対処した。２０科目に合計１つの割合で不要なものが見られる。後に説明されるように、例えば粒度は、バランスシートのレポートを作り出すには大き過ぎる。データベースから読み出される合計は、その後にソースコードで集計しなければならない。データベースの複数のフィールドを計算し、及びアクセスなしにレポートのために必要な合計を正確に読み出す着想は、ここでは現れていない。このように低い割合では、記憶スペース及び更新性能の面から不十分である。データが挿入され、又は更新される場合、一貫性を永続するために財務会計における同一データベーストランザクションにおいて生じる多数の合計は、同様に更新しなければならない。結果として、実際のデータベーストランザクションが遅延して、行レベルでロックされる場合には、多くの行が書き込みアクセスを排他的にロックされる。合計を記憶しないことにより、管理間接費を削減し、さらに科目の書き込みアクセスを有するデータベーストランザクションが高速化する。
【００４０】
〔金融データの特性のみの挿入〕
これまで、ＯＬＴＰアプリケーション用、及びＯＬＡＰアプリケーション用の物理的に分離した２つのデータ貯蔵部を有することの不利な点を説明してきた。しかしながら、ＯＬＡＰ動作とＯＬＴＰ動作とがデータの単一のレプリケーションにおいてリソースが競合する（すなわちロックする）ことがないことは、動作システムからＤＷシステムにデータをレプリケーションすることの大きな利点である。ＯＬＡＰ動作は一般的に多くのデータに作用するので、この点は重要である。これは、特にデータが別のレプリケーションにおいて予め集計されない場合、及びＯＬＴＰトランザクションのためのＡＣＩＤ（Atomicity, Consistency, Isolation, Durability、原子性、一貫性、独立性、及び永続性）特性が必要な場合である。これらは金融データに特に重要である。ＤＷにデータをレプリケーションする他の利点は、多くのレポートは、多くの履歴、すなわち時間よるデータの変化を考慮することである。ＯＬＴＰデータは通常、一貫性のある最新のスナップショットのデータのみを示す。
【００４１】
ＯＬＴＰデータに関する動作のレポートアプローチは、競合の問題と履歴の問題との双方を処理しなければならない。以下において、金融データの特性のみの挿入を利用することによって、双方の問題を解決可能な方法を説明することになるであろう。
【００４２】
ＯＬＴＰのようなシステムの主な目的である財務会計は、データが変化するごとに記録する必要があるものである。例えば、固定資産の額を減価事由（deprecation  reasons）に適用させなければならない場合には、固定資産の額は、更新されない。代わりに矯正転記（correctional  posting）が作り出される。これは、控除される資金を一方の口座から他方の口座に「移す（move）」ことである。この転記は、会計係のジャーナルに固定資産口座の新しい行として現れるであろう。ある額の控除と、この額が加えられる控除口座に新たな他の行とがあるといえる。データベースの観点からは、データは読み出されるか、挿入されるかのいずれかである。最近、Pat  Hellandが評価したように（http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants-don-t- use-erasers.aspx参照のこと）、「口座は消しゴムを使用しない」ため、更新動作、及び削除動作は、このモデルでは許可されない。したがって、データベースのロックは、もはや必要ではない。ＯＬＴＰのデータ挿入のみのモデルと、メインメモリデータベース１０６を永続性のあるただ１つの記憶装置として使用することを組み合わせることにより、ＯＬＴＰシステムの通常の動作の間に、ＯＬＴＰについての直接のレポートが短い応答時間で可能になる。Ｇｏｏｇｌｅ（登録商標）'s  Bigtable（F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber. Bigtable: A Distributed Storage System for Structured Data. In USENIX'06: Proceedings of the 7th conference on USENIX Symposium on Operating Systems Design and Implementation, pages 15-15, Berkeley, CA, USA, 2006. USENIX Association参照のこと）などの一時的なデータベースは、フィールドの更新を、関連付けされるタイムスタンプが伴う挿入とし扱うため、データ挿入のみのモデルに固有のサポートを提供する。
【００４３】
上述のように、本発明の実施形態は、ＤＷクエリが、いずれのデータも物理的に永続させずにＯＬＴＰシステムにリダイレクトされる仮想ＯＤＳに類似するところがある。本発明の実施形態と対照的に、仮想ＯＤＳは、スナップショットＯＬＴＰデータに直接アクセスする概念である。すなわち、履歴データは、考慮されない。上述のＯＬＴＰのデータ挿入のみのモデルのため、本発明の実施形態は、履歴データのレポートを本質的にサポートする。添付のみのジャーナル（append-only  journal）は、口座ごとに維持されるので、口座の前値は失われないが、再構成可能である。
【００４４】
〔全てのシナリオ用の１つのデータ貯蔵部〕
全体的なデータの組は、メインメモリ１０６に維持して、短い応答時間を保証できる。Yuによると（C. Yu. High-Dimensional Indexing: Transformational Approaches to High-Dimensional Range and Similarity Searches, volume 2341/2002. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2002, p. 137参照のこと）、データベースは、メインメモリ１０６に収めるには大き過ぎるとの仮定は、メインメモリが安価になり、かつ大きくなることにより徐々に変化している。一方、Gantzらは、世界中の組織が今後数年以内にいわゆる「情報爆発」に非常に悩まされるであろうことを主張する（J. F. Gantz et al. The Expanding Digital Universe: A Forecast of Worldwide Information Growth Through 2010. IDC white paper - Sponsored by EMC, <http://www.emc.com/about/destination/digital_universe/>, March 2007参照のこと）。２００７年において既に、より多くの情報が記憶するために利用可能な十分な容量なしに作り出される。しかしながら、情報爆発を作り出す情報の９５％は、音楽、写真、ビデオ、デジタル電話、デジタルテレビ、センサデータ、又はｅ‐メールなどの体系化されないデータである。
【００４５】
中規模会社の過去５年の金融トランザクションデータを、分析した。会社のデータの大きさは、ファイルシステムのスペースの約２０ＧＢであった。このデータをメインメモリデータベース１０６のデータ構造に変えて圧縮した後には、データの大きさは、１ＧＢ前後であった。このように、全体的なトランザクションデータの組を完全にメインメモリに維持することは、少なくとも小規模会社、中規模会社にとっては、適当なことであると思われる。
【００４６】
ＳＡＰ（登録商標）のテキスト検索情報抽出エンジン（Text  Retrieval  and Information Extraction  engine、ＴＲＥＸ）を使用して、メインメモリ装置システム１０６を実行する。ＴＲＥＸは、インデックスをつけて、体系化されていないデータを迅速に検索するテキスト検索エンジンとして当初は開発されてきた。本発明の実施形態に従う解決法は、本格的なメインメモリデータベースとしてＴＲＥＸを使用することを示唆する。しかしながら、ＴＲＥＸは、ＡＣＩＤ（原子性、一貫性、独立性、及び永続性）特性を全てサポートしていないが、これらはトランザクションシナリオの必須の条件である。しがたって、ＴＲＥＸは、従来のリレーショナルデータベース管理システム（ＲＤＢＭＳ）と組み合わされた。図２において、ＴＲＥＸをＭａｘＤＢに組み込む方法と、ＴＲＥＸとＭａｘＤＢとの間の書き込み及び読み出しの区分方法を示す。
【００４７】
図２は、本発明の実施形態に従うデータベースシステム２００のブロックを概略的に示す図である。データベース２００は、ＯＬＴＰ（及び／又はＯＬＡＰ）システム２０２と、リレーショナルデータベース管理システム２０４（ＲＤＢＭＳの特定の実施においては、ＭａｘＤＢ  ＲＤＢＭＳ２０４とも称される）と、列指向データ処理システム２０６（ＣＯＤＰＳの特定の実施において、ＴＲＥＸコンポーネント２０６とも称される）と、ファイルシステム２０８とを有する。ＯＬＴＰシステム２０２は、ＤＢ更新２２０を介してＲＤＢＭＳ２０４と対話する。ＯＬＴＰシステム２０２は、クエリ２２２を介してＣＯＤＰＳ２０６と対話する。ＲＤＢＭＳ２０４は、デルタ更新アクセス２２４を介してＣＯＤＰＳ２０６と対話する。ＣＯＤＰＳ２０６は、永続データアクセス２２６を介してＲＤＢＭＳ２０４と対話する。
【００４８】
データを変更するリクエスト、又は新しいデータを挿入するリクエストは、ＡＣＩＤ特性を保証するＭａｘＤＢ２０４によって処理される。ＭａｘＤＢ２０４は、データベースカーネル２１２（この特定の実施において、ＭａｘＤＢカーネルとも称される）と、データテーブル２１４と、（データベーステーブル内の）インデックスオブジェクト（index  object）のキュー２１６とを有する。データベースカーネル２１２は、ファイルシステム２０８と対話する。ＭａｘＢＤカーネル２１２は、データベーステーブル２１４における変化を記憶し、（キュー２１６内の）ＴＲＥＸ２０６のためのキューテーブルを管理する。キューテーブル２１６は、どのデータが変更されたか又は挿入されたかの情報を含む。ＴＲＥＸ２０６は、変更を通知され、キューテーブル２１６の助けでそれ自身のデータを更新できる。これは、同一のデータベーストランザクション内で行われる。したがって、ＴＲＥＸ２０６とＭａｘＤＢ２０４とは、データの一貫性のあるビューを共有する。
【００４９】
データベースクエリと、その戻りである分析レポート（クエリ２２２）は、ＴＲＥＸ２０６が直接処理する。ＣＯＤＰＳ２０６は、カーネル２３２（この特定の実施形態では、ＴＲＥＸカーネルとも称される）と、メインインデックス２３４と、デルタインデックス２３６とを有する。ＴＲＥＸ２０６は、メインインデックス２３４にデータを配置する。メインインデックス２３４は、テーブルが異なった形で記憶されるものの、ＭａｘＤＢ２０４のデータベーステーブル２１４と同一のデータを保持する。ＲＤＢＭＳ２０４において、テーブルは、ロー・ワイズで記憶される。ＴＲＥＸ２０６において、テーブルは、カラム・ワイズで記憶される。このデータ構造の有利な点は、次の章で説明する。メインインデックス２３４は、読み出しアクセスに対して高度に最適化されるので、ＴＲＥＸ２０６は、デルタインデックス２３６を保持して、高速なデータ検索を可能にする一方で同時にデータの組を更新する。キューテーブル２１６から引き出される全ての更新及び挿入は、デルタインデックス２３６に収集される。クエリに応答するとき、デルタインデックのデータと、メインインデックスのデータとにアクセスして、ＭａｘＤＢ２０４のデータベーステーブル２１４に対して、全体的なデータの組の一貫性のあるビューを提供する。デルタインデックス２３６は、メインインデックスと同様に圧縮されず、読み出しアクセスに対して最適化される。したがって、実施するシステムのハードウェアの制限によって決定される大きさの制限を超えるべきではない。ある大きさ、又は先に設定された時間間隔などの基準に達したときに、ＴＲＥＸカーネル２３２（又はＴＲＥＸカーネル２３２の監視コンポーネント）は、デルタインデックス２３６を、メインインデックス２３４とマージする。デルタインデックス２３６の、メインインデックス２３４とのマージは、ＴＲＥＸ２０６内部の読み出し及び書き込みアクセスのいずれもブロックしない。列指向データを処理するシステム２０６は、ネットワークと協働可能な１つ、又は複数のコンピュータ上で実行できる。
【００５０】
本発明の１つの実施形態において、データは、ＡＣＩＤ特性を保証するだけのために、データベーステーブル２１４とＴＲＥＸデータ構造２３４とに重複して記憶される。他の実施形態では、この重複は、解消される。そして、ＯＬＴＰ読み出し及び書き込みアクセス並びにＯＬＡＰレポートは、ＴＲＥＸ２０６のデータの組を使用することになるであろう。ＯＬＴＰ書き込みアクセスの必須条件として、ＴＲＥＸ２０６は、ＡＣＩＤ特性を完全にサポートするように修正される。ＴＲＥＸ２０６がサポート可能なＡＣＩＤが分析され、ＴＲＥＸが全体としてＡＣＩＤをサポートする方法が分析された。原子性は、分散型データベースシステムの二相コミットプロトコルに類似するいわゆるマルチインデックスコール（multi  index  calls）を使用してＴＲＥＸにおいて実現される。一貫性は、監視制限、及び規則が遵守されない場合にトランザクションを中止し、撤回することによって、サポートされる。ログファイルは、永続性を保証する。独立性は、ＴＲＥＸ２０６において現在では直接実現されない唯一の特性である。ＴＲＥＸ２０６は、読み出し委任（read  committed）と称される独立性レベルのみを提供する。ここで、読み出し委任は、更新の喪失（lost  updates）、又はファントム（phantoms）がデータの組に生じる可能性があることを意味する。本発明の１つの実施形態では、アプリケーションロックを介してトランザクションを直列化することによって、解決されるであろう。他の実施形態では、アーキテクチャは、ＭｏｎｅｔＤＢ、Ｃ−Ｓｔｏｒｅ、又はＧｏｏｇｌｅ（登録商標）’ｓ  Ｂｉｇｔａｂｌｅのような列ベースの現存する他のメインメモリ装置に基づいて構築できる。
【００５１】
さらにまた、ＳＱＬなどのデータベースアクセスの標準化されたインタフェースを実行することは、本発明に含むことができる。ＴＲＥＸ用の原型的なＳＱＬインタフェースは、概念実証として実施された。ＴＲＥＸ２０６自体は、ＡＢＡＰ（商標）言語、Ｃ＋＋言語、及びＰｙｔｈｏｎ言語のためのプログラミングインタフェースを提供する。ＳＵＭ、ＭＩＮ、ＭＡＸ、ＡＶＧ、ＣＯＵＮＴのような集計関数と、列のグルーピングと、列のソートと、基本的な条件処理とを含む簡単なクエリが可能である。
【００５２】
しかしながら、さらに他の実施形態では、メインメモリは、揮発性なので、メインメモリデータの組に加えて少なくとも１つの永続性を有する記憶部２０８をバックアップのために使用することが可能である。システムがクラッシュした後に、メインメモリデータ構造は、ここから再構成することが可能になるであろう。上述のように、ＴＲＥＸ２０６のデータは、従来のＲＤＢＭＳ２０４に記憶されるデータと比較して異なるように記憶される。先に集計する必要がなく、トランザクションデータをレポートするための高速アクセスを可能にすることについては、以下に説明する。
【００５３】
〔データ構造及び圧縮技術〕
会社において、日々の業務において莫大なデータが作り出される。この章において、性能を獲得するために２つの異なる領域が、対象となる。第１に、性能は、特定のデータ構造を利用することによって、達成される。ＤＷアーキテクチャのスタースキーマ、及びスノーフレークスキーマは、ディメンジョンによりグループ化されるキー性能係数（key  performance  figures）の高速アクセスを提供する。これらは、分析のための第３の正規形においてリレーショナルデータベースモデルを使用する場合などのケースであるが、複雑かつ大きな結合（join）を避けることによって、性能が最適化される。しかしながら、スタースキーマは、実行時以前にディメンジョンが規定されるため、予測不可能なレポート動作に関して比較的柔軟性に欠ける。さらに、リクエストが変更されると、通常は、スキーマも変更され、又は全体的なスキーマを再設計することになる（W. H. Inmon. When Are Star Schemas Okay in a Data Warehouse? B-Eye: Business Intelligence Network - The Global Vision for BI and Beyond, http://www.b-eye- network.com/view/ 5626, July 2007参照のこと）。
【００５４】
第２に、メインメモリに全体的なデータを維持することは、適当なクエリ性能を達成する他の方法である。サイズが大きくなるにも関わらず、メインメモリのスペースは、ディスクのスペースよりも高価であり、サイズ上の制約を有する。したがって、このような量のデータをメインメモリに収納するためには、最大の圧縮比と、挿入性能及び検索性能とに悪影響を最小限に抑える圧縮アルゴリズムを利用する可能性がある。
【００５５】
〔列指向〕
提案されるアーキテクチャでは１つのデータ記憶のみを使用するので、トランザクションシナリオのための適当な読み出しアクセス性能と、書き込みアクセス性能とを提供するとともに、分析シナリオのための検索性能を提供することが可能であるデータ構造を使用できる。一部が非正規化される分析シナリオにおいて使用されるスキームは、トランザクションシナリオにおいて良好に機能しない場合には、実行可能にはならない。高速検索アクセスを非正規化する代わりに、本発明の実施形態のアプローチは、反対の方向に進み、リレーショナルデータモデルからさらに正規化に１つ進める。複雑な結合を回避するために、データベーステーブルは、非正規化されず、先に算出された結合が獲得される。しかし、テーブルは、列レベルにブレークダウンされる。「ターニングザテーブル（turning the table）」の概念が２０年以上前から導入されている。１９８５年にCopelandとKhoshafianとが、完全な分解記憶モデル（decomposed  storage  model、ＤＳＭ）を導入した（G. P. Copeland and S. Khoshafian. A Decomposition Storage Model. In S. B. Navathe, editor, Proceedings of the 1985 ACM SIGMOD International Conference on Management of Data, Austin, Texas, May 28-31 , 1985, pages 268-279. ACM Press, 1985参照のこと）。それぞれの行は、行自体で記憶され（図３参照のこと）、論理テーブル構造は、サロゲート識別子（surrogate  identifier）を導入することによって、維持される。
【００５６】
図３において、行指向データ記憶と、列指向データ記憶との一例を示す。行指向記憶は、データの格子を有する単一のテーブルとして見ることができる。列指向記憶は、それぞれのテーブルに複製されたサロゲート識別子ｓＩＤを有する（列ごとの）複数のテーブルとして見ることができる。
【００５７】
サロゲート識別子ｓＩＤの記憶は、追加的に記憶を消費することにつながるが、識別子として列における属性の位置情報を使用するなどして克服できる。ヌル値、又は少量の異なる値のみが存在する場合など重複する記憶の属性値を回避する、より複雑なアプローチが存在する。行の変わりに列にデータを記憶する発想は、２、３例を挙げると、ＭｏｎｅｔＤＢ（P. Boncz. Monet: A Next-Generation DBMS Kernel for Query- Intensive Applications. PhD thesis, Universiteit van Amsterdam, Amsterdam, Netherlands, May 2002参照のこと）、Ｃ−Ｓｔｏｒｅ（M. Stonebraker et al. C-Store: A Column-oriented DBMS. In VLDB '05: Proceedings of the 31st International Conference on Very Large Data Bases, pages 553-564. VLDB Endowment, 2005参照のこと）、又はＧｏｏｇｌｅ（登録商標）’ｓ  Ｂｉｇ  Ｔａｂｌｅ（M. Stonebraker et al. C-Store: A Column-oriented DBMS. In VLDB '05: Proceedings of the 31st International Conference on Very Large Data Bases, pages 553-564. VLDB Endowment, 2005参照のこと）などの複数の製品において実行されている。
【００５８】
列指向記憶は、オブザベーションを使用するが、オブザベーションは、テーブルの全ての行がレポートで通常はクエリされず、結果を作り出す必要がない。結果が必要でない場合でも２つのテーブルの全ての行にアクセスするデータベースにおいて使用するリレーショナルモデルと比較すると、列指向アプローチは、より簡単な解決法を生じる。結果を作り出すのに必要とされる列にのみ直接アクセスしなければならない。
【００５９】
列指向データ構造において、従来の分析スキーム、又はトランザクションスキームと比較すると、同一の情報を構成する結合の数は多くなるが、結合自体がより単純になり、アクセスに必要なデータは少なくなる。値ごとに単一の行にアクセスして、結合を計算することは、複数のマシンにデータを分散されるときに、大規模並列処理を可能にする。図４に示すように、複数のマシンにデータを分散させる２つの基本的なアプローチが存在する。
【００６０】
図４において、水平フラグメンテーション、及び垂直フラグメンテーションの例を示す。水平フラグメンテーションは、行の組に分解し、計算を並列で実行するために、異なるマシンに分散させる。これは、ＤＷシステムのファクトテーブル（fact  table）のように、行の数が多いテーブルを処理する問題を解決するためなどに導入されている（A. Y. Noaman and K. Barker. A Horizontal Fragmentation Algorithm for the Fact Relation in a Distributed Data Warehouse. In CIKM '99: Proceedings of the Eighth International Conference on Information and Knowledge Management, pages 154-161 , New York, NY, USA, 1999. ACM Press参照のこと）。列指向は、複数のマシンにテーブルの列を分散する垂直フラグメンテーションを容易にする。ＴＲＥＸ２０６は、双方のアプローチを同時に使用する（T. Legler, W. Lehner, and A. Ross. Data Mining with the SAP（登録商標） NetWeaver BI Accelerator. In VLDB '06: Proceedings of the 32nd International Conference on Very Large Data Bases, pages 1059-1068. VLDB Endowment, 2006参照のこと）。並列計算の利点に加えて、フラグメンテーションによって、データの全ての組を、高級なハードウェア技術を使用する必要なしに記憶部に維持することが可能になる。
【００６１】
〔列の調整〕
圧縮は、限定的な記憶スペースにより多くのデータを収納するための１つの解決法である。しかしながら、書き込むときにデータを圧縮し、読み出すときにデータを解凍するため、ＣＰＵにより多くの負荷をかける。圧縮を使用するときの処理時間の増加と、圧縮を使用しないときに使用する記憶スペースの増加との間のトレードオフを、本発明の実施形態に従って図ることが可能である。しかしながら、ＣＰＵ速度の成長率と、メモリアクセス速度の間のギャップの広がりが明らかになる可能性がある（N. R. Mahapatra and B. Venkatrao. The Processor-Memory Bottleneck: Problems and Solutions. Crossroads, 5(3):2, 1999参照のこと）。年率６０％の割合でＣＰＵ速度が成長する一方、メモリ（ＤＲＡＭ）へのアクセス時間は、年率１０％以下の増加である。この成長の相違は、情報密度を増加して、メモリアクセスの量を減らす一方、処理能力の一部を圧縮及び解凍に転用することによるデータ圧縮の使用を埋め合わせする。
【００６２】
データ圧縮技術は、最適な結果のために、データドメインについてのデータ及び情報の内部の冗長性を利用する。この場合、列指向記憶は、圧縮を最適化するために寄与する。１つの列内部での属性は、同一の型のデータ、又は構造であるので、互いの間で強い類似性を有する。Abadiらは、ランレングスエンコーディング（ＲＬＥ）、又はビットベクトルエンコーディングなどの列指向記憶とともに特に良好に動作する圧縮技術の組を評価して、特徴づけた（D. Abadi, S. Madden, and M. Ferreira, Integrating Compression and Execution in Column-Oriented Database Systems, in SIGMOD '06: Proceedings of the 2006 ACM SIGMOD international conference on Management of data, pages 671-682 (New York, NY, USA, ACM Press 2006)参照のこと）。ＲＬＥにおいて、値の繰り返しは、（値、ランレングスの）対に圧縮される。例えば、配列「ａａａａ」は、「ａ［４］」に圧縮される。このアプローチは、属性値の分散が小さい列をソートするのに特に適する。後者では、ソートが適用できない場合は、ビットベクトルエンコーディングが適切である。ビットベクトルエンコーディングの多くの異なる変異形が存在する。原則的に、列内部に頻出する属性値は、ビットストリングスに関連付けられる。ここでビットは、列内部の位置を参照し、位置で生じる属性値を有するビットのみが設定される。次いで、列は、属性値なしで記憶され、ビットベクトルと組み合わせて再構成される。また、行指向記憶に使用されているアプローチは、列指向記憶に適用可能である。１つの例では、頻出するパターンが、より小さなシンボルに置換されるディクショナリエンコーディング（dictionary  encoding）である。
【００６３】
現在のところ、ＴＲＥＸ２０６は、整数を使用し、ビットエンコーディングとディクショナリエンコーディングとを組み合わせて使用する。属性のためのそれぞれの既存値（existing  value）は、ディクショナリテーブルに記憶され、整数値にマッピングされる。列の内部では、整数値のみが記憶される。第１の利点として、列内部に複数回存在する属性値は、ディクショナリテーブル内部の同一の行を参照する。これによって、重複して記憶される属性値は除去されて、同一の属性値を参照する整数の重複のみが生じる。第２の利点は、エンコードに使用される整数は、実際の属性値よりも消費する記憶スペースが少ない。
【００６４】
列を圧縮した結果、使用する記憶スペースに関連する情報の密度は増加する。これにより、関連する情報は、１回で処理するためにキャッシュにより多くロードできる。クエリに関連しない列を使用することなしにキャッシュにロードする行記憶と比較して、メモリからキャッシュへのロードを減らすことが必要である。
【００６５】
〔さらなる実施形態〕
従来のＤＷ製品の１つの大きな課題は、様々なソースからデータを抽出して、ＤＷに統合する処理方法を規定することである。ＥＴＬ処理は、種々のソースデータベースにアクセスし、ソースデータ間の矛盾を検出しかつ解消し、種々のデータフォーマット、又は言語の間で変換し、そして生じたデータをＤＷにロードするなどのような動作を有する。本発明の１つの実施形態は、ＥＴＬ動作をクエリ実行時間に移行することである。このとき、メインメモリ技術を使用して、ＥＴＬ処理の変換ステップを、オンザフライで効率的に計算できる動作にマッピングする試みが恐らくは多くなされるであろう。提示されたケーススタディは、１つの形式の変換動作である集計のみを有する。ＯＬＴＰシステム上で異なる全ての種類のレポートを直接提供することを可能にするためには、他の形式の変換動作を考慮しなければならない。変換動作は、原子性であるか、又は合成された性質（composed  nature）である可能性がある。統制の分野の例では、所与の年における１月から１２月の口座の期末残高と、期首残高を含むリストが示されるであろう。それぞれの月ｍにおいて、集計は、１月１日からｍ月の最終日の間の日にちを有する科目のみにおいて処理される。次いで、結果は、ｍの期末残高と、ｍ＋１の期首残高との双方である。この例では、合計動作（すなわち集計）は、原子性の変換であろう。合成変換を使用して、全ての期首残高、及び期末残高を創出する処理をモデリングする。いずれの複雑なレポートにおいて、このようなワークフロー様モデル（workflow-like  model）を使用して、変換を説明することが可能であろう。Simitsis、Vassiliadis、及びSellisは、最適化を見つけるためにＥＴＬ処理をワークフローとして処理する（A. Simitsis, P. Vassiliadis, and T. SeINs. State-Space Optimization of ETL Workflows. IEEE Transactions on Knowledge and Data Engineering, 17(10):1404− 1419, 2005参照のこと）。しかしながら、この研究は、従来のバッチジョブのようなＥＴＬ処理を最適化することを目的とする。オンザフライＥＴＬ処理のワークフローモデルは、調査されたことはなく、本発明のさらなる実施形態に良好な条件である。対応するタスクは、複雑なレポートシナリオの識別と、必要とする複雑な変換とを含む。次いで、変換を一般化して、ＥＴＬワークフローとともに構築できるように、これらの変換のための適当な抽象化が見つけられる。次いで、識別された変換のための効果的な実行を見つけることができる。
【００６６】
上述の実施形態によると、メインメモリデータベース２０６（ＴＲＥＸ）には、ＳＱＬを使用してアクセスする。ＳＱＬは、設定ベースのデータ検索言語であるので、ＯＬＡＰシステムに記憶するときにように、階層構造化されたデータの検索には適当ではない。このため、ＯＬＡＰ環境用に調整された多くのデータベースによりサポートされるＭＤＸが一般的に使用される。合成変換動作を使用して、ＯＬＴＰデータとレポートとの間の変換を説明することが可能であり、さらに他の実施形態では、ＭＤＸ、又はＸＱｕｅｒｙなど合成変換構成を有する言語に拡張することが考えられる。
【００６７】
上述の実施形態に従うと、この実施形態では、ＳＡＰ（登録商標）  ＴＲＥＸをＯＬＴＰデータに記憶されるメインメモリデータベース２０６として使用する。しかしながら、列指向などの同様の特性を有する他のデータベース製品が存在する。さらなる実施形態に従うと、ＭｏｎｅｔＤＢ、及びＶｅｒｔｉｃａなどの他のデータベース製品を使用できる。
【００６８】
これらのさらなる実施形態に関して、ＳＱＬ生成器６４０、及び列指向ＳＱＬモジュール６４２に言及する（図６参照のこと）。
【００６９】
図５において、本発明の実施形態に従うデータベースシステム５００を示す。データベースシステム５００は、会計書類５０２と、掛け勘定５０４と、高速検索インフラ基盤５０６とを有する。会計書類５０２と、掛け勘定５０４とは、メインメモリデータベース１０６が管理するデータ記憶装置１０８（図１参照のこと）におけるデータファイルの特定の例である。高速検索インフラ基盤５０６は、データベースシステム２００（図２参照のこと）の態様に対応する。これらは、以下の説明と図面とによって、より明確になるであろう。
【００７０】
会計書類５０２は、ルートオブジェクトと、会計科目とを有する。ユーザは、会計書類５０３と対話して、新たな科目を追加できる。次いで、科目は、掛け勘定５０４のルートオブジェクトに従って掛け勘定５０４を追加する。
【００７１】
高速検索インフラ基盤５０６は、会計書類５０３と対話して、列指向データ処理システム（ＴＲＥＸ２０６など。図２参照のこと）に科目を追加できる。以下、より詳細に説明する。
【００７２】
本発明のさらなる実施形態に従うと、合計オブジェクト５１２、ＴＢＴオブジェクト５１４、及び合計オブジェクト５１６（及び関連する接続）が省略される。高速検索インフラ基盤５０６がクエリを処理するときなどに、これらは省略できる。
【００７３】
図６において、本発明の実施形態に従うデータベースシステム６００を示す。データベースシステム６００は、アプリケーションスイート６０２（ＳＡＰ（登録商標）からの特定のアプリケーションスイートを実行する実施形態においては、ｃｕｒｒｅｎｔ  ＡＰ／Ａ１Ｓ、又はＢｕｓｉｎｅｓｓＢｙＤｅｓｉｇｎ（登録商標）と称される）と、２つの列指向システム６０４（変形１とも称される）、及び６０６（変形２とも称される）とを有する。特定の実施形態では、システム６０４とシステム６０６の双方を有する必要はなく、１つで十分である。
【００７４】
分析エンジン６１０は、アプリケーションスイート６０２と、２つのオプション６０４、及び６０６との間で共通である。分析エンジン６１０は、仮想プロバイダ６１２ａ（６０２のコンポーネント）と、６１２ｂ（６０４のコンポーネント）と、６１２ｃ（６０６のコンポーネント）と対話する。仮想プロバイダ６１２ａは、ビジネスインテリジェンス（ＢＩ）データソース６１４と対話する。ＢＩデータソース６１４は、合計及び残高ツール６１６と対話する。合計及び残高ツール６１６は、ビジネスオブジェクト（ＢＯ）永続（business  object  persistence）６１８と対話する。ＢＯ永続６１８は、合計６２０と、科目６２２とを有する。高速検索インフラ基盤（ＦＳＩ）６２４は、ＦＳＩが科目６３０をレプリケーションするときに、オプション６０４及び６０６に科目６２２をレプリケーションする。なお、データベース６００の態様は、データベース２００の態様（図２及び関連する説明を参照のこと）に対応する。
【００７５】
列指向システム６０４は、インデックス６３２（列指向システム６０４の特定の実施としてＴＲＥＸを使用する実施形態では、ＴＲＥＸインデックスと称する）を有する。科目６３０をレプリケーションしたＦＳＩは、インデックス６３２を追加する。仮想プロバイダ６１２ｂはインデックス６３２と対話する。
【００７６】
列指向システム６０６は、列指向システム６０４と類似するが、ＳＱＬ生成器６４０と、列指向ＳＱＬモジュール６４２（列指向システム６０４の特定の実施としてＴＲＥＸを使用する実施形態では、ＴＲＥＸＳＱＬと称する）とが追加される。ＳＱＬ生成器６４０は、仮想プロバイダ６１２ｃのコンポーネントである。ＳＱＬ生成器６４０は、さらなる実施形態に関して、上述のように動作する。
【００７７】
列指向ＳＱＬモジュール６４２は、パーサーコンポーネントと、モデルコンポーネントとを有する。列指向ＳＱＬモジュール６４２は、仮想プロバイダ６１２ｃ及びインデックス６３２と対話する。列指向ＳＱＬモジュール６４２は、さらなる実施形態に関して、上述のように動作する。
【００７８】
図７において、本発明の実施形態に従うデータベースシステム７００を示す。デーベースシステム７００は、データベースシステム２００（図２参照のこと）に類似する。重複した詳細については省略し、以下に（簡潔に）相違について説明する。アプリケーションスイート７０２（ＳＡＰ（登録商標）からの特定のアプリケーションスイートを実施する実施形態では、ＡＰ／Ａ１Ｓ、又はＢｕｓｉｎｅｓｓＢｙＤｅｓｉｇｎ（登録商標）とも称される）は、ＯＬＴＰ（及び／又はＯＬＡＰ）システム２０２に対応する。列指向データ処理システム７０６（ＣＯＤＰＳの特定の実施のときは、ＴＥＲＸコンポーネント７０６とも称される）は、挿入とクエリとを介してアプリケーションケーションスイート７０２と対話する。カーネル７３２（この特定の実施形態において、ＴＲＥＸカーネルとも称される）は、ファイルシステム７３４と対話する。
【００７９】
図８において、本発明の実施形態に従うデータベースシステム８００を示す。データベースシステム８００は、データベースシステム２００（図２参照のこと）に類似する。重複した詳細については省略し、以下に（簡潔に）相違について説明する。アプリケーションスイート８０２（ＳＡＰ（登録商標）からの特定のアプリケーションスイートを実施する実施形態では、ＡＰ／Ａ１Ｓ、又はＢｕｓｉｎｅｓｓＢｙＤｅｓｉｇｎ（登録商標）とも称される）は、ＯＬＴＰ（及び／又はＯＬＡＰ）システム２０２に対応する。データベース（ＤＢ）スペース８０８は、ファイルシステム２０８（図２参照のこと）に対応する。なお、データベースシステム７００（図７参照のこと）と比較すると、データベースシステム８００は、図７のファイルシステム７３４と比較するように、ファイルシステムと、関連する接続を省略する（図示されるがバツ印を付けて消される）。
【００８０】
図９において、本発明の実施形態に従うデータ処理方法９００のフローを示す。処理方法９００は、データベース情報をトランザクション、及びレポートの双方のために処理することを目的とする。処理方法９００は、データベースシステム２００（図２参照のこと）などの本発明の実施形態によって実行できる。
【００８１】
ステップ９０２において、デーベース情報は、行フォーマットで記憶される。デーベース情報は、データベーステーブル２１４（図２参照のこと）などに記憶される。リレーショナルデータベース管理システム２０４（図２参照のこと）などのリレーショナルデータベース管理システムコンポーネントは、記憶動作を管理できる。
【００８２】
ステップ９０４において、デーベース情報は、列フォーマットで記憶される。列指向データ処理コンポーネントのカーネル（カーネル２３２、及びＴＲＥＸコンポーネント２０６など、図２参照）は、メインインデックス、及びデルタインデックス（メインインデックス２３４、及びデルタインデックス２３６など、図２参照）を使用して、この記憶動作を管理できる。
【００８３】
ステップ９０６において、データベース更新リクエストに応答して、様々な更新手順、ロック手順、アンロック手順が、以下のように実行される。行フォーマットで記憶されるデータベース情報は、更新される。リレーショナルデータベース管理システム２０４（図２参照のこと）などのリレーショナルデータベース管理システムコンポーネントは、更新動作を管理できる。行フォーマットで記憶されるデーベース情報は、ロックされる。リレーショナルデータベース管理システム２０４（図２参照のこと）などのリレーショナルデータベース管理システムコンポーネントは、ロックを管理でき、列指向データ処理コンポーネント（カーネル２３２、及びＴＲＥＸコンポーネント２０６など。図２を参照のこと）にデータベース更新リクエストを通知できる。ロックが実施されると、列フォーマットで記憶されるデータベース情報は、更新される。これは、リレーショナルデータベース管理システムコンポーネントが、列指向データ処理コンポーネントに、ロックがアクティブである、又は更新リクエストが作用したなどのことを通知することによって、達成できる。列フォーマットに記憶されるデータベース情報が、更新されていた後に、行フォーマットで記憶されるデータベース情報は、アンロックされる。列指向データ処理コンポーネントは、更新を実行して、リレーショナルデータベース管理システムコンポーネントに更新が実行されたことを通知できる。
【００８４】
ステップ９０８において、クエリリクエストに応答して、クエリ応答が、列フォーマットで記憶されるデータベース情報に基づいて生成される。列指向データ処理コンポーネントは、クエリリクエストを受信して、クエリ応答を生成できる。
【００８５】
〔性能評価〕
本発明に従うレポートアーキテクチャの正当性を証明するために、原型的な実施の性能が既存のＳＡＰ（登録商標）ＤＷ製品に対してベンチマークされた。
【００８６】
既存のＤＷ製品とプロトタイプを比較可能にする設定を規定するために、ＤＷがＯＬＴＰデータにアクセスしなければならないユースケースに絞った。財務会計の分野のいくつかのシナリオがプロジェクトの過程で調査されているが、１つのケーススタディについて以下に報告する。
【００８７】
ケーススタディは、バランスシートレポートの小型のサブセットを表す２つのユースケースを含む。管理者は、会計期間の最後だけでなく、クエリを実行する日に当期が終了したと仮定した場合にバランスシートがどのようになるか、「ダブリューエイチエイティー−アイエフシミュレーション（what-if  simulation）」を実行するときにも使用する。第１のユースケースは、期間における会社の全ての会計の（貸方と借方との）合計を選択する。これは、バランスシートを作り出す主なステップの１つである。第２のユースケースは、特定の１つの会計及び期間の貸方と借方との合計を選択する。特定の会計の合計は、会社のある種の支出、収入、及び特別な資産の概観を得るために頻繁にチェックされる。
【００８８】
ＤＷシステムは、経営資源計画（ＥＲＰ）システム（すなわちＳＡＰ（登録商標）のＢｕｓｉｎｅｓｓＢｙＤｅｓｉｇｎ（登録商標））から会計の合計を収集する。ＥＲＰシステムは、専用のデータベーステーブルを使用して管理する科目に基づいて予め集計して、合計を作り出す。合計を記憶する理由は、財務会計との関連で特別の意味を有するので、頻繁にクエリされるからである。ＤＷシステムのデータは、一般的に予め集計されるので、合計を予め集計することは、標準的なＯＬＡＰ設定と共通点を有する。選択するバランスシートのシナリオにおいて、合計は、非常に高いレベルの集計による必要がある。しかしながら、ＥＲＰシステムが記憶する合計は、より詳細な集計レベルによる。バランスシートを作成するために、データがデータベースから読み出された後に、さらなる集計ステップを実行しなければならない。
【００８９】
それにも関わらず、ここで示される性能係数は、この追加の集計時間が考慮されていない。包含される全てのコンポーネントで消費される時間と、ネットワーク時間とを考慮するエンドツーエンド性能テストを実行しているが、データアクセス層に注目する。したがって、ＥＲＰシステムに内在するデータベースの応答時間は、上述のメインメモリベースのアプローチを使用して、それぞれのテーブルから科目のオンザフライ集計を実行する時間の合計を検索するときに測定された。第１のユーズケース（全ての合計を検索する）では、ＥＲＰデータベース（ＭａｘＤＢ２０４）は、科目レベルでのメインメモリデータベース（ＴＲＥＸ２０６）を検索するときに、合計テーブルに対して全てのテーブルスキャンを実行する必要がある。第２のユースケース（いくつかの特定の合計を検索する）では、ＴＲＥＸは、科目を含むテーブルの「総量」列でのフルスキャンを実施する必要があるが、ＭａｘＤＢにキャッシュヒットを生じる。
【００９０】
測定に使用されたテストデータは、電池産業の中堅企業から選び取られた。１年の会計年度のこの会計データ（大まかに３６００万の会計書類の科目）は、分析するテーブルに対応する値の確率分布が取られ、これから他のテストデータの組が生成される。データの組は、会計書類の数と、会計書類の科目と、データの組を作り出し、かつ管理するＥＲＰを使用した予め集計した合計の数とにより特徴付けられる。表１に種々のデータの組を示す。
【表１】
0005421269.tif 000002
【００９１】
ＭａｘＤＢ及びＴＲＥＸの双方の性能は、同一のマシンにより測定されている。表２にテストベッドのハードウェア構成を示す。
【表２】
0005421269.tif 000003
【００９２】
表３に測定結果を秒単位で示す。全ての結果は、２０クエリによる平均である。測定を開始する前に、４０クエリをデータベースに対して実行して、測定がデータベースを考慮していることを確認した。
【表３】
0005421269.tif 000004
【００９３】
ＴＲＥＸの平均応答時間は、双方のユースケースで同様である。これは、ＴＲＥＸが双方のユースケースでフルテーブルスキャンをしなければならないという事実によるものである。第１のユースケース（全ての口座の合計を検索する）では、ＭａｘＤＢは、予め集計した合計を含むテーブルでフルテーブルスキャンを実施しなければならない。また、ＴＲＥＸの平均応答時間は、ＭａｘＤＢの平均よりも少し良好である。最も大きなデータの組では、ＭａｘＤＢにおける合計テーブルの行の数と、ＴＲＥＸにおける科目の数との比率が１：１０であることは、注目に値する。第２のユースケース（特定の口座の合計を検索する）では、反対に、ＴＲＥＸは、ＭａｘＤＢよりも遅い。それにもかかわらず、オンザフライ計算は、会計書類の科目と一致するように合計が定期的に更新されないという意味ではＥＲＰシステムの扱いやすいアーキテクチャを可能にする。バランスシートに必要な集計レベルにおいて合計を計算することが可能なので、直接ＥＲＰシステムにおける過去のクエリの集計に対して、特定の合計における若干のクエリ性能の遅延によって、より大きな自由度を獲得する。
【００９４】
〔実施〕
図１０において、本発明の実施形態を実施するためのコンピュータシステムと、ネットワーク１４００との一例を概略的に示す。コンピュータ１４１０は、バス１４０５、又は情報を通信する他の通信機構と、情報を処理するためにバス１４０５に接続されるプロセッサ１４０１とを有する。また、コンピュータシステム１４１０は、上述の技術を実行するための命令と情報とを含む、プロセッサ１４０１が実行する命令と情報とを記憶するためにバス１４０５に接続されるメモリ１４０２を有する。また、このメモリを使用して、一時的な変数、又はプロセッサ１４０１が実行する命令を実行する間の他の中間情報を記憶できる。このメモリの可能な実施には、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、又はこれら双方にできるが、これには限定されない。また、記憶装置１４０３は、情報と命令との記憶を提供する。記憶装置の典型的な形式には、ハードドライブ、磁気ディスク、光ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、フラッシュメモリ、ＵＳＢメモリカード、又はコンピュータが読み出し可能な他の媒体形式を含む。記憶装置１４０３は、ソースコード、バイナリコード、若しくは技術を実行し、又は上述の概念を具現化するなどするソフトウェアファイルを含むことができる。
【００９５】
コンピュータシステム１４１０は、陰極線管（ＣＲＴ）、又は液晶ディスプレイ（ＬＣＤ）などコンピュータユーザに情報を表示する表示部１４１２にバス１４０５を介して接続できる。キーボード及び／又はマウスなどの入力装置１４１１は、情報及び選択指令をユーザからプロセッサ１４０１に通信するために、バス１４０５に接続される。これらのコンポーネントを組み合わせることにより、ユーザがシステムと通信することが可能になる。いくつかのシステムでは、バス１４０５は、複数の特化されたバスに分割できる。
【００９６】
また、コンピュータシステム１４１０は、バス１４０５に接続されるネットワークインタフェース１４０４を有する。ネットワークインタフェース１４０４は、コンピュータシステム１４１０とローカルネットワーク１４２０との間に双方向データ通信を提供できる。ネットワークインタフェース１４０４は、デジタル加入者回線（ＤＳＬ）、又は電話回線によってデータ通信接続を提供するモデムなどにできる。ネットワークインタフェースの他の例は、互換性があるローカルエリアネットワーク（ＬＡＮ）にデータ通信接続を提供するＬＡＮカードである。また、無線リンクは他の例である。このような実施において、ネットワークインタフェース１４０４は、様々な種類の情報を表すデジタルデータストリームを搬送する電気信号、磁気信号、又は光信号を送受信する。
【００９７】
コンピュータシステム１４１０は、メッセージ、又は他のインタフェースアクションを含む情報を、ネットワークインタフェースを介してイントラネット、又はインタネット１４３０に送受信できる。インタネットの例では、ソフトウェアコンポーネント、又はソフトウェアサービスは、複数の異なるコンピュータシステム１４１０、又はサーバ１４３１、１４３２、１４３３、１４３４、及び１４３５にネットワークを介して存在できる。サーバ１４３１は、インタネット１４３０、ローカルネットワーク１４２０、及びネットワークインタフェース１４０４を介してコンピュータシステムのコンポーネントに、１つのコンポーネントからアクション、又はメッセージを伝送できる。
【００９８】
〔まとめ〕
本発明の実施形態は、データソースとしてＯＬＴＰを直接使用するレポートのアーキテクチャを提案する。そして、
ＤＷシステムにデータをレプリケーションするバルクＥＴＬ負荷を必要としない。
様々なレベルのＯＬＴＰの集計を管理する必要がない。
ＯＬＡＰデータ構造（すなわちキューブ）が存在するレポートを提供することに限定されない。
ＯＬＴＰ及びＯＬＡＰの双方のための２つ以上の永続を要求しない。
【００９９】
列指向記憶パラダイムなどのメインメモリ技術を使用して、本アーキテクチャを実現できる。本アーキテクチャは、中間市場ビジネスソフトウェアソリュージョンＳＡＰ（登録商標）  ＢｕｓｉｎｅｓｓＢｙＤｅｓｉｇｎ（登録商標）に基づいて、原型的な実施とともに認証されている。財務会計からのケーススタディを導入して、提案されるレポートアーキテクチャの１つの可能なアプリケーションを説明する。金融データの実際の顧客を使用して、大きさが異なるテストデータの組を生成している。原型的な実施は、ＳＡＰ（登録商標）  ＢｕｓｉｎｅｓｓＢｙＤｅｓｉｇｎ（登録商標）からのケースを使用するレポートを提供するデータの直接抽出に対してベンチマークしている。結果として、２．１秒の応答時間で１０００万行を有するテーブルからそれぞれ集計する全ての口座の合計を有するレポートを作り出すことが可能になることを示す。この結果は、少なくとも財務会計の分野において、キューブ状の構造で集計する記憶装置は、もはや必要としないことを示唆する。
【０１００】
これまで、本発明の実現方法の例によって、本発明の様々な実施形態を説明した。上述の例、及び実施形態は、単なる実施形態として考えるべきでなく、以下のクレームにより規定される本発明の融通性、及び利点を説明するために示される。上述の開示、及び以下のクレームに基づいて、他の配置、実施形態、実施、及び均等は、当業者に明らかになるであろう。そして、クレームで規定される本発明の精神及び範囲から逸脱することなく使用されるであろう。
【図１】
0005421269.tif 000005
【図２】
0005421269.tif 000006
【図３】
0005421269.tif 000007
【図４】
0005421269.tif 000008
【図５】
0005421269.tif 000009
【図６】
0005421269.tif 000010
【図７】
0005421269.tif 000011
【図８】
0005421269.tif 000012
【図９】
0005421269.tif 000013
【図１０】
0005421269.tif 000014