JP2004177996A - 階層型データベース装置及び階層型データベースの構築方法 - Google Patents

Abstract

【課題】階層型データベースの分類に関連付けて典型属性を設定することのできる階層型データベース装置を提供すること
【解決手段】下位の分類が上位の分類の属性を継承する階層構造を持つ階層型データベース装置において、第１の分類が有する少なくとも１つの属性を典型属性に設定し、各典型属性に対する検索条件を含む付帯情報を、一の操作で選択可能な第１の典型属性セットに設定する手段と、前記第１の分類よりも下位の分類が前記第１の典型属性セットを継承する手段と、前記下位の分類に対してさらに下位の分類に継承させる第２の典型属性セットを、前記第１の典型属性セットの少なくとも一部を用いて設定する手段とを具備する
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、分類（クラス）のもつ属性が継承される階層型データベースにおいて典型属性を設定できるものに関する。
【０００２】
【従来の技術】
マイクロソフト社（商標）のオペレーティング・システム（ＯＳ）Ｗｉｎｄｏｗｓ（商標）や、その他ＵＮＩＸ（商標）、ＬＩＮＵＸ（商標）といった汎用ＯＳにおいては、ツリー状のディレクトリー構造やファイル構造をユーザに視覚的に明示し、ユーザを特定のディレクトリーやファイルへ誘導・移動（ナビゲート）するためのグラフィック・ユーザ・インタフェース（ＧＵＩ）としてツリー表示が採用されている。
【０００３】
しかしながら、このツリー表示の各ノード間においては、上位のノードに含まれる情報（ファイル等）と下位のノードに含まれる情報との間には継承関係あるいは包含ないし部分集合関係等の関係はなく、ルート・ノードから始まるツリー上のノードは、ファイルなどの情報を納める入れ物、つまりコンテナーがツリー状に上下に接続されていることを表わしているにすぎない。この種の構造のことを、本明細書では「階層型ファイル構造」と呼び区別する。
【０００４】
オブジェクト指向データベース（ＯＯＤＢ）や関係データベース（ＲＤＢ）の部分改良型として登場したオブジェクト・リレーショナルデータベース（ＯＲＤＢ）を代表とするデータベースは、階層構造を有し、該階層構造において下位分類が上位分類の属性を継承する仕組みを有する。このようなデータベースでは、継承によって下位の分類では属性が累増するという特徴がある。下位分類が上位分類の属性を継承することは、「インヘリタンス」とも呼ばれ、このような技術は多くの文献に記載されている（例えば下記非特許文献１参照。）。なお、オブジェクト指向データベース（ＯＯＤＢ）関連の技術分野では、階層中の分類を「クラス」と呼ぶことが多い。本明細書では、「分類」と「クラス」とをほぼ同じ意味を有する用語として用いる。
【０００５】
また、オブジェクト・リレーショナル型データベース（ＯＲＤＢ）においては、継承を許したテーブルがクラスに相当する。上下関係にあるテーブル間においては、上位のテーブルから下位のテーブルへ属性が継承される。ここでの属性は、ＯＲＤＢにおいては上位テーブルを構成するコラムのヘッダー情報に相当し、これが下位テーブルへ継承される。
【０００６】
本明細書においては、オブジェクト指向データベース（ＯＯＤＢ）とオブジェクト・リレーショナルデータベース（ＯＲＤＢ）の両者を含めて「階層型データベース」と称する。また、各階層のクラスに属する同じ属性種を持つデータを「インスタンス」と呼び、その集合をデータの「ポピュレーション」と呼ぶ。
【０００７】
ポピュレーションの実装方法は様々であるが、例えばＯＲＤＢでは１つの分類について、１つまたは複数のテーブルとして実装される。複数のテーブルとして実装された場合には、テーブル間の集合演算およびＪＯＩＮによりポピュレーション全体が表現されることがある。
【０００８】
ＩＳＯ１３５８４ Ｐａｒｔｓ Ｌｉｂｒａｒｙ規格（通称、”ＰＬＩＢ”「ピーリブ」）は、複数の”Ｐａｒｔ”（通常、「分冊」と訳される）からなる製品あるいは部品ライブラリデータに関するオブジェクト指向的な記述の方法とその交換ファイル形式のセマンティックス、すなわち、どのような用語や記述方式およびデータ型を用いるかを定める国際規格である。また、ＩＳＯ１３５８４ Ｐａｒｔｓ Ｌｉｂｒａｒｙ規格のＰａｒｔ４２（分冊第４２）はＩＥＣ６１３６０−２（分冊第２）と内容が共通している。この規格は、オブジェクト指向的に製品を分類し、個々の分類を特徴付ける属性群を明らかにし、分類に対するコンテンツをファイル交換する仕組みであるので、勿論、属性の継承の概念はこの中に含まれている。また、この規格はＩＳＯ６５２３“Ｓｔｒｕｃｔｕｒｅ ｆｏｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｏｆ ｏｒｇａｎｉｚａｔｉｏｎｓ ａｎｄ ｏｒｇａｎｉｚａｔｉｏｎ ｐａｒｔｓ”を引用して作られており、特に、ＩＳＯ６５２３の定めるＩＣＤ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｄｅ Ｄｅｓｉｇｎａｔｏｒ）を活用して属性に対して世界的に一意な識別子を割り振ることが可能である。
【０００９】
【非特許文献１】
Ｏｂｊｅｃｔ−Ｏｒｉｅｎｔｅｄ Ｃｏｎｃｅｐｔｓ， Ｄａｔａｂａｓｅｓ， ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ， Ｅｄｉｔｅｄ ｂｙ Ｗｏｎ Ｋｉｍ， １９８９， ＡＣＭ Ｐｒｅｓｓ
【００１０】
【発明が解決しようとする課題】
オブジェクト指向データベースを代表とする下位が上位分類の属性を継承する階層構造を持つデータベースにおいては、属性の継承に従って下位の分類では属性が累増する構造を持つ。このため一般的なユーザが頻繁に選択に用いるその分類を代表する（典型的）属性と、それ以外の付帯的な属性、もしくは極限られた用途まはたユーザグループにのみ必要となる属性の区別が難しく、工業製品の製造仕様データベースでは属性数が数百におよぶことも稀ではない。
【００１１】
したがって、製品の選択の際に属性種が数十を超える場合には、ユーザはどの属性に着目してインスタンスを選択すればよいのか、あるいはどの属性に関する情報がそのクラスにおいて、しばしば要求される典型的な情報であるかが一目瞭然ではない。例えば、工業製品の製造仕様データベースの場合には、属性がカテゴリー分けされていない場合には、属性数が多すぎるために簡単に個々の製品インスタンスの特徴を把握し、インスタンスを属性値により絞り込んで選択することが困難となる。このため、属性種をカテゴリーに分類することがしばしば行われる。
【００１２】
しかしながら、従来、そのカテゴリーの設定は分類（クラス）とは関係なく行われる（例えばＩＥＣ−６１３６０−２およびＩＳＯ１３５８４−４２においては、ＩＳＯ−３１に基づく属性のカテゴリー分けを記述する）か、あるいは、分類毎に設定される場合でも単純に前述の階層構造を持つデータベースそのものが持つ継承機構に依存して継承され、この継承機構に対して独立にかつ選択的に継承することができなかった。
【００１３】
したがって、階層型データベースの分類に関連付けて典型属性を設定するための新たな概念が必要とされており、さらには、典型属性を保存するデータベースの構造、および典型属性に対する検索条件を保存する仕組み、さらには検索条件に合致するインスタンスをユーザに提示する仕組みが求められている。しかしながら、これらの事項はＩＳＯ１３５８４規格やＩＥＣ６１３６０規格およびＩＳＯ６５２３のスコープからは外れており、これまでに提供されていない。
【００１４】
本発明はかかる事情を考慮してなされたものであり、階層型データベースの分類に関連付けて典型属性を設定することのできる階層型データベース装置を提供することを目的とする。
【００１５】
【課題を解決するための手段】
本発明に係る階層型データベース装置は、下位の分類が上位の分類の属性を継承する階層構造を持つ階層型データベース装置において、第１の分類が有する少なくとも１つの属性を典型属性に設定し、各典型属性に対する検索条件を含む付帯情報を、一の操作で選択可能な第１の典型属性セットに設定する手段と、前記第１の分類よりも下位の分類が前記第１の典型属性セットを継承する手段と、前記下位の分類に対してさらに下位の分類に継承させる第２の典型属性セットを、前記第１の典型属性セットの少なくとも一部を用いて設定する手段とを具備することを特徴とする。
【００１６】
本発明に係る階層型データベースの構築方法は、下位の分類が上位の分類の属性を継承する階層構造を持つ階層型データベースの構築方法において、第１の分類が有する少なくとも１つの属性を典型属性に設定し、各典型属性に対する検索条件を含む付帯情報を、一の操作で選択可能な第１の典型属性セットに設定するステップと、前記第１の分類よりも下位の分類が前記第１の典型属性セットを継承するステップと、前記下位の分類に対してさらに下位の分類に継承させる第２の典型属性セットを、前記第１の典型属性セットの少なくとも一部を用いて設定するステップと、を具備することを特徴とする。
【００１７】
【発明の実施の形態】
以下、図面を参照して本願発明の実施形態を説明する。
【００１８】
図１は、本発明に係る階層型データベース装置の一実施形態に係るシステムの概略構成を示すブロック図である。本システムは、インターネット６を介したウェブ（ＷＷＷ）ベースのシステムであり、ウェブ・クライアント５側とウェブ・サーバ７側とに構成要素を区分することができる。本発明に相当するのはウェブ・サーバ７側のシステムである。なお、このようなネットワーク通信を伴うクライアント・サーバ方式のみに本発明は限定されないことはいうまでもない。
【００１９】
ウェブ・クライアント５は、マウス１、キーボード２、ディスプレイ３、ＧＵＩ４を備え、汎用のコンピュータを用いて構成される。ウェブ・クライアント５はウェブサーバ７から受信したデータをＧＵＩ４を介してディスプレイ３に出力し、またＧＵＩ４を介してユーザよりキーボード２およびマウス１等のポインティング・デバイスからデータやコマンドを受取り、ウエブ・サーバ７へ送信する。
【００２０】
ウェブ・サーバ７は、ウェブ・クライアント５と同様にマウス９、キーボード１０、ディスプレイ１１、ＧＵＩ１２を備え、汎用のコンピュータを用いて構成することができる。さらに、ウェブ・サーバ７は、「辞書」と別称されるクラス分類とクラス分類を構成する属性のデータベース１６、「コンテンツ」と別称される個々のクラスの属性の値の組すなわちインスタンスのデータベース１５、クラス分類の典型属性のデータベース１７を備える。また、これらデータベース１５，１６，１７へのデータの入出力および検索の実行を管理するデータベース・マネージメント・システム８を備える。
【００２１】
典型属性のデータベース１７はキーボード１０からの入力により設定、構築することが可能であるが、これを簡単に初期設定するために、典型属性のデータベース１７とは別に、典型属性の設定用の外部ファイル１３もしくは典型属性設定テーブル１４を利用することができる。
【００２２】
辞書、すなわちクラス分類とクラス分類を構成する属性のデータベース１６には、クラス相互間についての情報が記録されており、１つのクラス分類を選んだときその上位分類クラス（スーパークラス）とその下位分類クラスが分かるようになっている。また、この辞書データベース１６にはクラス分類に所属する属性に関する情報が記録されており、１つのクラス分類を選んだときそのクラスに付属する全ての属性に関する情報が分かるようになっている。
【００２３】
典型属性のデータベース１７には、各々のクラスに所属する典型属性に関する情報が記録されており、１つのクラス分類を選んだときそのクラスに付属する全ての典型属性の組およびその個々の組を構成する全ての属性が分かるようになっている。
【００２４】
本実施形態は、ある分類についてそれを代表するような属性を１組あるいは数組の典型属性にまとめ、この組を各階層が（負の継承を含めて）継承し、さらに個々の階層において典型属性に対する代表的な検索条件値も含め「ティピカル・プロパティセット」として１種のクラスとして纏めて継承するようにし、このティピカル・プロパティセットへの追加や削除、あるいは条件の変更を分類クラス単位で可能にするものである。また、この組に対応するＧＵＩ上の要素、例えばボタン等をユーザが選択することで、ティピカル・プロパティセットの１つに属する属性に関する情報や検索値入力欄を表示させ、分類中のインスタンス・データ選択の容易化を狙っている。
【００２５】
クラスの典型属性とその検索条件を合わせてなるティピカル・プロパティセットには、検索条件の他に使用例、入力例、補足説明などの付帯的な情報を含むことができるものとする。このうち、検索条件のみを「クエリー・コンディションセット」と呼ぶ。なお、このティピカル・プロパティセットの概念は関係データベース（ＲＤＢ）における検索の主キー（プライマリー・キー）あるいは索引（ＩＮＤＥＸ）の概念とは異なり、これらと独立である。また同じ組に属する属性間に配置・表示順の指定がないならば、すなわち典型属性の組に属するということのみでは、特定の表示または継承上の順番は与えられない。また個々のプロパティセットは独立である、つまり１つの属性が複数のティピカル・プロパティセットに出現することがあり得る。
【００２６】
図２は、本実施形態の階層型データベースにおけるクラス分類と属性と典型属性および検索条件の関係、すなわち、クラス分類間の関係、クラス分類と属性の関係、クラス分類と典型属性の関係、および典型属性と検索条件の関係を表現する構造を模式的に示したものである。すなわち、全体のクラス分類の頂点であるルートクラス以外において常に上位クラス分類を辿ることが可能であり、クラス分類は上位クラス分類より上位クラス分類の持つ属性、典型属性の組、すなわちその属性の１つまたは複数個からなる属性のグループ、およびその典型属性の組に対応する検索条件を継承する。従って、本実施形態においては典型属性の組に対応する検索条件そのものも１つのクラスをなすとみなすことができる。
【００２７】
＜検索条件の継承＞
本実施形態では、上述のように属性の継承のみならず検索条件の継承をも可能にする。すなわち、ある特定分類の検索に使うような代表的な典型属性に関しては、その属性値に対する検索条件や検索条件の範例も典型的であり、下位の分類においては上位の分類の代表的な属性群に対する検索条件値を継承して使用可能な場合が多い。しかしながら、従来の階層型データベースでは、このような検索条件はあくまでもユーザが代入すべきものであり、属性のように継承されるものではなく、これをディフォルトの検索条件として下位クラスへ継承する仕組みを持っていなかった。
【００２８】
さらにこの代表的な属性の組とそれに対する検索条件、およびそれを設定した個々のユーザの識別子あるいはそのユーザの所属するグループの識別子を関係付け、これを保存しておいて、後に再度ユーザもしくはその所属するグループの何れかのユーザが、その分類についてインスタンスを検索しようとする際に、ユーザもしくはその所属するグループの保有する識別子に対応する適切な典型属性もしくは典型属性と検索条件の組をユーザに提示する仕組みを備えたものは無かった。この検索条件の継承は、オブジェクト指向プログラミング言語で普通に提供されるメモリ上の異種のデータ型の変数の集約化およびカプセル化をあらわすＣ＋＋言語やＪａｖａ言語の「クラス」の属性の継承およびその初期化とは異なり、データベースとしての検索条件に関わるもので異なる概念である。
【００２９】
＜負の継承＞
本実施形態は、新たな下位分類（サブクラス）を設けたとき、この下位分類へ係る典型属性について負の継承を行うことにより、この属性を消失させることによる効果を狙っている。
【００３０】
オブジェクト指向データベースを代表とする下位が上位分類の属性を継承する階層構造を持つデータベースにおいては、継承に従って下位の分類では属性が累増する構造を持つ。ところが、実際の製品や生物の分類においては、技術の発展にともない、あるいは生物の進化にともない、ある階層を起源としてそれ以降、その階層以前（上位）の分類において上位にあった特徴や性質が消失することがあり、これを従来のオブジェクト指向データベースの概念および階層型データベースでは適切に表現することができなかった。
【００３１】
例えば、従来の家庭用電気掃除機には電源ケーブルがあり、常に電源と掃除機は常時電源ケーブルで結ばれていた。しかし最近では操作性の向上のために電源ケーブルが消失し蓄電池から供給される電気を動力に変えてモータを駆動する掃除機が存在する。また家庭用のアイロンにおいても、現在は電源とアイロンのホルダー間に電源ケーブルはあるが、実際に衣類に当てる本体には電源ケーブルのない蓄熱型のものが存在する。これらは電気掃除機の発展形として分類されるものであるが、従来の電気掃除機やアイロンでは電源ケーブルの存在は必要不可欠と思われていたために、上位分類となる電気掃除機やアイロンの分類において電源ケーブルという属性が生じるのが普通である。
【００３２】
また自動車には、その燃料として使用するものがガソリンであれディーゼル油であれある種の内燃エンジン（ｃｏｍｂｕｓｔｉｏｎ ｅｎｇｉｎｅ）を必要とするが、環境に配慮した最近の電気自動車には内燃エンジンが存在しない。この時、例えば自動車に固有の属性とされる「内燃エンジン種類」を除去し、下位の分類例えばセダン等で改めて「エンジン種類」として設けるならば、問題を可避できるが、種類を問わず多くのデータベースにおいては、一度分類に固有の属性が定義されると、その属性に従ってインスタンス・データが入力され蓄積されるため、事後に分類から属性を削除することはデータベースの管理上大きな問題を引き起こすことが多い。
【００３３】
本実施形態では、典型属性について、上記の新しい属性の継承の仕組、すなわち負の継承、を取り込めるように設定を行えるよう構成される。すなわち、属性の消失を意味する負の属性については、その分類においてその負の属性が典型属性に組み入れられたということは、それより下位の分類の該当する典型属性の組においては、実際に効果を持つ属性としては継承されない、あるいは、存在しても効果を持つものとして扱われないという特殊性を持つ。
【００３４】
図３は、複数のユーザの各々に典型属性組および検索条件（クエリー・コンディションセット）が対応付けられている場合を示す図である。
【００３５】
本実施形態では、ユーザＡ，Ｂ，Ｃに対し３つの典型属性の組Ａ、Ｂ、Ｃが対応付けられている。これら典型属性の組Ａ、Ｂ、Ｃは上位の分類クラス１から継承したものである。図３において、属性および検索条件を示す楕円のうちドットで塗りつぶされたものが上位の分類クラス１から分類クラス２へ継承される典型属性およびその検索条件である。ユーザもしくはユーザの所属するグループの識別子とこのティピカル・プロパティセットを関連付け、ユーザがユーザ識別子もしくはユーザの所属するグループの識別子に応じて、表示選択できるティピカル・プロパティセットを限定する。
【００３６】
＜電子メール通知＞
このティピカル・プロパティセットとユーザあるいはユーザの所属するグループを関連付ける情報の中に、電子メールアドレスあるいは郵便のあて先を加え、ティピカル・プロパティセット中に記載された検索条件に合致するインスタンスが新たに登録された場合に、電子メールアドレスを利用して登録されたユーザもしくはユーザグループに属する全てのユーザへ自動的に電子メールで通知する、あるいは郵便にて通知することができる。
【００３７】
ユーザがデータベースの検索時にユーザの望む条件に合致するインスタンスが見つからず、事後に、条件を満たすインスタンスが、ユーザが検索対処とした分類クラス、あるいはその下位分類クラス（サブクラス）において登録されることがある。本実施形態では、ユーザ毎に検索条件を登録することにより、新たにインスタンスが登録された際に、既存のユーザの検索条件をこれらのインスタンスに適用することにより条件に合致するものの有無を調べ、合致するものがあった場合にはその旨を登録されたユーザに通知することにより、この問題を解決する。このような条件を満たすインスタンスを必要とするのは人間のユーザに限らず、他のデータベースやアプリケーション等のソフトウェアである場合もある。
【００３８】
データベースあるいはアプリケーションをユーザとして、特定の電子メールアドレスをデータベースに設定することにより、随時条件を満たす新たなインスタンス・データが情報提供者により登録された場合には、その旨の通知を電子メールで受信することにより、随時インスタンスを補充できるようにする。
【００３９】
図４においてはテーブルを利用して、図３に示す分類クラス２に対するユーザＡに「○△株式会社営業」というユーザグループ、Ｂに「Ｗｉｌｌｉａｍ Ｓｈａｋｅｓｐｅａｒ」、「Ｔｈｏｍａｓ Ｍａｎｎ」、「森鴎外」の３名の架空のユーザ、Ｃに「利用者Ｃ」１名の電子メールアドレスが関連付けられている。また図５は、図４の電子メールアドレスと典型属性の関連付けを図示したものである。
【００４０】
ティピカル・プロパティセット中に記載された検索条件に合致するインスタンスが新たに登録された場合にユーザへ通知する電子メールの中に、合致するインスタンスのＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ）を含めることにより、通知を受けたユーザをそのインスタンスの表示された画面へ直接誘導する。もともと多くの既存のアプリケーションにおいて、ＵＲＩはその文字列をクリックするだけでインターネットを介してＣＧＩやサーブレットを駆動し、そこに記載されたファイルの内容を呼び出したり、更にスクリプトまたはプログラムを駆動して情報をユーザのウェブブラウザに表示させることが可能になっている。
【００４１】
本実施形態では、ティピカル・プロパティセット中に記載された検索条件に合致するインスタンスが新たに登録された場合に通知するあて先に他のインタネットアドレス上に設置された他のデータベースやアプリケーションがプログラムより直接利用することのできる電子メールアドレスを含め、そこに電子メールを送付することによるか、もしくは、後者のデータベースが電子メールの内容を間接的にアクセスできる電子メールアドレスに電子メールを送付することにより、自動的に検索条件に合致するインスタンス・データの更新を通知し、さらに後者のデータベースやアプリケーションにおける自動的なデータの更新を実現する。
【００４２】
情報登録者がデータベース１５に新たなインスタンスを登録した際に、ティピカル・プロパティセット中に記載された検索条件に合致するインスタンスが存在した場合、そのインスタンスを提供した情報登録者にインスタンス中に属性値の一つとして与えられた、あるいはインスタンスに関連して別に用意された電子メールアドレス（例えばインスタンス中の属性の文字列値でＵＲＩを指定されたファイル中に記載された電子メールアドレス）を用いて電子メールで通知することにより、インスタンス情報のユーザと情報提供者のマッチングを行う。図６に情報登録者と情報利用者のマッチング（照合）のモデルを示す。なお、情報提供者側の電子メールアドレスを記述する属性そのものは、特に典型属性に含まれている必要はない。
【００４３】
なお階層型データベースの場合には上位で設けた属性が下位に継承されるため、上位の分類クラスで継承属性の一つとして、「情報提供者電子メールアドレス」に相当する属性を例えば文字列型として設けておけば、下位の分類クラスでもこの属性を持つことになる。従って、下位の分類クラスの各インスタンスはこの属性に対する電子メールアドレスの文字列値をそれぞれ持っていることになる。
【００４４】
特に「情報提供者電子メールアドレス」に相当する属性の識別子として、ＩＳＯ １３５８４ Ｐａｒｔｓ Ｌｉｂｒａｒｙ ＳｔａｎｄａｒｄのＰａｒｔ４２（第４２規格分冊）に定めるＢＳＵ（ＢａｓｉｃＳｅｍａｎｔｉｃ Ｕｎｉｔ）と呼ばれる標準コード記述の方法を用いる場合には、このコードがＩＳＯ ６５２３ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｄｅ Ｄｅｓｉｇｎａｔｏｒ（ＩＣＤ）を介して世界で一意になる構造を持っているため、情報提供者電子メールアドレスという属性に対して１つのＢＳＵ（すなわちこの場合はプロパティＢＳＵ、あるいはＰｒｏｐｅｒｔｙ＿ＢＳＵ）コードを割り振り、データベース・システムに対してそのコードを電子メール送信に用いるものとして認識させ、この辞書を標準辞書として公開することにより、本実施形態の階層型データベースを用いるならば、この辞書の定義を引用して作成される世界の全ての製品分類辞書に対するインスタンス・データに関して、電子メールによる情報利用者と情報提供者のマッチングのメカニズムが等しく有効になる。
【００４５】
＜リスト＞
本実施形態では、各分類より参照することのできるリストであって、その個々を識別子（名前またはコード）で区別することの可能なものを１つまたは複数用意する。リストの要素としては、その分類に設けられるティピカル・プロパティセットに属するプロパティ属性の識別子、その表示あるいは配置上の順番およびその検索条件の値を記述するものとする。このリスト構造は図３に対応している。このリストの保存の形態としては、ファイルではなく、例えば図７に示すように関係データベースのテーブルであっても良い。検索条件は属性に応じて存在する場合と存在しない場合がある。検索条件の中には、値を挟みこむ検索条件を記述することもできる。図８は、分類クラス２に関して図７のテーブルの記載する内容を纏めたものである。
【００４６】
表示あるいは配置上の順番については、リストを用いた場合にはリストに記載の順番をディフォールトの表示順番として用いることができるが、ディフォールトの状態としてはリスト中に記載の順番は特に表示あるいは配置上の順番を表すものとせず、別に属性に整数等を付記して表示あるいは配置上の順番を指定しても良い。図７の関係データベースのテーブルのそれぞれの行間には事前に決定された特定の順番は無いため、別に「描画順位」コラムにおいて、順番を表す整数型あるいは文字列型の列を設けることにより表示あるいは配置上の順番を表している。
【００４７】
このティピカル・プロパティセットのリストの初期設定の方法としては、図１に示した設定ファイル１３を参照することにより生成するか、またはハードディスク等の二次時記憶上に存在する典型属性設定用のデータベース１４より各分類に対する設定を読みこんで、それぞれの分類に対してティピカル・プロパティセットを決定すればよい。
【００４８】
この際、上位分類クラスに対する設定ファイルから生成され下位分類に継承される典型属性に関するティピカル・プロパティセットのリストの内容と、実際の下位分類クラスに対する設定ファイルの内容が異なることがある。この場合には、まず上位より継承される設定ファイルの内容を用いてティピカル・プロパティセットのリストの内容を仮決定し、次に下位分類クラスの設定ファイル中に定めるティピカル・プロパティセットのリストの内容を仮決めしたティピカル・プロパティセットのリストに加えるか、あるいは、上位と内容と下位の内容が異なる場合には、相当する上位の内容を下位の内容で上書きすればよい。もしくは、下位分類クラスに対する設定ファイルの内容でティピカル・プロパティセットのリストの内容を仮決めし、この設定ファイル中に記述されていない属性について、上位のティピカル・プロパティセットのリストの内容を引き写せばよい。この際、負の継承を示す典型属性については、予めその旨、例えば図７に示すようにテーブル中の「継承の正負」コラムにおいて “ＦＡＬＳＥ”とマークづけされているので、引写されなければよい。
【００４９】
この方式により、順次下位分類クラスにおいて上位のティピカル・プロパティセットより継承された内容の上書きが可能になる。
【００５０】
このようにして決定した、各ティピカル・プロパティセットに従ってティピカルプロパティの配置および表示順が決定される。このティピカル・プロパティセットのリストの内容については、最終的にハードディスク等の二次記憶装置またはファイル中に記載し格納することにより、毎回ユーザが用意する設定ファイルからティピカル・プロパティセットのリストの内容を決定する手間を省くことが可能になる。
【００５１】
図９は、配置・表示の順番が、属性名あるいは識別子の出現順番である場合の設定ファイルを用いたクラスに対するティピカルプロパティの設定の手順を示すフローチャートである。出現順番が数字で指定されている場合には、それを読み取って最初に出現順に並び替えることにより一般的に処理できる。まずステップＳ１において、設定ファイルから当該クラスについての典型属性、検索条件および付帯情報を読み込む。ステップＳ２において検索条件の有無を判断する。検索条件が有りの場合はステップＳ３において検索条件を典型属性リスト（ティピカル・プロパティセットのリスト）に書き込む。また、ステップＳ４において負の継承の有無を判断する。負の継承がある場合には、ステップＳ５において、負の属性を有する属性にマークを付与する。そして、ステップＳ６では、上位の分類クラスについて、負の継承を持つもの以外の他の属性に関する設定を現在の典型属性リストに加える。
【００５２】
＜マッチング＞
上述したように、条件を満たす新たなインスタンス・データが情報提供者により登録された場合には、随時、その旨の通知を検索条件の登録者のみではなく、インスタンス中の属性、あるいはその関連情報として記載された情報登録者の電子メールアドレスを認識し、そのアドレスへの電子メールを送信することにより、情報の利用者と提供者のマッチング（照合）を可能にする。
【００５３】
この電子メールアドレスを属性として認識する場合において、階層型データベースの辞書について特にＩＳＯ１３５８４に準拠した標準コード方式が用いられる場合にはＩＳＯ６５２３に基づき個々の情報コード体系の発行組織を一意に識別するＩＣＤと呼ばれる４桁の発行団体コードが、個々の情報コード体系中の企業・団体コードを修飾し、さらにこの企業・団体コードが企業・団体内で有効な個々の分類コード、属性コードを修飾するため、ＩＳＯ世界で一意に分類やそれに所属する属性を識別することが可能である。
【００５４】
またＩＳＯ１３５８４では、他の団体や企業の作った分類体系すなわち辞書を他の辞書中に部分的または全て引用（以下ではインポートと呼ぶ）して使う仕組みがあり、辞書中の上位分類でインポートした属性は下位分類へ継承される。
【００５５】
本実施形態においては、ある標準辞書、甲で定めた情報登録者の電子メールアドレスとして用いる属性の識別子（プロパティＢＳＵ）を一旦設定しシステムに認識させておくならば、別な分類体系を記述する辞書乙を使用する際にも、甲の辞書の電子メールアドレスの記述されている属性をかなり上位の分類において乙に輸入（インポート）することにより、その場限りの特殊で実装依存の属性の識別方法を用いることなく、また表面的な属性名称の異同に煩わされることなく、甲の標準コードを用いて電子メールアドレスの表記されている属性を特定することができる。
【００５６】
図１０は、条件に合うインスタンスの情報を利用者に通知し、情報利用者と情報提供者とのマッチングの手順を示すフローチャートである。この手順においては、まず新しいインスタンスが分類クラスに登録され、分類クラスが更新される（ステップＳ１）。次に、新しいインスタンスが登録された分類クラスを検知、特定する（ステップＳ２）。次に、登録された分類クラスに対し、電子メールアドレスが関連付けられたティピカル・プロパティセットの有無を判定する（ステップＳ３）。該ティピカル・プロパティセットが存在しない場合、インスタンスの新規登録を通知するあて先が無いから、処理を終了する。ステップＳ３において電子メールアドレスが関連付けられたティピカル・プロパティセット有りと判定された場合、新インスタンスが検知された分類に対するティピカル・プロパティセットを収集する（ステップＳ４）。次に新インスタンスのいずれかが収集されたティピカル・プロパティセットのクエリー・コンディションを満たすか判定する（ステップＳ５）。クエリー・コンディションを満たさない場合は処理を終了する。満たす場合はクエリー・コンディションセットに規定されている検索条件を満たすインスタンスの識別子又はこれに掲載された仕様情報を収集して保存する（ステップＳ６）。次に、条件を満たすティピカル・プロパティセットのクエリーコンディションに関連する電子メールアドレスを収集し、インスタンスの識別子又はこれに掲載された仕様情報を内容とする電子メールを作成する（ステップＳ７）。ステップＳ８において、作成された電子メールを、前記収集した電子メールアドレス宛てに発信（送信）する。さらに、情報提供者にこれを通知する場合（ステップＳ９）は、インスタンスの仕様情報の少なくとも一部またはそれに関連する情報として事前に設定された情報登録者の連絡先に、顧客（見込み客）の電子メールアドレスを含む引き合い情報を記載した電子メールを送信する。
【００５７】
図１１は、典型属性を１組持つ階層型データベースのＧＵＩの例を示す図である。すなわち、分類に付随して画面にティピカル・プロパティセットの１つが表示されている。図１１中で上方に「ＴＹＰＩＣＡＬ」と表示されたボタンをマウスでクリックすることにより、この分類クラス中の典型属性を全て一度に選択できるようになっている。図中では流量計に対する属性が示されており、これには百個以上の多数の属性があり、どれが典型属性であるかを判断しにくいが、「ＴＹＰＩＣＡＬ」ボタンによれば、典型属性を自動的に選択できるのでユーザの操作負担を軽減できる。
【００５８】
「ＴＹＰＩＣＡＬ」ボタンの下に表示されているのは、個々の属性の名称とその選択ボタンである。この分類クラスにおいて典型属性に設定されているものについては、正方形ボタンの表示色を異ならせるなどして他の属性と区別可能に表示することが好ましい。
【００５９】
図１２は、複数の典型属性の組を持つ階層型データベースのＧＵＩの例を示す図である。ここでは、典型属性の組が３つ設けられている。
【００６０】
図１３は典型属性設定ファイルの記述例を示す図である。これは、典型属性組を１組持つ場合に相当する。この典型属性設定ファイルには、分類および属性は全てＩＳＯ１３５８４（および一意性についてはＩＳＯ６５２３）で形式が規定されている情報の提供者に対する識別子分類に対する世界で一意となる識別子（Ｓｕｐｐｌｉｅｒ＿ＢＳＵ）Ｃｌａｓｓ ＢＳＵ）および属性に対する識別子（Ｐｒｏｐｅｅｒｔｙ ＢＳＵ）により記述されている。例えば図１３には、
ＳａｎｄＳ＿Ａｌｌ３．９９９９／ＩＥＣＲＯＯＴ．ＡＡＡ００１．ＡＡＥ７５２ ３００＜＝Ｖａｌｕｅ＜＝８００
ＳａｎｄＳ＿Ａｌｌ３．９９９９／ＩＥＣＲＯＯＴ．ＡＡＡ００１．ＪＣＩＥ００２ Ｖａｌｕｅ＝％ｔｏｓｈｉｂａ％
ＳａｎｄＳ＿Ａｌｌ３．９９９９／ＩＥＣＲＯＯＴ．ＡＡＡ００１．ＪＣＩＥ００３ ６＜＝Ｖａｌｕｅ
と記述されているが、このうち、ＳａｎｄＳ＿Ａｌｌ３．９９９９／ＩＥＣＲＯＯＴが情報の提供者を表わす識別子であり、ＡＡＡ００１が分類クラスの識別子であり、ＡＡＥ７５２、ＪＣＩＥ００２、ＪＣＩＥ００３はそれぞれ分類ＡＡＡ００１が持つ異なる３つの属性の識別子を表している。
【００６１】
また、「３００＜＝Ｖａｌｕｅ＜＝８００」は数値型の属性ＡＡＥ７５２に対する範囲を指定した検索条件の指定例である。同様に、「Ｖａｌｕｅ＝％ｔｏｓｈｉｂａ％」は、文字列型の属性ＪＣＩＥ００２に対する検索条件で、値として“ｔｏｓｈｉｂａ”を含む文字列を意味する。一方、「６＜＝Ｖａｌｕｅは、数値型の属性ＪＣＩＥ００３に対する値が６に等しいか大きいものを探すという、片方の範囲を指定した検索条件の指定の例である。
【００６２】
図１４、図１５は典型属性の組を一つだけ設けた例の異なるＧＵＩ例である。図１４は工業計器に対するプロパティセットの内容すなわち典型属性と検索条件を示し、図１５は工業計器の直下の下位文類クラスである流量計における典型属性組（プロパティセット）の内容を示している。また、図１６はこの２つのクラスに対する設定ファイルの例を示している。
【００６３】
図１５のリスト中に太字イタリックで示すように、工業計器においては、ＡＣ電源電圧（プロパティＢＳＵはＪＥＭＩＭＡ＿Ｐ００００１４）および企業名（プロパティＢＳＵはＸＪＥ０１１）が典型属性として定義され、ＡＣ電源電圧については、ＭＩＮ値が８０〜８５の間に納まるものを検索条件として設定している。また企業名については文字列で「東芝」を指定している。また、記述はこの分類クラスで新たに設けられる典型属性についてのみ与えている。そのため、ＡＣ電源電圧（同ＪＥＭＩＭＡ＿Ｐ００００１４）および企業名（同ＸＪＥ０１１）の描画順序は、工業計器の上位分類クラスである計測器から継承される全ての典型属性の末尾に加わるような記述になっている。ところが、工業計器の下位分類クラスである流量計では、工業計器より継承される属性全てに対して陽に描画順番を与えており、更に企業名の検索条件の指定を外し、ＡＣ電源電圧については、ＭＩＮ値が９０〜１００の間に納まるものを新たに検索条件として設定し直している。
【００６４】
図１４、図１５において表示されている典型属性の描画順序（位置）およびその検索条件を新ためて確認するならば、設定ファイルの内容が正しく典型属性および検索条件に設定されていることが分かる。
【００６５】
なお、本発明は上述した実施形態に限定されず種々変形して実施可能である。
【００６６】
【発明の効果】
以上説明したように、本発明によれば、階層型データベースの分類に関連付けて典型属性を設定することのできる階層型データベース装置を提供できる。
【図面の簡単な説明】
【図１】本発明に係る階層型データベース装置の一実施形態に係るシステムの概略構成を示すブロック図
【図２】分類（クラス）、属性、典型属性および検索条件（クエリー・コンディションセット）の関係を示す図
【図３】複数のユーザの各々に典型属性組および検索条件（クエリー・コンディションセット）が対応付けられている場合を示す図
【図４】典型属性と電子メールアドレスとを関連付けた例を示す図
【図５】電子メールアドレスと典型属性の組を結びつけた例を示す図
【図６】情報登録者と情報利用者の照合のモデルを示す図
【図７】典型属性を格納するテーブルの一例を示す図
【図８】分類クラス２に対する継承属性を含む各典型属性組に関連付けられた検索条件の例を示す図
【図９】クラスに対するティピカルプロパティの設定手順を示すフローチャート
【図１０】情報利用者と情報提供者とのマッチングの手順を示すフローチャート
【図１１】典型属性を１組持つ階層型データベースのＧＵＩの例を示す図
【図１２】複数の典型属性の組を持つ階層型データベースのＧＵＩの例を示す図
【図１３】典型属性設定ファイルの記述例を示す図
【図１４】上位分類クラス「工業計器」に対するプロパティセットの画面表示例を示す図
【図１５】下位分類クラス「流量計」に対するプロパティセットの画面表示例を示す図
【図１６】図１４、１５に対する典型属性の設定ファイルの例を示す図
【符号の説明】
１，９…マウス
２，１０…キーボード
３，１１…ディスプレイ
４，１２…ＧＵＩ（グラフィカル・ユーザ・インターフェース）
５…ウェブ・クライアント
６…インターネット
７…ウェブ・サーバ
８…データベース・マネージメント・システム
１３…典型属性設定ファイル
１４…典型属性設定テーブル
１５…インスタンスデータベース（コンテンツ）
１６…クラス分類と構成属性のデータベース（辞書）
１７…クラスとその構成典型属性のデータベース

