JP4251727B2 - ファイル管理方法 - Google Patents
ファイル管理方法 Download PDFInfo
- Publication number
- JP4251727B2 JP4251727B2 JP19459199A JP19459199A JP4251727B2 JP 4251727 B2 JP4251727 B2 JP 4251727B2 JP 19459199 A JP19459199 A JP 19459199A JP 19459199 A JP19459199 A JP 19459199A JP 4251727 B2 JP4251727 B2 JP 4251727B2
- Authority
- JP
- Japan
- Prior art keywords
- field
- file
- record
- block
- empty
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の属する技術分野】
本発明はファイル管理方法、特にデータベース処理など大量に記憶されたデータから必要なデータだけを効率良く読み出すための改良されたファイル管理方法に関する。
【0002】
【従来の技術】
データがレコード単位に格納されたファイルから所望するデータを取り出す場合、当該データを含むレコード全体を入出力バッファに書き込み、その入出力バッファの中から該当するフィールドのみを切り出す処理が必要であった。つまり、例えば512バイトで1レコードが形成されている場合には、所望するデータが4バイトであっても1レコードすなわち512バイト分をファイルから読み出さなければならなかった。例をあげて説明すると、社員データベースの中から氏名と住所だけを取り出して社員の住所録を作成する場合、上記のデータ読出し方法に従えば社員全員のレコードを入出力バッファへ読み出して、その中から氏名と住所だけを取り出さなければならない。このような方法だと必要以外のデータも読み出さなくてはならず、効率的でないし、処理負荷が無用に増大してしまう。
【0003】
そこで、本願と同一の出願人は、データをレコード単位に読み出すのではなく各レコードにおいてフィールド単位で読み出すことができるようにしたファイル管理方法を提案した(特願平9−319527号、以下「先行文献」)。
【0004】
この管理方法について図9を用いて説明する。元ファイル1には複数のフィールド2から構成されるレコ−ド3が複数格納されているとき、レコード3を一定件数、例えばNレコードずつ分割する。次に、分割した各グループにおいて各レコードの先頭から順に一フィールドずつ分割することによって同一位置すなわち同一項目を格納するために設けられたフィールドをまとめてブロック4を生成する。レコード3においてフィールド2が行方向に並んでいるとしたならば、フィールド2をグループ内において列方向にまとめることでブロック4を生成するということができる。そして、分割した各グループにおいて分割したブロック4を先頭から行方向に順次連結してグループ5を再編成する。これをレコード3の全件について行い、その後グループ5を連結することで転置ファイル6を生成する。
【0005】
このような構成の転置ファイル6を生成することにより、例えば、上記例において各レコード3に含まれる氏名のみを取り出したいときには氏名が記憶されたフィールド2を含むブロック4のみを転置ファイル6から順次読み出せば、社員番号や年齢など氏名以外のデータを社員データベースから読み出す必要がないので、入出力データ量の少ない効率的なデータ読出し処理を行うことができる。
【0006】
なお、転置ファイルの生成処理に関し、元ファイル1に含まれるフィールド2からブロック4が生成されるように図9を用いて説明したが、実際には、図10に示したように論理フィールドから固定長の内部フィールドに変換する処理と、内部フィールドを集めてブロック4を生成する処理という2段階の手順で構成されている。
【0007】
【発明が解決しようとする課題】
しかしながら、先行文献においては、データ読出しに使用する転置ファイルを生成された元ファイルに基づき生成しているので、元ファイルに格納されるレコードフォーマットが変更される度に転置ファイルを生成し直さなければならなかった。
【0008】
本発明は以上のような問題を解決するためになされたものであり、その目的は、元ファイルに格納されるレコードフォーマットが変更された場合でも転置ファイルの再生成を不要とすることができる改良されたファイル管理方法を提供することにある。
【0009】
また、元ファイルのレコードにないフィールドをレコードに付加できるようにすることでシステムにおける利便性の向上を図る改良されたファイル管理方法を提供することにある。
【0010】
【課題を解決するための手段】
以上のような目的を達成するために、本発明に係るファイル管理方法は、複数のフィールドを含むレコードを複数格納した元ファイルの管理を行うファイル管理方法において、元ファイルに格納されたレコードを構成する各フィールドを内部フィールドに変換するフィールド変換ステップと、変換された内部フィールドにより構成される全レコードを、複数の群に分割することによってレコードグループを生成するレコードグループ生成ステップと、各レコードグループにおいて、各レコードにおける同一フィールドが同じグループに含まれるように分割することでブロックを生成するブロック生成ステップと、レコ−ドグループ毎に、当該レコ−ドグループにおいて生成されたブロックを並べて含むグループを生成し、更にその生成したグループを並べて含むファイルを転置ファイルとして生成する転置ファイル生成ステップとを含み、生成された転置ファイルには、各レコードグループを構成する各レコードに対応付けして設けられ元ファイルのレコードに含まれない付加フィールドをそれぞれに含む1又は複数の付加ブロックが各グループに対応付けされて設けられているものである。
【0011】
また、付加フィールドは空きフィールドであり、レコードに対して新たにフィールドを追加する場合、各レコードに対応付けして設けた空きフィールドを当該フィールドに割り当てるものである。
【0012】
更に、元ファイルからのデータ読出し要求に対して転置ファイルの空きブロックへのアクセスを抑止するものである。
【0013】
あるいは、レコードの一部のフィールドを削除する場合、転置ファイルを再生成することなく、当該削除対象となったフィールドに対応した転置ファイル内のフィールドを空きフィールドとして残存させるものである。
【0014】
あるいは、前記フィールド変換ステップは、フィールドを内部フィールドに変換する際に1又は複数の空きフィールドを付加するものである。
【0015】
あるいは、前記転置ファイル生成ステップは、新たなグループを編成する際、当該レコ−ドグループを構成するレコード数分の空きフィールドを含む1又は複数の空きブロックを付加するものである。
【0016】
また、付加フィールドはレコードを識別するための識別情報が付加された制御情報フィールドであり、ユーザレベルのフィールドデータ読出し要求に対しては制御情報フィールドを含む制御情報ブロックへのアクセスを抑止し、システムレベルのフィールドデータ読出し要求に対しては制御情報ブロックから制御情報フィールドを読み出すものである。
【0017】
また、付加フィールドはデータの誤り検出冗長データを格納するための冗長データ格納フィールドであり、システムレベルでの読出し要求に応じて冗長データ格納フィールドを読み出すものである。
【0018】
また、冗長データ格納フィールドを含む冗長データ格納用ブロックを、1又は複数の内部フィールド単位に対応させて1又は複数設けるものである。
【0019】
また、付加フィールドは対応するフィールドに含まれるデータに基づく演算により得られた結果を格納するための演算済みデータ格納フィールドであり、演算済みデータ格納フィールドに当該演算を行った結果を予め設定しておき、当該演算を行うためのフィールドデータ読出し要求に対して演算済みデータ格納フィールドを読み出すものである。
【0020】
【発明の実施の形態】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【0021】
実施の形態1.
図1は、本発明に係るファイル管理方法の実施の形態1に用いられる転置ファイルの生成方法を示すための模式図であり、図2は、元ファイルに含まれているレコードを構成する論理フィールドの構造と本実施の形態におけるファイル管理システムが取り扱う内部フィールドの構造並びに各フィールドの対応関係を示した図である。これらの図及び図3に示したフローチャートを用いて本実施の形態における転置ファイル生成処理について説明する。
【0022】
本実施の形態におけるこの処理の手順自体は、先行文献に記載された手順と基本的には同様である。すなわち、元ファイルの論理フィールドを内部フィールドに変換し、同一の内部フィールドをまとめることでブロックを生成し、そのブロックを連結することで転置ファイルを生成する。以下、この各処理について詳述する。
【0023】
ステップ101において、まず、図2に示したようにレコードを構成するM個の各論理フィールドField0,Field1,...,Field(M-1)をM個の内部フィールドField#0,Field#1,...,Field#(M-1)に変換する。本実施の形態においては、この変換を行う際、更に空きフィールド10を内部フィールドに付加することを特徴としている。また、本実施の形態では、説明の簡略化のために一定長の空きフィールド10を元ファイルのレコードに含まれていない付加フィールドとして内部フィールドの最後尾に1個だけ自動付加することにする。
【0024】
本実施の形態では、説明の簡略化のために各内部フィールドを固定長とするが、処理効率を向上させるために固定境界、例えばワード境界に内部フィールドの区切りを合致させることにしている。つまり、内部フィールドの区切りがワード境界に合致するように必要に応じて空き領域を設け、その空き領域に図2に示したようにpadding(パディング)を挿入する。この空き領域の大きさは、論理フィールド長と固定境界を意識した内部フィールド長との差分に相当する。従って、図2におけるField1とField#1の関係から明らかなように、論理フィールドの対応する内部フィールドの長さがその論理フィールドと一致するとは限らない。なお、図2にはデータの後ろにパディングを挿入した例を示したが、一内部フィールド内におけるパディングの挿入箇所及び数はこの例に限定されるものではない。
【0025】
以上のようにして元ファイルに含まれていたレコードが内部フィールドにより構成されるレコードへ変換されると、次に、変換されたレコードを複数の群に分割することによってレコードグループ11を生成する(ステップ102)。本実施の形態の場合、先行文献と同様に元ファイルを予め決められたNレコードずつに分割して等しい大きさのレコードグループ11を生成するものとする。
【0026】
続いて、各レコードグループ11内においてブロック12を生成する(ステップ103)。これは、各レコードグループ11に対して同じように処理される。また、各レコードグループ11における生成ブロック数は全て同じであり、本実施の形態の場合、レコードを先頭から一内部フィールドずつ行方向へ順番に分割する。そして、分割した同一の内部フィールドをまとめることによってブロック12を生成する。例えば、一のレコードグループ11における先頭のブロック12は、図1に示したように1番目からN番目のレコードにおける同一内部レコードField#0により生成されることになる。端的に言うと、このブロック生成処理は、各レコードを行方向に一内部フィールドずつ分割した後、内部フィールドを列方向にまとめてブロック12を生成することになる。結果として、内部フィールドの数と等しい個数のブロック12が各レコードグループ11において生成されることになる。このとき、本実施の形態の場合、空きフィールド10が付加されているので、空きフィールドのみから構成される空きブロック12aが生成される。本実施の形態のように、固定数Nのレコードで構成されるレコードグループ11を一内部グループずつに分割してブロック12を生成する場合の処理自体は先行文献と同じである。
【0027】
そして、最後に転置ファイルを生成するわけであるが(ステップ104)、ここでは、まず最初に各レコードグループ11において生成されたブロック12を先頭から順番に連結していくことによってグループ13を新たに生成する。図1に基づけば、横(行)方向に並んでいるブロック12をグループというファイルに順番(列方向)に追加登録していくようなイメージである。この処理ではレコードグループ数個のグループ13が作成されることになる。このグループ13の生成処理においては、連結するブロック12が付加的な空きブロック12aであろうとなかろうと各ブロック12を同じように処理するわけであるが、どれが空きブロック12aであるかというフラグ情報で表すことのできるブロック識別情報は内部で保持しておく必要がある。各レコードグループ11に対してブロック生成処理が行われると、各グループ13を連結することで転置ファイル14を生成する。このとき、本実施の形態の場合、空きブロック12aが各グループ13に対応付けされ設けられることになる。なお、レコードグループ11と、レコードグループ11に対応するグループ13とは、それぞれを構成する内部フィールドは同一であるが、内部フィールドの並び順の相違により内部構造が異なるので、異なる符号を付け異なる構成要素として示している。以上のようにして、単一の元ファイルからフィールドが転置した単一の転置ファイル14が生成される。
【0028】
以上のようにして転置ファイル14を事前に生成し、元ファイルからのデータ読出し要求に対して転置ファイル14へアクセスを行う本実施の形態におけるファイル管理方法を使用することにより、データ読出し処理の効率を向上させることができる。次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について説明する。
【0029】
社員データベースの中から「氏名」という論理フィールドField1に格納されているフィールドデータのみを全て取り出したいという要求が送られてきた場合、本実施の形態においては、論理フィールドField1に対応した転置ファイル14内の内部フィールドField#1からデータが入力バッファに取り出されることになる。このとき、内部フィールドField#1はブロック単位にまとめられて格納されているので、ファイル管理システムは、転置ファイル14における各グループ13から内部フィールドField#1を含むブロックのみを読み出せばよい。もし、元ファイルに対して内部フィールドField#1を読出しにいくのであれば、結果として元ファイル全体をアクセスしなければならないが、転置ファイル14では、内部フィールドField#1をまとめてブロック化してあるので、不要なデータを読み出すことなく「氏名」を効率的に読み出すことができる。
【0030】
図4は、SELECT文を実行することにより転置ファイル14から全フィールドデータを入力バッファ15へ読み出したときの概念図である。本実施の形態においては、空きブロック12aを各グループ13に対応付けして自動付加するようにしたが、ファイル管理システムは、全フィールドデータの読出し要求にもかかわらず空きブロック12aへのアクセスを抑止した結果、空きブロック12aを入力バッファ15への読出し対象にしない。これにより、各レコードに空きフィールドを自動付加しても入力バッファ15の領域を余計に消費することはなく、また、データ読出し処理効率を低下させることもない。
【0031】
ここで、元ファイルに格納された論理レコードに対して新たにフィールドを追加する必要が生じたとする。例えば、新たな属性情報が追加されたり、レコードを構成する各フィールドデータ値の合計を同一レコード内で保持したりする場合がこれに相当する。従来であれば、元ファイルのレコードにフィールドが追加されるのだから転置ファイル14を新たに生成し直さなければならなかったところを、本実施の形態では、各レコードに対応付けして空きフィールド10を設けてあるので、その空きフィールド10を当該フィールドに割り当てることができる。これにより、転置ファイル14を生成し直す必要がなく、新たに追加してフィールドデータを転置ファイル14に書き込めばよい。このデータ書き込み処理も極めて容易に行うことができる。
【0032】
空きフィールド10を新たに追加したフィールドに割り当てることで空きブロック12aはもう空きブロックではなくなる。このときに全フィールドデータを入力バッファ15へ読み出すSELECT文を実行すると、ファイル管理システムは、全ブロックBlock#0,Block#1,...,Block#(M-1)及びBlock#Mを転置ファイル14から読み出すことになる。
【0033】
一方、元ファイルに格納された論理レコードから一部のフィールドを削除したい場合、従来であれば、元ファイルのレコードからフィールドが削除されるのだから転置ファイル14を新たに生成し直さなければならなかったところを、本実施の形態では、削除対象のフィールドを空きフィールドとし、転置ファイル14を再生成することはしない。また、削除されたフィールドは、空きフィールドとして転置ファイル14に残されるので、前述したように後に追加されることになるフィールドに割り当てられることになる。
【0034】
本実施の形態によれば、空きフィールドを予め内部フィールドに付加しておき、転置ファイル14に空きブロック12aを含ませておくようにしたので、レコードに新たにフィールドを追加する場合でも転置ファイル14を再生成する必要がない。また、フィールドを削除する際にもそのフィールドを空きフィールドとして転置ファイル14に残しておくようにしたので、転置ファイルを再生成する必要もなく、また、後に追加されることになるフィールドのためにその空きフィールドを利用することができる。また、空きフィールドの取り方にもよるが、ファイルシステムによっては、ディスクの領域を取らないで論理的に場所だけを確保することができるので、このファイルシステムを利用する場合にはディスクスペースの無駄にはならない。
【0035】
なお、本発明は、転置ファイル14に空きブロック12aを予め設けておくことを特徴としている。このために、本実施の形態においては、ステップ101において内部フィールドへの変換時に空きフィールドを追加するようにしたが、ステップ104において各レコードグループ11を構成するレコード数分の空きフィールドを含む空きブロック12aを生成して、各グループ13の生成の際にその空きブロック12aを通常のブロック12に連結するようにしてもよい。
【0036】
また、上記説明においては、空きブロック12aを各グループ13の最後尾に1つ付加するようにしたが、空きフィールドの長さ、数、付加位置は適宜決めることができる。例えば、空きフィールドの用途が予めわかっている場合やレコード種別等によって空きフィールドを多めに確保しておいた方がよい場合などは、それに応じた空きフィールドを設けておけばよい。
【0037】
実施の形態2.
本実施の形態は、付加ブロックとして空きブロックの代わりに制御情報ブロックを設けることを特徴としている。制御情報は、レコードを識別するための情報であり、元ファイルに格納される論理レコードには含まれてなく、システムが内部処理のために付加する情報である。本実施の形態における転置ファイル生成処理は、空きブロックの代わりに制御情報ブロックであること、各グループにおいて付加される位置が最後尾ではなく最前(Block#0)であること以外は同じである。従って、詳細な処理の説明は省略する。なお、この際、どのブロックが制御情報ブロックであるかというブロック識別情報は内部で保持しておく必要がある。実施の形態1において「空きブロック」と認識しているところを「制御情報」と認識するだけの違いである。
【0038】
次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について図5に基づき説明する。
【0039】
基本的な処理は、実施の形態1と同じである。本実施の形態においては、制御情報ブロック12bを各グループ13に自動付加するようにしたが、ファイル管理システムは、外部からユーザレベルの全フィールドデータ読出し要求を受け取ると、その要求に応じてSELECT文16aを実行することにより制御情報を含まない全フィールドデータを入力バッファ15へ読み出す。このように、制御情報をまとめて別途制御情報ブロック12bを設けるようにしたので、システムが勝手に付けた制御情報をユーザレベルの読出し要求の際に読み出されることはない。これにより、入力バッファ15の領域を余計に消費することはなく、また、データ読出し処理効率を低下させることもない。
【0040】
一方、システムレベルの全フィールドデータ読出し要求を受け取ると、その要求に応じてSELECT文16bを実行することにより制御情報「RecID」を含む全フィールドデータを入力バッファ15へ読み出すことができる。
【0041】
本実施の形態によれば、各レコードに対応した制御情報を任意に読み出すことができる。また、制御情報が不要なときには、入力バッファ15に読み出さないように処理することができる。
【0042】
なお、上記説明においては、制御情報ブロック12bを各グループ13の最後尾に1つ付加するようにしたが、制御情報フィールドの長さ、数、付加位置は、その情報の内容によって適宜決めることができればよい。
【0043】
実施の形態3.
本実施の形態は、付加ブロックとして冗長ブロックを設けることを特徴としている。本実施の形態のように同一レコードに含まれるフィールドを分断して取り扱う場合、同一レコードに含まれるフィールドが物理的に異なるディスクブロックに分散して配置されることになる。このため、ハードウェアの故障やソフトウェアの誤りなどによってブロック間の整合性がとれなくなる可能性が生じる。そこで、本実施の形態のように誤り制御用冗長データを含む冗長フィールドから構成される冗長ブロックを追加することにより、このような誤り状態を検出することができる。冗長データの生成方法には種々の誤り検出コードの手法を用いることができる。誤り検出コードの例としては、パリティ、CRC(Cyclic Redunduncy Code)などがある。
【0044】
本実施の形態における転置ファイル生成処理は、空きブロックの代わりに冗長ブロックであること以外は同じである。従って、詳細な処理の説明は省略する。なお、この際、どのブロックが冗長ブロックであるかというブロック識別情報は内部で保持しておく必要がある。実施の形態1において「空きブロック」と認識しているところを「冗長ブロック」と認識するだけの違いである。
【0045】
次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について図6に基づき説明する。
【0046】
基本的な処理は、実施の形態2と同じである。すなわち、ファイル管理システムは、外部からユーザレベルの全フィールドデータ読出し要求を受け取ると、その要求に応じてSELECT文16cを実行することにより冗長データを含まない全フィールドデータを入力バッファ15へ読み出す。このように、冗長データをまとめて、上記冗長ブロックに相当する誤り制御用冗長データ格納ブロック12cを別途設けるようにしたので、システムが使用する冗長データをユーザレベルの読出し要求の際に読み出されることはない。これにより、入力バッファ15の領域を余計に消費することはなく、また、データ読出し処理効率を低下させることもない。
【0047】
一方、システムレベルの全フィールドデータ読出し要求を受け取ると、その要求に応じてSELECT文16dを実行することにより冗長データを含む全フィールドデータを入力バッファ15へ読み出すことができる。
【0048】
本実施の形態によれば、各レコードに対応した冗長データを任意に読み出すことができる。また、冗長データが不要なときには、入力バッファ15に読み出さないように処理することができる。
【0049】
なお、上記説明においては、誤り制御用冗長データ格納ブロック12cを各グループ13の最後尾に1つ付加するようにしたが、冗長データフィールドの長さ、数、付加位置は任意に決めることができる。
【0050】
また、本実施の形態では、グループ13毎に誤り制御用冗長データ格納ブロック12cを設けたが、図7に示したように複数の内部フィールド毎に誤り制御用冗長データ格納ブロック12cを設けるようにしてもよい。これにより、誤りに対する耐性が強くなる。あるいは、グループ13に含まれる全内部フィールドに対してでなく特定の内部フィールドに対してのみ冗長データを付加するようにしてもよく、こうすることで誤り制御用冗長データ格納ブロック12cのデータ量を削減することができる。
【0051】
実施の形態4.
本実施の形態は、付加ブロックとして実施の形態1における空きブロックの代わりに演算済みデータ格納ブロックを設けることを特徴としている。例えば、元ファイルに格納されるレコードには計算可能な数値データが設定されており、実際にフィールドとして設けられていないが各フィールドデータに基づく計算結果(合計値、平均値等)の算出が要求されることが想定できる場合、システムにおいてその演算を行って計算結果を求めておき、その結果を演算済みデータ格納ブロックに予め設定しておくようにした。
【0052】
本実施の形態における転置ファイル生成処理は、空きブロックの代わりに演算済みデータ格納ブロックであること以外は同じである。従って、詳細な処理の説明は省略する。なお、この際、どのブロックが演算済みデータ格納ブロックであるかというブロック識別情報は内部で保持しておく必要がある。実施の形態1において「空きブロック」と認識しているところを「演算済みデータ格納ブロック」と認識するだけの違いである。
【0053】
次に、本実施の形態におけるファイル管理方法に基づくデータの読出し処理について図5に基づき説明する。
【0054】
基本的な処理は、実施の形態1と同じである。本実施の形態において、ファイル管理システムは、全フィールドデータ読出し要求を受け取ると、その要求に応じてSELECT文16eを実行することにより計算結果を含まない全フィールドデータを入力バッファ15へ読み出す。これにより、要求されていない演算済みデータ格納ブロック12dを読み出すことはなく、よって入力バッファ15の領域を余計に消費することはなく、また、データ読出し処理効率を低下させることもない。
【0055】
一方、所定の演算(本実施の形態では合計値を求める場合を例にしている)を行うためにフィールドデータ読出し要求がされたとすると、ファイル管理システムは、その演算を実際に行わずにデータ格納ブロック12dからフィールドデータを入力バッファ15へ読み出す。これにより、所定の演算のためのデータ読出し要求に対して演算に用いる実フィールドデータを読み出す必要がないので読出し処理に要する負荷を軽減することができ、また、演算を行うこともないため読出し要求時における演算処理も軽減でき、かつ演算結果を即座に得ることができる。
【0056】
なお、本実施の形態では、合計値を演算結果の例にして説明したが、平均値等他の演算結果を求める際にも応答することができる。また、上記説明においては、データ格納ブロック12dを各グループ13の最後尾に1つ付加するようにしたが、演算済みデータ格納フィールドの長さ、数、付加位置は、その演算結果として何を扱うかによって適宜決めることができればよい。
【0057】
【発明の効果】
本発明によれば、転置ファイルに予め元ファイルに含まれていない付加フィールドから構成される付加ブロックを含ませるようにしたので、元ファイルに含まれる各レコードに対応して何らかの情報を付加する場合にも転置ファイルを生成し直す必要がない。
【0058】
付加フィールドが空きフィールドである場合、新たなフィールドを追加する際には空きフィールドを当該追加フィールドに割り当てることができるので、新たなフィールドを追加する際にも転置ファイルを生成し直す必要がないため効率的である。
【0059】
また、空きブロックを含む転置ファイルから全フィールドデータを読み出すという要求がされた場合でも、空きブロックをデータ読出し処理の対象外としたので、空きブロックを予め付加しておいても無用な処理負荷及びバッファ容量は発生しない。
【0060】
また、レコードを構成する一部のフィールドを削除する場合でも当該削除対象のフィールドを空きフィールドとして転置ファイルに残存させるようにしたので、転置ファイルを再生成する必要もなく、また、当該空きフィールドを後に追加されるフィールドのために利用することができる。
【0061】
また、付加フィールドが制御情報フィールドである場合、ユーザレベルのフィールドデータ読出し要求に対しては制御情報ブロックへのアクセスを抑止し、システムレベルのフィールドデータ読出し要求に対しては制御情報ブロックから制御情報フィールドを読み出すという効率的な読出し処理を行うことができる。
【0062】
また、付加フィールドが冗長データ格納フィールドである場合、システムレベルでのデータ読出し要求に対して冗長データを読み出すようにすることができる。
【0063】
また、演算結果を予め求めて付加フィールドとして設けた演算済みデータ格納フィールドに設定しておき、当該演算を行うためのデータ読出し要求に対して演算済みデータ格納フィールドを読み出すようにしたので、データ読出し要求時に演算を行う必要もなく即座に演算結果を得ることができる。これにより、演算処理及びデータ読出し処理の負荷の軽減を図ることができる。
【図面の簡単な説明】
【図1】 本発明に係るファイル管理方法の実施の形態1に用いられる転置ファイルの生成方法を示すための模式図である。
【図2】 実施の形態1において元ファイルの論理フィールドと内部フィールドとの対応関係を示したレコード構造図である。
【図3】 実施の形態1における転置ファイル生成処理の流れを示したフローチャートである。
【図4】 実施の形態1において転置ファイルからフィールドデータを入力バッファへ読み出したときの概念図である。
【図5】 実施の形態2において転置ファイルからフィールドデータを入力バッファへ読み出したときの概念図である。
【図6】 実施の形態3において転置ファイルからフィールドデータを入力バッファへ読み出したときの概念図である。
【図7】 実施の形態3に用いられる転置ファイルの生成方法を示すための模式図である。
【図8】 実施の形態4において転置ファイルからフィールドデータを入力バッファへ読み出したときの概念図である。
【図9】 従来のファイル管理方法において転置ファイルの生成方法を示すための模式図である。
【図10】 従来において元ファイルの論理フィールドと内部フィールドとの対応関係を示したレコード構造図である。
【符号の説明】
10 空きフィールド、11 レコードグループ、12 ブロック、12a 空きブロック、12b 制御情報ブロック、12c 誤り制御用冗長データ格納ブロック、12d 演算済みデータ格納ブロック、13 グループ、14 転置ファイル、15 入力バッファ。
Claims (10)
- 複数のフィールドを含むレコードを複数格納した元ファイルの管理を行うファイル管理方法において、
元ファイルに格納されたレコードを構成する各フィールドを内部フィールドに変換するフィールド変換ステップと、
変換された内部フィールドにより構成される全レコードを、複数の群に分割することによってレコードグループを生成するレコードグループ生成ステップと、
各レコードグループにおいて、各レコードにおける同一フィールドが同じグループに含まれるように分割することでブロックを生成するブロック生成ステップと、
レコ−ドグループ毎に、当該レコ−ドグループにおいて生成されたブロックを並べて含むグループを生成し、更にその生成したグループを並べて含むファイルを転置ファイルとして生成する転置ファイル生成ステップと、
を含み、生成された転置ファイルには、各レコードグループを構成する各レコードに対応付けして設けられ元ファイルのレコードに含まれない付加フィールドをそれぞれに含む1又は複数の付加ブロックが各グループに対応付けされて設けられていることを特徴とするファイル管理方法。 - 付加フィールドは空きフィールドであり、レコードに対して新たにフィールドを追加する場合、各レコードに対応付けして設けた空きフィールドを当該フィールドに割り当てることを特徴とする請求項1記載のファイル管理方法。
- 元ファイルからのデータ読出し要求に対して転置ファイルの空きブロックへのアクセスを抑止することを特徴とする請求項2記載のファイル管理方法。
- レコードの一部のフィールドを削除する場合、転置ファイルを再生成することなく、当該削除対象となったフィールドに対応した転置ファイル内のフィールドを空きフィールドとして残存させることを特徴とする請求項2記載のファイル管理方法。
- 前記フィールド変換ステップは、フィールドを内部フィールドに変換する際に1又は複数の空きフィールドを付加することを特徴とする請求項2記載のファイル管理方法。
- 前記転置ファイル生成ステップは、新たなグループを編成する際、当該レコ−ドグループを構成するレコード数分の空きフィールドを含む1又は複数の空きブロックを付加することを特徴とする請求項2記載のファイル管理方法。
- 付加フィールドはレコードを識別するための識別情報が付加された制御情報フィールドであり、ユーザレベルのフィールドデータ読出し要求に対しては制御情報フィールドを含む制御情報ブロックへのアクセスを抑止し、システムレベルのフィールドデータ読出し要求に対しては制御情報ブロックから制御情報フィールドを読み出すことを特徴とする請求項1記載のファイル管理方法。
- 付加フィールドはデータの誤り検出冗長データを格納するための冗長データ格納フィールドであり、システムレベルでの読出し要求に応じて冗長データ格納フィールドを読み出すことを特徴とする請求項1記載のファイル管理方法。
- 冗長データ格納フィールドを含む冗長データ格納用ブロックを、1又は複数の内部フィールド単位に対応させて1又は複数設けることを特徴とする請求項8記載のファイル管理方法。
- 付加フィールドは対応するフィールドに含まれるデータに基づく演算により得られた結果を格納するための演算済みデータ格納フィールドであり、演算済みデータ格納フィールドに当該演算を行った結果を予め設定しておき、当該演算を行うためのフィールドデータ読出し要求に対して演算済みデータ格納フィールドを読み出すことを特徴とする請求項1記載のファイル管理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP19459199A JP4251727B2 (ja) | 1999-07-08 | 1999-07-08 | ファイル管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP19459199A JP4251727B2 (ja) | 1999-07-08 | 1999-07-08 | ファイル管理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2001022623A JP2001022623A (ja) | 2001-01-26 |
JP4251727B2 true JP4251727B2 (ja) | 2009-04-08 |
Family
ID=16327100
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP19459199A Expired - Lifetime JP4251727B2 (ja) | 1999-07-08 | 1999-07-08 | ファイル管理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4251727B2 (ja) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4494892B2 (ja) * | 2004-07-14 | 2010-06-30 | 三菱電機株式会社 | データ処理装置及びプログラム |
WO2008117513A1 (ja) * | 2007-03-23 | 2008-10-02 | Panasonic Corporation | 導電性バンプとその製造方法および電子部品実装構造体 |
-
1999
- 1999-07-08 JP JP19459199A patent/JP4251727B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2001022623A (ja) | 2001-01-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4251726B2 (ja) | ファイル管理方法 | |
EP0166148B1 (en) | Memory assignment method for computer based systems | |
US6725225B1 (en) | Data management apparatus and method for efficiently generating a blocked transposed file and converting that file using a stored compression method | |
US8255398B2 (en) | Compression of sorted value indexes using common prefixes | |
KR101207510B1 (ko) | 클러스터 데이터 관리시스템 및 클러스터 데이터 관리 시스템에서 공유 재수행 로그를 이용한 데이터 재구축 방법 | |
JP3629510B2 (ja) | 拡張カード・ファイル・システム | |
KR100856245B1 (ko) | 파일 시스템 장치 및 그 파일 시스템의 파일 저장 및 파일 탐색 방법 | |
JP2006260582A (ja) | Raidディスクサブシステムと統合されたファイルシステムのファイル割り当て方法 | |
JP3992495B2 (ja) | トリー構造に基づく機能的メモリ | |
JP3407628B2 (ja) | 計算機システム | |
US4630030A (en) | Compression of data for storage | |
KR100907477B1 (ko) | 플래시 메모리에 저장된 데이터의 인덱스 정보 관리 장치및 방법 | |
JP4673299B2 (ja) | 情報処理方法及び情報処理システム | |
JP4251727B2 (ja) | ファイル管理方法 | |
JP2001265628A (ja) | ファイル記録管理システム | |
JP3515810B2 (ja) | ソート処理方法および装置 | |
CN112181973B (zh) | 一种时序数据的存储方法 | |
CN113360095A (zh) | 硬盘数据管理方法、装置、设备及介质 | |
CN115374127B (zh) | 数据存储方法及装置 | |
JP2001022622A (ja) | ファイル管理方法 | |
US20240020277A1 (en) | Implementation for efficient log storage | |
US6154792A (en) | Method and computer program product for paging control using a reference structure including a reference bitmap | |
CN115390758A (zh) | 一种提高raid卡的卷迁移效率的方法、装置、设备及介质 | |
CN118012656A (zh) | 损坏pdf文档修复方法、装置、设备及存储介质 | |
CN113722188A (zh) | 日志服务系统及日志记录的处理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060117 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20060117 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081028 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081218 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090120 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090120 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4251727 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120130 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130130 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130130 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |