特表 2024-514672 アペンド専用データ構造を用いるリスト・ベースのデータ検索

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-04-02

(54)【発明の名称】アペンド専用データ構造を用いるリスト・ベースのデータ検索

(51)【国際特許分類】

   G06F 16/28 20190101AFI20240326BHJP

   G06F 16/23 20190101ALI20240326BHJP

【ＦＩ】

G06F16/28

G06F16/23

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023563948

(86)(22)【出願日】2022-04-22

(85)【翻訳文提出日】2023-12-11

(86)【国際出願番号】 EP2022060747

(87)【国際公開番号】W WO2022223807

(87)【国際公開日】2022-10-27

(31)【優先権主張番号】21170144.6

(32)【優先日】2021-04-23

(33)【優先権主張国・地域又は機関】EP

(81)【指定国・地域】

(71)【出願人】

【識別番号】523168168

【氏名又は名称】コルテックス イノベーションズ ゲーエムベーハー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】パルム，ペトル

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175CA09

(57)【要約】

本発明は、データベース（104）内でデータベース照会を実行するためのコンピュータ実装される方法に関する。前記データベースは、フィールド固有データ値リスト（116）の形で物理的に記憶され、当該方法は：・データ値を変更する命令を受領するステップと；・前記フィールド固有データ値リスト（116）に前記変更を加えることなく、アペンド専用データ構造（202）に前記命令を格納するステップ（604）であって、ここではAODエントリーと呼ばれる、前記アペンド専用データ構造における各エントリーが、少なくとも、前記データ・レコードのうちの1つのデータ・レコードのフィールド識別子‐データ値ペアのうち、前記変更命令の1つに従って変更されるべきものを含む、ステップと；・前記データベースがそれについて命令を受領する前記データ・レコードのそれぞれについて、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうちの最新のもののアドレス（206,208）を、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブル（226）に格納するステップ（606）と；・データベース照会を実行するステップとを含み、前記データベース照会は：i. 前記フィールド固有データ値リストを検索して（612）、データ・レコード（214）のIDを識別し；ii. i）で識別されたデータ・レコードIDの1つに割り当てられたAODエントリーのアドレスを識別するために、前記アドレス割り当てテーブルを評価し（614）；iii. 前記AODエントリーの識別されたアドレスにアクセスし（616）；iv. これらの識別されたAODエントリーに含まれる変更詳細を使用して（618）、フィールド識別子‐データ値ペアをステップi）で確認されたデータ・レコードIDに追加し、それを出力することを含む。

【特許請求の範囲】

【請求項1】

データベース（104）内でデータベース照会を実行するためのコンピュータ実装される方法であって、前記データベースは、「最新の統合時点」と呼ばれる第1の時点における複数の論理データ・レコードを含み、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、前記データ・レコードは、フィールド固有データ値リスト（116,402,404,406）の形で物理的に記憶され、当該方法は、前記最新の統合時点の後に：
・前記データ・レコードのうちのいくつかのデータ・レコードのフィールドのデータ値を変更する命令を受領するステップ（602）と；
・前記フィールド固有データ値リスト（116）に前記変更を加えることなく、アペンド専用データ構造（202）に前記命令を格納するステップ（604）であって、ここではAODエントリーと呼ばれる、前記アペンド専用データ構造における各エントリーが、少なくとも、前記データ・レコードのうちの1つのデータ・レコードのフィールド識別子‐データ値ペアのうち、前記変更命令の1つに従って変更されるべきものを含む、ステップと；
・前記データベースが、最新の統合時点の後に、それについてデータ値を変更する一つまたは複数の命令を受領する前記データ・レコードのそれぞれについて、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうちの最新のもののアドレス（206,208）を、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブル（226）に格納するステップ（606）であって、前記アドレス割り当てテーブルにおけるリンクは、自動的に更新される、ステップと；
・データベース照会を実行するステップとを含み、前記データベース照会は：
i. 前記フィールド固有データ値リストを検索して（612）、一つまたは複数のフィールド固有検索値との一致に基づいて、その内容の全部または一部が返されるデータ・レコード（214）のIDを識別し；
ii. i）で識別されたデータ・レコードIDの1つに割り当てられたAODエントリーのアドレスを識別するために、前記アドレス割り当てテーブルにアクセスし（614）；
iii. 前記AODエントリーの識別されたアドレスにアクセスし（616）；
iv. これらの識別されたAODエントリーに含まれる変更詳細を使用して（618）、フィールド識別子‐データ値ペアをステップi）で確認されたデータ・レコードIDに追加し、それを出力することを含む、
コンピュータ実装される方法。

【請求項2】

・前記アドレス割り当てテーブルにおけるちょうど1つのエントリーが、前記論理データ・レコードのそれぞれに対応する、および／または
・当該方法は、さらに、前記論理データ・レコードと前記アドレス割り当てテーブルにおけるエントリーの、DMSシステムによる協調管理を含み、前記論理データ・レコードは常に、各論理データ・レコードのIDが前記アドレス割り当てテーブルにおけるそのエントリーのメモリ・アドレスを明示的または暗黙的に指定するように、生成され、前記アドレス割り当てテーブルと同期され、該アドレス割り当てテーブルにおいて、その論理データ・レコードのIDはそのデータ・レコードに対する最新の変更を有するAODエントリーのアドレスを割り当てられ；特に、ステップii）において、データ・レコードIDにおいて指定されたメモリ・アドレスが、i）において確認されたデータ・レコードに一意的に割り当てられた前記アドレス割り当てテーブルにおけるエントリーに直接アクセスする、
請求項１に記載のコンピュータ実装される方法。

【請求項3】

・「新しい統合時点」と呼ばれる第2の時点において、前記フィールド固有データ値リストに対するデータベース照会の実行と独立して、および／または、それと並行して、前記フィールド固有データ値リストを統合することによって、前記最新の統合時点以降に指示された変更を統合するステップ；または
・「新しい統合時点」と呼ばれる第2の時点において、前記フィールド固有データ値リストに対するデータベース照会の実行と独立して、および／または、それと並行して、前記フィールド固有データ値リストの統合されたコピー（228）を生成することによって、前記最新の統合時点以降に指示された変更を統合するステップを含む、
請求項１または２に記載のコンピュータ実装される方法。

【請求項4】

・各フィールド固有データ値リストの各データ値について、前記第1の統合時点と前記第2の統合時点との間に受領された変更命令の結果として、そのフィールドに関してそのデータ値がもはや割り当てられなくなるすべての論理データ・レコードのデータ・レコードIDを、ネガティブ・リスト（220）と呼ばれるリストに格納するステップと；
・各フィールド固有データ値リストの各データ値について、各フィールドの新しいデータ値について、前記第1の統合時点と前記第2の統合時点との間に受領された変更命令の結果として、そのフィールドに関してそのデータ値が割り当てられることになるすべての論理データ・レコードのデータ・レコードIDを、ポジティブ・リスト（218）と呼ばれるリストに格納するステップとをさらに含み、
前記統合を実行することは、前記ポジティブ・リストおよび前記ネガティブ・リストの内容に従って、前記フィールド固有データ値リストまたは前記フィールド固有データ値リストのコピーの、データ値およびデータ・レコードIDを更新することを含み、
統合後、前記ポジティブ・リストおよび前記ネガティブ・リストは空にされる、
請求項３に記載のコンピュータ実装される方法。

【請求項5】

・当該方法が、中断することなく、前記統合と並行して、かつ、前記統合とは独立して、前記フィールド固有データ値リストに対してさらなるデータベース照会を実行することを含む、および／または
・前記フィールド固有データ値リストにも、前記統合の実行中に該フィールド固有データ値リストに含まれるデータ値に対するロックがない、
請求項３または４に記載のコンピュータ実装される方法。

【請求項6】

前記フィールド固有データ値リストのそれぞれについて前記統合を実行することは：
・データ・レコードIDのフィールド固有およびデータ値固有のポジティブ・リスト（218）およびネガティブ・リスト（220）を解析して、前記第1の統合時点と前記第2の統合時点との間の、あるフィールドの一意的なデータ値の数に関する変化、およびそのフィールドのデータ値にリンクされたデータ・レコードIDの最大数に関する変化を確認するステップと；
・前記解析において確認された一意的なデータ値の数の変化の関数として、前記フィールド固有データ値リストの統合バージョンに含まれる一意的なデータ値の数を確認するステップと；
・前記フィールド固有データ値リストの前記統合バージョンにおけるデータ値に割り当てられる、前記解析において確認されたデータ・レコードIDの最大数を格納するための第1のメモリ要件と、前記フィールド固有データ値リストの前記統合バージョンに格納される最大のデータ値を格納するための第2のメモリ要件を確認するステップと；
・リスト内の一意的なデータ値の確認された数ならびに前記第1および第2のメモリ要件の関数として、前記フィールド関連データ値リストの統合バージョンを格納するために必要とされるメモリ要件を計算するステップと；
・少なくとも計算されたメモリ領域と同じ大きさの物理的なデータ担体上の連続領域を確認するステップと；
・最後の統合時点以降に前記ポジティブ・リストおよび前記ネガティブ・リストに格納された変更を組み込んで、前記フィールド関連データ値リストの前記統合バージョンを生成するステップと；
・前記フィールド関連データ値リストの前記統合バージョンを、前記データ担体の確認された連続領域に格納するステップとを含む、
請求項３ないし５のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項7】

前記フィールド固有データ値リストの提供をさらに含み、前記提供が：
・生データをパースして、もとのデータ・レコードを作成するステップであって、各もとのデータ・レコードは、データ・レコードIDに加えて、フィールド識別子とそれに割り当てられたもとのデータ値との一つまたは複数のペアを含む、ステップと；
・前記データベースにおいて、冗長性のないフィールド固有のもとデータ値リストを格納するステップであって、前記冗長性のないフィールド固有のもとデータ値リストのうちの1つにおけるもとのデータ値のそれぞれに、前記もとデータ値リストを表すフィールドにおいて前記もとのデータ値を含むもとのデータ・レコードのすべてのデータ・レコードIDが割り当てられている、ステップと；
・前記冗長性のないもとデータ値リストの各もとのデータ値に、他のいずれのもとのデータ値にも割り当てられていない少なくとも1つのマッピングIDを割り当てるマッピング・テーブル（210）を生成するステップと；
・前記もとのデータ・レコードを前記複数の論理データ・レコードに変換し、前記冗長性のないフィールド固有のもとデータ値リストを前記フィールド固有データ値リストに変換するステップであって、前記変換は、前記マッピング・テーブルに従って、もとのデータ値をマッピングIDで置換することを含み、前記データ・レコードのフィールドに割り当てられる前記データ値は、前記マッピングIDである、
請求項１ないし６のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項8】

・前記マッピングIDは、好ましくはデータベース検索のために使用されるコンピュータ・システムのプロセッサ・アーキテクチャーに依存して長さおよび／またはタイプが選択される値であり、特に数値である、請求項７に記載のコンピュータ実装される方法。

【請求項9】

前記変更命令の少なくとも1つが、前記論理データ・レコードの少なくとも1つにおけるフィールドの古くなったデータ値を変更または削除する命令であり、当該方法が：
・前記少なくとも1つのデータ・レコードのデータ・レコードIDを、ネガティブ・リスト（220）と呼ばれるデータ・レコードIDのリストに格納するステップをさらに含み、前記ネガティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、前記変更要求に従って変更または削除されるべきデータ値にリンクされてデータ構造（216）において格納され、
・前記フィールド固有の検索値のそれぞれについての前記データベース照会の実行は：
・前記データ構造（216）が、前記フィールド固有の検索値および該検索値のフィールド識別子と同一のデータ値およびフィールド識別子にリンクされて格納されたネガティブ・リストを含むかどうかをチェックし；
・もしそうであれば、このフィールド固有の検索値についてステップi）で確認されたすべてのデータ・レコードIDと、前記ネガティブ・リストにおけるデータ・レコードIDとの差分量を計算し；
・ステップii～ivのためにデータ・レコードIDの前記差分量を使用することを含む、
請求項１ないし８のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項10】

前記変更命令の少なくとも1つが、前記データ・レコードの少なくとも1つにおけるフィールドに新しいデータ値を割り当てる命令であり、当該方法が：
・前記少なくとも1つのデータ・レコードのデータ・レコードIDを、ポジティブ・リストと呼ばれるデータ・レコードIDのリストに格納するステップであって、前記ポジティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、かつ、前記新しいデータ値にリンクされてデータ構造（216）において格納される、ステップと；
・前記新しいデータ値が古くなったデータ値を置換する場合、前記少なくとも1つのデータ・レコードのデータ・レコードIDを、ネガティブ・リスト（220）と呼ばれるデータ・レコードIDのリストに格納するステップであって、前記ネガティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、前記古くなったデータ値にリンクされて格納される、ステップとをさらに含み、
・前記フィールド固有の検索値のそれぞれについての前記データベース照会の実行は：
・前記データ構造が、前記フィールド固有の検索値および前記検索値のフィールド識別子と同一のデータ値およびフィールド識別子にリンクされて格納されたポジティブ・リストを含むかどうかをチェックすることと；
・もしそうであれば、このフィールド固有の検索値についてステップi）で確認されたすべてのデータ・レコードIDと、前記ポジティブ・リストにおけるデータ・レコードIDの和集合を計算することであって、前記新しいデータ値が古くなったデータ値を置換する場合、前記和集合のデータ・レコードIDは、この検索値とそのフィールドに割り当てられた前記ネガティブ・リストにおけるデータ・レコードIDだけ縮小される、ことと；
・ステップii～ivのためにデータ・レコードIDの前記和集合を使用することとを含む、
請求項１ないし９のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項11】

・前記データ構造（216）は、検索可能なソートされた要素の配列を含み、前記配列は、リスト要素のリスト、またはノードの検索ツリー、特にBツリーであり、
・前記配列は、それぞれの場合における前記フィールドの1つを表し、
・前記配列の要素は、前記データ・レコード（214）に含まれ、前記配列によって表される前記フィールドに割り当てられたデータ値の非冗長リスト（116）の1つのデータ値を表し、
・前記配列の各要素は、空であるもしくは空でないポジティブ・リストおよび／または空であるもしくは空でないネガティブ・リストにリンクされて格納される、
請求項７ないし１０のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項12】

・前記フィールド固有データ値リスト（116）はそれぞれ、前記論理データ・レコードにおけるそのフィールド固有データ値リストを表すそのフィールドに割り当てられたデータ値を選んだ非冗長データ値リストであり、
・それぞれのフィールド固有データ値リストの各データ値は、一意的であり、そのフィールド固有データ値リストによって表されるそのフィールド内のそのデータ値を含むすべての論理データ・レコードのデータ・レコードIDにリンクされて格納され、
・前記データ値は、好ましくは、前記フィールド固有データ値リストにおいてソートされた形で格納される、
請求項１ないし１１のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項13】

前記統合は：
・前記第2の時点において、前記最新の統合時点以降に指示された変更を統合するためのコマンドを受領するステップと；
・前記コマンドを受領することに応答して：
・前記最新の統合時点と前記第2の時点との間に指示された前記フィールド固有データ値リストまたはそのコピーにおける変更を実装して、統合フィールド固有データ値リスト（228）を生成し、各統合フィールド固有データ値リストにおける各データ値は、第1の時点と第2の時点との間に指示されたそのフィールドにおける変更を考慮に入れた後でもそのデータ値を含む論理データ・レコードのIDのみが割り当てられるようにし；
・前記第2の時点より後にデータベース検索を実行するために、以前に使用されたフィールド固有データ値リスト（216）の代わりに、前記統合フィールド固有データ値リストを使用し；
・前記第2の時点を新しい最新の統合時点として使用する、
ステップとを含む、
請求項３ないし１２のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項14】

前記コマンドを受領することに応答して、前記統合フィールド固有データ値リストを生成した後に：
前記統合フィールド固有データ値リストに基づいて、前記少なくとも1つのデータ構造（216）を再生成するステップをさらに含み、前記データ構造の再生成は、前記ポジティブ・リストおよび／または前記ネガティブ・リストを空にすることを含み、
前記統合の過程における前記最新の統合時点と前記第2の時点との間に指示された変更の前記実装は、好ましくは、変更によって影響を受けるすべてのフィールド固有データ値リストにおけるすべてのデータ値の前記ポジティブ・リストおよびネガティブ・リストを解析することによって、前記最新の統合時点と前記第2の統合時点との間に指示された前記変更を確認することを含む、
請求項９および／または１０に関連する請求項１３に記載のコンピュータ実装される方法。

【請求項15】

・前記論理データ・レコードの少なくとも一部が、一つまたは複数の「is-superordinate-to」フィールドを含み、前記「is-superordinate-to」フィールドのそれぞれが、そのデータ・レコードの下位のデータ・レコードのデータ・レコードIDを格納するように構成され；
・前記フィールド固有データ値リストは、前記「is-subordinate-to」フィールドを表すデータ値リスト（416）を含み、そのデータ値リストに格納されたデータ値は、少なくとも1つの他の論理データ・レコードの下位の論理データ・レコードのIDであり、前記「is-superordinate-to」データ値リストにおける各データ値は、前記他の下位のデータ・レコードの一つまたは複数のIDを割り当てられ；
・前記データベース照会は、前記データベース照会において確認されたデータ・レコードに加えて、これらのデータ・レコードの下位のデータ・レコードも出力されるかどうかを指定する完全性検索パラメータを含み；
・前記データベース照会の実行は：
・前記下位のデータ・レコードも出力されるべきであると決定し；
・ステップi）で確認されたデータ・レコードの下位のデータ・レコードの一つまたは複数のIDを取得するために、ステップi）で確認されたデータ・レコードIDを用いて前記「is-superordinate-to」データ値リストを検索し；
・前記アドレス割り当てテーブルを評価して、前記確認された下位のデータ・レコードのうちの1つのIDに割り当てられたAODエントリーのアドレスを識別し；
・前記データベース照会において確認されたデータ・レコードに下位のデータ・レコードを追加するために、前記AODエントリーのこれらの識別されたアドレスにアクセスすることを含む、
請求項１ないし１４のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項16】

・フィールド固有データ値リストは、時間値リストと呼ばれる複数のフィールド固有データ値リストを含み、各時間値リストは、時点の非冗長リストからなり、前記時点は、それぞれ、その時間値リストが関係する前記フィールドのデータ値の有効性が一つまたは複数の論理データ・レコードにおいて開始または終了する時点を表し、
・前記時間値リストにおける各時点は、その時点において有効な論理データ・レコードのIDを割り当てられ；
当該方法は：
・前記論理データ・レコードの1つに関する変更要求を受領することに応答して、変更されるべきデータ・レコードの新しいバージョンを生成するステップであって、前記新しいバージョンは、少なくとも1つの前バージョン・フィールドを含む新しい論理データ・レコードであり、前記前バージョン・フィールドは、変更されるべきデータ・レコードのIDを含み、前記変更されるべきデータ・レコードではなく、前記新しいバージョンが、前記変更要求において指定された変更と変更時刻を含む、ステップと；
・新データ・レコードIDを有する前記データ・レコードの前記新しいバージョンを前記フィールド固有データ値リストに格納し、前記時間値リストの前記新しいデータ・レコードの有効性の開始と、前記変更命令が参照するフィールドとを格納するステップであって、前記新しいバージョンのIDは、前記時間値リストに格納される、ステップと；
・前記データベース照会は、フィールド固有の有効時間の指示を含み、前記有効時間は、前記データベース照会において確認されるデータ・レコード・バージョンが、対応するフィールドにおいて前記少なくとも1つのフィールド固有の検索値を含んでいた時点または時間期間を指定し、前記データベース照会の実行は：
・前記検索値と前記有効時間が関連するフィールドに関連する前記時間値リストを識別するステップと；
・前記有効時間に、または前記有効期間内の時点にリンクされて前記時間値リストに格納されているデータ・レコード・バージョンの一つまたは複数のデータ・レコードIDを識別するために、識別された時間値リストを前記有効時間で検索するステップと；
・前記検索値および前記有効時間が関連するフィールドに関連する前記フィールド固有データ値リストを識別するステップと；
・前記検索値にリンクされて前記データ値リストに格納された一つまたは複数のデータ・レコードIDを識別するために、前記識別されたデータ値リストを前記検索値で検索するステップと；
・前記識別された時間値リストおよび前記識別されたデータ値リストに基づいて確認された前記データ・レコードの前記バージョンのIDの共通集合を計算するステップと；
・前記アドレス割り当てテーブルを評価して、前のステップにおいて確認されたデータ・レコード・バージョンのうちの1つのIDに割り当てられたAODエントリーのアドレスを識別するステップと；
・前記有効時点においてまたは前記有効時間期間中に有効な前記データ・レコード・バージョンを、そのフィールド値で補足して出力するために、前のステップで識別された前記AODエントリーのアドレスにアクセスするステップとを含む、
請求項１ないし１５のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項17】

・前記AODエントリーは、暗号学的ハッシュ値を介して一緒に連鎖された、前記アペンド専用データ構造内のブロックチェーンの要素として格納され、
・前記データベース検索の実行は、前記データベース照会の過程で処理されるAODエントリーのハッシュ値の有効性チェックを含む、
請求項１ないし１６のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項18】

前記データベース照会は、前記フィールド固有データ値リストの形で前記論理データ・レコードを管理および永続化するように構成されたデータ処理および検索システム――DMSシステム（102）――によって実行され、前記DMSシステムは、前記フィールド固有データ値リストに加えて、前記第1の統合時において前記DMSシステムによってすでに管理されているすべての論理データ・レコードが再構築されうるもとになるいかなるデータ構造をも管理および永続化しないように構成される、請求項１ないし１７のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項19】

前記フィールド固有データ値リストは、ステップi）において検索された前記フィールド固有データ値リストのいずれかまたはすべてに対してロック（「データベース・ロック」）がなく、少なくともステップi）の実行中に、そこに含まれるデータ値に対してロックがない、請求項１ないし１８のうちいずれか一項に記載のコンピュータ実装される方法。

【請求項20】

コンピュータ可読命令が格納されている揮発性または不揮発性の記憶媒体であって、前記命令は、プロセッサに、請求項１ないし１９のうちいずれか一項に記載の、データベース内でデータベース照会を実行するための方法を実行させるように構成される、記憶媒体。

【請求項21】

・論理データ・レコードが分散式に格納される複数のフィールド固有データ値リスト（116）であって、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、好ましくは、各フィールド固有データ値リストは、前記論理データ・レコードにおけるそのリストによって表される前記フィールドの1つに割り当てられたデータ値のみのソートされた冗長性のないリストであり、前記フィールド固有リストにおける各データ値は、そのフィールド内のそのデータ値を含むすべてのデータ・レコードのIDにリンクされて格納される、複数のフィールド固有データ値リスト（116）と；
・前記データ・レコードのフィールドのデータ値を変更するための命令を含むアペンド専用データ構造（202）であって、ここではAODエントリーと呼ばれる前記アペンド専用データ構造における各エントリーは、少なくとも、前記データ・レコードのうちの1つのデータ・レコードの前記フィールド識別子‐データ値ペアのうち、前記変更命令の1つに従って変更されるべきものを含む、アペンド専用データ構造（202）と；
・アドレス割り当てテーブルであって、前記アドレス割り当てテーブルは、変更命令のあるAODエントリーが前記アペンド専用データ構造において格納されている各データ・レコードのIDに、そのデータ・レコードに対する変更を指定する最新のAODエントリーのアドレス（206、208）を割り当てる、アドレス割り当てテーブル（226）とを含む
データ構造であって、
当該データ構造は、特にさらに：
・少なくとも1つのデータ構造（216）であって、
・前記データ構造（216）は、検索可能なソートされた要素の配列を含み、前記配列は、リスト要素のリスト、またはノードの検索ツリー、特にBツリーであり、
・前記配列は、それぞれの場合における前記フィールドの1つを表し、
・前記配列の要素はそれぞれ、前記データ・レコード（214）に含まれ、前記配列によって表される前記フィールドに割り当てられたデータ値の非冗長リスト（116）の1つのデータ値を表し、
・前記配列の各要素は、空であるもしくは空でないポジティブ・リストおよび／または空であるもしくは空でないネガティブ・リストにリンクされて格納される、
データ構造（216）および／または
・前記論理データ・レコードが格納された生データから得られたもとのデータ値の冗長性のないリスト、および／または
・マッピング・テーブル（210）であって、
・前記マッピング・テーブルは、前記もとのデータ値のそれぞれに、他のどのもとのデータ値にも割り当てられていない少なくとも1つのマッピングIDを割り当て、
・前記データ・レコードの前記データ値は、前記マッピングIDである、
マッピング・テーブル（210）
を含む、データ構造。

【請求項22】

コンピュータ・システム（100,500）であって：
・少なくとも1つのプロセッサ（108）と；
・データベース（104）を含むデータ・メモリであって、前記データベースは、「最新の統合時点」と呼ばれる第1の時点において複数の論理データ・レコードを含み、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、前記データ・レコードは、フィールド固有データ値リスト（116）の形で物理的に記憶される、データベース（104）と；
・データ処理および検索システム――DMSシステム（102）――であって、前記DMSシステムは前記データベース（104）を管理するように構成され、前記管理は、前記最新の統合時点の後に：
・前記データ・レコードのうちのいくつかのデータ・レコードのフィールドのデータ値を変更する命令を受領するステップと；
・前記フィールド固有データ値リスト（116）に前記変更を加えることなく、アペンド専用データ構造（202）に前記命令を格納するステップであって、ここではAODエントリーと呼ばれる、前記アペンド専用データ構造における各エントリーが、少なくとも、前記データ・レコードのうちの1つのデータ・レコードのフィールド識別子‐データ値ペアのうち、前記変更命令の1つに従って変更されるべきものを含む、ステップと；
・前記データベースが、最新の統合時点の後に、それについてデータ値を変更する一つまたは複数の命令を受領する前記データ・レコードのそれぞれについて、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうちの最新のもののアドレス（206,208）を、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブル（226）に格納するステップであって、前記アドレス割り当てテーブルにおけるリンクは、自動的に更新される、ステップと；
・データベース照会を実行するステップとを含み、前記データベース照会は：
i. 前記フィールド固有データ値リストを検索して（612）、一つまたは複数のフィールド固有検索値との一致に基づいて、その内容の全部または一部が返されるデータ・レコード（214）のIDを識別し；
ii. i）で識別されたデータ・レコードIDの1つに割り当てられたAODエントリーのアドレスを識別するために、前記アドレス割り当てテーブルを評価し（614）；
iii. 前記AODエントリーの識別されたアドレスにアクセスし（616）；
iv. これらの識別されたAODエントリーに含まれる変更詳細を使用して（616,618）、フィールド識別子‐データ値ペアをステップi）で確認されたデータ・レコードIDに追加し、それを出力することを含む、
コンピュータ・システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データを格納し、データ内で効率的な検索を実行する方法およびシステムに関する。

【背景技術】

【0002】

