JPH08123713A

JPH08123713A - データベース用ファイル格納管理システム

Info

Publication number: JPH08123713A
Application number: JP6255231A
Authority: JP
Inventors: Masayuki Nakayama; 正行中山; Yukiyasu Kobayashi; 志康小林; Yasuhiro Suzuki; 康弘鈴木
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1994-10-20
Filing date: 1994-10-20
Publication date: 1996-05-17
Anticipated expiration: 2020-06-29
Also published as: US5915254A; JP3666907B2

Abstract

(57)【要約】【目的】データ個々の実体を表すレコード間の親子関係
に応じて、データ格納ファイル内にお互いに近接して編
成させるファイル格納管理システムを提供する。【構成】リレーション定義ファイルと、データページフ
ァイルと、データページと、ページマップファイルと、
メタマップファイルを有する。且つ、従属関係管理手段
と、データページ管理手段と、ページマップ管理手段
と、メタマップ管理手段とを有し、前記従属関係管理手
段、データページ管理手段、ページマップ管理手段、メ
タマップ管理手段を操作し、リレーション及びモジュー
ルに所属したレコードに対する挿入（ｉｎｓｅｒｔ）、
削除（ｒｅｍｏｖｅ）、モジュール単位のレコードの主
記憶上への読み込み（ｌｏａｄ）、更にリレーションを
通したレコード単位の読み込み（ｓｃａｎ）を実行す
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、クラスタリングを促進
したデータベースのためのファイル格納管理システムに
関する。特に、データの型に対する集合を表したリレー
ション毎のアクセスを可能としながら、データ個々の実
体を表すレコード間の親子関係に応じて、データ格納フ
ァイル内にお互いに近接して編成させるファイル格納管
理システムに関する。

【０００２】

【従来の技術】ＣＡＤ（ＣｏｍｐｕｔｅｒＡｉｄｅｄ
Ｄｅｓｉｇｎ）のようなエンジニアリング・アプリケ
ーションの分野ではデータベースの利用に関し、データ
間にモジュール性を持ち、このモジュール単位のデータ
処理を高速に実現することが要求されている。

【０００３】一方、リレーショナル・データベース管理
システム（ＲＤＢＭＳ）では、ＳＱＬ（Ｓｔｒｕｃｔｕ
ｒｅｄＱｕｅｒｙＬａｎｇｕａｇｅ）のように、大
量データを様々な項目で臨機応変（ａｄｈｏｃ）に検索
できる特徴がある。

【０００４】しかし、ＲＤＢＭＳは、従業員情報のよう
に均質なデータの処理を対象としたビジネス・アプリケ
ーションの分野に適したものであり、エンジニアリング
・アプリケーションの分野には、適さないとされてい
る。

【０００５】アプリケーション・プログラムが扱うデー
タの単位となるレコード（ｒｅｃｏｒｄ）、又はタップ
ル（ｔｕｐｌｅ）は、それぞれ一様な型（ｔｙｐｅ）、
又はクラス（ｃｌａｓｓ）を持ち、レコードがどんなデ
ータ項目のフィールドで構成されるかを表している。

【０００６】ＲＤＢＭＳでは、この型やクラスに適応し
たリレーションという単位で、レコードの集合を管理す
るものであり、これにより一つのリレーションに属する
広範囲のレコードについて、一様な検索条件を適用する
ことができる。

【０００７】一方で、レコード間の従属関係のようなモ
ジュール性を表現する場合もモジュール単位を識別する
一つのキーによる検索により集める必要があり、この場
合のモジュール単位のアクセス動作は遅い。

【０００８】ＲＤＢＭＳの各レコードに対するこのよう
な識別キーに対し、ハッシュ（Ｈａｓｈ）コードやＢ
（バイナリー）−ｔｒｅｅ等の２次インデクスを設ける
ことにより、モジュール単位のアクセスを高速化するこ
とも提案されている（米国特許No. ４，９６１，１３
９、米国特許No. ５，０５８，００２）。

【０００９】ここで、ハッシュコードとは、あるキーを
もとにデータ領域を確保し、そのキー位置をもとに、デ
ータをぶら下げていくものである。Ｂ−ｔｒｅｅは、あ
るキーで分布されたツリーコードでぶら下げていくもの
で、半分、半分にデータを分割して格納されるので、検
索の場合は、半分の時間で済むという利点がある。

【００１０】しかし、これらの方法でも２次インデクス
で纏められたモジュール単位のレコードが、物理的に離
散して二次記憶装置に格納配置される場合は、データへ
のアクセスが遅くなる。

【００１１】更に、ネットワーク型データベース管理シ
ステムのように、モジュール単位のようなある特定のレ
コード間の関係を、レコード間のアドレス・リンクで表
現する方法もある。この場合は、データをリンク関係で
繋いでいくものであり、前のデータ、次のデータ、そし
てその次のデータと言うようにリンクを辿るようにアク
セスするようにした方法である。

【００１２】しかし、この場合も同様にアドレス・リン
クされたレコード群が、必ずしも物理的に近接して配置
されるとは限らない。

【００１３】したがって、モジュール単位の高速アクセ
スを可能とするには、このようなレコード間の従属関係
に応じて、物理的に近接配置することが必要である。こ
れを解決する方法として、区分編成（ｐａｒｔｉｔｉｏ
ｎｅｄｏｒｇａｎｉｚａｔｉｏｎ）ファイルのよう
に、モジュール単位の物理的な格納管理情報を表したデ
ィレクトリを設ける方法が考えられる（米国特許No.
４，８２７，４６２、米国特許No. ５，０５８，００
２）。

【００１４】この方法では、モジュール単位となる複数
のレコード群を格納するページ領域をディレクトリから
アドレスリンクすることにより、モジュール単位のレコ
ード群を、ページという範囲で近接配置することが可能
となる。

【００１５】しかし、この方法では、全てのレコード
は、モジュール毎、即ちディレクトリ毎にアドレスリン
クされたページ、及びページ内に格納されたレコードに
対してしかアクセスできない、即ち、ディレクトリを介
してしかアクセスできない。ＲＤＢＭＳのようなリレー
ションを通したレコードのアクセスはできない。また、
ディレクトリ上でページアドレスリンクで表現する以
上、レコードを格納したページ自体の（ページ同士の）
近接配置は、困難である。せいぜい、直前のページ領域
に近接させるぐらいしかできない。

【００１６】したがって、モジュール単位情報が複数ペ
ージにまたがり、頻繁なレコードの挿入と削除に伴うペ
ージの挿入、削除が行われると、ページ自体の格納場所
が離散してしまう。

【００１７】上記の従来のファイル格納技術を纏める
と、図２９のように整理される。これらいずれの技術に
おいても、既に説明し、図３０に示すように二次記憶装
置１へのデータ格納の際に、格納位置が分散しがちとな
る。したがって、二次記憶装置１へのアクセス回数が多
くなり、アクセス時間の増大に繋がる。

【００１８】上記の従来の技術に鑑みて、本出願人によ
り先にリレーション間の関係に基づいた近接格納を行う
クラスタリングについて提案している（特開平６−１１
０７４４号、対応米国出願No. １２９，８５３）。

【００１９】この先に提案した方法は、データの一様な
型（ｔｙｐｅ）、或いはクラス（ｃｌａｓｓ）に着目し
て近接関係を導き出す方法である。データ種類毎に一括
して主記憶装置に読み込んで、大量の計算を伴うような
データ処理（回路設計ＣＡＤにおけるシュミレーション
や回路合成）のデータ管理に向いている。

【００２０】しかし、部品のライブラリ情報のように、
データの実体毎に局所的にアクセスを要する場合には、
本方法においても十分ではなく親となる部品のレコード
毎に従属しあう、ポーション、ピンといった子レコード
の纏まりというような、更に細かいクラスタリングが要
求される。

【００２１】

【発明が解決しようとする課題】したがって、本発明の
目的は、前記従来の欠点を排除する斬新、且つ有用なデ
ータベース用ファイル格納管理システムを提供すること
にある。

【００２２】更に本発明の目的は、データの実体（ｉｎ
ｓｔａｎｃｅ）として個々のモジュール性に着目して近
接格納を管理するクラスタリング方法を用いるデータベ
ース用ファイル格納管理システムを提供することにあ
る。

【００２３】又、本発明の目的は、モジュール単位とな
るレコード群を格納したページに関するクラスタリング
を高度に実現するデータベース用ファイル格納管理シス
テムを提供することにある。

