JP2012504266A - データ記憶のためのシステム及び方法 - Google Patents

Abstract

データ記憶装置にデータを記憶し、データ記憶装置からデータを取り出すためにコンピュータ・システムを動作させる方法。コンピュ―タ・システムは、元の形式における記憶データの再構成を可能にするやり方でパターンに関連付けられたポインタとともに、記憶データにおけるパターンを管理するよう動作可能なデータ・マネージャ装置を有する。方法は、第１の時点におけるデータ・テーブル・エントリを併せて表すポインタ・データ及びパターン空間情報とともに第１の時点で使用されるスキーマを施す第１のデータ・テーブル・エントリを記憶する工程と、スキーマ変更に応じたマップを後の時点で生成する工程であって、上記マップが、新たなポインタ・データ及び／又は新たなパターン空間情報を含む工程とを含む。

Description

本発明は一般に、データ記憶に関する。より具体的には、本発明の実施例は、特に、あまり、又は全くデータを修正することなく、レガシー・データの使用を可能にするアーカイブ及びデータベース管理のための種々のシステム及び方法に関する。

多くのビジネス及び他の組織は、それらの情報インフラの一部として特定の形態の大規模データ記憶を使用する。多くの組織は、ルーチンのビジネス及び記録を保持するために、数百テラバイトを記憶し、更に複数のペタバイト（それらそれぞれは１０００テラバイトである）を記憶する。データは、周期的に前述のアーカイブに加えられる。毎週、毎月、毎年、又はアプリケーションの管理者（本明細書及び特許請求の範囲では「ユーザ」とも表す）が適切と認める何れかの期間において、データが、実動システムから除去され、アーカイブに入れられる。しかし、この新たなデータは、アーカイブに既にあるデータと同じ形式にないことがあり得る。この意味合いで、実動システムは、何らかの形式で、データ・テーブルを生成し、データ・テーブルをアーカイブに送信し、アーカイブからデータを再受信するよう動作可能なコンピュータ・システム上で実行する何れかのコンピュータ・システム又はプログラムである。

時間の経過につれ、データがアーカイブされるアプリケーションの性質又は要件が変動する。例えば、既存テーブル内の新たな列に新たなデータを収集し、記憶することができ、又は、データが記憶される精度は変動し得る（すなわち、列の「タイプ」が変動する）。あるいは、もう必要でないデータは収集されず、列がテーブルから削除される。前述の変動の何れかが生じる（か、又は、他の構造的変更がデータベースに行われる）と、既にアーカイブされているデータに何が起きるかという疑問が残る。一部の代替案を以下に列挙する。

１．アーカイブされたデータは、全て復元し、同じ変更を施し、前述の変更を行って再保存することが可能である。しかし、このことは、長く、高価な処理であるのみならず、更に、元のデータが、コンプライアンスの目的でアーカイブされていた場合、この形態のリカバリには潜在的な課題が存在している。元のデータの一部の部分をもう記憶することができないからである。例えば、データベース・フィールドを、より低い精度のタイプにキャストする（例えば、固定小数点タイプの小数の桁数を削減する）ことにより、アーカイブされた旧いデータに対するくつがえせないデータ喪失が生じる。

２．措置をとらず、アーカイブされたデータを不変のままにしておく。しかし、アーカイブ内のデータを照会する際に問題がもたらされる。別々の複数のスキーマでデータが記憶された場合、各スキーマにおいて別々のクエリを使用し、前述の別々のクエリからの結果が合成される一部の更なる手順を提供することが必要になる。更に、別々のクエリの結果は、違ったふうに、かつ、異なる精度でフォーマッティングし得る。

データベース・スキーマに対する変更が、アーカイブに保持された旧いデータに対する修正を必要としないと同時に、アーカイブ内のデータの何れか、及び／又は全てに対して実行する対象の最新の（すなわち、現在の）スキーマに対してクエリが記述されることを可能にする機構を提供する現在知られている手法は存在しない。

本発明の実施例によれば、データ記憶装置にデータを記憶し、データ記憶装置からデータを取り出すためにコンピュータ・システムを動作させる方法が提供される。上記方法では、コンピュ―タ・システムは、元の形式における記憶データの再構成を可能にするやり方でパターンに関連付けられたポインタとともに、記憶データにおけるパターンを管理するよう動作可能なデータ・マネージャ装置を有し、上記方法は、第１の時点におけるデータ・テーブル・エントリを併せて表すポインタ・データ及びパターン空間情報とともに第１の時点で使用されるスキーマを施す第１のデータ・テーブル・エントリを記憶する工程と、スキーマ変更に応じたマップを後の時点で生成する工程であって、上記マップが、新たなポインタ・データ及び／又は新たなパターン空間情報を含む工程とを含む。

好ましくは、ポインタ・データは、テーブル・メタ・データ及びインデクス・データの１つ又は複数を含む。

好ましくは、ポインタ・データは、スキーマの局面を定義するヘッダ情報を含む。

好ましくは、ポインタ・データはテーブル・メタ・データを含み、テーブル・メタ・データは、テーブルのフィールド、フィールドのタイプ、フィールドの最大値、フィールドの最小値、フィールドの別の属性から選択された１つ又は複数を含む。

好ましくは、ポインタ・データは、パターン空間内のパターン要素の配列を規定するインデクス・データを含む。

好ましくは、ポインタ・データは、制御機能がどのようにしてパターン要素を横移動すべきか規定する経路データを含む。

好ましくは、経路データは、１つ又は複数の変換に対する命令を含む。

好ましくは、ポインタ・データは、パターン空間の少なくとも一部分を再現する。

好ましくは、ポインタ・データの少なくとも一部分は、不変である。

好ましくは、スキーマ変更により、旧いポインタ情報に対する変更がマップに示される。

好ましくは、スキーマ変更により、合体したポインタ情報がマップに示される。

好ましくは、合体ポインタ情報からデータ・エントリを求めるために再帰プロセスが活用される。

好ましくは、スキーマ変更は、列を削除する工程を含み、マップは新たな列、旧いインデクス・データ、及び旧いパターン空間情報を含む。

好ましくは、スキーマ変更は、列を改名することを含み、マップは新たな列名、及び隠す対象の旧い列名を含む。

好ましくは、スキーマ変更は、列を加える工程を含み、マップは、別の列における値の関数、リテラルのデフォルト値、及びナル値から選択された新たな列情報を示す。

好ましくは、マップは、少なくとも部分的に、経路データへの参照により、新たな列情報を示す。

好ましくは、経路データは、ナビゲーション・データ及び機能要素の１つ又は複数を含む。

好ましくは、スキーマ変更は列の再タイプを含み、マップは、新たな列におけるエントリにつながる少なくとも一変換を示す。

好ましくは、スキーマ変更は列を再タイプする工程を含み、上記変換は、少なくとも部分的に経路データで規定される。

本発明の一局面によれば、上述の方法が提供され、上記方法は更に、先行する時点における記憶データをクエリする工程を含み、データ・マネージャは、スキーマ変更に応じて生成された少なくとも１つのマップにアクセスして、その先行する時点におけるクエリをサポートするデータを導き出す。

好ましくは、スキーマ変更は、列の分割を含み、データ・マネージャは、新たな列を加え、列を削除することに関するマップ・データを生成する。

好ましくは、スキーマ変更は、列のマージを含み、データ・マネージャは、列の削除、及び、新たな少なくとも１つの列の追加に関するマップ・データを生成する。

本発明の実施例によれば、データ記憶装置にデータを記憶し、データ記憶装置からデータを取り出すコンピュータ・システムを提供し、コンピュータ・システムは、元の形式における記憶データの再構成を可能にするやり方でパターンに関するポインタとともに記憶データにおけるパターンを管理するよう動作可能なパターン・マネージャ装置と、第１の時点におけるデータ・テーブル・エントリを併せて表すポインタ・データ及びパターン空間情報とともに第１の時点で使用されるスキーマを施す第１のデータ・テーブル・エントリを記憶する記憶装置と、スキーマ変更に応じてマップを後の時点で生成するマップ生成器とを備え、上記マップは、新たなポインタ・データ及び／又は新たなパターン空間情報を含む。