従来技術では、データを格納し、管理し、処理するためのさまざまなデータベース管理システム（database management system、DBMS）が知られている。DBMSの主なタスクは、大量のデータを矛盾なく永続的に、効率的に保存し、要求された部分集合をユーザーやアプリケーション・プログラムに対して、種々のニーズに基づく表現形式で利用できるようにすることである。従来のDBMSによって管理されるデータベースにおいて、データおよびそれらの相互の関係を構造化するための基礎は、DBMS製造業者によって定義されるデータベース・モデルである。データベース・モデルに応じて、データベース・スキーマを特定の構造化オプションに適合させる必要がある。今日使用されているよく知られたデータベース・モデルは、階層式モデル、ネットワーク様モデル、リレーショナル・モデル（テーブルで構成されている）、オブジェクト指向モデル、ドキュメント指向モデル、およびこれらのモデルの混合形式を含む。さらに、多くの小さなクエリーに効率的に回答すること（OLTP）または長期にわたる評価（OLAP）のために最適化されたDBMSを区別するのが一般的である。

【0003】

ビッグデータを扱う際の主な問題は、リソースの問題である。データ量が多いほど、メモリ、プロセッサ、およびハードドライブの形でより多くのリソースが必要になる。

【0004】

データベースを作成し、それに対して実行されるクエリーおよび分析を定義するとき、サポートされているデータベース検索クエリーの複雑さと検索速度の間には、目的の対立が生じることがよくある。確かに、時間的、内容ベース、および／または構造的な検索基準を考慮して、複雑な検索クエリーを許容するDBMSがある。しばしば、これらのDBMSは、複数のテーブルに対する複雑でネストされたクエリーの時間的実行と、複数のテーブルから得られた部分的な結果の集約を自動的に計画し、統率するモジュール（「クエリー・プランナー」）がある。しかしながら、これらのモジュールは、非常に複雑なクエリーおよび／または多数のテーブルでは、すぐに限界に達してしまう。処理されてRAMにロードされるデータの量は、多くの「ビッグデータ」アプリケーションでは膨大な量になり、実際上、複雑な構造の大きなデータ・レコードを評価することが不可能になる可能性がある。少なくとも、当面のタスクに望ましいあらゆる形のデータ分析を実行することは、多くの場合不可能である。現在のDBMSの制限によって特に影響を受ける分野は、たとえば、モノのインターネット（IOT）、ゲノム解析、天文学分野のスペクトルデータの解析、タクシー、バス、鉄道会社、航空会社、携帯電話会社からの移動データなどを含むが、他にも多くの分野を含む。

【0005】

サポートされる検索クエリーを、検索基準と出力される結果の両方に関して、より低い複雑さのクエリーに制限することによって、従来のデータベース・システムの速度は、しばしば、限られた範囲まで向上されうる。しかしながら、一方では、これは、大きなデータ・レコードに対して重要な分析を実行することができず、多くの場合、データの不可逆的な損失につながることさえあるという効果をもつ。なぜなら、生データは複雑さを軽減したテーブル構造にマッピングされ、これらのテーブル構造においてマッピングできない複雑な相互関係やメタデータは失われるからである。

【0006】

よって、既存のDBMSは、特に、非常に多くの異なる属性（キー）および対応する値を有する大量のデータ・オブジェクトに関連する複雑なクエリーを処理するとき、構造的な柔軟性の欠如、貧弱な拡張性および／または貧弱な性能によって特徴付けられることが多い。追加の異なる構造のデータを後でデータベースに保存しなければならない場合、既存のデータと新たに追加されたデータを、内容の点で好都合であり、パフォーマンスとリソースの点で有利な仕方で、一緒に照会して分析することは、多くの場合不可能である。

【0007】

複雑な分析やデータ・クエリーをサポートするためのビッグデータの課題は、依然として未解決の問題と考えられており、今後のデータ量のさらなる増加を考えると、より大きな問題になることが予想される。

【発明の概要】

【発明が解決しようとする課題】

【0008】

本発明の目的は、上述の問題がない、またはあっても程度が低いような仕方で、データを記憶し、データベース・クエリーを実行するための改善された方法およびシステムを提供することである。

【0009】

発明の基礎をなす目的は、独立請求項の特徴によってそれぞれ達成される。本発明の実施形態は、従属請求項に記載されている。以下に列挙される実施形態は、互いに排他的でない限り、互いに自由に組み合わせることができる。

【課題を解決するための手段】

【0010】

ある側面では、本発明は、データベース内でデータベース照会を実行するためのコンピュータ実装される方法に関する。データベースは、「最新の統合時点」と呼ばれる第1の時点における複数の論理データ・レコードを含む。各論理データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含む。データ・レコードは、フィールド固有データ値リストの形で物理的に保存される。この方法は、最新の統合時点の後に、以下のことを含む：
・前記データ・レコードのうちのいくつかのデータ・レコードのフィールドのデータ値を変更する命令を受領するステップと；
・前記フィールド固有データ値リストに変更を加えることなく、アペンド専用データ構造に前記命令を格納するステップであって、ここではAODエントリーと呼ばれる、前記アペンド専用データ構造における各エントリーが、少なくとも、変更命令の1つに従って変更されるべき前記データ・レコードのうちの1つのデータ・レコードのフィールド識別子データ値ペアのエントリーを含む、ステップと；
・前記データベースが、最新の統合時点の後に、それについてデータ値を変更する一つまたは複数の命令を受領するデータ・レコードのそれぞれについて、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうちの最新のもののアドレスを、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブルに格納するステップであって、アドレス割り当てにおけるリンクは、自動的に更新される、ステップと；
・データベース・クエリーを実行するステップとを含み、前記データベース・クエリーは：
i. 前記フィールド固有データ値リストを検索して、一つまたは複数のフィールド固有検索値との一致に基づいて、その内容の全部または一部が返されるデータ・レコードのIDを識別することと；
ii. i）で識別されたデータ・レコードIDの1つに割り当てられたAODエントリーのアドレスを識別するために、前記アドレス割り当てテーブルにアクセスすることと；
iii. 前記AODエントリーの識別されたアドレスにアクセスすることと；
iv. これらの識別されたAODエントリーに含まれる変更詳細を使用して、フィールド識別子‐データ値ペアをステップi）で確認されたデータ・レコードIDに追加し、それを出力すること。

【0011】

これは、次のようないくつかの理由のため、有利でありうる。

【0012】

データベース照会は、最も複雑な分析クエリーであっても高速で実行されることができ、完全な結果データ・レコードが迅速に出力されることができるような仕方で、2つの異なるデータ構造に対して実行される。まず、ステップi）におけるデータベース・クエリーがフィールド固有リストに対して実行される。このステップは、最初は、一つまたは複数のフィールド固有の検索値との一致に基づいて、その内容の全部または一部が返されるデータ・レコードのIDを識別するためにのみ使用される。通例、データベース・クエリーを開始したソフトウェアまたはユーザーは、最初に、識別子だけでなく、内容の点でデータ・レコードを特徴付ける属性（フィールド固有データ値）をも必要とする。従来技術では、データベース・クエリーは、通例、1つの処理ステップで、その属性を含めて、返されるべきデータ・レコードを確認して返すような仕方で、すでに定式化されている。データベース・クエリーもそれに応じて複雑で、しばしば複数のテーブルにまたがって広がり、さまざまなJOIN操作を含む。従来のデータベース・クエリーの複雑さのため、いくつかのテーブルをロードして評価する必要があることが多く、データベース・クエリーのパフォーマンスが低いか、ある程度の複雑さを超えると不可能になる。しかしながら、本発明の実施形態によれば、データ・レコードの属性の物理的担体、この場合はフィールド固有データ値リストの分析は、返されるべきデータ・レコードIDを確認する〔求める〕ためにのみ使われる。これらの結果データ・レコードの属性を確認するためには使用されない。本発明の実施形態によれば、返されるべきデータ・レコードのフィールド関連データ値は、フィールド固有データ値リストを解析することによって確認されるのではなく、2つの特別なデータ構造、すなわち、アペンド専用データ構造およびアドレス割り当てテーブルを使用することによって確認される。

【0013】

アペンド専用データ構造は、逐次的に更新されるいくつかのエントリーからなるデータ構造である。個々のAODエントリーのその後の削除、修正、または再グループ化は不可能である。各AODエントリーは、論理データ・レコードの一つまたは複数のフィールドの一つまたは複数のデータ値の変更を指定する。

【0014】

このアペンド専用データ構造は、アドレス割り当てテーブルに機能的に密接に結合されている。すなわち、アドレス割り当てテーブルは、論理データ・レコードのそれぞれについて、そのデータ・レコードのIDを有する行を含む。このデータ・レコードのIDは、ちょうど1つのアドレスにリンクされたアドレス割り当てテーブルに格納され、この1つのアドレスは、このデータ・レコードへの変更を指定する最新のAODエントリーのアドレスである。

【0015】

今、ステップi）で確認されたデータ・レコードに現在のデータ値を与えてそれらを出力するために、データベースを管理するソフトウェアおよび／またはハードウェア・ベースのデータ管理および検索システム（data management and search system）（DMSシステム）は、まずアドレス割り当てテーブルにアクセスする。

【0016】

本発明の実施形態によれば、アドレス割り当てテーブルは、論理データ・レコードのそれぞれについて、そのデータ・レコードのIDを有するちょうど1つのエントリー（たとえば、テーブルのちょうど1つの行に対応する）を含む。各論理データ・レコードのIDは、AODエントリーのちょうど1つのアドレスにリンクされたアドレス割り当てテーブルに格納され、この1つのアドレスは、そのデータ・レコードへの変更を指定する最新のAODエントリーのアドレスである。

【0017】

本発明のいくつかの実施形態によれば、アドレス割り当てテーブルにアクセスして、特定の論理データ・レコードのID（すなわち、たとえば、返されるべきデータ・レコードのID）に関連するアドレス割り当てテーブル内のエントリーを確認することは、以下のように実装される。DMSシステムは、DMSシステムによって管理され、分散方式でリストに格納された論理データ・レコードのIDを生成するように構成され、それにより、各データ・レコードIDは、アドレス割り当てテーブル内でそのデータ・レコードに関連するただ1つのエントリー（「行」）が有するオフセットを明示的または暗黙的に指定する。特に、データ・レコードIDは、数値であってもよい。アドレス割り当てテーブル内のエントリーのオフセットの明示的な指定は、たとえば、アドレス割り当てテーブルのベース・アドレスに対するアドレス割り当てテーブル内のエントリーのメモリ・アドレスの指定であってもよい。暗黙的な指定は、たとえば、アドレス割り当てテーブル内のそのエントリーの番号（「行番号」）の指定であってもよく、ここで、そのエントリー番号にアドレス割り当てテーブルの各エントリーの所定のメモリ・サイズを乗算することにより、アドレス割り当てテーブルのベース・アドレスに対するそのエントリーの合計オフセットが得られる。

【0018】

たとえば、DMSシステムは、アドレス割り当てテーブル内のエントリー（行）の位置が不変であり、これらのエントリーのオフセットがそのエントリーに関連する論理データ・レコードのIDと同一であるように、アドレス割り当てテーブルを生成するように構成される。DMSシステムは、アドレス割り当てテーブルにアクセスするとき、特定の論理データ・レコードについての1つのエントリーを確認し、論理データ・レコードIDに基づいて、たとえば、エントリーのオフセットとしてのデータ・レコードIDに、アドレス割り当てテーブル内の各エントリーの指定されたメモリ位置サイズを乗算することによって、そのエントリーの位置を計算するように、適切に構成されてもよい。このようにして得られた積は、アドレス割り当てテーブルのベース・アドレスから始まるその1つのデータ・レコードの、アドレス割り当てテーブルにおけるエントリーの位置を示す。

【0019】

たとえば、新しい論理データ・レコードが生成されるとき、DMSシステムは、IDを生成し、アドレス割り当てテーブル内のこの新しいエントリーのオフセットが新しい論理データ・レコードのIDと同一であるように、アドレス割り当てテーブル内の新しいエントリー／新しい行をも生成するように構成される。たとえば、論理IDは、数値データ値、またはメモリ・アドレスであってもよい。

【0020】

たとえば、アドレス割り当てテーブルのベース・アドレスは、メモリ・アドレス#23862382844を有することができる。各行は、たとえば16バイトの事前定義されたメモリ空間を必要とすることがある。次いで、DMSシステムは、たとえばID 1008を有する論理データ・レコードについてのエントリーのメモリ・アドレスを、次のように計算することができる：ベース・アドレス＋（アドレス割り当てテーブル・エントリーのメモリ・サイズ×論理データ・レコードのID）＝#23862382844＋16バイト×1008。計算されたメモリ・アドレスは、ここでは架空に#23862992849と呼ばれる。

【0021】

別の明示的な実装変形によれば、データ・レコードの論理IDは、アドレス割り当てテーブル内の対応するエントリーのメモリ・アドレスと同一であり、すなわち、たとえば、上記の例における「1008」の代わりに、#23862992849である。

【0022】

よって、本発明の実施形態によれば、DMSシステムによる、論理データ・レコードの管理とアドレス割り当てテーブル内のエントリーの管理とは密接に結合され、論理データ・レコードは常に生成され、アドレス割り当てテーブルと同期され、そのため、各論理データ・レコードのIDは、アドレス割り当てテーブル内の1つのエントリーのメモリ・アドレスを明示的または暗黙的に指定し、該テーブル内で、その論理データ・レコードのIDは、そのデータ・レコードに対する最新の変更を有するAODエントリーのアドレスを割り当てられる。諸実施形態によれば、データベース・クエリーを処理するとき、返されるべきデータ・レコードの論理IDが、そのデータ・レコードに関連するアドレス割り当てテーブル内の1つのエントリーのアドレスを確認し、そのアドレスに直接アクセスするために使用される。

【0023】

出力されるべきデータ・レコードのIDを含むアドレス割り当てテーブル内の行を確認するこの方法は、RAMおよびCPUパワーをほとんど必要としない。DMSシステムがアドレス割り当てテーブル内の対応するエントリーに即時に直接アクセスするか、または必要であれば単純で非常に迅速に実行可能な乗算の後にアクセスすることができるからである。アドレス割り当てテーブルを検索する必要はない。アドレス割り当てテーブルにおけるこのエントリーから開始して、DMSシステムは、AODデータ構造における関連するエントリーに直接アクセスすることができる。なぜなら、最新の変更をもつこのAODエントリーのアドレスは、アドレス割り当てテーブルの、以前に確認されたエントリーにおいて指定されるからである。このデータ・レコードに対するさらなる、より古い変更を指定するさらなるAODエントリーがある場合、これらも直接メモリ・アクセスによって非常に迅速に確認され、読み出される。好ましくは各AODエントリーが最新のAODエントリーのアドレスを含むからである（少なくともAODエントリーが「完全にロードされた」エントリーでない、すなわちそれぞれのデータ・レコードのすべての現在のフィールド値を含むのでない場合）。

【0024】

したがって、DMSシステムは、任意の種類のデータベース・クエリーの結果としてデータ・レコードを出力するためにアドレスからアドレスへジャンプするだけであり、複数のテーブルにまたがる複雑なJOINSまたはSELECTSを実行する必要はない。これは、最も複雑なデータベース・クエリーでさえも、大幅に加速させる結果になりうる。なぜなら、ひとたびデータ・レコードのIDが確認されると（これは、冗長性のないリストに基づいて非常に迅速に行うことができる）、完全なデータ・レコードの出力は、実質的に、または、もっぱら、ジャンプ・アドレスに基づいて、つまり、データ構造内の逐次的検索および／またはテーブルの複雑なJOIN操作なしに実行されるからである。

【0025】

たとえば、このAODエントリーは、前記データ・レコードのすべてのフィールドのすべての現在のデータ値を含むことができ、そのため、この1つのAOD要素へのアクセスで、このデータ・レコードのすべての現在のデータ値がすでに確認され、返されることができる。

【0026】

AODエントリーが、そのデータ・レコードのすべてのフィールドのデータ値のすべてではない一つまたは複数の現在のデータ値のみを含むことも可能である（本明細書では、「不完全なAODエントリー」とも呼ばれる）。しかしながら、本発明の実施形態によれば、「不完全な」AODエントリーは、同じデータ・レコードを参照する、次の、より古いAODエントリーを指すアドレスを含む。このアドレスは、ジャンプ・アドレスとも呼ばれ、DMSシステムが、AODエントリーにおいて指定されるそれぞれのアドレスを介して、AODファイル内でAODエントリーからAODエントリーへ直接「ジャンプ」することを許容する。それにより、その特定のデータ・レコードに影響を及ぼすすべての変更を再構築するためである。これは、データ・レコードのすべてのフィールドについて現在のデータ値が確認されるまで行われてもよい。

【0027】

よって、本発明の実施形態によれば、ステップi）で確認されたデータ・レコードIDから開始して、これらのデータ・レコードのフィールド値は、非常に効率的かつ迅速に確認されることができ、複雑な結果データ・レコードを確認して出力するために従来のDBMSによって必要とされるCPUおよび／またはRAMリソースのほんの一部を必要とするだけである。なぜなら、ステップi）からのデータ・レコードIDから開始して、アドレス割り当てテーブル内のIDベースのヒットのみが確認される必要があり、これらから開始して、一つまたは複数のAODエントリーの一つまたは複数のメモリ・アドレスが特に読み出される必要があるからである。これは、たとえば、アペンド専用データ構造の線形走査が必要とされず、代わりに、アドレスによって指定されたAODエントリーに対して直接に読み出しアクセスが行われうるので、非常に効率的である。

【0028】

本発明の実施形態によれば、フィールド固有データ値リストは、冗長性のない、ソートされたフィールド固有データ値リストであり、各データ値はリストごとに1回だけ出現する。

【0029】

実施形態によれば、データベース・クエリーは、論理データ・レコードを管理し、フィールド固有データ値リストの形でそれらを永続化するデータ処理および検索システム（DMSシステム）によって実行される。フィールド固有データ値リスト以外に、DMSシステムは、第1の統合時点でDMSシステムによってすでに管理されているすべての論理データ・レコードがそこから再構築されうるような、さらなるデータ構造を含まない。DMSシステムが、それらのデータ・レコードにおいて読むべき生データを一時的にパースまたはインポートすることは可能だが、これはデータ・レコードの抽出のために役立つだけである。したがって、データ・レコードが追加的に、テーブルやその他のデータ構造に永続的に保存される（永続化される）されることはない。

【0030】

これは、非常に少ない記憶空間しか必要とされない仕方で非常に大量のデータを記憶することができるので、有利でありうる。従来のデータベースでは、データはまず、主にまたは排他的にそのデータを永続化させるために機能するデータ構造、すなわち、たとえば、テーブルまたはグラフ・データベースのノードに格納される。これらの構造に加えて、使用されるDBMSのタイプと構成に応じて、検索インデックスなどの追加的な構造が作成され、高速検索が可能になる。よって、データは、テーブルとインデックスの両方において、冗長な仕方で格納される。しかしながら、実施形態によれば、論理データ・レコードは、フィールド固有データ値リスト内のエントリーの形でのみ記憶される。AOD構造、ポジティブ・リストおよび／またはネガティブ・リストなどの、本明細書に記載される追加的なデータ構造は、特に、次の統合の間に既存のフィールド固有データ値リストに、または既存のフィールド固有データ値リストのコピーに統合される変更情報を格納するために使用される。本発明の実施形態によれば、フィールド関連リストは、このように、論理データ・レコードを永続的に格納するとともに、迅速な検索を可能にするように機能する。

【0031】

原則として、このタイプの論理データ・レコード記憶は、追加的な検索インデックスの形での追加データの記憶を回避するだけでなく、実は、生データの記憶の過程で通例、圧縮が生じることが観察されている。たとえば、整数、浮動小数点数、文字列の形で天文学上の測定値およびパラメータを含む複数の列をもつ1.5TBのサイズのCSVファイルが、サイズが1.3TBのフィールド固有データ値リストの形で格納された。データ圧縮は、各フィールド固有データ値がリスト内で一度しか生起しないという事実によって可能になる。データ値が生起する論理データ・レコードへの参照の格納にも、記憶スペースが必要である。参照は、たとえば所定の長さの数値として、スペースを節約する仕方で記憶されうるデータ・レコードIDの形で記憶されるので、データ・レコードIDを記憶するために必要とされる追加的なメモリ要件は、通例、特定のフィールド／パラメータに属するすべてのデータ値を一度だけ記憶することによって節約されるメモリ要件よりも少ない。実施形態によれば、統合の過程で、フィールド固有データ値リストのそれぞれの統合バージョンのエントリーの数および最小の必要メモリ・サイズを決定し、この決定の結果に応じて、統合データ値リストの構造および／またはそれらの記憶位置を選択することによって、さらなる節約が達成されうる。

【0032】

データベースは、98のフィールドをもつ18億5000万のデータ・レコードを有する。

【0033】

実施形態に従って使用されるデータ構造は、きわめて高性能なデータ照会をも許容する。たとえば、前述の1.3TBのデータセットは、98のフィールドをもつ18億5000万の論理データ・レコードを含んでいた。本発明の実施形態によるデータ構造に基づいて、多数のフィールドに関する非常に複雑なクエリーでさえ、標準的なコンピュータ（516GB RAM、2つのIntel Xeon CPU E5-2643 v4@3.40 GHz）上で、数ミリ秒以内、場合によっては数秒以内に実行されうる。

【0034】

フィールド固有データ値リストのそれぞれにおける各データ値は、それらのフィールド識別子‐データ値ペアに従って、リストによって表されるフィールドについてそのデータ値を含む、すべての論理データ・レコードのデータ・レコードIDを割り当てられる。データ・レコードのそれぞれは、分散式に、一つまたは複数のフィールド固有データ値リストに物理的に格納される（複数のリストのデータ値に割り当てられた同一のデータ・レコードID（単数または複数）が、複数のデータ値を概念的に一貫したデータ・レコードに組み合わせる）。ステップi）におけるフィールド固有データ値リストの検索は、フィールド固有検索用語を、表現されているフィールドがフィールド固有検索用語のフィールドと同一であるフィールド固有データ値リストの、ソートされたデータ値とマッチングすることによって、実行される。

【0035】

実施形態によれば、フィールド固有データ値リストは、ステップi）で検索されたフィールド固有データ値リストのいずれかまたはすべてに対してロック（「データベース・ロック」）がなく、少なくともステップi）の実行中は、そこに含まれるデータ値に対してロックがない。これは、データベース・クエリー速度を大幅に向上させる可能性がある。

【0036】

ある実施形態によれば、AODエントリーのアドレスは、たとえば、オフセットと組み合わされた、アペンド専用データ構造の最初のAODエントリーの物理アドレスから構成されてもよく、オフセットは、アペンド専用データ構造の最初のAODエントリーに対するAODエントリーのアドレスである。

【0037】

従来のDBMSでは、返されるデータ・レコードの集合のデータ・レコードIDの確認と、やはり返されるこれらのデータ・レコードの属性との間に区別がなかった。むしろ、単一の複雑な、通常はSQLベースのクエリーが、どのテーブルを分析し、それらのテーブルのどの列を評価し、および／または返すかを指定した。しかしながら、本発明の実施形態は、データベース・クエリーが2ステップのクエリーであることを許容し、ここで、返されるべきデータ・レコードのIDの確認のみが、データの物理的な担体構造、すなわち、この場合、フィールド値固有リストに対して実行される。返されるべきデータ・レコードをその属性を用いて充実させることは、2つの特別なデータ構造、すなわち、先述のアドレス割り当てテーブルとアペンド専用データ構造のエントリー（そのアドレスを、アドレス割り当てテーブルのエントリーが参照する）に基づく。

【0038】

別の有利な側面では、データベースが非常に効率的に使用され、統合されることもできる。要求された変更は、第1の時点と後の（「第2の」）時点との間でフィールド固有リストに直ちに格納されず、最初はAODエントリーの形でアペンド専用データ構造にのみ、（そして、いくつかの実施形態によれば、いわゆるポジティブ・リストおよびネガティブ・リストにおいても、）格納されるので、読み出し要求は、フィールド固有リストに対するいかなる「ロック」もなしに実行されうる。よって、フィールド固有リストは、静的、すなわち、第1および第2の時点の間、変化しない状態を表す。クエリーの一貫性を保証するために、いくつかの読み取りアクセスの前にリストを一時的にロックする必要がないため、読み取り要求はこれらのフィールド固有リスト上で非常に効率的に実行されうる。

【0039】

たとえば、DMSシステムは、AODデータ構造上で並列に実行される1つの書き込みプロセスと多数の読み取りプロセスのみを許容するように構成されてもよい。したがって、データの一貫性の理由からロックを導入することなく、さまざまなデータベース・クエリーを完了するために、多くの読み取りプロセスから、継続的に補足されたAODデータ構造の内容を評価することが可能である。ここには論理的な対立は存在しない。データ構造を補足するために必要とされる1つの書き込みプロセスといくつかの読み取りプロセスは互いに干渉せず、特に、2つの書き込みプロセスが同じメモリに同時にアクセスすることは不可能であるというのが、アペンド専用構造の性質であるためである。本発明の実施形態によれば、方法は、フィールド固有データ値リストを、該フィールド固有データ値リストに対するデータベース・クエリーの実行とは独立して、および／またはそれと並行して統合することによって、最新の統合時点以降に指示された変更を統合することをさらに含む。統合は、新しい統合時点と呼ばれる第2の時点において実行される。

【0040】

たとえば、フィールド固有データベース・リストの統合は、実施形態に従って使用されるポジティブおよび／またはネガティブ・リストに基づいて記憶された情報（フィールド関連データ値およびそれらの論理データ・レコードとの関連付けに関する）を使用した、フィールド固有データベース・リストのデータ値およびデータ・レコードIDの更新を含んでいてもよい。

【0041】

実施形態によれば、方法は、それぞれのフィールド固有データ値リストのそれぞれのデータ値について：
・前記第1の統合時点と前記第2の統合時点との間に受領された変更命令の結果として、前記フィールドに関して前記データ値がもはや割り当てられなくなったすべての論理データ・レコードのデータ・レコードIDを、前記ネガティブ・リストおよびデータ・レコードIDと呼ばれるリストに格納し；
・前記第1の統合時点と前記第2の統合時点との間に受領された変更命令の結果として、前記フィールドに関して前記データ値が割り当てられることになるすべての論理データ・レコードのデータ・レコードIDを、ポジティブ・リスト（218）およびデータ・レコードIDと呼ばれるリストに格納することを含む。

【0042】

統合を実行することは、ポジティブ・リストおよびネガティブ・リストの内容に従って、フィールド固有データ値リストまたはフィールド固有データ値リストのコピーのデータ値およびデータ・レコードIDを更新することを含む。統合後、ポジティブ・リストとネガティブ・リストは空にされる。

【0043】

実施形態によれば、この方法は、統合と並行して、かつ統合とは独立して、中断することなく、フィールド固有データ値リストに対してさらなるデータベース・クエリーを実行することを含む。追加的または代替的に、フィールド固有データ値リストは、統合の実行中に、それらに含まれるデータ値に対するロックがない。

