JP2016053976A - データ生成方法、装置及びプログラム、検索処理方法、装置及びプログラム - Google Patents

Abstract

【課題】各々１又は複数のタグを含む複数のデータブロックを効率よく検索可能にする。
【解決手段】本方法は、格納すべき複数のデータブロックから当該複数のデータブロックの各々に含まれる１又は複数のタグを抽出して、当該タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１の処理と、複数のデータブロックについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２の処理と、複数のグループのうち各グループについて、当該グループに属するビット列に対応するデータブロックのデータを、当該グループに属するビット列の種類に対応付けてデータ格納部に格納する第３の処理とを含む。
【選択図】図１

Description

本技術は、データベース管理、検索処理技術に関する。

現在、企業活動の全てを長期間に渡り可視化するため、多数の業務帳票を収集してデータウェアハウス化するという傾向がある。このようなデータウェアハウスには、おおよそ以下のような特徴がある。すなわち、参照頻度は低いが、長期に大量のデータを保存することになる。また、長期に渡ってデータを保管するので途中で業務変更によるアプリケーションの変更が生じても対応可能な非定型データ（例えばＸＭＬ（eXtensible Markup Language））の帳票等を保管することになる。さらに、旧来から保持している資産としてリレーショナルデータベース（ＲＤＢ）を活用して、コストの低減を図ることになる。

そのため、事前設計が前提となるＲＤＢにおけるカラムにＸＭＬ文書をそのまま格納する方式が主流となっており、データの検索コスト（例えば性能問題）の増加、大量データ保存のためにディスクに対する投資費用の増加が著しくなっている。また、データの配置構成として、ＩＬＭ（情報ライフサイクル管理）の考え方に則った形式が一般化している。

これに対して、上で述べた性能問題については、データベース管理システムにおいて、ＸＭＬ構造を意識した索引を付加する（例えばＸＭＬ文書のパスと「value」を保持する索引を作成する）ことで、アクセス対象となるレコードの局所化を行うという技術が存在している。また、別のアプローチとして、全件を検索しつつも、並列処理を用いることで、全体としての性能を速めるという技術も存在している。

上で述べたＸＭＬ文書構造を意識した索引を付加して対象のレコードを特定する方式は、ＲＤＢにおける従来の索引機構の考え方をＸＭＬに対応させたものである。しかし、長期間に渡るデータ蓄積において、業務の変化に伴い変更されるＸＭＬ文書構造（帳票形式）に追随するために、設計変更が発生する可能性があり、コストが増大する。

さらに、並列で検索する方式は、ディスクを分割することによって性能効果を得る方法であり、余分な資源が用いられることになる。また、並列効果を得るために、パーティショニングを行ってデータ分散を行うにも、長期に渡るデータ管理において、どのようにして、ディスク毎のアクセス平坦化を行うかについて設計を行うことになり、費用面で負担が大きい。

特開平８−３２９１１６号公報 特開平１０−２７５１０５号公報

Symfoware Server V10.0.0 RDB運用ガイド（XMLアダプタ編）、２．２．１ＸＭＬデータのインデックスの格納構造［平成２３年６月１３日検索］インターネット＜http://software.fujitsu.com/jp/manual/manualfiles/M100005/J2X17481/01Z200/J7481-00-02-02-01.html＞

従って、本技術は、一側面においては、各々１又は複数のタグを含む複数のデータブロックを効率よく検索可能にすることを目的とする。

本技術に係る記憶制御方法は、（Ａ）複数のデータのうちの所定種類のタグを含むデータ群を圧縮して、圧縮ファイルを生成するステップと、（Ｂ）生成した圧縮ファイルを、所定の種類のタグを識別可能な識別情報と関連付けて記憶部に格納するステップとを含む。

本技術に係る検索制御方法は、（Ａ）あるタグについての検索要求を受信した場合に、データを圧縮して得られる圧縮データを、上記データ内に含まれるタグを識別可能な識別情報と関連付けて格納する格納部から、上記あるタグの識別情報と関連付けられた圧縮データを特定するステップと、（Ｂ）特定した圧縮データを伸張するステップと、（Ｃ）伸張して得られたデータに対して上記あるタグについての検索処理を行うステップとを含む。

各々１又は複数のタグを含む複数のデータブロックを効率よく検索できる。

図１は、本技術の実施の形態のシステム概要を示す図である。 図２は、第１の実施の形態におけるデータ移動処理部の機能ブロック図である。 図３は、第１の実施の形態における検索処理部の機能ブロック図である。 図４は、第１ＤＢに格納されるデータの一例を示す図である。 図５Ａは、営業状況を表す帳票データの一例を示す図である。 図５Ｂは、出勤情報を表す帳票データの一例を示す図である。 図５Ｃは、売上データを表す帳票データの一例を示す図である。 図６は、タグ変換表の一例を示す図である。 図７は、第１の実施の形態における処理の概要を説明するための図である。 図８は、第１の実施の形態における処理の概要を説明するための図である。 図９は、第１の実施の形態における第２ＤＢへのデータの格納について説明するための図である。 図１０は、タグジャッジの一例を示す図である。 図１１は、第１の実施の形態における検索処理の概要を説明するための図である。 図１２は、第１の実施の形態における検索処理の概要を説明するための図である。 図１３は、第１の実施の形態におけるデータ格納時の処理の処理フローを示す図である。 図１４は、第１の実施の形態におけるタグビットマップ生成処理の処理フローを示す図である。 図１５は、第１の実施の形態におけるタグビットマップ生成処理の処理フローを示す図である。 図１６は、タグビットマップのフォーマット例を示す図である。 図１７は、第１の実施の形態におけるデータ格納時の処理の処理フローを示す図である。 図１８は、第１の実施の形態におけるデータ格納処理の処理フローを示す図である。 図１９は、圧縮ブロックのデータ構造の一例を示す図である。 図２０は、タグジャッジ登録処理の処理フローを示す図である。 図２１は、タグジャッジのデータ構造の一例を示す図である。 図２２は、第１の実施の形態におけるデータ格納処理の処理フローを示す図である。 図２３は、第２ＤＢに格納されるデータの一例を示す図である。 図２４は、第１の実施の形態における検索時の処理の処理フローを示す図である。 図２５は、第１の実施の形態における検索時の処理の処理フローを示す図である。 図２６は、第２の実施の形態におけるタグ変換表の生成処理を説明するための図である。 図２７は、第２の実施の形態におけるタグ変換表の生成処理を説明するための図である。 図２８は、第２の実施の形態におけるタグ変換ワーク表の一例を示す図である。 図２９は、第２の実施の形態におけるタグ変換表の一例を示す図である。 図３０は、第２の実施の形態における処理の概要を説明するための図である。 図３１は、第２の実施の形態における処理の概要を説明するための図である。 図３２は、第２の実施の形態における処理の概要を説明するための図である。 図３３は、第２の実施の形態における処理の概要を説明するための図である。 図３４は、第２の実施の形態における処理の概要を説明するための図である。 図３５は、第２の実施の形態における処理の概要を説明するための図である。 図３６は、第２の実施の形態における処理の概要を説明するための図である。 図３７は、第２の実施の形態におけるデータ格納時の処理の処理フローを示す図である。 図３８は、第２タグビットマップ生成処理の処理フローを示す図である。 図３９は、第２タグビットマップ生成処理の処理フローを示す図である。 図４０は、第２データ格納部処理の処理フローを示す図である。 図４１は、ＷｋＴａｇＢｍｐ一覧登録処理の処理フローを示す図である。 図４２は、圧縮処理の処理フローを示す図である。 図４３は、第２ＴａｇＪｕｄｇｅ登録処理の処理フローを示す図である。 図４４は、第２ＴａｇＪｕｄｇｅ登録処理の処理フローを示す図である。 図４５は、第２の実施の形態における検索時の処理の処理フローを示す図である。 図４６は、第２の実施の形態における検索時の処理の処理フローを示す図である。 図４７は、コンピュータの機能ブロック図である。 図４８は、実施の形態におけるデータ格納処理のための情報処理装置の機能ブロック図である。 図４９は、実施の形態における検索処理のための情報処理装置の機能ブロック図である。

［実施の形態１］
図１を用いて、本技術の第１の実施の形態に係るシステムの概要を説明する。例えば企業内ネットワークであるネットワーク１には、複数の業務システム（図１では業務システムＡ乃至Ｃ）と、複数の分析システム（図１では分析システムＡ及びＢ）と、本実施の形態における主要な処理を実施するＤＢ管理システム１００とが接続されている。業務システムＡ乃至Ｃは、例えばＸＭＬ文書データである帳票データを生成してＤＢ管理システム１００に登録したり、参照する。また、分析システムＡ及びＢは、ＤＢ管理システム１００に登録されている帳票データを分析する処理を実施する。ＤＢ管理システム１００は、１又は複数のコンピュータを含む。

ＤＢ管理システム１００は、記録管理部１１０と、第１データベース（ＤＢ）１２０と、データ移動処理部１３０と、第２ＤＢ１４０と、検索処理部１５０とを有する。記録管理部１１０は、業務システムＡ乃至Ｃから送られてくる帳票データを第１ＤＢ１２０に格納する。第１ＤＢ１２０は、例えば１日分、１週間分、１ヶ月分といった直近所定期間内に生成された帳票データを格納する。典型的には、データ移動処理部１３０は、帳票発生順に、第１ＤＢ１２０に格納する。また、データ移動処理部１３０は、第１ＤＢ１２０に格納されていた帳票データを、１日、１週間、１ヶ月といった所定期間分まとめて第２ＤＢ１４０に格納するための処理を実施する。検索処理部１５０は、例えば分析システムＡ及びＢからの検索要求を受信し、検索要求に対応する処理を第２ＤＢ１４０に対して実施して、検索結果を要求元の分析システムに返信する。第２ＤＢ１４０には、１日単位、１週間単位、１ヶ月単位といった所定期間単位でデータが蓄積される。

図２に、データ移動処理部１３０の機能ブロック図を示す。データ移動処理部１３０は、データ抽出部１３１と、抽出データ格納部１３２と、タグビットマップ生成部１３３と、タグ変換表格納部１３４と、ソート処理部１３５と、データ格納処理部１３６と、タグジャッジ格納部１３７と、圧縮バッファ１３８とを有する。

データ抽出部１３１は、第１ＤＢ１２０から第２ＤＢ１４０に格納すべきデータレコードを抽出し、抽出データ格納部１３２に格納する。タグビットマップ生成部１３３は、抽出データ格納部１３２に格納されているデータからタグ変換表を生成してタグ変換表格納部１３４に格納し、タグビットマップを生成し、データレコードと連結して抽出データ格納部１３２に格納する。また、ソート処理部１３５は、タグビットマップを含むレコードを当該タグビットマップに従ってソートして、ソート結果を抽出データ格納部１３２に格納する。

