JP7051108B2 - データソースシステムに不可知のファクトカテゴリパーティション化情報リポジトリ及び情報リポジトリを用いてデータを挿入及び検索するための方法 - Google Patents

Description

本発明は、一般に、データウェアハウジングに関し、特に、データソースシステムに不可知の（ａｇｎｏｓｔｉｃ）ファクトカテゴリパーティション化情報リポジトリ及び情報リポジトリを用いてデータを挿入及び検索するための関連する方法に関する。

データがソースシステムに固有であり、データウェアハウスがデータを同様の構造的コンテキストに格納するという点で、従来のデータウェアハウジング技術に伴う問題が存在する。

例えば、データウェアハウジングのための主な手法は、ディメンション手法及び正規化手法を含む。

ディメンション手法（Ｒａｌｐｈ Ｋｉｍｂａｌｌにより提案されている）では、データは、普通はサブジェクトエリアにより編成される「ファクト」と、ファクトにコンテキストを与える参照情報である「ディメンション」へパーティション化される。

ディメンション手法を用いるこのような従来技術のデータウェアハウスが図１に示される。

図から分かるように、各ソースシステム２１に関して、従来技術のデータディメンション・データウェアハウス２６は、関連するサブジェクトエリア２７を備える。

例えば、ポイント・オブ・セールシステム２１のサブジェクトエリア２７に関して、販売トランザクションは、注文された製品の数及び製品の支払われた価格などのファクト２８へ、及び、注文日、顧客名、製品番号、注文の送り先及び請求先の位置、及び注文の受注を担当する販売員などのディメンション２９へ分解することができる。

ディメンション手法の重要な利点は、データウェアハウスがユーザにとって理解及び使用するのがより容易であるという点である。また、データウェアハウスからのデータの検索は、非常に速く動作する傾向がある。ディメンション構造は、該構造が測定値／ファクトとコンテキスト／ディメンションへ分割されるので、ビジネスユーザにとって理解するのが容易である。ファクトは、組織のビジネスプロセス及び運用システムに関係しており、一方、それらの周囲のディメンションは、コンテキストを提供する。ディメンションモデルによって与えられる別の利点は、リレーショナルデータベースクエリを常には必要としないことである。したがって、このタイプのモデリング技術は、エンドユーザクエリに非常に有用である。

しかしながら、ディメンション手法の欠点は、ファクトとディメンションとの一体性を維持するためにデータウェアハウスに異なる運用システムからのデータをロードするのは複雑である点である。すべてではないがほとんどの場合に、データウェアハウスに構築及び格納されるファクトは、オペレーショナルトランザクション又はプロセスに固有であり、「サブジェクトエリア」ファクトと呼ばれる。これらのファクトは、それらのサブジェクトエリアに厳密に制約され、したがって、広範なデコンストラクションなしにはリレーショナル分析に適さない。同様に、定義されたサブジェクトエリアにわたる時間コンテキストは、しばしば異種であり、ディメンションとしての時間は、範囲が拘束（ｒａｎｇｅ ｂｏｕｎｄ）される必要があり、すべてのファクトにわたる時間の瞬間（ｉｎｓｔａｎｔ ｉｎ ｔｉｍｅ）を容易に表さない場合があることを示す。

さらに、ディメンション手法を用いると、ディメンション手法を採用する組織がビジネスプロセスを変える場合に、「サブジェクトエリア」が新しいビジネスに合うように変化し、古いデータが陳腐化されるので、データウェアハウス構造を修正するのが難しい。加えて、データウェアハウス内の組織の複数のサブジェクトエリアを記述するのに必要とされるディメンションの数は、多くのしばしば重複したディメンションを伴って急速に拡大する複雑なスキーマ又は設計につながる。

さらに、従来技術のディメンション・データウェアハウス２６の種々の異種のサブジェクトエリア２７からのデータの抽出は、例えば、販売スタッフの成績の分析などの種々の目的で種々のデータを選択的に選択し関係付けるデータ「キューブ」３０の生成を必要とする。キューブのセットアップ及び使用は、面倒なだけでなく、結果的に望まないデータ重複も生じることがある。

正規化手法（Ｂｉｌｌ Ｉｎｍｏｎにより提案されている）では、データウェアハウスにおけるデータは、データベース正規化ルールにある程度従って格納される。テーブルは、一般的なデータカテゴリ（例えば、顧客データ、製品データ、財務データなど）を反映するサブジェクトエリアによって一緒にグループ化される。正規化構造は、データをエンティティへ分割し、これはリレーショナルデータベースにいくつかのテーブルを作成する。

大企業に適用されるとき、正規化手法は、結果的に結合のウェブ（ａ ｗｅｂ ｏｆ ｊｏｉｎｓ）により一緒にリンクされる多くのテーブルを生じる。さらに、作成されたエンティティのそれぞれは、データベースが実装されるときに別個の物理テーブルへ変換される。

正規化手法の主な利点は、データベースへ情報を追加するのが簡単である点である。この手法の欠点は、関係するテーブルの数により、異なるソースからのデータを意味のある情報へ結合（ｊｏｉｎ）することと、データのソースの及びデータウェアハウスのデータ構造の正確な理解なしに情報にアクセスすることはユーザにとって難しい場合があるという点である。

本発明は、従来技術の欠点のすべてではないが少なくともいくつかを克服する又は実質的に改善することになる静的な構成可能なデータウェアハウス構造を提供しようとする又は少なくとも持続可能な代替を提供しようとするものである。

したがって、本発明は、トランザクションデータとデータソースシステムに不可知との両方であるデータリポジトリに関する。

具体的には、図２に示されるように、本発明のデータリポジトリ８は、特定のファクトパーティション１６（サブジェクトエリアではなくデータのタイプ又はカテゴリによってカテゴライズされる）と、ファクトパーティション１６に関連して格納される特定のカスタマイズ可能なディメンションへ分割される。

さらに、異なるデータソースシステムから受信したデータを特定のファクトパーティション及び関連するディメンション内に格納するのに適したフォーマットへマップ／翻訳するべくデータソース固有のマッピング／プラグイン１９が使用される。

このようにして、本発明のデータリポジトリは、基礎をなすファクトパーティション、既存の報告、分析プロセス、及びディメンションへの修正なしに、異なる運用システム及び他のソースシステムからのデータを受信及び共有するために用いることができる。

加えて、ビジネス固有のカスタマイゼーションが必要とされるならば、該当する共有ディメンションの１つ又は複数のデータベーステーブルにカラムを追加することにより、追加のコンテキスト情報が本発明のデータリポジトリ内に格納されてよい。

上記に定義されたリポジトリを用いると、データは、追加のファクトテーブルの包含を必要とせずに、複数のデータソースシステム（人的資源、給与支払い名簿、電子商取引、小売り、生産倉庫、在庫管理、及び他のタイプの運用システムなど）から受信されてよい。次いで、各異なる運用システムから受信したデータを、基礎をなすファクトパーティション及びディメンションに関する共通のリポジトリフォーマットへマップ／分解／パーティション化するのに、ソースシステム固有のマッピングが用いられてよい。

同様に、検索のために、データは、リポジトリ内にあるままで用いられてよく、又は代替的に、基礎をなすファクトパーティション及びディメンション内に格納されたデータを各運用システムに適したデータへマップするべく該当するソースシステム固有のマッピングを用いて「逆マップ」又は「再構築」されてよい。

したがって、本発明の実施形態は、ビジネストランザクション時のデータ転送の実行を可能にするべく、プル方法の代わりにパブリッシュ／プッシュ方法を用いることができる。

さらに、本発明のファクトパーティション化リポジトリ８は、スキーマの再設計なしにすべての新しいデータストリームを受け入れることができる。

さらに、本発明のファクトパーティション化リポジトリ８は、新しいビジネス構造が追加されるときに新しいファクトタイプを追加する必要をなくす。

さらに、本発明の方法論は、新しいデータストリームの迅速な受け入れを容易にする標準化されたロードプロセスを可能にする。

さらに、本発明のファクトパーティション化リポジトリ構造は、静的ロードプロセスを可能にし、これは、リポジトリからのデータ抽出だけが構成することを必要とし、これにより、データ入力中のステージングを回避し得ることを意味し、この場合、レコードはソースでクリーンにされる。

さらに、本発明のファクトパーティション化リポジトリは、詳細な、デコンストラクトされた、信頼性のある（ソースから直接の）データを提供し、これにより、データマート／キューブの必要をなくす。データが、ＰＴＬプロセス中にその「信頼できる情報源（ｓｏｕｒｃｅ ｏｆ ｔｒｕｔｈ）」から直接に、該当するファクトパーティション及び関連するディメンションへデコンストラクトされる際に、本発明のリポジトリ自体がそのデータマート又はキューブとなるという点で、リポジトリと分析ツールとの間にデータマート又はキューブに関する要件は存在しない。データの粒度も、「同一条件での（ａｐｐｌｅｓ ｔｏ ａｐｐｌｅｓ）」比較を容易にし、一貫性及び信頼性をもたらす。