【0044】

上記の統合は、データ・レコードのフィールド固有データ値をフィールド固有データ値リストに格納することにより、矛盾したクエリー結果を避けるために、統合中にアクセスを一時的にロックされる必要があるリスト要素が、少数であり、可能性としては全くないことが保証されるため、有利である。たとえば、あるフィールドに関連する全く新しいデータ値が、データ値リストを統合する過程で追加された場合、すなわち、たとえば、以前は知られていなかったファーストネーム「Torben」が、この値を含むデータ・レコードのIDにリンクされたフィールド「ファーストネーム（first name）」に固有のデータ値リストに格納された場合、リストは1つの新しいエントリーのみを含み、以前のエントリーをロックする必要はない。データ・レコードの既存のデータ値が変更された場合、すなわち、たとえば、特定のデータ・レコードにおいて、誤記を含むファーストネーム「Micchael」が「Michael」に訂正された場合、データ値「Michael」のエントリーはデータ値自体を変更せず、代わりに、このデータ値に割り当てられたデータ・レコードIDのみが、今や訂正されたデータ・レコードのIDによって補足される。したがって、この統合中に、ファーストネーム・リストのデータ値が分析され、処理されることができる。

【0045】

従来のDBMSでは、データベースの、キャッシュされた変更との統合をサポートする限り、複数の依存関係と論理的制約をもつ複雑なテーブル構造に起因して、クエリー結果の論理的整合性を保証するために、統合中にいくつかの列、またはさらにはテーブルを完全にロックすることがしばしば必要になる。たとえば、従来のDBMSの書き込みおよび統合プロセスの過程では、セマフォ機構に基づくロックがしばしば使用され、これは、データベース・クエリーの処理に関してシステムの性能を著しく低下させる可能性がある。本発明の実施形態によれば、これは必要ない。なぜなら、一方では、アドレス割り当てテーブルとアペンド専用データ構造と組み合わせたフィールド固有リスト構造は、データベース設計において複雑なテーブル構造および制約を不要にするためであり、また他方では、多くの内容関連の変更の場合、影響を受けるのはデータ値ではなく、それぞれのフィールド固有データ値リスト内のこれらのデータ値に割り当てられたデータ・レコードIDのタイプおよび数のみであるためである。制約は、たとえば、値がテーブルに受け入れられるために変数の値が満たされなければならない条件であってもよい。本発明の実施形態によれば、さらに、フィールド関連データ値リストには最初は全く変更が行われず、AODデータ構造、ポジティブ・リスト、およびネガティブ・リストに変更が行われるので、データベース・クエリーを処理するためにデータ値リストが制限なしに使用されうる。統合の過程においてのみ、書き込みプロセスにおいてデータ値リストまたはそのコピーにアクセスする必要があるが、ほとんどの場合、既存のデータ値は変更によって全く影響されず、高々、データ値にリンクされて格納されているデータ・レコードIDである。削除後、データ値が、論理データ・レコードのいずれかにおける前記フィールドにもはや割り当てられていなくなる場合にのみ、実施形態によれば、そのデータ値リストの対応するデータ値が削除される（しかし、データ値が、将来格納されるデータ・レコードに後刻、リンクされることがありうるので、データ値がもはや論理データ・レコード内に現れない場合であっても、データ値リスト内にデータ値を残すことも可能である）。

【0046】

あるいはまた、本方法は、フィールド固有データ値リストに対するデータベース・クエリーの実行と独立して、および／または、それと並行して、フィールド固有データ値リストの統合されたコピーを生成することによって、最新の統合時点以降に指示された変更を統合することをさらに含む。統合は、新しい統合時点と呼ばれる第2の時点で実行される。

【0047】

この実施形態の利点は、データベース・クエリーのためにすでに分析されたデータ値リストに対して統合が直接実行される実施形態の利点に対応する。データ・レコードID割り当てまたはデータ値のロックが完全に回避されうるので、利点はなおさらである。というのも、統合は、現在の検索クエリーのために使用されるフィールド固有データ値リストに対してではなく、フィールド特定データ値リストのコピーに対して実行されるからである。

【0048】

たとえば、フィールド固有データベース・リストの統合されたコピーの作成は、統合の過程で、特にバックグラウンドで、DMSシステムによって自動的に実行されてもよく、一方、並行したデータベース・クエリーは、AODデータ構造を使用し、好ましくはポジティブ・リストおよびネガティブ・リストも使用して、まだ統合されていないデータ値リストに対して、通常の動作においてDMSシステムによって実行される。DMSシステムは、統合が完了した後、統合されていないフィールド固有データ値リストの代わりに、フィールド固有データ値リストの統合されたコピーに対してデータベース・クエリーを実行するように構成されている。したがって、この「スイッチオーバー」は、完了された統合またはスイッチオーバーの時点から、統合されたデータ値リストに対して新しいクエリーを実行させる。

【0049】

よって、AODデータ構造、ポジティブ・リスト、およびネガティブ・リストは、フィールド固有データ値リストがそれ自体ではもはや最新ではなくても、最新の結果を返すデータベース・クエリーが実行されることを許容し、一方、統合プロセスは、これらのデータ値リストのコピーに対してバックグラウンドで実行される。これにより、バックグラウンドで行われる統合の間、データベース・クエリーのためにデータが、パフォーマンスよく、中断されずに利用可能になる。

【0050】

本発明の実施形態によれば、統合は、フィールド固有データ値リストのそれぞれについて、以下のことを含む。
・フィールド固有およびデータ値固有の、データ・レコードIDのポジティブ・リストおよびネガティブ・リストを分析して、フィールドの一意的なデータ値の数に関する変化、および第1の統合時点と第2の統合時点の間のそのフィールドのデータ値にリンクされたデータ・レコードIDの最大数に関する変化を確認する；
・前記分析で確認された一意的なデータ値の数の変化の関数として、フィールド固有データ値リストの統合されたバージョンに含まれる一意的なデータ値の数を確認する；
・フィールド固有データ値リストの統合されたバージョンにおけるあるデータ値に割り当てられる、前記分析で確認されたデータ・レコードIDの最大数を格納するための第1のメモリ要件と、フィールド固有データ値リストの統合されたバージョンに格納される最大のデータ値を格納するための第2のメモリ要件を確認する；
・リスト内の一意的なデータ値の確認された数と第1および第2のメモリ要件の関数として、フィールド関連データ値リストの統合されたバージョンを格納するために必要とされるメモリ要件を計算する；
・少なくとも計算されたメモリ領域と同じ大きさの物理的なデータ担体上の連続領域を確認する；
・最後の統合時点以降にポジティブ・リストおよびネガティブ・リストに格納された変更を組み込む、フィールド関連データ値リストの統合されたバージョンを生成する；
・フィールド関連データ値リストの統合されたバージョンを、データ担体の確認された連続領域に記憶する。特に、記憶は、データ値リストの各エントリーが同じサイズを有する、たとえば、少なくとも、計算された第1および第2のメモリ要件の合計と同じ大きさであるようにしてもよい。

【0051】

たとえば、データ値リスト「ファーストネーム」の非統合バージョンは、312,234個の異なるエントリー（ファーストネーム）を含んでいてもよい。AODデータ構造の分析に基づいて、DMSシステムは、これらのファーストネームのうちの3つがデータセット内でグローバルに削除されたことを判別する（すなわち、これらの3つのファーストネームの削除は、現在すでに削除されているか、または異なるファーストネームを有する3つの個々のデータ・レコードに影響を及ぼすだけでなく、3つの削除または変更の結果として、これらの3つのファーストネームのうちの1つを有する単一の論理データ・レコードがもはや提供されない）。その代わりに、数百の新しいデータ・レコードがAOD構造に保存された。これは、2つの全く新しいファーストネームをもつ人についてのデータ・レコードを含む。したがって、ファーストネームのデータ値リストを統合する過程で、3つのファーストネームがリストから削除され、2つの新しいファーストネームが追加される必要がある。統合されたファーストネームのリストの要素数は、正味1要素分増加して、312,235個の異なるエントリー（ファーストネーム）になる。DMSシステムは、統合されたファーストネーム・リストによって必要とされるメモリ要件を、たとえば、エントリー数（312,235）と単一エントリーについてのメモリ要件の積として計算することができる。統合されたデータ値リストが記憶される仕方は、好ましくは、リストが、少なくとも、312,235個のエントリーとデータ値リストのエントリー毎に必要なメモリ容量との積と同じ大きさの連続した物理的なメモリ領域に格納されるようなものである。

【0052】

たとえば、データ値リストのエントリー毎に必要とされるメモリ・スペースは、次のように定義されてもよい：データ値自体を格納するために予約されるメモリ領域は、このリストの最大または最長のデータ値によって必要とされるスペースに対応する。たとえば、最も長いファーストネームは20文字（1文字あたり8ビットのメモリ要件をもつデータ型charとして表される）であってもよく、その結果、ここでは、ファーストネーム値一つあたり160ビットのメモリ領域となる。しかしながら、ファーストネーム・リストにおける各エントリーは、さらに、たとえば、整数データ型として表されうる論理データ・レコードIDの集合をも含む。DMSシステムは、まだ統合されていないファーストネーム・リストとAODデータ構造を分析することによって、ファーストネームに割り当てられたデータ・レコードIDの最大数を確認するように構成されている。たとえば、「Andreas」のようないくつかのファーストネームは頻繁に出現するため、大量のデータ・レコードIDを有するが、「XAEA-12」のような他のファーストネームは稀であるか、またはユニークである。（AOD構造に格納された関連する変更、および／またはファーストネームのポジティブ・リストおよびネガティブ・リストを考慮に入れて）最も頻繁に出現するファーストネームが、エントリーごとのデータ・レコードIDの量のために予約されるべきメモリ領域のサイズを決定する。たとえば、ファーストネーム「Andreas」が最も頻繁に、具体的には、たとえば502,344の論理データ・レコードにおいて出現する場合、および、各データ・レコードIDが32ビット整数として格納される場合、ファーストネーム・データ値リストの各エントリーは、データ・レコードIDを格納するために、少なくとも502,344×32ビット＝16,075,008ビットのメモリを予約しなければならない。したがって、ファーストネームのデータ値を格納するための160ビットを含めて、各エントリーについて16,075,168ビットのメモリを予約する必要がある。好ましくは、フィールドのデータ値（割り当てられたデータ・レコードIDの集合）について観察される最大の出現頻度は、それぞれのデータ値リストにリンクされて記憶され、各統合の過程で新たに確認され更新される。

【0053】

ここで説明する例では、ファーストネーム・リストの統合バージョンを格納するために必要とされる連続的な物理メモリ領域のサイズは、312,235個のエントリーと、データ値リストのエントリーごとに必要とされる16,075,168ビットのメモリ容量との積をとることによって計算される。

【0054】

このように、実施形態によれば、統合の過程における統合されたデータ値リストの記憶は、各統合リストがデータ担体の連続した物理的領域に、所定のサイズ（データ値自体とそれにリンクされたデータ・レコードIDの集合のための所定のサイズ）のデータ構造において記憶されるように行われる。リスト全体のための必要とされるメモリ要件、データ値のために必要なサイズ、およびリンクされた記憶されたデータ・レコードIDの量がいずれも、統合ごとに、必要に応じて、再計算され、調整される。これは、一方では、リストのデータ値が物理的に互いに隣接して連続的に記憶され、読み取り／書き込みヘッドがジャンプを行う必要がない場合、データを特に迅速に読み出すことができるため、有利でありうる。他方では、データ値またはデータ・レコードIDの集合のために予約されたメモリ領域は、実際に存在するデータの特性に動的に適応するため、データは非常に省スペースな仕方で格納されるということもある。したがって、記憶に使用されるデータ構造は、実際に必要とされるメモリ領域のみが予約されるように、記憶されるデータに自動的かつ柔軟に適応する。データベースのコンテキストでは、可変サイズのデータ値は、多くの場合、個別のデータ構造に格納され、それらはポインタを介してのみ参照される。しかしながら、このような格納は、パフォーマンスに悪影響を及ぼす可能性がある。実施形態によれば、各データ値およびその関連するデータ・レコードIDが、所定のサイズのデータ構造に格納され、個々のデータ・レコードは、物理的なデータ担体上に連続的に格納される。いくつかの実施形態によれば、DMSシステムは、それぞれのフィールド関連データ値リストのベース・アドレス、および個々のリスト・エントリーのオフセットおよびメモリ・サイズを使用して、フィールド関連データ値リストの各エントリーの物理的なメモリ・アドレスを指定し、アクセスするように構成される。これにより、アクセス時間が大幅に短縮される可能性がある。オフセットに基づく直接的でターゲットを絞ったアクセスは、事前定義されたサイズのデータ構造を使用することによって可能になる。

【0055】

本発明の実施形態によれば、方法は、フィールド固有データ値リストの提供、特に、フィールド固有データ値リストの初期提供を含む。この提供は、下記を含む：
・生データを解析してもとのデータ・レコードを作成するステップであって、各もとのデータ・レコードは、データ・レコードIDに加えて、フィールド識別子とそれに割り当てられたもとのデータ値との一つまたは複数のペアを含む、ステップと；
・前記データベースにおいて、冗長性のないフィールド固有のもとのデータ値リストを格納するステップであって、前記冗長性のないもとのデータ値リストの1つにおけるもとのデータ値リストのそれぞれに、該もとのデータ値リストによって表される1つのフィールドにそのもとのデータ値を含むデータ・レコードのすべてのデータ・レコードIDが割り当てられる、ステップと；
・前記冗長性のないもとのデータ値リストのそれぞれのもとのデータ値に、他のいずれのもとのデータ値にも割り当てられていない少なくとも1つのマッピングIDを割り当てるマッピング・テーブルを生成するステップと；
・前記もとのデータ・レコードを前記複数の論理データ・レコードに変換するステップと、前記冗長性のないもとのデータ値リストを冗長性のないフィールド固有データ値リストに変換するステップとを含み、前記変換は、前記マッピング・テーブルに従って、もとのデータ値をマッピングIDで置換することを含み、前記データ・レコードのフィールド識別子に割り当てられるデータ値は、前記マッピングIDである。

【0056】

たとえば、もとのデータ値は、文字列、たとえばファーストネーム「Michael」であってもよく、このもとのデータ値に割り当てられたマッピングIDは、「3493487879」のような数値であってもよい。

【0057】

他の実施形態によれば、もとのデータ値は論理データ値として直接使用されてもよく、フィールド固有リストはこの場合、フィールド固有のもとのデータ値リストである。

【0058】

フィールド固有リストを生成し、記憶するとき、検索を実行し、フィールド固有データ値に対して検索値を評価するときに、もとのデータ値の代わりにマッピングIDを使用することは、方法を大幅に高速化し、リソース消費を最小限にするという利点がある：たとえばパースおよび／またはトークン化ステップのために得られたもとのデータ値の長さは予測できず、たとえば文字列またはvarcharデータ型の形で存在するもとのデータ値の格納は多くのメモリ・スペースを必要とするが、マッピングIDの長さは一様な値に固定されてもよい。また、マッピングIDは数値として記憶することができるので、ユニコード文字列に比べてメモリ消費が削減でき、処理速度が大幅に向上できる。

【0059】

さらに、データ値リストは今や数値のマッピングIDのみで構成され、これはマッピング・テーブルの知識がなければもとのデータ値の再構成を許容しないため、データベースはより安全になる。

【0060】

以下では、論理データ値のフィールド固有データ値を説明するために、データ値がもとのデータ値、たとえばユニコード文字列である例が一般に使用される。しかしながら、好ましくは、データ値は、マッピング・テーブルにおいてもとのデータ値に一意的に割り当てられる数値データ値、特にマッピングIDである。実施形態に依存して、マッピング・テーブルは、いくつかのフィールド固有マッピング・テーブルを含んでいてもよく、または、任意のフィールドに存在するすべてのデータ値にマッピングIDを割り当てるグローバル・マッピング・テーブルからなる。

【0061】

本発明の実施形態によれば、マッピングIDは、データベース検索のために使用されるコンピュータ・システムのプロセッサ・アーキテクチャーに応じて、長さおよび／またはタイプ〔型〕が好ましくは選択される値である。特に、マッピングIDは、数値であってもよい。

【0062】

たとえば、すべてのマッピングIDは、使用されるプロセッサ・アーキテクチャーのレジスタ長に対応する特定のビット長（たとえば、32ビットまたは64ビット）を有してもよい。これにより、データ処理の速度がさらに向上し、リソース消費が削減されうる。

【0063】

本発明の実施形態によれば、マッピング・テーブルを生成することは、もとのデータ・レコードにおけるもとのデータ値の出現頻度を分析することを含む。もとのデータ・レコードにおけるもとのデータ値の出現頻度が閾値を超える場合、方法は、マッピング・テーブルにおいてこの1つのもとのデータ値に複数の異なるマッピングIDを割り当てることを含む。変換におけるもとのデータ値の置換は、1つのもとのデータ値が複数のマッピングIDによって置換されるように行われ、それにより、1つのもとのデータ値のもとの出現頻度が不明瞭になる。

【0064】

これは、出現頻度に基づくもとのデータ値のマッピングIDからの推論を排除されうるという利点を有することができる。言語またはデータ・レコードに依存して、ある種のもとのデータ値、たとえばある種の単語が非常に頻繁に出現する（ドイツ語では、たとえば「und」、「ein」、「eine」、または「das」（英語の「and」、「a」、または「the」）のような単語）一方、他の値はまれに出現する（たとえば「Schiffschraube」（「船のプロペラ」））。したがって、特にデータベースの内容がほぼわかっている場合、データ値やマッピングIDの出現頻度がもとのデータ値への手がかりを与えるため、フィールド固有リストがマッピングIDのみを含み、マッピング・テーブルが知られていないとしても、フィールド固有リストからもとのデータ・レコードが推測されるリスクがある。本発明の実施形態によれば、これは、可能性としては同じデータ値にいくつかの異なるマッピングIDを割り当てて、もとのデータ・レコード内のデータ値の出現頻度が不明瞭になるようにすることによって回避できる。たとえば、もとのデータ値「Michael」は、初期にはマッピングID「9237923」を割り当てられていることがありうる。特定のフィールド内の特定のデータ値（たとえば、「Michael」）を含むもとのデータ・レコードの数が閾値（たとえば、用途に応じて、1,000または10,000など）を超える場合、その後の各データ・レコード内のそのデータ値の出現が、データ値リストおよびマッピング・テーブルに格納され、それにより、データ・レコード内のこのデータ値の次の（たとえば、1001番目または10001番目の）出現から、新しいマッピングID「23747283472」がデータ値「Michael」に割り当てられ、フィールド固有データ値リストも、割り当てられたデータ・レコードIDとともに、この新しいデータ値によって拡張される。

【0065】

本発明の実施形態によれば、変更命令の少なくとも1つは、論理データ・レコードの少なくとも1つにおけるフィールドの古くなったデータ値を変更または削除する命令である。この方法は、ネガティブ・リストと呼ばれるデータ・レコードIDのリストにおいて、前記少なくとも1つのデータ・レコードのデータ・レコードIDを格納することを含む。ネガティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、変更要求に従って変更または削除されるデータ値にリンクされたデータ構造に格納される。

【0066】

データベース・クエリーの実行は、フィールド固有の検索値のそれぞれについて、下記を含む。
・データ構造が、フィールド固有の検索値および検索値のフィールド識別子と同一のデータ値およびフィールド識別子にリンクされて格納されたネガティブ・リストを含むかどうかをチェックするステップと；
・もしそうであれば、このフィールド固有の検索値についてステップi）で確認されたすべてのデータ・レコードIDと、ネガティブ・リストにおけるデータ・レコードIDとの差分量を計算するステップと；
・ステップii～ivのためにデータ・レコードIDの前記差分量を使用するステップ。

【0067】

これは、最新の統合時点以降の一つまたは複数のデータ値の変化に起因してデータベース・クエリーにおいてもはや見つからないべきであるが、データ値リストがまだ変化を反映していないためにステップi）で最初に見つかるデータ・レコードが返されないことを保証するので、有利である。たとえば、フィールド固有データ値リストのそれぞれについて、データ構造がデータベース内に作成され、このデータ構造は、このデータ値リストに含まれる各データ値について、データ値を上書きすることによるか、データ値を削除することによるか、またはデータ・レコード全体を削除することによるかにかかわらず、データ値リストを表すフィールド内でこの値が削除された、データ値固有の「ネガティブ・リスト」内のデータ・レコードIDのリストを含む。これは、データベース・クエリーが、まだ統合されていない特定のフィールドのデータ値の削除も考慮に入れることを保証する。

【0068】

本発明の実施形態によれば、変更命令の少なくとも1つは、データ・レコードのうちの少なくとも1つのデータ・レコードにおけるあるフィールドに新しいデータ値を割り当てる命令である。本方法は、さらに下記を含む。
・前記少なくとも1つのデータ・レコードのデータ・レコードIDを、ポジティブ・リストと呼ばれるデータ・レコードIDのリストに格納するステップであって、前記ポジティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、かつ、前記新しいデータ値にリンクされてデータ構造に格納される、ステップと；
・前記新しいデータ値が古くなったデータ値を置き換える場合、前記少なくとも1つのデータ・レコードのデータ・レコードIDを、ネガティブ・リストと呼ばれるデータ・レコードIDのリストに格納するステップであって、前記ネガティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、かつ古くなったデータ値にリンクされて格納される。

【0069】

データベース・クエリーの実行は、フィールド固有の検索値のそれぞれについて、下記を含む。
・データ構造が、フィールド固有の検索値および検索値のフィールド識別子と同一のデータ値およびフィールド識別子にリンクされて格納されたポジティブ・リストを含むかどうかをチェックするステップと；
・もしそうであれば、このフィールド固有の検索値についてステップi）で確認されたすべてのデータ・レコードIDと、ポジティブ・リストにおけるデータ・レコードIDとの和集合を計算するステップであって、前記新しいデータ値が古くなったデータ値を置き換える場合、前記和集合のデータ・レコードIDは、この検索値とそのフィールドに割り当てられたネガティブ・リストにおけるデータ・レコードIDだけ減らされる、ステップと；
・ステップii～ivのためにデータ・レコードIDの前記和集合を使用するステップ。

【0070】

これは、最新の統合時点以降の一つまたは複数のデータ値の変化に起因してデータベース・クエリーにおいて追加的に見出されるべきであるが、データ値リストがまだ変化を反映していないためにステップi）では初期にまだ見出されないデータ・レコードが返されることを保証するので、有利でありうる。たとえば、フィールド固有データ値リストのそれぞれについて、このデータ値リストに含まれる各データ値について、データ値リストを表すフィールドにおいてこの値が格納されたデータ値固有の「ポジティブ・リスト」内のデータ・レコードIDのリストを含むデータ構造がデータベース内に作成されてもよい。これは、別の古くなったデータ値を上書きすることによるか、このデータ・レコードのフィールドに初めてデータ値を格納することによるか、またはデータ・レコード全体を初めて格納することによるかを問わない。これは、データベース・クエリーが、まだ統合されていない変更や、特定のフィールドのデータ値または新しく書き込まれたデータ・レコードの補足も考慮に入れることを保証する。

【0071】

本発明の実施形態によれば、データ構造は、検索可能な、ソートされた要素の配列を含む。配列は、リスト要素のリストまたはノードの検索ツリーである。特に、検索ツリーはBツリーであってもよい。配列は、それぞれの場合においてフィールドの1つを表す。配列の要素は、データ・レコードに含まれ、配列によって表されるフィールドに割り当てられたデータ値の非冗長リストからの、それぞれ1つのデータ値を表す。配列の各要素は、空のまたは空でないポジティブ・リストおよび／または空のまたは空でないネガティブ・リストにリンクされて格納される。

【0072】

ソートされた、検索可能な形式でのポジティブ・リストおよび／またはネガティブ・リストの実装は、データベース・クエリーにおいて、動的に変更される、まだ統合されていないデータが非常に迅速に考慮に入れられることをも許容するので、有利でありうる。

【0073】

これまで、従来のデータベースでは、実際に保存することが意図されている（テーブル）形式にまだ転送されていない動的な非統合データを効率的に照会することができなかった。なぜなら、ここで同時にいくつかの問題が発生したからである。たとえばキャッシュに保存された、まだ統合されていない新しいデータは、データ格納のために使用される実際の（テーブル）構造に対して作用するクエリーによって捕捉されない。さらに、それらは、どのみちこれらのクエリーが作用できないキャッシュ内の構造において利用可能である。対照的に、記載される他のデータ構造、特にフィールド固有データ値リスト、アペンド専用データ構造、およびアドレス割り当てテーブルと組み合わせたポジティブ・リストおよびネガティブ・リストの使用は、データ・レコードIDに対する集合演算が、データベース・クエリーに応答して最終的に出力されるべきデータ・レコードの集合を認識するのに十分であるという利点を有する：ステップi）およびネガティブ・リストおよび／またはポジティブ・リストにおける検索の両方は、最終的に、データ・レコードIDであって、これらのデータ・レコードIDに対する集合演算によって非常に効率的な仕方で処理されうるデータ・レコードIDを返す。

【0074】

たとえば、検索クエリーは、フィールド「ファーストネーム」に関して、検索値「Michael」を含むことができる。フィールド「ファーストネーム」についての非冗長データ値リストにおける前記検索値を用いた検索は、ステップi）において、最新の統合時点でフィールド「ファーストネーム」内に値「Michael」を有していたデータ・レコードに関するデータ・レコードIDの初期集合を与える。

【0075】

フィールド「ファーストネーム」についてのデータ値「Michael」のネガティブ・リストの評価は、たとえば上書きのため、またはデータ・レコード全体が削除されたために、最新の統合時点以降にファーストネーム「Michael」が削除されたデータ・レコードに関するデータ・レコードIDの第2の集合をもたらす。しかしながら、i）で確認された第1の集合は、最新の統合時点以降の変化を含まないので、第2の集合のIDが、第1の集合のIDから差し引かれなければならない。すなわち、その間にファーストネーム・フィールドにおいて検索値「Michael」をもはや含まないデータ・レコードが出力されるのを防ぐために、差集合が形成されなければならない。

【0076】

フィールド「ファーストネーム」についてのデータ値「Michael」のポジティブ・リストの評価は、たとえば古くなった値を上書きすることにより、またはデータ・レコード全体が新しく作成されたことにより、最新の統合時点以降にファーストネーム「Michael」が追加されたデータ・レコードに関するデータ・レコードIDの第3の集合をもたらす。しかしながら、i）で確認された第1の集合は、最新の統合時点以降のいかなる変更も含まないので、第3の集合のIDは、第1の集合のIDに追加されなければならない。すなわち、最新の統合時点の後になってからファーストネーム・フィールドに検索値「Michael」を含むデータ・レコードも出力されることを保証するために、集合1および3から和集合が形成されなければならない。

【0077】

