データ処理システム
【課題】DBサーバにおけるレンジスキャンの頻度を低減し、検索処理の高速化を実現する。
【解決手段】DBサーバ14とAPサーバ12を備えたデータ処理システム10。APサーバ12は、メモリ26と、DBサーバ14に対しテーブルのキー項目に係るデータの読み出しを指令するデータ処理部22と、DBサーバ14から送信されたデータを圧縮し、メモリ26にインデックスとして格納するインデックス生成部24を備える。
【効果】テーブルのキー項目の内容がAPサーバ12のメモリ26上にキャッシュされているため、DBサーバ14に検索を指令する際にはキー項目の値の全てを特定し、対象となるレコードをピンポイントで絞り込んだSQL文の発行が可能となり、DBサーバ14におけるレンジスキャンの低減が可能。
【解決手段】DBサーバ14とAPサーバ12を備えたデータ処理システム10。APサーバ12は、メモリ26と、DBサーバ14に対しテーブルのキー項目に係るデータの読み出しを指令するデータ処理部22と、DBサーバ14から送信されたデータを圧縮し、メモリ26にインデックスとして格納するインデックス生成部24を備える。
【効果】テーブルのキー項目の内容がAPサーバ12のメモリ26上にキャッシュされているため、DBサーバ14に検索を指令する際にはキー項目の値の全てを特定し、対象となるレコードをピンポイントで絞り込んだSQL文の発行が可能となり、DBサーバ14におけるレンジスキャンの低減が可能。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ処理システムに係り、特に、APサーバ内にDBサーバのデータベースに含まれるレコードのキー項目の値をキャッシュしておき、DBサーバにSQL文を発行するに際しては全キー項目の値を特定することにより、検索処理等の高速化を実現する技術に関する。
【背景技術】
【０００２】
クライアントサーバ型システムの進展に伴い、より大規模な情報処理の要求に応えるために、データの表示をするクライアントの他にデータの加工を行うAPサーバ及びデータの格納をするDBサーバを備えた、いわゆる三層構造のクライアントサーバシステムが普及してきている。
また、処理速度の向上を図るため、複数のAPサーバを並列配置させることで負荷を分散させることも行われている。
【特許文献１】特開２００５−１６５６１０
【発明の開示】
【発明が解決しようとする課題】
【０００３】
APサーバは廉価なPCサーバで構成することができるため、設置台数を増加させることで処理速度を向上させることは比較的容易であるが、DBサーバについてはデータの同期を維持する必要性があるため、APサーバのように簡単に分散処理に移行することはできない。
もちろん、データベースシステムのベンダ各社は、様々な技術を駆使してソフトウェア及びハードウェアの両面からDBサーバ自体の高速化を図ってきており、その結果一定の成果は上がっているが、その分システムの価格が上昇することは否めない。
また、今後ともクライアントサーバ型システムに担わされるデータベースの規模が増大を続ける限り、いずれはディスクI/O（データの読み書き）速度が壁となり、DBサーバの性能アップでは対応できない時期が来るものと予想される。
【０００４】
ところで、DBサーバにおける検索処理に時間を要するのは、一般にレンジスキャン（範囲走査）と呼ばれる処理を実行する場合である。
すなわち、図２に示すテーブルを例に説明すると、APサーバがSQL文を発行する際に日付、店Cd（店コード）、商品Cd（商品コード）のキー項目の値を全て指定してやれば、目的のレコードが一意に決まるためDBサーバは即座に必要なデータにアクセス可能となる。
これに対し、SQL文中で日付、店Cdのみを指定してデータの抽出を命令した場合、DBサーバは指定された日付、商品Cdに係る全てのレコードを先頭レコードから走査して該当のレコードを抽出する必要が生じ、その分時間を要することとなる。
【０００５】
データベースの検索速度を向上させるために、通常は各テーブル毎にインデックス（索引情報）が生成され、これを参照することでDBサーバは検索処理の高速化をある程度達成することができる。
しかしながら、キー項目の数が多くなり、その組合せパターンが複雑化する場合には一次インデックス、二次インデックス…というように予想される検索パターンに対応したインデックスファイルを多数準備する必要が生じ、かえってディスクI/Oが増加する結果となる。
【０００６】
また、キー項目を細分化し、例えば商品Cdの上位キーとして「商品分類Cd」を設定しておき、検索条件を指定する際に商品分類コードまで特定するように促すことで、DBサーバ側でのレンジスキャンの幅を抑制することも行われているが、これはレンジスキャン自体を一掃するものではないし、レコード長の増大を招くという欠点もある。
【０００７】
この発明は、従来のデータ処理システムが抱えていた上記の問題を解決するために案出されたものであり、DBサーバ自体の性能アップに依存するのではなく、また過度なインデックス情報の生成や上位キー項目の追加を行うことなく、APサーバ側の処理工程に改良を加えることによってDBサーバにおけるレンジスキャンの頻度を低減し、もって検索処理の高速化を実現することを目的としている。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１に記載したデータ処理システムは、DBサーバとAPサーバを備えたデータ処理システムであって、上記DBサーバが、データベース管理システムと、テーブルを格納したデータベースを備え、上記APサーバが、上記DBサーバにSQL文を発行し、上記テーブルのキー項目に係るデータの読み出しを指令するデータ読み出し手段と、DBサーバから送信されたキー項目に係るデータを圧縮し、上記APサーバの記憶手段に上記テーブルのインデックスとして格納するインデックス生成手段と、クライアント端末から上位キー項目を検索条件として指定した検索リクエストが送信された場合に、上記APサーバのインデックスを参照し、上記検索条件に包含されるキー項目の値を取得するキー項目値取得手段と、各キー項目の値を特定したSQL文を生成し、上記DBサーバに発行する手段とを備えたことを特徴としている。
【０００９】
請求項２に記載したデータ処理システムは、請求項１のシステムであって、さらに上記のデータ読み出し手段が、上記SQL文において一または複数のキー項目の値を指定することにより、上記DBサーバから上記テーブルをグループに分割して読み出す処理を実行し、上記のインデックス生成手段が、圧縮処理をグループ単位で実行することを特徴としている。
【００１０】
請求項３に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信されたデータ中において値が相互に重複するものが存在する場合に、一つの値のみを実データとしてメモリ上に残し、他の値については上記実データを参照する型に変換する処理を実行し、参照型データを含む表形式のインデックスを生成することを特徴としている。
【００１１】
請求項４に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、少なくとも最上位のキー項目毎に対応のフォルダをAPサーバのディスク上に生成する第１の処理と、各最上位のキー項目に包含される１または複数の中位キー項目に対応したファイルを生成し、対応のフォルダに格納する第２の処理と、各中位のキー項目に包含される１または複数の下位キー項目の値を対応のファイルに記述する第３の処理を実行することを特徴としている。
【００１２】
請求項５に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、残された最上位のキー項目を一つの根の元に結合させることにより、木構造のインデックスをAPサーバのメモリ上に生成する第２の処理を実行することを特徴としている。
【００１３】
請求項６に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、値が相互に重複する下位のキー項目については、一の値のみを実データとしてAPサーバのメモリ上に残し、他の値については上記実データを参照する型に変換する第２の処理と、残された最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する第３の処理を実行することを特徴としている。
【００１４】
請求項７に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各レコードの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、各レコードの下位のキー項目の値と先行レコードの同キー項目の値とを順次比較し、先行レコードの値と重複する値を削除すると共に、先行レコードの値を参照する型に変換する第２の処理と、残された上位キー項目同士を一つの根の元に結合させ、参照型を含む木構造のデータを生成する第３の処理を実行することを特徴としている。
【００１５】
請求項８に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第１の処理と、各レコードを下位のキー項目の値に基づいて所定の順序で整列させ、下位のキー項目の値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第２の処理と、各レコードを少なくとも最上位のキー項目の値に基づいて所定の順序で整列させる第３の処理と、残された最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のデータを生成する第４の処理を実行することを特徴としている。
【００１６】
請求項９に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、残された最上位のキー項目を一つの根の元に結合させて木構造のデータを生成する第２の処理と、上記木構造のデータに含まれる最下位のキー項目の類型を抽出し、これらを要素として充填させたディスティンクト・リストをメモリ上に生成する第３の処理と、上記ディスティンクト・リストに含まれる各要素と上記木構造のデータに含まれる最下位のキー項目の各値とをマッチングし、最下位のキー項目の各値をディスティンクト・リスト中の対応の要素を参照する型に変換する第４の処理を実行することを特徴としている。
【００１７】
請求項１０に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第４の処理を実行し、上記キー項目値取得手段が、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴としている。
【００１８】
請求項１１に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第４の処理と、上記のブーリアン配列をビット配列に変換する第５の処理を実行し、上記キー項目値取得手段が、各ビット配列をブーリアン配列に変換し、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴としている。
【００１９】
請求項１２に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたビット配列における対応位置に１をセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ビット配列の対応位置に０をセットする第４の処理を実行し、上記キー項目値取得手段が、各ビット配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴としている。
【発明の効果】
【００２０】
請求項１、３〜１２に記載したデータ処理システムにあっては、DBサーバ内に格納されているテーブルのキー項目の内容が、APサーバのメモリやディスク上にキャッシュされるため、DBサーバに検索を指令する際にはキー項目の値の全てを特定し、対象となるレコードをピンポイントで絞り込んだ形のSQL文を発行することが可能となる。この結果、DBサーバにおいてレンジスキャンが発生することがなくなり、その分検索処理の高速化を実現できる。
【００２１】
請求項２に記載したデータ処理システムの場合、APサーバがデータをDBサーバから取り出すに際し、全レコードに係るキー項目のデータ全体を一度に受け取るのではなく、特定のキー項目の値を指定することにより、グループ単位に分割して受け取り、当該グループについて圧縮処理が完了した時点で次のグループに係るレコードを受け取る方式を採用しているため、比較的大きなテーブルであってもAPサーバのメモリ上にキー項目をキャッシュできるようになる。
【発明を実施するための最良の形態】
【００２２】
図１は、この発明に係るデータ処理システム10の全体構成図であり、このシステム10は、複数のAPサーバ12と、DBサーバ14と、ロードバランサ（負荷分散装置）16とを備えている。
ロードバランサ16と各APサーバ12間、及び各APサーバ12とDBサーバ14間はネットワークによって接続されている。
また、各APサーバ12に対しては、イントラネット18やインターネット等のネットワーク及びロードバランサ16を介して多数のクライアント端末20が接続されている。
【００２３】
各APサーバ12は、データ処理部22と、インデックス生成部24と、メモリ26と、ハードディスク（HDD）27を備えている。
各APサーバ12のハードディスク27には、OS及びこのシステム専用のアプリケーションプログラムがセットアップされており、APサーバ12のCPUがこれらのプログラムに従って動作することにより、上記のデータ処理部22及びインデックス生成部24が実現される。
【００２４】
DBサーバ14は、データベース管理システム（DBMS）28と、業務処理用の各種テーブルが格納されたデータベース30を備えている。
データベース管理システム28は、データベース30を管理し、データベース30に格納されたデータの入出力、更新、および所定の演算などを行う。
【００２５】
図２は、データベース30に格納されたテーブルの一例を示すものであり、このテーブルは、日付、店Cd（店コード）、商品Cd（商品コード）、扱いフラグ、在庫数、売上数のデータ項目を備えている。
これらの中、日付、店Cd、商品Cdのデータ項目は、各レコードを特定するためのキー項目であり、扱いフラグ、在庫数、売上数のデータ項目は、各レコードの属性項目である。
また、日付は最上位のキー項目に相当し、店Cd、商品Cdは下位キー項目に相当する（商品コードは最下位のキー項目）。
【００２６】
ロードバランサ16は、クライアント端末20から送信されたリクエストを、各APサーバ12にかかっている負荷に応じて分散する役割を果たす。
【００２７】
クライアント端末20は、ＰＣ等のコンピュータよりなり、OSの他に、Webブラウザプログラムや専用のアプリケーションプログラムがセットアップされている。
【００２８】
以下、図３及び図４のフローチャートに従い、このシステム10における基本的な処理手順を説明する。
まず、APサーバ12のデータ処理部22が起動すると（Ｓ10）、DBサーバ14に対してSQL文を発行し、テーブルのキー項目に係るデータの抽出をリクエストする（Ｓ11）。
この際データ処理部22は、例えば図２のテーブルに格納された各レコードを、日付×店コードで特定されるグループ単位で、かつ日付、店コード、商品コードの値に基づいて昇順に整列させた状態で送信することを指令するSQL文を生成し、DBサーバ14に送信する。
【００２９】
DBサーバ14のデータベース管理システム28から対応のデータが日付×店コードのグループ単位で送信されると、データ処理部22はこれをインデックス生成部24に渡す（Ｓ12）。
インデックス生成部24は、各レコードの日付及び店コードの値を、先行するレコードの日付及び店コードの値と比較する（Ｓ13）。
ここで、先行レコードに係るデータとの重複が認められた場合（Ｓ14のYES）、インデックス生成部24は当該データを削除した後、先行レコードに係るデータを参照する型に置き換える（Ｓ16）。
これに対し、先行レコードに係るデータとの重複が認められない場合（Ｓ14のNO）、インデックス生成部24は当該日付及び店コードをそのまま（実データとして）メモリ26に格納する（Ｓ15）。
【００３０】
図５は、メモリ26に格納されたデータグループのイメージを示すものであり、(a)は2006年３月15日の店コード：600店に係るグループのデータに対応している。
図示の通り、日付（20060315）及び店コード（600）のデータは先頭レコードについてのみ実データとして残されており、他のレコードの日付及び店コードはこれらの値を参照する形式で表現されている。
また、商品コードの「491234567890」、「491234567891」、「491234567892」及び「491234567893」に関しては、何れも先行データとの重複が存在しないため、そのまま実データとして残されている。
【００３１】
一つのグループに関する上記の処理が完了すると、データ処理部22は次のグループ（日付×店コード）に属するレコードの抽出を指令するSQL文をDBサーバ14に発行し（Ｓ17、Ｓ11）、インデックス生成部24によるデータの圧縮及びメモリ26への格納が実行される（Ｓ12〜Ｓ16）。
【００３２】
図５(b)は、2006年３月15日の店コード：601店に係るグループのデータに対応している。
この場合、日付「20060315」及び商品コードの「491234567891」、「491234567893」については重複するデータが先行のデータグループに存在するため（図５(a)）、インデックス生成部24はこれらを削除すると共に、先行グループの実体データを参照する型に置き換える（Ｓ16）。
また、店コード「601」については重複するデータが先行グループに存在しないため、先頭レコードに係る店コードはそのまま実データとして維持されるのに対し（Ｓ15）、次のレコードの店コードはこれを参照する型に置き換えられる（Ｓ16）。
【００３３】
図６は、インデックス生成部24によって生成されたインデックステーブルを示しており、図２のテーブルのキー項目値が、参照型を含む表形式で表現されている。
このように、重複するデータについては一の実データのみを残し、他はこれを参照する型に置き換えることにより、大幅なデータ量の削減効果が得られるため、比較的大規模なテーブルであっても、APサーバ12のメモリ26上にそのキー項目値の存在を示すデータをキャッシュすることが可能となる。
APサーバ12のデータ処理部22は、定期的にＳ11〜Ｓ18の処理を実行することにより、インデックスデータの内容をアップデートする。
【００３４】
ここで、クライアント端末20からの検索リクエストを、ロードバランサ16経由でAPサーバ12が受信すると（図４のＳ19）、データ処理部22はメモリ26上に形成された参照型データを含む表形式のインデックスを参照し、検索条件に該当する全キー項目の値を取得する（Ｓ20）。
例えば、クライアント端末20から日付及び店コードのみを指定した検索リクエストが送信された場合であっても、APサーバ12のメモリ26上には「日付×店」配下の商品コードが全てキャッシュされているため、データ処理部22は当該「日付×店」に係る商品コードを全て取得可能となる。
【００３５】
つぎにデータ処理部22は、日付、店コード、商品コードを特定したSQL文を生成し、DBサーバ14に発行する（Ｓ21）。
これに対しDBサーバ14は、該当のレコードをデータベース30から抽出し、APサーバ12に送信する。
これを受けたデータ処理部22は、所定の形式に加工した上で、クライアント端末20に送信する（Ｓ22）。
【００３６】
このデータ処理システム10にあっては、上記のようにDBサーバ14のデータベース30内に格納されていたテーブルのキー項目の内容が、APサーバ12のメモリ26上にキャッシュされているため、DBサーバ14に検索を指令する際にはキー項目の値の全てを特定し、対象となるレコードをピンポイントで絞り込んだ形のSQL文を発行することが可能となる。
この結果、DBサーバ14においてレンジスキャンが発生することがなくなり、その分検索処理の高速化を実現できる。
【００３７】
また、上記のように先行データと重複するデータについては参照型データに置き換えることにより、インデックステーブルのデータ量を低減できるため、比較的容量の小さいAPサーバ12のメモリ26（一般に２ＧＢ程度）でも効率的に必要データを収容することが可能となる。
【００３８】
また、データをDBサーバ14から取り出すに際し、全レコードに係るキー項目のデータを一度に受け取るのではなく、日付及び店コードの値を指定することにより、グループ単位に分割して受け取り、当該グループについて圧縮処理が完了した時点で次のグループに係るデータを受け取る方式を採用しているため、登録件数の比較的多いテーブルであってもAPサーバ12のメモリ26上にキー項目をキャッシュできるようになる。
【００３９】
ただし、APサーバ12が保持するインデックスデータの構造は上記に限定されるものではない。以下にその具体例を示す。
まず図７は、テーブルのインデックス情報を、APサーバ12のハードディスク27内にフォルダ−ファイル形式で表現した例を示している。
この場合、データ処理部22からテーブルのキー項目データを受け取ったインデックス生成部24は、ハードディスク27の「Cache」フォルダ配下に「Shohin tbl」フォルダを生成し、その中に上位キー項目である日付に対応した「20060315」、「20060316」、「20060317」のフォルダを順に生成し、各フォルダに下位キー項目である店コードに対応した「600」、「601」、「602」のファイル名を有するテキストファイルを格納する。
また、各テキストファイルには、インデックス生成部24によって日付×店コード配下の商品コードが記述されている。
【００４０】
この場合、例えばクライアント端末20から「日付（20060316）×店コード（601）」が検索条件として送信されると、データ処理部22は20060316のフォルダに格納された601ファイルを参照し、「491234567891」及び「491234567893」の商品コードを取得し、上記と同様、商品コードまで特定したSQL文をDBサーバ14に発行する。
【００４１】
つぎに、図８のフローチャートに従い、APサーバ12のメモリ26上に木構造のインデックスデータを生成する例を説明する。
まず、APサーバ12のデータ処理部22が起動すると（Ｓ30）、DBサーバ14に対してSQL文を発行し、テーブルのキー項目に係るデータの抽出をリクエストする（Ｓ31）。
この際データ処理部22は、上記と同様、図２のテーブルに格納された各レコードを日付×店コードで特定されるグループ単位で、かつ日付、店コード、商品コードの値に基づいて昇順に整列させた状態で送信することを指令するSQL文を生成し、DBサーバ14に送信する。
【００４２】
DBサーバ14のデータベース管理システム28から対応のデータが日付×店コードのグループ単位で送信されると、データ処理部22はこれをインデックス生成部24に渡す（Ｓ32）。
インデックス生成部24は、各レコードの日付と店コードに重複する値が存在するか否かをチェックし、重複がある場合には一つの日付及び一つの店コードを残し、他のデータを除去した後、メモリ26に各データを格納する（Ｓ33）。
【００４３】
一つのグループに関してデータの圧縮（重複データの削除及び参照型への置換）及びメモリ26への格納が完了すると、データ処理部22は次のグループ（日付×店コード）に属するレコードの抽出を指令するSQL文をDBサーバ14に発行し（Ｓ34、Ｓ31）、インデックス生成部24によるデータの圧縮及びメモリ26への格納が実行される（Ｓ32、Ｓ33）。
【００４４】
APサーバ12のデータ処理部22及びインデックス生成部24は、対象となるテーブル上の全グループについて処理が完了するまで、Ｓ31〜Ｓ33のステップを繰り返す（Ｓ34）。
図９は、メモリ26に格納されたデータのイメージを示すものであり、(a)は2006年３月15日の店コード：600店に係るグループのデータに対応している。図示の通り、日付（20060315）及び店コード（600）のデータは先頭レコードについてのみ残されており、他のレコードからは削除されている。この時点で、日付及び店コードが削除されたレコードに係る商品コードは、先頭レコードの商品コードと共に配列として残された日付及び店コードに関連付けられている。
また、(g)は2006年３月17日の店コード：601店に係るグループのデータに対応している。
【００４５】
つぎにインデックス生成部24は、各グループの中で日付を同じくするもの同士を一つの日付の下に集約し、それぞれを一つの根（root）の元に結合する（この時点で重複する日付は削除される）。
この結果、図１０に示すように、DBサーバ14のデータベース30内に格納されていたテーブルのキー項目が、APサーバ12のメモリ26上に木構造のインデックスデータとして形成される（Ｓ35）。
【００４６】
図２のテーブルにおいては、各レコード毎に日付及び店コードのデータを備えていたが、図１０に示した木構造のデータの場合、上位キー項目である日付については一切の重複がない形で集約され、下位キー項目である店コードについても同一グループ内では重複が存在しない形で集約されているため、データ容量の大幅な圧縮が達成されている。
この結果、比較的容量の小さいAPサーバ12のメモリ26上に、より効率的にインデックスデータをキャッシュすることが可能となる。
【００４７】
この場合も、クライアント端末20から検索リクエストが送信されると、データ処理部22はメモリ26上に形成された木構造のインデックスデータを参照し、検索条件に該当する全キー項目の値を取得した後、日付、店コード、商品コードを特定したSQL文を生成し、DBサーバ14に発行する。
【００４８】
つぎに、図１１のフローチャートに従い、APサーバ12のメモリ26上に参照型データを含む木構造のインデックスを生成する例を説明する。
まず、Ｓ40〜Ｓ43において、図８のＳ30〜33と同一の処理がAPサーバ12のデータ処理部22及びインデックス生成部24によって実行され、DBサーバ14が管理するテーブルのキー項目値が、日付×店コードのグループ単位でメモリ26に格納される。
図１２は、インデックス生成部24によってメモリ26に格納されたデータグループのイメージを示すものであり、(a)は2006年３月15日の店コード：600店に係るグループのデータに対応している。図示の通り、日付（20060315）及び店コード（600）のデータは先頭レコードについてのみ残されており、他のレコードからは削除されている。この時点で、日付及び店コードが削除されたレコードに係る商品コードは、先頭レコードの商品コードと共に配列として残された日付及び店コードに関連付けられている。
【００４９】
つぎにインデックス生成部24は、各レコードの店コード及び商品コードを先行するレコードの店コード及び商品コードと順次比較していき（Ｓ44）、同一の店コードまたは商品コードが存在するか否かを確認する（Ｓ45）。
図１２(a)の場合には、店コード及び商品コードの双方について重複する先行データが存在しないため、メモリ26上のデータはそのまま維持される（Ｓ46）。
【００５０】
一つのグループに関する上記の処理が完了すると、データ処理部22は次のグループ（日付×店コード）に属するレコードの抽出を指令するSQL文をDBサーバ14に発行し（Ｓ48、Ｓ41）、インデックス生成部24によるデータの圧縮（重複データの削除）及びメモリ26への格納が実行される（Ｓ42、Ｓ43）。
【００５１】
つぎにインデックス生成部24は、各レコードの店コード及び商品コードを先行するレコードの店コード及び商品コードと順次比較していき（Ｓ44）、同一の店コードまたは商品コードが存在するか否かを確認する（Ｓ45）。
図１２(b)は、2006年３月15日の店コード：601店に係るグループのデータに対応しており、この場合には商品コードの「491234567891」及び「491234567893」の双方について重複するデータが先行のデータグループ（図１２(a)）に存在するため、インデックス生成部24はこれらを削除すると共に、先行商品コードの実体データを参照する型に置き換える（Ｓ47）。
これに対し、店コード「601」については重複するデータが先行のデータグループに存在しないため、インデックス生成部24は当該店コードをそのまま維持する（Ｓ46）。
【００５２】
APサーバ12のデータ処理部22及びインデックス生成部24は、対象となるテーブル上の全グループについて処理が完了するまで、Ｓ41〜Ｓ47のステップを繰り返す（Ｓ48）。
因みに、図１２(c)は2006年３月16日の店コード：600店に係るグループのデータに対応しており、店コード及び商品コードの全データについて先行データが存在しているため、インデックス生成部24によって実データが削除されると共に、先行する実データの参照型に置き換えられている。
【００５３】
つぎにインデックス生成部24は、各グループ間で日付を同じくするもの同士を一つの日付の下に集約し、それぞれを一つの根（root）の元に結合する（この時点で重複する日付は削除される）。
この結果、図１３に示すように、DBサーバ14のデータベース30内に格納されていたテーブルのキー項目値が、APサーバ12のメモリ26上に参照型データを含む木構造のインデックスとしてキャッシュされる（Ｓ49）。
図２のテーブルにおいては、各レコード毎に日付及び店コードのデータを備えていたが、図１３に示したデータ構造の場合、上位キー項目である日付については一切の重複がない形で集約され、また下位キー項目である店コード及び商品コードについても参照型を使うことで各グループを通じて一切の重複が存在しない形で表現されているため、データ容量の大幅な圧縮が達成されている。
【００５４】
この場合も、クライアント端末20から検索リクエストが送信されると、データ処理部22はメモリ26上に形成された参照型データを含む木構造のインデックスを参照し、検索条件に該当する全キー項目の値を取得した後、日付、店コード、商品コードを特定したSQL文を生成し、DBサーバ14に発行する。
【００５５】
上記においては、店コード及び商品コードを参照型のデータに変換する処理をデータグループ単位で実行する例を説明したが、変換手順はこれに限定されるものではない。
以下、図１４のフローチャートに従い、参照型データへの他の変換手順を説明する。
まず、APサーバ12のデータ処理部22及びインデックス生成部24によって図８のＳ30〜Ｓ34と同一の処理が実行される結果、図９に示した通り、メモリ26上にはDBサーバ14のキー項目の値が、日付×店コードのグループ単位で、かつ重複する日付及び店コードが削除された形で格納される（Ｓ50〜Ｓ54）。
【００５６】
つぎにインデックス生成部24は、図１５に示すように、Ｓ53において一旦削除した日付及び店コードのデータを、残された実データを参照する型のデータで補充し、表形式のデータをメモリ26上に再編成する（Ｓ55）。
このように、重複データを削除した後に参照型のデータに置き換えることにより、データ量を低減しつつ各レコードのソートが可能な状態となる。
【００５７】
つぎにインデックス生成部24は、図１６に示すように、各レコードを商品コードの値に基づいて昇順にソートし（Ｓ56）、重複する商品コードについては先頭の商品コードのみを実データとしてメモリ26上に残し、それ以外のデータは削除した上で残された実データの参照型に置き換える（Ｓ57）。
【００５８】
つぎにインデックス生成部24は、図１７に示すように、各レコードを店コードの値に基づいて昇順にソートし（Ｓ58）、重複する店コードについては先頭の店コードのみを実データとしてメモリ26上に残し、それ以外のデータは削除した上で残された実データの参照型に置き換える（Ｓ59）。
【００５９】
つぎにインデックス生成部24は、各レコードを日付×店コードに基づいて昇順にソートした後（Ｓ60）、日付×店コードを同じくするグループに分け、各グループ間で日付を同じくするもの同士を一つの日付の下に集約し、それぞれを一つの根（root）の元に結合する（この時点で重複する日付は削除される）。
この結果、図１３に示したのと同様、DBサーバ14のデータベース30内に格納されていたテーブルの全キー項目値が、APサーバ12のメモリ26上に参照型データを含む木構造のインデックスとしてキャッシュされる（Ｓ61）。
【００６０】
つぎに、図１８のフローチャートに従い、参照型への第３の変換手順を説明する。
まず、APサーバ12のデータ処理部22及びインデックス生成部24によって図８のＳ30〜Ｓ34と同一の処理が実行される結果、図９に示した通り、メモリ26上にはDBサーバ14のキー項目の値が、日付×店コードのグループ単位で、かつ重複する日付及び店コードが削除された形で格納される（Ｓ70〜Ｓ74）。
【００６１】
つぎにインデックス生成部24は、各グループ間で日付を同じくするもの同士を一つの日付の下に集約し、それぞれを一つの根（root）の元に結合する（この時点で重複する日付は削除される）。
この結果、図１９に示すように、DBサーバ14のデータベース30内に格納されていたテーブルの全キー項目値が、APサーバ12のメモリ26上に参照型データを含まない木構造のデータとしてキャッシュされる（Ｓ75）。
【００６２】
つぎにインデックス生成部24は、メモリ26上に空のディスティンクト（Distinct）配列32を設定すると共に（Ｓ76）、ここに木構造のデータ中に含まれる商品コードの値を、店コードを同じくするグループ単位で充填し（Ｓ77）、ディスティンクト配列32内の商品コードを昇順にソートした後、重複する商品コードを削除する（Ｓ78）処理を、商品コードの全グループについて繰り返す（Ｓ79）。
この結果、木構造に含まれる商品コードの全類型が重複することなく昇順に整列配置されたディスティンクト・リスト（DistinctList）が、メモリ26上に生成される。
【００６３】
つぎにインデックス生成部24は、木構造のデータ中に含まれる各商品コードの値とディスティンクト・リストの各要素とのマッチングを行い、商品コードの実データを対応のディスティンクト要素を参照する型に変換する（Ｓ80）。
この結果、図２０に示すように、木構造のデータ中に含まれる全ての商品コードが、ディスティンクト・リスト34の参照型データとして表現される。
【００６４】
つぎにインデックス生成部24は、木構造のデータ中に含まれる店コード毎に、先行する店コードの値と比較し（Ｓ81）、重複する先行データが存在しない場合にはそのまま実データとしてメモリ26上に残し（Ｓ82、Ｓ83 ）、重複する先行データが存在する場合には当該店コードを削除して先行データの参照型に置き換える（Ｓ82、Ｓ84）。
以上の結果、APサーバ12のメモリ26上に、参照型のデータを含む木構造のデータが形成される。
【００６５】
なお、図示の便宜上図１８のフローチャートにおいては店コードについてのみＳ81〜Ｓ84の処理を実行するように簡略化して記載したが、最上位のキー項目である日付と最下位のキー項目である商品コードとの間に複数の階層が存在する場合（例えば店コードの上位階層として「地域コード」が設定されている場合）には、各階層毎にＳ81〜Ｓ84の処理が繰り返される。
【００６６】
つぎに、図２１のフローチャートに従い、APサーバ12のメモリ26上に参照型データ及びブーリアン配列を含む木構造のインデックスを生成する例を説明する。
この実施形態においては、APサーバ12のデータ処理部22及びインデックス生成部24によって図１１のＳ40〜Ｓ49の処理が実行され、メモリ26上に参照型データを含む木構造のインデックスが形成されることが前提となる。
ここでインデックス生成部24は、図２２に示すように、上記と同様の手順に従い、商品コードのディスティンクト・リスト34をメモリ26上に生成する（Ｓ90）。
【００６７】
つぎにインデックス生成部24は、ディスティンクト・リスト34の各要素と各商品コードの値を、商品コードの上位キー項目である店コードを共通にする兄弟単位で順番にマッチングさせていき（Ｓ91）、ディスティンクト・リストの要素と一致する場合には、当該商品コードを削除すると共に、ディスティンクト・リスト32と同サイズのブーリアン配列における対応位置にブーリアン型の「true」をセットし、ディスティンクト・リストの値が存在しない場合にはブーリアン型の「false」を対応位置にセットする処理を実行する（Ｓ92）。
【００６８】
図２３は、「20060315」−「600」に係る商品コードの配列36とディスティンクト・リスト34とのマッチングを示しており、この商品コードの配列36にはディスティンクト・リスト32と同じ位置に同じ商品コードが存在しているため、全商品コードが「true」に置き換えられる。
【００６９】
また、図２４は、「20060315」−「601」に係る商品コードの配列とディスティンクト・リスト32とのマッチングを示している。この場合、商品コードの「491234567891（参照型）」及び「491234567893（参照型）」のみがディスティンクト・リスト32中の２番目及び４番目の値と対応しており、ディスティンクト・リスト32中の１番目及び３番目の値である「491234567890」及び「491234567892」が欠落している。このため、インデックス生成部24は商品コードの「491234567891（参照型）」及び「491234567893（参照型）」を削除した後、ブーリアン型の「false」、「true」、「false」、「true」を商品コードを表すデータとしてブーリアン配列にセットする。
【００７０】
図２５は、実データ及び参照型を含む全ての商品コードが削除され、ディスティンクト・リスト34と同サイズのブーリアン配列に置き換えられた木構造のインデックスを示している。
商品コードを参照型で表現した場合、32ビットシステムでは１参照当たり４バイトのメモリを消費することになるが（64ビットシステムでは８バイト）、ブーリアン型の場合には１バイトで特定の商品コードの存在を表現できるため、データ容量の圧縮効果をより高めることが可能となる。
【００７１】
この場合も、クライアント端末20から検索リクエストが送信されると、データ処理部22はメモリ26上に形成された参照型データ及びブーリアン配列を含む木構造のインデックス及びディスティンクト・リスト34を参照し、検索条件に該当する全キー項目の値を取得した後、日付、店コード、商品コードの値を特定したSQL文を生成し、DBサーバ14に発行する。
【００７２】
つぎに、図２６のフローチャートに従い、APサーバ12のメモリ26上に参照型データ及びビット配列を含む木構造のインデックスを生成する例を説明する。
この実施形態においては、APサーバ12のデータ処理部22及びインデックス生成部24によって図１１のＳ40〜Ｓ49及び図２１のＳ90〜Ｓ93の処理が実行され、メモリ26上に参照型及びブーリアン配列を含む木構造のインデックス（図２５）が形成されることが前提となる。
【００７３】
つぎにインデックス生成部24は、上記のブーリアン配列をビット配列に変換する処理を実行する（Ｓ94）。
このビット配列は、図２７に示すように、８桁の二値データ（１または０）を備えており、各桁には下から１、２、４、８、１６、３２、６４、−１２８の定数が割り当てられている。
ここでインデックス生成部24は、ブーリアン配列のある桁に「true」が格納されている場合には、ビット配列の対応の桁に「１」をセットし、「false」が格納されている場合には「０」をセットする。
【００７４】
図２７(a)の場合には、商品コードの存在がブーリアン値のtrue, true, true, trueで表現されているため、インデックス生成部24がビット配列の上４桁に「１」をセットすると共に、下４桁に「該当する値なし」ということで「０」をセットする様子を示している。この「１１１１００００」のビット配列は、上記した各桁の定数を適用することにより、「−１６」という数値を表していることになる。
図２７(b)の場合には、商品コードの存在がブーリアン値のfalse, true, false, trueで表現されているため、インデックス生成部24がビット配列の上４桁に「０１０１」をセットすると共に、下４桁に「該当する値なし」ということで「０」をセットする様子を示している。この「０１０１００００」のビット配列は、上記した各桁の定数を適用することにより、「８０」という数値を表していることになる。
図２７(c)の場合には、商品コードの存在がブーリアン値のtrue, false, true, trueで表現されているため、インデックス生成部24がビット配列の上４桁に「１０１１」をセットすると共に、下４桁に「該当する値なし」ということで「０」をセットする様子を示している。この「１０１１００００」のビット配列は、上記した各桁の定数を適用することにより、「−８０」という数値を表していることになる。
【００７５】
また、図２８(a)の場合には、商品コードの存在がブーリアン値のfalse, true, true, true, true, true, true, trueで表現されているため、インデックス生成部24がビット配列の最初の桁に「０」をセットすると共に、残りの桁に「１」をセットする様子を示している。この「０１１１１１１１」のビット配列は、上記した各桁の定数を適用することにより、「１２７」という数値を表していることになる。
図２８(b)の場合には、商品コードの存在がブーリアン値のtrue, false, false, false, false, false, false, falseで表現されているため、インデックス生成部24がビット配列の最初の桁に「１」をセットすると共に、残りの桁に「０」をセットする様子を示している。この「１０００００００」のビット配列は、上記した各桁の定数を適用することにより、「−１２７」という数値を表していることになる。
【００７６】
上記のように、ブーリアン配列の代わりに８桁のビット配列を用いることにより、−１２７〜１２７までの２５６通りの数値を表現することが可能となり、これは即ち２５６パターンのブーリアン値の組合せを僅か８ビット（１バイト）で表現できることを意味している。
【００７７】
以上の結果、図２９に示すように、図２５のブーリアン配列をビット配列に変換した木構造のインデックスがメモリ26上に形成される（Ｓ95）。
例えば、2006年３月15日の600店における商品コードとして「１１１１００００」のビット配列が関連付けられていた場合、ここから「true, true,true, true, false, false, false, false」のブーリアン配列が導かれ、これをディスティンクト・リスト34と対比することにより、「491234567890」、「491234567891」、「491234567892」、「491234567893」の具体的な商品コードを特定することが可能となる（下４桁のfalseはディスティンクト・リスト34のサイズと合致しないため、無視される）。
【００７８】
この場合も、クライアント端末20から検索リクエストが送信されると、データ処理部22はメモリ26上に形成された参照型及びビット配列を含む木構造のインデックスデータ及びディスティンクト・リスト34を参照し、検索条件に該当する全キー項目の値を取得した後、日付、店コード、商品コードを特定したSQL文を生成し、DBサーバ14に発行する。
【００７９】
ブーリアン配列の場合には、１つの状態（true or false）を表現するのにメモリを１バイト消費し、４つの状態を表現するのであれば４バイトのメモリを消費することになる。
これに対し、８桁のビット配列を用いた場合には、上記の通り１バイトで８つの状態を表示可能となり、メモリの使用量を劇的に抑制可能となる。
【００８０】
なお、ブーリアン配列のサイズが８桁を越えている場合には、別のビット配列がインデックス生成部24によって設けられ、そこにブーリアン値に応じた二値データがセットされる。
図３０はその具体例を示すものであり、ブーリアン配列が12桁である場合には１〜８桁までを第１のビット配列によって表現し、９〜12桁までが第２のビット配列によって表現される。
この場合、データ処理部22は第１のビット配列を参照することによってブーリアン配列の上８桁を特定し、また第２のビット配列を参照することによってブーリアン配列の下４桁を特定する。
その後、データ処理部22はディスティンクト・リスト34を参照することにより、具体的な商品コードを特定する。
【００８１】
上記にあっては、ブーリアン配列を経由してビット配列を生成する例を説明したが、図２２に示した参照型データを含む木構造のインデックスから直接ビット配列を生成することもできる。
すなわち、インデックス生成部24は、ディスティンクト・リスト34の各要素と各商品コードの値を、商品コードの上位キー項目である店コードを共通にする兄弟単位で順番にマッチングさせていき、ディスティンクト・リスト34の要素と一致する場合には、当該商品コードを削除すると共に、メモリ26上に設けた所定桁数のビット配列における対応位置に１をセットし、ディスティンクト・リストの値が存在しない場合には０を対応位置にセットする。
この場合もデータ処理部22は、メモリ26上に形成されたビット配列の各桁の値（１または０）とディスティンクト・リスト34を参照することにより、商品コードの値を取得する。
【００８２】
上記においては、最上位のキー項目である日付と最下位のキー項目である商品コードの間に、店コードのみが存在するテーブルを例に説明したが、最上位のキー項目と最下位のキー項目との間に複数階層のキー項目（例えば「日付−地域コード−店コード−商品コード」）が存在している場合にも適用可能であることはいうまでもない。
【図面の簡単な説明】
【００８３】
【図１】この発明に係るデータ処理システムの全体構成図である。
【図２】DBサーバのデータベースに格納されたテーブルの一例を示す図である。
【図３】参照型データを含む表形式のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図４】このシステムにおける検索処理の手順を示すフローチャートである。
【図５】APサーバのメモリに格納されたグループデータを示すイメージ図である。
【図６】APサーバのメモリにキャッシュされた参照型データを含む表形式のインデックスを示すイメージ図である。
【図７】APサーバのディスクにフォルダ−ファイル形式でキャッシュされたインデックスを示すイメージ図である。
【図８】木構造のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図９】APサーバのメモリに格納されたグループデータを示すイメージ図である。
【図１０】APサーバのメモリにキャッシュされた木構造のインデックスを示すイメージ図である。
【図１１】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図１２】APサーバのメモリに格納されたグループデータを示すイメージ図である。
【図１３】APサーバのメモリにキャッシュされた参照型データを含む木構造のインデックスを示すイメージ図である。
【図１４】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する他の手順を示すフローチャートである。
【図１５】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図１６】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図１７】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図１８】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する他の手順を示すフローチャートである。
【図１９】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２０】APサーバのメモリにキャッシュされた参照型データを含む木構造のインデックスを示すイメージ図である。
【図２１】参照型データ及びブーリアン配列を含む木構造のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図２２】APサーバのメモリに形成された参照型データを含む木構造のインデックスを示すイメージ図である。
【図２３】参照型データ及びブーリアン配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２４】参照型データ及びブーリアン配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２５】APサーバのメモリにキャッシュされた参照型データ及びブーリアン配列を含む木構造のインデックスを示すイメージ図である。
【図２６】参照型データ及びビット配列を含む木構造のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図２７】参照型データ及びビット配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２８】参照型データ及びビット配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２９】APサーバのメモリにキャッシュされた参照型データ及びビット配列を含む木構造のインデックスを示すイメージ図である。
【図３０】参照型データ及びビット配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【符号の説明】
【００８４】
10 データ処理システム
12 APサーバ
14 DBサーバ
16 ロードバランサ
18 イントラネット
20 クライアント端末
22 データ処理部
24 データ圧縮部
26 メモリ
28 データベース管理システム
30 データベース
32 ディスティンクト配列
34 ディスティンクト・リスト
36 商品コードの配列
【技術分野】
【０００１】
この発明はデータ処理システムに係り、特に、APサーバ内にDBサーバのデータベースに含まれるレコードのキー項目の値をキャッシュしておき、DBサーバにSQL文を発行するに際しては全キー項目の値を特定することにより、検索処理等の高速化を実現する技術に関する。
【背景技術】
【０００２】
クライアントサーバ型システムの進展に伴い、より大規模な情報処理の要求に応えるために、データの表示をするクライアントの他にデータの加工を行うAPサーバ及びデータの格納をするDBサーバを備えた、いわゆる三層構造のクライアントサーバシステムが普及してきている。
また、処理速度の向上を図るため、複数のAPサーバを並列配置させることで負荷を分散させることも行われている。
【特許文献１】特開２００５−１６５６１０
【発明の開示】
【発明が解決しようとする課題】
【０００３】
APサーバは廉価なPCサーバで構成することができるため、設置台数を増加させることで処理速度を向上させることは比較的容易であるが、DBサーバについてはデータの同期を維持する必要性があるため、APサーバのように簡単に分散処理に移行することはできない。
もちろん、データベースシステムのベンダ各社は、様々な技術を駆使してソフトウェア及びハードウェアの両面からDBサーバ自体の高速化を図ってきており、その結果一定の成果は上がっているが、その分システムの価格が上昇することは否めない。
また、今後ともクライアントサーバ型システムに担わされるデータベースの規模が増大を続ける限り、いずれはディスクI/O（データの読み書き）速度が壁となり、DBサーバの性能アップでは対応できない時期が来るものと予想される。
【０００４】
ところで、DBサーバにおける検索処理に時間を要するのは、一般にレンジスキャン（範囲走査）と呼ばれる処理を実行する場合である。
すなわち、図２に示すテーブルを例に説明すると、APサーバがSQL文を発行する際に日付、店Cd（店コード）、商品Cd（商品コード）のキー項目の値を全て指定してやれば、目的のレコードが一意に決まるためDBサーバは即座に必要なデータにアクセス可能となる。
これに対し、SQL文中で日付、店Cdのみを指定してデータの抽出を命令した場合、DBサーバは指定された日付、商品Cdに係る全てのレコードを先頭レコードから走査して該当のレコードを抽出する必要が生じ、その分時間を要することとなる。
【０００５】
データベースの検索速度を向上させるために、通常は各テーブル毎にインデックス（索引情報）が生成され、これを参照することでDBサーバは検索処理の高速化をある程度達成することができる。
しかしながら、キー項目の数が多くなり、その組合せパターンが複雑化する場合には一次インデックス、二次インデックス…というように予想される検索パターンに対応したインデックスファイルを多数準備する必要が生じ、かえってディスクI/Oが増加する結果となる。
【０００６】
また、キー項目を細分化し、例えば商品Cdの上位キーとして「商品分類Cd」を設定しておき、検索条件を指定する際に商品分類コードまで特定するように促すことで、DBサーバ側でのレンジスキャンの幅を抑制することも行われているが、これはレンジスキャン自体を一掃するものではないし、レコード長の増大を招くという欠点もある。
【０００７】
この発明は、従来のデータ処理システムが抱えていた上記の問題を解決するために案出されたものであり、DBサーバ自体の性能アップに依存するのではなく、また過度なインデックス情報の生成や上位キー項目の追加を行うことなく、APサーバ側の処理工程に改良を加えることによってDBサーバにおけるレンジスキャンの頻度を低減し、もって検索処理の高速化を実現することを目的としている。
【課題を解決するための手段】
【０００８】
上記の目的を達成するため、請求項１に記載したデータ処理システムは、DBサーバとAPサーバを備えたデータ処理システムであって、上記DBサーバが、データベース管理システムと、テーブルを格納したデータベースを備え、上記APサーバが、上記DBサーバにSQL文を発行し、上記テーブルのキー項目に係るデータの読み出しを指令するデータ読み出し手段と、DBサーバから送信されたキー項目に係るデータを圧縮し、上記APサーバの記憶手段に上記テーブルのインデックスとして格納するインデックス生成手段と、クライアント端末から上位キー項目を検索条件として指定した検索リクエストが送信された場合に、上記APサーバのインデックスを参照し、上記検索条件に包含されるキー項目の値を取得するキー項目値取得手段と、各キー項目の値を特定したSQL文を生成し、上記DBサーバに発行する手段とを備えたことを特徴としている。
【０００９】
請求項２に記載したデータ処理システムは、請求項１のシステムであって、さらに上記のデータ読み出し手段が、上記SQL文において一または複数のキー項目の値を指定することにより、上記DBサーバから上記テーブルをグループに分割して読み出す処理を実行し、上記のインデックス生成手段が、圧縮処理をグループ単位で実行することを特徴としている。
【００１０】
請求項３に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信されたデータ中において値が相互に重複するものが存在する場合に、一つの値のみを実データとしてメモリ上に残し、他の値については上記実データを参照する型に変換する処理を実行し、参照型データを含む表形式のインデックスを生成することを特徴としている。
【００１１】
請求項４に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、少なくとも最上位のキー項目毎に対応のフォルダをAPサーバのディスク上に生成する第１の処理と、各最上位のキー項目に包含される１または複数の中位キー項目に対応したファイルを生成し、対応のフォルダに格納する第２の処理と、各中位のキー項目に包含される１または複数の下位キー項目の値を対応のファイルに記述する第３の処理を実行することを特徴としている。
【００１２】
請求項５に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、残された最上位のキー項目を一つの根の元に結合させることにより、木構造のインデックスをAPサーバのメモリ上に生成する第２の処理を実行することを特徴としている。
【００１３】
請求項６に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、値が相互に重複する下位のキー項目については、一の値のみを実データとしてAPサーバのメモリ上に残し、他の値については上記実データを参照する型に変換する第２の処理と、残された最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する第３の処理を実行することを特徴としている。
【００１４】
請求項７に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各レコードの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、各レコードの下位のキー項目の値と先行レコードの同キー項目の値とを順次比較し、先行レコードの値と重複する値を削除すると共に、先行レコードの値を参照する型に変換する第２の処理と、残された上位キー項目同士を一つの根の元に結合させ、参照型を含む木構造のデータを生成する第３の処理を実行することを特徴としている。
【００１５】
請求項８に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第１の処理と、各レコードを下位のキー項目の値に基づいて所定の順序で整列させ、下位のキー項目の値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第２の処理と、各レコードを少なくとも最上位のキー項目の値に基づいて所定の順序で整列させる第３の処理と、残された最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のデータを生成する第４の処理を実行することを特徴としている。
【００１６】
請求項９に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、残された最上位のキー項目を一つの根の元に結合させて木構造のデータを生成する第２の処理と、上記木構造のデータに含まれる最下位のキー項目の類型を抽出し、これらを要素として充填させたディスティンクト・リストをメモリ上に生成する第３の処理と、上記ディスティンクト・リストに含まれる各要素と上記木構造のデータに含まれる最下位のキー項目の各値とをマッチングし、最下位のキー項目の各値をディスティンクト・リスト中の対応の要素を参照する型に変換する第４の処理を実行することを特徴としている。
【００１７】
請求項１０に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第４の処理を実行し、上記キー項目値取得手段が、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴としている。
【００１８】
請求項１１に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第４の処理と、上記のブーリアン配列をビット配列に変換する第５の処理を実行し、上記キー項目値取得手段が、各ビット配列をブーリアン配列に変換し、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴としている。
【００１９】
請求項１２に記載したデータ処理システムは、請求項１のシステムであって、さらに上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたビット配列における対応位置に１をセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ビット配列の対応位置に０をセットする第４の処理を実行し、上記キー項目値取得手段が、各ビット配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴としている。
【発明の効果】
【００２０】
請求項１、３〜１２に記載したデータ処理システムにあっては、DBサーバ内に格納されているテーブルのキー項目の内容が、APサーバのメモリやディスク上にキャッシュされるため、DBサーバに検索を指令する際にはキー項目の値の全てを特定し、対象となるレコードをピンポイントで絞り込んだ形のSQL文を発行することが可能となる。この結果、DBサーバにおいてレンジスキャンが発生することがなくなり、その分検索処理の高速化を実現できる。
【００２１】
請求項２に記載したデータ処理システムの場合、APサーバがデータをDBサーバから取り出すに際し、全レコードに係るキー項目のデータ全体を一度に受け取るのではなく、特定のキー項目の値を指定することにより、グループ単位に分割して受け取り、当該グループについて圧縮処理が完了した時点で次のグループに係るレコードを受け取る方式を採用しているため、比較的大きなテーブルであってもAPサーバのメモリ上にキー項目をキャッシュできるようになる。
【発明を実施するための最良の形態】
【００２２】
図１は、この発明に係るデータ処理システム10の全体構成図であり、このシステム10は、複数のAPサーバ12と、DBサーバ14と、ロードバランサ（負荷分散装置）16とを備えている。
ロードバランサ16と各APサーバ12間、及び各APサーバ12とDBサーバ14間はネットワークによって接続されている。
また、各APサーバ12に対しては、イントラネット18やインターネット等のネットワーク及びロードバランサ16を介して多数のクライアント端末20が接続されている。
【００２３】
各APサーバ12は、データ処理部22と、インデックス生成部24と、メモリ26と、ハードディスク（HDD）27を備えている。
各APサーバ12のハードディスク27には、OS及びこのシステム専用のアプリケーションプログラムがセットアップされており、APサーバ12のCPUがこれらのプログラムに従って動作することにより、上記のデータ処理部22及びインデックス生成部24が実現される。
【００２４】
DBサーバ14は、データベース管理システム（DBMS）28と、業務処理用の各種テーブルが格納されたデータベース30を備えている。
データベース管理システム28は、データベース30を管理し、データベース30に格納されたデータの入出力、更新、および所定の演算などを行う。
【００２５】
図２は、データベース30に格納されたテーブルの一例を示すものであり、このテーブルは、日付、店Cd（店コード）、商品Cd（商品コード）、扱いフラグ、在庫数、売上数のデータ項目を備えている。
これらの中、日付、店Cd、商品Cdのデータ項目は、各レコードを特定するためのキー項目であり、扱いフラグ、在庫数、売上数のデータ項目は、各レコードの属性項目である。
また、日付は最上位のキー項目に相当し、店Cd、商品Cdは下位キー項目に相当する（商品コードは最下位のキー項目）。
【００２６】
ロードバランサ16は、クライアント端末20から送信されたリクエストを、各APサーバ12にかかっている負荷に応じて分散する役割を果たす。
【００２７】
クライアント端末20は、ＰＣ等のコンピュータよりなり、OSの他に、Webブラウザプログラムや専用のアプリケーションプログラムがセットアップされている。
【００２８】
以下、図３及び図４のフローチャートに従い、このシステム10における基本的な処理手順を説明する。
まず、APサーバ12のデータ処理部22が起動すると（Ｓ10）、DBサーバ14に対してSQL文を発行し、テーブルのキー項目に係るデータの抽出をリクエストする（Ｓ11）。
この際データ処理部22は、例えば図２のテーブルに格納された各レコードを、日付×店コードで特定されるグループ単位で、かつ日付、店コード、商品コードの値に基づいて昇順に整列させた状態で送信することを指令するSQL文を生成し、DBサーバ14に送信する。
【００２９】
DBサーバ14のデータベース管理システム28から対応のデータが日付×店コードのグループ単位で送信されると、データ処理部22はこれをインデックス生成部24に渡す（Ｓ12）。
インデックス生成部24は、各レコードの日付及び店コードの値を、先行するレコードの日付及び店コードの値と比較する（Ｓ13）。
ここで、先行レコードに係るデータとの重複が認められた場合（Ｓ14のYES）、インデックス生成部24は当該データを削除した後、先行レコードに係るデータを参照する型に置き換える（Ｓ16）。
これに対し、先行レコードに係るデータとの重複が認められない場合（Ｓ14のNO）、インデックス生成部24は当該日付及び店コードをそのまま（実データとして）メモリ26に格納する（Ｓ15）。
【００３０】
図５は、メモリ26に格納されたデータグループのイメージを示すものであり、(a)は2006年３月15日の店コード：600店に係るグループのデータに対応している。
図示の通り、日付（20060315）及び店コード（600）のデータは先頭レコードについてのみ実データとして残されており、他のレコードの日付及び店コードはこれらの値を参照する形式で表現されている。
また、商品コードの「491234567890」、「491234567891」、「491234567892」及び「491234567893」に関しては、何れも先行データとの重複が存在しないため、そのまま実データとして残されている。
【００３１】
一つのグループに関する上記の処理が完了すると、データ処理部22は次のグループ（日付×店コード）に属するレコードの抽出を指令するSQL文をDBサーバ14に発行し（Ｓ17、Ｓ11）、インデックス生成部24によるデータの圧縮及びメモリ26への格納が実行される（Ｓ12〜Ｓ16）。
【００３２】
図５(b)は、2006年３月15日の店コード：601店に係るグループのデータに対応している。
この場合、日付「20060315」及び商品コードの「491234567891」、「491234567893」については重複するデータが先行のデータグループに存在するため（図５(a)）、インデックス生成部24はこれらを削除すると共に、先行グループの実体データを参照する型に置き換える（Ｓ16）。
また、店コード「601」については重複するデータが先行グループに存在しないため、先頭レコードに係る店コードはそのまま実データとして維持されるのに対し（Ｓ15）、次のレコードの店コードはこれを参照する型に置き換えられる（Ｓ16）。
【００３３】
図６は、インデックス生成部24によって生成されたインデックステーブルを示しており、図２のテーブルのキー項目値が、参照型を含む表形式で表現されている。
このように、重複するデータについては一の実データのみを残し、他はこれを参照する型に置き換えることにより、大幅なデータ量の削減効果が得られるため、比較的大規模なテーブルであっても、APサーバ12のメモリ26上にそのキー項目値の存在を示すデータをキャッシュすることが可能となる。
APサーバ12のデータ処理部22は、定期的にＳ11〜Ｓ18の処理を実行することにより、インデックスデータの内容をアップデートする。
【００３４】
ここで、クライアント端末20からの検索リクエストを、ロードバランサ16経由でAPサーバ12が受信すると（図４のＳ19）、データ処理部22はメモリ26上に形成された参照型データを含む表形式のインデックスを参照し、検索条件に該当する全キー項目の値を取得する（Ｓ20）。
例えば、クライアント端末20から日付及び店コードのみを指定した検索リクエストが送信された場合であっても、APサーバ12のメモリ26上には「日付×店」配下の商品コードが全てキャッシュされているため、データ処理部22は当該「日付×店」に係る商品コードを全て取得可能となる。
【００３５】
つぎにデータ処理部22は、日付、店コード、商品コードを特定したSQL文を生成し、DBサーバ14に発行する（Ｓ21）。
これに対しDBサーバ14は、該当のレコードをデータベース30から抽出し、APサーバ12に送信する。
これを受けたデータ処理部22は、所定の形式に加工した上で、クライアント端末20に送信する（Ｓ22）。
【００３６】
このデータ処理システム10にあっては、上記のようにDBサーバ14のデータベース30内に格納されていたテーブルのキー項目の内容が、APサーバ12のメモリ26上にキャッシュされているため、DBサーバ14に検索を指令する際にはキー項目の値の全てを特定し、対象となるレコードをピンポイントで絞り込んだ形のSQL文を発行することが可能となる。
この結果、DBサーバ14においてレンジスキャンが発生することがなくなり、その分検索処理の高速化を実現できる。
【００３７】
また、上記のように先行データと重複するデータについては参照型データに置き換えることにより、インデックステーブルのデータ量を低減できるため、比較的容量の小さいAPサーバ12のメモリ26（一般に２ＧＢ程度）でも効率的に必要データを収容することが可能となる。
【００３８】
また、データをDBサーバ14から取り出すに際し、全レコードに係るキー項目のデータを一度に受け取るのではなく、日付及び店コードの値を指定することにより、グループ単位に分割して受け取り、当該グループについて圧縮処理が完了した時点で次のグループに係るデータを受け取る方式を採用しているため、登録件数の比較的多いテーブルであってもAPサーバ12のメモリ26上にキー項目をキャッシュできるようになる。
【００３９】
ただし、APサーバ12が保持するインデックスデータの構造は上記に限定されるものではない。以下にその具体例を示す。
まず図７は、テーブルのインデックス情報を、APサーバ12のハードディスク27内にフォルダ−ファイル形式で表現した例を示している。
この場合、データ処理部22からテーブルのキー項目データを受け取ったインデックス生成部24は、ハードディスク27の「Cache」フォルダ配下に「Shohin tbl」フォルダを生成し、その中に上位キー項目である日付に対応した「20060315」、「20060316」、「20060317」のフォルダを順に生成し、各フォルダに下位キー項目である店コードに対応した「600」、「601」、「602」のファイル名を有するテキストファイルを格納する。
また、各テキストファイルには、インデックス生成部24によって日付×店コード配下の商品コードが記述されている。
【００４０】
この場合、例えばクライアント端末20から「日付（20060316）×店コード（601）」が検索条件として送信されると、データ処理部22は20060316のフォルダに格納された601ファイルを参照し、「491234567891」及び「491234567893」の商品コードを取得し、上記と同様、商品コードまで特定したSQL文をDBサーバ14に発行する。
【００４１】
つぎに、図８のフローチャートに従い、APサーバ12のメモリ26上に木構造のインデックスデータを生成する例を説明する。
まず、APサーバ12のデータ処理部22が起動すると（Ｓ30）、DBサーバ14に対してSQL文を発行し、テーブルのキー項目に係るデータの抽出をリクエストする（Ｓ31）。
この際データ処理部22は、上記と同様、図２のテーブルに格納された各レコードを日付×店コードで特定されるグループ単位で、かつ日付、店コード、商品コードの値に基づいて昇順に整列させた状態で送信することを指令するSQL文を生成し、DBサーバ14に送信する。
【００４２】
DBサーバ14のデータベース管理システム28から対応のデータが日付×店コードのグループ単位で送信されると、データ処理部22はこれをインデックス生成部24に渡す（Ｓ32）。
インデックス生成部24は、各レコードの日付と店コードに重複する値が存在するか否かをチェックし、重複がある場合には一つの日付及び一つの店コードを残し、他のデータを除去した後、メモリ26に各データを格納する（Ｓ33）。
【００４３】
一つのグループに関してデータの圧縮（重複データの削除及び参照型への置換）及びメモリ26への格納が完了すると、データ処理部22は次のグループ（日付×店コード）に属するレコードの抽出を指令するSQL文をDBサーバ14に発行し（Ｓ34、Ｓ31）、インデックス生成部24によるデータの圧縮及びメモリ26への格納が実行される（Ｓ32、Ｓ33）。
【００４４】
APサーバ12のデータ処理部22及びインデックス生成部24は、対象となるテーブル上の全グループについて処理が完了するまで、Ｓ31〜Ｓ33のステップを繰り返す（Ｓ34）。
図９は、メモリ26に格納されたデータのイメージを示すものであり、(a)は2006年３月15日の店コード：600店に係るグループのデータに対応している。図示の通り、日付（20060315）及び店コード（600）のデータは先頭レコードについてのみ残されており、他のレコードからは削除されている。この時点で、日付及び店コードが削除されたレコードに係る商品コードは、先頭レコードの商品コードと共に配列として残された日付及び店コードに関連付けられている。
また、(g)は2006年３月17日の店コード：601店に係るグループのデータに対応している。
【００４５】
つぎにインデックス生成部24は、各グループの中で日付を同じくするもの同士を一つの日付の下に集約し、それぞれを一つの根（root）の元に結合する（この時点で重複する日付は削除される）。
この結果、図１０に示すように、DBサーバ14のデータベース30内に格納されていたテーブルのキー項目が、APサーバ12のメモリ26上に木構造のインデックスデータとして形成される（Ｓ35）。
【００４６】
図２のテーブルにおいては、各レコード毎に日付及び店コードのデータを備えていたが、図１０に示した木構造のデータの場合、上位キー項目である日付については一切の重複がない形で集約され、下位キー項目である店コードについても同一グループ内では重複が存在しない形で集約されているため、データ容量の大幅な圧縮が達成されている。
この結果、比較的容量の小さいAPサーバ12のメモリ26上に、より効率的にインデックスデータをキャッシュすることが可能となる。
【００４７】
この場合も、クライアント端末20から検索リクエストが送信されると、データ処理部22はメモリ26上に形成された木構造のインデックスデータを参照し、検索条件に該当する全キー項目の値を取得した後、日付、店コード、商品コードを特定したSQL文を生成し、DBサーバ14に発行する。
【００４８】
つぎに、図１１のフローチャートに従い、APサーバ12のメモリ26上に参照型データを含む木構造のインデックスを生成する例を説明する。
まず、Ｓ40〜Ｓ43において、図８のＳ30〜33と同一の処理がAPサーバ12のデータ処理部22及びインデックス生成部24によって実行され、DBサーバ14が管理するテーブルのキー項目値が、日付×店コードのグループ単位でメモリ26に格納される。
図１２は、インデックス生成部24によってメモリ26に格納されたデータグループのイメージを示すものであり、(a)は2006年３月15日の店コード：600店に係るグループのデータに対応している。図示の通り、日付（20060315）及び店コード（600）のデータは先頭レコードについてのみ残されており、他のレコードからは削除されている。この時点で、日付及び店コードが削除されたレコードに係る商品コードは、先頭レコードの商品コードと共に配列として残された日付及び店コードに関連付けられている。
【００４９】
つぎにインデックス生成部24は、各レコードの店コード及び商品コードを先行するレコードの店コード及び商品コードと順次比較していき（Ｓ44）、同一の店コードまたは商品コードが存在するか否かを確認する（Ｓ45）。
図１２(a)の場合には、店コード及び商品コードの双方について重複する先行データが存在しないため、メモリ26上のデータはそのまま維持される（Ｓ46）。
【００５０】
一つのグループに関する上記の処理が完了すると、データ処理部22は次のグループ（日付×店コード）に属するレコードの抽出を指令するSQL文をDBサーバ14に発行し（Ｓ48、Ｓ41）、インデックス生成部24によるデータの圧縮（重複データの削除）及びメモリ26への格納が実行される（Ｓ42、Ｓ43）。
【００５１】
つぎにインデックス生成部24は、各レコードの店コード及び商品コードを先行するレコードの店コード及び商品コードと順次比較していき（Ｓ44）、同一の店コードまたは商品コードが存在するか否かを確認する（Ｓ45）。
図１２(b)は、2006年３月15日の店コード：601店に係るグループのデータに対応しており、この場合には商品コードの「491234567891」及び「491234567893」の双方について重複するデータが先行のデータグループ（図１２(a)）に存在するため、インデックス生成部24はこれらを削除すると共に、先行商品コードの実体データを参照する型に置き換える（Ｓ47）。
これに対し、店コード「601」については重複するデータが先行のデータグループに存在しないため、インデックス生成部24は当該店コードをそのまま維持する（Ｓ46）。
【００５２】
APサーバ12のデータ処理部22及びインデックス生成部24は、対象となるテーブル上の全グループについて処理が完了するまで、Ｓ41〜Ｓ47のステップを繰り返す（Ｓ48）。
因みに、図１２(c)は2006年３月16日の店コード：600店に係るグループのデータに対応しており、店コード及び商品コードの全データについて先行データが存在しているため、インデックス生成部24によって実データが削除されると共に、先行する実データの参照型に置き換えられている。
【００５３】
つぎにインデックス生成部24は、各グループ間で日付を同じくするもの同士を一つの日付の下に集約し、それぞれを一つの根（root）の元に結合する（この時点で重複する日付は削除される）。
この結果、図１３に示すように、DBサーバ14のデータベース30内に格納されていたテーブルのキー項目値が、APサーバ12のメモリ26上に参照型データを含む木構造のインデックスとしてキャッシュされる（Ｓ49）。
図２のテーブルにおいては、各レコード毎に日付及び店コードのデータを備えていたが、図１３に示したデータ構造の場合、上位キー項目である日付については一切の重複がない形で集約され、また下位キー項目である店コード及び商品コードについても参照型を使うことで各グループを通じて一切の重複が存在しない形で表現されているため、データ容量の大幅な圧縮が達成されている。
【００５４】
この場合も、クライアント端末20から検索リクエストが送信されると、データ処理部22はメモリ26上に形成された参照型データを含む木構造のインデックスを参照し、検索条件に該当する全キー項目の値を取得した後、日付、店コード、商品コードを特定したSQL文を生成し、DBサーバ14に発行する。
【００５５】
上記においては、店コード及び商品コードを参照型のデータに変換する処理をデータグループ単位で実行する例を説明したが、変換手順はこれに限定されるものではない。
以下、図１４のフローチャートに従い、参照型データへの他の変換手順を説明する。
まず、APサーバ12のデータ処理部22及びインデックス生成部24によって図８のＳ30〜Ｓ34と同一の処理が実行される結果、図９に示した通り、メモリ26上にはDBサーバ14のキー項目の値が、日付×店コードのグループ単位で、かつ重複する日付及び店コードが削除された形で格納される（Ｓ50〜Ｓ54）。
【００５６】
つぎにインデックス生成部24は、図１５に示すように、Ｓ53において一旦削除した日付及び店コードのデータを、残された実データを参照する型のデータで補充し、表形式のデータをメモリ26上に再編成する（Ｓ55）。
このように、重複データを削除した後に参照型のデータに置き換えることにより、データ量を低減しつつ各レコードのソートが可能な状態となる。
【００５７】
つぎにインデックス生成部24は、図１６に示すように、各レコードを商品コードの値に基づいて昇順にソートし（Ｓ56）、重複する商品コードについては先頭の商品コードのみを実データとしてメモリ26上に残し、それ以外のデータは削除した上で残された実データの参照型に置き換える（Ｓ57）。
【００５８】
つぎにインデックス生成部24は、図１７に示すように、各レコードを店コードの値に基づいて昇順にソートし（Ｓ58）、重複する店コードについては先頭の店コードのみを実データとしてメモリ26上に残し、それ以外のデータは削除した上で残された実データの参照型に置き換える（Ｓ59）。
【００５９】
つぎにインデックス生成部24は、各レコードを日付×店コードに基づいて昇順にソートした後（Ｓ60）、日付×店コードを同じくするグループに分け、各グループ間で日付を同じくするもの同士を一つの日付の下に集約し、それぞれを一つの根（root）の元に結合する（この時点で重複する日付は削除される）。
この結果、図１３に示したのと同様、DBサーバ14のデータベース30内に格納されていたテーブルの全キー項目値が、APサーバ12のメモリ26上に参照型データを含む木構造のインデックスとしてキャッシュされる（Ｓ61）。
【００６０】
つぎに、図１８のフローチャートに従い、参照型への第３の変換手順を説明する。
まず、APサーバ12のデータ処理部22及びインデックス生成部24によって図８のＳ30〜Ｓ34と同一の処理が実行される結果、図９に示した通り、メモリ26上にはDBサーバ14のキー項目の値が、日付×店コードのグループ単位で、かつ重複する日付及び店コードが削除された形で格納される（Ｓ70〜Ｓ74）。
【００６１】
つぎにインデックス生成部24は、各グループ間で日付を同じくするもの同士を一つの日付の下に集約し、それぞれを一つの根（root）の元に結合する（この時点で重複する日付は削除される）。
この結果、図１９に示すように、DBサーバ14のデータベース30内に格納されていたテーブルの全キー項目値が、APサーバ12のメモリ26上に参照型データを含まない木構造のデータとしてキャッシュされる（Ｓ75）。
【００６２】
つぎにインデックス生成部24は、メモリ26上に空のディスティンクト（Distinct）配列32を設定すると共に（Ｓ76）、ここに木構造のデータ中に含まれる商品コードの値を、店コードを同じくするグループ単位で充填し（Ｓ77）、ディスティンクト配列32内の商品コードを昇順にソートした後、重複する商品コードを削除する（Ｓ78）処理を、商品コードの全グループについて繰り返す（Ｓ79）。
この結果、木構造に含まれる商品コードの全類型が重複することなく昇順に整列配置されたディスティンクト・リスト（DistinctList）が、メモリ26上に生成される。
【００６３】
つぎにインデックス生成部24は、木構造のデータ中に含まれる各商品コードの値とディスティンクト・リストの各要素とのマッチングを行い、商品コードの実データを対応のディスティンクト要素を参照する型に変換する（Ｓ80）。
この結果、図２０に示すように、木構造のデータ中に含まれる全ての商品コードが、ディスティンクト・リスト34の参照型データとして表現される。
【００６４】
つぎにインデックス生成部24は、木構造のデータ中に含まれる店コード毎に、先行する店コードの値と比較し（Ｓ81）、重複する先行データが存在しない場合にはそのまま実データとしてメモリ26上に残し（Ｓ82、Ｓ83 ）、重複する先行データが存在する場合には当該店コードを削除して先行データの参照型に置き換える（Ｓ82、Ｓ84）。
以上の結果、APサーバ12のメモリ26上に、参照型のデータを含む木構造のデータが形成される。
【００６５】
なお、図示の便宜上図１８のフローチャートにおいては店コードについてのみＳ81〜Ｓ84の処理を実行するように簡略化して記載したが、最上位のキー項目である日付と最下位のキー項目である商品コードとの間に複数の階層が存在する場合（例えば店コードの上位階層として「地域コード」が設定されている場合）には、各階層毎にＳ81〜Ｓ84の処理が繰り返される。
【００６６】
つぎに、図２１のフローチャートに従い、APサーバ12のメモリ26上に参照型データ及びブーリアン配列を含む木構造のインデックスを生成する例を説明する。
この実施形態においては、APサーバ12のデータ処理部22及びインデックス生成部24によって図１１のＳ40〜Ｓ49の処理が実行され、メモリ26上に参照型データを含む木構造のインデックスが形成されることが前提となる。
ここでインデックス生成部24は、図２２に示すように、上記と同様の手順に従い、商品コードのディスティンクト・リスト34をメモリ26上に生成する（Ｓ90）。
【００６７】
つぎにインデックス生成部24は、ディスティンクト・リスト34の各要素と各商品コードの値を、商品コードの上位キー項目である店コードを共通にする兄弟単位で順番にマッチングさせていき（Ｓ91）、ディスティンクト・リストの要素と一致する場合には、当該商品コードを削除すると共に、ディスティンクト・リスト32と同サイズのブーリアン配列における対応位置にブーリアン型の「true」をセットし、ディスティンクト・リストの値が存在しない場合にはブーリアン型の「false」を対応位置にセットする処理を実行する（Ｓ92）。
【００６８】
図２３は、「20060315」−「600」に係る商品コードの配列36とディスティンクト・リスト34とのマッチングを示しており、この商品コードの配列36にはディスティンクト・リスト32と同じ位置に同じ商品コードが存在しているため、全商品コードが「true」に置き換えられる。
【００６９】
また、図２４は、「20060315」−「601」に係る商品コードの配列とディスティンクト・リスト32とのマッチングを示している。この場合、商品コードの「491234567891（参照型）」及び「491234567893（参照型）」のみがディスティンクト・リスト32中の２番目及び４番目の値と対応しており、ディスティンクト・リスト32中の１番目及び３番目の値である「491234567890」及び「491234567892」が欠落している。このため、インデックス生成部24は商品コードの「491234567891（参照型）」及び「491234567893（参照型）」を削除した後、ブーリアン型の「false」、「true」、「false」、「true」を商品コードを表すデータとしてブーリアン配列にセットする。
【００７０】
図２５は、実データ及び参照型を含む全ての商品コードが削除され、ディスティンクト・リスト34と同サイズのブーリアン配列に置き換えられた木構造のインデックスを示している。
商品コードを参照型で表現した場合、32ビットシステムでは１参照当たり４バイトのメモリを消費することになるが（64ビットシステムでは８バイト）、ブーリアン型の場合には１バイトで特定の商品コードの存在を表現できるため、データ容量の圧縮効果をより高めることが可能となる。
【００７１】
この場合も、クライアント端末20から検索リクエストが送信されると、データ処理部22はメモリ26上に形成された参照型データ及びブーリアン配列を含む木構造のインデックス及びディスティンクト・リスト34を参照し、検索条件に該当する全キー項目の値を取得した後、日付、店コード、商品コードの値を特定したSQL文を生成し、DBサーバ14に発行する。
【００７２】
つぎに、図２６のフローチャートに従い、APサーバ12のメモリ26上に参照型データ及びビット配列を含む木構造のインデックスを生成する例を説明する。
この実施形態においては、APサーバ12のデータ処理部22及びインデックス生成部24によって図１１のＳ40〜Ｓ49及び図２１のＳ90〜Ｓ93の処理が実行され、メモリ26上に参照型及びブーリアン配列を含む木構造のインデックス（図２５）が形成されることが前提となる。
【００７３】
つぎにインデックス生成部24は、上記のブーリアン配列をビット配列に変換する処理を実行する（Ｓ94）。
このビット配列は、図２７に示すように、８桁の二値データ（１または０）を備えており、各桁には下から１、２、４、８、１６、３２、６４、−１２８の定数が割り当てられている。
ここでインデックス生成部24は、ブーリアン配列のある桁に「true」が格納されている場合には、ビット配列の対応の桁に「１」をセットし、「false」が格納されている場合には「０」をセットする。
【００７４】
図２７(a)の場合には、商品コードの存在がブーリアン値のtrue, true, true, trueで表現されているため、インデックス生成部24がビット配列の上４桁に「１」をセットすると共に、下４桁に「該当する値なし」ということで「０」をセットする様子を示している。この「１１１１００００」のビット配列は、上記した各桁の定数を適用することにより、「−１６」という数値を表していることになる。
図２７(b)の場合には、商品コードの存在がブーリアン値のfalse, true, false, trueで表現されているため、インデックス生成部24がビット配列の上４桁に「０１０１」をセットすると共に、下４桁に「該当する値なし」ということで「０」をセットする様子を示している。この「０１０１００００」のビット配列は、上記した各桁の定数を適用することにより、「８０」という数値を表していることになる。
図２７(c)の場合には、商品コードの存在がブーリアン値のtrue, false, true, trueで表現されているため、インデックス生成部24がビット配列の上４桁に「１０１１」をセットすると共に、下４桁に「該当する値なし」ということで「０」をセットする様子を示している。この「１０１１００００」のビット配列は、上記した各桁の定数を適用することにより、「−８０」という数値を表していることになる。
【００７５】
また、図２８(a)の場合には、商品コードの存在がブーリアン値のfalse, true, true, true, true, true, true, trueで表現されているため、インデックス生成部24がビット配列の最初の桁に「０」をセットすると共に、残りの桁に「１」をセットする様子を示している。この「０１１１１１１１」のビット配列は、上記した各桁の定数を適用することにより、「１２７」という数値を表していることになる。
図２８(b)の場合には、商品コードの存在がブーリアン値のtrue, false, false, false, false, false, false, falseで表現されているため、インデックス生成部24がビット配列の最初の桁に「１」をセットすると共に、残りの桁に「０」をセットする様子を示している。この「１０００００００」のビット配列は、上記した各桁の定数を適用することにより、「−１２７」という数値を表していることになる。
【００７６】
上記のように、ブーリアン配列の代わりに８桁のビット配列を用いることにより、−１２７〜１２７までの２５６通りの数値を表現することが可能となり、これは即ち２５６パターンのブーリアン値の組合せを僅か８ビット（１バイト）で表現できることを意味している。
【００７７】
以上の結果、図２９に示すように、図２５のブーリアン配列をビット配列に変換した木構造のインデックスがメモリ26上に形成される（Ｓ95）。
例えば、2006年３月15日の600店における商品コードとして「１１１１００００」のビット配列が関連付けられていた場合、ここから「true, true,true, true, false, false, false, false」のブーリアン配列が導かれ、これをディスティンクト・リスト34と対比することにより、「491234567890」、「491234567891」、「491234567892」、「491234567893」の具体的な商品コードを特定することが可能となる（下４桁のfalseはディスティンクト・リスト34のサイズと合致しないため、無視される）。
【００７８】
この場合も、クライアント端末20から検索リクエストが送信されると、データ処理部22はメモリ26上に形成された参照型及びビット配列を含む木構造のインデックスデータ及びディスティンクト・リスト34を参照し、検索条件に該当する全キー項目の値を取得した後、日付、店コード、商品コードを特定したSQL文を生成し、DBサーバ14に発行する。
【００７９】
ブーリアン配列の場合には、１つの状態（true or false）を表現するのにメモリを１バイト消費し、４つの状態を表現するのであれば４バイトのメモリを消費することになる。
これに対し、８桁のビット配列を用いた場合には、上記の通り１バイトで８つの状態を表示可能となり、メモリの使用量を劇的に抑制可能となる。
【００８０】
なお、ブーリアン配列のサイズが８桁を越えている場合には、別のビット配列がインデックス生成部24によって設けられ、そこにブーリアン値に応じた二値データがセットされる。
図３０はその具体例を示すものであり、ブーリアン配列が12桁である場合には１〜８桁までを第１のビット配列によって表現し、９〜12桁までが第２のビット配列によって表現される。
この場合、データ処理部22は第１のビット配列を参照することによってブーリアン配列の上８桁を特定し、また第２のビット配列を参照することによってブーリアン配列の下４桁を特定する。
その後、データ処理部22はディスティンクト・リスト34を参照することにより、具体的な商品コードを特定する。
【００８１】
上記にあっては、ブーリアン配列を経由してビット配列を生成する例を説明したが、図２２に示した参照型データを含む木構造のインデックスから直接ビット配列を生成することもできる。
すなわち、インデックス生成部24は、ディスティンクト・リスト34の各要素と各商品コードの値を、商品コードの上位キー項目である店コードを共通にする兄弟単位で順番にマッチングさせていき、ディスティンクト・リスト34の要素と一致する場合には、当該商品コードを削除すると共に、メモリ26上に設けた所定桁数のビット配列における対応位置に１をセットし、ディスティンクト・リストの値が存在しない場合には０を対応位置にセットする。
この場合もデータ処理部22は、メモリ26上に形成されたビット配列の各桁の値（１または０）とディスティンクト・リスト34を参照することにより、商品コードの値を取得する。
【００８２】
上記においては、最上位のキー項目である日付と最下位のキー項目である商品コードの間に、店コードのみが存在するテーブルを例に説明したが、最上位のキー項目と最下位のキー項目との間に複数階層のキー項目（例えば「日付−地域コード−店コード−商品コード」）が存在している場合にも適用可能であることはいうまでもない。
【図面の簡単な説明】
【００８３】
【図１】この発明に係るデータ処理システムの全体構成図である。
【図２】DBサーバのデータベースに格納されたテーブルの一例を示す図である。
【図３】参照型データを含む表形式のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図４】このシステムにおける検索処理の手順を示すフローチャートである。
【図５】APサーバのメモリに格納されたグループデータを示すイメージ図である。
【図６】APサーバのメモリにキャッシュされた参照型データを含む表形式のインデックスを示すイメージ図である。
【図７】APサーバのディスクにフォルダ−ファイル形式でキャッシュされたインデックスを示すイメージ図である。
【図８】木構造のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図９】APサーバのメモリに格納されたグループデータを示すイメージ図である。
【図１０】APサーバのメモリにキャッシュされた木構造のインデックスを示すイメージ図である。
【図１１】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図１２】APサーバのメモリに格納されたグループデータを示すイメージ図である。
【図１３】APサーバのメモリにキャッシュされた参照型データを含む木構造のインデックスを示すイメージ図である。
【図１４】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する他の手順を示すフローチャートである。
【図１５】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図１６】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図１７】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図１８】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する他の手順を示すフローチャートである。
【図１９】参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２０】APサーバのメモリにキャッシュされた参照型データを含む木構造のインデックスを示すイメージ図である。
【図２１】参照型データ及びブーリアン配列を含む木構造のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図２２】APサーバのメモリに形成された参照型データを含む木構造のインデックスを示すイメージ図である。
【図２３】参照型データ及びブーリアン配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２４】参照型データ及びブーリアン配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２５】APサーバのメモリにキャッシュされた参照型データ及びブーリアン配列を含む木構造のインデックスを示すイメージ図である。
【図２６】参照型データ及びビット配列を含む木構造のインデックスをAPサーバのメモリ上に生成する手順を示すフローチャートである。
【図２７】参照型データ及びビット配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２８】参照型データ及びビット配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【図２９】APサーバのメモリにキャッシュされた参照型データ及びビット配列を含む木構造のインデックスを示すイメージ図である。
【図３０】参照型データ及びビット配列を含む木構造のインデックスをAPサーバのメモリ上に生成する要領を示す説明図である。
【符号の説明】
【００８４】
10 データ処理システム
12 APサーバ
14 DBサーバ
16 ロードバランサ
18 イントラネット
20 クライアント端末
22 データ処理部
24 データ圧縮部
26 メモリ
28 データベース管理システム
30 データベース
32 ディスティンクト配列
34 ディスティンクト・リスト
36 商品コードの配列
【特許請求の範囲】
【請求項１】
DBサーバとAPサーバを備えたデータ処理システムであって、
上記DBサーバが、データベース管理システムと、テーブルを格納したデータベースを備え、
上記APサーバが、上記DBサーバにSQL文を発行し、上記テーブルのキー項目に係るデータの読み出しを指令するデータ読み出し手段と、
DBサーバから送信されたキー項目に係るデータを圧縮し、上記APサーバの記憶手段に上記テーブルのインデックスとして格納するインデックス生成手段と、
クライアント端末から上位キー項目を検索条件として指定した検索リクエストが送信された場合に、上記APサーバのインデックスを参照し、上記検索条件に包含されるキー項目の値を取得するキー項目値取得手段と、
各キー項目の値を特定したSQL文を生成し、上記DBサーバに発行する手段とを備えたことを特徴とするデータ処理システム。
【請求項２】
上記のデータ読み出し手段が、上記SQL文において一または複数のキー項目の値を指定することにより、上記DBサーバから上記テーブルをグループに分割して読み出す処理を実行し、
上記のインデックス生成手段が、圧縮処理をグループ単位で実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
上記インデックス生成手段が、上記DBサーバから送信されたデータ中において値が相互に重複するものが存在する場合に、一つの値のみを実データとしてメモリ上に残し、他の値については上記実データを参照する型に変換する処理を実行し、参照型データを含む表形式のインデックスを生成することを特徴とする請求項１に記載のデータ処理システム。
【請求項４】
上記インデックス生成手段が、少なくとも最上位のキー項目毎に対応のフォルダをAPサーバのディスク上に生成する第１の処理と、
各最上位のキー項目に包含される１または複数の中位キー項目に対応したファイルを生成し、対応のフォルダに格納する第２の処理と、
各中位のキー項目に包含される１または複数の下位キー項目の値を対応のファイルに記述する第３の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項５】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、
残された最上位のキー項目を一つの根の元に結合させることにより、木構造のインデックスをAPサーバのメモリ上に生成する第２の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項６】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、
値が相互に重複する下位のキー項目については、一の値のみを実データとしてAPサーバのメモリ上に残し、他の値については上記実データを参照する型に変換する第２の処理と、
残された最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する第３の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項７】
上記のデータ圧縮手段が、上記DBサーバから送信された各レコードの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、
各レコードの下位のキー項目の値と先行レコードの同キー項目の値とを順次比較し、先行レコードの値と重複する値を削除すると共に、先行レコードの値を参照する型に変換する第２の処理と、
残された上位キー項目同士を一つの根の元に結合させ、参照型を含む木構造のデータを生成する第３の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項８】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第１の処理と、
各レコードを下位のキー項目の値に基づいて所定の順序で整列させ、下位のキー項目の値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第２の処理と、
各レコードを少なくとも最上位のキー項目の値に基づいて所定の順序で整列させる第３の処理と、
最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のデータを生成する第４の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項９】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、
残された最上位のキー項目を一つの根の元に結合させて木構造のデータを生成する第２の処理と、
上記木構造のデータに含まれる最下位のキー項目の類型を抽出し、これらを要素として充填させたディスティンクト・リストをメモリ上に生成する第３の処理と、
上記ディスティンクト・リストに含まれる各要素と上記木構造のデータに含まれる最下位のキー項目の各値とをマッチングし、最下位のキー項目の各値をディスティンクト・リスト中の対応の要素を参照する型に変換する第４の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項１０】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第４の処理を実行し、
上記キー項目値取得手段が、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項１に記載のデータ処理システム。
【請求項１１】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第４の処理と、
上記のブーリアン配列をビット配列に変換する第５の処理を実行し、
上記キー項目値取得手段が、各ビット配列をブーリアン配列に変換し、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項１に記載のデータ処理システム。
【請求項１２】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたビット配列における対応位置に１をセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ビット配列の対応位置に０をセットする第４の処理を実行し、
上記キー項目値取得手段が、各ビット配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項１に記載のデータ処理システム。
【請求項１】
DBサーバとAPサーバを備えたデータ処理システムであって、
上記DBサーバが、データベース管理システムと、テーブルを格納したデータベースを備え、
上記APサーバが、上記DBサーバにSQL文を発行し、上記テーブルのキー項目に係るデータの読み出しを指令するデータ読み出し手段と、
DBサーバから送信されたキー項目に係るデータを圧縮し、上記APサーバの記憶手段に上記テーブルのインデックスとして格納するインデックス生成手段と、
クライアント端末から上位キー項目を検索条件として指定した検索リクエストが送信された場合に、上記APサーバのインデックスを参照し、上記検索条件に包含されるキー項目の値を取得するキー項目値取得手段と、
各キー項目の値を特定したSQL文を生成し、上記DBサーバに発行する手段とを備えたことを特徴とするデータ処理システム。
【請求項２】
上記のデータ読み出し手段が、上記SQL文において一または複数のキー項目の値を指定することにより、上記DBサーバから上記テーブルをグループに分割して読み出す処理を実行し、
上記のインデックス生成手段が、圧縮処理をグループ単位で実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
上記インデックス生成手段が、上記DBサーバから送信されたデータ中において値が相互に重複するものが存在する場合に、一つの値のみを実データとしてメモリ上に残し、他の値については上記実データを参照する型に変換する処理を実行し、参照型データを含む表形式のインデックスを生成することを特徴とする請求項１に記載のデータ処理システム。
【請求項４】
上記インデックス生成手段が、少なくとも最上位のキー項目毎に対応のフォルダをAPサーバのディスク上に生成する第１の処理と、
各最上位のキー項目に包含される１または複数の中位キー項目に対応したファイルを生成し、対応のフォルダに格納する第２の処理と、
各中位のキー項目に包含される１または複数の下位キー項目の値を対応のファイルに記述する第３の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項５】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、
残された最上位のキー項目を一つの根の元に結合させることにより、木構造のインデックスをAPサーバのメモリ上に生成する第２の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項６】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、
値が相互に重複する下位のキー項目については、一の値のみを実データとしてAPサーバのメモリ上に残し、他の値については上記実データを参照する型に変換する第２の処理と、
残された最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のインデックスをAPサーバのメモリ上に生成する第３の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項７】
上記のデータ圧縮手段が、上記DBサーバから送信された各レコードの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、
各レコードの下位のキー項目の値と先行レコードの同キー項目の値とを順次比較し、先行レコードの値と重複する値を削除すると共に、先行レコードの値を参照する型に変換する第２の処理と、
残された上位キー項目同士を一つの根の元に結合させ、参照型を含む木構造のデータを生成する第３の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項８】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第１の処理と、
各レコードを下位のキー項目の値に基づいて所定の順序で整列させ、下位のキー項目の値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、残されたデータを参照する型に変換する第２の処理と、
各レコードを少なくとも最上位のキー項目の値に基づいて所定の順序で整列させる第３の処理と、
最上位のキー項目を一つの根の元に結合させ、参照型データを含む木構造のデータを生成する第４の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項９】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除されたデータに従属していた下位データを残されたデータに関連付ける第１の処理と、
残された最上位のキー項目を一つの根の元に結合させて木構造のデータを生成する第２の処理と、
上記木構造のデータに含まれる最下位のキー項目の類型を抽出し、これらを要素として充填させたディスティンクト・リストをメモリ上に生成する第３の処理と、
上記ディスティンクト・リストに含まれる各要素と上記木構造のデータに含まれる最下位のキー項目の各値とをマッチングし、最下位のキー項目の各値をディスティンクト・リスト中の対応の要素を参照する型に変換する第４の処理を実行することを特徴とする請求項１に記載のデータ処理システム。
【請求項１０】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第４の処理を実行し、
上記キー項目値取得手段が、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項１に記載のデータ処理システム。
【請求項１１】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたディスティンクト・リストと同サイズのブーリアン配列における対応位置にブーリアン型のtrueをセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ブーリアン配列の対応位置にブーリアン型のfalseをセットする第４の処理と、
上記のブーリアン配列をビット配列に変換する第５の処理を実行し、
上記キー項目値取得手段が、各ビット配列をブーリアン配列に変換し、各ブーリアン配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項１に記載のデータ処理システム。
【請求項１２】
上記インデックス生成手段が、上記DBサーバから送信された各データの中で、少なくとも最上位のキー項目については、値が相互に重複する場合に一つのレコードのデータを残して他のレコードのデータを削除し、削除された上位データに従属していた下位データを残された上位データに関連付ける第１の処理と、
残された最上位のキー項目同士を一つの根の元に結合させ、木構造のデータを生成する第２の処理と、
最下位のキー項目に含まれる値の類型を抽出し、これらを所定の順序で整列させたディスティンクト・リストを生成し、メモリに格納する第３の処理と、
上記ディスティンクト・リストに含まれる各要素と最下位のキー項目の値とを、親のキー項目を共通にする兄弟単位で順にマッチングさせ、ディスティンクト・リストの要素が最下位のキー項目に存在する場合には、メモリ上に設けたビット配列における対応位置に１をセットすると同時に実データを削除し、該当の値が最下位のキー項目に存在しない場合には上記ビット配列の対応位置に０をセットする第４の処理を実行し、
上記キー項目値取得手段が、各ビット配列及び上記ディスティンクト・リストを参照することにより、最下位のキー項目の値を特定することを特徴とする請求項１に記載のデータ処理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【公開番号】特開２００７−３１０８４５（Ｐ２００７−３１０８４５Ａ）
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願番号】特願２００６−１４２１７６（Ｐ２００６−１４２１７６）
【出願日】平成１８年５月２２日（２００６．５．２２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願日】平成１８年５月２２日（２００６．５．２２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]