JP6510083B2

JP6510083B2 - 広域分散型環境内での相互依存企業データの整合性を保全するためのシステム及び方法

Info

Publication number: JP6510083B2
Application number: JP2017567561A
Authority: JP
Inventors: ソウサフェリックス、テルモイナシオデ; クラドドック、シアン; オーレイリー、コナー
Original assignee: D&B Business Information Solutions Ltd
Current assignee: D&B Business Information Solutions Ltd
Priority date: 2015-03-20
Filing date: 2016-03-18
Publication date: 2019-05-08
Anticipated expiration: 2036-03-18
Also published as: AU2016238520A1; KR102025222B1; EP3271835A1; JP2018510442A; CN107636644A; US20160275135A1; CA2980241A1; MX2017012161A; WO2016151400A1; US10891283B2; KR20170137753A; CN107636644B; AU2016238520B2; CA2980241C

Description

本開示は、データの同時かつ部分的な更新が認められている分散型環境での相互依存企業データの整合性を保全するための方法に関する。

相互依存企業データは、概して、例えば、企業特性、連絡先詳細、リンケージ（ファミリーツリーを含む）、分析スコアリングデータ及び任意の他の得られた、及び／または導き出された事業者情報を含むとして定義されることができる。

一般的なデータ整合性の課題に対する多くの解決策がある。従来のデータベース整合手法は、データが分散型データベース間で、未加工データレベルで同期されることを保証することに焦点が当てられている。対照的に、相互依存企業データに対する整合性を維持することは、従来のデータベース整合性の問題を超え、いかにして事業者から見たデータの整合性を維持するかを考慮しなければならない。例えば、組織の財務データのサブセットに基づいて、リスクスコアが算出される。企業データの整合性を維持するために、基礎となる財務データ及び算出されたリスクスコア（両方が連携されている）は、顧客にデータが提示されたときに同期していなければならない。

並行した事業者処理及び多数の技術システムに関連する技術的課題は、例えば、１つのグループが財務データを更新し、一方でリスクスコアが古い財務データ上で算出される場合、企業データを同期させることができないことである。

いくつかのケースでは、事業者データは、分散型のデータストアにある。この企業情報の多様性は、別個の部分が多数のグループ（例えば、データエントリ）及び多数のシステム（例えば、リスクスコアリング）ごとに独立して更新される可能性が非常に高いことを意味する。これらの更新は、同時に行われる見込みが低く、結果として不整合となる可能性がある。

報告のために、このデータの整合性は必須である。しかしながら、データがグローバルに分散されるときに整合性を維持すること、及びすべてのシステムが常にオンラインではないかもしれないことが、問題となる。オフラインのデータストアは、企業データの整合性及び精度を保証するような方法で、すべてのデータストアが全領域の可能性のあるデータを有するわけではないことを意識して、それら自体を更新することを要する。標準的なデータベース複写及び整合のために用いられる技術は、企業データの整合性の維持まわりでの複雑な使用のケースを対象とするためには簡易すぎる。

グローバルデータの整合性及び時間的な完全性、データにおける相互依存関係整合性、ベンディングデータからの在庫データの分離、ベンディングされるデータの品質及び待ち時間を含む汎用データの整合性、及び、データを市場、規制及び顧客によってカスタマイズされた何百もの製品にまとめることに対する多くの技術的な問題がある。

このように、同時かつ部分的な更新を可能にする、広域分散型環境においての相互依存企業データの整合性の保全に対する要望がある。

分散型環境で相互依存企業データの整合性を保全するためのシステム及び方法は、固有の企業識別情報に関するレコードのいくつかまたはすべてを並行して更新することが可能であり、これは、単独または組み合わせて系統立てられた数字、アルファベット、及びまたは他の記号を含み得る。

広域分散型環境内でのデータの整合性を保全するためのシステムは、
ネットワークと、
前記ネットワークと通信するユーザインターフェースと、
前記ネットワークと通信する少なくとも１つのローカルデータストレージであって、前記ローカルデータストレージが、事業者実体に関する複数のローカルデータレコードを含む、ローカルデータストレージと、
前記ネットワークと通信するグローバルデータストレージであって、前記グローバルデータストレージが、前記少なくとも１つのローカルデータストレージから受信されたローカルデータレコードから生成された複数のグローバルデータレコードを含む、グローバルデータストレージと、
前記ネットワークと通信するプロセッサ及びメモリを備えるコンピュータであって、前記プロセッサが、
（ａ）ユーザインターフェースから、前記ネットワークを介して、事業者実体に関する更新レコードに対する要求を受信することと、
（ｂ）少なくとも１つの前記ローカルデータストレージに記憶された前記ローカルデータレコードから、前記更新レコードを取得し、前記更新レコードを、前記グローバルデータストレージに記憶された少なくとも１つのグローバルデータレコードと比較することであって、前記グローバルデータストレージが、前記ローカルデータストレージのうちの少なくとも１つから予め受信されたデータを含む、比較をすることと、
（ｃ）前記更新レコード及び前記グローバルデータレコードの最新の更新ポイントを判定することと、
（ｄ）前記更新レコードに対する最新の日付参照が前記グローバルデータレコードとは異なる場合、前記コンピュータが、いずれのレコードが優先であるかを判定し、それによって、少なくとも１つの優先レコード要素を作成することと、
を行う、コンピュータと、
前記優先レコード要素を、少なくとも１つの他のデータストレージリポジトリから取り出された前記優先レコード要素に関連する前記実体の付加的なレコード要素とともにアセンブルし、それによって、最終更新レコードを形成するアセンブラと、
前記ユーザに前記最終更新レコードを分配する分配器と、
を備える。

