JPH02146677A - リレーシヨナル・データベース・システム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、コンピユータ化されたデータベースに関し、
さらに詳しくは、リショーナル・データベースのカラム
内での２バイ１へ・キャラクタ・セラｌ〜・データと１
バイ１へ・キャラクタ・セット・データの使用に関する
。

Ｂ、従来技術及びその問題点 データベースは、将来のユーザがらのリフストに応じた
検索のために、大量のデータをストアするのに使われる
。ユーザは、アプリケーション・プログラムであること
もあるし、入力デバイスを通じてデータベース・システ
ムとインターラクトするエンド・ユーザであってもよい
。関連づけられたデータのグループは、普通にリレーシ
ョナル・データベースで使われているように、データ・
ファイルまたはテーブルと呼ばれる。テーブル中のデー
タの行（ロー）は論理レコードと呼ばれ、データのカラ
ム（欄）はフィールドと呼ばれる。リレーショナル・デ
ータベース・システムでは、ユーザは、データをテーブ
ルとしてのみ知覚し、その他の組織形態、たとえばデー
タの階層構造の形では知覚しない。

これらのデータベース・システムは、典型的な場合、デ
ータベース・マネジャーという、ユーザ・インタフェー
スを介して入力される様々なコマンドに応答してデータ
を記憶・編集・更新・挿入・削除・検索するコンピュー
タ・プログラムが、含まれている。データベース・マネ
ジャーは、データベースに対するユーザからのすべての
リクエストを処理し、上記のような様々な機能を実行す
る。

特に、データ検索に関しては、サーチ・コマンド、つま
りデータベース・マネジャーがそれに応答して要求デー
タを供給するところの１間合せ″を定式化するために、
多数のコンピュータ言語が考案されている。これらの間
合せは、基本的には、コンピュータ及び関連するデータ
ベース・マネジャーをして所望のサーチを実行させるべ
く符号化されたサーチ・インス１ヘラクションである。

データベースでの問合せを定式化するためのこれらの言
語には、いくつかの問題点がある。まず、間合せ言語の
多くが普通のプログラミング言語と異なっている。した
がって、ユーザにプロゲラミンクの経験があっても、デ
ータベースから有意なデータを取り出すためだけに、全
く新しいコマンドのセットを学習しなければならなかっ
た。コンピュータ経験が全くないユーザ、例えば多くの
ターミナル・オペレータの場合には、データベースとイ
ンターラクトするためだけに、１種のコンピュータ・プ
ログラミングを学習しなければならなかった。さらに、
かかる間合せ言語は高度かつ複雑なシンタックス及びセ
マンティクス・ルールを必要とするので、データを首尾
よく検索できる人間は、高度かつ高価な訓練をつんだ少
数の者に限られていた。このため、かかるコンピュータ
・システムのユーティリティに悪影響が及び、広範囲な
数の人間による使用を不可能としていた。

構造化間合せ言語（ＳＱＬ）は、エンド・ユーザが情報
を検索するべくデータベース・マネジャーとインターフ
ェースするにあたって利用されるインターラクテイブな
間合せ言語であり、かつデータベース・マネジャーを介
してデータベース中のデータにアクセスすべくアプリケ
ーション・プロゲラ１１中に埋め込むことのできるデー
タベース・プログラミング言語である。、ＳＱＬは、必
要とされる情報のタイプを指定するための簡便な方法で
ある。

かかる間合せ言語の代表は標準間合せ言語、つまり“Ｓ
ＱＬ”であり、その詳細は、ＡＮＡＤａｔａｂａｓｅ　
１．、ａｒｌｇｕａｇｅ　Ｓ　Ｑ　Ｌ　、５ｔａｎｄａ
ｒｄ　Ｘ３．１３５−１９８６、Ａｍｅｒｊ、ｃａｎ　
Ｎａｔｉｏｎａｌ　５ｔａｎｄａｒｄ　Ｉｎ５ｔｉｔｕ
ｔｅ刊に記述されている。Ｓ　Ｑ　Ｌの詳細な説明は、
”ＴＢＭＤａｔａｂａｓｅ２　Ｓ　Ｑ　Ｌ　Ｒｅｆｅｒ
ｅｎｃｅ”ドキュメン１一番号５Ｃ２６−４３４６−３
，Ｉ　Ｂ　Ｍ社刊にても行われている。

例えば、第４図に示すような、名前とアドレスを含むデ
ータのローとカラムを有するテーブル■６を作るために
は、ユーザは、テーブル作成（ＣＲＥＡＴＥ　ＴＡＢＬ
Ｅ）文を発して、データベースを以下のように規定する
ことになる。

ＣＲＥＡＴＥ　　　ＴＡＢＬＥ　　ＤＩＲＥＣＴＯＲＹ
（ＮＡＭＥ　　　　　ＣＨＡＲ（２０）。

ＡＤＤＲＥＳＳ　　ＣＨＡＲ（５０）　）テーブル作成
文は、ＳＱＬデータ定義文の］−例である。各テーブル
の作成文は、作られるテーブルの名前、カラムの名前、
及びカラムのデータ・タイプを与える。テーブル作成文
は実行可能な文である。つまり、テーブル作成文がユー
ザによってターミナルから入力されると、その時点でシ
ステムはテーブルを作るのである。最初、テーブルは空
である。すなわち、データ行は１つもない。

しかしながら、ＳＱＬ挿入文を用いることにより、ユー
ザは第４図に示すようなテーブルを作成することができ
る。テーブルを作成し、かつそこにレコードを挿入し終
えたなら、ユーザは、Ｓ　Ｑ　Ｌデータ操作文を使って
、テーブルからデータを検索することができる。

上述のように、ユーザは、テーブル作成文によっていつ
でもテーブルを作成できるだけでなく、テーブル改造（
ＡＬＴＥＲＴＡＢＬＥ）文によってカラムを付加するこ
とにより、いつでも既存のテーブルを改造することがで
きる。例えば、第４図のテーブル１６にパ市と州（ｃｉ
ｔｙ　ａｎｄ　５ｔａｔｅ）”のカラムを付加する場合
、テーブル改造文は次のようになる。

ＡＬＴＥＲＴＡＢＬＥ　　ＤＩＲＥＣＴＯＲＹＡＤＤ　
　ＣＴＴＹ　　５ＴＡＹＴＥ　　ＣＨＡＲ（２０）上記
文により、テーブル”　Ｄ　Ｉ　ＲＥ　ＣＴ　ＯＲＹ　
”に”ＣＩＴＹ　　５ＴＡＴＥ”のカラムが追加される
。カラム名が指定された後に、該カラムのデータ・タイ
プが指定される。いくつかのデータ・タイプを示すと以
下のにようになる。最後の３つのカテゴリー、ＣＨＡＲ
，ＶＡＲＣＨＡＩ又、及びＬ　ＯＮ　Ｇ　　Ｖ　Ａ　Ｒ
ＣＨＡ　Ｒを、ココテは、キャラクタ・データ・タイプ
と呼ぶことにする。

ＴＮＴＥＧＥＲ符号つきのフルワード２進整数（３］ピ
ツ１へ精度） ＳＭＡＬＬ、工ＮＴ　　　　　　符号つきのハーフワー
ド２進整数（１６ビツ１へ精度） ＤＥＣＩＭ、Ａ、Ｌ　　　　　　　精度２桁の符号つき
パック１０進数。

少数点は右から９桁とする。

ＦＬＯＡＴ　　　　　　　　　符号つきの倍精度浮動小
数点数ＣＨＡＲ（ロ）　　　　　　　長さｎキャラクタ
の固定長キャラクタ・ス１−リング ＶＡＲＣｊ−ＩＡＲ（ｎ）　　　　最大炎をｎキャラク
タとする可変長キャラクタ・ストリング。ただ し、４０００バイ１〜を越えない。

ＬＯＮＧ　　ＶＡＲＣＩ（Ａ、Ｒ３２，７００パイ１〜
を越えない、可変長キャラクタ・ス１−リング この分野については、Ｃ，Ｊ、Ｄａｔａ著、Ａｎ　Ｉｎ
ｔｒｏｄｕｃｔｊｏｎｔｏ　Ｄａｔａｂａｓｅ　Ｓｙｓ
ｔｅｍ、Ｖｏｌｕｍｅｌ、　、　Ｆｏｕｒｔｈ　Ｅｄｊ
、ｔｉｏｎ。

Ａｄｄｉｓｏｎ−１ｉ１ｅｓｌｃｙ　Ｐｕｂｌｊｓｈｉ
ｎｇ　Ｃｏｍｐａｎｙ　Ｉｒ＋ｃ、、１９８６を参照さ
れたい。

ユーザが第４図に示すようなデータ挿入を行うとき、処
理システムは、データを現実に示されるとおりには見な
いで、１とＯのピッ１へ・スＩ−リングとして見る。処
理システムによるビット・ス１〜リングの解釈の仕方は
、データのタイプに応じて様々である。データがテキス
Ｉ・またはキャラクタなら、処理システムはス１〜リン
グを固定ユニツ１−の形で解釈する。この場合、各ユニ
ツ１へは、キャラクタ、数字、またはその他のテキス１
〜・グラフィックを表わす。普通、これらのユニノ１−
はコード・ポインＩ・と呼ばれ、通常、特定のビット幅
、例えば８ビツト（１バイト）の幅を持つ。１バイト・
コード・ポイン１〜・スｈラテージ、つまりエンローデ
ィング・スキームによれば、１−とＯの組合せを変える
ことによって２５６の異なるコード・ポイン１〜が実現
できる。これらの２５６個のロー１く・ポイントを使っ
て、様々なキャラクタ、数字、シンボル等を２５６個ま
で表現することができる。

２５６個のロー１〜・ポイントからなるグループの各々
は、ロー１へ・ページと呼ばれる。英語で使われるキャ
ラクタと数字及び普通に用いられるいくつかのシンボル
のほとんどを表現するためには、コード・ページ１つで
十分である。コード・ページ２１の１例を第２図に示す
。上述の１バイト・コード・ページは、英語を表すのに
は十分である。

しかしながら、日本語には６０００を超すシンボルが含
まれるので、上記エンコーディング・スキームは、様々
なシンボルのすべてを表現するのに用い得ない。

したがって、′より豊富な″エンコーディング・スキー
ムが必要とされる。その１例が、日本二［業規格のシフ
１〜ＪＩＳと呼ばれるものである。シフ１−　Ｊ　Ｉ　
Ｓ規格は、１」本語キャラクタ・セラ１〜及び日本語で
使われる６０００を越すグラフィック・シンボル用のコ
ード・ページを記述している。第３図は、日本語用のロ
ー１−・ページ２２の１例を示している。

第３図を参照すると、１６進コード○ＸＯｏから０ｘ７
Ｅは、アッパーケースとロアケースの英語アルファベッ
ト及び数字等の１パイ１〜・シンボルを表わす。１６進
コート０ｘＡ１からＯｘＤＦは、半角の片仮名を表わし
ている。Ｊ６進コード０ｘ８１から０ｘ９Ｆ、及び０ｘ
ＥＯから０ｘＥＣは、約１１０００〜１．２０００個の
日本語シンボルにアクセスするための″導入パイ１〜と
考えることができる。導入バイトは、２バイ１〜・シー
ケンスの第１バイト目である。したがって、これらの約
１１０００個のシンボルについては、シンボルを識別す
るのに２バイトが必要である。このようにして、２バイ
ト・エンコーディング・スキームが定義される。

