JPH0212464A - データベース・システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、コンピユータ化されたデータベース・システ
ム、特にデータ操作に言語のステートメントによりアク
セスされるリレーショナル・データベース・システムに
関する。

Ｂ、従来技術 データベース・システム中の全てのデータは、スキーマ
記述により特徴付けられる。スキーマ記述自体はそれを
記述するスキーマにより特徴付けられる。このスキーマ
記述は、データベース・オブジェクト間の関係及び属性
を定める。この情報は、リレーショナル・データベース
の動作時にＤＭＬ　（データ操作言語）ステートメント
のコンパイル中にアクセスされなければならない。これ
は所定のステートメントに適合する、データベース・オ
ブジェクト間の関係及び属性を識別するために必要であ
る。

前述のものの一例として、構造化照会言語（ＳＱＬ）と
して知られている１つの形式の照会言語が広く受は入れ
られており、ユーザが高水準、−般的且つ非手続き的な
ステートメントとしてデータベース動作を特定すること
を可能にしている。

ＳＱＬはＡｍｅｒｉｃａｎ　Ｎａｔｉｏｎａｌ　５ｔａ
ｎｄａｒｄ　Ｉｎ５ｔｉｔｕｔｅ発行のＤｒａｆｔ　Ｐ
ｒｏｐｏｓａｌ　ＡＮＡ　Ｄａｔａｂａｓｅ　Ｌａｎｇ
ｕａｇｅＳＱＬ　５ｔａｎｄａｒｄ　ｘ３．　１３５−
１９８６に詳述されている。またＳＱＬの詳細な説明は
ＩＢＭ社発行の“ＩＢＭ　Ｄａｔａｂａｓｅ　２ＳＱＬ
　Ｒｅｆｅｒｅｎｃｅ”文書番号５Ｃ２６−４３４６−
３にも示されている。

ユーザは、単に動作（データの取り出し、更新、挿入、
等）を指定し、次にその動作が行なわれるデータベース
・オブジェクト（表、ビュー又は列）がどれかを特定す
るだけである。例えば、第１図を参照すると、リレーシ
ョナル・データベースの単純化された例が描かれている
。この情報を含むリレーショナル・データベースのユー
ザが、図示の表の中に示された従業貴名（ＮＡＭＥ）、
従業員番号（ＥＭＰ　　Ｎｏ）　、及び給与（ＳＡＬＡ
ＲＹ）を検索したいものと想定する。対応するＳＱＬス
テーメントは次の通りである。

５ＥＬＥＣＴ　　ＮＡＭＥ、ＥＭＰ　　Ｎｏ。

５ＡＬＡＲＹ　　　ＦＲＯＭ　　　ＥＭＰＬＯＹＥＥＳ
ＱＬ要求は非常に高水準、即ちファイル、インデックス
等が指定されないので、コンパイラがこの情報を与えな
ければならない。またコンパイラは、ＮＡＭＥ、ＥＭＰ
　　Ｎｏ及び５ＡＬＡＲＹが表ＥＭＰＬＯＹＥＥに属す
る有効な列であることを確認しなければならない。さら
に、コンパイラは、指定された列が操作（例えば検索）
可能で、且つ指定されたコンテキスト中で使用可能であ
ることを確認しなければならない。例えば、照会ステー
トメントがさらに拘束条件ｒＷＨＥＲＥ　　ＮＡＭＥ　
　ＧＲＥＡＴＥＲＴＨＡＮ　　＄１００００」を含む場
合、これは明らかに有効なステートメントではない。と
いうのはＮＡＭＥ　（文字フィールド）が＄１００００
を含む（文字フィールドとは適合しない）整数フィール
ドと比較されようとしているからである。そのような確
認検査が全て終了すると、コンパイラはさらにＥＭＰＬ
ＯＹＥＥ表をいかにしてアクセスするかを決定する、即
ちＥＭＰＬＯＹＥＥ表の物理的なファイル名を決定し利
用可能なインデックスを解析しデータを検索するのに必
要なデータ構造を構成する等の作業を行なわなければな
らない。

従って、上記要求される確認及び物理的アクセス・タス
クの合成を行なうために、データベースにより維持され
る全部のオブジェクトの物理的特性を記述する定義デー
タが記憶される必要がある。

この情報は１組のシステム・カタログ中に記憶される（
その概略的な例が第２図〜第５図に描かれている）。こ
れらのカタログは外部的にユーザに可視であり、データ
ベース内の全てのオブジェクトの物理的属性及びデータ
ベース内のあるオブジェクトと他のオブジェクトとの間
の関係（これに関して、特定の依存関係、例えば表に対
する列の関連、列に対するインデックスの関連、等が存
在する）を定義する。

コンパイル中に、ユーザの要求のなかで指定された全て
のオブジェクトに関する情報が、それらのオブジェクト
の必要な物理的記述を得るためにシステム・カタログか
らアクセスされなければならない。さらに、指定された
オブジェクトに対して依存関係を有する他のオブジェク
トの記述もアクセスされなければならない。この活動は
、典型的な場合には、多数のディスクＩ１０及びそれら
のオブジェクトについて記述するレコードのロツりを生
じることがある。