さらに、本発明の方法論は、リポジトリへの入力の前のソースでの汚れたレコードの拒否を可能にし、これにより、一体性の問題を除去する。

従来技術と比較して、ＵＳ２０１０／００７０４２１ Ａ１（ＦＡＺＡＬ他）（以下「Ｄ１」）は、組織の成績を管理するためのデータウェアハウスシステムを開示する。Ｄ１のデータウェアハウスシステムは、データモデルが特定の組織を表すように、複数の組織に適用可能なディメンション及び測度を表すデータを格納するためのデータモデルと、プレースホルダを設定するための構成ユニットとを備える。これは、多くの組織にわたって同じコンテキストで用いられる、ファクト構造のマルチカテゴリコレクションではない、単一のファクト定義を構成する。

しかしながら、Ｄ１は、オペレーショナルパフォーマンスを記録するための特定のデータベース構造を提供することに向けられており、したがって、報告又は分析の目的でデータの運用システムに不可知のストレージを提供する問題に向けられていない。データウェアハウスレコードは、データタイプ又はカテゴリではなく基礎にあるビジネス機能又は「サブジェクトエリア」（例えば、「販売分析」）によって明瞭に編成される。

ＵＳ２００９／０２７１３４５ Ａ１（ＲＩＣＨ他）（以下「Ｄ２」）は、トランザクションデータベースのデータの関係性を再構築することなくトランザクションデータベースのリレーショナルマッピングを用いて構築されるデータウェアハウスを開示する。最初に、アプリケーションプログラマが、オブジェクトモデルのオブジェクト、属性、及びパスを用いてファクト及びディメンションを記述するためにオブジェクトモデルを分析する。ディメンションのそれぞれは、トランザクションデータベースにおけるアイテムをデータウェアハウスにおけるディメンションレコードと相関させる識別子を有する。ファクト及びディメンションの記述は、記述ファイルに保存される。次に、データウェアハウスエンジン（ＤＷＥ）が、記述ファイルにアクセスし、オブジェクトモデル、ファクト及びディメンションの記述、及びオブジェクト－リレーショナルマッピングを用いてトランザクションデータをデータウェアハウスにマップする。これは、特異のデータウェアハウジングの保持及び分析に関する単一のファクトカテゴリ定義を構成する。

しかしながら、Ｄ２は、現在のオブジェクトタイプを超える範囲を有さず、そしてまたオブジェクト定義は静的であることからトランザクションデータコンテキストの融通性をもたらすどのような能力もない単一のトランザクションタイプに関連する事実上特異の「サブジェクトエリア」であるオブジェクト定義によるソーストランザクションの特異のマッピングを挙げている。

ＵＳ２０１０／０１０６７４７ Ａ１（ＨＯＮＺＡＬ他）（以下「Ｄ３」）は、関係する資産の組に関するファクト情報及び関連情報を含むデータリポジトリの組からのディメンションデータモデルにデータマートをポピュレートすることを開示する。各資産に関するファクト及び関連を処理するべく中間データウェアハウスが生成される。中間ウェアハウスを用いて、各資産に関して入手可能な情報を十分にモデル化するべく１つ以上のデータマートがファクトテーブル、ディメンション、及び階層と共に生成される。

しかしながら、Ｄ３は、データウェアハウスリポジトリ又は同様のもの（Ｄ３で「中間データウェアハウス」として具体的に言及される）に既にあるデータに適用可能な「ステージング」リレーショナルデータベースを示す。このようなステージングは、キューブ化された形態を入力する前に起こり、１つの情報タイプにのみ関係した現在のデータウェアハウスの静的ディメンションを明瞭に表現するのに役立つ。

ＵＳ２００３／０２３３２９７ Ａ１（ＣＡＭＰＢＥＬＬ）（以下「Ｄ４」）は、税の支払いを容易にするべくファクトの詳細を生成するための税に関係するデータのトランザクションに関係するディメンションを開示する。最初に、税に関係するデータのトランザクションに関係するディメンションが、トランザクションに関係するディメンションに関する複数の属性と共に提供される。このような属性は、トランザクション識別子、トランザクションタイプ、税タイプ、顧客アカウント識別子、販売先の地理的コード、送り先の地理的コード、契約番号、購入注文番号、ベンダーアカウント識別子、及びベンダー郵便番号に基づいて決定されるトランザクションラインアイテムを含む。次に、トランザクションに関係するディメンションの属性と関連付けられる複数のエントリが受信される。次いで、トランザクションに関係するディメンションの属性の所定の組のエントリを用いて複数のファクトの詳細が生成される。その後、ファクトの詳細が出力される。

しかしながら、Ｄ４は、単一のビジネスタイプ又はサブジェクトエリア（課税）を表し、他のビジネスタイプ（例えば、マイニング及び製造）からのトランザクションを格納するための関連する能力を有さず、また、このようなアイテムの抵当又はクレジット契約はこのモデルに相応しくないので金融サービスでの単一の課税モデルを超えるコンテキスト能力はない。

ＵＳ２００８／０１２０１２９ Ａ１（ＳＥＵＢＥＲＴ他）（以下「Ｄ５」）は、インターフェースを生成するのに用いられる、所与のビジネストランザクション中に用いられるデータを反映する、ビジネスオブジェクトモデルを開示する。このビジネスオブジェクトモデルは、産業、ビジネス、及びビジネストランザクション中のビジネス内の異なる部局にわたる使用に適する一貫したインターフェースを提供することにより商取引を容易にする。

しかしながら、Ｄ５のトランザクションは、サブジェクトエリアに固有であり、互いに関連を保持せず、したがって、固有のデコンストラクションなしに分析に関する内部能力を提供しない。

ＵＳ２００７／０２３９７１１ Ａ１（ＵＮＮＥＢＲＩＮＫ他）（以下「Ｄ６」）は、トランザクションデータモデルと、トランザクションデータモデルにおけるオブジェクトをそれぞれ参照するビューフィールドのコレクションを含むビューとを受信することと、コレクションにおける複数のビューフィールドのうちの１つ以上を複数のデータウェアハウスオブジェクトのうちの１つ以上にマップすることと、マップされたデータウェアハウスオブジェクトを報告データモデルへグループ化することを含む、トランザクションデータモデルの報告データモデルへのマッピングを開示する。

しかしながら、Ｄ６は、（データのカテゴライゼーションではなく）そのサブジェクトエリア固有のデータのユーザの観点が、どのトランザクション分解とも対照的にビューでの再定義によってより有効にされる、正規のデータウェアハウスをはっきりと説明する。

上記から分かるように、挙げた引用文献のいずれも、データソースシステムに不可知の情報リポジトリを提供する問題に向けられていない。

さらに、挙げた引用文献のいずれも、特定のファクトパーティションタイプ（生成的なサブジェクトエリアではなくデータのカテゴリである）に従ってパーティション化され、種々の共有ディメンションに関連して格納されるファクトパーティションを備えるリポジトリ構造を含む本発明の実施形態の特徴を教示又は提案していない。

さらに、挙げた引用文献のいずれも、複数のデータソースシステムからのデータを特定のファクトパーティション及び関連する共有ディメンションのデータ構造に関して適用可能な共通のフォーマットへ翻訳することができるようにするべくデータソースシステム固有のデータマッピングに従って受信したデータを翻訳／マップ／パーティション化するためのデータマッパーの使用を教示又は開示していない。

次の説明から明らかとなるように、本発明の実施形態のデータソースシステムに不可知の情報リポジトリは、前述の従来技術のディメンション手法及び正規化手法とは異なる。

具体的には、本発明の実施形態のデータソースシステムに不可知の情報リポジトリは、正規化手法よりも従来技術のディメンション手法により関係していると考えられ得るが、本発明の実施形態に係るファクトは、サブジェクトエリアではなくデータカテゴリ又はタイプに従ってパーティション化されるという点で、本発明の実施形態のデータソースシステムに不可知の情報リポジトリは従来技術のディメンション手法とは本来異なる。上記の背景の項目で言及したように、従来技術のディメンションファクトは、普通は、データタイプ又はカテゴリではなくサブジェクトエリアにより編成される。

本明細書で開示される固有のデータカテゴリは、物理的世界又は論理的世界のすべてではないがほとんどの可能性のあるシナリオに関係するトランザクションデータ及び他のデータを格納することができる「普遍的に記述的な（ｕｎｉｖｅｒｓａｌｌｙ ｄｅｓｃｒｉｐｔｉｖｅ）」データソースシステムに不可知の情報リポジトリを可能にし、これにより、ディメンション手法を採用する組織がビジネスプロセスを変える又は追加のデータソースシステムからのデータを導入することを望む場合にデータソースシステムに不可知の情報リポジトリを修正することが難しい従来のディメンション手法の構成の問題を克服する。