このように、ポジティブ・リストおよび／またはネガティブ・リストの使用は、最終的に返されるべきデータ・レコードの集合を確認するために、ステップi）で確認されたデータ・レコードIDの集合を用いた集合演算によって集計されうるデータ・レコードIDの第2の集合および／または第3の集合を非常に迅速に確認することを可能にする。ここでも、出力されるデータ・レコードを属性（データ値）を用いて充実させることは、アドレス割り当てテーブルとアペンド専用データ構造を介して行われる。出力されるべきデータ・レコードIDを補足するときにAODエントリーへのジャンプ・アドレスが使用されうるので、複雑な、テーブルを横断するJOINまたは類似の複雑な操作は必要とされず、したがって、出力は非常に効率的である。

【0078】

諸実施形態によれば、DMSは、すでに統合されたデータに対してのみ、および／または動的な、すなわちまだ統合されていないデータを含むすべての利用可能なデータに対して、データベース照会を実行することができる。ロックによるデータの不整合や時間遅延のリスクはない。

【0079】

DMSシステムは、最新の統合時点において統合されたデータに対してのみデータベース照会を実行することができる。これはたとえば、ステップi）でデータ・レコードIDを確認するために、データ値リストのみを使用し、ポジティブ・リストまたはネガティブ・リストを使用しないことによって、また、これらのデータ・レコードIDについてアドレス割り当てテーブルを介して確認された、最新の統合時点よりも古い、i）で確認された、返されるべきデータ・レコードを完成するために、AODエントリーのみを評価することによる。

【0080】

追加的にまたは代替的に、DMSシステムは、利用可能なデータの全体に対して、すなわち、統合されたデータおよびまだ統合されていないデータに対してデータベース照会を実行してもよい。これはたとえば、データ値リスト、および追加的にポジティブ・リストおよびネガティブ・リストを使用して、ステップi）でデータ・レコードIDを確認することにより、また、これらのデータ・レコードIDについてアドレス割り当てテーブルを介して確認された、i）で確認された、返されるべきデータ・レコードを完成するために、すべてのAODエントリーを評価することによる。

【0081】

データ値がマッピングIDである場合、諸実施形態によれば、データ値は、マッピング・テーブルにおいてマッピングIDに割り当てられたもとのデータ値で置き換えられてから出力される。

【0082】

本発明の実施形態によれば、配列の要素はそれぞれ、数値である、マッピングIDと呼ばれるデータ値を表す。マッピングIDは、マッピング・テーブル内の生のデータから得られたちょうど1つのもとのデータ値に割り当てられる。マッピング・テーブルにおけるマッピングIDの数値は、好ましくは、マッピングIDの数値順がもとのデータ値の順序関係と同一になるように選択される。もとのデータ値の順序関係は、特に、アルファベット順、数値順、または他の仕方で定義された順序である。検索可能な配列内の要素のソートは、マッピングIDの数値順に基づく検索順に対応する。

【0083】

これは、ネガティブ・リストおよび／またはポジティブ・リストの評価が非常に効率的に実行されうるため、有利でありうる。たとえば、Bツリーでは、ツリー内のノードは順序関係に従って配置されているので、ツリーのノードにおいて逐次検索は必要とされない。ソートされたリストの使用は、要素の数が少ないことを考慮すると、検索ツリーの構築があまりにコスト高である場合に特に有利でありうる。本発明の実施形態によれば、検索ツリーと検索リストの組み合わせも生成されてもよく、ここで、配列〔アレイ〕が検索ツリーとして生成されるか、検索リストとして生成されるかの問題は、検索されるデータ値の数に応じて動的に生成され、検索されるデータ値の数が最小数を超える場合にのみ、検索ツリーが生成される。

【0084】

諸実施形態によれば、フィールド固有データ値リストは、論理データ・レコード内のフィールド固有データ値リストを表す、フィールドに割り当てられたデータ値から選択される、それぞれ非冗長データ値リストである。それぞれのフィールド固有データ値リスト内の各データ値は、一意的であり（よって、「非冗長」リスト）、フィールド固有データ値リストによって表されるフィールド内のそのデータ値を含むすべての論理データ・レコードのデータ・レコードIDにリンクされて格納される。

【0085】

データ値は、好ましくは、フィールド固有データ値リストにおいて、ソートされた形式で格納される。これは、これらのリスト内のデータベース・クエリーの検索速度が大幅に向上させうる。

【0086】

本発明の実施形態は、（特定のプロパティまたは意味概念を表す）多くの異なるフィールドに関連する非常に多数の（オブジェクト当たり数千にもなりうる）データ値によって記述されるデータ・レコードが、（たとえば、データベース内のテーブルおよびインデックス構造に関して、リレーショナル・インデックス・ベースDBMSにおける検索クエリーの場合のように）データ・オブジェクトのもとの構造に依存する仕様に従う必要なしに、非常に短いクエリー時間で、最も多様なフィールド固有データ値の任意の組み合わせについて問い合わせされうるという利点を有しうる。インデックス・ベースのシステムでは、すべてのキーのすべての可能な組み合わせのインデックスが利用可能でなければならない。したがって、従来のインデックス・ベースのDBMSにおけるインデックスの量は、キーの階乗とともに増加する。特に、多数の異なる意味概念をもつ多数の異なるオブジェクト・タイプの場合、必要なインデックスの数は、キー関連の検索基準とキーの階乗との考えられる組み合わせによって増加する。一方、本発明の実施形態によれば、インデックスの生成および使用（実際のデータ値に加えて生成された検索可能なデータ構造という意味で）は、特にデータベースの静的部分においては必要ではない。実施形態によれば、非冗長データ値リストは、各フィールドに対応し、このフィールドの各データ値は――たとえば、リレーショナルDBMSのデータ・レコード・ベースのテーブルとは対照的に――一度だけ発生する。よって、本発明の実施形態によれば、期待される検索クエリーについて好適なインデックス構造を生成する必要なしに、検索および／または分析を実行することができる。むしろ、検索は、冗長性のないフィールド固有データ値リストにおいて直接実行されてもよい。

【0087】

本発明の実施形態によれば、統合は、最新の統合時点以降に指示された変更を統合するためのコマンドを受領することを含む。コマンドは、第2の時点で受領される。コマンドの受領に応答して、方法は下記を含む。
・統合されたフィールド固有データ値リストを生成するために、最新の統合時点と第2の時点との間に指示されたフィールド固有データ値リストまたはそのコピーにおける変更を実装して、各統合されたフィールド固有データ値リストにおける各データ値が、第1の時点と第2の時点との間に指示されたそのフィールドにおける変更を考慮に入れた後でも、そのデータ値を含む論理データ・レコードのIDのみが割り当てられるようにするステップと；
・第2の時点より後にデータベース検索を実行するために、以前に使用されたフィールド固有データ値リストの代わりに、統合されたフィールド固有データ値リストを使用するステップと；
・第2の時点を新しい最新の統合時点として使用するステップ
たとえば、フィールド固有データ値リストは、ネガティブ・リストに含まれるデータ・レコードIDを、それらが依然として対応するデータ値にリンクされている対応するフィールド固有リストから除去することによって、統合されることができる。同様に、統合は、ポジティブ・リスト内のデータ・レコードIDを対応するフィールド固有リストに追加して、これらのデータ・レコードのIDも対応するデータ値にリンクされるようにすることを含みうる。

【0088】

諸実施形態によれば、このコマンドの受領に応答して、統合されたフィールド固有データ値リストを生成した後、方法は、少なくとも1つのデータ構造を再生することを含む。生成は、統合されたフィールド固有データ値リストに基づいており、データ構造の再生は、ポジティブ・リストおよび／またはネガティブ・リストを空にすることを含む。

【0089】

これは、統合の過程で、ポジティブ・リストとネガティブ・リストの内容がフィールド固有データベース・リストにおいて変換され、第2の時点でデータの新しい統合された状態がデータベースにおいて作成されるため、有利でありうる。第2の時点の後、よって統合後に受領されるデータ値の変更を実行する命令については、空にされたポジティブ・リストとネガティブ・リストに再び入力され、再び統合が実行されるまで続行される。これにより、ポジティブ・リストとネガティブ・リストが長くなりすぎて、その使用と管理（たとえば、Bツリーの生成と更新）が計算上、より高価になるのを防ぐことができる。

【0090】

本発明の実施形態によれば、最新の統合時点と第2の統合時点との間で指示された変更を実施することは、変更によって影響を受けるすべてのフィールド固有データ値リスト内のすべてのデータ値のポジティブ・リストおよびネガティブ・リストを分析することによって、最新の統合時点と第2の統合時点との間に指示された変更を確認することを含む。

【0091】

本発明の実施形態によれば、論理データ・レコードのうちの少なくともいくつかは、一つまたは複数の「is-subordinate-to」〔…に従属する〕フィールドを含み、各「is-subordinate-to」フィールドは、そのデータ・レコードに対して上位にある（superordinate）データ・レコードのデータ・レコードIDを格納するように構成される。これは、DMSシステムが、「is-subordinate-to」フィールドにおいて、実際に上記関係を満たすデータ・レコードのデータ・レコードIDのみを格納するように構成されることを意味する。

【0092】

フィールド固有データ値リストは、「is-subordinate-to」フィールドを表すデータ値リストを含み、このデータ値リストに格納されるデータ値は、少なくとも1つの他の論理データ・レコードに従属する論理データ・レコードのIDである。「is-subordinate-to」データ値リスト内の各データ値は、他の上位データ・レコードの一つまたは複数のIDを割り当てられる。データベース・クエリーは、データベース・クエリーで確認されたデータ・レコードに加えて、これらのデータ・レコードの上位のデータ・レコードも出力されるかどうかを指定する完全性（completeness）検索パラメータを含む。

【0093】

データベース・クエリーの実行は、下記を含む。
・上位データ・レコードも出力されるべきであることを決定するステップと；
・ステップi）において確認されたデータ・レコードの上位にあるデータ・レコードの一つまたは複数のIDを取得するために、ステップi）において確認されたデータ・レコードIDを用いて「is-subordinate-to」データ値リストを検索するステップと；
・前記アドレス割り当てテーブルにアクセスして、前記確認された上位のデータ・レコードのうちの1つのIDに割り当てられたAODエントリーのアドレスを識別するステップと；
・データベース・クエリーにおいて確認されたデータ・レコードに上位のデータ・レコードを追加するために、AODエントリーのこれらの識別されたアドレスにアクセスするステップ。

【0094】

これは、階層式のオブジェクト関係も出力されることができるので有利であるうる。ここで、階層は、データ・レコード階層において前記検索値についてステップi）における諸ヒットから開始して、一つまたは複数のレベルだけ上方に拡張される。ステップi）においてIDが確認されたデータ・レコードが、たとえば、それが複数の所有者を有する車両であるために、いくつかの他のデータ・レコードに従属している場合、上位データ・レコードおよびそれらのデータ値は、いくつかのテーブルにわたる複雑で非効率的なデータベース・クエリーを実行する必要なしに、同時に出力されうる。

【0095】

本発明の実施形態によれば、論理データ・レコードのうちの少なくともいくつかは、一つまたは複数の「is-superordinate-to」〔…の上位である〕フィールドを含み、「is-superordinate-to」フィールドのそれぞれは、そのデータ・レコードに従属するデータ・レコードのデータ・レコードIDを格納するように構成される。

【0096】

フィールド固有データ値リストは、「is-superordinate-to」フィールドを表すデータ値リストを含む。このデータ値リストに格納されているデータ値は、少なくとも1つの他の論理データ・レコードに対して上位の論理データ・レコードのIDであり、「is-superordinate-to」データ値リスト内の各データ値は、他の従属〔下位〕データ・レコードの一つまたは複数のIDを割り当てられる。

【0097】

データベース・クエリーは、データベース・クエリーにおいて確認されたデータ・レコードに加えて、これらのデータ・レコードに従属するデータ・レコードも出力されるかどうかを指定する完全性検索パラメータを含む。データベース・クエリーの実行は、下記を含む。
・従属データ・レコードも出力されるべきであると決定するステップと；
・ステップi）で確認されたデータ・レコードに従属するデータ・レコードの一つまたは複数のIDを取得するために、ステップi）で確認されたデータ・レコードIDを用いて「is-superordinate-to」データ値リストを検索するステップと；
・前記アドレス割り当てテーブルにアクセスし、前記確認された従属データ・レコードのうちの1つのIDに割り当てられたAODエントリーのアドレスを識別するステップと；
・データベース・クエリーにおいて確認されたデータ・レコードに従属データ・レコードを追加するために、AODエントリーのこれらの識別されたアドレスにアクセスするステップ。

【0098】

これは、階層式のオブジェクト関係も出力されうるので有利でありうる。ここで、階層は、データ・レコード階層において前記検索値についてステップi）における諸ヒットから開始して、一つまたは複数のレベルだけ下方に拡張される。ステップi）においてIDが確認されたデータ・レコードが、他のいくつかのデータ・レコードに対して上位にある場合（たとえばそのデータ・レコードがいくつかの車両を所有する人を表し、それらの車両がその人に従属するデータ・レコードとして表されるため）、従属データ・レコードとそのデータ値は、いくつかのテーブルにわたる複雑で非効率的なデータベース・クエリーを実行する必要なしに、同時に出力されうる。

【0099】

よって、諸実施形態は、データベース・クエリーの結果が、（ステップi）において）データベース・クエリーの結果として直接確認されるデータ・レコードに加えて、これらの初期結果データ・レコードに対して上位または下位にあるさらなるデータ・レコードも確認され、出力されうるように、動的に拡張されうるという利点を有する。ここでは、データベース・クエリーの調整は必要ない。これは、ステップi）で確認された（データ値を用いて充実させられた）データ・レコードのみを返すデータベース・クエリーと、該結果データ・レコードに加えて下位および／または上位のデータ・レコードも（それらのデータ値とともに）含むデータベース・クエリーが、ほとんど同じ速度で実行されうることを意味する。この目的のために、クエリーを適応させてより複雑にする（そしてパフォーマンスを下げる）必要も、種々の問い合わせオプション（補足データ・レコードなし、上位データ・レコードのみ補足、下位データ・レコードのみ補足、下位および上位データ・レコードを補足）について別個のSQL SELECTクエリーを事前定義する必要もない。上位および下位データ・レコードの確認は、最終的には、集合演算を介してデータ・レコードIDに基づき、データ値（属性）によるこれらのデータ・レコードIDの補足は、アドレス割り当てテーブルおよび一つまたは複数のAODエントリーを介して高性能な仕方で実行されるので、実施形態によるデータベースは、高度に柔軟性があり、高度にスケーラブルであり、最小のCPUおよびメモリ要件で非常に大きなデータ・レコードに対してこの上なく複雑なクエリーでさえ実行することができる。

【0100】

実施形態によれば、ステップi）において初期に確認された結果データ・レコードを、さらなる下位および／または上位データ・レコードで補足するための上述のステップが逐次反復的に実行されてもよく、それにより、上位および下位データ・レコードのいくつかのレベルが出力されてもよい。このようにして、最高の複雑さのデータベース・クエリーを、従来のDBMSでは、少なくとも受け入れ可能な実行時間内ではできなかったような高パフォーマンスで、処理することができる。

【0101】

諸実施形態によれば、DMSシステムは、クエリー・システム（たとえば、ソフトウェア、別のコンピュータ・システム、ユーザーのデジタル表現など）がデータベース・クエリーを指定し、それを実行させることを許容するだけでなく、データベース・クエリーが、実際の結果データ・レコードに加えて、このクエリーの実際の結果データ・レコードに対して上位および／または下位にあるデータ・レコードも確認し、出力すべきかどうかを指定することを許容するインターフェースを有する。クエリー・システムは、好ましくは、クエリーがそのような拡張クエリーとして実行されるべきかどうかをそれぞれの個々のクエリーについて個別に指定することができ、DMSシステムは、フィールド固有データ値リスト「is-superordinate-to」および／または「is-subordinate-to」内で検索を実行することによって、ステップi）においてクエリーについて確認されたデータ・レコードについて上位または下位のデータ・レコードが存在するかどうかを自動的にチェックする。

【0102】

いくつかの実施形態によれば、各AODエントリーは、「フラグ」とも呼ばれる識別子を含み、これは、AODエントリーが関係するデータ・レコードについて上位または下位のデータ・レコードが存在するかどうかを示す。この識別子が上位または下位データ・レコードが存在しないことを示す場合、「is-superordinate-to」および／または「is-subordinate-to」データ値リストを検索するステップは、クエリーが実際に拡張クエリーとして実行される場合であっても省略される。なぜなら、この場合、識別子は、このデータ・レコードについて上位または下位データ・レコードが存在しないことをすでに示しているからである。これにより、この方法の速度がさらに向上しうる。

【0103】

本発明の諸実施形態によれば、フィールド固有データ値リストは、時間値リストと呼ばれる複数のフィールド固有データ値リストを含む。時間値リストのそれぞれは、時点〔時間点〕の非冗長リストからなり、時点はそれぞれ、その時間値リストが関係するフィールドのデータ値の有効性が一つまたは複数の論理データ・レコードにおいて開始または終了する時点を表す。時間値リストにおける各時点は、その時点で有効な諸論理データ・レコードのIDが割り当てられる。たとえば、「ファーストネーム」フィールドのためのフィールド固有データリストは、すべてのデータ・レコードのすべてのファーストネームの非冗長リストを含むことができ、そのフィールドに関連する時間値リストは、ファーストネーム・フィールドのデータ値がデータ・レコードのいずれかにおいて有効になった（たとえば、ファーストネームを有するデータ・レコードの生成によって、または既存のデータ・レコードのファーストネーム・フィールドへの現在有効なファーストネームの割り当てによって）すべての時点の非冗長リストを含むことができる。

【0104】

本方法は、好ましくは、さらに以下を含む：
・論理データ・レコードの1つに関する（すなわち、データ・レコードのフィールドの1つに対する新しい、より最新のデータ値の割り当てに関する）変更要求の受領に応答して、変更されるデータ・レコードの新しいバージョンを生成するステップであって、新しいバージョンは、少なくとも1つの前バージョン・フィールドを含む新しい論理データ・レコードであり、前バージョン・フィールドは、変更されるデータ・レコードのIDを含み、変更されるデータ・レコードではなく、新しいバージョンが、変更要求で指定された変更と変更の時刻を含む、ステップと；
・前記フィールド固有データ値リストにおいて、新データ・レコードIDを有する前記データ・レコードの新しいバージョンを格納し、前記時間値リストの前記新しいデータ・レコードの有効性の開始と、前記変更命令が参照するフィールドとを格納するステップであって、前記新しいバージョンのIDは前記時間値リストに格納される、ステップ。

【0105】

これは、データ・レコードの有効性およびその個々のデータ値の有効性の履歴過程も記憶され、それにより、経時的なデータ・レコードの履歴も記憶され、再構築されうるため、有利でありうる。データ・レコードのデータ値が変化した場合、すなわち、前のデータ値が無効になった場合、DMSシステムは、その有効期間の開始が新しいデータ値の有効性または割り当ての開始とともに始まる新しい論理データ・レコードを作成する。データ・レコードの有効期間は、そのデータ値の1つが無効になる、すなわち変更または削除されるときに終了する。

【0106】

本発明の諸実施形態によれば、データベース照会は、フィールド固有の有効時間の指示を含む。有効時間は、データベース照会で確認されるべきデータ・レコード・バージョンが、対応するフィールドにおいて前記少なくとも1つのフィールド固有の検索値を含んでいた時点または時間期間を指定する。データベース照会〔データベース・クエリー〕の実行は、下記を含む：
・検索値および有効時間が関連するフィールドに関連する時間値リストを識別するステップと；
・有効時間に、または有効期間内の時点にリンクされた時間値リストに格納されているデータ・レコード・バージョンの一つまたは複数のデータ・レコードIDを識別するために、識別された時間値リストを前記検索値で検索するステップと；
・前記検索値および前記有効時間が関連するフィールドに関連するフィールド固有データ値リストを識別するステップと；
・前記検索値にリンクされたデータ値リストに格納された一つまたは複数のデータ・レコードIDを識別するために、前記識別されたデータ値リストを前記検索値で検索するステップと；
・前記識別された時間値リストおよび前記識別されたデータ値リストに基づいて確認されたデータ・レコードのバージョンのIDの共通集合を計算するステップと；
・アドレス割り当てテーブルにアクセスして、前のステップで確認されたデータ・レコード・バージョンのうちの1つバージョンのIDに割り当てられたAODエントリーのアドレスを識別するステップと；
・有効性時点において、または有効性期間中に、データ・レコード・バージョンをそのフィールド値で補足して出力するために、前のステップで識別されたAODエントリーのアドレスにアクセスするステップ。

【0107】

これは、データ・レコードの各フィールド値について、いつ変更されたか、または、どの時間期間の間に、前記データ値がある特定のデータ・レコードの特定のフィールドについて有効であったかを決定することができるため、有利でありうる。時間値は、冗長性のないデータ値リストにおいてデータ値として格納されるため、ある時点、その後、またはその前に発生した変更を効率的に検索することも可能である。時間情報は、たとえば、日付と時間情報の組み合わせから構成されてもよく、および／または、所定のグローバル開始時間から開始して時間とともに増加する数値として記憶されてもよい。

【0108】

本発明の諸実施形態によれば、フィールド識別子の数および／またはタイプは、データ・レコードの少なくともいくつかについて異なる。

【0109】

これは、データベースを非常に柔軟に使用できるようにするため、有利でありうる。物理的なストレージ構造（この場合はフィールド固有データ値リスト）の構造を適応させる必要なく、幅広い多様なデータをデータベースに記憶することができるデータは、テーブル構造の事前に定義された狭いコルセット（corset）に変換されるため、データベースに生データを格納するときに情報が失われることが回避される。その代わりに、異なるフィールドをもつデータ・レコードは、最終的に各フィールドのデータ値が冗長性のないフィールド固有データ値リストに格納されるため、データベースにおいて均等に格納されうる。

【0110】

いくつかの実施形態によれば、論理データ・レコードは、同じフィールドを参照する複数のフィールド識別子‐データ値ペアを含むこともできる。これは、関係を表すフィールドについて特に有効でありうる。たとえば、「is-superordinate-to」フィールドは、複数の車両を所有する人を特徴付けるデータ・レコード内に複数回出現することがある。その人が所有する車両を表すデータ・レコードのデータ・レコードIDをその人の複数の「is-superordinate-to」フィールドに格納することによって、データベースにおいてperson-owns-vehicle〔人が車両を所有〕関係が表現され、格納されてもよい。データ・レコード内の同じフィールドについて複数のフィールド識別子データ値ペアを有することによって、1:nおよびn:mの関係を含むオブジェクト間の任意の関係を格納することが可能であり、これらの複雑な関係は、データベース・クエリーによって非常に迅速に確認され、出力され、および／または考慮されることができる。

【0111】

本発明の諸実施形態によれば、AODエントリーは、アペンド専用データ構造内のブロックチェーンの要素として格納され、暗号学的ハッシュ値を介して一緒にチェーンされる。データベース検索の実行は、データベース照会の過程で処理されるAODエントリーのハッシュ値の有効性チェックを含む。

【0112】

これは、アペンド専用データ構造のその後の操作が効果的に防止されうるため、または少なくとも、アペンド専用データ構造を使用する前にブロックチェーンのハッシュ値を有効確認するDMSシステムによって、そのような操作をすぐに検出することが可能であるため、有利でありうる。

【0113】

別の側面では、本発明は、コンピュータ可読命令が記憶される揮発性または不揮発性記憶媒体に関する。命令は、本明細書に記載された実施形態および例のいずれかに従って、データベース内でデータベース照会を実行する方法をプロセッサに実行させるように構成される。

【0114】

別の側面では、本発明は、データベース内でデータベース照会を実行するためのコンピュータ実装される方法、ならびに対応するコンピュータ・システム、コンピュータ・プログラム・プロダクトおよびデータ構造に関する。データベースは、「最新の統合時点」と呼ばれる第1の時点における複数の論理データ・レコードを含む。各論理データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアを含む。データ・レコードは、フィールド固有データ値リストの形で物理的に格納される。この方法は、最新の統合時点の後に、以下のことを含む：
・前記データ・レコードのいくつかのもののフィールドのデータ値を変更する命令を受け取るステップと；
・フィールド固有データ値リストに変更を加えることなく、アペンド専用データ構造に前記命令を格納するステップであって、ここではAODエントリーと呼ばれるアペンド専用データ構造における各エントリーが、少なくとも、前記データ・レコードのうちの1つのフィールド識別子データ値ペアのうちの、変更命令の1つに従って変更されるべきものを含む、ステップと；
・データベースが、最新の統合時点の後にデータ値を変更するための一つまたは複数の命令をそれについて受領するデータ・レコードのそれぞれについて、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうちの最新のもののアドレスを、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブルに格納するステップであって、前記アドレス割り当てにおけるリンクは、自動的に更新される、ステップ；
アドレス割り当てテーブルを使用して、フィールド固有データ値リストに対してデータベース・クエリーを実行する。たとえば、データベース・クエリーは、本発明の実施形態についてここで説明される、上述のステップi～ivを含むことができる。他のすべての実施形態も、本発明のこの側面と組み合わされることができる。別の側面では、本発明はデータ構造に関する。データ構造は、下記を含む：
・論理データ・レコードが分散式に格納される複数のフィールド固有データ値リストであって、各データ・レコードがデータ・レコードIDと一つまたは複数のフィールド識別子‐データ値ペアを含む、複数のフィールド固有データ値リストと；
・データ・レコードのフィールドのデータ値を変更するための命令を含むアペンド専用データ構造であって、ここではAODエントリーと呼ばれるアペンド専用データ構造における各エントリーは、少なくとも、前記データ・レコードのうちの1つのフィールド識別子データ値ペアのうち、変更命令の1つに従って変更されるべきものを含む、アペンド専用データ構造と；
・アドレス割り当てテーブルであって、該アドレス割り当てテーブルは、変更命令を有するAODエントリーがアペンド専用データ構造において格納されている各データ・レコードのIDに対して、そのデータ・レコードに対する変更を指定する最新のAODエントリーのアドレスを割り当てる、アドレス割り当てテーブル。

【0115】

フィールド固有データ値リスト、アペンド専用データ構造、およびアドレス割り当てテーブルのそれぞれは、1つのデータ構造と見なされる。

【0116】

本発明の諸実施形態によれば、データ構造は、追加的または代替的に、検索可能なソートされた要素の配列を含む少なくとも1つのデータ構造を含む。配列は、リスト要素のリストまたはノードの検索ツリーである。特に、探索ツリーはBツリーであってもよい。配列は、それぞれの場合における論理データ・レコードのフィールドの1つを表す。配列の要素は、データ・レコードに含まれ、配列によって表されるフィールドに割り当てられたデータ値の非冗長リストからの、それぞれ1つのデータ値を表す。配列の各要素は、空または空でないポジティブ・リストおよび／または空または空でないネガティブ・リストにリンクされて格納される。

【0117】