データ格納処理部１３６は、抽出データ格納部１３２に格納されているソート結果に従って、検索のための索引データであるタグジャッジ（TagJudge）を生成してタグジャッジ格納部１３７に格納し、処理途中のレコードについては圧縮バッファ１３８に蓄積する。さらに、データ格納処理部１３６は、圧縮後のデータ、タグジャッジデータ格納部１３７に格納されているタグジャッジのデータ及びタグ変換表格納部１３４に格納されているデータを、第２ＤＢ１４０に格納する。

図３に、検索処理部１５０の機能ブロック図を示す。検索処理部１５０は、インターフェース部１５１と、検索式処理部１５２と、データ抽出部１５３と、データ格納部１５４と、検索部１５５とを有する。

インターフェース部１５１は、分析システム等から検索要求を受信すると、当該検索要求に含まれる検索式を検索式処理部１５２に出力する。検索式処理部１５２は、第２ＤＢ１４０に格納されているタグ変換表から検索式に関連するビットマップを生成してデータ抽出部１５３に出力する。データ抽出部１５３は、検索式処理部１５２が生成したビットマップと、第２ＤＢ１４０に格納されているタグジャッジとから、該当する圧縮データを特定して第２ＤＢ１４０から読み出して、解凍処理を実施し、解凍後のデータをデータ格納部１５４に格納する。また、検索式処理部１５２は、第２ＤＢ１４０に格納されているタグ変換表に基づき検索式をタグ変換表に含まれるタグＩＤ表記の検索式に変換して、変換後の検索式を検索部１５５に出力する。検索部１５５は、変換後の検索式で、データ格納部１５４に格納されるレコード（帳票データを含む）を検索して、該当する帳票データをインターフェース部１５１に出力する。インターフェース部１５１は、該当する帳票データを、検索要求元の分析システムなどに送信する。

次に、図４乃至図２５を用いて、第１の実施の形態に係る処理についてその概要を説明しておく。例えば第１ＤＢ１２０には、図４に示すようなデータが格納されている。図４の例では、第１のカラムには日付（例えば「２０１１０１１５０１０１」）が、第２のカラムには付随データ（図４では「Ａ」）が、第３のカラムには帳票データ（ここではＸＭＬ文書のデータ）が登録されるようになっている。帳票データには、営業状況のデータ、出勤情報、売上のデータなどが含まれる。このように１つのＸＭＬ文書のデータブロックが１データレコードとして登録されている。

図５Ａは、営業状況を表す帳票データの一例を示しており、この例には、部門タグと、状況タグと、個数タグとが含まれている。図５Ｂは、出勤情報の一例を示しており、この例には、部門タグと、申請タグと、出勤日数タグとが含まれている。図５Ｃは、売上データの帳票データの一例を示しており、この例には、部門タグと、売上タグと、商品タグと、価格タグと、個数タグとが含まれている。

このようなデータを第２ＤＢ１４０に格納する場合には、例えば図６に示すようなタグ変換表を新たな種類のタグ出現毎に生成しつつ処理を行う。図６の例では、タグ変換表には、タグ識別番号（タグＩＤと呼ぶ）と、タグ名とが対応付けて登録されている。

そして、図７に模式的に示すような処理を実施する。すなわち、タグ変換表から、タグ圧縮処理を実施する。タグ圧縮処理では、タグの文字列をタグＩＤに置換して、タグ圧縮文書（タグ圧縮帳票データとも呼ぶ）を生成する。例えば、図５Ａの帳票データは、タグ圧縮文書１００１に変換される。部門タグはタグＩＤ「０」に、状況タグはタグＩＤ「１」に、個数タグはタグＩＤ「２」に置換されている。図５Ｂの帳票データは、タグ圧縮文書１００２に変換される。部門タグはタグＩＤ「０」に、申請タグはタグＩＤ「３」に、出勤日数タグがタグＩＤ「４」に置換されている。図５Ｃの帳票データは、タグ圧縮文書１００３に変換される。部門タグはタグＩＤ「０」に、状況タグはタグＩＤ「２」に、売上タグはタグＩＤ「５」に、商品タグはタグＩＤ「６」に、価格タグはタグＩＤ「７」に置換されている。

そして、各タグ圧縮文書（すなわち各帳票データブロック）についてタグビットマップ（TagBmp）も生成する。具体的には、タグＩＤは、タグビットマップのビット位置に対応しており、タグＩＤ「０」はビット位置「０」に、タグＩＤ「１」はビット位置「１」に、タグＩＤ「２」はビット位置「２」に、といったように対応付けがなされている。ここではタグＩＤの小さい方がタグビットマップの上位ビットとなっている。

タグ圧縮文書１００１には、タグＩＤ「０」「１」及び「２」のタグが含まれているので、タグビットマップにおけるビット位置「０」「１」及び「２」には「１」にセットされ、それ以外のビット位置には「０」がセットされる。すなわち、タグビットマップ１００１ｔが生成される。同様に、タグ圧縮文書１００２には、タグＩＤ「０」「３」及び「４」のタグが含まれているので、タグビットマップにおけるビット位置「０」「３」及び「４」には「１」がセットされ、それ以外のビット位置には「０」がセットされる。すなわち、タグビットマップ１００２ｔが生成される。さらに、タグ圧縮文書１００３には、タグＩＤ「０」「２」「５」「６」及び「７」のタグが含まれているので、タグビットマップにおけるビット位置「０」「２」「５」「６」及び「７」には「１」がセットされ、それ以外のビット位置には「０」がセットされる。すなわち、タグビットマップ１００３ｔが生成される。

図７には、その他の帳票データブロック（タグ圧縮文書）についてのタグビットマップも示されているが、全ての帳票データブロックについてタグビットマップが生成される。

このように生成されたタグビットマップを、図８に示すように、第１ＤＢ１２０から抽出したデータレコードと連結して、タグビットマップ部分をキーにしてソート処理を実施する。図８に示したように６レコードを処理する場合には、図９に示すようにソートされる。そして、本実施の形態では、タグビットマップの種別毎に、該当するレコードのデータを圧縮する。すなわち、同一タグビットマップが得られた１又は複数のレコードのデータをまとめて圧縮して圧縮ブロックを生成して、第２ＤＢ１４０に格納する。図９の例では、タグビットマップ「１００１１０００」が生成されたレコードは１レコードであるが、このレコードのデータを圧縮して、圧縮ブロックＢｌｋ１を生成し、第２ＤＢ１４０の所定位置に格納する。また、タグビットマップ「１０１００１１１」が生成されたレコードは２レコードであるが、これらのレコードのデータを纏めて圧縮して、圧縮ブロックＢｌｋ２を生成し、第２ＤＢ１４０の所定位置に格納する。さらに、タグビットマップ「１１１０００００」が生成されたレコードは３レコードであるが、これらのレコードのデータを纏めて圧縮して、圧縮ブロックＢｌｋ３及びＢｌｋ４を生成し、第２ＤＢ１４０の所定位置に格納する。なお、圧縮ブロックのサイズの上限が設定されている場合には、同じタグビットマップが生成されたレコード群について２以上の圧縮ブロックが生成される。また、１度に第１ＤＢ１２０から抽出されたレコード群については、第２ＤＢ１４０における同一のパーティション等に格納するものとする。

さらに、分析システムなどからの検索要求に対応するために、文書構造索引であるタグジャッジ（TagJudge）も生成される。この例では、図１０に示すようなタグジャッジが生成される。具体的には、タグビットマップの種別毎に、対応する圧縮ブロックへのポインタが登録される。この例では、タグビットマップ「１００１１０００」については圧縮ブロックＢｌｋ１へのポインタｐｔｒが登録され、タグビットマップ「１０１００１１１」については圧縮ブロックＢｌｋ２へのポインタｐｔｒが登録され、タグビットマップ「１１１０００００」については圧縮ブロックＢｌｋ３及びＢｌｋ４へのポインタｐｔｒが登録されている。

図６に示したタグ変換表及び図１０に示したタグジャッジについては、第２ＤＢ１４０に登録しておき、検索処理部１５０による検索処理で用いる。

このような処理を実施すれば、タグ変換表及びタグジャッジは自動的に生成されるので業務の変更による帳票の変更に対して人手による設計変更が不要となる。また、タグビットマップによって帳票データブロックをクラスタリングすることで、同一種類の帳票データブロックが纏めて圧縮されることが期待される。すなわち、高圧縮率となることが期待され、データ保持コスト（ハードウエアコスト）を削減することができる。

次に、図１１及び図１２を用いて、検索時の処理について概要を説明する。例えば検索式「ＸＱＵＥＲＹ（売上／商品＝テレビ）」を含む検索要求を受信した場合を例に説明する。具体的には、売上タグ又は商品タグについてテレビのデータを含む帳票データブロックを抽出することを要求する検索要求を処理する。

従って、検索式に含まれる条件である「売上」及び「商品」について、タグ変換表から該当するタグＩＤを読み出す。この例では「５」及び「６」が特定される。そうすると、ビット位置「５」及び「６」が「１」にセットされている検索式のビットマップ１１０１が生成される。図１１の例では「０００００１１０」が得られる。そして、この検索式のビットマップ１１０１と、タグジャッジにおける各レコードに含まれるタグビットマップについてビットＡＮＤ演算を実施する。そして、いずれかのビット位置に「１」が生じる、タグジャッジ内のレコードを特定する。この例では、ビット位置「５」又は「６」に「１」がセットされているレコードは２行目のレコードであり、このレコードが特定される。そうすると、対応する圧縮ブロックＢｌｋ２へのポインタｐｔｒが得られるので、第２ＤＢ１４０に格納されている圧縮ブロックＢｌｋ２を読み出すことになる。

次に、図１２に示すように、圧縮ブロックＢｌｋ２に対して解凍処理を実施して、元のデータレコードを復元する。なお、帳票データブロック内においてはタグ圧縮されているので、検索式についてもタグ圧縮してから検索処理を実施する。すなわち、タグ変換表から、検索式は「ＸＱＵＥＲＹ（５／６＝テレビ）」に変換され、解凍処理によって復元されたデータレコードについて検索処理を実施する。この検索処理において条件に合致する帳票データブロックが存在する場合には、当該帳票データブロックを出力する。

このように、タグジャッジによって、解凍する圧縮ブロックの範囲が局所化されるので、検索時における計算コストが低減される。また、並列アクセスによる高速化のための複数ディスク装置の設置や当該複数ディスク装置へのデータ配分についての設計なども不要となる。

次に、図１３乃至図２５を用いて具体的な処理内容について説明する。まず、第２ＤＢ１４０にデータを格納する処理について図１３乃至図２３を用いて説明する。

