JP2013137763A - 生存ルールによるソースレコードをマージするためのシステムおよび方法 - Google Patents

生存ルールによるソースレコードをマージするためのシステムおよび方法 Download PDF

Info

Publication number
JP2013137763A
JP2013137763A JP2012277898A JP2012277898A JP2013137763A JP 2013137763 A JP2013137763 A JP 2013137763A JP 2012277898 A JP2012277898 A JP 2012277898A JP 2012277898 A JP2012277898 A JP 2012277898A JP 2013137763 A JP2013137763 A JP 2013137763A
Authority
JP
Japan
Prior art keywords
survival
record
source
group
rule
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2012277898A
Other languages
English (en)
Inventor
Haham Uri
ウリ・ハハム
Machol Gary
ゲイリー・マチョル
Rozenwald Guy
ガイ・ローゼンヴァルト
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SAP SE filed Critical SAP SE
Publication of JP2013137763A publication Critical patent/JP2013137763A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/35—Clustering; Classification
    • G06F16/355—Class or cluster creation or modification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】入力データレコードを効率的かつ正確に処理および/またはマージするための方法および機構を提供する。
【解決手段】複数のソースレコードが複数のデータソースから受信され得、各ソースレコードは、複数のフィールドを含んでいる。異なるデータソースからのソースレコードのマッチグループが同一エンティティに関連していることが決定され得、単一の最良レコードが、フィールド値に基づいて自動的に作成され得る。この作成には、例えば、第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当てること、および第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てることを含むことができる。マッチグループにおけるすべてのレコードは、単一のクエリを使用して、第1のおよび第2の生存ルールにより同時に順位付けされ、最良レコードは、他アプリケーションのために記憶される。
【選択図】図１

Description