本システムは、分配される前に、最終更新レコードの固有の識別子を、ユーザによって用いられる異なる固有の識別子に変換するトランスレータをさらに備える。トランスレータは、最終更新レコードの固有の識別子を、正準変換を介して変換する。

本システムは、ユーザによって指定されたインターフェースに、最終更新レコードの変換された固有の識別子をパッケージするパッケージャをさらに備える。インターフェースは、アプリケーションプログラミングインターフェースを含む。

本システムは、ローカルデータストレージ及びグローバルデータストレージから遠隔したユーザデータストアをさらに備える。

本システムは、アセンブラに優先レコード要素を渡す前に、更新レコード及び／またはグローバルデータレコードが、相互依存データ要素を含むかを判定することをさらに含み、相互依存データ要素が、異なる最新の日付参照を有する場合、その後、相互依存データ要素に対する最新の日付参照が一致するまで、最終更新レコードの形成を止める。

本システムは、アセンブラに優先レコード要素を渡す前に、リンケージリポジトリに記憶された事業者実体名の相互依存関係の確認を行って、最終更新レコードにおけるリンクされた企業名に対して、正しい実体名が整合性をもって使いられること保証することをさらに含む。

本システムは、ユーザへの分配の前に、最終更新レコードを記憶するベンディングデータストレージをさらに備える。

広域分散型環境でのデータの整合性を保全するための方法であって、少なくとも１つのローカルデータストレージにおいて、複数の実体の企業データを維持することと、ユーザから、前記企業データからの更新レコードに対する要求を受信することと、少なくとも１つの前記ローカルデータストレージに記憶された前記企業データから前記更新レコードを取得し、前記更新レコードを、グローバルデータストレージから受信された少なくとも１つのグローバルデータレコードと比較することであって、前記グローバルデータストレージが、前記ローカルデータストレージのうちの少なくとも１つから予め受信されたデータを含む、比較をすることと、前記更新レコード及び前記グローバルデータレコードの最新の更新ポイントを判定することと、前記更新レコードに対する最新の日付参照が前記グローバルデータレコードとは異なる場合、いずれのレコードが優先であるかを判定することと、前記優先レコード要素を、少なくとも１つの他のデータストレージリポジトリから取り出された前記優先レコードに関連する前記実体の付加的なレコード要素とともにアセンブルし、それによって、最終更新レコードを形成することと、前記ユーザに前記最終更新レコードを分配することと、を含む。

本方法は、ユーザへの分配の前に、最終更新レコードの固有の識別子を、ユーザによって用いられる異なる固有の識別子に翻訳することをさらに含む。

本方法は、ユーザによって指定されたインターフェースに、最終更新レコードをパッケージすることをさらに含む。インターフェースは、アプリケーションプログラミングインターフェースを含む。

本方法は、ローカルデータストレージ及びグローバルデータストレージから遠隔したユーザデータストアに、最終更新レコードを分配することをさらに含む。

本方法は、アセンブルするステップ及び分配するステップの前に、更新レコード及び／またはグローバルデータレコードが、相互依存データ要素を含むかを判定することをさらに含み、相互依存データ要素が、異なる最新の日付参照を有する場合、その後、相互依存データ要素に対する最新の日付参照が一致するまで、最終更新レコードの形成を止める。

本方法は、アセンブルするステップ及び分配するステップの前に、リンケージリポジトリに記憶された実体名の相互依存関係の確認を行って、最終更新レコードにおけるリンクされた企業名に対して、正しい実体名が整合性をもって使いられること保証することをさらに含む。

広域分散型環境での企業データの整合性を保全するための非一時的メモリ媒体であって、プロセッサと協働して、以下の少なくとも１つのローカルデータストレージにおいて、複数の実体の企業データを維持するステップと、ユーザから、前記企業データからの更新レコードに対する要求を受信するステップと、少なくとも１つの前記ローカルデータストレージに記憶された前記企業データから前記更新レコードを取得し、前記更新レコードを、グローバルデータストレージから受信された少なくとも１つのグローバルデータレコードと比較するステップであって、前記グローバルデータストレージが、前記ローカルデータストレージのうちの少なくとも１つから予め受信されたデータを含む、比較をするステップと、前記更新レコード及び前記グローバルデータレコードの最新の更新ポイントを判定するステップと、前記更新レコードに対する最新の日付参照が前記グローバルデータレコードとは異なる場合、いずれのレコードが優先されるかを判定するステップと、前記優先レコード要素を、少なくとも１つの他のデータストレージリポジトリから取り出された前記優先レコードに関連する前記実体の付加的なレコード要素とともにアセンブルし、それによって、最終更新レコードを形成するステップと、前記ユーザに前記最終更新レコードを分配するステップと、を提供するように構成されたプログラムモジュールを含む。

本開示の他の及びさらなる目的、利点及び特徴は、以下の明細書を添付の図面とともに参照することによって理解され、図面において、同様の参照記号は、構造における同様の要素を示す。