本発明の一実施例によれば、データ記憶装置にデータを記憶し、データ記憶装置からデータを取り出すコンピュータ・システムが提供され、上記コンピュータ・システムは、（ｉ）データ記憶装置内の複数のデータ・テーブル、及び（ｉｉ）データ・テーブルの生成に施される複数のスキーマに関する補助データを生成し、管理するよう動作可能なデータ・マネージャ装置を備え、補助データは、データ・テーブルの個々のフィールド値をパターン空間から求めることが可能な参照データ、及びデータ記憶装置のパターン空間内の少なくとも１つのパターンの表示を含む。

本発明の一実施例によれば、アーカイブされたデータを処理するための、コンピュータによって実現される方法が提供され、上記方法は、時点Ｔにおいてデータ・レポジトリからアーカイブに抽出データを転送する工程であって、データが、時点Ｔにおける第１のスキーマによって表される工程と、（ｉ）ヘッダ部分、（ｉｉ）インデクス部分、及び（ｉｉｉ）アーカイブにおける少なくとも１つのパターン空間に向けたポインタの組み合わせとしての少なくとも１つの抽出データを記憶する工程であって、ヘッダ部分は、データ・レポジトリにおいて存在した形式のデータを回復するためにパターン空間におけるパターンをどのようにして解釈するかに関する情報を含み、インデクス部分は、レポジトリからのデータ・レコード全体を表すパターン空間内からのパターンを識別する工程と、Ｔよりも遅い時点でデータ・クエリを受信する工程であって、レポジトリにおけるデータ・スキーマが、第１と異なる第２のスキーマに変更された工程と、第２のスキーマ下で作成されたかのように第１のスキーマがクエリに応じて挙動するように、ヘッダ部分、インデクス部分及びパターン空間におけるデータを利用するアーカイブからのデータをデータ・クエリに応じて返す工程とを含む。

好ましくは、クエリする工程は更に、データに対して変換を行う工程を更に含む。

好ましくは、変換は、列を削除する工程、列を改名する工程、列を追加する工程、列を再タイプする工程、一時点でクエリする工程、列を分割する工程、列をマージする工程のうちの１つ又は複数から選択される。

好ましくは、少なくとも１つの抽出データが不変データとして記憶される。

好ましくは、ヘッダ部分は少なくとも、（ｉ）テーブルのレコード内に存在するフィールド名、及び（ｉｉ）前述のフィールドのタイプを含む。

好ましくは、デ―タ・レポジトリは、リレーショナル・データベース、データ・ウェアハウス、又はスター・スキーマのデータベースである。

本発明の一実施例によれば、コンピュータ・システムにおいて使用するためにデータ構造が提供され、データ構造は、（ｉ）パターン空間に向けたポインタであって、パターン空間は、元のデータ・ソースにおいて発見されている１つ又は複数のパターンを含むポインタと、（ｉｉ）インデクス部分であって、インデクス領域は、元のデータ・ソースからのデータ・レコード全体を表すパターン空間内からのパターンを識別するインデクス部分と、（ｉｉｉ）ヘッダ部分であって、ヘッダ部分は、データ・レポジトリに存在した形式でデータを回復するためにパターン空間におけるパターンをどのようにして解釈するかを記述したメタデータを含むヘッダ部分とを含み、併せて、ヘッダ、インデクス、及びパターン空間に対するポインタは、一時点におけるデータ・ソースの状態を表す抽出データを形成する。

好ましくは、２つ以上の抽出データは、単一パターン空間を共有する。

本発明の一実施例によれば、アーカイブされたデータをクエリする方法が提供され、上記方法は、データをテーブルＴに記憶する工程であって、Ｔは、２つ以上の抽出データ・テーブルＴｌ、Ｔ２、Ｔ３．．．ＴＮの和集合であり、各抽出データ・テーブルが、アーカイブに記憶され、そのデータを表す別のスキーマを有する工程と、抽出データ・テ―ブルＴｌ、Ｔ２、Ｔ３．．．ＴＮ間の各スキーマ変更を表すマップを生成し、抽出データ・テーブルのうちの１つに含まれるデータに対するユーザ要求をクエリ・マネージャにおいて受信する工程と、第２の抽出データ・テーブルのスキーマ下で作成されたかのようにクエリに応じて、それを表すデータがふるまうようにクエリ・マネージャは第１の抽出データ・テーブルのスキーマを再書き込みするように適切なマップを施す工程とを含む。

好ましくは、各抽出データ・テーブルは不変データを含む。

本発明の実施例によれば、レガシー・データ・マネージャに提供される。レガシー・データ・マネージャは、少なくとも１つの実動システムからデータを受信するよう構成されたインタフェースと、データを受信し、データにおけるパターンを求め、識別されたパターンをメモリに記憶し、ポインタを使用してパターンの表現を生成するよう動作可能なパターン識別器と、ヘッダ領域を規定し、それをメモリに記憶し、ポインタを使用したヘッダの表現を生成するよう動作可能なヘッダ・マネージャと、メモリからアーカイブにデータを転送するよう構成された記憶装置上の少なくとも１つのデータ・アーカイブとのインタフェースとを備える。

本発明の一実施例によれば、データをアーカイブするコンピュータ・システムが提供される。上記コンピュータ・システムは、上述のレガシー・データ・マネージャと、動作するようレガシー・データ・マネージャに接続された、データを生成するよう動作可能な少なくとも１つの実動システムとを備える。

好ましくは、コンピュータ・システムは、動作するよう、実動システム及び／又はレガシー・データ・マネージャに少なくとも１つのユーザ端末を接続し、データ・クエリを受信するよう構成された少なくとも１つのユーザ端末インタフェースを更に備える。

好ましくは、ユーザ端末は、パーソナル・コンピュータ、シン・クライアント装置、又は何れかの他の適切な電子装置である。

本発明の実施例によるレガシー・データ・コンピュータ・システムを示す図である。 過去の別々の時点においてレガシー・データ・マネージャ１０により、アーカイブ２０にアーカイブされたデータの例を示す図である。 本発明の実施例による、アーカイブ２０内のデータのテーブルの表現の例を示す図である。 本発明の実施例による、経路及びインデクス・エントリの例を示す図である。 本発明の一実施例により、列がどのようにして削除されるかの更なる詳細を示す図である。 本発明の実施例による、列情報を取り出すための手順の例を示す図である。 本発明の実施例による、データを記憶するための別々の可能性を示す図である。 本発明の実施例による、データを記憶するための別々の可能性を示す図である。 本発明の実施例による、経路を使用して値が取り出される処理を示す図である。

本発明、及びどのようにして本発明を実施することができるかをより良く理解するために、次に、例示の目的でのみ、添付図面を参照する。

添付図面に示される同じ参照符号は、別途明記しない限り、本明細書を通じて記載された機能的に同等の構成を表すものとして解されるものとする。

図１は、本発明の実施例によるレガシー・データ・コンピュータ・システムを示す。レガシー・データ・コンピュータ・システムは、レガシー・データ・マネージャ１０と、記憶装置上に常駐している少なくとも１つのデータ・アーカイブ２０と、少なくとも１つの実動システム３０とを備える。任意的には、ユーザ・データ要求／クエリを受信するために、動作するようレガシー・データ・マネージャ１０及び／又は実動システム３０に接続された少なくとも１つのユーザ端末４０も存在し得る。ユーザ端末は、例えば、パーソナル・コンピュータ、シン・クライアント装置、又は何れかの他の適切な電子装置である。

