JPH0212463A - データ記憶検索システム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は総括的にコンピュータの分野に関するものであ
り、具体的には、データ記憶検索システムに関するもの
である。

Ｂ、従来技術 ウィンチエスタ・ハード・ディスクまたは５１／４イン
チ・ディスケット等の記録媒体上に記憶されたデータの
記憶及び検索を容易にするデータベース管理プログラム
は、ディジタル・コンピュータ・システムでは周知であ
る。特に、コンピュータ及びそれらの関連周辺記憶装置
の大きさが小さくなったので、使用可能な記憶域を効率
的に使用することが望ましい。

データベース内のデータ様式は通常、種々の大きさの複
数のデータ・フィールドを含む。各フィールドの大きさ
は、固定長項目の場合はデータ項目内のバイトの数に等
しく設定され、可変長項目の場合はデータ項目の最大炎
に等しく設定される。

可変長データ項目の場合、または特定のフィールドにつ
いて項目が必ずしも、存在するとは限らない場合は、実
際に存在するデータ項目のみを収容するためフィールド
の大きさを縮小することにより、データを圧縮すること
ができる。

したがって、たとえば従業員名、社会保障番号、誕生日
等の連続したフィールドからなる従業員記録では、名前
フィールドが可変長であるのに対し、社会保障番号及び
誕生日のフィールドは固定長である。後の２つのフィー
ルドについては、社会保障番号をその各フィールドに入
力することが常に必要であるが、誕生日を含む必要はな
いことがある。したがって、これらのそれぞれのフィー
ルドのデータは以下の形態を取ることができる。

ＪＯＩＩＮ　Ｅ　ＤＯＥ／９８７６５４３２１１０１２
３４５ＭＡＲＹ　Ｊ　ＰＯＰＰＩＮＳ／１２３４５６７
８９１００００００最初のフィールド、すなわち名前フ
ィールドは、いかなる長さの名前でも収容するのに十分
な長さでなければならず、２番目のフィールドは正確に
９文字の長さでなければならず、３番目のフィールドは
６文字の長さでなければならない。場合によっては、上
の例でＯにより示すように、データが誕生日フィールド
に入力されないこともある。

これらのフィールドに配置されたこれらのデータ項目を
記憶するときは、実際に有用なデータのみを記憶するこ
とが望ましい。このことを実現するには、データベース
管理プログラムは、実際のデータが必要とするよりも大
きくならないように、記憶域内のフィールドの大きさを
変更しなければならない。記憶域内のデータ様式によっ
ては、このことは簡単な課題にもなることもあれば、非
常に難しい課題になることもある。

単純なデータ圧縮に適さないデータ様式の１つは、いわ
ゆる「関係データベース・テーブル」である。「関係デ
ータベース・テーブル」はデータ項目の２次元の配列、
すなわち行及び列を形成するデータ項目の配列である。

テーブルの各行は１つまたは複数の情報レコードからな
っている。各データ・レコードは、データ項目が配置さ
れた１つまたは複数のフィールドからなっている。これ
らのフィールドが社会保障番号、誕生日等の異なる属性
を有していてもかまわないし、またフィールドのグルー
プが特定のパラメータに対する統計資料グループ等の同
じ属性を有していてもかまわない。テーブルの列はすべ
てのレコードで同じフィールドである。１つの列に対す
るすべてのデータ項目は同じデータ・タイプでなければ
ならない（整数、浮動小数点数、固定長文字、可変長図
形等）。

したがって、テーブル内の特定のデータ項目はすべて正
確に１行及び１列に属し、そのようなものとして配置す
ることが可能である。

関係テーブルの一般的な使い方は、同種のデータ・オブ
ジェクトの集合を記述することである。

行はオブジェクトの単一の事例（インスタンス）を示し
、列はそのオブジェクトに関する記述データ属性である
。たとえば、従業員を記述するデータのテーブルは、名
前、社会保障番号、誕生日等に関する列値によって各従
業員に対して定義された行を含むことができる。

したがって、関係テーブル内のｒ列」を、テーブルの垂
直次元の１単位として定義することができる。列は通常
、列ロケーシヨンを有する全データ項目に適用される特
定のデータ属性を有する。

データ・　「フィールド」に類似した列がテーブルのす
べての行に適用可能である。

関係テーブルの「行」をテーブルの水平次元の１単位と
して定義することができる。行はテーブルの各列からの
データ項目を含むが、データ項目は行及び列ロケーシロ
ンのあるものから失われる可能性がある。すべての列は
すべての行について同じ順序であるものと見なされる。

したがって、行は非関係データベース内の「レコード」
と類似している。

テーブル内の行の順序についての前提は何もない。テー
ブルの行を異なった方法で論理的に規定するため、イン
デックスをユーザが作成することができ、したがって、
各インデックスは別の順序を定義する。したがって、「
インデックス」という用語を、昇順または降順の指定を
有するテーブル内の列の集合として定義することができ
る。−度定義されると、インデックスはデータベース管
理プログラムにより内部的に維持される。インデックス
は、データを操作または検索するためのユーザ要求では
決して参照されることはないが、順次ファイル検索によ
るよりも既存のインデックスを使用したアクセスの方が
速いと判断されるときに、内部的に使用される。

インデックスはいつでも作成することができ、いつでも
除去することができる。テーブルに対して何らかのイン
デックスが存在する必要性はない。

「基本テーブル」は、実データとして記録媒体上に物理
的に記憶される関係テーブルである。

「視点」　（ビュー）は、物理的記憶域には存在しない
が、１つまたは複数の基本テーブルから得られる関係テ
ーブルである。

この形式のデータが与えられると、「データベース」を
関係テーブル、カタログ・テーブル及び回復ログの集合
として定義することができる。データベースを、たとえ
ば、単一のＯ８／２フアイル・システム内にあるものと
限定することができる。

この限定は、すべてのカタログ及び回復機能を、任意の
データについて、その制御下で任意の時点で実行するこ
とが可能であることを保証する。データベースはハード
・ファイルまたはディスケットに記憶することができる
。多数のデータベースを単一のＯ８／２フアイル・シス
テム上に置くことができる。

本発明を理解するため必要なもう１つの用語は、データ
ベースのいわゆる「コードページ」環境である。「コー
ドページ」は変換テーブル、すなわち印刷装置、表示装
置またはその他の入出力装置により作成される文字表示
へのバイト・セット（２５６バイトある）のマツピング
として定義することができる。周知のコードページには
、ＥＢＣＤＩＣ文字セット（拡張２進化１０進コード）
の他に、ＡＳＣＩＩ（情報交換用米国標準コード）ＩＢ
Ｍ米国コードベージ４３７及び国際コードベージ８５０
がある。

あるデータベースと別のデータベースの間でデータを交
換する際は、必要な場合には、あるコードページから別
のコードページにデータの保全性を維持することができ
るように、データのコードページを知り、追跡すること
が必要である。しかし、交換方法はまた、原始データベ
ース上にある構造を目標データベース上で作成すること
を可能とするものでなければならない。このことは、テ
ーブル名、列名、列タイプ及びインデックスを交換の一
部として移さなければならないことを意味する。

Ｃ０発明が解決しようとする問題点 本発明の主な目的は、使用可能記憶域の効率的使用によ
り、関係データベースを記録媒体上に記憶することを可
能にする、データベース管理システムで使用するための
交換様式を提供することである。

本発明のさらに具体的な目的は、データ項目が空白であ
るか、またはその最大長よりも短かいときにファイル圧
縮を可能にする関係データベース・テーブル用のファイ
ル様式を提供することである。

本発明のさらに具体的な目的は、データベース間での関
係テーブルの内容の交換のためのファイル様式を提供す
ることである。

Ｄ１問題点を解決するための手段 これらの目的は、本発明によれば、以下からなる関係テ
ーブル・ファイル様式で、（１）データを記録媒体に伝
送するか、または（２）データを記録媒体に記憶し、か
つそこから検索することによって達成される。

（１）複数のデータ（ｒＤＪ　）レコード。各Ｄレコー
ドは可変長であり、連続して順次配置された、特定の行
に対する項目を含み、それにより、各Ｄレコード内の各
データ項目が別々の列に配置された複数のデータ行及び
列を形成し、１つのデータ行当り少なくとも１つのＤレ
コードがあり、テーブルの各行には一定数のＤレコード
がある。