データソースシステムに不可知の情報リポジトリは、データソースシステムに不可知の情報リポジトリ内に格納されたデータの簡易化された効率的な検索におけるさらなる技術的利点をさらに与える。

さらに、オペレーティングシステムにわたるデータ構造の共通性は、クロス運用システムデータ遍在を可能にし、これにより、異なるソース及びサブジェクトエリアからのデータを意味のある情報へ結合することと、データのソースの及びデータソースシステムに不可知の情報リポジトリのデータ構造の正確な理解なしに情報にアクセスすることはユーザにとって難しい場合がある正規化手法の問題を克服する。

さらに、後述するように、データソースシステムに不可知の情報リポジトリは、固有のディメンションタイプを使用し、データソースシステムに不可知の情報リポジトリを簡易化し、結果的に簡易化された効率的なクエリの挿入及び選択などをもたらすことにより、パーティション化されたデータカテゴリ間のディメンションの共通性を備える。

したがって、上記のことを念頭に置いて、一態様によれば、データソースシステムに不可知のファクトパーティション化データ情報リポジトリシステムであって、複数のファクトパーティションと、ファクトパーティションに関連して格納された複数のディメンションであって、その複数のディメンションは、ファクトパーティションのそれぞれによって共有される、複数のディメンションと、を備える、データリポジトリと、複数のデータソースシステム固有のデータマッピングと、複数のデータソースシステムからデータを受信するためのデータレシーバと、複数のデータソースシステム固有のデータマッピングを用いてデータを複数のファクトパーティションへパーティション化するためのデータマッパーと、を備えるシステムが提供される。

複数のファクトパーティションは、イベント発生を格納するためのイベント・ファクトパーティションを含んでよい。

複数のファクトパーティションは、数量を格納するための数量ファクトパーティションを含んでよい。

複数のファクトパーティションは、マネー量を格納するためのマネー・ファクトパーティションを含んでよい。

複数のファクトパーティションは、ＧＩＳ位置を格納するためのＧＩＳファクトパーティションを含んでよい。

複数のファクトパーティションは、パーセンタイル値を格納するためのパーセンタイル・ファクトパーティションを含んでよい。

複数のファクトパーティションは、参照値を格納するための参照ファクトパーティションを含んでよい。

複数のファクトパーティションは、データウェアハウス内か又は異なる位置のいずれかに格納された構造化されていないデータへのリンクを格納するための構造化されていないファクトパーティションを含んでよい。

少なくとも１つのファクトパーティション・データタイプは、少なくとも２つのファクトパーティション・データカテゴリであってよく、少なくとも２つのファクトパーティション・データタイプを格納することは、少なくとも２つのファクトパーティション・データタイプを、それぞれタイムスタンプ値を含む状態でファクトパーティションのうちの少なくとも２つに格納することを含んでよく、データをリポジトリから検索することは、ソーストランザクションを再構築するためにタイムスタンプ値を用いることにより少なくとも２つのファクトパーティション・データタイプを結合することを含んでよい。

複数のディメンションは、製品に関係するデータを格納することができる製品ディメンションを含んでよい。

複数のディメンションは、資産に関係するデータを格納することができる資産ディメンションを含んでよい。

複数のディメンションは、位置に関係するデータを格納することができる位置ディメンションを含んでよい。

複数のディメンションは、物理位置か又は論理位置のいずれかに関係するデータのうちの少なくとも１つを含んでよい。

複数のディメンションは、エンティティに関係するデータを格納することができるエンティティ・ディメンションを含んでよい。

別の態様によれば、データソースシステムに不可知のファクトカテゴリパーティション化データ情報リポジトリシステムであって、イベントを格納するためのイベント・ファクトパーティションと、数量を格納するための数量ファクトパーティションと、マネー量を格納するためのマネー・ファクトパーティションと、ＧＩＳ位置を格納するためのＧＩＳファクトパーティションと、パーセンタイル値を格納するためのパーセンタイル・ファクトパーティションと、参照値を格納するための参照ファクトパーティションと、を含む、複数のファクトパーティションと、ファクトパーティションに関連して格納された複数のディメンションであって、その複数のディメンションは、ファクトパーティションのそれぞれによって共有され、その複数のディメンションは、製品に関係するデータを格納することができる製品ディメンションと、資産に関係するデータを格納することができる資産ディメンションと、位置に関係するデータを格納することができる位置ディメンションと、エンティティに関係するデータを格納することができるエンティティ・ディメンションとを含む、複数のディメンションと、複数のデータソースシステム固有のデータマッピングと、複数のデータソースシステムからデータを受信するためのデータレシーバと、複数のデータソースシステム固有のデータマッピングを用いてデータを複数のファクトパーティションへパーティション化するためのデータマッパーと、を備えるデータリポジトリを備えるシステムが提供される。

別の態様によれば、データをデータソースシステムに不可知の情報リポジトリシステム内に格納するための方法であって、前記システムは、前記データリポジトリは、ファクトパーティション・データタイプによってパーティション化される、複数のファクトパーティションと、ファクトパーティションに関連して格納された複数のディメンションであって、その複数のディメンションは、ファクトパーティションのそれぞれによって共有される、複数のディメンションと、を備えるデータリポジトリを備え、前記方法が、データを受信することと、データを少なくとも１つのファクトパーティション・データタイプへパーティション化することと、少なくとも１つのファクトパーティション・データタイプを複数のファクトパーティションのうちの少なくとも１つに格納することと、ディメンションデータを生成することと、ディメンションデータを複数のファクトパーティションのうちの少なくとも１つに関連して複数のディメンションのうちの少なくとも１つに格納することとを含む、方法が提供される。

データは、少なくとも２つのデータソースから受信されてよく、パーティション化することは、データソースによってデータをパーティション化することを含んでよい。

本発明の他の態様も開示される。

何らかの従来技術の情報が本明細書で言及される場合、このような言及は、その情報が国内の当該技術分野での共通の一般知識の一部をなすことの自認を構成するものではないことが理解される。

本発明の範囲内に入り得るあらゆる他の形態があるにもかかわらず、本開示の好ましい実施形態がここで単なる例として添付図を参照しながら説明される。

従来技術のディメンション手法のデータウェアハウスを示す図である。 一実施形態に係るデータソースシステムに不可知のリポジトリを示す図である。 一実施形態に係るデータソースシステムに不可知の情報リポジトリをさらに示す図である。 図３のデータソースシステムに不可知の情報リポジトリが製品購入イベントトランザクションに適用される例示的なシナリオを示す図である。 図３のデータソースシステムに不可知の情報リポジトリが配達トラック移動イベントトランザクションに適用される例示的なシナリオを示す図である。 一実施形態に係るデータソースシステムに不可知の情報リポジトリに関する例示的なエンティティの関係性のダイヤグラムを示す図である。

本開示に係る原理の理解を促進する目的で、ここで図面に示された実施形態への言及を行い、同じものを説明するために特定の言葉が用いられる。それにもかかわらず、開示の範囲を限定することは意図されないことは理解されるであろう。当該技術分野の当業者は本開示を入手すると通常想到するであろう本明細書で例示される発明的な特徴のどの変更及びさらなる修正、並びに本明細書で例示される開示の原理のどのさらなる用途も、本開示の範囲内にあると考えられるものとする。

データソースシステムに不可知の、ファクトタイプ、又はカテゴリパーティション化リポジトリに関係する構造、システム、及び関連する方法が開示及び説明される前に、本開示は、そのように若干変化し得るものであるから、本明細書で開示された特定のディメンション構成、プロセスステップ、及び材料に限定されないことが理解される。開示の範囲は請求項及びその均等物によってのみ制限されるので、本明細書で使用される用語は、特定の実施形態を単に説明する目的で用いられ、限定するものとなることを意図されないことも理解される。

本開示の主題を説明し、特許請求するにあたり、以下に記載の定義に従って以下の用語が用いられる。

本明細書及び付属の請求項で用いられる場合の単数形（「一」、「一つ」、及び「その」）は、文脈上他の意味に明白に規定される場合を除き複数の指示対象を含むことに留意しなければならない。

本明細書で用いられる場合の「備える」、「含む」、「包含する」、「によって特徴づけられる」という用語、及びその文法上の均等物は、さらなる挙げられていない要素又は方法ステップを除外しない包括的な又は制限のない用語である。

以下の説明では、異なる実施形態における同様の又は同じ参照番号は同じ又は類似の特徴を表すことに留意されたい。

ここで図３に移ると、データソースシステムに不可知の情報リポジトリ８を備えるシステム１が示されている。