さて、日本語では、漢字、平仮名、片仮名という３種類
のキャラクタが使われる。第３図に示すように、片仮名
キャラクタは１バイ１〜・キャラク夕であるけれども、
平仮名と漢字のキャラクタは２バイ１へ・キャラクタで
ある。さらに、日本語ではローマ字も使われる。このこ
とは、第３図において、１６進コード０ｘ４１〜○ｘ７
Ａで示されている。結局、日本語文は、漢字、平仮名、
片仮名、ローマ字、数字及びその他のキャラクタの混合
したものであり、１バイ１−・キャラクタと２バイ１−
・キャラクタの両方が含まれる。

同様に、リレーショナル・データベースが日本語をサポ
ー１−するなら、リレーショナル・データベース中のカ
ラムもまた１バイト・キャラクタと２バイト・キャラク
タを含み得ることになる。

現在のＳＱＬベースのリレーショナル・データベース・
プロダク１へには、（２バイ１へ１パイ１〜の）混合デ
ータを処理しなければならないかどうかを指定するイン
ストレーシミン・オプションがある。

このオプションが指定されたなら、キャラクタ・データ
は混合データとして扱われる。そういうものとして、混
合オプションが指示されると、たとえあるフィールドは
１バイト・データしか含んでいなくても、すべてのフィ
ールドのすへてのデータが混合データとして扱われる。

例えば日本語におけるように、２バイト・キャラクタ・
セットのデータを必要とする環境では、すべてのキャラ
クタを、２バイ１〜・キャラクタ・セット・データと］
バイト・キャラクタ・セラ１へ・データの混合物とみな
さなければならない。混合データを処理するためには、
１バイｌ−・データの場合よりも複雑なアルゴリズムが
必要になる。結果として、混合データが指示された場合
、リレーショナル・データベースのすべてのデータ・カ
ラムの処理によってパフォーマンスが低下してしまう。

従前は、パーソナル・コンピュータの環境において、テ
ーブル中のあるカラムが１バイト・キャラクタ・セラ１
−・データのみのために用いられることを指定する方法
がなかった。したがって、そのようなカラムにより簡単
なアルゴリズムを適用することができなかった。ＳＱＬ
言語は、かかる情報を指定し、蓄える方法を提供してい
なかった。

さらに、２バイト・キャラクタ・セット・データ用 と１バイト・キャラクタ・セット・データを混合して用
いる環境では、 Ｃ１問題点を解決するための手段 したがって、本発明の目的は、１バイト・データと２バ
イト・データが混在するリレーショナル・データベース
において、データ処理のパフォーマンスを向上させるこ
とにある。

本発明の他の目的は、リレーショナル・データベースの
フィールドに含まれるデータが１バイト・キャラクタ・
セット・データのみであることを指定し、もって当該フ
ィールドのデータにより簡単な処理方法を適用し得るよ
うにすることにある。

本発明のシステムにおいては、ＳＱＬ言語が拡張される
。カラム毎にキャラクタ・タイプ・データのサブタイプ
を指定するオプション・パラメータが、テーブル作成文
とテーブル改造文に付加さる。サブタイプは、カラムに
含まれることになるデータが混合データなのか純粋」バ
イ１〜・データなのかを表示する。加えて、ユーザがカ
ラムを１バイト・データ用だと指定する場合には、さら
に。

１バイ１−・キャラクタ・セラｌ−・データ用のコード
・ページを指定することができる。ユーザがカラムを混
合データ用だと指定する場合には、さらに、１バイト・
キャラクタ・セラ１〜・データ用のコート・ページと、
２バイ１〜・キャラクタ・セット・データ用のコード・
ページを、それぞれ指定することができる。

本発明にて用いられるエンコーディング・スキームは、
２つの目的に寄与する。データベース・システム・カタ
ログ内のキャラクタ・カラムの、１バイ１〜・コード・
ページ・７１−リビュート（属性）と２バイト・コード
・ページ・アトリビューがゼロであるのかノン・ゼロで
あるのかをチエツクするだけで、システムあるいはアプ
リケーションは、当該キャラクタ・カラムが混合データ
用又は純粋１バイ１〜・データ用の何れとして指定され
ているかを判断することができ、同時に、当該カラムに
つき用いられることになっているロー１〜・ページを判
断することができる。当該カラムに含まれるキャラクタ
・サブタイプを表示するフラグはコートページそれ自体
であり、該フラグを使って当該カラムについての特殊な
トランスレーション等を実行することができる。例えば
、１バイト・コード・ページ・アトリビュートがノン・
ゼロ値であり、２バイト・コート・ページ・アトリビュ
ートがゼロであるならば、該カラムは１バイ１〜・キャ
ラクタ・セラ１へ・データのみに対応するよう指定され
ている。加えて、ノン・ゼロである１バイト・コード・
ページ・アトリビュートの値は、特定のコード・ページ
を指示する値なのである。

また、１バイト・ロー１へ・ページと２バイト・コード
・ページの７１ヘリビユー１〜が両方ともノン・ゼロで
あるならば、該カラムの内容は、２バイト・キャラクタ
・セット・データと１バイト・キャラクタ・セット・デ
ータを両方持つ混合データである。加えて、この場合の
ノン・ゼロの数値は、１バイト・データにつき使用され
ることになっているコード・ページと２バイト・データ
につき使用されることになっているコード・ページを、
それぞれ指示する。

本発明によれば、データベース・プロダクト及びユーザ
・アプリケーションが、切捨、サブストリング等のデー
タ処理アルゴリズムに関連して、キャラクタ・カラム中
のデータをどのように扱うべきかを知ることが可能にな
る。カラムが１バイト・キャラクタ・セット・データ専
用であるなら、データ処理を大幅に簡略化できよう。本
発明を使わなければ、混合データという最悪のケースを
想定していなければならないのである。なお、本発明の
ようにカラム毎に別個のコード・ページを指示すること
によって、カラム毎に違った照合順序を適用することが
可能になる。

Ｄ、実施例 第１Ａ図と第１Ｂ図は、本発明を実施するのに用いられ
る処理装置の概要を示す。

第１Ａ図は、ＩＢＭ社のパーソナル・システム／２（商
標）で用いられているような、パーソナル・コンピュー
タ・アーキテクチャの１例を示す。

このアーキテクチャの焦点は、マイクロプロセッサ１か
らなる。マイクロプロセッサ１はバス２につながれる。

バス２は、データ・ラインのセット、アドレス・ライン
のセット、及びコントロール・ラインのセットからなる
。複数のＩ１０デバイス、メモリ、記憶装置３〜８が、
それぞれアダプタ９〜１４を介して、バス２に接続され
ている。例えば、デイスプレィ４はＩＢＭパーソナル／
システム・カラー・デイスプレィ８５１４であってよく
、その場合は、アダプタ１０をプレナ・ボードに集積化
することができる。その他のデバイス３，５〜８及びア
ダプタ９，１１〜１４は、ＩＢＭパーソナル・システム
／２の一部として含まれていてもよいし、■ＢＭ社製の
プラグ・イン・オプションとしてアベイラブルであって
もよい。例えば、ＲＡＭ、６．ＲＯＭ７．及びこれに対
応するアダプタ１２．１３は、ＩＢＭパーソナルシステ
ム／２の標準装備ではあるけれども、ＲＡＭ６を補うた
めにプラグ・イン・メモリ・エクスパンション・オプシ
ョンを介してＲＯＭをさらに付加してもよい。

ＲＯＭ７の中には、マイクロプロセッサ１によって実行
される、ＢＩＯ８（基本人出力オペレー＝１６ ティング・システム）として知られる複数の命令が記憶
されている。ＢＩＯ８は、コンピュータの基本動作をコ
ントロールする。Ｏ８，／２　（商標）等のオペレーテ
ィング・システムはメモリ６にロードされ、ＲＯＭ７に
記憶されたＢＩＯ８と協同する。もっとも、ＢＩＯ８の
一部ないし全部をＲＯＭ７ではなくメモリ６に記憶させ
てもよい。そうすることにより、基本的なシステム動作
の修正を、ＢＩＯＳプログラムの変更によって吸収し、
かつ変更したＢＩＯＳプログラムをＲＡＭ６に即座にロ
ードすることができる。

パーソナル・システム／２とＯ８／２に関しては、以下
のマニュアルを参照されたい。

Ｔｅｃｈｎｊ、ｃａｌ　　Ｒｅｆｅｒｅｎｃｅ　　Ｍａ
ｎｕａｌ、ｐｅｒｓｏｎａｌ　　Ｓｙｓｔｅｍ／２　（
Ｍｏｄｅｌ　５０．６０　ｓｙｓｔｅｍｓ）、　ＩＢＭ
コーポレーション、パーツ・ナンバー６８Ｘ２２２４　
、オーダー・ナンバー５６８Ｘ−２２２４，Ｔｅｃｈｎ
ｉｃａｌ　Ｒｅｆｅｒｅｎｃｅ　Ｍａｎｕａｌ。

Ｐｅｒｓｏｎａｌ　Ｓｙｓｔｅｍ／２　（Ｍｏｄｅｌ　
８０）、　ＩＢＭコーポレーション、パーツ・ナンバー
６８Ｘ２２５６　、オーダー・ナンバー５６８Ｘ−２２
５６，ＴＢＭ　ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ／２ｖ
ｅｒｓｊｏｎ　１．Ｏ５ｔａｎｄａｒｄ　Ｅｄｊｔｉｏ
ｎ　Ｔｅｃｈｎｊ、ｃａｌＲｅｆｅｒｅｎｃｅ、　ＩＢ
Ｍコーポレーション、パーツ・ナンバー６２８０２０１
．、オーダー・ナンバー５８７１．−ＡＡＡ。

Ｉａｃｏｂｕｃｃｉ、　Ｅｄ、　Ｏ３／２　Ｐｒｏｇｒ
ａｍｍｅｒ’ｓ　Ｇｕｉｄｅ。

ＭｃＧｒａｔｙ　Ｈｉｌ］、、１９８８゜本発明の装置
では、リレーショナル・データベース・マネジャー等の
アプリケーション・プログラム２０は、メモリ６にロー
ドされたり、あるいはメディア５に常駐したりする。メ
ディア５はデイスケソｈまたはハート・ファイルを含む
が、これに限定されるものではない。リレーショナル・
データベース・マネジャー２０は、オペレーティング。

・システム１５の拡張と考えてもよい。リレーショナル
・デ・−タベース・マネジャー２０は、リレーショナル
・データベース・マネジャー・タスクの包括的なセット
であり、マイクロプロセッサ１にインストラクションを
与えて、第１Ａ図及び第１Ｂ図に示される処理システム
をしてリレーショナル・データベース機能を営ませる。

メモリ６にロードされたアプリケーション・プロゲラ１
１］８は、メモリ６に先にロードされたオペレーティン
グ・システムと協同する。

第］−Ａ図及び第１−　Ｂ図の処理システムにおいて、
オペレータは、キーボード３のオペレータ・コンｌ−ロ
ール・キーを介して、レリーショナル・データベース・
マネジャー２０にアクセスする。バス２を介してデイス
プレィ４、メディア・ス１−レージ５、及びメモリ６に
接続されたプロセッサ］は、キーボードによってドライ
ブされる。ユーザが、キーボード３を介して、リレーシ
ョナル・ケージベース・マネジャー２０とインターラク
トするアプリケーション・プログラムとインターラフ１
〜するとき、リレーショナル・データベース・マネジャ
ー２０とそのケージはデイスプレィ４を通じてユザーに
表示される。データベース・マネジャー２０とインター
ラフ１〜するユーザーに加えて、アプリケーション】８
も、アプリケージ９ン１８中のＳＱＬコマンドを介して
データベース・マネジャー２０とインターラフＩ−する
ことができる。

