(57)【要約】本発明は、スキーマ（２４）にしたがったデータベース管理システムを提供するため、電子演算処理装置によって実行される機械が読み出し可能な命令を含むコンピュータソフトウェア製品（１８）を提供し、このスキーマは、各種エンティティタイプ名を記憶するための第１テーブル（３４）と、各種エンティティタイプのエンティティ名を記憶するための、第１テーブルと関連した第２テーブル（３６）と、各種エンティティタイプに関してフィールド名を記憶するための、第１テーブルと関連した第３テーブル（３８）と、記憶したフィールド値をエンティティと関連づけるための、第２テーブルおよび第３テーブルに関連した１以上の値記憶テーブル（４０）とを備えている。スキーマは、上記の各テーブルに記憶するデータの性状を示唆する識別子、たとえば「ＥｎｔｉｔｙＴｙｐｅ」、「Ｅｎｔｉｔｙ」、「Ｆｉｅｌｄ」、「ＦｉｅｌｄＴｙｐｅ」を含んでいる。
2006524376.tif 000002
【特許請求の範囲】
【請求項１】
電子演算処理装置によって実行される機械が読み出し可能な命令を含む、スキーマにしたがったデータベース管理システムを提供するコンピュータソフトウェア製品であって、スキーマが、
各種エンティティタイプ名を記憶する第１テーブルと、
各種エンティティタイプに関してエンティティ名を記憶する、第１テーブルと関連した第２テーブルと、
各種エンティティタイプに関してフィールド名を記憶する、第１テーブルと関連した第３テーブルと、
記憶したフィールド値をエンティティと関連づけるための、第２テーブルおよび第３テーブルに関連した１以上の値記憶テーブルと、
上記の各テーブルに記憶するデータの性質を示唆する識別子と
を備えているコンピュータソフトウェア製品。
【請求項２】
前記スキーマが、第１テーブルに適用される第１階層関係と、第２テーブルに適用される第２階層関係を含んでおり、階層的なエンティティの定義の便宜がはかられている請求項１記載のコンピュータソフトウェア製品。
【請求項３】
前記スキーマが、各エンティティ間の関係を記憶するテーブルを含んでいる請求項１記載のコンピュータソフトウェア製品。
【請求項４】
第１テーブルが、エンティティタイプに対応したポインタを記憶するカラムを備えており、ポインタが、エンティティタイプの新しいインスタンスを作成する間にデフォルト値を得ることが可能な位置を示唆している請求項１記載のコンピュータソフトウェア製品。
【請求項５】
第３テーブルが、データを記憶するカラムを含んでおり、このことから、新たに作成されたエンティティ名は、１以上の値記憶テーブルのカラムに記憶されたデータから生成するものであることが示唆される請求項１記載のコンピュータソフトウェア製品。
【請求項６】
１以上の値記憶テーブルが、いくつかの値テーブルを含んでおり、そのそれぞれが、特定タイプの値のカラムを含んでいる請求項１記載のコンピュータソフトウェア製品。
【請求項７】
値テーブルの１以上を、それぞれ、スキーマの１以上の他のテーブルと関連させた請求項６記載のコンピュータソフトウェア製品。
【請求項８】
値テーブルの１以上を、それぞれ第２テーブルと関連させた請求項７記載のコンピュータソフトウェア製品。
【請求項９】
値テーブルの１以上を、ポインタを、コンピュータソフトウェア製品によって作成されるデータ構造の外側に記録されているデータに記録するよう配置した請求項８記載のコンピュータソフトウェア製品。
【請求項１０】
前記スキーマが、値記憶テーブル名を、特定タイプの値のカラムの対応名に関連付けるデータタイプのテーブルを含んでいる請求項６記載のコンピュータソフトウェア製品。
【請求項１１】
前記データタイプのテーブルが、第３テーブルと関連付けられている請求項１０記載のコンピュータソフトウェア製品。
【請求項１２】
前記データタイプのテーブルが、中間の値のタイプのテーブルと関連づけられており、値のタイプのテーブルが、第３テーブルを指している請求項１１記載のコンピュータソフトウェア製品。
【請求項１３】
第３テーブルが、複数のフィールドの機能性を定義するためのカラムを含んでいる請求項１記載のコンピュータソフトウェア製品。
【請求項１４】
第３テーブルが、履歴データ値を、対応データ値に関して記憶すべきなのかどうかを示唆するためのカラムを含み、値記憶テーブルが、それぞれ、上記フィールドタイプの現在の値を記憶し、現在値がいつ書かれたのかを示唆するデータを記憶ためのカラムを含んでいる請求項６記載のコンピュータソフトウェア製品。
【請求項１５】
第３テーブルが、新たに作成されたエンティティのインスタンスの値を、あるエンティティの別のインスタンスから受けつぐべきかについて示唆する値を記憶するためのカラムを含んでいる請求項６記載のコンピュータソフトウェア製品。
【請求項１６】
前記スキーマが、データ記憶フォーマットを記憶するためのカラムを持つフォーマット・テーブルを含んでいる請求項６記載のコンピュータソフトウェア製品。
【請求項１７】
前記スキーマが、フィールドのセットのグルーピングを示唆する値を記憶するための１以上の表を含んでいる請求項６記載のコンピュータソフトウェア製品。
【請求項１８】
電子演算処理装置によって、データを記憶する際に実施される方法であって、このデータが、各種エンティティタイプのエンティティ数および各種エンティティタイプ間の関係に関するものであり、
第１テーブルの各エンティティタイプについての識別子を保存し、
第１テーブルと関連した第２テーブルの各エンティティ数についての識別子を記憶し、
第１テーブルと関連した第３テーブルの各種エンティティタイプについての各フィールドタイプ数についての識別子を記憶し、そして
第２および第３テーブルと関連した１以上の値記憶テーブルのエンティティに関連したフィールド値を記憶する工程を含む方法。
【請求項１９】
第１階層関係を第１テーブルに適用し、第２階層関係を第２テーブルに適用することによって階層的エンティティを記憶する工程をさらに含む請求項１８記載の方法。
【請求項２０】
エンティティ同士の関係を定義する１以上のテーブルにデータを記録する工程をさらに含む請求項１８記載の方法。
【請求項２１】
関係を定義するデータを記憶する工程が、
各種の関係のタイプを特定するデータを第５テーブルに記憶し、そして
各種関係を特定するデータを第６テーブルに記憶する工程を含む請求項２０記載の方法。
【請求項２２】
請求項１８の方法によって操作される計算装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース、およびデータベースのスキーマに関する。
【背景技術】
【０００２】
今日のビジネス環境では、データベース管理システム（ＤＢＭＳ）が広く使用されている。ＤＢＭＳはそのほとんどが、リレーショナルデータベースに記録されたデータを操作するように構成されている。リレーショナルデータベースには、データベース内で規定されたさまざまなエンティティタイプの間に存在する関係が記述されている。この関係とエンティティタイプは、スキーマダイアグラムという形でグラフィックに提示されることが多い。スキーマダイアグラムでは、テーブルのカラム名からなるフィールドリストを四角く描き、エンティティタイプを描写する。エンティティタイプを示す四角形のリストはラインで結ばれており、このラインがエンティティ間の関係を表す。
【０００３】
あるアプリケーションを実現するリレーショナルデータベースを設計するためには、通常、適切なスキーマを生成できるように、エンティティを分析するとともにアプリケーションで必要となる関係を求めるという膨大な作業が必要となる。モデル化したアプリケーションに変更が加えられることも多いが、そのような場合、スキーマも更新しなければならないし、それに伴い、ＤＢＭＳも更新しなければならないことが多い。そして、そのデータベースにアクセスするソフトウェアアプリケーションにも変更を加えなければならなくなることが多い。たとえば、新しいエンティティタイプを導入したり、あるエンティティタイプのフィールドを変更したり、新しいフィールドをあるエンティティタイプに追加したり、エンティティタイプ間の関係を変更したりするためには、スキーマの更新が必要となることがある。スキーマが複雑になると、通常、スキーマ更新にともなうオーバーヘッドは指数関数的に増大する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
通常のモデル化手法には、少なくともふたつの問題があることがわかる。第１は、アプリケーションごとに新しいスキーマダイアグラムを作成しなければならない点である。第２は、既存スキーマの更新や、必要に応じて行う関連ＤＢＭＳおよびソフトウェアアプリケーションの再構成が、膨大なオーバーヘッドを生じる点である。
【０００５】
本発明の目的は、上記課題へ取り組むのに都合のよい手段を提供することにある。
【課題を解決するための手段】
【０００６】
本発明の第１の観点では、電子演算処理装置によって実行される機械が読み出し可能な命令を含む、スキーマにしたがったデータベース管理システムを提供するコンピュータソフトウェア製品であって、スキーマが、
各種エンティティタイプ名を記憶する第１テーブルと、
各種エンティティタイプに関してエンティティ名を記憶する、第１テーブルと関連した第２テーブルと、
各種エンティティタイプに関してフィールド名を記憶する、第１テーブルと関連した第３テーブルと、
記憶したフィールド値をエンティティと関連づけるための、第２テーブルおよび第３テーブルに関連した１以上の値記憶テーブルと、
上記の各テーブルに記憶するデータの性質を示唆する識別子と
を備えているコンピュータソフトウェア製品を提供する。
【０００７】
前記スキーマは、第１テーブルに適用される第１階層関係と、第２テーブルに適用される第２階層関係を含んでおり、階層的なエンティティの定義の便宜がはかられていることが好ましい。
【０００８】
好適な態様では、前記スキーマは、各エンティティ間の関係を記憶するテーブルを含んでいる。
【０００９】
好ましくは、第１テーブルが、エンティティタイプに対応したポインタを記憶するカラムを備えており、ポインタが、エンティティタイプの新しいインスタンスを作成する間にデフォルト値を得ることが可能な位置を示唆している。
【００１０】
第３テーブルは、データを記憶するカラムを含むことができ、このことから、新たに作成されたエンティティ名は、１以上の値記憶テーブルのカラムに記憶されたデータから生成するものであることが示唆される。
【００１１】
好ましくは、１以上の値記憶テーブルが、いくつかの値テーブルを含んでおり、そのそれぞれが、特定タイプの値のカラムを含んでいる。
【００１２】
一態様では、値テーブルを、それぞれ、スキーマの１以上の他のテーブルと関連させてある。
【００１３】
好ましくは、値テーブルを、それぞれ第２テーブルと関連させてある。
【００１４】
値テーブルは、ポインタを、コンピュータソフトウェア製品によって作成されるデータ構造の外側に記録されているデータに記録するよう配置することができる。
【００１５】
好適態様では、スキーマが、値記憶テーブル名を、特定タイプの値のカラムの対応名に関連付けるデータタイプのテーブルを含んでいる。
【００１６】
前記データタイプのテーブルは、第３テーブルと関連付けられていることが好ましい。
【００１７】
前記データタイプのテーブルは、中間の値のタイプのテーブルと関連づけることができ、値のタイプのテーブルは、第３テーブルを指している。
【００１８】
第３テーブルは、複数のフィールドの機能性を定義するためのカラムを含んでいることが好ましい。
【００１９】
第３テーブルは、履歴データ値を、対応データ値に関して記憶すべきなのかどうかを示唆するためのカラムを含むことができ、値記憶テーブルは、それぞれ、上記フィールドタイプの現在の値を記憶し、現在値がいつ書かれたのかを示唆するデータを記憶ためのカラムを含んでいる。
【００２０】
第３テーブルは、新たに作成されたエンティティのインスタンスの値を、あるエンティティの別のインスタンスから受けつぐべきかについて示唆する値を記憶するためのカラムを含んでいることが好ましい。
【００２１】
データ記憶フォーマットを記憶するためのカラムを持つフォーマット・テーブルを設けることができる。
【００２２】
好適態様では、前記スキーマが、フィールドのセットのグルーピングを示唆する値を記憶するための１以上の表を含んでいる。
【００２３】
本発明の別の観点では、電子演算処理装置によって、データを記憶する際に実施される方法であって、このデータが、各種エンティティタイプのエンティティ数および各種エンティティタイプ間の関係に関するものであり、
第１テーブルの各エンティティタイプについての識別子を保存し、
第１テーブルと関連した第２テーブルの各エンティティ数についての識別子を記憶し、
第１テーブルと関連した第３テーブルの各種エンティティタイプについての各フィールドタイプ数についての識別子を記憶し、そして
第２および第３テーブルと関連した１以上の値記憶テーブルのエンティティに関連したフィールド値を記憶する工程を含む方法を提供する。
【００２４】
この方法は、第１階層関係を第１テーブルに適用し、第２階層関係を第２テーブルに適用することによって階層的エンティティを記憶する工程をさらに含むことが好ましい。
【００２５】
この方法は、エンティティ同士の関係を定義する１以上のテーブルにデータを記録する工程をさらに含むことができる。
【００２６】
関係を定義するデータを記憶する工程は、
各種の関係のタイプを特定するデータを第５テーブルに記憶し、そして
各種関係を特定するデータを第６テーブルに記憶する工程を含むことが好ましい。
【００２７】
本発明の別の観点では、上述の方法によって操作される計算装置を提供する。。
【００２８】
本発明の各種の側面についてのさらなる好適な特徴については、以下の好適な態様についての説明から明らかとなるはずである。以下では、いくつかの図面に言及しつつ説明を行う。
【発明を実施するための最良の形態】
【００２９】
図１Ａは、本発明の一実施態様に従って作成されたソフトウェア製品を実行できるコンピュータシステムのブロック図である。システムには、モニタ６とキーボード４、マウス２０が含まれ、これらはいずれもボックス２に接続されている。このボックス２には、メインボード１０が内蔵されており、このメインボードは電子演算処理装置（ＣＰＵ）８とＲＡＭ１２、ＲＯＭ１４、通信ポート２２、２次記憶デバイスリーダ１６にインターフェースされている。２次記憶デバイスリーダはソフトウェア製品１８から命令を読み出す。ソフトウェア製品は、通常、光ディスクや磁気ディスク、ソリッドステートメモリなどの形態で提供されることが多い。使用時には、ＣＰＵ８が、ソフトウェア製品１８に記録された命令にしたがってコンピュータシステムを動かす。この命令により定義されるのが、これから説明するデータベースプログラム２６とデータベーススキーマ２４である。
【００３０】
本発明では、「データ抽象化」という用語は、標準的なデータベーススキーマ、すなわち、複数のテーブルとこれらのテーブルのカラム、フィールド間の関係で情報が定義され、かつ、各テーブルがそれぞれデータクラス（たとえばＣｌｉｅｎｔ）を表し、各カラムが保存するデータアイテム（たとえばＦｉｒｓｔ  Ｎａｍｅ）を表すものから、「抽象」データベーススキーマ、すなわち、テーブルとフィールド、関係というセットは一定不変とし、つまり、スキーマ（テーブル、フィールド、関係の設計）を変更することなく、その構成を変えることによって望みのクラスのデータを保存できるものへの変換プロセス意味する用語として用いる。
【００３１】
データ抽象化のごく簡単な例を、図１に示す。テーブルがＥｎｔｉｔｙ＊２８とＦｉｅｌｄ＊３０の２つあり、両者がひとつの関係３２で結合されている。
【００３２】
以下のフィールドを持つＣｌｉｅｎｔテーブルのマッピングを行うためには、
・  Ｆｉｒｓｔ  Ｎａｍｅ
・  Ｌａｓｔ  Ｎａｍｅ
・  Ｐｈｏｎｅ
・  Ａｄｄｒｅｓｓ
【００３３】
図１に示すスキーマでは、以下のステップを実行する。
１．  Ｅｎｔｉｔｙテーブルに、ＩＤ＝１、Ｎａｍｅ＝Ｃｌｉｅｎｔとしてレコードを入力する。
２．  Ｆｉｅｌｄテーブルに４つのレコードを入力する。各レコードの内容は、Ｌａｂｅｌ＝「上記フィールド名のいずれかひとつ」、ＥｎｔｉｔｙＩＤ＝１とする。
３．  次に、Ｆｉｅｌｄテーブルの適切なＶａｌｕｅカラムにデータを入力する。
【００３４】
上記の手順はある種のデータを２つのみのテーブルに保存する方法を示すものであるが、いくつかの欠点を持つことが明らかである。すなわち、
１．  これらのテーブルを、一定のクエリで検索することができない。
２．  各ＦｉｅｌｄのＬａｂｅｌがくり返されざるをえない。
３．  エンティティとフィールドを定義する構造がない。
【００３５】
その結果、上記の手順は、完全に抽象化したスキーマを構築する際には使用できない。
【００３６】
コア・アブストラクション・システム（ＣＡＳ）
図２に、本発明の第１の態様のデータ抽象化に用いる基本構造を示す。図２のスキーマは、それぞれＥｎｔｉｔｙＴｙｐｅ３４、Ｅｎｔｉｔｙ３６、ＦｉｅｌｄＴｙｐｅ３８、Ｆｉｅｌｄ４０という４つのテーブルからなり、各テーブルに保存されるデータの性質（後述）を示している。
【００３７】
図２のスキーマは、それぞれが独自のフィールドタイプ・セットを持つ、任意の数のエンティティタイプを構築・構成することができる。これらの構成ができれば、ＥｎｔｉｔｙＴｙｐｅテーブルとＦｉｅｌｄＴｙｐｅテーブルのクエリにより、あるエンティティの新しいインスタンスを保存するために必要なＥｎｔｉｔｙレコードとＦｉｅｌｄレコードを自動的に生成することができる。ここで注目すべき点は、フィールドラベルとしてＦｉｅｌｄ  ＴｙｐｅのＮａｍｅを用いるため、ＦｉｅｌｄテーブルからＬａｂｅｌカラムがなくなっていることである。
【００３８】
以下のフィールドを持つ標準「Ｃｌｉｅｎｔ」テーブルの抽象テーブルを定義するためには、
・  Ｆｉｒｓｔ  Ｎａｍｅ
・  Ｌａｓｔ  Ｎａｍｅ
・  Ｐｈｏｎｅ
・  Ａｄｄｒｅｓｓ
【００３９】
図２のスキーマで以下のステップを実行する。
１．  ＥｎｔｉｔｙＴｙｐｅテーブルに、ＩＤ＝１、Ｎａｍｅ＝Ｃｌｉｅｎｔとしてレコードを入力する。
２．  ＦｉｅｌｄＴｙｐｅテーブルに４つのレコードを入力する。各レコードの内容は、Ｌａｂｅｌ＝「上記フィールド名のいずれかひとつ」、ＥｎｔｉｔｙＩＤ＝１とする。
【００４０】
新しいＣｌｉｅｎｔ  Ｅｎｔｉｔｙを生成するには、
１．  Ｅｎｔｉｔｙテーブルに、ＥｎｔｉｔｙＴｙｐｅＩＤ＝１としてレコードをひとつ、入力する。
２．  Ｃｌｉｅｎｔ  ＥｎｔｉｔｙＴｙｐｅについて定義されたＦｉｅｌｄＴｙｐｅひとつに対してひとつとなるように、一連のＦｉｅｌｄレコードを入力する。その際、新しいＥｎｔｉｔｙにＥｎｔｉｔｙＩＤを割り当てるとともに、ＦｉｅｌｄＴｙｐｅＩＤを対応するＦｉｅｌｄＴｙｐｅテーブルのＩＤに割り当てる。
【００４１】
これで、新しいエンティティ名カラムと新しいフィールド値カラムに値を入力できるようになる。本スキーマでは、スキーマを変更することなく任意の数のＥｎｔｉｔｙＴｙｐｅを定義することが可能であり、また、保存されたデータをあらゆる側面から選択的かつ正確にクエリすることが可能である。
【００４２】
標準テーブル「Ｑｕｅｒｙ」と抽象テーブル「ｑｕｅｒｙ」で姓が「Ｓｍｉｔｈ」というレコードを検索するＳＱＬステートメントを比較すると、標準ＳＱＬは次のようになる。
ＳＥＬＥＣＴ  ＩＤ  ＦＲＯＭ  Ｃｌｉｅｎｔ  ＷＨＥＲＥ  Ｌａｓｔｎａｍｅ  ＝  ‘Ｓｍｉｔｈ’
【００４３】
これに対し、図２のＣＡＳスキーマで同じ動作を実現するステートメントは次のようになる。
ＳＥＬＥＣＴ  ＩＤ  ＦＲＯＭ  Ｅｎｔｉｔｙ
ＩＮＮＥＲ  ＪＯＩＮ  Ｆｉｅｌｄ  ＯＮ  Ｆｉｅｌｄ．ＥｎｔｉｔｙＩＤ  ＝  Ｅｎｔｉｔｙ．ＩＤ
ＷＨＥＲＥ  Ｅｎｔｉｔｙ．ＥｎｔｉｔｙＴｙｐｅＩＤ  ＝  １
ＡＮＤ  Ｆｉｅｌｄ．ＦｉｅｌｄＴｙｐｅＩＤ  ＝  ２
ＡＮＤ  Ｆｉｅｌｄ．Ｖａｌｕｅ  ＝  ‘Ｓｍｉｔｈ’
【００４４】
ＣＡＳ  ＳＱＬステートメントは複雑であるが、汎用性がある。標準スキーマの場合、新しいテーブルセットが定義されるたびに、新しいテーブルとカラムにアクセスする専用のＳＱＬが必要になる。抽象スキーマでは、新しいデータクラスが定義されても、上記のＳＱＬを用い、ＩＤをそれぞれにあわせて変更するだけで任意のＥｎｔｉｔｙＴｙｐｅとＦｉｅｌｄＴｙｐｅを取得できる。
【００４５】
もう１点、ＳＱＬについて違うのは、標準クエリの場合、ＳＥＬＥＣＴ  ＊に対してすべてのテーブルフィールドが返されるのに対し、ＣＡＳの場合は、「副選択」というＦｉｅｌｄ  Ｖａｌｕｅを返す関数が必要な点である。これらも、ＦｉｅｌｄＴｙｐｅの定義から自動的に生成可能であり、一貫性と汎用性を持つフィールドアクセスが実現できる。
【００４６】
コードで列挙子のシステムあるいはオブジェクトベースのＩＤサービスを使用しても、保存情報に高い信頼性でアクセスできる。これらは、データベースの内容から自動的に生成することができる。
【００４７】
以下に記述するその他のサービスも、データアクセスにおけるＳＱＬ構造と同じ一貫性と汎用性を持つ。
【００４８】
エンティティサービス
これらのサービスは、ＣＡＳのさまざまな機能を表す。
【００４９】
以下の「サービス」は、ＣＡＳと組みあわせて使用すれば、さまざまな機能を実現できる各種のサポートサービスである。記述するサービスはそれぞれＣＡＳを拡張し、新しい機能を付与するものである。
【００５０】
ここで重要な点は、これらのサービスをＣＡＳに一体化すれば、さらに広汎な標準スキーマアーキテクチャと標準スキーマ手法をＣＡＳで代替できるようになる点である。
【００５１】
エンティティ階層のサポート
エンティティテーブルを階層構造とすると有益である。こうすると階層「骨格」が形成されるとともに、エンティティのフォルダやディレクトリが作れるようになる。
【００５２】
図３では、図示するように、ＥｎｔｉｔｙＴｙｐｅテーブルが、同じテーブルのＩＤに関係づけられたＰａｒｅｎｔＥｎｔｉｔｙＴｙｐｅＩＤカラムを持っている。この構造はＥｎｔｉｔｙテーブルにも反映されており、そのＰａｒｅｎｔＥｎｔｉｔｙＩＤが同じテーブルのＩＤに関係づけられている。
【００５３】
このようにすると、ＥｎｔｉｔｙＴｙｐｅ定義で階層が定義できるようになり、Ｅｎｔｉｔｙテーブルに新しいエンティティが入力される際にその階層を反映できるようになる。
【００５４】
ＥｎｔｉｔｙＴｙｐｅテーブルでＰａｒｅｎｔＥｎｔｉｔｙＴｙｐｅＩＤがＮＵＬＬ（未定義）に定義されているものは、階層のＲｏｏｔ  Ｎｏｄｅであると判断される。Ｒｏｏｔ  Ｎｏｄｅタイプのエンティティは、また、ＮＵＬＬ値のＰａｒｅｎｔＥｎｔｉｔｙＩＤを持ち、ＥｎｔｉｔｙテーブルのＲｏｏｔ  Ｎｏｄｅとなる。
【００５５】
フォルダやディレクトリのサポート
階層構造においてプレースホルダーとなるフォルダやディレクトリを表すＥｎｔｉｔｙＴｙｐｅは、図４のようにＥｎｔｉｔｙＴｙｐｅテーブルにＩｓＦｏｌｄｅｒブールカラムを導入するだけで、定義することができる。
【００５６】
ＩｓＦｉｘｅｄブールカラムの導入によって、フォルダまたは他のエンティティが階層構造の定義された位置になければならないのか、あるいは、階層構造の任意の位置にあってもいいのかを規定する手段が得られる。
【００５７】
いずれもがＥｎｔｉｔｙＴｙｐｅ  ＩＤを指すＥｎｔｉｔｙＴｙｐｅＩＤフィールドとＥｘｉｓｔＵｎｄｅｒＥｎｔｉｔｙＴｙｐｅＩＤフィールドを持つ多対多対応テーブル、ＨｉｅｒａｃｈｉｃａｌＬｏｃａｔｉｏｎを導入して、あるＥｎｔｉｔｙＴｙｐｅが階層内に持つ複数の位置を制御することも考えられる。
【００５８】
エンティティクローニングとＤｅｆａｕｌｔ  Ｅｎｔｉｔｙのサポート
図４において、ＥｎｔｉｔｙＴｙｐｅテーブルにＤｅｆａｕｌｔＥｎｔｉｔｙＩＤカラムを導入すれば、当該ＥｎｔｉｔｙＴｙｐｅのＤｅｆａｕｌｔ  Ｅｎｔｉｔｙとするエンティティを指し示させることができる。
【００５９】
図４のスキーマは一種の「エンティティおよびブランチのクローニング」をサポートしており、つまり、ユーザは任意のエンティティとそのフィールドを複製し、当該エンティティとそのデータのコピーを作成し、階層内の任意の位置に置くことが可能である。クローニングは、階層内のひとつのエンティティ、複数エンティティのセット、エンティティのブランチ全体のいずれに対しても行うことができる。この機能は、さまざまな用途に利用できる。
【００６０】
そうした用途のひとつが、デフォルトエンティティを定義し、同じタイプのエンティティが新しく要求されたとき、そのクローンを作成するというものである。
【００６１】
このようにすれば、フィールドの初期値をすべてＤｅｆａｕｌｔ  Ｅｎｔｉｔｙで定義し、当該Ｄｅｆａｕｌｔ  Ｅｎｔｉｔｙがクローニングされたとき、初期値をすべて反映させることが可能になる。
【００６２】
デフォルト値のサポート
エンティティの名前は、エンティティのデータのひとつとして取り扱うこともできるし、あるいは、一定セットのフィールドの値を組みあわせて名前を作るようにすることもできる。これは、マルチフィールドフォームでユーザが入力したひとつあるいは複数のデータから有意味なエンティティ名を得たい場合に便利な方法である。
【００６３】
図５では、ＦｉｅｌｄＴｙｐｅテーブルに新しく整数カラム、ＤｅｆａｕｌｔＶａｌｕｅを設定し、エンティティの名前を構築する際に組みあわせるべきフィールドと、その順番を定義できるようにしている（ＤｅｆａｕｌｔＶａｌｕｅの値の順に組みあわせる）。ＤｅｆａｕｌｔＶａｌｕｅ  ＞  ０であれば、その順番に並べてエンティティ名を得るわけである。
【００６４】
関係のサポート
エンティティ間の関係をサポートするために、図５のシステムは、前述の階層関係以外にも、データベースにおけるエンティティ間の関係を定義し、実装する汎用性のとても高い方法を持つ。
【００６５】
たとえば、図４に対して追加されたＲｅｌａｔｉｏｎｓｈｉｐＴｙｐｅテーブルとＲｅｌａｔｉｏｎｓｈｉｐテーブルを使えば、以下のステップを実行するだけで、「Ｓｔａｆｆ」ＥｎｔｉｔｙＴｙｐｅと「Ｃｌｉｅｎｔ」ＥｎｔｉｔｙＴｙｐｅの間に「Ｃｌｉｅｎｔ  Ｍａｎａｇｅｒ」という関係をすばやく設定できる。
１．  Ｅｎｔｉｔｙ  ＴｙｐｅとしてＳｔａｆｆとＣｌｉｅｎｔを定義する（前述）。
２．  ＲｅｌａｔｉｏｎｓｈｉｐＴｙｐｅテーブルにレコードを入力し、Ｎａｍｅ＝「Ｃｌｉｅｎｔ  Ｍａｎａｇｅｒ」、ＦｒｏｍＥｎｔｉｔｙＴｙｐｅＩＤ＝「Ｓｔａｆｆ  ＥｎｔｉｔｙＴｙｐｅのＩＤ」、ＴｏＥｎｔｉｔｙＴｙｐｅＩＤ＝「Ｃｌｉｅｎｔ  ＥｎｔｉｔｙＴｙｐｅのＩＤ」と設定する。
【００６６】
このようにすれば、ソフトウェアによってスタッフエンティティやクライアントエンティティで使える関係をリストアップする場合、このＲｅｌａｔｉｏｎｓｈｉｐＴａｂｌｅを調べることにより、「Ｃｌｉｅｎｔ  Ｍａｎａｇｅｒ」を構築可能な関係のひとつとして取りあげることが可能になる。
【００６７】
Ｓｔａｆｆ  ＥｎｔｉｔｙとＣｌｉｅｎｔ  Ｅｎｔｉｔｙの間に「Ｃｌｉｅｎｔ  Ｍａｎａｇｅｒ」というタイプの関係を構築する手順は、以下のとおり。
１．  Ｒｅｌａｔｉｏｎｓｈｉｐテーブルに新しいレコードを入力する。
２．  目的とするＳｔａｆｆ  ＥｎｔｉｔｙのＩＤにＦｒｏｍＥｎｔｉｔｙＩＤを設定する。
３．  目的とするＣｌｉｅｎｔ  ＥｎｔｉｔｙのＩＤにＴｏＥｎｔｉｔｙＩＤを設定する。
４．  「Ｃｌｉｅｎｔ  Ｍａｎａｇｅｒ」ＲｅｌａｔｉｏｎｓｈｉｐＴｙｐｅのＩＤにＲｅｌａｔｉｏｎｓｈｉｐＴｙｐｅＩＤを設定する。
【００６８】
これで、シンプルなＳＱＬによって、所与のスタッフが管理するクライアントの全リストなどを取得できるようになる。
【００６９】
ＲｅｌａｔｉｏｎｓｈｉｐＴｙｐｅは任意の数を定義可能であり、また、Ｒｅｌａｔｉｏｎｓｈｉｐテーブルの関係も任意の数を設定可能である。
【００７０】
ここで注意すべき点として、標準スキーマでは、関係を保存しておきたいと希望するテーブル１対ごとに多対多対応テーブル（Ｒｅｌａｔｉｏｎｓｈｉｐテーブルなど）を１つ用意しなければならないことがある。システムによっては（たとえば治安用データベースや捜査用データベース）、すべてのテーブル間を関係づけなければならないことがある。この場合、新しいテーブルを追加するごとに、既存データテーブルの数だけ多対多対応テーブルが追加で必要になり、システムの設計・開発・管理がとても大変になる。
【００７１】
本スキーマはエンティティごとにテーブルを用意するかわりに、すべてのエンティティをひとつのエンティティＩＤテーブルに抽象化するため、関係テーブルもひとつだけしか必要とならない。
【００７２】
保存するデータタイプのサポート
データタイプとは、Ｂｏｏｌｅａｎ（ブール）、Ｃｕｒｒｅｎｃｙ（通貨）、Ｄａｔｅ（日付）、Ｂｉｎａｒｙ（バイナリ）、Ｔｅｘｔ（テキスト）などを意味する。
【００７３】
上述のＣＡＳでは、「バリアント」データタイプを使用してＦｉｅｌｄテーブルにデータを保存する。この点は、本スキーマを実用化する際の制限となる。多様なデータタイプが存在するが、その多くはバリアントとして利用することができず、よって、本スキーマでも利用できないからである。
【００７４】
ひとつの方法として、Ｆｉｅｌｄテーブルにさまざまなデータタイプの記憶場所を用意することも考えられるが、こうすると、ひとつの値を保存するとき、そのＦｉｅｌｄに使わないカラムが数多くできてしまうことになるため、効率が悪くなってしまう。
【００７５】
本発明によるスキーマの好適態様としては、目的とするデータタイプごとおよび目的とするポインタごとに専用のＶａｌｕｅテーブルをひとつ用意する。Ｖａｌｕｅテーブルは、それぞれ、Ｆｉｅｌｄテーブルに関連づける。データは、そのデータタイプに応じたＶａｌｕｅテーブルに保存する。
【００７６】
図６は、わかりやすいようにＶａｌｕｅテーブルのサブセットを示した例である。ＦｉｅｌｄテーブルからＶａｌｕｅカラムがなくなっている点に注意されたい。
【００７７】
各Ｆｉｅｌｄに対し、Ｆｉｅｌｄテーブルにひとつのエントリが存在するとともに、Ｖａｌｕｅテーブルのいずれかひとつにリンクされたエントリが存在する。Ｆｉｅｌｄテーブルをなくしてしまうことも選択肢としてはあるが、そうするとＶａｌｕｅテーブルがそれぞれＥｎｔｉｔｙテーブルを直接指し示すことになるため、ＦｉｅｌｄＴｙｐｅポインタを持たせなければならない。本スキーマにとって実用的な方法ではある。しかし、Ｆｉｅｌｄテーブルがあったほうが、ＳＱＬにおけるＦｉｅｌｄＴｙｐｅへのリンクとしても便利であるし、値のヒストリやその他のステータスデータを維持しやすいアーキテクチャが得られもする（後述）。
【００７８】
Ｍｉｃｒｏｓｏｆｔ社（本社：米国ワシントン州レドモンド）のＭｉｃｒｏｓｏｆｔ  ＳＱＬ  Ｓｅｒｖｅｒ  ２０００では、２５のデータタイプが利用できる。よって、必要なデータタイプにもよるが、最大で２５のＶａｌｕｅＸテーブルが定義される可能性がある（図７に示した４つの例を含む）。
【００７９】
Ｖａｌｕｅテーブルは、それぞれ、目的とするデータタイプのＶａｌｕｅカラムをひとつ持つ。たとえば、ＶａｌｕｅＢｏｏｌｅａｎテーブルはデータタイプがＢＩＴ（ビット）のＢｏｏｌｅａｎＶａｌｕｅカラムを持っているし、ＶａｌｕｅＤａｔｅテーブルはデータタイプがＤａｔｅＴｉｍｅ（日付と時刻）のＤａｔｅＶａｌｕｅカラムを持つ。
【００８０】
所与のＦｉｅｌｄＴｙｐｅに対し、どのＶａｌｕｅテーブルにデータを保存すべきかを定義するため、ＤａｔａＴｙｐｅテーブルを導入する。本テーブルは、目的とするデータタイプを定義するとともに、使用するテーブルの名前とそのＶａｌｕｅカラムの名前を提供する。こうすれば、定義されたＶａｌｕｅテーブルからデータを読み出すために必要なＳＱＬを自動的に構築できるようになる。
【００８１】
ＤａｔａＴｙｐｅテーブルの機能の一部はシステムテーブル（ＳＱＬ  Ｓｅｒｖｅｒ  ２０００のｓｙｓｏｂｊｅｃｔｓなど）を使っても実現できるが、この方法には限界があり、このように変更すべきではない。
【００８２】
Ｖａｌｕｅテーブルひとつに対してＤａｔａＴｙｐｅテーブルにひとつのレコードが存在する。図６に示すＶａｌｕｅテーブルのセットについては、ＤａｔａＴｙｐｅテーブルが次の表１に示す値のセットを持つ。
【表１】
2006524376.tif 000003
【００８３】
この後は、ＦｉｅｌｄＴｙｐｅテーブルにＤａｔａＴｙｐｅＩＤポインタを付加するのが一番簡単ではあるが、ここでは、中間ステップとなるＶａｌｕｅＴｙｐｅテーブルを導入する。
【００８４】
利用できるデータタイプのすべてにアクセスするためには、利用できるＤａｔａＴｙｐｅエントリにリンクされたエントリが少なくともひとつ、ＶａｌｕｅＴｙｐｅテーブルに存在しなければならない。
【００８５】
一方、ＶａｌｕｅＴｙｐｅテーブルにはいくつでもエントリを追加し、使用可能にしたデータタイプをさらにさまざまな使い方で利用可能にすることができる。
【００８６】
たとえば、「Ｄｕｅ  ｂｙ  ｄａｔｅ」というＶａｌｕｅＴｙｐｅを新しく導入し、ＶａｌｕｅＤａｔｅテーブルにマッピングしたとしよう。こうすれば、「ｄｕｅ  ｂｙ  ｄａｔｅ（期日）」を表すエンティティの日付を定めるとき、標準のＤａｔｅ  ＶａｌｕｅＴｙｐｅのかわりにこのＶａｌｕｅＴｙｐｅを使うことが可能になる。そしてまた、システム全体でも、Ｄｕｅ  ｂｙ  Ｄａｔｅの処理と報告に用いることができる。このようにさまざまなＶａｌｕｅＴｙｐｅを定義できれば、さまざまな応用が考えられる。
【００８７】
このようにＶａｌｕｅＴｙｐｅテーブルとＤａｔａＴｙｐｅテーブル、ＶａｌｕｅＸテーブルを組みあわせると、本発明の好適態様によるスキーマで、多様な値に適したデータタイプが各種、利用できるようになる。
【００８８】
Ｅｎｔｉｔｙ  Ｐｏｉｎｔｅｒデータタイプのサポート
Ｅｎｔｉｔｙテーブルへのポインタを持つＶａｌｕｅテーブルを構築したことにより、どのような標準スキーマでも、本発明の態様を用いてモデル化できる段階に入ってきた。
【００８９】
図７では、ＶａｌｕｅＭｏｎｅｙテーブルのかわりにＶａｌｕｅＥｎｔｉｔｙテーブルが置かれるとともに、ＦｉｅｌｄＴｙｐｅテーブルにＶａｌｕｅＥｎｔｉｔｙＴｙｐｅＩＤとＶａｌｕｅＥｎｔｉｔｙＰａｒｅｎｔＩＤというポインタとなるカラムが２つ、新しく導入されている。
【００９０】
ＶａｌｕｅＥｎｔｉｔｙテーブルは、ＥｎｔｉｔｙテーブルのＩＤを示すＥｎｔｉｔｙＩＤポインタを持つ。
【００９１】
ＦｉｅｌｄＴｙｐｅテーブルのＶａｌｕｅＥｎｔｉｔｙＴｙｐｅＩＤポインタとＶａｌｕｅＥｎｔｉｔｙＰａｒｅｎｔＩＤポインタの組みあわせにより、Ｅｎｔｉｔｙ  Ｐｏｉｎｔｅｒ  Ｆｉｅｌｄに許すエンティティの範囲を定義することができる。
【００９２】
たとえば、これらがいずれもセットされていないとき、Ｆｉｅｌｄは任意のＥｎｔｉｔｙを指し示すことができる。ＶａｌｕｅＥｎｔｉｔｙＴｙｐｅＩＤのみがセットされているとき、Ｆｉｅｌｄは、そのＥｎｔｉｔｙＴｙｐｅのＥｎｔｉｔｙのみを指し示すことができる。ＶａｌｕｅＥｎｔｉｔｙＰａｒｅｎｔＩＤのみがセットされているとき、Ｆｉｅｌｄは、選択されたＥｎｔｉｔｙの子のみを指し示すことができる。両方がセットされているとき、Ｆｉｅｌｄは、定義されたＥｎｔｉｔｙＴｙｐｅであり、かつ、選択されたＥｎｔｉｔｙの子であるエンティティのみを指し示すことができる。
【００９３】
ユーザの必要条件によっては、許可するエンティティを定義する別の方法を導入することも考えられる。
【００９４】
この構造は、標準スキーマにおけるテーブルポインタ構造に等しく、一般に、「検索リスト」を用意するという使い方が多い。
【００９５】
都市名（ロンドン、メルボルン、ワシントンなど）を並べたＣｉｔｙテーブルのかわりに、ＥｎｔｉｔｙＴｙｐｅ  Ｃｉｔｙとしてこれらの名前を持つエンティティがリストされるわけである。
【００９６】
前述のクライアントテーブルの例で説明すると、Ｃｉｔｙ検索機能が必要であれば、普通ならデータベース内に新しくＣｉｔｙテーブルを作成するとともにＣｌｉｅｎｔテーブルにはＣｉｔｙＩＤカラムを作成し、ＣｉｔｙＩＤカラムをＣｉｔｙテーブルのＩＤカラムに外部キーとしてリンクする。
【００９７】
これに対し、図７のスキーマでは、Ｃｉｔｉｅｓ  Ｅｎｔｉｔｙをフォルダと定義し、Ｃｉｔｙ  Ｅｎｔｉｔｙをその子とする。次にＣｌｉｅｎｔ  ＥｎｔｉｔｙＴｙｐｅとしてＣｉｔｙ  ＦｉｅｌｄＴｙｐｅを定義し、Ｃｉｔｙ  ＥｎｔｉｔｙＴｙｐｅを指し示すようにＶａｌｕｅＥｎｔｉｔｙＴｙｐｅＩＤをセットする（Ｃｉｔｉｅｓ  Ｅｎｔｉｔｙを指し示すようにＶａｌｕｅＥｎｔｉｔｙＰａｒｅｎｔＩＤもセットしてもよい）。
【００９８】
本発明者の経験では、Ｖａｌｕｅテーブルの中で群を抜いてよく使うのがＶａｌｕｅＥｎｔｉｔｙテーブルである。
【００９９】
他のスキーマポインタのサポート
Ｖａｌｕｅテーブルを作成し、本スキーマの任意のテーブルを指し示すようにすることもできる。このやり方には、さまざまな応用が考えられる。
【０１００】
データベースと外部のデータベースやシステム、リソースとのインターフェースが必要な場合にも、Ｖａｌｕｅテーブルを作成し、テーブルやディレクトリ、デバイスなどを指し示すようにすることができる。
【０１０１】
オプション値や複数値のサポート
ＦｉｅｌｄＴｙｐｅ／Ｆｉｅｌｄ機能の根本前提は、「Ｅｎｔｉｔｙが生成されるとき、ＥｎｔｉｔｙＴｙｐｅについて定義されているＦｉｅｌｄＴｙｐｅひとつにつきひとつのＦｉｅｌｄが生成される」である。
【０１０２】
しかし、本スキーマでは、あるＦｉｅｌｄＴｙｐｅに対して任意の数のＦｉｅｌｄを生成することが可能である。これを標準スキーマで実現しようとすると、テーブルや関係を追加する必要がある。
【０１０３】
図８では、ＦｉｅｌｄＴｙｐｅテーブルに新しいカラムがある。ＩｓＭｕｌｔｉｐｌｅとＭｕｌｔｉｐｌｅｓＴｏＣｒｅａｔｅ、ＭａｘｉｍｕｍＭｕｌｔｉｐｌｅｓで、これを使うと、複数Ｆｉｅｌｄの挙動をさまざまに定義できる。マルチフィールド機能は、ＩｓＭｕｌｔｉｐｌｅを真にすると利用できるようになる。
【０１０４】
たとえば、ＩｓＭｕｌｔｉｐｌｅを真として、エンティティを生成すると、ＭｕｌｔｉｐｌｅｓＴｏＣｒｅａｔｅに設定された数のフィールドが生成される。その後、ＦｉｅｌｄＴｙｐｅが同じＦｉｅｌｄをさらに追加することも可能である。Ｆｉｅｌｄの最大数は、ＭａｘｉｍｕｍＭｕｌｔｉｐｌｅｓが設定されていればその数、設定されていなければ任意である。マルチフィールドの数をユーザが削除して減らすことも可能で、その最小数はＭｕｌｔｉｐｌｅｓＴｏＣｒｅａｔｅが設定されていればその数となり、設定されていなければ当該ＦｉｅｌｄＴｙｐｅのＦｉｅｌｄすべてを削除することができる。この機能は、たとえば、顧客の電話番号を複数、記録したい場合や、フォームのマルチセレクト・リストボックスで選択されたものを記録したい場合に利用する（ＶａｌｕｅＥｎｔｉｔｙ  Ｆｉｅｌｄを使う）。
【０１０５】
Ｆｉｅｌｄの変更履歴／監査のサポート
標準データベーススキーマに対する要求でもっとも厳しいもののひとつに、あらゆる値について変更履歴を完全に保存する機能のサポートがある。このとき標準スキーマで問題になるのは、項目が記録されている場所が、あるテーブルのあるカラム、１カ所に限られている点である。変更履歴は通常、テーブル名とカラム名で変更点を指し示すログテーブルという形で記録される。所与の日付におけるあるレコードの状態を標準スキーマで知るのは、普通、とても難しい。
【０１０６】
図８では、ＦｉｅｌｄＴｙｐｅテーブルに新しいカラム、ＫｅｅｐＨｉｓｔｏｒｙがある。また、すべてのＶａｌｕｅテーブルに、ＩｓＣｕｒｒｅｎｔＶａｌｕｅとＤａｔｅＴｉｍｅＬａｓｔＷｒｉｔｔｅｎという２つの新しいカラムが追加されている。
【０１０７】
あるＦｉｅｌｄＴｙｐｅについてＫｅｅｐＨｉｓｔｏｒｙが真に設定されていると、値が変更されるたびに、定義されたＶａｌｕｅテーブルに新しいレコードが追加される。追加されたレコードのＩｓＣｕｒｒｅｎｔＶａｌｕｅは真にセットされ、当該フィールドの過去の値はすべてＩｓＣｕｒｒｅｎｔＶａｌｕｅが偽にセットされる。ＤａｔｅＴｉｍｅＬａｓｔＷｒｉｔｔｅｎカラムは、Ｈｉｓｔｏｒｙ  Ｆｉｅｌｄ  Ｖａｌｕｅが生成されたとき、一度だけセットされる。このＤａｔｅＴｉｍｅＬａｓｔＷｒｉｔｔｅｎは変更のタイムスタンプとなるものであるが、同時に、前述のＩｓＣｕｒｒｅｎｔＶａｌｕｅルールをソフトウェアで実行できなかった場合に回復する手だてともなる。
【０１０８】
この結果、現在のデータをスキーマから取得するクエリでは、すべてのＶａｌｕｅテーブルについてＩｓＣｕｒｒｅｎｔＶａｌｕｅ  ＝  Ｔｒｕｅを指定しなければならない。一方、過去のある時点におけるデータを取得したい場合には、希望する日付と時刻に対し、「ｌｅｓｓ  ｔｈａｎ  ｏｒ  ｅｑｕａｌ  ｔｏ  ＤａｔｅＴｉｍｅＬａｓｔＷｒｉｔｔｅｎ」とＴＯＰ  １を条件としたシンプルなクエリを実行するだけで、履歴のビューが得られる。
【０１０９】
あるＥｎｔｉｔｙについて履歴値をすべてリストすれば、完全な監査証跡が得られる。
【０１１０】
共有フィールドタイプのサポート
あるＦｉｅｌｄＴｙｐｅを複数ＥｎｔｉｔｙＴｙｐｅで共有できると便利である。本スキーマではこれを実現可能であり、そのためには、その機能を定義し実装する方法さえあればいい。
【０１１１】
ＦｉｅｌｄＴｙｐｅを共有する方法の一例を示す。
１．  「Ｓｈａｒｅｄ  Ｅｎｔｉｔｙ  Ｔｙｐｅ」という名前でＳｈａｒｅｄ  ＥｎｔｉｔｙＴｙｐｅを生成する。
２．  当該ＥｎｔｉｔｙＴｙｐｅについて、「Ｌａｓｔ  Ｍｏｄｉｆｉｅｄ」ＦｉｅｌｄＴｙｐｅを生成する。
３．  「Ｃｌｉｅｎｔ」ＥｎｔｉｔｙＴｙｐｅのＤｅｆａｕｌｔ  Ｅｎｔｉｔｙを生成する。
４．  Ｃｌｉｅｎｔ  ＥｎｔｉｔｙＴｙｐｅのＤｅｆａｕｌｔＥｎｔｉｔｙＩＤが、このＤｅｆａｕｌｔ  Ｅｎｔｉｔｙを指すようにする。
５．  これに対し、「Ｓｈａｒｅｄ  Ｅｎｔｉｔｙ  Ｔｙｐｅ」ＥｎｔｉｔｙＴｙｐｅから「Ｌａｓｔ  Ｍｏｄｉｆｉｅｄ」ＦｉｅｌｄＴｙｐｅのＦｉｅｌｄを追加する。
【０１１２】
そのＥｎｔｉｔｙＴｙｐｅで直接定義されていない場合でも、他のＥｎｔｉｔｙＴｙｐｅについても、Ｄｅｆａｕｌｔ  Ｅｎｔｉｔｙに「Ｌａｓｔ  Ｍｏｄｉｆｉｅｄ」Ｆｉｅｌｄを必ず持たせるようにしてもよい。
【０１１３】
Ｄｅｆａｕｌｔ  Ｅｎｔｉｔｙのクローニングは当該ＥｎｔｉｔｙとＦｉｅｌｄデータによるため（ＥｎｔｉｔｙＴｙｐｅのＤｅｆａｕｌｔＥｎｔｉｔｙＩＤだけを用いる）、他のＥｎｔｉｔｙＴｙｐｅに対して定義された任意のＦｉｅｌｄＴｙｐｅをＤｅｆａｕｌｔ  Ｅｎｔｉｔｙに追加することができる。これは、ひとつのＦｉｅｌｄＴｙｐｅＩＤをさまざまなＥｎｔｉｔｙＴｙｐｅを横断する共通フィールドとして利用できる強力な機能である。
【０１１４】
値継承のサポート
新しいＥｎｔｉｔｙを生成するとき、その親（あるいは他の）エンティティのデータから値を継承できると便利である。継承が実装できるのは、新しいエンティティのＦｉｅｌｄが、親エンティティ（あるいはデータソースとして使うことをユーザが望む他のエンティティ）と同じＦｉｅｌｄＴｙｐｅＩＤを持つ場合である。ＦｉｅｌｄＴｙｐｅを共有する方法は、前述の「共有フィールドタイプのサポート」というセクションで説明したとおりである。
【０１１５】
図８では、ＦｉｅｌｄＴｙｐｅテーブルに「Ｉｎｈｅｒｉｔ」というブールカラムがある。ここが真にセットされていると、このＦｉｅｌｄＴｙｐｅテーブルは、その親（あるいは他の指定されたエンティティ）で自分と同じＦｉｅｌｄＴｙｐｅのフィールドを探し、見つかった場合には、その値を自分にコピーする。
【０１１６】
この機能はさまざまに応用できるが、そのひとつとして、階層に子エンティティが追加されたとき、そのデフォルト値を供給することが考えられる。
【０１１７】
データフォーマットのサポート
表示用に、保存されているデータを指定されたデータタイプにフォーマットしたいということがよくある。データを理解するためや、その意味を明確にするため、あるいはある基準から見た価値を表すため、さまざまなデータタイプのフォーマットが必要になる。
【０１１８】
図９には、Ｆｏｒｍａｔテーブルが導入されている。これに伴い、ポインタとしてＦｉｅｌｄＴｙｐｅテーブルにはＦｏｒｍａｔＩＤが、ＶａｌｕｅＴｙｐｅテーブルにはＤｅｆａｕｌｔＦｏｒｍａｔＩＤが、ＤａｔａＴｙｐｅテーブルにはＤｅｆａｕｌｔＦｏｒｍａｔＩＤが追加されている。
【０１１９】
Ｆｏｒｍａｔテーブルには、ＮａｍｅカラムとＦｏｒｍａｔカラム、ＤａｔａＴｙｐｅＩＤカラムがある。
【０１２０】
Ｎａｍｅカラムはフォーマット機能の名前として用いるものであり、Ｆｏｒｍａｔカラムはフォーマットの書式文字列を保存しておくものである。
【０１２１】
ＤａｔａＴｙｐｅＩＤカラムは、当該Ｆｏｒｍａｔが適用されるＤａｔａＴｙｐｅの指定に用いる。
【０１２２】
ＤａｔａＴｙｐｅテーブルのＤｅｆａｕｌｔＦｏｒｍａｔＩＤをセットすると、新しいＶａｌｕｅＴｙｐｅテーブルのＤｅｆａｕｌｔＦｏｒｍａｔＩＤに、ＶａｌｕｅＴｙｐｅテーブルで使用するＤａｔａＴｙｐｅに応じた値をセットできるようになる。同様に、新しいＦｉｅｌｄＴｙｐｅテーブルも、使用するＶａｌｕｅＴｙｐｅに応じてＦｏｒｍａｔＩＤをセットできるようになる。
【０１２３】
あるＦｉｅｌｄテーブルを表示する場合、コードはセットされたＦｏｒｍａｔＩＤが見つかるまで以下の順番で検索していく。
１．  ＦｉｅｌｄＴｙｐｅテーブルのＦｏｒｍａｔＩＤ
２．  ＶａｌｕｅＴｙｐｅテーブルのＤｅｆａｕｌｔＦｏｒｍａｔＩＤ
３．  ＤａｔａＴｙｐｅテーブルのＤｅｆａｕｌｔＦｏｒｍａｔＩＤ
【０１２４】
書式文字列は、プログラミング言語がサポートするフォーマット機能や、ユーザがコードを自ら作成してサポートしたカスタムフォーマット構造によるものが使える。
【０１２５】
フォーマットの適用例を以下の表２に示す。
【表２】
2006524376.tif 000004
【０１２６】
ＦｉｅｌｄグループあるいはＦｉｅｌｄ行のサポート
複数のＦｉｅｌｄをセットとしてグループ化すると、さまざまな場合に便利である。ひとつの値を複数位置に保存しなければならない場合や、コンテキストが共通の複数ＦｉｅｌｄをひとつのＲｏｗにまとめる場合が考えられる。
【０１２７】
図１０には、ＦｉｅｌｄＲｏｗＴｙｐｅテーブルとＦｉｅｌｄＲｏｗテーブルが導入されている。
【０１２８】
ＦｉｅｌｄＲｏｗＴｙｐｅテーブルが、ＦｉｅｌｄＴｙｐｅテーブルと同じように、３種類のマルチ制御用カラムを持つことに注意されたい。この結果、「オプション値や複数値のサポート」で説明したＦｉｅｌｄマルチ機能と同じ機能が、ＦｉｅｌｄＲｏｗについても実現される。
【０１２９】
一方、ＦｉｅｌｄＴｙｐｅテーブルにはＦｉｅｌｄＲｏｗＴｙｐｅＩＤカラムが、ＦｉｅｌｄテーブルにはＦｉｅｌｄＲｏｗＩＤカラムが追加されている。
【０１３０】
あるＥｎｔｉｔｙの元で複数Ｆｉｅｌｄをグループ化したい場合には、（ＥｎｔｉｔｙＴｙｐｅＩＤをセットすることにより）当該Ｅｎｔｉｔｙｐｅに新しいＦｉｅｌｄＲｏｗＴｙｐｅエントリを定義し、グループ化したいＦｉｅｌｄＴｙｐｅのすべてについて、ＦｉｅｌｄＲｏｗＴｙｐｅＩＤをＦｉｅｌｄＲｏｗＴｙｐｅテーブルのＩＤにセットする。
【０１３１】
新しいエンティティが生成されると、そのＥｎｔｉｔｙＴｙｐｅについて定義されたＦｉｅｌｄＲｏｗＴｙｐｅテーブルのそれぞれにひとつずつ、新しいＦｉｅｌｄＲｏｗテーブルが生成される。対応する複数のＦｉｅｌｄが生成されると、そのＦｉｅｌｄＲｏｗＩＤはすべて、ＦｉｅｌｄＲｏｗテーブルのＩＤにセットされる。このようにすれば、定義された複数のＦｉｅｌｄＲｏｗＴｙｐｅテーブルによってＦｉｅｌｄＴｙｐｅテーブルがグループ化されるのと同じように、Ｆｉｅｌｄテーブルもグループ化される。
【０１３２】
値のインクリメントのサポート
新しいＥｎｔｉｔｙに、対応する一意かつ一定の増分で増加していく数値コードを持たせたり、数値コードと他のフィールドや現在年などとの組みあわせを持たせたりしたいことが多い。この機能は、標準スキーマでは、数値を記憶するＩＤカラムで実現するか、あるいは専用のインクリメントカラムを置いて実現することが多い。
【０１３３】
本スキーマでは、この値のインクリメント機能を提供する方法として、さまざまな方法を取りうる。
【０１３４】
利用できる方法の例は以下のとおり。
１．  ＳＱＬを使用して、所与のＦｉｅｌｄＴｙｐｅの値がもっとも大きなＶａｌｕｅテーブル（数値用）をクエリし、その値に１を加えて、新しいＶａｌｕｅテーブルの値とする。
２．  ＦｉｅｌｄＴｙｐｅテーブルにＮｅｘｔＩｎｃｒｅｍｅｎｔｏｒカラムを追加し、当該ＦｉｅｌｄＴｙｐｅの次のＶａｌｕｅテーブルを書きこみ、ＮｅｘｔＩｎｃｒｅｍｅｎｔｏｒカラムに１を加え、ＦｉｅｌｄＴｙｐｅレコードを更新する際に、その値を用いる。
３．  所与のＥｎｔｉｔｙＴｙｐｅであるＥｎｔｉｔｙの数を用いて増加すべき値を計算する。
【０１３５】
表示サービス
データベースのデータを表示する、編集する、リストアップする、あるいはその他の対話的操作を行う一貫したシステムを提供することが望ましい。
【０１３６】
標準スキーマでは、ユーザがどのようにデータを操作するかを定義することが容易ではないため、通常は、コード内において「Ｆｏｒｍ」という形で定義する。「Ｆｏｒｍ」は論理的に存在するものであり、データベースで定義されるものではない。
【０１３７】
本発明の好適態様によるスキーマでは、それぞれ、テーブルやカラムへの関係と同等とみなし、ＥｎｔｉｔｙＴｙｐｅテーブルとＦｉｅｌｄＴｙｐｅテーブルとに直接関係づけることが可能である。必要に応じ、データベース内に置いたシステムテーブルを使い、これらにリンクすることも可能である。
【０１３８】
本セクションで説明する表示システムでは、フォームを用いてユーザインターフェースを定義し、以下を初めとするさまざまな機能を実現する。
・  閲覧
・  編集
・  リストアップ
・  検索
・  報告
【０１３９】
本システムは、マルチタブのフォームにも対応できる。
【０１４０】
フォーム
フォームは、あるＥｎｔｉｔｙＴｙｐｅについて一部のＦｉｅｌｄＴｙｐｅを選択し、グループ化して好みのレイアウトで閲覧するためのメカニズムである。
【０１４１】
たとえば、従業員フォームを他の従業員が閲覧する場合、見せてはならない情報が表示されてはならないので、表示データから除外する。一方、マネージャーが部下の情報を見る場合には、そのような情報も含む別のフォームを使用する。
【０１４２】
図１１に、ＥｎｔｉｔｙＴｙｐｅテーブルとＦｉｅｌｄＴｙｐｅテーブルにリンクされたＦｏｒｍスキーマコンポーネントを示す。このＥｎｔｉｔｙＴｙｐｅテーブルとＦｉｅｌｄＴｙｐｅテーブルは、図２〜図１０と同じものである。つまり、図１１は、図２〜図１０を拡張したものと言える。
【０１４３】
ＦｏｒｍテーブルにはＮａｍｅがあるとともに、このテーブルがサービスを提供するＥｎｔｉｔｙＴｙｐｅテーブルのＩＤを指し示すＥｎｔｉｔｙＴｙｐｅＩＤがあり、かつまた、フォームの機能（閲覧／編集、リスト表示、検索など）を定義するＦｏｒｍＴｙｐｅテーブルのＩＤを指し示すＦｏｒｍＴｙｐｅＩＤがある。
【０１４４】
当該Ｆｏｒｍで使用するＦｉｅｌｄＴｙｐｅのセットを定義するのが、ＦｏｒｍＦｉｅｌｄテーブルである。ＦｏｒｍＦｉｅｌｄにはＮａｍｅがあるとともに、使用するＦｉｅｌｄＴｙｐｅを指定するＦｉｅｌｄＴｙｐｅＩＤがあり、かつまた、当該ＦｏｒｍＦｉｅｌｄを表示する際に使用するフォームグループを選ぶＦｏｒｍＧｒｏｕｐＩＤがある。ＣｏｎｔｒｏｌＴｙｐｅＩＤは、このＦｏｒｍＦｉｅｌｄを表示したり編集したりする際に使用するコントロールを選ぶものである。
【０１４５】
フォームを定義するためには、まずＦｏｒｍテーブルに新しいレコードを入力し、名前をつける。また、ＦｏｒｍＴｙｐｅＩＤを必要なＦｏｒｍＴｙｐｅ（すなわち、たとえばＶｉｅｗ）に設定する。ＥｎｔｉｔｙＴｙｐｅＩＤは、新しくフォームを生成しようとしているＥｎｔｉｔｙＴｙｐｅを示すように設定する（すなわちＣｌｉｅｎｔ  ＥｎｔｉｔｙＴｙｐｅ）。
【０１４６】
次に、ＦｏｒｍＧｒｏｕｐテーブルにひとつ、あるいは複数のレコードを入力し、それぞれのレコードに名前をつける（すなわち、Ｃｌｉｅｎｔ  ＤｅｔａｉｌｓやＬｏｇｉｎ  Ｄｅｔａｉｌｓなど）。
【０１４７】
当該フォームで表示するＦｉｅｌｄＴｙｐｅごとに、ＦｏｒｍＦｉｅｌｄテーブルにレコードをひとつ、入力する。それぞれに名前を付け（ＦｉｅｌｄＴｙｐｅテーブルのＮａｍｅを使うこともできるし、フォーム内の別の名前をコピーしてもいいことに注意）、各ＩＤポインタのリンクを設定する。つまり、ＦｏｒｍＩＤは新しいＦｏｒｍエントリを指すように、ＦｏｒｍＧｒｏｕｐＩＤは適切なＦｏｒｍＧｒｏｕｐエントリを指すように、ＦｉｅｌｄＴｙｐｅＩＤは表示するＦｉｅｌｄＴｙｐｅを指すように、そして、ＣｏｎｔｒｏｌＴｙｐｅＩＤはＦｉｅｌｄ  Ｄａｔａの表示に適したＣｏｎｔｒｏｌＴｙｐｅを指すようにする。
【０１４８】
ＦｏｒｍＦｉｅｌｄテーブルには、たとえば以下のようなカラムを複数作成し、その挙動を定義することが可能である。
・  ＨｅｌｐＴｅｘｔ
・  ＶｉｅｗＯｎｌｙ
・  Ｆｏｎｔ
・  Ｃｏｌｏｕｒ
・  など。
【０１４９】
ＣｏｎｔｒｏｌＴｙｐｅテーブルは、たとえば以下のような、サポートしている閲覧コントロールや編集コントロールのリストを保持する。
・  Ｃｈｅｃｋ  Ｂｏｘ
・  Ｒａｄｉｏ  Ｂｕｔｔｏｎ
・  Ｔｅｘｔ  Ｂｏｘ
・  Ｔｅｘｔ  Ａｒｅａ
・  Ｄａｔｅ  Ｃｏｎｔｒｏｌ
・  など。
【０１５０】
このリストには、開発言語がサポートするコントロールのリストやＨＴＭＬ用コントロールを含む可能性が高いが、それ以外にコード側でサポートするカスタムコントロールのリストをも保持することができる。
【０１５１】
ＣｏｎｔｒｏｌＴｙｐｅテーブルも、たとえば以下のようなカラムを複数作成し、ある種のコントロールで必要となる構造を定義することができる。
・  ＭａｘｉｍｕｍＣｈａｒａｃｔｅｒｓ
・  Ｗｉｄｔｈ
・  Ｈｅｉｇｈｔ
・  Ｆｏｎｔ
・  Ｃｏｌｏｕｒ
・  など。
【実施例】
【０１５２】
以下に、フォームシステムの用途の実施例を示す。
【０１５３】
実施例１：  閲覧フォーム
図１２は、本スキーマを使用して生成された閲覧フォームの例である。ＦｏｒｍＦｉｅｌｄのＮａｍｅが左側にリスト表示されており、ＦｏｒｍＧｒｏｕｐによるグループ化の例も示されている。表示されているデータは選択されたエンティティ、この場合は発明者のＳｔａｆｆ  Ｅｎｔｉｔｙから取得したものである。つまり、これは、Ｓｔａｆｆ  Ｅｎｔｉｔｙを表示するように設計されたフォームである。
【０１５４】
実施例２：  編集フォーム
図１３は、本スキーマを使用して生成された編集フォームの例である。図１２に示した閲覧フォーム（原文はｅｄｉｔ  Ｆｏｒｍ＝編集フォームだが、意味的に閲覧フォームの間違いと思われる）の一部分も、編集モードとなった状態で示されている。また、Ｔｅｘｔ  Ｉｎｐｕｔ、Ｄｒｏｐｄｏｗｎ（Ｏｔｈｅｒ項目を含む）、Ｐａｓｓｗｏｒｄ、Ｔｅｘｔ  ＡｒｅａなどのＣｏｎｔｒｏｌＴｙｐｅも使われている。
【０１５５】
図１３はまた、Ｆｏｒｍで複数データをどのように処理するかも示している。ＦｏｒｍＧｒｏｕｐテーブルがＭｕｌｔｉｐｌｅ  ＦｉｅｌｄＴｙｐｅを含む場合、マルチ項目にユーザーが追加したいと考える数を入力できるダイアログが表示される。また、Ｍｕｌｔｉｐｌｅ  ＦｉｅｌｄＴｙｐｅにはそれぞれＤｅｌｅｔｅ  Ｃｈｅｃｋｂｏｘがあり、既存の複数データ項目から任意の項目を削除できるようになっている。これらのコントロールを使った場合、Ｓｕｂｍｉｔボタンがクリックされるとそのリクエストが実行され、編集モードに戻る。
【０１５６】
実施例３：  履歴フォーム
図１４は、図１２のフォームの一部を履歴モードとして表示したものである。
このフォームでは、表示されたＦｉｅｌｄに対して今まで行われた変更をすべて確認することができる。
【０１５７】
実施例４：  リストフォーム
図１５は、ＥｎｔｉｔｙＴｙｐｅのリストに使うカラムを定義するフォームである。
【０１５８】
実施例５：  リポート用フォーム
図１６は、Ｒｅｐｏｒｔ  Ｂｕｉｌｄｅｒ  Ｆｏｒｍを作成するために使用するフォームである。このフォームを使うと、表示すると選択されたＦｏｒｍＦｉｅｌｄを定められた順番で表示するリポートを生成することができる。比較演算子（＞４など）を含む検索条件や期間、選択するＶａｌｕｅＥｎｔｉｔｙをセットすることができる（ドロップダウンコントロールを使う）。
【０１５９】
ＦｉｅｌｄＲｏｗ表示のサポート
図１７では、ＦｏｒｍスキーマコンポーネントがＥｎｔｉｔｙＴｙｐｅテーブルとＦｉｅｌｄＴｙｐｅテーブル、ＦｉｅｌｄＲｏｗＴｙｐｅテーブルにリンクされている。ＥｎｔｉｔｙＴｙｐｅテーブルとＦｉｅｌｄＴｙｐｅテーブル、ＦｉｅｌｄＲｏｗＴｙｐｅテーブルは、いずれも、図２〜図１０に示したものと同じである。つまり、図１７は、図２〜図１０を拡張したものと言える。
【０１６０】
図１７にはＦｏｒｍＲｏｗテーブルが導入されるとともに、ＦｏｒｍＦｉｅｌｄテーブルに新しくＦｏｒｍＲｏｗＩＤカラムが追加されている。
【０１６１】
ＦｏｒｍＲｏｗを表示するためには、対応するＦｉｅｌｄＲｏｗＴｙｐｅを定義しなければならない。
【０１６２】
コントロールを列に並べてフォームで表示したい場合、ユーザーは、まず、ＦｏｒｍＲｏｗテーブルに適切なＮａｍｅのエントリを作成し（ＦｉｅｌｄＲｏｗＴｙｐｅテーブルのＮａｍｅをコピーすることもできるし、フォーム内の別の名前を使用してもいいことに注意）、次に、Ｆｏｒｍテーブルの新しいエントリを指すようにＦｏｒｍＩＤをセットするとともに、表示したいＦｉｅｌｄＲｏｗＴｙｐｅテーブルのＩＤを指すようにＦｉｅｌｄＲｏｗＴｙｐｅＩＤをセットする。
【０１６３】
このＦｏｒｍＲｏｗの一部として表示するＦｏｒｍＦｉｅｌｄは、すべて、当該ＦｏｒｍＲｏｗテーブルのＩＤを指すようにＦｏｒｍＲｏｗＩＤカラムをセットしておく。
【０１６４】
コードがあるフォームを表示しようとしたとき、ＦｏｒｍＲｏｗを指すポインタを持ったＦｏｒｍＦｉｅｌｄがあると、当該ＦｏｒｍＲｏｗに属するＦｏｒｍＦｉｅｌｄがすべて集められ、グループ化が行われる（つまり、フォームに一列に並べて表示される）。
【０１６５】
マルチタブ付きフォームのサポート
図１８では、ＦｏｒｍスキーマコンポーネントがＥｎｔｉｔｙＴｙｐｅテーブルとＦｉｅｌｄＴｙｐｅテーブル、ＦｉｅｌｄＲｏｗＴｙｐｅテーブルにリンクされている。ＥｎｔｉｔｙＴｙｐｅテーブルとＦｉｅｌｄＴｙｐｅテーブル、ＦｉｅｌｄＲｏｗＴｙｐｅテーブルは、いずれも、図２〜図１０に示したものと同じである。つまり、図１８は、図２〜図１０を拡張したものと言える。
【０１６６】
タブ付きフォームとは、基本的に、あるＥｎｔｉｔｙＴｙｐｅについて異なるセクションや機能を持つ複数のフォームのグループである。
【０１６７】
図１８にはＦｏｒｍＴａｂテーブルが導入されるとともに、Ｆｏｒｍテーブルに新しくＦｏｒｍＴａｂＩＤカラムが追加されている。
【０１６８】
タブ付きフォームのセットを生成するためには、新しいＦｏｒｍＴｙｐｅを入力し、前述のように構成を行う必要がある。
【０１６９】
前述の手順に従ってタブごとにひとつのフォームを作成したら、そのＦｏｒｍＴｙｐｅＩＤをすべて、新しいＦｏｒｍＴｙｐｅにセットする。
【０１７０】
作成した新しいフォームひとつにつきひとつのエントリをＦｏｒｍＴａｂテーブルに追加し、Ｔａｂ  Ｎａｍｅを設定するとともに、ＦｏｒｍＴｙｐｅＩＤを新しいＦｏｒｍＴｙｐｅにセットする。
【０１７１】
新しく作成した複数フォームのＦｏｒｍＴａｂＩＤを、それぞれ、対応するＦｏｒｍＴａｂエントリにセットする。
【０１７２】
コードがあるフォームを表示しようとしたとき、ＦｏｒｍＴａｂＩＤがセットされていると、ＦｏｒｍＴｙｐｅの確認が行われ、当該ＦｏｒｍＴａｂ  Ｓｅｔに属するタブがすべて集められ、表示される。
【０１７３】
プロセスをＦｏｒｍＴａｂにリンクできるというヒントとして、ＦｏｒｍＴａｂテーブルには、ＰｒｏｃｅｓｓＥｎｔｉｔｙＩＤが導入されている。プロセスは、本スキーマではＰｒｏｃｅｓｓ  ＥｎｔｉｔｙＴｙｐｅとして簡単に定義可能であり、プロセスパスはＶａｌｕｅＥｎｔｉｔｙ  Ｆｉｅｌｄで示す。
【０１７４】
グローバルな表示エンジン
ここで説明するフォームシステムは、本スキーマで定義されるあらゆるエンティティに統一的に実装できるグローバルな表示エンジンが使える記憶システムとなりうる。
【０１７５】
つまり、１セットのコードを実装するだけで、すべてのＥｎｔｉｔｙについて、閲覧から編集、リスト作成、検索、リポートが行えることを意味する。
【０１７６】
グローバルなリポートエンジン
同様に、本データベースで定義されるすべてのＥｎｔｉｔｙＴｙｐｅをサービスできるグローバルなリポートエンジンも構築可能である。
【０１７７】
グローバル整列サービス、ＩＤ列挙サービス、データベース同期サービス
整列
本スキーマで整列を実現する場合、すべてのテーブルに数値を記録するＯｒｄｅｒｉｎｇカラムを追加するという方法がある。このカラムに適切な順番で数値をセットしておけば、「ＯＲＤＥＲ  ＢＹ」句を含むＳＱＬステートメントを使うことにより、定められた順番にレコードを取りだすことができる。
【０１７８】
ＩＤ列挙
本スキーマの使用モードに応じ、これと対話するコードは、本スキーマのテーブルＩＤにリンクされた機能を切り替える必要がある。
【０１７９】
コードでＩＤが必要になる場合があるが、ＩＤが数値なら、適当な列挙子を使いマニュアルでコードに含めることができる。本スキーマでは、ＧＵＩＤ（Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  ＩＤ）をＩＤフォーマットとして推奨するが、ＧＵＩＤを列挙子として使うことはほとんどの開発言語で禁止されている。ユーザーが定数あるいはオブジェクトとして定義すれば、ＧＵＩＤを使うことができる。
【０１８０】
どのような形のＩＤを使うにせよ、ＩＤ用モジュールをデータベースから直接、自動的に生成できる可能性がある。このようにすれば、人為的なミスも防止されるし、開発オーバーヘッドもかなり削減できる。本スキーマの発明者は、ＩＤＦａｃｔｏｒｙ  ｄｌｌを自動的に生成するそのようなシステムを実装し、データベースに列挙項目が追加されるたびにＩＤＦａｃｔｏｒｙジェネレーターを実行することにより、アップデートをすばやく行えるようにした。
【０１８１】
そのような自動生成機能をサポートしたり、コードからオンにできるレコードのすべてをマーキングしたりするためには、全テーブルにブール型のＥｎｕｍカラムを導入する。本スキーマのあるレコードがコードからオンにされると、当該レコードのＥｎｕｍカラムを真（非ゼロ）にセットして、それを示す。この情報を用いれば、コードで必要なＩＤをクエリし、これらのＩＤを定義するコードを生成することができる。
【０１８２】
データベースの同期
本スキーマは、中央のＩＤ  Ｍａｓｔｅｒ  Ｄａｔａｂａｓｅのシステムを定義し、その定義の全体あるいは一部を、データが記録される生産データベースに転用するという使い方に向いている。
【０１８３】
また、複数サーバーに複数データベースを保持し、冗長性を確保したりロードバランスを取ったりすることもよく行われる。
【０１８４】
本スキーマの全テーブルにＤａｔｅＴｉｍｅ  ＬａｓｔＭｏｄｉｆｉｅｄカラムを追加すれば、複数データベース間のデータ同期がやりやすくなる。コードで本スキーマのレコードをアップデートするとき、必ず、レコードがアップデートされた日付と時間をＬａｓｔＭｏｄｉｆｉｅｄカラムに記録しておく。
【０１８５】
レコードのＬａｓｔＭｏｄｉｆｉｅｄフィールドを比較すれば、データベースの同期が行える。
【０１８６】
データアクセスサービス
本発明によるスキーマのスキーマダイアグラムは、慣れないユーザーには最初、理解しにくいかもしれない。よって、本発明によるスキーマで記録するデータは、比較的標準的で、理解しやすい形で提示できたほうが望ましい。サードパーティのリポートエンジンやデータ解析エンジンがデータにアクセスする場合や、他のデータベースとのインターフェースが必要な場合などである。
【０１８７】
ビュー
データを標準テーブルのビューで提示できる方法は各種存在する。
・  Ｊｏｉｎ  Ｖｉｅｗ
・  Ｓｕｂ−ｓｅｌｅｃｔ  Ｖｉｅｗ
・  Ｆｕｎｃｔｉｏｎｓ  Ｖｉｅｗ
【０１８８】
これらのビューを生成する方法で、Ｔｅｍｐｏｒａｒｙテーブルを生成することが可能である。
【０１８９】
これらのビューは、ＥｎｔｉｔｙＴｙｐｅの定義をベースとした標準テーブルを返すことも可能である。
【０１９０】
自動生成のビュー
重要なポイントであるが、ビューを生成するＳＱＬも、ＥｎｔｉｔｙＴｙｐｅの定義から直接、自動的に生成することが可能である。この結果、自動生成のビューにふたつの利用方法が生まれる。
【０１９１】
１．  ＥｎｔｉｔｙＴｙｐｅの定義が変更されるたびにビューが更新される。
２．  必要な場合に毎回、１回限りのビューを生成する。
【０１９２】
ここで大事な点は、表示するＦｏｒｍや、Ｒｅｐｏｒｔ  Ｆｏｒｍｓ  Ｓｅｌｅｃｔｅｄ  ＦｏｒｍＦｉｅｌｄと条件をベースに１回限りのビューを生成すると、高いパフォーマンスが得られることである。
【０１９３】
本発明を、好適態様に関して説明してきたが、本発明は、これらの態様に限定されるものであはない。均等な方法、構造、構成、方法、工程、および当業者であれば理解しうる他の変更内容も、以下のクレームの範囲内である。
【図面の簡単な説明】
【０１９４】
【図１Ａ】図１Ａは、本発明の一態様をを実施するためのコンピュータシステムのブロック図である。
【図１】図１は、データの抽象化の単純な例を示すスキーマを示す。
【図２】図２は、本発明の一態様のスキーマを示す。
【図３】図３は、本発明の一態様のスキーマを示す。
【図４】図４は、本発明の一態様のスキーマを示す。
【図５】図５は、本発明の一態様のスキーマを示す。
【図６】図６は、本発明の一態様のスキーマを示す。
【図７】図７は、本発明の一態様のスキーマを示す。
【図８】図８は、本発明の一態様のスキーマを示す。
【図９】図９は、本発明の一態様のスキーマを示す。
【図１０】図１０は、本発明の一態様のスキーマを示す。
【図１１】図１１は、図２〜１０に示したスキーマの拡張を示す。
【図１２】図１２は、本発明の一態様にしたがって作動させたコンピュータシステムによって生成したビューフォームの例を示す。
【図１３】図１３は、本発明の一態様にしたがって作動させたコンピュータシステムによって生成したエディットフォームの例を示す。
【図１４】図１４は、本発明の一態様にしたがって作動させたコンピュータシステムによって生成した履歴フォームの例を示す
【図１５】図１５は、本発明の一態様にしたがって作動させたコンピュータシステムによって生成したリストフォームの例を示す。
【図１６】図１６は、本発明の一態様にしたがって作動させたコンピュータシステムによって生成した報告フォームの例を示す。
【図１７】図１７は、本発明の一態様のスキーマの一部を示す。
【図１８】図１８は、本発明の一態様のスキーマのさらなる一部を示す。
【図１Ａ】
2006524376.tif 000005
【図１】
2006524376.tif 000006
【図２】
2006524376.tif 000007
【図３】
2006524376.tif 000008
【図４】
2006524376.tif 000009
【図５】
2006524376.tif 000010
【図６】
2006524376.tif 000011
【図７】
2006524376.tif 000012
【図８】
2006524376.tif 000013
【図９】
2006524376.tif 000014
【図１０】
2006524376.tif 000015
【図１１】
2006524376.tif 000016
【図１２】
2006524376.tif 000017
【図１３】
2006524376.tif 000018
【図１４】
2006524376.tif 000019
【図１５】
2006524376.tif 000020
【図１６】
2006524376.tif 000021
【図１７】
2006524376.tif 000022
【図１８】
2006524376.tif 000023
【国際調査報告】
2006524376.tif 000024
2006524376.tif 000025
2006524376.tif 000026