リポジトリ８は、複数の特定のファクト－カテゴリパーティション１６を備える。ファクトパーティション１６は、さらに詳細に後述するように、パーティションデータタイプ（イベント、数量、マネー、パーセンタイル、位置、参照、及び構造化されていないデータリンクデータタイプなど）によってパーティション化される。

図２によりよく例示されるように、各ファクトパーティションは、ファクトカテゴリ及び関連するファクト定義／記述を備える。

さらに、リポジトリ８は、ファクトパーティション１６に関連して格納される複数の共有ディメンション９を備える。

各パーティション１６は、ディメンションの共通性を有してよい。言い換えれば、共有ディメンション９のそれぞれは、パーティション化されたデータタイプのそれぞれによって概して一様に共有される。

上記で言及したように、ディメンションの共通性は、リポジトリ８が有限数のテーブルにより実装され得るという点でリポジトリ８の構造を簡易化し、これにより、クエリの挿入及び選択を簡易化する。さらに、ビジネスプロセスのカスタマイゼーションが必要とされる場合、正規化手法の場合のように新しいテーブルを必要とする代わりに、追加のカラムがディメンションテーブル内で使用されてよい。

複数の共有ディメンションに関連して格納される複数の特定のファクトパーティション（種々のファクトパーティション・データカテゴリによってパーティション化される）は、システム１が本質的にソースシステムに不可知となることを可能にする。

ここで、データをリポジトリ８内に格納することは、システム１がソースシステム２１からデータ２０を受信することを含む。

例えば、ソースシステム２１は、エンタープライズ・リソース・プランニング（ＥＲＰ）、ポイント・オブ・セール（ＰｏＳ）、在庫管理、ロジスティックス、又はＨＲ、業務、会計などの異なる運用システムに属する顧客関係管理（ＣＲＭ）タイプのシステムであり得る。

データをリポジトリ８内で検索及び格納する目的で、システム１は、データを検索及び処理するための種々のプラグイン１９（例えば、ＦＴＰファイル、統合ミドルウェアトランザクション、又はデータファイルなど）と共に構成されてよい。

データレシーバモジュール１８
プラグイン１９は、種々のソースデータシステム２１からデータをフェッチするように構成されたデータレシーバモジュール１８を含んでよい。例えば、プラグイン１９は、ＳＡＰプラントメンテナンス（ＳＡＰ ＰＭ）ソースＥＲＰモジュールへのプラグインであり得る。

データレシーバモジュール１８は、トランザクションイベントを実質的にリアルタイムでリスニングするエンタープライズ・サービス・バス（ＥＳＢ）レシーバであり得る。代替的な実施形態では、データレシーバモジュール１８は、データを定期的な間隔でフェッチ又は受信してよい。

データマッピングモジュール２４及びデータソースシステム固有のデータマッピング１７
プラグイン１９は、受信したデータを固有のデータソースシステム２１に従って種々のファクトパーティション１６（及びいくつかの実施形態では共有ディメンション９）へマップするように構成された、データマッピングモジュール２４をさらに含んでよい。

データマッピングモジュール２４は、異なるタイプのデータソースシステム２１に関して固有のファクトカテゴリ毎にデータをマップするための複数のデータソースシステム固有のデータマッピング１７を使用してよい。

このようにして、異なるデータソースシステム２１からのデータが、パーティション１６及びディメンション９内の適切な格納のために適切なマッピング１７によってそれぞれマップされる。

データマッピングは、ロードプロセスがデータベース構造９及び１６に密接に結合され、ソースシステムトランザクション２０との直接結合を保持せず、これにより、リポジトリをデータソースに不可知にするという点で、普通のデータウェアハウジング手法とは異なる。同様に、データソースシステムは、データウェアハウスがどのような形態にも変化することを必要とせずに、発生データの生成のために変化することができる。このリポジトリの静的な性質は、ビジネスが変化する場合であっても構造の頑健性が維持され、データが決して陳腐化されないことを保証する。この「ロード」プロセスに関するマッピングは、クライアントの情報の必要性に関してクライアントに一意のコンポーネントである。

ファクトパーティション・データカテゴリ
上記で言及したように、リポジトリ８は、固有のパーティション化データカテゴリによってパーティション化されるファクトパーティション１６を使用する。

固有のファクトパーティション・データカテゴリは、潜在的にあらゆる数のデータソースシステム２１からのすべてではないがほとんどの考えられるシナリオに関連してデータを格納することができるという点で、リポジトリ８に「普遍的なタイプ記述子能力」を与える。

好ましい実施形態では、ファクトパーティション１６は、図３に示される場合のファクトパーティションのタイプのすべてを含む。しかしながら、或る実施形態では、リポジトリ８内に格納され得る異なるタイプのトランザクションへの制限がある可能性があるにもかかわらずである（これは固有のデータソースシステム及び関連するトランザクションにとって問題ではない場合があり得る）。

例えば、マネー・ファクトパーティション１２は、マネーベースのトランザクションを取り扱わないデータソースシステム２１に関して省略されてよい。

データのカテゴライゼーションは、それらの組み合わされた効果が公知のあらゆるタイプのプロセス、ビジネス活動、イベント、及びデータのタイプからほとんどなんでも参照する能力を具体化することから明確に選択される。モデルは、電子装置から世界的規模での物体の物理的位置への詳細な読取値を保持することができ、現在のタイプの拡張をもたらすことになるいくつかの要件にほとんど又は全くならない（我々の現在の知識によれば）と想像される。この選択は、すべての点で完全であるが、任意の１つのクライアントに関するファクトの異なる命名を制約せず、むしろこれはファクトパーティション１６において表される情報タイプの例示となる。

ファクトパーティション１６は、イベント・ファクトパーティション１０を含んでよい。

イベント・ファクトパーティション１０は、購入イベント、配達イベント、従業員の雇用イベント、車両の修理イベント、子供の誕生イベント、及びそれらの表現において本来特異的な他のタイプのイベントなどのイベントタイプを格納してよい。

いくつかの実施形態では、イベントデータカテゴリは、計数データカテゴリを含んでよい。

ファクトパーティション１６は、数量を格納することができる数量ファクトパーティション１１をさらに含んでよい。これに関して、数量ファクトパーティション１１は、数値を含んでよい。

例えば、数量は、販売されたユニットの数を表してよく、したがって、整数データタイプを含む。代替的に、数量は、受け取った商品の重量を表してよく、したがって、浮動小数点データタイプを含む。

ファクトパーティション１６は、マネー量を格納することができるマネー・ファクトパーティション１２をさらに含んでよい。これに関して、マネー・ファクトパーティション１２は、数値を含んでよい。

例えば、マネー量は、製品が＄８．２５で買い付けられ、＄１０．５９で売られたことであり得る。したがって、マネーファクト・データカテゴリは、マネー量を少なくとも２桁の小数位及び潜在的にはそれ以上で格納することができる浮動小数点データタイプなどであり得る。

ファクトパーティション１６は、ＧＩＳ位置を格納することができるＧＩＳファクトパーティション１３をさらに含んでよい。例えば、ＧＩＳファクトパーティション１３は、資産が現在特定の位置に存在するというファクトを格納してよい。

いくつかの実施形態では、ＧＩＳファクトパーティション１７データカテゴリは、緯度及び経度を表すことができるように２つの浮動小数点データタイプを含む構造データタイプを含んでよい。

ファクトパーティション１６は、パーセンタイル値を格納することができるパーセンタイル・ファクトパーティション１４をさらに含んでよい。

例えば、パーセンタイル・ファクトパーティション１４は、付加価値税（ＶＡＴ）パーセンタイル値を格納してよい。これに関して、パーセンタイル・ファクトパーティション１４は、整数、浮動小数点値などの数値データタイプを格納してよい。

ファクトパーティション１６は、参照値を格納することができる参照ファクトパーティション１５をさらに含んでよい。

参照ファクトパーティション１５は、送り状番号、部品番号などの参照を格納するために用いられる。このように、参照ファクトパーティション１５は、例えば、文字列データ値と数値データ値との両方を格納することができるＶａｒｃｈａｒデータタイプを使用してよい。

ファクトパーティション１６は、構造化されていないデータへのリンクを格納するために使用され得る構造化されていないデータファクト１５をさらに含んでよい。例えば、法律事務所組織によって使用されるとき、構造化されていないデータは、特定の法律文書の位置を突き止めるＵＲＬ又は他のリソースロケータを表してよい。

共有ディメンション９
共有ディメンション９は、ファクトパーティション１６に関するコンテキストを提供するためにリポジトリ８によって使用される。

上記でさらに言及したように、共有ディメンション９は、特定のファクトカテゴリがディメンションの１つ１つとの関連を必要としない場合があるにもかかわらず、ファクトパーティション１６のそれぞれに共通である。

例えば、以下でさらに詳しく説明される製品ディメンション３に関して、製品ディメンション３は、ファクトパーティション１６のそれぞれによって共有されてよい。