【００２４】更に又、本発明の目的は、データの型に対
する集合を表したリレーション毎のアクセスを可能とし
ながら、データ個々の実体を表すレコード間の親子関係
に応じて、データ格納ファイル内に互いに近接して編成
させるデータベース用ファイル格納管理システムを提供
することにある。

【００２５】本発明の更なる目的は、以下の図面に基づ
く実施例の説明及び特許請求の範囲の記載から明らかと
なる。

【００２６】

【課題を解決するための手段及び作用】本発明の上記目
的を達成するデータベース用ファイル格納管理システム
は、複数リレーションに所属するデータを格納するレコ
ードを管理するデータベース用ファイル格納管理システ
ムにおいて、リレーション間のモジュール性を表す従属
関係の情報を格納するリレーション定義ファイルと、リ
レーションに所属するデータレコードをページ単位に格
納するデータページファイルと、リレーション及びモジ
ュールに所属したレコードを格納すると共に、有効レコ
ードとして再利用される０個以上の空きレコード領域を
持ち、空きページは何らレコードを持たず、ページ単位
に再利用されるデータページと、空きページのデータペ
ージファイル内での所在情報をある特定のページ数単位
に表したページマップ情報を格納するページマップファ
イルと、各ページマップ情報毎の空きページ数を格納す
るメタマップファイルを有する。

【００２７】且つ、該リレーション定義ファイルと該デ
ータページファイルを管理し、リレーション間の従属関
係の情報と、モジュール毎の、モジュール単位に包含さ
れるリレーション毎の空きレコードの探査開始情報とモ
ジュールに所属するページの含まれる、各ページマップ
情報毎に、ページマップ情報の識別、データページ数、
及びリレーション毎のページ存在有無と空きレコード存
在有無を表す情報を表すページマップの一覧情報であ
る、ディレクトリ情報とを管理する従属関係管理手段
と、該データページファイルを管理するデータページ管
理手段と、該ページマップファイルを管理するページマ
ップ管理手段と、該メタマップファイルを管理するメタ
マップ管理手段とを有し、該従属関係管理手段、該デー
タページ管理手段、該ページマップ管理手段、該メタマ
ップ管理手段を操作し、リレーション及びモジュールに
所属したレコードに対する挿入（ｉｎｓｅｒｔ）、削除
（ｒｅｍｏｖｅ）、モジュール単位のレコードの主記憶
上への読み込み（ｌｏａｄ）、更にリレーションを通し
たレコード単位の読み込み（ｓｃａｎ）を実行するレコ
ード操作手段を有して構成される。

【００２８】かかる構成により、ページマップ情報と、
モジュール単位にページマップとの対応情報を管理した
ディレクトリ情報を利用することにより、モジュール単
位のレコードを格納したページを高レベルでクラスタリ
ングすることが可能である。

【００２９】これにより、モジュール単位のレコードを
高速に主記憶上に読み込むことが可能となる。更に、デ
ィレクトリ情報を伴わずに、ページマップ情報内のペー
ジ毎に対応するリレーションの識別により、リレーショ
ンを通したデータレコードを走査される。

【００３０】

【実施例】図１は、本発明のデータベース用ファイル格
納システムの原理構成図である。以下、図において、同
一または類似のものには、同一の参照番号及び記号を付
して説明する。ここで、本発明の理解のために、先に本
発明の原理とクラスタリングの概念について説明を行
う。

【００３１】図２〜図９は、部品としてのＩＣを例とし
て、クラスタリングを説明する図である。図２は、ＩＣ
部品（Ｑｕａｄ２−ＩｎｐｕｔＮＡＮＤＧａｔｅ
ｓ）を一例とするクラスタリングの概念を説明する図で
ある。

【００３２】図２に示すような、ＩＣ部品を考えると、
４つのＩＣ素子ＩＣ１〜ＩＣ４と、それぞれのＩＣ素子
が３つの信号ピンを有する形で、計１２個の信号ピンに
より成り立っている。

【００３３】したがって、図３に示すように、４つのＩ
Ｃ素子ＩＣ１〜ＩＣ４をポーションと呼び、順にポーシ
ョン番号１〜４が付され、且つピン構成として、ポーシ
ョン番号１には、ピン番号１Ａ、１Ｂ、１Ｙが、ポーシ
ョン番号２には、ピン番号２Ａ、２Ｂ、２Ｙが、ポーシ
ョン番号３には、ピン番号３Ａ、３Ｂ、３Ｙが、そして
ポーション番号４には、ピン番号４Ａ、４Ｂ、４Ｙが対
応づけられる。

【００３４】このようなデータに基づき、先に本出願人
が提案したクラスタリングの方法では、ＩＣ部品を一つ
の部品と考え、データの一様な型（ｔｙｐｅ）、或いは
クラス（ｃｌａｓｓ）に着目してデータ種類毎に一括し
て主記憶装置に読み込むようにしている。この場合、図
４に示すようなデータ配列となる。

【００３５】しかし、図４に示すようなデータ配列で
は、あるポーションを要素として、これにリンクするデ
ータ（ピンデータ等）にアクセスしようとする場合、他
のポーションとリンクするデータをも参照することにな
り、オーバーヘッドが大きくなる。

【００３６】これに対し、本発明によるクラスタリング
では、図５に示すように、モジュールの実体（ｉｎｓｔ
ａｎｃｅ）をベースとしている。即ち、ＩＣ部品を一つ
の部品として纏めずに、これを構成する複数の部品１〜
部品ｉ、図２に示す部品の例ではＩＣ素子ＩＣ１〜ＩＣ
４をそれぞれ別のものとして分類し、具体的には、素子
（ポーション）１〜４というように分類している。

【００３７】このようにすることにより、本発明により
データの実体（ｉｎｓｔａｎｃｅ）の個々のモジュール
性に着目して近接格納を管理することが可能となる。

【００３８】図６は、更にモジュール性に着目して近接
格納されるデータのリレーション間の従属関係の定義を
説明する図である。リレーション定義テーブルとして、
リレーション名、リレーション番号、親リレーション番
号が定義される。

【００３９】図６において、網かけ部は、ディレクトリ
であり、その下にディレクトリ単位が従属する。例え
ば、部品ディレクトリに部品ピン、ポーション及び特性
値のディレクトリ単位が従属する。

【００４０】リレーション番号は、親識別であり、親リ
レーション番号は、親への識別である。従って、部品デ
ィレクトリのリレーション番号０１とその下のディレク
トリ単位である部品ピン、ポーション及び特性値の親リ
レーション番号０１が一致し、これらの間でリレーショ
ンが関連付けられ、図７に示す関係が得られる。

【００４１】また、シンボルディレクトリの下にディレ
クトリ単位であるシンボルピンが図８のように示され
る。更に、この時シンボルピン間の接続は、ネットディ
レクトリと経路ディレクトリ単位により、ネット番号に
対応して接続されるポーションとシンボルピンとの対応
関係が図９に示される。

【００４２】図１に戻り、説明すると、１は、二次記憶
装置を表し、データベースをリレーション定義ファイル
１０、データページファイル２０、ページマップファイ
ル３０及びメタマップファイル４０として格納する。

【００４３】二次記憶装置１のリレーション定義ファイ
ル１０には、図６において説明したリレーション間のモ
ジュール性を表す従属関係の情報が格納される。

【００４４】データページファイル２０には、リレーシ
ョンに属するデータレコードをページ単位に格納し、ペ
ージマップファイル３０は、データページと空きページ
のデータページファイル２０内での所在情報を、ある特
定のページ単位に表したページマップ情報を格納する。

【００４５】更に詳しくは、データページファイル２０
は、リレーション及びモジュールに属したレコードを格
納するとともに、有効レコードとして再利用される空き
レコード領域を有し、空きページは何らレコードを持た
ず、ページ単位に再利用されるものである。

【００４６】メタマップファイル４０は、各ページマッ
プ毎のページ空き状態として、空きページ数を格納す
る。

【００４７】一方、演算処理装置２内では、機能として
従属関係即ち、モジュール間リレーションの管理手段１
１を有し、リレーション定義ファイル１０とデータペー
ジファイル２０を管理し、図６に示したようなリレーシ
ョン間の従属関係の情報１０１とディレクトリ情報１０
２を管理する。

【００４８】ディレクトリ情報１０２は、モジュールに
属するリレーション毎の空きレコードの探査開始ページ
アドレス１１２と、モジュールに属するページの含まれ
るページマップの一覧情報を表し、ページマップ一覧情
報は、各ページマップ毎に、ページマップのアドレス、
データページ数及びリレーション毎のページ存在有無と
空きレコード存在有無の情報１２２を表す。