従って照会を実行するのに必要なコンパイラ時間という
点でかなりのコスト高になる可能性がある。例えば第２
図〜第４図及び第６図トに描かれており表、列及びイン
デックスの記述より成るシステム・カタログは、通常は
各々別個のファイルであり、各オブジェクトが別々の行
に記憶されている。従って、照会を実行するにはそのよ
うなシステム・カタログの全て及び多数の行に、関連回
数のＩ１０動作を行なってアクセスする必要がある。リ
レーショナル・データベースの状態情報は例えば表から
ｎ個の列へのｌ：ｎの写像であり、列から関連のインデ
ックスへの１：ｍの写像であるので、全部で１：ｎ：ｍ
のオブジェクトの写像がコンパイルに必要であり、これ
は（最悪の場合には）ｎＸｍのＩｌｏが要求される事態
を生じる可能性がある。以上述べた手続きは、ＤＢＱ及
びＳＱＬ　　ＤＳの名称の下にＩＢＭ社によって販売さ
れている公知のシステムを含む従来のデータベース・シ
ステムの動作に存在している。

従来のデータベース・システムの方式は、ＤＭＬステー
トメント中で参照されるオブジェクト及び部分オブジェ
クト毎にシステム・カタログから行を検索しなければな
らながった。オブジェクト及び部分オブジェクトを決定
するために、「リンク」が部分オブジェクトのカタログ
・テーブルを親オブジェクトのカタログ・テーブルに接
続した。

例えば、列オブジェクトは表オブジェクトの部分である
。言いかえると、列は表なしには存在できない。従って
、ＳＹＳ、ＣＯＬＵＭＮＳ中の行はＳＹＳ、ＴＡＢＬＥ
Ｓ中の行に対するリンクを含まなければならない。これ
はＳＹＳ、ＣＯＬＵＭＮＳの行の中の列ＴＢＮＡＭＥ及
びＴＢＣＲＥＡＴｏ　Ｒ１７）値が、ＳＹＳ、ＴＡＢＬ
ＥＳの行中のＮＡＭＥＳ及びＣＲＥＡＴＯＲの値に一致
する時に達成される。ＤＭＬステートメント中で参照さ
れる表又はビュー・オブジェクトに関して、所与の表に
リンクされたＳＹＳ、ＣＯＬＵＭＮＳＯ行のできるだけ
全てが、コンパイラにより検索される必要がある。同様
に、インデックス情報の全てが表参照に関してアクセス
されなければならない。

この活動は、当然のこととして、以前に注意した多数の
ディスクＩ１０を生じ、その結果それらのオブジェクト
について記述した行のロッキングを生じ、高い並列性を
与えることは不可能になる。

例えば、１００個の列と２個のインデックスを有する表
の全ての列を返す５ＥＬＥＣＴステートメントが与えら
れると、１０３個の取り出し動作が要求される（表オブ
ジェクトを記述する１つの行、各列オブジェクトを記述
する行、及び各インデックス・オブジェクトを記述する
行）。さらに、コンパイルの目的で検索される列のある
ものも、ユーザによって共通に照会され（例えば列のデ
ータ型）従って外部形式（即ち、例えば文字ストリング
ｒＩ　ＮＴＥＧＥＲＪ　）でカタログ中に保持される。

これは、当然のこととして、それらがコンパイラにより
受は取られる毎に内部形式への写像を必要とする。

Ｃ１発明が解決しようとする問題点 以上の記載から、コンパイル時のデータベース・オブジ
ェクトの解析において劇的に性能を改善する新規な技術
が大いに必要とされ且つ探し求められていたことが、容
易に認められるであろう。

さらに、比較的に安価であり且つ実現が容易であるにも
かかわらず、同時にデータベースをアクセスする既存の
アプリケーション・プログラムに適合性のある新規なシ
ステムが切望されていた。

Ｄ１問題点を解決するための手段 本発明によれば、異なったオブジェクト（データベース
に対して定義された表又はビュー等）及び全てのその部
分オブジェクト（関連する列及びインデックス等）に関
連する属性を定義するデータを含むエントリを有する複
数のパックされた記述を表の中の列として提供するシス
テムが開示される。

特定のオブジェクトに対応する行をアクセスすると、オ
ブジェクト自体について述べた情報及びオブジェクトの
部分オブジェクトの全ての属性についての記述が得られ
る。パックされた記述の情報は、互換性のために、デー
タ操作言語（ＤＭＬ）ステートメントのコンパイル中以
外の時に使用するために他のシステム・カタログ中に通
常の形で冗長に記憶されている。それによりエンド・ユ
ーザは、他のデータベース製品と矛盾しないやり方でオ
ブジェクトの物理的定義を照会できる。

パックされた記述を構成するデータベースの状態の情報
は内部形式で保持されているが、対応する冗長な情報は
ユーザに可読な外部形式で保持されている。スキーマ・
データに関するスキーマを非正規化（ｄｅｎｏｒｍａｌ
　１ｚｅ）することにより、オブジェクト間の関係を識
別することが単純化され、ＤＭＬステートメントのコン
パイルに要する時間が大幅に減少する。ＤＭＬステート
メント中で指定されたオブジェクト及びステートメント
のコンパイルに必要な部分オブジェクトの属性に関する
全ての情報は、１回のＩ１０動作で、オブジェクトに対
応するパックされた記述のフィールドから取り出される
。さもなければ、オブジェクトの記述は、集合的にその
記述を含む別々のシステム・カタログに対する多数のＩ
１０動作により検索しなければならない。

Ｅ、実施例 第２図〜第５図及び第８図を参照して、本発明が取り組
んだ問題点の一般的な説明とその解決策への一般的なア
プローチの議論を行なう。その後でさらに具体的な実施
例の詳細な説明を行なう。