このように、リポジトリ８は、１）１つの製品タイプが売られたこと、２）３つの製品が売られたこと、３）３つの製品が＄１０．５９で売られたこと、４）３つの製品が特定の位置において＄１０．５９で売られたこと、５）３つの製品が特定の位置において＄１０．５９で（１０％のＶＡＴを除いて）売られたこと、６）販売参照「ＳＡＬ－１３２６２」と共に３つの製品が特定の位置において＄１０．５９で（１０％のＶＡＴを除いて）売られたこと、及び７）特定のＵＲＬを用いてアクセス可能なＰＤＦ領収書を有する販売参照「ＳＡＬ－１３２６２」と共に３つの製品が特定の位置において＄１０．５９（１０％のＶＡＴを除いて）売られたことのいずれかを記録してよい。

また、好ましい実施形態では、データソースシステムに不可知の情報リポジトリ８は、図３に示すように共有ディメンション９のすべてを備える。しかしながら、いくつかの実施形態では、リポジトリ８に格納され得る異なるタイプのトランザクションへの制限がおそらくあるにもかかわらず、リポジトリ８のサブセットコンテキスト記述能力である、共有ディメンション９のサブセットが採用され得る（これは、或るタイプのトランザクションにおいてのみ取り扱う或るタイプのデータソースシステム２１にとって問題ではない場合があり得る）。

共有ディメンション９は、製品ディメンション３を含んでよい。製品ディメンション３は、商業製品（及びサービス）に関係する情報、例えば、鉄鉱石の品位、建築要素のタイプ（コンクリート、補強筋など）、銀行勘定タイプ、小売りアイテム、車、学校、医療処置、又はファクトパーティションのいずれかに関する任意の集合的なグループの関連付けを格納してよい。

共有ディメンション９は、種々の資産、例えば、ロジスティックスシステムからの車両、クレーン、クラッシャ、Ｘ線マシン、腕時計、携帯電話、プロジェクタ、又はラップトップ、本質において、関連する事業価値又は個人的価値を有する又は有さない場合がある任意の有形アイテムに関係するデータ、を格納するように構成された資産ディメンション３をさらに含んでよい。

共有ディメンション９は、物理的情報又は論理的情報などの位置情報を格納するための位置ディメンション２３をさらに含んでよい。

共有ディメンション９は、種々のエンティティに関連して情報を格納するためのエンティティ・ディメンション５をさらに含んでよい。エンティティ・ディメンション５は、人及び会社に固有の情報を格納するための人及び会社情報（図示せず）をさらに含んでよい。

共有ディメンション９は、さらなる未だ明示されていないディメンションタイプを格納するための追加のディメンション６及び７をさらに含んでよい。これらは、組織の必要性ごとに固有となり、特定の要件に関するモデルの一意の拡張を可能にするべく設計に含まれる。

一意のタイムスタンプデータ
ここで、一実施形態では、種々のデータが、一意のタイムスタンプを用いてファクトパーティション１６において関係付けられる。

したがって、ファクトパーティション１６における各エントリに関して、一意のタイムスタンプデータも格納される。

したがって、その後、ファクトパーティション１６からデータを検索するために、もし必要とされるときには該当するデータを再び組み立てるのに一意のタイムスタンプデータを用いる結合選択クエリが採用される。

リポジトリ８が実装されるならば、各ファクトパーティション１６内の特定のタイムスタンプデータカラムは、一意のものとして構成されてよい。

追加の組織固有のディメンション
ここで、ビジネス固有のカスタマイゼーションのために追加のサブジェクト固有のテーブルが追加される従来技術の正規化されたデータベース手法とは対照的に、該当する共有ディメンション９のデータベーステーブルにカラム／属性を追加することにより追加のコンテキスト情報がリポジトリ８内に格納されてよい。

実施例１－製品の販売
ここで図４に移ると、製品購入イベントトランザクションを格納するためのリポジトリ８の例示的な用途が示されている。

製品購入イベントトランザクションは、データレシーバ１８を用いて他の電子商取引トランザクションデータ内で定期的な間隔で検索され得る電子商取引データソースシステム２１によって最初に記録されてよい。

その後、データマッピング２４が、受信したトランザクションデータ２０を該当するファクトパーティション１６へマップし、これを、データソースシステム固有のデータマッピング１７を使用して共有ディメンション９にリンクする。

提供される例示的な実施形態では、ファクトパーティション・データカテゴリへのデータのパーティション化が実線で示される。

一意のカテゴリディメンションが破線で示され、追加の組織固有のディメンションが点線で示される。

具体的には、ウィジェットを買う顧客は、ソースシステム２１により購入イベントトランザクションへ振り分けられ（ｒｅｓｏｌｖｅｄ）、次いで、購入イベントを表すイベントパーティションテーブル１０へマップされ、ウィジェットを識別する製品共有ディメンションテーブル３へリンクされてよい。

その後、注文数量が数量ファクトパーティション１１内に格納されてよく、単価がマネー・ファクトパーティション１２に格納されてよく、１０％の税がパーセンタイル・ファクトパーティション１４に格納されてよい。

図から分かるように、データ自体から得られる又は例えばシステムクロックから生成される場合がある一意のタイムスタンプが、結合選択文を使用してそこからその後に検索することを可能にするべく、各ファクトパーティション内に格納される。

したがって、イベント・ファクトパーティション１０内に格納される特定の購入イベントに関して、関連する注文数量、単価、及び課税額が、同じタイムスタンプを使用する数量ファクトパーティション１１、マネー・ファクトパーティション１２、及びパーセンタイル・ファクトパーティション１４から検索され得る。

実施例２－移動するトラック
ここで図５に移ると、配達トラック移動イベントを格納するためのリポジトリ８のまたさらに例示的な用途が示されている。

具体的には、例示的な用途では、配達トラックが、第１の時間での第１の位置（緯度座標及び経度座標を含む）から第２の時間での第２の位置に移動する。

図から分かるように、データは、イベント・ファクトパーティション１０及びＧＩＳファクトパーティション１３へパーティション化されてよい。

さらに、車両ＩＤ、荷物番号、及び顧客番号が、外部キーによってイベント・ファクトパーティション１０及びＧＩＳファクトパーティション１３にリンクされる共有ディメンション９のテーブルにおいて追加のカラムを構成することにより、追加の組織固有のコンテキストとして格納されてよい。

一意のタイムスタンプデータが、イベント・ファクトパーティション１０及びＧＩＳファクトパーティション１０に対応するテーブル内に格納されることに加えて、第１及び第２の位置に対応する第１及び第２のタイムスタンプも、ＧＩＳファクトパーティション１３内に格納される。

上記の２つの例から分かるように、製品購入イベントトランザクションと移動イベントトランザクションとの両方を記録するのに同じファクトパーティション１６が使用され、組織固有のカスタマイゼーションが必要とされる場合、ファクトパーティション１６及び共有ディメンション９の基礎をなすテーブル構造を操作する必要性を回避するべく、共有ディメンション９のテーブルに追加のカラムが追加されてよい。

例示的なエンティティの関係性のダイヤグラム
図６に移ると、リポジトリ８の例示的なエンティティの関係性のダイヤグラムが示されており、表されるエンティティの関係性に関して、１は、単一のレコードを表し、０．．１は、ゼロ又は１つのレコードを表し、１．．１は、１対１の関係性を表し、１．．^＊は、一対多の関係性を表す。

さらに、カテゴライズされたファクトパーティションカテゴリが、それぞれの関連するトランザクションを有する丸みのある角部をもつ実線矩形／記述的ファクトを有する角張った角部をもつ破線矩形で示される。

角張った角部をもつ点線矩形で関連するトランザクションファクト１６に関連して示される共有ディメンション９も示されている。

さらに、ディメンションの強化版（ｅｎｒｉｃｈｍｅｎｔ）が、角張った縁部をもつ実線矩形で示され、例えば、エンティティ・ディメンション５は、潜在的に人エンティティ又は会社エンティティを表す関連するエンティティタイプを有するものとして示される。

さらに、結ぶラインは、外部キーの関係性を表し、矢印付きの隣接するラインは、親と子の関係性を表す。

例示的な技術的シナリオ
特定の実施形態に係るデータソースシステムに不可知のデータリポジトリの特徴及び機能をさらに例示するための例示的な技術的シナリオがここで提供される。

以下に提供される特定の実施形態は、主として例証する目的で提供され、したがって、固有の技術的実装の詳細を含むことに留意されたい。

しかしながら、本発明の実施形態は、これらの特定の技術的実装の詳細に限定されるものではなく、本発明の目的に適った範囲及び精神内でこれに修正がなされ得る。