レガシー・データ・マネージャ１０は、レガシー・データ・マネージャ１０とアーカイブ２０との間の通信を容易にするよう動作可能なアーカイブ・インタフェース１０１と、レガシー・データ・マネージャ１０と実動システム３０との間の通信を容易にするよう動作可能な実動システム・インタフェース１０２と、パターン識別器モジュール１０４と、クエリ・マネージャ１０５と、マップ生成器１０８と、インデクス・マネージャ１１０と、ヘッダ・マネージャ１１２とを含む。更に、メモリ６０も、動作するようレガシー・データ・マネージャ１０に接続される。

通常、実動システム３０は、少なくとも１つのデータベースを生成し、かつ／又は管理する。本発明の意味合いでは、「データベース」という語は、レコード又はデータの何れかの構造化された収集物を広く表すものと解されることを意図している。何れの特定のデータベース・モデルへの限定を意図するものでなく、したがって、階層モデル、ネットワーク・モデル、リレーショナル・モデル又は何れかの他のモデルのうちの１つ又は複数から選択することができる。一実施例によれば、本発明の装置及び方法がリレーショナル・データベースに施される。別の実施例によれば、本発明の装置及び方法が、スター・スキーマ又は他のデータ・ウェアハウス・モデルに施される。少なくとも１つのデータベース５０のデータの生成及び／又は管理は、自動的に、実動システム３０によって行うことができ、端末４０へのユーザ入力に応じて行うことができ、又はそれらの組み合わせによって行うことができる。いずれにせよ、少なくとも１つのデータベース５０からのデータ・テーブルは、経時的にデータ・アーカイブ２０にバックアップされる。本発明の実施例によれば、このバックアップ処理は、レガシー・データ・マネージャ１０の種々の構成部分によって管理される。

データベース・アーカイブ動作を行うために、データはデータベース５０からアーカイブ２０に転送しなければならない。しかし、一実施例によれば、データは、別個のデータベース５０に維持されるものでなく、代わりに、実動システム３０からアーカイブ２０にレガシー・データ・マネージャ１０を介して直接、転送される。いずれにせよ、この処理は、自動的に、レガシー・データ・マネージャ１０によって起動させることができ、実動システム３０によって起動させることができ、かつ／又は（例えば、端末４０への）ユーザ入力に応じて起動させることができる。デ―タベース・アーカイブ動作の結果は、過去の別々の時点でアーカイブされたデータで埋められる。不可避にも、種々の変更を経時的にデータに施し得る。特に、データ・スキーマは、時間の経過とともにデータベースの変動する要件に応じて変更し得る。「スキーマ」という語は、本明細書及び特許請求の範囲では、データベース・システムの構造、すなわち、データを表すメタデータを表すために使用される。例えば、リレーショナル・データベースでは、スキ―マはテーブル、各テーブル内のフィールド、及びフィールドとテーブルとの間の関係を規定する。しかし、上述の通り、本発明の実施例はリレーショナル・データベースにのみ限定されるものでない。

図２は、過去の別々の時点においてレガシー・データ・マネージャ１０により、アーカイブ２０にアーカイブされたデータの例を示す図である。データが、インタフェース１０２を介して実動システム３０からレガシー・データ・マネージャ１０によって受信される。例証的な一例では、抽出データは、過去の別々のいくつかの時点において実動システム３０からアーカイブ２０に送信される、各抽出データは、別個のスタンドアロン・テーブルとしてアーカイブに記憶される。アーカイブ抽出データ間で、実動システム３０によって使用されるスキーマは異なる。よって、図２を参照すれば、時点ｔ１で作成されたテーブルＴ１（２１０）は、実動システム３０において同じ名前及び汎用機能を有するテーブルＴ２（２３０）及びスキーマＳ１（２２０）を使用する。

一例によれば、例えば、端末４０に位置するユーザは、アーカイブ内のデータに対してクエリ２６０を実行したいものとする。図２に示す例では、このクエリがテーブルＴ（２５０）に対して実行される。テーブルＴ（２５０）は、上述の通り、抽出データ・テーブルＴ１（２１０）及びテーブルＴ２（２２０）の和集合である。Ｔ１及びＴ２は別々のスキーマを有するので、両方のテーブルに対して有効に実行する単一のクエリを記述することは一般に可能でない。しかし、本発明の実施例によれば、変動していない状態でＴ１に記憶された元のデータを維持することが可能である。これは、マップ生成器１０８によって作成されたマップ２７０のおかげである。具体例によれば、Ｔ２のアーカイブに先行して行われたスキーマ変更に応じて、マップ生成器１０８は、Ｔ１を取り囲むマップ２７０を作成し、そのスキーマを書き直し、ちょうどスキーマＳ２下で作成されたかのようにクエリ２６０に応じて元のデータが振る舞うことを可能にするマップ２７０を作成する。マップ２７０の機能は以下に更に詳細に説明する。しかし、概ね、マップ２７０は、スキーマ２４０の複製であるかのようにスキーマ２２０が挙動することを可能にする機能を表す。

クエリ・マネージャ１０５は、例えば、ユーザ端末４０からユーザ・クエリを受信し、マップ２７０を使用して、スキーマＳ１及びＳ２を使用して記憶されているデータに対してユーザ・クエリ２６０を実行するよう動作可能である。この影響は、別々のスキーマを使用して記憶されたデータが、例えば、このケースＳ２において、単一のスキーマを使用して記述されているかのようにクエリに対してふるまう。

データ編成
本発明の実施例によれば、データ・セットにおけるパターンを識別し、一時データベースにパターンを記憶し、記憶パターンに対するポインタを使用してデータベース構造の表現を生成することにより、実動システム３０によって生成されたデータの組（すなわち、「データ・セット」）からレガシー・データ・マネージャ１０により、メモリ６０において作成される。好ましい実施例によれば、この表現は、以下に更に詳細に説明するように＜ヘッダ（ｈｅａｄｅｒ）、インデクス（ｉｎｄｅｘ）、（パターン（ｐａｔｔｅｒｎ））スペース（ｓｐａｃｅ）＞のトリプルである。

本明細書及び特許請求の範囲の意味合いでは、「ポインタ」は、そのアドレスを使用してアーカイブ２０内の他の所に記憶された別の値をその値が直接指す（すなわち、「指し示す」）データ・タイプを表す。リスト、キュー、ツリー等などのデータ構造を設定する場合、構造が実現され、制御されるやり方を管理するためにポインタを有することが有用である。ポインタの使用は、データベース上のより高速のサーチ、ソート及び他の動作を可能にし得る。前述の動作は、単一動作における多くのレコード（組）のフィールド値を表すために個々のパターンを使用して行うことが可能である。注：「組」、「行」、及び「レコード」の語は本明細書を通じて同義に使用される。

本発明の実施例は例えば、「Ｍｅｔｈｏｄ ｏｆ Ｑｕｅｒｙｉｎｇ ａ Ｓｔｒｕｃｔｕｒｅ ｏｆ Ｃｏｍｐｒｅｓｓｅｄ Ｄａｔａ」と題する国際公開第０２／０６３４９８号に記載されたようなデータベースを使用し、操作し得る。

以下の実施例、及び、適切な場合、具体例は、例えば、リレーショナル・データベース、別の階層モデルによるデータベース、又は何れかの他のデータベース・モデルによるデータベースであり得る、アーカイブ２０におけるテーブルのデータ・セットを参照して説明される。しかし、上記説明した実施例は、単一のテーブルのみでなく、いくつかのテーブルにわたって使用することが可能であり、本明細書及び特許請求の範囲の記載は、データベースの単一のテーブル上でのみ動作するよう本発明の実施例を限定するものとして解されないものとする。

図３は、本発明の実施例による、アーカイブ２０内のデータのテーブルの表現の例を示す。好ましい実施例によれば、元のデータ・テーブルは、実動システム３０からレガシー・データ・マネージャ１０によって受け取られ、別個の３つの構成部分に分割される。一実施例によれば、この分割処理は、最も一般的には、ランダム・アクセス・メモリ（ＲＡＭ）などの揮発性メモリであるメモリ６０において行われる。しかし、他のタイプのメモリを、適宜、使用し得る。データ・テーブルは、３つの構成部分に操作された後、インタフェース１０１を介してアーカイブ２０に書き込まれる。