第８図を参照すると、リレーショナル・データベース・
システムにおいてアクセスされる又はそれに関連すると
考えられる代表的な一般的且つ単純化されたデータの列
が描かれている。この例では、ＥＭＰＬＯＹＥＥ　（従
業員）表１０が、従業員番号（ＥＭＰ　　Ｎｏ）　、指
名（ＥＭＰ　　ＮＡＭＥ）、給与（ＳＡＬＡＲＹ）及び
部門番号（ＤＥＰＴ　　Ｎｏ）等の情報を含む各従業員
に関する多数のレコードを含む。従来のリレーショナル
・データベースでは、第２図〜第４図のような複数のシ
ステム・カタログが設けられている。第２図には従来の
システム・カタログ１２の概略図が与えられている。そ
の目的は、データベースを構成する第８図のような複数
の表についての詳細を与えるためである。例えば、従業
員番号に関する列、及び従業員の部門が存在し従ってそ
の従業員が働いている事業所の所在地を示す別の列を有
する従業員所在地表等の付加的な表が存在することもあ
る。それらの種々の表の中の共通の要素により、その共
通性を利用することにより関連情報を導き出せる。例え
ば、従業員番号が上記の従業員表及び従業員所在地表で
共通なので、その情報を利用して、第１表からの特定の
従業員の氏名を第２の表から導き出された従業員の働い
ている場所に関連付けることができる。

第２図で、ＳＹＳ、ＴＡＢＬＥＳカタログ１２は、各表
毎に１つのレコード・エントリあるいは行を含み、第２
図に参照番号１８で示される行は第８図の従業員表に関
係している。ＳＹＳ、ＴＡＢＬＥＳカタログ中の列は、
例えば表の名前（従業員表１０の場合は“ＥＭＰ”）、
表の作成者、及び統計情報を含む。この統計情報はデー
タ操作言語のステートメント等に関するコンパイル時に
、又は周知の他の目的のために使われる。さらにＳＹＳ
、ＴＡＢＬＥＳカタログ１２の各レコードに関して、フ
ィールドＩＤ列２２が設けられる。これにより、表に対
する付加的情報を導き出すことのできるレコードの各々
に関連してファイル位置が与えられる。第２図で、さら
に付加的な列ＰＤ２０が斜線領域として示されている。

これはＳＹＳ、ＴＡＢＬＥＳカタログ１２の各レコード
に関して従来技術では知られていない、本発明の一部分
を成す、以下詳細に説明する付加的フィールドが含まれ
ていることを示している。現在の目的に関して、ＰＤと
はパックされた記述（ｐａｃｋｅｄｄｅｓｃｒｉｐｔｉ
ｏｎ）を示し、長フィールド・ファイル形式においては
、その特定のＰＤが現れるレコードに関連する特定のオ
ブジェクトの全ての部分オブジェクトの記述を含むこと
を注意するだけで充分であろう。ＳＹＳ、ＴＡＢＬＥＳ
中のレコードは、表又はビュー等のデータベースの各オ
ブジェクト毎に存在する。

第３図は、現在説明している例のデータベースの一部分
を成す、従来のシステム・カタログのＳＹＳ、ＣＯＬＵ
ＭＮＳカタログ部分の例を示す。

ＳＹＳ、ＣＯＬＵＭＮＳカタログ中の目的は、システム
・カタログのＳＹＳ、ＴＡＢＬＥＳ部分の中にある表の
各々の全ての列の属性の記述を与えることである。より
一般的には、ＳＹＳ、ＣＯＬＵＭＮＳ及びＳＹＳ、ＩＮ
ＤＥＸＥＳカタログ（その代表例が第３図及び第４図に
示されている）は、一意的に関連付けられている。デー
タベースのオブジェクト（例えば第２図のシステム・テ
ーブルに記述された第６図の表）の属性を詳細に記述す
ることを意図された部分オブジェクトに関する情報を含
んでいる。

従って、第３図を参照すると、そこに示されているＳＹ
Ｓ、ＣＯＬＵＭＮＳカタログ１４中の各レコードが、従
業員表１０中の列の相関しているものの属性を記述する
多数のフィールドを含んでいる。例えば、図の最初のレ
コード１３は従業員表１０の第１列の属性を記述し、Ｓ
ＹＳ、ＣＯＬＵＭＮＳ　１４の第２のレコードは第２列
（従業員表１０の従業員氏名）について記述している、
等々。第１のレコード１３をより詳しく見ると、例えば
、その最初のフィールドとして、ｒＴＡＢＬＥＪ列の中
のｒＥＭＰＪは、その右側のデータが、従業員表に現れ
る列に関する属性又は情報であることを示す。レコード
１３のｒｃＯＬ　　ＮＡＭＥ」列２４の下のエントリｒ
ＥＭＰ　　ＮＯｊは、それが対応する表ｒＥＭＰＪの最
初の列ｒＥＭＰＮＯＪの列名に対応するものと考えられ
る。レコード１３中のＥＭＰ　　Ｎｏに続いて、ｒｃＯ
ＬＮＯＪ列２５の下の数字１は、これが従業員表１０の
最初の列であることを示す。次のｒｃＯＬＴＹＰＥＪ２
７は、エントリｒＣＨＡＲＡＣＴＥＲＪ２９を有する。

これはＥＭＰ　　Ｎｏ列のフィールドが文字データであ
ることを示す。最後に、ＳＹＳ、ＣＯＬＵＭＮＳ　ｌ　
４のレコード１３の最後のフィールド、列ｒＬＥＮＧＴ
ＨＪ　３１はエントリ「６」を有し、これはＥＭＰ　　
Ｎｏ列中に現れるデータに関して最大６バイトが許容さ
れることを示す。ＥＭＰ表中の対応する列に関係するレ
コードしかＳＹＳ、ＣＯＬＵＭＮＳカタログ１４中に示
されていないが、データベースの他の表又ハヒューに現
れる列の属性を記述した同様のレコードが現れ、それら
が特定の表又はビューの名前に対応する第２図のＴＡＢ
ＬＥ列中に対応するエントリを存することが認められる
であろう。

