(57)【要約】【課題】複数のフィールドで構成された表データにおいて、それらのフィールドの更新が多い場合であっても、検索効率及びデータ格納効率を維持することができるインデクス管理の技術を提供することを目的とする。【解決手段】コンピュータ上で複数のフィールド（列）を備える表データを管理する際に、管理対象の表データに対し、更新頻度の高い列についてはインデクス作成の対象から除外し、それ以外の更新頻度の低い列についてはインデクス作成対象として、インデクスを作成する。検索の際には、指示された探索条件が更新頻度の低い列についての探索条件を含むかどうかチェックし、含む場合は、そのインデクスを利用した探索を行なうようにする。インデクスを利用した検索で高速にレコードを絞り込み、その絞り込んだレコードを対象として、インデクス構成から除外した更新頻度の高い列に関する探索条件で順検索により探索を行なう。【選択図】図６
2008015810.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ上で複数のフィールド（列）を備える表データを管理するためのインデクス分割管理方法であって、
コンピュータが備えるインデクス作成手段が、前記管理対象の表データに対し、所定の基準値以上に更新頻度の高いフィールドについてはインデクス作成の対象から除外し、それ以外の所定の基準値未満に更新頻度の低いフィールドについてはインデクス作成対象として、インデクスを作成するステップと、
コンピュータが備える検索手段が、指示された探索条件が前記所定の基準値未満に更新頻度の低いフィールドについての探索条件を含む場合は、前記インデクスを利用した探索を行なうステップと
を備えることを特徴とする複数列の表データにおけるインデクス分割管理方法。
【請求項２】
請求項１に記載の複数列の表データにおけるインデクス分割管理方法において、
コンピュータが備える更新手段が、
指示された更新条件が前記所定の基準値未満に更新頻度の低いフィールドについての更新条件を含む場合は、前記フィールドの更新を行なった後に前記インデクスを再作成するステップと、
前記指示された更新条件が前記所定の基準値以上に更新頻度の高いフィールドについての更新条件のみを含む場合は、前記フィールドの更新のみを行なうステップと、
を備えることを特徴とする複数列の表データにおけるインデクス分割管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の列で構成された表のデータを、該表に格納されているデータに対して定義されたインデクスで、データの更新頻度別に分割管理する技術に関するものである。
【背景技術】
【０００２】
従来のデータベース管理システム（DataBase Management System: DBMS）では、データを表に登録して管理する。その表は、レコード（行）とフィールド（列）で構成される。指定されたデータを検索する場合、レコードを格納した順に検索を行うため、登録したレコード件数が大量の場合は容易に抽出できない。そこで、大量に登録されているデータの検索効率を向上させるため、表に登録されているデータに対して索引（インデクス）を作成する方法が利用されている。
【０００３】
なお、本発明に関連する公知技術文献としては下記の特許文献１がある。該文献には、CSVファイル等の被検索ファイルが大規模なものとなった場合でも効率的かつ高速にデータ抽出を行うためにインデクスファイルを用いて検索する技術が開示されている。
【特許文献１】特開２００３−１６２５４５
【発明の開示】
【発明が解決しようとする課題】
【０００４】
インデクスを作成するにあたり、上記特許文献１によると、表に登録されているデータは予め整列し、各フィールドごとに対してインデクスを作成する必要がある。しかし、表に登録されているレコード及びデータは絶えず更新されるものであるため、インデクス管理情報も頻繁に変更されることとなり、そのためにインデクス情報を使った検索とそのデータの格納効率が下がり、有用な効果が得られない。
【０００５】
そこで、B-Tree（Binary-Tree）によるインデクス探索手法が考えられている。この手法を用いることで、表のレコードの格納順序に関係なく、整列されたデータとして探索することができる。B-Tree（Binary-Tree）によるインデクス探索手法で用いる木構造のインデクスのことをインデクスツリーと呼ぶ。インデクスツリーは、複数のフィールドを対象にして構成することができ、これによりデータの検索効率を上げることができる。
【０００６】
ところが、前述したように、表に登録されているレコードは絶えず更新されているため、それに伴いインデクスツリーも絶えず更新されることになる。このため、インデクスツリー構造が乱れ、指定したデータを検索するときの効率が低下してしまう。さらに、データの格納領域の断片化が発生するため、データの格納領域の再構成が必要となる頻度が高くなる。データの格納領域を再構成する場合は、業務を一度中断することになるため、業務の中断期間が長くなってしまう。
【０００７】
本発明の目的は、複数のフィールドで構成された表データにおいて、それらのフィールドの更新が多い場合であっても、検索効率及びデータ格納効率を維持することができるインデクス管理の技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、本発明のインデクス分割管理方式は、コンピュータ上で複数のフィールド（列）を備える表データを管理する際に、管理対象の表データに対し、所定の基準値以上に更新頻度の高いフィールドについてはインデクス作成の対象から除外し、それ以外の所定の基準値未満に更新頻度の低いフィールドについてはインデクス作成対象として、インデクスを作成することを特徴とする。そして、検索の際には、指示された探索条件が前記所定の基準値未満に更新頻度の低いフィールドについての探索条件を含むかどうかチェックし、含む場合は、そのインデクスを利用した探索を行なうようにする。具体的には、指示された探索条件が所定の基準値未満に更新頻度の低いフィールドについての探索条件のみからなる場合は、インデクスを利用した探索で、指示された探索条件を満たすレコードが探索できる。また、指示された探索条件が所定の基準値未満に更新頻度の低いフィールドについての探索条件と所定の基準値以上に更新頻度の高いフィールドについての探索条件の両方を含む場合は、まずインデクスを利用した探索で更新頻度の低いフィールドについての探索条件を満たすレコードに絞り込み、絞り込んだレコードを順検索して更新頻度の高いフィールドについての探索条件を満たすレコードを探索する。
【０００９】
さらに、データの更新時には、指示された更新条件が前記所定の基準値未満に更新頻度の低いフィールドについての更新条件を含む場合は、前記フィールドの更新を行なった後に前記インデクスを再作成し、指示された更新条件が前記所定の基準値以上に更新頻度の高いフィールドについての更新条件のみを含む場合は、前記フィールドの更新のみを行なうようにする。
【００１０】
上記インデクスは、例えば、インデクスの作成対象のフィールドをキーとする木構造をもつようなものである。インデクスを利用した探索は、例えば木構造のB-Treeサーチ（Binary-Tree Search）の方式などを用いる。なお、表データの更新によりインデクス格納容量が不足する場合があるが、その場合は、自動的に更新フィールドをインデクス作成の対象から除外するようにしてもよい。
【発明の効果】
【００１１】
本発明の複数列に対するインデクスにおけるインデクス分割管理方式によれば、次のような効果がある。
（１）データの更新頻度の高いフィールドをインデクス構成対象から除外しているので、当該フィールドを更新した場合はインデクスに変更がないため、インデクスのデータ格納効率を維持することができる。また、検索時には、インデクスを利用した高速な検索が行えるので、データの検索効率の維持・向上を図ることができる。
（２）データの更新頻度の高いフィールドをインデクス構成対象から除外しているため、データの更新頻度の高いフィールドのデータ格納領域が不足し、別データ格納領域に分割格納する場合でもインデクスに変更がないため、データの検索効率の維持・向上、及びインデクスのデータ格納効率を維持することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明を適用した複数列の表データに対するインデクスにおけるインデクス分割管理方式の一実施の形態について説明する。
【００１３】
図１は、本発明の実施の形態であるデータベース管理システムの構成例を示すブロック図である。データベース管理システム装置Ｄ１は、データベースアクセス部Ｄ３及びデータ管理部Ｄ４を備える。アプリケーションＤ２は、入力情報として表名や探索条件などを指定して、データベースアクセス部Ｄ３に処理を依頼する。データベースアクセス部Ｄ３は、アプリケーションＤ２で指定された入力情報を受け取るデータ入力部Ｄ３１、データ管理部Ｄ４の情報を抽出・更新するデータ操作部Ｄ３２、及び、結果情報をアプリケーションＤ２に受け渡すデータ出力部Ｄ３３を備える。データ管理部Ｄ４は、様々なデータを管理する外部記憶装置で、各データは表Ｄ４１に格納されて管理され、表Ｄ４１のデータを管理するためにインデクスＤ４２が作成されている。データ管理部Ｄ４は、複数の外部記憶装置で構成することもできる。なお、図１のデータベース管理システム装置Ｄ１やアプリケーションＤ２は、具体的にはコンピュータ上で所定のソフトウェアを実行することにより実現されている。
【００１４】
図２は、図１のシステムで管理する表の一例を示すデータ構成図である。表Ｔ１は、フィールド１（Ｔ１１）とフィールド２（Ｔ１２）とフィールド３（Ｔ１３）の３つのフィールドで構成されており、データは登録した順に格納されている。フィールド１（Ｔ１１）にはひらがなの文字が格納され、フィールド２（Ｔ１２）には英字が格納され、フィールド３（Ｔ１３）には数字が格納されるものとする。また、表Ｔ１に格納されているデータの更新頻度は、フィールド１（Ｔ１１）とフィールド２（Ｔ１２）は低く、フィールド３（Ｔ１３）は高いとする。
【００１５】
本実施形態では、表Ｔ１の検索効率を向上させるため、表Ｔ１に対して、図３のようなインデクスＩ１を作成する。インデクスＩ１は、表Ｔ１に格納されているデータをもとにインデクスツリーＩ１１を作成し、各データの位置を特定できるインデクス管理部Ｉ１２を、データの更新頻度の低いフィールド１（Ｔ１１）とフィールド２（Ｔ１２）の２つのフィールドに対して作成したものである。データの更新頻度の高いフィールド３（Ｔ１３）については、インデクス管理部Ｉ１２の管理対象に含めない構成にする。従って、フィールド３の検索を行なうときには、インデクスを利用することなく、表の各レコードのフィールド３のデータそのものを順番に参照しながら検索する順検索の手法を採る必要がある。
【００１６】
表Ｔ１にインデクスＩ１が定義されている状態で、表Ｔ１のレコードＴ１４（図２）のフィールド３（Ｔ１３）の値“５”を“１１”に更新したとする。このとき、インデクスＩ１は、図４のようなインデクスＩ２の状態となる。図４から分るように、フィールド３（Ｔ１３）はインデクスツリー構成対象から除外してあるため、インデクス管理部Ｉ１２に対する変更はなく、インデクス管理部Ｉ１１とＩ１２は同じである。また、インデクスキー情報Ｉ１３の値がＩ２３に更新されるのみで別領域を使用しないため、インデクス管理部におけるデータ格納効率を維持することができる。また、データ更新前のインデクスＩ１とデータ更新後のインデクスＩ２は全く変更がないため、今までの検索効率を維持することができる。
【００１７】
図５は、本実施形態におけるインデクス管理方法での、インデクス作成時のフローチャート図である。表に対してインデクスを作成する場合、まずインデクスツリーの構成対象としようとするフィールドの更新頻度が高いかどうかを判断する（ステップＣ０１）。データの更新頻度の高い列である場合は、インデクスツリー構成対象に含めずに終了する。データの更新頻度の低い列である場合は、その列に格納されているデータを昇順にしてインデクス管理部としてキー情報を登録し（ステップＣ０２）、インデクスツリーを構成する（ステップＣ０３）。
【００１８】
図６は、本実施形態におけるインデクス管理方法での、データ検索時のフローチャート図である。データ検索時に与えられる命令は、例えば、図２の表に対して「｛（列１が『う』）かつ（列２が『Ｂ』）かつ（列３が『８』）｝または｛（列１が『お』）かつ（列２が『Ｃ』）かつ（列３が『７』）｝であるレコードを探索せよ」というようなものである。図６の処理に入る前の事前の処理により、与えられた命令を整理して、何れかの１つのフィールド（列）についての探索条件（例えば「列１が『う』」）を「かつ」で接続したものを単位として、幾つかの探索条件に区分けしておく。区分けした各探索条件ごとにステップＳ０１〜Ｓ０９の処理を行なう。
【００１９】
まず初めの処理対象の探索条件が、データの更新頻度の低いフィールドについての探索条件を含むものである場合、その更新頻度の低いフィールドについての探索条件で、インデクスツリーを利用して、探索を行う（ステップＳ０１）。インデクスツリーは更新頻度の低いフィールドについて作成されており、これを利用することにより高速に探索を行なうことができる。そして、インデクス管理部でその探索条件を満たしているレコードがあるかどうかを判断し（ステップＳ０２）、無ければ上記探索条件を満たすレコードが無いということであるから、ステップＳ０９に進んで、次の探索条件（上記事前の処理により区分けしたもの）があるか判断する。あればその探索条件を処理対象として（ステップＳ１０）、ステップＳ０１から繰り返す。
【００２０】
ステップＳ０２で上記更新頻度の低いフィールドについての探索条件を満たすレコードがあった場合は、更新頻度の低いフィールドについての探索条件でレコードが絞り込まれたということであるから、当該絞り込まれたレコードを探索対象として、ステップＳ０３以降の処理を行なう。まず、処理対象の探索条件が、インデクス構成対象外のフィールド（すなわち、データの更新頻度の高いフィールド）についての探索条件を含むか判断する（ステップＳ０３）。そのような探索条件を含む場合は、上記更新頻度の低いフィールドについての探索条件で絞り込んだレコードを探索対象として、上記更新頻度の高いフィールドについての探索条件を満たすレコードを順検索し（ステップＳ０４、ステップＳ０６〜Ｓ０８）、探索条件と合致するレコードを全て探索結果として出力した段階でステップＳ０９に進む。ステップＳ０３でインデクス構成対象外のフィールドについての探索条件を含まない場合は、ステップＳ０１，Ｓ０２の探索結果が、処理対象の探索条件を満たすレコードであるから、それらのレコードを探索結果として出力し（ステップＳ０５）、ステップＳ０９に進む。
【００２１】
なお、処理対象の探索条件が更新頻度の高いフィールドについての探索条件のみから構成される場合は、ステップＳ０１，Ｓ０２のインデクスを利用した探索の処理はスキップして、表内の全レコードを探索対象としてステップＳ０３以降の処理を行なうものとする。
【００２２】
上記のデータ検索命令「｛（列１が『う』）かつ（列２が『Ｂ』）かつ（列３が『８』）｝または｛（列１が『お』）かつ（列２が『Ｃ』）かつ（列３が『７』）｝であるレコードを探索せよ」が与えられたとして、図６の流れを説明する。図６の処理に入る前に、事前の処理により、上記命令を「（列１が『う』）かつ（列２が『Ｂ』）かつ（列３が『８』）」と「（列１が『お』）かつ（列２が『Ｃ』）かつ（列３が『７』）」の２つの探索条件に区分けしておく。
【００２３】
まず探索条件「（列１が『う』）かつ（列２が『Ｂ』）かつ（列３が『８』）」を処理対象として、ステップＳ０１からの処理を行なう。この探索条件のうち、インデクスが作成されている列１と列２についての探索条件「（列１が『う』）かつ（列２が『Ｂ』）」についてはインデクスを利用して高速に検索できる。そこで、ステップＳ０１，Ｓ０２で探索条件「（列１が『う』）かつ（列２が『Ｂ』）」でインデクスを利用した探索を行なう。これにより、図２の「う  Ｂ  ５」と「う  Ｂ  ８」のレコードに絞り込まれる。上記処理対象の探索条件は、インデクスが作成されていない列３についての探索条件「列３が『８』」も含むから、ステップＳ０３からＳ０４に進み、ステップＳ０４，Ｓ０６〜Ｓ０８で上記絞り込まれた２つのレコードを探索対象として、探索条件「列３が『８』」を満たすレコードを順検索する。これにより、探索結果として「う  Ｂ  ８」のレコードが出力される。この結果は、探索条件「（列１が『う』）かつ（列２が『Ｂ』）かつ（列３が『８』）」の探索結果として、所定のバッファに記憶しておく。
【００２４】
次にステップＳ０９からＳ１０に進み、次の探索条件「（列１が『お』）かつ（列２が『Ｃ』）かつ（列３が『７』）」についてステップＳ０１からの処理を行なう。上記と同様にして、インデクスを利用した探索で絞り込み、順検索を行ない、探索結果として「お  Ｃ  ７」のレコードを得る。その後、ステップＳ０９では次の探索条件は無いので、データ検索を終了する。なお、上記２つの探索条件は「または」で結ばれていたので、上記探索結果を「または」で結んだ「（う  Ｂ  ８）または（お  Ｃ  ７）」が最終的な結果となる。
【００２５】
図７は、本実施形態におけるインデクス管理方法での、データ更新時のフローチャート図である。なお、データ更新時には、更新すべきレコードを特定するための探索条件が与えられると共に、その探索条件で特定されるレコードの更新対象のフィールドを指定する情報と、そのフィールドに設定する値が与えられるものとする。
【００２６】
まず、更新対象のフィールドがインデクスツリー構成対象のフィールドか判定する（ステップＵ０１）。
【００２７】
インデクスツリー構成対象のフィールドである場合は、与えられた探索条件に応じてインデクスツリーを利用して更新対象のレコードの探索を行ない（ステップＵ０２）、該当するインデクス管理レコードをインデクスツリーから削除して（ステップＵ０３）、該当するレコードの該当するフィールドのデータを更新する（ステップＵ０４）。次に、更新後のインデクス管理レコードを挿入すべき新たな位置を探索するために、再度、インデクスツリーを利用して探索を行い（ステップＵ０５）、該当するインデクス管理レコードをインデクスツリーに追加し、インデクスツリーを再作成する（ステップＵ０６）。
【００２８】
なお、更新すべきレコードを特定するための探索条件がインデクスツリー構成対象外のフィールドについての探索条件のみからなる場合は、ステップＵ０２でインデクスを利用した探索の代わりに順検索で更新対象のレコードの探索を行ない、ステップＵ０３では当該更新対象のレコードのインデクス管理レコードを削除するようにすればよい。また、更新すべきレコードを特定するための探索条件がインデクスツリー構成対象のフィールドについての探索条件とインデクスツリー構成対象外のフィールドについての探索条件の両方を含むものである場合は、ステップＵ０２のインデクスツリーを利用した探索だけでは絞り込みが行なえるだけであるので、さらにインデクスツリー構成対象外のフィールドについての探索条件で探索を行なう必要があるが、その探索はステップＵ０２で行なえばよい。要するにＵ０２〜Ｕ０６では、更新対象のレコードの更新対象のフィールドを更新する処理に加えて、当該レコードのインデクスの作り直しを行なっている点が特徴である。
【００２９】
ステップＵ０１でインデクスツリー構成対象外のフィールドの更新である場合は、まず与えられた探索条件に応じてインデクスツリーを利用して更新対象のレコードの探索を行なう（ステップＵ０７）。なお、ステップＵ０７は、更新すべきレコードを特定するための探索条件がインデクスツリー構成対象のフィールドについての探索条件を含む場合に、その探索条件でレコードを絞り込む処理を行なうものである。もし更新すべきレコードを特定するための探索条件がインデクスツリー構成対象外のフィールドについての探索条件のみからなる場合は、ステップＵ０７はスキップする。
【００３０】
次に、更新すべきレコードを特定するための探索条件がインデクスツリー構成対象外のフィールドについての探索条件を含む場合は、ステップＵ０７で絞り込んだレコードを処理対象とし、該処理対象のレコードを１つ１つ取り出しながらステップＵ０８〜Ｕ１１の処理を行なう。まず、取り出したレコードが、与えられているインデクスツリー構成対象外のフィールドについての探索条件を満たすか判断する（ステップＵ０８）。ステップＵ０８で探索条件を満たさない場合は、ステップＵ１０に進む。ステップＵ０８で探索条件を満たす場合は、そのレコードが更新対象のレコードであるということであるから、そのレコードの更新対象のフィールドを指定されたとおりに更新し（ステップＵ０９）、ステップＵ１０に進む。次のレコードが存在するか判断し（ステップＵ１０）、存在しなければステップＵ１２に進み、存在すれば次のレコードを処理対象として（ステップＵ１１）、ステップＵ０８からの処理を繰り返す。
【００３１】
なお、更新すべきレコードを特定するための探索条件がインデクスツリー構成対象外のフィールドについての探索条件を含まない場合は、既にステップＵ０７の探索だけで更新すべきレコードが特定されているはずであり、ステップＵ０８〜Ｕ１１のような順検索を行なう必要はない。従って、その場合は、ステップＵ０７の後、更新対象のレコードの更新対象のフィールドを指定されたとおりに更新し、ステップＵ１２に進むようにすればよい。要するにＵ０７〜Ｕ１１では、更新対象のレコードの更新対象のフィールドを更新する処理を行なうだけで、当該レコードのインデクスについては全くそのままにしている点が特徴である。これにより、インデクスツリー構造が変わらず、新たなインデクス管理領域を使用しないため、データ管理領域の格納効率を維持することができる。
【００３２】
さらに、次のデータ更新が指示されている場合は（ステップＵ１２）、そのデータ更新を行なうべく、次の探索条件を処理対象として（ステップＵ１３）、ステップＵ０１からの処理を繰り返す。指示された全てのデータ更新が終了した段階でデータ更新とインデクス管理情報の更新が終了する。
【００３３】
なお、上記実施の形態では、図５のステップＣ０１において、フィールドの更新頻度が高いかどうかによりインデクスを作成するかしないかを決定しているが、この更新頻度の高低の判断は任意である。例えば、所定期間における各フィールドの更新回数を集計しておき、更新頻度の高低を分ける閾値（基準値）を決定しておき、その閾値以上の回数の更新が為されているフィールドを更新頻度が高いフィールドとすればよい。また、人の判断で更新頻度の高低の基準値を随時決定できるようにしてもよい。
【００３４】
以上のように、本実施の形態の複数列に対するインデクスにおけるインデクス分割管理方式によれば、次のような効果がある。
（１）データの更新頻度の高いフィールドをインデクスツリー構成対象から除外しており、レコード更新を行った場合においてもインデクスツリーに変更がないため、検索効率を維持・向上させることができる。
（２）データの更新頻度の高いフィールドをインデクスツリー構成対象から除外しているため、データの更新頻度の高いフィールドのデータ格納領域が不足し、別のデータ格納領域に分割格納した場合でもインデクスツリーに変更がないため、検索効率を維持・向上させることができる。
【図面の簡単な説明】
【００３５】
【図１】データベース管理システム構成の一例を示すブロック図である。
【図２】本発明の実施形態を説明する表の一例を示すデータ構成図である。
【図３】図２の表に対するインデクスを示すデータ構成図である。
【図４】本発明によるインデクス管理方法での、データの更新を行った場合の図３のインデクスを示すデータ構成図である。
【図５】本発明におけるインデクス管理方法での、インデクス作成時のフローチャート図である。
【図６】本発明におけるインデクス管理方法での、データ検索時のフローチャート図である。
【図７】本発明におけるインデクス管理方法での、データ更新時のフローチャート図である。
【符号の説明】
【００３６】
Ｄ１…データベース管理システム（DBMS : DataBase Management System）、Ｄ２…アプリケーション、Ｄ３…データアクセス部、Ｄ３１…データ入力部、Ｄ３２…データ操作部、Ｄ３３…データ出力部、Ｄ４…データ管理部、Ｄ４１…表、Ｄ４２…インデクス、Ｔ１…表、Ｉ１，Ｉ２…インデクス、Ｉ１１…インデクスツリー、Ｉ１２…インデクスツリー構成対象。
【図１】
2008015810.tif 000003
【図２】
2008015810.tif 000004
【図３】
2008015810.tif 000005
【図４】
2008015810.tif 000006
【図５】
2008015810.tif 000007
【図６】
2008015810.tif 000008
【図７】
2008015810.tif 000009