JP6450865B2 - 多数の重複するソースからの大量の時間データの集計 - Google Patents

Description

関連出願の相互参照
本出願は、２０１５年３月２０日出願の米国特許仮出願番号第６２／１３５，９８２号の優先権を主張し、その内容は、参照により本明細書に組み入れられる。

本開示は、データストレージシステムに関し、より具体的には、多数の重複するソースからの大量の時間データを集計するためのシステムに関する。

本項で説明される手法は、遂行されることができた手法であるが、必ずしも以前に想到されたかまたは遂行された手法ではない。したがって、本項で説明された手法は、本出願の請求項に対する従来技術ではない場合があり、本項に含まれることによって従来技術であると認められるものではない。

データベース管理システム及びデータウェアハウスは、多数のシステムからのデータを統合するために、抽出、変換、ロード（ＥＴＬ）のさまざまな実行を利用する。バッチ及び並列実行といった技術が利用可能であり、本分野にフォーカスした学術的及び産業的な出版物及びシステムが、幅広く存在する。しかしながら、これらのシステムは、データが多数の異なるソースからインポートされることを必要とする場合、これらのソースが重複する可能性がある、例えば多数のソース内の同じ要素に対する同じフィールドがあり、利用可能なソースから最善のソースを選択する必要性が生じる場合、すべてのソースがあらゆる動作処理ウィンドウの間中に利用可能であることが保証されず、更新の順番が前もって決められることができない場合、難しい動作シナリオを解読しない。さらに、集計された更新へのアクセスは、更新データ量または全領域データ量に関わらず、高速かつ水平拡張可能であるべきである。このデータ量に関与するサービス水準合意を達成することは、最低限の、もしあれば人手による介在がある、十分に自動化されたストレートスループロセッシングシステムを必然的に必要とする。

問題を例証するために、事業環境では、クライアントに対して、すべての更新されたデータを毎日利用可能にすることが必要とされる。これは、例えば２４時間の、動作処理ウィンドウである。技術的課題が存在するのは、（ａ）これらの更新は、多数の多様なソースシステムから得られることができ、いくつかのデータは、数個のソースと重複する、例えばｃｏｍｐａｎｙ＿ａのｓａｌｅｓ＿ｄａｔａは、ｓｏｕｒｃｅ＿１及びｓｏｕｒｃｅ＿３に、そして場合によってはｓｏｕｒｃｅ＿４に含まれる可能性があること、及び（ｂ）動作ウィンドウ（マルチ）の間中、数個のソースからの更新が、処理のために異なる時間で到着するかもしれず、加えて、すべてのソースが、各動作ウィンドウの間中に利用可能ではないかもしれないことに起因する。解決には、すべてのソース（１、３及び４）が利用可能であり得るか否かに関わらず、かつこれらのソースが利用可能にされる順序に関わらず、いずれのバージョンのデータ、例えばｃｏｍｐａｎｙ＿ａのｓａｌｅｓ＿ｄａｔａが用いられるべきかを選択する方法を提供する必要がある。さらに、これらの更新を照会するシステムは、処理されているデータ容量に関わらず、クエリの性能低下を経験するべきではない。クエリの性能低下は、データ量が増大するに従ってクエリ速度が低下することに関連する。

多数の重複するソースからの大量の時間データを集計し、更新の順番が前もって決められることができない場合に、動作処理ウィンドウ内のすべての利用可能なソースから最善のソースが用いられることを保証し、すべての集計された更新に対する高速なアクセスを提供するための方法及びシステムが提供される。

本方法は、（１）データ要素を受信することと、（２）データ要素を、時間経過にともなってデータ要素に生じた変更を包含する保留更新履歴リポジトリ内の対応するデータ要素と比較し、それによって比較をもたらすことと、（３）比較に基づいて、データ要素を変更したことを判定することと、（４）データ要素のためのより最新のデータを包含しているかもしれない、動作中の更新プロセスがないことを確認することと、（５）データ要素を、カットオフログにおける特定の時間範囲に関連付けられたカットオフ番号と関係付けることと、（６）（ａ）データ要素の現在の値と、データ要素の以前の値とを格納する全領域データリポジトリと、（ｂ）（ｉ）データ要素が更新されていることと、（ｉｉ）カットオフ番号とを示すレコードを格納するデルタデータリポジトリと、における対応するデータ要素を更新することと、を含む。

多数の重複するソースからの大量の時間データを集計するためのシステムのブロック図である。

図１のシステムによって利用されるファイル内の、いくつかのデータの例を提供する。

図１のシステム内のカットオフログ内の情報のストレージのための、代表的な構造の表の図である。

図１のシステムのリポジトリのデータモデルの構造の図である。

図１のシステムのリポジトリ内に格納され得る、いくつかのデータの例である。

図１のシステム内のプロセッサによって行われる方法の機能ブロック図である。

図２の方法によって利用される代表的な変換規則の表の図である。

図２の方法における、更新検出ステージの機能ブロック図である。

図２の方法によって用いられる状態機械論理の例を示す表である。

図２の方法のための更新されたデータの例を提供する表の図である。