第４図を参照すると、あるオブジェクトの部分オブジェ
クトである（ＳＹＳ、ＣＯＬＵＭＮＳカタログ１４中に
属性が記述されている）列に加えて、各オブジェクトの
部分オブジェクトのさらに付加的なりラスが定義可能で
ある。それらはインデックスであり、ＳＹＳ、ＩＮＤＥ
ＸＥＳカタログ１６として示されている。リレーショナ
ル・データベースにおいて周知のように、インデックス
はデータの効率的な回復を容易にするために設けられる
。そのようなインデックスの目的を一般的に理解するた
めに、ＳＹＳ、ＩＮＤＥＸＥＳカタログ１６中のレコー
ド２６として示されているような従業貴名インデックス
がどのように機能するかを示す図解が第５図に与えられ
ている。従業員表ＩＯがデータベースの動作中に時々刻
々と形成され、下記のような挿入ステートメントにより
データが表に付加されるものと想定する。

ｌＮ５ＥＲＴ　　ＩＮＴＯＥＭＰ ＶＡＬＵＥＳ　（３８３６２，ＤＯＥ ７５０００、Ａ６Ａ） このステートメントは、表１０に示されているようなり
ｏｓ氏に関するデータを入力するために使われる。次に
、例えば下記のステートメントにより、Ｄｏｓ氏を含む
かもしれない従業員に関するデータのあるものがアクセ
スされると想定する。

５ＥＬＥＣＴ　　ＦＲＯＭ　　ＥＭＰ　　ＷＨＥＲＥＤ
ＥＰＴ　　Ｎ０＝Ａ６Ａ　　ＡＮＤ ＳＡＲＡＲＹ＞５００００ この照会はＳＱＬ形式である。このステートメントをコ
ンパイルし実行する時、Ｄｏｓ氏に関するファイルが必
要になると、そのファイルに関係するレコード１０を見
つける必要がある。第５図のＥＭＰ　　ＮＡＭＥインデ
ックスに示されているように、インテ・ンクスは従来技
術で周知の通常のＢ木構造であり得る。単純化された例
ではＤｏｓ氏のスペリングにアルファベット的に対応す
るノードをサーチすることにより、Ｄｏｓ氏に関する所
望の情報を有するファイルの位置を含むレコードＩＤ２
８に到達する。

従来技術に伴う１つの問題は、システム・テーブル１２
、システム列１４、及びシステム・インデックス１６を
含む前述のシステム・カタログが、通常はそこからデー
タを検索するために別個の■１０動作が必要であるよう
な記憶装置に記憶されていることである。データのアク
セスに必要なＳＱＬ形式の上述のようなりＭＬステート
メントのコンパイル時に、通常、照会結果を返すために
ＤＭＬステートメント中で定義された各オブジェクトに
対応するシステム・カタログの各々にアクセスする必要
がある。これは多数のＩ１０動作及びそれに付随するレ
コードのロックを生じ、これは照会の複雑性と伴に増大
する。そしてＤＭＬステートメントのコンパイル時の性
能の深刻な劣化及び並列性の問題を生じる。後者の問題
に関して、従来のデータベースは、データ・ページ・レ
ベルに対する比較的大きな粒子性（ｇｒａｎｕｌａｒｔ
ｔｙ）のロッキングを提供した。これは最終的には望ま
しくないことが判明している。というのは多数のユーザ
にアクセスを許容するデータベース・システムでは、並
行性が問題になる、即ち首尾一貫した状態を保つために
あるユーザが使用している間にロックアウトされる他の
ユーザがデータベースにアクセスすることを妨げられる
からである。これはこの技術分野の初期には問題でなか
ったかもしれないが、データベースのユーザの数が増加
するとともに、この従来のシステムの深刻な限界が明白
化した。ユーザは行ロッキングのためにしばしばロック
アウトされ、前述の多数のＩ１０動作により、照会ステ
ートメントをコンパイルするために甚だしく長時間が必
要であった。

ここで本発明に関するより詳細な説明を行なう前に、要
約を行なうと、全てのリレーショナル・データベースは
第２図〜第４図を参照して説明したような１組のシステ
ム・カタログを含まなければならない。それらは通常、
オブジェクトと呼ばれる表及びビューの記述、並びに以
下部分オブジェクト（ｃｏｍｐｏｎｅｎｔ　ｏｂｊｅｃ
ｔ）と呼ばれる関連の列及びインデックスの記述より成
る。各々のカタログはそれ自身、表である。表の属性を
定義するシステム表には、そのような表毎に１つのレコ
ードが存在する。同様に列及びその属性を定義するシス
テム列には、各表の列毎に１つのレコートカ存在する。

これらのシステム・カタログは、エンド・ユーザがデー
タベースに照会を行ない、データベース中のオブジェク
ト及び部分オブジェクト並びにそれらの属性を見い出す
ことを可能にする目的のためのものである。

