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

Description

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

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

データベース内のデータ様式は通常、種々の大きさの複
数のデータ・フィールドを含む。各フィールドの大きさ
は、固定長項目の場合はデータ項目内のバイトの数に等
しく設定され、可変長項目の場合はデータ項目の最大長
に等しく設定される。可変長データ項目の場合、または
特定のフィールドについて項目が必ずしも存在するとは
限らない場合は、実際に存在するデータ項目のみを収容
するためフィールドの大きさを縮小することにより、デ
ータを圧縮することができる。

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

JOHN E DOE/987654321/012345 MARY J POPPINS/123456789/000000 最初のフィールド、すなわち名前フィールドは、いかな
る長さの名前でも収容するのに十分な長さでなければな
らず、２番目のフィールドは正確に９文字の長さでなけ
ればならず、３番目のフィールドは６文字の長さでなけ
ればならない。場合によっては、上の例で０により示す
ように、データが誕生日フィールドに入力されないこと
もある。

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

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

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

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

したがって、関係テーブル内の「列」を、テーブルの垂
直次元の１単位として定義することができる。列は通
常、列ロケーションを有する全データ項目に適用される
特定のデータ属性を有する。データ・「フィールド」に
類似した列がテーブルのすべての行に適用可能である。

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

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

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

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

この形式のデータが与えられると、「データベース」を
関係テーブル、カタログ・テーブル及び回復ログの集合
として定義することができる。データベースを、たとえ
ば、単一のOS/2ファイル・システム内にあるものと限定
することができる。この限定は、すべてのカタログ及び
回復機能を、任意のデータについて、その制御下で任意
の時点で実行することが可能であることを保証する。デ
ータベースはハード・ファイルまたはディスケットに記
憶することができる。多数のデータベースを単一のOS/2
ファイル・システム上に置くことができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下では、特にPC/IXFと関連して本発明について説明す
るが、本発明の教示するところはPC環境のみに限定され
るものではない。具体的には、本発明はPCに対する機械
依存性はなく、IBM社のPS/2及びRTコンピュータ、中型
コンピュータ等のその他のコンピュータでの使用に適合
させることができる。

同様に、OS/2オペレーティング・システムと関連して本
発明は説明するが、本発明はこれに限定されるものでは
なく、周知のオペレーティング・システムのどのような
ものでの使用にも適合させることができる。OS/2、OS/2
拡張版、OS/2EE、PS/2及びRTはIBM社の商標である。

第３図は、典型的な連系データベース・テーブルを示
す。このようなテーブルを含むファイルは、ファイル／
レコード／フィールドまたは関係／集合／属性に対立す
るものしてのテーブル／行／列という用語を使用する。
明らかなように、テーブル名は「都市」である。テーブ
ルは各都市につき１行ずつの複数の水平行を含み、各行
は複数の情報フィールドからなる。これらの情報フィー
ルドは各情報フィールドにつき１列ずつの垂直列に配置
されている。

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

INTEGER:−2147483648と＋2147483647の間のすべての数
を表わす４バイトの整数。

VARCHAR:可変長文字ストリング。ストリングの最大長
（バイト）は254バイトを超えることはできない。スト
リングは、この列に対して規定されたコードページにあ
る。

CHAR:254バイトの最大ストリング長を有する固定長文字
ストリング。ストリングは、この列に対して規定された
コードページにある。

LONGVARCHAR:32767バイトを超えることができない可変
長文字ストリング。このストリングは、この列に対して
指示されたコードページにある。ストリング自体の前に
は、ストリングの長さをバイトで指定する２バイトの整
数である現在長標識が付けられる。

SMALLINT:−32768と＋32767の間のすべての数を表わす
２バイトの整数。

FLOATING POINT:IEEE様式の長精度（８バイト）または
短精度（４バイト）浮動小数点数のいずれか。

GRAPHIC:127を超えることができない２バイト文字の固
定長ストリング。ストリングは、この列に対して指定さ
れたコードページにある。

VARGRAPHIC:最大数が127を超えることができない２バイ
ト文字の可変長ストリング。このVARGRAPHICデータに対
するコードページは、その列に対して指定された通りで
ある。

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

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

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

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