本開示による方法を実行するためのシステムのブロック図である。要求元に対するデータの相互依存関係整合的更新をアセンブルする方法のブロック図である。データの更新をアセンブルし分配するための図２の方法の一部のブロック図である。要求元に対する更新をロードし翻訳するための図２及び３の方法の一部のブロック図である。図１のシステムのプログラムモジュールによって行われる動作のフロー図である。図１のシステムのプログラムモジュールによって行われるさらなる動作のフロー図である。

図１及び２を参照すると、本開示の方法２００の実行を提供するための代表的なシステム１００が示される。最初に図１を参照すると、システム１００は、ネットワーク１３０と各々相互接続されるコンピュータ１０５、要求元１０２、ソース２０１、及び在来ベンディングデータストア２２６を備え、ネットワーク１３０は、プライベートネットワークまたはより広範なネットワーク、例えば、インターネットであってもよい。ソース２０１は、状態ストア２０５、リンケージリポジトリ２０６及びデルタデータリポジトリ２０７及びまたは他のデータベースを含む。いくつかの実施形態では、１つ以上のコンピュータ、要求元、ソース及びベンディングデータストアがあってもよい。

コンピュータ１０５は、プロセッサ１１０及びメモリ１１５を備える。プログラムモジュール１２０及びプログラムモジュール１２５は、メモリ１１５内に配設される。プロセッサ１１０は、ネットワーク１３０と、要求元１０２と、在来ベンディングデータストア２２６と、状態ストア２０５、リンケージリポジトリ２０６、及びデルタデータリポジトリ２０７のうちの１つ以上とを用いて、方法２００を行うためのプログラムモジュール１２０及び１２５の命令を実行するように動作可能である。

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

システム２００は、現在のデータ複写手法の、企業データに関連する場合のさまざまな不利点を克服する。すなわち、システム２００は、要求プロセスにおいて、全企業データのすべてまたはそのサブセットが、中央データリポジトリに対する更新が継続的かつ予め決められることができない順序で行われる環境内で、そのデータ内部での相互依存関係を保全するような方法で利用可能であるようにする。さらに、システム２００は、要求データを中央リポジトリと同じ形式で記憶するためのあらゆる要件を取り除く。

システム２００は、（ｉ）要求元１０２から、企業データを包含する在来ベンディングデータストア２２６を更新するための要求を受信するステップと、（ｉｉ）デルタデータリポジトリ２０７から要求された更新のすべてをアセンブルして、要求元１０２が最新であることを保証するステップと、（ｉｉｉ）すべての相互依存関係データを含むステップと、（ｉｖ）要求元１０２に更新を分配するステップと、（ｖ）すべての更新を在来ベンディングデータストア２２６内にロードし、正準名変換を適用するステップと、（ｖｉ）データを表現するための方法を提供するステップと、を含む。

図２を参照すると、プロセッサ１１０は、更新要求を受信すると、ステップ（ｉ）を開始して、ボックス２１０においてステップ（ｉｉ）及び（ｉｉｉ）を開始し、アセンブル更新プロセス２１５を用いて、企業データの相互依存関係に整合性のある更新をアセンブルし、要求元１０２が最新であることを確実にする。また、プロセッサ１１０は、ボックス２１０においてステップ（ｉｖ）を開始して、分配データプロセス２１６を用いて、要求元１０２に、及びボックス２２０に更新を汎用形式で分配する。プロセッサ１１０はさらに、ボックス２２０においてステップ（ｖ）を開始して、ロード更新プロセス２２５を用いて、すべての更新を在来ベンディングストア２２６内に、そしてデータ翻訳プロセス２２７にロードする。

図３を参照すると、プロセッサ１１０は、アセンブル更新プロセス２１５を開始して、要求元１０２からの要求に応答し、ここで（ａ）ボックス３０５において、システム２００は、状態ストア２０５から現在の更新状態レベルを判定し、これによって、いくつの更新が要求されたかを判定し、（ｂ）ボックス３０６において、システム２００は、リンケージリポジトリ２０６からの全実体間の相互依存関係の確認に着手し、（ｃ）ボックス３０７において、システム２００は、デルタデータリポジトリ２０７からの更新を含むすべての更新をアセンブルする。そして、アセンブルされた更新データは、ボックス２１６においてボックス２２０に渡される（図２）。

図４を参照すると、プロセッサ１１０は、ロードマネージャボックス４１０においてプロセス２２５を開始して、ボックス２１６から更新データを受信し、更新データをストアベンドデータボックス４１１にロードして、在来ベンディングデータストア２２６に記憶する。プロセッサ１１０はさらに、データ翻訳プロセス２２７を開始して、内部正準命名規則４２１から、要求元１０２によって要求された命名規則への変換を行う。そして、変換されたデータは、要求元１０２に提供される。