以下の例示的な技術的シナリオは、Ｍｉｃｒｏｓｏｆｔ ．Ｎｅｔプログラミング言語及びＸＭＬ構造を用いてＭｉｃｒｏｓｏｆｔ ＳＱＬ（登録商標）２０１６データベース上で実装される。これは、任意のリレーショナルデータベース（例えば、Ｏｒａｃｌｅ、ＤＢ２、ＭｙＳｑｌ）又はＣｏｌｕｍｎａｒデータベース（例えば、ＮｏＳＱＬ、ＭｏｎｇｏＤＢ）、任意のプログラミング言語（例えば、Ｐｙｔｈｏｎ、Ｊａｖａ（登録商標）など）及び任意のメッセージ構造技術（例えば、Ｈｔｍｌ、ＪＳＯＮなど）を用いて実装され得る。

例示的な技術的シナリオ－開発努力１
最初に、ビジネスユーザ「Ｘ」は、ポイント・オブ・セールデータをビジネス分析フレキシブルリポジトリに包含することを望む。技術的には、ポイント・オブ・セールソリューションは、価格、製品、数量、及びいくつかの場合には報酬に基づく顧客の顧客情報への固有のトランザクション参照を有するＯｒａｃｌｅベースのトランザクションソリューションである。ＳＱＬデータベーステーブルは、ディメンション９を表すように設計及び構築される。

例示的な技術的シナリオ－開発努力１－クライアントフレームワークの開発
製品は、製品ディメンションテーブルに合わせた明示的に設計されたＸＭＬ構造からのＰｒｏｄｕｃｔ ｌｏａｄ．Ｎｅｔプログラムを介してロードされる。製品マスターソースは、スプレッドシートにおけるクライアントに関する製品の完全なリストを提供し、これは、開始される製品ＸＭＬ構造及び製品ディメンションロードへパースされる。

位置は、位置ディメンションテーブルに合わせた明示的に設計されたＸＭＬ構造からのＬｏｃａｔｉｏｎ ｌｏａｄ．Ｎｅｔプログラムを介してロードされる。位置マスターソースは、クライアントスプレッドシートにおけるクライアントとの関連性のある論理的と物理的との両方の位置の完全なリスト（店（Ｏｕｔｌｅｔ）、課（Ｄｉｖｉｓｉｏｎ）、部（Ｄｅｐａｒｔｍｅｎｔ）、建物（Ｂｕｉｌｄｉｎｇ））を提供し、これは、開始される位置ＸＭＬ及び位置ディメンションロードへパースされる。

エンティティは、エンティティ・ディメンションテーブルに合わせた明示的に設計されたＸＭＬ構造からのＥｎｔｉｔｙ ｌｏａｄ．Ｎｅｔプログラムを介してロードされる。エンティティマスターソースは、クライアントスプレッドシートにおける報酬プログラムファイルからのクライアントとの関連性のある顧客の完全なリストを提供し、これは、開始されるエンティティＸＭＬ及びエンティティ・ディメンションロードへパースされる。

ファクトパーティションテーブルは、ロードされる場合の作成されたファクトカテゴリとディメンションとの間の外部キー制約を通じて参照の一体性をもって定義される。

例示的な技術的シナリオ－開発努力１－一次成果物の開発
ソースデータベースは、オペレーショナルデータベースにおける３００を超えるテーブルを有する第３正規形に正規化されたデータベースである。データベーストリガは、カスタムビルトの格納された手順を開始するべく一次トランザクションテーブル上でＯｒａｃｌｅデータベースへ構築される。カスタムの格納された手順１９は、以下のようにユーザの文書化された要件に基づいて複数のＸＭＬレコードを作成する：
ａ．製品（製品ディメンション３）、販売トランザクション顧客（エンティティ・ディメンション５）、トランザクションの日時（タイムスタンプ）、及び小売店を表す位置レコード（位置ディメンション２３）へのフルキー値ペア参照を有するＸＭＬフォーマットの「販売」イベント・パーティション・ファクト、
ｂ．製品（製品ディメンション３）、販売トランザクションにおける製品の数量（数量ファクト１１）、トランザクションの日時（タイムスタンプ）、販売トランザクション顧客（製品ディメンション３）、及び小売店を表す位置レコード（位置ディメンション２３）へのフルキー値ペア参照を有するＸＭＬフォーマットの「販売」数量パーティションファクト、
ｃ．製品（製品ディメンション３）、販売トランザクションにおける製品（すなわち、ラインアイテム）を表すトランザクションのマネー値（マネーファクト１２）、トランザクションの日時（タイムスタンプ）、販売トランザクション顧客（エンティティ・ディメンション５）、及び小売店を表す位置レコード（位置ディメンション２３）へのフルキー値ペア参照を有するＸＭＬフォーマットの「販売」マネーパーティションファクト。

上記のレコードは、ディメンションテーブル「イベントタイプ」、「数量タイプ」、及び「マネータイプ」におけるファクトタイプビジネスキーを示すべく「販売」の特定の命名標準を有し、このビジネスキーは、それらのそれぞれのファクトカテゴリ内のウェアハウスにレコードを適正にタイプするべくロードプロセスによって用いられる。

作成されると、これらのレコードは、指定されたディレクトリ位置へ「パブリッシュされ」、そこでファイルリスナは、受信したレコードごとに設計されたロードプロセス１６のうちの１つを開始することになる。これらのロードプロセスは、作成されたＸＭＬファイルを使用し、コンテキスト（すなわち、製品、顧客、位置など）のＳＱＬ一意ＩＤを取得し、ディメンションテーブル９から検索される一意のキーを用いてＳＱＬ挿入文の対象となるファクトレコードを構築する．Ｎｅｔプログラムである。「販売」タイプに関する定義された最低限必要なディメンション関連付けが欠落している又はそのディメンションキーがまだロードされていない任意のレコードがデータベースにおけるパーキングロットテーブルに入れられ、不成功のレコードのサポートスタッフに警告するべく通知が送出される。これらは、レコードの不成功及び理由ごとに特定の顧客により定義されたプロセスによって対処される。

挿入されると、クライアントは、レポート又はダッシュボード／グラフィカルフォーマットのいずれかの格納されるデータを表面化するのにＭｉｃｒｏＳｔｒａｔｅｇｙ Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅマイニングツールを用いる。

例示的な技術的シナリオ－開発努力２
ビジネスユーザ「Ｘ」は、次いで、フレキシブルリポジトリに「製品のコスト」を作製するべく会計ソースシステムからのデータを追加することに決定する。レコードの金融システムは、レコードのシステムからの金融トランザクション及び他の詳細の抽出のためのＷｅｂサービスＡＰＩインターフェースを有するクラウドベースのＭＹＯＢソリューションである。

クラウドベースのデータベースへの直接のアクセスは存在しないので、「調達」情報の検索のためのＷｅｂサービスＡＰＩは、．Ｎｅｔで書かれたスケジュールされたプログラムから呼び出される。プログラムは、毎時に実行し、最後の呼び出しのタイムスタンプをもつＭＹＯＢクラウドにおける対象ＡＰＩを非同期的に呼び出し、次いで、ＡＰＩは、このクライアントに関するこの目的のためにタイムスタンプパラメータが事前に定義されたディレクトリ位置にＪＳＯＮフォーマットで提供されるので、金融システムに記録されたすべての購入を戻す。

ファイルリスナは、この例では出力ファイルの到着によりトリガされ（他で見つかる何らかのレコードが存在する場合は何もトリガされない）、これは次に、以下のように「購入」情報を複数のレコードへマップする「調達マッピング」．Ｎｅｔプログラムを開始する：
ａ．製品（製品ディメンション３）、購入トランザクション供給者（エンティティ・ディメンション５）、トランザクションの日時、及び小売店を表す位置レコード（位置ディメンション２３）へのフルキー値ペア参照を有するＸＭＬフォーマットの「購入」イベント・パーティション・ファクト－注：このＸＭＬ構造は、上記の開発努力１で開発された「販売」イベントパーティションと同じであり、
ｂ．製品（製品ディメンション３）、購入トランザクションにおける製品の数量（数量ファクト１１）、トランザクションの日時（タイムスタンプ）、購入トランザクション供給者（ディメンション５）、及び小売店を表す位置レコード（位置ディメンション２３）へのフルキー値ペア参照を有するＸＭＬフォーマットの「購入」数量パーティションファクト－注：このＸＭＬ構造は、上記の開発努力１で開発された「販売」数量パーティションと同じであり、
ｃ．製品（製品ディメンション３）、製品を表す購入トランザクションのマネー値（マネーファクト１２）、及び購入トランザクション供給者（エンティティ・ディメンション５）、トランザクションの日時（タイムスタンプ）、及び小売店を表す位置レコード（位置ディメンション２３）へのフルキー値ペア参照を有するＸＭＬフォーマットの「購入」マネーパーティションファクト－注：このＸＭＬ構造は、上記の開発努力１で開発された「販売」マネーパーティションと同じである。