Claims (11)

1. 下位の分類が上位の分類の属性を継承する階層構造を持つ階層型データベース装置において、
   第１の分類が有する少なくとも１つの属性を典型属性に設定し、各典型属性に対する検索条件を含む付帯情報を、一の操作で選択可能な第１の典型属性セットに設定する手段と、
   前記第１の分類よりも下位の分類が前記第１の典型属性セットを継承する手段と、
   前記下位の分類に対してさらに下位の分類に継承させる第２の典型属性セットを、前記第１の典型属性セットの少なくとも一部を用いて設定する手段と
   を具備することを特徴とする階層型データベース装置。
2. 前記典型属性のいずれかに負の継承を設定する手段をさらに具備することを特徴とする請求項１に記載の階層型データベース装置。
3. 前記第１の分類における前記典型属性の表示順序を設定する手段と、
   前記表示順序を前記下位の分類が継承する手段と、
   を具備することを特徴とする請求項１又は２に記載の階層型データベース装置。
4. 前記下位の分類が継承した前記表示順序が可変であることを特徴とする請求項３に記載の階層型データベース装置。
5. 前記第２の典型属性セットに、前記第１の典型属性セットから継承した典型属性の第１の組とは異なる典型属性の第２の組を追加する手段を具備し、
   前記下位の分類に対してさらに下位の分類において、前記第１の組と第２の組のいずれか一を選択可能となるように前記第２の典型属性セットを継承することを特徴とする請求項１乃至４のいずれかに記載の階層型データベース装置。