図５を参照すると、フロー図５００は、ステップ（ｉ）、（ｉｉ）、（ｉｉｉ）、（ｉｖ）及び（ｖ）を示す。プロセッサ１１０は、プログラムモジュール１２５（図１）の命令を実行して、フロー図５００に記載された動作を行う。ボックス５０５において、新しい更新が認識される。ボックス３０５において、状態ストア２０５にアクセスすることによって、最新の更新ポイントが判定される。ボックス５１０において、何らかの相互依存関係があるかが判定される。ない場合には、本手順はボックス３０７に進む。ある場合には、ボックス５１２において、リンケージリポジトリ２０６にアクセスすることによって、相互依存関係が取得され、その後本手順はボックス３０７に進む。ボックス３０７において、状態ストア２０５及び／またはリンケージリポジトリ２０６から得られた更新は、デルタデータリポジトリ２０７からの任意の更新とともにアセンブルされる。ボックス５１４において、更新は、遠隔ロード更新ボックス４１０及びストアベンディングデータボックス４１１に分配されて、在来ベンディングストア２２６に記憶される。方法２００のために、状態ストア２０５、リンケージリポジトリ２０６及びデルタデータリポジトリ２０７は、読み取り専用のデータベースである。

図６を参照すると、フロー図６００は、更新を収集し、離隔したユーザまたはベンダによって用いられる形式に更新を変換するための動作、すなわちステップ（ｖｉ）及び（ｖ）を示す。ボックス６０２において、更新データに対する要求の受信が認識される。ボックス６０４において、要求された更新データが、在来データストア２２６から取り出される。ボックス６０６において、更新の変換を要するかが判定される。例えば、システム１００は、データに対する固有の識別子を用いてもよく、ベンダは、異なる固有の識別子を用いてもよい。ボックス６０６において、変換が必要であると判定されると、ボックス４２１において、データのフィールドが、システム１００の固有の識別子（例えば、正規名）から、要求元の異なる識別子に変換される。

ボックス４２２において、更新は、要求された形式にパッケージされる。例えば、データは、要求元１０２によって指定された形式で、アプリケーションプログラミングインターフェース（ＡＰＩ）を通して利用可能であってもよく、またはそのようにされてもよい。

（実施例）
ここで、どのようにして、各々が事業者実体を記述する事業者データを包含する少数の相互依存データファイルが、本システムを通して、データファイルを供給するソースデータベースが広域に分散する性質であるにもかかわらず、データの整合性を保全するように処理されることができるかの例を示す。

各ソースファイルは、異なるデータベースリポジトリ内に存在する。これらのリポジトリは、異なる地理的位置に分散し、異なるグループに置かれている各リポジトリの更新及び維持を担っている。いくつかのリポジトリは、中央データベースストレージ設備の外部であることができる。

各ソースリポジトリは、システム１００に更新を送信することを承諾するが、これらの更新の頻度は、リポジトリとプロセスとの間の差異に起因して変動する。いくつかのリポジトリは、データファイルを毎日提供し、他は、毎週、毎月、３か月ごと、毎年または要求に応じて提供する。

概して、これらのファイルは、３つ（３）の異なるタイプ、すなわち区切られるか、固定幅であるか、またはＸＭＬであるが、しかしながら、これらの異なる広範なタイプの範囲内で、内部のデータの正確な形式及び定義は、ファイルごとに変動する。

この作用は、異なるファイル内に同じレコードが存在するにもかかわらず、レコードに関連するデータが、変動する頻度ケイデンスで更新され、データの不整合の問題につながることを意味する。

本実施例においては、「レコード」は、ソースファイルのうちの１つの入力列を指す。各レコードは、固有に特定され、同じ識別子が各ソースファイル内に存在する。各レコードは、単一の企業に基づく事業者データを指す。そして、以下の例では、「レコードＢ」は、グローバルファイル及びローカルファイル１の両方に存在し、「レコードＤ」は、グローバルファイル及びローカルファイル２の両方に存在し、「レコードＡ」は、グローバルファイルに固有である等である。

（図５及び６を通したフローを説明するシナリオ）
４つのソースファイルが、システムにデータを分配した。各々が、各レコード上に事業者データ要素に加えて日付参照を包含する。この日付参照は、ファイル内のレコードが更新された日である日付を指す。日付参照の例は、年月日形式での「２０１６０１１５」であり、２０１６年１月１５日を意味する。この日付参照は、図５のプロセス３０５、すなわち「最新の更新ポイントを判定」で用いられる。

１．グローバルファイル−これは、世界中の多数の国からの入力データを表すレコードを包含するファイルである。このファイル内には、地理的位置に基づいてレコードを分類するための国コード識別子がある。簡略化するために、本実施例では国名を使用する。

本実施例では、これらは、グローバルファイル内部のレコード毎の７つ（７）の事業者データ要素であり、このファイルの頻度は、毎日である。

２．ローカルソースファイル１−これは、単一の国からの入力データを表すレコードを包含するファイルである。このファイルには、国を特定するための国コード識別子が存在する。

本実施例では、このローカルファイル内部にレコード毎に２つ（２）の事業者データ要素を有し、このファイルの頻度は毎日である。

３．ローカルソースファイル２−これは、ローカルファイル１で対象とされた単一の国とは異なる単一の国からの入力データを表すレコードを包含するファイルである。このファイルには、国を特定するための国コード識別子が存在する。

本実施例では、このファイル内部にレコード毎に２つ（２）の事業者データ要素を有し、このファイルの頻度は毎週である。

４．削除ファイル−これは、予め入力されたデータのレコードを削除するための命令を包含するファイルである。

本実施例では、このファイル内部にレコード毎に２つ（２）の事業者データ要素を有し、このファイルの頻度は毎月である。