上記のレコードは、ディメンションテーブル「イベントタイプ」、「数量タイプ」、及び「マネータイプ」におけるファクトタイプビジネスキーを示すべく「購入」の特定の命名標準を有する。このビジネスキーは、それらのそれぞれのカテゴリ内のウェアハウスにレコードを適正にタイプするべくロードプロセスによって用いられることになる。

作成されると、これらのレコードは、指定されたディレクトリ位置へ「パブリッシュされ」、そこでファイルリスナは、受信したレコードごとに設計されたロードプロセス１６のうちの１つを開始することになる。これらのロードプロセスは、上記の開発努力１の一部として設計及び構築された同じ．Ｎｅｔロードモジュールであり、したがって正確に同じく動作する。

挿入されると、クライアントは、レポート又はダッシュボード／グラフィカルフォーマットのいずれかの格納されるデータを表面化するのにＭｉｃｒｏＳｔｒａｔｅｇｙ Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅマイニングツールを用いる。ここで、より大きい分析及び報告の汎用性を可能にする同じ構造へロードされる２つのトランザクションタイプが存在することに注目されたい。

例示的な技術的シナリオ－開発努力３
ビジネスユーザ「Ｘ」は、次いで、フレキシブルリポジトリで入手可能な職員の詳細を作製するべく人的資源（「ＨＲ」）ソースシステムからのデータを追加することに決定する。レコードのＨＲシステムは、Ｗｉｎｄｏｗｓ（登録商標）Ｆｏｒｍｓアプリケーションフロントエンドの背後にあるＳＱＬサーバデータベース技術を用いるオンプレミスのインストールされたソリューションである。ソースシステムにおける最後に更新されたタイムスタンプに基づいてシステムからの各人に関する出力レコードを作成するべくカスタムＨＲソースシステムの格納された手順が構築される。プログラムは、人的資源データを抽出し、これを既存の組織エンティティ・ディメンションＸＭＬ構造へマップするＳＱＬのスケジュールされたタスクとして毎時に実行する。所与の名前、姓、及び生年月日上の．Ｎｅｔマッチングプログラムが、重複が不注意で作成されないことを保証するべく既存のＥｎｔｉｔｙ ｄｉｍｅｎｓｉｏｎ ｌｏａｄ．Ｎｅｔプログラムに追加される。修正されたエンティティＸＭＬ構造（最初のフレームワーク定義に従業員ＩＤが追加された）における抽出されたデータがＸＭＬ構造へマップされ、「挿入」ＳＱＬ命令上の重複をチェックした後で、追加された更新チェックに従ってレコードが「作成」、「更新」又は「削除」される（論理レコードは無効化のみ）。

開発努力１での「販売」プロセスに関する．Ｎｅｔプログラム及びＸＭＬが従業員に関連する「スタッフナンバー」をもつように更新され、抽出する格納された手順は、販売員の従業員ＩＤを提供する。以下の更新が行われる：
ａ．該当する「販売」パーティションファクトが、１つ１つのファクトタイプパーティションに関するエンティティへの第２の接続を可能にするべく「販売員」識別子をもつように強化される。

例示的な技術的シナリオ－開発努力４
ビジネスユーザ「Ｘ」は、次いで、フレキシブルリポジトリに分析のために利用可能な「職員の生産性」を作製するべく人的資源ソースシステムからの出勤データを追加することに決定する。カスタムＨＲソースシステムの格納された手順が、パラメータが提供されるときに日々の各従業員からの各タイムシートエントリに関する出力レコードを作成するべくタイムシートインジケータパラメータをもつように強化される。プログラムは、人的資源タイムシートデータを抽出し、これを指定されたファイル位置における各シフトの開始及びシフトの終了に関する既存の組織エンティティ・ディメンションＸＭＬ構造へマップするＳＱＬのスケジュールされたタスクとして日々実行する。ファイルリスナは、この例では出力ファイルの到着によりトリガされる（他で見つかる何らかのレコードが存在する場合は日曜日に何もトリガされない）、これは次に、以下のように「タイムシート」情報を複数のレコードへマップする「タイムシートマッピング」．Ｎｅｔプログラムを開始する：
ａ．従業員エンティティ（エンティティ・ディメンション５）、トランザクションの日時（タイムスタンプ）、及び小売店を表す位置レコード（位置ディメンション２３）へのフルキー値ペア参照を有するＸＭＬフォーマットの「ＳｈｉｆｔＳｔａｒｔ」イベント・パーティション・ファクト－注：同じく、このＸＭＬ構造は、上記の開発努力１で開発されたイベントパーティションと同じであり、
ｂ．従業員エンティティ（エンティティ・ディメンション５）、トランザクションの日時（タイムスタンプ）、及び小売店を表す位置レコード（位置ディメンション２３）へのフルキー値ペア参照を有するＸＭＬフォーマットの「ＳｈｉｆｔＥｎｄ」イベント・パーティション・ファクト－注：同じく、このＸＭＬ構造は、上記の開発努力１で開発されたイベントパーティションと同じである。

上記のレコードは、ディメンションテーブル「イベントタイプ」におけるファクトタイプビジネスキーを示すべく「ＳｈｉｆｔＳｔａｒｔ」及び「ＳｈｉｆｔＥｎｄ」の特定の命名標準を有し、このビジネスキーは、イベント・パーティション・ファクトカテゴリ内のウェアハウスにレコードを適正にタイプするべくロードプロセスによって用いられることになる。作成されると、これらのレコードは、指定されたディレクトリ位置へ「パブリッシュされ」、そこでファイルリスナは、受信したレコードごとに単一のイベントロードプロセス１０を開始することになる。これらのロードプロセスは、上記の開発努力１の一部として設計及び構築された同じ．Ｎｅｔロードモジュールであり、したがって、正確に同じく動作する。

挿入されると、クライアントは、レポート又はダッシュボード／グラフィカルフォーマットのいずれかの格納されるデータを表面化するのにＭｉｃｒｏＳｔｒａｔｅｇｙ Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅマイニングツールを用いる。ここで、より大きい分析及び報告の汎用性を可能にする同じリポジトリ構造にロードされる４つのタイプが存在することに注目されたい。

解釈
実施形態：
本明細書の全体を通して、「１つの実施形態」又は「一実施形態」への言及は、実施形態に関連して説明される特定の特徴、構造体、又は特色が本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書の全体にわたる種々の場所での「一実施形態では「１つの実施形態では」又は「一実施形態では」という文言の出現は、必ずしも同じ実施形態に言及するものではないが、同じ実施形態に言及する場合もある。さらに、特定の特徴、構造体、又は特色は、本開示から当業者には分かるように任意の適切な方法で１つ以上の実施形態において組み合わされてもよい。

同様に、本発明の例示的な実施形態の上記の説明では、本発明の種々の特徴は、開示を合理化し、種々の発明的な態様のうちの１つ以上の理解を助ける目的で、時には、単一の実施形態、図面、又はその説明において一緒にグループ化されることが理解されるであろう。この開示の方法は、しかしながら、特許請求される発明が各請求項で明確に列挙されるよりも多くの特徴を必要とするという意図を反映するものとして解釈されるべきではない。むしろ、以下の請求項が反映する場合の発明的な態様は、単一の上記の開示された実施形態のすべてよりも少ない特徴にある。したがって、「発明を実施するための形態」に後続する請求項は、この「発明を実施するための形態」にここで明確に組み込まれており、各請求項は、この発明の別個の実施形態としてそれ自身で独立している。

さらに、本明細書に記載のいくつかの実施形態は、いくつかの、しかし他の実施形態に含まれる他の特徴ではない特徴を含むが、当業者によって理解されるように、異なる実施形態の特徴の組み合わせが本発明の範囲内にあって、異なる実施形態を形成することを意図される。例えば、以下の請求項では、特許請求される実施形態のいずれかを任意の組み合わせで用いることができる。

対象の異なる事例
本明細書で用いられる場合の、他に規定されない限り、共通の対象を説明するための序数詞「第１の」、「第２の」、「第３の」などの使用は、同様の対象の異なる事例に言及することを単に表しており、そのように説明される対象が、一時的、空間的、格付け、又は任意の他の様態のいずれかの所与の順序でなければならないことを表すことは意図されない。

具体的な詳細
本明細書で提供される説明では、多くの具体的な詳細が記載される。しかしながら、本発明の実施形態はこれらの具体的な詳細なしに実施されてもよいことが理解される。他の場合には、周知の方法、構造体、及び技術は、この説明の理解を妨げないようにするために詳細に示されていない。

用語
図面に例示される本発明の好ましい実施形態を説明するにあたり、明瞭にするために具体的な用語が使用されることになる。しかしながら、本発明は、そのように選択された特定の用語に限定されることを意図されず、それぞれの具体的な用語は、同様の技術的目的を達成するために同様の様態で動作するすべての技術的均等物を含むことが理解される。「前方」、「後方」、「半径方向に」、「周方向に」、「上方に」、「下方に」などの用語は、基準点を提供するのに便利な言葉として用いられ、限定する用語として解釈されるべきではない。