図２の方法における、デルタ作成プロセスの機能ブロック図である。

１以上の図面に共通する構成又は特徴は、各図面において同じ参照番号で示されている。

本書は、多数の重複するソースからの大量の時間データを集計し、更新の順番が前もって決められることができない場合に、動作処理ウィンドウ内のすべての利用可能なソースから最善のソースが用いられることを保証し、すべての集計された更新に対する高速なアクセスを提供するための方法及びシステムを開示する。

図１は、多数の重複するソースから大量の時間データを集計するためのシステム１００のブロック図である。システム１００は、コンピュータ１１５、及び、ネットワーク１５０に通信可能に結合されたデータソース、すなわちソース１４５を含む。

ソース１４５は、複数のソース１４５ａ〜１４５ｎの総称であり、ソース１４５が任意の数のソースを含むことができることを示す。

ネットワーク１５０は、データ通信ネットワークである。ネットワーク１５０は、私的ネットワークまたは公衆ネットワークであってもよく、（ａ）例えば一室をカバーするパーソナルエリアネットワーク、（ｂ）例えば建物をカバーするローカルエリアネットワーク、（ｃ）例えばキャンパスをカバーするキャンパスエリアネットワーク、（ｄ）例えば都市をカバーするメトロポリタンエリアネットワーク、（ｅ）、例えば都市境界、地域境界、または国境を渡ってつながる領域をカバーする広域ネットワーク、または（ｆ）インターネットのうちのいずれかまたはすべてを含んでもよい。通信は、電子信号及び光信号によって、ネットワーク１５０を介して行われる。

コンピュータ１１５は、プロセッサ１２０と、プロセッサ１２０に結合されたメモリ１２５とを含む。本明細書では、コンピュータ１１５は、スタンドアロン装置として表されているが、それに限定されず、代わりに分散型処理システム内の他の装置（図示せず）に結合されることができる。

プロセッサ１２０は、命令に応答しそれを実行する論理回路構成で構成される電子装置である。

メモリ１２５は、コンピュータプログラムでエンコードされた、有形の非一時的コンピュータ可読記憶装置である。この点において、メモリ１２５は、プロセッサ１２０の動作を制御するために、プロセッサ１２０によって読み取り及び実行可能であるデータ及び命令、すなわちプログラムコードを格納する。メモリ１２５は、ランダムアクセスメモリ（ＲＡＭ）、ハードドライブ、リードオンリーメモリ（ＲＯＭ）、またはそれらの組み合わせに組み入れられ得る。メモリ１２５のコンポーネントのうち１つは、プログラムモジュール１３０である。

プログラムモジュール１３０は、プロセッサ１２０を、本明細書で説明された方法を実行するように制御するための命令を包含する。用語「モジュール」は、本明細書においては、スタンドアロンのコンポーネントとして、または複数の下位コンポーネントの一体型の構成としてのいずれかで具現化され得る機能的動作を意味するために用いられる。このように、プログラムモジュール１３０は、単一のモジュールとして、または互いに協働する複数のモジュールとして、組み入れられ得る。本書においては、プログラムモジュール１３０またはその下位モジュールによって行われている動作を説明する場合、当該動作は、実際にはプロセッサ１２０によって行われている。プログラムモジュール１３０は、本明細書においては、メモリ１２５にインストールされ、そのためソフトウェアに組み入れられているとして説明されているが、ハードウェア（例えば、電子回路構成）、ファームウェア、ソフトウェア、またはそれらの組み合わせのうちのいずれかに組み入れられることができる。

プログラムモジュール１３０は、メモリ１２５内にすでにロードされているとして示されているが、記憶装置１２７上において、メモリ１２５に後にロードされるように構成されてもよい。記憶装置１２７は、プログラムモジュール１３０を格納する、有形の非一時的コンピュータ可読記憶装置である。記憶装置１２７の例は、コンパクトディスク、磁気テープ、リードオンリーメモリ、光記憶媒体、ハードドライブ、または多数の並列ハードドライブで構成されるメモリユニット、及びユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブを含む。代替的に、記憶装置１２７は、ランダムアクセスメモリ、または、リモートストレージシステム上に位置し、ネットワーク１５０を介してコンピュータ１１５に結合された他のタイプの電子記憶装置であることができる。

フィールド要素ファイル１０５、更新用要素ファイル１３５、及び変更済み要素ファイル１４０は、システム１００内の中間データストアとして用いられるデータ項目であり、メモリ１２５に格納される。フィールド要素ファイル１０５は、複数のフィールド要素ファイル１０５ａ〜１０５ｎの総称であり、フィールド要素ファイル１０５が任意の数のフィールド要素ファイルを含むことができることを示す。更新用要素ファイル１３５は、複数の更新用要素ファイル１３５ａ〜１３５ｎの総称であり、更新用要素ファイル１３５が任意の数の更新用要素ファイルを含むことができることを示す。変更済み要素ファイル１４０は、複数の変更済み要素ファイル１４０ａ〜１４０ｎの総称であり、変更済み要素ファイル１４０が任意の数の変更済み要素ファイルを含むことができることを示す。フィールド要素ファイル１０５、更新用要素ファイル１３５、及び変更済み要素ファイル１４０は、互いに同じ構造を有する。