【００４９】データページ管理手段２１は、データペー
ジファイル２０を管理し、ページマップ管理手段３１
は、ページマップファイル３０を管理し、メタマップ管
理手段４１は、メタマップファイル３０を管理する。

【００５０】レコード操作手段５０は、モジュール間リ
レーション管理手段１１、データページ管理手段２１、
ページマップ管理手段３１及びメタマップ管理手段４１
を操作し、リレーション及びモジュールに属したレコー
ドに対する挿入（ｉｎｓｅｒｔ）５１、削除（ｄｅｌｅ
ｔｅ）５２、主記憶上への読み込み（ｌｏａｄ）５３、
更にリレーションを通したレコードの読み込み（ｓｃａ
ｎ）５４を実行する。また、上記各処理の実行に対し、
共通にモジュールの割り付け（ｌｏｃａｔｅ）処理５５
の処理が行われる。

【００５１】上記構成において、本発明は、ページマッ
プファイル２０からのページマップ情報と、リレーショ
ン定義ファイル１０に格納される図６に示す如き、ペー
ジマップとの対応情報を管理するディレクトリ情報を利
用する。これにより、モジュール単位のレコードを格納
したページを高度にクラスタリングすることが可能であ
る。

【００５２】したがって、モジュール単位のデータレコ
ードを高速に主記憶上に読み込むことができる。更に、
ディレクトリ情報を伴わずに、ページマップ情報内のペ
ージ毎に対応するリレーションの識別により、リレーシ
ョンを通したデータレコードを操作することも出来る。

【００５３】図１０は、本発明システムの実施例ブロッ
ク図である。図１０においては、図１の原理構成図に対
し、ディスプレィ装置３とキーボード装置４を備えた応
用処理部６０が部品情報のデータベースをアクセスする
例を示している。

【００５４】更に、実施例として演算処理装置２内に、
レコード操作５０の際に用いられるＲｉｄ（レコードｉ
ｄ：データデース上でのレコードアドレス）識別回路６
１及びレコードバッファメモリ６２を有している。

【００５５】又、実施例として、データベースを構成す
るファイルは、リレーション定義、データページ、ペー
ジマップ及びメタマップであり、それぞれ図１において
説明したように、二次記憶装置１の対応するファイル格
納部即ち、リレーション定義ファイル１０、データペー
ジファイル２０、ページマップファイル３０及びメタマ
ップファイル４０に格納される。

【００５６】そして、リレーション定義ファイル１０に
おけるリレーション定義は、データの種類（テーブルの
型）毎のリレーション自身とリレーション間の制御関係
即ち、リレーションｉｄ（識別記号）、レコード長、親
リレーションｉｄ、従属する子リレーション数等を含
む。

【００５７】データページファイル２０は、応用処理の
必要とするデータのレコードを格納する。ファイルは、
物理的な入出力の単位となるページで分割されている。
同一ページには一種類のリレーションに所属するレコー
ドのみ格納される。

【００５８】ページマップファイル３０は、前記データ
ページファイルを構成するページ単位の空き／使用の情
報を管理する。空き／使用されるリレーションｉｄ、従
属関係を表す親レコードのＲｉｄ、空きレコード情報
（空きレコード数）を複数ページでページマップをグル
ープ化する。例えば、１ページマップ当たり４ページと
する。メタマップファイル４０は、前記のページマップ
毎のページ空き状態として空きページ数を管理する。

【００５９】ここでメタマップ、ページマップとデータ
ページの関係について具体的に説明する。図１１は、メ
タマップ、ページマップとデータページの関係を一例と
して示す図である。

【００６０】図１１（３）に示されるデータマップに
は、ディレクトリに親レコード（例として部品単位）、
及び親レコード毎の従属する子レコードの情報をテーブ
ルで有する。

【００６１】例えば、部品１のディレクトリに、従属す
る（リレーションを有する）子レコードとしてデータペ
ージアドレス１〜４に（ピン、ピン、特性値及びポーシ
ョン）が格納されていること示している。

【００６２】また、図１１（２）に示されるページマッ
プには、データページの情報及び空きレコード情報を有
している。例えば、ページマップアドレス１には、デー
タページアドレス１〜４が関係付けられ、ディレクトリ
である親レコードのｉｄ（部品：１）、リレーションを
有する子レコードのｉｄ（ピン：１、ピン：１、特性
値：３、ポーション：２）及び空きレコード情報（全て
０）が示される。空きレコード情報は、空きレコード数
または空きレコードサイズで表される。

【００６３】更に、図１１（１）に示されるメタマップ
には、ページマップアドレス毎の空きページ数が表され
ている。即ち、図１１（２）との比較により理解容易の
ように、例えばページマップアドレス１は、空きページ
が０、ページマップアドレス２は、空きページが１であ
ることが示される。

【００６４】図１２は、ディレクトリのデータ構造を示
している。ディレクトリのデータ〔図１２（１）〕とし
て、メンバーリレーション数（Ｒ）、リレーション情
報、空きレコード管理情報、使用ページマップ数（Ｐ）
及びページ所在管理情報が含まれる。

【００６５】リレーション情報は、図１２（２）に示さ
れるようにメンバーリレーション数分のリレーションの
リレーション定義情報を有し、各々のリレーション定義
情報は、図１２（３）に示されるように、リレーション
定義、親リレーション番号及びメンバーリレーション数
を含み、これらは、ページマップから得られる。

【００６６】空きレコード管理情報は、図１２（４）に
示されるようにメンバーリレーション数分の空きページ
探査位置を有する。

【００６７】ページ所在管理情報は、図１２（５）に示
されるように使用ページマップを有する。各々の使用ペ
ージマップは、図１２（６）に示されるようにページマ
ップアドレス、使用ページ数、使用ページ所在マスク及
び空きレコードマスクを有する。

【００６８】図１３は、本発明システムの全体の実施例
動作フローである。先ずシステムの初期化において、リ
レーション定義ファイル１０からリレーション定義の読
み込みが行われる（ステップＳ１）。

【００６９】次に、全ての編集作業の終了受付までディ
レクトリ単位即ち、ある特定部品に対する処理が行われ
る（ステップＳ２）。このディレクトリ単位の処理（ス
テップＳ２）において、先ずディレクトリ識別名と編集
対象テーブルがキーボードより入力される（ステップＳ
３）。これにより、１種類のリレーション、複数種類の
リレーション、全ての子リレーション（ポーション、ピ
ン、特性値）が選択される。

【００７０】更に、図１３の動作フローにおいて、レコ
ードの読み込み（ｓｃａｎ）処理により集合条件で全メ
ンバーのあるリレーションデータを検索する（ステップ
Ｓ４）。ついで、割り付け（ｌｏｃａｔｅ）処理により
データの割り付けを行う（ステップＳ５）。

【００７１】また、一つのテーブルの編集のための１リ
レーションのモジュール単位の読み込み、複数のテーブ
ルの編集のための複数リレーションのモジュール単位の
読み込みあるいは、全テーブルの編集のための全リレー
ションのモジュール単位の読み込み（ｌｏａｄ）処理が
行われる（ステップＳ６）。

【００７２】更に、編集の過程においてディスプレィに
内容が表示される（ステップＳ７）。また、ディレクト
リ単位の編集終了受付までレコード操作が行われる（ス
テップＳ８）。レコード操作の過程で最新状態が反映さ
れディスプレイに表示される（ステップＳ９）。

【００７３】レコード操作（ステップＳ８）において、
キーボードよりレコード単位のコマンドが入力され（ス
テップＳ１０）、入力されるコマンドに応じ、追加（ｉ
ｎｓｅｒｔ）処理（ステップＳ１１）又は、削除（ｒｅ
ｍｏｖｅ）処理（ステップＳ１２）が行われる。

【００７４】次に、上記説明におけるレコードの読み込
み（ｓｃａｎ）処理、割り付け（ｌｏｃａｔｅ）処理、
モジュール単位の読み込み（ｌｏａｄ）処理、追加（ｉ
ｎｓｅｒｔ）処理及び削除（ｒｅｍｏｖｅ）処理を更に
説明し、本発明システムの特徴を更に明らかにする。

【００７５】レコードの読み込み（ＳＣＡＮ）処理：図
１４は、レコードの読み込み（ＳＣＡＮ）処理のフロー
である。レコードの読み込み（ＳＣＡＮ）処理は、リレ
ーションの親子関係に関わらず、同一リレーションの全
レコードを走査する。即ち、全ページマップ数分のペー
ジマップ単位に処理が行われる（ステップＳ２０）。