諸実施形態は、いくつかの異なるソースレコードに基づくレコードの作成に関する。より詳細には、諸実施形態は、生存ルールによりレコードを作成するためのシステムおよび方法を提供する。
会社または企業が、様々なエンティティについての情報を電子レコードの形態で保管する場合がある。例えば、法人が、従業員データベースを保有していることがあり得、その場合、データベースにおける各行は、特定の従業員についての情報(例えば、従業員の氏名、雇用日、および給与)を含んでいるレコードを表す。さらに、実際には、種々の電子レコードが、単一のエンティティに関連している場合がある。例えば、人事データベースと営業データベースの両方に、同一従業員についてのレコードが含まれていることがあり得る。場合によっては、複数レコードを統合して、データベースに表されるエンティティごとに単一の電子レコードを含んでいるデータストアを作成することが望ましい場合がある。このような目標が、例えば、マスターデータ管理プログラムと関連付けられることがあり得る。
現在のところ、マスターデータ管理プログラムの統合プロセスは、時間のかかる操作である。例えば、いくつかの異なる統合ルールは、順番に適用され得、各アプリケーションは、最終レコードが作成されるまで、別個のデータベースクエリおよび/またはデータのインターンバージョンの作成を必要とする場合があり得る。しかし、このような手法は、かなりの数のレコードおよび/または入力データソースが含まれている(例えば、数十万のソースレコードを統合する必要があり得る)場合、実践的でない可能性がある。
したがって、入力データレコードを効率的かつ正確に処理および/またはマージするための方法および機構が、本明細書に記載されるいくつかの実施形態により提供され得る。
特許請求の範囲に記載の手段によって課題を解決する。
いくつかの実施形態によるレコード統合と関連付けられ得るシステムのブロック図である。 いくつかの実施形態によるレコード統合と関連付けられるデータフローを示す図である。 いくつかの実施形態によるレコード統合と関連付けられるデータフローを示す図である。 いくつかの実施形態によるレコード統合と関連付けられるデータフローを示す図である。 いくつかの実施形態によるレコード統合と関連付けられるデータフローを示す図である。 いくつかの実施形態によるプラットフォームのブロック図である。 いくつかの実施形態による方法の流れ図である。 いくつかの実施形態によるソースレコードデータベースの一部を示す図である。 いくつかの実施形態による最良レコードデータベースの一部を示す図である。 いくつかの実施形態によるレコード統合と関連付けられ得るシステムのブロック図である。
図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において、保存され得る。
いくつかの実施形態によれば、ユーザが生存グループを構成し、ルールがそれぞれのグループと関連付けられる場合、プロセスが、自動的にトリガされて、そのユーザの構成についてカスタマイズされたコードを生成することが可能である。このような手法により、この構成に基づく動的な分岐の必要性を回避することが可能になり、最適化が、必要に応じてハードコード化されることが可能になる。さらに、場合によっては、レコードが、生存グループごとにすべてのグループについて同時に選択され得、生存グループの数が増加するにつれて、ほぼ平坦な性能曲線がもたらされることになり、最良レコードを生存グループのそれぞれによって増分的に形成するのではなく、最良レコードは、単一の構成プロセスを使用して形成され得る(所要の処理ステップが抑えられる)。さらに、すべてのマッチグループについての最良レコードは同時に構成可能であり、これにより、マッチグループの数が増加するにつれて、ほぼ平坦な性能曲線がもたらされる。
例えば、いかにして生存ルールおよび生存グループがモデル化され得るかを検討する。具体的には、生存ルールを有する「デフォルト」レコードレベルの生存グループ、すなわち、
Figure 2013137763
は、他の生存グループにおいてカバーされないすべてのフィールドをカバーすることが可能である。
それらのデフォルトルールと関連付けられて結果として得られる疑似コードは、以下、すなわち、
Figure 2013137763
の通りであり得る。
次に、(2つのフィールドをカバーする)1つまたは複数のオーバーライド生存グループおよびその生存ルール、
Figure 2013137763
が構成され得る。
それらのオーバーライドルールと関連付けられて結果として得られる疑似コードは、以下、すなわち、
Figure 2013137763
の通りであり得る。
次いで、最良レコードが、以下、すなわち、
Figure 2013137763
の通り、すべてのマッチグループについて同時にいくつかのソースレコードから構成され得る。
いくつかの実施形態によれば、命令論理(例えば、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 最良レコードデータベース

Claims (24)

  1. 複数のソースレコードを複数のデータソースから受信するステップであって、各ソースレコードが、複数のフィールドを含む、ステップと、
    異なるデータソースからのソースレコードのマッチグループが同一エンティティに関連していることを決定するステップと、
    前記マッチグループにおける異なるソースレコードからのフィールド値に基づいて、前記マッチグループについて単一の最良レコードを自動的に作成するステップであって、前記作成するステップが、
    第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当てるステップ、
    第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てるステップ、および
    単一のクエリを使用して、前記第1の生存ルールおよび前記第2の生存ルールにより、前記マッチグループにおけるすべてのソースレコードを同時に順位付けするステップ
    を含む、ステップと、
    前記最良レコードを記憶するステップと
    を含む、コンピュータ実施方法。
  2. 前記第1の生存ルールまたは前記第2の生存ルールのうちの1つが、(i)信頼度、(ii)最新度、または(iii)完全度のうちの少なくとも1つと関連付けられる、請求項1に記載の方法。
  3. ユーザから生存構成情報を受信するステップと、
    前記受信した生存構成情報に基づいて、自動的にコードを生成して、実行されると、前記単一の最良レコードを作成するステップと
    をさらに含む、請求項1に記載の方法。
  4. 前記コードが、デフォルト生存グループ、オーバーライド生存グループを作成し、前記単一のクエリが、複数マッチグループについて前記最良レコードを同時に構成する、請求項3に記載の方法。
  5. 単一のソースレコードが、複数の生存ルール次元に従って、生存グループごとに計算される、請求項1に記載の方法。
  6. 複数のソースレコードが、複数生存グループについて同時に計算される、請求項5に記載の方法。
  7. 前記クエリが、構造化されたクエリ言語プロトコルと関連付けられる、請求項1に記載の方法。
  8. 前記作成するステップが、列ベースのメモリ内テーブルと関連付けられる、請求項1に記載の方法。
  9. 前記データソースの少なくとも1つが、(i)企業資源計画データベース、(ii)顧客関係管理データベース、(iii)人事データベース、または(iv)レガシーデータベースのうちの少なくとも1つを含む、請求項1に記載の方法。
  10. 単一のソースレコードのみを含んでいるマッチグループを識別するステップをさらに含み、前記作成するステップが、前記識別されたマッチグループについて実行されない、
    請求項1に記載の方法。
  11. 方法を実行するようにコンピュータプロセッサによって実行可能なプログラムコード命令を記憶する非一時的コンピュータ可読媒体であって、前記方法が、
    複数のソースレコードを複数のデータソースから受信するステップであり、各ソースレコードが、複数のフィールドを含む、ステップと、
    異なるデータソースからのソースレコードのマッチグループが同一エンティティに関連していることを決定するステップと、
    前記マッチグループにおける異なるソースレコードからのフィールド値に基づいて、前記マッチグループについて単一の最良レコードを作成するステップであり、前記作成するステップが、
    第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当てるステップ、
    第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てるステップ、および
    単一のクエリを使用して、前記第1の生存ルールおよび前記第2の生存ルールにより、前記マッチグループにおけるすべてのソースレコードを同時に順位付けするステップ
    を含む、ステップと、
    前記最良レコードを記憶するステップと
    を含む、媒体。
  12. 前記第1の生存ルールまたは前記第2の生存ルールのうちの少なくとも1つが、(i)信頼度、(ii)最新度、または(iii)完全度のうちの少なくとも1つと関連付けられる、請求項11に記載の媒体。
  13. 前記プログラムコード命令の実行は、前記コンピュータプロセッサに
    ユーザから生存構成情報を受信し、
    前記受信した生存構成情報に基づいて、コードを自動的に生成し、実行されると、前記単一の最良レコードを作成するように
    さらに実行させる、請求項11に記載の媒体。
  14. 前記自動的に生成されたコードが、デフォルト生存グループ、オーバーライド生存グループを作成し、前記単一のクエリが、複数マッチグループについて前記最良レコードを同時に構成する、請求項13に記載の媒体。
  15. 単一のソースレコードが、複数の生存ルール次元に従って、生存グループごとに計算され、さらに、複数のソースレコードが、複数生存グループについて同時に計算される、請求項11に記載の媒体。
  16. 前記クエリが、構造化されたクエリ言語プロトコルと関連付けられ、前記作成するステップが、列ベースのメモリ内テーブルと関連付けられる、請求項11に記載の媒体。
  17. 前記データソースのうちの少なくとも1つが、(i)企業資源計画データベース、(ii)顧客関係管理データベース、(iii)人事データベース、または(iv)レガシーデータベースのうちの少なくとも1つを含む、請求項11に記載の媒体。
  18. 異なるデータソースと関連付けられる複数のソースレコードを用意するソースデータストアであり、各ソースレコードが、複数のフィールドを含む、ストアと、
    最良レコードデータストアと、
    (i)前記ソースデータストアから前記ソースレコードを受信し、(ii)単一の最良レコードを前記最良レコードデータストアに記憶する計算最良レコードプラットフォームであり、前記マッチグループにおける異なるソースレコードからのフィールド値に基づいて、前記マッチグループについて単一の最良レコードを作成する、計算最良レコードプラットフォームと
    を備える、システムであって、
    前記作成することが、
    第1のセットのフィールドを第1の生存ルールと関連付けられる第1の生存グループに割り当てること、
    第2のセットのフィールドを第2の生存ルールと関連付けられる第2の生存グループに割り当てること、および
    単一のクエリを使用して、前記第1の生存ルールおよび前記第2の生存ルールにより、前記マッチグループにおけるすべてのソースレコードを同時に順位付けること
    を含む、システム。
  19. 前記第1の生存ルールまたは前記第2の生存ルールのうちの少なくとも1つが、(i)信頼度、(ii)最新度、または(iii)完全度のうちの少なくとも1つと関連付けられる、請求項18に記載のシステム。
  20. 前記プログラムコード命令の実行は、前記コンピュータプロセッサに
    ユーザから生存構成情報を受信し、
    前記受信した生存構成情報に基づいて、コードを自動的に生成し、実行されると、前記単一の最良レコードを作成するように
    さらに実行させる、請求項18に記載のシステム。
  21. 前記自動的に生成されたコードが、デフォルト生存グループ、オーバーライド生存グループを作成し、前記単一のクエリが、複数マッチグループについて前記最良レコードを同時に構成する、請求項20に記載のシステム。
  22. 単一のソースレコードが、複数の生存ルール次元に従って、生存グループごとに計算され、さらに、複数のソースレコードが、複数生存グループについて同時に計算される、請求項18に記載のシステム。
  23. 前記クエリが、構造化されたクエリ言語プロトコルと関連付けられ、前記作成することが、列ベースのメモリ内テーブルと関連付けられる、請求項18に記載のシステム。
  24. 前記データソースのうちの少なくとも1つが、(i)企業資源計画データベース、(ii)顧客関係管理データベース、(iii)人事データベース、または(iv)レガシーデータベースのうちの少なくとも1つを含む、請求項18に記載のシステム。
JP2012277898A 2011-12-21 2012-12-20 生存ルールによるソースレコードをマージするためのシステムおよび方法 Pending JP2013137763A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/333,073 2011-12-21
US13/333,073 US8943059B2 (en) 2011-12-21 2011-12-21 Systems and methods for merging source records in accordance with survivorship rules

Publications (1)

Publication Number Publication Date
JP2013137763A true JP2013137763A (ja) 2013-07-11

Family

ID=47562914

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012277898A Pending JP2013137763A (ja) 2011-12-21 2012-12-20 生存ルールによるソースレコードをマージするためのシステムおよび方法

Country Status (4)

Country Link
US (1) US8943059B2 (ja)
EP (1) EP2608074B1 (ja)
JP (1) JP2013137763A (ja)
CN (1) CN103177068B (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017509954A (ja) * 2014-01-21 2017-04-06 ポキットドク インコーポレイテッド 動的文書マッチング及びマージング

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2904743B1 (en) 2012-10-02 2017-09-06 Mordecai Barkan Secure computer architectures, systems, and applications
US9342695B2 (en) 2012-10-02 2016-05-17 Mordecai Barkan Secured automated or semi-automated systems
US11188652B2 (en) 2012-10-02 2021-11-30 Mordecai Barkan Access management and credential protection
US9672360B2 (en) * 2012-10-02 2017-06-06 Mordecai Barkan Secure computer architectures, systems, and applications
US11593326B2 (en) * 2012-10-08 2023-02-28 GiantChair, Inc. Method and system for managing metadata
US20140164378A1 (en) * 2012-12-11 2014-06-12 International Business Machines Corporation Source record management for master data
WO2014190209A1 (en) * 2013-05-22 2014-11-27 Alok Pareek Apparatus and method for pipelined event processing in a distributed environment
US11093521B2 (en) * 2013-06-27 2021-08-17 Sap Se Just-in-time data quality assessment for best record creation
CN103390036A (zh) * 2013-07-16 2013-11-13 沈阳中科博微自动化技术有限公司 一种应用于封装测试生产线的历史快照存储方法
CN104298695B (zh) * 2013-07-19 2020-06-16 腾讯科技（深圳）有限公司 数据缓存方法、装置及服务器
US9607036B2 (en) * 2013-08-21 2017-03-28 International Business Machines Corporation Managing a data set
US10026114B2 (en) * 2014-01-10 2018-07-17 Betterdoctor, Inc. System for clustering and aggregating data from multiple sources
US11126627B2 (en) 2014-01-14 2021-09-21 Change Healthcare Holdings, Llc System and method for dynamic transactional data streaming
US10769122B2 (en) * 2014-03-13 2020-09-08 Ab Initio Technology Llc Specifying and applying logical validation rules to data
US10007757B2 (en) 2014-09-17 2018-06-26 PokitDok, Inc. System and method for dynamic schedule aggregation
WO2016118619A1 (en) 2015-01-20 2016-07-28 PokitDok, Inc. Health lending system and method using probabilistic graph models
US20160342750A1 (en) 2015-05-18 2016-11-24 PokitDok, Inc. Dynamic topological system and method for efficient claims processing
US10366204B2 (en) 2015-08-03 2019-07-30 Change Healthcare Holdings, Llc System and method for decentralized autonomous healthcare economy platform
US10587555B2 (en) 2015-09-01 2020-03-10 Sap Portals Israel Ltd. Event log analyzer
CA3002032A1 (en) 2015-10-15 2017-04-20 PokitDok, Inc. System and method for dynamic metadata persistence and correlation on api transactions
WO2017189921A1 (en) 2016-04-29 2017-11-02 Dotalign, Inc. Method, apparatus, and computer-readable medium for identifying
US10102340B2 (en) 2016-06-06 2018-10-16 PokitDok, Inc. System and method for dynamic healthcare insurance claims decision support
US10108954B2 (en) 2016-06-24 2018-10-23 PokitDok, Inc. System and method for cryptographically verified data driven contracts
US10601915B2 (en) 2016-12-20 2020-03-24 Striim, Inc. Data stream processor with both in memory and persisted messaging
US10409788B2 (en) 2017-01-23 2019-09-10 Sap Se Multi-pass duplicate identification using sorted neighborhoods and aggregation techniques
WO2018231832A1 (en) 2017-06-12 2018-12-20 PokitDok, Inc. System and method for autonomous dynamic person management
CN107807996A (zh) * 2017-11-08 2018-03-16 江苏国泰新点软件有限公司 多数据源多维度数据匹配的方法、装置、设备和存储介质
CN110457348B (zh) * 2018-05-02 2022-05-10 北京三快在线科技有限公司 一种数据处理方法及装置
US10942906B2 (en) * 2018-05-31 2021-03-09 Salesforce.Com, Inc. Detect duplicates with exact and fuzzy matching on encrypted match indexes
CN109034199B (zh) * 2018-06-25 2022-02-01 泰康保险集团股份有限公司 数据处理方法及装置、存储介质和电子设备
US11830012B2 (en) * 2018-12-13 2023-11-28 Target Brands, Inc. System for U.S. customs compliance for overseas importers
CN110555071A (zh) * 2019-09-03 2019-12-10 北京明略软件系统有限公司 数据融合处理方法和装置、存储介质及电子装置
WO2022006151A1 (en) * 2020-06-29 2022-01-06 6Sense Insights, Inc. Aggregation of noisy datasets into master firmographic database

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005502132A (ja) * 2001-09-05 2005-01-20 シーメンス メディカル ソルーションズ ヘルス サーヴィシズ コーポレイション レコード処理統合システム

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1109115A1 (en) * 1999-12-14 2001-06-20 Sun Microsystems, Inc. Merging driver for accessing multiple database sources
US6604110B1 (en) * 2000-08-31 2003-08-05 Ascential Software, Inc. Automated software code generation from a metadata-based repository
WO2003021473A1 (en) * 2001-08-30 2003-03-13 Privasource, Inc. Data source privacy screening systems and methods
US6965886B2 (en) * 2001-11-01 2005-11-15 Actimize Ltd. System and method for analyzing and utilizing data, by executing complex analytical models in real time
US8452787B2 (en) * 2001-12-28 2013-05-28 International Business Machines Corporation Real time data warehousing
US8200622B2 (en) * 2002-05-31 2012-06-12 Informatica Corporation System and method for integrating, managing and coordinating customer activities
US20040107189A1 (en) * 2002-12-03 2004-06-03 Lockheed Martin Corporation System for identifying similarities in record fields
US8166033B2 (en) * 2003-02-27 2012-04-24 Parity Computing, Inc. System and method for matching and assembling records
US20040181512A1 (en) * 2003-03-11 2004-09-16 Lockheed Martin Corporation System for dynamically building extended dictionaries for a data cleansing application
US7376680B1 (en) * 2003-04-07 2008-05-20 Charles Loren Kettler System and method for cleansing, linking and appending data records of a database
US7177877B2 (en) * 2003-05-29 2007-02-13 Electronic Data Systems Corporation Method and system for externalizing conditional logic for collecting multi-purpose objects
US7283994B2 (en) * 2003-09-15 2007-10-16 Sap Ag Merging of products into a database
US8825502B2 (en) * 2003-09-30 2014-09-02 Epic Systems Corporation System and method for providing patient record synchronization in a healthcare setting
CA2560277A1 (en) * 2004-03-19 2005-09-29 Oversight Technologies, Inc. Methods and systems for transaction compliance monitoring
US7739309B2 (en) * 2004-09-30 2010-06-15 Microsoft Corporation Method, system, and computer-readable medium for merging data from multiple data sources for use in an electronic document
US8224830B2 (en) * 2005-03-19 2012-07-17 Activeprime, Inc. Systems and methods for manipulation of inexact semi-structured data
US7493344B2 (en) * 2005-04-01 2009-02-17 Schlumberger Technology Corporation Method and system for dynamic data merge in databases
US7496588B2 (en) * 2005-06-27 2009-02-24 Siperian, Inc. Method and apparatus for data integration and management
US7603350B1 (en) * 2006-05-09 2009-10-13 Google Inc. Search result ranking based on trust
US9286595B2 (en) * 2006-08-02 2016-03-15 Emc Corporation System and method for collecting and normalizing entitlement data within an enterprise
US7634508B2 (en) * 2007-03-29 2009-12-15 Microsoft Corporation Processing of duplicate records having master/child relationship with other records
US20080319983A1 (en) * 2007-04-20 2008-12-25 Robert Meadows Method and apparatus for identifying and resolving conflicting data records
US7966291B1 (en) * 2007-06-26 2011-06-21 Google Inc. Fact-based object merging
EP2058733A3 (en) * 2007-11-09 2009-09-02 Avro Computing Inc. Multi-tier interface for management of operational structured data
US7895174B2 (en) * 2008-03-27 2011-02-22 Microsoft Corporation Database part table junctioning
US20100223231A1 (en) * 2009-03-02 2010-09-02 Thales-Raytheon Systems Company Llc Merging Records From Different Databases
US8468160B2 (en) * 2009-10-30 2013-06-18 International Business Machines Corporation Semantic-aware record matching
US8521758B2 (en) * 2010-01-15 2013-08-27 Salesforce.Com, Inc. System and method of matching and merging records
US8341131B2 (en) * 2010-09-16 2012-12-25 Sap Ag Systems and methods for master data management using record and field based rules
US8364692B1 (en) * 2011-08-11 2013-01-29 International Business Machines Corporation Identifying non-distinct names in a set of names

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005502132A (ja) * 2001-09-05 2005-01-20 シーメンス メディカル ソルーションズ ヘルス サーヴィシズ コーポレイション レコード処理統合システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6016038709; サンデリック デヤン: ＳＱＬ Ｓｅｒｖｅｒ ２００５ ストアドプロシージャプログラミング 初版, 20070320, ｐｐ．２７〜２９，４０, 株式会社翔泳社 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017509954A (ja) * 2014-01-21 2017-04-06 ポキットドク インコーポレイテッド 動的文書マッチング及びマージング

Also Published As

Publication number Publication date
US8943059B2 (en) 2015-01-27
CN103177068B (zh) 2018-03-13
CN103177068A (zh) 2013-06-26
US20130166552A1 (en) 2013-06-27
EP2608074B1 (en) 2019-06-05
EP2608074A3 (en) 2013-08-07
EP2608074A2 (en) 2013-06-26

Similar Documents

Publication Publication Date Title
JP2013137763A (ja) 生存ルールによるソースレコードをマージするためのシステムおよび方法
JP7273045B2 (ja) Ｓｑｌクエリプランを最適化するための次元コンテキスト伝搬技術
US20230139783A1 (en) Schema-adaptable data enrichment and retrieval
CN107003868B (zh) 处理包含联合类型操作的查询
US20160004757A1 (en) Data management method, data management device and storage medium
EP2680151A1 (en) Distributed data base system and data structure for distributed data base
US10171311B2 (en) Generating synthetic data
US10157234B1 (en) Systems and methods for transforming datasets
GB2555087A (en) System and method for retrieving data from server computers
US11461333B2 (en) Vertical union of feature-based datasets
US20180365294A1 (en) Artificial intelligence driven declarative analytic platform technology
US11657069B1 (en) Dynamic compilation of machine learning models based on hardware configurations
US8880485B2 (en) Systems and methods to facilitate multi-threaded data retrieval
US11636124B1 (en) Integrating query optimization with machine learning model prediction
AU2014101659A4 (en) Metadata automated system
US9489423B1 (en) Query data acquisition and analysis
US11354313B2 (en) Transforming a user-defined table function to a derived table in a database management system
JP2017537398A (ja) 一組の構造化データタームからの非構造化検索クエリの生成
US8200673B2 (en) System and method for on-demand indexing
US11928125B2 (en) Cleaning and organizing schemaless semi-structured data for extract, transform, and load processing
CN111971666B (zh) 优化sql查询计划的维度上下文传播技术
KR102314068B1 (ko) 동물병원 통합 데이터베이스 구축 시스템 및 방법
WO2013128611A1 (ja) データ管理システム、データ管理方法、及び計算機読み取り可能な記憶媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151218

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160929

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161007

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170105

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20170227