（２）複数の列記述子（ｒｃＪ　）レコード。各Ｃレコ
ードは１つのテーブル列と関連づけられ、さらに以下を
指定する。

（ｉ）　　それぞれのＣレコードと関連づけられた上記
列の識別、 （ｉｉ　）上記の関連した列に置かれるデータ項目を含
むテーブル行内の関連Ｄレコードの識別。

（ｉｉｉ　）データ・タイプにより数が暗示されていな
い場合は、上記関連列でデータ項目を形成する文字の最
大数、及び （ｉｖ　）上記関連Ｄレコード内の関連列の開始位置。

すべての列記述子（ｒｃＪ　）レコードが、伝送または
記憶／検索中、連続配置レコードにおけるデータ（ｒＤ
Ｊ　）レコードに先行するのが好ましい。

列記述子（ｒｃＪ　）レコードはデータ（ｒＤＪ　）レ
コード及び位置を昇順で含んでいなければならないが、
列記述子レコード自体はどのような順序で配置してもか
まわない。

このテーブル・ファイル様式により、１行分のデータ内
に列に対するデータを配置するため、２つのフィールド
が列記述子（ｒｃＪ　）　Ｌ／：Ｉ−ト（７）各々に設
けられる。すなわち、どのデータ（ｒＤＪ　）・レコー
ドが（１行のデータからなる幾つかのデータ・レコード
の内の）この列に対するデータを含むかを指定するデー
タ・レコード識別子及び１行のデータの一部である。以
前に選択されたデータ・レコード内に、列に対するデー
タを配置するため使用されるデータ・レコード位置であ
る。したがって、このレコード位置は、特定のデータ・
レコード内でのそれぞれの列に対するデータ項目の絶対
変位を示す。

このファイル様式はまたＣレコード内で、関連の列（列
名）、ならびにデータ・タイプ、データ精度、データ空
白可能度及びコードページ環境等のこの列の属性の識別
を可能にする。したがって、各列のこれらの属性はすべ
てテーブルに一度だけ記憶される。さらに、この様式は
その他の列属性を含めるため、容易に拡張可能である。

好都合にも、このファイル様式は、あるデータベースか
ら別のデータベースにデータを転送するときに、データ
ベースのデータのいかなる変換も生じさせないので、こ
のファイル様式によるデータ消失の問題は全くない。強
制的な変換がないことは、同様なシステム間でデータ交
換が行なわれるとき、処理を最小限にする傾向がある。

一般に、上記のファイル様式を使用すると、どのような
列も、そのデータ・レコード内の最後の列であれば、圧
縮可能である。このことは、任意の可変長または空白可
能データ・フィールドの後に新しいデータ・レコードを
開始することにより実現される。このフィールドの始ま
りは、列記連子レコー・ドにより識別され、一方、この
フィールドの終わりは、「Ｄ」レコード内における先行
する空白標識ないし長さ標識により識別される。

任意の定数よりも長い最大長さを有する空白可能または
可変長フィールドのみが圧縮されることが好ましい。た
とえば、そのような定数を、サポートされる任意の数値
の最長の長さに等しくすることができる。非常に長くな
る可能性があるものと認識された可変長フィールドは（
たとえば、ｒＬＯＮＧ　ＶＡＲＣＨＡＲＪ及びｒＬＯＮ
Ｇ　ＶＡＲＧＲＡＰＨＩＣＪにより）それら自身の専用
データ・レコードを各々占有することができる。

列記述子（ｒｃＪ　）及びデータ（ｒＤＪ　）・レコー
ドに加えて、関係テーブルはヘッダ（ｒＨＪ　）・レコ
ード、テーブル（ｒＴＪ）　　・レコード、インデック
ス（ｒＡＩＪ）・レコード及び終了（ｒＡＥＪ　）レコ
ード等の他のレコードを含むことができる。Ｈ，Ｔ及び
ＡＩレコードは、以下に詳細に考察するように、各々幾
つかの情報項目を指定することができる。ＡＥレコード
は、テーブルの終わりのＨを指定するのが好ましい。