第１の構成部分は、ポインタ３２０によって表されるパターン空間３４０である。パターン空間３４０は、元のデータ・テーブルにおいて発見されているパターンが記憶されたランダム・アクセス領域である。データ・テーブルにおいて発見されたパターンを識別し、記憶する処理は、インタフェース１０２を介して実動システム３０からデータを受け取り、（例えば、適切なアルゴリズムを使用して）パターンを求め、メモリ６０に、識別されたパターンを記憶し、適宜、適切なポインタを使用してパターンの表現を生成するよう動作可能なパターン識別器１０４によって管理される。好ましい実施例によれば、この表現は、＜ヘッダ（ｈｅａｄｅｒ）、インデクス（ｉｎｄｅｘ），パターン（ｐａｔｔｅｒｎ）（空間（ｓｐａｃｅ））＞というトリプルを構成するために使用される。

「パターン空間」という語は、本明細書及び特許請求の範囲では、レガシー・データ・マネージャにより受け取られ、アーカイブ２０に最終的に記憶されるデータのインスタンス全てのレポジトリを広く表すために使用される。すなわち、パターン空間３４０は、実動システム３０及び／又は元のデータベース５０から埋められたデータのプールである。パターンがどのようにして発見され、生成されるかの一例は、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｉｍｐｌｅｍｅｎｔｉｎｇ Ａｎ Ｅｎｈａｎｃｅｄ Ｄａｔａｂａｓｅ」と題する米国特許出願公開第１１／２４４３４７号明細書において見つけ得る。

パターンを参照するためにポインタを使用することは、通常、パターン自体よりもかなり小さい更なるポインタで複製パターンを置き換えることにより、データ・セットを記憶するために必要なメモリ又は他の空間の量を大きく削減することが可能であるという点で効果的である。

第２の構成部分は、ポインタ３１０によって示されるインデクス領域３３０である。インデクス領域３３０は、元のデータ・テーブルからのデータ・レコード全体を表すパターン空間３４０内からのパターンを識別する。基本的には、インデクスは、レコードを訪問する特定の配列を実施し、インデクス領域は、前述のインデクス全てのレポジトリである。通常、インデクスは、レコードが、必然的でないが、元のテーブルに現れた配列を支配する。例えば、元のレコードの部分集合のみを参照するインデクスを有することも考えられる。

インデクス領域は、インデクス・マネージャ１１０によって識別され、管理され、インデクス・マネージャ１１０は、インタフェース１０２からの入力データを受け取り、インデクス領域を識別するためにデータを操作し、この情報をメモリ６０に記憶し、適切なポインタを適宜、使用してインデクスの表現を生成するよう動作可能である。好ましい実施例によれば、この表現は、上述の＜ｈｅａｄｅｒ、ｉｎｄｅｘ、（ｐａｔｔｅｒｎ）ｓｐａｃｅ＞のトリプルを構成するために使用され、これは更に、メモリ６０において生成され、適宜、アーカイブ２０に送出される。

構造の第３の構成部分は、ポインタ３００が指すヘッダ領域３５０である。ヘッダ領域３５０は、特定のテーブルに関連付けられたメタデータを実施する。ヘッダ３５０は、ア―カイブの一部であり、そういうものとして、アーカイブにコミットされると、変わらないという意味で不変である。ヘッダを変えることが必要な場合、新たなヘッダを表すために別のヘッダが作成される。更に、ヘッダはパターン空間において、又は、アーカイブ内の別の所で、データを変えず、やはり、不変性を維持する。その代わりに、ヘッダは、テーブルにあったデータを回復するためにパターン空間におけるパターンをどのようにして解釈するかについての情報を提供する。

ヘッダにおけるメタデータは、（ｉ）テーブルのレコードに現れるフィールドの名称、（ｉｉ）前述のフィールドのタイプ（すなわち、整数フィールドであるか、テキスト・フィールドであるか等を含む）。使用されるデータ・フィールドのタイプから、データがどのようにして表されるか、及びデータに対して行うことが可能な動作を判定することが可能である。ヘッダ領域３５０は、フィールドが読み出しのみ等であるかに係わらず、その最大値及び最小値などのフィールドの他の属性を含み得る。ヘッダ領域３５０の局面は全て、ヘッダ領域を規定するためにインタフェース１０２を介して入ってくるデータを操作し、メモリ６０に記憶し、適宜、適切なポインタを使用してヘッダの表現を生成するよう動作可能なヘッダ・マネージャ１１２によって管理される。好ましい実施例によれば、この表現は、上述の＜ｈｅａｄｅｒ、ｉｎｄｅｘ、（ｐａｔｔｅｒｎ）ｓｐａｃｅ＞のトリプルを構成するために使用され、これは更に、メモリ６０において生成され、適宜、アーカイブ２０に送出される。

ヘッダ領域３５０が記憶する別のメタデータは、特定のフィールドのナビゲーション情報である。よって、ヘッダ３５０は、伝統的なデータベース・スキーマよりも多くの情報を含む。「経路」という語は、このナビゲーション情報を広く表すために本明細書を通して使用される。これは、インデクス領域３３０におけるインデクス・エントリから始め、元のレコードに現れたフィールドの値を回復することが可能な工程を説明する。前述のプロセスにはパターン空間３４０のナビゲーションが関係する。インデクス領域３３０における各インデクス・エントリは、パターン空間３４０内のデータ・レコード全体を表す特定のパターンを識別する。前述の特定のパターンは通常、更なるパターン等にそれら自体が指し示し得る他のパターンに対するポインタを含む。最も基本的なレベルでは、何れかの特定のレコードに対するフィールドの実際の値を表す「プリミティブ値」が存在している。

要約すれば、上記３つの構成部分は、相互依存的な役割を果たし、それぞれは、アーカイブに記憶されたデータに依存する。パターン空間は単純にパターンの集合である。単一のテーブルを表すために必要なパターンよりもずっと多いパターンが空間内に存在し得る。例えば、パターン空間は、別々の多くのテーブル、又は同じテーブルの別々のビューを表し得る。インデクス３３０は、このインスタンスにおいてどのパターンが存在しているか、及びそれが現れる順序を識別する。インデクス及びパターン空間の組み合わせはほぼ、例えば、行及び列におけるセルの集合である概念的なテーブルの再作成を可能にする。例えば、パターン空間及びインデクスにより、テーブルに現れた順序でセルを再構成することが可能である。しかし、この時点で、セルを埋めるためにパターンが存在しているに過ぎない。例証するために、セルにパターン２００５０８０６が存在し得るが、その情報は、如何なるもの（例えば、西暦2005年8月６日、西暦2005年６月８日、整数20050806、固定小数2005.0806、又は他の多くのこと）も表し得る。眼に見えるパターンをどのようにして解釈するかの情報を提供するヘッダ３５０なしで元のテーブルの復元を完了することは可能でない。よって、ヘッダは、テーブルのスキーマにおいて伝統的に現れる情報を提供すると言うことが可能である。しかし、当業者に分かるように、ヘッダはスキーマよりも多くのことを行う。パターン空間もインデクスもスキーマに貢献しない。もう一度図２を参照すれば、マップ２７０は、ヘッダ（又は、より単純なレベルで考慮された場合にはスキーマ）２２０がヘッダ２４０の複製であるかのようにふるまうことを可能にする機能を表す。マップは概念的な装置である。実際には、新たな経路を含む新たなヘッダ（図示せず）が作成され、個々の経路はそれぞれ、ヘッダ２４０からの同等のフィールドであるかのようにヘッダ２２０内の一フィールドがふるまうことを可能にするマッピングの一部を含むからである。