図１Ａは、フィールド要素ファイル１０５内のファイル内の何らかのデータの一例を提供する。当該例は、事業体に対する汎用データ番号付けシステム（ＤＵＮＳ）の番号、及びそれに関連付けられたいくつかの事業体連絡先情報を示す。格納されることができるデータのタイプに制限はない。

システム１００は、いくつかのデータベース、すなわちカットオフログ１５２、全領域データリポジトリ１５５、デルタデータリポジトリ１６０、及び保留更新履歴リポジトリ１６５を含む。

カットオフログ１５２は、カットオフ番号及び関連情報のためのストレージである。処理パイプラインが実行され、基礎となるデータに抗した変更が記録されるたびに、その処理パイプラインからの新しいデータセットのすべてが、カットオフ番号と呼ばれる新しい連番で刻印される。この番号は、特定の時になされるすべての変更に関連する。カットオフ番号は、カットオフログ１５２に順次格納される。

図１Ｂは、カットオフログ１５２内の情報のストレージのための、代表的な構造内のデータの表、すなわち表１９０の図である。この例は、カットオフ番号３、４、５及び６によって特定される４つの更新期間を示す。更新範囲開始及び更新範囲終了は、ｙｙｙｙ−ｍｍ−ｄｄ＿ｈｈ：ｍｍ：ｓｓ（すなわち、年月日＿時分秒）の形式の日付である。

全領域データリポジトリ１５５は、すべての要素の完全なマスターリストと、それらの現在の値及び以前の値とを保存するために用いられる。デルタデータリポジトリ１６０は、更新ごとに、特定の時間に更新された要素のみを包含するデルタ表を包含する。保留更新履歴リポジトリ１６５は、各要素に対して時間経過にともなって生じたすべての変更を包含する。

図１Ｃは、全領域データリポジトリ１５５、デルタデータリポジトリ１６０、及び保留更新履歴リポジトリ１６５のデータモデルの構造の図である。図１Ｃに示された特徴は、以下の通りである。
（ａ）要素ベースは、ヘッダ及びペイロードを包含する。
（ｂ）ヘッダは、以下を含む多くのフィールドを包含する。
ｅｎｔｉｔｙ Ｉｄ：固有の実体を参照するｉｄ、例えばＤＵＮＳ番号
ｅｌｅｍｅｎｔ Ｎａｍｅ：この要素固有の名称
ｔｉｍｅｓｔａｍｐ：最終更新の日付及び時間
ｈａｓｈ：データベース検索を加速させるために、この特定のレコードを参照する固有の値
（ｂ）ペイロードは、アトミックまたは集計タイプの要素を包含する。
（ｄ）アトミック要素は、精密なかつ単一の意味を有し、以下を包含する。
ｉｄ：この特定の要素を参照する固有のｉｄ
ｖａｌｕｅ：当該要素の実際値
ｈａｓｈ：データベース検索を加速させるために、この特定のレコードを参照する固有の値
ａｔｔｒｓ：この要素に関連付けられた多数の属性、例えばデータのソース、カットオフ番号
（ｅ）集計要素は、多数のアトミック要素を組み合わせた結果、または算出された／導き出された値を包含し、以下で構成される。
ｉｄ：この特定の要素を参照する固有のｉｄ
ｈａｓｈ：データベース検索を加速させるために、この特定のレコードを参照する固有の値
ｅｌｅｍｅｎｔ：この集計要素を作り上げる要素のリスト

図１Ｄは、どのようにして全領域データリポジトリ１５５、デルタデータリポジトリ１６０、及び保留更新履歴リポジトリ１６５においてデータが表されるかの一例の図である。この例は、実体についての２つの部分的レコード（１２３４５６７８９及び９８７６５４３２１）を示す。実体ごとに、図１Ｄの左右に図示された４つの要素があり、組織、都市、標準産業分類（ＳＩＣ）、及び従業員数をカバーしている。中央の表は、どのようにしてこれらの要素が、実体の完全レコードに組み合わせられるかを示す。

図２は、プロセッサ１２０によってプログラムモジュール１３０内の命令に従って行われる方法２００の機能ブロック図である。方法２００では、プロセッサ１２０は、ソース１４５からの大量の時間データを集計して、全領域データリポジトリ１５５及びデルタデータリポジトリ１６０内のデータセットにする。ソース１４５は、ソース１４５ａ、ソース１４５ｂ、及びソース１４５ｃ乃至ソース１４５ｎを含む。方法２００は、準備及び要素化ステージ２０５、更新検出ステージ２２０、及びフォールドオーバステージ２３５を含む。

準備及び要素化ステージ２０５では、要素化プロセス２１５は、ソース１４５からファイルを受信する。要素化プロセス２１５は、ファイル／フィールド（ソース１４５からの）を、データ要素（図１Ａ参照）に変換する。ファイルは、ソース１４５から、予め定められることができない順番で到着し、各ファイルは、フィールドを包含し得、全領域データリポジトリ１５５及びデルタデータリポジトリ１６０内のデータセットのために必要とされる重複するフィールド、すなわち多数のファイルにおいて同じフィールドを含む。

