(57)【特許請求の範囲】
【請求項１】
複数のフィールドを含むレコードを複数格納した元ファイルの管理を行うファイル管理方法において、
元ファイルに格納されたレコードを構成する各フィールドを内部フィールドに変換するフィールド変換ステップと、
変換された内部フィールドにより構成される全レコードを、複数の群に分割することによってレコードグループを生成するレコードグループ生成ステップと、
各レコードグループにおいて、各レコードにおける同一フィールドが同じグループに含まれるように分割することでブロックを生成するブロック生成ステップと、
レコ−ドグループ毎に、当該レコ−ドグループにおいて生成されたブロックを並べて含むグループを生成し、更にその生成したグループを並べて含むファイルを転置ファイルとして生成する転置ファイル生成ステップと、
を含み、生成された転置ファイルには、各レコードグループを構成する各レコードに対応付けして設けられ元ファイルのレコードに含まれない付加フィールドをそれぞれに含む１又は複数の付加ブロックが各グループに対応付けされて設けられていることを特徴とするファイル管理方法。
【請求項２】
付加フィールドは空きフィールドであり、レコードに対して新たにフィールドを追加する場合、各レコードに対応付けして設けた空きフィールドを当該フィールドに割り当てることを特徴とする請求項１記載のファイル管理方法。
【請求項３】
元ファイルからのデータ読出し要求に対して転置ファイルの空きブロックへのアクセスを抑止することを特徴とする請求項２記載のファイル管理方法。
【請求項４】
レコードの一部のフィールドを削除する場合、転置ファイルを再生成することなく、当該削除対象となったフィールドに対応した転置ファイル内のフィールドを空きフィールドとして残存させることを特徴とする請求項２記載のファイル管理方法。
【請求項５】
前記フィールド変換ステップは、フィールドを内部フィールドに変換する際に１又は複数の空きフィールドを付加することを特徴とする請求項２記載のファイル管理方法。
【請求項６】
前記転置ファイル生成ステップは、新たなグループを編成する際、当該レコ−ドグループを構成するレコード数分の空きフィールドを含む１又は複数の空きブロックを付加することを特徴とする請求項２記載のファイル管理方法。
【請求項７】
付加フィールドはレコードを識別するための識別情報が付加された制御情報フィールドであり、ユーザレベルのフィールドデータ読出し要求に対しては制御情報フィールドを含む制御情報ブロックへのアクセスを抑止し、システムレベルのフィールドデータ読出し要求に対しては制御情報ブロックから制御情報フィールドを読み出すことを特徴とする請求項１記載のファイル管理方法。
【請求項８】
付加フィールドはデータの誤り検出冗長データを格納するための冗長データ格納フィールドであり、システムレベルでの読出し要求に応じて冗長データ格納フィールドを読み出すことを特徴とする請求項１記載のファイル管理方法。
【請求項９】
冗長データ格納フィールドを含む冗長データ格納用ブロックを、１又は複数の内部フィールド単位に対応させて１又は複数設けることを特徴とする請求項８記載のファイル管理方法。
【請求項１０】
付加フィールドは対応するフィールドに含まれるデータに基づく演算により得られた結果を格納するための演算済みデータ格納フィールドであり、演算済みデータ格納フィールドに当該演算を行った結果を予め設定しておき、当該演算を行うためのフィールドデータ読出し要求に対して演算済みデータ格納フィールドを読み出すことを特徴とする請求項１記載のファイル管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はファイル管理方法、特にデータベース処理など大量に記憶されたデータから必要なデータだけを効率良く読み出すための改良されたファイル管理方法に関する。
【０００２】
【従来の技術】
データがレコード単位に格納されたファイルから所望するデータを取り出す場合、当該データを含むレコード全体を入出力バッファに書き込み、その入出力バッファの中から該当するフィールドのみを切り出す処理が必要であった。つまり、例えば５１２バイトで１レコードが形成されている場合には、所望するデータが４バイトであっても１レコードすなわち５１２バイト分をファイルから読み出さなければならなかった。例をあげて説明すると、社員データベースの中から氏名と住所だけを取り出して社員の住所録を作成する場合、上記のデータ読出し方法に従えば社員全員のレコードを入出力バッファへ読み出して、その中から氏名と住所だけを取り出さなければならない。このような方法だと必要以外のデータも読み出さなくてはならず、効率的でないし、処理負荷が無用に増大してしまう。
【０００３】
そこで、本願と同一の出願人は、データをレコード単位に読み出すのではなく各レコードにおいてフィールド単位で読み出すことができるようにしたファイル管理方法を提案した（特願平９−３１９５２７号、以下「先行文献」）。
【０００４】
この管理方法について図９を用いて説明する。元ファイル１には複数のフィールド２から構成されるレコ−ド３が複数格納されているとき、レコード３を一定件数、例えばＮレコードずつ分割する。次に、分割した各グループにおいて各レコードの先頭から順に一フィールドずつ分割することによって同一位置すなわち同一項目を格納するために設けられたフィールドをまとめてブロック４を生成する。レコード３においてフィールド２が行方向に並んでいるとしたならば、フィールド２をグループ内において列方向にまとめることでブロック４を生成するということができる。そして、分割した各グループにおいて分割したブロック４を先頭から行方向に順次連結してグループ５を再編成する。これをレコード３の全件について行い、その後グループ５を連結することで転置ファイル６を生成する。
【０００５】
このような構成の転置ファイル６を生成することにより、例えば、上記例において各レコード３に含まれる氏名のみを取り出したいときには氏名が記憶されたフィールド２を含むブロック４のみを転置ファイル６から順次読み出せば、社員番号や年齢など氏名以外のデータを社員データベースから読み出す必要がないので、入出力データ量の少ない効率的なデータ読出し処理を行うことができる。
【０００６】
なお、転置ファイルの生成処理に関し、元ファイル１に含まれるフィールド２からブロック４が生成されるように図９を用いて説明したが、実際には、図１０に示したように論理フィールドから固定長の内部フィールドに変換する処理と、内部フィールドを集めてブロック４を生成する処理という２段階の手順で構成されている。
【０００７】
【発明が解決しようとする課題】
しかしながら、先行文献においては、データ読出しに使用する転置ファイルを生成された元ファイルに基づき生成しているので、元ファイルに格納されるレコードフォーマットが変更される度に転置ファイルを生成し直さなければならなかった。
【０００８】
本発明は以上のような問題を解決するためになされたものであり、その目的は、元ファイルに格納されるレコードフォーマットが変更された場合でも転置ファイルの再生成を不要とすることができる改良されたファイル管理方法を提供することにある。
【０００９】
また、元ファイルのレコードにないフィールドをレコードに付加できるようにすることでシステムにおける利便性の向上を図る改良されたファイル管理方法を提供することにある。
【００１０】
【課題を解決するための手段】
以上のような目的を達成するために、本発明に係るファイル管理方法は、複数のフィールドを含むレコードを複数格納した元ファイルの管理を行うファイル管理方法において、元ファイルに格納されたレコードを構成する各フィールドを内部フィールドに変換するフィールド変換ステップと、変換された内部フィールドにより構成される全レコードを、複数の群に分割することによってレコードグループを生成するレコードグループ生成ステップと、各レコードグループにおいて、各レコードにおける同一フィールドが同じグループに含まれるように分割することでブロックを生成するブロック生成ステップと、レコ−ドグループ毎に、当該レコ−ドグループにおいて生成されたブロックを並べて含むグループを生成し、更にその生成したグループを並べて含むファイルを転置ファイルとして生成する転置ファイル生成ステップとを含み、生成された転置ファイルには、各レコードグループを構成する各レコードに対応付けして設けられ元ファイルのレコードに含まれない付加フィールドをそれぞれに含む１又は複数の付加ブロックが各グループに対応付けされて設けられているものである。
【００１１】
また、付加フィールドは空きフィールドであり、レコードに対して新たにフィールドを追加する場合、各レコードに対応付けして設けた空きフィールドを当該フィールドに割り当てるものである。
【００１２】
更に、元ファイルからのデータ読出し要求に対して転置ファイルの空きブロックへのアクセスを抑止するものである。
【００１３】
あるいは、レコードの一部のフィールドを削除する場合、転置ファイルを再生成することなく、当該削除対象となったフィールドに対応した転置ファイル内のフィールドを空きフィールドとして残存させるものである。
【００１４】
あるいは、前記フィールド変換ステップは、フィールドを内部フィールドに変換する際に１又は複数の空きフィールドを付加するものである。
【００１５】
あるいは、前記転置ファイル生成ステップは、新たなグループを編成する際、当該レコ−ドグループを構成するレコード数分の空きフィールドを含む１又は複数の空きブロックを付加するものである。
【００１６】
また、付加フィールドはレコードを識別するための識別情報が付加された制御情報フィールドであり、ユーザレベルのフィールドデータ読出し要求に対しては制御情報フィールドを含む制御情報ブロックへのアクセスを抑止し、システムレベルのフィールドデータ読出し要求に対しては制御情報ブロックから制御情報フィールドを読み出すものである。
【００１７】
また、付加フィールドはデータの誤り検出冗長データを格納するための冗長データ格納フィールドであり、システムレベルでの読出し要求に応じて冗長データ格納フィールドを読み出すものである。
【００１８】
また、冗長データ格納フィールドを含む冗長データ格納用ブロックを、１又は複数の内部フィールド単位に対応させて１又は複数設けるものである。
【００１９】
また、付加フィールドは対応するフィールドに含まれるデータに基づく演算により得られた結果を格納するための演算済みデータ格納フィールドであり、演算済みデータ格納フィールドに当該演算を行った結果を予め設定しておき、当該演算を行うためのフィールドデータ読出し要求に対して演算済みデータ格納フィールドを読み出すものである。
【００２０】
【発明の実施の形態】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００２１】
実施の形態１．
図１は、本発明に係るファイル管理方法の実施の形態１に用いられる転置ファイルの生成方法を示すための模式図であり、図２は、元ファイルに含まれているレコードを構成する論理フィールドの構造と本実施の形態におけるファイル管理システムが取り扱う内部フィールドの構造並びに各フィールドの対応関係を示した図である。これらの図及び図３に示したフローチャートを用いて本実施の形態における転置ファイル生成処理について説明する。
【００２２】
本実施の形態におけるこの処理の手順自体は、先行文献に記載された手順と基本的には同様である。すなわち、元ファイルの論理フィールドを内部フィールドに変換し、同一の内部フィールドをまとめることでブロックを生成し、そのブロックを連結することで転置ファイルを生成する。以下、この各処理について詳述する。
【００２３】
ステップ１０１において、まず、図２に示したようにレコードを構成するＭ個の各論理フィールドField0,Field1,...,Field(M-1)をＭ個の内部フィールドField#0,Field#1,...,Field#(M-1)に変換する。本実施の形態においては、この変換を行う際、更に空きフィールド１０を内部フィールドに付加することを特徴としている。また、本実施の形態では、説明の簡略化のために一定長の空きフィールド１０を元ファイルのレコードに含まれていない付加フィールドとして内部フィールドの最後尾に１個だけ自動付加することにする。
【００２４】
本実施の形態では、説明の簡略化のために各内部フィールドを固定長とするが、処理効率を向上させるために固定境界、例えばワード境界に内部フィールドの区切りを合致させることにしている。つまり、内部フィールドの区切りがワード境界に合致するように必要に応じて空き領域を設け、その空き領域に図２に示したようにｐａｄｄｉｎｇ（パディング）を挿入する。この空き領域の大きさは、論理フィールド長と固定境界を意識した内部フィールド長との差分に相当する。従って、図２におけるField1とField#1の関係から明らかなように、論理フィールドの対応する内部フィールドの長さがその論理フィールドと一致するとは限らない。なお、図２にはデータの後ろにパディングを挿入した例を示したが、一内部フィールド内におけるパディングの挿入箇所及び数はこの例に限定されるものではない。
【００２５】
以上のようにして元ファイルに含まれていたレコードが内部フィールドにより構成されるレコードへ変換されると、次に、変換されたレコードを複数の群に分割することによってレコードグループ１１を生成する（ステップ１０２）。本実施の形態の場合、先行文献と同様に元ファイルを予め決められたＮレコードずつに分割して等しい大きさのレコードグループ１１を生成するものとする。
【００２６】
続いて、各レコードグループ１１内においてブロック１２を生成する（ステップ１０３）。これは、各レコードグループ１１に対して同じように処理される。また、各レコードグループ１１における生成ブロック数は全て同じであり、本実施の形態の場合、レコードを先頭から一内部フィールドずつ行方向へ順番に分割する。そして、分割した同一の内部フィールドをまとめることによってブロック１２を生成する。例えば、一のレコードグループ１１における先頭のブロック１２は、図１に示したように１番目からＮ番目のレコードにおける同一内部レコードField#0により生成されることになる。端的に言うと、このブロック生成処理は、各レコードを行方向に一内部フィールドずつ分割した後、内部フィールドを列方向にまとめてブロック１２を生成することになる。結果として、内部フィールドの数と等しい個数のブロック１２が各レコードグループ１１において生成されることになる。このとき、本実施の形態の場合、空きフィールド１０が付加されているので、空きフィールドのみから構成される空きブロック１２ａが生成される。本実施の形態のように、固定数Ｎのレコードで構成されるレコードグループ１１を一内部グループずつに分割してブロック１２を生成する場合の処理自体は先行文献と同じである。
【００２７】
そして、最後に転置ファイルを生成するわけであるが（ステップ１０４）、ここでは、まず最初に各レコードグループ１１において生成されたブロック１２を先頭から順番に連結していくことによってグループ１３を新たに生成する。図１に基づけば、横（行）方向に並んでいるブロック１２をグループというファイルに順番（列方向）に追加登録していくようなイメージである。この処理ではレコードグループ数個のグループ１３が作成されることになる。このグループ１３の生成処理においては、連結するブロック１２が付加的な空きブロック１２ａであろうとなかろうと各ブロック１２を同じように処理するわけであるが、どれが空きブロック１２ａであるかというフラグ情報で表すことのできるブロック識別情報は内部で保持しておく必要がある。各レコードグループ１１に対してブロック生成処理が行われると、各グループ１３を連結することで転置ファイル１４を生成する。このとき、本実施の形態の場合、空きブロック１２ａが各グループ１３に対応付けされ設けられることになる。なお、レコードグループ１１と、レコードグループ１１に対応するグループ１３とは、それぞれを構成する内部フィールドは同一であるが、内部フィールドの並び順の相違により内部構造が異なるので、異なる符号を付け異なる構成要素として示している。以上のようにして、単一の元ファイルからフィールドが転置した単一の転置ファイル１４が生成される。
【００２８】
以上のようにして転置ファイル１４を事前に生成し、元ファイルからのデータ読出し要求に対して転置ファイル１４へアクセスを行う本実施の形態におけるファイル管理方法を使用することにより、データ読出し処理の効率を向上させることができる。次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について説明する。
【００２９】
社員データベースの中から「氏名」という論理フィールドField1に格納されているフィールドデータのみを全て取り出したいという要求が送られてきた場合、本実施の形態においては、論理フィールドField1に対応した転置ファイル１４内の内部フィールドField#1からデータが入力バッファに取り出されることになる。このとき、内部フィールドField#1はブロック単位にまとめられて格納されているので、ファイル管理システムは、転置ファイル１４における各グループ１３から内部フィールドField#1を含むブロックのみを読み出せばよい。もし、元ファイルに対して内部フィールドField#1を読出しにいくのであれば、結果として元ファイル全体をアクセスしなければならないが、転置ファイル１４では、内部フィールドField#1をまとめてブロック化してあるので、不要なデータを読み出すことなく「氏名」を効率的に読み出すことができる。
【００３０】
図４は、ＳＥＬＥＣＴ文を実行することにより転置ファイル１４から全フィールドデータを入力バッファ１５へ読み出したときの概念図である。本実施の形態においては、空きブロック１２ａを各グループ１３に対応付けして自動付加するようにしたが、ファイル管理システムは、全フィールドデータの読出し要求にもかかわらず空きブロック１２ａへのアクセスを抑止した結果、空きブロック１２ａを入力バッファ１５への読出し対象にしない。これにより、各レコードに空きフィールドを自動付加しても入力バッファ１５の領域を余計に消費することはなく、また、データ読出し処理効率を低下させることもない。
【００３１】
ここで、元ファイルに格納された論理レコードに対して新たにフィールドを追加する必要が生じたとする。例えば、新たな属性情報が追加されたり、レコードを構成する各フィールドデータ値の合計を同一レコード内で保持したりする場合がこれに相当する。従来であれば、元ファイルのレコードにフィールドが追加されるのだから転置ファイル１４を新たに生成し直さなければならなかったところを、本実施の形態では、各レコードに対応付けして空きフィールド１０を設けてあるので、その空きフィールド１０を当該フィールドに割り当てることができる。これにより、転置ファイル１４を生成し直す必要がなく、新たに追加してフィールドデータを転置ファイル１４に書き込めばよい。このデータ書き込み処理も極めて容易に行うことができる。
【００３２】
空きフィールド１０を新たに追加したフィールドに割り当てることで空きブロック１２ａはもう空きブロックではなくなる。このときに全フィールドデータを入力バッファ１５へ読み出すＳＥＬＥＣＴ文を実行すると、ファイル管理システムは、全ブロックBlock#0,Block#1,...,Block#(M-1)及びBlock#Mを転置ファイル１４から読み出すことになる。
【００３３】
一方、元ファイルに格納された論理レコードから一部のフィールドを削除したい場合、従来であれば、元ファイルのレコードからフィールドが削除されるのだから転置ファイル１４を新たに生成し直さなければならなかったところを、本実施の形態では、削除対象のフィールドを空きフィールドとし、転置ファイル１４を再生成することはしない。また、削除されたフィールドは、空きフィールドとして転置ファイル１４に残されるので、前述したように後に追加されることになるフィールドに割り当てられることになる。
【００３４】
本実施の形態によれば、空きフィールドを予め内部フィールドに付加しておき、転置ファイル１４に空きブロック１２ａを含ませておくようにしたので、レコードに新たにフィールドを追加する場合でも転置ファイル１４を再生成する必要がない。また、フィールドを削除する際にもそのフィールドを空きフィールドとして転置ファイル１４に残しておくようにしたので、転置ファイルを再生成する必要もなく、また、後に追加されることになるフィールドのためにその空きフィールドを利用することができる。また、空きフィールドの取り方にもよるが、ファイルシステムによっては、ディスクの領域を取らないで論理的に場所だけを確保することができるので、このファイルシステムを利用する場合にはディスクスペースの無駄にはならない。
【００３５】
なお、本発明は、転置ファイル１４に空きブロック１２ａを予め設けておくことを特徴としている。このために、本実施の形態においては、ステップ１０１において内部フィールドへの変換時に空きフィールドを追加するようにしたが、ステップ１０４において各レコードグループ１１を構成するレコード数分の空きフィールドを含む空きブロック１２ａを生成して、各グループ１３の生成の際にその空きブロック１２ａを通常のブロック１２に連結するようにしてもよい。
【００３６】
また、上記説明においては、空きブロック１２ａを各グループ１３の最後尾に１つ付加するようにしたが、空きフィールドの長さ、数、付加位置は適宜決めることができる。例えば、空きフィールドの用途が予めわかっている場合やレコード種別等によって空きフィールドを多めに確保しておいた方がよい場合などは、それに応じた空きフィールドを設けておけばよい。
【００３７】
実施の形態２．
本実施の形態は、付加ブロックとして空きブロックの代わりに制御情報ブロックを設けることを特徴としている。制御情報は、レコードを識別するための情報であり、元ファイルに格納される論理レコードには含まれてなく、システムが内部処理のために付加する情報である。本実施の形態における転置ファイル生成処理は、空きブロックの代わりに制御情報ブロックであること、各グループにおいて付加される位置が最後尾ではなく最前(Block#0)であること以外は同じである。従って、詳細な処理の説明は省略する。なお、この際、どのブロックが制御情報ブロックであるかというブロック識別情報は内部で保持しておく必要がある。実施の形態１において「空きブロック」と認識しているところを「制御情報」と認識するだけの違いである。
【００３８】
次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について図５に基づき説明する。
【００３９】
基本的な処理は、実施の形態１と同じである。本実施の形態においては、制御情報ブロック１２ｂを各グループ１３に自動付加するようにしたが、ファイル管理システムは、外部からユーザレベルの全フィールドデータ読出し要求を受け取ると、その要求に応じてＳＥＬＥＣＴ文１６ａを実行することにより制御情報を含まない全フィールドデータを入力バッファ１５へ読み出す。このように、制御情報をまとめて別途制御情報ブロック１２ｂを設けるようにしたので、システムが勝手に付けた制御情報をユーザレベルの読出し要求の際に読み出されることはない。これにより、入力バッファ１５の領域を余計に消費することはなく、また、データ読出し処理効率を低下させることもない。
【００４０】
一方、システムレベルの全フィールドデータ読出し要求を受け取ると、その要求に応じてＳＥＬＥＣＴ文１６ｂを実行することにより制御情報「ＲｅｃＩＤ」を含む全フィールドデータを入力バッファ１５へ読み出すことができる。
【００４１】
本実施の形態によれば、各レコードに対応した制御情報を任意に読み出すことができる。また、制御情報が不要なときには、入力バッファ１５に読み出さないように処理することができる。
【００４２】
なお、上記説明においては、制御情報ブロック１２ｂを各グループ１３の最後尾に１つ付加するようにしたが、制御情報フィールドの長さ、数、付加位置は、その情報の内容によって適宜決めることができればよい。
【００４３】
実施の形態３．
本実施の形態は、付加ブロックとして冗長ブロックを設けることを特徴としている。本実施の形態のように同一レコードに含まれるフィールドを分断して取り扱う場合、同一レコードに含まれるフィールドが物理的に異なるディスクブロックに分散して配置されることになる。このため、ハードウェアの故障やソフトウェアの誤りなどによってブロック間の整合性がとれなくなる可能性が生じる。そこで、本実施の形態のように誤り制御用冗長データを含む冗長フィールドから構成される冗長ブロックを追加することにより、このような誤り状態を検出することができる。冗長データの生成方法には種々の誤り検出コードの手法を用いることができる。誤り検出コードの例としては、パリティ、ＣＲＣ(Cyclic Redunduncy Code)などがある。
【００４４】
本実施の形態における転置ファイル生成処理は、空きブロックの代わりに冗長ブロックであること以外は同じである。従って、詳細な処理の説明は省略する。なお、この際、どのブロックが冗長ブロックであるかというブロック識別情報は内部で保持しておく必要がある。実施の形態１において「空きブロック」と認識しているところを「冗長ブロック」と認識するだけの違いである。
【００４５】
次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について図６に基づき説明する。
【００４６】
基本的な処理は、実施の形態２と同じである。すなわち、ファイル管理システムは、外部からユーザレベルの全フィールドデータ読出し要求を受け取ると、その要求に応じてＳＥＬＥＣＴ文１６ｃを実行することにより冗長データを含まない全フィールドデータを入力バッファ１５へ読み出す。このように、冗長データをまとめて、上記冗長ブロックに相当する誤り制御用冗長データ格納ブロック１２ｃを別途設けるようにしたので、システムが使用する冗長データをユーザレベルの読出し要求の際に読み出されることはない。これにより、入力バッファ１５の領域を余計に消費することはなく、また、データ読出し処理効率を低下させることもない。
【００４７】
一方、システムレベルの全フィールドデータ読出し要求を受け取ると、その要求に応じてＳＥＬＥＣＴ文１６ｄを実行することにより冗長データを含む全フィールドデータを入力バッファ１５へ読み出すことができる。
【００４８】
本実施の形態によれば、各レコードに対応した冗長データを任意に読み出すことができる。また、冗長データが不要なときには、入力バッファ１５に読み出さないように処理することができる。
【００４９】
なお、上記説明においては、誤り制御用冗長データ格納ブロック１２ｃを各グループ１３の最後尾に１つ付加するようにしたが、冗長データフィールドの長さ、数、付加位置は任意に決めることができる。
【００５０】
また、本実施の形態では、グループ１３毎に誤り制御用冗長データ格納ブロック１２ｃを設けたが、図７に示したように複数の内部フィールド毎に誤り制御用冗長データ格納ブロック１２ｃを設けるようにしてもよい。これにより、誤りに対する耐性が強くなる。あるいは、グループ１３に含まれる全内部フィールドに対してでなく特定の内部フィールドに対してのみ冗長データを付加するようにしてもよく、こうすることで誤り制御用冗長データ格納ブロック１２ｃのデータ量を削減することができる。
【００５１】
実施の形態４．
本実施の形態は、付加ブロックとして実施の形態１における空きブロックの代わりに演算済みデータ格納ブロックを設けることを特徴としている。例えば、元ファイルに格納されるレコードには計算可能な数値データが設定されており、実際にフィールドとして設けられていないが各フィールドデータに基づく計算結果（合計値、平均値等）の算出が要求されることが想定できる場合、システムにおいてその演算を行って計算結果を求めておき、その結果を演算済みデータ格納ブロックに予め設定しておくようにした。
【００５２】
本実施の形態における転置ファイル生成処理は、空きブロックの代わりに演算済みデータ格納ブロックであること以外は同じである。従って、詳細な処理の説明は省略する。なお、この際、どのブロックが演算済みデータ格納ブロックであるかというブロック識別情報は内部で保持しておく必要がある。実施の形態１において「空きブロック」と認識しているところを「演算済みデータ格納ブロック」と認識するだけの違いである。
【００５３】
次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について図５に基づき説明する。
【００５４】
基本的な処理は、実施の形態１と同じである。本実施の形態において、ファイル管理システムは、全フィールドデータ読出し要求を受け取ると、その要求に応じてＳＥＬＥＣＴ文１６ｅを実行することにより計算結果を含まない全フィールドデータを入力バッファ１５へ読み出す。これにより、要求されていない演算済みデータ格納ブロック１２ｄを読み出すことはなく、よって入力バッファ１５の領域を余計に消費することはなく、また、データ読出し処理効率を低下させることもない。
【００５５】
一方、所定の演算（本実施の形態では合計値を求める場合を例にしている）を行うためにフィールドデータ読出し要求がされたとすると、ファイル管理システムは、その演算を実際に行わずにデータ格納ブロック１２ｄからフィールドデータを入力バッファ１５へ読み出す。これにより、所定の演算のためのデータ読出し要求に対して演算に用いる実フィールドデータを読み出す必要がないので読出し処理に要する負荷を軽減することができ、また、演算を行うこともないため読出し要求時における演算処理も軽減でき、かつ演算結果を即座に得ることができる。
【００５６】
なお、本実施の形態では、合計値を演算結果の例にして説明したが、平均値等他の演算結果を求める際にも応答することができる。また、上記説明においては、データ格納ブロック１２ｄを各グループ１３の最後尾に１つ付加するようにしたが、演算済みデータ格納フィールドの長さ、数、付加位置は、その演算結果として何を扱うかによって適宜決めることができればよい。
【００５７】
【発明の効果】
本発明によれば、転置ファイルに予め元ファイルに含まれていない付加フィールドから構成される付加ブロックを含ませるようにしたので、元ファイルに含まれる各レコードに対応して何らかの情報を付加する場合にも転置ファイルを生成し直す必要がない。
【００５８】
付加フィールドが空きフィールドである場合、新たなフィールドを追加する際には空きフィールドを当該追加フィールドに割り当てることができるので、新たなフィールドを追加する際にも転置ファイルを生成し直す必要がないため効率的である。
【００５９】
また、空きブロックを含む転置ファイルから全フィールドデータを読み出すという要求がされた場合でも、空きブロックをデータ読出し処理の対象外としたので、空きブロックを予め付加しておいても無用な処理負荷及びバッファ容量は発生しない。
【００６０】
また、レコードを構成する一部のフィールドを削除する場合でも当該削除対象のフィールドを空きフィールドとして転置ファイルに残存させるようにしたので、転置ファイルを再生成する必要もなく、また、当該空きフィールドを後に追加されるフィールドのために利用することができる。
【００６１】
また、付加フィールドが制御情報フィールドである場合、ユーザレベルのフィールドデータ読出し要求に対しては制御情報ブロックへのアクセスを抑止し、システムレベルのフィールドデータ読出し要求に対しては制御情報ブロックから制御情報フィールドを読み出すという効率的な読出し処理を行うことができる。
【００６２】
また、付加フィールドが冗長データ格納フィールドである場合、システムレベルでのデータ読出し要求に対して冗長データを読み出すようにすることができる。
【００６３】
また、演算結果を予め求めて付加フィールドとして設けた演算済みデータ格納フィールドに設定しておき、当該演算を行うためのデータ読出し要求に対して演算済みデータ格納フィールドを読み出すようにしたので、データ読出し要求時に演算を行う必要もなく即座に演算結果を得ることができる。これにより、演算処理及びデータ読出し処理の負荷の軽減を図ることができる。
【図面の簡単な説明】
【図１】  本発明に係るファイル管理方法の実施の形態１に用いられる転置ファイルの生成方法を示すための模式図である。
【図２】  実施の形態１において元ファイルの論理フィールドと内部フィールドとの対応関係を示したレコード構造図である。
【図３】  実施の形態１における転置ファイル生成処理の流れを示したフローチャートである。
【図４】  実施の形態１において転置ファイルからフィールドデータを入力バッファへ読み出したときの概念図である。
【図５】  実施の形態２において転置ファイルからフィールドデータを入力バッファへ読み出したときの概念図である。
【図６】  実施の形態３において転置ファイルからフィールドデータを入力バッファへ読み出したときの概念図である。
【図７】  実施の形態３に用いられる転置ファイルの生成方法を示すための模式図である。
【図８】  実施の形態４において転置ファイルからフィールドデータを入力バッファへ読み出したときの概念図である。
【図９】  従来のファイル管理方法において転置ファイルの生成方法を示すための模式図である。
【図１０】  従来において元ファイルの論理フィールドと内部フィールドとの対応関係を示したレコード構造図である。
【符号の説明】
１０  空きフィールド、１１  レコードグループ、１２  ブロック、１２ａ  空きブロック、１２ｂ  制御情報ブロック、１２ｃ  誤り制御用冗長データ格納ブロック、１２ｄ  演算済みデータ格納ブロック、１３  グループ、１４  転置ファイル、１５  入力バッファ。
【図１】
0004251727.tif 000002
【図２】
0004251727.tif 000003
【図３】
0004251727.tif 000004
【図４】
0004251727.tif 000005
【図５】
0004251727.tif 000006
【図６】
0004251727.tif 000007
【図７】
0004251727.tif 000008
【図８】
0004251727.tif 000009
【図９】
0004251727.tif 000010
【図１０】
0004251727.tif 000011