上述のリレーショナル・データベース・システムでは、
１バイト・キャラクタ・データを処理するよりも、混合
キャラクタ・データを処理する方が、高価である。なぜ
なら、混合データの場合は、１バイト・データの後に必
ずキャラクタ境界が来るとは限らないからである。例え
ば、キャラクタ・データを移動させることを伴うオペレ
ーションについて考えてみると、１バイ１−・データの
方が速やかに実行できる。なぜなら、あるアドレスから
別のアドレスへ、何バイトかのデータ（キャラクタ）を
単純に移せばよいからである。しかるに、混合キャラク
タの場合は、バイ１−境界をまたぐことがあるので、あ
るアドレスから別のアドレスへデータを移すアルゴリズ
ムは、キャラクタの境界を決めるアルゴリズム、及び、
キャラクタ・データのインテグリテイを維持するアルゴ
リズムを伴わねばならない。

混合キャラクタ・データによって例えば日本語をサポー
１−するり１ノーシヨナル・データベース・システムに
おいて、本発明のシステム及び方法によれば、ユーザー
が、カラム毎にキャラクタ・夕イブのサブタイプを、１
バイ１〜・データまたは混合データのどちらかに指定で
きるようになる。ユーザーは、テーブル作成文またはテ
ーブル改造文によってカラムが作られつつあるときに、
カラムのキャラクタ・タイプのサブタイプを指定するこ
とができる。

第５Ａ図及び第５Ｂ図には、テーブル作成文３２とテー
ブル改造文３４が示されている。これらは、指定された
カラム名３３．３５のキャラクタ・データ・タイプのサ
ブタイプ３７．３９を生成するために、ユーザーが用い
る。カラム名］、　（ｃｏｌｕｍｎ−ｎａｍｅ　’Ｌ　
）３３、３５についてのサブタイプＦＯＲ５ＢＣ８ＤＡ
ＴＡ３７は、カラム名１につき１バイト・キャラクタ・
セット・データを指定する。カラム名２（３３，３５）
についてのサブタイプＦＯＲＭ丁ＸＥＤ　　ＤＡＴＡ３
９は、カラム名２につき、〕−バイトど２バイトの混合
したキャラクタ・セット・データ髪指定する。

これらのＳＱＬ文３２．３４及びその中で指定されたザ
ブタイプは、本発明のシステム内で以下のようして処理
される。リレーショナル・データベース・マネジャー２
０のカーネル４２についての説明は第６図で、リレーシ
ョナル・データ・サービスＲＤＳ２５の構造についての
説明は第８図で、また流れ図は第７図で、それぞれ行う
。

プレコンパイラ４３は、ソース・プログラム１８から埋
込ＳＱＬ文を抽出してリレーショナル・データベース・
マネジャー２０の基本システム・ユーティリティー（Ｂ
ＳＵ）４］に渡す（ステップ７１．第７図）。ＢＳＵ４
１は、Ｓ　Ｑ　Ｌ文をＲＤＳ２５に渡す（ステップ７２
）。ＲＤＳ２５は、Ｓ　Ｑ　Ｌ文をコンパイルするＳ　
Ｑ　Ｌコンパイラ２４へのインターフェースである（ス
テップ７３）。Ｓ　Ｑ　Ｌコンパイラ２４は、解釈可能
コードを生成する（ステップ７４）。解釈可能ローＩ−
はＲ，ＤＳ２５のランタイム・インタープリタ−５２に
よって実行される（ステップ７５）。このロー１−はＲ
ＤＳ２５のカタログ・サービス・ルーチン５４を呼び、
データベース・カタログ２３を更新する（ステップ７６
）。

」二記ステップは、リレーショナル・データベース・マ
ネジャー２０のカーネル４２の構成要素と機能（第６図
）及びＲ，Ｄ　Ｓ　２５の構成要素と機能（第６図、第
８図）について説明した後、疑似コードとフローチャー
１へを参照しながら詳述する。

ＲＤＳ２５は、Ｓ　Ｑ　Ｌテープル作成文及びテーブル
を改造文から由来するテーブルの生成と操作を準備する
。ＲＤＳ２５は、データベース・カタログ２３の管理も
行う。データベース・カタログ自体はリレーショナル・
データベース内のテーブルであり、リレーショナル・デ
ータベースが常駐しているファイル・システムの中、例
えば第］Ａ図のメディア５の上に、常駐する。

データベース・カタログ２３は、２次的なデータベース
・オブジェク１〜であり、データベース・マネジャーに
よってセットアツプされ、かつ維持される。カタログ・
テーブルはすへてデータベース・生成時に生成され、レ
リーシミナル・データベース・テーブルとしてインブリ
メン１〜される。カタログ・テーブルは、カーネルによ
って独占的に使用され維持されるものを除き、ユーザー
作成チープルと異ならない。もっとも、ユーザーがカタ
ログ・テーブルに間合せすることは許される。いくつか
のカタログ・テーブルはシステムによって維持され、ユ
ーザー・テーブルに関する情報及びプログラムを持つ。

第６図のリレーショナル・データ・サービス（ＲＤＳ）
２５は、プレコンパイラ４３とアプリケーション１８に
とって、データベース・マネジャー２０のカーネル４２
へのインターフェースである。プレコンパイラは、ＳＱ
Ｌコンパイラ２４を呼び出して、ＳＱＬ文をコンパイル
する。アプリケーションは、コンパイルされた形のＳＱ
Ｌ文を実行（解釈）する。

リレーショナル・データベース・マネジャーのカーネル
４２は、リレーショナル・データ・サービス（ＲＤＳ）
２５．ＳＱＬコンパイラ２４、ソー１へ・リス１〜・サ
ービス（ＳＬＳ）４４．データ・マネーシメンＩ〜・サ
ービス（ＤＭＳ）４５．インデックス・マネジャー（Ｉ
ＤＸ）４６．データサービス（ＤＳＶ）４７．データ・
プロテクション・サービス（ＤＩ）Ｓ）４８．バッファ
、プール・サービス（ＢＰＳ）４９、及びオペレーティ
ング・システム・サービス（Ｏ８Ｓ）５０を含む。

Ｓ　Ｑ　Ｌコンパイラ２４は、Ｓ　Ｑ　Ｌ文をコンパイ
ルする。ＳＱＬコンパイラは、本発明のシステム及び方
法において、３つの大きな機能を持つ。ＳＱＬコンパラ
イは、解析、セマンティクス、及びコード生成機能を提
供する。パーサは、レキシカル・チェツキングとシンタ
ックス・チェツキングを行い、解析木を築く。セマンテ
ィック機能は、カタログ・ルックアップと文のセマンテ
ィック゛チェツキングを含む。コード生成段階では、ア
クセス・セクションの残りとともに、スレッド化コード
（ｔｈｒｅａｄａ＋ｒＪ−ｃｏｄｅ）が生成される。

５ＬＳ４４は、ソーティング及び−時的なりレーション
（・リスｌ−）管理機能を提供する。ＤＭＳ４５は、デ
ータベースの物理的モデルを提供し、かつ物理的テーブ
ル操作を提供する。ＩＤＸ４６は、物理的なインデック
ス操作を提供する。ＤＳＶ４７は、データ値比較、デー
タ変換、及び算術を行う。

ＤＰ３４８は、トランザクション管理、コンカレンシー
・コン１−ロール、及びリカバリーを提供する。

ＢＰＳ４９は、バッファ及びファイル管理と１７０機能
とを提供する。○５Ｓ５０は、メモリ・アレンジメンＩ
・機能を提供する。

ＲＤ　Ｓ　２５の要素が第８図に示される。アプリケー
ション・インタフェース５１は、プレコンパイラ４３、
アプリケーション１８、及びユーティリティーからのリ
クエストを処理しかつ経路指定する。インタープリタ−
５２は、スレッド化コードをＳ　Ｑ　Ｌ文のオブジェク
１〜・コードとして使って、該ＳＱＬ文をコンパイルさ
れた形で実行（解釈）する。

インタープリタ−５２は、スレッド化コード中のオペレ
ータ、例えばデータベース・オペレータ（テーブル・ア
クセス、マージ、ジョイン等）や式オペレータ（加算、
比較等）の各々について、適切なルーチンを呼び出す。

アクセス・プラン・マネジャー５３は、カタログ内およ
びメモリ内のアクセス・プランを管理し、かつカタログ
内およびメモリ内のアクセス・セクションを管理する。

カタログ・サービス５４は、カタログ操作のための、Ｄ
ＭＳ４５に対するインターフェースである。ラン・スタ
ティックス５５は、テーブルとインデックスに関する統
計資料を集めるＤＭＳ４５へのインターフェースである
。

テーブル作成文３２またはテーブル改造文３４が、キャ
ラクタ・カラム３３．３５上にＦＯＲＭＩＸＥＤ　　Ｄ
ＡＴＡパラメータ３９またはＦＯＲ５ＢＣ８ＤＡＴＡ３
７を持つならば、第１表及び第２表に示すように、デー
タベース伽カタログ２３が以下のような変更を受ける。

第１表のＳ　Ｙ　Ｓ　Ｔ　Ａ、　Ｂ　ＬＥＳと第２表の
ＳＹＳＣＯＬＵＭＮは、データベース・カタログ・テー
ブル２３の２つのテーブルである。Ｓ　Ｙ　Ｓ　Ｔ　Ａ
　Ｂ　ＬＥ　Ｓでは、新しいテーブルまたはビュー（ν
ｊｅｗ）が生成される度に、１つの行が挿入される。自
分自身を含めて、カタログ・テーブルは、すへてこのテ
ーブルにエン１へり一を持つ。ＳＹＳＣＯＬＵＭＮＳで
は、テーブルまたはビューのカラムが定義される度に、
１つの行が挿入される。すべてのカタログ・テーブルは
このテーブルにもエントリーを持つ。

第１表のＳ　Ｙ　Ｓ　Ｔ　Ａ、　Ｂ　Ｌ　Ｅ　Ｓを参照
すると、ＰＡＣＫＥＤ　　ＤＥＳＣ（パック記述）のカ
ラムでは、ＦＯＲＭＩＸＥＤ　　ＤＡＴＡとして指定さ
れたカラムについて、内部データ・タイプＣＨＡＲＭＩ
ＸＥＤ、ＶＡＲＣＨＡＲＭＩＸＥＤ、またはＬ　ＯＮ　
Ｇ　　Ｖ　Ａ　Ｒ，ＣＨＡ　ＲＭ　Ｉ　Ｘ　Ｅ　Ｄが符
号化される。この内部データ・タイプは、データベース
・マネジャーによって、混合データ処理をキャラクタ・
カラムに適用すべきか否かを決定するのに用いられる。

ＦＯＲＭＩＸＥＤ　　ＤＡＴＡもＦＯＲ５ＢＣ８ＤＡＴ
Ａも指定されず、かつＦＯＲＢＩＴ　　ＤＡＴＡも指定
されないなら、２バイｌ−・バージョンのプロダクトで
はＭＩＸＥＤ　　ＤＡＴＡが想定される。ＦＯＲＢＩＴ
Ｄ　Ａ、　Ｔ　Ａは、本実施例において、２進データを
保持するのに用いられる。キャラクタ・カラム内にあっ
てキャラクタ・データとして処理すべきでない２進デー
タは、ＦＯＲＢＩＴ　　ＤＡＴＡとして指定される。し
かしながら１本発明の他の実施例ではこの付加的なりラ
ス分けは必要でない。