レコード長フィールドがすべてのレコード（Ｈレコード
、Ｔレコード、Ｃレコード、Ｄレコード、ＡＩレコード
及びＡＥレコード）の始めに付加される。Ｃレコードは
記録媒体上における順次配置レコード内のＤレコードに
先行する。

単一バイト及び２バイト・コードページ・フィールドが
、テーブル・ファイルを開始するＨレコードに付加され
る。単一バイト及び２バイト・コードページ・フィール
ドはＣレコードにも含まれる。

Ｈレコード内のコードページ・フィールドはテーブル内
の文字データのコードページを指定するが、以下の２つ
の例外の可能性がある。

（１）データ・レコードのデータ部分内の列データ、及
び （２）その他のアプリケージ日ン固有レコード内のデー
タ。

文字（及び図形）列のＣレコード内のコードページ・フ
ィールドは、それぞれの列に対するデータのコードペー
ジを指定する。「ピット・データ」の文字列は、ビット
・データが印刷時に文字に変換されないことを示すため
、その単一または２バイト・コードページに対して０を
存することができる。

これらのコードページ識別フィールドは、ホスト自コン
ピュータとパーソナル・コンピュータの間のデータベー
ス・データの移行について責任を負うプログラムが、ど
のフィールドに文字変換が適用されるのかを識別するこ
とを可能にする。また、あるデータベースから別のデー
タベースにデータを移行するとき、ユーザが選択を行な
うことを可能とする。たとえば、異なるコードページ環
境から現われるデータをユーザが受は入れるか、または
拒絶することを可能にする。

本発明を完全に理解するため、本発明の好ましい実施例
についての以下の詳細な説明及び添付の図面を次に参照
するべきである。

Ｅ、実施例 次に、図面の第１図ないし第６図に関連して本発明の好
ましい実施例について説明する。

第１図は本発明の概略的なコンピュータ・ハードウェア
環境を示す。本発明は単一のパーソナル・コンピュータ
、情報を交換するため互いに接続された２台以上のパー
ソナル・コンピュータ、または、第１図に示すように、
互いに接続され、かつＩＢＭ３７０システム等のホスト
・コンピュータに接続された２台以上のパーソナル・コ
ンピュータ上に存在することができる。第１図は、大型
ディスク記憶ファイル１２と動作するホスト・コンピュ
ータ１０を示す。第１のパーソナル・コンピュータ１４
と第２のパーソナル・コンピュータ１６が、データ及び
制御情報を伝送する複数の線１８及び２０をそれぞれ介
して、ホスト・コンピュータ１０に接続される。２台の
パーソナル・コンピュータはまたデータ及び制御線２２
を介して互いに接続されている。

本発明のデータベース環境は、第２図に示す形態を取る
ことができる。この場合は、ＰＳ／２パーソナル・コン
ピュータは、関係テーブル構造及びデータの交換を可能
にする統合交換様式（ＩＸＦ）データ交換ソフトウェア
を変形したＯ８／２拡張版データベース・マネージャで
動作する。文字データは、ＩＢＭＡＳＣＩＩコードペー
ジ４コードページ環境−ドページ環境における１つまた
は複数のデータベースに記憶される。数字及び８７時デ
ータは、基本オペレーティング・システム及びハードウ
ェアがサポートする様式で内部的に記憶される。

詳細にいえば、データベース・マネージャは、すべての
データがテーブルの集合と見なされるようになった関係
データベース・モデルをサポートするデータベース管理
システム（ハードウェア及びソフトウェア）である。デ
ータベース・マネージャは、以下で説明する「データベ
ース・サービス」と呼ばれる関係コマンド・プロセッサ
、別のコンピュータ・システムからデータを搬入し、か
つ別のコンピュータ・システムにデータを搬出するため
のシステム、及び個々の関係データベース・テーブルの
バックアップ及び復元とテーブル維持のためのシステム
を提供する。

データベース・サービスはデータベース・マネージャの
関係コマンド・プロセッサである。データベース・サー
ビスは多数の機能を提供するものであって、これらの機
能には、記憶アクセスのためのシステム、構造化照会言
語（ＳＱＬ）ステートメント処理、データベース管理、
ロック管理、競合管理、先行書込みロギング、回復サー
ビス、行レベル・ロッキング細分性、アプリケーション
、システムまたは記録媒体が故障した場合のデータ回復
、及び安全保護制御がある。