データ抽出部１３１は、所定のタイミングで第１ＤＢ１２０から、第２ＤＢ１４０に格納すべきデータレコードを１件抽出し、抽出データ格納部１３２に格納する（図１３：ステップＳ１）。そして、タグビットマップ生成部１３３は、抽出されたデータレコードに対してタグビットマップ生成処理を実施する（ステップＳ５）。タグビットマップ生成処理については、図１４乃至図１６を用いて説明する。

タグビットマップ生成部１３３は、抽出されたデータレコードに含まれるＸＭＬ文書（帳票データブロック）において未処理のタグを１つ特定し、変数＿ｔに設定する（図１４：ステップＳ１１）。そして、タグビットマップ生成部１３３は、タグ変換表格納部１３４においてタグ変換表が生成済みであるか判断する（ステップＳ１３）。タグ変換表が未生成である場合には、タグビットマップ生成部１３３は、タグ変換表格納部１３４においてタグ変換表のための領域を確保する（ステップＳ１５）。そしてステップＳ１７に移行する。

既にタグ変換表が生成済みである場合又はステップＳ１５の後に、タグビットマップ生成部１３３は、＿ｔがタグ変換表に既に登録済みであるかを判断する（ステップＳ１７）。タグ名の欄に＿ｔのタグ名が含まれているかを確認する。＿ｔがタグ変換表に未登録である場合には、タグビットマップ生成部１３３は、未使用のタグＩＤを発行し、当該タグＩＤと＿ｔをタグ変換表に登録する（ステップＳ１９）。そしてステップＳ２１に移行する。

既に＿ｔがタグ変換表に登録済みである場合又はステップＳ１９の後に、タグビットマップ生成部１３３は、タグ変換表から＿ｔに対応するタグＩＤを取得する（ステップＳ２１）。そして、処理は端子Ｂを介して図１５の処理に移行する。

図１５の処理の説明に移行して、タグビットマップ生成部１３３は、抽出されたデータレコードについてのタグビットマップにおいて、タグＩＤに対応するビット位置を「１」にセットする（ステップＳ２３）。なお、タグビットマップのビット長は出現すると予測されるタグの種類数に応じて予め定められた固定長とする。例えば図１６に示すように、先頭に長さＬＬのデータに、ビットマップが付加されたフォーマットを有している。但し、ビットマップ長は、なくてもよい。

そして、タグビットマップ生成部１３３は、タグ圧縮処理として、抽出されたデータレコードに含まれるＸＭＬ文書において、特定されたタグをタグＩＤで置換する（ステップＳ２５）。図５Ａを図７の１００１に変換する処理に相当する。

その後、タグビットマップ生成部１３３は、抽出されたデータレコードに含まれるＸＭＬ文書において未処理のタグが存在しているか判断する（ステップＳ２７）。未処理のタグが存在している場合には、端子Ｃを介して図１４のステップＳ１１に戻る。一方、未処理のタグが存在していない場合には、呼び出し元の処理に戻る。

このような処理を実施すれば、図７のタグビットマップ１００１ｔのようなタグビットマップが生成される。すなわち、データレコードに含まれるＸＭＬ文書におけるタグについての特徴がタグビットマップとして表されることになる。

図１３の処理の説明に戻って、タグビットマップ生成部１３３は、生成したタグビットマップ及び抽出されたデータレコードを連結したレコードを、ソート処理部１３５に投入して、ソート処理部１３５に、タグビットマップ全体をキーとしたソート処理を実施させる（ステップＳ７）。なお、ソート処理自体はよく知られた処理なので説明は省略する。なお、ソート処理部１３５は、ソート結果を、抽出データ格納部１３２に格納する。

そして、データ抽出部１３１は、未処理のデータレコードが第１ＤＢ１２０に存在しているか判断する（ステップＳ９）。未処理のデータレコードが存在していない場合には、処理は端子Ａを介して図１７の処理に移行する。一方、未処理のデータレコードが存在している場合にはステップＳ１に戻る。

図１７の処理の説明に移行して、データ格納処理部１３６は、抽出データ格納部１３２に格納されているソート処理結果のうち未処理のレコードを１つ特定する（ステップＳ３３）。そして、データ格納処理部１３６は、データ格納処理を実施する（ステップＳ３５）。データ格納処理については、図１８乃至図２２を用いて説明する。

データ格納処理部１３６は、データ量を格納する変数＿ｌｅｎ及び処理に係る直前のタグビットマップを保管する変数＿ｏｔｂを０で初期化する（図１８：ステップＳ４１）。そして、データ格納処理部１３６は、ステップＳ３３で特定されたレコードを読み込む（ステップＳ４３）。その後、データ格納処理部１３６は、読み込んだレコードに含まれるタグビットマップを変数＿ｃｔｂに設定する（ステップＳ４５）。

さらに、データ格納処理部１３６は、特定されたレコードが最初のレコードであるか又は＿ｃｔｂ＝＿ｏｔｂであるか判断する（ステップＳ４７）。特定されたレコードが最初のレコードである場合又は＿ｃｔｂ＝＿ｏｔｂである（直前のタグビットマップと同一のタグビットマップが特定された場合）場合には、データ格納処理部１３６は、＿ｌｅｎに、読み込まれたレコードのレコード長を加算すると最大サイズ（例えば５ＭＢｙｅｔｓ）を超えるか判断する（ステップＳ５９）。＿ｌｅｎに、読み込まれたレコードのレコード長を加算しても最大サイズを超えない場合には、端子Ｄを介して図２２の処理に移行する。一方、＿ｌｅｎに、読み込まれたレコードのレコード長を加算すると最大サイズを超えた場合には、ステップＳ５１に移行する。

ステップＳ４７で、最初のレコードでもなく＿ｃｔｂ＝＿ｏｔｂでもない、すなわち直前のタグビットマップと異なるタグビットマップが検出された場合、データ格納処理部１３６は、圧縮バッファ１３８に蓄積されたレコードが存在するか判断する（ステップＳ４９）。データ格納処理部１３６は、圧縮バッファ１３８に蓄積されたレコードが存在しない場合には、端子Ｄを介して図２２の処理に移行する。一方、圧縮バッファ１３８に蓄積されたレコードが存在する場合には、データ格納処理部１３６は、圧縮バッファ１３８に格納されているレコード群を、所定の方式で圧縮して圧縮ブロックを生成する（ステップＳ５１）。そして、データ格納処理部１３６は、圧縮ブロックを第２ＤＢ１４０に格納し、第２ＤＢ１４０における格納位置を取得する（ステップＳ５３）。

図１９に、１ファイルにおける圧縮ブロックのデータ構造の一例を示す。このように、圧縮ブロックにブロック長を付加した形で格納する。なお、図１９では、圧縮ブロックを連続して１ファイルに格納する例を示している。なお、格納位置としては、ファイル識別子（ＩＤ）と、当該ファイル内におけるオフセット（ブロックオフセットとも呼ぶ）とで特定される。図１９では、圧縮ブロックＢｌｋ３についてのオフセットを例示している。

さらに、データ格納処理部１３６は、タグジャッジ（ＴａｇＪｕｄｇｅ）登録処理を実施する（ステップＳ５５）。ＴａｇＪｕｄｇｅ登録処理については、図２０及び図２１を用いて説明する。

まず、データ格納処理部１３６は、＿ｃｔｂがタグジャッジ（TagJudge）に登録済みであるか判断する（図２０：ステップＳ６１）。＿ｃｔｂがＴａｇＪｕｄｇｅに登録済みである場合には、ステップＳ６５に移行する。一方、＿ｃｔｂがＴａｇＪｕｄｇｅに未登録である場合には、データ格納処理部１３６は、＿ｃｔｂを例えばタグジャッジ格納部１３７内のＴａｇＪｕｄｇｅに一旦登録する（ステップＳ６３）。そしてステップＳ６５に移行する。

図２１に、タグジャッジ格納部１３７におけるＴａｇＪｕｄｇｅのデータ構造の一例を示す。図２１の例では、タグビットマップ（ＴａｇＢｍｐ）の種別毎に、圧縮ブロックへのポインタの数（ＢｌｋＰｔｒ数）と、圧縮ブロックの格納位置へのポインタ（Ｐｔｒ）とが登録されるようになっている。圧縮ブロックの格納位置については、ファイルＩＤとブロックオフセットとの組み合わせで示される。以下で述べるように、１つのタグビットマップについて多数のレコードが存在する場合には、最大サイズを超えないようにレコードを纏めて圧縮するようになっているため、複数の圧縮ブロックが生成される場合がある。そのため、ポインタ数を管理するようになっている。

＿ｃｔｂがＴａｇＪｕｄｇｅに登録済みであるかステップＳ６３の後に、データ格納処理部１３６は、ＴａｇＪｕｄｇｅにおいて、該当タグビットマップに対応付けて、ステップＳ５３で取得された格納位置を登録する（ステップＳ６５）。なお、この際、ポインタ数を１インクリメントする。そして、呼び出し元の処理に戻る。

このようにして、タグビットマップの種別毎に、該当する圧縮ブロックを参照するためのデータ構造を用意することができるようになる。

図１８の処理の説明に戻って、データ格納処理部１３６は、変数＿ｌｅｎを０に初期化する（ステップＳ５７）。そして端子Ｄを介して図２２の処理に移行する。

図２２の処理の説明に移行して、データ格納処理部１３６は、ステップＳ４３で読み出したレコードを圧縮バッファ１３８に蓄積する（ステップＳ７１）。そして、データ格納処理部１３６は、変数＿ｌｅｎに、圧縮バッファ１３８に格納したレコードのレコード長を加算する（ステップＳ７３）。さらに、データ格納処理部１３６は、変数＿ｏｔｂにタグビットマップを設定する（ステップＳ７５）。そして呼び出し元の処理に戻る。

このような処理を繰り返すことによって、レコードが圧縮されて第２ＤＢ１４０に蓄積されると共に、検索のための索引構造データであるＴａｇＪｕｄｇｅが構築されるようになる。

図１７の処理の説明に戻って、データ格納処理部１３６は、未処理のレコードが存在しているか判断する（ステップＳ３７）。未処理のレコードが存在している場合には、ステップＳ３３に戻る。一方、未処理のレコードが存在しない場合には、データ格納処理部１３６は、データ格納終了処理を実施する（ステップＳ３８）。すなわち、圧縮バッファに残っているレコードについての処理を実施する。具体的には、最後に変数＿ｃｔｂに代入されたタグビットマップについて、ステップＳ５１乃至Ｓ５５を実施する。

