(57)【特許請求の範囲】
【請求項１】
複数リレーションに所属するデータを格納するレコードを管理するデータベース用ファイル格納管理システムにおいて、
親リレーションと、前記親リレーションに属する複数の子リレーションとの間のモジュール性を表す従属関係の情報を格納するリレーション定義ファイルと、
親リレーションの親データレコードと、前記親リレーションに属する複数の子リレーションの子データレコードをページ単位に格納するデータページファイルと、
前記データページファイルにおけるデータページと空きページの所在情報を表したページマップ情報を格納するページマップファイルであって、前記データページは、親データレコードと、子データレコードと、親リレーションと前記親リレーションに属する複数の子リレーションのモジュールを格納し、有効レコードとして再利用される空きレコード領域を有し、更に前記記空きページは、レコードを有さず、ページ単位で再利用されるものであるページマップファイルと、
各ページマップ毎の空きページを表す情報を格納するメタマップファイルと、
前記リレーション定義ファイルと前記データページファイルを管理し、親リレーションに対応するモジュール単位に、従属関係とディレクトリ情報を管理する従属関係管理手段であって、前記ディレクトリ情報は、各モジュール用の子リレーション単位の空きレコードの探査開始情報と、一のモジュールに所属するページを含むページマップの一覧情報を表し、前記ページマップの一覧情報は、ページマップ情報識別子と、データページの数と、各子リレーションに対するページと空きレコードの存在情報を表しているものである従属関係管理手段と、
前記データページファイルを管理するデータページ管理手段と、
前記ページマップファイルを管理するページマップ管理手段と、
前記メタマップファイルを管理するメタマップ管理手段と、
前記従属関係管理手段、前記データページ管理手段、前記ページマップ管理手段、前記  メタマップ管理手段を操作し、親データレコード及び子データレコードとモジュールを  、挿入（ｉｎｓｅｒｔ）及び削除（ｒｅｍｏｖｅ）し、モジュール単位の子データレコ  ードをデータページファイルへ読み込む（ｌｏａｄ）レコード操作手段を有して構成さ  れるデータベース用ファイル格納管理システム。
【請求項２】
請求項１において、前記リレーション定義ファイル、データページファイル、ページマップファイル及びメタマップファイルは二次記憶装置に格納され、前記従属関係管理手段、データページ管理手段と、ページマップ管理手段及びメタマップ管理手段の各々の機能は、演算処理装置によって実行される
ように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項３】
請求項１において、
前記ページマップファイルは、各ページの使用／空き状態を表し、空きページの場合には該当ページが空いている識別を、使用ページの場合には、該当ページに格納するデータが所属する子リレーション及びモジュールの識別を表す情報を有し、
前記ページマップ管理手段は、前記レコード操作手段の１以上の子リレーションに所属するレコードの読み込みに際して、読み込み対象となるモジュールの識別が与えられない場合には、当該子リレーションに所属するページを読み込み対象として選び出し、当該子リレーションに所属ページを読み込まれるモジュールの識別子とともに、選び出すように構成されたことを特徴とするデータベース用ファイル格納管理システ
ム。
【請求項４】
請求項３において、
前記メタマップ管理手段は、前記レコード操作手段の１以上のリレーションに所属するレコードの読み込みに際して、空きページだけから成るページマップ情報を除外して、読み込み対象ページを選び出すべきページマップ情報を選び出すように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項５】
請求項３において、
前記従属関係管理手段の前記ディレクトリ情報は、モジュールに所属するページの含まれるページマップ情報のアドレスの一覧情報を持ち、ページマップ一覧情報は、各ページマップ情報毎にページマップ情報のアドレスを持ち、
該従属関係管理手段は、前記レコード操作手段のモジュールに所属するレコードの読み込みに際して、読み込み対象ページを選び出すべきページマップ情報を、前記ディレクトリ情報のページマップ一覧情報のページマップ情報の識別（アドレス）で示されるものに限定するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項６】
請求項５において、
前記従属関係管理手段の前記リレーション間の従属関係の情報は、モジュール単位に従属する複数の子リレーションについて、順序性を持ってその識別を表し、
該従属関係管理手段の前記ディレクトリ情報のページマップ一覧情報は、更に該従属するリレーションの順序性に対応したページ存在有無を表す情報を持ち、
該従属関係管理手段は、前記レコード操作手段のモジュールに所属し、且つ１つのリレーションに所属するレコードの読み込みに際して、読み込み対象ページを選び出すべきページマップ情報を、前記ディレクトリ情報のベージマップ一覧情報の内、当該リレーションのページが存在するページマップ情報の識別（アドレス）で示されるものに限定するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項７】
請求項５において、
前記従属関係管理手段の前記リレーション間の従属関係の情報は、モジュール単位に従属する複数の子リレーションについて、順序性を持ってその識別を表し、
該従属関係管理手段の前記ディレクトリ情報のページマップ一覧情報は、更に前記従属するリレーションの順序性に対応したページ存在有無を表すビット・フラグを持ち、このビットフラグは、ページが存在する場合は１を、存在しない場合は０を示し、
該従属関係管理手段は、前記レコード操作手段のモジュールに所属し、且つ複数のリレーションに所属するレコードの読み込みに際して、前記従属するリレーションの順序性に対応したビットマスクを作成し、このビット・マスクは、当該リレーションに対応したビットに１を、それ以外は０を表し、読み込み対象ページを選び出すべきページマップ情報を、該ディレクトリ情報のページマップ一覧情報の内、前記リレーション毎のページ存在有無を表すビットフラグと該リレーションに対応したビットマスクの論理積（ｃｏｎｊｕｎｃｔｉｏｎ（ＡＮＤ））の結果が全て０でない（少なくとも一つのビットが１である）、ページマップ情報の識別（アドレス）で示されるものに限定するように構成されたことを特徴と
するデータベース用ファイル格納管理システム。
【請求項８】
請求項１において、
前記ページマップファイルは、各ページの使用／空き状態を表し、空きページの場合には当該ページが空いている識別を、使用ページの場合には、当該ページが格納するデータが所属するリレーション及びモジュールの識別を表す情報を提供し、
前記従属関係管理手段の前記ディレクトリ情報は、モジュールに所属するページの含まれるページマップ情報のアドレスの一覧情報を持ち、ページマップ一覧情報は、各ページマップ情報毎にページマップ情報のアドレスを持ち、
前記レコード操作手段の特定モジュールに所属し、且つ全リレーションに所属するレコードの読み込みに際して、
該従属関係管理手段は、読み込み対象ページを選び出すべきページマップ情報を、前記ディレクトリ情報のページマップ一覧情報のページマップ情報の識別（アドレス）で示されるものに限定し、
該前記ページマップ管理手段は、リレーションの識別に関わらず、そのモジュール識別に所属するページを読み込み対象として選び出すように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項９】
請求項１記載において、
前記ページマップファイルは、各ページの使用／空き状態を表し、空きページの場合には当該ページが空いている識別を、使用ページの場合には、当該ページが格納するデータが所属するリレーション及びモジュールの識別を表す情報を有し、
前記レコード操作手段のある特定モジュールに所属し、１つのリレーションに所属するレコードの挿入は、最初に前記ページマップ管理手段によって、当該モジュールと当該リレーションに所属する既存ページを探査し、それらページに空きレコード領域が有ればそのページにレコードを挿入し、
無ければ、次に前記ページマップ管理手段によって、空きページを探査し、そのページに対応するページマップ情報に、当該リレーションとモジュールの識別を記録し、新規ページとして割当て、そのページにレコードを挿入するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１０】
請求項９におてい
前記ページマップ・ファイルは、更に使用ページの空きレコード情報を持ち、  前記レコード操作手段の前記レコードの挿入における既存ページの探査に際して、前記ページマップ管理手段は、当該モジュールと当該リレーションに所属する既存ページを探査し、それらページに空きレコード領域が有るか否かを、実際にデータページファイルをアクセスすることなく判断するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１１】
請求項９において、
前記従属関係管理手段の前記ディレクトリ情報は、モジュールに所属するページの含まれるページマップ情報のアドレスの一覧情報を持ち、ページマップ一覧情報は、各ページマップ情報毎にページマップ情報のアドレスを持ち、  前記レコード操作手段の前記レコードの挿入における既存ページの探査に際して、該従属関係管理手段は、既存ページを選び出すべきページマップ情報を、前記ディレクトリ情報のページマップ一覧情報のページマップ情報の識別（アドレス）で示されるものに限定するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１２】
請求項１１において、
前記従属関係管理手段の前記リレーション間の従属関係の情報は、モジュール単位に従属する複数の子リレーションについて、順序性を持ってその識別を表し、該従属関係管理手段の前記ディレクトリ情報のページマップ一覧情報は、更に前記従属するリレーションの順序性に対応した空きレコード探査開始情報を持ち、前記レコード操作手段の前記レコードの挿入における既存ページの探査に際して、該従属関係管理手段は、当該リレーションに対応する前記空きレコード探査開始情報の示す位置（一覧配列の位置）からその直前までについて逐次、前記ディレクトリ情報のページマップ一覧情報のページマップ情報の識別（アドレス）で示されるページマップ情報に限定して、既存ページを選び出すべきページマップ情報を限定していくように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１３】
請求項１１において、
前記従属関係管理手段の前記リレーション間の従属関係の情報は、モジュール単位に従属する複数のリレーションについて、順序性を持ってその識別を表し、
該従属関係管理手段の前記ディレクトリ情報のページマップ一覧情報は、更に前記従属するリレーションの順序性に対応した空きレコード存在有無を示す情報を持ち、
前記レコード操作手段の前記レコードの挿入における既存ページの探査に際して、
該従属関係管理手段は、既存ページを選び出すべきページマップ情報を、前記ディレクトリ情報のページマップ一覧情報のページマップ情報の識別（アドレス）で示されるものの内、更に当該リレーションに対応する前記空きレコード存在有無情報に基づいて、空きレコードの存在するページマップ情報を限定するよう
に構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１４】
請求項１１において、
前記従属関係管理手段の前記リレーション間の従属関係の情報は、モジュール単位に従属する複数の子リレーションについて、順序性を持ってその識別を表し、
該従属関係管理手段の前記ディレクトリ情報のページマップ一覧情報は、更に前記従属するリレーションの順序性に対応した空きレコード探査開始情報と空きレコード存在有無を示す情報を持ち、
前記レコード操作手段の前記レコードの挿入における既存ページの探査に際し該従属関係管理手段は、当該リレーショッに対応する前記空きレコード探査開始情報の示す位置（一覧配列の位置）からその直前までについて逐次、前記ディレクトリ情報のページマップ一覧情報のページマップ情報の識別（アドレス）で示され、且つ当該リレーションに対応する前記空きレコード存在有無情報に基づいて、空きレコードの存在するページマップ情報を限定していくように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１５】
請求項９において、
前記レコード操作手段の前記レコードの挿入における新規ページを割り当てるべき空きページの探査に際して、前記メタマップ管理手段は、空きページを持つページマップ情報を限定するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１６】
請求項１５において、
前記従属関係管理手段の前記ディレクトリ情報は、モジュールに所属するページの含まれるページマップ情報の一覧情報を持ち、ページマップ一覧情報は、各ヘージマップ情報毎にページマップ情報のアドレスを持ち、
該従属関係管理手段は、前記レコード操作手段の前記レコードの挿入における新規ページを割り当てるべき空きページの探査に際して、空きページを選び出すべきページマップ情報を、前記ディレクトリ情報のページマップ一覧情報のページマップ情報の識別（アドレス）で示されるものの内、前記メタマップ管理手段で空きページを持つページマップに限定し、空きページを持つページマップ情報が存在すれば、そのページマップ情報より空きベージを探査し、前記ページマップ一覧情報で示されるプージマップ情報のいずれも空きページが無ければ、該メタマップ管理手段により、空きページを持つページマップ情報を限定し、そのページマップ情報より空きページを探査するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１７】
請求項１６において、
前記従属関係管理手段の前記ディレクトリ情報のページマップ一覧情報は、更にモジュールに所属する使用中のページ数を持ち、前記レコード操作手段の前記レコードの挿入における新規ページを割り当てるべき空きページの探査に際して、該従属関係管理手段は、空きページを選び出すべきページマップ情報を、前記ディレクトリ情報のページマップ一覧情報のページマップ情報の識別（アドレス）で示されるものの内、前記メタマップ管理手段で空きページを持つページマップに限定し、更に当該モジュールに所属する使用中のページ数の最も多いページマップ情報を限定し、そのページマップ情報より空きページを探査し、前記ページマップ一覧情報で示されるページマップ情報のいずれも空きページが無ければ、該メタマップ管理手段により、空きページを持つページマップ情報を限定し、そのページマップ情報より時期ページを探査するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【請求項１８】
請求項１において、
前記ページマップファイルは、各ページ使用／空き状態を表し、空きページの場合には当該ページが空いている識別を、使用ページの場合には、当該ページが格納するデータが所属するリレーション及びモジュールの識別を表す情報を提供し、前記ページマップ手段は、削除対象となるレコードアドレス（Ｒｉｄ）により、そのレコードを格納するページアドレスを導き出し、そのページアドレスに対応するページマップ情報により、当該レコードの所属するリレーションとモジュールの識別を取得するように構成されたことを特徴とするデータベース用ファイル格納管理システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、クラスタリングを促進したデータベースのためのファイル格納管理システムに関する。特に、データの型に対する集合を表したリレーション毎のアクセスを可能としながら、データ個々の実体を表すレコード間の親子関係に応じて、データ格納ファイル内にお互いに近接して編成させるファイル格納管理システムに関する。
【０００２】
【従来の技術】
ＣＡＤ（Ｃｏｍｐｕｔｅｒ  Ａｉｄｅｄ  Ｄｅｓｉｇｎ）のようなエンジニアリング・アプリケーションの分野ではデータベースの利用に関し、データ間にモジュール性を持ち、このモジュール単位のデータ処理を高速に実現することが要求されている。
【０００３】
一方、リレーショナル・データベース管理システム（ＲＤＢＭＳ）では、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）のように、大量データを様々な項目で臨機応変（ａｄｈｏｃ）に検索できる特徴がある。
【０００４】
しかし、ＲＤＢＭＳは、従業員情報のように均質なデータの処理を対象としたビジネス・アプリケーションの分野に適したものであり、エンジニアリング・アプリケーションの分野には、適さないとされている。
【０００５】
アプリケーション・プログラムが扱うデータの単位となるレコード（ｒｅｃｏｒｄ）、又はタップル（ｔｕｐｌｅ）は、それぞれ一様な型（ｔｙｐｅ）、又はクラス（ｃｌａｓｓ）を持ち、レコードがどんなデータ項目のフィールドで構成されるかを表している。
【０００６】
ＲＤＢＭＳでは、この型やクラスに適応したリレーションという単位で、レコードの集合を管理するものであり、これにより一つのリレーションに属する広範囲のレコードについて、一様な検索条件を適用することができる。
【０００７】
一方で、レコード間の従属関係のようなモジュール性を表現する場合もモジュール単位を識別する一つのキーによる検索により集める必要があり、この場合のモジュール単位のアクセス動作は遅い。
【０００８】
ＲＤＢＭＳの各レコードに対するこのような識別キーに対し、ハッシュ（Ｈａｓｈ）コードやＢ（バイナリー）−ｔｒｅｅ等の２次インデクスを設けることにより、モジュール単位のアクセスを高速化することも提案されている（米国特許No. ４，９６１，１３９、米国特許No. ５，０５８，００２）。
【０００９】
ここで、ハッシュコードとは、あるキーをもとにデータ領域を確保し、そのキー位置をもとに、データをぶら下げていくものである。Ｂ−ｔｒｅｅは、あるキーで分布されたツリーコードでぶら下げていくもので、半分、半分にデータを分割して格納されるので、検索の場合は、半分の時間で済むという利点がある。
【００１０】
しかし、これらの方法でも２次インデクスで纏められたモジュール単位のレコードが、物理的に離散して二次記憶装置に格納配置される場合は、データへのアクセスが遅くなる。
【００１１】
更に、ネットワーク型データベース管理システムのように、モジュール単位のようなある特定のレコード間の関係を、レコード間のアドレス・リンクで表現する方法もある。この場合は、データをリンク関係で繋いでいくものであり、前のデータ、次のデータ、そしてその次のデータと言うようにリンクを辿るようにアクセスするようにした方法である。
【００１２】
しかし、この場合も同様にアドレス・リンクされたレコード群が、必ずしも物理的に近接して配置されるとは限らない。
【００１３】
したがって、モジュール単位の高速アクセスを可能とするには、このようなレコード間の従属関係に応じて、物理的に近接配置することが必要である。これを解決する方法として、区分編成（ｐａｒｔｉｔｉｏｎｅｄ  ｏｒｇａｎｉｚａｔｉｏｎ）ファイルのように、モジュール単位の物理的な格納管理情報を表したディレクトリを設ける方法が考えられる（米国特許No. ４，８２７，４６２、米国特許No. ５，０５８，００２）。
【００１４】
この方法では、モジュール単位となる複数のレコード群を格納するページ領域をディレクトリからアドレスリンクすることにより、モジュール単位のレコード群を、ページという範囲で近接配置することが可能となる。
【００１５】
しかし、この方法では、全てのレコードは、モジュール毎、即ちディレクトリ毎にアドレスリンクされたページ、及びページ内に格納されたレコードに対してしかアクセスできない、即ち、ディレクトリを介してしかアクセスできない。  ＲＤＢＭＳのようなリレーションを通したレコードのアクセスはできない。また、ディレクトリ上でページアドレスリンクで表現する以上、レコードを格納したページ自体の（ページ同士の）近接配置は、困難である。せいぜい、直前のページ領域に近接させるぐらいしかできない。
【００１６】
したがって、モジュール単位情報が複数ページにまたがり、頻繁なレコードの挿入と削除に伴うページの挿入、削除が行われると、ページ自体の格納場所が離散してしまう。
【００１７】
上記の従来のファイル格納技術を纏めると、図２９のように整理される。これらいずれの技術においても、既に説明し、図３０に示すように二次記憶装置１へのデータ格納の際に、格納位置が分散しがちとなる。したがって、二次記憶装置１へのアクセス回数が多くなり、アクセス時間の増大に繋がる。
【００１８】
上記の従来の技術に鑑みて、本出願人により先にリレーション間の関係に基づいた近接格納を行うクラスタリングについて提案している（特開平６−１１０７４４号、対応米国出願No. １２９，８５３）。
【００１９】
この先に提案した方法は、データの一様な型（ｔｙｐｅ）、或いはクラス（ｃｌａｓｓ）に着目して近接関係を導き出す方法である。データ種類毎に一括して主記憶装置に読み込んで、大量の計算を伴うようなデータ処理（回路設計ＣＡＤにおけるシュミレーションや回路合成）のデータ管理に向いている。
【００２０】
しかし、部品のライブラリ情報のように、データの実体毎に局所的にアクセスを要する場合には、本方法においても十分ではなく親となる部品のレコード毎に従属しあう、ポーション、ピンといった子レコードの纏まりというような、更に細かいクラスタリングが要求される。
【００２１】
【発明が解決しようとする課題】
したがって、本発明の目的は、前記従来の欠点を排除する斬新、且つ有用なデータベース用ファイル格納管理システムを提供することにある。
【００２２】
更に本発明の目的は、データの実体（ｉｎｓｔａｎｃｅ）として個々のモジュール性に着目して近接格納を管理するクラスタリング方法を用いるデータベース用ファイル格納管理システムを提供することにある。
【００２３】
又、本発明の目的は、モジュール単位となるレコード群を格納したページに関するクラスタリングを高度に実現するデータベース用ファイル格納管理システムを提供することにある。
【００２４】
更に又、本発明の目的は、データの型に対する集合を表したリレーション毎のアクセスを可能としながら、データ個々の実体を表すレコード間の親子関係に応じて、データ格納ファイル内に互いに近接して編成させるデータベース用ファイル格納管理システムを提供することにある。
【００２５】
本発明の更なる目的は、以下の図面に基づく実施例の説明及び特許請求の範囲の記載から明らかとなる。
【００２６】
【課題を解決するための手段及び作用】
本発明の上記目的を達成するデータベース用ファイル格納管理システムは、複数リレーションに所属するデータを格納するレコードを管理するデータベース用ファイル格納管理システムにおいて、リレーション間のモジュール性を表す従属関係の情報を格納するリレーション定義ファイルと、リレーションに所属するデータレコードをページ単位に格納するデータページファイルと、リレーション及びモジュールに所属したレコードを格納すると共に、有効レコードとして再利用される０個以上の空きレコード領域を持ち、空きページは何らレコードを持たず、ページ単位に再利用されるデータページと、空きページのデータページファイル内での所在情報をある特定のページ数単位に表したページマップ情報を格納するページマップファイルと、各ページマップ情報毎の空きページ数を格納するメタマップファイルを有する。
【００２７】
且つ、該リレーション定義ファイルと該データページファイルを管理し、リレーション間の従属関係の情報と、モジュール毎の、モジュール単位に包含されるリレーション毎の空きレコードの探査開始情報とモジュールに所属するページの含まれる、各ページマップ情報毎に、ページマップ情報の識別、データページ数、及びリレーション毎のページ存在有無と空きレコード存在有無を表す情報を表すページマップの一覧情報である、ディレクトリ情報とを管理する従属関係管理手段と、該データページファイルを管理するデータページ管理手段と、該ページマップファイルを管理するページマップ管理手段と、該メタマップファイルを管理するメタマップ管理手段とを有し、該従属関係管理手段、該データページ管理手段、該ページマップ管理手段、該メタマップ管理手段を操作し、リレーション及びモジュールに所属したレコードに対する挿入（ｉｎｓｅｒｔ）、削除（ｒｅｍｏｖｅ）、モジュール単位のレコードの主記憶上への読み込み（ｌｏａｄ）、更にリレーションを通したレコード単位の読み込み（ｓｃａｎ）を実行するレコード操作手段を有して構成される。
【００２８】
かかる構成により、ページマップ情報と、モジュール単位にページマップとの対応情報を管理したディレクトリ情報を利用することにより、モジュール単位のレコードを格納したページを高レベルでクラスタリングすることが可能である。
【００２９】
これにより、モジュール単位のレコードを高速に主記憶上に読み込むことが可能となる。更に、ディレクトリ情報を伴わずに、ページマップ情報内のページ毎に対応するリレーションの識別により、リレーションを通したデータレコードを走査される。
【００３０】
【実施例】
図１は、本発明のデータベース用ファイル格納システムの原理構成図である。以下、図において、同一または類似のものには、同一の参照番号及び記号を付して説明する。ここで、本発明の理解のために、先に本発明の原理とクラスタリングの概念について説明を行う。
【００３１】
図２〜図９は、部品としてのＩＣを例として、クラスタリングを説明する図である。図２は、ＩＣ部品（Ｑｕａｄ  ２−Ｉｎｐｕｔ  ＮＡＮＤ  Ｇａｔｅｓ）を一例とするクラスタリングの概念を説明する図である。
【００３２】
図２に示すような、ＩＣ部品を考えると、４つのＩＣ素子ＩＣ１〜ＩＣ４と、それぞれのＩＣ素子が３つの信号ピンを有する形で、計１２個の信号ピンにより成り立っている。
【００３３】
したがって、図３に示すように、４つのＩＣ素子ＩＣ１〜ＩＣ４をポーションと呼び、順にポーション番号１〜４が付され、且つピン構成として、ポーション番号１には、ピン番号１Ａ、１Ｂ、１Ｙが、ポーション番号２には、ピン番号２Ａ、２Ｂ、２Ｙが、ポーション番号３には、ピン番号３Ａ、３Ｂ、３Ｙが、そしてポーション番号４には、ピン番号４Ａ、４Ｂ、４Ｙが対応づけられる。
【００３４】
このようなデータに基づき、先に本出願人が提案したクラスタリングの方法では、ＩＣ部品を一つの部品と考え、データの一様な型（ｔｙｐｅ）、或いはクラス（ｃｌａｓｓ）に着目してデータ種類毎に一括して主記憶装置に読み込むようにしている。この場合、図４に示すようなデータ配列となる。
【００３５】
しかし、図４に示すようなデータ配列では、あるポーションを要素として、これにリンクするデータ（ピンデータ等）にアクセスしようとする場合、他のポーションとリンクするデータをも参照することになり、オーバーヘッドが大きくなる。
【００３６】
これに対し、本発明によるクラスタリングでは、図５に示すように、モジュールの実体（ｉｎｓｔａｎｃｅ）をベースとしている。即ち、ＩＣ部品を一つの部品として纏めずに、これを構成する複数の部品１〜部品ｉ、図２に示す部品の例ではＩＣ素子ＩＣ１〜ＩＣ４をそれぞれ別のものとして分類し、具体的には、素子（ポーション）１〜４というように分類している。
【００３７】
このようにすることにより、本発明によりデータの実体（ｉｎｓｔａｎｃｅ）の個々のモジュール性に着目して近接格納を管理することが可能となる。
【００３８】
図６は、更にモジュール性に着目して近接格納されるデータのリレーション間の従属関係の定義を説明する図である。リレーション定義テーブルとして、リレーション名、リレーション番号、親リレーション番号が定義される。
【００３９】
図６において、網かけ部は、ディレクトリであり、その下にディレクトリ単位が従属する。例えば、部品ディレクトリに部品ピン、ポーション及び特性値のディレクトリ単位が従属する。
【００４０】
リレーション番号は、親識別であり、親リレーション番号は、親への識別である。従って、部品ディレクトリのリレーション番号０１とその下のディレクトリ単位である部品ピン、ポーション及び特性値の親リレーション番号０１が一致し、これらの間でリレーションが関連付けられ、図７に示す関係が得られる。
【００４１】
また、シンボルディレクトリの下にディレクトリ単位であるシンボルピンが図８のように示される。更に、この時シンボルピン間の接続は、ネットディレクトリと経路ディレクトリ単位により、ネット番号に対応して接続されるポーションとシンボルピンとの対応関係が図９に示される。
【００４２】
図１に戻り、説明すると、１は、二次記憶装置を表し、データベースをリレーション定義ファイル１０、データページファイル２０、ページマップファイル３０及びメタマップファイル４０として格納する。
【００４３】
二次記憶装置１のリレーション定義ファイル１０には、図６において説明したリレーション間のモジュール性を表す従属関係の情報が格納される。
【００４４】
データページファイル２０には、リレーションに属するデータレコードをページ単位に格納し、ページマップファイル３０は、データページと空きページのデータページファイル２０内での所在情報を、ある特定のページ単位に表したページマップ情報を格納する。
【００４５】
更に詳しくは、データページファイル２０は、リレーション及びモジュールに属したレコードを格納するとともに、有効レコードとして再利用される空きレコード領域を有し、空きページは何らレコードを持たず、ページ単位に再利用されるものである。
【００４６】
メタマップファイル４０は、各ページマップ毎のページ空き状態として、空きページ数を格納する。
【００４７】
一方、演算処理装置２内では、機能として従属関係即ち、モジュール間リレーションの管理手段１１を有し、リレーション定義ファイル１０とデータページファイル２０を管理し、図６に示したようなリレーション間の従属関係の情報１０１とディレクトリ情報１０２を管理する。
【００４８】
ディレクトリ情報１０２は、モジュールに属するリレーション毎の空きレコードの探査開始ページアドレス１１２と、モジュールに属するページの含まれるページマップの一覧情報を表し、ページマップ一覧情報は、各ページマップ毎に、ページマップのアドレス、データページ数及びリレーション毎のページ存在有無と空きレコード存在有無の情報１２２を表す。
【００４９】
データページ管理手段２１は、データページファイル２０を管理し、ページマップ管理手段３１は、ページマップファイル３０を管理し、メタマップ管理手段４１は、メタマップファイル３０を管理する。
【００５０】
レコード操作手段５０は、モジュール間リレーション管理手段１１、データページ管理手段２１、ページマップ管理手段３１及びメタマップ管理手段４１を操作し、リレーション及びモジュールに属したレコードに対する挿入（ｉｎｓｅｒｔ）５１、削除（ｄｅｌｅｔｅ）５２、主記憶上への読み込み（ｌｏａｄ）５３、更にリレーションを通したレコードの読み込み（ｓｃａｎ）５４を実行する。また、上記各処理の実行に対し、共通にモジュールの割り付け（ｌｏｃａｔｅ）処理５５の処理が行われる。
【００５１】
上記構成において、本発明は、ページマップファイル２０からのページマップ情報と、リレーション定義ファイル１０に格納される図６に示す如き、ページマップとの対応情報を管理するディレクトリ情報を利用する。これにより、モジュール単位のレコードを格納したページを高度にクラスタリングすることが可能である。
【００５２】
したがって、モジュール単位のデータレコードを高速に主記憶上に読み込むことができる。更に、ディレクトリ情報を伴わずに、ページマップ情報内のページ毎に対応するリレーションの識別により、リレーションを通したデータレコードを操作することも出来る。
【００５３】
図１０は、本発明システムの実施例ブロック図である。図１０においては、図１の原理構成図に対し、ディスプレィ装置３とキーボード装置４を備えた応用処理部６０が部品情報のデータベースをアクセスする例を示している。
【００５４】
更に、実施例として演算処理装置２内に、レコード操作５０の際に用いられるＲｉｄ（レコードｉｄ：データデース上でのレコードアドレス）識別回路６１及びレコードバッファメモリ６２を有している。
【００５５】
又、実施例として、データベースを構成するファイルは、リレーション定義、データページ、ページマップ及びメタマップであり、それぞれ図１において説明したように、二次記憶装置１の対応するファイル格納部即ち、リレーション定義ファイル１０、データページファイル２０、ページマップファイル３０及びメタマップファイル４０に格納される。
【００５６】
そして、リレーション定義ファイル１０におけるリレーション定義は、データの種類（テーブルの型）毎のリレーション自身とリレーション間の制御関係即ち、リレーションｉｄ（識別記号）、レコード長、親リレーションｉｄ、従属する子リレーション数等を含む。
【００５７】
データページファイル２０は、応用処理の必要とするデータのレコードを格納する。ファイルは、物理的な入出力の単位となるページで分割されている。同一ページには一種類のリレーションに所属するレコードのみ格納される。
【００５８】
ページマップファイル３０は、前記データページファイルを構成するページ単位の空き／使用の情報を管理する。空き／使用されるリレーションｉｄ、従属関係を表す親レコードのＲｉｄ、空きレコード情報（空きレコード数）を複数ページでページマップをグループ化する。例えば、１ページマップ当たり４ページとする。メタマップファイル４０は、前記のページマップ毎のページ空き状態として空きページ数を管理する。
【００５９】
ここでメタマップ、ページマップとデータページの関係について具体的に説明する。図１１は、メタマップ、ページマップとデータページの関係を一例として示す図である。
【００６０】
図１１（３）に示されるデータマップには、ディレクトリに親レコード（例として部品単位）、及び親レコード毎の従属する子レコードの情報をテーブルで有する。
【００６１】
例えば、部品１のディレクトリに、従属する（リレーションを有する）子レコードとしてデータページアドレス１〜４に（ピン、ピン、特性値及びポーション）が格納されていること示している。
【００６２】
また、図１１（２）に示されるページマップには、データページの情報及び空きレコード情報を有している。例えば、ページマップアドレス１には、データページアドレス１〜４が関係付けられ、ディレクトリである親レコードのｉｄ（部品：１）、リレーションを有する子レコードのｉｄ（ピン：１、ピン：１、特性値：３、ポーション：２）及び空きレコード情報（全て０）が示される。空きレコード情報は、空きレコード数または空きレコードサイズで表される。
【００６３】
更に、図１１（１）に示されるメタマップには、ページマップアドレス毎の空きページ数が表されている。即ち、図１１（２）との比較により理解容易のように、例えばページマップアドレス１は、空きページが０、ページマップアドレス２は、空きページが１であることが示される。
【００６４】
図１２は、ディレクトリのデータ構造を示している。ディレクトリのデータ〔図１２（１）〕として、メンバーリレーション数（Ｒ）、リレーション情報、空きレコード管理情報、使用ページマップ数（Ｐ）及びページ所在管理情報が含まれる。
【００６５】
リレーション情報は、図１２（２）に示されるようにメンバーリレーション数分のリレーションのリレーション定義情報を有し、各々のリレーション定義情報は、図１２（３）に示されるように、リレーション定義、親リレーション番号及びメンバーリレーション数を含み、これらは、ページマップから得られる。
【００６６】
空きレコード管理情報は、図１２（４）に示されるようにメンバーリレーション数分の空きページ探査位置を有する。
【００６７】
ページ所在管理情報は、図１２（５）に示されるように使用ページマップを有する。各々の使用ページマップは、図１２（６）に示されるようにページマップアドレス、使用ページ数、使用ページ所在マスク及び空きレコードマスクを有する。
【００６８】
図１３は、本発明システムの全体の実施例動作フローである。先ずシステムの初期化において、リレーション定義ファイル１０からリレーション定義の読み込みが行われる（ステップＳ１）。
【００６９】
次に、全ての編集作業の終了受付までディレクトリ単位即ち、ある特定部品に対する処理が行われる（ステップＳ２）。このディレクトリ単位の処理（ステップＳ２）において、先ずディレクトリ識別名と編集対象テーブルがキーボードより入力される（ステップＳ３）。これにより、１種類のリレーション、複数種類のリレーション、全ての子リレーション（ポーション、ピン、特性値）が選択される。
【００７０】
更に、図１３の動作フローにおいて、レコードの読み込み（ｓｃａｎ）処理により集合条件で全メンバーのあるリレーションデータを検索する（ステップＳ４）。ついで、割り付け（ｌｏｃａｔｅ）処理によりデータの割り付けを行う（ステップＳ５）。
【００７１】
また、一つのテーブルの編集のための１リレーションのモジュール単位の読み込み、複数のテーブルの編集のための複数リレーションのモジュール単位の読み込みあるいは、全テーブルの編集のための全リレーションのモジュール単位の読み込み（ｌｏａｄ）処理が行われる（ステップＳ６）。
【００７２】
更に、編集の過程においてディスプレィに内容が表示される（ステップＳ７）。また、ディレクトリ単位の編集終了受付までレコード操作が行われる（ステップＳ８）。レコード操作の過程で最新状態が反映されディスプレイに表示される（ステップＳ９）。
【００７３】
レコード操作（ステップＳ８）において、キーボードよりレコード単位のコマンドが入力され（ステップＳ１０）、入力されるコマンドに応じ、追加（ｉｎｓｅｒｔ）処理（ステップＳ１１）又は、削除（ｒｅｍｏｖｅ）処理（ステップＳ１２）が行われる。
【００７４】
次に、上記説明におけるレコードの読み込み（ｓｃａｎ）処理、割り付け（ｌｏｃａｔｅ）処理、モジュール単位の読み込み（ｌｏａｄ）処理、追加（ｉｎｓｅｒｔ）処理及び削除（ｒｅｍｏｖｅ）処理を更に説明し、本発明システムの特徴を更に明らかにする。
【００７５】
レコードの読み込み（ＳＣＡＮ）処理：
図１４は、レコードの読み込み（ＳＣＡＮ）処理のフローである。レコードの読み込み（ＳＣＡＮ）処理は、リレーションの親子関係に関わらず、同一リレーションの全レコードを走査する。即ち、全ページマップ数分のページマップ単位に処理が行われる（ステップＳ２０）。
【００７６】
メタマップ（図１１参照）より空きページマップか否かを判断し、空きページマップである場合は、次のメタマップを参照する（ステップＳ２１）。
【００７７】
空きページマップでない場合は、ページマップ内の全ページ数をページ単位で処理する（ステップＳ２２）。ページ単位の処理において、該当のリレーションページか否かを判断し、該当のリレーションページでない場合は、次のページマップの処理に移行し、該当のリレーションページである場合は、有効レコード数分をレコード単位に処理を行う（ステップＳ２３）。
【００７８】
このレコード単位の処理において、レコードの内容とキー内容を比較する（ステップＳ２３１）。比較処理（ステップＳ２３１）おいて、条件が一致する時、後処理（ＰＯＳＴ  ＰＲＯＣ）が行われる（ステップＳ２３２）。後処理（ＰＯＳＴ  ＰＲＯＣ）において、レコード数を＋１し、レコード内容を応用処理（Ａ／Ｐ）領域（図１０：６０）に格納する。
【００７９】
図１５は、レコードの読み込み（ＳＣＡＮ）処理の過程におけるデータベースの具体的状態である。図１５において、図中の記号は次のように定義される。
【００８０】
Ｐ：ページマップ、ＥＰ：空きページ数、ＤＰ：データページ、ＤＩ：親レコード／Ｒｉｄ、ＥＲ：空きレコード情報
Ｒ：リレーションｉｄ＝R1．ピン，R2. ポーション, R3. シンボルネット,
R4. ネット，R5. 特性値
図１５▲１▼は、メタマップから有効ページが存在するページマップを決定されることを示す。図１５▲２▼は、ページマップで抵抗Ｒが一致したレコードを絞り込む状態を示す。
【００８１】
図１５▲３▼は、絞り込んだレコードを応用処理（Ａ／Ｐ）６０のコールバックルーチンに渡し、比較処理（ステップＳ２３１）を行う状態を示す。
【００８２】
図１５▲４▼は、次いで条件の一致したレコードを応用処理（Ａ／Ｐ）６０のコールバックルーチンに渡し、後処理（ステップＳ２３２）を行う状態を示す。
【００８３】
図１６は、モジュールの割り付け（ｌｏｃａｔｅ）処理のフローである。応用処理部６０から親レコードを識別するリレーションｉｄ（Ｒｉｄ）を与えられる。したがって、演算処理部５０でこのＲｉｄに基づき、リレーション定義ファイル１９から対応のディレクトリ情報の読み込みを行う（ステップＳ３０）。この時、ディレクトリ情報の読み込みは、Ｒｉｄをキーにしたり、又は直接親レコード自身と結合させて行う。
【００８４】
ここで、前記の親レコードを識別するリレーションｉｄ（Ｒｉｄ）より、親レコードのリレーションｉｄが分かり、リレーション定義によりリレーションの親子関係が分かる。即ち、Ｒｉｄ→ページアドレス→ページマップの手順により、リレーションｉｄ→リレーション定義の関係からリレーションの親子関係が求められる。
【００８５】
ついで、リレーションの親子関係により、ディレクトリ情報（図１２参照）について、子リレーション毎の子リレーション毎の空きレコード探査開始ページ・アドレスの配列の順番、更に、使用ページマップ一覧内のページ存在マスク、空きレコード存在マスクのビットの順番と、子リレーションｉｄとの対応が付けられる。
【００８６】
図１６に戻り、ディレクトリ情報の読み込み（ステップＳ３０）が行われ、前回のディレクトリ情報が存在する場合は、ディレクトリ情報の交換（スワップ）を行う（ステップＳ３１）。ディレクトリ情報の交換（スワップ）において、以前の別ディレクトリ情報の退避（ステップＳ３１１）を行い、又今回のディレクトリ情報の読み込み（ステップＳ３１２）を行う。
【００８７】
更に、前回のディレクトリ情報が存在しない時は、ディレクトリ情報の作成を行う（ステップＳ３２）。ディレクトリ情報の作成において、ディレクトリ情報が新規の場合は、初期化クリアし（ステップＳ３２１）、そうでなければ読み込んだディレクトリ情報を転写する（ステップＳ３２２）。
【００８８】
一方、親子関係の設定（ステップＳ３２）は、レコード識別によりページアドレスを求める（ステップＳ３２１）。更に、当該ページアドレスのページマップによりレコード識別のリレーション識別を求める（ステップＳ３２２）。
【００８９】
ついで、リレーション定義数分のリレーション定義単位処理を行う（ステップＳ３２３）。この処理において、リレーション識別が当該リレーション識別と一致するかを判断し、一致しない場合、ディレクトリ情報に子リレーション定義を設定する（ステップＳ３２４）。
【００９０】
図１７は、モジュール単位の読み込み（ｌｏａｄ）処理のフローである。図１８乃至図２１は、モジュール単位の読み込み（ｌｏａｄ）処理におけるデータベース上の具体的状態を示す関係図である。
【００９１】
モジュール単位の読み込み（ｌｏａｄ）処理は、レコードの読み込み（ｓｃａｎ）処理と異なり、割り付け（ｌｏｃａｔｅ）処理で特定された親レコードに所属するレコードのみを読み込みの対象とする。読み込み対象となるリレーションの種類として、１種類、複数種類、又は親子関係になる全ての読み込みを選択する。
【００９２】
読み込み対象レコードを格納するページは、ディレクトリのページマップ一覧より特定する。読み込み対象リレーションに応じて子リレーション毎のページ存在マスクにより調べるべきページマップを特定する。また、読み込み対象となるリレーション毎のビットをオン（１）とし、それらを読み込み対象リレーション分について論理和（ＯＲ）をとったビットマスクと、ページマップ一覧毎のページ所在マスクとの論理積（ＡＮＤ）の結果が、全て０以外のページマップと判断する。
【００９３】
更に、ページマップ内での読み込み対象ページの絞り込みには、リレーションｉｄと共に、親レコードｉｄとの一致も調べる。
【００９４】
上記説明に基づき、図１７に戻ると、先ずディレクトリへの割り付け（ｌｏｃａｔｅ）が行われる（ステップＳ４０）。ついで、全リレーションが対象でない場合、照合用リレーションマスクが作成される（ステップＳ４１）。
【００９５】
この時、上記の説明の通り、対象リレーションの対応ビットをオン（１）とする。複数リレーションの時は、各リレーションの論理和（ＯＲ）で作成する。更に、全リレーションの時は、対象リレーションの対応ビットを全てオン（１）とする。
【００９６】
更に、図１７において、全リレーションが対象である場合は、ページマップ単位に、ページ所在管理が処理される（ステップＳ４２）。このページ所在管理処理において、対象リレーションがない場合（ページ所在管理のページ所在マスクと照合マスクの論理積（ＡＮＤ）をとり全て０とする場合）、次のページ所在管理を処理する。
【００９７】
対象リレーションがある場合は、ページマップ内のページ単位にページマップ内ページ数分のモジュールの読み込み（ｌｏａｄ）処理（ステップＳ４２２）を行う。このモジュールの読み込み（ｌｏａｄ）処理により、当該メンバーのページに対し、データページアドレスにより、データページをデータファイルより有効レコード数分読み込まれる。
【００９８】
ここで図１８乃至図２１を参照する。図１８乃至図２１において、共通に使用される記号は、次のように定義される。
【００９９】
ＤＩ：ディレクトリ  ＰＭＡＰ：ページマップ  ＤＰ：データページ
ＲＭＳＫ：使用ページ所在マスク  Ｒ：リレーションｉｄ（図１１参照）
図１８は、図６乃至図９を参照した場合のページ所在の概略全体表である。使用ページ所在マスクＲＭＳＫは、リレーション番号に対応してビットが１又は０のビットがたてられる。
【０１００】
図１９は、ページマップの全体表であり、各ページマップＰＭＡＰに対して、データページＤＰ及びリレーションｉｄが記される。
【０１０１】
図２０は、図５乃至図８を参照した時のモジュールの読み込みの内容を示す図である。図２０（１）は、ディレクトリレーション・部品についてのロードの内容であり、図２０（２）は、ディレクトリレーション・シンボルについてのロードの内容であり、図２０（２）は、ディレクトリレーション・ネットについてのロードの内容である。
【０１０２】
更に図２１は、データページを示し、ページマップ対応にデータページＤＰ及びリレーションｉｄがテーブル化されている。
【０１０３】
図２２は、挿入（ｉｎｓｅｒｔ）処理のフローである。ここで、挿入（ｉｎｓｅｒｔ）処理は、ディレクトリへの位置づけが行われる（ステップＳ５０）と、大きくは、レコードの割り当て先ページの決定処理（ステップＳ５１）と、その決定されたページ内へのレコード割り当ての処理（ステップＳ５２）で構成される。
【０１０４】
レコードの割り当て先ページの決定（ステップＳ５１）は、既に割り当てられている既存のページの中から空きレコード領域を探査する場合（ステップＳ５１１）と、既存ページに空きレコードがない場合に新規ページを割り当てる場合（ステップＳ５１６）とに別れる。
【０１０５】
既存のページの中から空きレコード領域を探査する場合（ステップＳ５１１）は、空きレコード管理の空きレコード探査開始アドレスからページマップアドレスを求め（ステップＳ５１２）、ぺージ所在数分、ページマップ単位に処理される（ステップＳ５２３）。
【０１０６】
そして、このページマップ単位に処理において、当該リレーションにおいて、空きレコードがあ場合、最初のレコド探査開始アドレスの直前までページマップ内でページチェックを行う。このページチェックで当該リレーションで空きデータがある時、データページアドレス（ページｉｄ）を割当て対象とする。
【０１０７】
一方、新規ページの割当て（ステップＳ５１６）処理は、新規ページを割り当てる先のページマップの決定（ステップＳ５１７）と、ページマップ内へのページ割当ての処理（ステップＳ５２０）で構成する。
【０１０８】
更に、割り当てる先のページマップの決定（ステップＳ５１７）は、現在使用中の既存のページマップ一覧より決定する（ステップＳ５１８）か、使用中のページマップに空きページがない場合にメタマップより新規のページマップを調べる場合（ステップＳ５１９）に分かれる。
【０１０９】
ページ内へのレコード割当ての処理（ステップＳ５２）では、当該ページに対応するページマップのページ単位情報の空きレコード情報を更新する（ステップＳ５２１）。
【０１１０】
そして、今回のレコード挿入で、当該ページに空きレコード領域が無くなった場合、ページマップ上に当該リレーションｉｄと当該親レコードのＲｉｄを持つ全てのページについて空きレコードが無くなった場合（当該ページマップ上の全てのページ単位情報を調べることにより判断）、ページマップ一覧の当該ページマップにおける当該リレーションに対する空きレコード存在マスクをオフ（０）にする（ステップＳ５２２）。
【０１１１】
次に、挿入（ｉｎｓｅｒｔ）処理（図２２のフロー）における各場合について更に詳細に説明する。
【０１１２】
図２３は、挿入（ｉｎｓｅｒｔ）処理において、既存ページの中から空きレコード領域を探査する場合（ステップＳ５１１：図２２参照）の例を示す。図２３において使用される記号の定義は、次の通りである。
【０１１３】
ＰＭＡＰ：ページマップ  ＲＥ：空きレコード管理  ＰＥ：ページ所在管理
ＤＰ：データページ  Ｒ：リレーション  ＥＲ：空きレコード情報
ＰＭＳＫ：ページ存在マスク
この処理は、ディレクトリ情報を基に、ページマップ一覧からページマップ、次いで既存ページの順に、空きレコード領域を持ちうる既存ページを探査していく。常にページマップ一覧の先頭から調べるのでは、レコードがフル状態になっている場合には効率が悪い。
【０１１４】
そこで、子リレーション毎の空きレコード探査開始ページアドレスから最初に調べるべきページマップを決定する。ページマップ一覧には、子リレーション毎に対応したビットで表現される空きレコード存在マスクにより、当該ページマップ内に空きレコードを持つページの有無を知ることが出来る。
【０１１５】
探査開始すべきページマップからページマップ一覧を調べ、ページマップ一覧の最後に達したら、ページマップ一覧の先頭より逆上り元の探査開始ページマップの直前のページマップまでを調べる。
【０１１６】
このビットマスクにより、当該ページマップ内からレコード割当て対象となるリレーションｉｄを持ち、当該親レコードｉｄを且つ空きレコードを持つページを探査することにより、レコード割り当てとなる既存ページが決定される。
【０１１７】
ページを割り当てるべき既存ページが決定されたら、最終的に空きレコード探査開始ページアドレスをそのページのアドレスに更新する。これにより、次回の挿入（ｉｎｓｅｒｔ）処理でも、そのページアドレスより探査される。
【０１１８】
図２４は、挿入（ｉｎｓｅｒｔ）処理の新規にページを割り当てるべきページマップの決定において、現在使用中のページマップ一覧より決定する（ステップＳ５１６：図２２参照）例を示している。図２４において使用される記号の定義は、図２３と同じものは、同じ定義であり、図２４で始めて現れる記号の定義は、次の通りである。
【０１１９】
ＭＭ：メタマップ  ＤＩ：親レコード  ＥＰ：空きページ数  ＵＰ：使用ページ数
この処理は、本発明の中心となる部分であり、互いに関連し合うレコード群を格納するページをページマップという単位で互いに近接配置させ、且つそのページが配置されるべき物理的なグループき範囲を表すページマップそのものも極力分散しないようにページを割り当てるページマップを決定する。
【０１２０】
先ず使用中のページマップ一覧より、ページを割り当てるべきページマップを決定するのに、少なくとも空きページがあるページマップでなければならない。この条件は、メタマップを参照することにより、実際のページマップ内のページ単位情報をアクセスすることなく分かる。
【０１２１】
次に、空きページを持つページマップの内、各ページマップ毎の使用ページ数が大きいものも選択する。このことは、レコード操作の挿入（ｉｎｓｅｒｔ）処理、削除（ｒｅｍｏｖｅ）処理に伴うページの割り当て、開放が繰り返されるのに伴い、過疎なページマップが除外され、ページ割り当て対象となるページマップが過疎化することに繋がる。
【０１２２】
図２４において、（ａ）、（ｂ）は、それぞれメタマップ、ページ所在管理であり、メタマップより空きページ数のあるページ所在管理を絞り込む（図２４の▲１▼参照）。
【０１２３】
ページマップの７、８に空きページ数が１ずつあり、これに絞りこまれる。次に絞り込み後のページ所在管理について、最も使用ページ数の多いページ所在管理を決定ページとする。図２４では、使用ページ数が３であるページマップの８ページを決定ページとする（図２４の▲２▼）。
【０１２４】
これに基づき、検索前のページマップの８ページ（図２４のｃ）を更新する（図２４の▲３▼）。図においては、編みかけ部分（図２４のｄ）が更新される。次いで、メタマップとページ所在管理の更新が、それぞれ図２４のｅ、ｆの網かけ部分のように行われる（図２４の▲４▼）。
【０１２５】
図２５は、挿入（ｉｎｓｅｒｔ）処理の新規にページを割り当てるべきページマップの決定において、現在使用中のページマップ一覧からではなく、空きページを含むページマップより決定する例（ステップＳ５１９：図２２参照）である。図２５において使用される記号の定義は、図２４におけると同じである。
【０１２６】
先ずメタマップＭＭより空きページ数のあるページ所在管理ＰＥを絞り込む（図２５の▲１▼）。全く空きページが存在しない場合は、メタマップＭＭより空きの存在するページマップを探しだす。図２５の▲２▼の例では、空きページ２を持つページマップを検索する。そして、図示のような検索前のページマップをページマップ５について、検索後の変更を図示のように行う（図２５の▲３▼）。
【０１２７】
その後、図しされるように、メタマップＭＭとページ所在管理ＰＥにページマップの５を新規追加して更新する（図２５の▲４▼）。
【０１２８】
尚、上記の場合、図２４及び図２５において、ページマップ内のページ割り当ての処理では、次の内容が行われる。
【０１２９】
i）メタマップ上の（当該ページマップアドレスの空きページ−１）。
【０１３０】
ii）更に、ディレクトリ情報の中のページマップ一覧の当該ページマップの配列に対し、
使用ページ数＋１、リレーション毎のページ存在マスク、空きレコード存在マスクを共にオン（１）とする。
【０１３１】
iii）ページマップ内より空きページを探し、ページ単位情報として、リレーションｉｄ、親Ｒｉｄの設定、及び空きレコード情報のリセットを行う。
【０１３２】
図２６は、削除（ｒｅｍｏｖｅ）処理のフローである。他の処理と同様にディレクトリの位置づけ（ｌｏｃａｔｅ）処理Ｓ６０を行う。
【０１３３】
ページ内から１件のレコードを削除し（有効レコード−１）、ページマップ内の当該ページの空きレコード情報を更新する（空きレコード数＋１）。
【０１３４】
更に、ページ所在の当該ページマップの空きレコードマスクをオン（１）とする。厳密には、当該ページマップ内の当該リレーションの全てのページについて初めて空きレコードが発生した場合、すでにオン（１）となっている場合がある。
【０１３５】
削除（ｒｅｍｏｖｅ）処理は、上記のようにページ内から１件のレコードを削除した結果についてケースが次のように分かれる。
【０１３６】
ページ内が全て空き（有効レコードがない）場合（ステップＳ６１）、ページマップ内の当該ページ情報を削除し、メタマップの空きページ数を、＋１し、ページ所在の当該ページマップに対する使用ページを、−１する。
【０１３７】
更に、ページ所在の使用ページが空き（使用ページ数＝０）の場合（ステップＳ６２）、ページ所在の当該ページマップの配列を削除する。
【０１３８】
また、ページマップ内に当該リレーションのページが残っていない場合（ステップＳ６３）は、ページ所在の当該ページマップの当該リレーションに対するページマスク及び空きレコードマスクを共にオフ（０）とする。
【０１３９】
図２７、２８は、削除（ｒｅｍｏｖｅ）処理において、空きが発生し、且つ当該ページマップに当該親レコードに従属するページが残っている場合を示す図である。図２７、２８で使用される記号の定義は、図２５と同じ記号の他、ＲＭＳＫ：空きレコード存在マスクが追加されている。
【０１４０】
図示されるページマップＰＭＡＰ、メタマップＭＭおよびページ管理所在ＰＥの状態において、削除対象データページアドレスＤＰが２、対象リレーションが２とすると、図示のメタマップＭＭおよびページ管理所在ＰＥの編みかけ領域が削除される。
【０１４１】
即ち、削除対象データページアドレスＤＰよりページマップアドレス（ＰＭＡＰアドレス）を求める。ＣＥＩＬ（ＤＰ／Ｎ）より、ＰＭＡＰアドレス＝１となる。そして、１ページ内の最大数は４となる。
【０１４２】
図２７のケース１は、ＰＭＡＰアドレス＝１Ｋ  ＤＰ＝２のレコードを削除した結果、ＤＰ＝２が空きになる場合の削除後のページマップＰＭＡＰ、メタマップＭＭ及びページ存在管理ＰＥの状態を示している。
【０１４３】
更に、図２８は、ケース１に対し、更にページ所在内のページマップに対する使用データページが全て空きになる場合の削除後のページマップＰＭＡＰ、メタマップＭＭ及びページ存在管理ＰＥの状態を示している。これは、ページマップ一覧の当該屁の配列の使用ページ数が０になったことで判断され、ページマップ一覧より当該ページマップの配列が削除される。ページ存在管理ＰＥの影線部分が、削除により詰められ、配列が減る領域を示している。
【０１４４】
以上本発明の実施例において、説明してきたようにディレクトリ情報のページマップ一覧にといて、リレーション毎のページの存在有無と空きレコードの存在有無とをビットマスクで表現したが、これの代わりにそれぞれリレーション毎の使用ページ数、空きレコードを持つページ数で管理することも可能である。
【０１４５】
この場合は、ディレクトリ情報の中のページマップ一覧におけるリレーション毎のページの存在有無と空きレコードの存在有無のビットマスクをオフ（０）にするか否かの判断において、挿入（ｉｎｓｅｒｔ）処理と削除（ｒｅｍｏｖｅ）処理で、それぞれ当該ページマップ内の全てのページ単位情報について調べる処理が省略できる（単に当該ページ数を−１とすることで自ずと０となる）。
【０１４６】
しかし、ディレクトリ情報のサイズが極端に大きくなる。例えば、ページマップ毎に２５６ページの対応を記録するとすれば、前記リレーション毎の両ページ数は、２の８乗、即ちビット表現に比べ８倍以上の大きさが必要である。このサイズは、従属するリレーションの種類数、及び使用されるページマップアドレスの数に依存して膨れ上がる。
【０１４７】
更に、モジュール単位の読み込み（ｌｏａｄ）処理における読み込み対処となるリレーションの存在するページマップを選別する際のビット演算のオーバーヘッドも増大するという欠点がある。
【０１４８】
又、上記実施例では、リレーション間の親子関係について、部品とそれに従属する特性値、ポーション、ピンと言った一種類の関係のみを例として説明したが、同一データベース内に複数の親子関係、例えばシンボルとシンボル端子、ネットと信号線の経路情報といった、複数の親子関係が混在してもよい。
【０１４９】
これは、リレーション毎にリレーション間の親子関係を表現でき、且つディレクトリ情報の中のリレーション毎の対応関係が、親リレーションの種類毎に可変であることから容易に類推可能である。
【０１５０】
更に、上記実施例では、説明の簡単化のために、個々のリレーション毎のレコード長は固定長であり、ディレクトリ情報は、データページのファイルとは別ノファイルに格納される例を示した。しかし、データベースで可変長のレコードを格納できるように拡張することは容易である（レコード毎にそのサイズを、空きレコード情報として残りサイズをそれぞれ付加する）。これにより可変長となるディレクトリ情報を親レコードと一体にしたり、あるいは同一ファイル内の別のレコードとして格納するように拡張することも容易である。
【０１５１】
尚、上記実施例におけるリレーションを通したレコードの読み込み（ＳＣＡＮ）及びモジュール単位の読み込み（ｌｏａｄ）に際して、当該レコード集合の全てについて、順次読み込んでいるが、リレーション定義毎にスキーマ情報を管理すると共に、様々なキー値による二次インデックス（Ｂ−ｔｒｅｅやＨａｓｈ等）を設けることにより、ＳＱＬ仕様の柔軟な検索や、更なる高速な検索を実現する拡張は容易である。
【０１５２】
かかるいずれの拡張も本発明の保護の範囲に入るものである。
【０１５３】
【発明の効果】
上記実施例にしたがい説明したように、本発明は、ページマップ情報と、モジュール単位にページマップとの対応情報を管理したディレクトリ情報を利用することにより、モジュール単位のレコードを格納したページを高レベルでクラスタリングすることが可能である。
【０１５４】
これにより、モジュール単位のレコードを高速に主記憶上に読み込むことが可能となる。更に、ディレクトリ情報を伴わずに、ページマップ情報内のページ毎に対応するリレーションの識別により、リレーションを通したデータレコードを走査することもできる。
【図面の簡単な説明】
【図１】本発明の原理構成を説明する図である。
【図２】ＩＣ部品の一例を説明する図である。
【図３】クラスタリングに基づくポーションとピン構成を説明する図である。
【図４】レコード、タップル（型／クラス）をベースとしたリレーションによるクラスタリングを説明する図である。
【図５】モジュール実体（インスタンス）をベースとしたクラスタリングを説明する図である。
【図６】リレーション間の従属関係を説明する図である。
【図７】ＩＣ部品の構成を説明する図である。
【図８】シンボルピンを説明する図である。
【図９】シンボルピンの接続関係を説明する図である。
【図１０】本発明実施例システムの構成例ブロック図である。
【図１１】メタマップ、ページマップ及びデータページの関係図である。
【図１２】ディレクトリのデータ構造を説明する図である。
【図１３】本発明の実施例動作フローである。
【図１４】レコードの読み込み（ｓｃａｎ）処理フローである。
【図１５】レコードの読み込み（ｓｃａｎ）処理の過程におけるデータベースの具体的状態を示す図である。
【図１６】割りつけ（ｌｏｃａｔｅ）処理のフローである。
【図１７】モジュール単位の読み込み（ｌｏａｄ）処理のフローである。
【図１８】ページ所在の概略全体表である。
【図１９】ページマップの全体表である。
【図２０】モジュール単位の読み込み（ｌｏａｄ）の状態を説明する図である。
【図２１】データページの状態を示す図である。
【図２２】挿入（ｉｎｓｅｒｔ）処理のフローである。
【図２３】挿入（ｉｎｓｅｒｔ）処理における空きレコード検索の状態を示す図である。
【図２４】挿入（ｉｎｓｅｒｔ）処理における新規ページ所在と既存ページマップの状態を示す図である。
【図２５】挿入（ｉｎｓｅｒｔ）処理におけるページ所在のページマップ上に空きがない状態を示す図である。
【図２６】削除（ｒｅｍｏｖｅ）処理のフローである。
【図２７】削除（ｒｅｍｏｖｅ）処理における状態を示す図（その１）である。
【図２８】削除（ｒｅｍｏｖｅ）処理における状態を示す図（その２）である。
【図２９】従来のファイル格納技術を説明する図である。
【図３０】従来技術における二次記憶装置へのデータ格納の説明図である。
【符号の説明】
１  二次記憶装置
１０  リレーション定義ファイル
２０  データページファイル
３０  ページマップファイル
４０  メタマップファイル
２  演算処理装置
５０  レコード操作
５１  挿入（ｉｎｓｅｒｔ）
５２  削除（ｒｅｍｏｖｅ）
５３  モジュール単位の読み込み（ｌｏａｄ）
５４  レコードの読み込み（ｓｃａｎ）
５５  割りつけ（ｌｏａｄ）
１１  モジュール間リレーション管理
１０１  リレーション情報
１０２  ディレクトリ管理
１１２  空きレコード管理
１２２  ページ所在管理
２１  データページ管理
３１  ページマップ管理
４１  メタマップ管理
【図１】
0003666907.tif 000002
【図２】
0003666907.tif 000003
【図３】
0003666907.tif 000004
【図４】
0003666907.tif 000005
【図５】
0003666907.tif 000006
【図６】
0003666907.tif 000007
【図７】
0003666907.tif 000008
【図８】
0003666907.tif 000009
【図９】
0003666907.tif 000010
【図１０】
0003666907.tif 000011
【図１１】
0003666907.tif 000012
【図１２】
0003666907.tif 000013
【図１３】
0003666907.tif 000014
【図１４】
0003666907.tif 000015
【図１５】
0003666907.tif 000016
【図１６】
0003666907.tif 000017
【図１７】
0003666907.tif 000018
【図１８】
0003666907.tif 000019
【図１９】
0003666907.tif 000020
【図２０】
0003666907.tif 000021
【図２１】
0003666907.tif 000022
【図２２】
0003666907.tif 000023
【図２３】
0003666907.tif 000024
【図２４】
0003666907.tif 000025
【図２５】
0003666907.tif 000026
【図２６】
0003666907.tif 000027
【図２７】
0003666907.tif 000028
【図２８】
0003666907.tif 000029
【図２９】
0003666907.tif 000030
【図３０】
0003666907.tif 000031