JP2023519551A - 実体の複数の一意の識別子のための多値主キー - Google Patents

Abstract

データベース・システム内の実体を明確に識別するためのコンピュータ実装方法が提供され得る。方法は、データ項目を、異なる属性を含むレコードとしてデータベースのテーブルに格納することと、データ項目の属性の選択された組み合わせに関する命名規則を格納することと、命名規則に優先順位を付けることとを含む。方法は、データ項目の属性の選択された組み合わせの各々に対してハッシュ値を決定することと、決定されたハッシュ値および優先順位付けされた命名規則を使用して重複するデータ項目を識別することとも含む。

Description

本発明は、一般に、データベース・システムに関し、より詳細には、データベース・システム内の実体を明確に識別するためのコンピュータ実装方法に関する。本発明は、データベース・システム内の実体を明確に識別するための関連するデータベース・システム、および方法を実行するように適応されたコンピュータ・プログラム製品にさらに関する。

企業の情報管理は、依然として企業のＩＴ（Information Technology：情報技術）組織の主要なテーマの１つとなっている。このことは、大規模なグローバル２０００企業だけでなく、中小企業にも当てはまる。その理由は単純であり、情報化時代において成功するために管理されるべきデータ管理のソースの数および大量のデータが、ますます増加しているからである。この困難な状況に対処するための１つの手法は、データ・ウェアハウス・プロジェクトとの関連において企業のデータ・カタログを作成すること、およびデータ管理の概念を使用することだった。しかし現実は、かつてない短い周期で新しいデータ・ソースおよび新しい種類のデータがＩＴ組織を襲ったため、この手法が極めて困難であるということを示した。したがって、多くの企業アプリケーションにおいて、および重複するデータ・オブジェクトのそのようなアプリケーション全体にわたって、この一般的な問題に対処するためのより動的な方法が必要とされている。

例えば、同じ顧客が、わずかに異なる名前で、または異なる書式に配置された雇用者識別番号（例えば、納税者番号）で、ＥＲＰシステムに何度も入力される可能性がある。同じ顧客名が、大文字または大文字と小文字が混在して、あるいは完全な企業名または省略名で保存されることがあるため、何らかのユニット制約（unit constrain）を作成することは十分ではない。時間と共に、そのようなテーマが発見され得るが、他の関連するデータのマージは、多くの場合、困難であり、時間がかかり、ときには不可能である。やがて、インボイス、発注、および多くのその他の関連するデータ・オブジェクトが、ＥＲＰシステム内に（および顧客関係管理システム（ＣＲＭ：customer relationship management system）、サプライ・チェーン管理システム（ＳＣＭ：supply chain management system）、ロジスティック・システムなどのような関連するシステム内にも）作成されることがある。これらのシステムはすべて、重複する顧客レコードを使用することもある。例えば、累積的な発注金額に基づいて顧客に割引を提供したい場合、保存されている発注を異なる顧客データと集約することが必要になり、この機能は、現在のＥＲＰシステムにおいて使用できないことがある。

しかし、説明された問題は、顧客データなどを格納しているデータベースのみに存在するのではなく、高度に技術的なアプリケーション用のデータベース（例えば、コンピュータ・リソースへのアクセスを制御し、優先順位を付け、許可および拒否するために使用される構成管理データベース（ＣＭＤＢ：configuration management databases））にも存在する。

エントリ・ストレージ・システム（entries storage system）の重複排除のためのコンピュータ実装方法に関連する複数の開示が存在する。文献ＵＳ２０１７／０３０８５５７Ａ１は、データベース内のデータを浄化し、重複排除するための方法およびシステムを開示している。この方法は、データ・フィールドに基づいて複数のレコードから不要なレコードをフィルタリングすること、および浄化ルールを適用して浄化されたデータベースを作成することを含む。類似性ベクトルが生成され、各ベクトルは、浄化されたデータベース内の離れたデータ・エントリの一対比較に対応する。各ベクトルに、一致、不一致、および未分類のうちの１つとしてラベルを付けるために、照合ルールが適用される。

さらに、文献ＵＳ２０１７／００１１０８８Ａ１は、データベース内のレコードの少なくとも２つのフィールド・グループに関して、計算されたハッシュ値を含んでいるデータベース内の二重の部分を見つけるための方法を開示しており、フィールド・グループがレコードの少なくとも２つのフィールドを含み、レコードの数個のグループのハッシュ値が、各レコードに格納された各フィールド・グループの少なくとも２年以内の値に基づく。

しかし、前述したように、問題に対処するための既知の手法は、企業アプリケーションまたは技術的アプリケーションあるいはその両方を切れ目なく労力を要せずにサポートしているデータベース内の複数のエントリを処理するときに、企業の情報組織が直面している困難を解決することができない。

したがって、前述した技術的問題を克服し、同じデータ・オブジェクトまたは異なるデータ・オブジェクトあるいはその両方に関連する実体を正しく格納して明確に識別するための高度な解決策を提供する必要があることがある。

本発明の１つの態様によれば、データベース・システム内の実体を明確に識別するためのコンピュータ実装方法が提供されてよい。方法は、データ項目をデータベースのテーブルに格納することであって、データ項目が、複数の属性を含んでいるレコードとして格納される、格納することと、データ項目の属性の選択された組み合わせに関する命名規則を格納することと、命名規則に優先順位を付けることとを含んでよい。方法は、データ項目の属性の選択された組み合わせの各々に対してハッシュ値を決定することと、決定されたハッシュ値および優先順位付けされた命名規則を使用して重複するデータ項目を識別することとを含んでもよい。

本発明の別の態様によれば、データベース・システム内の実体を明確に識別するためのデータベース・システムが提供されてよい。データベース・システムは、データ項目をデータベース・システムのテーブルに格納するように適応された第１の格納手段であって、データ項目が、複数の属性を含んでいるレコードとして格納される、第１の格納手段と、データ項目の属性の選択された組み合わせに関する命名規則を格納するように適応された第２の格納手段と、命名規則に優先順位を付けるように適応された優先順位付け手段とを備えてよい。データベース・システムは、データ項目の属性の選択された組み合わせの各々に対してハッシュ値を決定するように適応された決定手段と、決定されたハッシュ値および優先順位付けされた命名規則を使用して重複するデータ項目を識別するように適応された識別手段とを備えてもよい。

ワークロード環境内のノード上でのステートレス・サービスの実行のための提案されたコンピュータ実装方法は、複数の利点、技術的効果、貢献、または改善、あるいはその組み合わせを提供し得る。

２つのレコードが同じ物理的実体を識別するという意味での重複するデータ・エントリの問題が、問題なく対処される。提案された解決策は、データベース内の実体を明確に識別するために、データ項目の属性の選択された組み合わせに対するハッシュ値の決定と共に、多値キーおよび命名規則ならびに命名規則の優先順位付けを使用することに基づく。この解決策は、同じ物理的実体を識別するよう意図された複数のレコードを格納している古典的な企業のデータ管理システム（例えば、商用データベース）および技術的データベース（例えば、ＣＭＤＢ）を使用するという問題を解決し得る。

この解決策は、同じ一意の物理的実体が表されるべきである場合に、企業の情報管理がデータベース・システム内の二重の、ただしわずかに異なるエントリを取り除くことを極めて容易にする。提案された方法およびシステムは、この概念に依存し、設定された後に、自動的かつ自律的に機能する。例えば、追加の手動による介入なしで、必要な既定の範囲内で、重複するエントリが自動的に識別され、マージされ得る。

提案された概念は、バックアップ・システムまたはアーカイブ・システムにおける重複排除の労力とは対照的に、オンライン・トランザクション・データベース・システムに特に役立つ。しかし、提案された方法は、他の環境において有利に使用されてよい。提案された概念は、企業のコンピューティング環境内の追加データの増え続けるソースに基づいて、顧客、見込み客、および製品同一性に加えて、個人用デバイスおよび現場のコンピューティング・システム、ならびに（例えば、クラウド・コンピューティングの概念の意味で）リモートにアクセス可能な計算リソースを含む大規模で複雑な企業のＩＴデバイスまたはネットワークを管理するために使用される技術データに関して、企業の知的財産をより良く管理することに役立ち得る。

