(57)【特許請求の範囲】
【請求項１】
少なくとも１つの可変長のフィールドを含むレコードを複数格納した元ファイルの管理を行うファイル管理方法において、
元ファイルに格納されたレコードを構成する各フィールドを内部フィールドに１対１に変換する際、可変長データを含む可変長フィールドをそれぞれ、データの区切りを示す固定境界と区切りが合致する１つの内部フィールドに変換するフィールド変換ステップと、
変換された内部フィールドにより構成される全レコードを、複数の群に分割することによってレコードグループを生成するレコードグループ生成ステップと、
各レコードグループにおいて、各レコードにおける同一フィールドが同じグループに含まれるように分割することでブロックを生成するブロック生成ステップと、
レコ−ドグループ毎に、当該レコ−ドグループにおいて生成されたブロックを並べて含むグループを生成し、更にその生成したグループを並べて含むファイルを転置ファイルとして生成し、更に可変長データを含むブロックの転置ファイルにおける格納位置を特定できるブロック管理情報を生成する転置ファイル生成ステップと、
を含み、元ファイルからの可変長データ読出し要求に対して当該格納位置情報を参照することによって転置ファイルから該当する可変長データを特定して読み出すことを特徴とするファイル管理方法。
【請求項２】
少なくとも１つの可変長のフィールドを含むレコードを複数格納した元ファイルの管理を行うファイル管理方法において、
元ファイルに格納されたレコードを構成する各フィールドを内部フィールドに１対１に変換する際、可変長データを含む可変長フィールドに対して当該可変長データを可変長データ記憶手段に登録するとともに、可変長データ記憶手段における当該可変長データ格納位置情報を内部フィールドに設定するフィールド変換ステップと、
変換された内部フィールドにより構成される全レコードを、複数の群に分割することによってレコードグループを生成するレコードグループ生成ステップと、
各レコードグループにおいて、各レコードにおける同一フィールドが同じグループに含まれるように分割することでブロックを生成するブロック生成ステップと、
レコ−ドグループ毎に、当該レコ−ドグループにおいて生成されたブロックを並べて含むグループを生成し、更にその生成したグループを並べて含むファイルを転置ファイルとして生成する転置ファイル生成ステップと、
を含み、元ファイルからの可変長データ読出し要求に対して転置ファイルに格納された当該可変長データの格納位置情報を参照することによって可変長データ記憶手段に格納された当該可変長データを特定して読み出すことを特徴とするファイル管理方法。
【請求項３】
前記フィールド変換ステップは、内部フィールドに空き領域を付加することによって各内部フィールドの区切りを物理的な処理単位となる境界に合致させることを特徴とする請求項１又は２記載のファイル管理方法。
【請求項４】
前記ブロック生成ステップは、生成したブロックサイズが物理的な最小入出力単位の整数倍と一致しないときには、最小入出力単位の整数倍になるように当該ブロックに空き領域を付加することを特徴とする請求項１又は２記載のファイル管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はファイル管理方法、特に可変長データを取り扱うことのできる改良されたファイル管理方法に関する。
【０００２】
【従来の技術】
データがレコード単位に格納されたファイルから所望するデータを取り出す場合、当該データを含むレコード全体を入出力バッファに書き込み、その入出力バッファの中から該当するフィールドのみを切り出す処理が必要であった。つまり、例えば５１２バイトで１レコードが形成されている場合には、所望するデータが４バイトであっても１レコードすなわち５１２バイト分をファイルから読み出さなければならなかった。例をあげて説明すると、社員データベースの中から氏名と住所だけを取り出して社員の住所録を作成する場合、上記のデータ読出し方法に従えば社員全員のレコードを入出力バッファへ読み出して、その中から氏名と住所だけを取り出さなければならない。このような方法だと必要以外のデータも読み出さなくてはならず、効率的でないし、処理負荷が無用に増大してしまう。
【０００３】
そこで、本願と同一の出願人は、データをレコード単位に読み出すのではなく各レコードにおいてフィールド単位で読み出すことができるようにしたファイル管理方法を提案した（特願平９−３１９５２７号、以下「先行文献」）。
【０００４】
この管理方法について図８を用いて説明する。元ファイル１には複数のフィールド２から構成されるレコ−ド３が複数格納されているとき、レコード３を一定件数、例えばＮレコードずつ分割する。次に、分割した各グループにおいて各レコードの先頭から順に一フィールドずつ分割することによって同一位置すなわち同一項目を格納するために設けられたフィールドをまとめてブロック４を生成する。レコード３においてフィールド２が行方向に並んでいるとしたならば、フィールド２をグループ内において列方向にまとめることでブロック４を生成するということができる。そして、分割した各グループにおいて分割したブロック４を先頭から行方向に順次連結してグループ５を再編成する。これをレコード３の全件について行い、その後グループ５を連結することで転置ファイル６を生成する。
【０００５】
このような構成の転置ファイル６を生成することにより、例えば、上記例において各レコード３に含まれる氏名のみを取り出したいときには氏名が記憶されたフィールド２を含むブロック４のみを転置ファイル６から順次読み出せば、社員番号や年齢など氏名以外のデータを社員データベースから読み出す必要がないので、入出力データ量の少ない効率的なデータ読出し処理を行うことができる。
【０００６】
ところで、先行文献においては、処理速度の高速化を実現するためにブロック４を構成する各フィールド（以下、「内部フィールド」）２を固定長としている。特に、内部フィールド長をワード境界などの固定境界と合致させることでディスク装置に対する物理的な入出力回数が増えないように配慮している。従って、元ファイル１を構成する各フィールド（以下、「論理フィールド」）が可変長である場合、図９に示したように、論理フィールドを１乃至複数の固定境界に従った固定長の内部フィールドに変換していた。そして、論理フィールドのデータで満たされなかった内部フィールド内の領域に対してパディング（ｐａｄｄｉｎｇ）を施している。
【０００７】
なお、転置ファイルの生成処理の説明に関し、元ファイル１に含まれるフィールド２からブロック４が生成されるように図８を用いて上述したが、実際には、図９に示したように論理フィールドから固定長の内部フィールドに変換する処理と、内部フィールドを集めてブロック４を生成する処理という２段階の手順で構成されている。
【０００８】
【発明が解決しようとする課題】
しかしながら、先行文献においては、同一項目を格納するための内部フィールド長は、フィールド内に格納するデータ長に関係なく全レコード共通の長さとなる。上記例に従って説明すると、社員データベースに格納される住所の実際のデータ長は全て同じではないが、先行文献においては、住所データを登録するために同一長であって固定長の内部フィールドが全レコード共通に割り当てられる。例えば、住所データのために１００バイト分の内部フィールドが用意された場合、住所データが４０バイトであっても６０バイトであっても１００バイト分のフィールド長が割り当てられる。
【０００９】
本発明は以上のような問題を解決するためになされたものであり、その目的は、可変長データを可変長フィールドを用いて管理しうる改良されたファイル管理方法を提供することにある。
【００１０】
【課題を解決するための手段】
以上のような目的を達成するために、本発明に係るファイル管理方法は、少なくとも１つの可変長のフィールドを含むレコードを複数格納した元ファイルの管理を行うファイル管理方法において、元ファイルに格納されたレコードを構成する各フィールドを内部フィールドに１対１に変換する際、可変長データを含む可変長フィールドをそれぞれ、データの区切りを示す固定境界と区切りが合致する１つの内部フィールドに変換するフィールド変換ステップと、変換された内部フィールドにより構成される全レコードを、複数の群に分割することによってレコードグループを生成するレコードグループ生成ステップと、各レコードグループにおいて、各レコードにおける同一フィールドが同じグループに含まれるように分割することでブロックを生成するブロック生成ステップと、レコ−ドグループ毎に、当該レコ−ドグループにおいて生成されたブロックを並べて含むグループを生成し、更にその生成したグループを並べて含むファイルを転置ファイルとして生成し、更に可変長データを含むブロックの転置ファイルにおける格納位置を特定できるブロック管理情報を生成する転置ファイル生成ステップとを含み、元ファイルからの可変長データ読出し要求に対して当該格納位置情報を参照することによって転置ファイルから該当する可変長データを特定して読み出すものである。
【００１１】
他の発明に係るファイル管理方法は、少なくとも１つの可変長のフィールドを含むレコードを複数格納した元ファイルの管理を行うファイル管理方法において、元ファイルに格納されたレコードを構成する各フィールドを内部フィールドに１対１に変換する際、可変長データを含む可変長フィールドに対して当該可変長データを可変長データ記憶手段に登録するとともに、可変長データ記憶手段における当該可変長データ格納位置情報を内部フィールドに設定するフィールド変換ステップと、変換された内部フィールドにより構成される全レコードを、複数の群に分割することによってレコードグループを生成するレコードグループ生成ステップと、各レコードグループにおいて、各レコードにおける同一フィールドが同じグループに含まれるように分割することでブロックを生成するブロック生成ステップと、レコ−ドグループ毎に、当該レコ−ドグループにおいて生成されたブロックを並べて含むグループを生成し、更にその生成したグループを並べて含むファイルを転置ファイルとして生成する転置ファイル生成ステップとを含み、元ファイルからの可変長データ読出し要求に対して転置ファイルに格納された当該可変長データの格納位置情報を参照することによって可変長データ記憶手段に格納された当該可変長データを特定して読み出すものである。
【００１２】
また、上記各発明において、前記フィールド変換ステップは、内部フィールドに空き領域を付加することによって各内部フィールドの区切りを物理的な処理単位となる境界に合致させるものである。
【００１３】
また、上記各発明において、前記ブロック生成ステップは、生成したブロックサイズが物理的な最小入出力単位の整数倍と一致しないときには、最小入出力単位の整数倍になるように当該ブロックに空き領域を付加するものである。
【００１４】
【発明の実施の形態】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００１５】
実施の形態１．
図１は、本発明に係るファイル管理方法の実施の形態１に用いられる転置ファイルの生成方法を示すための模式図であり、図２は、元ファイルに含まれているレコードを構成する論理フィールドの構造と本実施の形態におけるファイル管理システムが取り扱う内部フィールドの構造並びに各フィールドの対応関係を示した図である。これらの図及び図３に示したフローチャートを用いて本実施の形態における転置ファイル生成処理について説明する。
【００１６】
本実施の形態におけるこの処理の手順自体は、先行文献に記載された手順と基本的には同様である。すなわち、元ファイルの論理フィールドを内部フィールドに変換し、同一の内部フィールドをまとめることでブロックを生成し、そのブロックを連結することで転置ファイルを生成する。以下、この各処理について詳述する。
【００１７】
ステップ１０１において、まず、図２に示したようにレコードを構成するＭ個の各論理フィールドField0,Field1,...,Field(M-1)をＭ個の内部フィールドField#0,Field#1,...,Field#(M-1)に変換する。本実施の形態における論理フィールドには、図２（ａ）に示したように実際のフィールドデータに加えてフィールド長が付加されており、このため各論理フィールドを可変長に形成することができる。各論理フィールドを内部フィールドに変換する際、内部フィールドの区切りがワード境界に合致するように必要に応じて空き領域を設け、その空き領域に図２（ｂ）に示したようにｐａｄｄｉｎｇ（パディング）を挿入する。これは、処理効率を向上させるためにワード境界などの固定境界に内部フィールドの区切りを合致させるためである。この空き領域の大きさは、論理フィールド長と固定境界を意識した内部フィールド長との差分に相当する。従って、図２（ｂ）におけるField1とField#1の関係から明らかなように、論理フィールドの対応する内部フィールドの長さがその論理フィールドと一致するとは限らない。なお、図２（ｂ）にはデータの後ろにパディングを挿入した例を示したが、一内部フィールド内におけるパディングの挿入箇所及び数はこの例に限定されるものではない。
【００１８】
本実施の形態において特徴的なことは、内部フィールドにより構成されるレコード（以下「内部レコード」ともいう）に含まれる各内部フィールド（Field#0,Field#1,...,Field#(M-1)）の長さが可変であることのみならず、同一内部フィールド、例えば図２（ａ），（ｂ）に示した各Field#1のように各内部レコードにおける同一位置におけるフィールド長をも可変として扱うことができるようにしたことである。これにより、可変長データを可変長のまま取り扱うことができる。上記例に従って説明すると、社員データベースに格納される住所データが４０バイトであれば４０バイト長の内部フィールドを、６０バイトであれば６０バイト長の内部フィールドを割り当てることができるようになる。
【００１９】
以上のようにして元ファイルに含まれていたレコード（以下「論理レコード」ともいう）が内部レコードへ変換されると、次に、内部レコードを複数の群に分割することによってレコードグループ１１を生成する（ステップ１０２）。本実施の形態の場合、先行文献と同様に元ファイルを予め決められたＮレコードずつに分割して等しい大きさのレコードグループ１１を生成するものとする。
【００２０】
続いて、各レコードグループ１１内においてブロック１２を生成する（ステップ１０３）。これは、各レコードグループ１１に対して同じ処理が施される。また、各レコードグループ１１における生成ブロック数は全て同じであり、本実施の形態の場合、内部レコードを先頭から一内部フィールドずつ行方向へ順番に分割する。そして、分割した同一の内部フィールドをまとめることによってブロック１２を生成する。つまり、例えば図１によると、先頭のＮレコードから構成される先頭のレコードグループ１１に含まれる先頭のブロック１２は、１番目からＮ番目の内部レコードにおける同一内部レコードField#0により生成されることになる。端的に言うと、このブロック生成処理は、各内部レコードを行方向に一内部フィールドずつ分割した後、内部フィールドを列方向にまとめてブロック１２を生成する。結果として、内部フィールドの数と等しい個数のブロック１２が各レコードグループ１１において生成されることになる。本実施の形態のように、固定数Ｎのレコードで構成されるレコードグループを一内部グループずつに分割してブロックを生成する場合の処理自体は先行文献と同じである。
【００２１】
ところで、本実施の形態における内部フィールドは、論理フィールドからの変換時にパディングが施されることによって隣接する内部フィールドとの区切りがワード境界に合致するように調整されている。しかし、ブロック１２の大きさが物理的な入出力単位の整数倍となるとは限らない。すなわち、ディスク装置などの記憶装置では、物理的に入出力できる最小単位は固定されている場合が多い。この最小単位を以下、「セクタサイズ」と呼ぶ。ディスク装置に格納されているファイルにアクセスを行うときの入出力単位がセクタサイズの整数倍であれば、記憶装置と入出力バッファとの間で直接入出力を行うことができる。しかし、入出力単位がセクタサイズの整数倍でなければ、ディスク装置内のデータをメモリにいったん読み出した後、改めて入出力バッファにコピーを行うようにしなければ入出力を行えない場合がある。このことは、本実施の形態においても同様なことがいえ、効率的な入出力を行うためにはブロック１２の大きさをセクタサイズの整数倍にすることが望ましい。本実施の形態においては、内部フィールド長をワード境界などの固定境界に合致させるようにはしたが、内部フィールドをまとめて生成するブロック１２の大きさが必ずしもセクタサイズの整数倍になるとは限らない。例えば、セクタサイズが５１２バイト、ワード境界が４バイトである場合、１０バイトの論理フィールドは１２バイトの内部フィールドに変換されるが、このとき１２×４２＋８＝５１２であるから４２レコード分の１２バイト長の内部フィールドをまとめて生成されたブロック１２は、セクタサイズの整数倍にはならない。
【００２２】
そこで、本実施の形態においては、内部フィールドをまとめてブロック１２を生成した結果、そのブロック１２の大きさがセクタサイズの整数倍にならなかったときにはパディングを施してセクタサイズの整数倍となるように調整する。図４は、可変長である一ブロック１２のデータ構造例を示した図であるが、内部フィールドを連結したときのブロックサイズがセクタサイズの整数倍とならない場合には、最終内部フィールドに続けて空き領域１６を設けて、そこにパディングを施す。このようにして、ブロックサイズがセクタサイズの整数倍となるように調整され、このようなブロックサイズの調整を行うようにすることで入出力処理の効率化を図ることができる。
【００２３】
なお、このブロック生成処理においてパディングを挿入するのであれば、内部フィールド内にパディングを施す必要がなくなる。つまり、ブロック１２の生成の元になる論理フィールド長の総和とセクタサイズの整数倍との差異の数のパディングをブロック１２に施せばよいことになる。内部フィールド内にパディングを施さず、内部フィールドの区切りをワード境界に合致させないようにするのであれば、論理フィールドを内部フィールドにマッピング（変換）する必要もなくなる。
【００２４】
最後に、転置ファイルを生成するわけであるが（ステップ１０４）、ここでは、まず各レコードグループ１１において生成されたブロック１２を先頭から順番に連結していくことによってグループ１３を新たに生成する。図１に基づけば、横（行）方向に並んでいるブロック１２をグループというファイルに順番（列方向）に追加登録していくようなイメージである。この処理ではレコードグループ数個のグループ１３が作成されることになる。各レコードグループ１１に対してブロック生成処理が行われると、各グループ１３を連結することで転置ファイル１４を生成する。なお、レコードグループ１１と、レコードグループ１１に対応するグループ１３とは、それぞれを構成する内部フィールドは同一であるが、内部フィールドの並び順の相違により内部構造が異なるので、異なる符号を付け異なる構成要素として示している。
【００２５】
更に、可変長の内部フィールドから構成される各ブロック１２の大きさも可変であるため、ブロック１２を連結する際に各ブロック１２の大きさを特定するための情報を生成しておく必要がある。本実施の形態では、管理ファイル１５を生成し、ブロック管理情報として各グループ１３における各ブロック１２の転置ファイル１４におけるオフセット位置を管理ファイル１５で保持管理するようにした。これにより、転置ファイル１４へアクセスする際には管理ファイル１５に基づき転置ファイル１４における所望するブロック１２の格納位置を特定でき、アクセス対象となるフィールドデータを読み出すことができる。以上のようにして、単一の元ファイルからフィールドが転置した単一の転置ファイル１４が生成される。
【００２６】
本実施の形態では、以上のようにして転置ファイル１４を事前に生成し、元ファイルからのデータ読出し要求に対して転置ファイル１４へアクセスを行うことで処理効率を向上させることを特徴としている。次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について図５に示したフローチャートを用いて説明する。
【００２７】
ファイル管理システムは、要求されたフィールドデータを転置ファイル１４から読み出す。この際、内部処理では、要求されたデータを含むブロックを入出力バッファへ読み出すことになるが、フィールド長が可変の場合その読出し先となる入出力バッファをどのような大きさにするかが問題となる。そこで、本実施の形態では、最大ブロックサイズ（全ブロック１２の最大長）を予め求めておき、その最大ブロックサイズに等しい（あるいは整数倍）の大きさの入出力バッファを用意する。
【００２８】
ファイル管理システムは、入出力バッファを確保すると（ステップ２０１）、管理ファイル１５に設定されている各ブロック１２のオフセットを参照することによって要求されたフィールドデータを格納するブロック位置及びそのブロック１２における格納位置を特定して当該フィールドデータを順次読み出す。すなわち、ファイル管理システムは、管理ファイル１５の読出し位置を先頭グループに位置づけて（ステップ２０２）、当該グループに含まれる各ブロックのオフセットを得る（ステップ２０３）。管理ファイル１５に基づき各ブロック１２のオフセット位置が求まると、ブロック１２内に含まれる内部フィールドの構造及びフィールド長は既知なので、読出し対象となるフィールドデータの格納位置を容易に特定できる（ステップ２０４）。この後は転置ファイル１４の特定したグループ１３において特定したブロック１２から読出し対象とされたフィールドデータを順次読み出せばよい（ステップ２０５〜２０９）。本実施の形態では、転置ファイル１４からの読出し処理を非同期に行っている。そして、先頭のグループに対する処理が終了すると、次のグループに処理を移行し、最終的には転置ファイル１４に含まれる全グループに対して前述した読出し処理を施す（ステップ２１０，２１１）。以上のようにして、各グループ１３へのデータ読出し処理が終了すると、この時点で入出力バッファを解放する（ステップ２１２）。
【００２９】
例えば、社員データベースの中から「住所」という論理フィールドField1に格納されているフィールドデータのみを全て取り出したいという要求が送られてきた場合、本実施の形態においては、論理フィールドField1に対応した転置ファイル１４内の内部フィールドField#1からデータが取り出されることになる。このとき、内部フィールドField#1はブロック単位にまとめられて格納されているので、ファイル管理システムは、転置ファイル１４における各グループ１３から内部フィールドField#1を含むブロックのみを各グループ１３から読み出せばよい。この際、各グループ１３に含まれている内部フィールドField#1のブロック１２の転置ファイル１４における格納位置は、管理ファイル１５を参照することによって特定することができる。もし、元ファイルに対して内部フィールドField#1を読出しにいくのであれば、結果として元ファイル全体をアクセスしなければならないが、転置ファイル１４では、内部フィールドField#1をまとめてブロック化してあるので、不要なデータを読み出すことなく「住所」を効率的に読み出すことができる。
【００３０】
本実施の形態によれば、ブロック管理情報を保持管理するだけで、各ブロック長が可変であってもフィールドデータの読出しを容易に行うことができる。なお、本実施の形態では、管理ファイル１５を別個な構成として設けたが、転置ファイル１４の内部に組み込んでもよいし、障害対策としてレコード数等の情報を管理ファイル１５と転置ファイル１４の双方に持たせて二重化するようにしてもよい。
【００３１】
なお、上記説明では、管理ファイル１５に最大ブロックサイズを設けることで読出し処理の開始前に必要なバッファサイズを確実に確保することができるようにした。もし、可変長データの最大長が制限されているような場合には、管理ファイル１５に最大ブロックサイズを設けずにその最大長に基づき計算により最大ブロックサイズを求めるようにしてもよい。これにより、管理ファイル１５の実装を簡素化できる。あるいは、ブロック１２からフィ−ルドデータを読み出す度に必要な入出力バッファの獲得と解放を繰り返し行うようにしてもよい。これにより、必要最小限のサイズのバッファでメモリを確保することができるので、メモリを効率的に使用することができる。必要なときにバッファの獲得と解放を繰り返し行うように処理することは、特にブロックサイズに極端なばらつきがある場合には効果的である。
【００３２】
また、上記実施の形態では、ブロック管理情報として各ブロック１２のオフセット位置を保持管理するようにしたが、直前のブロックサイズとの差異を保持するようにしてもよい。これにより、管理ファイル１５の大きさを縮小することができる。
【００３３】
また、本実施の形態では、転置ファイル１４からの読出し処理を非同期に行うようにしたが、同時に発行できる非同期読出し要求の数に制限がある場合を想定してこの制限数を考慮した非同期発行制御を行う必要がある。あるいは、同期処理として実行してもよい。
【００３４】
実施の形態２．
上記実施の形態１では、可変長データをそのままブロック１２に組み入れたためブロック自体も可変長となり、ブロックサイズを管理するための管理ファイル１５が必要となった。そこで、本実施の形態では、フィールド長がレコードによって異なってくる可変長である場合、可変長データをブロック１２に組み入れず別途可変長データファイルに格納するとともにブロック１２には可変長データファイルへのポインタ情報を設定するようにした。
【００３５】
図６は、本発明に係るファイル管理方法の実施の形態２に用いられる転置ファイルの生成方法を示すための模式図である。本実施の形態においては、実施の形態１に示した管理ファイル１５を設けずに、可変長データを転置ファイル１４と別個に格納する可変長データ記憶手段として可変長データファイル１７を設けており、また、フィールドデータが通常格納される内部フィールドには、扱うデータが可変長である場合には可変長データファイル１７に格納されている該当する可変長データの格納位置を特定するためにオフセット情報及び可変長データのサイズ情報が格納される。このように、可変長となるデータを別ファイルに格納し、可変長データが格納されるべき内部フィールドには固定長で表現できるオフセット及びサイズのデータを格納するようにしたので、転置ファイル１４を固定長のデータ、すなわち実際の固定長データとオフセット及びサイズで生成することができる。図６には、オフセットとサイズとを別の内部フィールドに設定し、別のブロック１２として生成しているが、オフセットとサイズの各内部フィールドをまとめて１つの可変長データ用ブロック１８として生成するようにしてもよいし、大きいサイズの同一の内部フィールドに設けるようにしてもよい。なお、本実施の形態においても上記実施の形態１と同様に、必要に応じてブロック１２にパディングを施して転置ファイル１４に格納することができる。
【００３６】
本実施の形態における転置ファイル生成処理は、基本的には実施の形態１とほぼ同様である。異なる処理のみを説明すると、ステップ１０１において論理フィールドから内部フィールドへ変換する際、扱うデータが可変長であるときには、その可変長データを内部フィールドに設定するのではなく可変長データファイル１７に追加登録する。その際、可変長データファイル１７における可変長データの格納位置情報として、可変長データファイル１７の先頭からのオフセット情報を取得してサイズ情報（可変長データ長）とともに内部フィールドに設定する。その後の処理は、内部フィールドに含まれるデータが可変長データそのものであるかオフセット及びサイズであるかの相違しかなく実施の形態１と同じである。この結果、転置ファイル１４には、固定長データを含むブロック１２とオフセット情報及びサイズ情報を含む可変長データ用ブロック１８とが含まれることになる。
【００３７】
次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について図７に示したフローチャートを用いて説明する。ここでは、転置ファイル１４から固定長データを読み出す処理については実施の形態１と同様なので、可変長データを読み出す際の処理についてのみ説明する。なお、内部フィールドに含まれているのが固定長データであるかオフセット情報又はサイズ情報であるかは、内部フィールド内に識別フラグを持たせるなどして識別することができる。
【００３８】
ファイル管理システムは、データの読出し要求を受け取ると、転置ファイル１４の先頭グループ１３にポインタ（読出し位置）を位置づけ（ステップ２２１）、読出し対象とされた可変長データに関するオフセット情報及びサイズ情報を含む可変長データ用ブロック１８を図示しない転置ファイル用ブロックバッファに読み出す（ステップ２２２）。そして、転置ファイル用ブロックバッファの先頭レコードにポインタ（処理位置）を位置づけ（ステップ２２３）、読出し対象とされた可変長データに関するオフセット情報及びサイズ情報を読み出す（ステップ２２４）。続いて、読み出したオフセット情報及びサイズ情報に基づきそのオフセット情報により特定される格納位置からサイズ情報で示された大きさのデータを可変長データファイル１７から図示しない可変長データバッファに読み出す（ステップ２２５）。
【００３９】
この後は転置ファイル用ブロックバッファにおいてポインタを次に移し、次のオフセット情報及びそのオフセット情報に対応したサイズ情報を取得して、可変長データファイル１７から可変長データを読み出す処理を繰り返し行う（ステップ２２６，２２７，２２４，２２５）。
【００４０】
転置ファイル用ブロックバッファに読み出した可変長データ用ブロック１８に対して上記処理（ステップ２２４〜２２７）を繰り返し行い、全てのオフセット情報及びサイズ情報に基づく処理が終了すると、転置ファイル１４に未処理のグループ１３がなくなるまで上記処理（ステップ２２２〜２２７）を繰り返し行う（ステップ２２８，２２９）。
【００４１】
本実施の形態によれば、以上のようにして可変長データを扱うことができる。特に、本実施の形態においては、可変長データを転置ファイル１４とは別個に設けた記憶手段に格納し、転置ファイル１４を構成するブロックには固定長で表現できる可変長データのオフセット情報及びサイズ情報を格納するようにしたので、転置ファイルを固定長ブロックに基づき生成することができる。
【００４２】
【発明の効果】
本発明によれば、内部処理において各レコードにおける同一フィールドに対して異なる長さを持つ可変長フィールドを割り当てることができるようにしたので、可変長データを可変長のまま取り扱うことができる。
【００４３】
また、実際の可変長データを別個に設けた可変長データ記憶手段で保持するようにし、転置ファイルに固定長で表現可能なオフセット情報やサイズ情報などの格納位置情報を格納したので、転置ファイルを固定長ブロックに基づき生成することができる。
【００４４】
また、空き領域を内部フィールドに付加することによって各内部フィールドの区切りを物理的な処理単位となる境界に合致させることができるので、効率的な読出し処理を実現することができる。
【００４５】
また、内部フィールドをまとめてブロックを生成した結果、そのブロックサイズが物理的な最小入出力単位の整数倍にならなかったときにはパディングを施してその最小入出力単位の整数倍となるように調整するようにしたので、入出力処理を効率的に行うことができる。
【図面の簡単な説明】
【図１】  本発明に係るファイル管理方法の実施の形態１に用いられる転置ファイルの生成方法を示すための模式図である。
【図２】  実施の形態１において元ファイルの論理フィールドと内部フィールドとの対応関係を示したレコード構造図である。
【図３】  実施の形態１における転置ファイル生成処理の流れを示したフローチャートである。
【図４】  実施の形態１における可変長ブロックのデータ構造例を示した図である。
【図５】  実施の形態１におけるデータ読出し処理を示したフローチャートである。
【図６】  本発明に係るファイル管理方法の実施の形態２に用いられる転置ファイルの生成方法を示すための模式図である。
【図７】  実施の形態２におけるデータ読出し処理を示したフローチャートである。
【図８】  従来のファイル管理方法において転置ファイルの生成方法を示すための模式図である。
【図９】  従来において元ファイルの論理フィールドと内部フィールドとの対応関係を示したレコード構造図である。
【符号の説明】
１１  レコードグループ、１２  ブロック、１３  グループ、１４  転置ファイル、１５  管理ファイル、１６  空き領域、１７  可変長データファイル、１８  可変長データ用ブロック。
【図１】
0004251725.tif 000002
【図２】
0004251725.tif 000003
【図３】
0004251725.tif 000004
【図４】
0004251725.tif 000005
【図５】
0004251725.tif 000006
【図６】
0004251725.tif 000007
【図７】
0004251725.tif 000008
【図８】
0004251725.tif 000009
【図９】
0004251725.tif 000010