【００７６】メタマップ（図１１参照）より空きページ
マップか否かを判断し、空きページマップである場合
は、次のメタマップを参照する（ステップＳ２１）。

【００７７】空きページマップでない場合は、ページマ
ップ内の全ページ数をページ単位で処理する（ステップ
Ｓ２２）。ページ単位の処理において、該当のリレーシ
ョンページか否かを判断し、該当のリレーションページ
でない場合は、次のページマップの処理に移行し、該当
のリレーションページである場合は、有効レコード数分
をレコード単位に処理を行う（ステップＳ２３）。

【００７８】このレコード単位の処理において、レコー
ドの内容とキー内容を比較する（ステップＳ２３１）。
比較処理（ステップＳ２３１）おいて、条件が一致する
時、後処理（ＰＯＳＴＰＲＯＣ）が行われる（ステッ
プＳ２３２）。後処理（ＰＯＳＴＰＲＯＣ）におい
て、レコード数を＋１し、レコード内容を応用処理（Ａ
／Ｐ）領域（図１０：６０）に格納する。

【００７９】図１５は、レコードの読み込み（ＳＣＡ
Ｎ）処理の過程におけるデータベースの具体的状態であ
る。図１５において、図中の記号は次のように定義され
る。

【００８０】Ｐ：ページマップ、ＥＰ：空きページ数、
ＤＰ：データページ、ＤＩ：親レコード／Ｒｉｄ、Ｅ
Ｒ：空きレコード情報Ｒ：リレーションｉｄ＝R1．ピン，R2. ポーション, R
3. シンボルネット, R4. ネット，R5. 特性値図１５は、メタマップから有効ページが存在するペー
ジマップを決定されることを示す。図１５は、ページ
マップで抵抗Ｒが一致したレコードを絞り込む状態を示
す。

【００８１】図１５は、絞り込んだレコードを応用処
理（Ａ／Ｐ）６０のコールバックルーチンに渡し、比較
処理（ステップＳ２３１）を行う状態を示す。

【００８２】図１５は、次いで条件の一致したレコー
ドを応用処理（Ａ／Ｐ）６０のコールバックルーチンに
渡し、後処理（ステップＳ２３２）を行う状態を示す。

【００８３】図１６は、モジュールの割り付け（ｌｏｃ
ａｔｅ）処理のフローである。応用処理部６０から親レ
コードを識別するリレーションｉｄ（Ｒｉｄ）を与えら
れる。したがって、演算処理部５０でこのＲｉｄに基づ
き、リレーション定義ファイル１９から対応のディレク
トリ情報の読み込みを行う（ステップＳ３０）。この
時、ディレクトリ情報の読み込みは、Ｒｉｄをキーにし
たり、又は直接親レコード自身と結合させて行う。

【００８４】ここで、前記の親レコードを識別するリレ
ーションｉｄ（Ｒｉｄ）より、親レコードのリレーショ
ンｉｄが分かり、リレーション定義によりリレーション
の親子関係が分かる。即ち、Ｒｉｄ→ページアドレス→
ページマップの手順により、リレーションｉｄ→リレー
ション定義の関係からリレーションの親子関係が求めら
れる。

【００８５】ついで、リレーションの親子関係により、
ディレクトリ情報（図１２参照）について、子リレーシ
ョン毎の子リレーション毎の空きレコード探査開始ペー
ジ・アドレスの配列の順番、更に、使用ページマップ一
覧内のページ存在マスク、空きレコード存在マスクのビ
ットの順番と、子リレーションｉｄとの対応が付けられ
る。

【００８６】図１６に戻り、ディレクトリ情報の読み込
み（ステップＳ３０）が行われ、前回のディレクトリ情
報が存在する場合は、ディレクトリ情報の交換（スワッ
プ）を行う（ステップＳ３１）。ディレクトリ情報の交
換（スワップ）において、以前の別ディレクトリ情報の
退避（ステップＳ３１１）を行い、又今回のディレクト
リ情報の読み込み（ステップＳ３１２）を行う。

【００８７】更に、前回のディレクトリ情報が存在しな
い時は、ディレクトリ情報の作成を行う（ステップＳ３
２）。ディレクトリ情報の作成において、ディレクトリ
情報が新規の場合は、初期化クリアし（ステップＳ３２
１）、そうでなければ読み込んだディレクトリ情報を転
写する（ステップＳ３２２）。

【００８８】一方、親子関係の設定（ステップＳ３２）
は、レコード識別によりページアドレスを求める（ステ
ップＳ３２１）。更に、当該ページアドレスのページマ
ップによりレコード識別のリレーション識別を求める
（ステップＳ３２２）。

【００８９】ついで、リレーション定義数分のリレーシ
ョン定義単位処理を行う（ステップＳ３２３）。この処
理において、リレーション識別が当該リレーション識別
と一致するかを判断し、一致しない場合、ディレクトリ
情報に子リレーション定義を設定する（ステップＳ３２
４）。

【００９０】図１７は、モジュール単位の読み込み（ｌ
ｏａｄ）処理のフローである。図１８乃至図２１は、モ
ジュール単位の読み込み（ｌｏａｄ）処理におけるデー
タベース上の具体的状態を示す関係図である。

【００９１】モジュール単位の読み込み（ｌｏａｄ）処
理は、レコードの読み込み（ｓｃａｎ）処理と異なり、
割り付け（ｌｏｃａｔｅ）処理で特定された親レコード
に所属するレコードのみを読み込みの対象とする。読み
込み対象となるリレーションの種類として、１種類、複
数種類、又は親子関係になる全ての読み込みを選択す
る。

【００９２】読み込み対象レコードを格納するページ
は、ディレクトリのページマップ一覧より特定する。読
み込み対象リレーションに応じて子リレーション毎のペ
ージ存在マスクにより調べるべきページマップを特定す
る。また、読み込み対象となるリレーション毎のビット
をオン（１）とし、それらを読み込み対象リレーション
分について論理和（ＯＲ）をとったビットマスクと、ペ
ージマップ一覧毎のページ所在マスクとの論理積（ＡＮ
Ｄ）の結果が、全て０以外のページマップと判断する。

【００９３】更に、ページマップ内での読み込み対象ペ
ージの絞り込みには、リレーションｉｄと共に、親レコ
ードｉｄとの一致も調べる。

【００９４】上記説明に基づき、図１７に戻ると、先ず
ディレクトリへの割り付け（ｌｏｃａｔｅ）が行われる
（ステップＳ４０）。ついで、全リレーションが対象で
ない場合、照合用リレーションマスクが作成される（ス
テップＳ４１）。

【００９５】この時、上記の説明の通り、対象リレーシ
ョンの対応ビットをオン（１）とする。複数リレーショ
ンの時は、各リレーションの論理和（ＯＲ）で作成す
る。更に、全リレーションの時は、対象リレーションの
対応ビットを全てオン（１）とする。

【００９６】更に、図１７において、全リレーションが
対象である場合は、ページマップ単位に、ページ所在管
理が処理される（ステップＳ４２）。このページ所在管
理処理において、対象リレーションがない場合（ページ
所在管理のページ所在マスクと照合マスクの論理積（Ａ
ＮＤ）をとり全て０とする場合）、次のページ所在管理
を処理する。

【００９７】対象リレーションがある場合は、ページマ
ップ内のページ単位にページマップ内ページ数分のモジ
ュールの読み込み（ｌｏａｄ）処理（ステップＳ４２
２）を行う。このモジュールの読み込み（ｌｏａｄ）処
理により、当該メンバーのページに対し、データページ
アドレスにより、データページをデータファイルより有
効レコード数分読み込まれる。

【００９８】ここで図１８乃至図２１を参照する。図１
８乃至図２１において、共通に使用される記号は、次の
ように定義される。

【００９９】ＤＩ：ディレクトリＰＭＡＰ：ページマ
ップＤＰ：データページＲＭＳＫ：使用ページ所在マスクＲ：リレーションｉ
ｄ（図１１参照）図１８は、図６乃至図９を参照した場合のページ所在の
概略全体表である。使用ページ所在マスクＲＭＳＫは、
リレーション番号に対応してビットが１又は０のビット
がたてられる。

【０１００】図１９は、ページマップの全体表であり、
各ページマップＰＭＡＰに対して、データページＤＰ及
びリレーションｉｄが記される。

【０１０１】図２０は、図５乃至図８を参照した時のモ
ジュールの読み込みの内容を示す図である。図２０
（１）は、ディレクトリレーション・部品についてのロ
ードの内容であり、図２０（２）は、ディレクトリレー
ション・シンボルについてのロードの内容であり、図２
０（２）は、ディレクトリレーション・ネットについて
のロードの内容である。