本発明の諸実施形態によれば、データ構造は、追加的または代替的に、フィールド固有の冗長性のないデータ値リストを含む。データ値リストは、もとのデータ・レコードが格納されている生データから得られるフィールド固有のもとのデータ値リスト、またはマッピング・テーブル内でこれらのもとのデータ値に一意的に割り当てられた値、好ましくは数値のリスト（ここでは「マッピングID」と呼ぶ）として構成されうる。

【0118】

本発明の諸実施形態によれば、データ構造は、追加的または代替的に、マッピング・テーブルを含む。マッピング・テーブルは、もとのデータ・レコードのもとのデータ値のそれぞれに対して、もとのデータ値の他のいずれにも割り当てられていない少なくとも1つのマッピングIDを割り当てる。マッピングIDは、論理データ・レコードおよびフィールド固有リストのデータ値として使用される。

【0119】

本発明の諸実施形態によれば、データ構造は、追加的または代替的に、一つまたは複数のフィールド固有の時間値リストを含み、各時間値リストは、有効時間の、冗長性のないリストからなるリストであり、各有効時間は、その時間値リストを表すフィールドのデータ値が論理データ・レコードの1つにおいて変更された時間を示し、各フィールド固有の時間値リストの各有効時間は、その有効時間において時間値リストのフィールドに対応するデータ値が変更された論理データ・レコードのすべてのバージョンのデータ・レコードIDを割り当てられる。

【0120】

本発明の諸実施形態によれば、データ構造は、追加的または代替的に、一つまたは複数の「is-superordinate-to」データ値リストを含み、その「is-superordinate-to」データ値リストに格納されたデータ値は、少なくとも1つの他の論理データ・レコードに対して上位の論理データ・レコードのIDであり、「is-superordinate-to」データ値リスト内の各データ値は、他の下位のデータ・レコードの一つまたは複数のIDを割り当てられる。

【0121】

本発明の諸実施形態によれば、データ構造は、追加的または代替的に、一つまたは複数の「is-subordinate-to」データ値リストを含み、そのデータ値リストに格納されたデータ値は、少なくとも1つの他の論理データ・レコードに従属する論理データ・レコードのIDであり、「is-subordinate-to」データ値リスト内の各データ値は、他の上位データ・レコードの一つまたは複数のIDを割り当てられる。

【0122】

別の側面では、本発明は、少なくともプロセッサと、データベースを含むデータ・メモリとを含むコンピュータ・システムに関する。

【0123】

データベースは、「最新の統合時点」と呼ばれる第1の時点において、複数の論理データ・レコードを含み、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを有する。各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、データ・レコードは、フィールド固有データ値リストの形で物理的に格納される。

【0124】

コンピュータ・システムは、データ処理および検索システム――DMSシステム――をさらに含む。DMSシステムは、データベースを管理するように構成され、最新の統合時間後の管理は、以下を含む：
・前記データ・レコードのいくつかのもののフィールドのデータ値を変更する命令を受け取るステップと；
・フィールド固有データ値リストに変更を加えることなく、アペンド専用データ構造に前記命令を格納するステップであって、ここではAODエントリーと呼ばれるアペンド専用データ構造における各エントリーが、少なくとも、前記データ・レコードのうちの1つのフィールド識別子データ値ペアのうちの、変更命令の1つに従って変更されるべきものを含む、ステップと；
・データベースが、最新の統合時点の後にデータ値を変更するための一つまたは複数の命令をそれについて受領するデータ・レコードのそれぞれについて、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうちの最新のもののアドレスを、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブルに格納するステップであって、前記アドレス割り当てにおけるリンクは、自動的に更新される、ステップと；
・データベース・クエリーを実行するステップ。ここで、データベース・クエリーは下記を含む：
i）フィールド固有データ値リストを検索して、一つまたは複数のフィールド固有の検索値との一致に基づいて、その内容の全部または一部が返されるべきデータ・レコード（214）のIDを識別し；
ii）i）で識別されたデータ・レコードIDの1つに割り当てられたAODエントリーのアドレスを識別するために、アドレス割り当てテーブルにアクセスし；
iii）AODエントリーの識別されたアドレスにアクセスし；
iv）これらの識別されたAODエントリーに含まれる変更詳細を使用して、フィールド識別子‐データ値ペアをステップi）で確認されたデータ・レコードIDに追加し、後者を出力する。

【0125】

諸実施形態によれば、前記少なくとも1つのプロセッサは、ALU（算術論理ユニット・プロセッサ）またはFPGA（フィールドプログラマブルゲートアレイ）を含む。ALUまたはFPGAは、データ・レコードIDの集合に対して集合演算を実行するように構成され、集合演算は、特に、共通集合、和集合、差集合、または対称差集合の計算を含む。特に、集合演算はALUまたはFPGAによって、2つのデータ・レコードIDの比較がALUまたはFPGAの単一の動作サイクル（比較動作）内で実行されるように、実行されてもよい。たとえば、識別子の長さは、プロセッサ・アーキテクチャーの処理範囲（たとえば、32ビットアーキテクチャーの場合は32ビット、64ビットアーキテクチャーの場合は64ビット）に対応してもよい。プロセッサ・アーキテクチャーが数値を特に効率的に処理することができる場合、識別子は数値から構成されてもよい。プロセッサ・アーキテクチャーが他の値タイプ（たとえば、シンボル）を特に効率的に処理することができる場合、識別子はシンボルから構成されてもよい。

【0126】

これは、設計（たとえば、レジスタ・サイズ）が事前定義された長さのデータ・レコードIDに対して集合演算を実行するために最適化されているハードウェア・コンポーネントの形態での実装が、データベース内のデータの処理および検索を著しく高速化することができるため、有利でありうる。

【0127】

「プロセッサ」は、ここでは、（通例、非常にサイズが小さくされ、通例は自由に）プログラム可能な演算ユニット、すなわち、転送されたコマンドに従って他のマシンまたは電気回路を制御し、そうすることで、通例、データ処理に関わるアルゴリズム（プロセス）を駆動するマシンまたは電子回路であると理解される。プロセッサは、たとえば、メインプロセッサ、中央処理装置、または（より一般的には）その中でプロセッサがコマンドを実行するコンピュータまたはコンピュータのような装置の中央処理装置（略してCPU）であってもよい。プロセッサは、組み込みシステム（家庭用電化製品、券売機、スマートフォン等）におけるマイクロコントローラとして構成されることもできる。

【0128】

諸実施形態によれば、方法のステップの少なくとも1つは、プロセッサのサブユニットによって直接実行される。

【0129】

特に、本発明の諸実施形態によれば、データ・レコードIDに対する集合演算は、前記少なくとも1つのプロセッサの算術論理ユニット（ALUと短縮されることが多い）によって直接実行されてもよい。ALUは、同じ桁数（n）の2つのバイナリ値をリンクすることができる。nビットALUが言及される。nの典型的な値は、8、16、32、および64である。本発明の諸実施形態によれば、すべてのデータ・レコードIDは、固定長、特に同一長を有し、これは、各データ・レコードIDがALUの作業レジスタ内に完全に収まるように選択されることが好ましく、ALU内の集合演算の過程で互いに比較されうる。特に、データ・レコードIDの2つの集合を比較するために、たとえば、共通集合、和集合、差集合、または対差分集合を計算するために、ALUは、一方の集合のすべてのデータ・レコードIDを、同一性について他方の集合のすべてのデータ・レコードIDと比較することができる。

【0130】

ここで、「生データ」とは、電子形式で利用可能であり、まだDMSシステムのパーサーによってパースされた形式ではない任意のデータを意味する。特に、生データは、観察、測定またはデータ収集の間に直接得られ、まだ未処理のままで利用可能なデータを含む。

【0131】

「データ処理および検索システム――DMSシステム」は、ここでは、電子データを記憶、管理および処理するためのソフトウェアおよび／またはハードウェア・ベースのシステムとして理解される。本発明の実施形態によれば、DMSシステムは、大量のデータを矛盾なく、かつ永続的に効率的に格納するように構成される。諸実施形態によれば、DMSシステムは、モジュールの形でありうるいくつかの構成要素、すなわち、生データを受領してパースし、パースされたデータを非冗長リストに格納するためのインポート・コンポーネントを含みうる。ここで、インポート・コンポーネントは既存のリストを使用し、必要に応じて新しいリストを自動的に作成することができる。DMSシステムは、リストを検索および／または解析するための検索および解析コンポーネントをさらに含むことができる。任意的に、DMSシステムは、たとえば、下位および／または上位のデータ・レコード、またはあるデータ・レコードの履歴も出力されるべきかどうかを指定するために、ユーザーが検索を構成することを許容するGUIを含んでいてもよい。DMSシステムは、DMSシステムによって管理されるデータ・メモリへの読み取りおよび書き込みアクセスを有する。諸実施形態によれば、DMSシステムは、データ・メモリと、そこに格納されたデータ値リストとを含む。任意的に、DMSシステムは、生データの少なくとも一部を記憶するための文書メモリをさらに含むことができる。

【0132】

「論理データ・レコード」は、ここで、関連する内容、たとえば、アイテム番号、アイテム名および製造日を有する（オブジェクトに属する）データ値のグループであると理解される。データ・レコードは、たとえば、生データをパースするとき、またはフィールド・ベースの生データをインポートするときに認識されるデータ値の論理構造に対応する。データ・レコードの論理構造は、このデータ・レコードにいくつのフィールドが含まれるかおよびどのフィールドが含まれるか、およびこれらの各フィールドにどのデータ値が割り当てられるかを指定する。しかしながら、物理的には、データ・レコードは、異なる仕方で、特に分散式に格納されてもよく、たとえば、あるデータ・レコードの諸データ値は、それぞれ、冗長性のないフィールド固有データ値リストの要素として格納されてもよい。

【0133】

生データに含まれるデータ・オブジェクトは、すでにデータ・レコードID（たとえば、行ごとに配向されたデータ・レコードを有するExcelテーブルの行番号）を含んでいる場合があるが、諸実施形態によれば、生データをパースまたはインポートする過程で、データ・レコードIDがDMSシステムによって動的に作成されることも可能である。特に、データ・レコードIDは、そのデータ・レコードに割り当てられたアドレス割り当てテーブル内の行のメモリ・アドレスを明示的または暗黙的にエンコードするように生成されてもよい。

【0134】

論理データ・レコードは、もとのデータ・レコードであってもよいが、好ましくは、もとのデータ値をマッピングIDで置換することによってもとのデータ・レコードから変換ステップにおいて形成されるデータ・レコードである。

【0135】

「もとのデータ・レコード」は、ここで、生データから得られた、自動的にインポートされた、またはユーザーによって入力された、ここで「もとのデータ値」と呼ばれる関連する内容を有する（オブジェクトに属する）データ値のグループを意味する。もとのデータ・レコードは、少なくとも部分的には、数値ではないデータ値（たとえば、自然言語の単語）で構成される場合がある。

【0136】

「アペンド専用データ構造」は、ここでは、データ構造の一方の端に新たなデータを追記することができるが、既存のデータは変更できないデータ構造、特にファイルを意味するものと理解される。多くのファイルシステムのアクセス制御リストは、「アペンド専用」のパーミッションを実装している。たとえば、chattrをもつLinux（登録商標）オペレーティング・システムは、ファイルとディレクトリーに設定される「append-only」〔アペンド専用〕フラグをサポートする。一部のクラウド・ストレージ・プロバイダーは、アクセスを「アペンド専用」として制限するオプションを提供している。この機能は、これまで、特にバックアップ・ポリシーのためのデータ損失のリスクを緩和するために使用されてきたが、アドレス割り当てテーブルと組み合わせてデータベース・クエリーの速度を上げるためには使用されていない。なぜなら、これらのデータ・レコードのフィールド関連データ値による結果データ・レコードIDの充実は、これらのデータ構造に基づいて実行されるからである。アペンド専用データ構造は、時間の経過とともに大きくなる。

【0137】

アドレスとは、ここでは、論理的または物理的なメモリ領域の一意的な識別子を意味するものと理解される。好ましくは、メモリ領域は、アドレスを援用して直接アクセスされうる、揮発性または不揮発性の記憶媒体（たとえば、RAM、ハードドライブ等）内の領域である。アドレスは、アクセスが行われる正確な位置を指定するために、メモリ・アクセスにおいて使用される。アドレッシングの詳細は、特定のハードウェアに依存する。AODエントリーのアドレスは、複合アドレスであってもよく、その第1の部分は、最初に書き込まれたAODエントリーのメモリ・アドレスを指定し、その第2の部分は、複合アドレスによって指定されたAODエントリーが見出されうる、その最初AODエントリーに対するオフセットを指定する。アドレスは、論理アドレスまたは物理アドレスでありうる。

【0138】

特に、「アドレス」は、データ処理システムが、このアドレスで利用可能にされたデータへの少なくとも読み出しアクセスを有することを可能にする指示として定義されてもよい。アドレスは、たとえば、ネットワークを介して利用可能なファイルへのURL、ファイルのローカルファイルシステム・ベースのアドレス、または特定のファイル内のエントリーなどでありうる。

【0139】

「データ値」とは、ここでは、データ・レコードの評価可能な最小単位を意味するものと理解される。データ値は、たとえば、ストリング、画像、ピクセルマトリクス、ユニコード文字、または数値であってもよい。データ値は、たとえば、データ・インポート、パースするステップおよび／またはトークン化ステップの過程で、またはこれらのステップに続くマッピング・ステップの過程で取得することができ、ここで、もとのデータ値は、最終的にデータ値として使用され、フィールドに割り当てられ、フィールド固有データ値リストに格納される数値マッピングIDを割り当てられる。

【0140】

「冗長性のないデータ値リスト」は、ここでは、各データ値を一度だけ含むデータ値のリストとして理解される。好ましくは、データ値は、リストに対するデータベース照会を高速化するために、リスト内にソートされた順序で格納される。

【0141】

「フィールド固有データ値リスト」は、ここでは、特定のフィールドに割り当てられ、このフィールドを表し、まさにこのフィールド内のデータ・レコードに含まれるデータ値のみを選択的に含むデータ値リストを意味するものと理解される。データ値は、他の（「もとの」）データ値に割り当てられたマッピングIDであることもできる。

【0142】

「時間値リスト」は、ここでは、データ値が時点または時点のマッピングIDである、冗長性のないデータ値リストを意味するものと理解される。時間値リストは、好ましくは、ここでは、データ・レコードのフィールドの1つに割り当てられる。時間値リストに格納された各時間値は、時間値リストが割り当てられているフィールドのデータ値が一つまたは複数のデータ・レコードにおいて変更された時点を表す。時間値リストには、その時点における変化によって影響を受けたデータ・レコードのIDが、その時間値にリンクされて格納される。

【0143】

典型的には、データ値の内容の変更は、フィールド固有データ値リストにも格納されるため（たとえば、前のフィールド関連データ値と新しいフィールド関連データ値にそれぞれ割り当てられたデータ・レコードIDの変更の形で）、このフィールド固有データ値リストとフィールド固有の時間値リストの内容の組み合わせは、データ値の変更の内容と時間の両方を明らかにする。

【0144】

有効時間期間とは、ここで、あるデータ値がデータ・レコードのフィールドに割り当てられている（よって、このデータ・レコードおよびこのフィールドについて「有効」である）時間期間を意味すると理解される。時間期間は、たとえば、（たとえば、データ・レコードを初めて生成するかまたはインポートすることにより、または古くなったデータ値を上書きすることにより）前記データ値がデータ・レコードのフィールドに割り当てられた最初の有効時間によって、およびこのデータ値が上書きされたかまたはデータ・レコードが削除されたかまたは古くなったバージョンとして扱われた、有効時間期間の終点によって制限される。

【0145】

「有効時点」とは、ここで、あるデータ値がデータ・レコードのフィールドに割り当てられている（よって、このデータ・レコードおよびこのフィールドについて「有効」である）時点を意味するものと理解される。

【0146】

「データ・メモリ」とは、データの記憶のために使用される、記憶媒体もしくは記憶媒体上の記憶領域、またはいくつかの記憶媒体もしくは記憶領域の組み合わせを意味する。データ・メモリがいくつかの記憶媒体または記憶媒体領域を含む場合、これらは互いに接続されて論理データ・メモリを形成することができる。この場合、記憶媒体または記憶媒体領域は、たとえば、ネットワークを介して、またはコンピュータ・システムのバスを介して、互いに動作上接続されてもよい。たとえば、DMSシステムによって管理されるデータ・メモリは、DMSシステムが排他的なアクセスを有するデータに対するデータ・メモリであってもよい。

【0147】

「フィールド」は、ここでは、特定の意味内容を表し、さまざまな特定の実施形態で実現されうるパラメータ（または「属性識別子」）を意味すると理解される。たとえば、フィールドは、色、建物の種類、幅、高さ、年齢、密度などのオブジェクトのプロパティを表すことができる。データ・レコードに格納されたデータの内容に依存して、フィールドは異なりうる。たとえば、マシンを表すデータ・レコードは、通例、人を表すデータ・レコードとは異なるフィールドをもつ。生データのタイプおよび／または使用されるパーサーに依存して、パースされインポートされたもとのデータ値および／またはそれらに割り当てられたマッピングIDは、それらに割り当てられた多様な異なるフィールドを有することができる。たとえば、医療データについて、1つのフィールドは、「糖尿病」、「パーキンソン病」、または「皮膚癌」などのさまざまな特定の具現（「データ値」、または「フィールド値」）が割り当てられうる「診断」の概念を表すことができる。別のフィールドは、「発熱」、「悪寒」、「歯痛」（または、それらのそれぞれのマッピングID）などの具現またはデータ値が割り当てられる「症状」を表すことができる。データ値が異なる諸フィールドに割り当てられることもできる。たとえば、データ値「silver」〔銀〕は、フィールドまたは概念「metal」〔金属〕に割り当てられてもよいが、概念「color」〔色〕または「surname」〔名字〕にも割り当てられてもよい。実施形態に依存して、いくつかの異なるフィールドに割り当てられたデータ値についてのマッピングIDは、フィールドに依存して異なるか、または同一でありうる。

【0148】

「コンピュータ・システム」は、ここでは、単体のまたは分散式のデータ処理システム、特にデジタルデータ処理システムを意味すると理解される。よって、データ処理システムは、たとえば、スタンドアローンコンピュータシステムまたはコンピュータネットワーク、特にクラウドシステムから構成されてもよい。コンピュータ・システムは、たとえば、モバイルデータ処理システム、たとえば、ノートブック、タブレットコンピュータ、または携帯型通信装置、たとえば、スマートフォンとして構成されてもよい。

【0149】

「システム」は、ここでは、データを処理することができる一つまたは複数の要素（たとえば、コンピュータシステム）の全体を意味すると理解される。この目的のために、システムコンポーネントは、データおよび／または制御コマンドを交換する。たとえば、システムは、DMSシステムを備えたコンピュータを含むことができる。任意的に、システムは、DMSシステムに検索要求および／または解析要求を送信する、さらなるコンポーネント、たとえば一つまたは複数のクライアントコンピュータシステムを含んでいてもよい。

【0150】

「データ構造」とは、ここで、データを格納し、編成するために使用されるオブジェクトを意味すると理解される。特に、データが効率的にアクセスされ、管理されるような仕方でデータが配置され、リンクされているため、それは構造である。

【0151】

「統合時点」は、ここでは、時点として理解される。特に、統合時点は、DMSシステムの特定のデータがDMSシステムの他のデータと一体化される時点であってもよい。たとえば、データ値に対する変更および／または論理データ・レコードへのデータ値の割り当てに関する変更を含むAODデータ構造内、ネガティブ・リストおよび／またはポジティブ・リストのデータは、統合の過程でフィールド固有データ値リストに組み込まれ、それにより統合後にはフィールド固有のリストは前記変更も含む。

【図面の簡単な説明】

【0152】

以下、図面を参照して本発明の実施形態を説明する。

【図1】DMSシステムを有するシステムのブロック図を示す。

【図2】検索クエリーを指定するためのGUIのブロック図を示す。

【図3】データベースの種々のデータ構造のブロック図を示す。

【図4】種々のタイプの生データの例を示す。

【図5】生データをフィールド固有データ値リストに変換する例を示す。

【図6】データベースの統合されたバージョンと非統合バージョンを使用する分散システムのブロック図を示す。

【図7】データベース照会を実行する方法のフローチャートを示す。

【図8】データベース・クエリーにおいて未統合のデータ値変更を考慮する方法のフローチャートを示す。

【図9】いくつかのポジティブ・リストおよびネガティブ・リストをもつフィールド固有のデータ構造の例を示す。

【図10】統合前と統合後のデータ構造のブロック図を示す。

【図11】完全なデータ・レコードを効率的に出力するためのデータ構造を示す。

【発明を実施するための形態】

【0153】

図1は、データベース104に対してデータベース照会を実行するためのDMSシステム102を備えたシステム100のブロック図を示す。システム100は、具体的には、一つまたは複数のプロセッサを備えたコンピュータ・システム、たとえばデータベースサーバーであってもよい。

【0154】

たとえば、システムは、図7および8に示される方法を実行するために使用されてもよい。したがって、以下では、システム100および図7の方法を、2つのそれぞれの図を参照して一緒に説明する。

【0155】

たとえば、システムおよび方法は、大量の不均質な構造の生データ112を統合し、それを効率的かつ柔軟に拡張可能な仕方で検索および解析できるようにするために使用されてもよい。

【0156】

たとえば、生データは、異なる内容および構造のXMLファイル、JSONファイル、さまざまなフォーマットのテキスト・ファイル（たとえば、Microsoft Word、OpenOffice、Adobe Acrobat PDFファイル、TXTファイル等）、一つまたは複数の異なるリレーショナル・データベースからの異なるテーブル、メディアデータ、または階層的に編成されたデータ、たとえば、オブジェクトツリーを含むことができる。一部の生データでは、データ・オブジェクト、それらのデータ値、および任意的にはそれらの内容的意味も、たとえば、データベース・テーブル、Excelファイル、および対応するフィールドおよびフィールド識別子を有する他の比較的高度に構造化されたデータにおいて、多かれ少なかれ明示的に識別されてもよい。他の生データ（たとえば、画像データ）では、データ・オブジェクトおよびそのデータ値は、明示的ではなく、暗黙的であってもよい。これは、データ・オブジェクトとそのデータ値が、パース・プロセスの過程でのみ認識され、抽出されることを意味する。

【0157】

いくつかの異なる構文および／または意味内容パーサー118～130を使用して、さまざまな生データをパースすることができる。パーサーは、たとえば、論理データ・レコードに対応するデータ・オブジェクトについてのデータ・レコードIDを動的に生成するときに、このIDが本当に一意的であるか、またはデータ値リストの1つにおいて使用されているデータ・レコードIDによってすでに占有されているかどうかを決定することができるように、パース中にDMSシステムまたはDMSシステムの他のコンポーネントと交換することが好ましい。

【0158】

データ・レコードIDは、生データによってすでに事前定義され、DMSシステムによってデータ・レコードIDとして採用される論理データ・レコードの識別子であってもよい。代替的に、データ・レコードIDは、データ・レコードのインポートまたは生成の間に生成されてもよい。

【0159】

生成され、パースされ、および／または直接インポートされた論理データ・レコードのデータ値は、生データのフィールド識別子によってまたはパーサーによってそれらに割り当てられた意味概念に従って、対応するフィールド固有データ値リストに格納される。

【0160】

いくつかのフィールド固有データ値リストに論理データ・レコードを格納することは、オブジェクト構造を、すなわち、特定のデータ・オブジェクトにどのデータ値または意味概念が存在するか、またはメモリ上のデータ値の物理的な編成が、データ・レコードへの論理的な所属に向けられていないという問題をある程度解決する。

【0161】

論理データ・レコードがデータベース104に正常に格納された後、データベースは、初期には「第1の時点」において一貫した状態にある。第1の時点は、「最新の統合時点」とも呼ばれる。この時点では、データベースは、マッピング・テーブルを含む、フィールド固有データ値リストの形でデータベースに以前に格納された論理データ・レコードの全体を含む。フィールド固有データ値リストの全体は、第1の統合時点におけるデータベースの静的部分101を表す。

【0162】

後刻、602 DMSシステム102は、データ値を変更するための幅広い多様な命令、たとえば、個々のデータ値を削除または変更するための命令、あるいは論理データ・レコード全体を削除または追加するための命令を受け取る。命令は、たとえば、ソフトウェア・プログラムまたはハードウェア・コンポーネントであるか、または自然人のデジタル表現である照会システムから受け取ることができる。

【0163】

これらの受領された変更命令は、フィールド固有データ値リストに対して初期には実行されない。むしろ、これらの命令は、フィールド固有データ値リスト116上の変更を実行することなく、アペンド専用データ構造202に格納される（604）。ここではAODエントリーと呼ばれるアペンド専用データ構造の各エントリーは、少なくとも、データ・レコードのうちの1つの、フィールド識別子データ値ペアのうち、変更命令の1つに従って変更されるべきものを含む。任意的に、DMSシステムは、変更されるデータ値だけでなく、AODエントリーが関係するデータ・レコードの現在のデータ値のすべてを含むような仕方で、AODエントリーを作成し、記憶するように構成されてもよい（いわゆる「完全な」または「完全にロードされた」AODエントリー）。たとえば、DMSシステムは、特定のデータ・レコードに関するある最小数の変更要求を受領したときに、AODエントリーを完全なAODエントリーとして格納するように構成されうる。完全なAODエントリーを記憶するための別の基準は、検索クエリー持続時間の超過であってもよい。よって、AODエントリーの数は参照によって。

【0164】

データベースが最新の統合時点の後にデータ値を変更するための一つまたは複数の命令を受領するデータ・レコードのそれぞれについて、DMSシステム102は、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうち最新のもののアドレス206、208を、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブル226に格納する。このステップの詳細およびAODエントリーの性質は、たとえば図3にさらに示される。アドレス割り当てテーブル内のリンクは、各データ・レコードについて、そのデータ・レコードに対する最新の変更を含むAODエントリーのうちの1つのAODエントリーのアドレスが常に記憶されるように、自動的に更新される。したがって、アペンド専用構造は、データベースの静的部分101とまだ統合されていない変更および補足も含む。アペンド専用データ構造、少なくとも最新の統合時点でのそのエントリー、ならびにネガティブ・リストおよびポジティブ・リストなどの後述するいくつかの他の任意的なデータ構造は、データベース104の動的部分103に属する。

【0165】

次いで、DMSシステムは、データベース照会を実行する（610）。たとえば、データベース照会は、複雑なデータ解析の過程で、または照会システムからの検索クエリーの受信に応答して実行されてもよい。

【0166】

データベース・クエリーは、データ・レコードの各フィールドを参照する一つまたは複数のデータ値（検索値とも呼ばれる）を含む。

【0167】