エンド・ユーザは通常、そのようなカタログを修正でき
ず、ただそれを照会することしかできない事、及びデー
タベース管理システムの機能がそのようなカタログを管
理し、データベースの変更とともに時々刻々とそれらを
更新すべき事に注意されたい。従って、カタログは、カ
タログを通じて知ることのできるデータベースに関する
任意の時点の状態情報と見なすことができる。前述のよ
うに、従来技術の深刻な欠点は、照会を解決するために
、照会ステートメントを構文及び意味論等の検証におい
て確認及び合成するためにそれをコンパイルする必要が
ある事である。しかし、このコンパイルを行なう時、シ
ステム・カタログ中の情報を見る必要がある。そのよう
な情報のアクセスは性能上非常にコストがかかる。とい
うのは例えば３つの異なった表と種々のデータベース行
にアクセスする必要があり得るからである。従来技術の
そのような表は、おそら（システム表に対するＩｌｏ、
システム列に対するｎ回のＩｌｏ、並びに、システム列
及び関連行に関係する各インデックスに関するｍ回のＩ
ｌｏを必要とするにもかかわらず、それ自身のＤＯＳフ
ァイルを有していた。その上に、アクセス中にロックが
生じ、さらにコンパイルの速度を低下させ、並列性に悪
影響を与える。

これらの問題を回避するために、本発明は、バツクされ
た記述における照会ステートメントをコンパイルするた
めに必要な情報を冗長に記憶する。

従って本発明の技術思想に従えば、以前には集団的に拡
散しそして従来は多数のシステム・カタログ及び行の上
にあった情報を単一のフィールドが含んでいる。従って
本発明は、付随的なＩｌｏ及び性能の低下を伴なう個々
のファイルを別々にアクセスする必要性を回避し、それ
によって１回の１１０で１つのファイル位置に情報が得
られる。

システム・カタログ情報の形成又は変更の結果として、
対応する上記のパックされた記述情報も形成又は変更さ
れ、それがパックされた記述として記憶されるのみなら
ず、各々の従来のＳＹＳ。

ＴＡＢＬＥＳ、ＳＹＳ、ＣＯＬＵＭＮＳ及びＳＹＳ、Ｉ
ＮＤＥＸＥＳカタログ中に通常の方式で冗長に記憶され
るデータベースが変化する時、形成されたパックされた
記述は、付加及び修正を含めて更新され、従って通常の
表の中に含まれる。

さもなければシステム・カタログ中に存在するパックさ
れた記述情報を冗長に提供することの意義は、それによ
ってこれがシステム間のプログラムの移植性を提供する
ことである。従来のアプリケーション・プログラムは例
えばアプリケーションの実行中にこれらのシステム・カ
タログ・ファイルに個々にアクセスする必要があった。

この情報を冗長に提供することにより、パックされた記
述の提供はアプリケーション及びユーザにとって透明に
なるであろう。しかし、効率的なスキーマ表現を形成し
維持するためのこの方法は、１：ｎ：ｍの写像を１つの
フィールドに減縮し１：１の対応を与えることによりＤ
ＭＬステートメントのコンパイル時にＩ１０処理を最小
限にするという重要な前述の利点を有する。

本発明に対する明らかな欠点は、従来のシステム・カタ
ログに加えて、パックされた記述の状態情報を冗長に記
憶するために必要な（ディスク又は他の媒体の）記憶装
置の増加、並びにその情報の形成時に少し長い時間がか
かること、即ちパックされた記述のデータの形成及び更
新に関係した付加的な時間を要することである。しかし
、ＤＭＬのコンパイル時に本発明により提供される性能
の劇的な改善並びに形成及び更新に関するデータベース
照会の頻度の増大は、本発明の大きな利点を示している
。

本発明の一般的な特徴は、第２図のＳＹＳ、ＴＡＢＬＥ
Ｓカタログ１２中の参照番号２０で示すような前述のパ
ックされた記述を提供することである。このパックされ
た記述は、それに対応するオブジェクトに関係したシス
テム・カタログ情報の全て（そのオブジェクトを含むス
テートメントのコンパイルに必要な全ての情＠）を含む
。しかし、より重要なこととして、パックされた記述は
長いフィールドのファイルに記憶され、それによりこの
オブジェクトの部分オブジェクトに関する必要な情報の
全てが１個のＩ１０動作中にアクセスできることである
。

第１図を参照すると、所定の表の行に関する一般的なパ
ックされた記述の列エントリの概略図が示されている。

別個のそのようなフィールド・エントリは、各オブジェ
クト毎にＳＹＳ、ＴＡＢＬＥＳカタログ１２及びＳＹＳ
、ＴＡＢＬＥＳカタログ１２中に示すようなそれが対応
するレコード中に与えられている。

第１図を参照すると、各々のパックされた記述は、１つ
の実施例では好ましくは特定のデータベース・オブジェ
クトを参照し、一般的な形式で別々の長いフィールドの
ファイルに含まれる。パックされた記述は、当技術分野
で周知の目的のヘッダ情報を含み、さらに複数の列の記
述及び複数のインデックスの記述がそれに続く。列記述
及びインデックス記述の両者は、特定のパックされた記
述がそれに関連する所の特定のオブジェクトに関する全
てのものである。そのようなパックされた記述の各々は
ＳＹＳ、ＴＡＢＬＥＳカタログの異なった行に対応する
。従業員表１０のような表オブジェクトの場合には、対
応するパックされた記述において、表中の各列毎に列の
記述が存在する。

そのような列の記述の各々は特定の表に対応するＳＹＳ
、ＣＯＬＵＭＮＳカタログ中の行に対応し、列名、列番
号、型（整数、文字、長フィールド、等）の情報を含む
。最後に、同様に、第１図に示すように、従業員表オブ
ジェクトに関係するインデックス毎に別々のインデック
ス記述が与えられ、それらはＳＹＳ、ＩＮＤＥＸＥＳカ
タログ中の別々の行エントリに対応する。それらは、そ
の特定のインデックスが関係する表の名、インデックス
ＩＤ、そのインデックスが関係する列の名、等に関する
情報を含んでいる。