第２表のＳＹＳＣＯＬＵＭＮＳを参照すると、カラムＣ
０ＬＴＹＰＥ（カラムのデータ・タイプ）では、現実の
ＳＱＬデータ・タイプＣＨＡＲ，ＶＡＲＣＨＡＲ，ＬＯ
ＮＧ　　ＶＡＲＣＨＡＲが符号化される。第２表ないし
第４表のカラムＣ０ＤＥＰＡＧＥ及びＤＢＣ８ＣＯＤＥ
ＰＧでは、以下のような情報が符号化される。

データベース・システム・カタログ２３のＳＹＳＣＯＬ
ＵＭＮＳテーブル２８のカラムＣＯＴ−Ｔ　Ｙ　ＰＥに
ついて問合せがあると、次のようなことが起こる。ＳＹ
ＳＣＯＬＵＭＮＳテーブル２８のＣ０ＬＴＹＰＥカラム
がＣＨＡＲ，ＶＡＲＣＨＡＲ，Ｌ○Ｎ　Ｇ　　Ｖ　Ａ　
ＲＣＩ−（Ａ　Ｒ等のキャラクタ・データ・タイプを表
示しているなら、コード・ページ・カラムＣ０ＤＥＰＡ
ＧＥ及び２バイ１へ・キャラクタ・セラ１−・コード・
ページ・カラムＤＢＣ８ＣＯＤＥＰＧに問合せをして、
キャラクタ・タイプのサブタイプを決定することができ
る。

本発明のエンコーディング・スキームによれば、第４表
に示される如く、高度でかつ効率よくサブタイプが決定
される。Ｃ０ＤＥＰＡＧＥとＤＢＣ８ＣＯＤＥＰＧのカ
ラムがそれぞれゼロ値を持つ場合、サブセラ１〜はＦＯ
ＲＢＩＴ　　ＤＡＴＡを指定し、データをキャラクタ・
データとして処理しない。Ｃ０ＤＥＰＡＧＥカラムがノ
ン・ゼロ値を持ち、かつＤ　Ｂ　ＣＳ　ＣＯＤ　Ｅ　Ｉ
？　Ｇカラムがゼロ値を持つ場合、カラムは、１−ハイ
ド・オンリーのデータについて指定されたことになる。

Ｃ０ＤＥＩ）　Ａ　Ｇ　ＥとＤＢＣ８ＣＯＤＥＰＧのカ
ラムがそれぞれノン・ゼロ値を持つ場合、カラムは混合
データとなるが、これはカラムのサブタイプが特に指定
されなかった場合のデフォルト値である。さらに、ＣＯ
Ｄ　Ｅ　Ｐ　Ａ　Ｇ　Ｅ　力”）　ムまたはＤＢＣ８Ｃ
ＯＤＥＰＧカラムがノン・セロ値なら、そのノン・ゼロ
値に従って、該データベースの当該カラムに用いられる
特定のロー１〜・ページが指定される。

ＦＯＲＢＩＴ　　ＤＡＴＡの場合は、当該データをキャ
ラクタ・データとして処理すべきではないので、コート
・ページの指定は行われない。

本発明の」二連のシステム及び方法を、以下の疑似コー
ドによって説明する。疑似コードの説明は、後で第９図
ないし第１３図を参照して行う。

略語： ＣＤ−（パック記述による）カラム記述Ｄ　Ｄ　Ｌ−デ
ータ定義言語 ＤＭＳ−データ・マネーシメン１〜・サービスＩ）　テ
ーブル作成文とテーブル改造文には、ＭＩＸＥＤ及び５
ＢＣＳキヤラクタ・サブタイプのためのサポーＩ・を付
加する。

■）　カラムにＣ０ＤＥＰＡＧＥアトリビュート用のサ
ポー１〜を付加する。

注意：　ステップＡ）とステップＢ）はオフ・ラインで
一度に実行され、新たなＳＱ Ｌパーサを生成する。

Ａ）　　ＳＱＬパーサ文法テーブルを修正して、以下の
プロダクションを追加する。

Ｃｏ１．ｕｍｎＴｙｐｅ　　　＝　Ｃｈａｒａｃｔｅｒ
Ｔｙｐｅ　ＣｈａｒａｃｔｅｒＯｐｔｉｏｎＣｈａｒａ
ｃｔｅｒＯｐｔｊ、ｏｎ＝空ＦｏｒＭｉｘｅｄ　（ＦＯ
Ｒ０ＰＴＩＯＮノー１へを生成する） ＦｏｒＳＢＣ３（ＦＯＲ０ＰＴＩＯＮノード生成する。

ＦｏｒＭｉｘｅｄ　　　　＝　　ＦＯＲＭＩＸＥＤ　Ｄ
ＡＴＡ　ＭｊｘｅｄＯｐｔｊｏｎＦｏｒ　５ＢＣ３＝Ｆ
ＯＲ５ＢＣ３ＤＡＴＡ　ＳＢＣ５ＯｐｔｉｏｎＭｉｘｅ
ｄＯｐｔｉｏｎ　　＝空 （ＣｏｄｅＰａｇｅ、　ＣｏｄｅＰａｇｅ）ＳＢＣ３Ｏ
ｐｔｊｏｎ　　＝空 （ＣｏｄｅＰａｇｅ） ＣｏｄｅＰａｇｅ　　　　＝　　ＩｎｔｅｇｅｒＢ）新
たなパーサ・テーブルを生成する。

（オフ・ライン・パーサ・ジェネレータ及び新たな文法
テーブルを用いる。） Ｃ）ＳＱＬコンパイラを呼んで、テーブル作成文又はテ
ーブル変造文をコンパイルする。

（ＳＱＬコンパイラ・パーサ・フェーズ）注意：入力は
ＳＱＬ文。

出力は解析木。

／＊ＩＦ（テーブル作成文）＊／ ／＊　テーブル作成文用の解析木を生成する。＊／／＊
　　ＥＬＳＥ　（テーブル改造文）＊／／＊　テーブル
改造交圧の解析木を生成する。＊／／＊　　ＥＮＤＩＦ
＊／ ／＊　　ＩＦ（ＦＯＲＭＩＸＩＥＤ又はＦＯＲ５ＢＣ３
パラメータが存在する＊／ ／＊　解析木の中にＦＯＲ０ＰＴＩＯＮノー１−を生成
する＊／ ■アイ・ビー・エム・コーポレーション１９８８第９図
は、上記疑似ロー１くが実行される様子を示す。まず、
Ｓ　Ｑ　Ｌコンパイラが呼ばれて、ＳＱ■１文がコンパ
イルされる。ＳＱＬパーサ・フェーズでは、Ｓ　Ｑ　Ｌ
コンパイラが、テーブル作成文またはテーブル改造文の
ための解析木ノードを生成する（ステップ１０１）。Ｓ
ＱＬ文にてＦＯＲＭＩＸＥＤ、ＦＯＲ５ＢＣ８、または
ＦＯＲＢＩＴが表示されていたなら、ＦＯＲ０ＰＴＩＯ
Ｎ解析本が生成される（ステップ１０３．１０５）。Ｓ
ＱＬ文にてローｌ〜・ページ・パラメータが定義されて
いたなら（ステップ１０７）　、コード・ページ解析木
ノー１くが生成される（ステップ１０９）。

（ＳＱＬコンパイラ・コード生成フェース）注意二人力
は解析木。

出力は更新されたパック記述と解釈可 能ロー１く。

／＊ＩＦ（テーブル作成文）＊／ ／＊　　ＤＤＬテーブル作成命令コードを、スレッド化
コ−１’の形でストアする。＊／ ／＊　ＩＥＬＳＥ　（テーブル改造文）＊／／＊ＤＤＬ
テーブル改造命令コードを、スレッド化ローＩ−の形で
スＩ−アする。＊／ ／＊　ＥＮＤＩＦ＊／ ／＊解析木トラバース・ポインタを、解析本ルー１〜・
ノー１−を示すように初期化する。＊／ ■アイ・ビー・エム・ローポレーシ竺ン１９８８第１０
図及び上記疑似コードを参照して、Ｓ　Ｑ　Ｌコンパイ
ラのコード生成フェーズを説明する。そのすへてのノー
ドが第９図に示す如くして先行して生成されたところの
解析木が、コード生成フェーズの入力である（ステップ
■１１）。Ｓ　Ｑ　Ｌ文がテーブル生成文でテーブル改
造文でもないならば（ステップ１１３）　、ＳＱＬ文は
通常の如く処理される。Ｓ　Ｑ　Ｌ文がテーブル生成文
またはテーブル改造分の何れかであるならば、当該文に
対応する命令コードが生成される（ステップ１１７）。

コード生成フェーズの間、解析木のルー１〜・ノートが
ポイン１−される（ステップ１１９）。

／＊　　　　　解析木のトラバース＊／／＊ＤＯｗ＋＋
ｎ、ｐ　　　（エラーが検出されず、かつまだ解析木を
１〜ラバースする必要があるとき）＊／／＊　５ＷＩＴ
ＣＨ（解析木ノード・タイプ）＊／／＊ＣＡＳＥ　　ヘ
ッダ・カラム・リスト・ノー１〜・タイプ（ＣＤのスタ
ー１〜）＊／ ／＊　　ＣＤパック記述フィールドを初期設定するルー
チンを呼ぶ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　Ｃａ５ｅ　　カラム名識別子ノード・タイプ＊／
／＊　　ＣＤ構造体とカラム名についてストレージを割
り当てる。＊／ ／＊ＩＦ（スｉ〜レージの割当に成功）　ＴＩＩＥＮ＊
／／＊１′その他″カラム情報のセラ１〜・アップ＊／
／＊　　ＣＤコード・ページ＃］−をデータベース５Ｂ
ＣＳコード・ページに初期設定する。

／＊　　ＣＤコード・ページ＃２をデータベース５ＢＣ
Ｓコード・ページに初期設定する。／＊パック記述長さ
を更新する。木／ ／＊　ＥＮＤＩＦ＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ｃａｓｅ　　ＦＯＲ０ＰＴＩＯＮ　　ノート・タ
イプ＊／／＊　５ＩＩＩＴＣＨ（ＦＯＲ０ＰＴＩＯＮの
サブタイプ）＊／／＊　ｃａｓｅ　　ＦＯＲＢＩＴ　Ｄ
ＡＴＡノード・タイプ＊／／大５ｌｔｌＩＴＣ１ｌ　（
ＣＤのカラム・タイプ（先行ノー１への処理中にセラ１
〜される））＊／ ／＊　ｃａｓｅカラム・タイプ−ＣＨＡＲＭＩＸＥＤ＊
／／＊ＣＩＩＡＲカラム・タイプをＣＤタイプ・フィー
ルドにス１ヘアする。＊／ ／＊　ＤＩ）　ＣＡＳＥ＊／ ／＊　Ｃａ５ｅカラム・タイプ−ＶＡＲＣＩＩＡＲＭＩ
χＥＤ＊／ ／＊ＶＡＲＣＨＡＲカラム・タイプをＣＤタイプ・フィ
ールドにストア する。

／＊　ＥＮＤ　　ｃＡＳＥ＊／ ／＊　Ｃａ５ｅ　　カラム・タイプ＝　ＬＯＮＶＡＲＣ
ＩＩＡＩｔ　ＭＩＸＥＤ＊／ ／＊ＬＯＮＧ　　ＶＡＲＣＨＡＲカラム・タイプをＣＤ
タイプ・フィールドにストアする。

＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／ｌ　ＥＮＤＳＷＩＴＣＨカラム・タイプ＊／／＊　Ｃ
Ｄコローページ＃１と＃２をＯにセットする。＊／／＊
　ＥＮＤ　ＣＡＳＥ　ＦＯＲＢＩＴ＊／／＊　ｃａｓｅ
　１バイト・キャラクタ・セラ１−・ノード・タイプ＊
／ ／＊　５ＷＩＴＣ１＋　（ＣＤのカラム・タイプ（先行
ノードの処理中にセットされる））＊／ ／＊　ｃａｓｅカラム・タイプ：ＣＨＡＲＭＩＸＥＤ＊
／／＊　ＣＨＡＲカラム・タイプをＣＤタイプ・フィー
ルドにス１へアする。＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊ｃａｓｅカラム・タイプ０＝ＶＡＲＣＨＡＲＭＩＸ
ＥＤ＊／／＊　ＶＡＲＣＩＩＡＲカラム・タイプをＣＤ
タイプ、フィール１くにスーヘアする。＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ＣａＳｅカラム・タイプ−ＬＯＮＧ　ＶＡＲＣＨ
ＡＲＭＩＸＥＤ＊／／＊　ＬＯＮＧ　ＶＡＲＣＨＡＲカ
ラム・タイプをＣＤタイプ・フィール１−にスＩ〜アす
る。＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ＥＭＤＳＷ］１ＴＣＩＩカラム・タイプ＊／１＊
　ＩＦ　（コードページが指定されていた）　ＴＨＥＮ
＊／／＊コード・ページをセーブ・エリアから取得＊／
／＊コード・ページＣＤコードページ＃］フィールドに
ス１〜アする。＊／ ／＊　ＣＯコローページ１１２フィールドにはＯをスト
アする。＊／ ／＊　ＥＮＤＩＦ＊／ ／＊　ＥＮＤ　ＣＡＳＥ　５ＢＣ３＊／／＊　ｃａｓｅ
混合（ＭＩＸＥＤ）キャラクタ・ノード・タイプ ／＊ＩＦ　（コード・ページが指定されていた。

Ｔｌ＋ＥＮ　＊／ ／＊コロー・ページ２をセーブ・エリアから取得する。

＊／ ／＊コロー・ページをＣＤコード・ページ＃１フィール
ドにスＩ〜アする。＊／ ／＊コロー・ページ１をセーブ・エリアから取得する。

＊／ ／＊コロー・ページをＣＤコローく・ページ＃１フィー
ル１くにストアする。＊／ ／＊　ＥＮＤＩＦ＊／ ／＊　ＥＮＤ　ＣＡＳＥ　ＭＩＸＥＤ＊／／＊　ＥＮＤ
聞工ＴＣＩＩ　ＦＯＲのサブタイプ＊／／＊　ＥＮＤ　
ＣＡＳＥ　ＦＯＲ０ＰＴＩＯＮ＊／／＊　ｃａｓｅコー
ドベージ・ノード・タイプ＊／／＊コードページ識別子
をセーブする。水／／＊　ＩＥＮＤ　ＣＡＳＥ＊／ ／＊　ｃａｓｅカラムのデータ・タイプ・ノード（Ｃｈ
ａｒ、ｖａｒｃｈａｒ、。

、）＊／″ ／＊　５ＷＩＴＣＩ＋（データ・タイプ）＊／／＊　ｃ
ａｓｅデータ・タイプ＝　ＣＨＡＲ＊／／＊　ＣＨＡＲ
阿ＩＸＥＤカラム・タイプをＣＤタイプ・フィールドに
ストアする。＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ｃａｓｅデータ・タイプ−ＶＡＲＣＨＡＲ＊／／
＊ＩＦ　（長さが指定されていた、つまり、これはＶＡ
ＲＣＨＡＲ）　ＴＩＩＥＮ＊／ ／＊　ＶＡＲＣ１＋ＡＲＭＩＸＥＤカラム・タイプをＣ
Ｄタイプにス１へアする。＊／ ／＊　ＥＬＳＥ＊／ ／＊　ＬＯＮＧ　ＶＡＲＣＨＡＲＭ工ＸＥＤカラム・タ
イプをＣＤタイプにス１へアする。＊／ ／＊　ＥＮＩ）ＩＦ＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ＥＭＤ聞ＩＴＣＨデータ・タイプ＊／／＊　Ｃａ
５ｅ　ＣＤノー１〜・タイプ（カラム定義の終了）＊／
／＊ノー・アクション＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ＥＮＤＳＩＩ工ＴＣＨ解析本ノー解析・タイプ＊
／／＊解枦木のポインタを次のノー１へにインクリメン
１〜する。

＊／ ／＊　ＥＮＤＷＨＩＬＩＥ＊／ ■アイ・ビー・エム・コーポレーション１９８８第ｔ　
］、　Ａ図ないし第１１Ｅ図、及び」二掲の疑似コード
を参照して、ノー１くのタイプに応じて起こるステップ
を説明する。ノードがヘッダ・カラムであるならば（ス
テップ１２］、）、パック記述カラムが初期設定される
（ステップ１２３）。ノードがカラム・ノードであるな
らば（ステップ１２５）　、パック記述中のカラム記述
のためにストレージ（記憶域）が割り当てられる（ステ
ップＪ２７）。その後、カラム情報がセラＩ・・アップ
され（ステップ１２９）１バイト・コード・ページと２
バイト・コート・ページが、データベースのコード・ペ
ージに初期設定される（ステップ１３］、　＋３３）。

続いてパック記述長さが更新される（ステップ１３５）
。　ノードがオプションについてのもの、例えばＦＯＲ
ＢＩＴ、ＦＯＲ５ＢＣ８，Ｉ？○ＲＭＩＸ、ＥＤなら（
ステップ１３７）　、各ケースに応して次のようなこと
が行われる。

ノードがＦＯＲＢＩＴノードまたはＦＯＲ５ＢＣＳノー
トであり（ステップ１３９．１４１．）　、かつカラム
・タイプがＣＨＡ　ＲＭ　Ｉ　Ｘ　Ｅ　Ｉ）なら（ステ
ップ１４３．第１１Ｂ図）、ＣＨＡＲがカラム記述のカ
ラム・タイプ・フィールドにス１−アされる（ステップ
１４５）。カラム・タイプがＶ　Ａ、　ＲＣＨＡＲＭＩ
ＸＥＤであるなら（ステップ１４７）、ＶＡＲＣＨＡＲ
がカラム記述タイプ・フィール１（にス１−アされる（
ステップ１４９）。カラム・タイプがＬ　ＯＮ　Ｇ　　
Ｖ　Ａ　ＲＣＨＡ　ＲＭ　Ｉ　Ｘ　Ｅ　Ｄであるなら（
ステップ］５１）、ＬＯＮＧ　　ＶＡＲＣＨＡＲがカラ
ム記述カラム・タイプ・フィールドにストアされる（ス
テップ１５３）。

第１１Ａ図に戻ると、ＦＯＲＢＩＴオプションの場合（
ステップ］３９）　、　］−バイト・コード・ページと
２バイト・コード・ページ用の両方について、コード・
ページがゼロにセラ１〜される（ステップ１５５．第］
、ＩＣ図）。ＦＯＲ５ＢＣＳオプシヨンの場合（ステッ
プ１４１．第１１Ａ図）、コード・ページ・フィール１
−が指定されているなら（ステップ１５７．第１．ＩＣ
図）、当該コード・ページが検索され、カラム記述内の
第１コード・ページとして、つまり１バイ１−・キャラ
クタ・セット・ロー１−・ページとしてス１−アされる
（ステップ１５９．１６１）。２バイ１〜・ロー１へ・
ページはゼロにセラ１−される。　第１１Ａ図と第１１
．Ｄ図を参照するに、ＦＯＲＭＩＸＥＤオプションが指
定され（第１１Ａ図のステップ１．６３）　、かつコー
ド・ページがさらに指定されているなら（第１ＩＤ図の
ステップ１６５）、が第２コー１−・ページが検索され
、カラム記述内のロー）ミ・ページ＃２の下にス１〜ア
される（ステップ１．６７、１．６９）。続いて、第１
コード・ページが検索され、カラム記述内にコード・ペ
ージ＃１の下にストアされる（ステップ］、７］、　１
７３）。

第］、］Ａ図と第１．１．　Ｅ図を参照するに、ポイン
１〜されているノー１へがデータ・タイプ・ノー１へで
あるなら（第］、ＩＡ図のステップ１７５）　、第］Ｉ
Ｆ図に示すようなステップが実行される。データ・タイ
プがＣＨＡ　Ｒならば、ＣＨＡＲＭＩＸＥＤがカラム記
述のカラム・タイプ・フィール１〜にスＩ・アされる（
ステップ１７７、１７９）。データ・タイプが■Ａ　Ｒ
ＣＨＡ　Ｒであり、長さが指定済であるなら（ステップ
１８１．１８３）　、ＶＡＲＣＨＡＲＭＩＸＥＤがカラ
ム記述のカラム・タイプ・フィールドにストアされる（
ステップ１８５）。長さが指定されていないなら、ＬＯ
ＮＧ　　ＶＡＲＣＨＡＲＭＩＸＥＤがカラム記述のカラ
ム・タイプにストアされる（ステップ１８７）。

上述のステップは、すべてのノードが処理されてしまう
まで繰り返される。

Ｓ　Ｑ　Ｌコンパイラが上記ステップを実行した後、リ
レーシ１ナル・データ・サービス（ＲＤＳ）はインター
プリタ−を読んで、スレッド化コード及び生成されたパ
ック記述を実行する。文がテーブル作成ならば、出力は
、データベース内で生成される新たなテーブルであり、
５ＹＳＴＡＢＬＥＳカタログ・テーブル内の該新規作成
テーブルの行であり、そして、該新規テーブルのカラム
毎にできるＳＹＳＣＯＬＵＭＮＳカタログ・テーブルの
行である。テーブル改造文の場合の出力は、新たに追加
されたカラムに対応するＳＹＳＣＯＬＵＭＮＳカタログ
・テーブルの行と、Ｓ　Ｙ　Ｓ　ＴＡ　Ｂ　ＬＥＳカタ
ログ・テーブル中の改造テーブルについての更新された
行である。以下の擬似ロー１くが、スレッド化コード及
びパック記述の、インタープリタ−による実行ステップ
を示している。

Ｃ）ラン・タイム・インタープリタ−を呼んで、テーブ
ル作成文を実行する。

注意二人力は、ＳＱＬコンパイラによって生成されたパ
ック記述及びスレッド 化コード。

出力は、データベース中の新規作成テーブル、作成テー
ブルに対応する５ＹＳＴＡＢＬＥＳカタログ・テーブル
内の行、及び新規テーブルの各カラムに対応するＳＹＳ
ＣＯＬＵＭＮＳカタログ・テーブル内の行である。

／＊パンク記述から、ＤＭＳテーブル記述構造体をセッ
ト・アップする。

／＊　ＳＭＳを呼んでテーブルを作る。