要素化プロセス２１５は、ソース１４５からファイル／フィールドを受信し、変換指定（ｓｐｅｃ）２１０を用いて、フィールド要素ファイル１０５に格納されたフィールド要素を作成する。要素化プロセス２１５は、ソース１４５の各々に対して、フィールド要素ファイル１０５のうち対応するものを作成する。例えば、要素化プロセス２１５は、ソース１４５ａに対してはフィールド要素ファイル１０５ａ、ソース１４５ｂに対してはフィールド要素ファイル１０５ｂ等を作成する。要素化プロセス２１５は、ソース１４５ａ、１４５ｂ、及び１４５ｃ乃至１４５ｎからのファイルを、順次または並行して処理することができる。

ソース１４５内のフィールドと、フィールド要素ファイル１０５内の要素との間で１対１の関係、１対多の関係、または多対１の関係があることができる。

１対１の関係では、ソース１４５に含まれるデータフィールドが、フィールド要素ファイル１０５内のフィールド要素に直接マッピングされる。例えば、ソース１４５ａからのフィールドＡは、フィールド要素ファイル１０５ａ内のフィールドＡに直接マッピングされる。

１対多の関係では、ソース１４５内の単一のデータフィールドが、フィールド要素ファイル１０５内の多数のフィールド要素にマージされることができる。例えば、ソース１４５ａからのフィールドＢは、フィールド要素ファイル１０５ａ内のフィールドＣ、フィールドＤ、及びフィールドＥにマージされるかまたはそれらによって用いられる。

多対１の関係では、ソース１４５内の多数のフィールドが、フィールド要素ファイル１０５内の１つのフィールドにマージされることができる。例えば、ソース１４５ａからのフィールドＦ、フィールドＧ、フィールドＨは、フィールド要素ファイル１０５ａ内のフィールドＪにマージされる。

これらの関係は、変換指定２１０において、行われる変換を記述する規則及びプロセスに同調して定義される。

図２Ａは、変換規則の例の表、すなわち表２９０の図である。この例では、「ＩｎｄｕｓｔｒｙＣｏｄｅ［Ｄ＆ＢＩｎｄｕｓｔｒｙＣｏｄｅ］［１］」は、１対多の関係であり、「マッピング」欄に記載されているような値及び属性を用いて、フィールド
ＧＢＷＲ＿ＵＳ＿１９８７＿ＳＩＣＳ１、
ＧＢＷＲ＿ＵＳ＿１９８７＿ＳＩＣＳ１＿ＤＮＢ＿ＩＮＤ＿ＴＹＰＥ＿ＣＯＤＥ＿ＮＯＲＭＡＬＩＺＥＤ、
ＧＢＷＲ＿ＵＳ＿１９８７＿ＳＩＣＳ１＿ＤＮＢ＿ＩＮＤ＿ＴＹＰＥ＿ＴＥＸＴ＿ＮＯＲＭＡＬＩＺＥＤ、
ＧＢＷＲ＿ＵＳ＿１９８７＿ＳＩＣＳ１＿ＤＮＢ＿ＩＮＤ＿ＣＯＤＥ＿ＤＥＳＣ＿ＮＯＲＭＡＬＩＺＥＤ、及び
ＥＤＧＥＤ＆ＢＳＴＡＮＤＡＲＤ
にマッピングしている。

図２を再度参照すると、更新検出ステージ２２０は、変更検出プロセス２２５及び適用事業体規則プロセス２３０を含む。更新検出ステージ２２０は、通常の動作サイクルの一部として、通例は毎日稼働するが、より頻繁であることができる。

変更検出プロセス２２５は、ダウンストリームマッピング及び比較のために、フィールド要素ファイル１０５を用いる。変更検出プロセス２２５は、全フィールド要素ファイル１０５にわたるすべての変更された要素を検出する。これらの変更は集計され、変更検出プロセス２２５は、フィールド要素ファイル１０５内のフィールド要素を、保留更新履歴リポジトリ１６５内のこれらの要素の現在の値と比較する。

適用事業体規則プロセス２３０は、全領域データリポジトリ１５５及びデルタデータリポジトリ１６０内のいずれのフィールド要素値を実際に更新するかを決定する事業体規則論理を適用する。上述のように、要素化プロセス２１５は、ソース１４５ａ、１４５ｂ及び１４５ｃ乃至１４５ｎからのファイルを、順次または並行して処理することができる。このように、要素化プロセス２１５によってソース１４５ａ、１４５ｂ、１４５ｃ乃至１４５ｎからのファイルを処理することは、すべて同時に始めることができる。適用事業体規則プロセス２３０は、時間的な完全性を管理し、要素化プロセス２１５がソース１４５を並行処理したとしても、更新を順番にのみリリースする。また、各ファイルのコンテンツ及びサイズに依存して、いくつかが他よりも早く処理されてもよく、そして、適用事業体規則プロセス２３０は、時間的な完全性の確認を行い、更新が正しい順序で適用されることを保証する。