以下では、本発明の方法および関連するデータベース・システムに適用可能な、本発明の概念の追加の実施形態が説明される。

方法の１つの有用な実施形態によれば、データベース・システムはリレーショナル・データベース・システムであってよい。これが、最も一般的な応用を表し得る。しかし、提案された概念の場合、オブジェクト指向データベース、グラフ・データベース、階層型データベース、データ・レコードを格納する単層ファイルシステムなどの、その他の種類のデータベースまたはストレージの概念が、提案された技術思想に使用されてよい。

方法の別の有用な実施形態によれば、データベース・システムは、構成管理データベース（ＣＭＤＢ）であってよい。そのようなデータベースは、特定の内部組織の基礎になることがあり、特に、データ・センター内の技術的デバイスおよびアプリケーションを管理するために使用されることがある。したがって、提案された概念は、さまざまな技術分野において容易に使用され得る。

有利な実施形態によれば、方法は、決定されたハッシュ値を、マージされた（すなわち、結合された）データ項目の多値キーとして維持することによって、識別された重複するデータ項目をマージすることを含んでもよい。したがって、本明細書では、データベース・システム内の多値キーの概念が、本明細書で提案された概念の実装のための確かな技術的基礎を構築し得る。

高度な実施形態によれば、方法は、識別されたデータ項目と複合関係にある他のデータ項目をマージすることを含んでもよい。したがって、アプリケーションのデータ・フィールド自体が互いに直接関連し得るだけでなく、実体の特徴を表しているすべてのデータが一緒に、明確にアクセス可能になり得るように、従属データ、すなわち識別された重複するデータ項目と複合関係にあるデータがマージされてよい。

別の有利な実施形態によれば、方法は、決定されたハッシュ値に関して、マージされた（すなわち、結合された）データ項目の同じ行識別子へのポインタ（すなわち、行ＩＤ）を維持することを含んでもよい。それによって、主キーの一意性が維持されてよく、行ＩＤがデータベースのテーブル内の実際の主キーになってよい。しかし、行ＩＤは、データベース・ユーザにとって全く不可視である。代替として、行ＩＤは、データベース・ユーザにとって可視であってよいが、データベース・ユーザによって変更可能でなくてよい。

さらに別の高度な実施形態によれば、方法は、テーブルのインデックスを維持することと、結合されたデータ項目に関して、ポインタ値が同じレコード識別子を指し示し得るように、インデックスに関連する探索木内のポインタを維持することとを含んでもよい。したがって、本明細書で提案された概念は、データベース内の高速な探索について説明されてもよい。適用される中心思想は、探索木の機能の速度を低下させない。これは、インデックス木の異なる分岐内のポインタに同じ値を与えることによって実現される。

さらなる高度な実施形態によれば、方法は、命名規則およびそれに関連する優先度の作成に適応された「ｃｒｅａｔｅ ＳＱＬステートメント」（本明細書によって新たに定義される）を使用することを含んでもよい。したがって、ユーザまたは（例えば、ＡＰＩを介する）アプリケーション・プログラムは、特定のアプリケーションに必要とされるような命名規則および関連する優先度、またはデータ項目によって表された実体を識別するために通常は使用される命名規約を作成してよい。

１つの許容される実施形態によれば、方法は、多値主キー（multi-value primary key）をデータベースのテーブル内のレコードの並べ替えに使用することを含んでもよい。したがって、提案された概念は、通常のデータベース・テーブル操作の方法では通常、使用されず、従来のデータベース・システムのテーブルには通常、適用されない。

方法の別の許容される実施形態によれば、多値主キーは、マルチノード・データベース・エンジン上でクラスタ・データをクラスタ化するために使用されてよい。したがって、提案された概念は、より複雑な分散型のデータベースに拡張可能であってもよい。

方法のさらに有用な実施形態によれば、多値主キーは、単一値列のデータ項目に相当してよい。したがって、従来のデータベースで知られているような、テーブル間のデータ・フィールドの比較などの既知の操作が、本明細書で提案された技術的概念に従って適用可能であってもよい。

さらに高度な実施形態によれば、方法は、単一値主キー（single-valued primary key）および多値主キーのデータ・ブロックに関して、統計的データベース・データを収集することを含んでもよい。したがって、方法の技術的概念は、ベスト・プラクティスに従ってデータベース・システムを管理するためだけでなく、多値キーを含んでいる基礎になるデータベース管理システムをより良く管理するための統計的方法の使用を可能にするためでもある。

さらに、実施形態は、コンピュータまたは任意の命令実行システムによって、またはこれらに接続して使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセスできる関連するコンピュータ・プログラム製品の形態をとってよい。この説明の目的で、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、命令実行装置、または命令実行デバイスによって、またはこれらに接続して使用するためのプログラムを格納するか、伝達するか、伝搬するか、または運ぶための手段を含み得る任意の装置であってよい。

本発明の実施形態が、さまざまな対象を参照して説明されるということに注意するべきである。具体的には、一部の実施形態は、方法タイプの請求項を参照して説明され、他の実施形態は、装置タイプの請求項を参照して説明される。ただし、当業者は、前述の説明および以下の説明から、特に注記のない限り、対象の１つの種類に属している特徴の任意の組み合わせに加えて、異なる対象に関連する特徴間、特に、方法タイプの請求項の特徴と装置タイプの請求項の特徴の間の任意の組み合わせも、本明細書内で開示されると見なされるということを推測するであろう。

上で定義された態様および本発明のさらなる態様は、以下に記載された実施形態の例から明らかになり、実施形態の例を参照して説明されるが、本発明はこれらに限定されない。

以下の詳細な説明は、例として、実施形態例を限定するよう意図されていないということを前提として、添付の図面と共に最も良く理解されるであろう。

データベース・システム内の実体を明確に識別するための本発明のコンピュータ実装方法の実施形態のブロック図である。 （ａ）および（ｂ）は、同じ物理的実体の異なるレコードを示すテーブル、および合計発注量に対する割引の問題を説明するテーブルである。 （ａ）、（ｂ）、および（ｃ）は、例示的なフィールド、名前、住所、および発注データを含む階層的に構造化されたデータベース・テーブルである。 （ａ）および（ｂ）は、一意の属性に基づいてマージされるデータベース・テーブル・エントリのエントリを示す図である。 （ｃ）および（ｄ）は、命名規則に基づいてマージされるデータベース・テーブル・エントリのエントリを示す図である。 （ａ）および（ｂ）は、関連するインデックス木と共にマージされるデータベース・テーブル・エントリのエントリを示す図である。 （ａ）および（ｂ）は、関連するインデックス木と共に命名規則に従ってマージされるデータベース・テーブル・エントリのエントリを示す図である。 データベース・システム内の実体を明確に識別するためのデータベース・システムの実施形態のブロック図である。 実施形態例に従って、図７に記載のデータベース・システムを含んでいるコンピューティング・システムのハードウェア・コンポーネントを示す例示的なブロック図である。 実施形態例に従って、クラウド・コンピューティング環境を示す図である。 実施形態に従って、抽象モデル・レイヤを示す図である。

図面の縮尺は、必ずしも一定ではない。図面は単なる略図であり、実施形態例の特定のパラメータを表すよう意図されていない。図面は、代表的な実施形態例のみを示すよう意図されている。図面において、類似する番号は類似する要素を表す。