第７図に、そのようなパックされた記述の単純化された
例が、第２図〜第４図及び第６図に示した例のシステム
・カタログに関するものとして示されている。説明を簡
単にするために、インデックスの記述は例から削除され
ている。

第８図及び第８Ａ図は、既存のデータベース・アプリケ
ーション・プログラムと一緒に用いられている通常のシ
ステム・カタログと共に、パックされた記述の列記述部
骨を形成、変更及び更新するためのプロセスの流れ図を
示す。同様に、第９図は、オブジェクトのインデックス
に関するパックされた記述の部分を形成、変更及び更新
し、且つ通常のＳＹＳ、ＩＮ、ＤＥＸＥＳカタログに関
して同様の操作を行なう事に関するプロセスの流れ図を
示す。本発明のさらに別の特徴は、このパックされた記
述の情報を、容易にアクセスできない２進形式等の内部
形式で提供し、且つ冗長なシステム・カタログ情報を、
より便利に使用するために外部形式あるいはユーザ・フ
レンドリでアクセス可能な形式で提供することである。

このようにして、既存のデータベース・システム及びア
プリケーションとの互換性を与えながら本発明のシステ
ムの有用性が保持される。

第１０図を参照すると、第８図、第８Ａ図、及び第９図
に示すようなＳＹＳ、ＣＯＬＵＭＮＳ及びＳＹＳ、ＩＮ
ＤＥＸＢＳカタログに関して、生成、記憶及び更新され
た、パックされた記述の情報を用いるためのプロセスの
ための一般的な流れ図が示されている。

第８図を参照すると、この図は、パックされた記述の列
記述及びコンパイラ・システム（第８Ａ図の実施例では
インタープリタ・システムを用いている）を用いた従来
のシステム・カタログを形成、変更及び更新するための
プロセスの良好な実施例を示す。コンパイル時（パック
された記述の形成を含む）に、表形式ステートメントが
受は取られる（ステップ４９）と、ステップ５１で最初
に表の名前が処理される。次に、ステップ５３で、パッ
クされた記述が初期化され、そしてステップ５５で列定
義の処理が行なわれ、ステップ５７でパックされた記述
に関連の列の記述が付加される。

次にステップ５９で、それ以上の列が存在するか否かに
関する判定が行なわれ、もしそうであれば処理はステッ
プ５５にループ・パックし、別の列の定義を処理し続け
る９列が残っていない時は、処理はブロック５９のＮＯ
の枝を出て、ステップ２９で、パックされた記述のヘッ
ダが修正される。

第８図を続けると、実行的にソフトウェアは下記のステ
ップを実行する。最初に、データベース・プログラムが
表形式ステートメントが（パックされた記述を含む内部
形式で）ステップ３１で受は取られると、ステップ３３
でＳＹＳ、ＴＡＢＬＥＳがオープンされる。次にステッ
プ３５で、ＳＹＳ、Ｔ、ＡＢ、ＬＥＳにその表を特徴付
けるレコードが付加される（これはパックされた記述を
含む）。そしてステップ３７でＳＹＳ、ＴＡＢＬＥＳが
クローズされる。次に、ステップ３９でＳＹＳ、ＣＯＬ
ＵＭＮＳがオープンされ、ステップ４１で、パックされ
た記述から最初の列記述が取り出される。次に、ステッ
プ４３で、新しいレコードがＳＹＳ、ＣＯＬＵＭＮＳに
付加され、ステップ４５で、さらに列の記述が要求され
ているか否かが判定される。もしそうであれば、処理は
ステップ４３にループ・パックし、さらに別のレコード
をＳＹＳ、ＣＯＬＵＭＮＳに付加する。一方、もしそれ
以上の列の記述が不要であれば、処理は終了し、ステッ
プ４７でＳＹＳ、ＣＯＬＵＭＮＳがクローズされる。

再び第８Ａ図を参照すると、第８図のコンパイラ方式の
システムに対して、インクプリタ式のシステムが示され
ている。最初に、ステップ３０で、表を形式又は変更す
るために呼び出されるルーチン又はプロセスによりステ
ートメントが受は取られる。それに応じてプロセスはス
テップ３２でＳＹＳ、ＴＡＢＬＥＳファイルをオープン
し、ステップ３４で通常のＳＹＳ、ＴＡＢＬＥＳカタロ
グ３４にレコードを形成又は付加し、その表を特徴付け
、ステップ３６でヘッダ及びトレーラ情報を含むパック
された記述が初期化される。次にステップ３８でＳＹＳ
、ＣＯＬＵＭＮＳファイルがオープンされ、ステップ４
０で、新たに形式又は付加された、列情報のレコードが
ＳＹＳ、ＣＯＬＵＭＮＳカタログに付加される。ステッ
プ４２で、パックされた記述が同様の列情報に付加又は
それを用いて変更される。そしてステップ４４で、新し
い列を付加又は変更したいか否かが判定される。

もしそうであれば、処理はループし、ステップ４０及び
４２を繰り返す。これはステップ４４での検査が、もう
列を形成又は変更する必要がない事を示すまで継続する
。新しい又は変更された表の各列に関して、パックされ
た記述の列部分が形成及び記憶されると、ステップ５０
でＳＹＳ、ＣｏＬＵＭＮＳファイルがクローズされる。

ステップ５２で、ステップ３６及び４２のパックされた
記述情報がメモリ中の関連フィールドに記憶され、ステ
ップ５４でＳＹＳ、ＴＡＢＬＥＳファイルがクローズさ
れる。