ＰＣ／ＩＸＦアーキテクチャは、受信側（ハードウェア
及びソフトウェア）データベース・システムの要件及び
特質を予想する必要性なしに、データベース・サービス
がデータベースを搬出することを可能にする。同様に、
ＰＣ／ＩＸＦファイルを搬入するデータベース・システ
ムはＰＣ／ＩＸＦアーキテクチャを理解するだけでよく
、ファイルを搬出したシステムの特性は関係ない。ＰＣ
／ＩＸＦファイル・アーキテクチャはデータベース・シ
ステムの搬出及び搬入の両方の独立性を維持する。

ＩＸＦアーキテクチャは、総称関係データベース交換様
式として、多分特定の関係データベース・プロダクトに
よりサポートされない幾つかのデータ・タイプを含む大
きな関係データ・タイプ・セットをサポートすることが
好ましい。ＰＣ／ＩＭＦファイル様式はこの融通性を保
持する。たとえば、ＰＣ／ＩＸＦアーキテクチャは単一
バイト及び２バイト両方のストリング・データ・タイプ
をサポートする。すべてのデータベース・システムがす
べてのＰＣ／ＩＸＦデータ・タイプをサポートするわけ
ではないが、限定されたデータ・システム実施例でさえ
、搬入中に、サポートされていないデータ・タイプの検
出及び後処理をもたらす。

以下では、特にＰＣ／ＩＸＦと関連して本発明について
説明するが、本発明の教示するところはＰＣ環境のみに
限定されるものではない。具体的には、本発明はＰＣに
対する機械依存性はなく、ＩＢＭ社のＰＳ／２及びＲＴ
コンピュータ、中型コンピュータ等のその他のコンピュ
ータでの使用に適合させることができる。

同様に、Ｏ８／２オペレーテイング・システムと関連し
て本発明は説明するが、本発明はこれに限定されるもの
ではなく、周知のオペレーティング・システムのどのよ
うなものでの使用にも適合させることができる。Ｏ８／
２、Ｏ８／２拡張版、Ｏ８／２ＥＥ、ＰＳ／２及びＲＴ
はＩＢＭ社の商標である。

第３図は、典型的な連系データベース・テーブルを示す
。このようなテーブルを含むファイルは、ファイル／レ
コード／フィールドまたは関係／集合／属性に対立する
ものとしてのテーブル維持／列という用語を使用する。

明らかなように、テーブル名は「都市」である。テーブ
ルは各都市にっき１行ずつの複数の水平行を含み、各行
は複数の情報フィールドからなる。これらの情報フィー
ルドは各情報フィールドにつき１列ずつの垂直列に配置
されている。

実際には、関係テーブルの各行に含まれるデータ・レコ
ードは、第４図に示す方法で選択される。

この図は、Ｄレコードを第３図のテーブル内で割り振る
ための可能な方式を示す。各列の最上部には、列名とこ
の列に含まれるデータのタイプが示される。データ・タ
イプはデータ・タイプの規定されているセットから選択
される。これらのデータ・タイプは、たとえば、以下を
含む。

ＩＮＴＥＧＥＲ：　−２１４７４８３８４８と＋２１４
７４８３６４７の間のすべての数を表わす４バイトの整
数。

ＶＡＲＣＩＩＡＲ：可変長文字ストリング。ストリング
の最大長（バイト）は２５４バイトを超えることはでき
ない。ストリングは、この列に対して規定されたコード
ページにある。

ＣＩＩＡＲ：　２５４バイトの最大ストリング長を有す
る固定長文字ストリング。ストリングは、この列に対し
て規定されたコードページにある。

ＬＯＮＧＶＡＲＣＨＡＲ：　３２７６７　ハイ）を超エ
ルコトができない可変長文字ストリング。このストリン
グは、この列に対して指示されたコードページにある。

ストリング自体の前には、ストリングの長さをバイトで
指定する２バイトの整数である現在長標識が付けられる
。

ＳＭＡＬＬＩＮＴ　：　−３２７８８と＋３２７６７の
間のすべての数を表わす２バイトの整数。