データベース照会は、検索値のそれぞれについて、その検索値のフィールドに対応するフィールド固有データ値リストを検索値で検索して、一つまたは複数のフィールド固有検索値との一致に基づいてその内容の全部または一部が返されるべきデータ・レコード214のIDを識別する第1ステップi）612を含む。たとえば、検索値は、First name=Peter〔ファーストネーム＝ペーター〕およびCity=Berlin〔都市＝ベルリン〕を含むことができる。好ましくは、検索値はマッピングIDであり、たとえば、照会システムによって入力された一次検索値をマッピング・テーブルと照合して、その一次検索値に割り当てられたマッピングIDを確認することによって確認することができる。たとえば、「Peter」はマッピングID 2392を有することができ、「Berlin」はマッピングID 68672を有することができる。よって、検索は、たとえば、検索値First name=2392およびCity=68672を含む。ファーストネーム・データ値リストにおいて2392を検索することは、「ファーストネーム・ヒット」データ・レコードIDの集合をもたらし、都市データ値リストにおいて68672を検索することは、「都市ヒット」データ・レコードIDの集合をもたらし、ファーストネーム・ヒット・データ・レコードIDと都市ヒット・データ・レコードIDの共通集合が、ステップi）で確認されたデータ・レコードIDの集合を表すことができる。たとえば、ステップi）において、いずれもファーストネームMichaelおよびベルリン内の住所をもつ人物を表す、2つのデータ・レコードID 5578および5907が確認されることがある。

【0168】

次のステップii）614は、アドレス割り当てテーブル226にアクセスして、i）で識別されたデータ・レコードIDの1つに割り当てられたAODエントリーのアドレスを識別することである。たとえば、DMSシステムは、新しい論理データ・レコードのIDを選択するように構成され、これらのIDは、アドレス割り当てテーブル内のその論理データ・レコードに一意的に関連付けられた行のメモリ・アドレスを、明示的に（たとえば、メモリ・アドレスとして）または暗黙的に（たとえば、行メモリ・サイズを乗算することによって、ベース・アドレス（たとえば、ファイル先頭）に対する行のメモリ・アドレスを与える、アドレス割り当てテーブル内の行の連続番号として）エンコードするようにすることができる。アドレス割り当てテーブルは、ステップi）で求めたデータ・レコードIDから、これらのIDに一意的に割り当てられたアドレス割り当てテーブル内の行のメモリ・アドレスを求め、これらのメモリ・アドレスを検索プロセスなしに直接アクセスのために使用することによって、アクセスされうる。

【0169】

たとえば、d）で求められたデータ・レコードIDは、個人データ・レコードのIDを含むことができ、ここで、IDは、たとえば「5578」であってもよく、ここで、この値は、たとえば、アドレス割り当てテーブル内でこのデータ・レコードに一意的に割り当てられた行のメモリ・アドレスでもあってもよい。

【0170】

よって、人物5578の完全な個人データ・レコードを出力するために、ステップi）で使用されるデータベース照会をいかなる仕方でも修正する必要はない。i）で確認されたデータ・レコードに一意的に割り当てられたアドレス割り当てテーブル行を最初に識別し、これらの行を評価するために、ステップi）で得られた返されるべきデータ・レコードのデータ・レコードIDが、アドレス割り当てテーブル内のキーとして（および、いくつかの実装変形では、アドレス割り当てテーブル行のメモリ・アドレスとして）使用されることで十分である。確認されたアドレス割り当てテーブルの行は、その行が一意的に割り当てられたデータ・レコードに対する最新の変更を含むAODエントリーのアドレスをそれぞれ含む。DMSシステムは、このAODエントリーに従って変更された、少なくともこの人物のプロパティ（たとえば、電話番号）を見つけるために、このAODエントリー・アドレスを直接探す必要があるだけである。

【0171】

次のステップiii）では、DMSシステムは、AODエントリーの識別されたアドレスにアクセスする（616）。このAODエントリーがフル（または「完全」な）AODエントリーである場合、すなわち、その人の現在有効なデータ値をすべて含むエントリーである場合、フルAODエントリーにおいて指定されたデータ値は、すべての個人属性を含む個人5578のデータ・レコードを出力するために使用されうる。前記AODエントリーがすべての現在のデータ値は含まない場合、それは好ましくは、同じ人物5578に関連し、たとえば住所、電話番号、職場等に関連する他の変更を含む、次の、より古いAODエントリーのためのアドレスを少なくとも含む。この次の、より古いAODエントリーが完全なAODエントリーである場合、人物5578についてのアペンド専用データ構造の検索は終了されてもよい。もしそうでなければ、このAODエントリーに含まれるアドレスは、次に近くて古いAODエントリーに続き、論理個人レコードのすべてのフィールドについての対応するデータ値が存在するまで、必要ならこのステップが繰り返される。

【0172】

ステップiv）618では、DMSシステムは、これらの識別されたAODエントリーに含まれる変更情報を使用して、フィールド識別子‐データ値ペアをステップi）で確認されたデータ・レコードIDに追加し、それらを出力する。

【0173】

このようにして、ステップi）でIDが確認されたすべてのデータ・レコードのフィールド固有データ値、および任意的には上位または下位のデータ・レコードおよび／またはこれらのデータ・レコードの履歴バージョンが確認されうる。

【0174】

検索クエリーは、データ・レコードのデータ値、および関係によってこれらのデータ・レコードに接続されたさらなるデータ・レコードのデータ値を非常に効率的に確認することができ、検索は実質的にはデータ値リストのみに基づき、出力されるべき結果データ・レコードの完了は実質的にはジャンプ・アドレスに基づく。これにより、検索のパフォーマンスとリソース効率が向上する。データ値リストは、好ましくは、数値、特にマッピングIDのソートされた、冗長性のないリストであり、それにより、すべてのステップi～ivが高パフォーマンスな仕方で実行されうる。

【0175】

いくつかの例によれば、DMSシステムは、データベースの動的部分103を静的部分と規則的または不規則な間隔で統合するように構成されてもよい。これは、動的部分にキャッシュされたデータ・レコード変更が、今やフィールド固有データ値リストに格納されるようになることを意味する。たとえば、統合は、統合モジュール105によって実行されてもよく、データベース照会は別のモジュール106によって実行されてもよい。たとえば、モジュール106は、一つまたは複数のクライアントコンピュータからネットワークインターフェースを介して、または、ローカルに作業するユーザーから直接GUIを介して、検索クエリーを受領するように構成されてもよい。追加的または代替的に、モジュール106は、複数のフィールド固有データ値リスト、および任意的にはネガティブ・リストおよび／またはポジティブ・リストに対する集合演算に基づく複数の複雑な解析機能をも含んでいてもよい。

【0176】

よって、静的部分は、ある統合時点におけるデータベースを表し、この時点で利用可能なデータについて一貫した評価および解析を計算するために使用されうる。この固定された時点からのすべての変更は、初期にはデータベースの動的部分103において管理されるだけであり、この動的部分は、特に、まだ永続化されていないアペンド専用データ構造の部分、ならびにポジティブ・リストおよびネガティブ・リストを含む。したがって、アペンド専用データ構造は、変更命令およびすでに統合された、すなわちフィールド固有リストにおいて永続化されたAODエントリーを含む静的部分と、動的部分からなる。動的部分は、最新の統合時点においてまだ統合（データ値リストにおいて永続化）されていない変更を含む。統合のたびに、統合および非統合AODエントリーの境界または分割がシフトする。各境界は統合時点に対応する。

【0177】

任意の時点において、データベースのこの動的成分は、統合され、すなわち、静的成分101に組み込まれ、新しい空の動的成分によって置き換えられうる。このようにして、前の動的成分は静的になり、バックグラウンドで前の静的成分とマージされて、新しい静的データベース成分を形成することができる。これが終了すると、前の静的および動的成分は保存および／または削除されうる。

【0178】

統合モジュール105は、たとえば、APIを提供し、それを介して、ユーザーおよび外部プログラムは、検索するときに、検索の基礎として、たとえば静的成分のみまたは両方の成分を使用する、または必要であれば動的成分のみを使用するオプションを有する。

【0179】

実装変形の大きな利点は、進行中の動作中に更新可能であることにある。というのも、最適化可能性を含め、進行中の中断されない動作中に再編成を保証するよう、すべての成分が凍結されうるためである。データベースの静的および動的成分の並列操作が可能であり、データベースの更新も可能である。

【0180】

図2は、検索クエリーを指定するためのGUI 154のブロック図を示す。たとえば、GUIは、いくつかの入力フィールド、たとえば、一つまたは複数の検索値およびそれらに割り当てられたフィールドを指定するための一つまたは複数の入力フィールド156、ならびに、実際の結果データ・レコードに加えて、結果データ・レコードとの論理的および／または時間的関係を有するさらなるデータ・レコードが返されるべきかどうかをユーザーが指定することを許容するさらなるフィールド158、160を含むことができる。たとえば、ユーザーは、ステップi）においてフィールド156に入力された検索語との一致に基づいて確認された結果データ・レコードに加えて、これらの結果データ・レコードの下位または上位のデータ・レコード、または結果データ・レコードの前のバージョンを表すデータ・レコードも出力されるべきかを指定することができる。他の例では、これらのフィールド158、160に加えて、またはこれらのフィールドの代替として、GUIは、ユーザーが検索を特定の有効時間または時間期間に制限できるように、時間または時間期間を入力するためのフィールドをも含んでいてもよい。

【0181】

いくつかの例では、GUIは、上位および／または下位のデータ・レコードが確認され、出力される逐次反復回数（データ・レコード階層）が指定されることを許容する入力フィールド159を含むことができる。

【0182】

GUIに加えて、またはGUIの代替として、DMSシステムは、他のインターフェース、特にAPI 152を提供することもでき、それを介して、他のソフトウェア・プログラムが、検索クエリーおよびここに記載される追加的なパラメータ（上位または下位のデータ・レコードが出力されるべきかどうか、以前のバージョンが出力されるべきかどうか、および／または検索が有効時間期間に制限されるべきかどうかを決定する）を入力することができる。

【0183】

第1のステップi）では、フィールド固有の検索値とフィールド固有データ値リストに基づいてデータ・レコードIDの集合が確認され、これは中間結果162とみなされてもよい。さらなるステップii～iv）では、これらのデータ・レコードIDに割り当てられた現在のフィールド値が確認され、フィールド固有データ値によって補足された完全なデータ・レコード164が最終結果として出力される。出力データ・レコードのデータ値は、特に、マッピングID、またはマッピング・テーブルにおいてマッピングIDに割り当てられた生データのもとのデータ値であってもよい。

【0184】

図3は、データベース104のさまざまなデータ構造のブロック図を示す。

【0185】

諸実施形態によるデータ格納にために使用されるデータ構造は、実際のデータ格納のために使用されるデータ構造に加えてのインデックスが存在しない、および／またはインデックスが必要とされない、もしくは使用されないという点で、他のデータベースと異なる。このデータ管理構造により、大量のデータがある場合でも、任意の組み合わせですべてのクエリー、選択、評価が可能になる。

【0186】

生データをインポートするとき、キーと値のペア（キーは、典型的にはパラメータまたは属性を表すフィールド）は、無次元のデータ・レコードID（RID）に変換される。データ・レコード内で生起するすべてのキー／値ペアは、同じRIDを持つ。

【0187】

このように、キー／値の任意の組み合わせに対するデータベース・クエリーは、最終的にはRIDの組み合わせを与え、その共通集合、差集合、対称差集合、および／または和集合が最終的に結果を与える。

【0188】

データ構造は、アペンド専用データ構造202、たとえばアペンド専用ファイルを含む。論理データ・レコードに対するすべての変更は、変更要求がDMSシステムによって受領された順序でこれに書き込まれ、もはや変更できなくなる。たとえば、変更は、データ・レコードの個々のデータ値のみから構成されてもよく、たとえば、データ・レコードへの新しいまたは追加的なフィールド‐データ値ペアの補足だけでなく、フィールド‐データ値ペアの削除またはあるデータ値の別のデータ値による置換も含むことができる。変更は、論理データ・レコード全体に関連してもよく、たとえば、データ・レコード全体の削除または初期記憶を提供してもよい。

【0189】

アペンド専用データ構造内の各エントリーは、ブロック202内の行として表される。たとえば、各AODエントリーは、一つまたは複数の識別子（フラグ）を含むことができる。フラグは、たとえば、ビット値の形であってもよく、たとえば、データ・レコードについて上位または下位の値が存在するかどうか、AODエントリーが完全なAODエントリーであるか否か、データ・レコードの以前のバージョンが存在するかどうか等を含みうる。

【0190】

破線206は、第1の時点（最新の統合時点）を示す。このラインより上のすべてのAODエントリー222は、最新の統合時点においてすでに統合されており、このラインより下のすべてのAODエントリー224は、まだ統合されていない。矢印204は、データ構造の最初のAODエントリーを表す。たとえば、そのアドレスはベース・アドレスとして機能し、他のすべてのAODエントリーのアドレスはこのベース・アドレスとオフセットの組み合わせである。矢印208は、データ構造202の終点を示し、そこに、受領された変更要求に従って、さらなるAODエントリーが連続的にアペンドされる。

【0191】

データ構造は、アドレス割り当てテーブル226をさらに含むことができる。これにより、データベース104内の各論理データ・レコードにAODエントリーのアドレスが割り当てられる。このAODエントリーは、その1つのデータ・レコードに対する変更を指定する、アペンド専用構造内の最新のAODエントリーである。たとえば、テーブル226において、データ・レコードID（"RID"）=35を有するデータ・レコードは、現在、フィールドF3がデータ値「b」を有することを述べるAODエントリーを割り当てられている（矢印209参照）。しかしながら、以前に、RID 35をもつデータ・レコードは、異なるデータ値「a」が割り当てられていた。この以前の変更は、上から3番目のAODエントリーに対応する。この以前の時点において、アドレス割り当てテーブルにおいて、RID 35は、破線矢印207によって示されるように、上から3番目のAODエントリーのアドレスにリンクされていた。しかしながら、このアドレスは、その後、矢印209によって参照されるAODエントリーのアドレスによって置き換えられている。しかしながら、このAODエントリー209は、このAODエントリーよりさらに前に書き込まれた最新のAODエントリー207のアドレスを含み、これは同じデータ・レコードRID=35を参照する。よって、DMSシステムは、データ・レコード35のすべてのフィールドについてのすべての現在のデータ値を得るために、同じデータ・レコードの次に最も新しいAODエントリーまで、AODエントリー内の諸アドレスを単に追跡することができる。

【0192】

図3および他の図において、人間が理解しやすいデータ値が、例示目的のために使用されている。しかしながら、好ましくは、論理データ・レコードのフィールド固有データ値は、マッピング・テーブル210において、生データから得られたデータ・レコードおよび／または初期に入力されたデータ・レコードに一意的に割り当てられた数値である。これらの数値は、マッピングIDとも呼ばれ、好ましくは、フィールド・ベースのリストに格納され、検索中に検索値と照合されるデータ・レコードとして使用される。マッピング・テーブル210は、もとのデータ値（ここでは単語）の、マッピングIDへの割り当てを概略的に示す。

【0193】

マッピング・テーブル210は、たとえば、マッピングID（MID）によって区別されるべきすべてのデータ値を表す目的を果たす。いくつかの導入例によれば、各データ値は、フィールド固有リスト内でそのMIDを介してのみ格納されるので、そのコンテキスト内で生起するすべてのMIDが、各FIDについて格納される。データ値は、たとえば、文字、テキスト、整数、浮動小数点、日付／タイムスタンプ、UUID値、バイナリ値などのフィールドまたはデータ・タイプによって分類されてもよい。各フィールドまたは各データ・タイプについて、たとえば、あたかも関連するもとのデータ値がソートされていたかのようにマッピング・テーブル210内のMIDが同じ順序で格納されるように、MIDがソートされてもよい。これにより、まず内容自体をロードする必要なく、フィールド固有データ値リストの内容を、そこで生起するMIDを使用してソートすることが可能になる。つまり、Anton‐Bertram‐Christoph‐Doris‐Emilというファーストネーム・リストへのMIDの割り当ては、AntonのMIDの数値がマッピング・テーブルのソート順において他のすべてのファーストネームのMIDよりも前になり、Bertramの数値が2番目になるというようになる。

【0194】

データ構造は、それぞれネガティブ・リスト220およびポジティブ・リスト218にリンクされて格納される、ソートされた検索可能なデータ値を含むフィールド固有のデータ構造216をさらに含むことができる。これらは、まだ統合され、データ値リスト116に格納されていない変更も含めるために使用されてもよい。

【0195】

たとえば、フィールド関連の検索値を有する検索クエリーを受領した後、DMSシステムは、まず、マッピング・テーブル210を使用して、検索値をマッピングIDに変換することができる。次いで、このマッピングIDが、検索値が割り当てられているフィールドを表すフィールド固有データ値リスト116を検索するために使用される。任意的に、このステップi）では、まだ統合されていない変更が考慮されるように、データ値リスト116に基づいて得られたデータ・レコードIDをさらに拡張および／または縮小するために、ネガティブ・リストおよびポジティブ・リストの形で格納されたまだ統合されていない変更を含む、データ値またはマッピングIDのソートされた配列216も検索されてもよい。この第1の検索ステップi）でこのようにして得られたデータ・レコードIDは、中間結果162として使用され、これは、後続のステップii～iv）において、さらなるデータで充実される。さらなるデータは、i）で確認されたデータ・レコードのデータ値を含んでいてもよく、任意的にはi）で確認されたデータ・レコードの上位または下位にあるさらなるデータ・レコードをも含んでいてもよい。充実されたデータは、結果164として返される。

【0196】

以下では、図3のデータ構造のうちのいくつかのデータ構造のいくつかの具体例が、例示的な実装変形に従って説明される。

【0197】

論理データ・レコードは、それぞれ一つまたは複数のフィールド‐データ値ペアで構成され、データ値はマッピングIDである。論理データ・レコードは、任意の数のこのようなペアで構成されうる。アドレス割り当てテーブル226は、対応する変更命令が受領された順序でさまざまな論理データ・シーケンスの個々のフィールドのデータ値を格納する、アペンド専用データ構造202内のAODエントリーを参照する。新しいAODエントリーは、一般に、データ構造202の末尾に書き込まれ、ここで、新しいAODエントリーを生成する過程で、DMSは、新しいデータ・レコードの、前のデータ・レコードからの差を確認し、新しいAODエントリーにおいて変更を特定し、格納する。新しいAODエントリーは、前の内容を参照するジャンプ・アドレス（「ポインタ」）を含む。特に、ポインタは、データ構造202内の最初のAODエントリーから開始して計算されるファイル・オフセットを指定することができる。一度書き込まれると、AODエントリーは二度と変更されず、それに追加されるだけである。いくつかの実装変形によれば、各論理データ・レコードにおいて、同じフィールドが論理データ・レコード内に複数回出現することがあり、異なるマッピングIDを割り当てられることがあるので、各置換されたフィールド‐データ値ペアは好ましくはネガティブ・リストにも格納され、一方、現在のフィールド‐データ値ペアはポジティブ・リストに書き込まれる。フィールド‐データ値ペアがデータ・レコードに初めて追加されるときは、新しいフィールド‐データ値ペアはポジティブ・リストに追加される。削除の場合、フィールド‐データ値ペアはネガティブ・リストに追加される。ポジティブ・リストおよびネガティブ・リストは、たとえば、図9に関連して、より詳細に記載される。多くの編集の場合にシステム・ローディングを最適化するために、本方法の諸実施形態によれば、各AODエントリーは、現在のAODエントリーが先行するもののローディングを必要とするか（「不完全なAODエントリー」）、または必要としないか（「完全な」または「完全にロードされた」AODエントリー）を指定する識別子（フラグ）を含む。ただし、すべての変更要求の履歴は引き続き利用可能であり、たとえば改竄できない仕方でブロックチェーンとして格納されてもよい。

【0198】

追加的にまたは代替的に、AODエントリーは、他の識別子、たとえば、AODエントリーが上位および／または下位のデータ・レコードがあるデータ・レコードを参照するかどうかを指定する識別子（いわゆる「リピート・グループ」に関連する識別子）を含んでいてもよい。好ましくは、論理データ・レコードの少なくともいくつかは、対応する参照フィールド、たとえば、「is-superordinate-to」および／または「is-subordinate-to」フィールドを含む。このフィールドは、そのフィールドをもつ関連データ・レコードの上位または下位にあるデータ・レコードのIDを含む。エンジンについていくつかのコンポーネントが入力される場合、コンポーネントは、たとえば、論理データ・レコードとして、その物品番号および技術的特性と一緒に記憶される。ここで、「is-subordinate-to」フィールド内のコンポーネント・データ・レコードは、エンジンのデータ・レコードIDを含む。エンジン・データ・レコードが書き込まれた後にコンポーネント・エントリーが作成された場合、エンジンの論理データ・レコードへの変更は、「is-subordinate-to」=TRUE識別子のみで構成される補足的なAODエントリーによって書き込まれる。これは、たとえば、この識別子について1のビット値を格納することによって行うことができる。ここで、任意の数の新しいコンポーネント・データ・レコードが生成されてもよく、対応するAODエントリーが書き込まれてもよい。その共通の特徴は、フィールドデータ値ペア「is-subordinate-to」‐「engine MF-3000」である。データ出力中に、拡張されたまたは再帰的な出力が所望される場合、特定のコンポーネントが出力されうるだけでなく、それが組み込まれているかまたは組み込まれうるエンジン・タイプに関する情報も出力されうる。このプロセスは再帰的に適用されうる。というのも、各エンジンについて、このエンジンを含む上位の車両が存在しうるからである。したがって、データの構造をあらかじめ知ることなく、任意にネストされた内容を書き込んで出力することができる。

【0199】

ある実装例では、アペンド専用データ構造は、論理データ・レコードの変更に関連する完全な時間履歴の記憶および再構築もサポートする。下記の例では、フィールドID（FID）=2が履歴情報の連結のために予約されている。たとえば、引っ越しによって人の住所が変わる場合、前の住所は間違っていないが、その時間的な権威（「有効性」）は失効している。したがって、そのフィールドに関連する新しいデータ値（新しいストリート、番地、郵便番号、町）は新しい論理データ・レコードDS_neuに移転され、そこでは、前のデータ・レコードのID（DS_alt、よって、新しいデータ・レコードの古くなったバージョンを表すデータ・レコードのID）がFId=2において入力される。古いデータ・レコードDS_altは、AODエントリーの形で2つのタイムスタンプ（自／至）とともに格納される。論理データ・レコードとそれに対応するAODエントリーのこの有効時間期間は、そのデータが有効であった有効期間から生じる。よって、この時間期間の終わりは、現在の（またはより最新の）データ・レコードおよびその値のうちの少なくとも1つの有効性の開始も自動的に決定する。イベントのデータ・レコード履歴のためのAODエントリー（「履歴エントリー」）の有効性の開始は、以前の有効性から生じるか、または手動で設定されてもよい。もとのデータ値に基づく次の例は、以前のバージョンのデータ・レコードおよび階層的にリンクされたデータ・レコードを参照するAODエントリーを示している。
Data record〔データ・レコード〕:
Company〔会社〕="Cortex Innovations"
is-employer-for〔…の雇用主である〕="Employee A, 1.2.1990 ‐ Employee B, 7.12.1988 ‐ Employee C, 1.5.2001
Offices〔オフィス〕="Isernhagen, Tischlerstr. 1a, 30916, Lower Saxony - Bendeleben 地域再編まで: Kalkuferstr. 7, 99707 Bendeleben - Bendeleben 地域再編後: Kaluferstr. 11, 99703 Kyfhaeuserland
。

【0200】

これは、アペンド専用ファイルにおける以下の表現に帰結する。ここで、FID=1を有するフィールドは、データ・レコードの先行バージョンへの参照を含み、ここで、RIDは、データ・レコードの識別子IDであり、識別子has_nR（"has nested records"〔ネストされたレコードを有する〕）は、AODエントリーが関係するデータ・レコードに階層的に関係するさらなるデータ・レコードが存在するかどうかを示す。
RId:4711: Company Cortex Innovations Flag〔フラグ〕:has_nR
RId=4712, FId:1=4711 FId:12=First name-employee-A FId:13=Last name-employee-A, FId:4:1.2.1990
RId=4713, FId:1=4711 FId:12=First name-employee-B FId:13=Last name-employee-B, FId:4:7.12.1988
RId:4714, FId:1=4711, FId:12=First name-employee-C, FId:13=Last name-employee-C, 4:1.5.2001
…
RId:9876654, FId:1=4711, 2: First name-employee-D, 3: First name-last name-D, 4:8.6.54
…
RId:123456789 FId:1=4711, FId:47=Isernhagen, FId:46=30916, FId:50=Tischlerstr. 1a, FId:55=Lower Saxony
RId:1234568 FId:1=4711, FId:47=Kyfhaeuserland, FId:46=99703, FId:50=Kalkuferstr. 11, FId:55=Thuringia
…
RId=999991234 FId:2=1234568, FId:47=Bendeleben,FId: FId:46=99706, FId:50=Kalkuferstr. 7, T1=1, T2=30.05.2017
。

【0201】

この例は、データ・レコードRId=999991234を参照するAODエントリーが、このデータ・レコードRId=999991234のIDだけでなく、FID=2を有するフィールドにある同じデータ・レコードの先行バージョンのRID、つまり1234568も含んでいることを示している。DMSシステムは、完全な履歴、またはCortex社についてのデータ・レコードの以前に有効なバージョンのみが出力される場合、アドレス割り当てテーブルを検索して、以前のバージョン参照フィールド（FID=2）の内容、すなわち値999991234を求めてもよい。それはこれにより、該前のバージョンの最後の変更を含むAODエントリーのアドレスに送信され、それによりこのAODエントリーに含まれるデータ、および該当する場合には、このAODエントリー内のジャンプ・アドレスを介して到達されうるさらなる履歴データが出力されうる。

【0202】

図4は、DMSシステムによってもとのデータ値（この場合はユニコード文字のストリング）に分解され、マッピングIDにマップされるフィールドに割り当てられる、種々のタイプの生データの例を示している。マッピングIDは論理データ・レコードのデータ値として使用される。これらの論理データ・レコードは、フィールド固有データ値リストの形で格納される。これは、実際にはフィールド固有のマッピングIDリストである。以下では、例示の目的で、もともと得られたデータ値を論理データ・レコードのデータ値として記述するが、好ましくは、論理データ・レコードおよびフィールド固有データ値リストのデータ値は、これらのもとのデータ値の数値マッピングIDである。

【0203】

たとえば、データ構造302、304、306は、JSONフォーマット（スペースの理由から、ここではタブ区切りテキスト・ファイルとして示される）での、ある製造業者のエンジンの製品データシートである。たとえば、生データから得られた論理データ・レコードのデータベースへのインポートは、3つのJSONファイル302、304、306のそれぞれが、それぞれデータ・レコードIDを有する別個のデータ・オブジェクトまたは別個の論理データ・レコードとして解釈されるように行うことができる。各データ・オブジェクトは、フィールド「Power」〔パワー〕についての特定のデータ値、フィールド「Torque」〔トルク〕についての特定のデータ値など、いくつかのフィールド‐データ値ペアを含む。

【0204】