／＊　５ＹＳＴＡＢｔ、ＥＳに対して、（パック記述カ
ラムを含む）行を、新規テーブルのために追加する。＊
／ ／＊第１カラム記述へのポインタを得る。＊／／＊テー
ブルについてのパック記述のカラム毎に＊／／＊　ＳＹ
ＣＯＩＪＩＭＮＳ　Ｃ０ＤＥＰＡＧＥフイールドをコー
ドページ＃１でセットアツプする＊／ ／＊　ＳＹＣＯＬＵＭＮＳ　ＤＢＣ５ＣＯＤＥＰＧフィ
ールドをコードページ＃２でセットアツプする。＊／ ／＊　５ＹＳＣＯＬ聞ＮＳ　Ｃ０ＬＴＹＰＥフイールド
をサブタイプではなくキャラクタ・タイプでセットアツ
プする＊／／＊　５ＷＩＴＣｔｌ（パック記述ＣＤ中の
カムラ・タイプ）＊／／＊　ｃａＳｅカラム・タイプ＝
ＣＩＩＡＲＭＩＸＥＤ＊／／＊　ＳＹＳＣＯＬＵＭＮＳ
のカラム・タイプ・フィールドに“Ｃ）ＪＡＲ”をス１
−アする。＊／／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　Ｃａ５ｅカラム・タイプ＝ＶＡＲＣＩＩＡＲＭＩ
ＸＥＤ＊／／＊　ＳＹＳＣＯＬＵＭＮＳのカラム・タイ
プ・フィールドにＡＲＣＩＩＡＲ’″をストアする。＊
／／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ｃａｓｅカラム・タイプ−ＬＯＮＧ　ＶＡＲＣＨ
ＡＲＭＩＸＥＤ＊／／＊　ＳＹＳＣＯＬＵＭＮＳのカラ
ム・タイプ・フィールドニ”ＬＯＮＧＶＡＲ”をス１−
アする。＊／／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ＥＮＤＳｌｔｌＴＴＨＣＩＩ＊／／＊行をＳＹＳ
ＣＯＬＵＭＮＳに挿入する。＊／／＊　ＥＮＤＦＯＲ＊
／ Ｂ）ラン・タイム・インタープリタ−を呼んで、テーブ
ル改造文を実行する。

注意二人力は、ＳＱＬコンパイラによって生成されたパ
ック記述及びスレッド 化コード。

出力は、データベース中のテーブル に追加された新規カラム記述、５Ｙ ＳＴＡＢＬＥＳカタログ・テーブル 中の改造テーブルに対応して更新さ れた行、及びＳＹＳＣＯＬＵＭＮＳ カタログ・テーブル中の新規カラム 毎に設けられた行である。

／＊パック記述から、ＤＮＳテーブル記述構造体をセッ
ト・アップする。＊／ ／＊　ＤＮＳを呼んで、データベース中のテーブル記述
を改める。＊／ ／＊　５ＹＳＴＡＢＬＥＳにおいて、改造テーブルに対
応するパック記述を更新する。＊／ ／＊第１カラム記述へのポインタを得る。＊／／＊テー
ブルについてのパック記述のカラム毎に＊／／＊　５Ｙ
ＣＯＬＵ阿ＮＳ　Ｃ０ＤＥＰＡＧＥフイール１くをロー
１（ページ＃１でセットアツプスル＊／ ／＊　ＳＹＣＯＬＵＭＮＳ　ＤＢＣ３ＣＯＤＥＰＧフィ
ールドをコートページ＃２でセットアツプする＊／ ／＊　ＳＹＳＣＯＬＵＭＮＳ　Ｃ０ＬＴＹＰＥフイール
ドをサブタイプではなくキャラクタ・タイプでセット・
アップする。＊／／＊　５ＩＩＩＴＣＨパツク記述ＣＤ
中のカラム・タイプ＊／／＊　Ｃａ５ｅカラム・タイプ
＝ＣＩ＋ＡＲＭＩＸＥＤ＊／／＊ＳＹＳＣＯＬＵＭＮＳ
のカラム・タイプ・フィールドに“ＣＨＡＲ”をストア
する。＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　Ｃａ５ｅカラム・タイプ＝ＶＡＲＣＨＡＲＭＩＸ
ＥＤ　＊／／＊　Ｓ’／ＳＣＯＬＵＭＮＳのカラム・タ
イプ・フィールドに”ＶＡＲＣＨＡＲ”をス１〜アする
。＊／／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　Ｃａ５ｅカラム・タイプ＝ＬＯＮＧ　ＶＡＲＣｌ
ｌＡＲＭＩＸＥＤ＊／／＊ＳＹＳＣＯＬＵＭＮＳのカラ
ム・タイプ・フィールドに”ＬＯＮＧＶＡＲ”をストア
する＊／ ／＊　ＥＮＤ　ＣＡＳＥ＊／ ／＊　ＥＮＤＳＷＩＴＣＨ＊／ ／＊　ＥＮＤＳＩＩＩＴＨＣＨ＊／ ／＊行をＳＹＳＣＯＬｔｌＭＮＳに挿入する＊／／＊　
ＥＮＤＦＯＲ＊／ ■アイ・ビー・エム・コーポレーション１９８８第１２
図は、上記擬似コードを説明するためのものである。パ
ック記述（ＰＤ）から、ＤＭＣテーブル記述がセット・
アップされる（ステップ２０１）。

ＤＮＳは、実際に、新規な物理テーブルまたはカラムを
生成する（ステップ２０３）。カタログ・サービスは、
行をＳ　Ｙ　Ｓ　Ｔ　Ａ　Ｂ　Ｌ　Ｅ　Ｓに付加する（
ステップ２０５）。新規に作成されたテーブルのカラム
毎に、または新規に追加されたカラム毎に、ＳＹＳＣＯ
ＬＵＭＮＳの行は増えていく。ｓｙｓＣＯＬＵＭＮＳの
Ｃ０ＤＥＰＡＧＥカラムは、カラム記述に由来するコー
ドページ１でもってセソ１へされる（ステップ２０９）
。ＳＹＳＣＯＬＵＭＳのＤ　Ｅ　ＣＳ　ＣＯＤ　Ｅ　Ｉ
）　Ａ　Ｇ　Ｅカラムは、カラム記述に由来するコード
ページ２でもってセットされる（ステップ２１１）。

カラム記述のカラム・タイプがＣＩ−Ｉ　Ａ　ＲＭ　Ｉ
ＸＥＤなら、ＳＹＳＣＯＬＵＭＮ　　Ｃ０ＬＴＹＰＥは
ＣＨＡ　Ｒにセラ１−される（ステップ２１３．２１４
）。

カラム記述のカラム・タイプがＶ　Ａ　ＲＣＨＡ　ＲＭ
ＩＸＥＤなら、ＳＹＳＣＯＬＵＭ、ＮのＣ０ＬＴＹＰＥ
はＶ　Ａ　ＲＣＨＡ　Ｒにセラ１−される（ステップ２
］、５．２１６）。カラム記述のカラム・タイプがＬＯ
ＮＧ　　ＶＡＲＣＨＡＲＭＩＸＥＤなら、ＳＹＳＣＯＬ
ＵＭＮ　　Ｃ０ＬＴＹＰＥはＬＯＮＧＶＡ　ＲＣＨＡ　
Ｒにセラ１〜される（ステップ２１７．２１．８）。

カラム記述のカラム・タイプがＣＩ（ＡＲＭＩＸＥＤ、
ＶＡＲＣＨＡＲＭＩＸＥＤ、またはＬ○Ｎ　Ｇ　　Ｖ　
Ａ　ＲＣＨＡ、　ＲＭ　Ｉ　Ｘ　Ｅ　Ｄ　（７）何れで
もないならば、Ｓ　Ｙ　Ｓ　ＣＯＬ　ｔＪ　Ｍ　ＮのＣ
ＯＩ、ＴＹＰＥはカラム記述のカラム・タイプにセラ１
〜される（ステップ２１９）。１つの行が５ｙｓｃ○Ｌ
　Ｕ　ＭＮＳに追加され（ステップ２２］）　、次のカ
ラム記述が検索される（ステップ２２３）。

以下の擬似コードは、５ＱＬＤＡ、（ＳＱＬ記述子エリ
ア）を指定されたコードページで更新する様子を説明す
る。ＳＱＩ、ＤＡの詳しい説明及び使用 法については、ＩＢＭ　Ｓｙｓｔｅｍｓ　Ａｐｐｌｊｃ
ａｔｊｏｎ　ＡｒｃｈｉｔｅｃｔｕｒｅＣｏｍｍｏｎ　
Ｐｒｏｇｒａｍｍｊ、ｎｇ　Ｉｎｔｅｒｆａｃｅ　Ｄａ
ｔａｂａｓｅＲｅｆｅｒｅｎｃｅ。

ＩＢＭ　　Ｃｏｒｐｏｒａｔｊ、ｏｎ、Ｄｏｃｕｍｅｎ
ｔ　　Ｎｕｍｂｅｒ　　５Ｃ２６−４３８−０，１９８
７を参照されたい。

Ｓ　Ｑ　Ｌ準備（ＰＲＥＲＡＲＥ）文または選択記述（
ＤＥＳＣＲＩＢＥ　　ｏｆ　　５ＬＥＣＴ）文の処理に
際して、Ｓ　Ｑ　Ｌ　Ｉ）　Ａをコードページ情報でも
って更新する。

／＊　ｗｈｉｌｅ選択リス１〜を処理する＊／／＊　ｊ
ｆ　リス１−項目がカラムである＊／／木コーローペー
ジ＃１（ＳＢＣＳコー１ローページ）をパック記述から
５ＱＬＤＡの５ＱＬＤＡＴＡフイールドにコピーする。

＊／ ／＊コローページ＃　２　（ＤＢＣＳコート・ページ）
をパックδ己述から５ＱＬＤＡの５ＱＬＩＮＤフィ−ル
ドにコピーする。＊／ ／＊　ｅｌ、ｓｅカラムではない＊／ ／＊コードロージ＃１（ＳＢＣＳコード・ページ）ヲデ
ータベース・コード・ページ・エリアからＳ　Ｑ　Ｌ　
Ｄ　Ａの５ＱＬＤＡＴＡフイールドにコピーする。

／＊コローページ＃２（ＤＢＣＳコード・ページ）をデ
ータベース・コード・ページ・エリアから５ＱＬＤＡの
Ｓ　Ｑ　Ｌ　Ｉ　Ｎ　Ｄフィールドにコピーする。

／＊　　ｅｎｄｊｆ木／ ／＊　ｃｎｄｗｈｉｌｅ＊／■アイ・ビー−エム・コー
ポレーション１９８８ 第１３図は、−」二掲の擬似コードを説明したものであ
る。ＳＱＬ文が準備でも選択記述でもないならば、５Ｑ
ＬＤＡは更新されない（ステップ２２５゜２２７）　、
　Ｓ　Ｑ　Ｌ文が準備または選択記述であるならば、選
択リストの第１項目が検索される（ステップ２２９）。

選択リスｌ−の項目がカラムであるならば（ステップ２
３］、）、５ＢＣＳコードページ（コードページ１）が
、パック記述からＳ　Ｑ　Ｌ　Ｉ）　ＡＴＡフィールド
にコピーされる（ステップ２３３）。

また、ＤＢＣＳコートページ（コードページ２）は、パ
ック記述からＳＱＬ　Ｉ　ＮＤラフイールドへピーされ
る（ステップ２３５）。選択リストの項目がカラムでな
いならば、５ＢＣＳコードページ（コードページ１）が
データベース・コード・ページ・エリアからＳ　Ｑ　Ｌ
　Ｄ　Ａ　Ｔ　Ａヘコピーされる（ステップ２３９）。