フォールドオーバステージ２３５は、デルタ作成プロセス２４０を含む。

デルタ作成プロセス２４０は、大容量の集計データの高速な検索を可能にする。デルタ表、例えばデルタ表２４５は、デルタデータリポジトリ１６０内の更新ごとに作成され、これは、特定の時間に更新された実体のみを包含する。システム１００では、個々の事業実体が、固有の識別子、例えばＤＵＮＳ番号によって固有に特定可能である。デルタ表２４５は、実体のすべての要素を包含し、これは、例えばＤＵＮＳ番号によって特定可能であり、全領域データリポジトリ１５５のフルスキャンを強いるのではなく、特定の更新時間での要素変更の高速な検索を可能にする。

図３は、更新検出ステージ２２０の機能ブロック図である。図３では、吹き出し３−１、３−２、３−３、３−４及び３−５を接続することによって、いくつかのラインが表される。例えば、吹き出し３−１の接続は、フィールド要素ファイル１０５から変更を検出するプロセス３２０までのライン、すなわちデータの流れを表す。上述のように、更新検出ステージ２２０は、変更検出プロセス２２５及び適用事業体規則プロセス２３０を含む。上記でさらに述べられるように、変更検出プロセス２２５は、すべての変更された要素を、すべてのフィールド要素ファイル１０５全体にわたって検出し、変更を集計し、フィールド要素ファイル１０５内のフィールド要素を、保留更新履歴リポジトリ１６５内のこれらの要素の現在の値と比較する。これらの動作を行うために、変更検出プロセス２２５は、変更を検出するプロセス３２０を含む。

変更を検出するプロセス３２０は、フィールド要素ファイル１０５を受信し、データカタログ３０５にアクセスする。

データカタログ３０５は、要素ｉｄ、要素記述、及び要素固有の名称を包含する。例えば、値「００７」の要素ｉｄは、要素記述「Ｕｎｉｑｕｅ Ｅｎｔｉｔｙ Ｉｄｅｎｔｉｆｉｅｒ」及び要素固有の名称「ＥｎｔｉｔｙＩｄ」を備える。

上述のように、保留更新履歴リポジトリ１６５は、各要素に対して時間経過にともなって生じたすべての変更を包含する。したがって、変更を検出するプロセス３２０は、フィールド要素ファイル１０５ａ〜１０５ｎ内の要素が、保留更新履歴リポジトリ１６５内のそれらの要素に対する現在の値とは異なるかを判定する。実際に変更されたすべての要素は、変更済み要素ファイル１４０ａ〜１４０ｎに格納される。変更されたフィールド要素のみが、適用事業体規則プロセス２３０に進められる。

上述のように、適用事業体規則プロセス２３０は、全領域データリポジトリ１５５及びデルタデータリポジトリ１６０内のいずれのフィールド要素値を実際に更新するかを決定する事業体規則論理を適用する。保留更新履歴リポジトリ１６５が更新される必要があるかを判定するために、適用事業体規則プロセス２３０は、更新が、順番が予め決められることができない多数のソースから得られることができることを考慮した論理を適用する。これらの動作を行うために、適用事業体規則プロセス２３０は、規則を適用するプロセス３３０及び更新をリリースするプロセス３３５を含む。

規則を適用するプロセス３３０は、状態機械論理を使用して、更新が受信される順序とは無関係に、どのようにして更新が適用されるかを判定する。この点において、規則を適用するプロセス３３０は、最善の品質規則３２５を利用して、更新を評価し、状態遷移を判定し、そしてどのようにして更新が適用されるかを判定する。

図３Ａは、どのようにして３つの異なるソースから得られたデータに状態機械論理が適用されるかの一例を示す表、すなわち表３９０の図である。グループＡは、ソース：Ｓ１（１４５ａ）から得られた要素のための規則を示し、グループＢは、ソース：Ｓ２（１４５ｂ）のための規則を示し、グループＣは、ソース：Ｓ３（１４５ｃ）のための規則を示す。これらは、単なる説明のための例である。

最善の品質は、ソース１４５ａ〜１４５ｎのいずれが、要素に対して最善の、そして次に最善のデータ等を包含するかの定義である。要素は、関連付けられたタイムスタンプを有する。各最善の品質規則は、もしあれば、要素のソースに基づいて、要素に何の変更がなされるか、タイムスタンプがより新しいか、及び要素の現在の値のソースがより良い品質のソースからであるか否かを記述する。

最善の品質規則３２５は、更新決定をすることができる前に、２つ以上のソース１４５からの値が存在することを必要としない。用いるための値は、成し遂げた更新のみならず、保留更新履歴リポジトリ１６５及びソース１４５ａ〜１４５ｎにおける更新の現在値にも依存する。例えば、保留更新履歴リポジトリ１６５内の直近の要素の値は、ソース１４５ａ（すなわち、前のソース）から得られたかもしれず、同じ要素に対するソース１４５ｂ（すなわち、現在のソース）からの別の更新は、その後検出される。規則を適用するプロセス３３０は、最善の品質規則３２５を利用して、保留更新履歴リポジトリ１６５が更新されるべきか否かを判定する。