データの上記操作が完了すると、すなわち、データ・テーブルが上記種々の構成部分に分割されると、レガシー・データ・マネージャ１０はデータをメモリ６０からアーカイブ２０にインタフェース１０４を介して転送する。一実施例によれば、操作中に各種レートを一時的に記憶するために一時データベースが利用される一方、別の実施例によれば、レガシー・データ・マネージャ１０は、一時データベースを利用しないことがあり得、その代わりに、アーカイブ２０に直接記憶する以外は同じやり方で、オンザフライで、メモリに実動システム３０から受け取られたデータを操作し得る。

要約すれば、経路のナビゲーションは、パターン空間３４０内のパターンをまわる工程、及び、プリミティブ・パターンに達し、クエリに応じて返すことが可能である状態になるまで、その中のポインタをたどって、サブパターンに達する工程を含む。前述の意味合いにおける経路のナビゲーションはクエリ・マネージャ１０６によって管理される。クエリ・マネージャ１０６は、ユーザが取り出そうとするフィールドの識別情報により、特定のパターンからたどる対象のポインタを識別する。すなわち、フィールドの（ヘッダ領域３５０における）メタデータに記憶された経路は、特定のフィールドに対応するパターンに達するためにクエリ・マネージャ１０６が横移動しなければならないパターンがどれかを求める旨の命令を含む。例えば、パターン空間３４０におけるパターン全てに一意の整数識別子が割り当てられ、インデクス領域３３０におけるエントリが前述の識別子のうちの１つ（例えば、６２６）であるとすれば、経路は、（パターンに割り当てられたものと無関係に）更なる整数の系列、例えば、３、０、２、を含み得る。

図４は、本発明の実施例による、経路及びインデクス・エントリの例を示す。インデクス・エントリ値は、例えば、工程４１０におけるユーザにより、レガシー・データ・マネージャ１０に入力される。上記の例をたどると、この値は６２６である。よって、パターン番号６２６が、工程４２０で、クエリ・マネージャ１０５によって回復され、この時点で、何れかのサブパターンがクエリ・マネージャ１０５によって識別される。もう一度、上記例をたどれば、パターン番号６２６は、５つのサブパターン識別子（例えば、７３５、１０２、１０３、４１６、１７０）を含むと判定し得る。工程４３０で、クエリ・マネージャ１０５は、経路から第１の整数（例えば、３）を回復する。すなわち、（上述の）経路は、［３，０，２］であり得るので、第１の整数は、テキストに現れているように「３」である。＜７３５，１０２，１０３，４１６，１７０＞という組は、特定の例示的なパターンの内容である。この例による整数「３」は、関心の要素、すなわち、このケースでは、パターンにおける４つ目の要素（すなわち、「４１６」）をもたらす。クエリ・マネージャ１０５は次いで、工程４４０で、次の経路の要素を求めるよう動作する。工程４５０では、クエリ・マネージャ１０５は、サブパターン・インデクスにおけるサブパターンに現在のインデクスを割り当てる。インデクスは、パターン空間における要素を識別するポインタ（この例では、整数）を含む。経路をたどると、クエリ・マネージャ１０５は、インデクスから読み取られた値に現在のインデクスがセットされることから開始する。例えば、インデクスから読み取られる値には、変数「ｃｉ」が割り当てられるものとする。「ｃｉ」における値は、パターン空間、例えば、＜７３５，１０２，１０３，４１６，１７０＞からパターンを回復するために使用される。経路は次いで、サブ要素「３」（４番目）が必要なものである旨を識別するために使用されるので、それにはｃｉが割り当てられ、よって、その場合、そのｃｉは４１６を含む。この処理が繰り返され、パターン４１６がパターン空間から回復される。経路内の次の要素は０であるので、第１の値／ポインタはこのパターンから得られ、経路の終点に達するまで「ｃｉ」等に割り当てられる。工程４６０では、プリミティブ・パターンに達したか否かがクエリ・マネージャ１０５によって判定される。これを判定するために、クエリ・マネージャ１０５は、経路上に残っている工程がなお存在しているか否かを検査する。経路の終点に達していないと検査が判定した場合、クエリ・マネージャ１０５は工程４２０に戻り、さもなければ、処理は、工程４７０において完了しているものと認められ、保持された現在のパターンのインデクスは、テーブル内の特定のレコードについて必要なフィールドに対応するプリミティブ・パターンを識別する。

ヘッダ領域３５０は、フィールド毎のメタデータ、及び経路（又はナビゲーション情報）を含み、インデクス領域３３０はパターン空間３４０へのポインタ（又はインデクス）を含む。しかし、経路は、単に、パターン空間を追うための工程を含むものでなくてよい。更に、クエリ中にフェッチされるデータに対して行う対象の変換に関する命令も含み得る。あるいは、経路は単に、既存のプリミティブ・パターンに対するレファレンス又はリテラルの値を含み得る。

以下の動作は、本発明の実施例による、クエリ中にデータに対して行い得る変換の限定的でない例である：１．列を削除する、２．列を命名する、３．列を追加する、４．列を再タイプする、５．一時点においてクエリする、及び、６．列を分割し／マージする。これらは、レガシー・データ・マネージャ１０により、アーカイブ２０におけるデータに対して行われる通常の動作である。

1. 列を削除する
列を削除することは、データ・テーブルから列を除去することを意味する。これは、実動システム３０において、その列に保持されたデータがもう必要ない場合に行われる。既にアーカイブされたデータの組（すなわち、アーカイブ２０に記憶されたデータの組）からの列を削除するために、そのデータの組に関連付けられたヘッダ３５０から列を除去するだけで十分である。例えば、初期ヘッダ３５０は、

の４つのフィールドを含む。更に、フィールドＢを削除するために、ヘッダ３５０を、

で置き換えることが可能である。

図５は、本発明の一実施例により、列がどのようにして削除されるかの更なる詳細を示す。図５に示す例では、２つの「ヘッダ／インデクス／パターン」の組のトリプルが存在している。第１のトリプル５００、５１０、５２０は、Ａ、Ｂ、Ｃ、Ｄを含む、元のヘッダ５５０に対するポインタを含む。第１のトリプルは更に、元のインデクス及び元のパターン空間を含む。第２のトリプル５７０、５８０、５９０は、旧いパターン空間５４０、旧いインデクス５３０以外に、Ａ、Ｃ、Ｄ５６０を含む新たなヘッダへのポインタを含む。インデクスがこのインスタンスにおいて共有される。列が削除されているが、この場合において列Ｂがないことにもかかわらず、同じレコードがパターン空間内に存在するからである。更に、トリプル５００、５１０、５２０を用いることにより、スキーマ変更の前に存在した形式のデータをクエリすることが可能であり、トリプル５７０、５８０、５９０を用いることにより、スキーマ変更後に存在した状態をクエリすることが可能である。

テーブル内のフィールドが多数存在している場合、単一の列を削除するために、ｎ−１個のフィールド・エントリを複製することは不経済と考えられ得る。したがって、本発明の別の実施例によれば、ヘッダは、先行するヘッダに対するポインタ、及びこのヘッダに対して行われる変更（又は「デルタ」）のリストを含む。このようにして情報を記憶することはいくつかの理由で効果的であるが、大量の記憶空間を節減し、データの特に効率的な回復を可能にする。

