(57)【特許請求の範囲】
【請求項１】
分類体系を規定するレコードを格納した分類テーブルを備えたDBサーバと、このDBサーバにネットワークによって接続された複数のAPサーバとからなる分類体系情報管理システムであって、
上記分類テーブルのレコードが、上位の分類属性が記述される親項目と、これに直結する下位の分類属性が記述される子項目を有しており、あるレコードの子項目に記述された分類属性が他の下位の分類属性に係るレコードの親項目の値として記述される再帰的な構造を備えると共に、分類体系を木構造で表現した際にROOTノードに直に繋がる最上位ノードとなる分類属性のレコードに関しては、その親項目の値としてROOTが設定されており、
上記の各APサーバは、
(1) 上記DBサーバにSQL文を発行し、上記分類テーブルに格納されたROOTを親項目の値とするレコードを取得する処理と、
(2) 取得した各レコードの子項目の値を抽出し、最上位ノードの一覧を生成する処理と、
(3) 上記DBサーバにSQL文を発行し、ROOTを親項目の値として含まないレコードを取得する処理と、
(4) 取得したレコードの中で親項目の値が共通するレコード同士を集め、親項目の値を共通のキー部とし、それぞれの子項目の値をメンバー部として有するグループを生成する処理と、
(5) 特定の最上位ノードをキー部とするグループを抽出すると共に、各グループを当該最上位ノードに継ぎ足す処理と、
(6) 継ぎ足されたグループに属するメンバー部の値をキー部とするグループを抽出し、各グループを上記メンバー部の分類属性に継ぎ足す処理と、
(7) 継ぎ足されたグループに属するメンバー部の値をキー部とするグループを抽出し、各グループを上記メンバー部の分類属性に継ぎ足す処理を、上記メンバー部の値をキー部とするグループが存在しなくなるまで繰り返して、一の最上位ノード配下の木構造をメモリ上に完成させる処理と、
(8) 上記(5)〜(7)の処理を他の最上位ノードに関して繰り返すことにより、全ての最上位ノード配下の木構造をメモリ上に完成させる処理と、
(9) メモリ上に生成された上記木構造の分類体系情報に記述された分類属性がフォルダ名またはファイル名として記述されると共に、各フォルダまたはファイルを上記木構造の分類体系の該当する階層位置に配したフォルダ−ファイル形式の分類体系情報を生成し、ハードディスク上に格納する処理と、
(10) 特定の分類情報が入力された場合に、上記フォルダ−ファイル形式の分類体系情報の必要部分を木構造の分類体系情報としてメモリ上に復元すると共に、このメモリ上の分類体系情報を参照して、当該分類属性配下の分類属性を取得する処理と、
(11) この分類属性を出力する処理と、
を実行することを特徴とする分類データ管理システム。
【請求項２】
上記レコードに格納された少なくとも一部の分類属性には、一意性を確保するためのユニーク情報が付加されており、
上記木構造の分類体系情報を生成する際に、このユニーク情報が削除されることを特徴とする請求項１に記載の分類データ管理システム。
【請求項３】
上記ユニーク情報が、相互に重複しない数値からなる連番であることを特徴とする請求項２に記載の分類データ管理システム。
【請求項４】
上記ユニーク情報が、各分類属性よりも上位に位置する分類属性を連結させた経路情報であることを特徴とする請求項２に記載の分類データ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は分類データ管理システムに係り、特に、最上位から最下位に至る複数の階層構造を備えた分類データを効率的に管理可能な技術に関する。
【背景技術】
【０００２】
個々の生物の全体における位置付けや他の種との比較を容易にするため、門、綱、目、科、属などの階層構造を備えた分類属性を各生物に付与し、分類体系を図示することが、18世紀から現代まで広く行われてきている。
また、大企業グループや行政機構についても、「法人→事業本部→部→課」や「省→局→部→課→係」のように、上位階層から下位階層に向けて枝分かれする複雑な組織体系が形成されており、その組織図を概観することにより、組織全体における特定機関の位置付けや他の機関との関係性が一目で理解できるように工夫されている。
あるいは、多数の製品を製造するメーカも、「電機→民生品→AV機器→一般向け→DVD→型番」のように、自社の製品を様々な観点から複数のレベルに整理・分類している。この結果ユーザは、当該メーカのWebサイトにおいて上記の階層を辿ることにより、目的の商品やその関連商品を効率的に探し出すことができ、サポート情報等を入手することが可能となる。
【非特許文献１】分類体系のお話インターネットURL:http://umiushi.zapto.org/Jpn/Class/Class.html検索日：平成１９年７月２日
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このような階層化された分類体系情報をコンピュータのデータベースで管理する場合、一つの方法としては、最上位から最下位に亘る複数の分類項目を備えたレコードをテーブルに格納することによって実現される。
図１２はその一例を示すものであり、企業グループの年度毎の組織体系を格納したテーブルである。このテーブルには、年度、法人、事業部、部、課の分類項目を備えたレコードが多数登録されている。また、図３は、この企業グループの組織体系の一部を木構造で表現したものである。
【０００４】
この場合、例えばユーザの操作するクライアント端末から「2006」の年度選択情報を送信すると、サーバから2006年に存在したグループ企業の法人名リストが送信され、クライアント端末の画面に表示される。
これに対しユーザが甲社を選択すると、今度は2006年当時の甲社の事業部リストがクライアント端末の画面に表示される。
上記の操作を繰り返すことにより、ユーザは当該企業グループの各年度における組織体系を容易に認識することが可能となる。
【０００５】
しかしながら、このように分類パターン毎に上位〜下位の全ての分類項目を備えたレコードをテーブルに格納することによって階層構造を記録する従来の管理手法では、分類パターンのバリエーションが増加するのに比例して、上位分類項目におけるデータの重複が多く発生することとなる。図１２の場合には比較的単純な分類体系を例示したが、生物の分類体系や国際特許分類、国際商品分類のように、階層数及び最下位の分類項目数が共に膨大となるケースでは、重複データの存在が看過できないレベルに達する。
【０００６】
また、途中で分類の階層を増やす必要に迫られた場合、例えば「年度」と「法人」との間に「地域」を追加する場合には、「地域」のカラムをテーブルに追加することで対応することになるが、この際には当該データベースを利用しているアプリケーションプログラムについても対応の修正を施す必要が生じる。
【０００７】
階層化された分類体系情報をコンピュータのデータベースで管理する他の方法として、図示は省略したが、「年度−法人マスタ」、「法人−事業部マスタ」、「事業部−部マスタ」のように、相互に関連付けられた複数のテーブルに、細分化されたレコードを格納することもよく行われる。
この場合には、データの重複を低減することができる反面、分類体系の階層が増大するにつれてテーブル数が増大することとなり、その管理が煩雑化するという問題が生じる。
【０００８】
また、途中で分類の階層を増やす必要に迫られた場合、例えば「年度」と「法人」との間に「地域」を追加する場合には、「年度−地域マスタ」及び「地域−法人マスタ」を新設する必要が生じ、この際にはアプリケーションプログラムについても対応の修正を施す必要が生じる。
【０００９】
この発明は、従来の分類データ管理システムが抱えていた上記の問題を解決するために案出されたものであり、上位分類項目の重複をできるだけ低減できると共に、分類体系の階層を増やす場合もカラムの追加やテーブルの追加が不要であり、従って対応アプリケーションプログラムの修正も不要な分類データ管理技術の提供を目的としている。
【課題を解決するための手段】
【００１０】
上記の目的を達成するため、請求項１に記載した分類データ管理システムは、  分類体系を規定するレコードを格納した分類テーブルを備えたDBサーバと、このDBサーバにネットワークによって接続された複数のAPサーバとからなる分類体系情報管理システムであって、上記分類テーブルのレコードが、上位の分類属性が記述される親項目と、これに直結する下位の分類属性が記述される子項目を有しており、あるレコードの子項目に記述された分類属性が他の下位の分類属性に係るレコードの親項目の値として記述される再帰的な構造を備えると共に、分類体系を木構造で表現した際にROOTノードに直に繋がる最上位ノードとなる分類属性のレコードに関しては、その親項目の値としてROOTが設定されており、上記の各APサーバは、(1) 上記DBサーバにSQL文を発行し、上記分類テーブルに格納されたROOTを親項目の値とするレコードを取得する処理と、(2) 取得した各レコードの子項目の値を抽出し、最上位ノードの一覧を生成する処理と、(3) 上記DBサーバにSQL文を発行し、ROOTを親項目の値として含まないレコードを取得する処理と、(4) 取得したレコードの中で親項目の値が共通するレコード同士を集め、親項目の値を共通のキー部とし、それぞれの子項目の値をメンバー部として有するグループを生成する処理と、(5) 特定の最上位ノードをキー部とするグループを抽出すると共に、各グループを当該最上位ノードに継ぎ足す処理と、(6) 継ぎ足されたグループに属するメンバー部の値をキー部とするグループを抽出し、各グループを上記メンバー部の分類属性に継ぎ足す処理と、(7) 継ぎ足されたグループに属するメンバー部の値をキー部とするグループを抽出し、各グループを上記メンバー部の分類属性に継ぎ足す処理を、上記メンバー部の値をキー部とするグループが存在しなくなるまで繰り返して、一の最上位ノード配下の木構造をメモリ上に完成させる処理と、(8) 上記(5)〜(7)の処理を他の最上位ノードに関して繰り返すことにより、全ての最上位ノード配下の木構造をメモリ上に完成させる処理と、(9) メモリ上に生成された上記木構造の分類体系情報に記述された分類属性がフォルダ名またはファイル名として記述されると共に、各フォルダまたはファイルを上記木構造の分類体系の該当する階層位置に配したフォルダ−ファイル形式の分類体系情報を生成し、ハードディスク上に格納する処理と、(10) 特定の分類情報が入力された場合に、上記フォルダ−ファイル形式の分類体系情報の必要部分を木構造の分類体系情報としてメモリ上に復元すると共に、このメモリ上の分類体系情報を参照して、当該分類属性配下の分類属性を取得する処理と、(11) この分類属性を出力する処理を実行することを特徴としている。
上記の「出力」とは、例えばディスプレイに表示することや、プリンタを介してプリントアウトすること、あるいはサーバによって生成された画面をネットワーク経由でクライアント端末に送信することが該当する。
【００１３】
請求項２に記載した分類データ管理システムは、請求項１のシステムであって、さらに、上記レコードに格納された少なくとも一部の分類属性には一意性を確保するためのユニーク情報が付加されており、上記木構造の分類体系情報を生成する際に、このユニーク情報が削除されることを特徴としている。
【００１４】
請求項３に記載した分類データ管理システムは、請求項２のシステムであって、上記ユニーク情報が、相互に重複しない数値からなる連番であることを特徴としている。
【００１５】
請求項４に記載した分類データ管理システムは、請求項２のシステムであって、上記ユニーク情報が、各分類属性よりも上位に位置する分類属性を連結させた経路情報であることを特徴としている。
【発明の効果】
【００１６】
請求項１に記載した分類データ管理システムにあっては、DBサーバ側の分類テーブルに格納された各レコードが、上位レコードの子項目が次の階層のレコードの親項目となり、その子項目に下位の分類属性が記述されるという、いわゆる再帰的なデータ構造を備えているため、分類属性をフラットな表形式で規定する場合に比べ、データの重複を大幅に削減することが可能となる。また、システムの運用途中で分類体系の階層を増やす必要が生じた場合であっても、対応のレコードを追加等すれば済み、カラムを追加する必要がないため、システム変更の柔軟性が向上する。
またAPサーバ側でも、DBサーバから受け取ったレコードの中から親項目の値を共通にする複数のレコードを共通のキー部を備えたグループとなし、このグループ単位で上位の分類属性に継ぎ足す処理を繰り返す方式を採用することにより、再帰的なデータ構造を備えた分類テーブルから木構造の分類体系情報を効率的に生成することが可能となる。
さらに、分類体系情報がフォルダ−ファイル形式でハードディスクに格納されるため、比較的サイズの大きな分類体系情報であっても、必要な部分を個別にメモリに復元すれば済み、瞬間的にコンピュータのメモリを圧迫することを有効に回避できる利点がある。
【００１９】
請求項２〜４に記載した分類データ管理システムにあっては、レコードに格納された分類属性に対して、必要に応じて連番や経路情報のようなユニーク情報が付加される仕組みを備えているため、相互に重複する分類属性が複数存在したとしても相互間で一意性が担保される結果、分類属性の取り違えが生じることなく、正しい木構造の分類体系情報を生成可能となる。
【発明を実施するための最良の形態】
【００２０】
図１は、この発明に係る分類データ管理システム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は、DB管理システム（RDBMS）28と、分類テーブル30を備えている。
DB管理システム28は、分類テーブル30を管理し、同テーブルに格納されたデータの入出力、更新、および所定の演算などを行う。
【００２３】
ロードバランサ16は、クライアント端末20から送信されたリクエストを、各APサーバ12にかかっている負荷に応じて分散する役割を果たす。
【００２４】
クライアント端末20は、ＰＣ等のコンピュータよりなり、OSの他に、Webブラウザプログラム等のアプリケーションプログラムがセットアップされている。
【００２５】
図２は、分類テーブル30の構成例を示すものであり、親ID（親項目）及び子ID（子項目）の二つのデータ項目を備えたレコード36が多数登録されている。
この分類テーブル30は、階層構造を備えた分類体系を再帰的なデータ構造で規定するものである。
【００２６】
図３は、分類テーブル30に規定された分類体系を木構造で表現したものであり、ROOT（根）の直下に「2005」、「2006」、「2007」の年度が配置されている。また、各年度には「甲社」、「乙社」、「丙社」等の法人名が配置され、各法人名には「情報事業部」、「電機事業部」、「機械事業部」等の事業部名が配置されている。また、各事業部名には「開発部」、「情報営業部」等の部名が配置されている。さらに、各部名には、「ハード設計課」、「ソフト開発課」、「国内営業１課」、「国内営業２課」、「海外営業課」等の課名が配置されている。
この分類体系を参照することにより、例えば「ハード設計課」は、2006年度に甲社の情報事業部−開発部に属していたことが読み取れる。
【００２７】
従来の分類データ管理システムにあっては、図１１に示した通り、各レコードに年度、法人、事業部、部、課の分類項目を設けることによって、このような分類体系を表現していたのであるが、このシステム10の場合には、親ID及び子IDの２つのデータ項目を備えた分類テーブル30によって組織の分類体系を規定している。
【００２８】
まず、「親ID＝ROOT、子ID＝2005」、「親ID＝ROOT、子ID＝2006」、「親ID＝ROOT、子ID＝2007」の３つのレコード群Ａにより、ROOTに繋がる最上位の分類属性が「2005」、「2006」、「2007」の３つであることが規定されている。
【００２９】
また、「親ID＝2006、子ID＝101_甲社」、「親ID＝2006、子ID＝102_乙社」、「親ID＝2006、子ID＝103_丙社」のレコード群Ｂにより、2006に繋がる分類属性が「甲社」、「乙社」、「丙社」であることが規定されている。
【００３０】
甲社の前に付加された「101_」、乙社の前に付加された「102_」、丙社H003の前に付加された「103_」は、各ノード（分類属性）にユニーク性を付与する目的で、APサーバ12によって必要データに対し自動的に採番される連番である。
すなわち、甲社は2006年に限定されるものでなく、2005年あるいは2007年配下にも存在する可能性があるため、他の年度における甲社と区別するため、APサーバ12のデータ処理部22は、予め分類テーブル30に格納されたレコード36に対して、自動的にユニークな連番を付与しておく。
因みに、2005、2006、2007はROOTに繋がる最上位の分類属性であり、本来的にユニークであるため、自動連番付与の対象から外されている。
【００３１】
また、「親ID＝101_甲社、子ID＝104_情報事業部」、「親ID＝101_甲社、子ID＝105_電機事業部」、「親ID＝101_甲社、子ID＝106_機械事業部」のレコード群Ｃにより、甲社に繋がる下位の分類属性が「情報事業部」、「電機事業部」、「機械事業部」であることが規定されている。
ここでも、情報事業部の前に付加された「104_」、電機事業部の前に付加された「105_」、機械事業部の前に付加された「106_」は、各ノードにユニーク性を付与するためAPサーバ12によって各データに自動的に採番される連番を意味している。
【００３２】
また、「親ID＝104_情報事業部、子ID＝107_開発部」、「親ID＝104_情報事業部、子ID＝108_情報営業部」のレコード群Ｄにより、情報事業部に繋がる下位の分類属性が「開発部」と「情報営業部」であることが規定されている。
開発部の前に付加された「107_」及び情報営業部の前に付加された「108_」は、上記と同様、各ノードにユニーク性を付与するためAPサーバ12によって各データに自動的に採番される連番である。
【００３３】
また、「親ID＝107_開発部、子ID＝109_ハード設計課」、「親ID＝107_開発部、子ID＝110_ソフト開発課」のレコード群Ｅにより、開発部に繋がる下位の分類属性が「ハード設計課」と「ソフト開発課」であることが規定されている。
ハード設計課の前に付加された「109_」及びソフト開発課の前に付加された「110_」は、上記と同様、各ノードにユニーク性を付与するためAPサーバ12によって各データに自動的に採番される連番である。
【００３４】
さらに、「親ID＝108_情報営業部、子ID＝111_国内営業１課」、「親ID＝108_情報営業部、子ID＝112_国内営業２課」、「親ID＝108_情報営業部、子ID＝113_海外営業課」のレコード群Ｆにより、情報営業部に繋がる下位の分類属性が「国内営業１課」、「国内営業２課」、「海外営業課」であることが規定されている。
国内営業１課の前に付加された「111_」、国内営業２課の前に付加された「112_」、海外営業課の前に付加された「113_」は、上記と同様、各ノードにユニーク性を付与するためAPサーバ12によって各データに自動的に採番される連番である。
【００３５】
以下、図４のフローチャートに従い、APサーバ12による分類体系情報の生成に係る処理手順を説明する。
まず、APサーバ12のデータ処理部22は、DBサーバ14に対してSQL文を発行し、分類テーブル30に格納されたROOTノードを親とするレコード36を取得する（Ｓ10）。
つぎに、分類体系情報生成部24が上記レコード36の子の値を抽出し、ROOTノードに直に繋がる最上位ノードの一覧を生成する（Ｓ12）。具体的には、図５に示すように、「2005」、「2006」、「2007」が最上位ノードとして認定される。
【００３６】
つぎにデータ処理部22は、DBサーバ14に対してSQL文を発行し、ROOTノードを親としないレコード36を、分類テーブル30から最上位ノード単位で取得する（Ｓ14）。
【００３７】
つぎに分類体系情報生成部24は、共通の親を有するレコード36同士を集めてグループ38を生成する（Ｓ16）。このグループ38は、図６に示すように、共通の親をキー部とし、それぞれの子をメンバー部として有している。
【００３８】
つぎに分類体系情報生成部24は、各グループ38のキー部を参照し、親ノードの一覧を生成する（Ｓ18）。すなわち、何れかのキー部に登場するノードは親ノードと判定され、一度もキー部に登場しないノードは親ノードではないものとして一覧から排除される。この親ノード一覧は、後で各グループの子が他のグループの親に該当するか否かを判断する際に参照される。
【００３９】
つぎに分類体系情報生成部24は、最上位ノードの１つを選択した後（Ｓ20）、当該最上位ノードに下位のノードを継ぎ足して木構造を形成していく。ここでは「2005」配下の木構造が既に完成し、「2006」がつぎの処理対象として選択されたものとして説明を進める。
【００４０】
まず分類体系情報生成部24は、「2006」を親に持つグループを検索する（Ｓ22）。この結果、「甲社」、「乙社」、「丙社」をメンバー部に有する図６(a)のグループ38aが抽出される。
【００４１】
つぎに分類体系情報生成部24は、Ｓ18で生成した親ノード一覧を参照し、同グループのメンバー部が他のグループの親であるか否かを判定する（Ｓ24）。
この場合、「甲社」等は「情報事業部」等をメンバー部とする下位グループ38bにおいて親となっているため、YESの判定結果が得られる。
この結果、分類体系情報生成部24は、図６(a)のグループ38aを枝として上記2006のTreeに継ぎ足す（Ｓ26）。この際、各データに付与されていた連番が、分類体系情報生成部24によって削除される（以下同様）。
【００４２】
つぎに分類体系情報生成部24は、このグループに属する子ノードの１つである「甲社」を選択した後（Ｓ28）、この「甲社」を親とするグループを検索する（Ｓ30）。この結果、図６(b)のグループ38bが抽出される。
【００４３】
つぎに分類体系情報生成部24は、Ｓ18で生成した親ノード一覧を参照し、同グループのメンバー部が他のグループの親であるか否かを判定する（Ｓ32）。
この場合、「情報事業部」等は「開発部」等をメンバー部とする下位グループ38cにおいて親となっているため、YESの判定結果が得られる。
この結果、分類体系情報生成部24は、図６(b)のグループ38bを枝として上記2006のTreeに継ぎ足す（Ｓ34）。
【００４４】
つぎに分類体系情報生成部24は、このグループに属する子ノードの１つである「情報事業部」を選択した後（Ｓ36）、この「情報事業部」を親とするグループを検索する（Ｓ38）。この結果、図６(c)のグループ38cが抽出される。
【００４５】
つぎに分類体系情報生成部24は、Ｓ18で生成した親ノード一覧を参照し、同グループのメンバー部が他のグループの親であるか否かを判定する（Ｓ40）。
この場合、「開発部」等は「ハード設計課」等をメンバー部とする下位グループにおいて親となっているため、YESの判定結果が得られる。
この結果、分類体系情報生成部24は、図６(c)のグループ38cを枝として上記2006のTreeに継ぎ足す（Ｓ42）。
【００４６】
つぎに分類体系情報生成部24は、このグループに属する子ノードの１つである「開発部」を選択した後（Ｓ44）、この「開発部」を親とするグループを検索する（Ｓ46）。この結果、図６(d)のグループ38dが抽出される。
【００４７】
つぎに分類体系情報生成部24は、Ｓ18で生成した親ノード一覧を参照し、当該グループのメンバー部が他のグループの親であるか否かを判定する（Ｓ48）。
この場合、「開発部」のメンバー部である「ハード設計課」及び「ソフト開発課」は他の何れのグループでも親となっていないため、NOの判定結果が得られる。
この結果、分類体系情報生成部24は当該グループ38dを葉としてTreeに追加する（Ｓ50）。
【００４８】
このようにして、「2006-甲社-情報事業部-開発部-ハード設計課」及び「2006-甲社-情報事業部-開発部-ソフト開発課」のライン（分類パターン）が完了した後、分類体系情報生成部24はＳ44〜Ｓ50の処理を繰り返し、「情報営業部」をキー部とするグループを葉としてTreeに追加することにより、「2006-甲社-情報事業部-情報営業部-国内営業１課」、「2006-甲社-情報事業部-情報営業部-国内営業２課」及び「2006-甲社-情報事業部-情報営業部-海外営業課」のライン（分類パターン）を完成させる（図３参照）。
【００４９】
その後、分類体系情報生成部24は、「乙社」以下及び「丙社」以下についてもＳ28〜Ｓ50の処理を繰り返し、「2006」配下のTreeを完成させる。
そして、「2006」を最上位ノードとするTreeが完成した後、分類体系情報生成部24は「2007」を最上位ノードとするTreeの生成に着手する。
【００５０】
なお、上記のＳ24、Ｓ32及びＳ40においてNoと判定された場合（グループの子が他のグループの親でない場合）、分類体系情報生成部24は該当グループを葉としてTreeに追加すると共に、階層の深化を停止して次の枝または葉の追加処理に移行する。
【００５１】
また、上記のＳ48においてYesと判定された場合（グループの子が他のグループの親である場合）、分類体系情報生成部24は該当グループを枝としてTreeに追加すると共に、つぎの階層の構築に移行する。
【００５２】
このように、あるグループ38の子が他のグループ38の親であるか親でないかを分類体系情報生成部24が判定し、その結果に応じてTreeに枝として追加するか葉として追加するかを切り替える方式を採用することにより、分類体系の階層が増減しても分類体系情報生成部24は正しく階層構造を再現することが可能となる。
【００５３】
以上のようにして、全ての最上位分類属性配下のTreeをメモリ26上に完成させた分類体系情報生成部24は、この木構造の分類体系情報に基づいて、フォルダ−ファイル形式の分類体系情報をハードディスク27上に生成する。
具体的には、図７に示すように、ハードディスク27の「ROOT」フォルダ44の配下に「2005」、「2006」、「2007」の年度フォルダ46を生成し、それぞれの配下に法人フォルダ48（「甲社」等）を生成する。
また、分類体系情報生成部24は、各法人フォルダ48の配下に事業部フォルダ50（「情報事業部」等）を生成する。
さらに、分類体系情報生成部24は、部に対応したファイル名（「開発部」等）のテキストファイル52を生成し、対応の事業部フォルダ50に格納する。
これらのテキストファイル52には、当該部に属する具体的な課名54（「ハード設計課」等が記述されている。
【００５４】
つぎに、図８のフローチャートに従い、このシステム10による分類体系情報の提示手順について説明する。
例えば、クライアント端末20から「2006」年度を指定した分類体系情報の表示リクエストをAPサーバ12が受信すると（Ｓ60）、データ処理部22はハードディスク27上に形成されたフォルダ−ファイル形式の分類体系情報42を参照し、「2006」直下の「甲社」、「乙社」、「丙社」の分類属性を取得する（Ｓ62）。
つぎにデータ処理部22は、「甲社」、「乙社」、「丙社」の分類属性を選択肢として列記したWebページを生成し、クライアント端末20に送信する（Ｓ64）。
【００５５】
上記Ｓ60〜Ｓ64の処理を繰り返すことにより、データ処理部22はユーザに対してより下位レベルの分類体系情報を段階的に提供していく。
すなわち、クライアント端末20から「甲社」の選択情報が送信されると、データ処理部22は分類体系情報42を参照し、「情報事業部」、「電機事業部」、「機械事業部」の選択肢が記述されたWebページをクライアント端末20に返す。
つぎに、クライアント端末20から「情報事業部」の選択情報が送信されると、データ処理部22は分類体系情報42を参照し、「開発部」、「情報営業部」の選択肢が記述されたWebページをクライアント端末20に返す。
これに対し、クライアント端末20から「開発部」の選択情報が送信されると、データ処理部22は分類体系情報42を参照し、「ハード設計課」及び「ソフト開発課」が記述されたWebページをクライアント端末20に返す。
【００５６】
以上の一連の操作を通じて、ユーザは2006年度における甲社の組織体系について網羅的に認識することが可能となる。
もちろん、上記のようにユーザに分類体系の階層を一段一段辿らせて最終的な課のレベルまで導く代わりに、ユーザが甲社を選択した時点でデータ処理部22が同社の全組織体系が記述されたWebページを生成し、クライアント端末20に返信するように運用することもできる。
【００５７】
このシステム10にあっては、分類パターン毎に年度、法人、事業部、部、課といった分類項目を備えたレコードを登録する従来の方式と異なり、上位の子項目が次の階層の親項目となり、下位の分類属性を子項目として指定する（関連付ける）という再帰的な構造によって分類体系を表現しているため、上位分類項目におけるデータの重複を大幅に削減することが可能となる。
例えば、図１２の従来方式で分類体系を記録する場合、「2006」という年度データは2006年に係る全レコード数分だけ記述する必要があるが、図２の再帰的な構造を備えた分類テーブル30で記録した場合、「2006」のデータは下位の分類属性である法人の数＋ROOTの子としての１回分だけ記述すれば済むこととなる。
【００５８】
また、システム10の運用途中で分類の階層を増やす必要が生じた場合であっても、分類テーブル30に対するレコードの追加・削除だけで済む利点がある。
例えば、図９に示すように、「2006」の年度分類と「甲社」、「乙社」、「丙社」の法人分類との間に、「東日本」及び「西日本」の地域分類を後から挿入する場合であっても、図１０に示すように、「2006／101_甲社」、「2006／102_乙社」、「2006／103_丙社」のレコードからなるレコード群Ｂを削除すると共に、「2006／301_東日本」、「2006／302_西日本」からなるレコード群Ｇと、「301_東日本／101_甲社」、「301_東日本／102_乙社」、「302_西日本／103_丙社」からなるレコード群Ｈを追加するだけで済む。
【００５９】
分類体系の最下層に分類属性を追加する場合（例えば、「課」の下位分類として「係」を追加する場合）には、図示は省略したが、「109_ハード設計課／401_技術情報収集係」、「109_ハード設計課／402_特許係」のように、親項目にこれまでの最下層の分類属性を記述し、子項目に新たな階層を形成する分類属性を記述したレコードを分類テーブル30に追加すればよい。
【００６０】
このように、分類体系の階層を増やすに際してカラムを分類テーブル30に追加する必要がないため、アプリケーションプログラム側に大きな修正を施す必要がなくなり、システム改変の柔軟性が向上する。
【００６１】
なお、新しいレコード36を分類テーブル30に加える際、APサーバ12のデータ処理部22は分類テーブル30を参照して最終の連番を確認し、これよりも後の連番（必ずしも直後の連番である必要はなく、一定の間隔が空いてもよい）を必要なデータに対し自動的に付与する。
【００６２】
あるいは、連番管理用のテーブルをDBサーバ14内に設けておき、新たに連番を付与するに際してはAPサーバ12がこれを参照し、最終の連番＋１の値をレコード36に付加するように構成してもよい。この場合、APサーバ12はこの最新の連番によって上記連番管理用テーブルの最終値を更新する。
【００６３】
上記のように、一旦メモリ26上に構築した木構造の分類体系情報を、フォルダ−ファイル形式の分類体系情報に変換してハードディスク27に格納した結果、比較的サイズの大きな分類体系情報であっても、必要な部分を個別にメモリに復元すれば済むため、瞬間的にAPサーバ12のメモリ26を圧迫することを有効に回避できる利点があるが、分類属性の数（レコード36の件数）が比較的少ない場合には、メモリ26上に生成された木構造の分類体系情報をそのままデータ処理部22が参照するように構成してもよい。
【００６４】
図１１は、分類テーブル30の他の構成例を示すものであり、各ノード（分類属性）のユニーク性を担保するために「101_」や「102_」といった連番を自動的に付与する代わりに、必要なデータに対し上位ノードの経路（パス）情報がAPサーバ12のデータ処理部22によって付与される点に特徴を有している。
【００６５】
例えば「2006_甲社」のように、「甲社」の前に「2006_」を付与することにより、2006配下の甲社であることが明確となり、2005配下の甲社や2007配下の甲社と識別可能となる。
また、「2006甲社_情報事業部」のように、「情報事業部」の前に「2006甲社_」を付与することにより、2006×甲社配下の情報事業部であることが明確となり、仮に2006×乙社配下に情報事業部が存在したとしても、両者を識別可能となる。
【００６６】
この経路情報は、上記連番付与方式の分類テーブル30による場合と同様、メモリ26上に木構造の分類体系情報が生成されるタイミングで、分類体系情報生成部24によって削除される。
また、システムの運用途中で分類体系に変更を加える必要が生じ、分類テーブル30に対するレコード36の追加及び削除がなされた際には、APサーバ12のデータ処理部22によって変更箇所配下に位置する各データの経路情報の書き替えが実行される。
【００６７】
なお、分類属性相互間で同じ値が重複する可能性がない場合には、上記のように連番や経路情報をレコード36の分類属性に付加する必要がないことは言うまでもない。
【図面の簡単な説明】
【００６８】
【図１】この発明に係る分類データ管理システムの全体構成図である。
【図２】分類テーブルの構成例を示す図である。
【図３】分類テーブルに規定された分類体系を木構造で表現した図である。
【図４】分類体系情報の生成手順を示すフローチャートである。
【図５】木構造の分類体系情報を生成する過程を示す図である。
【図６】グループの生成過程を示す図である。
【図７】フォルダ−ファイル形式の分類体系情報を示す図である。
【図８】分類体系情報の提示手順を示すフローチャートである。
【図９】木構造で表現された分類体系に新たな階層を追加する例を示す図である。
【図１０】分類テーブルに対しレコードの追加及び削除を行う例を示す図である。
【図１１】分類テーブルの他の構成例を示す図である。
【図１２】従来の分類データ管理システムにおける分類テーブルの構成例を示す図である。
【符号の説明】
【００６９】
10 分類データ管理システム
12 APサーバ
14 DBサーバ
16 ロードバランサ
18 イントラネット
20 クライアント端末
22 データ処理部
24 分類体系情報生成部
26 メモリ
27 ハードディスク
28 DB管理システム
30 分類テーブル
36 レコード
38 グループ
42 フォルダ−ファイル形式の分類体系情報
44 ルートフォルダ
46 年度フォルダ
48 法人フォルダ
50 事業部フォルダ
52 テキストファイル
54 課名
【図１】
0005058729.tif 000002
【図２】
0005058729.tif 000003
【図３】
0005058729.tif 000004
【図４】
0005058729.tif 000005
【図５】
0005058729.tif 000006
【図６】
0005058729.tif 000007
【図７】
0005058729.tif 000008
【図８】
0005058729.tif 000009
【図９】
0005058729.tif 000010
【図１０】
0005058729.tif 000011
【図１１】
0005058729.tif 000012
【図１２】
0005058729.tif 000013