PC/IXFファイルはまた、「Ｈ」レコードの後のどこにで
もアプリケーション固有（「Ａ」）レコードを含むこと
ができる。これらの「Ａ」レコードはPC/IXFファイル
で、アプリケーションが、PC/IXF様式により定義されな
い追加データをPC/IXFファイルに含むことができるよう
にすることができる。たとえば、テーブルのインデック
スを記憶するため、もしくは単一IXFファイルの複数デ
ィスケット記憶を可能にするため、「Ａ」レコードを使
用することができる。「Ａ」レコード内のアプリケーシ
ョン識別子により暗示されるデータ様式及び内容に関す
る特定の知識を持たないPC/IXFファイルを読むあらゆる
プログラムは、「Ａ」レコードを無視する。

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

これらのレコードは、第５図に示す順序でファイル内に
配置されている。アプリケーション・レコードは他の任
意の２つのレコード・タイプの間に配置することができ
る。

第6A図及び第6B図は、PC/IXFファイルを記録媒体上に書
き込むためデータベース・ユーティリティがどのように
動作するかを示す。レコードからデータを読み取るため
の処理は、書込みの手順と同様であり、第6A図及び第6B
図中それぞれ「媒体に」を「媒体から」、「書込む」を
「読み込む」、「生成し」を「検索し」、「形成する」
を「検索する」に置き換えることによってファイルを読
むための流れ図を得ることができる（第7A図及び第7B
図）。

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

（１） データ・タイプ等、それぞれのＣレコードと関
連した列の識別及び規定の属性、 （２） 関連した列に配置されるデータ項目を含むテー
ブル列における関連したＤレコードの識別、 （３） データ・タイプにより数が暗示されていない場
合は、関連した列におけるデータ項目を形成する最大数
の文字、 （４） 関連したＤレコード内の関連した列の位置。す
べてのＣレコードが書き込まれた後、プログラムはテー
ブル内の各々の連続行について個々のＤレコードの書込
みを始める。Ｄレコードは、テーブル内のデータが要求
するように、可変長である。各Ｄレコードの最後のフィ
ールドは行内の最後の列か、または可変長データ項目
か、または空白にすることが可能なデータ項目のいずれ
かを含む列のいずれかであることが好ましい。

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

F.発明の効果 要するに、本発明のファイル様式は多くの点で従来技術
よりも優れている。最初の空白フィールドまたは最大サ
イズよりも小さい可変長フィールドは圧縮可能である。
列属性のさらに他の記憶は多くの理由で理想的である。
各列の属性は正確に一度記憶される。すべての属性（列
名、列タイプ、精度、長さまたは最大長、空白可能性、
コードページ）を記憶することができ、様式はその他の
列属性に対して容易に拡張可能である。また、すべての
関係タイプがサポートされ、様式は新しいタイプに対し
て容易に拡張可能である。

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

【図面の簡単な説明】

第１図は、ホスト・コンピュータ及び２台のパーソナル
・コンピュータからなる小ネットワークを示すブロック
・ダイヤグラムである。 第２図は、データベース管理プログラム及び２つの独立
したデータベースをサポートするオペレーティング・シ
ステムを使用したパーソナル・コンピュータ・システム
のブロック・ダイヤグラムである。 第３図は、関係テーブルに配置することができるデータ
の一例である。 第４図は、異なるデータ・タイプの列と異なる長さのデ
ータ・レコードを含む関係テーブルの特定の例である。 第５図はPC/IXFファイル内のレコードの配置を示すチャ
ートである。 第6A図及び第6B図（ひとまとめにして）は、PC/IXFファ
イルを書くための流れ図である。 第7A図及び第7B図（ひとまとめにして）は、PC/IXFファ
イルを読むための流れ図である。 10……ホスト・コンピュータ、12……ディスク記憶装
置、14、16……パーソナル・コンピュータ。

フロントページの続き (72)発明者 ロイド・ジユーゼン・ジヨーダン、セカン ド アメリカ合衆国テキサス州オースチン、ベ イスウオーター・ガーデン13505番地 (72)発明者 レイモンド・ヘルナンデス アメリカ合衆国テキサス州オースチン、カ ウンシル・ブラフ・ドライブ13304番地 (56)参考文献 Ｃ．Ｊ．Ｄａｔｅ著，藤原譲訳「データ ベース・システム概論」（昭和59年）丸善 Ｐ．87−279 「データベースの基礎」（昭和54年）オ ーム社Ｐ．28−31，Ｐ．94−101 「データベース・導入と設計」（昭和50 年）企画センターＰ．42−50

Claims (1)

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