（在来ベンディングデータストアにおける予想出力（図５及び６−ボックス２２６））
４つ（４）のファイルはすべて、単一の日のうちのさまざまな時点で受信される。グローバルな整合性を維持するために、本システムは、処理中のファイル間の依存関係を理解する必要がある。これらは、各地理的市場における各事業者要素に適用可能な更新規則によって予め定めされる。本実施例のためにこれらの依存関係を理解するために、以下は、在来ベンディングストア２２６に見出される、７つ（７）の事業者データ要素に対する予想出力と、本システムを通したプロセスの説明を助けるための、上付き文字１〜４で印が付された４つ（４）のシナリオである。

^１レコードＢ及びレコードＣの事業者名
^２レコードＡ及びレコードＤのＨＱ事業者名
^３レコードＤの財務諸表
^４レコードＥの削除インジケータ

（在来ベンディングデータストア（２２６）を上記データで更新するためのプロセス）
４つ（４）のファイルから、グローバルファイルが、在来ベンディングストア２２６において予想される７つ（７）すべての事業者データ要素を提供することが認識される。しかしながら、その他の重複するローカルソースファイルは、すべての依存関係を考慮したとき、データを更新する方法を判定するために、図５において概説されたプロセスが必要とされることを意味する。

処理されている４つ（４）のファイルは、図５のボックス５０５に対するトリガ、すなわち「新規更新のトリガ」である。

ボックス３０５において、入力ファイル内部のデータは評価され、最新の更新ポイントが判定される。ファイル内の日付参照は、要素上のカスタム規則とともに、更新を進めることができるかを判定する。上述の本実施例を通して、ボックス３０５における本プロセスについて示唆する。

（ファイルが重複している場合のマルチソース規則）
^１レコードＢ及びレコードＣの事業者名

事業者名は、特定の企業の取引名の商号を記述する要素である。本システム内では、事業者名は、多数の異なるソースシステムを情報源とすることができる。本実施例では、この要素が、グローバルファイル及びローカルソースファイル１の両方に存在することが認識できる。最初に述べたように、本ソースシステムの広域に分散する性質は、異なるシステムが同じ事業者データ要素の異なる表現を有し得ることを意味する。本実施例では、以下の事業者名要素の入力を認識することができる。

・レコードＢ−グローバルファイル内の「ＢｅｒｌｉｎＩｎｃ」、及びローカルソースファイル１内の「ＢｅｒｌｉｎＢｏｏｋｓｈｏｐｓＧＭＢＨ」
・レコードＣ−グローバルファイル内の「ＣａｒｄｉｆｆＰｌｃ」、及びローカルソースファイル１内の「ＣａｒｄｉｆｆＣａｒｄｓＰｕｂｌｉｃＬｔｄＣｏ」

ボックス３０５において、この要素の解釈は、事業者名要素のローカルバージョンが、当該要素のグローバルバージョンよりも優先されるべきであることを述べるための規則を含む。両方のファイル内のこの要素の日付参照が一致する、すなわち２０１６０１１４（２０１６年１月１４日）であることに留意することが重要である。そして、この場合、更新を判定するために、システムは、日付参照には依拠することができないが、代わりに所定のソーシング規則に依拠して、これらのレコードの両方について、ローカルソースファイル１内の要素のバージョンであり、グローバルファイル内のバージョンではないことを理解する。これらの規則は、ボックス３０５に存在して、これらの要素に対する更新がなされかを判定し、次のプロセスステップに至るまでローカルバージョンが取られる。

（ファイル重複時の日付駆動規則）
^４レコードＥの削除インジケータ

削除インジケータは、データレコードがもはや存在しないことを顧客に知らせるために正として設定されるか、または、レコードがアクティブであり最新であることを顧客に知らせるために誤として設定された要素である。このインジケータは、多数のソースからもたらされることができ、ボックス３０５において更新を判定するためにファイル内部の日付参照を必要とする。

本実施例では、この要素は、グローバルファイル及び削除ファイル内のレコードＥに対して存在することを認識することができる。これらのファイルは、異なる頻度を有する。グローバルファイルは毎日受信され、削除ファイルは毎月受信される。この理由から、日付参照は重要であるが、これは、各ファイル内の日付参照が、ソースシステムがデータ変更を知らされ、更新がなされた日付を表すためである。このことは、システムが、更新を判定するためにこれらの日付参照を考慮することを要することを意味する。本実施例では、以下の削除インジケータ要素入力を見ることができる。

・レコードＥ−グローバルファイル内の日付参照「２０１６０１１４」による「正」、及び削除ファイル内の日付参照「２０１６０１０３」による「誤」

ボックス３０５において、この要素の解釈は、同時に受信されたときに、多数のファイルから最新の日付参照を用いて、更新を判定するべきであることを述べるための規則を含む。本実施例では、日付参照２０１６０１１４（２０１６年１月１４日）は、２０１６０１０３（２０１６年１月３日）よりも近い日付であり、これは、次の処理ステップに進めるために、最新かつ正しい値と考えられるべきである。本実施例では、最新の値は「正」である。本プロセスが、一定の従来のシステムと同様に、この要素の更新を正確には考えていない場合、「誤」の不正確な値は、削除ファイルから取り出され、これは、このレコードが不正確に削除された状態を顧客に知らせることを意味する。削除ファイルが毎月更新されるため、グローバルファイルを重複したソースとみなすシステムを用いない場合、顧客は、最大１（１）カ月にわたって、正しいデータ値に基づいて同期することができない。