【０１０２】更に図２１は、データページを示し、ペー
ジマップ対応にデータページＤＰ及びリレーションｉｄ
がテーブル化されている。

【０１０３】図２２は、挿入（ｉｎｓｅｒｔ）処理のフ
ローである。ここで、挿入（ｉｎｓｅｒｔ）処理は、デ
ィレクトリへの位置づけが行われる（ステップＳ５０）
と、大きくは、レコードの割り当て先ページの決定処理
（ステップＳ５１）と、その決定されたページ内へのレ
コード割り当ての処理（ステップＳ５２）で構成され
る。

【０１０４】レコードの割り当て先ページの決定（ステ
ップＳ５１）は、既に割り当てられている既存のページ
の中から空きレコード領域を探査する場合（ステップＳ
５１１）と、既存ページに空きレコードがない場合に新
規ページを割り当てる場合（ステップＳ５１６）とに別
れる。

【０１０５】既存のページの中から空きレコード領域を
探査する場合（ステップＳ５１１）は、空きレコード管
理の空きレコード探査開始アドレスからページマップア
ドレスを求め（ステップＳ５１２）、ぺージ所在数分、
ページマップ単位に処理される（ステップＳ５２３）。

【０１０６】そして、このページマップ単位に処理にお
いて、当該リレーションにおいて、空きレコードがあ場
合、最初のレコド探査開始アドレスの直前までページマ
ップ内でページチェックを行う。このページチェックで
当該リレーションで空きデータがある時、データページ
アドレス（ページｉｄ）を割当て対象とする。

【０１０７】一方、新規ページの割当て（ステップＳ５
１６）処理は、新規ページを割り当てる先のページマッ
プの決定（ステップＳ５１７）と、ページマップ内への
ページ割当ての処理（ステップＳ５２０）で構成する。

【０１０８】更に、割り当てる先のページマップの決定
（ステップＳ５１７）は、現在使用中の既存のページマ
ップ一覧より決定する（ステップＳ５１８）か、使用中
のページマップに空きページがない場合にメタマップよ
り新規のページマップを調べる場合（ステップＳ５１
９）に分かれる。

【０１０９】ページ内へのレコード割当ての処理（ステ
ップＳ５２）では、当該ページに対応するページマップ
のページ単位情報の空きレコード情報を更新する（ステ
ップＳ５２１）。

【０１１０】そして、今回のレコード挿入で、当該ペー
ジに空きレコード領域が無くなった場合、ページマップ
上に当該リレーションｉｄと当該親レコードのＲｉｄを
持つ全てのページについて空きレコードが無くなった場
合（当該ページマップ上の全てのページ単位情報を調べ
ることにより判断）、ページマップ一覧の当該ページマ
ップにおける当該リレーションに対する空きレコード存
在マスクをオフ（０）にする（ステップＳ５２２）。

【０１１１】次に、挿入（ｉｎｓｅｒｔ）処理（図２２
のフロー）における各場合について更に詳細に説明す
る。

【０１１２】図２３は、挿入（ｉｎｓｅｒｔ）処理にお
いて、既存ページの中から空きレコード領域を探査する
場合（ステップＳ５１１：図２２参照）の例を示す。図
２３において使用される記号の定義は、次の通りであ
る。

【０１１３】ＰＭＡＰ：ページマップＲＥ：空きレコ
ード管理ＰＥ：ページ所在管理ＤＰ：データページＲ：リレーションＥＲ：空きレ
コード情報ＰＭＳＫ：ページ存在マスクこの処理は、ディレクトリ情報を基に、ページマップ一
覧からページマップ、次いで既存ページの順に、空きレ
コード領域を持ちうる既存ページを探査していく。常に
ページマップ一覧の先頭から調べるのでは、レコードが
フル状態になっている場合には効率が悪い。

【０１１４】そこで、子リレーション毎の空きレコード
探査開始ページアドレスから最初に調べるべきページマ
ップを決定する。ページマップ一覧には、子リレーショ
ン毎に対応したビットで表現される空きレコード存在マ
スクにより、当該ページマップ内に空きレコードを持つ
ページの有無を知ることが出来る。

【０１１５】探査開始すべきページマップからページマ
ップ一覧を調べ、ページマップ一覧の最後に達したら、
ページマップ一覧の先頭より逆上り元の探査開始ページ
マップの直前のページマップまでを調べる。

【０１１６】このビットマスクにより、当該ページマッ
プ内からレコード割当て対象となるリレーションｉｄを
持ち、当該親レコードｉｄを且つ空きレコードを持つペ
ージを探査することにより、レコード割り当てとなる既
存ページが決定される。

【０１１７】ページを割り当てるべき既存ページが決定
されたら、最終的に空きレコード探査開始ページアドレ
スをそのページのアドレスに更新する。これにより、次
回の挿入（ｉｎｓｅｒｔ）処理でも、そのページアドレ
スより探査される。

【０１１８】図２４は、挿入（ｉｎｓｅｒｔ）処理の新
規にページを割り当てるべきページマップの決定におい
て、現在使用中のページマップ一覧より決定する（ステ
ップＳ５１６：図２２参照）例を示している。図２４に
おいて使用される記号の定義は、図２３と同じものは、
同じ定義であり、図２４で始めて現れる記号の定義は、
次の通りである。

【０１１９】ＭＭ：メタマップＤＩ：親レコードＥ
Ｐ：空きページ数ＵＰ：使用ページ数この処理は、本発明の中心となる部分であり、互いに関
連し合うレコード群を格納するページをページマップと
いう単位で互いに近接配置させ、且つそのページが配置
されるべき物理的なグループき範囲を表すページマップ
そのものも極力分散しないようにページを割り当てるペ
ージマップを決定する。

【０１２０】先ず使用中のページマップ一覧より、ペー
ジを割り当てるべきページマップを決定するのに、少な
くとも空きページがあるページマップでなければならな
い。この条件は、メタマップを参照することにより、実
際のページマップ内のページ単位情報をアクセスするこ
となく分かる。

【０１２１】次に、空きページを持つページマップの
内、各ページマップ毎の使用ページ数が大きいものも選
択する。このことは、レコード操作の挿入（ｉｎｓｅｒ
ｔ）処理、削除（ｒｅｍｏｖｅ）処理に伴うページの割
り当て、開放が繰り返されるのに伴い、過疎なページマ
ップが除外され、ページ割り当て対象となるページマッ
プが過疎化することに繋がる。

【０１２２】図２４において、（ａ）、（ｂ）は、それ
ぞれメタマップ、ページ所在管理であり、メタマップよ
り空きページ数のあるページ所在管理を絞り込む（図２
４の参照）。

【０１２３】ページマップの７、８に空きページ数が１
ずつあり、これに絞りこまれる。次に絞り込み後のペー
ジ所在管理について、最も使用ページ数の多いページ所
在管理を決定ページとする。図２４では、使用ページ数
が３であるページマップの８ページを決定ページとする
（図２４の）。

【０１２４】これに基づき、検索前のページマップの８
ページ（図２４のｃ）を更新する（図２４の）。図に
おいては、編みかけ部分（図２４のｄ）が更新される。
次いで、メタマップとページ所在管理の更新が、それぞ
れ図２４のｅ、ｆの網かけ部分のように行われる（図２
４の）。

【０１２５】図２５は、挿入（ｉｎｓｅｒｔ）処理の新
規にページを割り当てるべきページマップの決定におい
て、現在使用中のページマップ一覧からではなく、空き
ページを含むページマップより決定する例（ステップＳ
５１９：図２２参照）である。図２５において使用され
る記号の定義は、図２４におけると同じである。

【０１２６】先ずメタマップＭＭより空きページ数のあ
るページ所在管理ＰＥを絞り込む（図２５の）。全く
空きページが存在しない場合は、メタマップＭＭより空
きの存在するページマップを探しだす。図２５のの例
では、空きページ２を持つページマップを検索する。そ
して、図示のような検索前のページマップをページマッ
プ５について、検索後の変更を図示のように行う（図２
５の）。

【０１２７】その後、図しされるように、メタマップＭ
Ｍとページ所在管理ＰＥにページマップの５を新規追加
して更新する（図２５の）。

【０１２８】尚、上記の場合、図２４及び図２５におい
て、ページマップ内のページ割り当ての処理では、次の
内容が行われる。

【０１２９】i）メタマップ上の（当該ページマップア
ドレスの空きページ−１）。