時間的な完全性が維持されることを保証するために、更新は、要素化プロセス２１５及び／または変更を検出するプロセス３２０によって、順番にまたは並行して処理され得るが、これらは更新をリリースするプロセス３３５によって順番にリリースされる。

更新をリリースするプロセス３３５は、より古い更新プロセスの前により新しい更新プロセスが終了したかを監視し、そうであれば、更新されたデータは、より古いプロセスが終了するまでリリースされないが、これは、両方のプロセスが同じ要素に変更を適用し得るためである。更新をリリースするプロセス３３５は、保留更新履歴リポジトリ１６５内に更新を格納し、更新されたカットオフ番号が各更新に適用される。上述のように、カットオフ番号は、各更新に適用され、その特定の時間でなされたすべての変更に関連する。よって、更新をリリースするプロセス３３５は、カットオフログ１５２にカットオフ番号を順次格納する。

図３Ｂは、更新されたデータの例を提供する表、すなわち表３９５の図である。表３９５は、要素ＳｔｒｅｅｔＡｄｄｒｅｓｓＬｉｎｅ１に対する２つの更新の例を示す。この更新の値は、「ｖａｌｕｅ」属性にタイムスタンプ「２０１５−０１−０６Ｔ１３４４５４Ｚ」で生じた「５６０ＢＲＯＡＤＷＡＹ ＲＭ ５１０」として示される。各更新には、カットオフ番号も与えられ、すべての変更ポイントを追跡することが可能になる。この場合、「ｃｕｔｏｆｆ」は、この更新に対して「７」と設定される。更新のソースは、「ソース」属性に示され、この例では、ソースは「ｗｏｒｌｄｂａｓｅ４３７０」である。この要素に対する第２の更新は、タイムスタンプ「２０１５−０１−１３Ｔ１１５９１４Ｚ」で生じたとして示され、要素値を「５６０ＢＲＯＡＤＷＡＹ ＲＭ ５３０」に変更する。「ｃｕｔｏｆｆ」値は、「９」と設定される。カットオフログ１５２は、関連付けられた日付及び時間範囲を各カットオフ番号に関連付けて格納し、これによって、すべての更新ポイントを容易に追跡することが可能になる。

図４は、デルタ作成プロセス２４０の機能ブロック図であり、これは、上述のように、大容量の集計されたデータの高速な検索を可能にする。デルタ作成プロセス２４０は、全実体をアセンブルするプロセス４０５と、デルタ表を作成するプロセス４１０とを含む。全実体をアセンブルするプロセス４０５及びデルタ表を作成するプロセス４１０は、周期的な動作更新サイクル中にインスタンス化される。

上述のように、全領域データリポジトリ１５５は、すべての要素の完全なマスターリストと、それらの現在の値及び以前の値とを保存するために用いられる。よって、全実体をアセンブルするプロセス４０５は、更新用要素ファイル１３５ａ〜１３５ｎを読み取り、全領域データリポジトリ１５５に対する最新の更新を書き込み、全領域データリポジトリ１５５から最も古い更新を取り除く。このように、全実体をアセンブルするプロセス４０５は、全領域データリポジトリ１５５内の直近の更新及び以前の更新のみを保存する。

デルタ表を作成するプロセス４１０は、更新用要素ファイル１３５ａ〜１３５ｎを読み取り、これらをデルタデータリポジトリ１６０に書き込む。変更ごとに、デルタ表を作成するプロセス４１０は、デルタデータリポジトリ１６０において、その更新時間で更新された要素のみを包含するデルタ表を作成する。デルタ表は、実体（ＤＵＮＳ）のすべての要素を包含する。変更された値は、デルタ表と同じ名称を有するカットオフ番号を有する。このことは、実体及びその特定の更新時間での変更の高速な検索を可能にし、それによって、変更を判定するために、全領域データリポジトリ１５５の全表のスキャンが必要ではないことを保証する。

デルタ表がない場合、システム１００の出力を用いるシステムは、全領域データリポジトリ１５５をスキャンして、何らかの変更がなされたかを判定する必要がある。大容量のデータを備えるシステムには、このスキャンは、非常に時間がかかり、さらなるデータを付加するためにさらなる時間がかかる。デルタデータリポジトリ１６０内のデルタ表は、特定の更新時間でなされた更新を格納する。各デルタ表は、対応するカットオフ番号でマークされる。カットオフログ１５２は、固有のカットオフ番号によってマークされた全更新期間のリストを保管する。特定の時間範囲内になされた更新を判定するために、カットオフログ１５２をスキャンして、関連するカットオフ番号のリストを取得することができる。これらのカットオフ番号を用いて、デルタデータリポジトリ１６０内の対応するデルタ表は、要求された期間におけるすべての更新についてスキャンされることができる。