また、ＤＢＣＳコード・ページ（コードページ２）は、
データ・ベース・コード・ページ・エリアからＳ　Ｑ　
Ｌ　丁Ｎ　Ｉ）へコピーされる（ステップ２４１）。そ
の後、次の選択リスト項目が検索される（ステップ２３
７）。このようにして、選択リストの全項目について−
に記ステップが繰り返される。

以下では、本発明に従ってカラムのサブタイプが混合デ
ータまたは１バイト・キャラクタ・セラ１〜・データに
指定された状態の下で、データベース・テーブルからデ
ータを検索する動作を説明する。

データベース・テーブルからのデータの取出としアプリ
ケーション・プログラムへの該データのリターンは、選
択文及び取出（フェッチ）文を使って行われる。５ＱＬ
ＤＡ（ＳＱｒ、記述子エリア）またはホスＩ〜の変数リ
ストを使って、データベース・マネジャーは、データを
アプリケーション・プロフラノ、中のデータ・エリアへ
移す。キャラクタ・データ・タイプの場合、アプリケー
ション・プログラムでのターゲラ１〜・データ・エリア
の長さがリフニス１〜されたデータベース・データの長
さにより短いならば、データは切り捨てられ、５ＱＬＣ
Ａに警告フラグがセソ１〜される。このことは、上記デ
ータベースの参考文献に記載されている。キャラクタ・
データが混合データであるならば、切捨（ｔｒｕｎｃａ
ｔｊ、ｏｎ）によって２バイト・キャラクタが２分され
、その結果最終キャラクタが無効なものとなることのな
いように、切捨時に特殊な処理が必要になる。

第１．／１．Ａ図には、混合データ用の切捨アルゴリズ
ムが示されている。ＨＮＩＩは、ターゲラ１−・エリア
のバイ１〜長を表わしている（ステップ２４５）。

ＩＩ　Ｆ　Ｂ　ＩＩは、切り捨てられたデータの最終デ
ータのアドレスを表わしている（ステップ２４７）。Ｎ
バイ１−のデータが、データベース・データのスター１
へ・ア１くレスからターゲット・アドレスへ移される（
ステップ２４９）。ＦＢは、（ターゲット・エリアのス
ター１〜地点十Ｎ−１）になる（ステップ２５１）。Ｆ
Ｂの前の、最終キャラクタ境界が決定される（ステップ
２５３）。ＦＢが２バイ１−・キャラクタの１バイト目
であるならば、ＦＢは１パイ１〜分のスペースと置換さ
れる（ステップ２５５．２５７）。そうでなければ、何
のアクションも起こらない。

比較対照のため第１４Ｂ図に１パイ１〜・データ用の切
捨アルゴリズムを示す。ここでも、ＩＩ　Ｎ　ＩＩはタ
ーゲット・エリアのバイＩ・長である（ステップ２５９
）。次に、Ｎバイトのデータが、データベース・データ
のスタート・アドレスからターゲラ１〜・アドレスに移
される（ステップ２６１）。第１４Ａ図に示したように
、混合データ切捨アルゴリズムには、第１ｉＢ図の１バ
イト・オンリー・データ用アルゴリズムでは不要のステ
ップが含まれている。

第１４Ａ図のステップ２５３に示した最終キャラクタ境
界の決定は、データの長さと内容によっては極めてコス
トのかかるものになり得る。混合データを表示する内部
データ・タイプを付加することによって、切捨を行うラ
ンタイム・コードが、単純な１バイト・ルーチン（第１
．４Ｂ図）または高価な混合ルーチン（第４．４Ａ図）
の何れかを、選択的に呼び出ぜるようになる。

５ＵＢＳＴＲ５ＣＡＬＡＲＦＵＮＣＴＩ○Ｎもまた、混
合データよりも」バイト・データの場合により効率が良
い。スカラー関数は、Ｓ　Ｑ　Ｌ文の式の代りに使うこ
とができる。Ｓ　Ｕ　Ｂ　Ｓ　ＴＲは、キャラクタ・デ
ータ・フィールドのサブストリングを返すスカラー関数
である。５ＵＢＳＴＲを含むスカラー関数について、詳
細な’′■ＢＭ　Ｄａｔａｂａｓｅ　２ＳＱＬ　Ｒｅｆ
ｅｒｅｎｃｅ”　Ｄｏｃｕｍｅｎｔ　Ｎｕｍｂｅｒ　５
Ｃ２６−４３４６−３゜ＩＢＭ　Ｃｏｒｐｏｒａｔｊｏ
ｎを参照されたい。

５ＵＢＳＴＲ関数の第］パラメータは、サブストリング
の抽出対象となるデータベース・キャラクタ・ス１〜リ
ングを指定する。パラメータ２は。

サブストリグのスター１〜・バイ１へ位置である。

パラメータ３は、結果のバイ１へ長である。混合データ
については、上述の切捨アルゴリズムを使って、最終キ
ャラクタが確実に有効となるよう、サブストリグの最終
バイトの処理を行わなしづればならない。結果として得
られたスＩ・リングが２バイ１へ・キャラクタの第２バ
イ１−から始まることがないことを保証するべく、サブ
ストリングの第１キヤラクタも吟味しなければならない
。このチエツクのためのアルゴリズムが第１５図に示さ
れている。

混合データの場合のＳ　Ｕ　Ｂ　Ｓ　Ｔ　Ｒの第１キヤ
ラクタの検証（ＶａＨ，ｄａｔｉ、ｏｎ　）は次の通り
である。ｒｒＮ″″は、５ＵＢＳＴＲのパラメータ２で
ある（ステップ２６３）。Ｉｆ　Ｓ　Ｂ　ＩＩは、サブ
ストリグのスタート・バイトである（ステップ２６５）
。ＳＢは、（パラメータ１のデータベース・データの７
１−レス＋Ｎ−１）になる（ステップ２６７）。ＱＩＡ
ｂｌて、ＳＢの前の最終キャラクタ境界が決定される（
ステップ２６９）。ＳＢが２バイ１−・キャラクタの第
２バイトであるならば、サブストリングの第１バイトが
１バイトのスペースと置換される（ステップ２７１．２
７３）。そうでないならば、何のアクションもない。

パラメータ１がＭＩＸＥＤタイプ以外のデータを指示す
るなら、特殊な境界チエツク及びサブストリングの最初
と最後のキャラクタの処理を実行する（ステップ２６９
．２７１．２７３．２５３．２５５．２５７）ためのル
ーチンを呼ぶ必要はない。

アプリケーション・プログラムも、５ＢＣＳデータとＭ
　Ｉ　Ｘ、　Ｅ　Ｄデータが識別されることを利用する
ことができる。アプリケーション・プログラムにおいて
、キャラクタ・データが１バイト・オンリーか混合であ
るかに応じて、該キャラクタ・データに特殊な処理を施
す必要が生じ得る。例えば、あるプログラムにおいて、
特定のフィールドにストアされるレボ−１へを生成する
必要が生じ得る。順序立った値の２５６バイ″ｌ−・テ
ーブルに基づく単純な照合を用いては、混合データをス
トアすることはできない。２バイト・キャラクタのソー
１〜・アルゴリズムは複雑であり、関係する言語に応じ
て変化する。

したがって、データに対して高価なアルゴリズムを適用
しようとする前に、アプリケーション・プログラムがシ
ステム・カタログに問合せをして、テーブル内のカラム
がＭＩＸＥＤとして定義されているか否かを決定できる
ようにすることは、有用なことである。この結果、一般
的なユーザ・インタフェースまたはレボ−ｊ〜・ジェネ
レータのアプリケーションが、他のアプリケーションに
よって生成されたキャラクタ・データを精巧に処理する
ことが可能になる。なぜなら、作成アプリケーションと
は別個の独立に、キャラクタ・データのタイプに関する
情報がデータベース中にス１〜アされるからである。

アプリケーション・プログラムがシステム・カタログか
ら情報を取得する方法は、以下の通りである。

１）カタログ・テーブルからの選択。

２）＄備または５ＱＬＤＡへの記述。

「これらのＳＱＬ動作の詳細は、上記”ＩＢＭ　Ｄａｔ
ａｂａｓｅ２　ＳＱＬ　Ｒｅｆｅｒｅｎｃｅ”に記載さ
ている。ＦＯＲＭＩＸＥＤ　　ＤＡＴＡ及びＦＯＲ５Ｂ
Ｃ８ＤＡＴＡは、ＳＱＬデータ・タイプではなくてデー
タ・サブタイプであるので、アプリケーションは、ＳＹ
ＳＣＯＬＵＭＮＳのＣＯＬ　Ｔ　Ｙ　Ｐ　Ｅカラムや５
ＱＬＤＡのＳ　Ｑ　ＬＴ　Ｙ　Ｐ　Ｅフィールドを調べ
てサブタイプ情報を獲得することができない。その代り
、該情報をアプリケーションに返すために、以下の方法
が用いられる。キャラクタ・データ・タイプについて、
記述（またはＩＮＴＯ節を持つ準備）文にならって、第
５表に示すように、フィールドＳ　Ｑ　Ｌ　Ｄ　Ａ　Ｔ
　Ａと５ＱＬＩＮＤが符号化される。アプリケーション
は、第４表に示されるようなエンコーディング・スキー
ムのために、第２表のＳＹＳＣＯＬＵＭＳの中のＣ０Ｄ
ＥＰＡＧＥカラムとＤＢＣ８ＣＯＤＥＰＧカラムに問い
合わせることもできる。

同様に、アプリケーションは、特殊なコード・ページ支
配キャラクタ・データ・エンコーディングに対して敏感
であってもよい。例えば、アプリケーションは、データ
を検索したり、特にはデータを変更しようと試みる前に
、自分がデータのエンコーディング・スキームを理解で
きるか否かを決定したいと欲するかもしれない。かかる
ニーズをサポートするべく、本発明によれば、アプリケ
ーションは、データベースに問い合わせをして所与のキ
ャラクタ・フィールドのコード・ページを決定できるだ
けでなく、キャラクタ・フィールドのコード・ページ環
境を作成時に宣言することができる。さらに、本発明の
設計によれば、どのカラムのコード・ページ・アトリビ
ュート他のカラムのものとは独立に宣言することができ
るので、複数のコード・ページ環境を収容する先進的な
システム及びアプリケーションが十分にサポートされる
。

以下では、混合バイ１−・データを許容するリレーショ
ナル・データベース・システムにおいて、１バイト・キ
ャラクタ・セラ１〜・データを指定することの重要性を
説明する。説明のために、以下の取決に従って、」バイ
１−・キャラクタを２バイト・キャラクタと区別するこ
とにする。

１バイ１〜・キャラクタはロア・ケースのアルファベッ
トで表現する。例えば、ａＴ　ｂ、ｃ、　　の如し。

２バイト・キャラクタは、アッパー・ケースのアルファ
ベラ１〜２文字で表現する。例えば、ＡＡ。

ＢＢ、ＣＣ，の如し。

１例として−ＩＶ○ＲＹという名のカラムとＨＥＩＮＺ
という名のカラムをもつ、ＳＡＭＰＬＥという名前のテ
ーブルを考えてみよう。ここで、Ｉ　Ｖ　ＯＲＹは、１
バイトのキャラクタ・ストリング（数値）だけを持つ一
方、ＨＥＩＮＺでは、１バイＩ・・キャラクタ・ストリ
ングと２バイト・キャラクタ・ストリングが混合してい
る。かかるテーブルは、以下のＳ　Ｑ　Ｌ文を使って作
成できよう。