ＦＬＯＡＴＩＮＧ　ＰＯＩＮＴ　：　ＩＥＥＥ様式の良
精度（８バイト）または短精度（４バイト）浮動小数点
数のいずれか。

ＧＲＡＰＨＩＣ：　１２７を超えることができない２バ
イト文字の固定長ストリング。ストリングは、この列に
対して指定されたコードページにある。

ＶＡＲＧＲＡＰＨＩＣ：最大数が１２７を超えることが
できない２バイト文字の可変長ストリング。このＶＡＲ
ＧＲＡＰ）ＩＩｃ　データに対するコードページは、そ
の列に対して指定された通りである。

本発明に従って記憶データの圧縮も可能にするため、行
データは、１．２及び３の番号を付された別々のデータ
（ｒＤＪ　）・レコード（この事例では３個）に分割さ
れる。各Ｄレコードは可変長フィールド（列）または、
データを含まなくてもよい（空白）フィールド（列）の
いずれかで終了する。このようにして、特定の行におけ
るデータ・レコードは、それらの最後のフィールドに含
まれる実際のデータにとって必要な大きさよりも長い必
要はない。

上で説明したように、本発明によるファイル様式は、関
連するＤレコード識別番号（１，２，３等）及び関連す
るＤレコード位置を指定する列記述子（「Ｃ」）レコー
ドを含む。Ｄレコード位置は、列の始めに対するＤレコ
ードのデータ域部分内にバイト変位として記憶される。

一般にそのデータベース・サービスにより書き込まれる
か、または読み取られるＰＣ／ＩＸＦファイル、または
データベース・サービスの出力は連続した一連の可変長
レコードからなる。ファイルは、所定の順序で以下のレ
コード・タイプを含む。

１つのヘッダ（ｒＨＪ　’）・レコード、１つのテーブ
ル（ｒＴＪ　”）・レコード、複数の列記述子（「Ｃ」
）・レコード（テーブル内の各データ列ごとにルコード
）、 複数のデータ（ｒＤＪ）・レコード（テーブルの各行は
１つまたは複数のｒＤＪレコードにより表わされる）、
及び ０１１または複数のインデックス（ｒＡＩＪ）・レコー
ド（各インデックスはテーブルから定義される）、及び １つの終了（ｒＡＥＪ　）・レコード。

ＰＣ／ＩＸＦファイルはまた、ｒＨＪレコードの後のど
こにでもアプリケーション固宵（ｒＡＪ　）レコードを
含むことができる。これらのｒＡＪレコードはＰＣ／Ｉ
ＸＦファイルで、アプリケージ日ンが、ＰＣ／ＩＸＦ様
式により定義されない追加データをＰＣ／ＩＸＦファイ
ルに含むことができるようにすることができる。たとえ
ば、テーブルのインデックスを記憶するため、もしくは
単一■ＸＦファイルの複数ディスケット記憶を可能にす
るため、「Ａ」レコードを使用することができる。

ｒＡＪレコード内のアプリケ−シロン識別子により暗示
されるデータ様式及び内容に関する特定の知識を持たな
いＰＣ／ＩＸＦファイルを読むあらゆるプログラムは、
「Ａ」レコードを無視する。

次のテーブルでは、各々の特定レコードは、各々がフィ
ールド名を与えられた一連のフィールドとして記述され
ている。各レコードについて、これらのフィールドは定
義された長さであり、示された順序で現われねばならな
い。