その後、データ格納処理部１３６は、タグジャッジ格納部１３７におけるＴａｇＪｕｄｇｅ及びタグ変換表格納部１３４に格納されているタグ変換表を、纏めて第２ＤＢ１４０に格納する（ステップＳ３９）。第２ＤＢ１４０は、圧縮ブロックを含むファイルに加えて、図２３に示すようなデータが格納されるようになる。すなわち、タグ変換表とＴａｇＪｕｄｇｅとを含む、検索のための索引構造データが格納される。

次に、検索時の処理について図２４及び図２５を用いて説明する。検索処理部１５０のインターフェース部１５１は、分析システムなどから検索式を含む検索要求を受信する（図２４：ステップＳ８１）。そうすると、インターフェース部１５１は、検索式のデータを、検索式処理部１５２に出力する。検索式処理部１５２は、検索要求の検索式に含まれる未処理のタグを１つ特定し、変数＿ｔに設定する（ステップＳ８３）。そして、検索式処理部１５２は、第２ＤＢ１４０に格納されているタグ変換表から、＿ｔに対応するタグＩＤを取得する（ステップＳ８５）。

その後、検索式処理部１５２は、検索式におけるタグをタグＩＤに置換する（ステップＳ８７）。また、検索式処理部１５２は、ビットマップ＿ｓｔｂにおいて、タグＩＤに対応するビット位置の値を「１」にセットする（ステップＳ８９）。その後、検索式処理部１５２は、未処理のタグが検索式に存在しているか判断する（ステップＳ９１）。未処理のタグが存在する場合にはステップＳ８３に戻る。一方、未処理のタグが存在しない場合には、検索式処理部１５２は、ビットマップ＿ｓｔｂをデータ抽出部１５３に出力し、置換処理後の検索式のデータを検索部１５５に出力する。そして、処理は端子Ｅを介して図２５の処理に移行する。

図２５の処理の説明に移行して、データ抽出部１５３は、第２ＤＢ１４０に格納されているＴａｇＪｕｄｇｅにおける未処理のタグビットマップを１つ＿ｔｔｂに設定する（ステップＳ９３）。そして、データ抽出部１５３は、ビットマップ＿ｓｔｂと読み出したタグビットマップ＿ｔｔｂとのビットＡＮＤを計算する（ステップＳ９５）。そして、データ抽出部１５３は、いずれかのビット位置の値が「１」になっているか判断する（ステップＳ９７）。いずれのビット位置の値も「０」であれば、検索式でヒットするような帳票データは含まれないことになるので、ステップＳ１０１に移行する。

一方、いずれかのビット位置の値が「１」になっていれば、データ抽出部１５３は、読み出したタグビットマップに対応付けて格納されているポインタを読み出して、当該ポインタが指している圧縮ブロックを第２ＤＢ１４０から読み出し、圧縮処理の逆処理である解凍処理を実施し、データ格納部１５４に格納する（ステップＳ９９）。

その後、データ抽出部１５３は、ＴａｇＪｕｄｇｅに未処理のタグビットマップが存在するか判断する（ステップＳ１０１）。未処理のタグビットマップがＴａｇＪｕｄｇｅに存在する場合には、処理はステップＳ９３に戻る。一方、未処理のタグビットマップがＴａｇＪｕｄｇｅに存在しない場合には、検索部１５５は、データ格納部１５４に格納されているデータに対して、タグをタグＩＤに置換した後の検索式で、解凍後のデータブロックを検索して、検索式の条件を満たす帳票データ（すなわちＸＭＬ文書）を抽出する（ステップＳ１０３）。検索部１５５は、条件を満たす帳票データが存在すれば当該帳票データを、条件を満たす帳票データが存在しない場合にはその旨を、インターフェース部１５１に出力する。インターフェース部１５１は、検索結果を、検索要求の送信元の分析システム等に返信する（ステップＳ１０５）。

以上のような処理を実施することで、タグビットマップにより元のデータレコードがクラスタリングされるので、タグビットマップを用いた検索時にもアクセス先が局所化される。特にデータを圧縮して保持する場合には、このアクセス先の局所化は、解凍処理するデータを削減するように作用するので、検索要求に対するレスポンスの高速化がなされ、処理負荷も下げられる。また、ディスク容量を少なくしてアクセス先も局所化できれば、ディスク装置の管理などにかかる人件費なども削減できる。さらに、タグビットマップの元となるタグ変換表も、タグの出現順にその都度生成されるので、人手による設計を省くことができ、人件費などを削減することができる。

なお、上で述べた実施の形態ではタグ圧縮を実施する例を示したが、場合によってはタグ圧縮を省略するようにしても良い。さらに、場合によってはデータ圧縮自体も行わない場合もある。

さらに、ＴａｇＪｕｄｇｅ及びタグ変換表などのフォーマットについては上で述べた例に限定されず、保管場所についても第２ＤＢ１４０ではなく、他のデータ格納部である場合もある。

［実施の形態２］
第１の実施の形態では、タグビットマップ全体をソートキーとしてソート処理を実施するので、タグの種類数が多くなるとソートキーのビット長も長くなってしまい、ソート処理にかかる時間が長くなる。タグの種類数は、環境によっても変化するが、数千から数万種類存在する場合もある。従って、本実施の形態では、ソート処理の処理時間を抑えるために、ソートキーのビット長をタグビットマップのビット長より短くする。但し、単純にソートキーのビット長を短くして、さらに第１の実施の形態のように単純に出現順にタグ変換表を生成してしまうと、頻繁に検索に用いられるタグについてソート処理が行われないという現象が生じる可能性がある。このような場合には、多数の圧縮ブロックに、頻繁に検索に用いられるタグを含むデータが散在することになり、検索時のアクセス局所化の効果を得られなくなる。従って、以下に述べるような処理を実施することで、ソートキーのビット長を短くする場合であっても、検索処理への影響を抑えるようにする。

本実施の形態の処理の概要を図２６乃至図４６を用いて説明する。本実施の形態は、検索処理において検索に頻繁に用いられたタグほどタグビットマップにおける上位ビットになるようにタグ変換表を生成する。さらに、新たに出現したタグについては、検索に用いられたタグよりも下位のビット位置を割り当てる。

図２６に示すように、例えば２０１１年３月の検索結果などから２０１１年４月の月初のタグ変換表を生成する。本実施の形態では、タグ変換表は、検索式からビットマップを生成する際に用いるタグＩＤであるタグＩＤａと、検索式に含まれるタグをタグ置換する場合に用いるタグＩＤであるタグＩＤｂと、タグ名と、参照回数のカウンタとを含む。２０１１年４月の月初では、タグＩＤａ＝タグＩＤｂであるものとして、参照回数のカウンタは「０」である。

その後、２０１１年４月に１ヶ月間、２０１１年３月分のデータを検索処理において利用した後、例えば２０１１年４月月末の状態になったものとする。参照回数は、降順で「個数」「状況」「申請」「出勤日数」「部門」の順番になる。そうすると、２０１１年５月月初のタグ変換表は、この参照回数の順番に従ってタグＩＤが決定される。すなわち、「個数」「状況」「申請」「出勤日数」「部門」の順番に、タグＩＤａ及びタグＩＤｂが割り振られる。その後、２０１１年５月に１ヶ月間、２０１１年４月分のデータを検索処理において利用した後、例えば２０１１年５月月末の状態になったものとする。なお、２０１１年４月に生成されたデータにおいては、出現するタグの種類に変化がなかった場合の例である。

次に、２０１１年６月月初のタグ変換表を生成する場合には、図２６右下に示したような参照回数に基づき、図２７で示すような参照順位作業表を生成する。すなわち、参照回数に基づきタグ名を降順に並べた表を参照順位作業表として生成する。この例では参照回数０であっても参照順位作業表に登録する。次に、２０１１年５月に生成されたデータを第２ＤＢ１４０に格納する場合には、出現するタグの種類が変化したものとする。例えば、「申請」及び「出勤日数」タグが出現せず、「売上」「商品」「価格」タグが新たに出現したものとする。

このような場合には、「状況」「個数」「申請」「部門」「出勤日数」の各タグのタグＩＤ及びビット位置は確保しておき、これらのタグのうち２０１１年５月に生成されたデータにおいて出現が確認されたタグについては、図２８に示すようにタグ変換ワーク表においてそのビット位置で有効化する。上で述べたように、「申請」及び「出勤日数」タグについては２０１１年５月に生成されたデータについては出現しないので、（空き）となる。そして、新たに出現した「売上」「商品」「価格」タグについては、タグＩＤ「５」「６」「７」が出現順で割り当てられる。このように未使用のタグＩＤが発生してしまうが、タグ変換ワーク表生成を並行してタグビットマップは生成されてしまうので、図２９に示すように、（空き）部分を詰めた形で元のタグＩＤをタグＩＤｂとして採用する。さらに、ＴａｇＪｕｄｇｅについても未使用ビット位置を詰めてデータ量を削減するので、ＴａｇＪｕｄｇｅとの対応付けのために配列順を表すタグＩＤａを設定する。

タグ変換表の生成方法は上で述べたように第１の実施の形態とは異なるが、タグ変換表の基となるタグ変換ワーク表を基に、各ＸＭＬ文書についてタグビットマップを生成するという処理内容は同じである。具体的には、ＸＭＬ文書に含まれるタグのタグＩＤ（タグ変換表のタグＩＤｂ）をタグ変換ワーク表から特定し、当該タグＩＤに対応するビット位置をオン（例えば「１」）にセットする。例えばタグＩＤ「０」「１」「３」のビット位置がオンになっていると、図３０の第１行目のように「１１０１０００００」が生成される。他のＸＭＬ文書についても同様である。

このように生成されたタグビットマップを、図３０に示すように、第１ＤＢ１２０から抽出したデータレコードと連結して、タグビットマップ部分のうち予め定められたソートキー長のビット群（例えば６ビット）をキーにしてソート処理を実施する。このソートキー長が、第１の実施の形態と比較すると短くなっている。

図３０に示したように６レコードを処理する場合には、図３１に示すようにソートされる。本実施の形態では、先頭６ビットでのみソートされるので、下位３ビットの違いは無視される。従って、本来は３つにクラスタリング（グルーピングとも呼ぶ）されるべきであるが、図３１に示すように２つにクラスタリングされる。このように上位ソートキー長は一致するがその他は不一致の類似するタグビットマップも、同一のクラスタに分類される。そして、クラスタ毎に、所属するレコードのデータを圧縮する。すなわち、同一クラスタに分類された１又は複数のレコードのデータをまとめて圧縮して圧縮ブロックを生成して、第２ＤＢ１４０に格納する。図３１の例では、タグビットマップ「００１１１００００」が生成されたレコードは１レコードであるが、このレコードのデータを圧縮して、圧縮ブロックＢｌｋ１を生成し、第２ＤＢ１４０の所定位置に格納する。また、タグビットマップ「１１０１０００００」と「１１０１００１１１」については上位６ビットが「１１０１００」となる類似タグビットマップであり、これら５レコードのうち４レコードを纏めて圧縮して、圧縮ブロックＢｌｋ２を生成し、第２ＤＢ１４０の所定位置に格納する。なお、最後の１レコードについても上位６ビットが「１１０１００」で一致するがデータ量が５レコードで閾値を超えてしまうので、最後の１レコードだけ別に圧縮して、圧縮ブロックＢｌｋ３を生成し、第２ＤＢ１４０の所定位置に格納する。また、１度に第１ＤＢ１２０から抽出されたレコード群については、第２ＤＢ１４０における同一のパーティション等に格納するものとする。