【０１３０】ii）更に、ディレクトリ情報の中のページ
マップ一覧の当該ページマップの配列に対し、使用ペー
ジ数＋１、リレーション毎のページ存在マスク、空きレ
コード存在マスクを共にオン（１）とする。

【０１３１】iii）ページマップ内より空きページを探
し、ページ単位情報として、リレーションｉｄ、親Ｒｉ
ｄの設定、及び空きレコード情報のリセットを行う。

【０１３２】図２６は、削除（ｒｅｍｏｖｅ）処理のフ
ローである。他の処理と同様にディレクトリの位置づけ
（ｌｏｃａｔｅ）処理Ｓ６０を行う。

【０１３３】ページ内から１件のレコードを削除し（有
効レコード−１）、ページマップ内の当該ページの空き
レコード情報を更新する（空きレコード数＋１）。

【０１３４】更に、ページ所在の当該ページマップの空
きレコードマスクをオン（１）とする。厳密には、当該
ページマップ内の当該リレーションの全てのページにつ
いて初めて空きレコードが発生した場合、すでにオン
（１）となっている場合がある。

【０１３５】削除（ｒｅｍｏｖｅ）処理は、上記のよう
にページ内から１件のレコードを削除した結果について
ケースが次のように分かれる。

【０１３６】ページ内が全て空き（有効レコードがな
い）場合（ステップＳ６１）、ページマップ内の当該ペ
ージ情報を削除し、メタマップの空きページ数を、＋１
し、ページ所在の当該ページマップに対する使用ページ
を、−１する。

【０１３７】更に、ページ所在の使用ページが空き（使
用ページ数＝０）の場合（ステップＳ６２）、ページ所
在の当該ページマップの配列を削除する。

【０１３８】また、ページマップ内に当該リレーション
のページが残っていない場合（ステップＳ６３）は、ペ
ージ所在の当該ページマップの当該リレーションに対す
るページマスク及び空きレコードマスクを共にオフ
（０）とする。

【０１３９】図２７、２８は、削除（ｒｅｍｏｖｅ）処
理において、空きが発生し、且つ当該ページマップに当
該親レコードに従属するページが残っている場合を示す
図である。図２７、２８で使用される記号の定義は、図
２５と同じ記号の他、ＲＭＳＫ：空きレコード存在マス
クが追加されている。

【０１４０】図示されるページマップＰＭＡＰ、メタマ
ップＭＭおよびページ管理所在ＰＥの状態において、削
除対象データページアドレスＤＰが２、対象リレーショ
ンが２とすると、図示のメタマップＭＭおよびページ管
理所在ＰＥの編みかけ領域が削除される。

【０１４１】即ち、削除対象データページアドレスＤＰ
よりページマップアドレス（ＰＭＡＰアドレス）を求め
る。ＣＥＩＬ（ＤＰ／Ｎ）より、ＰＭＡＰアドレス＝１
となる。そして、１ページ内の最大数は４となる。

【０１４２】図２７のケース１は、ＰＭＡＰアドレス＝
１ＫＤＰ＝２のレコードを削除した結果、ＤＰ＝２が
空きになる場合の削除後のページマップＰＭＡＰ、メタ
マップＭＭ及びページ存在管理ＰＥの状態を示してい
る。

【０１４３】更に、図２８は、ケース１に対し、更にペ
ージ所在内のページマップに対する使用データページが
全て空きになる場合の削除後のページマップＰＭＡＰ、
メタマップＭＭ及びページ存在管理ＰＥの状態を示して
いる。これは、ページマップ一覧の当該屁の配列の使用
ページ数が０になったことで判断され、ページマップ一
覧より当該ページマップの配列が削除される。ページ存
在管理ＰＥの影線部分が、削除により詰められ、配列が
減る領域を示している。

【０１４４】以上本発明の実施例において、説明してき
たようにディレクトリ情報のページマップ一覧にとい
て、リレーション毎のページの存在有無と空きレコード
の存在有無とをビットマスクで表現したが、これの代わ
りにそれぞれリレーション毎の使用ページ数、空きレコ
ードを持つページ数で管理することも可能である。

【０１４５】この場合は、ディレクトリ情報の中のペー
ジマップ一覧におけるリレーション毎のページの存在有
無と空きレコードの存在有無のビットマスクをオフ
（０）にするか否かの判断において、挿入（ｉｎｓｅｒ
ｔ）処理と削除（ｒｅｍｏｖｅ）処理で、それぞれ当該
ページマップ内の全てのページ単位情報について調べる
処理が省略できる（単に当該ページ数を−１とすること
で自ずと０となる）。

【０１４６】しかし、ディレクトリ情報のサイズが極端
に大きくなる。例えば、ページマップ毎に２５６ページ
の対応を記録するとすれば、前記リレーション毎の両ペ
ージ数は、２の８乗、即ちビット表現に比べ８倍以上の
大きさが必要である。このサイズは、従属するリレーシ
ョンの種類数、及び使用されるページマップアドレスの
数に依存して膨れ上がる。

【０１４７】更に、モジュール単位の読み込み（ｌｏａ
ｄ）処理における読み込み対処となるリレーションの存
在するページマップを選別する際のビット演算のオーバ
ーヘッドも増大するという欠点がある。

【０１４８】又、上記実施例では、リレーション間の親
子関係について、部品とそれに従属する特性値、ポーシ
ョン、ピンと言った一種類の関係のみを例として説明し
たが、同一データベース内に複数の親子関係、例えばシ
ンボルとシンボル端子、ネットと信号線の経路情報とい
った、複数の親子関係が混在してもよい。

【０１４９】これは、リレーション毎にリレーション間
の親子関係を表現でき、且つディレクトリ情報の中のリ
レーション毎の対応関係が、親リレーションの種類毎に
可変であることから容易に類推可能である。

【０１５０】更に、上記実施例では、説明の簡単化のた
めに、個々のリレーション毎のレコード長は固定長であ
り、ディレクトリ情報は、データページのファイルとは
別ノファイルに格納される例を示した。しかし、データ
ベースで可変長のレコードを格納できるように拡張する
ことは容易である（レコード毎にそのサイズを、空きレ
コード情報として残りサイズをそれぞれ付加する）。こ
れにより可変長となるディレクトリ情報を親レコードと
一体にしたり、あるいは同一ファイル内の別のレコード
として格納するように拡張することも容易である。

【０１５１】尚、上記実施例におけるリレーションを通
したレコードの読み込み（ＳＣＡＮ）及びモジュール単
位の読み込み（ｌｏａｄ）に際して、当該レコード集合
の全てについて、順次読み込んでいるが、リレーション
定義毎にスキーマ情報を管理すると共に、様々なキー値
による二次インデックス（Ｂ−ｔｒｅｅやＨａｓｈ等）
を設けることにより、ＳＱＬ仕様の柔軟な検索や、更な
る高速な検索を実現する拡張は容易である。

【０１５２】かかるいずれの拡張も本発明の保護の範囲
に入るものである。

【０１５３】

【発明の効果】上記実施例にしたがい説明したように、
本発明は、ページマップ情報と、モジュール単位にペー
ジマップとの対応情報を管理したディレクトリ情報を利
用することにより、モジュール単位のレコードを格納し
たページを高レベルでクラスタリングすることが可能で
ある。

【０１５４】これにより、モジュール単位のレコードを
高速に主記憶上に読み込むことが可能となる。更に、デ
ィレクトリ情報を伴わずに、ページマップ情報内のペー
ジ毎に対応するリレーションの識別により、リレーショ
ンを通したデータレコードを走査することもできる。

【図面の簡単な説明】

【図１】本発明の原理構成を説明する図である。

【図２】ＩＣ部品の一例を説明する図である。

【図３】クラスタリングに基づくポーションとピン構成
を説明する図である。

【図４】レコード、タップル（型／クラス）をベースと
したリレーションによるクラスタリングを説明する図で
ある。

【図５】モジュール実体（インスタンス）をベースとし
たクラスタリングを説明する図である。

【図６】リレーション間の従属関係を説明する図であ
る。

【図７】ＩＣ部品の構成を説明する図である。

【図８】シンボルピンを説明する図である。

【図９】シンボルピンの接続関係を説明する図である。

【図１０】本発明実施例システムの構成例ブロック図で
ある。

【図１１】メタマップ、ページマップ及びデータページ
の関係図である。

【図１２】ディレクトリのデータ構造を説明する図であ
る。

【図１３】本発明の実施例動作フローである。

【図１４】レコードの読み込み（ｓｃａｎ）処理フロー
である。

【図１５】レコードの読み込み（ｓｃａｎ）処理の過程
におけるデータベースの具体的状態を示す図である。