特許請求される構造および方法の詳細な実施形態が本明細書において開示されるが、開示された実施形態が、さまざまな形態で具現化されてよい特許請求される構造および方法の例にすぎないということが、理解され得る。実施形態例は例にすぎないが、さまざまな形態で具体化されてよく、本明細書において示された実施形態例に限定されると解釈されるべきではない。むしろ、これらの実施形態例は、本開示が詳細かつ完全なものになり、実施形態例の対象になる範囲を当業者に完全に伝えるように、提供される。説明において、周知の特徴および技術の詳細は、提示された実施形態を不必要に分かりにくくするのを避けるために、省略されることがある。

本明細書における「一実施形態」、「実施形態」、「実施形態例」などへの参照は、記載された実施形態が特定の特徴、構造、または特性を含み得るが、必ずしもすべての実施形態が特定の特徴、構造、または特性を含まなくてよいということを示している。さらに、そのような語句は必ずしも同じ実施形態を参照していない。また、特定の特徴、構造、または特性がある実施形態に関連して説明される場合、明示的に説明されるかどうかにかかわらず、他の実施形態に関連してそのような特徴、構造、または特性を実装することは、当業者の知識の範囲内にあると考えられる。

実施形態例の提示を曖昧にしないために、以下の詳細な説明では、従来技術において知られている一部の処理ステップまたは動作が、提示および例示の目的で一緒に結合されていることがあり、場合によっては、詳細に説明されていないことがある。他の例では、従来技術において知られている一部の処理ステップまたは動作が、全く説明されないことがある。以下の説明が、さまざまな実施形態例に従って、際立った特徴または要素に重点を置いているということが、理解されるべきである。

本説明の文脈において、以下の規則、用語、または表現、あるいはその組み合わせが使用されてよい。

「明確に識別する」という用語は、関連するデータ項目によって物理的項目を交換不可能なように一意に識別する能力を示してよい。簡単に言うと、同じ物理的実体を指し示す２つのデータ項目が存在するべきではない。

「実体」という用語は、データ項目（例えば、データベースへのレコード）によって識別されるか、または対処されるか、あるいはその両方である、物理的対象を示してよい。

「データベース・システム」という用語は、データ項目を格納するように適応されたストレージ・デバイス（物理的または論理的のいずれか）を示してよい。配信システムの例は、リレーショナル・データベース・システム、階層型データベース・システム、単層ファイルシステム、グラフ・データベース、またはオブジェクト・データベース、あるいはその組み合わせであってよい。一般に、提案された概念は、多種多様なデータベースにおいて機能することができる。

「リレーショナル・データベース・システム」という用語は、Ｃ．Ｆ． Ｃｏｄｄのルールに従って構造化されているデータベース・システムを示してよい。リレーショナル・データベース・システムは、好ましくはそれぞれ固定長または可変長のいずれかのレコードに、データを格納することが可能にされたストレージ・デバイスを示してよい。通常、特にリレーショナル・データベース・システムにおいて、データは、行を含んでいるテーブル内で構造化される。各行は、属性を含むレコードを表してよい。選択経路を属性に適用することによって、異なるテーブルの異なるレコードの関係が設定されてよい。

「属性」という用語は、データベース・システム内のテーブルのレコード内のフィールドを示してよい。

「命名規則」という用語は、レコードの属性に適用される制約または解釈フレームワークを示してよい。命名規則は、類似しているが異なるデータ項目を互いに関連付けるような方法で作成されてよい。

「命名規則に優先順位を付ける」という用語は、特定の属性または属性の組み合わせに対する命名規則の重要性に従って、使用可能な命名規則の順序を定義することを示してよい。

「ハッシュ値」という用語は、固定長を有するデータ・フィールド（例えば、整数値）への可変長のデータ・フィールド（例えば、テキストフィールド）のマッピングを示してよい。このマッピングは、通常、ハッシュ関数またはハッシュ・テーブルを使用して実行されてよい。

「重複するデータ項目」という用語は、同じ物理的実体に関連するが、同一のデータ項目の代わりに、特定の属性のみにおいて類似する値を含んでよいデータ項目を取り除くプロセスを示してよい。しかし、属性の類似する値は取り除かれず、冗長な情報およびその他の属性のみが取り除かれるということに注意するべきである。

「多値キー」という用語は、キー属性フィールド内に、従来のルールに従う１つのみの代わりに、２つ以上の値を含むという概念を示してよい。これで、一意性は、この特定の属性を介して定義されなくなったが、ユーザが操作アクセス権限を持たなくてよい行ＩＤによって定義されるようになった。

「複合関係」という用語は、ＵＭＬ（universal markup language：ユニバーサル・マークアップ言語）の意味で解釈されてよい。複合関係は、関連性の特定の事例を表してよい。集約および複合の両方において、あるクラスのオブジェクトは、上位のクラスの別のオブジェクトを「所有する」。一例として、家なしでは部屋は存在し得ない。したがって、２つのオブジェクト部屋／家は、複合関係を有する。

「行識別子」という用語は、特定のレコードを一意に識別する、データベースの特定のテーブル内の一意の識別子を示してよい。行識別子（すなわち、行ＩＤ）は、多値主キーに置き換えられ得る元の主キーの置き換えとして使用されてよい。

「インデックス」という用語は、特に検索動作において、データベース・テーブル内の個別のレコードへのアクセス速度を速くするためのメカニズムを示してよい。インデックス木の葉は、特定のレコードへの（例えば、特定の行ＩＤへの）ポインタを含んでよい。

「ＳＱＬステートメント」という用語は、構造化照会言語（ＳＱＬ：structured query language）と呼ばれる、データベースに使用されるプログラミング言語内のコマンドを示してよい。

以下では、各図について詳細に説明する。図内のすべての命令は概略図である。最初に、データベース・システム内の実体を明確に識別するための本発明のコンピュータ実装方法の実施形態のブロック図が説明される。その後、さらなる実施形態に加えて、データベース・システム内の実体を明確に識別するためのデータベース・システムの実施形態が説明される。

図１は、データベース・システム内の実体を明確に識別するためのコンピュータ実装方法１００の好ましい実施形態のブロック図を示している。方法１００は、データ項目を、特にリレーショナル・データベース内のレコードの形態で、ただし任意のその他の格納形式でも、データベースのテーブルに格納すること（１０２）を含む。データ項目は、それぞれ固定長または可変長の複数の属性を含んでいるレコードとして格納される。

方法１００は、データ項目の属性の選択された組み合わせに関する命名規則（特に、属性の２つの組み合わせに関する少なくとも２つの規則）を格納すること（１０４）を含む。組み合わせが１つの属性のみに関連することもできるということに注意することができる。

さらに、方法１００は、命名規則に優先順位を付けること（１０６）（すなわち、命名規則を適用する順序を定義するか、または規則の順序を定義すること）を含む。優先順位付けは、実体識別にとっての命名規則の重要性によって決まるべきである。

次に、方法１００は、データ項目の属性の選択された組み合わせの各々に対して、（ハッシュ関数を使用して）ハッシュ値を決定すること（１０８）と、決定されたハッシュ値および優先順位付けされた命名規則を使用して重複するデータ項目（特に、少なくとも１つのレコード）を識別すること（１１０）とを含む。

言い換えると、命名規則は、特定の実体を一意に識別するための方法である。命名規則は、実体の属性に基づく。例えば、顧客を識別するために、顧客の名前を使用することができる。ほとんどの場合、顧客の名前だけで、顧客を区別するのに十分である。したがって、顧客の名前が第１の命名規則になることができる。次の命名規則は、顧客の納税者識別子（雇用者識別番号（ＥＩＮ：employer identification number）と呼ばれることもある）を使用することができる。

命名規則は、属性のセットに基づくこともでき、例えば、良い命名規則は、顧客の名前および顧客の関連するＥＩＮに基づく命名規則であろう。