同様に第９図及びインデックス情報を参照すると、コン
パイラ方式のシステムである本発明の良好な実施例では
、コンパイル時に、ステップ６１で、インデックス・ス
テートメントが形成又は変更されるべきであるという指
示をデータベースが受取る。次にステップ６３で関連の
表名が処理され、次にステップ６５でインデックスの定
義が処理される。その後でインデックスの記述がステッ
プ６９で形成される。実行時に、ステップ６０でインデ
ックス・ステートメントが形成又は変更されるとい指示
（内部形式のもの）をデータベースが受取る時、再びＳ
ＹＳ、ＴＡＢＬＥＳファイルがステップ６２オーブンさ
れ、ステップ６４でＳＹＳ、ＴＡＢＬＥＳカタログから
レコードが検索される。ステップ６６で、ステップ６４
の表から得られた対応するパックされた記述の位置から
、対応するパックされた記述がアクセスされ、ステップ
６８でＳＹＳ、ＩＮＤＥＸＥＳファイルがオープンされ
る。ステップ７０で、形成又は変更された特定のインデ
ックスを記述するレコードが通常のＳＹＳ、ＩＮＤＥＸ
ＥＳカタログに挿入され、そしてステップ７２でコンパ
イラにより作成された関連のパックされた記述の対応す
るインデックス記述部分が変更される。ＣＲＥＡＴＥ　
　ＩＮＤＥＸステートメント毎に１つだけのインデック
スしか形成されないので、ステップ８０でＳＹＳ。

ＩＮＤＥＸＥｓファイルがクローズされる。ステップ７
２で形成されたインデックスに関するパックされた記述
は、次にステップ８２でパックされた記述フィールドに
記憶される。最後に、ステップ８４でＳＹＳ、ＴＡＢＬ
ＥＳファイルがクローズされる。

第１０図に、本発明のパックされた記述がデータベース
・システムにより用いられる過程が示されている。取り
出し、挿入、更新又は削除に関するＤＭＬステートメン
トのコンパイル中の表又はビュー等のオブジェクトに対
する各々の参照は、システム・カタログ中に含まれるオ
ブジェクトの記述及びパックされた記述にアクセスする
必要がある。ＤＭＬステートメント中で最初の表又はビ
ューのオブジェクトの参照が行なわれると、ステップ８
６でシステム・テーブルがオープンされ、ステップ８８
でオブジェクトに関する対応するパックされた記述を含
む表に関してアクセスするために対応するレコードが読
み取られる。データベースからメモリへ適当なパックさ
れた記述を検索するために取り出し要求が発行されると
、ＤＭＬステートメント中で同じオブジェクトが再び参
照される時、コンパイラは既にメモリ中にあるパックさ
れた記述を参照することができ、従ってＩｌｏを節約で
きる。１回のＩ１０動作でそっくりメモリから適当なパ
ックされた記述が検索される場合、コンパイラは、１度
、表又はビューのパックされた記述にアクセスすると、
オブジェクト及び部分オブジェクトに関する必要な情報
を得るためにそれをトラバースする。

第１１図は本発明のパックされた記述を用いたコンピユ
ータ化されたリレーショナル・データベース・システム
の単純化された概略図である。最初に、プロセッサ９６
が設けられる。これは任意の数のマイクロ、ミニ及びメ
イン・フレーム・コンピュータの形を取り得る。さらに
、第８図〜第１０図を参照して述べたプロセスを実現す
るためのコンピュータ・プログラムを含むデータベース
・プログラムを記憶するために記憶装置９４が設けられ
る。さらに、（ハード・ファイル等の形の）記憶装置９
４は、コンピユータ化されたリレーショナル・データベ
ース及びパックされた記述を用いて照会が行なわれる第
１図のようなリレーショナル・データを記憶する。キー
ボード９２は、記憶装置９４に記憶されたリレーショナ
ル・データへのデータ入力、その更新及び編集コマンド
、並びにコンパイル中にパックされた記述を用いること
のある種々のデータベース検索コマンド又は照会を含む
システムへの入力をユーザが行なうために設けられる。

デイスプレィ装置９０は、データベース・システム及び
キーボード９２からの認知可能な出力をユーザに提供す
るために設けられる。通常のアドレス・コマンド及び制
御バス線を含む従来技術で周知の適当な相互接続９８が
、プロセッサ９６、記憶装置９４、キーボード９２、デ
イスプレィ装置９０及び２次記憶装置を相互接続するた
めに設けられる。

本発明のパックされた記述は、好ましくは、ＳＱＬのデ
ータ型ＬＯＮＧ　　ＶＡＲＣＨＡＲを用いて文字ストリ
ング列としてデータベース中に記憶される。これは長さ
が３２７００バイトまでの可変長文字ストリングである
。内部的には、従来技術で周知のＣ言語の構造体が、こ
の列についての定義を行なうために使用される。前述の
ように、パックされた記述は、ヘッダ情報、その後の一
連の列の記述（表又はビューの各列毎に１つ）、及び最
後の一連の前述のインデックスの記述（表に関して定義
された各インデックス毎に１つ）より成る。パックされ
た記述のヘッダ部分及び列部分は、ＣＲＥＡＴＥ　　Ｔ
ＡＢＬＥステートメント又はＣＲＥＡＴＥ　　ＶＩＥＷ
ステートメントがコンパイルされる時に形成される。ス
テートメントが実行される時、他のリレーショナル・デ
ータベース製品の場合と同様に、表又はビューを記述す
る行がＳＹＳ、ＴＡＢＬＥＳカタログ表中に形成され、
各列毎にＳＹＳ、ＣＯＬＵＭＮＳカタログ表中に行が形
成される。パックされた記述はＳＹＳ。

ＴＡＢＬＥＳカタログの行の中の列の１つである。