備える及び含む
以下の請求項では、及び本発明の上記の説明では、表現言語又は必要な含意に起因して文脈が他を必要とする場合を除いて、「備え」という用語、若しくは「備えて」又は「備える」などの変形は、包括的な意味で、すなわち提示される特徴の存在を明記するが本発明の種々の実施形態でのさらなる特徴の存在又は追加を除外しないように用いられる。

本明細書で用いられる場合の、含む又は含み又は含んでという用語のいずれも開放型用語であり、これはまた、その用語に従う少なくともいくつかの要素／特徴を含むが他の特徴を除外しないことを意味する。したがって、含むは、備えると同じ意味である。

発明の範囲
したがって、本発明の好ましい実施形態と考えられるものが説明されているが、本発明の精神から逸脱することなく他の及びさらなる修正がなされてもよく、本発明の範囲内に入るすべてのこうした変化及び修正を特許請求することが意図されることを当業者は認識するであろう。例えば、上記で与えられるどのような方式も、用いられ得る手順の単なる代表である。機能は、ブロック図から追加又は削除されてもよく、動作は、機能ブロック間で置き換えられてもよい。ステップは、本発明の範囲内で説明される方法に追加又は削除されてもよい。

本発明は具体例を参照して説明されているが、本発明は多くの他の形態で具体化されてもよいことが当業者には分かるであろう。

説明した構成は、データウェアハウジング産業に利用可能であることが上記から明らかである。

Claims (20)

1. ファクトパーティション化データ情報リポジトリシステムであって、
   データリポジトリであって、
   複数のファクトパーティションと、
   前記ファクトパーティションに関連して格納された複数のディメンションであって、前記複数のディメンションは、前記ファクトパーティションのうちの１つ以上によって共有される、複数のディメンションと、
   を備える、データリポジトリと、
   複数のデータソースシステム固有のデータマッピングと、
   前記複数のデータソースシステムからデータを受信するためのデータレシーバと、
   前記複数のデータソースシステム固有のデータマッピングを用いてデータをデータカテゴリ又はタイプに従って複数のファクトパーティションへパーティション化するためのデータマッパーと、
   を備える、システム。
2. 前記複数のファクトパーティションが、イベント発生を格納するためのイベント・ファクトパーティションを含む、請求項１に記載のシステム。
3. 前記複数のファクトパーティションが、数量を格納するための数量ファクトパーティションを含む、請求項１又は２に記載のシステム。
4. 前記複数のファクトパーティションが、マネー量を格納するためのマネー・ファクトパーティションを含む、請求項１乃至３のいずれか一項に記載のシステム。
5. 前記複数のファクトパーティションが、ＧＩＳ位置を格納するためのＧＩＳファクトパーティションを含む、請求項１乃至４のいずれか一項に記載のシステム。
6. 前記複数のファクトパーティションが、パーセンタイル値を格納するためのパーセンタイル・ファクトパーティションを含む、請求項１乃至５のいずれか一項に記載のシステム。
7. 前記複数のファクトパーティションが、参照値を格納するための参照ファクトパーティションを含む、請求項１乃至６のいずれか一項に記載のシステム。
8. 前記複数のファクトパーティションが、データウェアハウス内か又は異なる位置のいずれかに格納された構造化されていないデータへのリンクを格納するための構造化されていないファクトパーティションを含む、請求項１乃至７のいずれか一項に記載のシステム。
9. 前記複数のファクトパーティションの少なくとも１つのファクトパーティション・データタイプが、少なくとも２つのファクトパーティション・データタイプであり、前記少なくとも２つのファクトパーティション・データタイプを格納することが、前記少なくとも２つのファクトパーティション・データタイプを、それぞれタイムスタンプ値を含む状態で前記ファクトパーティションのうちの少なくとも２つに格納することを含み、前記データをリポジトリから検索することが、ソーストランザクションを再構築するためにタイムスタンプ値を用いることにより前記少なくとも２つのファクトパーティション・データタイプを結合することを含む、請求項１乃至８のいずれか一項に記載のシステム。
10. 前記複数のディメンションが、製品に関係するデータを格納することができる製品ディメンションを含む、請求項１乃至９のいずれか一項に記載のシステム。
11. 前記複数のディメンションが、資産に関係するデータを格納することができる資産ディメンションを含む、請求項１乃至１０のいずれか一項に記載のシステム。
12. 前記複数のディメンションが、位置に関係するデータを格納することができる位置ディメンションを含む、請求項１乃至１１のいずれか一項に記載のシステム。
13. 前記位置に関係するデータが、物理位置か又は論理位置のいずれかに関係するデータのうちの少なくとも１つを含む、請求項１２に記載のシステム。
14. 前記複数のディメンションが、エンティティに関係するデータを格納することができるエンティティ・ディメンションを含む、請求項１乃至１３のいずれか一項に記載のシステム。
15. ファクトカテゴリパーティション化データ情報リポジトリシステムであって、
    データリポジトリであって、
    複数のファクトパーティションであって、
    イベントを格納するためのイベント・ファクトパーティションと、
    数量を格納するための数量ファクトパーティションと、
    マネー量を格納するためのマネー・ファクトパーティションと、
    ＧＩＳ位置を格納するためのＧＩＳファクトパーティションと、
    パーセンタイル値を格納するためのパーセンタイル・ファクトパーティションと、
    参照値を格納するための参照ファクトパーティションと、
    を含む、複数のファクトパーティションと、
    前記ファクトパーティションに関連して格納された複数のディメンションであって、前記複数のディメンションは、前記ファクトパーティションのそれぞれによって共有され、前記複数のディメンションは、
    製品に関係するデータを格納することができる製品ディメンションと、
    資産に関係するデータを格納することができる資産ディメンションと、
    位置に関係するデータを格納することができる位置ディメンションと、
    エンティティに関係するデータを格納することができるエンティティ・ディメンションと、
    を含む、複数のディメンションと、
    複数のデータソースシステム固有のデータマッピングと、
    複数のデータソースシステムからデータを受信するためのデータレシーバと、
    複数のデータソースシステム固有のデータマッピングを用いてデータをデータカテゴリ又はタイプに従って複数のファクトパーティションへパーティション化するためのデータマッパーと、
    を備える、データリポジトリ
    を備える、システム。
16. 前記ファクトパーティションが、構造化されていないデータ要素位置へのリンクを格納するための構造化されていないファクトパーティションをさらに含む、請求項１５に記載のシステム。
17. データをファクトパーティション化データ情報リポジトリシステム内に格納するための方法であって、前記システムが、コンピュータソフトウェアによって指令され、前記方法が、前記システムによって自動的に行われ、
    前記システムが、
    ファクトパーティション・データカテゴリによってパーティション化される、複数のファクトパーティションと、
    前記ファクトパーティションに関連して格納された複数のディメンションであって、前記複数のディメンションは、前記ファクトパーティションのそれぞれによって共有される、複数のディメンションと、
    を備えるデータリポジトリを備え、
    前記方法が、
    データを受信することと、
    前記データをデータカテゴリ又はタイプに従って少なくとも１つのファクトパーティション・データカテゴリへパーティション化することと、
    前記少なくとも１つのファクトパーティション・データカテゴリを前記複数のファクトパーティションのうちの少なくとも１つに格納することと、
    ディメンションデータを生成することと、
    前記ディメンションデータを前記複数のファクトパーティションのうちの少なくとも１つに関連して前記複数のディメンションのうちの少なくとも１つに格納することと、
    を含む、方法。
18. 前記データが、少なくとも２つのデータソースから受信され、前記パーティション化することが、前記データをデータカテゴリ又はタイプに従ってデータソースによってパーティション化することを含む、請求項１７に記載の方法。
19. 前記複数のファクトパーティションが、
    イベントを格納するためのイベント・ファクトパーティションと、
    数量を格納するための数量ファクトパーティションと、
    マネー量を格納するためのマネー・ファクトパーティションと、
    ＧＩＳ位置を格納するためのＧＩＳファクトパーティションと、
    パーセンタイル値を格納するためのパーセンタイル・ファクトパーティションと、
    参照値を格納するための参照ファクトパーティションと、
    構造化されていないデータ要素位置へのリンクを格納するための構造化されていないファクトパーティションと、
    のうちの少なくとも２つを含む、請求項１７に記載の方法。
20. 前記複数のディメンションが、
    製品に関係するデータを格納することができる製品ディメンションと、
    資産に関係するデータを格納することができる資産ディメンションと、
    位置に関係するデータを格納することができる位置ディメンションと、
    エンティティに関係するデータを格納することができるエンティティ・ディメンションと、
    のうちの少なくとも１つを含む、請求項１７に記載の方法。

Images