全領域データリポジトリ１５５及びデルタデータリポジトリ１６０は、デルタ作成プロセス２４０によって更新された後、発行準備される。

実施例

１）ソース１４５ａがフィールドＡを包含し、ソース１４５ｂがフィールドＡを包含すると仮定する。

２）要素化プロセス２１５は、変換ｓｐｅｃ２１０を用いて、フィールドＡを要素に変換する方法を判定する。この場合、要素Ａへの１対１の変換である。要素化プロセス２１５は、フィールド要素ファイル１０５ａ及び１０５ｂを作成し、各々が要素Ａを包含する。

３）変更を検出するプロセス３２０は、フィールド要素ファイル１０５ａ及び１０５ｂを読み取り、保留更新履歴リポジトリ１６５内の要素Ａの現在の値を読み取り、データカタログ３０５を用いて、要素Ａが変更されたかを判定する。この場合、要素Ａは変更されており、変更済み要素ファイル１４０ａ及び１４０ｂは、要素Ａを包含して作成される。

４）規則を適用するプロセス３３０は、最善の品質規則３２５を用いて、（変更済み要素ファイル１４０ａから、または変更済み要素ファイル１４０ｂからの）いずれの要素Ａを用いるかを判定する。この場合、変更済み要素ファイル１４０ｂからの要素Ａが用いられる。更新用要素ファイル１３５ｂは、変更済み要素ファイル１４０ｂからの要素Ａの値で書き込まれる。

５）更新をリリースするプロセス３３５は、時間的な完全性を確認して、より最新のデータを包含するかもしれない関連する更新プロセスが、依然として稼動中ではないことを確かめる。本実施例では、稼動中のプロセスがなく、そのため更新用要素ファイル１３５ｂからの要素Ａに対する更新がリリースされて、保留更新履歴リポジトリ１６５に書き込まれる。現在の更新時期の間の新しいカットオフレコードは、順次割り当てられたカットオフ番号で、カットオフログ１５２に付加される。

６）全実体をアセンブルするプロセス４０５は、更新用要素ファイル１３５ｂから全領域データリポジトリ１５５までの要素Ａに対する更新を適用し、要素Ａの以前の値を保持する。デルタ表を作成するプロセス４１０は、要素Ａに対する更新を、デルタデータリポジトリ１６０内の新しいデルタ表（新しいカットオフ番号が付される）に適用し、新しいカットオフ番号を、要素Ａの更新された詳細に適用する（図３Ｂ参照）。

システム１００は、更新の順番を前もって決められることができない場合に、動作処理ウィンドウ内のすべての利用可能なソースから最善のソースが用いられることを保証し、すべての集計された更新に対する高速なアクセスを提供する。システム１００は、動作処理ウィンドウ内で更新を、例えば２４時間適用することによって、このことを達成する。動作処理ウィンドウは、システム１００がいずれかのソース１４５からの更新を待っているかに関わらず、更新を生じさせる。これらの更新は、多数の多様なソース１４５から得ることができ、いくつかのデータは、数個のソース１４５で重複する、例えばｃｏｍｐａｎｙ＿ａのｓａｌｅｓ＿ｄａｔａがソース１４５ａ及びソース１４５ｂ、ならびに場合によってはソース１４５ｃに含まれる可能性がある。動作ウィンドウ（マルチ）の間中、数個のソース１４５からの更新が、処理のために異なる時間で到着するかもしれず、加えて、すべてのソース１４５が、各動作ウィンドウの間中利用可能ではないかもしれない。システム１００は、更新検出ステージ２２０を利用して、すべてのソース１４５ａ、１４５ｂ及び１４５ｃが利用可能であり得るか否かに関わらず、かつソース１４５ａ、１４５ｂ及び１４５ｃが利用可能にされる順序に関わらず、いずれのバージョン、例えばｃｏｍｐａｎｙ＿ａのｓａｌｅｓ＿ｄａｔａが用いられるべきかを選択する。さらに、システム１００の出力を照会するシステムは、処理されているデータ容量に関わらず、クエリの性能低下を経験しない。システム１００は、各更新ポイントでの更新のみを包含しているデルタデータリポジトリ１６０内のデルタ表を利用し、それによって、更新のリストを探すときに、全領域データリポジトリ１５５がスキャンされることを必要としないことを保証する。

本明細書で説明された技術は、代表例であり、本開示において何らかの特定の限定を含意するとして解釈されるべきではない。当業者によって、さまざまな代替、組み合わせ、及び改変が考え出され得ることが理解されるべきである。例えば、本明細書で説明されたプロセスに関連付けられたステップは、任意の順序で行われるか、さもなければステップ自体によって特定され、または決定づけられることができる。本開示は、添付の請求項の範囲内に入るすべてのそのような代替、改変及び変形を包含することが意図される。

用語「含む（ｃｏｍｐｒｉｓｅｓ）」または「含む（ｃｏｍｐｒｉｓｉｎｇ）」は、述べられた特徴、整数、ステップまたはコンポーネントの存在を特定するとして解釈されるべきであるが、１つ以上の他の特徴、整数、ステップまたはコンポーネント、もしくはそれらの群の存在を排除しない。用語「１つの（ａ）」及び「１つの（ａｎ）」は、不定冠詞であり、それら自体は、複数の冠詞を有する実施形態を排除しない。