【図１６】割りつけ（ｌｏｃａｔｅ）処理のフローであ
る。

【図１７】モジュール単位の読み込み（ｌｏａｄ）処理
のフローである。

【図１８】ページ所在の概略全体表である。

【図１９】ページマップの全体表である。

【図２０】モジュール単位の読み込み（ｌｏａｄ）の状
態を説明する図である。

【図２１】データページの状態を示す図である。

【図２２】挿入（ｉｎｓｅｒｔ）処理のフローである。

【図２３】挿入（ｉｎｓｅｒｔ）処理における空きレコ
ード検索の状態を示す図である。

【図２４】挿入（ｉｎｓｅｒｔ）処理における新規ペー
ジ所在と既存ページマップの状態を示す図である。

【図２５】挿入（ｉｎｓｅｒｔ）処理におけるページ所
在のページマップ上に空きがない状態を示す図である。

【図２６】削除（ｒｅｍｏｖｅ）処理のフローである。

【図２７】削除（ｒｅｍｏｖｅ）処理における状態を示
す図（その１）である。

【図２８】削除（ｒｅｍｏｖｅ）処理における状態を示
す図（その２）である。

【図２９】従来のファイル格納技術を説明する図であ
る。

【図３０】従来技術における二次記憶装置へのデータ格
納の説明図である。

【符号の説明】

１二次記憶装置１０リレーション定義ファイル２０データページファイル３０ページマップファイル４０メタマップファイル２演算処理装置５０レコード操作５１挿入（ｉｎｓｅｒｔ）５２削除（ｒｅｍｏｖｅ）５３モジュール単位の読み込み（ｌｏａｄ）５４レコードの読み込み（ｓｃａｎ）５５割りつけ（ｌｏａｄ）１１モジュール間リレーション管理１０１リレーション情報１０２ディレクトリ管理１１２空きレコード管理１２２ページ所在管理２１データページ管理３１ページマップ管理４１メタマップ管理

Claims

【特許請求の範囲】