6. 階層型データベースにアクセスするユーザ又はユーザグループを登録する手段と、
   前記第１の典型属性セットに基づいて、前記ユーザ又はユーザグループの各々に固有の第３の典型属性セットを設定する手段を具備することを特徴とする請求項１に記載の階層型データベース装置。
7. 前記第３の典型属性セットに、前記ユーザ又はユーザグループの各々の電子メールアドレスを関連付ける手段と、
   前記第３の典型属性セットの付帯条件に含まれる検索条件を満足する新たなインスタンスの登録を検知する手段と、
   前記新たなインスタンスの登録検知を前記電子メールアドレスに基づいて前記ユーザ又はユーザグループに通知する手段と
   を具備することを特徴とする請求項６に記載の階層型データベース装置。
8. 前記新たなインスタンスのＵＲＩをさらに通知することを特徴とする請求項７に記載の階層型データベース装置。
9. 前記新たなインスタンスの登録検知の通知に基づく要求に応じて前記新たなインスタンスを前記ユーザ又はユーザグループに送信する手段を具備することを特徴とする請求項７又は８のいずれかに記載の階層型データベース装置。
10. 前記新たなインスタンスの登録に対し前記検索条件に係わるいずれかの前記ユーザ又はグループを特定し、該新たなインスタンスの登録をなした情報登録者に通知する手段を具備することを特徴とする請求項７乃至９のいずれかに記載の階層型データベース装置。
11. 下位の分類が上位の分類の属性を継承する階層構造を持つ階層型データベースの構築方法において、
    第１の分類が有する少なくとも１つの属性を典型属性に設定し、各典型属性に対する検索条件を含む付帯情報を、一の操作で選択可能な第１の典型属性セットに設定するステップと、
    前記第１の分類よりも下位の分類が前記第１の典型属性セットを継承するステップと、
    前記下位の分類に対してさらに下位の分類に継承させる第２の典型属性セットを、前記第１の典型属性セットの少なくとも一部を用いて設定するステップと、を具備することを特徴とする階層型データベースの構築方法。

Images