図６は、本発明の実施例による、列情報を取り出すための手順の例を示す。ユーザ要求に応じて、工程６１０では、クエリ・マネージャ１０５は、ヘッダの鎖の先頭から開始し、そのヘッダが関心の列（すなわち、この場合においてユーザが削除したい列）を定義するかを検査する。肯定の場合、クエリ・マネージャ１０５は、その列の列情報を取り出し、列が、削除されたとしてマーキングされているかを検査する（６４０）。当該項目が削除されたものとしてマーキングされていない場合、クエリ・マネージャ１０５はその列のデータを返す。さもなければ、クエリ・マネージャ１０５は、鎖における次のヘッダに移動し（６３０）、工程５１０からもう一度始めて検査を繰り返す。この方法を使用して列を削除するために、クエリ・マネージャ１０５は、列が削減されている旨を表示するための特殊マーカをヘッダに入れる。限定列挙でないが、削除を示す旨の追加のフラグ属性をヘッダ情報に加える工程、列のタイプをナルにセットする工程等を含む、これを行うための多くのやり方が存在している。図６に示す例では、列が削除された（６４０）としてマーキングされ、次いで、列が存在していない（６５０）旨を示すためにエラーを返す。工程６４０において削除されたとして列がマーキングされていない場合、クエリ・マネージャ１０５は、ヘッダから情報を返す（６６０）。

多数のスキーマ変更が行われた場合、使用するのに扱いにくい長いヘッダ鎖が存在し得る。したがって、本発明の更なる実施例は、前述の要素全ての効果を合成する単一のヘッダに、鎖内の２つ以上の要素を合体させることを可能にする。例証するために、以下の例を記載する。３つのスキーマ変更（すなわち、「列Ｂの削除」、「列Ｄの削除」及び「列Ａの削除」）が行われる、上記の例をたどる。この例では、結果は、（元のものを含む）４つのヘッダとなる。一実施例によれば、各ヘッダが、先行するヘッダに対するポインタ、及び最後のヘッダが作成されてから行われる変更のみを含むように「デルタ」が利用される。

したがって、ヘッダ０は、
Ａ，ＩＮＴＥＧＥＲ，．．
Ｂ，ＣＨＡＲ（２０），．．
Ｃ，ＤＡＴＥ，．．
Ｄ，ＦＬＯＡＴ（１５），．．
であり得る。

最初のスキーマ変更後、ヘッダ１はその場合、
Ｂ，ＮＵＬＬ，．．
＜ｈｅａｄｅｒ ０＞である。

（タイプをナルにセットすることは、列が削除されている旨を示す１つのやり方である。）
ヘッダ２は、
Ｄ，ＮＵＬＬ，．．
＜ｈｅａｄｅｒ １＞
である。

ヘッダ３は、
Ａ，ＮＵＬＬ，．．
＜ｈｅａｄｅｒ ２＞
である。

前述の例示的なヘッダが合体された場合、４つのヘッダの組み合わせた効果を表す単一のヘッダを生成するようデルタが「集められる」。これは、再帰プロセス（例えば、ｃｏａｌｅｓｃｅ（ｈｅａｄｅｒ３）＝ｒｅｍｏｖｅ（Ａ，ｃｏａｌｅｓｃｅ（ｈｅａｄｅｒ２））等）とみなし得る。この例示的なプロセスが施された場合、結果は例えば、ヘッダ
Ｃ，ＤＡＴＥ，．．．
である。

この実施例によれば、このヘッダは、何れの他のヘッダも指し示さないが、それは、完全にスタンドアロンであり、先行して存在していた何れかの他のヘッダと無関係に動作するからである。

２． 列の改名
本発明の実施例によれば、列が改名されると、ヘッダ３００においてその列の新たな名前を割り当てるだけでよい。例えば、ユーザが、上述の例（上記参照）における列「Ｂ」を「Ｅ」に改名しようとした場合、結果として生じるヘッダは、

になる。

その名称から離れた列の属性全てが変わらない状態にどのようにして留まるかに留意する。ヘッダ鎖を使用する場合、改名された列を定義するのみならず、旧い名前を隠す鎖の要素を提供することが必要である。例えば、

である。

３．列を追加する。

リレーショナル・データベースに、新たな列を加える場合、その列に保持された初期値を定義することが必要である。明らかに、既存のテーブルはこの列を含まず、データベースは、その列に対する要求によって返される値を知る必要がある。前述の値は、ナル、列のリテラルのデフォルト値として、又は、テーブル内の別の列に保持された値の関数として規定される。本発明の実施例によれば、これが、各フィールドの属性の１つである「経路」オブジェクトの使用の根拠である。

上述の通り、経路は、ナビゲーション要素及び機能要素を組み合わせる。新たな列のデフォルト値が、パターン空間に既に現れているリテラル値又はナル値である場合、パターン空間２４０からその値を取り出す経路をこの列に割り当てることが可能である。リテラル値が、現在のパターン空間に現れていない場合、ナビゲーション情報はないが、リテラル値を返す経路の終点における単純な関数を有する経路を追加することが可能である。

以下には、より複雑な関数が関係する列を加える例証的な例を示す。元のテーブルが、「コスト」及び「価格」と呼ばれる（とりわけ）２つの列を含んでいるとする。例えば、

である。

ユーザが、新たな列（この例では、「利益」と呼ばれ、その値が「価格−コスト」になる）をテーブルに追加しようとする場合、このことを行うために、レガシー・データ・マネージャ１０は、やはりナビゲーション要素を有しない経路を作成するが、「価格・コスト」を計算し、その値を返す機能要素を有する。

ユーザが列をデータ・テ―ブルに加える場合、データがどのようにして記憶されるかにはいくつかの可能性が存在している。例えば、一実施例によれば、元のデータ・テーブルが、＜ｈｅａｄｅｒ，ｉｎｄｅｘ，ｐａｔｔｅｒｎ，ｓｐａｃｅ＞というトリプルとして記憶され、新たなデータが＜ｈｅａｄｅｒ’，ｉｎｄｅｘ’，ｐａｔｔｅｒｎ ｓｐａｃｅ’＞というトリプルとして記憶され、ここで、ｐａｔｔｅｒｎ ｓｐａｃｅ’は、新たなデータ及び元のデータ全ての複製である（すなわち、パターン空間＋更なるデータ（δ））。別の実施例によれば、変更（この場合、列を加えること）がデータベースに対して行われると、更なるデータ（δ）は、単に、更なるデータ及び元のデータを含む別個のパターン空間を有することなく、元のパターン空間に記憶することができる。すなわち、一実施例によれば、パターン全てのレポジトリである単一のパターン空間が存在しており、新たなヘッダ及びインデクスのみが、スキーマ変動を反映するために作成される。変更が行われる都度、新たなヘッダ及びインデクスを作成することが可能であり、更なるデータ・パターンがパターン空間に加えられる。前述の２つの可能性は図７Ａ及び図７Ｂに示す。

熟練した読者に明らかになるように、構成部分（ヘッダ、インデクス、パターン空間）の種々の組み合わせにおけるデータをアーカイブするための種々の可能性は、列の追加だけでなく、適切なデータベース変更全てにあてはまる。

４． 列の再タイプ
列の再タイプは一般に、下にあるアプリケーションが変わる場合に生じる。例えば、実動システムは、トランザクションに対する日付及び時間を記録し始め得、又は、ドルのみでなく、ドル及びセントで価格を記録し得る。列のタイプが変わると、これは、その列の将来の値が、アーカイブに既に入れられている値とは異なる表現を使用する。新たな表現に一致させるためにアーカイブに既にある値全てを変えることが可能であるが、それは、長く、多くの場合、費用がかかる処理であることは言うまでもなく、アーカイブされた元のデータの破壊、及び長く、多くの場合、高価な処理を意味する。ユーザは、新たな値と組み合わせて旧い値にクエリしたい場合、新たな値と同じ表現を使用するよう旧い値を変換することが必要になる。更に、値自体が、パターン空間の一部であるので、場所を変換することは可能でない。