さらに、分析システムなどからの検索要求に対応するために、文書構造索引であるタグジャッジ（TagJudge）も生成される。この例では、図３２に示すようなタグジャッジが生成される。具体的には、タグビットマップの種別毎に、対応する圧縮ブロックへのポインタが登録される。この例では、タグビットマップ「００１１１００００」については圧縮ブロックＢｌｋ１へのポインタｐｔｒが登録され、タグビットマップ「１１０１０００００」については圧縮ブロックＢｌｋ２へのポインタｐｔｒが登録され、タグビットマップ「１１０１００１１１」については圧縮ブロックＢｌｋ２及びＢｌｋ３へのポインタｐｔｒが登録されている。

さらに、本実施の形態では上で述べたようにタグ変換ワーク表からタグ変換表を生成すると共に、上で生成したＴａｇＪｕｄｇｅの変形をも行う。図２６乃至図２９に示した例とは異なっているが、図３３に示すように、タグ変換ワーク表においてタグＩＤ「５」のタグ名が処理したＸＭＬ文書には出現しなかった場合、その部分を上にシフトさせる。そして、タグ変換表における配列番号であり且つ検索処理時に検索式からビットマップを生成する際に用いるタグＩＤであるタグＩＤａを付加する。従って、タグＩＤａについては、シリアルに番号が付与されるが、タグＩＤｂについては、検索式に含まれるタグをタグ置換する場合に用いるので、出現しなかったタグＩＤ「５」を欠番にして並べられる。すなわち、タグ変換ワーク表のタグＩＤがそのまま用いられる。さらに、検索処理時に参照回数をカウントするための列も設けられている。

また、本実施の形態ではタグ変換表の変形に合わせて、ＴａｇＪｕｄｇｅについても図３４に示すような変形を行う。タグＩＤ「５」に対応するビット位置（上位から６ビット目）を削除して左詰にする。これによってＴａｇＪｕｄｇｅのデータ量を削減することができる。

次に、図３５及び図３６を用いて、検索時の処理について概要を説明する。例えば検索式「ＸＱＵＥＲＹ（売上／商品＝テレビ）」を含む検索要求を受信した場合を例に説明する。具体的には、売上タグ又は商品タグについてテレビのデータを含む帳票データブロックを抽出することを要求する検索要求を処理する。

従って、検索式に含まれる条件である「売上」及び「商品」について、タグ変換表から該当するタグＩＤａを読み出す。この例では「５」及び「６」が特定される。そうすると、ビット位置「５」及び「６」が「１」にセットされている検索式のビットマップ３１０１が生成される。図３５の例では「０００００１１０」が得られる。そして、この検索式のビットマップ３１０１と、タグジャッジにおける各レコードに含まれるタグビットマップについてビットＡＮＤ演算を実施する。そして、いずれかのビット位置に「１」が生じる、タグジャッジ内のレコードを特定する。この例では、ビット位置「５」又は「６」に「１」がセットされているレコードは３行目のレコードであり、このレコードが特定される。そうすると、対応する圧縮ブロックＢｌｋ２及びＢｌｋ３へのポインタｐｔｒが得られるので、第２ＤＢ１４０に格納されている圧縮ブロックＢｌｋ２及びＢｌｋ３を読み出すことになる。

また、タグ変換表においては、タグＩＤａが「５」及び「６」のレコードについて参照回数のカウント値を１インクリメントさせる。

次に、図３６に示すように、圧縮ブロックＢｌｋ２及びＢｌｋ３に対して解凍処理を実施して、元のデータレコードを復元する。なお、帳票データブロック内においてはタグ圧縮されているので、検索式についてもタグＩＤｂの方を用いてタグ圧縮してから検索処理を実施する。すなわち、タグ変換表から、検索式は「ＸＱＵＥＲＹ（６／７＝テレビ）」に変換され、解凍処理によって復元されたデータレコードについて検索処理を実施する。この検索処理において条件に合致する帳票データブロックが存在する場合には、当該帳票データブロックを出力する。

このように、タグジャッジによって、解凍する圧縮ブロックの範囲が局所化されるので、検索時における計算コストが低減される。また、並列アクセスによる高速化のための複数ディスク装置の設置や当該複数ディスク装置へのデータ配分についての設計なども不要となる。また、第２ＤＢ１４０へのデータ格納時に行われるソート処理を高速化することもできる。

なお、上で述べた例では参照回数０であっても次のタグ変換ワーク表では上位にタグＩＤが割り振られるが、参照回数０又は予め定められた閾値以下のタグについては上位のタグＩＤを割り振ることなく、例えば今回データ格納を行うＸＭＬ文書に出現した場合には、新たに下位ビットに追加するような変形を行っても良い。

このような処理を実施するデータ移動処理部１３０及び検索処理部１５０の構成は、動作は異なるが図２及び図３に示したものと同様である。従って、構成の説明自体は省略する。

図３７乃至図４６を用いて本実施の形態に係る処理内容を説明する。

データ抽出部１３１は、所定のタイミングで第１ＤＢ１２０から、第２ＤＢ１４０に格納すべきデータレコードを１件抽出し、抽出データ格納部１３２に格納する（図３７：ステップＳ２０１）。そして、タグビットマップ生成部１３３は、抽出されたデータレコードに対して第２タグビットマップ生成処理を実施する（ステップＳ２０３）。第２タグビットマップ生成処理については、図３８及び図３９を用いて説明する。

タグビットマップ生成部１３３は、抽出されたデータレコードに含まれるＸＭＬ文書（帳票データブロック）において未処理のタグを１つ特定し、変数＿ｔに設定する（図３８：ステップＳ２２１）。そして、タグビットマップ生成部１３３は、タグ変換表格納部１３４においてタグ変換ワーク表が生成済みであるか判断する（ステップＳ２２３）。タグ変換ワーク表が未生成である場合には、タグビットマップ生成部１３３は、例えばタグ変換表格納部１３４においてタグ変換ワーク表のための領域を確保する（ステップＳ２２５）。さらに、タグビットマップ生成部１３３は、第２ＤＢ１４０に格納されている前回のタグ変換表から、参照順位作業表（図２７）を生成して、タグ変換表格納部１３４に格納する（ステップＳ２２７）。具体的には、参照回数が多い順にタグを並び替え、その順番で上位のタグＩＤを付与する。そしてステップＳ２２９に移行する。

既にタグ変換ワーク表が生成済みである場合又はステップＳ２２７の後に、タグビットマップ生成部１３３は、＿ｔがタグ変換ワーク表に既に登録済みであるかを判断する（ステップＳ２２９）。タグ名の欄に＿ｔのタグ名が含まれているかを確認する。＿ｔがタグ変換ワーク表に未登録である場合には、タグビットマップ生成部１３３は、参照順位作業表を＿ｔで検索して登録済みであるか否かを判断し、登録済みであれば参照順位作業表におけるタグＩＤを特定し、参照順位作業表に未登録である場合には新規に最下位のタグＩＤを発行する（ステップＳ２３１）。参照順位作業表に既に登録済みのタグの場合には、参照順位作業表におけるタグＩＤを維持し、それ以外の場合には新たに下位のタグＩＤを発行する。そして、タグビットマップ生成部１３３は、タグＩＤと＿ｔをタグ変換ワーク表に登録する（ステップＳ２３３）。そしてステップＳ２３５に移行する。

既に＿ｔがタグ変換ワーク表に登録済みである場合又はステップＳ２３３の後に、タグビットマップ生成部１３３は、タグ変換ワーク表から＿ｔに対応するタグＩＤを取得する（ステップＳ２３５）。そして、処理は端子Ｆを介して図３９の処理に移行する。

図３９の処理の説明に移行して、タグビットマップ生成部１３３は、抽出されたデータレコードについてのタグビットマップにおいて、タグＩＤに対応するビット位置を「１」にセットする（ステップＳ２３７）。なお、タグビットマップのビット長は出現すると予測されるタグの種類数に応じて予め定められた固定長とする。例えば図１６に示すように、先頭に長さＬＬのデータに、ビットマップが付加されたフォーマットを有している。但し、ビットマップ長は、なくてもよい。

そして、タグビットマップ生成部１３３は、タグ圧縮処理として、抽出されたデータレコードに含まれるＸＭＬ文書において、特定されたタグをタグＩＤで置換する（ステップＳ２３９）。図５Ａを図７の１００１に変換する処理に相当する。

その後、タグビットマップ生成部１３３は、抽出されたデータレコードに含まれるＸＭＬ文書において未処理のタグが存在しているか判断する（ステップＳ２４１）。未処理のタグが存在している場合には、端子Ｇを介して図３８のステップＳ２２１に戻る。一方、未処理のタグが存在していない場合には、呼び出し元の処理に戻る。

このような処理を実施すれば、図７のタグビットマップ１００１ｔのようなタグビットマップが生成される。すなわち、データレコードに含まれるＸＭＬ文書におけるタグについての特徴がタグビットマップとして表されることになる。生成されるタグビットマップは、第１の実施の形態と同じであるが、生成されるタグ変換ワーク表は第１の実施の形態におけるタグ変換表とは異なる。

図３７の処理の説明に戻って、タグビットマップ生成部１３３は、生成したタグビットマップ及び抽出されたデータレコードを連結したレコードを、ソート処理部１３５に投入して、ソート処理部１３５に、予め定められたソートキー長だけでソート処理を実施させる（ステップＳ２０５）。なお、ソート処理自体はよく知られた処理なので説明は省略する。なお、ソート処理部１３５は、ソート結果を、抽出データ格納部１３２に格納する。第１の実施の形態とは異なり、タグビットマップ長より短いソートキー長が採用されている。ソートキー長は、ソート処理のパフォーマンスなどに基づき決定される。

そして、データ抽出部１３１は、未処理のデータレコードが第１ＤＢ１２０に存在しているか判断する（ステップＳ２０７）。未処理のデータレコードが存在している場合には、ステップＳ２０１に戻る。

