(57)【特許請求の範囲】
【請求項１】
DBサーバとAPサーバを備えたデータ処理システムであって、
上記DBサーバが、プライマリキーが付与された第１のレコードを格納する第１のテーブルと、第１のレコードの階層構造化された分類属性を規定する第２のレコードを格納した第２のテーブルとを備え、
上記APサーバが、上記DBサーバにSQL文を発行し、上記第２のテーブルに格納された第２のレコードの読み出しを指令するデータ読み出し手段と、
DBサーバから送信された第２のレコードに基づいて木構造のインデックスを生成し、APサーバの記憶装置に格納するインデックス生成手段と、
クライアント端末から分類属性を組み合わせた検索条件が送信された場合に、上記インデックスを参照し、当該検索条件に合致する第１のレコードのプライマリキーを取得する手段と、
第１のレコードのプライマリキーを特定したSQL文を生成し、上記DBサーバに発行する手段を備え、
上記第２のレコードが、上位の分類属性が記述される親項目と、これに直結する下位の分類属性が記述される子項目を有しており、あるレコードの子項目に記述された分類属性が他のレコードの親項目の分類属性として記述されると共に、最下位の分類属性を親項目に記述したレコードの子項目に第１のレコードのプライマリキーが記述される再帰的な構造を備えており、
さらに上記APサーバが、上記第２のレコードに格納された必要な分類属性に対して、当該分類属性に一意性を付与するためのユニーク情報を追加する手段と、
上記インデックスを生成する際に各分類属性から上記ユニーク情報を削除する手段を備えたことを特徴とするデータ処理システム。
【請求項２】
上記ユニーク情報が、相互に重複しない数値からなる連番であることを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
上記ユニーク情報が、各分類属性よりも上位に位置する分類属性を連結させた経路情報であることを特徴とする請求項１に記載のデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はデータ処理システムに係り、特に、DBサーバが管理するレコードの分類体系をAPサーバ内にインデックスとしてキャッシュしておき、DBサーバにSQL文を発行するに際してはレコードのプライマリキーを特定することにより、検索処理等の高速化を実現する技術に関する。
【背景技術】
【０００２】
クライアントサーバ型システムの進展に伴い、より大規模な情報処理の要求に応えるために、データの表示をするクライアントの他にデータの加工を行うAPサーバ及びデータの格納をするDBサーバを備えた、いわゆる三層構造のクライアントサーバシステムが普及してきている。
また、処理速度の向上を図るため、複数のAPサーバを並列配置させることで負荷を分散させることも行われている。
【特許文献１】特開２００５−１６５６１０
【発明の開示】
【発明が解決しようとする課題】
【０００３】
APサーバは廉価なPCサーバで構成することができるため、設置台数を増加させることで処理速度を向上させることは比較的容易であるが、DBサーバについてはデータの同期を維持する必要性があるため、APサーバのように簡単に分散処理に移行することはできない。もちろん、データベースシステムのベンダ各社は、様々な技術を駆使してソフトウェア及びハードウェアの両面からDBサーバ自体の高速化を図ってきており、その結果一定の成果は上がっているが、その分システムの価格が上昇することは否めない。今後ともクライアントサーバ型システムに担わされるデータベースの規模が増大を続ける限り、いずれはディスクI/O（データの読み書き）速度が壁となり、DBサーバの性能アップでは対応できない時期が来るものと予想される。
【０００４】
ところで、DBサーバにおいては一般に、各レコードにユニークなプライマリキーが付与されると共に、各レコードの位置付けを規定するための分類属性が複数付与されている。例えば、図１１に示す伝票管理用のテーブルにおいては、それぞれのレコードに「伝票番号」というユニークなプライマリキーが割り振られており、この伝票番号を指定することによって目的のレコードをピンポイントで抽出することが可能となるのであるが、検索の便宜のために年度、法人、伝票種類の分類属性が割り振られている。この結果ユーザは、具体的な伝票番号を認識していなくとも、「年度×法人×伝票種類」を検索条件として指定することにより、この検索条件にマッチする複数のレコードをDBサーバから抽出することが可能となる。
【０００５】
しかし一方で、SQL文中で年度、法人、伝票種類の分類属性のみを指定してレコードの抽出を命令した場合、DBサーバは指定された年度、法人、伝票種類にマッチする全てのレコードを先頭レコードから走査して該当のレコードを抽出するフル・スキャンと呼ばれる処理を実行する必要が生じ、その分時間を要することとなる。
【０００６】
また、各レコード毎に分類属性の項目を設ける必要があるため、当然ながらその分データ容量が嵩むこととなり、テーブルの肥大化に繋がる。大手流通グループの場合でいえば、伝票件数が年間１千万件単位となるため、各レコード毎に「2006」や「H001」等のデータを重複して持つことにより、膨大なリソースを消費する結果となる。
【０００７】
また、一旦分類体系を付与した以上、途中で分類体系の見直しをするとテーブル定義の変更（カラムの追加・変更・削除）が必要となるため、長期間に亘ってこれを踏襲する必要があり、システムの柔軟性が損なわれるという問題もある。
【０００８】
さらに、検索処理の高速化のため、分類属性の組合せパターンに応じてDBサーバ内にインデックス（索引情報）が生成されるのが一般的であるが、分類属性の項目数が多くて様々な検索パターンが想定される場合には、２次インデックス、３次インデックス…のように索引情報自体が複雑化・肥大化する結果、DBサーバのディスク容量を圧迫する。もちろん、レコードの追加時にはこれらのインデックスを再構築する必要が生じ、その結果生じるCPU負荷も無視することはできない。
【０００９】
この発明は、従来のデータ処理システムが抱えていた上記の問題を解決するために案出されたものであり、DBサーバ自体の性能アップに依存することなく、DBサーバにおけるフル・スキャンの頻度を低減することで検索処理の高速化を達成でき、また各レコードの分類属性項目によってDBサーバのディスク容量が圧迫されることもなく、レコードの分類体系の変更にも柔軟に対応可能であり、２次、３次インデックスの生成も不要なデータ処理システムの提供を目的としている。
【課題を解決するための手段】
【００１０】
上記の目的を達成するため、請求項１に記載したデータ処理システムは、DBサーバとAPサーバを備えたデータ処理システムであって、上記DBサーバが、プライマリキーが付与された第１のレコードを格納する第１のテーブルと、第１のレコードの階層構造化された分類属性を規定する第２のレコードを格納した第２のテーブルとを備え、上記APサーバが、上記DBサーバにSQL文を発行し、上記第２のテーブルに格納された第２のレコードの読み出しを指令するデータ読み出し手段と、DBサーバから送信された第２のレコードに基づいて木構造のインデックスを生成し、APサーバの記憶装置に格納するインデックス生成手段と、クライアント端末から分類属性を組み合わせた検索条件が送信された場合に、上記インデックスを参照し、当該検索条件に合致する第１のレコードのプライマリキーを取得する手段と、第１のレコードのプライマリキーを特定したSQL文を生成し、上記DBサーバに発行する手段を備え、上記第２のレコードが、上位の分類属性が記述される親項目と、これに直結する下位の分類属性が記述される子項目を有しており、あるレコードの子項目に記述された分類属性が他のレコードの親項目の分類属性として記述されると共に、最下位の分類属性を親項目に記述したレコードの子項目に第１のレコードのプライマリキーが記述される再帰的な構造を備えており、さらに上記APサーバが、上記第２のレコードに格納された必要な分類属性に対して、当該分類属性に一意性を付与するためのユニーク情報を追加する手段と、上記インデックスを生成する際に各分類属性から上記ユニーク情報を削除する手段を備えたことを特徴としている。
【００１１】
請求項２に記載したデータ処理システムは、請求項１のシステムであって、さらに上記ユニーク情報が、相互に重複しない数値からなる連番であることを特徴としている。
【００１２】
請求項３に記載したデータ処理システムは、請求項１のシステムであって、さらに上記ユニーク情報が、各分類属性よりも上位に位置する分類属性を連結させた経路情報であることを特徴としている。
【発明の効果】
【００１５】
請求項１に記載したデータ処理システムにあっては、DBサーバの第１のテーブルに格納された第１のレコードの階層構造化された分類属性が、APサーバのメモリやディスク内にキャッシュされているため、DBサーバに検索を指令する際には第１のレコードのプライマリキーを特定し、抽出対象をピンポイントで絞り込んだ形のSQL文を発行することが可能となる。この結果、DBサーバにおいてフル・スキャンが発生することがなくなり、その分検索処理の高速化を実現できる。このように、APサーバから抽出対象をピンポイントで絞り込んだSQL文が発行される以上、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は、データベース管理システム（RDBMS）28と、第１のテーブル30と、第２のテーブル32を備えている。
データベース管理システム28は、第１のテーブル30及び第２のテーブル32を管理し、各テーブルに格納されたデータの入出力、更新、および所定の演算などを行う。
【００２２】
ロードバランサ16は、クライアント端末20から送信されたリクエストを、各APサーバ12にかかっている負荷に応じて分散する役割を果たす。
【００２３】
クライアント端末20は、ＰＣ等のコンピュータよりなり、OSの他に、Webブラウザプログラム等のアプリケーションプログラムがセットアップされている。
【００２４】
図２は、第１のテーブル30の構成例を示すものであり、伝票番号、発行日、発行店舗、担当者等のデータ項目を備えた第１のレコード34が多数登録されている。第１のレコード34は、ユニークな伝票番号によって一意に特定される。
【００２５】
図３は、第２のテーブル32の構成例を示すものであり、親ID（親項目）及び子ID（子項目）の二つのデータ項目を備えた第２のレコード36が多数登録されている。
この第２のテーブル32は、第１のテーブル30に格納された第１のレコード34の階層構造化された分類属性を規定するものである。
【００２６】
図４は、第１のレコード34の分類体系を木構造で表現したものであり、ROOT（根）の直下に「2005」、「2006」、「2007」の年度が配置されている。また、各年度には「H001」、「H002」、「H003」の法人コードが配置され、各法人コードには「C01」、「C02」、「C03」の伝票種類コードが配置されている。さらに、各伝票種類コードには、「10001」、「10002」、「10003」等の伝票番号が配置されている（図示の便宜上、「2006-H001-C01」のライン以外は記載を省略）。
この分類体系を参照することにより、例えば「伝票番号＝10002」の伝票は、2006年度にH001の法人によって発行された「C01」種類に属することが理解できる。
【００２７】
従来のデータ管理システムにあっては、図１１に示した通り、各レコードに年度コード、法人コード、伝票種類コードの項目を設けることによって、このような分類体系を表現していたのであるが、このシステム10の場合には、親ID及び子IDの２つのデータ項目を備えた第２のテーブル36によって伝票の分類体系を規定している。
【００２８】
まず、第２のテーブル36においては、「親ID＝ROOT、子ID＝2005」、「親ID＝ROOT、子ID＝2006」、「親ID＝ROOT、子ID＝2007」の３つのレコード群Ａにより、ROOTに繋がる最上位の分類属性が「2005」、「2006」、「2007」の３つであることが規定されている。
【００２９】
また、第２のテーブル36においては、「親ID＝2006、子ID＝1001_H001」、「親ID＝2006、子ID＝1002_H002」、「親ID＝2006、子ID＝1003_H003」の３つのレコード群Ｂにより、2006に繋がる中位の分類属性が「H001」、「H002」、「H003」の３つであることが規定されている。
【００３０】
なお、H001の前に付加された「1001_」、H002の前に付加された「1002_」、H003の前に付加された「1003_」は、各ノード（分類属性）にユニーク性を付与する目的で、APサーバ12によって必要データに対し自動的に採番される連番である。
すなわち、H001の法人コードは2006年に限定されるものでなく、2005年あるいは2007年配下にも存在する可能性があるため、他の年度におけるH001と区別するため、APサーバ12のデータ処理部22は、予め第２のテーブル32に格納された第２のレコード36に対して、自動的にユニークな連番を付与しておく。
因みに、2005、2006、2007はROOTに繋がる最上位の分類属性であり、本来的にユニークであるため、自動連番付与の対象から外されている。
【００３１】
また、第２のテーブル32においては、「親ID＝1001_H001、子ID＝1004_C01」、「親ID＝1001_H001、子ID＝1005_C02」、「親ID＝1001_H001、子ID＝1006_C03」の３つのレコード群Ｃにより、H001に繋がる下位の分類属性が「C01」、「C02」、「C03」の３つであることが規定されている。
ここでも、C01の前に付加された「1004_」、C02の前に付加された「1005_」、C03の前に付加された「1006_」は、各ノード（分類属性）にユニーク性を付与するためAPサーバ12によって自動的に採番される連番を意味している。
【００３２】
さらに、第２のテーブル36においては、「親ID＝1004_C01、子ID＝10001」、「親ID＝1004_C01、子ID＝10002」、「親ID＝1004_C01、子ID＝10003」、「親ID＝1004_C01、子ID＝10004」、「親ID＝Ｃ０１、子ID＝10005の５つのレコード群Ｄにより、最下位の分類属性であるＣ０１に繋がる具体的な伝票番号が、「10001」、「10002」、「10003」、「10004」、「10005」の５つであることが規定されている。
【００３３】
上記のように、ユニークな伝票番号によって一意に特定される第１のレコード34の分類体系を規定する第２のレコード36を、第１のレコード34毎に年度、法人、伝票種類といった分類属性を関連付ける通常の表形式とする代わりに、上位の子項目が次の階層の親項目となり、下位の分類属性を子項目として指定する（関連付ける）という再帰的な構造によって分類体系を表現することにより、データの重複を大幅に削減することが可能となる。
【００３４】
また、システムの運用途中で分類体系に変更を加える必要が生じた場合であっても、第２のテーブルのレコードの変更（追加及び削除）だけで済み、テーブル定義に変更を加える必要がないため、システムの柔軟性な改変が可能となる利点がある。
【００３５】
なお、新しいレコード36を第２のテーブル32に加える際、APサーバ12のデータ処理部22は第２のテーブル32を参照して最終の連番を確認し、これよりも後の連番（必ずしも直後の連番である必要はなく、一定の間隔が空いてもよい）を必要なデータに対し自動的に付与する。
【００３６】
あるいは、連番管理用のテーブルをDBサーバ14内に設けておき、新たに連番を付与するに際してはAPサーバ12がこれを参照し、最終の連番＋１の値を第２のレコード36に付加するように構成してもよい。この場合、APサーバ12はこの最新の連番によって上記連番管理用テーブルの最終値を更新する。
【００３７】
以下、図５のフローチャートに従い、APサーバ12による木構造のインデックスの生成に係る処理手順を説明する。
まず、APサーバ12のデータ処理部22は、DBサーバ14に対して定期的にSQL文を発行し、第２のテーブル32に格納されたROOTノードを親とする第２のレコード36を取得する（Ｓ10）。
つぎに、インデックス生成部24が上記第２のレコード36の子の値を抽出し、ROOTノードに直に繋がる最上位ノードの一覧を生成する（Ｓ12）。具体的には、図６に示すように、「2005」、「2006」、「2007」が最上位ノードとして認定される。
【００３８】
つぎにデータ処理部22は、DBサーバ14に対してSQL文を発行し、ROOTノードを親としない第２のレコード36を、第２のテーブル32から最上位ノード単位で取得する（Ｓ14）。
【００３９】
つぎにインデックス生成部24は、共通の親を有する第２のレコード36同士を集めてグループを生成する（Ｓ16）。図７に示すように、このグループ38は、共通の親をキー部とし、それぞれの子をメンバー部として有している。
【００４０】
つぎにインデックス生成部24は、各グループ38のキー部を参照し、親ノードの一覧を生成する（Ｓ18）。すなわち、何れかのキー部に登場するノードは親ノードと判定され、一度もキー部に登場しないノードは親ノードではないものとして一覧から排除される。この親ノード一覧は、後で各グループ38の子が他のグループ38の親に該当するか否かを判断する際に参照される。
【００４１】
つぎにインデックス生成部24は、最上位ノードの１つを選択した後（Ｓ20）、当該最上位ノードに下位のノードを継ぎ足して木構造を形成していく。ここでは「2005」配下の木構造が既に完成し、「2006」がつぎの処理対象として選択されたものとして説明を進める。
【００４２】
まずインデックス生成部24は、「2006」を親に持つグループを検索する（Ｓ22）。この結果、「H001」、「H002」、「H003」をメンバー部に有する図７(a)のグループ38aが抽出される。
【００４３】
つぎにインデックス生成部24は、Ｓ18で生成した親ノード一覧を参照し、同グループ38aのメンバー部が他のグループ38の親であるか否かを判定する（Ｓ24）。
この場合、「H001」等は「C01」、「C02」、「C03」等をメンバー部とするグループ38bにおいて親となっているため、YESの判定結果が得られる。
この結果、インデックス生成部24は、メンバー部の１つである「H001」を選択し、図７(b)のグループを枝として上記2006のTreeに継ぎ足す（Ｓ26）。この際、各データに付与されていた連番が、インデックス生成部24によって削除される（以下同様）。
【００４４】
つぎにインデックス生成部24は、このグループ38bに属する子ノードの１つである「C01」を選択した後（Ｓ30）、この「C01」を親とするグループ38を検索する（Ｓ32）。この結果、図７(c)のグループ38cが抽出される。
【００４５】
つぎにインデックス生成部24は、Ｓ18で生成した親ノード一覧を参照し、当該グループ38cのメンバー部が他のグループの親であるか否かを判定する（Ｓ34）。
この場合、「C01」のメンバー部である「10001」〜「10005」は何れも他のグループで親となっていないため、NOの判定結果が得られる。
この結果、インデックス生成部24は当該グループ38cを葉としてTreeに追加する（Ｓ36）。
【００４６】
このようにして、図６に示すように、「2006-H001-C01」のラインが完了した後、インデックス生成部24はＳ30〜Ｓ36の処理を繰り返し、「C02」及び「C03」をキー部とするグループを葉としてTreeに追加することにより、「2006-H001-C02」及び「2006-H001-C03」のラインを完成させる（図示省略）。
その後、インデックス生成部24は「H002」以下及び「H003」以下についてもＳ26〜Ｓ36  の処理を繰り返し、「2006」配下のTreeを完成させる。
そして、「2006」を最上位ノードとするTreeが完成した後、インデックス生成部24は「2007」を最上位ノードとするTreeの生成に着手する。
【００４７】
なお、上記のＳ24においてNoと判定された場合（グループ38の子が他のグループ38の親でない場合）、インデックス生成部24は該当グループ38を葉としてTreeに追加すると共に、階層の深化を停止して右隣の葉の追加処理に移行する。
また、上記のＳ34においてYesと判定された場合（グループ38の子が他のグループ38の親である場合）、インデックス生成部24は該当グループ38を枝としてTreeに追加すると共に、つぎの階層の構築に移行する。
このように、あるグループ38の子が他のグループ38の親であるか親でないかをインデックス生成部24が判定し、その結果に応じてTreeに枝として追加するか葉として追加するかを切り替えることにより、分類体系の階層が増減してもインデックス生成部24は正しく階層構造を再現することが可能となる。
【００４８】
以上のようにして、全ての最上位分類属性配下のTreeをメモリ26上に完成させたインデックス生成部24は、この木構造の分類体系に基づいて、フォルダ−ファイル形式のインデックスをハードディスク27上に生成する。
具体的には、図８に示すように、ハードディスク27の「ROOT」フォルダ44配下に「2005」、「2006」、「2007」の年度フォルダ46を生成し、それぞれの配下に法人フォルダ48（「H001」等）を生成する。
また、インデックス生成部24によって伝票種類に対応したファイル名（「C01」等）のテキストファイル50が生成され、対応の法人フォルダ48内に格納される。
これらのテキストファイル50には、当該伝票種類に属する具体的な伝票番号52が記述されている。
【００４９】
つぎに、図９のフローチャートに従い、このシステム10による検索処理について説明する。
まず、クライアント端末20からの検索リクエストを、ロードバランサ16経由でAPサーバ12が受信すると（Ｓ50）、データ処理部22はハードディスク27上に形成されたフォルダ−ファイル形式のインデックス42を参照し、検索条件に該当する全ての伝票番号を取得する（Ｓ52）。
例えば、クライアント端末20から「2006（年度）×H001（法人）×C01（伝票種類）」の検索条件が送信された場合、データ処理部22は「10001」、「10002」、「10003」、「10004」、「10005」の値を取得する。
【００５０】
つぎにデータ処理部22は、上記の伝票番号を明記したSQL文を生成し、DBサーバ14に発行する（Ｓ54）。
これに対しDBサーバ14は、該当する第１のレコード34を第１のテーブル30から抽出し、APサーバ12に送信する。
これを受けたデータ処理部22は、所定の形式に加工した上で、クライアント端末20に送信する（Ｓ56）。
【００５１】
このデータ処理システム10にあっては、DBサーバ14の第１のテーブル30に格納された第１のレコード34の分類体系が、木構造のインデックスとしてAPサーバ12内にキャッシュされているため、DBサーバ14に検索を指令する際には第１のレコード34のプライマリキーを特定し、抽出対象をピンポイントで絞り込んだ形のSQL文を発行することが可能となる。
この結果、DBサーバ14においてフル・スキャンが発生することがなくなり、その分検索処理の高速化を実現できる。
【００５２】
上記のように、一旦メモリ26上に構築した木構造のインデックス（分類体系）を、フォルダ−ファイル形式のインデックス42に変換してハードディスク27に格納した結果、比較的サイズの大きなインデックスであっても、必要な部分を個別にメモリに復元すれば済むため、瞬間的にAPサーバ12のメモリを圧迫することを有効に回避できる利点があるが、分類属性の数や第１のレコード34の件数が比較的少ない場合には、メモリ26上に生成された木構造のインデックスをそのまま参照するように構成してもよい。
【００５３】
図１０は、第２のテーブル32の他の構成例を示すものであり、各ノード（分類属性）のユニーク性を担保するために「1001_」や「1002_」といった連番を自動的に付与する代わりに、必要なデータに対し上位ノードの経路（パス）情報がAPサーバ12のデータ処理部22によって付与される点に特徴を有している。
【００５４】
例えば「2006_H001」のように、「H001」の前に「2006_」を付与することにより、2006配下のH001であることが明確となり、2005配下のH001や2007配下のH001と識別可能となる。
また、「2006H001_C01」のように、「C01」の前に「2006H001_」を付与することにより、2006×H001配下のC01であることが明確となり、2006×H002配下のC01と識別可能となる。
【００５５】
この経路情報は、上記連番付与方式の第２のテーブル32による場合と同様、メモリ26上に木構造のインデックスが生成されるタイミングで、インデックス生成部24によって削除される。
また、システムの運用途中で分類体系に変更を加える必要が生じ、第２のテーブル32に対する第２のレコード36の追加及び削除がなされた際には、APサーバ12のデータ処理部22によって変更箇所配下に位置する各データの経路情報の書き替えが実行される。
【００５６】
なお、分類属性相互間で同じ値が重複する可能性がない場合には、上記のように連番や経路情報をレコード36の分類属性に付加する必要がないことは言うまでもない。
【図面の簡単な説明】
【００５７】
【図１】この発明に係るデータ処理システムの全体構成図である。
【図２】第１のテーブルの構成例を示す図である。
【図３】第２のテーブルの構成例を示す図である。
【図４】第１のレコードの分類体系を木構造で表現した図である。
【図５】インデックスの生成手順を示すフローチャートである。
【図６】木構造のインデックスを生成する過程を示す図である。
【図７】グループの生成過程を示す図である。
【図８】フォルダ−ファイル形式のインデックスを示す図である。
【図９】検索手順を示すフローチャートである。
【図１０】第２のテーブルの他の構成例を示す図である。
【図１１】従来のテーブルの構成例を示す図である。
【符号の説明】
【００５８】
10 データ処理システム
12 APサーバ
14 DBサーバ
16 ロードバランサ
18 イントラネット
20 クライアント端末
22 データ処理部
24 インデックス生成部
26 メモリ
27 ハードディスク
28 データベース管理システム
30 第１のテーブル
32 第２のテーブル
34 第１のレコード
36 第２のレコード
38a〜38c グループ
42 フォルダ−ファイル形式のインデックス
44 ルートフォルダ
46 年度フォルダ
48 法人フォルダ
50 テキストファイル
52 伝票番号
【図１】
0005069525.tif 000002
【図２】
0005069525.tif 000003
【図３】
0005069525.tif 000004
【図４】
0005069525.tif 000005
【図５】
0005069525.tif 000006
【図６】
0005069525.tif 000007
【図７】
0005069525.tif 000008
【図８】
0005069525.tif 000009
【図９】
0005069525.tif 000010
【図１０】
0005069525.tif 000011
【図１１】
0005069525.tif 000012