特定の実体の命名規則は、命名規則の各重要性に基づいて並べ替えられるべきである。例えば、同じＥＩＮを持つ２つの顧客が存在することがほとんど不可能であるため、ＥＩＮに基づく命名規則がより良い。また、ＥＩＮに基づく命名規則は、システム内で顧客のレコードを作成している人がＥＩＮデータベース（またはデータベース・テーブル）に対するアクセス権限を持っている場合、その人が、他の関連する顧客データに対するアクセス権限も持っている可能性が高いため、さらに重要である。したがって、顧客の名前だけを知っているが、関連するＥＩＮを知らない人は、顧客データのあまり良いソースにならない。したがって、顧客の名前だけに基づく命名規則は、同程度に低い優先度を有するべきである。

命名規則は、特定のテーブルに対して作成され、データベース・エンジンによって自動的に考慮され、適用される。テーブルにレコードを入力するときに、データベース・システムは、すべての適用可能な命名規則（すなわち、ヌル属性値でない属性に基づく名前の単語）のリストを作成する。次に、データベース・エンジンは、各命名規則の値が、連結された属性の値に基づくハッシュ値であるということを決定する。

例えば、ある顧客に対して、前述の第１の命名規則を使用し、その値を、
ＮＲ１＝ｈａｓｈ（顧客名）＝ｈａｓｈ（ＡＢＣ）＝ＵＵＩＤ１、および
ＮＲ２＝ｈａｓｈ（顧客のＥＩＮ）＝ｈａｓｈ（ＥＩＮ１２３４）＝ＵＵＩＤ２として決定してよい。

これを使用して、両方の値が特定のレコードの主キーとして使用され得る。レコードは、多くの命名の単語を含むことができ、その結果、（データベース内の主キーの元の過去の定義とは対照的に）多くの主キーが存在することができる。ここで、関連するレコードが、主キーの各々によって検出され、識別され得るため、主キーの各々は、同じように重要な主キーである。可能性のあるフォアグラウンドの競合に対する解決策は、一意の行ＩＤを真の一意の主キーとして使用することであるが、行ＩＤは通常、データベース・ユーザによってアクセス可能ではない。

複数の値が主キーとして含まれているため、その主キーを外部キーとして使用することもできる。そのため、外部キー制約を作成するために、特定の行の内部識別子である行の行ＩＤ（一意の行識別子）を使用することができ、行ＩＤは、特定の環境下では、データベース・ユーザにとって可視であることができるが、データベース・ユーザのクエリにおいて使用されるべきではない。データベース・エンジンまたはデータベース・システムは、この活動を禁止することがある。

図２（ａ）は、同じ物理的実体の異なるレコードを示すデータベース・テーブル・エントリを示している。この図に関連する説明文が、本明細書の「背景技術」のセクションにある。列ＰＫは、この例では、同じ物理的実体（すなわち、同じ顧客）と呼ばれてよい顧客名ＡＢＣ、Ａ－Ｂ－Ｃ、およびＡＢＣ Ｌｔｄ．に関連する、示された主キーである顧客識別子ＣＩＤ１、ＣＩＤ２、ＣＩＤ３を参照する。この例では、顧客は、２つの類似するが完全に同一ではないＥＩＮ番号ＥＩＮ１２３４およびＥＩＮ－１２３４と共に示されている。

図２（ｂ）は、発注量に対する割引の問題を説明するデータベース・テーブル・エントリを示している。この問題を説明する文が、本明細書の「背景技術」のセクションにある。したがって、図２（ｂ）は、主キーである発注エントリ（ＯＩＤｉ）、発注番号、顧客識別子、および顧客ごとの発注金額を含む発注エントリ・テーブルを示している。２つのテーブル間のリンクは、矢印で示されているように、顧客識別子に基づく。テーブルおよびレコードの形態でのデータベース・エントリのその他すべての例が、この説明された意味で解釈されるべきである。

図３（ａ）、（ｂ）、および（ｃ）は、例示的なフィールド、名前、住所、および発注データを含む階層的に構造化されたデータベース・テーブルを示している。図３（ａ）は、（同一である可能性がある）２つの顧客がデータベースに登録されていることを示している。図３（ｂ）は、図３（ａ）の顧客の関連する住所を示している。顧客の各々は、図３（ｃ）に示されているような発注を持っている。

誰かが、「ＥＩＮ１２３４」を持つ「ＡＢＣ」という名前の新しい顧客を作成したいということが、仮定されてよい。これが、以下の図に示されている。

図４ー１（ａ）および（ｂ）は、一意の属性に基づいてマージされるデータベース・テーブル・エントリのエントリを示している。レコードのそのようなマージの結果として、２つの既存の顧客レコード、具体的には、図４ー１（ａ）内の右側の楕円によって示されているように、図４ー１（ａ）のテーブルの１番目の行のレコード、および図４ー１（ａ）のテーブル内の３番目のレコードを含むレコードがマージされる必要がある。属性「名前」は、より高い優先度を定義する命名規則を使用して作成された３番目の行から来ており（３番目の行では、より優先度の高いＥＩＮ属性が設定されていることに注意されたい）、そのため「ＡＢＣ」が名前として保持される。１番目の行内のＥＩＮフィールドは空であり、そのため、２番目の行からの値が、マージされたレコード内で保持される。その結果、二重の主キーＣＮＲ１＃Ａ、ＣＮＲ２＃Ｂを含むが、行ＩＤ（行識別子）として示された１つの真の一意の識別子を含む、１つのエントリが存在している。

図４ー２（ｃ）および（ｄ）は、上位の文脈において命名規則に基づいてマージされるデータベース・テーブル・エントリのエントリを示している。通常、顧客の文脈では、住所が「命名される」。これは、上位のオブジェクト（すなわち、オブジェクト「顧客」）なしでは住所が存在できないということを意味する。これが住所の命名規則において示され、住所の命名規則では、「顧客」が第１の属性として定義される。上位のオブジェクト（顧客）がマージされるべきであるため、従属オブジェクト（顧客の文脈において命名されるオブジェクト、すなわちここでは住所）もマージする必要があるかどうかを決定する必要がある。

図４ー２（ｃ）および図４ー２（ｄ）は、一意の行ＩＤ ＡＲＩＤ１の下に多値主キーＡＮＲ１＃ＡおよびＡＮＲ１＃Ｂが作成されるように、属性「通り」および「市」がマージされるそのような状況を参照している。

したがって、マージされる顧客が、マージされ得る同じ属性「通り」および「市」を含む２つの住所を持っているということを決定することができる。古い主キーの値ＡＮＲ１＃Ｂは、他のオブジェクトにおいて、または何らかの外部システムにおいても、参照として使用される可能性があるため、この値も保持される。しかし、これは以前の行ＩＤを使用して決定されるため、過度なマージをもたらす可能性がある他の主キーの値との競合のリスクはない。過度なマージは、異なる実体を提示する２つの個別のオブジェクトが、マージされるべきではないにもかかわらず、マージされる状況である。

図５（ａ）および（ｂ）は、関連するインデックス木と共にマージされるデータベース・テーブル・エントリのエントリを示している。前述のマージ技術に加えて、多値の性質にもかかわらず、主キーの一意性をサポートする必要もある。主として、同じ行ＩＤを指し示している複数の主キーの値を格納する必要がある。

特定のテーブル内で、別名が、別名の集合として単一の列に格納され得る。主キー制約を維持するために、この列にインデックスが作成されるときに、別名のリストが個別のリストに分割され、それらの別名の各々が、インデックスにおいて単一の値として使用される。それらすべてのインデックスの葉は、テーブル内の同じレコードを指し示す。これが図５（ａ）および図５（ｂ）に示されている。図５（ａ）では、管理されていないテーブル内の異なる行を参照しているインデックス木の２つの葉が存在しており、図５（ｂ）では、同じ２つのインデックス木の葉が、ここでは多値キーおよび一意の行ＩＤを含んでいる同じレコードを指し示している。

図６（ａ）および（ｂ）は、関連するインデックス木と共に命名規則に従ってマージされるデータベース・テーブル・エントリのエントリを示している。これらの図は、子テーブルの事例を参照している。この場合、上位の（または親）別名に基づいて、１つの追加のインデックスが作成される。上位の別名のリストが、個別の別名に分割され、別名の各々が、インデックスにおいて単一の値として使用される。それらの値は、葉ノードに格納され、子テーブル内の単一のレコードを指し示す。