本発明の実施例によれば、変換は、やはり経路構造を使用することによって実現することが可能である。スキーマの変更後、システムは、列のタイプが新たなタイプに一致するようにヘッダ・エントリを書き直す。この列の属性に記憶された経路はこの場合、先行する経路の複製になり、更なる関数が経路の終点に加えられる。この更なる関数は、先行して返され、新たなタイプによって要求された表現に書き換える値を得る。例として、元のフィールドが「価格」と呼ばれ、整数値を有しており、例えば、ＤＥＣＩＭＡＬ（６，２）に精度を向上させるようスキーマ変更が行われた場合、この例示的な新たなタイプは、６桁を有する固定小数を表し、６桁のうちの２桁は、小数点の右側である。前述の数を表すための１つのやり方は、整数として記憶するが、何らかの結果を表示する前に適切に変換することである。例えば、値４３．５７は内部的に整数４３５７として記憶することが可能である。

したがって、本発明の実施例によれば、特定のタイプ（例えば、ＤＥＣＩＭＡＬ（６，２）のもの）を有し、その経路が先行する経路の複製であるが、経路の終点に新たな関数が加えられている新たなエントリ（例えば、「価格」）をヘッダに割り当てることが可能である。この関数は、元の表現における値を得て、それを一係数（例えば、１００）で乗算して、その表現を、新たなデータによって使用されるものと一致させている。この新たなスキーマ下では、例えば、３５として記憶された値は、３５００としてクエリに経路によって返される。

一時点におけるクエリ
ユーザが、アーカイブにクエリしたく、特に、時間上、特定のインスタンスでのデータにクエリしたい場合、その時点において提示されたデータのみならず、そのデータに施されるスキーマも識別することが重要である。上記から明らかであるように、スキーマ変更がアーカイブに施される都度、システムは、アーカイブにおけるテーブル及びサブテーブル毎に＜ｈｅａｄｅｒ，ｉｎｄｅｘ，ｓｐａｃｅ＞という新たなトリプルを作成する。システムは更に、スキーマが変更された日時で前述のトリプルをマーキングする。ユーザが特定の時点でのアーカイブの状態をクエリしたい場合、システムは、その時点において存在していたデータを回復し、次いで、テーブルの一部を表すパターン空間毎に、システムは、その時点でアクティブであった対応するトリプルを求める。システムが、前述のトリプルを併せて収集すると、その場合、その時点でのデータベースに対するクエリを実行するための適切な手段を有する。

６． 列の分割／マージ
列の分割は、新たな２つの列の追加（上記項番３参照）及び１つの列の削除（上記項番１参照）の組み合わせとしてみなし得る。同様に、列のマージは、２つの列の削除及び新たな１列の追加とみなし得る。

図８は、本発明の実施例による、経路を使用して値が取り出される処理を示す。工程８００では、クエリ・マネージャ１０５は、＜ｈｅａｄｅｒ，ｉｎｄｅｘ，（ｐａｔｔｅｒｎ）ｓｐａｃｅ＞というトリプルであるテーブルの表現及び経路から開始する。経路が、ナビゲーション情報８１０を含む場合、ナビゲーション情報は、インデクスによって識別される初期パターンから始まるパターン空間から値を取り出すためにクエリ・マネージャ１０５によって使用される（８２０）。ナビゲーション情報が存在しない場合、有用なデフォルト（例えば、「ナル」）が値に割り当てられる（８３０）。経路が、少なくとも１つの関数８４０を含む場合、システムは、新たな値を得るために（８５０）関数を現在の値に加える。システムは更に、テーブル・トリプルを関数に渡す。このことは、関数を使用して、テーブルからの更なる１つ又は複数の値に基づいて結果を取り出し、計算することも可能である旨を意味する。施すための関数がもうない場合（８７０）、システムは通常、実動システム３０又は端末４０に、経路により、取り出しされた（８６０）現在の値を返す。

本明細書及び特許請求の範囲が、最善のモードであると考えられるものが何であるか、及び適切な場合、本発明を実行する他のモードを開示するが、本発明は、好ましい実施例の説明に開示された特定の構成及び方法に限定されない。

Claims (40)

1. データ記憶装置にデータを記憶し、前記データ記憶装置からデータを取り出すためにコンピュータ・システムを動作させる方法であって、前記コンピュ―タ・システムは、元の形式における前記記憶データの再構成を可能にするやり方でパターンに関連付けられたポインタとともに、前記記憶データにおけるパターンを管理するよう動作可能なデータ・マネージャ装置を有し、前記方法は、
   第１の時点におけるデータ・テーブル・エントリを併せて表すポインタ・データ及びパターン空間情報とともに第１の時点で使用されるスキーマを施す第１のデータ・テーブル・エントリを記憶する工程と、
   スキーマ変更に応じたマップを後の時点で生成する工程であって、前記マップが、新たなポインタ・データ及び／又は新たなパターン空間情報を含む工程と
   を含む方法。
2. 請求項１記載の方法であって、ポインタ・データはテーブル・メタ・データ及びインデクス・データのうちの１つ又は複数を含む方法。
3. 請求項１又は２に記載の方法であって、ポインタ・データは、スキーマの局面を定義するヘッダ情報を含む方法。
4. 請求項２記載の方法であって、ポインタ・データはテーブル・メタ・データを含み、前記テーブル・メタ・データは、テーブルのフィールド、フィールドのタイプ、フィールドの最大値、フィールドの最小値、及びフィールドの別の属性から選択された１つ又は複数を含む方法。
5. 請求項２記載の方法であって、ポインタ・データは、パターン空間内のパターン要素の順序を規定するインデクス・データを含む方法。
6. 請求項５記載の方法であって、ポインタ・データは、制御機能がパターン要素をどのようにして横移動すべきかを規定する経路データを含む方法。
7. 請求項６記載の方法であって、経路データが、１つ又は複数の変換に関する命令を含む方法。
8. 請求項１乃至７の何れか一項に記載の方法であって、ポインタ・データは前記パターン空間の少なくとも一部分を複製する方法。
9. 請求項１乃至８の何れか一項に記載の方法であって、ポインタ・データの少なくとも一部分は不変である方法。
10. 請求項１乃至９の何れか一項に記載の方法であって、スキーマ変更により、前記マップに、旧いポインタ情報に対する変更を示させる方法。
11. 請求項１乃至１０の何れか一項に記載の方法であって、スキーマ変更により、前記マップに、合体されたポインタ情報を示させる方法。
12. 請求項１１記載の方法であって、再帰処理は、合体されたポインタ情報からのデータ・エントリを求めるよう使用される方法。
13. 請求項１乃至１２の何れか一項に記載の方法であって、前記スキーマ変更は、列を削除する工程を含み、前記マップは新たな列、旧いインデクス・データ、及び旧いパターン空間情報を含む方法。
14. 請求項１乃至１２の何れか一項に記載の方法であって、前記スキーマ変更は、列を改名することを含み、前記マップは新たな列名、及び隠す対象の旧い列名を含む方法。
15. 請求項１乃至１２の何れか一項に記載の方法であって、前記スキーマ変更は列を追加する工程を含み、前記マップは、ナル値、リテラルのデフォルト値、及び別の列における値の関数から選択された新たな列情報を示す方法。
16. 請求項１５記載の方法であって、前記マップは、少なくとも部分的に、経路データへの参照により、新たな列情報を示す方法。
17. 請求項１６記載の方法であって、前記経路データは、ナビゲーション・データ及び機能要素のうちの１つ又は複数を含む方法。
18. 請求項１乃至１２の何れか一項に記載の方法であって、前記スキーマ変更は列の再タイプを含み、前記マップは、新たな列におけるエントリにつながる少なくとも一変換を示す方法。
19. 請求項１８記載の方法であって、前記スキーマ変更は列を再タイプする工程を含み、前記変換は、少なくとも部分的に経路データで規定される方法。
20. 請求項１乃至１９の何れか一項に記載の方法であって、前記方法は更に、先行する時点における記憶データをクエリする工程を含み、データ・マネージャは、スキーマ変更に応じて生成された少なくとも１つのマップにアクセスして、その先行する時点におけるクエリをサポートするデータを導き出す方法。
21. 請求項１乃至１２の何れか一項に記載の方法であって、前記スキーマ変更は、列を分割することを含み、前記データ・マネージャは新たな列の追加、及び列名の削除に関するマップ・データを生成する方法。
22. 請求項１乃至１２のうちの何れか一項に記載の方法であって、前記スキーマ変更は、列をマージする工程を含み、前記データ・マネージャは新たな少なくとも１つの列の追加、及び列の削除に関するマップ・データを生成する方法。
23. データ記憶装置にデータを記憶し、前記データ記憶装置からデータを取り出すコンピュータ・システムであって、
    元の形式で前記記憶データの再構成を可能にするやり方でパターンに関するポインタとともに前記記憶データにおけるパターンを管理するよう動作可能なパターン・マネージャ装置と、
    第１の時点におけるデータ・テーブル・エントリを併せて表すポインタ・データ及びパターン空間情報とともに第１の時点で使用されるスキーマを施す第１のデータ・テーブル・エントリを記憶する記憶装置と、
    スキーマ変更に応じてマップを後の時点で生成するマップ生成器と
    を備え、前記マップは、新たなポインタ・データ及び／又は新たなパターン空間情報を含むコンピュータ・システム。