【請求項１】複数リレーションに所属するデータを格納
するレコードを管理するデータベース用ファイル格納管
理システムにおいて、リレーション間のモジュール性を表す従属関係の情報を
格納するリレーション定義ファイルと、リレーションに所属するデータレコードをページ単位に
格納するデータページファイルと、リレーション及びモジュールに所属したレコードを格納
すると共に、有効レコードとして再利用される０個以上
の空きレコード領域を持ち、空きページは何らレコード
を持たず、ページ単位に再利用されるデータページと、
空きページのデータページファイル内での所在情報をあ
る特定のページ数単位に表したページマップ情報を格納
するページマップファイルと、各ページマップ情報毎の空きページ数を格納するメタマ
ップファイルを有し、且つ、該リレーション定義ファイルと該データページフ
ァイルを管理し、リレーション間の従属関係の情報と、
モジュール毎の、モジュール単位に包含されるリレーシ
ョン毎の空きレコードの探査開始情報とモジュールに所
属するページの含まれる、各ページマップ情報毎に、ペ
ージマップ情報の識別、データページ数、及びリレーシ
ョン毎のページ存在有無と空きレコード存在有無を表す
情報を表すページマップの一覧情報である、ディレクト
リ情報とを管理する従属関係管理手段と、該データページファイルを管理するデータページ管理手
段と、該ページマップファイルを管理するページマップ管理手
段と、該メタマップファイルを管理するメタマップ管理手段と
を有し、該従属関係管理手段、該データページ管理手段、該ペー
ジマップ管理手段、該メタマップ管理手段を操作し、リ
レーション及びモジュールに所属したレコードに対する
挿入（ｉｎｓｅｒｔ）、削除（ｒｅｍｏｖｅ）、モジュ
ール単位のレコードの主記憶上への読み込み（ｌｏａ
ｄ）、更にリレーションを通したレコード単位の読み込
み（ｓｃａｎ）を実行するレコード操作手段を有して構
成されるデータベース用ファイル格納管理システム。
【請求項２】請求項１において、前記リレーション定義
ファイル、データページファイル、ページマップファイ
ル及びメタマップファイルは二次記憶装置に格納され、
前記従属関係管理手段、データページ管理手段と、ペー
ジマップ管理手段及びメタマップ管理手段の各々の機能
は、演算処理装置によって実行されるように構成された
ことを特徴とするデータベース用ファイル格納管理シス
テム。
【請求項３】請求項１において、前記ページマップファイルは、各ページの使用／空き状
態を表し、空きページの場合には該当ページが空いてい
る識別を、使用ページの場合には、該当ページが格納す
るデータが所属するリレーション及びモジュールの識別
を表す情報を有し、前記ページマップ管理手段は、前記レコード操作手段の
１以上のリレーションの所属するレコードの読み込みに
際して、読み込み対象となるモジュールの識別が与えら
れない場合には、当該リレーションに所属するページを
読み込み対象として選び出し、更にモジュール識別が与
えられた場合には、当該リレーションに所属すると共に
そのモジュール識別に所属するページを読み込み対象と
して選び出すように構成されたことを特徴とするデータ
ベース用ファイル格納管理システム。
【請求項４】請求項３において、前記メタマップ管理手段は、前記レコード操作手段の１
以上のリレーションに所属するレコードの読み込みに際
して、空きページだけから成るページマップ情報を除外
して、読み込み対象ページを選び出すべきページマップ
情報を選び出すように構成されたことを特徴とするデー
タベース用ファイル格納管理システム。
【請求項５】請求項３において、前記従属関係管理手段の前記ディレクトリ情報は、モジ
ュールに所属するページの含まれるページマップ情報の
アドレスの一覧情報を持ち、ページマップ一覧情報は、
各ページマップ情報毎にページマップ情報のアドレスを
持ち、該従属関係管理手段は、前記レコード操作手段のモジュ
ールに所属するレコードの読み込みに際して、読み込み
対象ページを選び出すべきページマップ情報を、前記デ
ィレクトリ情報のページマップ一覧情報のページマップ
情報の識別（アドレス）で示されるものに限定するよう
に構成されたことを特徴とするデータベース用ファイル
格納管理システム。
【請求項６】請求項５において、前記従属関係管理手段の前記リレーション間の従属関係
の情報は、モジュール単位に従属する複数リレーション
について、順序性を持ってその識別を表し、該従属関係管理手段の前記ディレクトリ情報のページマ
ップ一覧情報は、更に該従属するリレーションの順序性
に対応したページ存在有無を表す情報を持ち、該従属関係管理手段は、前記レコード操作手段のモジュ
ールに所属し、且つ１つのリレーションに所属するレコ
ードの読み込みに際して、読み込み対象ページを選び出
すべきページマップ情報を、前記ディレクトリ情報のベ
ージマップ一覧情報の内、当該リレーションのページが
存在するページマップ情報の識別（アドレス）で示され
るものに限定するように構成されたことを特徴とするデ
ータベース用ファイル格納管理システム。
【請求項７】請求項５において、前記従属関係管理手段の前記リレーション間の従属関係
の情報は、モジュール単位に従属する複数リレーション
について、順序性を持ってその識別を表し、該従属関係管理手段の前記ディレクトリ情報のページマ
ップ一覧情報は、更に前記従属するリレーションの順序
性に対応したページ存在有無を表すビット・フラグを持
ち、このビットフラグは、ページが存在する場合は１
を、存在しない場合は０を示し、該従属関係管理手段は、前記レコード操作手段のモジュ
ールに所属し、且つ複数のリレーションに所属するレコ
ードの読み込みに際して、前記従属するリレーションの
順序性に対応したビットマスクを作成し、このビット・
マスクは、当該リレーションに対応したビットに１を、
それ以外は０を表し、読み込み対象ページを選び出すべ
きページマップ情報を、該ディレクトリ情報のページマ
ップ一覧情報の内、前記リレーション毎のページ存在有
無を表すビットフラグと該リレーションに対応したビッ
トマスクの論理積（ｃｏｎｊｕｎｃｔｉｏｎ（ＡＮ
Ｄ））の結果が全て０でない（少なくとも一つのビット
が１である）、ページマップ情報の識別（アドレス）で
示されるものに限定するように構成されたことを特徴と
するデータベース用ファイル格納管理システム。
【請求項８】請求項１において、前記ページマップファイルは、各ページの使用／空き状
態を表し、空きページの場合には当該ページが空いてい
る識別を、使用ページの場合には、当該ページが格納す
るデータが所属するリレーション及びモジュールの識別
を表す情報を提供し、前記従属関係管理手段の前記ディレクトリ情報は、モジ
ュールに所属するページの含まれるページマップ情報の
アドレスの一覧情報を持ち、ページマップ一覧情報は、
各ページマップ情報毎にページマップ情報のアドレスを
持ち、前記レコード操作手段の特定モジュールに所属し、且つ
全リレーションに所属するレコードの読み込みに際し
て、該従属関係管理手段は、読み込み対象ページを選び出す
べきページマップ情報を、前記ディレクトリ情報のペー
ジマップ一覧情報のページマップ情報の識別（アドレ
ス）で示されるものに限定し、該前記ページマップ管理手段は、リレーションの識別に
関わらず、そのモジュール識別に所属するページを読み
込み対象として選び出すように構成されたことを特徴と
するデータベース用ファイル格納管理システム。
【請求項９】請求項１記載において、前記ページマップファイルは、各ページの使用／空き状
態を表し、空きページの場合には当該ページが空いてい
る識別を、使用ページの場合には、当該ページが格納す
るデータが所属するリレーション及びモジュールの識別
を表す情報を有し、前記レコード操作手段のある特定モジュールに所属し、
１つのリレーションに所属するレコードの挿入は、最初
に前記ページマップ管理手段によって、当該モジュール
と当該リレーションに所属する既存ページを探査し、そ
れらページに空きレコード領域が有ればそのページにレ
コードを挿入し、無ければ、次に前記ページマップ管理手段によって、空
きページを探査し、そのページに対応するページマップ
情報に、当該リレーションとモジュールの識別を記録
し、新規ページとして割当て、そのページにレコードを
挿入するように構成されたことを特徴とするデータベー
ス用ファイル格納管理システム。
【請求項１０】請求項９におてい前記ページマップ・フ
ァイルは、更に使用ページの空きレコード情報を持ち、前記レコード操作手段の前記レコードの挿入における既
存ページの探査に際して、前記ページマップ管理手段は、当該モジュールと当該リ
レーションに所属する既存ページを探査し、それらペー
ジに空きレコード領域が有るか否かを、実際にデータペ
ージファイルをアクセスすることなく判断するように構
成されたことを特徴とするデータベース用ファイル格納
管理システム。
【請求項１１】請求項９において、前記従属関係管理手段の前記ディレクトリ情報は、モジ
ュールに所属するページの含まれるページマップ情報の
アドレスの一覧情報を持ち、ページマップ一覧情報は、
各ページマップ情報毎にページマップ情報のアドレスを
持ち、前記レコード操作手段の前記レコードの挿入における既
存ページの探査に際して、該従属関係管理手段は、既存ページを選び出すべきペー
ジマップ情報を、前記ディレクトリ情報のページマップ
一覧情報のページマップ情報の識別（アドレス）で示さ
れるものに限定するように構成されたことを特徴とする
データベース用ファイル格納管理システム。
【請求項１２】請求項１１において、前記従属関係管理手段の前記リレーション間の従属関係
の情報は、モジュール単位に従属する複数リレーション
について、順序性を持ってその識別を表し、該従属関係管理手段の前記ディレクトリ情報のページマ
ップ一覧情報は、更に前記従属するリレーションの順序
性に対応した空きレコード探査開始情報を持ち、前記レコード操作手段の前記レコードの挿入における既
存ページの探査に際して、該従属関係管理手段は、当該リレーションに対応する前
記空きレコード探査開始情報の示す位置（一覧配列の位
置）からその直前までについて逐次、前記ディレクトリ
情報のページマップ一覧情報のページマップ情報の識別
（アドレス）で示されるページマップ情報に限定して、
既存ページを選び出すべきページマップ情報を限定して
いくように構成されたことを特徴とするデータベース用
ファイル格納管理システム。
【請求項１３】請求項１１において、前記従属関係管理手段の前記リレーション間の従属関係
の情報は、モジュール単位に従属する複数のリレーショ
ンについて、順序性を持ってその識別を表し、該従属関係管理手段の前記ディレクトリ情報のページマ
ップ一覧情報は、更に前記従属するリレーションの順序
性に対応した空きレコード存在有無を示す情報を持ち、前記レコード操作手段の前記レコードの挿入における既
存ページの探査に際して、該従属関係管理手段は、既存ページを選び出すべきペー
ジマップ情報を、前記ディレクトリ情報のページマップ
一覧情報のページマップ情報の識別（アドレス）で示さ
れるものの内、更に当該リレーションに対応する前記空
きレコード存在有無情報に基づいて、空きレコードの存
在するページマップ情報を限定するように構成されたこ
とを特徴とするデータベース用ファイル格納管理システ
ム。
【請求項１４】請求項１１において、前記従属関係管理手段の前記リレーション間の従属関係
の情報は、モジュール単位に従属する複数リレーション
について、順序性を持ってその識別を表し、該従属関係管理手段の前記ディレクトリ情報のページマ
ップ一覧情報は、更に前記従属するリレーションの順序
性に対応した空きレコード探査開始情報と空きレコード
存在有無を示す情報を持ち、前記レコード操作手段の前記レコードの挿入における既
存ページの探査に際して、該従属関係管理手段は、当該リレーショッに対応する前
記空きレコード探査開始情報の示す位置（一覧配列の位
置）からその直前までについて逐次、前記ディレクトリ
情報のページマップ一覧情報のページマップ情報の識別
（アドレス）で示され、且つ当該リレーションに対応す
る前記空きレコード存在有無情報に基づいて、空きレコ
ードの存在するページマップ情報を限定していくように
構成されたことを特徴とするデータベース用ファイル格
納管理システム。
【請求項１５】請求項９において、前記レコード操作手段の前記レコードの挿入における新
規ページを割り当てるべき空きページの探査に際して、前記メタマップ管理手段は、空きページを持つページマ
ップ情報を限定するように構成されたことを特徴とする
データベース用ファイル格納管理システム。
【請求項１６】請求項１５において、前記従属関係管理手段の前記ディレクトリ情報は、モジ
ュールに所属するページの含まれるページマップ情報の
一覧情報を持ち、ページマップ一覧情報は、各ヘージマ
ップ情報毎にページマップ情報のアドレスを持ち、該従属関係管理手段は、前記レコード操作手段の前記レ
コードの挿入における新規ページを割り当てるべき空き
ページの探査に際して、空きページを選び出すべきペー
ジマップ情報を、前記ディレクトリ情報のページマップ
一覧情報のページマップ情報の識別（アドレス）で示さ
れるものの内、前記メタマップ管理手段で空きページを
持つページマップに限定し、空きページを持つページマ
ップ情報が存在すれば、そのページマップ情報より空き
ベージを探査し、前記ページマップ一覧情報で示される
プージマップ情報のいずれも空きページが無ければ、該
メタマップ管理手段により、空きページを持つページマ
ップ情報を限定し、そのページマップ情報より空きペー
ジを探査するように構成されたことを特徴とするデータ
ベース用ファイル格納管理システム。
【請求項１７】請求項１６において、前記従属関係管理手段の前記ディレクトリ情報のページ
マップ一覧情報は、更にモジュールに所属する使用中の
ページ数を持ち、前記レコード操作手段の前記レコードの挿入における新
規ページを割り当てるべき空きページの探査に際して、該従属関係管理手段は、空きページを選び出すべきペー
ジマップ情報を、前記ディレクトリ情報のページマップ
一覧情報のページマップ情報の識別（アドレス）で示さ
れるものの内、前記メタマップ管理手段で空きページを
持つページマップに限定し、更に当該モジュールに所属
する使用中のページ数の最も多いページマップ情報を限
定し、そのページマップ情報より空きページを探査し、
前記ページマップ一覧情報で示されるページマップ情報
のいずれも空きページが無ければ、該メタマップ管理手
段により、空きページを持つページマップ情報を限定
し、そのページマップ情報より時期ページを探査するよ
うに構成されたことを特徴とするデータベース用ファイ
ル格納管理システム。
【請求項１８】請求項１において、前記ページマップファイルは、各ページ使用／空き状態
を表し、空きページの場合には当該ページが空いている
識別を、使用ページの場合には、当該ページが格納する
データが所属するリレーション及びモジュールの識別を
表す情報を提供し、前記レコード操作手段のレコードの削除に際して、前記ページマップ手段は、削除対象となるレコードアド
レス（Ｒｉｄ）により、そのレコードを格納するページ
アドレスを導き出し、そのページ・アドレスに対応する
ページマップ情報により、当該レコードの所属するリレ
ーションとモジュールの識別を取得するように構成され
たことを特徴とするデータベース用ファイル格納管理シ
ステム。