図６（ａ）および（ｂ）は、関連するインデックス木と共に命名規則に従ってマージされるデータベース・テーブル・エントリのエントリを示している。住所に関して、図６（ａ）に示されているように、上位の属性「顧客」に基づく追加のインデックスが存在している。

当然ながら、３つの子レコードおよび２つの親主キーがある場合、親主キーＣＮＲ１＃ＡおよびＣＮＲ２＃Ｂの両方について３つの行すべてを見つけることができる必要があるため、図６（ｂ）に示されているように、結果として６つの葉ノードが得られる。

図７は、データベース・システム内の実体を明確に識別するためのデータベース・システム７００の実施形態のブロック図を示している。データベース・システム７００は、データ項目をデータベース・システムのテーブルに格納するように適応された第１の格納手段（特に、第１のストレージ・ユニット７０２）を備え、データ項目が、複数の属性を含んでいるレコードとして格納される。

データベース・システム７００は、データ項目の属性の選択された組み合わせに関する命名規則を格納するように適応された第２の格納手段（特に、第２のストレージ・ユニット７０４）と、命名規則に優先順位を付けるように適応された優先順位付け手段（特に、優先順位付けモジュール７０６）と、データ項目の属性の選択された組み合わせの各々に対してハッシュ値を決定するように適応された決定手段（特に、決定ユニット７０８）とを備える。

最後に重要なこととして、データベース・システム７００は、決定されたハッシュ値および優先順位付けされた命名規則を使用して重複するデータ項目を識別するように適応された識別手段（特に、識別モジュール７１０）を備える。

モジュール、ユニット、または手段、あるいはその組み合わせが、それらの間の信号またはメッセージあるいはその両方の交換のために、相互接続され得るということに注意することができる。この接続は、１対１の方法で、またはデータベース・システムの内部バス・システム７１２を使用して、実装されてよい。このデータベース・システムの内部バス・システム７１２に、第１のストレージ・ユニット７０２、第２のストレージ・ユニット７０４、優先順位付けモジュール７０６、決定ユニット７０８、および識別モジュール７１０が、直接的または間接的に接続され得る。

図８は、実施形態例に従って、本発明に含まれているデバイスのブロック図を示している。図８は、単に１つの実施形態の例を提供しており、さまざまな実施形態が実装され得る環境に関して、どのような限定も意味していないと理解されるべきである。図に示された環境に対して、多くの変更が行われてよい。

本明細書において使用されるデバイスは、１つまたは複数のプロセッサ０２、１つまたは複数のコンピュータ可読ＲＡＭ０４、１つまたは複数のコンピュータ可読ＲＯＭ０６、１つまたは複数のコンピュータ可読ストレージ媒体０８、デバイス・ドライバ１２、読み取り／書き込み駆動またはインターフェイス１４、ネットワーク・アダプタまたはインターフェイス１６を含んでよく、これらはすべて通信ファブリック１８を経由して相互接続される。通信ファブリック１８は、プロセッサ（マイクロプロセッサ、通信プロセッサ、およびネットワーク・プロセッサなど）、システム・メモリ、周辺機器、およびシステム内の任意のその他のハードウェア・コンポーネントの間で、データまたは制御情報あるいはその両方を渡すために設計された、任意のアーキテクチャを使用して実装されてよい。

１つまたは複数のオペレーティング・システム１０、および１つまたは複数のアプリケーション・プログラム１１は、各ＲＡＭ０４（通常、キャッシュ・メモリを含む）のうちの１つまたは複数を介してプロセッサ０２のうちの１つまたは複数によって実行するために、コンピュータ可読ストレージ媒体０８のうちの１つまたは複数に格納される。示されている実施形態では、コンピュータ可読ストレージ媒体０８の各々は、内部ハード・ドライブの磁気ディスク・ストレージ・デバイス、ＣＤ－ＲＯＭ、ＤＶＤ、メモリ・スティック、磁気テープ、磁気ディスク、光ディスク、半導体ストレージ・デバイス（ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、フラッシュ・メモリなど）、またはコンピュータ・プログラムおよびデジタル情報を格納できる任意のその他のコンピュータ可読の有形のストレージ・デバイスであってよい。

本明細書において使用されるデバイスは、１つまたは複数のポータブル・コンピュータ可読ストレージ媒体２６に対して読み取りおよび書き込みを行うためのＲ／Ｗ駆動またはインターフェイス１４を含んでもよい。前述のデバイス上のアプリケーション・プログラム１１は、ポータブル・コンピュータ可読ストレージ媒体２６のうちの１つまたは複数に格納され、各Ｒ／Ｗ駆動またはインターフェイス１４を介して読み取られ、各コンピュータ可読ストレージ媒体０８に読み込まれてよい。

本明細書において使用されるデバイスは、ＴＣＰ／ＩＰアダプタ・カードまたは無線通信アダプタ（ＯＦＤＭＡ技術を使用する４Ｇ無線通信アダプタなど）などのネットワーク・アダプタまたはインターフェイス１６を含んでもよい。前述のコンピューティング・デバイス上のアプリケーション・プログラム１１は、ネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、またはその他の広域ネットワーク、あるいは無線ネットワーク）およびネットワーク・アダプタまたはインターフェイス１６を介して、外部コンピュータまたは外部ストレージ・デバイスからコンピューティング・デバイスにダウンロードされてよい。プログラムは、ネットワーク・アダプタまたはインターフェイス１６からコンピュータ可読ストレージ媒体０８に読み込まれてよい。このネットワークは、銅線、光ファイバ、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組み合わせを備えてよい。

本明細書において使用されるデバイスは、ディスプレイ画面２０、キーボードまたはキーパッド２２、およびコンピュータ・マウスまたはタッチパッド２４を含んでもよい。デバイス・ドライバ１２は、画像化のためにディスプレイ画面２０とインターフェイスをとるか、キーボードまたはキーパッド２２とインターフェイスをとるか、コンピュータ・マウスまたはタッチパッド２４とインターフェイスをとるか、または英数字入力およびユーザ選択の圧力検出のためにディスプレイ画面２０とインターフェイスをとるか、あるいはその組み合わせとインターフェイスをとる。デバイス・ドライバ１２、Ｒ／Ｗ駆動またはインターフェイス１４、およびネットワーク・アダプタまたはインターフェイス１６は、ハードウェアおよびソフトウェア（コンピュータ可読ストレージ媒体０８またはＲＯＭ０６あるいはその両方に格納される）を備えてよい。

本明細書に記載されたプログラムは、アプリケーションに基づいて識別され、実施形態例のうちの特定の１つにおいて、そのアプリケーションに関して実装される。ただし、本明細書における特定のプログラムの名前は単に便宜上使用されていると理解されるべきであり、したがって、実施形態例は、そのような名前によって識別されたか、または暗示されたか、あるいはその両方である特定のアプリケーションのみで使用するように限定されるべきではない。

前述の説明に基づいて、コンピュータ・システム、方法、およびコンピュータ・プログラム製品が開示された。しかし、実施形態例の範囲から逸脱することなく、多数の変更および代替が行われ得る。したがって実施形態例は、限定ではなく、例として開示された。

本開示にはクラウド・コンピューティングに関する詳細な説明が含まれているが、本明細書において示された内容の実装は、クラウド・コンピューティング環境に限定されないと理解されるべきである。むしろ、実施形態例は、現在既知であるか、または今後開発される任意のその他の種類のコンピューティング環境と組み合わせて実装できる。

クラウド・コンピューティングは、構成可能な計算リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利なオンデマンドのネットワーク・アクセスを可能にするためのサービス提供モデルであり、管理上の手間またはサービス・プロバイダとのやりとりを最小限に抑えて、これらのリソースを迅速にプロビジョニングおよび解放することができる。このクラウド・モデルは、少なくとも５つの特徴、少なくとも３つのサービス・モデル、および少なくとも４つのデプロイメント・モデルを含んでよい。