下に示されるデータ構造は、塗料ディーラーの塗料のさまざまなプロパティの仕様を含むExcelテーブルである。各行308～313は、ちょうど1つのデータオブジェクト（データ・レコード）を含む。パース・プロセスの間、各認識されたデータ・オブジェクトは、たとえば、データ・レコードIDとしてのこのExcelテーブルの識別子と組み合わせた行番号を割り当てられてもよい。

【0205】

生データの一部は、テキストデータ、たとえばテキスト・ファイル314～318の形で提供されてもよい。たとえば、純粋な構文解析パーサーが、このテキストを個々の単語（それぞれがデータ値として作用する）に分解するために使用できる。たとえば、構文解析パーサーは、自然言語テキストを、（必要な場合にはいくつかのストップワードを除いて）データ値として作用する単語に分解するトークン化器であってもよい。この場合、単語／データ値は、たとえば、NLP技術を通じてそれらの内容的意味を自動的に認識することによって、たとえば、インポート中に自動的にフィールドに割り当てられてもよい。

【0206】

生データの別の部分は、たとえば、商業登記抜粋320～324の形で提供されてもよい。これらは、キー値フィールドとフリーテキストの混合を含みうる。

【0207】

生データは種々のソースに由来するが、部分的は重複する内容をもち（「Gelb-AG」）、部分的には曖昧なデータ値（「silver」〔シルバー〕）をもつ。それにもかかわらず、諸実施形態は、意味的あいまいさを解決しながら、これらすべてのデータの効率的な統合および処理を許容する。それは、たとえば、インポートの間に生データのコンテキストを考慮に入れ、データ値「silver」をコンテキストに依存して姓または金属として解釈し、そのマッピングIDを関連付けられたデータ・レコードIDと一緒にファーストネーム・データ値リストまたは金属データ値リストのいずれかに格納するか、または、このマッピングIDがすでにそこに存在する場合には、それに応じてこのマッピングIDに割り当てられたデータ・レコードIDの集合を拡張することによる。

【0208】

図5は、図4に示した生データの一部をフィールド固有データ値リストに変換する例を示している。ここでも、本方法の好ましい実装では、もとのデータ値の数値マッピングIDが実際にはリストに記憶されるが、例示の目的で、もとのデータ値を有するリストがここに示されている。

【0209】

冗長性のないリスト402、404、406、408、412、414、416に示されているデータ値もまた、単にセレクションであり、典型的には、リストはこれよりかなり長い。

【0210】

ここに示された例に従ってDMSシステムによって生成され管理されるすべてのフィールド特定データ値リストは、冗長性がなく、すなわち、それらは各データ値を一度だけ含む。好ましくは、データ値もソートされ、それにより、検索語のソート順とリストのすでに検索されたデータ値とに基づいて、リスト内の更なる検索がヒットをもたらすことが排除される場合に、リスト内の逐次的な検索が中止されうる。

【0211】

たとえば、論理データ・レコードは次のフィールドを含む。色、製造業者、（該製造業者の）塗料ID、姓、および金属のタイプ。これらのフィールドは、それぞれフィールド固有データ値リスト402、404、406、408、および412によって表される。

【0212】

同じデータ値「Gelb-AG」が、コンテキストに依存して種々のフィールドに割り当てられることが可能である。たとえば、データ値「Silver」は、いくつかの論理データ・レコードにおいては色であり、色識別子として値「Silver」を含むデータ・レコードのデータ・レコードIDにリンクされたリスト402に格納される。データ値「Silver」は、他の論理データ・レコードにおいてはフィールド「Metal type」〔金属タイプ〕に割り当てられてもよく、金属タイプとして値「Silver」を含むデータ・レコードのデータ・レコードIDにリンクされたリスト412に格納される。

【0213】

リストにおけるデータ値の格納は、データ値が割り当てられているそれぞれのフィールドに依存するが、論理データ・レコードへの所属とは無関係である。このように、生データのデータ・オブジェクトのもとの構造は、リストが生成されたときに構造の点では完全に解消された。なぜなら、データ値の、データ・レコードへの割り当ては、データ・レコードIDの形でのみ存在し、再構成可能だからである。

【0214】

好ましくは、データ構造は、異なるデータ・レコード間の「is-subordinate-to」関係タイプを表す冗長性のないデータ値リスト414、および／または異なるデータ・レコード間の「is-superordinate-to」関係タイプを表す冗長性のないデータ値リスト416も含む。

【0215】

たとえば、リスト414は、ソートのおかげで迅速に検索されうる個々のデータ・レコードIDの非冗長ソート済みリストを含む。これらのデータ・レコードIDは、「Key ID」〔キーID〕列に格納される。これらの「Key ID」のそれぞれは、この「Key ID」の上位のデータ・レコードの一つまたは複数のデータ・レコードIDにリンクされて格納される。たとえば、リスト414のキーID列内のIDは、エンジンなどの一つまたは複数のより大きなコンポーネントに組み込むことができる特定のコンポーネントを表すことができる。たとえば、データ・レコードID（RID）304を有する構成要素は、エンジン・タイプMF-3000、MF-3020、およびMF-6000に組み込まれてもよい。したがって、これらのエンジン・タイプは、ある意味でこれらのコンポーネントよりも上位である。

【0216】

たとえば、DMSシステムは、エンジン・コンポーネントの検索要求を受領し、ステップi）で、まず、これらのコンポーネントのデータ・レコードIDのみを確認する。上位コンポーネントも出力されることを要求が指定している場合、これらのコンポーネントのデータ・レコードIDを有するリスト414が検索されて、エンジン・タイプ（または他の上位コンポーネント）の一つまたは複数のデータ・レコードIDを確認し、属性（データ値）をもつこれらの上位エンジンまたはコンポーネントのデータ・レコードIDを完成させ、出力する。

【0217】

同様に、要求内で、または、たとえば、DMSシステムの構成ファイル内で、クエリーの検索値に対するヒットに加えて、これらのヒットの下位のデータ・レコードも返されるように指定されてもよい。よって、たとえば、一つまたは複数のエンジン・タイプを確認するデータベース・クエリーを最初に処理し、ここで、たとえばこれらのエンジン・タイプのコンポーネントを表すのでこれらのエンジン・タイプの下位であるデータ・レコードのIDも、データ値リスト416を解析することによって自動的に確認されることも可能である。

【0218】

データ・レコードの上位または下位に関する関係を表す非冗長データ値リスト414、416を提供することによって、複雑で、したがって通例は非常に遅いデータベース・クエリーの指定を必要とすることなく、考えられるあらゆる検索クエリーについての結果の大量のコンテキスト情報を効率的に出力することが可能である。最後の414、416における検索の逐次反復により、3月2日の上位および／または下位のデータ・レコードまたはさらなるレベルも出力することが可能である。よって、たとえば、非常に複雑な機械の場合、各コンポーネントについて、非常に効率的に、個々のねじに至るまでのそれらのサブコンポーネントの全体が確認され、出力されうる。

【0219】

よって、階層関係によってリンクされたデータ・レコードのためのきわめて効率的な検索および総合機能が提供され、これは、RAMおよび／または計算能力がほとんどないデータ処理装置によっても使用されうる。

【0220】

図6は、データベースの統合バージョンおよび非統合バージョンを使用するための分散システム500のブロック図を示す。

【0221】

たとえば、システム500は、提供側コンピュータ・システム100と、一つまたは複数の受領側コンピュータ・システム506、508とを含むことができる。受領側コンピュータ・システムは、データベース104内に非冗長なフィールド固有データ値リストの形で現在の論理データ・レコードを格納し、保持するために使用される。たとえば、いくつかの実装変形によれば、提供側コンピュータ・システム100は、DMSシステム102を含んでいてもよく、該DMSシステム102は、APIを介して検索要求を受領し処理することができ、および／または、APIを介して、生データがそこからリスト形式の論理データ・レコードとして受領され、処理され、記憶されるさまざまなソース・システム502、504に結合されることができる。すでに説明したように、データベースは、たとえば、特定の時点（統合時点）における静的データベース部分101を含むことができる。これは、特に、フィールド固有の非冗長データ値リストの形でそのフィールド固有データ値が分散式に格納される、複数の論理データ・レコードを含む。既存の、およびすでに統合されたデータ値および／またはデータ・レコードに対する変更は、初期にはこれらのフィールド固有データ値リストには格納されず、アペンド専用データ構造内のAODエントリーの形式で、好ましくはネガティブおよび／またはポジティブ・リストの形で格納される。アペンド専用データ構造のまだ統合されていない部分は、ネガティブ・リストおよびポジティブ・リストと同様に、データベース104の動的部分103を表す。好ましくは、提供側コンピュータ・システム500のみが、たとえば、パーサー118～130を介して、または生データから論理データ・レコードを抽出することができる他のプログラム・モジュール110を介して、新しいデータ・レコードをインポートするための適切なプログラムを含む。これにより、継続的に修正および更新されるデータベース・インスタンスは1つだけであり、同じデータベースの異なるインスタンスが互いに独立して修正されることがなく、よって一貫しなくなりうることが保証される。

【0222】

しかしながら、たとえば、ネットワーク接続の利用可能性にかかわらず、受領側システムもデータベース・コンテンツにアクセスできることを保証するために、データベース・コンテンツを一つまたは複数の受領側システムのローカル・メモリに物理的に複製することが必要な場合がある。この目的のためには、データベースの静的部分101のみを受領側コンピュータ・システム506に転送することで十分であることが多い。たとえば、受領側コンピュータ・システムが必ずしも常にデータベース104の最新バージョンを有する必要がなく、受領側コンピュータ・システム506上のローカル・コピーがそれ自体の中で一貫していれば十分である場合がそうである。

【0223】

システム500のいくつかの例によれば、静的部分が提供側コンピュータ・システム100から受領側コンピュータ・システムに自動的に複製されるだけでなく、動的部分も複製される。これは、たとえば、受領側コンピュータ・システム508に関して、図6に示されている。この場合、受領側コンピュータ・システム508は、データベース検索クエリーの処理の過程で、静的部分を動的部分において指定された変更と統合し、動的データ構造（ポジティブ・リスト、ネガティブ・リスト、アペンド専用データ構造の未統合部分）も解析するためのモジュール510も含む。

【0224】

典型的には、個々のコンピュータ・システム500、506、508、502、504は、ネットワーク、たとえばインターネットを介して接続される。

【0225】

しかしながら、図6に示されるシステムアーキテクチャー500は、多くの可能なオプションの1つにすぎない。多くの代替アーキテクチャーが可能である。たとえば、生データの処理は、データベース104を記憶し、データベース照会およびデータベース統合を実行するなどの、異なるデータ処理システム上で実行されうる。

【0226】

図7は、データベース照会を実行する方法のフローチャートを示している。この方法のステップは、図1と関連してすでに説明した。

【0227】

図8は、データベース・クエリーにおいて、まだ統合されていないデータ値変更を考慮に入れる方法のフローチャートを示している。

【0228】

ステップ702では、DMSシステムは、たとえば、ファーストネーム・フィールドに関する検索値Stefanを含む検索クエリーを受領する。

【0229】

次のステップ710では、DMSシステムは、マッピング・テーブル210を検索して、データ値または検索値「Stefan」に割り当てられたマッピングIDの1つを識別する。たとえば、これは数値「150」でありうる。このマッピングID「150」は、以下では実際の検索値として使用される。

【0230】

検索値「150」は、データベースの静的部分101、すなわちフィールド固有データ値リストに対してデータベース検索を実行するために使用される。ここで説明する例では、検索値150は、ファーストネーム・データ値リストを検索するために使用され、図7に示す検索方法のステップi）では、データ・レコードIDの集合が、静的部分の検索の結果として返されるべく、静的データ上で確認される。この結果は、最新の統合時点の時点でのデータベース104の内容を表し、よって、その最新の統合時点以降に得られた変更要求が結果に及ぼしうる影響を含まない。まだ統合されていない変更を考慮に入れるために、たとえば、図7で説明されているステップに加えて、図8で説明されているステップが実行される。

【0231】

ステップ706では、まだ統合されていない変更命令の後のデータ値「Stefan」を今や含む、またはもはや含まないファーストネーム・フィールドを含むデータ・レコードを確認するために、データベース104の動的部分103のデータ構造216が検索される。特に、これらのデータ構造216は、データ値、特にマッピングIDのソートされた検索可能な配列を含むデータ構造であってもよい。検索可能な配列は、たとえば、ソートされたリストまたは検索ツリー、特にBツリーであってもよい。そのようなデータ構造の例が図9に示される。DMSシステムは、たとえば図9に示されるように、個々のデータ値および／またはデータ・レコード全体に関する変更命令を、最初はアペンド専用データ構造内に、およびポジティブ・リストおよびネガティブ・リストを含むデータ構造内に格納するように構成される。データ構造216では、まだ統合されていない変更命令の1つに従って一つまたは複数のデータ・レコードに追加されるか、または一つまたは複数のデータ・レコードから削除される特定のフィールドに割り当てられたデータ値が、配列の要素として表される。これらのデータ値または要素のそれぞれには、ポジティブ・リストと呼ばれるデータ・レコードIDのリスト、および／またはネガティブ・リストと呼ばれるデータ・レコードIDのリストが割り当てられる。ポジティブ・リストは、配列の要素によって表されるデータ値が、そのフィールドに新たに追加されるデータ・レコードのIDを選択的に含む。ネガティブ・リストは、そのフィールドにおいて配列の要素によって表されるデータ値を含まなくなるべきであるデータ・レコードのIDを選択的に含む。

【0232】

ステップ706では、この検索値「150」を表す要素（たとえば、Bツリーのノード）が見つかるまで、よって、ファーストネーム「Stefan」が確認されるまで、検索値「150」を用いてデータ構造216が検索される。さらに、これらのノードに割り当てられたポジティブ・リストとネガティブ・リストが確認される。ポジティブ・リストは、最新の統合時間の後にDMSシステムが受け取った変更命令に従って、「ファーストネーム」フィールドにデータ値「Stefan」または「150」を含むことになるすべてのデータ・レコードIDのリストを含む。含むことになるのは、たとえば、このファーストネームをもつ新しい個人データ・レコードがデータベースに追加されるため、および／または、たとえばタイプミスの修正後に、既存の個人データ・レコードのファーストネームが変更されるためである。ネガティブ・リストは、最新の統合時間後にDMSシステムが受け取った変更命令に従って、以前のデータ値「Stefan」をもはや含まないべきであるすべてのデータ・レコードIDのリストを含む。含まなくなるのは、たとえば、この個人データ・レコードが削除されるか、ファーストネームのみが変更されるためである。

【0233】

ステップ708では、データベース104の静的部分と動的部分の両方を考慮に入れて、データ・レコードIDの最終結果リストが計算される：静的部分で確認されたデータ・レコードIDの集合、すなわち、検索値150についてのファーストネーム・データ値リストが、検索値150のポジティブ・リストに含まれるデータ・レコードIDの集合とマージされる。したがって、この和集合は今や、最新の、まだ統合されていない変更命令に従って、データ値150またはStefanをファーストネーム・フィールドに含むべきであるデータ・レコードIDも含む。また、この和集合と検索値150のネガティブ・リストに含まれるデータ・レコードIDの集合との差分集合が形成される。このようにして取得された差集合は、最新の統合時点後に完全に削除されたデータ・レコードのIDが含まないか、またはファーストネーム150またはStefanをもはや含まない。

【0234】

ステップ710で計算された差集合は、図7のステップ612とは対照的に、動的な、まだ統合されていない変更も考慮に入れる、検索ステップi）の新しい結果として使用されうる。好ましくは、この検索は、今や、データ・レコードIDだけでなく、データ値を有する完全なデータ・レコード、および任意的には上位および／または下位のデータ・レコードまたは以前のデータ・レコード・バージョンを出力するために、図7に関して説明したステップと同様に、ステップ614、616、および618の実行をも含む。

【0235】

図9は、複数のポジティブ・リストおよびネガティブ・リストを有するデータ構造216の例を示す。たとえば、データ構造は、フィールド固有のデータ構造であってもよく、たとえば、特定のフィールド（たとえば、ファーストネーム）に割り当てられた（好ましくは、マッピングIDの形の）データ値のみを含んでいてもよい。しかしながら、たとえば、データベース内のすべてのデータ値の全体を単一の検索可能な配列に格納するような仕方でデータ構造を実装することも可能であり、この場合、配列の各要素には一つまたは複数のフィールドが割り当てられる（たとえばデータ値silverは、金属、姓、または色を表しうる）。ここで説明する実施形態では、データ構造216は、ファーストネーム・フィールドのデータ値またはマッピングIDのみを表す。

【0236】

図9に示される検索可能な配列はBツリーであり、マッピングIDはその数値に従ってソートされて格納される。このツリーにおける検索値150の検索は、マッピングID（MID）150を含むノードで終了する。このノードには、ネガティブ・リスト220とポジティブ・リスト218が割り当てられている。

【0237】

ポジティブ・リスト218は、最新の統合時点後に受領された変更命令に従ってデータベースに新たに書き込まれるべきであり、かつ、ファーストネーム・フィールドにファーストネームStefanまたはマッピングID 150を含むすべてのデータ・レコードのIDを含む。ポジティブ・リスト218は、さらに、最新の統合時点より前にすでにデータベースの一部であったが、最新の統合時点より後に受領された変更命令に従ってファーストネームがStefanに変更されるべきもののみの、すべてのデータ・レコードのデータ・レコードIDを含む。

【0238】

ネガティブ・リスト220は、最新の統合時点の後に受領された変更命令に従ってデータベースから削除されるべきであり、かつ、ファーストネーム・フィールドにファーストネームStefanまたはマッピングID 150を含むすべてのデータ・レコードのIDを含む。さらに、ネガティブ・リストは、最新の統合時点より前にすでにデータベースの一部であり、名フィールドにファーストネームStefanまたはマッピングID 150を含んでいたが、最新の統合時点より後に受領された変更命令に従ってStefanまたは150以外の値に変更されるべきであるすべてのデータ・レコードのデータ・レコードIDを含む。

【0239】

図10は、統合前と統合後のデータ構造のブロック図と、アペンド専用ファイル構造の読み取り加速の（統合に依存しない）最適化の効果を示している。

【0240】

たとえば、データベースを統合する過程で、すべてのポジティブ・リストとネガティブ・リストの内容が、フィールド固有データ値リストに対する変更の形で格納されてもよい。ポジティブ・リストおよびネガティブ・リストは、フィールド識別子およびデータ値（たとえば、マッピングID）にリンクされて格納されるので、ネガティブ・リストまたはポジティブ・リストに格納される各データ・レコードIDは、ポジティブ・リストおよびネガティブ・リストに含まれるおよび／またはアペンド専用データ構造のまだ統合されていない部分に含まれる情報も反映するために、データベースのすでに統合された静的な部分が変更されなければならない仕方に関する情報を含む。対応するフィールド関連データ値リストにおけるデータ値としてすでに含まれているデータ値のみを含む新しいデータ・レコードを統合しても、フィールド固有データ値リストにおけるデータ値の数やマッピングIDは変更されない（出現頻度を隠す目的で既存のデータ値について追加のマッピングIDが生成されるのでない限り）。ただし、既存のデータ値またはマッピングIDは、今や、新しいデータ・レコードのIDに追加的にリンクされる。データ・レコードが削除される場合は、そのデータ・レコードに含まれるデータ値またはマッピングIDを含むすべてのフィールド固有データ値リストから、データ・レコードIDが除去される結果となる。データ値の上書きなどの変更が行われた場合でも、多くの場合、対応するデータ値またはマッピングIDへのデータ・レコードIDの割り当てのみが変更される。特定のデータ値が特定のフィールドに初めて割り当てられる場合、またはそのデータ値を含む唯一のデータ・レコードであるデータ・レコードのデータ値を上書きまたは削除する場合にのみ、統合は、フィールド固有データ値リストに含まれるデータ値またはマッピングIDの数の変更も含意する。

【0241】

よって、統合の過程で、フィールド固有データ値リスト116は、統合されたフィールド固有データ値リスト228に変換される。統合リスト228は、データ値（またはマッピングID）の割り当てと、最新の過去の統合時点と現在の統合の時点との間の変更命令の形でDMSシステムから受領されたすべての変更を反映するデータ・レコードIDとを含む。変更命令は、たとえば、古典的なSQLベースのDELETE〔削除〕、UPDATE〔更新〕、またはINSERT〔挿入〕命令、または異なるシンタックスにおける他の形の書き込み命令であってもよい。

【0242】

さらに、データ値の検索可能な配列（たとえば、リスト、検索ツリー）を有するデータ構造は、これらのデータ構造の統合バージョン234に移転される。データ構造の統合バージョンは、以前にはデータベースに含まれていなかった、新たに追加されたデータ値またはマッピングIDを反映する追加的な要素（ソートされたリストのリスト要素、検索ツリーのノードなど）を含むことができる。データ構造216の統合バージョン234は、データセットからいくつかのデータ値またはマッピングIDが完全に削除されている場合、より少ない数の要素を含むこともできる。特に、統合データ構造234のポジティブ・リストおよびネガティブ・リストは空にされる。これにより、ポジティブ・リストとネガティブ・リストが、現在の統合時点より後に受領された変更命令に従って変更されるデータ・レコードに関連するデータ・レコードIDのみを含む。

【0243】

アペンド専用データ構造202は、継続的に更新される。したがって、それは典型的には統合の過程で空にされることはない。

【0244】

しかしながら、好ましくは、DMSシステムは、統合の途中で、または統合とは独立して、ステップ216および218の実行の過程におけるデータ構造の評価を大幅に加速するように、アペンド専用データ構造202に変更を加えるように構成される。これは、アペンド専用データ構造202を、最適化された形のアペンド専用データ構造236に変換する。最適化は、DMSシステムが、「完全な」または「完全にロードされた」AODエントリーと呼ばれ、現在のデータ値（特に現在のマッピングID）をデータ・レコードの各フィールドに割り当てるAODエントリーを生成し、アペンド専用データ構造202に格納することからなる。これらの「完全な」AODエントリーは、変更要求の受領に応答して書き込まれるのではなく、変更要求とは独立して書き込まれる。たとえば、統合の過程で、ユーザーからのコマンドに応答して、または検索クエリーを実行する過程でのアペンド専用データ構造202の処理に時間がかかりすぎている、たとえば、要求される時間の事前定義された最大値を超えているというDMSシステムによる判別に応答して、事前定義された時間間隔の後に、完全なAODエントリーが生成され、格納されてもよい。

【0245】

典型的には、AODエントリーは、対応する変更要求に従って変更されるべき1つまたは少数のフィールドの現在のデータ値のみを含む。AODエントリーは、変更されたデータ・レコードのすべてのデータ値を含むわけではない。すべてのデータ値を確認するために、DMSシステムは、それぞれのAODエントリーに含まれるアドレスに従わなければならず、各エントリーは、同じデータ・レコードを参照する最後に書き込まれたAODエントリーを参照する。

【0246】

AODエントリーは、特に、DMSシステムが、変更されるべき特定のデータ・レコードについての新しいAODエントリーの書き込み中に、最新の／最も最近の変更命令をもつ、すでに存在するAODエントリーのアドレスをすでに確認するような仕方で生成される。この確認は、アドレス割り当てテーブルを使用して非常に迅速かつパフォーマンスよく実行でき、データ・レコードIDは、既存のAODエントリーのアドレスにリンクされて依然として格納されている。次いで、このデータ・レコードの最新の変更を有する新しいAODエントリーが、アペンド専用データ構造202に書き込まれ、この新しいAODエントリーは、既存の最新のAODエントリーの確認されたアドレスを含む。さらに、アドレス割り当てテーブル内のデータ・レコードIDに割り当てられたAODエントリー・アドレスは、データ・レコードIDが今や新しいAODエントリーのアドレスを指すように更新されなければならない。

【0247】

よって、アペンド専用データ構造202内のAODエントリーに含まれるアドレスを追跡することによって、特定のデータ・レコードに関連するすべてのAODエントリーのシーケンス全体を、そのデータ・レコードに関連するアペンド専用データ構造202内のまさに最初のAOD要素まで、迅速に検索することができる。

【0248】

アペンド専用データ構造202内でのこのアドレス・ベースのジャンプは非常に効率的であるが、他のデータベース統合に対して同期的または非同期的に実行されることができる時折の最適化の過程でも完全なAODエントリーを書き込むことによって、効率をさらに高めることができる。それにより、完全なAODエントリーに到達したときにデータ・レコードの現在有効なデータ値がすべてわかっているので、トレースが数回のトレース・ステップの後に終了しうる。

【0249】

ある実装変形によれば、AODデータ構造は、ステップ216および218の実行を加速するために、統合の過程でまたは統合とは独立して最適化される。これは、たとえば、AODファイルの内容のコピーを作成することによって行うことができ、このコピーは、同じデータ・レコードを参照するいくつかのAODエントリーの内容を組み合わせ、それにより、AODエントリーがすべて完全なAODエントリーであるか、または少なくとももとのAODデータ構造よりも完全なAODエントリーの含有率が高いAODデータ構造が作成される。次いで、修正されたコピーが、出力されるデータ・レコードを完成させるために使用される。AODエントリーを処理して結果データ・レコードを完成させるとき、AODエントリーの、より高い割合が完全なAODエントリーであり、よって過去にある、さらなるデータ・レコードにアクセスする必要がないため、AODエントリー・アドレスに対してなされる必要のあるアクセスは少なくなる。

【0250】

図11は、別の実装例に従った、完全な論理結果データ・レコードの効率的な出力のためのデータ構造を示す。データ構造は、他の実装変形、たとえば図3に示される変形についてすでに説明されているように、アドレス割り当てテーブル226とアペンド専用データ構造202とを含む。論理データ・レコード908は、ここでは、破線のブロックとして示されている。これは、論理データ・レコードが好ましくは、テーブル形式ではなく、非冗長データ値リストまたはマッピングIDリストの形で格納されることを明確にするためである。識別子「Distr.Stor.」は、これらのデータ・レコードのフィールド値またはマッピングIDの分散された格納が、いくつかの非冗長データ値リストにおいて行われることを示す。

【0251】

図11に示される実装変形では、DMSシステムは、新しい論理データ・レコードを作成および／またはインポートするときに、このデータ・レコードに一意的に割り当てられる新しいエントリーをアドレス割り当てテーブル226内に作成し、このデータ・レコードに割り当てられたアドレス割り当てテーブル内のエントリーのメモリ・アドレスを明示的または暗黙的に指定するIDを新しい論理データ・レコードに割り当てるようにも構成される。よって、データ・レコードID「#109」は、アドレス割り当てテーブル226内でそのデータ・レコードに一意的に割り当てられた行のメモリ・アドレスを指定し、別のデータ・レコードのデータ・レコードID「#110」は、アドレス割り当てテーブル226内でその別のデータ・レコードに一意的に割り当てられた行のメモリ・アドレスを指定する。これは、二重矢印によって示されている。データ・レコード#110についてのアドレス割り当てテーブル226内のエントリー／行は、特定のAODエントリー、すなわち、最も最近の変更（その過程でフィールドF3の値が「b」に設定された）を有するエントリーのメモリ・アドレスを含む。このAODエントリーは、同じデータ・レコード#110を参照する次の、より古いAODエントリーのアドレスを参照する／含む。この場合、これはフィールドF3の以前の値、すなわち「a」を指定する。