一方、未処理のデータレコードが存在していない場合には、データ格納処理部１３６は、第２データ格納部処理を実施する（ステップＳ２０９）。第２データ格納部処理については、図４０乃至図４４を用いて説明する。

データ格納処理部１３６は、データ量を格納する変数＿ｌｅｎ及び処理に係る直前のタグビットマップを保管する変数＿ｏｔｂを０で初期化する（図４０：ステップＳ２５１）。また、データ格納処理部１３６は、圧縮バッファ１３８に格納されているレコードに対応するタグビットマップを一時保管するためのＷｋＴａｇＢｍｐ一覧を初期化する（ステップＳ２５３）。ＷｋＴａｇＢｍｐ一覧は、例えばメインメモリなどの記憶装置に格納する。

そして、タグ格納処理部１３６は、抽出データ格納部１３２に格納されているソート後のデータレコードのうち未処理のレコードを読み込む（ステップＳ２５５）。その後、タグ格納処理部１３６は、読み込んだレコードに含まれるタグビットマップの上位ソートキー長のビット列を変数＿ｃｔｂに設定する（ステップＳ２５７）。

その後、タグ格納処理部１３６は、読み込まれたレコードが最初のレコードであるか又は＿ｃｔｂ＝＿ｏｔｂであるか判断する（ステップＳ２５９）。読み込まれたレコードが最初のレコードである場合又は＿ｃｔｂ＝＿ｏｔｂである（直前のタグビットマップ（ソートキー長分）と同一のタグビットマップ（ソートキー長分）が特定された場合）場合には、データ格納処理部１３６は、＿ｌｅｎに、読み込まれたレコードのレコード長を加算すると最大サイズ（例えば５ＭＢｙｅｔｓ）を超えるか判断する（ステップＳ２６７）。＿ｌｅｎに、読み込まれたレコードのレコード長を加算しても最大サイズを超える場合には、ステップＳ２６３に移行する。一方、＿ｌｅｎに、読み込まれたレコードのレコード長を加算すると最大サイズを超えない場合には、データ格納処理部１３６は、ＷｋＴａｇＢｍｐ一覧登録処理を実施する（ステップＳ２６９）。このＷｋＴａｇＢｍｐ一覧登録処理については、図４１を用いて説明する。なお、ステップＳ２６９が完了すると、端子Ｈを介して図４４の処理に移行する。

まず、データ格納処理部１３６は、読み込まれたレコードに含まれるタグビットマップがＷｋＴａｇＢｍｐ一覧に登録済みであるか判断する（図４１：ステップＳ２４３）。登録済みであれば、呼び出し元の処理に戻る。一方、未登録である場合、データ格納処理部１３６は、このタグビットマップ全体をＷｋＴａｇＢｍｐ一覧に登録する（ステップＳ２４５）。例えば、図３１の２行目乃至５行目を処理する場合には、２行目だけがＷｋＴａｇＢｍｐ一覧に登録される。なお、ＷｋＴａｇＢｍｐ一覧に登録されたタグビットマップをＷｋＴａｇＢｍｐと呼ぶことにする。その後、呼び出し元の処理に戻る。

図４０の処理の説明に戻って、ステップＳ２５９で、最初のレコードでもなく＿ｃｔｂ＝＿ｏｔｂでもない、すなわち直前のタグビットマップ（ソートキー長分）と異なるタグビットマップ（ソートキー長分）が検出された場合、データ格納処理部１３６は、圧縮バッファ１３８に蓄積されたレコードが存在するか判断する（ステップＳ２６１）。データ格納処理部１３６は、圧縮バッファ１３８に蓄積されたレコードが存在しない場合には、ステップＳ２６９に移行する。一方、圧縮バッファ１３８に蓄積されたレコードが存在する場合には、データ格納処理部１３６は、圧縮処理を実施する（ステップＳ２６３）。圧縮処理については、図４２を用いて説明する。

まず、データ格納処理部１３６は、圧縮バッファ１３８に格納されているレコード群を、所定の方式で圧縮して圧縮ブロックを生成する（図４２：ステップＳ２７１）。そして、データ格納処理部１３６は、圧縮ブロックを第２ＤＢ１４０に格納し、第２ＤＢ１４０における格納位置を取得する（ステップＳ２７３）。この処理は、第１の実施の形態と同様である。

さらに、データ格納処理部１３６は、第２タグジャッジ（ＴａｇＪｕｄｇｅ）登録処理を実施する（ステップＳ２７５）。第２ＴａｇＪｕｄｇｅ登録処理については、図４３を用いて説明する。なお、この処理が完了すると、図４０の処理に戻る。

例えば、図３１の２行目から５行目までが圧縮バッファ１３８に格納されており、２行目及び５行目のタグビットマップがＷｋＴａｇＢｍｐ一覧に登録されているものとする。

まず、データ格納処理部１３６は、ＷｋＴａｇＢｍｐ一覧から未処理のＷｋＴａｇＢｍｐを１つ読み出す（図４３：ステップＳ２８１）。そして、データ格納処理部１３６は、ＷｋＴａｇＢｍｐがＴａｇＪｕｄｇｅに登録済みであるか判断する（ステップＳ２８３）。未登録である場合には、データ格納処理部１３６は、読み出されたＷｋＴａｇＢｍｐをＴａｇＪｕｄｇｅに登録する（ステップＳ２８５）。そして、ステップＳ２８７に移行する。

ＷｋＴａｇＢｍｐがＴａｇＪｕｄｇｅに登録されている場合又はステップＳ２８５の後に、データ格納処理部１３６は、タグジャッジ格納部１３７内のＴａｇＪｕｄｇｅにおいて、該当ＷｋＴａｇＢｍｐに対応付けて、ステップＳ２７３で取得された格納位置を登録する（ステップＳ２８７）。ＴａｇＪｕｄｇｅのデータ構造は図２１に示したものとこの段階では同じである。

このようにして、ＷｋＴａｇＢｍｐ（タグビットマップ）の種別毎に、該当する圧縮ブロックを参照するためのデータ構造を用意することができるようになる。

その後、データ格納処理部１３６は、未処理のＷｋＴａｇＢｍｐがＷｋＴａｇＢｍｐ一覧に存在するか判断する（ステップＳ２８９）。未処理のＷｋＴａｇＢｍｐが存在する場合には、ステップＳ２８１に戻る。一方、未処理のＷｋＴａｇＢｍｐが存在しない場合には、データ格納処理部１３６は、ＷｋＴａｇＢｍｐ一覧を初期化する（ステップＳ２９１）。そして呼び出し元の処理に戻る。

圧縮バッファ１３８には、複数の種類のタグビットマップに係るレコードが蓄積されるので、ＷｋＴａｇＢｍｐ一覧にその複数種類のタグビットマップを登録しておき、ＴａｇＪｕｄｇｅに反映させている。

図４２を介して図４０の処理の説明に戻って、データ格納処理部１３６は、変数＿ｌｅｎを０に初期化する（ステップＳ２６５）。そしてステップＳ２６９に移行する。

ステップＳ２６９の処理の後、図４４の処理に移行する。

図４４の処理の説明に移行して、データ格納処理部１３６は、ステップＳ２５５で読み出したレコードを圧縮バッファ１３８に蓄積する（ステップＳ３０１）。そして、データ格納処理部１３６は、変数＿ｌｅｎに、圧縮バッファ１３８に格納したレコードのレコード長を加算する（ステップＳ３０３）。さらに、データ格納処理部１３６は、変数＿ｏｔｂに＿ｃｔｂを設定する（ステップＳ３０５）。

その後、データ格納処理部１３６は、抽出データ格納部１３２においてソート後のレコード群において未処理のレコードが存在しているか判断する（ステップＳ３０７）。未処理のレコードが存在している場合には、端子Ｉを介して図４０のステップＳ２５５に戻る。未処理のレコードが存在しない場合には、データ格納処理部１３６は、圧縮バッファ１３８が空であるか判断する（ステップＳ３０９）。空でない場合には、データ格納処理部１３６は、圧縮処理を実施する（ステップＳ３１１）。ステップＳ２６３と同じ処理を実施する。これによって圧縮バッファ１３８に残っていたデータを処理することができる。そしてステップＳ３１３に移行する。一方、圧縮バッファ１３８がちょうど空であればステップＳ３１３に移行する。

このような処理を実施することで、レコードが圧縮されて第２ＤＢ１４０に蓄積されると共に、検索のための索引構造データである初期段階のＴａｇＪｕｄｇｅが構築されるようになる。

その後、データ格納処理部１３６は、タグ変換表格納部１３４に格納されているタグ変換ワーク表から、タグ変換表を生成する（ステップＳ３１３）。図３３に示すように、タグ名の列にタグ名が登録されていない行を上にシフトさせて、シリアルにタグＩＤａを上位タグＩＤから付与する。さらに、参照回数を登録する列を設ける。このようにしてタグ変換表が生成される。

さらに、タグ変換ワーク表においてタグ名が登録されていないタグＩＤに対応するビット位置はＴａｇＪｕｄｇｅ（タグビットマップ部分）における未使用ビットとなるので、データ格納処理部１３６は、未使用ビットを前方シフトさせて、変更後のＴａｇＪｕｄｇｅを生成する（ステップＳ３１５）。そして、呼び出し元の処理に戻る。

このような処理を実施することで、タグ変換表及びＴａｇＪｕｄｇｅが完成することになる。

図３７の処理の説明に戻って、データ格納処理部１３６は、タグジャッジ格納部１３７におけるＴａｇＪｕｄｇｅ及びタグ変換表格納部１３４に格納されているタグ変換表を、纏めて第２ＤＢ１４０に格納する（ステップＳ２１１）。第２ＤＢ１４０は、圧縮ブロックを含むファイルに加えて、図２３に示すようなデータが格納されるようになる。すなわち、タグ変換表とＴａｇＪｕｄｇｅとを含む、検索のための索引構造データが格納される。但し、タグ変換表の構造は第１の実施の形態とは異なっている。また、ＴａｇＪｕｄｇｅにおけるタグビットマップ（ＴａｇＢｍｐ）も、未使用ビットをシフトさせているので長さが異なっている。

次に、検索時の処理について図４５及び図４６を用いて説明する。検索処理部１５０のインターフェース部１５１は、分析システムなどから検索式を含む検索要求を受信する（図４５：ステップＳ３２１）。そうすると、インターフェース部１５１は、検索式のデータを、検索式処理部１５２に出力する。検索式処理部１５２は、検索要求の検索式に含まれる未処理のタグを１つ特定し、変数＿ｔに設定する（ステップＳ３２３）。そして、検索式処理部１５２は、第２ＤＢ１４０に格納されているタグ変換表から、＿ｔに対応するタグＩＤａ及びタグＩＤｂを取得する（ステップＳ３２５）。図３６に示したような処理を行うためである。