特徴は、次のとおりである。

オンデマンドのセルフ・サービス：クラウドの利用者は、サーバの時間およびネットワーク・ストレージなどの計算能力を一方的に、サービス・プロバイダとの人間的なやりとりを必要とせず、必要に応じて自動的にプロビジョニングすることができる。

幅広いネットワーク・アクセス：クラウドの能力は、ネットワークを経由して利用可能であり、標準的なメカニズムを使用してアクセスできるため、異種のシン・クライアントまたはシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による利用を促進する。

リソース・プール：プロバイダの計算リソースは、プールされ、マルチテナント・モデルを使用して複数の利用者に提供される。さまざまな物理的および仮想的リソースが、要求に従って動的に割り当ておよび再割り当てされる。利用者は通常、提供されるリソースの正確な場所に関して管理することも知ることもないという点において、場所に依存しないという感覚があるが、より高い抽象レベルで、場所（例えば、国、州、またはデータ・センター）を指定できることがある。

迅速な順応性：クラウドの能力は、迅速かつ柔軟に、場合によっては自動的にプロビジョニングされ、素早くスケールアウトし、迅速に解放されて素早くスケールインすることができる。プロビジョニングに使用できる能力は、利用者には、多くの場合、任意の量をいつでも無制限に購入できるように見える。

測定されるサービス：クラウド・システムは、計測機能を活用することによって、サービスの種類（例えば、ストレージ、処理、帯域幅、およびアクティブなユーザのアカウント）に適した抽象レベルで、リソースの使用を自動的に制御および最適化する。リソースの使用状況は監視、制御、および報告することができ、利用されるサービスのプロバイダと利用者の両方に透明性が提供される。

サービス・モデルは、次のとおりである。

ＳａａＳ（Software as a Service）：利用者に提供される能力は、クラウド・インフラストラクチャ上で稼働しているプロバイダのアプリケーションの利用である。それらのアプリケーションは、Ｗｅｂブラウザ（例えば、Ｗｅｂベースの電子メール）などのシン・クライアント・インターフェイスを介して、さまざまなクライアント・デバイスからアクセスできる。利用者は、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個々のアプリケーション機能を含む基盤になるクラウド・インフラストラクチャを、限定的なユーザ固有のアプリケーション構成設定を行う可能性を除き、管理することも制御することもない。

ＰａａＳ（Platform as a Service）：利用者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、利用者が作成または取得したアプリケーションをクラウド・インフラストラクチャにデプロイすることである。利用者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、デプロイされたアプリケーション、および場合によってはアプリケーション・ホスティング環境の構成を制御することができる。

ＩａａＳ（Infrastructure as a Service）：利用者に提供される能力は、処理、ストレージ、ネットワーク、およびその他の基本的な計算リソースのプロビジョニングであり、利用者は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアをデプロイして実行できる。利用者は、基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、オペレーティング・システム、ストレージ、デプロイされたアプリケーションを制御することができ、場合によっては、選択されたネットワーク・コンポーネント（例えば、ホスト・ファイアウォール）を限定的に制御できる。

デプロイメント・モデルは、次のとおりである。

プライベート・クラウド：このクラウド・インフラストラクチャは、組織のためにのみ運用される。この組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。

コミュニティ・クラウド：このクラウド・インフラストラクチャは、複数の組織によって共有され、関心事（例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスに関する考慮事項）を共有している特定のコミュニティをサポートする。これらの組織またはサード・パーティによって管理することができ、オンプレミスまたはオフプレミスに存在することができる。

パブリック・クラウド：このクラウド・インフラストラクチャは、一般ユーザまたは大規模な業界団体が使用できるようになっており、クラウド・サービスを販売する組織によって所有される。

ハイブリッド・クラウド：このクラウド・インフラストラクチャは、データとアプリケーションの移植を可能にする標準化された技術または独自の技術（例えば、クラウド間の負荷バランスを調整するためのクラウド・バースト）によって固有の実体を残したまま互いに結合された２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の複合である。

クラウド・コンピューティング環境は、ステートレス、疎結合、モジュール性、および意味的相互運用性に重点を置いたサービス指向の環境である。クラウド・コンピューティングの中心になるのは、相互接続されたノードのネットワークを含んでいるインフラストラクチャである。

ここで図９を参照すると、例示的なクラウド・コンピューティング環境５０が示されている。図示されているように、クラウド・コンピューティング環境５０は、クラウドの利用者によって使用されるローカル・コンピューティング・デバイス（例えば、パーソナル・デジタル・アシスタント（ＰＤＡ：personal digital assistant）または携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎ、あるいはその組み合わせなど）が通信できる１つまたは複数のクラウド・コンピューティング・ノード４０を含んでいる。ノード４０は、互いに通信してよい。ノード４０は、１つまたは複数のネットワーク内で、本明細書において前述されたプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、またはハイブリッド・クラウド、あるいはこれらの組み合わせなどに、物理的または仮想的にグループ化されてよい（図示されていない）。これによって、クラウド・コンピューティング環境５０は、クラウドの利用者がローカル・コンピューティング・デバイス上でリソースを維持する必要のないインフラストラクチャ、プラットフォーム、またはＳａａＳ、あるいはその組み合わせを提供できる。図９に示されたコンピューティング・デバイス５４Ａ～Ｎの種類は、例示のみが意図されており、コンピューティング・ノード４０およびクラウド・コンピューティング環境５０は、任意の種類のネットワークまたはネットワーク・アドレス可能な接続（例えば、Ｗｅｂブラウザを使用した接続）あるいはその両方を経由して任意の種類のコンピュータ制御デバイスと通信することができると理解される。

ここで図１０を参照すると、クラウド・コンピューティング環境５０（図９）によって提供される機能的抽象レイヤのセットが示されている。図１０に示されたコンポーネント、レイヤ、および機能は、例示のみが意図されており、実施形態例がこれらに限定されないということが、あらかじめ理解されるべきである。図示されているように、次のレイヤおよび対応する機能が提供される。

ハードウェアおよびソフトウェア・レイヤ６０は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例は、メインフレーム６１、ＲＩＳＣ（Reduced Instruction Set Computer）アーキテクチャベースのサーバ６２、サーバ６３、ブレード・サーバ６４、ストレージ・デバイス６５、ならびにネットワークおよびネットワーク・コンポーネント６６を含む。一部の実施形態では、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

仮想化レイヤ７０は、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５などの仮想的実体を提供できる抽象レイヤを備える。

一例を挙げると、管理レイヤ８０は、以下で説明される機能を提供してよい。リソース・プロビジョニング８１は、クラウド・コンピューティング環境内でタスクを実行するために利用される計算リソースおよびその他のリソースの動的調達を行う。計測および価格設定８２は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡、およびそれらのリソースの利用に対する請求書またはインボイスの送付を行う。一例を挙げると、それらのリソースは、アプリケーション・ソフトウェア・ライセンスを含んでよい。セキュリティは、クラウドの利用者およびタスクのＩＤ検証を行うとともに、データおよびその他のリソースの保護を行う。ユーザ・ポータル８３は、クラウド・コンピューティング環境へのアクセスを利用者およびシステム管理者に提供する。サービス・レベル管理８４は、必要なサービス・レベルを満たすように、クラウドの計算リソースの割り当てと管理を行う。サービス水準合意（ＳＬＡ：Service Level Agreement）計画および実行８５は、今後の要求が予想されるクラウドの計算リソースの事前準備および調達を、ＳＬＡに従って行う。

ワークロード・レイヤ９０は、クラウド・コンピューティング環境で利用できる機能の例を示している。このレイヤから提供されてよいワークロードおよび機能の例としては、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想クラスルーム教育の配信９３、データ解析処理９４、トランザクション処理９５、およびマルチメディア変更９６が挙げられる。