Claims (12)

1. データ要素を受信することと、
   前記データ要素を、時間経過にともなって前記データ要素に生じた変更を包含する保留更新履歴リポジトリ内の対応する現在のデータ要素と比較し、それによって比較をもたらすことと、
   前記比較に基づいて、前記データ要素を変更したことを判定することと、
   前記データ要素のためのデータを包含する、動作中のプロセスがないことを確認することと、
   前記データ要素を、前記データ要素が受信された時間の範囲に関連付けられたカットオフ番号と関係付けることと、
   （ａ）前記データ要素の現在の値及び前記データ要素の以前の値を格納する全領域データリポジトリと、（ｂ）（ｉ）前記データ要素が更新されていること、及び（ｉｉ）前記カットオフ番号、を示すレコードを格納するデルタデータリポジトリと、における対応するデータ要素を更新することと、
   を含む、方法。
2. 前記データ要素が、ソースからのものであり、
   前記方法が、
   前記ソースを考慮した規則に従って、前記データ要素を更新するかを判定すること、
   をさらに含む、請求項１に記載の方法。
3. 前記ソースは、第１のソースであり、
   前記保留更新履歴リポジトリが、第２のソースからの前記データ要素の現在の値を保持し、
   前記規則が、前記第２のソースも考慮する、
   請求項２に記載の方法。
4. 前記データ要素の値が、複数のソースから入手可能であり、
   前記規則が、前記複数のソースを考慮する、
   請求項３に記載の方法。
5. 時間経過にともなってデータ要素に生じた変更を包含する保留更新履歴リポジトリと、
   前記データ要素の現在の値及び前記データ要素の以前の値を格納する全領域データリポジトリと、
   （ｉ）前記データ要素が更新されていること、及び（ｉｉ）前記カットオフ番号を示すレコードを格納するデルタデータリポジトリと、
   プロセッサと、
   前記プロセッサによって読み取り可能であり、前記プロセッサに、
   データ要素を受信することと、
   前記データ要素を、前記保留更新履歴リポジトリ内の対応する現在のデータ要素と比較し、それによって比較をもたらすことと、
   前記比較に基づいて、前記データ要素を変更したことを判定することと、
   前記データ要素のためのデータを包含する、動作中のプロセスがないことを確認することと、
   前記データ要素を、前記データ要素が受信された時間の範囲に関連付けられたカットオフ番号と関係付けることと、
   （ａ）前記全領域データリポジトリ及び（ｂ）前記デルタデータリポジトリ内の対応するデータ要素を更新することと、
   を行わせる命令を包含するメモリと、
   を備える、システム。
6. 前記データ要素が、ソースからのものであり、
   前記命令が、前記プロセッサに、
   前記ソースを考慮した規則に従って、前記データ要素を更新するかを判定すること、
   をさらに行わせる、
   請求項５に記載のシステム。
7. 前記ソースは、第1のソースであり、
   前記保留更新履歴リポジトリが、第２のソースからの前記データ要素の現在の値を保持し、
   前記規則が、前記第２のソースも考慮する、
   請求項６に記載のシステム。
8. 前記データ要素の値が、複数のソースから入手可能であり、
   前記規則が、前記複数のソースを考慮する、
   請求項７に記載のシステム。
9. 非一時的である記憶装置であって、プロセッサによって読み取り可能な命令を含み、前記プロセッサに、
   データ要素を受信することと、
   前記データ要素を、時間経過にともなって前記データ要素に生じた変更を包含する保留更新履歴リポジトリ内の対応する現在のデータ要素と比較し、それによって比較をもたらすことと、
   前記比較に基づいて、前記データ要素を変更したことを判定することと、
   前記データ要素のためのデータを包含する、動作中のプロセスがないことを確認することと、
   前記データ要素を、前記データ要素が受信された時間の範囲に関連付けられたカットオフ番号と関係付けることと、
   （ａ）前記データ要素の現在の値及び前記データ要素の以前の値を格納する全領域データリポジトリと、（ｂ）（ｉ）前記データ要素が更新されていること、及び（ｉｉ）前記カットオフ番号とを示すレコードを格納するデルタデータリポジトリと、における対応するデータ要素を更新することと、
   を行わせる記憶装置。
10. 前記データ要素が、ソースからのものであり、
    前記命令が、前記プロセッサに、
    前記ソースを考慮した規則に従って、前記データ要素を更新するかを判定すること、
    をさらに行わせる、
    請求項９に記載の記憶装置。
11. 前記ソースは、第１のソースであり、
    前記保留更新履歴リポジトリが、第２のソースからの前記データ要素の現在の値を保持し、
    前記規則が、前記第２のソースも考慮する、
    請求項１０に記載の記憶装置。
12. 前記データ要素の値が、複数のソースから入手可能であり、
    前記規則が、前記複数のソースを考慮する、
    請求項１１に記載の記憶装置。

Images