その後、検索式処理部１５２は、検索式におけるタグをタグＩＤｂに置換する（ステップＳ３２７）。また、検索式処理部１５２は、タグ変換表において＿ｔの参照回数を１インクリメントする（ステップＳ３２９）。

さらに、検索式処理部１５２は、ビットマップ＿ｓｔｂにおいて、タグＩＤａに対応するビット位置の値を「１」にセットする（ステップＳ３３１）。図３５に示したようなビットマップ３１０１を生成するための処理である。

その後、検索式処理部１５２は、未処理のタグが検索式に存在しているか判断する（ステップＳ３３３）。未処理のタグが存在する場合にはステップＳ３２３に戻る。一方、未処理のタグが存在しない場合には、検索式処理部１５２は、ビットマップ＿ｓｔｂをデータ抽出部１５３に出力し、置換処理後の検索式のデータを検索部１５５に出力する。そして、処理は端子Ｊを介して図４６の処理に移行する。

図４６の処理の説明に移行して、データ抽出部１５３は、第２ＤＢ１４０に格納されているＴａｇＪｕｄｇｅにおける未処理のタグビットマップを１つ＿ｔｔｂに設定する（ステップＳ３３５）。そして、データ抽出部１５３は、ビットマップ＿ｓｔｂと読み出したタグビットマップ＿ｔｔｂとのビットＡＮＤを計算する（ステップＳ３３７）。そして、データ抽出部１５３は、いずれかのビット位置の値が「１」になっているか判断する（ステップＳ３３９）。いずれのビット位置の値も「０」であれば、検索式でヒットするような帳票データは含まれないことになるので、ステップＳ３４３に移行する。

一方、いずれかのビット位置の値が「１」になっていれば、データ抽出部１５３は、読み出したタグビットマップに対応付けて格納されているポインタを読み出して、当該ポインタが指している圧縮ブロックを第２ＤＢ１４０から読み出し、圧縮処理の逆処理である解凍処理を実施し、データ格納部１５４に格納する（ステップＳ３４１）。

その後、データ抽出部１５３は、ＴａｇＪｕｄｇｅに未処理のタグビットマップが存在するか判断する（ステップＳ３４３）。未処理のタグビットマップがＴａｇＪｕｄｇｅに存在する場合には、処理はステップＳ３３５に戻る。一方、未処理のタグビットマップがＴａｇＪｕｄｇｅに存在しない場合には、検索部１５５は、データ格納部１５４に格納されているデータに対して、タグをタグＩＤに置換した後の検索式で、解凍後のデータブロックを検索して、検索式の条件を満たす帳票データ（すなわちＸＭＬ文書）を抽出する（ステップＳ３４５）。検索部１５５は、条件を満たす帳票データが存在すれば当該帳票データを、条件を満たす帳票データが存在しない場合にはその旨を、インターフェース部１５１に出力する。インターフェース部１５１は、検索結果を、検索要求の送信元の分析システム等に返信する（ステップＳ３４７）。

以上のような処理を実施することで、タグビットマップにより元のデータレコードがクラスタリングされるので、タグビットマップを用いた検索時にもアクセス先が局所化される。特にデータを圧縮して保持する場合には、このアクセス先の局所化は、解凍処理するデータを削減するように作用するので、検索要求に対するレスポンスの高速化がなされ、処理負荷も下げられる。また、ディスク容量を少なくしてアクセス先も局所化できれば、ディスク装置の管理などにかかる人件費なども削減できる。さらに、タグビットマップの元となるタグ変換表も、タグの出現順にその都度生成されるので、人手による設計を省くことができ、人件費などを削減することができる。

なお、上で述べた実施の形態ではタグ圧縮を実施する例を示したが、場合によってはタグ圧縮を省略するようにしても良い。さらに、場合によってはデータ圧縮自体も行わない場合もある。

さらに、ＴａｇＪｕｄｇｅ及びタグ変換表などのフォーマットについては上で述べた例に限定されず、保管場所についても第２ＤＢ１４０ではなく、他のデータ格納部である場合もある。

また、第２の実施の形態では、タグの種類が多くなってもソート処理の速度を高速化できるため、データ格納処理の処理時間を短縮することができる。

以上本技術に係る実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上で述べた機能ブロック図は一例であり、必ずしも実際のプログラムモジュールと一致しない場合もある。さらに、処理フローについても、処理結果が変わらない限り、処理順番を入れ替えたり、並列実行するようにしても良い。

以上本技術の実施の形態について説明したが、本技術はこれに限定されるものではない。例えば、図２及び図３の機能ブロック図は一例であって、必ずしも実際のプログラムモジュール構成と一致しない。また、処理フローについても、処理結果が変わらない限り、ステップの順番を入れ替えたり、並列に実行しても良い場合もある。

また、第２の実施の形態で図３３や図３４で示す処理を省略するようにしても良い。

さらに、図１に示したシステムは、１台のコンピュータで実現されるものもあれば、複数台のコンピュータで実現される場合もある。

なお、上で述べたＤＢ管理システムは、コンピュータ装置であって、図４７に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

実施の形態の第１の態様に係る情報処理方法は、（Ａ）格納すべき複数のデータブロックから当該複数のデータブロックの各々に含まれる１又は複数のタグを抽出して、当該タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１のステップと、（Ｂ）複数のデータブロックについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２のステップと、（Ｃ）複数のグループのうち各グループについて、当該グループに属するビット列に対応するデータブロックのデータを、当該グループに属するビット列の種類に対応付けてデータ格納部に格納する第３のステップとを含む。

このようにデータブロックを、そのデータブロックに出現するタグの種類を表すビット列によって特徴付け、当該ビット列に基づきデータブロックをグループ化（又はクラスタリング）して、ビット列の種類に対応付けてデータ格納部に格納すると、タグベースの検索時に適切なデータブロックを効率的に読み出すことができるようになる。

また、上で述べた第１のステップは、データブロックから新たな種類のタグが抽出された場合には、当該タグに未使用の識別番号を割り当て、当該タグの種類と割り当てられた識別番号とを対応付けて第２のデータ格納部に格納するステップを含むようにしてもよい。この際、ビット位置は識別番号と対応付けられている。このようにすれば、格納すべきデータブロックに応じて自動的にビット列生成のルールが生成されるので、格納すべきデータブロックの種類などが変化しても、人手でシステム変更を行わずに済む。

さらに、上で述べた第１のステップは、第２のデータ格納部に格納されており且つタグの検索利用頻度に応じて生成される、タグと当該タグの識別番号との第１の対応付けデータに含まれないタグが、データブロックから抽出された場合には、当該タグに未使用の識別番号を割り当て、当該タグと割り当てられた識別番号との対応付けデータを第２のデータ格納部に格納するステップを含むようにしても良い。このようにすれば、検索利用頻度の高いタグほどビット列において上位のビットを割り当てるといったことも可能になる。そうすれば、例えばビット列のうち上位の一部のビットだけを見てグループ化しても、検索時の効率の低下を最小限に抑えることができるようになる。

また、上で述べた第２のステップが、ビット列のビット長又は当該ビット長よりも短く且つ予め定められた第２のビット長で、複数のビット列をソートするステップを含むようにしても良い。分類処理についてはこのような処理で実装される場合もある。

さらに、上で述べた第３の処理が、グループに属するビット列に対応するデータブロック又は当該データブロックに含まれるタグが当該タグの識別番号で置換されたデータブロックを圧縮するステップを含むようにしても良い。このように圧縮すれば、ディスク容量を削減することができる。

本実施の形態の第２の態様に係る情報処理方法は、（Ａ）指定されたタグについて検索することを要求する検索要求を受信する第１のステップと、（Ｂ）タグと識別番号との第１の対応付けデータから、上記指定されたタグに対応する識別番号を特定し、特定された識別番号に対応するビット位置をオンにしたビット列を生成する第２のステップと、（Ｃ）ビット列と当該ビット列においてオンとなっているビット位置に対応する識別番号が対応付けられているタグを含むデータブロックのデータとの第２の対応付けデータにおいて、生成されたビット列においてオンにセットされたビット位置の少なくともいずれかがオンとなっているビット列を特定し、特定されたビット列に対応付けられているデータブロックを、複数のデータブロックを格納するデータ格納部から読み出す第３のステップと、（Ｄ）読み出したデータブロックを検索要求に従って検索する第４のステップとを含む。

このようにすれば、検索要求に含まれるタグを含むデータブロックを効率的に読み出すことができるようになる。

本実施の形態の第２の態様に係る情報処理方法においては、第１の対応付けデータに関連して各タグの検索利用頻度を管理している場合もある。その際には、本情報処理方法は、指定されたタグについての検索利用頻度を増加させるステップをさらに含むようにしても良い。このようにすれば、第１の対応付けデータ及び第２の対応付けデータを、検索実態に合わせて生成することができるようになる。

さらに、本実施の形態の第３の態様に係る情報処理装置（図４８）は、（Ａ）格納すべき複数のデータブロックから当該複数のデータブロックの各々に含まれる１又は複数のタグを抽出して、当該タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１の処理部（３０１０）と、（Ｂ）複数のデータブロックについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２の処理部（３０２０）と、（Ｃ）複数のグループのうち各グループについて、当該グループに属するビット列に対応するデータブロックのデータを、当該グループに属するビット列の種類に対応付けてデータ格納部（３０４０）に格納する第３の処理部（３０３０）とを有する。

また、本実施の形態の第４の態様に係る情報処理装置（図４９）は、（Ａ）指定されたタグについて検索することを要求する検索要求を受信する受信部（３５１０）と、（Ｂ）タグと識別番号との第１の対応付けデータから、上記指定されたタグに対応する識別番号を特定し、特定された識別番号に対応するビット位置をオンにしたビット列を生成する処理部（３５２０）と、（Ｃ）ビット列と当該ビット列においてオンとなっているビット位置に対応する識別番号が対応付けられているタグを含むデータブロックのデータとの第２の対応付けデータにおいて、生成されたビット列においてオンにセットされたビット位置の少なくともいずれかがオンとなっているビット列を特定し、特定されたビット列に対応付けられているデータブロックを、複数のデータブロックを格納するデータ格納部（３５４０）から読み出すデータ抽出部（３５３０）と、（Ｄ）読み出したデータブロックを検索要求に従って検索する検索部（３５５０）とを有する。

なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
コンピュータに、
複数のデータのうちの所定種類のタグを含むデータ群を圧縮して、圧縮ファイルを生成し、
生成した前記圧縮ファイルを、前記所定の種類のタグを識別可能な識別情報と関連付けて記憶部に格納する、
ことを実行させることを特徴とする記憶制御プログラム。