24. データ記憶装置にデータを記憶し、データ記憶装置からデータを取り出すコンピュータ・システムであって、前記コンピュータ・システムは、（ｉ）前記データ記憶装置内の複数のデータ・テーブル、及び（ｉｉ）前記データ・テーブルの生成に施される複数のスキーマに関する補助データを生成し、管理するよう動作可能なデータ・マネージャ装置を備え、前記補助データは、データ・テーブルの個々のフィールド値をパターン空間から求めることが可能な参照データ、及び前記データ記憶装置のパターン空間内の少なくとも１つのパターンの表示を含むコンピュータ・システム。
25. アーカイブされたデータを処理する、コンピュータによって実現される方法であって、
    時点Ｔにおいてデータ・レポジトリからアーカイブに抽出データを転送する工程であって、前記データが、時点Ｔにおける第１のスキーマによって表される工程と、
    （ｉ）ヘッダ部分、（ｉｉ）インデクス部分、及び（ｉｉｉ）前記アーカイブにおける少なくとも１つのパターン空間に向けたポインタの組み合わせとしての少なくとも１つの抽出データを記憶する工程であって、
    前記ヘッダ部分は、前記データ・レポジトリにおいて存在した形式のデータを回復するために前記パターン空間におけるパターンをどのようにして解釈するかに関する情報を含み、前記インデクス部分は、前記レポジトリからのデータ・レコード全体を表すパターン空間内からのパターンを識別する工程と、
    Ｔよりも遅い時点でデータ・クエリを受信する工程であって、前記レポジトリにおける前記データ・スキーマが、前記第１のスキーマと異なる第２のスキーマに変更された工程と、
    前記第２のスキーマ下で作成されたかのように前記第１のスキーマがクエリに応じて挙動するように、前記ヘッダ部分、前記インデクス部分、及び前記パターン空間におけるデータを利用する前記アーカイブからのデータをデータ・クエリに応じて返す工程とを含む方法。
26. 請求項２５記載の方法であって、クエリする工程は、データに対して変換を行う工程を更に含む方法。
27. 請求項２６記載の方法であって、前記変換は、列の削除、列の改名、列の追加、列の再タイプ、一時点におけるクエリ、列の分割、列のマージのうちの１つ又は複数から選択される方法。
28. 請求項２５記載の方法であって、前記少なくとも１つの抽出データが不変データとして記憶される方法。
29. 請求項２５記載の方法であって、前記ヘッダ部分は少なくとも、（ｉ）テーブルのレコード内に存在するフィールドの名称、及び（ｉｉ）前記フィールドのタイプを含む方法。
30. 請求項２５乃至２９の何れか一項に記載の方法であって、前記データ・レポジトリがリレーショナル・データベースである方法。
31. 請求項２５乃至２９の何れか一項に記載の方法であって、前記データ・レポジトリがデータ・ウェアハウスである方法。
32. 請求項２５乃至２９の何れか一項に記載の方法であって、前記データ・レポジトリがスター・スキーマ・データベースである方法。
33. コンピュータ・システムにおいて使用するためのデータ構造であって、前記データ構造は、
    （ｉ）パターン空間に対するポインタであって、前記パターン空間は、元のデータ・ソースにおいて発見されている１つ又は複数のパターンを含むポインタと、
    （ｉｉ）インデクス部であって、インデクス領域は、前記元のデータ・ソースからのデータ・レコード全体を表す前記パターン空間内からのパタ―ンを識別するインデクス部と、
    （ｉｉｉ）ヘッダ部分であって、前記ヘッダ部分は、データ・レポジトリに存在した形式でデータを回復するために前記パターン空間における前記パターンをどのようにして解釈するかを表すメタデータを含むヘッダ部分と
    を備え、
    併せて、前記パターン空間に対するポインタ、前記インデクス、及び前記ヘッダは、一時点におけるデータ・ソースの状態を表す抽出データを構成するデータ構造。
34. 請求項１乃至３３のうちの何れか一項に記載のデータ構造であって、前記２つ又は複数の抽出データは、単一のパターン空間を共有するデータ構造。
35. アーカイブされたデータをクエリする方法であって、前記方法は、
    前記データをテーブルＴに記憶する工程であって、Ｔは、２つ以上の抽出データ・テーブルＴｌ，Ｔ２，Ｔ３．．．ＴＮの和集合であり、各抽出データ・テーブルが、アーカイブに記憶され、そのデータを表す別のスキーマを有する工程と、
    抽出データ・テ―ブルＴｌ， Ｔ２， Ｔ３．．．ＴＮ間の各スキーマ変更を表すマップを生成する工程と、
    前記抽出データ・テーブルのうちの１つに含まれるデータに対するユーザ要求をクエリ・マネージャにおいて受信する工程と、
    第２の抽出データ・テーブルのスキーマ下で作成されたかのようにクエリに応じて、それを表すデータが挙動するように前記クエリ・マネージャは第１の抽出データ・テーブルのスキーマに再書き込みするように適切なマップを施す方法。
36. 請求項３５記載の方法であって、各抽出データが不変データを含む方法。
37. レガシー・データ・マネージャであって、
    少なくとも１つの実動システムからデータを受信するよう構成されたインタフェースと、
    前記データを受信し、前記データにおけるパターンを求め、識別されたパターンをメモリに記憶し、ポインタを使用してパターンの表現を生成するよう動作可能なパターン識別器と、
    前記データを受信し、インデクス領域を識別し、前記メモリにインデクスを記憶し、ポインタを使用してインデクスの表現を生成するよう動作可能なインデクス・マネージャと、
    ヘッダ領域を規定し、それをメモリに記憶し、ポインタを使用してヘッダの表現を生成するよう動作可能なヘッダ・マネージャと、
    前記メモリからアーカイブにデータを転送するよう構成された記憶装置上の少なくとも１つのデータ・アーカイブとのインタフェースと
    を備えるレガシー・データ・マネージャ。
38. データをアーカイブするコンピュータ・システムであって、
    請求項３７記載のレガシー・データ・マネージャと、
    動作するよう前記レガシー・データ・マネージャに接続された記憶装置上に常駐している少なくとも１つのデータ・アーカイブと、
    前記レガシー・データ・マネージャに、動作するよう接続され、データを生成するよう動作可能な少なくとも１つの実動システムと
    を備えるコンピュータ・システム。
39. 請求項３８記載のコンピュータ・システムであって、動作するよう、前記実動システム及び／又はレガシー・データ・マネージャに少なくとも１つのユーザ端末を接続し、データ・クエリを受信するよう構成された少なくとも１つのユーザ端末インタフェースを更に備えるコンピュータ・システム。
40. 請求項３９記載のコンピュータ・システムであって、前記ユーザ端末は、パーソナル・コンピュータ、シン・クライアント装置、又は何れかの他の適切な電子装置であるコンピュータ・システム。
    

Images