本発明は、任意の可能な統合の技術的詳細レベルで、システム、方法、またはコンピュータ・プログラム製品、あるいはその組み合わせであってよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を含んでいるコンピュータ可読ストレージ媒体を含んでよい。

コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持および格納できる有形のデバイスであることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組み合わせであってよいが、これらに限定されない。コンピュータ可読ストレージ媒体のさらに具体的な例の非網羅的リストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、読み取り専用メモリ（ＲＯＭ：read-only memory）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：erasable programmable read-only memoryまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：static random access memory）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：compact disc read-only memory）、デジタル・バーサタイル・ディスク（ＤＶＤ：digital versatile disk）、メモリ・スティック、フロッピー・ディスク、命令が記録されているパンチカードまたは溝の中の隆起構造などの機械的にエンコードされるデバイス、およびこれらの任意の適切な組み合わせを含む。本明細書において使用されるとき、コンピュータ可読ストレージ媒体は、それ自体が、電波またはその他の自由に伝搬する電磁波、導波管またはその他の送信媒体を伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、あるいはワイヤを介して送信される電気信号などの一過性の信号であると解釈されるべきではない。

本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から各コンピューティング・デバイス／処理デバイスへ、またはネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、または無線ネットワーク、あるいはその組み合わせ）を介して外部コンピュータまたは外部ストレージ・デバイスへダウンロードされ得る。このネットワークは、銅伝送ケーブル、光伝送ファイバ、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組み合わせを備えてよい。各コンピューティング・デバイス／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェイスは、コンピュータ可読プログラム命令をネットワークから受信し、それらのコンピュータ可読プログラム命令を各コンピューティング・デバイス／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：instruction-set-architecture）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路のための構成データ、あるいは、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組み合わせで記述されたソース・コードまたはオブジェクト・コードであってよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に実行すること、ユーザのコンピュータ上でスタンドアロン・ソフトウェア・パッケージとして部分的に実行すること、ユーザのコンピュータ上およびリモート・コンピュータ上でそれぞれ部分的に実行すること、あるいはリモート・コンピュータ上またはサーバ上で全体的に実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）または広域ネットワーク（ＷＡＮ：wide area network）を含む任意の種類のネットワークを介してユーザのコンピュータに接続されてよく、または接続は、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して行われてよい。一部の実施形態では、本発明の態様を実行するために、例えばプログラマブル・ロジック回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ：field-programmable gate arrays）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：programmable logic arrays）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによって、電子回路をカスタマイズするためのコンピュータ可読プログラム命令を実行してよい。

本発明の態様は、本明細書において、本発明の実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して説明される。フローチャート図またはブロック図あるいはその両方の各ブロック、ならびにフローチャート図またはブロック図あるいはその両方に含まれるブロックの組み合わせが、コンピュータ可読プログラム命令によって実装され得るいうことが理解されるであろう。

これらのコンピュータ可読プログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作を実施する手段を作り出すべく、コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されてマシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が格納されたコンピュータ可読ストレージ媒体がフローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作の態様を実施する命令を含んでいる製品を含むように、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラム可能なデータ処理装置、または他のデバイス、あるいはその組み合わせに特定の方式で機能するように指示できるものであってもよい。

コンピュータ可読プログラム命令は、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で実行される命令が、フローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作を実施するように、コンピュータ、その他のプログラム可能なデータ処理装置、またはその他のデバイスに読み込まれ、コンピュータ上、その他のプログラム可能な装置上、またはコンピュータ実装プロセスを生成するその他のデバイス上で一連の動作可能なステップを実行させるものであってもよい。

図内のフローチャートおよびブロック図は、本発明のさまざまな実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関連して、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つまたは複数の実行可能な命令を備える、命令のモジュール、セグメント、または部分を表してよい。一部の代替の実装では、ブロックに示された機能は、図に示された順序とは異なる順序で発生してよい。例えば、連続して示された２つのブロックは、実際には、含まれている機能に応じて、１つのステップとして同時に実行されるか、時間的に部分的または完全に重複する方法で実質的に同時に実行されるか、あるいは場合によっては逆の順序で実行されてよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方に含まれるブロックの組み合わせは、規定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令の組み合わせを実行する専用ハードウェアベースのシステムによって実装され得るということにも注意する。

本発明のさまざまな実施形態の説明は、例示の目的で提示されているが、網羅的であることは意図されておらず、開示された実施形態に限定されない。記載された実施形態の範囲および思想を逸脱することなく多くの変更および変形が可能であることは、当業者にとって明らかであろう。本明細書で使用された用語は、実施形態の原理、実際の適用、または市場で見られる技術を超える技術的改良を最も適切に説明するため、または他の当業者が本明細書で開示された実施形態を理解できるようにするため選択されている。

本発明は、システム、方法、またはコンピュータ・プログラム製品、あるいはその組み合わせとして具現化されてよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を含んでいるコンピュータ可読ストレージ媒体を含んでよい。

この媒体は、電子、磁気、光、電磁気、赤外線、または伝搬媒体用の半導体システムであってよい。コンピュータ可読媒体の例としては、半導体メモリまたは固体メモリ、磁気テープ、取り外し可能フロッピー・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、剛体磁気ディスク、および光ディスクが挙げられる。光ディスクの現在の例としては、コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、コンパクト・ディスク読み取り／書き込み（ＣＤ－Ｒ／Ｗ：compact disk-read/write）、ＤＶＤ、およびブルーレイディスクが挙げられる。

コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持および格納できる有形のデバイスであることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組み合わせであってよいが、これらに限定されない。コンピュータ可読ストレージ媒体のさらに具体的な例の非網羅的リストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、メモリ・スティック、フロッピー・ディスク、命令が記録されているパンチカードまたは溝の中の隆起構造などの機械的にエンコードされるデバイス、およびこれらの任意の適切な組み合わせを含む。本明細書において使用されるとき、コンピュータ可読ストレージ媒体は、それ自体が、電波またはその他の自由に伝搬する電磁波、導波管またはその他の送信媒体を伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、あるいはワイヤを介して送信される電気信号などの一過性の信号であると解釈されるべきではない。

本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から各コンピューティング・デバイス／処理デバイスへ、またはネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、または無線ネットワーク、あるいはその組み合わせ）を介して外部コンピュータまたは外部ストレージ・デバイスへダウンロードされ得る。このネットワークは、銅伝送ケーブル、光伝送ファイバ、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組み合わせを備えてよい。各コンピューティング・デバイス／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェイスは、コンピュータ可読プログラム命令をネットワークから受信し、それらのコンピュータ可読プログラム命令を各コンピューティング・デバイス／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、あるいは、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組み合わせで記述されたソース・コードまたはオブジェクト・コードであってよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に実行すること、ユーザのコンピュータ上でスタンドアロン・ソフトウェア・パッケージとして部分的に実行すること、ユーザのコンピュータ上およびリモート・コンピュータ上でそれぞれ部分的に実行すること、あるいはリモート・コンピュータ上またはサーバ上で全体的に実行することができる。後者のシナリオでは、リモート・コンピュータを、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザのコンピュータに接続することができ、または接続を、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して行うことができる。一部の実施形態では、本発明の態様を実行するために、例えばプログラマブル・ロジック回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによって、電子回路をカスタマイズするためのコンピュータ可読プログラム命令を実行してよい。

本発明の態様は、本明細書において、本発明の実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して説明される。フローチャート図またはブロック図あるいはその両方の各ブロック、ならびにフローチャート図またはブロック図あるいはその両方に含まれるブロックの組み合わせが、コンピュータ可読プログラム命令によって実装され得るということが理解されるであろう。

これらのコンピュータ可読プログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作を実施する手段を作り出すべく、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されてマシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が格納されたコンピュータ可読ストレージ媒体がフローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作の態様を実施する命令を含んでいる製品を備えるように、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラム可能なデータ処理装置、または他のデバイス、あるいはその組み合わせに特定の方式で機能するように指示できるものであってもよい。