ＣＲＥＡＴＥ　　　ＴＡＢＴ、Ｅ　　　ＳＡＭＰＬＥ（
ＩＶＯＲＹ　　ＶＡＲＣＴ−ＴＡＲ（１０）　　　ＦＯ
Ｒ８ＢＣ８ＤＡＴＡ。

ＨＥＩＮＺ　　ＶＡＲＣＨＡＲ（１０）　　　ＦＯＲＭ
ＩＸＥＤ　　ＤＡＴＡ） 」二記取決を使うと、ＩＶＯＲＹとＨＥＩＮＺ（７）い
くつかの値が以下のように与えられる。

ＳＡＭＰＬＥ行　　　ＩＶＯＲＹ　　　　　ＨＥＩＮＺ
ｌ−ａｂｃ　　　　　　　　　　　ＡＡＢＢＣＣ２ｄｏ
ｇ　　　　　　　　　　ＤＤＯＯｇ’３　　　　　　　
ｑｗｅｒｔｙｕ　ｊ、ｏｐ　　　　　　ＺＺｘＣＣｖＢ
Ｂｎ４−　　　　　　　］、ａｓｔ　ｖａｌｕｅ　　　
　　　ｑＱＱｑＱＱ上記の表を用いて、１バイ１−・キ
ャラクタのみからなるデータ・ストリングの処理方法と
、１バイ１〜・キャラクタと２パイ１〜・キャラクタの
混成データ・ストリング中 る。

混成ストリングは、ストリングの開始地点からしか解析
できないという特性を持つ。つまり、ストリング中のす
べての先行バイトの性質が決まらなければ、どんなバイ
トも無意味である。説明のために、ユーザ／アプリケー
ションが、ＩＶＯＲＹとＩ−Ｉ　Ｅ　Ｉ　Ｎ　Ｚにある
各数値の最終バイＩ−だけをデリートすることを欲した
としよう。ＩＶＯＲＹカラムの数値に用いられる処理方
法は単純である。

ストリングの終端がスキャンされ、ストリングの最終バ
イとが破棄される。これと同じ処理方法をＨＥＩＮＺカ
ラムの数値に用いたならば、ストリングの最終キャラク
タが２パイ１〜・キャラクタであったときに、２バイト
・キャラクタの２バイト目を破棄してしまうことになる
。それゆえ、混合バイ１−・カラムについては、より複
雑な処理アルゴリズムが必要とされる。まず、ストリン
グの最終キャラクタの性質（１バイ１−か２バイトか）
を決定しなければならない。単に最終バイ１−の値をチ
エツクするだけでは足りない。なぜなら、１バイ１〜・
キャラクタと２バイト・キャラクタの２バイト目は、同
しコード・ポイント値を共有するからである。したがっ
て、ストリング中 クタが１バイト・キャラクタかそれとも２バイ１−・・
キャラクタかを決定するためには、複雑な解析−図 アルゴリズムを適用しなければならない。これは明らか
に時間がかかる冗長な作業であるけれども、不可欠であ
る。

ＳＡＭＰＬＥテーブルの数値について、この「最終バイ
１−」切捨操作を実行した結果を下に記す。

ＳＡＭＰＬＥ　行　　　　　　　ＩＶＯＲＹ　　　　　
　　　　　　ＩＩＥＩＮＺｌ、　　　　　　　　　ａ　
ｂ　ｃ　　　　　　　　　　　　　Ａ　Ａ　Ｂ　Ｂ２　
　　　　　　　　ｄｏ　　　　　　　　　　　　　　Ｄ
ＤＯＯ３ｑｗｅｒｔｙｕｉｏ　　　　　　　ＺＺｘＣＣ
ｖＢＢ４　　　　　　　　］、ａｓｔ　ｖａｌｕ　　　
　　　　ｑＱＱｑもし、あるカラムが１バイト・キャラ
クタ・ストリングだけを持つことが事前に推測されるな
らば、かかるカラムについて、１バイト・２バイト・キ
ャラクタ混成ストリングに作用する方法よりもはるかに
効率がよくて簡単な切捨アルゴリズムを使用できる。”
ＦＯＲ５ＢＣ８ＤＡＴＡ”オプションによって、ユーザ
は、かようなカラム・７１−リビュー１−を指定できる
ようになる。

純粋１バイト・キャラクタ・ストリングに比して混成ス
トリングの方が処理の複雑さが増すことの説明例として
、「プラス１〜リング」関数を考えてみよう。このスＩ
〜リング・オペレータによれば、キャラクタ・ストリン
グの一部分の選択が可能になるが、その際、第１−パイ
１〜位置（プラス１へリングの先頭バイトの位置）と長
さが指定される。

切捨の場合に遭遇したのと同様の、純粋１バイ１−・ス
トリングと混成ス［−リンクの間に生しる処理の差異が
、プラス１〜リング関数にもあてはまる。

純粋１バイト値のサブストリングを選択する場合には、
ストリングをｎハイド−目までスキャンするだけでよい
。（ここで、ｎは、サブストリングが始まるキャラクタ
を指示する、プラスｊ・リング関数の引数である。）続
いて、このバイトに後続の（ｍ−１）パイ１〜をプラス
したものが結果どして選択される。（ここで、ｍは、サ
ブストリングの指定キャラクタ長である。）しかしなが
ら、１バイト・２バイト混成ストリングを処理対象とす
るとき、プラス１−リング中のキャラクタの有効性を確
保すべく、プラス１へリングの最初と最後のハイドの性
質を決定しなければならない。このような複雑なアルゴ
リズムを採用する結果のパフォーマンスの低下には甚大
なものがある。

まとめると、上記説明は、純粋１バイ１−・ス１〜リン
グと１バイト・２バイＩ−混成ストリングの根本的相違
をハイライ１へするものであった。純粋１バイ１−・ス
トリングにおいては、その中のどのバイトもキャラクタ
である。しかるに、混成スｊ・リングにおいては、ス１
へリング内のどのパイ１〜についても、先行バイトの性
質を知らずには何も言えない。

「この差異の結果、純粋１バイ１へ・ス１〜リング（及
び、カラム）に対するストリング操作は、１バイト・２
バイｌ〜混成ス１〜リングについての同じ操作よりも、
はるかに速く、かつ簡単である。したがって、カラムを
純粋または混成の何れかとして宣言し得ることは、かか
る差異に敏感なアルゴリズムと結合することによって、
顕著なパフォーマンスの改善をもたらす。これが、ＦＯ
ＲＳＢＣ８ＤＡＴＡ、ＦＯＲＭＩＸＥＤ　　　ＤＡＴＡ
というカラム宣言をなそうとするに至った、大きな動機
である。

本発明のリレーショナル・データベース・システムでは
、以下のことを特に明示し、記述した。

ＳＱＬ言語を拡張することによって、ユーザ／アプリケ
−シコンは、データベース・テーブル中のカラムに含ま
れるデータが１パイ１〜・キャラクタ・セラ１〜・デー
タだけなのが、それとも１パイ１〜・キャラクタ・セッ
ト・データど２バイ１へ・キャラクタ・セラ１へ・デー
タが混在しているのかを、指定できるようになる。カラ
ムが１パイ１〜・キャラクタ・セット・データのみを持
つのが、それとも混合データを持つのかの指定は、ＣＩ
−（ＡＲ，ＶＡＲＣＨＡ　Ｒ１及びＬ　ＯＮ　Ｇ　　Ｖ
　Ａ　ＲＣＩ−（Ａ　Ｒを含むキャラクタ・データ・タ
イプのザブタイプを指定することによって達成される。

ユーザ／アプリケーションは、カラムの作成または追加
時に、テーブル作成文またはテーブル改造文において　
ＦＯＲ５ＢＣ８ＤＡＴＡ、、ＦＯＲＭＩＸＥＤＤ　Ａ、
　Ｔ　Ａ　、またはＦＯＲＥｒＴ　　ＤＡＴＡの何れか
を指定することによって、カラム中のキャラクタ・デー
タのサブタイプを指定することができる。

サブタイプが１バイト・データか混合データかを指定で
きることに併せて、ユーザ／アプリケーションは、さら
に、データベース中のテーブルのカラム使われるコード
ページを指定することができる。本発明のデータベース
・マネジャーの内部では、サブタイプが、キャラクタ・
データ・タイプのコード・ページ・アトリビュートの見
地で、データベース・システム・カタログにスＩ−され
る（第４表参照）。このエンコーディング・スキームに
よれば、データベース・システム・カタログ内のコード
・ページ・カタログに問い合わせるだけで、カラムが１
バイ１−・キャラクタ・セラ１−・データ対応なのか、
それとも混合データ対応なのかを決定し、同時に、使用
される正しいコード・ページを知ることのできる、有効
な方法が提供される。

５ＹＳＴＡＢＬＥＳ　（システム・テ ブル） 第１表 第５表 Ｅ１発明の効果 本発明によれば、１バイト・キャラクタ・データと２バ
イト・キャラクタ・データが混在するリレーショナル・
データ・ベース・システムにおけるデータ処理のパフォ
ーマンスが向上する。

【図面の簡単な説明】

第１Ａ図及び第１Ｂ図は、それぞれ本発明のリレーショ
ナル・データベース・システムの概観図である。 第２図は、１バイト・データについて用いられるコード
・ページの１例の説明図である。 第３図は、日本語について用いられるコード・ページの
１例の説明図である。 第４図は、リレーショナル・データ・ベースのデータ・
テーブルの１例の説明図である。 第５Ａ図は、カラムに含まれるデータが混合データか１
バイト・データかを指示するための、キャラクタ・デー
タ・タイプのサブタイプを指示することのできる、テー
ブル作成文の構造を示す説明図である。第５Ｂ図は、カ
ラムに含まれるデータが混合データか１バイト・データ
かを指示するための、キャラクタ・データ・タイプのサ
ブタイプを指示することのできる、テーブル改造文の構
造を示す説明図である。 第６図は、リレーショナル・データベース・マネジャー
のコンポーネントを示す図ブロック図である。 第７図は、本発明の方法に含まれる渚ステップの全体的
な関係を示す概括的なフロー・チャー１〜＝７６ である。 第８図は、リレーショナル・データ・サービスのコンポ
ーネントを示すブロック図である。 第９図は、ＳＱＬコンパイラのＳ　Ｑ　Ｌパーサ・フェ
ーズを説明するフロー・チャートである。 第１０図は、ＳＱＬコンパイラのコード生成フェーズを
説明するフロー・チャー１・である。 第１］、Ａ図、第１１Ｂ図、第１１Ｃ図、及び第１１Ｅ
図は、本発明を実現する疑似コートを説明するための詳
細なフロー・チャー１・である。 第１２図は、生成されたコード及びパ記述の実行を説明
するフロー・チャー１・である。 第１３図に、５ＱＬＤＡのコード・ページの内容の更新
を説明するフロー・チャー１・である。 第１．４Ａ図は、混合データについての切捨方法を説明
するフロー・チャートである。 第１．４Ｂ図は、１バイト・データについての切捨方法
を説明するフロー・チャー１・である。 第１５図は、混合データについてのサブストリング・ア
ルゴリズムのフロー・チャー１・である。 第７図

Claims (1)

1. 【特許請求の範囲】 １バイト・キャラクタ・データと２バイト・キャラクタ
   ・データが混在するリレーショナル・データベース・シ
   ステムであって、 上記リレーショナル・データベース・システムの少なく
   とも１つのテーブル中の少なくとも１つのカラムと、 上記カラムが１バイト・キャラクタ・データのみを持つ
   のか否かを指定するための手段 を含む、リレーショナル・データベース・システム。