その後の列の記述はＡＬＴＥＲＴＡＢＬＥステートメン
トによって付加される。適当な表に関するパックされた
記述の列は付加的な列の記述を含むように更新され、ヘ
ッダ情報（例えば列の番号、インデックス情報へのオフ
セット等）に対する変更が行なわれ、行のＣｏＬＣＯＵ
ＮＴ列が更新される。同様に、インデックスの記述がＣ
ＲＥＡＴＥ　　ＩＮＤＥＸステートメントにより付加さ
れる。この場合、表に関するパックされた記述が、付加
的なインデックスの記述を含むように更新され、ヘッダ
情報（例えばインデックスの数）に変更が行なわれる。

他のデータベース製品と両立するように、各々の新しい
列毎にＳＹＳ、ＣＯＬＵＭＮＳカタログに行が付加され
、各々の新しいインデックス毎にＳＹＳ、ＣＯＬＵＭＮ
Ｓカタログに新しい行が付加される。

パックされた記述の中の値自体が他のカタログ列を生成
する時に使われる。例えば、第８Ａ図を参照すると、Ｓ
ＹＳ、ＣＯＬＵＭＮＳカタログ中の列の中の値は、関連
の表又はビューのパックされた記述の中の特定な列の記
述から導き出される。

従って、これらの列の中に含まれる情報は、パックされ
た記述の列の中に記憶されたデータと矛盾しないことが
保証される。

さらに、パックされた記述は、表及び／又はそのインデ
ックスについて統計情報を集めるユーティリティ・プロ
グラムの実行中に更新される。この情報は、コンパイル
中に、表にアクセスする時に使う最適アクセス戦略を決
定する時に使用される。他のデータベース製品の場合と
同様に、エンド・ユーザによる容易なアクセスを可能に
するためにＳＹＳ、ＴＡＢＬＥＳ及び／又はＳＹＳ、Ｔ
ＮＤＥＸＥＳの列にも各統計情報が記憶される。

表又はビューを定義するステートメントが実行された後
、オブジェクトに関するパックされた記述がコンパイラ
によりアクセスできる。その後のＤＭＬステートメント
（例えば取り出し、挿入、削除等）のコンパイル中の表
又はビューへの各々の参照は、オブジェクトのパックさ
れた記述に対するを必要とする。ステートメント中で最
初に表又はビュー・オブジェクトが参照される時、コン
パイラは、データベースからメモリヘパツクされた記述
を検索するために取り出し要求を出さなければならない
。もし同じオブジェクトがステートメント中で再び参照
されるならば、多くの場合、コンパイラは既にメモリ中
に存在するパックされた記述を参照する。コンパイラが
表又はビューのオブジェクトのパックされた記述にアク
セスすると、それはオブジェクト及び全ての部分オブジ
ェクトに関する情報を得るためにそれを走査する。

パックされた記述の検索は、１つのＩ１０動作により行
なわれるように以前説明したが、より一般的には、コン
パイラによるパックされた記述の検索は、論理的に単一
の行からデータを取り出すことより成っていてもよい。

例えば、この取り出し要求は、１つの長いフィールドに
関するデータの全部を記憶するために１つではなく２つ
の行を必要とするような実施形態の場合、実際には２つ
の物理的Ｉ１０動作を生じ得る。

【図面の簡単な説明】

第１図はシステム・カタログ中のレコードの中に現われ
得る一般的なパックされた記述の列のフィールドの形式
の概略図、 第２図はデータベース中の表の詳細を記述するシステム
・カタログの図、 第３図は表の列の詳細を記述するシステム・カタログの
図、 第４図はインデックスの詳細を記述するシステム・カタ
ログの図、 第５図はインデックスの機能を説明するための図、 第６図はリレーショナル・データベースの単純化された
例を示す図、 第７図はパックされた記述の１例を示す図、第８図は列
についての記述が生成され維持される処理を示す流れ図
、 第８Ａ図は第８図の処理の代替的実施例を示す流れ図、 第９図はインデックスについての記述が生成され維持さ
れる処理の流れ図、 第１０図はパックされた記述がアクセスされ使用される
過程の流れ図、 第１１図はリレーショナル・データベースが稼動してい
るシステムの１例の図である。 １１閃 ７５囚 蔦ＳＡ図 Ｘ１０図 メ１１　隠

Claims (3)

【特許請求の範囲】
1. （１）複数のシステム・カタログを有し、データベース
   ・オブジェクトを参照するステーメントがコンパイルさ
   れる型のリレーショナル・データベース・システムにお
   いて、上記システム・カタログの属性の表現を記憶する
   方法であつて、 上記システム・カタログの１つのオブジェクトの属性の
   表現を生成し、 パックされた記述のフィールドを初期化し、上記パック
   された記述のフィールド中に上記システム・カタログの
   １つの上記オブジェクトの属性の上記表現を記憶するス
   テップを含む リレーショナル・データベースにおける属性の表現を記
   憶する方法。
2. （２）オブジェクトを定義するデータを生成し、上記オ
   ブジェクトに機能的に関連する部分オブジェクトを定義
   するデータを生成し、 上記オブジェクト及び上記機能的に関連する部分オブジ
   ェクトを定義する上記データを１つのシステム・カタロ
   グ中の行として記憶するステップを含む データベースに関するスキーマ記述を管理する方法。
3. （３）データベースを構成するオブジェクト及び部分オ
   ブジェクトに関する記述がそれぞれ複数のシステム・カ
   タログに記憶されるデータベース・システムにおいて、
   各オブジェクトに関連する部分オブジェクトに関する記
   述の写しが、上記各オブジェクトに関する記述を含むシ
   ステム・カタログ中に記憶されるデータベース・システ
   ム。