ヘッダ・レコード フィールド名　　　フィールド長（バイト）レコード長
　　　　　　　　　０６ レコード・タイプ＝ｒＨｊ　　　０１ １ＸＦ識別子　　　　　　　　０３ ＩＸＦバ一ジ日ン　　　　　０４ ソフトウェア・プロダクト　　１２ 書かれた日付　　　　　　　　０８ 書かれた時間　　　　　　　　０６ ヘツデイング・　　　　　　　０５ レコード・カウント 単一バイト・コードページ　　０５ ２バイト書コードページ　　　０５ 予約　　　　　　　　　　　　０２ テーブル・レコード フィールド名　　　　フィールド長（バイト）レコード
長　　　　　　　　　０６ レコード・タイプ＝ｒＴＪ　　　０１ 名前長　　　　　　　　　　０２ データの名前（テーブル名）１８ 修飾子　　　　　　　　　　　０８ データ・ソース　　　　　　　１２ デ一タ規則＝ｒＣＪ　　　　　　０１ デ一タ様式＝　ｒＭＪ　　　　　　Ｏ１機械様式＝　ｒ
ＰｃＪ　　　　　　０５データ・ロケーシヨン　　　　
０１ ＝「Ｉ」 「Ｃ」レコード・カウント　　０５ 予約　　　　　　　　　　　　０２ データ記述　　　　　　　　　３０ 列記述子レコード レコード長 レコード・タイプ＝「Ｃｊ 列名長 列名 列は空白を許容する 列はフラッグを選択した 主要な列フラッグ データ・クラス データ・タイプ 単一バイト・コードページ ２バイト・コードページ 列データ長 ｒＤＪレコード識別子 列位置 列記述 次元数 各次元の大きさ 工８ 可変 データ・レコード フィールド名　　　　フィールド長（バイト）レコード
長　　　　　　　　　０６ レコード・タイプ＝＝ｒ［）Ｊ　　　０１ｒＤＪレコー
ド識別子　　　０３ 予約　　　　　　　　　　　　０４ 列データ零　　　　　　　　　可変 傘空白標識値及び可変長フィールドの長さを含む。

アプリケーション・レコード フィールド名　　　　フィールド長（バイト）レコード
長　　　　　　　　　０６ レコード・タイプ＝ｒＡＪ　　　ｏｔ アプリケージ日ノン識別子　　１２ アプリケージ目ン固有データ可変 これらのレコードは、第５図に示す順序でファイル内に
配置される。アプリケーシヨン・レコードは他の任意の
２つのレコード・タイプの間に配置することができる。

第６Ａ図及び第６Ｂ図は、ＰＣ／ＩＸＦファイルを記録
媒体上に書き込むためデータベース・ユーティリティが
どのように動作するかを示す。レコードからデータを読
み取るための処理は、書込みの手順と同様である。

テーブルを記憶する最初のステップは、原始データベー
スのコードページ環境を含むＨレコードを書くことであ
る。その後、Ｔレコードが生成され、記録媒体上に書き
込まれる。Ｔレコードに続いて、Ｃレコードが１つずつ
書き込まれる。上で説明したように、これらのＣレコー
ドは各々１列のテーブル列に関連づけられ、さらに以下
を指定する。

（１）データ・タイプ等、それぞれのＣレコードと関連
した列の識別及び規定の属性、 （２）関連した列に配置されるデータ項目を含むテーブ
ル列における関連したＤレコードの識別、（３）データ
・タイプにより数が暗示されていない場合は、関連した
列におけるデータ項目を形成する最大数の文字、 （４）関連したＤレコード内の関連した列の位置。

すべてのＣレコードが書き込まれた後、プログラムはテ
ーブル内の各々の連続杆について個々のＤレコードの書
込みを始める。Ｄレコードは、テーブル内のデータが要
求するように、可変長である。

各Ｄレコードの最後のフィールドは行内の最後の列か、
または可変長データ項目か、または空白にすることが可
能なデータ項目のいずれかを含む列のいずれかであるこ
とが好ましい。

第６Ｂ図から明らかなように、アルゴリズムはまず、す
べてのデータ行が書き込まれたかどうか質問し、書き込
まれていない場合は、現在の行内のすべてのＤレコード
が考慮されたかどうか質問する。書き込むべきＤレコー
ド及び行が他にない場合は、プログラムはインデックス
もしくは終了レコード等の同じアプリケーション固有情
報を書き込み、次にテーブルの終わりに終了（ｒＡＥＪ
　）レコードを書き込むことができる。さらにＤレコー
ドが書き込まれる場合は、プログラムは現在のＤレコー
ドの最後の列を探し、次に、バッファに記憶された列デ
ータからＤレコードの大きさを計算する。これは、バッ
ファ内の最後の有意データの終わりに基づく変数である
。−度大きさが計算されると、Ｄレコードが記録媒体に
書き込まれ、プログラムは現在の行における次のＤレコ
ードについて処理を繰り返し、その後で、次の後続行に
おける最初のＤレコードについて処理を繰り返す。