【0252】

好ましくは、データベース照会は、2つのステップで実行される。第1のステップでは、返される論理データ・レコードのIDだけが確認され、これらのデータ・レコードのフィールド値は確認されない。ここで説明する変形例では、このステップは、データ値リストを評価することによって実行されうる。

【0253】

第2のステップにおいてのみ、データ・レコードのIDから開始して、アドレス割り当てテーブルおよびAODデータ構造を使用して、結果データ・レコードに現在割り当てられているデータ値（たとえば、マッピングID）が確認され、それらのデータ値を含む完全なデータ・レコードが返される。この第2のステップでは、データ構造226および202におけるそれぞれのエントリーへのアクセスは、好ましくは、直接的に、すなわち、それぞれのデータ構造における検索ステップなしに実行され、第2のステップは、a）第1のステップで確認されたデータ・レコードIDにおいて明示的または暗黙的に指定されたアドレス割り当てテーブル内のエントリーのアドレスにアクセスするステップであって、このステップは、これらのアドレス割り当てテーブル・エントリーに含まれるAODアドレスを確認するためのステップである、ステップと、b）返されるべきデータ・レコードのフィールド値における最新の変更を確認するために、a）において確認されたAODエントリー・アドレスにアクセスするステップと、c）b）に関わるAODエントリーが完全でない場合、次の、より古いAODエントリーに直接アクセスして評価するために、各AODエントリーに含まれる次の、より古いAODエントリーのアドレスへの参照を評価するステップと、返されるべきデータ・レコードのすべてのフィールドについて現在のフィールド値が確認されるまで、ステップc）を繰り返すことを含む。フィールド値がマッピングIDである場合、マッピング・テーブルは、マッピングIDをもとのデータ値で置き換え、マッピングIDの代わりにもとのデータ値を含むデータ・レコードを返すために、さらなるステップにおいてアクセスされてもよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【手続補正書】

【提出日】2024-03-01

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

データベース（104）内でデータベース照会を実行するためのコンピュータ実装される方法であって、前記データベースは、「最新の統合時点」と呼ばれる第1の時点における複数の論理データ・レコードを含み、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、前記データ・レコードは、フィールド固有データ値リスト（116,402,404,406）の形で物理的に記憶され、当該方法は、前記最新の統合時点の後に：
・前記データ・レコードのうちのいくつかのデータ・レコードのフィールドのデータ値を変更する命令を受領するステップ（602）と；
・前記フィールド固有データ値リスト（116）に前記変更を加えることなく、アペンド専用データ構造（202）に前記命令を格納するステップ（604）であって、ここではAODエントリーと呼ばれる、前記アペンド専用データ構造における各エントリーが、少なくとも、前記データ・レコードのうちの1つのデータ・レコードのフィールド識別子‐データ値ペアのうち、前記変更命令の1つに従って変更されるべきものを含む、ステップと；
・前記データベースが、最新の統合時点の後に、それについてデータ値を変更する一つまたは複数の命令を受領する前記データ・レコードのそれぞれについて、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうちの最新のもののアドレス（206,208）を、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブル（226）に格納するステップ（606）であって、前記アドレス割り当てテーブルにおけるリンクは、自動的に更新される、ステップと；
・データベース照会を実行するステップとを含み、前記データベース照会は：
i. 前記フィールド固有データ値リストを検索して（612）、一つまたは複数のフィールド固有検索値との一致に基づいて、その内容の全部または一部が返されるデータ・レコード（214）のIDを識別し；
ii. i）で識別されたデータ・レコードIDの1つに割り当てられたAODエントリーのアドレスを識別するために、前記アドレス割り当てテーブルにアクセスし（614）；
iii. 前記AODエントリーの識別されたアドレスにアクセスし（616）；
iv. これらの識別されたAODエントリーに含まれる変更詳細を使用して（618）、フィールド識別子‐データ値ペアをステップi）で確認されたデータ・レコードIDに追加し、それを出力することを含む、
コンピュータ実装される方法。

【請求項2】

・前記アドレス割り当てテーブルにおけるちょうど1つのエントリーが、前記論理データ・レコードのそれぞれに対応する、および／または
・当該方法は、さらに、前記論理データ・レコードと前記アドレス割り当てテーブルにおけるエントリーの、DMSシステムによる協調管理を含み、前記論理データ・レコードは常に、各論理データ・レコードのIDが前記アドレス割り当てテーブルにおけるそのエントリーのメモリ・アドレスを明示的または暗黙的に指定するように、生成され、前記アドレス割り当てテーブルと同期され、該アドレス割り当てテーブルにおいて、その論理データ・レコードのIDはそのデータ・レコードに対する最新の変更を有するAODエントリーのアドレスを割り当てられ；特に、ステップii）において、データ・レコードIDにおいて指定されたメモリ・アドレスが、i）において確認されたデータ・レコードに一意的に割り当てられた前記アドレス割り当てテーブルにおけるエントリーに直接アクセスする、
請求項１に記載のコンピュータ実装される方法。

【請求項3】

・「新しい統合時点」と呼ばれる第2の時点において、前記フィールド固有データ値リストに対するデータベース照会の実行と独立して、および／または、それと並行して、前記フィールド固有データ値リストを統合することによって、前記最新の統合時点以降に指示された変更を統合するステップ；または
・「新しい統合時点」と呼ばれる第2の時点において、前記フィールド固有データ値リストに対するデータベース照会の実行と独立して、および／または、それと並行して、前記フィールド固有データ値リストの統合されたコピー（228）を生成することによって、前記最新の統合時点以降に指示された変更を統合するステップを含む、
請求項１に記載のコンピュータ実装される方法。

【請求項4】

・各フィールド固有データ値リストの各データ値について、前記第1の統合時点と前記第2の統合時点との間に受領された変更命令の結果として、そのフィールドに関してそのデータ値がもはや割り当てられなくなるすべての論理データ・レコードのデータ・レコードIDを、ネガティブ・リスト（220）と呼ばれるリストに格納するステップと；
・各フィールド固有データ値リストの各データ値について、各フィールドの新しいデータ値について、前記第1の統合時点と前記第2の統合時点との間に受領された変更命令の結果として、そのフィールドに関してそのデータ値が割り当てられることになるすべての論理データ・レコードのデータ・レコードIDを、ポジティブ・リスト（218）と呼ばれるリストに格納するステップとをさらに含み、
前記統合を実行することは、前記ポジティブ・リストおよび前記ネガティブ・リストの内容に従って、前記フィールド固有データ値リストまたは前記フィールド固有データ値リストのコピーの、データ値およびデータ・レコードIDを更新することを含み、
統合後、前記ポジティブ・リストおよび前記ネガティブ・リストは空にされる、
請求項３に記載のコンピュータ実装される方法。

【請求項5】

・当該方法が、中断することなく、前記統合と並行して、かつ、前記統合とは独立して、前記フィールド固有データ値リストに対してさらなるデータベース照会を実行することを含む、および／または
・前記フィールド固有データ値リストにも、前記統合の実行中に該フィールド固有データ値リストに含まれるデータ値に対するロックがない、
請求項３に記載のコンピュータ実装される方法。

【請求項6】

前記フィールド固有データ値リストのそれぞれについて前記統合を実行することは：
・データ・レコードIDのフィールド固有およびデータ値固有のポジティブ・リスト（218）およびネガティブ・リスト（220）を解析して、前記第1の統合時点と前記第2の統合時点との間の、あるフィールドの一意的なデータ値の数に関する変化、およびそのフィールドのデータ値にリンクされたデータ・レコードIDの最大数に関する変化を確認するステップと；
・前記解析において確認された一意的なデータ値の数の変化の関数として、前記フィールド固有データ値リストの統合バージョンに含まれる一意的なデータ値の数を確認するステップと；
・前記フィールド固有データ値リストの前記統合バージョンにおけるデータ値に割り当てられる、前記解析において確認されたデータ・レコードIDの最大数を格納するための第1のメモリ要件と、前記フィールド固有データ値リストの前記統合バージョンに格納される最大のデータ値を格納するための第2のメモリ要件を確認するステップと；
・リスト内の一意的なデータ値の確認された数ならびに前記第1および第2のメモリ要件の関数として、前記フィールド関連データ値リストの統合バージョンを格納するために必要とされるメモリ要件を計算するステップと；
・少なくとも計算されたメモリ領域と同じ大きさの物理的なデータ担体上の連続領域を確認するステップと；
・最後の統合時点以降に前記ポジティブ・リストおよび前記ネガティブ・リストに格納された変更を組み込んで、前記フィールド関連データ値リストの前記統合バージョンを生成するステップと；
・前記フィールド関連データ値リストの前記統合バージョンを、前記データ担体の確認された連続領域に格納するステップとを含む、
請求項３に記載のコンピュータ実装される方法。

【請求項7】

前記フィールド固有データ値リストの提供をさらに含み、前記提供が：
・生データをパースして、もとのデータ・レコードを作成するステップであって、各もとのデータ・レコードは、データ・レコードIDに加えて、フィールド識別子とそれに割り当てられたもとのデータ値との一つまたは複数のペアを含む、ステップと；
・前記データベースにおいて、冗長性のないフィールド固有のもとデータ値リストを格納するステップであって、前記冗長性のないフィールド固有のもとデータ値リストのうちの1つにおけるもとのデータ値のそれぞれに、前記もとデータ値リストを表すフィールドにおいて前記もとのデータ値を含むもとのデータ・レコードのすべてのデータ・レコードIDが割り当てられている、ステップと；
・前記冗長性のないもとデータ値リストの各もとのデータ値に、他のいずれのもとのデータ値にも割り当てられていない少なくとも1つのマッピングIDを割り当てるマッピング・テーブル（210）を生成するステップと；
・前記もとのデータ・レコードを前記複数の論理データ・レコードに変換し、前記冗長性のないフィールド固有のもとデータ値リストを前記フィールド固有データ値リストに変換するステップであって、前記変換は、前記マッピング・テーブルに従って、もとのデータ値をマッピングIDで置換することを含み、前記データ・レコードのフィールドに割り当てられる前記データ値は、前記マッピングIDである、
請求項１に記載のコンピュータ実装される方法。

【請求項8】

・前記マッピングIDは、好ましくはデータベース検索のために使用されるコンピュータ・システムのプロセッサ・アーキテクチャーに依存して長さおよび／またはタイプが選択される値であり、特に数値である、請求項７に記載のコンピュータ実装される方法。

【請求項9】

前記変更命令の少なくとも1つが、前記論理データ・レコードの少なくとも1つにおけるフィールドの古くなったデータ値を変更または削除する命令であり、当該方法が：
・前記少なくとも1つのデータ・レコードのデータ・レコードIDを、ネガティブ・リスト（220）と呼ばれるデータ・レコードIDのリストに格納するステップをさらに含み、前記ネガティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、前記変更要求に従って変更または削除されるべきデータ値にリンクされてデータ構造（216）において格納され、
・前記フィールド固有の検索値のそれぞれについての前記データベース照会の実行は：
・前記データ構造（216）が、前記フィールド固有の検索値および該検索値のフィールド識別子と同一のデータ値およびフィールド識別子にリンクされて格納されたネガティブ・リストを含むかどうかをチェックし；
・もしそうであれば、このフィールド固有の検索値についてステップi）で確認されたすべてのデータ・レコードIDと、前記ネガティブ・リストにおけるデータ・レコードIDとの差分量を計算し；
・ステップii～ivのためにデータ・レコードIDの前記差分量を使用することを含む、
請求項１に記載のコンピュータ実装される方法。

【請求項10】

前記変更命令の少なくとも1つが、前記データ・レコードの少なくとも1つにおけるフィールドに新しいデータ値を割り当てる命令であり、当該方法が：
・前記少なくとも1つのデータ・レコードのデータ・レコードIDを、ポジティブ・リストと呼ばれるデータ・レコードIDのリストに格納するステップであって、前記ポジティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、かつ、前記新しいデータ値にリンクされてデータ構造（216）において格納される、ステップと；
・前記新しいデータ値が古くなったデータ値を置換する場合、前記少なくとも1つのデータ・レコードのデータ・レコードIDを、ネガティブ・リスト（220）と呼ばれるデータ・レコードIDのリストに格納するステップであって、前記ネガティブ・リストは、前記1つのフィールドのフィールド識別子にリンクされ、前記古くなったデータ値にリンクされて格納される、ステップとをさらに含み、
・前記フィールド固有の検索値のそれぞれについての前記データベース照会の実行は：
・前記データ構造が、前記フィールド固有の検索値および前記検索値のフィールド識別子と同一のデータ値およびフィールド識別子にリンクされて格納されたポジティブ・リストを含むかどうかをチェックすることと；
・もしそうであれば、このフィールド固有の検索値についてステップi）で確認されたすべてのデータ・レコードIDと、前記ポジティブ・リストにおけるデータ・レコードIDの和集合を計算することであって、前記新しいデータ値が古くなったデータ値を置換する場合、前記和集合のデータ・レコードIDは、この検索値とそのフィールドに割り当てられた前記ネガティブ・リストにおけるデータ・レコードIDだけ縮小される、ことと；
・ステップii～ivのためにデータ・レコードIDの前記和集合を使用することとを含む、
請求項１に記載のコンピュータ実装される方法。

【請求項11】

・前記データ構造（216）は、検索可能なソートされた要素の配列を含み、前記配列は、リスト要素のリスト、またはノードの検索ツリー、特にBツリーであり、
・前記配列は、それぞれの場合における前記フィールドの1つを表し、
・前記配列の要素は、前記データ・レコード（214）に含まれ、前記配列によって表される前記フィールドに割り当てられたデータ値の非冗長リスト（116）の1つのデータ値を表し、
・前記配列の各要素は、空であるもしくは空でないポジティブ・リストおよび／または空であるもしくは空でないネガティブ・リストにリンクされて格納される、
請求項７に記載のコンピュータ実装される方法。

【請求項12】

・前記フィールド固有データ値リスト（116）はそれぞれ、前記論理データ・レコードにおけるそのフィールド固有データ値リストを表すそのフィールドに割り当てられたデータ値を選んだ非冗長データ値リストであり、
・それぞれのフィールド固有データ値リストの各データ値は、一意的であり、そのフィールド固有データ値リストによって表されるそのフィールド内のそのデータ値を含むすべての論理データ・レコードのデータ・レコードIDにリンクされて格納され、
・前記データ値は、好ましくは、前記フィールド固有データ値リストにおいてソートされた形で格納される、
請求項１に記載のコンピュータ実装される方法。

【請求項13】

前記統合は：
・前記第2の時点において、前記最新の統合時点以降に指示された変更を統合するためのコマンドを受領するステップと；
・前記コマンドを受領することに応答して：
・前記最新の統合時点と前記第2の時点との間に指示された前記フィールド固有データ値リストまたはそのコピーにおける変更を実装して、統合フィールド固有データ値リスト（228）を生成し、各統合フィールド固有データ値リストにおける各データ値は、第1の時点と第2の時点との間に指示されたそのフィールドにおける変更を考慮に入れた後でもそのデータ値を含む論理データ・レコードのIDのみが割り当てられるようにし；
・前記第2の時点より後にデータベース検索を実行するために、以前に使用されたフィールド固有データ値リスト（216）の代わりに、前記統合フィールド固有データ値リストを使用し；
・前記第2の時点を新しい最新の統合時点として使用する、
ステップとを含む、
請求項３に記載のコンピュータ実装される方法。

【請求項14】

前記コマンドを受領することに応答して、前記統合フィールド固有データ値リストを生成した後に：
前記統合フィールド固有データ値リストに基づいて、前記少なくとも1つのデータ構造（216）を再生成するステップをさらに含み、前記データ構造の再生成は、前記ポジティブ・リストおよび／または前記ネガティブ・リストを空にすることを含み、
前記統合の過程における前記最新の統合時点と前記第2の時点との間に指示された変更の前記実装は、好ましくは、変更によって影響を受けるすべてのフィールド固有データ値リストにおけるすべてのデータ値の前記ポジティブ・リストおよびネガティブ・リストを解析することによって、前記最新の統合時点と前記第2の統合時点との間に指示された前記変更を確認することを含む、
請求項９を引用する場合の請求項１３に記載のコンピュータ実装される方法。

【請求項15】

・前記論理データ・レコードの少なくとも一部が、一つまたは複数の「is-superordinate-to」フィールドを含み、前記「is-superordinate-to」フィールドのそれぞれが、そのデータ・レコードの下位のデータ・レコードのデータ・レコードIDを格納するように構成され；
・前記フィールド固有データ値リストは、前記「is-subordinate-to」フィールドを表すデータ値リスト（416）を含み、そのデータ値リストに格納されたデータ値は、少なくとも1つの他の論理データ・レコードの下位の論理データ・レコードのIDであり、前記「is-superordinate-to」データ値リストにおける各データ値は、前記他の下位のデータ・レコードの一つまたは複数のIDを割り当てられ；
・前記データベース照会は、前記データベース照会において確認されたデータ・レコードに加えて、これらのデータ・レコードの下位のデータ・レコードも出力されるかどうかを指定する完全性検索パラメータを含み；
・前記データベース照会の実行は：
・前記下位のデータ・レコードも出力されるべきであると決定し；
・ステップi）で確認されたデータ・レコードの下位のデータ・レコードの一つまたは複数のIDを取得するために、ステップi）で確認されたデータ・レコードIDを用いて前記「is-superordinate-to」データ値リストを検索し；
・前記アドレス割り当てテーブルを評価して、前記確認された下位のデータ・レコードのうちの1つのIDに割り当てられたAODエントリーのアドレスを識別し；
・前記データベース照会において確認されたデータ・レコードに下位のデータ・レコードを追加するために、前記AODエントリーのこれらの識別されたアドレスにアクセスすることを含む、
請求項１に記載のコンピュータ実装される方法。

【請求項16】

・フィールド固有データ値リストは、時間値リストと呼ばれる複数のフィールド固有データ値リストを含み、各時間値リストは、時点の非冗長リストからなり、前記時点は、それぞれ、その時間値リストが関係する前記フィールドのデータ値の有効性が一つまたは複数の論理データ・レコードにおいて開始または終了する時点を表し、
・前記時間値リストにおける各時点は、その時点において有効な論理データ・レコードのIDを割り当てられ；
当該方法は：
・前記論理データ・レコードの1つに関する変更要求を受領することに応答して、変更されるべきデータ・レコードの新しいバージョンを生成するステップであって、前記新しいバージョンは、少なくとも1つの前バージョン・フィールドを含む新しい論理データ・レコードであり、前記前バージョン・フィールドは、変更されるべきデータ・レコードのIDを含み、前記変更されるべきデータ・レコードではなく、前記新しいバージョンが、前記変更要求において指定された変更と変更時刻を含む、ステップと；
・新データ・レコードIDを有する前記データ・レコードの前記新しいバージョンを前記フィールド固有データ値リストに格納し、前記時間値リストの前記新しいデータ・レコードの有効性の開始と、前記変更命令が参照するフィールドとを格納するステップであって、前記新しいバージョンのIDは、前記時間値リストに格納される、ステップと；
・前記データベース照会は、フィールド固有の有効時間の指示を含み、前記有効時間は、前記データベース照会において確認されるデータ・レコード・バージョンが、対応するフィールドにおいて前記少なくとも1つのフィールド固有の検索値を含んでいた時点または時間期間を指定し、前記データベース照会の実行は：
・前記検索値と前記有効時間が関連するフィールドに関連する前記時間値リストを識別するステップと；
・前記有効時間に、または前記有効期間内の時点にリンクされて前記時間値リストに格納されているデータ・レコード・バージョンの一つまたは複数のデータ・レコードIDを識別するために、識別された時間値リストを前記有効時間で検索するステップと；
・前記検索値および前記有効時間が関連するフィールドに関連する前記フィールド固有データ値リストを識別するステップと；
・前記検索値にリンクされて前記データ値リストに格納された一つまたは複数のデータ・レコードIDを識別するために、前記識別されたデータ値リストを前記検索値で検索するステップと；
・前記識別された時間値リストおよび前記識別されたデータ値リストに基づいて確認された前記データ・レコードの前記バージョンのIDの共通集合を計算するステップと；
・前記アドレス割り当てテーブルを評価して、前のステップにおいて確認されたデータ・レコード・バージョンのうちの1つのIDに割り当てられたAODエントリーのアドレスを識別するステップと；
・前記有効時点においてまたは前記有効時間期間中に有効な前記データ・レコード・バージョンを、そのフィールド値で補足して出力するために、前のステップで識別された前記AODエントリーのアドレスにアクセスするステップとを含む、
請求項１に記載のコンピュータ実装される方法。

【請求項17】

・前記AODエントリーは、暗号学的ハッシュ値を介して一緒に連鎖された、前記アペンド専用データ構造内のブロックチェーンの要素として格納され、
・前記データベース検索の実行は、前記データベース照会の過程で処理されるAODエントリーのハッシュ値の有効性チェックを含む、
請求項１に記載のコンピュータ実装される方法。

【請求項18】

前記データベース照会は、前記フィールド固有データ値リストの形で前記論理データ・レコードを管理および永続化するように構成されたデータ処理および検索システム――DMSシステム（102）――によって実行され、前記DMSシステムは、前記フィールド固有データ値リストに加えて、前記第1の統合時において前記DMSシステムによってすでに管理されているすべての論理データ・レコードが再構築されうるもとになるいかなるデータ構造をも管理および永続化しないように構成される、請求項１に記載のコンピュータ実装される方法。

【請求項19】

前記フィールド固有データ値リストは、ステップi）において検索された前記フィールド固有データ値リストのいずれかまたはすべてに対してロック（「データベース・ロック」）がなく、少なくともステップi）の実行中に、そこに含まれるデータ値に対してロックがない、請求項１に記載のコンピュータ実装される方法。

【請求項20】

コンピュータ可読命令が格納されている揮発性または不揮発性の記憶媒体であって、前記命令は、プロセッサに、請求項１ないし１９のうちいずれか一項に記載の、データベース内でデータベース照会を実行するための方法を実行させるように構成される、記憶媒体。

【請求項21】

・論理データ・レコードが分散式に格納される複数のフィールド固有データ値リスト（116）であって、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、好ましくは、各フィールド固有データ値リストは、前記論理データ・レコードにおけるそのリストによって表される前記フィールドの1つに割り当てられたデータ値のみのソートされた冗長性のないリストであり、前記フィールド固有リストにおける各データ値は、そのフィールド内のそのデータ値を含むすべてのデータ・レコードのIDにリンクされて格納される、複数のフィールド固有データ値リスト（116）と；
・前記データ・レコードのフィールドのデータ値を変更するための命令を含むアペンド専用データ構造（202）であって、ここではAODエントリーと呼ばれる前記アペンド専用データ構造における各エントリーは、少なくとも、前記データ・レコードのうちの1つのデータ・レコードの前記フィールド識別子‐データ値ペアのうち、前記変更命令の1つに従って変更されるべきものを含む、アペンド専用データ構造（202）と；
・アドレス割り当てテーブルであって、前記アドレス割り当てテーブルは、変更命令のあるAODエントリーが前記アペンド専用データ構造において格納されている各データ・レコードのIDに、そのデータ・レコードに対する変更を指定する最新のAODエントリーのアドレス（206、208）を割り当てる、アドレス割り当てテーブル（226）とを含む
データ構造であって、
当該データ構造は、特にさらに：
・少なくとも1つのデータ構造（216）であって、
・前記データ構造（216）は、検索可能なソートされた要素の配列を含み、前記配列は、リスト要素のリスト、またはノードの検索ツリー、特にBツリーであり、
・前記配列は、それぞれの場合における前記フィールドの1つを表し、
・前記配列の要素はそれぞれ、前記データ・レコード（214）に含まれ、前記配列によって表される前記フィールドに割り当てられたデータ値の非冗長リスト（116）の1つのデータ値を表し、
・前記配列の各要素は、空であるもしくは空でないポジティブ・リストおよび／または空であるもしくは空でないネガティブ・リストにリンクされて格納される、
データ構造（216）および／または
・前記論理データ・レコードが格納された生データから得られたもとのデータ値の冗長性のないリスト、および／または
・マッピング・テーブル（210）であって、
・前記マッピング・テーブルは、前記もとのデータ値のそれぞれに、他のどのもとのデータ値にも割り当てられていない少なくとも1つのマッピングIDを割り当て、
・前記データ・レコードの前記データ値は、前記マッピングIDである、
マッピング・テーブル（210）
を含む、データ構造。

【請求項22】

コンピュータ・システム（100,500）であって：
・少なくとも1つのプロセッサ（108）と；
・データベース（104）を含むデータ・メモリであって、前記データベースは、「最新の統合時点」と呼ばれる第1の時点において複数の論理データ・レコードを含み、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、各データ・レコードは、データ・レコードIDと、一つまたは複数のフィールド識別子‐データ値ペアとを含み、前記データ・レコードは、フィールド固有データ値リスト（116）の形で物理的に記憶される、データベース（104）と；
・データ処理および検索システム――DMSシステム（102）――であって、前記DMSシステムは前記データベース（104）を管理するように構成され、前記管理は、前記最新の統合時点の後に：
・前記データ・レコードのうちのいくつかのデータ・レコードのフィールドのデータ値を変更する命令を受領するステップと；
・前記フィールド固有データ値リスト（116）に前記変更を加えることなく、アペンド専用データ構造（202）に前記命令を格納するステップであって、ここではAODエントリーと呼ばれる、前記アペンド専用データ構造における各エントリーが、少なくとも、前記データ・レコードのうちの1つのデータ・レコードのフィールド識別子‐データ値ペアのうち、前記変更命令の1つに従って変更されるべきものを含む、ステップと；
・前記データベースが、最新の統合時点の後に、それについてデータ値を変更する一つまたは複数の命令を受領する前記データ・レコードのそれぞれについて、そのデータ・レコードへの変更を指定する格納されたAODエントリーのうちの最新のもののアドレス（206,208）を、そのデータ・レコードのデータ・レコードIDにリンクされて、アドレス割り当てテーブル（226）に格納するステップであって、前記アドレス割り当てテーブルにおけるリンクは、自動的に更新される、ステップと；
・データベース照会を実行するステップとを含み、前記データベース照会は：
i. 前記フィールド固有データ値リストを検索して（612）、一つまたは複数のフィールド固有検索値との一致に基づいて、その内容の全部または一部が返されるデータ・レコード（214）のIDを識別し；
ii. i）で識別されたデータ・レコードIDの1つに割り当てられたAODエントリーのアドレスを識別するために、前記アドレス割り当てテーブルを評価し（614）；
iii. 前記AODエントリーの識別されたアドレスにアクセスし（616）；
iv. これらの識別されたAODエントリーに含まれる変更詳細を使用して（616,618）、フィールド識別子‐データ値ペアをステップi）で確認されたデータ・レコードIDに追加し、それを出力することを含む、
コンピュータ・システム。

【国際調査報告】