（ソース重複時の状態駆動規則）
^３レコードＤの財務諸表

財務諸表は、企業について報告された売上高の数値を参照する日付である。顧客にとっては、売上高と財務諸表との間の相互依存関係を理解することが重要であるが、これは、一方なしに他方を更新することは無意味であるためである。

本実施例では、この要素が、グローバルファイル及びローカルソースファイル２内のレコードＤについて存在することを認識することができる。これらのファイルは、異なる頻度を有する。グローバルファイルは毎日受信され、ローカルソースファイル２は毎週受信される。ローカルソースファイル２上の日付参照は、２０１６０１０９（２０１６年１月９日）であり、グローバルファイル内のレコードＤの日付参照、すなわち２０１６０１１４（２０１６年１月１４日）よりも日付が近い。

しかしながら、要素「売上高」と「財務諸表」との間に関係性があるため、ボックス３０５において、本プロセスは、この依存関係を解釈し、処理を行うために状態ストア２０５を適切に用いなければならない。そのため、ローカルソースファイル２が１月９日に、そしてグローバルファイルが１月１４日に受信された場合、財務諸表は、売上高が１月１４日に受信されるまで、１月９日から状態ストア２０５に保持されるはずである。そして、２０５を用いて、さらなる値が受信されるまで更新を保持し、その時になって初めて処理が次のステップに移ることができる。

（依存関係確認／リンケージリポジトリ）
リンケージは、２つ（２）の別個のデータレコード間の関係性を参照する用語である。例えば、１レコードは、別のレコードの支店位置である場合があり、顧客がレコード上のデータを要求する場合、それに関連付けられたリンクされたレコードを応答に反映することが重要である。この関連付けられたレコードは、本社、又はＨＱと称される。

本実施例では、グローバルファイルに取り込まれたＨＱレコード要素を備える２つ（２）のレコードを有する。

・レコードＡは、レコードＢを、ＨＱ事業者名を備えるＨＱレコードとしてリストアップ＝ＢｅｒｌｉｎＩｎｃ
・レコードＤは、レコードＣを、ＨＱ事業者名を備えるＨＱレコードとしてリストアップ＝ＣａｒｄｉｆｆＰｌｃ

しかしながら、グローバルファイル内にＨＱ事業者名が存在することは関係がないが、これは、プロセス５１０において（依存関係？）ＨＱレコード要素の存在が、読み取り専用のリンケージリポジトリ５０６からのプロセス５１２（依存関係を取得）を促進するためである。

このプロセスでは、レコードＡは、ＨＱレコードＢを有し、レコードＢのＨＱ事業者名を必要とすることによって、レコードＢの事業者名を索引し、それをレコードＡ内部のＨＱ事業者名として戻すことを要する。

この依存関係は、ローカルソースファイル１を情報源とする各自の事業者名を有する、先の例レコードＢ及びＣを想起させる。このため、本システムは、プロセス５１２においてこの索引を行うことによって、整合性を維持する。そして、結果として得られた値は、次の処理ステップに移る。

・ＨＱレコードを有するレコードＡ＝ＨＱ事業者名を有するレコードＢ＝ＢｅｒｌｉｎＢｏｏｋｓｈｏｐｓＧＭＢＨ
・ＨＱレコードを有するレコードＤ＝ＨＱ事業者名を有するレコードＣ＝ＣａｒｄｉｆｆＣａｒｄｓＰｕｂｌｉｃＬｔｄＣｏ

ステップ５１０において依存関係を特定することによって、５０６から正しいＨＱ事業者名に戻り、リンクされた企業の正しい事業者名と整合させることができる。この認識に基づく特定及び処理がなければ、システムは、事業者名間の不整合をもたらすだろう。

（アセンブリ、分配及び記憶）
プロセスステップ３０７において、入力ファイルから受信された事業者要素がアセンブルされる。これらの要素は、本実施例において更新された７つ（７）の要素を除く、これらのレコードについて既に存在するデルタデータリポジトリ２０７からの付加的な日付要素と組み合わせられ、そして、状態ストア２０５、リンケージリポジトリ５０６及びデルタデータリポジトリ２０７から入手可能であるすべての要素を示す完全更新レコードがある。

そして、完全にアセンブルされたデータは、一連のプロセス５１４、４１０及び４１１を通して、在来ベンディングストア２２６に分配されてロードされる。在来ベンディングストア２２６は、この段階で、システムが知っているあらゆるレコードの完全かつ最新のビューを包含する。

（顧客データのベンディング）
図６は、エンドユーザが在来ベンディングストア２２６に存在するデータにアクセスするためのプロセスを説明する。エンドユーザは、入力基準を用いて、ボックス６０２の一部として、レコード識別子等のレコードを要求する。この要求は、ボックス６０４をトリガし、これは、在来ベンディングストア２２６からの、要求されたレコードの取り出しを促す。要求元が、異なる入力基準を用いて、代替の事業者要素名または異なる識別子等のレコードを要求している場合、ボックス６０６は、変換が必要であることを判定する。プロセス４２１におけるこの変換は、レコードが在来ベンディングストア２２６から正しく取り出されることを可能にする。