（付記２）
前記データ群が、前記複数のデータのうち所定の複数種類のタグを含むデータ群であり、
前記識別情報が、前記所定の複数種類のタグを識別可能な識別情報である、
ことを特徴とする付記１記載の記憶制御プログラム。

（付記３）
コンピュータに、
複数のデータブロックから前記複数のデータブロックの各々に含まれる１又は複数のタグを抽出して、抽出された前記タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１の処理と、
前記複数のデータブロックについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２の処理と、
分類して得られた前記複数のグループのうちの各グループについて、当該グループに属するビット列に対応するデータブロックのデータを、当該グループに属するビット列の種類に対応付けてデータ格納部に格納する第３の処理と、
を実行させることを特徴とするプログラム。

（付記４）
前記第１の処理は、
前記データブロックから新たな種類のタグが抽出された場合には、当該タグに未使用の識別番号を割り当て、当該タグの種類と割り当てられた識別番号とを対応付けてデータ記憶部に格納する処理を含み、
前記ビット位置は前記識別番号と対応付けられている
付記３記載のプログラム。

（付記５）
前記第１の処理は、
データ記憶部に格納されている、タグと当該タグの識別番号とを対応付けたデータに含まれないタグが、前記データブロックから抽出された場合には、当該タグに未使用の識別番号を割り当て、当該タグと割り当てられた識別番号とを対応付けたデータを前記データ記憶部に格納する処理
を含む付記３記載のプログラム。

（付記６）
前記第２の処理が、
前記ビット列が同一であるか、又は前記ビット列のうちの前記ビット列のビット長よりも短い所定のビット長の一部分が一致するかに基づいて、前記複数のグループに分類する処理
であることを特徴とする付記３乃至５のいずれか１つ記載のプログラム。

（付記７）
前記第３の処理が、
前記グループに属するビット列に対応するデータブロックを圧縮する処理
を含む付記３乃至６のいずれか１つ記載のプログラム。

（付記８）
コンピュータに、
あるタグについての検索要求を受信した場合に、データを圧縮して得られる圧縮データを、前記データ内に含まれるタグを識別可能な識別情報と関連付けて格納する格納部から、前記あるタグの識別情報と関連付けられた圧縮データを特定し、
特定した前記圧縮データを伸張し、
伸張して得られたデータに対して前記あるタグについての検索処理を行う、
ことを実行させることを特徴とする検索制御プログラム。

（付記９）
指定されたタグについて検索することを要求する検索要求を受信する第１の処理と、
タグと識別番号との第１の対応付けデータから、前記指定されたタグに対応する識別番号を特定し、特定された識別番号に対応するビット位置をオンにしたビット列を生成する第２の処理と、
ビット列と当該ビット列においてオンとなっているビット位置に対応する識別番号が対応付けられているタグを含むデータブロックのデータとの第２の対応付けデータにおいて、生成されたビット列においてオンにセットされたビット位置の少なくともいずれかがオンとなっているビット列を特定し、特定されたビット列に対応付けられているデータブロックを、複数のデータブロックを格納するデータ格納部から読み出す第３の処理と、
読み出したデータブロックを前記検索要求に従って検索する第４の処理と、
を、コンピュータに実行させるためのプログラム。

（付記１０）
前記第１の対応付けデータに関連して各タグの検索利用頻度を管理しており、
前記指定されたタグについての検索利用頻度を増加させる処理
を、さらに前記コンピュータに実行させるための付記９記載のプログラム。

（付記１１）
複数のデータブロックから前記複数のデータブロックの各々に含まれる１又は複数のタグを抽出して、抽出された前記タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１の処理と、
前記複数のデータブロックについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２の処理と、
分類して得られた前記複数のグループのうちの各グループについて、当該グループに属するビット列に対応するデータブロックのデータを、当該グループに属するビット列の種類に対応付けてデータ格納部に格納する第３の処理と、
を、コンピュータが実行する情報処理方法。

（付記１２）
指定されたタグについて検索することを要求する検索要求を受信する第１の処理と、
タグと識別番号との第１の対応付けデータから、前記指定されたタグに対応する識別番号を特定し、特定された識別番号に対応するビット位置をオンにしたビット列を生成する第２の処理と、
ビット列と当該ビット列においてオンとなっているビット位置に対応する識別番号が対応付けられているタグを含むデータブロックのデータとの第２の対応付けデータにおいて、生成されたビット列においてオンにセットされたビット位置の少なくともいずれかがオンとなっているビット列を特定し、特定されたビット列に対応付けられているデータブロックを、複数のデータブロックを格納するデータ格納部から読み出す第３の処理と、
読み出したデータブロックを前記検索要求に従って検索する第４の処理と、
を、コンピュータが実行する情報処理方法。

（付記１３）
複数のデータブロックから前記複数のデータブロックの各々に含まれる１又は複数のタグを抽出して、抽出された前記タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１の処理部と、
前記複数のデータブロックについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２の処理部と、
分類して得られた前記複数のグループのうちの各グループについて、当該グループに属するビット列に対応するデータブロックのデータを、当該グループに属するビット列の種類に対応付けてデータ格納部に格納する第３の処理部と、
を有する情報処理装置。

（付記１４）
指定されたタグについて検索することを要求する検索要求を受信する受信部と、
タグと識別番号との第１の対応付けデータから、前記指定されたタグに対応する識別番号を特定し、特定された識別番号に対応するビット位置をオンにしたビット列を生成する処理部と、
ビット列と当該ビット列においてオンとなっているビット位置に対応する識別番号が対応付けられているタグを含むデータブロックのデータとの第２の対応付けデータにおいて、生成されたビット列においてオンにセットされたビット位置の少なくともいずれかがオンとなっているビット列を特定し、特定されたビット列に対応付けられているデータブロックを、複数のデータブロックを格納するデータ格納部から読み出すデータ抽出部と、
読み出したデータブロックを前記検索要求に従って検索する検索部と、
を有する情報処理装置。

（付記１５）
コンピュータが、
複数のデータのうちの所定種類のタグを含むデータ群を圧縮して、圧縮ファイルを生成し、
生成した前記圧縮ファイルを、前記所定の種類のタグを識別可能な識別情報と関連付けて記憶部に格納する、
ことを実行することを特徴とする記憶制御プログラム。

（付記１６）
複数のデータのうちの所定種類のタグを含むデータ群を圧縮して、圧縮ファイルを生成する生成部と、
生成した前記圧縮ファイルを、前記所定の種類のタグを識別可能な識別情報と関連付けて記憶部に記憶する記憶処理部と、
を含むことを特徴とする記憶制御装置。

（付記１７）
コンピュータが、
あるタグについての検索要求を受信した場合に、データを圧縮して得られる圧縮データを、前記データ内に含まれるタグを識別可能な識別情報と関連付けて格納する格納部から、前記あるタグの識別情報と関連付けられた圧縮データを特定し、
特定した前記圧縮データを伸張し、
伸張して得られたデータに対して前記あるタグについての検索処理を行う、
ことを実行することを特徴とする検索制御方法。

（付記１８）
あるタグについての検索要求を受信した場合に、データを圧縮して得られる圧縮データを、前記データ内に含まれるタグを識別可能な識別情報と関連付けて格納する格納部から、前記あるタグの識別情報と関連付けられた圧縮データを特定する特定部と、
特定した前記圧縮データを伸張する伸張部と、
伸張して得られたデータに対して前記あるタグについての検索処理を行う検索部と、
を含むことを特徴とする検索制御装置。

１ ネットワーク
１００ ＤＢ管理システム
１１０ 記録管理部
１２０ 第１ＤＢ
１３０ データ移動処理部
１４０ 第２ＤＢ
１５０ 検索処理部
１３１ データ抽出部
１３２ 抽出データ格納部
１３３ タグビットマップ生成部
１３４ タグ変換表格納部
１３５ ソート処理部
１３６ データ格納処理部
１３７ タグジャッジ格納部
１３８ 圧縮バッファ
１５１ インターフェース部
１５２ 検索式処理部
１５３ データ抽出部
１５４ データ格納部
１５５ 検索部

Claims (7)

1. コンピュータに、
   複数のデータブロックそれぞれに含まれる１又は複数のタグを抽出して、抽出された前記タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１の処理と、
   前記複数のデータブロックそれぞれについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２の処理と、
   分類して得られた前記複数のグループそれぞれについて、グループに属するビット列に対応するデータブロックのデータを、グループに属するビット列の種類に対応付けてデータ格納部に格納する第３の処理と、
   を実行させることを特徴とするプログラム。
2. 前記第１の処理は、
   前記データブロックから新たな種類のタグが抽出された場合には、当該タグに未使用の識別番号を割り当て、当該タグの種類と割り当てられた識別番号とを対応付けてデータ記憶部に格納する処理を含み、
   前記ビット位置は前記識別番号と対応付けられている
   請求項１記載のプログラム。
3. 前記第１の処理は、
   データ記憶部に格納されている、タグとタグの識別番号とを対応付けたデータに含まれないタグが、前記データブロックから抽出された場合には、タグに未使用の識別番号を割り当て、タグと割り当てられた識別番号とを対応付けたデータを前記データ記憶部に格納する処理
   を含む請求項１記載のプログラム。
4. 前記第２の処理が、
   前記ビット列が同一であるか、又は前記ビット列のうちの前記ビット列のビット長よりも短い所定のビット長の一部分が一致するかに基づいて、前記複数のグループに分類する処理
   であることを特徴とする請求項１乃至３のいずれか１つ記載のプログラム。
5. 前記第３の処理が、
   前記グループに属するビット列に対応するデータブロックを圧縮する処理
   を含む請求項１乃至４のいずれか１つ記載のプログラム。
6. 複数のデータブロックそれぞれに含まれる１又は複数のタグを抽出して、抽出された前記タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１の処理と、
   前記複数のデータブロックそれぞれについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２の処理と、
   分類して得られた前記複数のグループそれぞれについて、グループに属するビット列に対応するデータブロックのデータを、グループに属するビット列の種類に対応付けてデータ格納部に格納する第３の処理と、
   を、コンピュータが実行する情報処理方法。
7. 複数のデータブロックそれぞれに含まれる１又は複数のタグを抽出して、抽出された前記タグの種類に対応するビット位置がオンにセットされたビット列を生成する第１の処理部と、
   前記複数のデータブロックそれぞれについて生成された複数のビット列を同一の又は一部一致するビット列に基づき複数のグループに分類する第２の処理部と、
   分類して得られた前記複数のグループそれぞれについて、グループに属するビット列に対応するデータブロックのデータを、グループに属するビット列の種類に対応付けてデータ格納部に格納する第３の処理部と、
   を有する情報処理装置。

Images