コンピュータ可読プログラム命令は、コンピュータ上、その他のプログラム可能な装置上、または別のデバイス上で実行される命令が、フローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作を実施するように、コンピュータ、その他のプログラム可能なデータ処理装置、または別のデバイスに読み込まれ、コンピュータ上、その他のプログラム可能な装置上、またはコンピュータ実装プロセスを生成するその他のデバイス上で一連の動作可能なステップを実行させるものであってもよい。

図内のフローチャートまたはブロック図あるいはその両方は、本発明のさまざまな実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関連して、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つまたは複数の実行可能な命令を備える、命令のモジュール、セグメント、または部分を表してよい。一部の代替の実装では、ブロックに示された機能は、図に示された順序とは異なる順序で発生してよい。例えば、連続して示された２つのブロックは、実際には、含まれている機能に応じて、実質的に同時に実行されるか、または場合によっては逆の順序で実行されてよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方に含まれるブロックの組み合わせは、規定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令の組み合わせを実行する専用ハードウェアベースのシステムによって実装できるということにも注意する。

本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、本発明を限定することを意図していない。本明細書で使用される単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、特に明示的に示されない限り、複数形も含むことが意図されている。「備える」または「備えている」あるいはその両方の用語は、本明細書で使用される場合、記載された機能、整数、ステップ、動作、要素、またはコンポーネント、あるいはその組み合わせの存在を示すが、１つまたは複数のその他の機能、整数、ステップ、動作、要素、コンポーネント、またはこれらのグループ、あるいはその組み合わせの存在または追加を除外していないということが、さらに理解されるであろう。

添付の特許請求の範囲内のすべてのミーンズまたはステップ・プラス・ファンクション要素の対応する構造、材料、動作、および均等なものは、具体的に特許請求されるその他の特許請求された要素と組み合わせて機能を実行するための任意の構造、材料、または動作を含むことが意図されている。本発明の説明は、例示および説明の目的で提示されているが、網羅的であることは意図されておらず、開示された形態での発明に限定されない。本発明の範囲および思想を逸脱することなく多くの変更および変形が可能であることは、当業者にとって明らかである。本発明の原理および実際的な適用を最も適切に説明するため、およびその他の当業者が、企図されている特定の用途に適しているようなさまざまな変更を伴う多様な実施形態に関して、本発明を理解できるようにするために、実施形態が選択されて説明された。

Claims (20)

1. データベース・システム内の実体を明確に識別するためのコンピュータ実装方法であって、
   データ項目をデータベースのテーブルに格納することであって、前記データ項目が、複数の属性を含んでいるレコードとして格納される、前記格納することと、
   前記データ項目の前記属性の選択された組み合わせに関する命名規則を格納することと、
   前記命名規則に優先順位を付けることと、
   前記データ項目の前記属性の前記選択された組み合わせの各々に対してハッシュ値を決定することと、
   前記決定されたハッシュ値および前記優先順位付けされた命名規則を使用して重複するデータ項目を識別することとを含む、コンピュータ実装方法。
2. 前記データベース・システムがリレーショナル・データベース・システムである、請求項１に記載のコンピュータ実装方法。
3. 前記データベース・システムが構成管理データベースである、請求項１に記載のコンピュータ実装方法。
4. 前記決定されたハッシュ値を、マージされたデータ項目の多値キーとして維持することによって、前記識別された重複するデータ項目をマージすることをさらに含む、請求項１に記載のコンピュータ実装方法。
5. 前記識別されたデータ項目と複合関係にある他のデータ項目をマージすることをさらに含む、請求項４に記載のコンピュータ実装方法。
6. 前記決定されたハッシュ値に関して、前記マージされたデータ項目のうちの１つの同じ行識別子へのポインタを維持することをさらに含む、請求項４に記載のコンピュータ実装方法。
7. 前記テーブルのインデックスを維持することと、
   結合されたデータ項目の前記同じレコード識別子をポインタが指し示すように、前記インデックスに関連する探索木内の前記ポインタを維持することとをさらに含む、請求項１に記載のコンピュータ実装方法。
8. 前記命名規則およびそれに関連する優先度の作成に適応されたｃｒｅａｔｅ ＳＱＬステートメントを使用することをさらに含む、請求項１に記載のコンピュータ実装方法。
9. 多値主キーを、前記データベースの前記テーブル内のレコードの並べ替えに使用することをさらに含む、請求項１に記載のコンピュータ実装方法。
10. 多値主キーが、マルチノード・データベース・エンジン上でクラスタ・データをクラスタ化するために使用される、請求項１に記載のコンピュータ実装方法。
11. 多値主キーが、単一値列のデータ項目に相当する、請求項９に記載のコンピュータ実装方法。
12. 単一値主キーおよび多値主キーのデータ・ブロックに関して、統計的データベース・データを収集することをさらに含む、請求項１に記載のコンピュータ実装方法。
13. 前記データベース・システム内の実体を明確に識別するためのコンピュータ・システムであって、前記コンピュータ・システムが、
    １つまたは複数のコンピュータ・プロセッサと、１つまたは複数のコンピュータ可読ストレージ媒体と、方法を実行できる前記１つまたは複数のプロセッサのうちの少なくとも１つによって実行するために前記コンピュータ可読ストレージ媒体のうちの前記１つまたは複数に格納されたプログラム命令とを備え、前記方法が、
    データ項目をデータベースのテーブルに格納することであって、前記データ項目が、複数の属性を含んでいるレコードとして格納される、前記格納することと、
    前記データ項目の前記属性の選択された組み合わせに関する命名規則を格納することと、
    前記命名規則に優先順位を付けることと、
    前記データ項目の前記属性の前記選択された組み合わせの各々に対してハッシュ値を決定することと、
    前記決定されたハッシュ値および前記優先順位付けされた命名規則を使用して重複するデータ項目を識別することとを含む、コンピュータ・システム。
14. 前記データベース・システムがリレーショナル・データベース・システムである、請求項１３に記載のコンピュータ・システム。
15. 前記データベース・システムが構成管理データベースである、請求項１３に記載のコンピュータ・システム。
16. 前記決定されたハッシュ値を、マージされたデータ項目の多値キーとして維持することによって、前記識別された重複するデータ項目をマージすることをさらに含む、請求項１３に記載のコンピュータ・システム。
17. 前記識別されたデータ項目と複合関係にある他のデータ項目をマージすることをさらに含む、請求項１６に記載のコンピュータ・システム。
18. 前記決定されたハッシュ値に関して、前記マージされたデータ項目のうちの１つの同じ行識別子へのポインタを維持することをさらに含む、請求項１６に記載のコンピュータ・システム。
19. 前記テーブルのインデックスを維持することと、
    結合されたデータ項目の前記同じレコード識別子をポインタが指し示すように、前記インデックスに関連する探索木内の前記ポインタを維持することとをさらに含む、請求項１３に記載のコンピュータ・システム。
20. データベース・システム内の実体を明確に識別するためのコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品が、
    １つまたは複数の非一過性コンピュータ可読ストレージ媒体と、方法を実行することができる前記１つまたは複数の非一過性コンピュータ可読ストレージ媒体に格納されたプログラム命令とを備え、前記方法が、
    データ項目をデータベースのテーブルに格納することであって、前記データ項目が、複数の属性を含んでいるレコードとして格納される、前記格納することと、
    前記データ項目の前記属性の選択された組み合わせに関する命名規則を格納することと、
    前記命名規則に優先順位を付けることと、
    前記データ項目の前記属性の前記選択された組み合わせの各々に対してハッシュ値を決定することと、
    前記決定されたハッシュ値および前記優先順位付けされた命名規則を使用して重複するデータ項目を識別することとを含む、コンピュータ・プログラム製品。

Images