ボックス４２２は、在来ベンディングストア２２６からの応答を、要求元１０２によって要求された形式にパッケージする。この最終パッケージは、最終要求データ６１０として分配される。

このように、好ましい形態を特に参照して本開示を説明してきたが、添付の特許請求の範囲に定義された本開示の範囲から逸脱することなく、さまざまな変更及び改変がなされてもよいことが明白である。

Claims

広域分散型環境内でのデータの整合性を保全するためのシステムであって、
ネットワークと、
前記ネットワークと通信するユーザインターフェースと、
前記ネットワークと通信する少なくとも１つのローカルデータストレージであって、前記ローカルデータストレージが、事業者実体に関する複数のローカルデータレコードを含む、ローカルデータストレージと、
前記ネットワークと通信するグローバルデータストレージであって、前記グローバルデータストレージが、前記少なくとも１つのローカルデータストレージから受信されたローカルデータレコードから生成された複数のグローバルデータレコードを含む、グローバルデータストレージと、
複数の各更新レコードの更新状態を保持する状態ストアと、
前記ネットワークと通信するプロセッサ及びメモリを備えるコンピュータであって、前記プロセッサが、
（ａ）前記ユーザインターフェースから、前記ネットワークを介して、事業者実体に関する更新レコードに対する要求を受信することと、
（ｂ）少なくとも１つの前記ローカルデータストレージに記憶された前記ローカルデータレコードから、前記更新レコードを取得し、前記更新レコードを、前記グローバルデータストレージに記憶された少なくとも１つのグローバルデータレコードと比較することであって、前記グローバルデータストレージが、前記ローカルデータストレージのうちの少なくとも１つから予め受信されたデータを含む、比較をすることと、
（ｃ）前記状態ストアから、前記更新レコードの更新状態を取得することと、
（ｄ）前記更新レコードの前記更新状態から、前記更新レコードの最新の更新ポイントを判定することと、
（ｅ）前記グローバルデータレコードの最新の更新ポイントを判定することと、
（ｆ）前記更新レコードに対する最新の日付参照が前記グローバルデータレコードとは異なる場合、前記プロセッサが、いずれのレコードが優先であるかを判定し、それによって、少なくとも１つの優先レコード要素を作成することと、
を行う、コンピュータと、
前記優先レコード要素を、少なくとも１つの他のデータストレージリポジトリから取り出された前記優先レコード要素に関連する前記事業者実体の付加的なレコード要素とともにアセンブルし、それによって、最終更新レコードを形成するアセンブラと、
前記ユーザインターフェースのユーザに前記最終更新レコードを分配する分配器と、
を備える、システム。
前記最終更新レコードの固有の識別子を、前記分配の前に、前記ユーザによって用いられる異なる固有の識別子に変換するトランスレータをさらに備える、
請求項１に記載のシステム。
前記ユーザによって指定されたインターフェースに、前記最終更新レコードの前記変換された固有の識別子をパッケージするパッケージャをさらに備える、
請求項２に記載のシステム。
前記インターフェースが、アプリケーションプログラミングインターフェースを含む、
請求項３に記載のシステム。
前記ローカルデータストレージ及び前記グローバルデータストレージから遠隔したユーザデータストアをさらに備える、
請求項１に記載のシステム。
前記アセンブラに前記優先レコード要素を渡す前に、前記更新レコード及び／または前記グローバルデータレコードが、相互依存データ要素を含むかを判定することをさらに含み、
前記相互依存データ要素が、異なる最新の日付参照を有する場合、前記相互依存データ要素に対する最新の日付参照が一致するまで、前記最終更新レコードの形成を止めることをさらに含む、
請求項１に記載のシステム。
前記アセンブラに前記優先レコード要素を渡す前に、リンケージリポジトリに記憶された前記事業者実体名の相互依存関係の確認を行って、前記最終更新レコードにおけるリンクされた企業名に対して、正しい事業者実体名が整合性をもって使われることを保証することをさらに含む、請求項１に記載のシステム。
前記トランスレータが、前記ユーザによって要求された命名規則に従って、前記最終更新レコードの前記固有の識別子を変換する、
請求項２に記載のシステム。
前記ユーザへの前記分配の前に、前記最終更新レコードを記憶するベンディングデータストレージをさらに備える、
請求項１に記載のシステム。
プロセッサが実行する広域分散型環境でのデータの整合性を保全するための方法であって、
少なくとも１つのローカルデータストレージにおいて、複数の事業者実体の企業データを維持することと、
状態ストアにおいて、複数の各更新レコードの更新状態を保持することと、
ユーザインターフェースから、前記企業データからの更新レコードに対する要求を受信することと、
少なくとも１つの前記ローカルデータストレージに記憶された前記企業データから前記更新レコードを取得し、前記更新レコードを、グローバルデータストレージから受信された少なくとも１つのグローバルデータレコードと比較することであって、前記グローバルデータストレージが、前記ローカルデータストレージのうちの少なくとも１つから予め受信されたデータを含む、比較をすることと、
前記状態ストアから、前記更新レコードの更新状態を取得することと、
前記更新レコードの前記更新状態から、前記更新レコードの最新の更新ポイントを判定することと、
前記グローバルデータレコードの最新の更新ポイントを判定することと、
前記更新レコードに対する最新の日付参照が前記グローバルデータレコードとは異なる場合、いずれのレコードが優先であるかを判定し、それによって、少なくとも１つの優先レコード要素を作成することと、
前記優先レコード要素を、少なくとも１つの他のデータストレージリポジトリから取り出された前記優先レコード要素に関連する前記事業者実体の付加的なレコード要素とともにアセンブルし、それによって、最終更新レコードを形成することと、
前記ユーザインターフェースのユーザに前記最終更新レコードを分配することと、
を含む、方法。
前記プロセッサが、前記ユーザへの前記分配の前に、前記最終更新レコードの固有の識別子を、前記ユーザによって用いられる異なる固有の識別子に変換することをさらに含む、
請求項１０に記載の方法。
前記プロセッサが、前記ユーザによって指定されたインターフェースに、前記最終更新レコードをパッケージすることをさらに含む、
請求項１０に記載の方法。
前記インターフェースが、アプリケーションプログラミングインターフェースを含む、
請求項１２に記載の方法。
前記プロセッサが、前記ローカルデータストレージ及び前記グローバルデータストレージから遠隔したユーザデータストアに、前記最終更新レコードを分配するステップをさらに含む、
請求項１０に記載の方法。
前記プロセッサが、前記アセンブルするステップ及び前記分配するステップの前に、前記更新レコードまたは前記グローバルデータレコードに、相互依存データ要素が含まれるかを判定するステップをさらに含み、
前記相互依存データ要素が異なる最新の日付参照を有する場合、前記プロセッサが、前記相互依存データ要素に対する最新の日付参照が一致するまで、前記最終更新レコードの形成を止めることをさらに含む、
請求項１０に記載の方法。
前記アセンブルするステップ及び前記分配するステップの前に、前記プロセッサが、リンケージリポジトリに記憶された事業者実体名の相互依存関係の確認を行って、前記最終更新レコードにおけるリンクされた企業名に対して、正しい事業者実体名が整合性をもって使われることを保証することをさらに含む、
請求項１０に記載の方法。
プロセッサが読み取り可能な広域分散型環境での企業データの整合性を保全するための非一時的メモリ媒体であって、
少なくとも１つのローカルデータストレージにおいて、複数の事業者実体の企業データを維持するステップと、
状態ストアにおいて、複数の各更新レコードの更新状態を保持するステップと、
ユーザインターフェースから、前記企業データからの更新レコードに対する要求を受信するステップと、
少なくとも１つの前記ローカルデータストレージに記憶された前記企業データから前記更新レコードを取得し、前記更新レコードを、グローバルデータストレージから受信された少なくとも１つのグローバルデータレコードと比較するステップであって、前記グローバルデータストレージが、前記ローカルデータストレージのうちの少なくとも１つから予め受信されたデータを含む、比較をするステップと、
前記状態ストアから、前記更新レコードの更新状態を取得するステップと、
前記更新レコードの最新の更新ポイントを判定するステップと、
前記グローバルデータレコードの最新の更新ポイントを判定するステップと、
前記更新レコードに対する最新の日付参照が前記グローバルデータレコードとは異なる場合、いずれのレコードが優先されるかを判定し、それによって、少なくとも１つの優先レコード要素を作成するステップと、
前記優先レコード要素を、少なくとも１つの他のデータストレージリポジトリから取り出された前記優先レコード要素に関連する前記事業者実体の付加的なレコード要素とともにアセンブルし、それによって、最終更新レコードを形成するステップと、
前記ユーザインターフェースのユーザに前記最終更新レコードを分配するステップと、
を提供するように構成されたプログラムモジュールを含む、
非一時的メモリ媒体。
前記プログラムモジュールは、
前記ユーザへの前記分配の前に、前記最終更新レコードの固有の識別子を、前記ユーザによって用いられる異なる固有の識別子に変換するステップを、
さらに提供するように構成されている、
請求項１７に記載の非一時的メモリ媒体。
前記プログラムモジュールは、
前記ユーザによって指定されたインターフェースに、前記最終更新レコードをパッケージするステップを、
さらに提供するように構成されている、
請求項１７に記載の非一時的メモリ媒体。
前記ユーザインターフェースが、アプリケーションプログラミングインターフェースを含む、
請求項１９に記載の非一時的メモリ媒体。
前記プログラムモジュールは、
前記ローカルデータストレージ及び前記グローバルデータストレージから遠隔したユーザデータストアに、前記最終更新レコードを分配するステップを、
さらに提供するように構成されている、
請求項１７に記載の非一時的メモリ媒体。
前記プログラムモジュールは、
前記アセンブルするステップ及び前記分配するステップの前に、前記更新レコード及び／または前記グローバルデータレコードが、相互依存データ要素を含むかを判定することをさらに含み、前記相互依存データ要素が、異なる最新の日付参照を有する場合、前記相互依存データ要素に対する最新の日付参照が一致するまで、前記最終更新レコードの形成を止めるステップを、
さらに提供するように構成されている、
請求項１７に記載の非一時的メモリ媒体。
前記プログラムモジュールは、
前記アセンブルするステップ及び前記分配するステップの前に、リンケージリポジトリに記憶された事業者実体名の相互依存関係の確認を行って、前記最終更新レコードにおけるリンクされた企業名に対して、正しい事業者実体名が整合性をもって使われることを保証するステップを、
さらに提供するように構成されている、
請求項１７に記載の非一時的メモリ媒体。