(57)【要約】      （修正有）【課題】入力データレコードを効率的かつ正確に処理および/またはマージするための方法および機構を提供する。【解決手段】複数のソースレコードが複数のデータソースから受信され得、各ソースレコードは、複数のフィールドを含んでいる。異なるデータソースからのソースレコードのマッチグループが同一エンティティに関連していることが決定され得、単一の最良レコードが、フィールド値に基づいて自動的に作成され得る。この作成には、例えば、第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当てること、および第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てることを含むことができる。マッチグループにおけるすべてのレコードは、単一のクエリを使用して、第1のおよび第2の生存ルールにより同時に順位付けされ、最良レコードは、他アプリケーションのために記憶される。【選択図】図１
2013137763.tif 000002
【特許請求の範囲】
【請求項１】
複数のソースレコードを複数のデータソースから受信するステップであって、各ソースレコードが、複数のフィールドを含む、ステップと、
異なるデータソースからのソースレコードのマッチグループが同一エンティティに関連していることを決定するステップと、
前記マッチグループにおける異なるソースレコードからのフィールド値に基づいて、前記マッチグループについて単一の最良レコードを自動的に作成するステップであって、前記作成するステップが、
第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当てるステップ、
第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てるステップ、および
単一のクエリを使用して、前記第1の生存ルールおよび前記第2の生存ルールにより、前記マッチグループにおけるすべてのソースレコードを同時に順位付けするステップ
を含む、ステップと、
前記最良レコードを記憶するステップと
を含む、コンピュータ実施方法。
【請求項２】
前記第1の生存ルールまたは前記第2の生存ルールのうちの1つが、(i)信頼度、(ii)最新度、または(iii)完全度のうちの少なくとも1つと関連付けられる、請求項1に記載の方法。
【請求項３】
ユーザから生存構成情報を受信するステップと、
前記受信した生存構成情報に基づいて、自動的にコードを生成して、実行されると、前記単一の最良レコードを作成するステップと
をさらに含む、請求項1に記載の方法。
【請求項４】
前記コードが、デフォルト生存グループ、オーバーライド生存グループを作成し、前記単一のクエリが、複数マッチグループについて前記最良レコードを同時に構成する、請求項3に記載の方法。
【請求項５】
単一のソースレコードが、複数の生存ルール次元に従って、生存グループごとに計算される、請求項1に記載の方法。
【請求項６】
複数のソースレコードが、複数生存グループについて同時に計算される、請求項5に記載の方法。
【請求項７】
前記クエリが、構造化されたクエリ言語プロトコルと関連付けられる、請求項1に記載の方法。
【請求項８】
前記作成するステップが、列ベースのメモリ内テーブルと関連付けられる、請求項1に記載の方法。
【請求項９】
前記データソースの少なくとも1つが、(i)企業資源計画データベース、(ii)顧客関係管理データベース、(iii)人事データベース、または(iv)レガシーデータベースのうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項１０】
単一のソースレコードのみを含んでいるマッチグループを識別するステップをさらに含み、前記作成するステップが、前記識別されたマッチグループについて実行されない、
請求項1に記載の方法。
【請求項１１】
方法を実行するようにコンピュータプロセッサによって実行可能なプログラムコード命令を記憶する非一時的コンピュータ可読媒体であって、前記方法が、
複数のソースレコードを複数のデータソースから受信するステップであり、各ソースレコードが、複数のフィールドを含む、ステップと、
異なるデータソースからのソースレコードのマッチグループが同一エンティティに関連していることを決定するステップと、
前記マッチグループにおける異なるソースレコードからのフィールド値に基づいて、前記マッチグループについて単一の最良レコードを作成するステップであり、前記作成するステップが、
第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当てるステップ、
第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てるステップ、および
単一のクエリを使用して、前記第1の生存ルールおよび前記第2の生存ルールにより、前記マッチグループにおけるすべてのソースレコードを同時に順位付けするステップ
を含む、ステップと、
前記最良レコードを記憶するステップと
を含む、媒体。
【請求項１２】
前記第1の生存ルールまたは前記第2の生存ルールのうちの少なくとも1つが、(i)信頼度、(ii)最新度、または(iii)完全度のうちの少なくとも1つと関連付けられる、請求項11に記載の媒体。
【請求項１３】
前記プログラムコード命令の実行は、前記コンピュータプロセッサに
ユーザから生存構成情報を受信し、
前記受信した生存構成情報に基づいて、コードを自動的に生成し、実行されると、前記単一の最良レコードを作成するように
さらに実行させる、請求項11に記載の媒体。
【請求項１４】
前記自動的に生成されたコードが、デフォルト生存グループ、オーバーライド生存グループを作成し、前記単一のクエリが、複数マッチグループについて前記最良レコードを同時に構成する、請求項13に記載の媒体。
【請求項１５】
単一のソースレコードが、複数の生存ルール次元に従って、生存グループごとに計算され、さらに、複数のソースレコードが、複数生存グループについて同時に計算される、請求項11に記載の媒体。
【請求項１６】
前記クエリが、構造化されたクエリ言語プロトコルと関連付けられ、前記作成するステップが、列ベースのメモリ内テーブルと関連付けられる、請求項11に記載の媒体。
【請求項１７】
前記データソースのうちの少なくとも1つが、(i)企業資源計画データベース、(ii)顧客関係管理データベース、(iii)人事データベース、または(iv)レガシーデータベースのうちの少なくとも1つを含む、請求項11に記載の媒体。
【請求項１８】
異なるデータソースと関連付けられる複数のソースレコードを用意するソースデータストアであり、各ソースレコードが、複数のフィールドを含む、ストアと、
最良レコードデータストアと、
(i)前記ソースデータストアから前記ソースレコードを受信し、(ii)単一の最良レコードを前記最良レコードデータストアに記憶する計算最良レコードプラットフォームであり、前記マッチグループにおける異なるソースレコードからのフィールド値に基づいて、前記マッチグループについて単一の最良レコードを作成する、計算最良レコードプラットフォームと
を備える、システムであって、
前記作成することが、
第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当てること、
第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てること、および
単一のクエリを使用して、前記第1の生存ルールおよび前記第2の生存ルールにより、前記マッチグループにおけるすべてのソースレコードを同時に順位付けること
を含む、システム。
【請求項１９】
前記第1の生存ルールまたは前記第2の生存ルールのうちの少なくとも1つが、(i)信頼度、(ii)最新度、または(iii)完全度のうちの少なくとも1つと関連付けられる、請求項18に記載のシステム。
【請求項２０】
前記プログラムコード命令の実行は、前記コンピュータプロセッサに
ユーザから生存構成情報を受信し、
前記受信した生存構成情報に基づいて、コードを自動的に生成し、実行されると、前記単一の最良レコードを作成するように
さらに実行させる、請求項18に記載のシステム。
【請求項２１】
前記自動的に生成されたコードが、デフォルト生存グループ、オーバーライド生存グループを作成し、前記単一のクエリが、複数マッチグループについて前記最良レコードを同時に構成する、請求項20に記載のシステム。
【請求項２２】
単一のソースレコードが、複数の生存ルール次元に従って、生存グループごとに計算され、さらに、複数のソースレコードが、複数生存グループについて同時に計算される、請求項18に記載のシステム。
【請求項２３】
前記クエリが、構造化されたクエリ言語プロトコルと関連付けられ、前記作成することが、列ベースのメモリ内テーブルと関連付けられる、請求項18に記載のシステム。
【請求項２４】
前記データソースのうちの少なくとも1つが、(i)企業資源計画データベース、(ii)顧客関係管理データベース、(iii)人事データベース、または(iv)レガシーデータベースのうちの少なくとも1つを含む、請求項18に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
諸実施形態は、いくつかの異なるソースレコードに基づくレコードの作成に関する。より詳細には、諸実施形態は、生存ルールによりレコードを作成するためのシステムおよび方法を提供する。
【背景技術】
【０００２】
会社または企業が、様々なエンティティについての情報を電子レコードの形態で保管する場合がある。例えば、法人が、従業員データベースを保有していることがあり得、その場合、データベースにおける各行は、特定の従業員についての情報(例えば、従業員の氏名、雇用日、および給与)を含んでいるレコードを表す。さらに、実際には、種々の電子レコードが、単一のエンティティに関連している場合がある。例えば、人事データベースと営業データベースの両方に、同一従業員についてのレコードが含まれていることがあり得る。場合によっては、複数レコードを統合して、データベースに表されるエンティティごとに単一の電子レコードを含んでいるデータストアを作成することが望ましい場合がある。このような目標が、例えば、マスターデータ管理プログラムと関連付けられることがあり得る。
【０００３】
現在のところ、マスターデータ管理プログラムの統合プロセスは、時間のかかる操作である。例えば、いくつかの異なる統合ルールは、順番に適用され得、各アプリケーションは、最終レコードが作成されるまで、別個のデータベースクエリおよび/またはデータのインターンバージョンの作成を必要とする場合があり得る。しかし、このような手法は、かなりの数のレコードおよび/または入力データソースが含まれている(例えば、数十万のソースレコードを統合する必要があり得る)場合、実践的でない可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、入力データレコードを効率的かつ正確に処理および/またはマージするための方法および機構が、本明細書に記載されるいくつかの実施形態により提供され得る。
【課題を解決するための手段】
【０００５】
特許請求の範囲に記載の手段によって課題を解決する。
【図面の簡単な説明】
【０００６】
【図１】いくつかの実施形態によるレコード統合と関連付けられ得るシステムのブロック図である。
【図２】いくつかの実施形態によるレコード統合と関連付けられるデータフローを示す図である。
【図３】いくつかの実施形態によるレコード統合と関連付けられるデータフローを示す図である。
【図４】いくつかの実施形態によるレコード統合と関連付けられるデータフローを示す図である。
【図５】いくつかの実施形態によるレコード統合と関連付けられるデータフローを示す図である。
【図６】いくつかの実施形態によるプラットフォームのブロック図である。
【図７】いくつかの実施形態による方法の流れ図である。
【図８】いくつかの実施形態によるソースレコードデータベースの一部を示す図である。
【図９】いくつかの実施形態による最良レコードデータベースの一部を示す図である。
【図１０】いくつかの実施形態によるレコード統合と関連付けられ得るシステムのブロック図である。
【発明を実施するための形態】
【０００７】
図1は、レコード統合と関連付けられ得るシステム100のブロック図である。システム100は、レコードを記憶するいくつかのデータソースを含み、各レコードは、いくつかのフィールド(例えば、ビジネスパートナー名、住所、および電話番号)を含んでいる。異なるデータソースは、例えば、異なるビジネスアプリケーションと関連付けられ、クエリされ、またはそうでなければ、データソースレコードを出力し得る。いくつかの実施形態によれば、1つまたは複数のデータソースは、企業資源計画(「ERP : Enterprise Resource Planning」)システム110と関連付けられ得る。他の例として、データソースが、顧客関係管理(「CRM : Client Relation Management」)システム112、または(例えば、より古いデータベースアプリケーションと関連付けられる)レガシーシステム114と関連付けられ得る。いずれのソースレコードも、列ベースのメモリ内テーブルを含むデータベースの物理テーブル内に記憶され得る、またはそうでなければ、その物理テーブルと関連付けられ得るということに留意されたい。本明細書に記載されるいずれのデータベースも、例えばSAP MaxDB、Oracle、Microsoft SQL Server、IBM DB2、Teradataなどの関係データベースを含むことが可能である。別の例として、データソースは、多次元データベース、eXtendable Markup Language(「XML」)ドキュメント、または任意の他の構造化データ記憶システムと関連付けられてもよい場合がある。物理テーブルは、いくつかの関係データベース、次元データベース、および/または他のデータソースの中に分布していることが可能である。
【０００８】
最良レコード計算機プラットフォーム120は、様々なデータソース110、112、114からソースレコードを受信することが可能である。例えば、最良レコード計算機プラットフォーム120は、HyperText Transport Protocol(「HTTP」)通信、または任意の他のタイプのデータ交換を介して、遠隔データソースからソースレコードをインポートすることが可能であり得る。最良レコード計算機プラットフォーム120および/またはデータソースは、例えば、パーソナルコンピュータ(「PC」)、サーバ、および/またはモバイルデバイスと関連付けられてもよい場合がある。
【０００９】
最良レコード計算機プラットフォーム120は、本明細書に記載される実施形態のいずれかにより、データソースから受信したソースレコードを統合および/またはマージし、1つまたは複数の「最良」レコードを最良レコードデータベース130に記憶することが可能である。例えば、人事データベースと営業データベースの両方は、同一従業員についてのレコードを含んでいることがあり得る。この場合、最良レコード計算機プラットフォーム120は、複数レコードを自動的に統合して、その従業員についての単一の最良レコードを作成することが可能になる。このような目標は、例えば、マスターデータ管理プログラムと関連付けられてもよい場合がある。
【００１０】
いくつかの実施形態によれば、レコードの統合が、(i)潜在的な重複または「マッチ」を識別し、次いで(ii)エンティティを表す単一の最良レコードにレコードをマージする、2つのフェーズプロセスと関連付けられる。データの大きいセットが、複数レガシーシステムから最良レコード計算機プラットフォーム120に抽出され得ること、ならびにデータが最良計算機プラットフォーム120にインポートされるとすぐに、解決およびマージされる必要がある(かつされ得る)いくつかの明らかな、分かりやすい重複を含んでいる場合があり得ることに留意されたい。多くの場合、この重複の検出は、曖昧なように解釈され得ない、よく規定された識別子に基づいている場合などは分かりやすい。このような識別子の例には、個人を識別する社会保障番号(Social Security Number)、または重複物質を検出する国際取引商品番号(「GTIN」)が挙げられる。
【００１１】
しかし、場合によっては、重複レコードは、単一の物理レコードにマージされる必要がある場合がありながら、矛盾するデータ値が、異なるレコードの中に存在することがある。例えば、図1に示すように、ERPシステム110は、値が「1/1/1960」である生年月日(「DOB」)フィールドを有するレコードを含んでいることがあり得ると同時に、レガシーシステム114は、DOB値が「1/1/1970」である同一エンティティ(「John Smith」)と関連付けられるレコードを所有している。本明細書に記載されるいくつかの実施形態によれば、任意のこのような矛盾する状況における統合を容易にするための機構が提供され得る。
【００１２】
矛盾する情報は、様々な生存ルールにより統合またはマージ可能である。例えば、ある信頼度スコアが、異なるデータソースのレコードに割り当てられる場合があり得る(例えば、ERPシステム110は、CRMシステム112よりも信頼性があると常に仮定される場合があり得る)。別の例としては、最新度は、より最新のデータが、より古いデータと比較して、より信頼性があることを示してもよい場合がある。ソースレコードにおける異なるフィールドの矛盾が、異なる生存ルールを使用して解決され得ることに留意されたい。図1の例では、「デフォルト」生存ルールは、ERPシステム110がCRMシステム112よりも信頼性があり、信頼度「同順位」の場合には、最新のデータがより古いデータよりも信頼されるべきであることを示し得る。さらに、電話番号フィールドの場合、ソースは、(降順に)CRMシステム112、レガシーシステム114、最後にERPシステム110で信頼されるべきである(最新度は、二次的同順位決定項目である)。最後に、DOB値の場合には、レガシーシステム114は、最も信頼され、その後にCRMシステム112、およびERPシステム110が続く。
【００１３】
結果として、計算最良レコードプラットフォーム120は、John Smithの電話番号を調べ、「(123)999-8888」値が、最良レコードデータベース130に使用されるべきであることを決定することができ、それは、CRMシステム112が、ERPシステム110とレガシーシステム114の両方よりも少なくとも電話番号に関して信頼性があるからである。対照的に、レガシーシステム114からのDOB値「1/1/1970」は、最良レコードデータベース130において使用され、それは、ルールによれば、レガシーシステム114は、ERPシステム110またはCRMシステム112のいずれよりも信頼性があるからである。
【００１４】
図1は、いくつかの実施形態による論理アーキテクチャを表しており、実際の実装形態は、他の形で構成された多くのまたは異なる構成要素を含み得ることに留意されたい。さらに、本明細書に記載される各システムは、任意の数の他の公衆および/または個人のネットワークを介して通信する任意の数のデバイスによって実装可能である。2つ以上のデバイスが、互いに遠隔に配置されていても、ネットワークおよび/または専用の接続の任意の知られている形を介して互いに通信してもよい。さらに、各デバイスが、本明細書に記載される機能ならびに任意の他の機能を実行するのに適切な任意の数のハードウェアおよび/またはソフトウェアを備えていてもよい。他のトポロジーが、他の実施形態とともに使用されてもよい。
【００１５】
本明細書に論じられるすべてのシステムおよび方法は、1つまたは複数のコンピュータ可読媒体に記憶されたプログラムコードで実施され得る。このような媒体として、例えば、フロッピー（登録商標）ディスク、CD-ROM、DVD-ROM、ZIP(登録商標)ディスク、磁気テープ、および固体ランダムアクセスメモリ(RAM)または読取り専用メモリ(ROM)記憶ユニットを挙げることができる。したがって、諸実施形態は、ハードウェアおよびソフトウェアのいずれかの具体的な組合せに限定されない。
【００１６】
計算最良レコードプラットフォーム120は、いくつかの異なるやり方で、本明細書に記載されるデータ統合を実行することが可能である。例えば、図2は、いくつかの実施形態によるレコード統合と関連付けられるデータフロー200を示している。202において、ソースレコードの「マッチグループ」が決定され得る。本明細書に使用される場合、「マッチグループ」は、同一の現実世界のエンティティ(例えば、個人、製品、または法人)を示す(ソースレコードを含んだ)レコードの集合体を示すことができる。さらに、用語「ソースレコード」は、所与のソースからの、単一のレコードを説明するいずれかの元のデータを示すことができる。いくつかの実施形態によれば、ソースレコードは、あらかじめ一掃されていても、および/または適切なフォーマットに変換されていてもよい。
【００１７】
あるエンティティについて単一のソースレコードしか存在しない場合、そのソースレコードは、204において、利用可能な「最良レコード」として単に保存されるだけでよい。単一のエンティティについて複数ソースレコードが存在する場合には、206および208において、生存ルール、すなわち、どのレコードを最も正確であるととるべきであるかを決定するルールが適用され得る。異なるフィールドが、異なる生存ルールと関連付けられ得る。例えば、「生存グループ」は、同一の生存ルールとすべてが関連付けられることになるフィールドのセット(例えば、システムBと比較して、システムAからのDOBと電話番号の両方が信頼されるべきである)を表すことが可能である。さらに、デフォルト生存ルールが、任意の特定の生存ルールに属していないフィールドに適用されてもよい場合がある。206および208において、明らかに勝る方が決定された場合、「最良レコード」は、210において、ウィニングソースから取得され、212において、オーバーライドレコードからのデータが付加され、204において、新規レコードが最良レコードとして保存され得る。
【００１８】
生存が適用された後、2つのソース間に「同順位」が存在する場合、214において、最新度(またはそのソースシステム内でごく最近更新されたレコード)が、同順位決定項目として使用され得る。最新度について同順位が解決されない場合、216において、完全度(集中しているフィールドの数が最大のレコード)が、同順位決定項目として使用され得る。このデータフロー200では、レコードを徐々に最終的な最良レコードにするために、それぞれのレコードは、個々に処理され、一時的テーブルの使用を必要とし得ることに留意されたい。
【００１９】
性能を向上させるために、図3は、いくつかの実施形態によるデータフローを示している。具体的には、302において、単一のクエリが、1つのレコードを有するすべてのマッチグループを決定するために使用され得、次いでそれらは、304において、最良レコードとして単に保存される。302および304は、単一のソースレコードと関連付けられるすべてのマッチグループについて1度だけ実行される必要があり得ることに留意されたい。306において、2つ以上のレコードを有するすべてのマッチグループが決定され、308および310において、生存ルールが適用され得る。308および310において、明らかに勝る方が決定された場合、312において「最良レコード」は、ウィニングソースから取得され、314において、オーバーライドレコードからのデータが付加され、316において、新規レコードが、最良レコードとして保存され得る。
【００２０】
生存が適用された後、2つのソース間に「同順位」が存在する場合、318において、最新度が、同順位決定項目として使用され得る。最新度について同順位が解決されない場合、320において、完全度が、同順位決定項目として使用され得る。
【００２１】
性能をさらに向上させるために、図4は、本明細書に記載される実施形態によるデータフロー400を示している。図3と同様に、402において、単一のクエリが、1つのレコードを有するすべてのマッチグループを決定するために使用され得、次いでそれらは、404において、最良レコードとして単に保存される(402および404は、単一のソースレコードと関連付けられるすべてのマッチグループについて1度だけ実行される必要があり得る)。406において、2つ以上のレコードを有するすべてのマッチグループが決定され、408において、ソースレコードは、すべての生存グループについての信頼度、最新度、および完全度によって優先順位付けされ得る。408が、生存ルールが組み込まれているアルゴリズムと関連付け可能であること、およびレコードがマッチグループごとに原子動作として形成可能であることに留意されたい。さらに、マッチグループ内のすべてのソースレコードは、単一のクエリにおけるすべての生存ルールによって順位付けされてもよく、各生存グループは、生存ルールに従って選択された単一のソースレコードによって表されてもよい。
【００２２】
410において、最良レコードは、単一のソフトウェアクエリ言語(「SQL : Software Query Language」)文における選択されたソースレコードから構成され、次いで、412において保存され得る。このような手法により、一時的なまたはインターンのテーブルの必要性を回避することが可能になり、したがって、性能が向上することに留意されたい。さらに、(複数のソースを有する)各マッチグループは、順に計算され得、保存されている手順コードが、自動生成され、構成の変更後、展開され得る。ランタイム時に実行経路を決定するには、並行処理が困難になる生存ルールごとによるルーピングが必要になる場合があることに留意されたい。しかし、コンパイルタイム時に実行経路を決定することにより、ルーピングの要件をなくすことが可能になり、実際、並行処理が容易になる。
【００２３】
したがって、いくつかの実施形態は、すべてのマッチグループからのすべての最良レコードが、単一のクエリを使用して同時に形成され得るようにアルゴリズムを行うことが可能である。例えば、図5は、いくつかの実施形態によるデータフロー500を示しており、502において、単一のクエリが、1つのレコードを有するすべてのマッチグループを決定するために使用され得、次いでそれらは、504において、単に最良レコードとして保存されるだけである(前述と同様に、502および504は、単一のソースレコードと関連付けられるすべてのマッチグループについて1度だけ実行される必要があり得る)。506において、2つ以上のレコードを有するすべてのマッチグループが決定され、508において、ソースレコードは、すべての生存グループについての信頼度、最新度、および完全度によって優先順位付けされ得る。510において、最良レコードは、単一のSQL文における選択されたソースレコードから構成され、次いで512において、保存され得る。
【００２４】
いくつかの実施形態によれば、ユーザが生存グループを構成し、ルールがそれぞれのグループと関連付けられる場合、プロセスが、自動的にトリガされて、そのユーザの構成についてカスタマイズされたコードを生成することが可能である。このような手法により、この構成に基づく動的な分岐の必要性を回避することが可能になり、最適化が、必要に応じてハードコード化されることが可能になる。さらに、場合によっては、レコードが、生存グループごとにすべてのグループについて同時に選択され得、生存グループの数が増加するにつれて、ほぼ平坦な性能曲線がもたらされることになり、最良レコードを生存グループのそれぞれによって増分的に形成するのではなく、最良レコードは、単一の構成プロセスを使用して形成され得る(所要の処理ステップが抑えられる)。さらに、すべてのマッチグループについての最良レコードは同時に構成可能であり、これにより、マッチグループの数が増加するにつれて、ほぼ平坦な性能曲線がもたらされる。
【００２５】
例えば、いかにして生存ルールおよび生存グループがモデル化され得るかを検討する。具体的には、生存ルールを有する「デフォルト」レコードレベルの生存グループ、すなわち、
【００２６】
【数１】
2013137763.tif 000003
【００２７】
は、他の生存グループにおいてカバーされないすべてのフィールドをカバーすることが可能である。
【００２８】
それらのデフォルトルールと関連付けられて結果として得られる疑似コードは、以下、すなわち、
【００２９】
【数２】
2013137763.tif 000004
【００３０】
の通りであり得る。
【００３１】
次に、(2つのフィールドをカバーする)1つまたは複数のオーバーライド生存グループおよびその生存ルール、
【００３２】
【数３】
2013137763.tif 000005
【００３３】
が構成され得る。
【００３４】
それらのオーバーライドルールと関連付けられて結果として得られる疑似コードは、以下、すなわち、
【００３５】
【数４】
2013137763.tif 000006
【００３６】
の通りであり得る。
【００３７】
次いで、最良レコードが、以下、すなわち、
【００３８】
【数５】
2013137763.tif 000007
【００３９】
の通り、すべてのマッチグループについて同時にいくつかのソースレコードから構成され得る。
【００４０】
いくつかの実施形態によれば、命令論理(例えば、for、while、およびifの文)の使用を回避することができ、典型的なSQL手法が好ましい場合がある。さらに、バルク挿入、一時的データを記憶するための揮発性列テーブル、および/または少数の列にわたって迅速に結合するための列テーブルの使用は、システムの性能をさらに向上させることができる。
【００４１】
コードの生成および/または最良レコードの構成が、任意の適切なデバイスによって実行可能であることに留意されたい。例えば、図6は、いくつかの実施形態による最良レコード計算機プラットフォーム600のブロック概略図である。最良レコード計算機プラットフォーム600は、例えば、図1のシステム100と関連付けられてもよい。最良レコード計算機プラットフォーム600は、(図6には示されていない)通信ネットワークによって通信するように構成されている通信デバイス620に結合された、1チップのマイクロプロセッサの形態の1つまたは複数の商用の中央処理ユニット(CPU)など、プロセッサ610を備える。通信デバイス620は、例えば、1つまたは複数の遠隔データソース、最良レコードデータベース、および/またはオペレータと通信するために使用され得る。最良レコード計算機プラットフォームエンジン600は、入力デバイス640(例えば、生存グループおよび/または生存ルールに入力するためのマウスおよび/またはキーボード)と、出力デバイス650(例えば、ユーザインターフェース要素を表示し、かつ/または統合レポートを記録するためのコンピュータモニタ)とをさらに含む。
【００４２】
プロセッサ610は、記憶デバイス630と通信する。記憶デバイス630は、磁気記憶デバイス(例えば、ハードディスクドライブ)、光学記憶デバイス、および/または半導体メモリデバイスの組合せを含んだ任意の適切な情報記憶デバイスを備えることが可能である。記憶デバイス630は、プログラム612、および/またはプロセッサ610を制御するための最良レコードエンジンアプリケーション614を記憶する。プロセッサ610は、プログラム612、614の命令を実行し、それによって、本明細書に記載される実施形態のいずれかにより動作する。例えば、プロセッサ610は、複数のデータソースから複数のソースレコードを受信することが可能であり、各ソースレコードは、複数のフィールドを含んでいる。次いで、プロセッサ610は、異なるデータソースからのソースレコードのマッチグループが同一エンティティに関連していることを決定することが可能であり、単一の最良レコードが、マッチグループの異なるソースレコードからのフィールド値に基づいて、そのマッチグループについて自動的に作成され得る。例えば、プロセッサ610は、第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当て、第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てることが可能である。次いで、マッチグループにおけるすべてのレコードが、単一のクエリを使用して、第1のおよび第2の生存ルールにより、プロセッサ610によって同時に順位付けされ得る。次いで、最良レコードは、他のアプリケーションによって、その後に使用するために記憶され得る。
【００４３】
プログラム612、614は、圧縮されたフォーマット、コンパイルされていないフォーマット、および/または暗号化されたフォーマットで記憶され得る。プログラム612、614は、オペレーティングシステム、データベース管理システムなど、他のプログラム要素、および/または周辺デバイスとインターフェースする、プロセッサ610によって使用されるデバイスドライバをさらに含み得る。
【００４４】
本明細書に使用する限り、情報は、例えば、別のデバイスから(i)によって「受信」または(i)に「送信」され得、あるいは別のソフトウェアのアプリケーション、モジュール、もしくは任意の他のソースから(ii)によって「受信」または(ii)に「送信」され得、(i)は、最良レコード計算機プラットフォーム600であり、(ii)は、最良レコード計算機プラットフォーム600内のソフトウェアのアプリケーションまたはモジュールである。
【００４５】
(例えば図6に示すような)いくつかの実施形態において、記憶デバイス630は、データソースから受信したレコードを含んでいるソースレコードデータベース800、(生存グループおよび/またはルールについての情報を記憶する)生存データベース660、および(図9に関して説明される)最良レコードデータベース900を記憶している。最良レコード計算機プラットフォーム600と関連して使用可能なソースレコードデータベース800の一例は、図8に関して詳細に説明される。本明細書に記載されるデータベースは例であり、追加のおよび/または異なる情報は、その中に記憶され得ることに留意されたい。さらに、様々なデータベースは、本明細書に記載される実施形態のいずれかにより、分割されても、または組み合わせられてもよい場合がある。
【００４６】
最良レコード計算機プラットフォーム600は、本明細書に記載される実施形態のいずれかにより、動作することが可能である。例えば、図7は、いくつかの実施形態による方法700の流れ図である。本明細書に記載されるすべての方法が、ハードウェアおよび/またはソフトウェアのいずれかの組合せによって実行可能であることに留意されたい。方法は、有形媒体において記憶され、かつ本明細書に記載される機能を行うようにコンピュータによって実行可能なプログラムコードで実施され得る。さらに、本明細書に記載される流れ図は、ステップに対して一定の順序を示唆しておらず、本発明の実施形態は、実行可能な任意の順序で実施され得ることに留意されたい。
【００４７】
S710において、複数のソースレコードが、複数のデータソースから受信され得、各ソースレコードは、複数のフィールドを含んでいる。データソースは、例えば、ERPデータベース、CRMデータベース、人事データベース、および/またはレガシーデータベースと関連付け可能であり得る。S720において、異なるデータソースからのソースレコードのマッチグループが同一エンティティに関連していることが決定され得る。
【００４８】
いくつかの実施形態によれば、単一の最良レコードが、マッチグループにおける異なるソースレコードからのフィールド値に基づいて、マッチグループについて自動的に作成され得る。具体的には、S730において、第1のセットのフィールドは、第1の生存ルールと関連付けられる第1の生存グループに割り当てられ、第2のセットのフィールドは、第2の生存ルールと関連付けられる第2の生存グループに割り当てられ得る。生存ルールは、例えば、関連の信頼度、最新度、および/または完全度であってもよい。いくつかの実施形態によれば、生存構成情報は、(例えば、GUIを介して)ユーザから受信され、受信した生存構成情報に基づいて、コードが、自動的に生成され得て、実行されると、単一の最良レコードを作成する。コードは、例えば、デフォルト生存グループ、オーバーライド生存グループを作成することができ、単一のクエリは、複数マッチグループについて最良レコードを同時に構成することができる。
【００４９】
S740において、マッチグループ内のすべてのソースレコードは、単一のクエリを使用して、第1のおよび第2の生存ルールにより同時に順位付けされ得る。いくつかの実施形態によれば、単一のソースレコードは、複数の生存ルール次元に従って、生存グループごとに計算され得る。さらに、ソースレコードは、同時に複数生存グループについて計算され得、最良レコードの作成は、列ベースのメモリ内テーブルと関連付けられ得る。S750において、最良レコードは、(例えば、他のアプリケーションによって使用されるように)記憶され得る。
【００５０】
例として、図8は、いくつかの実施形態による最良レコード計算機プラットフォーム600に記憶され得るソースレコードデータベース800を表すテーブルである。このテーブルは、例えば、組合せおよび/またはマージされる必要があり得る関連レコードを識別するエントリを含んでいてもよい。テーブルはまた、エントリのそれぞれについて、フィールド802、804、806、808、810、812を規定することが可能である。フィールド802、804、806、808、810、812は、いくつかの実施形態によれば、氏名802、州804、郵便番号806、DOB808、ソース810、日付812を指定することができる。ソースレコードデータベース800における情報は、例えば、(場合によっては、レガシーデータソースを含む)データソースから受信した情報に基づいて、作成および更新可能である。
【００５１】
氏名802は、例えば、個人と関連付けられる英数字配列であってもよい。州804および郵便番号806は、その人の自宅の場所を表すことができ、DOB808は、その人の生年月日を表すことができる。ソース810は、エントリの情報の源(例えば、ERPシステムまたはCRMシステム)を示すことがあり、日付812は、情報の最終更新時を示すことがあり得る。ERPとCRMのシステムからの郵便番号806とDOB808が、互いに異なっていることに留意されたい。
【００５２】
図5に関して説明された例に続いて、(DOB808を除く)ほとんどのフィールドは、最も信頼性があるシステムからの値をとるべきであるが(ERPソース810が、最も信頼性がある)、DOB808は、(日付812によって規定される)最新のレコードからの値をとるべきであると仮定する。
【００５３】
このような場合、図9は、いくつかの実施形態により、最良レコード計算機プラットフォーム600において記憶され得る最良レコードデータベース900を表すテーブルを示している。このテーブルは、例えば、組合せおよび/またはマージされたレコードを識別するエントリを含んでいてもよい。テーブルはまた、エントリのそれぞれについてフィールド902、904、906、908を規定することができる。フィールド902、904、906、908は、いくつかの実施形態によれば、氏名902、州904、郵便番号906、およびDOB908を指定することができる。ソースレコードデータベース900における情報は、例えば、最良レコード計算機プラットフォーム600によって実行されるアルゴリズムに基づいて、作成および更新可能である。
【００５４】
氏名902は、例えば、個人と関連付けられる英数字配列であってもよい。州904および郵便番号906は、その人の自宅の場所を表すことができ、DOB908は、その人の生年月日を表すことができる。郵便番号906を含んだほとんどのフィールドはその源が、最も信頼性があるシステム(ERP)であるが、DOB908はその源が、ユーザの生存構成ごとの最新のレコードであることに留意されたい。
【００５５】
いくつかの実施形態によれば、生存グループまたは生存ルールのうちの少なくとも1つは、履歴情報に基づいて自動的に調整される。例えば、生存ルールが過去に最良レコードデータベースにおけるデータの品質を改善していないことが決定される場合があり、異なる手法または閾値が、自動的に選択または調整されてもよい場合がある。
【００５６】
図10は、レコードマージおよび/または統合と関連付けられ得るシステム1000のブロック図である。システム1000は、レコードを記憶するデータソース1010を含み、各レコードは、いくつかのフィールド(例えば、ビジネスパートナー名、ライセンス名、および郵便用住所)を含んでいる。最良レコード計算機プラットフォーム1020が、データソース1010からソースレコードを受信することができる。最良レコード計算機プラットフォーム1020は、本明細書に記載される実施形態のいずれかにより、データソース1010から受信したソースレコードを統合および/またはマージし、最良レコードを最良レコードデータベース1030に記憶することができる。
【００５７】
いくつかの実施形態によれば、最良レコード計算機プラットフォーム1020はまた、シミュレーションモードの間、テストソースからテストデータを受信することができる。テストデータは、例えば、最良レコードデータベース1030における特定のフィールドが空である、または不正確である理由を検出するために使用され得る。さらに、GUI1040は、オペレータから生存グループおよび生存ルールの情報を受信するために、および/またはレポートをオペレータに与えるために使用され得る。それに応じて、GUI1040により、生存グループおよび/または生存ルールは、ビジネスユーザによって容易に構成および変更可能にすることができる。所要の技術的な知識は存在しなくてもよく、その代わり、ユーザは、構成へと、およびその構成から実際の動作コードへと直接変換可能なビジネス要件を決定する必要があり得るだけである。
【００５８】
したがって、本明細書に記載されるいくつかの実施形態は、コード内の分岐が抑えられ、または回避され得るように、生存構成(ルールおよびグループ)に従って、処理コードの自動生成を可能にすることができる。結果として、処理コードは、ユーザ特有の生存構成にほぼ最適化され得る。さらに、生存グループごとに、1つのソースレコード(例えば、「最高優先度」レコード)が、すべての生存ルール次元に従って計算され得る。この計算は、いくつかの実施形態によれば、すべての生存グループについて同時に実行可能である。さらに、(生存グループのそれぞれによって最良レコードを増分的に形成するのではなく)最良レコードは、単一の構成プロセスを用いて構成または形成され得、すべてのマッチグループについての最良レコードは、同時に構成可能である(これによりマッチグループの数が増加するにつれて、ほぼ平坦な性能曲線がもたらされ得る)。
【００５９】
以下に様々な追加の実施形態を示し、それらは、すべての可能な実施形態の定義を構成しておらず、当業者は、本発明が多数の他の実施形態に適用可能であることを認識するであろう。さらに、以下の実施形態は、明瞭にするために簡潔に説明されているが、当業者は、必要応じて、これらのならびに他の実施形態および適用例に適応させるために、上述の装置および方法に対していかに任意の変更を行うべきであるかを認識するであろう。
【００６０】
実施形態は、特定のタイプのデータに関して説明されているが、実施形態を他のタイプの情報と関連付けることができることに留意されたい。例えば、販売注文、経済的情報、および健康データを本明細書に記載される実施形態のいずれかにより処理することができる。
【００６１】
さらに、実施形態が特定の一連のステップを使用して示されてきたが、実施形態は、任意の他のいくつかの異なるやり方で実施してもよい。例えば、生存グルーピングおよび/または生存ルールのアプリケーションの異なるタイプが、本明細書に記載される実施形態のいずれかにより適用され得る。
【００６２】
実施形態は、例示の目的でのみ、本明細書に説明されている。当業者は、本明細書から、実施形態が説明されたものに限定されず、しかし、添付の特許請求の趣旨および範囲によってのみ限定される修正形態および変更形態を用いて実施され得ることを理解するであろう。
【符号の説明】
【００６３】
100  システム
110  ERPシステム
112  CRMシステム
114  レガシーシステム
120  最良レコード計算機プラットフォーム
130  最良レコードデータベース
【図１】
2013137763.tif 000008
【図２】
2013137763.tif 000009
【図３】
2013137763.tif 000010
【図４】
2013137763.tif 000011
【図５】
2013137763.tif 000012
【図６】
2013137763.tif 000013
【図７】
2013137763.tif 000014
【図８】
2013137763.tif 000015
【図９】
2013137763.tif 000016
【図１０】
2013137763.tif 000017
【外国語明細書】
2013137763000001.pdf