Ｆ０発明の効果 要するに、本発明のファイル様式は多くの点で従来技術
よりも優れている。最初の空白フィールドまたは最大サ
イズよりも小さい可変長フィールドは圧縮可能である。

列属性のさらに他の記憶は多くの理由で理想的である。

各列の属性は正確に一度記憶される。すべての属性（列
名、列タイプ、精度、長さまたは最大長、空白可能性、
コードページ）を記憶することができ、様式はその他の
列属性に対して容易に拡張可能である。また、すべての
関係タイプがサポートされ、様式は新しいタイプに対し
て容易に拡張可能である。

本発明のさらに他の肯定的な特徴には、データベース・
データの強制変換がないので、様式に起因するデータ消
失の問題はなく、類似システム間でデータ変更があると
きに処理時間が最小にされるということがある。さらに
、コードページ識別フィールドは、異なるコードページ
環境からのデータを受は入れるか、または拒絶するため
のユーザの選択を可能にする。その他のアプリケージ日
ン固存レコードに対するサポートは、その他のアプリケ
ーション固有（Ａ）レコードの包含等の利益をさらにも
たらす。そのようなレコードは、たとえば、テーブルの
インデックスを記憶するため使用することができ、さら
に、単一ＰＣ／ＩＸＦファイルの複数ディスケット記憶
を可能にすることができる。

【図面の簡単な説明】

第１図は、ホスト・コンピュータ及び２台のパーソナル
・コンピュータからなる小ネットワークを示すブロック
・ダイヤグラムである。 第２図は、データベース管理プログラム及び２つの独立
したデータベースをサポートするオペレーティング令シ
ステムを使用したパーソナルΦコンピュータ・システム
のブロック・ダイヤグラムである。 第３図は、関係テーブルに配置することができるデータ
の一例である。 第４図は、異なるデータ・タイプの列と異なる長さのデ
ータ・レコードを含む関係テーブルの特定の例である。 第５図はＰＣ／ＩＸＦファイル内のレコードの配置を示
すチャートである。 第６Ａ図及び第６Ｂ図（ひとまとめにして）は、ＰＣ／
ＩＸＦファイルを書くための流れ図である。 １０・・・・ホスト・コンビエータ、１２・・・・ディ
スク記憶装置、１４．１８・・・・パーソナル・コンビ
エータ。 出願人　　インターナショナル−ビジネス・マシーンズ
・コーポレーシヨン 復代理人　弁理士　　澤　　１）　俊　　夫葛４図 ′＄６Ａ図

Claims (1)

1. 【特許請求の範囲】 データを記憶するための記録媒体と、 上記記録媒体上に記憶される関係データ・テーブルとか
   らなり、 上記テーブルが、複数のテーブル行と複数のテーブル列
   の交点に配置された複数のデータ項目からなり、上記テ
   ーブルが、連続して直列に配置された複数のレコードを
   含み、 上記レコードが、つぎの（ａ）及び（ｂ）のレコードを
   含むようにしたことを特徴とするデータ記憶検索システ
   ム。 （ａ）複数のデータ・レコード 上記データ・レコードの各々は可変長であり、かつ連続
   して順次に配置された、特定の行に対するデータ項目を
   含む。各データ・レコードの各データ項目は別個の列に
   属し、複数のデータ・レコードにより複数のデータ行及
   び列を形成する。 １つのデータ行当り少なくとも１つのデータ・レコード
   があり、一定数のデータ・レコードが上記テーブルの各
   行にある。 （ｂ）複数の列記述子レコード 上記列記述子レコードの各々は１つのテーブル列と関係
   付けられるとともに、 （ｉ）それぞれの列記述子レコードと関連した上記列の
   識別、 （ｉｉ）上記の関連した列に置かれるデータ項目を含む
   テーブル行における関連データ・レコードの識別、 （ｉｉｉ）上記データ項目におけるデータ・タイプによ
   り数が暗示されていない場合は、上記の関連した列にお
   けるデータ項目を形成する最大数の文字、及び （ｉｖ）上記の関連したデータ・レコード内の関連した
   列の開始部分を指定する。