(57)【要約】【課題】階層構造の下にクラス間で属性が継承するような階層型データベースに対する操作言語での問合わせにおけるクラス間の論理演算を実現すること。【解決手段】一のクラスから他のクラスへの属性の継承を許容する階層型データベースの階層構造を定義する辞書と、第１の問い合わせ言語で記述され、前記階層構造中のクラス間の論理演算の記述を含む第１の問い合わせ文を解釈する解釈器と、前記辞書を参照して前記階層構造内を探索することにより、前記第１の問い合わせ文に記述された前記クラス間の論理演算の結果に相当するクラスを決定するとともに、該クラスのインスタンスを検索するために用いられる第２の問い合わせ言語で記述された第２の問い合わせ文を作成する作成手段と、前記第２の問い合わせ文を用い、前記階層型データベースから前記インスタンスを検索する手段とを具備する。【選択図】    図１
2004178014.tif 000002
【特許請求の範囲】
【請求項１】
一のクラスから他のクラスへの属性の継承を許容する階層型データベースの階層構造を定義する辞書と、
第１の問い合わせ言語で記述され、前記階層構造中のクラス間の論理演算の記述を含む第１の問い合わせ文を解釈する解釈器と、
前記辞書を参照して前記階層構造内を探索することにより、前記第１の問い合わせ文に記述された前記クラス間の論理演算の結果に相当するクラスを決定するとともに、該クラスのインスタンスを検索するために用いられる第２の問い合わせ言語で記述された第２の問い合わせ文を作成する作成手段と、
前記第２の問い合わせ文を用い、前記階層型データベースから前記インスタンスを検索する手段と
を具備することを特徴とする階層型データベース装置。
【請求項２】
前記階層構造中のいずれかのクラスが、該クラスに対して上位のクラスから一部の属性のみを継承することを許容する請求項１に記載の階層型データベース装置。
【請求項３】
前記継承に係る属性の少なくとも一部を無効化する手段をさらに具備することを特徴とする請求項１または２に記載の階層型データベース装置。
【請求項４】
前記第１の問い合わせ文が、前記階層構造内の検索方向を指定する記述を含み、前記作成手段は、前記クラス間の論理演算の結果に相当するクラスを探索する範囲を、前記検索方向に応じて決定することを特徴とする請求項１乃至３のいずれかに記載の階層型データベース装置。
【請求項５】
前記階層構造は製品の部品クラスを含み、該階層構造中のいずれかのクラスの属性が、設定可変の参照条件の下に前記部品クラスを参照することを特徴とする請求項１乃至４のいずれかに記載の階層型データベース装置。
【請求項６】
識別子とともに前記参照条件を記憶する手段を具備することを特徴とする請求項５に記載の階層型データベース装置。
【請求項７】
前記参照条件は、前記部品クラス内の属性の値を表す変数を含むことを特徴とする請求項５に記載の階層型データベース装置。
【請求項８】
前記参照条件をグラフィカルユーザインターフェース（ＧＵＩ）及び参照条件設定ファイルによる一括登録手段の少なくともいずれかを用いて設定することを特徴とする請求項５に記載の階層型データベース装置。
【請求項９】
前記階層構造はユーザ管理のためのユーザクラスを含み、該ユーザクラスから下位のクラスは前記ユーザ管理に係る権限を表す属性を含み、該権限を表す属性の継承を許容することを特徴とする請求項１乃至８のいずれかに記載の階層型データベース装置。
【請求項１０】
前記階層構造は、前記インスタンスから参照されるリソースクラスを含み、該リソースクラスから下位のクラスは、上位クラスからの属性の継承を許容することを特徴とする請求項１乃至９のいずれかに記載の階層型データベース装置。
【請求項１１】
一のクラスから他のクラスへの属性の継承を許容する階層型データベースの階層構造を定義する辞書を記憶手段から読み出すステップと、第１の問い合わせ言語で記述され、前記階層構造中のクラス間の論理演算の記述を含む第１の問い合わせ文を解釈するステップと、
前記辞書を参照して前記階層構造内を探索することにより、前記第１の問い合わせ文に記述された前記クラス間の論理演算の結果に相当するクラスを決定するステップと、
決定された前記クラスのインスタンスを検索するために用いられる第２の問い合わせ言語で記述された第２の問い合わせ文を作成するステップと、
前記第２の問い合わせ文を用い、前記階層型データベースから前記インスタンスを検索するステップと
を具備することを特徴とする階層型データベース装置の検索方法。
【請求項１２】
前記階層構造中のいずれかのクラスが、該クラスに対して上位のクラスから一部の属性のみを継承することを許容する請求項１１に記載の階層型データベース装置の検索方法。
【請求項１３】
前記継承に係る属性の少なくとも一部を無効化するステップをさらに具備することを特徴とする請求項１１または１２に記載の階層型データベース装置の検索方法。
【請求項１４】
前記第１の問い合わせ文が、前記階層構造内の検索方向を指定する記述を含み、前記作成ステップは、前記クラス間の論理演算の結果に相当するクラスを探索する範囲を、前記検索方向に応じて決定することを特徴とする請求項１１乃至１３のいずれかに記載の階層型データベース装置の検索方法。
【請求項１５】
前記階層構造は製品の部品クラスを含み、該階層構造中のいずれかのクラスの属性が、設定可変の参照条件の下に前記部品クラスを参照することを特徴とする請求項１１乃至１４のいずれかに記載の階層型データベース装置の検索方法。
【請求項１６】
識別子とともに前記参照条件を記憶するステップを具備することを特徴とする請求項１５に記載の階層型データベース装置の検索方法。
【請求項１７】
前記参照条件は、前記部品クラス内の属性の値を表す変数を含むことを特徴とする請求項１５に記載の階層型データベース装置の検索方法。
【請求項１８】
前記参照条件をグラフィカルユーザインターフェース（ＧＵＩ）及び参照条件設定ファイルによる一括登録手段の少なくともいずれかを用いて設定するステップを具備することを特徴とする請求項１５に記載の階層型データベース装置の検索方法。
【請求項１９】
前記階層構造はユーザ管理のためのユーザクラスを含み、該ユーザクラスから下位のクラスは前記ユーザ管理に係る権限を表す属性を含み、該権限を表す属性の継承を許容することを特徴とする請求項１１乃至１８のいずれかに記載の階層型データベース装置の検索方法。
【請求項２０】
前記階層構造は、前記インスタンスから参照されるリソースクラスを含み、該リソースクラスから下位のクラスは、上位クラスからの属性の継承を許容することを特徴とする請求項１１乃至１９のいずれかに記載の階層型データベース装置の検索方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、階層的な構造を有し、クラス（分類）間において属性が継承する仕組みを備えた階層型データベースに関する。
【０００２】
【従来の技術】
広く普及しているリレーショナルデータベースの操作言語の規格であるＳＱＬ（ＡＮＳＩ／ＩＳＯ／ＩＥＣ  ９０７５−１−１９９９  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ  −  Ｄａｔａｂａｓｅ  Ｌａｎｇｕａｇｅ  −  ＳＱＬ  Ｐａｒｔ  １：  Ｆｒａｍｅｗｏｒｋ）は、集合論理に基づいており、内部アルゴリズムの詳細を知る必要なく問い合せを発行することができる言語インターフェースであり、多くのリレーショナルデータベースシステムにおいて実装されている。
【０００３】
また、オブジェクト指向データベースの問い合せ言語にＯＱＬ（Ｏｂｊｅｃｔ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）がある。ＯＱＬは、オブジェクト指向型の複雑なモデルに対して問い合わせを行うことができる言語である。さらに、構造化文書であるＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書に対して問合わせを行うための言語として、Ｗ３Ｃで規格化が進められているＸＱｕｅｒｙがある。
【０００４】
オブジェクト指向データベース（ＯＯＤＢ）やオブジェクト・リレーショナルデータベース（ＯＲＤＢ）を代表とするデータベースは、階層構造を有し、該階層構造において下位分類が上位分類の属性を継承する仕組みを有する。このようなデータベースでは、継承によって下位の分類では属性が累増するという特徴がある。下位分類が上位分類の属性を継承することは、「インヘリタンス」とも呼ばれ、このような技術は多くの文献に記載されている（例えば下記非特許文献１参照。）。
【０００５】
なお、オブジェクト指向データベース（ＯＯＤＢ）関連の技術分野では、階層中の分類を「クラス」と呼ぶことが多い。本明細書では、「分類」と「クラス」とをほぼ同じ意味を有する用語として用いる。
【０００６】
また、オブジェクト・リレーショナル型データベース（ＯＲＤＢ）においては、継承を許したテーブルがクラスに相当する。上下関係にあるテーブル間においては、上位のテーブルから下位のテーブルへ属性が継承される。ここでの属性は、ＯＲＤＢにおいては上位テーブルを構成するコラムのヘッダー情報に相当し、これが下位テーブルへ継承される。
【０００７】
本明細書においては、オブジェクト指向データベース（ＯＯＤＢ）とオブジェクト・リレーショナルデータベース（ＯＲＤＢ）の両者を含めて「階層型データベース」と称する。また、各階層のクラスに属する同じ属性種を持つデータを「インスタンス」と呼び、その集合をデータの「ポピュレーション」と呼ぶ。
【０００８】
上記ＳＱＬでは、同じ属性を持つテーブル間での集合和（Ｕｎｉｏｎ）、集合積（Ｉｎｔｅｒｓｅｃｔ）、集合差（Ｅｘｃｅｐｔ）の各演算が可能であり、多くのデータベース管理システム（ＤＢＭＳ；Ｄａｔａ  Ｂａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）に実装されている。
【０００９】
このようなＳＱＬを拡張した他の言語の一つにＣＱＬ（Ｃｌａｓｓ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）がある（例えば非特許文献２参照）。ＣＱＬでは、階層構造下におけるクラス間の論理演算を可能にする拡張がなされており、かかる論理演算はＳＱＬをそのまま用いて実現することはできない。また、これまでにＣＱＬを実装したＤＢＭＳは提供されていないのが現状である。
【００１０】
【非特許文献１】
Ｏｂｊｅｃｔ−Ｏｒｉｅｎｔｅｄ  Ｃｏｎｃｅｐｔｓ，  Ｄａｔａｂａｓｅｓ，  ａｎｄ  Ａｐｐｌｉｃａｔｉｏｎｓ，  Ｅｄｉｔｅｄ  ｂｙ  Ｗｏｎ  Ｋｉｍ，  １９８９，  ＡＣＭ  Ｐｒｅｓｓ
【００１１】
【非特許文献２】
”Ｃｌａｓｓ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ  ａｎｄ  ｉｔｓ  ａｐｐｌｉｃａｔｉｏｎ  ｔｏ  ＩＳＯ１３５８４  Ｐａｒｔｓ  Ｌｉｂｒａｒｙ  Ｓｔａｎｄａｒｄ”，  Ｙｕｍｉｋｏ  Ｍｉｚｏｇｕｃｈｉ−Ｓｈｉｍｏｇｏｒｉ，  Ｈｉｒｏｓｈｉ  Ｍｕｒａｙａｍａ，  Ｎｏｒｉｋｏ  Ｍｉｎａｍｉｎｏ，  ＥＣＥＣ’２００２  ９ｔｈ  Ｅｕｒｏｐｅａｎ  Ｃｏｎｃｕｒｒｅｎｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｃｏｎｆｅｒｅｎｃｅ
【００１２】
【発明が解決しようとする課題】
より詳しくは、上述のＳＱＬは、同じ属性を持つテーブル間で集合和（Ｕｎｉｏｎ）、集合積（Ｉｎｔｅｒｓｅｃｔ）、集合差（Ｅｘｃｅｐｔ）の各演算を可能とするが、ＳＱＬは継承の仕組みを持たないフラットなモデルを基本に考えられていることから、テーブル間における親子関係および属性の継承を考慮した集合演算は元より考えられていない。
【００１３】
また、上述のＯＱＬは、オブジェクト間の関係を考慮した問い合せが可能であるが、問い合せの結果は、そのオブジェクトで定義された検索メソッドに依存する。このため、ＯＱＬは複雑な検索メソッドを定義できる反面、オブジェクトの実装を知らなければ所望のデータを取得する検索文を発行することが難しい。
【００１４】
また、上述のＸＱｕｅｒｙについては、ＸＭＬが半構造であるがゆえに階層構造についてはモデル化されているが、属性の継承を考慮した演算については、やはり考慮されていない。したがって、検索文を発行するユーザは、階層構造をまたがる検索を行って所望の検索結果を取得するために、複雑な検索文を作成したり、オブジェクトの定義を調べる多大な手間がかかる。
【００１５】
本発明はかかる事情を考慮してなされたものであり、階層構造の下にクラス間で属性が継承するような階層型データベースに対する操作言語での問合わせにおけるクラス間の論理演算を実現することを目的とする。
【００１６】
【課題を解決するための手段】
本発明に係る階層型データベース装置は、一のクラスから他のクラスへの属性の継承を許容する階層型データベースの階層構造を定義する辞書と、第１の問い合わせ言語で記述され、前記階層構造中のクラス間の論理演算の記述を含む第１の問い合わせ文を解釈する解釈器と、前記辞書を参照して前記階層構造内を探索することにより、前記第１の問い合わせ文に記述された前記クラス間の論理演算の結果に相当するクラスを決定するとともに、該クラスのインスタンスを検索するために用いられる第２の問い合わせ言語で記述された第２の問い合わせ文を作成する作成手段と、前記第２の問い合わせ文を用い、前記階層型データベースから前記インスタンスを検索する手段とを具備することを特徴とする。
【００１７】
本発明に係る階層型データベース装置の検索方法は、一のクラスから他のクラスへの属性の継承を許容する階層型データベースの階層構造を定義する辞書を記憶手段から読み出すステップと、第１の問い合わせ言語で記述され、前記階層構造中のクラス間の論理演算の記述を含む第１の問い合わせ文を解釈するステップと、前記辞書を参照して前記階層構造内を探索することにより、前記第１の問い合わせ文に記述された前記クラス間の論理演算の結果に相当するクラスを決定するステップと、決定された前記クラスのインスタンスを検索するために用いられる第２の問い合わせ言語で記述された第２の問い合わせ文を作成するステップと、前記第２の問い合わせ文を用い、前記階層型データベースから前記インスタンスを検索するステップとを具備することを特徴とする。
【００１８】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。
【００１９】
図１は本発明の一実施形態に係る階層型データベース装置の概略構成を示すブロック図である。本実施形態の階層型データベース装置は、階層構造を持つクラス間の論理演算を可能にするＣＱＬ（Ｃｌａｓｓ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）を、既存の操作言語である例えばＳＱＬを有するＤＢＭＳを基に実現するものであり、入力部１、解析部２、検索文作成部３、データベース管理システム（ＤＢＭＳ）４、ライブラリ５、ユーザ情報６、リソース７、検索結果編集部８、表示部９、および辞書１０から構成されている。本装置は例えばＣＰＵ、メモリ、磁気ディスク装置等のハードウェアを備えた汎用のコンピュータを用い、同コンピュータ上で動作するアプリケーションプログラムとして実現することができる。この場合、同コンピュータには、アプリケーションプログラムの実行環境を提供するとともに、各種ハードウェアを制御するためのオペレーティングシステムも導入される。
【００２０】
なお、本発明は一般的なクライアント／サーバ方式のコンピュータシステムとして実施することもできる。この場合、本実施形態に係る階層型データベース装置の一部機能はクライアント側に設けられ、他の機能がサーバ側に設けられることになる。例えば、ユーザからの検索要求を受け付ける入力部１がクライアント側のコンピュータに設けられ、クライアント側のコンピュータに対しネットワーク回線を経由して接続されたサーバ側のコンピュータに、解析部２、検索文作成部３、ＤＢＭＳ４、ライブラリ５、ユーザ情報６、リソース７、辞書結果編集部８、および辞書１０が設けられ、同ネットワーク回線を経由してクライアント側コンピュータからの検索要求をサーバ側コンピュータにて処理し、その検索結果を同クライアント側コンピュータに返送する構成となる。なお、クライアント側とサーバ側との間の機能分担は任意である。例えば、解析部２、検索文作成部３、および辞書１０がクライアント側に設けられる構成も考えられる。
【００２１】
本実施形態に係る階層型データベース装置内では、クラスおよび属性（プロパティ）については、これらを識別子で一意に特定できるものとする。なお、業種や目的別の識別子を用いたい場合には、識別子の対応表を用いて本装置内の識別子に変換してからアクセスするものとする。
【００２２】
図２は、本実施形態に係る階層型データベース装置における検索文実行時の一処理手順を示すフローチャートである。
【００２３】
ステップＳ１において、ユーザからの第１の検索文（ここではＣＱＬ文）の入力を入力部１が受け付ける。入力された第１の検索文は解析部２に送られる。次にステップＳ２において、解析部２は入力部１から送られてきた第１の検索文を、構文解析を含む公知の字句処理によって解析し、その内容を検索文作成部３に送る。ステップ３において、検索文作成部３は解析部２から送られてきた第１の検索文の内容に基づき、辞書１０を参照して第２の検索文（ここではＳＱＬ文）を作成する。
【００２４】
作成された第２の検索文はＤＢＭＳ４に送られる。ステップＳ４において、ＤＢＭＳ４は第２の検索文による検索を実行する。ＤＢＭＳ４による検索対象はライブラリ５、ユーザ情報６、およびリソース７であり、これらは、階層型データベースのインスタンスに相当する。階層型データベースの構造を与える情報は辞書１０に予め格納されている。
【００２５】
そして、ステップＳ５では、ＤＢＭＳ４から得られた検索結果を検索結果編集部８が編集して表示部９に送る。表示部９はこれをディスプレイ等のデバイスに表示する。
【００２６】
本実施形態に係る階層型データベース装置は、少なくとも次の３種類の情報、すなわち、（１）階層構造情報、（２）クラス情報、（３）属性情報によって構成される辞書１０を具備する。上述のように辞書１０は、階層型データベースの構造を与える。本実施形態においては、辞書１０におけるこれら３種類の情報により構造定義された階層型データベースのインスタンス情報をライブラリ５が管理している。すなわち、インスタンス情報は、管理したい主対象のデータであり、ライブラリ５はこれを格納する。なお、リソース７はライブラリ５から参照される付加的な情報に相当するデータ（例えば、イメージファイルなど）であり、ユーザ情報６は、階層型データベースへのアクセス管理に必要な情報である。
【００２７】
ここで、辞書１０を構成する上記階層構造情報、クラス情報、および属性情報のそれぞれについて詳細に説明する。
【００２８】
階層構造情報は、クラス間の構造を規定する情報である。
【００２９】
例えば図３に示すようなクラス階層についての階層構造情報は、図４のような形式で辞書１０に格納することができる。この階層構造情報において、ｓｕｂｊｅｃｔ＿ｉｄおよびｏｂｊｅｃｔ＿ｉｄはそれぞれ、クラスを識別するための識別子の記述であり、ａｓｓｏｃ＿ｉｄはｓｕｂｊｅｃｔ＿ｉｄとｏｂｊｅｃｔ＿ｉｄ間の関係の種類を表す識別子（ここでは例えば数値）の記述である。例えば、ａｓｓｏｃ＿ｉｄ＝１は「ｓｕｂｊｅｃｔ＿ｉｄはｏｂｊｅｃｔ＿ｉｄの子クラスであること」を表す。また、ａｓｓｏｃ＿ｉｄ＝２は「ｓｕｂｊｅｃｔ＿ｉｄはｏｂｊｅｃｔ＿ｉｄの部分継承クラスであること」を表す。
【００３０】
クラス識別子としては、後述するクラス情報において定義されるものが用いられる。そして、図４において例えば２行目は「ＶｅｈｉｃｌｅクラスはＰｒｏｄｕｃｔクラスの子クラスであること」を表し、８行目は「ＨｙｂｒｉｄクラスはＳｅｄａｎクラスの部分継承クラスであること」を表している。
【００３１】
クラス情報は各々のクラスを定義する情報である。ある一つのクラスの定義は、該クラスの識別子、名称（呼称）、親クラス（の識別子）の記述を含む。また、該一つのクラスに対し、適用可能（ａｐｐｌｉｃａｂｌｅ）、部分継承（ｉｍｐｏｒｔｅｄ）、負の継承（ｎｅｇａｔｉｖｅ）といった関係にある属性の識別子の記述も含む。ある一つのクラスに適用可能な属性は、親クラスから継承した属性を含み、これに基づいて該クラスのインスタンスは表現される。
【００３２】
図３に示されているクラスに関する情報は例えば図５のような形式で辞書１０に格納することができる。図５において、Ｉｄｅｎｔｉｆｉｅｒはクラスの識別子、Ｎａｍｅはクラスの名称、ｓｕｐｅｒ＿ｃｌａｓｓは直接の上位（親）クラスである。ａｐｐｌｉｃａｂｌｅ＿ｐｒｏｐｅｒｔｉｅｓはそのクラスに適用可能な属性の識別子、ｉｍｐｏｒｔｅｄ＿ｐｒｏｐｅｒｔｉｅｓは部分継承に係る属性の識別子である。また、ｎｅｇａｔｉｖｅ＿ｐｒｏｐｅｒｔｉｅｓは上位のクラスから継承されてきたが当該クラスよりも下位の階層では今後適用されることのない属性の識別子である。属性の識別子としては、後述する属性情報において定義されるものが用いられる。なお、図５は、複数の属性識別子を、それぞれ配列型（ＡＲＲＡＹ型）であるａｐｐｌｉｃａｂｌｅ＿ｐｒｏｐｅｒｔｉｅｓ，  ｉｍｐｏｒｔｅｄ＿ｐｒｏｐｅｒｔｉｅｓ，  ｎｅｇａｔｉｖｅ＿ｐｒｏｐｅｒｔｉｅｓを用いて格納するものであるが、これはあくまで一例であり、属性識別子の格納方法は例えば実装上のデータベースのスキーマ設計に応じて異なっていてもよい。
【００３３】
図５において、例えばＨｙｂｒｉｄ  ＶｅｈｉｃｌｅクラスはＥｌｅｃｔｒｉｃ  Ｖｅｈｉｃｌｅクラスの子クラスであるから同Ｅｌｅｃｔｒｉｃ  Ｖｅｃｈｉｃｌｅの属性を継承する一方、Ｓｅｄａｎクラスからｄｉｓｐｌａｃｅｍｅｎｔとｅｎｇｉｎｅ＿ｔｙｐｅ属性（ｉｍｐｏｒｔｅｄ＿ｐｒｏｐｅｒｔｉｅｓ）を部分継承している（図３を参照）。
【００３４】
また、Ｃｏｍｐｒｅｓｓｅｄ  Ｎａｔｕｒａｌ  Ｇａｓ  Ｖｅｈｉｃｌｅ（ＬＮＧ）クラスでは、ルートクラスからＥｃｏｌｏｇｉｃａｌ  Ｖｅｈｉｃｌｅ（Ｅｃｏｌｏｇｉｃａｌ）までに定義されている属性を継承するが、ｎｅｇａｔｉｖｅ＿ｐｒｏｐｅｒｔｉｅｓとしてｍａｘ＿ｓｐｅｅｄが記述されている。したがって、この属性はＣｏｍｐｒｅｓｓｅｄ  Ｎａｔｕｒａｌ  Ｇａｓ  Ｖｅｈｉｃｌｅ（ＬＮＧ）クラスから下位のクラスには継承されない。このような負の継承（継承の否定）を「ネガティブインヘリタンス」という。このネガティブインヘリタンスについてさらに詳しく説明する。
【００３５】
オブジェクト指向データベースを代表とする、下位が上位クラスの属性を継承する階層構造を持つデータベースにおいては、継承によって下位のクラスでは属性が累増する。ところが、実際の製品や生物の分類においては、技術の発展あるいは生物の進化にともない、ある階層を起源としてそれ以降（下位）、その階層以前（上位）の分類において上位にあった特徴や性質が消失することがある。これを従来のオブジェクト指向データベースの概念および階層型データベースでは適切に表現することができなかった。
【００３６】
例えば、従来の家庭用電気掃除機には電源ケーブルがあり、常に電源と掃除機は常時電源ケーブルで結ばれていた。しかし最近では、蓄電池から供給される電気を動力に変えてモータを駆動するようにし、操作性の向上のために電源ケーブルを廃した掃除機が存在する。また家庭用のアイロンにおいても、現在は電源とアイロンのホルダー間に電源ケーブルはあるが、実際に衣類に当てる本体には電源ケーブルのない蓄熱型のものが存在する。これらは電気掃除機の発展形として分類されるものであるが、従来の電気掃除機やアイロンでは電源ケーブルの存在は必要不可欠と思われていたために、上位クラスとなる電気掃除機やアイロンのクラスにおいて電源ケーブルという属性が生じるのが普通である。また自動車には、その燃料として使用するものがガソリンであれディーゼル油であれ、ある種の内燃エンジン（ｃｏｍｂｕｓｔｉｏｎ  ｅｎｇｉｎｅ）を必要とするが、環境に配慮した最近の電気自動車には内燃エンジンが存在しない。この時、例えば自動車に固有の属性とされる「内燃エンジン種類」を除去し、下位のクラス例えばセダン等で改めて「エンジン種類」として設けるならば、問題を可避できるが、種類を問わず多くのデータベースにおいては、ひとたびクラスに固有の属性が定義されると、その属性に従ってインスタンス・データが入力、蓄積されるため、事後にクラスから属性を削除することはデータベースの管理上大きな問題を引き起こすことが多い。ネガティブインヘリタンス（負の継承）は、これらの問題を解決するための新しい属性の継承の仕組であり、形質の退化現象を扱い得るものである。
【００３７】
次に、属性情報は、各々の属性を定義する情報である。ある一つの属性定義は、少なくとも該属性の識別子、データ型の記述を含む。属性情報は例えば図６のような形式で辞書１０に格納することができる。
【００３８】
図６において、Ｉｄｅｎｔｉｆｉｅｒは属性の識別子、ｄａｔａ＿ｔｙｐｅはその属性のデータ型である。また、Ｕｎｉｔ／ｃｕｒｒｅｎｃｙは当該属性に関連付けられた単位／通貨等のことである。ｒｅｆ＿ｃｌａｓｓは当該属性が参照型のデータ型である場合の参照先のクラスの識別子を示す。図６において、例えばＴｉｒｅ属性は、ｄａｔａ＿ｔｙｐｅがクラスインスタンス型となっている。クラスインスタンス型は、他クラスのデータを参照する参照型のデータ型である。Ｔｉｒｅ属性は、ｒｅｆ＿ｃｌａｓｓに記述されているようにＴｉｒｅクラス（のインスタンス）を参照する。
【００３９】
以上が階層構造情報、クラス情報、および属性情報を辞書の説明である。次に、インスタンス情報について説明する。インスタンス情報は、クラス情報と属性情報の定義に従って作成されたコンテナに格納される。該コンテナは、リレーショナルデータベースの「テーブル」に相当する。
【００４０】
図７（ａ）〜（ｄ）はこのようなインスタンス情報の例を幾つか示したものである。
【００４１】
図５のクラス情報によると、Ｅｌｅｃｔｒｉｃ  Ｖｅｈｉｃｌｅ（Ｅｌｅｃｔｒｉｃ）クラスに所属するインスタンスを格納するために適用できる属性は、Ｐｉｄ，  Ｎａｍｅ，  Ｍａｋｅｒ，  Ｐｒｉｃｅ，  ｗｅｉｇｈｔ，  ｍａｘ＿ｓｐｅｅｄ，  ｔｉｒｅ，  ｔｉｒｅ＿ｓｉｚｅ，  Ｍｏｔｏｒ＿ｍａｘ＿ｐｏｗｅｒ，  Ｅｌｅｃｔｒｉｃ．ｍｏｔｏｒｅ＿ｔｙｐｅである。図７（ａ）に示すように、このＥｌｅｃｔｒｉｃ  Ｖｅｈｉｃｌｅ（Ｅｌｅｃｔｒｉｃ）クラスのインスタンス情報は、インスタンスを格納するためのコンテナの属性として、Ｐｉｄ，  Ｎａｍｅ，  Ｍａｋｅｒ，  Ｐｒｉｃｅ，  ｗｅｉｇｈｔ，  ｍａｘ＿ｓｐｅｅｄ，  Ｍｏｔｏｒ＿ｍａｘ＿ｐｏｗｅｒ，  Ｅｌｅｃｔｒｉｃ．ｍｏｔｏｒｅ＿ｔｙｐｅが用いられている。なお、実際のインスタンスを格納するテーブル名はシステム側が任意の規則で命名しても良いし、コンテナを作成するユーザが識別子を発行して作成しても良い。本実施形態では、Ｅｌｅｃｔｒｉｃ＿ｔｂｌというテーブルがデータベースにおいて作成されているものとする。同様に、図７（ｂ）はＳｅｄａｎ（Ｓｅｄａｎ）クラスのインスタンス情報、図７（ｃ）はＨｙｂｒｉｄ  Ｖｅｈｉｃｌｅ（Ｈｙｂｒｉｄ）クラスのインスタンス情報、図７（ｄ）はＴｉｒｅクラスのインスタンス情報を示す。
【００４２】
以下、図３〜図７に示したように構築された階層型データベースにおけるクラス間の論理演算の例を幾つか説明する。上述したように、クラス間の論理演算は例えばＣＱＬ文によって表現する。このＣＱＬ文は、例えば入力部１を介してユーザが入力する。この入力されたＣＱＬ文の内容は、解析部２により解析され、該ＣＱＬ文中に明記されたクラス間の論理演算をＤＢＭＳ４により解決するための第２の問合わせ言語の検索文、すなわちここではＳＱＬ文が作成される。このＳＱＬ文を作成するにあたり、検索文作成部３は、辞書１０を参照し、該辞書１０に規定の階層構造情報から、階層構造を持つクラス間の関係を分析し、検索対象となるクラスを決定する。
【００４３】
Ｐｒｏｄｕｃｔクラスとそのサブクラスから全てのインスタンスを検索する際、次のようにＣＱＬ文（１）を入力する。これは論理和（ＯＲ）演算に相当する。
ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  Ｐｒｏｄｕｃｔ＊；  （１）
検索結果として、図８（ａ）のようにＰｒｏｄｕｃｔクラス以下のクラスに含まれるインスタンスが、全ての属性の和集合として取得される。
【００４４】
次に、Ｅｌｅｃｔｒｉｃ  ＶｅｈｉｃｌｅクラスとＳｅｄａｎクラスとの間の論理積（ＡＮＤ）演算を説明する。例えば次のようにＣＱＬ文（２）を入力する。
ｓｅｌｅｃｔ  Ｐｉｄ，  Ｎａｍｅ  ｆｒｏｍ  Ｅｌｅｃｔｒｉｃ＊  ＡＮＤ  Ｓｅｄａｎ＊；  （２）
この入力されたＣＱＬ文（２）についての論理積演算は例えば以下の手順にしたがって実行される。
【００４５】
（ＳＴＥＰ１）命令文の解析：先ず、入力部１から入力されたＣＱＬ文（２）は解釈部２に送られ、該ＣＱＬ文（２）に含まれる命令の内容が解釈部２により解釈される。
【００４６】
（ＳＴＥＰ２）検索文作成と実行：検索文作成部３は、ＳＴＥＰ２において解析された命令について、辞書１０を参照しながらＤＢＭＳ４が利用するデータベース（ここではライブラリ５、ユーザ情報６、リソース７）への実際の問い合せ文を作成する。ＤＢＭＳ４が利用するデータベースはリレーショナルデータベースであり、問い合わせ文はＳＱＬ文である。
【００４７】
まず、図４の階層構造情報を手がかりにＥｌｅｃｔｒｉｃ  Ｖｅｈｉｃｌｅ（Ｅｌｅｃｔｒｉｃ）クラスとＳｅｄａｎ（Ｓｅｄａｎ）クラスの子クラスをたどり、Ｅｌｅｃｔｒｉｃ  Ｖｅｈｉｃｌｅクラスの子孫であって且つＳｅｄａｎクラスの子孫（ａｓｓｏｃ＿ｉｄ＝１またはａｓｓｏｃ＿ｉｄ＝２）でもあるクラスを決定する。ここではＨｙｂｒｉｄクラスがこれに相当し、これによりＨｙｂｒｉｄクラス以下のインスタンスが検索対象として決定される。検索文作成部３は、Ｈｙｂｒｉｄクラス以下のインスタンスを格納したテーブルを検索するＳＱＬ文を作成する。Ｈｙｂｒｉｄクラスのインスタンスを格納するコンテナとなるテーブルはｈｙｂｒｉｄ＿１＿ｔｂｌであり、検索文作成部３はこのｈｙｂｒｉｄ＿１＿ｔｂｌが指定された次のようなＳＱＬ文（３）を作成する。
ｓｅｌｅｃｔ  Ｐｉｄ，  Ｎａｍｅ  ｆｒｏｍ  ｈｙｂｒｉｄ＿１＿ｔｂｌ；  （３）
なお、図３の階層構造によるとＨｙｂｒｉｄクラスはサブクラスを持たないが、求められたクラスがサブクラスを持つような場合（階層構造情報から判断できる）には、該サブクラスに格納されたインスタンスも検索対象となる。
【００４８】
上記ＳＱＬ文（３）はＤＢＭＳ４に与えられ、該ＤＢＭＳ４は、実体としてのコンテナテーブル（ｈｙｂｒｉｄ＿１＿ｔｂｌ）に対して検索を実行する。これにより検索結果として図８（ｂ）が取得される。
【００４９】
（ＳＴＥＰ３）検索結果編集：ＤＢＭＳ４から取得された検索結果を、任意のフォーマットに整形するよう検索結果編集部８が編集する。表示部９は編集結果をディスプレ等のデバイスに表示する。フォーマットは、検索文を入力する側で指定できるようにすると好ましい。また、フォーマットの種類としては、図８（ａ）〜（ｄ）のような表形式でも良いし、ＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式で出力しても良い。あるいは、検索結果編集部８が検索結果をＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式で出力し、さらにこれをスタイルシート等を用いてＨＴＭＬに整形して表示するようにしてもよい。
【００５０】
ここで、検索方向の切り替えについて説明する。本実施形態では、検索文（命令）中に検索方法を指定することができる。具体的には、検索方向を切り替えることができる。
【００５１】
例えば、上記ＣＱＬ文（１）ではクラス識別子に続く「＊」の記述により検索方向が下方となっている。これとは異なる検索方法として、次のＣＱＬ文（４）はＨｙｂｒｉｄクラスから上位階層に向かってインスタンスを検索する。なお、ここでは部分継承に係わるものは検索対象から除外するようにしている。クラス識別子に続く「！」の記述が検索方法の指定である。
【００５２】
ｓｅｌｅｃｔ  Ｐｉｄ，  Ｎａｍｅ，  ｍｏｔｏｒ＿ｍａｘ＿ｐｏｗｅｒ  ｆｒｏｍ  Ｈｙｂｒｉｄ！
ｗｈｅｒｅ  ｍｏｔｏｒ＿ｍａｘ＿ｐｏｗｅｒ  ＜  ７０；  （４）
次のＣＱＬ文（５）は、Ｈｙｂｒｉｄクラスから上位階層に向かってインスタンスを検索する（部分継承を含む）。本例では、クラス識別子に続く「％」の記述が検索方法の指定である。
【００５３】
ｓｅｌｅｃｔ  Ｎａｍｅ，  Ｍａｋｅｒ，  Ｄｉｓｐｌａｃｅｍｅｎｔ  ｆｒｏｍ  Ｈｙｂｒｉｄ％
ｗｈｅｒｅ  Ｄｉｓｐｌａｃｅｍｅｎｔ  ＞  ４０００；  （５）
検索文の作成と実行においては、階層構造情報から、ｆｒｏｍ句に指定されているクラスを起点クラスとし、この起点クラスから遡って上位階層のクラスを取得するよう検索範囲を決定する。
【００５４】
図４の階層構造情報によると、上記ＣＱＬ文（４）の場合、Ｈｙｂｒｉｄクラスの親クラスは、ｎａｒｒｏｗ＿ｉｄ  ＝’Ｈｙｂｒｉｄ’  かつａｓｓｏｃ＿ｉｄ＝１であるｗｉｄｅｒ＿ｉｄを識別子にもつクラスである。同様にして、さらにその親を検索していき、親クラスがＲｏｏｔになるまで続ける。そして、取得したクラスのコンテナとなるテーブルをｆｒｏｍ句に配置した検索文を作成する。Ｈｙｂｒｉｄクラスの上位階層クラスは、Ｅｌｅｃｔｒｉｃ，  Ｅｃｏｌｏｇｉｃａｌ，  Ｖｅｈｉｃｌｅ，  Ｐｒｏｄｕｃｔである。その中で実際にインスタンスを持つテーブルは、ＥｌｅｃｔｒｉｃクラスのＥｌｅｃｔｒｉｃ＿ｔｂｌのみであり、自身のクラスがもつＨｙｂｒｉｄ＿１＿ｔｂｌと合わせて下記ＳＱＬ文（６）および（７）を作成する。
【００５５】
ｓｅｌｅｃｔ  Ｐｉｄ，  Ｎａｍｅ，  Ｅｌｅｃｔｒｉｃ＿ｍｏｔｏｒ＿ｍａｘ＿ｐｏｗｅｒ  ｆｒｏｍ  Ｈｙｂｒｉｄ＿１＿ｔｂｌ
ｗｈｅｒｅ  Ｅｌｅｃｔｒｉｃ＿ｍｏｔｏｒ＿ｍａｘ＿ｐｏｗｅｒ  ＜  ７０；  （６）
ｓｅｌｅｃｔ  Ｐｉｄ，  Ｎａｍｅ，  Ｅｌｅｃｔｒｉｃ＿ｍｏｔｏｒ＿ｍａｘ＿ｐｏｗｅｒ  ｆｒｏｍ  Ｅｌｅｃｔｒｉｃ＿ｔｂｌ
ｗｈｅｒｅ  Ｅｌｅｃｔｒｉｃ＿ｍｏｔｏｒ＿ｍａｘ＿ｐｏｗｅｒ  ＜  ７０；  （７）
上記ＳＱＬ文（６）および（７）の検索を実行し、検索結果として図８（ｃ）が取得される。上記ＣＱＬ文（５）の場合、ａｓｓｏｃ＿ｉｄ＝２（部分継承）も検索範囲に含められる。したがって、自身のクラスおよびその上位階層のテーブルに対する下記ＳＱＬ文（８）〜（１０）を作成する。
【００５６】
ｓｅｌｅｃｔ  Ｎａｍｅ，  Ｍａｋｅｒ，  Ｄｉｓｐｌａｃｅｍｅｎｔ  ｆｒｏｍ  Ｈｙｂｒｉｄ＿１＿ｔｂｌ
ｗｈｅｒｅ  Ｄｉｓｐｌａｃｅｍｅｎｔ  ＞  ４０００；  （８）
ｓｅｌｅｃｔ  Ｎａｍｅ，  Ｍａｋｅｒ，  Ｄｉｓｐｌａｃｅｍｅｎｔ  ｆｒｏｍ  Ｅｌｅｃｔｒｉｃ＿ｔｂｌ
ｗｈｅｒｅ  Ｄｉｓｐｌａｃｅｍｅｎｔ  ＞  ４０００；  （９）
ｓｅｌｅｃｔ  Ｎａｍｅ，  Ｍａｋｅｒ，  Ｄｉｓｐｌａｃｅｍｅｎｔ  ｆｒｏｍ  Ｓｅｄａｎ＿ｔｂｌ
ｗｈｅｒｅ  Ｄｉｓｐｌａｃｅｍｅｎｔ  ＞  ４０００；  （１０）
上記ＳＱＬ文（８）〜（１０）による検索を実行すると、その検索結果として図８（ｄ）が取得される。
【００５７】
次に、本実施形態に付加的に設けられている部品参照機能について説明する。
【００５８】
図６に示した属性情報によると、Ｔｉｒｅ属性はデータ型がｃｌａｓｓ  ｉｎｓｔａｎｃｅであると記述されており、ｒｅｆ＿ｃｌａｓｓにはＴｉｒｅと記述されている。これは、部品参照するためのデータ型であり、図３のクラス階層にあるＴｉｒｅクラスをＶｅｈｉｃｌｅクラスで定義された属性が参照していることを意味している。したがって、Ｖｅｈｉｃｌｅ以下のクラスにおいてＴｉｒｅ属性を使ってインスタンスを記述していると、Ｔｉｒｅクラス下の部品を参照していることを意味している。図７（ｂ）のインスタンス情報によると、ｐｉｄ＝５においてＴｉｒｅ属性にＴｉｒｅと記述されている。ここには、図６のｒｅｆ＿ｃｌａｓｓでＴｉｒｅクラスが指定されているので、インスタンスにはＴｉｒｅクラスか、またはＴｉｒｅクラスよりも下層のクラスを記述することができる。このインスタンスの場合、Ｔｉｒｅクラスがもつ全てのインスタンスを参照してしまう。そこで本実施形態では、適合するＴｉｒｅの条件を参照元のインスタンスに与えることができるよう構成されている。
【００５９】
図７（ｂ）においてｐｉｄ＝６のインスタンスではＴｉｒｅ＝’Ｔｉｒｅ−１’と記述している。’−’の記号に続く数字はクラス参照条件を参照する際に用いる識別子ｑｉｄの値である。図９（ａ）にクラス参照条件の一例を示す。ｑｉｄ＝１の条件はＳｉｚｅ＝ｔｉｒｅ＿ｓｉｚｅとなっている。このクラス参照条件を満たすＴｉｒｅが適合するタイヤである。Ｔｉｒｅクラスに格納されているインスタンスが図７（ｄ）の場合、適合するタイヤは、図９（ｂ）のようになる。このように条件は、値だけでなく属性を変数のように指定することもできる。これは、一つ一つ参照部品の条件を記述することなく、条件を再利用して容易に設定することを可能にする。また、条件設定には’＝’だけでなく比較演算子も用いることができ、値を挟みこむこともできる。例えば「５８０  ＞  Ｔｉｒｅ．ｏｕｔｌｉｎｅ＿ｓｉｚｅ  ＞  ５７６」のように設定できる。
【００６０】
本実施形態では、上述した部品参照を行ってい際に、ある属性から容易に参照部品を閲覧することができるＧＵＩ（グラフィカルユーザインターフェース）が設けられている。
【００６１】
例えば、図１０（ａ）に示すように参照元インスタンス２０において、参照条件を保持するセル２０がクリックされると、かかる参照条件に適合する参照先のインスタンス２２を図１０（ｂ）のように表示する。
【００６２】
また、本実施形態のＧＵＩでは、インスタンスの登録者が条件登録を容易に行うことができるようになっている。
【００６３】
例えば図１１（ａ）は属性による条件設定のためのダイアログである。このダイアログは、参照元の属性の候補３０を一覧表示し、変数として設定する属性３１を選択できるようになっている。また、図１１（ｂ）は、値による条件設定のためのダイアログである。入力エリア３２を通じて、’＝’条件に値を設定することができる。また、図１２（ａ）は属性による範囲条件設定のためのダイアログである。このダイアログでは、２つの入力エリア３３，３４を通じて、範囲条件に属性を変数として設定することができる。図１２（ｂ）は範囲条件に値を設定する為のダイアログである。このダイアログでは、２つの入力エリア３３，３４を通じて、範囲条件を規定する２つの値を設定することができる。さらに、図１３に示すように複数のインスタンスについての参照条件を記述した、例えばテキスト形式からなる部品参照一括入力用ファイル４０をインポートすることにより、一括して条件を設定することもできる。
【００６４】
次に、本実施形態に付加的に設けられているユーザ管理機能について説明する。図１４はプロジェクトの構成例を示す図である。本実施形態に係る階層型データベース装置は、この図に示すようなクラス階層木を用い、そのルートクラスに相当するＰｒｏｊｅｃｔクラス５０の単位でデータ管理を行うものである。ある一つのプロジェクトは、図１にも示したように、（１）階層構造情報、（２）クラス情報、（３）属性情報によって構成される辞書１０を持つ。また、ライブラリ５、ユーザ情報６、およびリソース７を持つ。
【００６５】
上述したように、ライブラリ５は、管理したい主対象のデータとしてのインスタンス情報を格納する。これは図１４のクラス階層木におけるＬｉｂｒａｒｙクラス５１に対応する。また、リソース７はライブラリ５から参照される付加的な情報に相当するデータ（例えば、イメージファイルなど）である。これは、図１４のクラス階層木におけるＲｅｓｏｕｒｃｅクラス５２に対応する。また、ユーザ情報６は、階層型データベースへのアクセス管理に必要な情報である。ユーザ情報６は、ライブラリ５と同様の階層を持つクラスとして同様の方法で管理される。
【００６６】
ユーザ情報６は、図１４のクラス階層木におけるＵｓｅｒクラス５３に対応する。ユーザに関する情報および権限に関する情報はクラス階層木において特定可能なデータであり、交換が可能である。グループを管理するクラスは、Ｕｓｅｒクラス５３の下に階層構造が構築されており、各ユーザはいずれかのユーザグループクラスのインスタンスとして登録される。各ユーザを表現する属性、および付与された権限は、下位のグループクラスに継承される。次の３種類の対象、すなわちクラス、属性、インスタンスに関する権限は、ユーザグループに対して付与される。
【００６７】
図１４に示すプロジェクトの構成例において、Ｌｉｂｒａｒｙクラス５１は、これまでに説明したＰｒｏｄｕｃｔクラス５４の階層を有する。Ｒｅｓｏｕｒｃｅクラス４２には、イメージファイル５５が格納されている。また、Ｕｓｅｒクラス５３の子クラスにはＣｅｒｔｉｆｉｅｄ  ｕｓｅｒ  ｇｒｏｕｐクラス５６、Ｐｕｂｌｉｃ  ｇｒｏｕｐクラス５７が作成されており、Ｃｅｒｔｉｆｉｅｄ  ｕｓｅｒ  ｇｒｏｕｐクラス５６の子クラスにはＡｄｖａｎｃｅｄ  ｅｄｉｔｏｒ  ｇｒｏｕｐクラス５８、Ｓｔａｎｄａｒｄ  ｅｄｉｔｏｒ  ｇｒｏｕｐクラス５９が作成されており、Ａｄｖａｎｃｅｄ  ｅｄｉｔｏｒ  ｇｒｏｕｐクラス５８の子クラスにはＡｄｍｉｎｉｓｔｒａｔｏｒ  ｇｒｏｕｐクラス６０が作成されている。
【００６８】
ユーザグループ（Ｕｓｅｒクラス５３）の階層構造は、Ｌｉｂｒａｒｙクラス５１と同様に例えば図１５のような記述によって規定することができる。それぞれのクラスのインスタンスとなるユーザ情報は、例えば図１６（ａ）〜（ｅ）のように記述することができる。ここでも、規定された階層構造の下にクラス間で属性は継承される。例えば、図１６（ｄ）に示すようにＡｄｖａｎｃｅｄ＿ｅｄｉｔｏｒクラスは、その上位クラスであるＣｅｒｔｉｆｉｅｄ  ｕｓｅｒで使われている属性を継承している（ｕｓｅｒｉｄ，  ｐａｓｓｗｏｒｄ，  ｇｒｏｕｐ）。なお、Ａｄｖａｎｃｅｄ＿ｅｄｉｔｏｒクラスではｄｅｐａｒｔｍｅｎｔ属性がさらに追加されている。このように例えば新しい組織が結成され、追加したい属性が生じた際には、アクセス制限用のクラスであっても情報の追加を容易に行うことができる。
【００６９】
図１７（ａ）〜（ｅ）は、それぞれのクラスに係わる権限の管理に用いられるテーブル構成例を示す図である。
【００７０】
Ｐｕｂｌｉｃ  ｇｒｏｕｐクラスの権限テーブルは、図１７（ａ）に示すように、ＬｉｂｒａｒｙクラスおよびＲｅｓｏｕｒｃｅクラスから下位のクラスに対してｓｅｌｅｃｔ権限を与える。つまり、Ｐｕｂｌｉｃ  ｇｒｏｕｐクラスに属するユーザはデータを閲覧する権限を有する。テーブル内のシーケンス番号３（ｓｅｑｕｅｎｃｅ＝３）の行によると、全ての属性にｓｅｌｅｃｔ権限が与えられている。また、シーケンス番号４（ｓｅｑｕｅｎｃｅ＝４）の行によると、属性Ｐｉｄにはｓｅｌｅｃｔ権限が与えられていない。したがって、ｐｕｂｌｉｃ  ｇｒｏｕｐクラスに属するユーザは、ＬｉｂｒａｒｙクラスおよびＲｅｓｏｕｒｃｅクラスから下位のクラスに対して閲覧権限を有するが、属性ｐｉｄを閲覧することはできないことがわかる。
【００７１】
図１７（ｂ）は、Ｃｅｒｔｉｆｉｅｄ  ｕｓｅｒ  ｇｒｏｕｐクラスの権限テーブルを示したものであり、図１７（ａ）のＰｕｂｌｉｃ  ｇｒｏｕｐクラスの設定を全て継承しているが、全ての属性に対してｓｅｌｅｃｔ権限を与える記述が付加されている。したがって、Ｃｅｒｔｉｆｉｅｄ  ｕｓｅｒ  ｇｒｏｕｐクラスでは、全ての属性を閲覧することができる。
【００７２】
図１７（ｃ）は、Ｓｔａｎｄａｒｄ  ｅｄｉｔｏｒ  ｇｒｏｕｐクラスの権限テーブルを示したものであり、これはＬｉｂｒａｒｙクラスおよびＲｅｓｏｕｒｃｅクラスにｉｎｓｅｒｔ権限を与えるものである。ただし、例外条件も既定されており、すなわち「ｐｉｄ！＝’ｔａｙａｔａ’」であるインスタンスにはｉｎｓｅｒｔ権限を与えない。したがって、ｐｉｄがｔａｙａｔａでないインスタンスにデータを入力することはできない。
【００７３】
以上説明したように、本発明の一実施形態に係る階層型データベース装置によれば、クラス階層を有し、上位クラスの属性が下位クラスに継承されるような階層型データベースへの問合わせにおいて必要となるクラス間の論理演算（ブール演算）を実現することができるから、該クラス間の論理演算をＣＱＬのような問合わせ言語の検索文にそのまま記述して、容易に検索が行える。
【００７４】
また、部分継承やネガティブインヘリタンスとして継承の種類を拡張ができるから、各クラスの性質を属性の集合によって適切に表わすことができるようになる。ネガティブインヘリタンスによれば、既存クラスの冗長性を排除できるメリットもある。
【００７５】
また、ＣＱＬのような問合わせ言語で記述された検索文において柔軟な検索範囲を指定することができる。例えば、クラス階層中の検索方向を、上位クラスから下位クラスへの方向とするのみならず、下位クラスから上位クラスへの方向とすることができることである。したがって、データベースが極めて細分化、複雑化されていたとしても、階層内の深いクラスを起点とし、上位クラスに遡るように検索を行って所要の検索結果を得ることができるようになる。
【００７６】
また、部品参照機能によれば、製品を構成する多数の部品から任意のものを容易に参照することができる。また、部品ＩＤを用いない参照条件による部品参照によれば、製品のインスタンス作成者と、部品のインスタンス作成者との間で当該部品に付与されている部品ＩＤを厳密に共有管理する必要がなくなり、
両者が独立して作業を行うことが可能となる。上述したＧＵＩやテキストファイルによる部品参照一括入力等の参照条件設定手段によれば、製品のインスタンス作成者が容易に部品参照条件を設定することができ、作業効率を向上できる。
【００７７】
また、ユーザに関する情報や該ユーザに与えるデータベースアクセスの権限等のユーザ情報を、製品ライブラリ等と同様に属性の継承をサポートする階層型データベースの形態で格納するようにしているので、該製品ライブラリと同様の仕組みで適切かつ容易にデータ交換が可能となり、ユーザ管理機能を強化できる。
【００７８】
なお、本発明は上述した実施形態に限定されず種々変形して実施可能である。例えば、上記実施形態では、ライブラリ５、ユーザ情報６、リソース７等はリレーショナルデータベースを用いて構成され、その操作言語としてＤＢＭＳ４がＳＱＬが用いられるものについて説明したが、リレーショナルベースに代えてＸＭＬ文書データベースを用いてもよい。この場合、該ＸＭＬ文書データベースの操作言語としてＸＱｕｅｒｙ等を利用できる。
【００７９】
【発明の効果】
以上説明したように本発明によれば、階層構造の下にクラス間で属性が継承するような階層型データベースに対し、利用性の高い操作言語での問合わせを行うことができるようになり、利便性を向上できる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る階層型データベース装置の概略構成を示すブロック図
【図２】上記実施形態に係る階層型データベース装置における検索文実行時の一処理手順を示すフローチャート
【図３】クラス階層の一例を示す図
【図４】上記実施形態に係るクラス階層についての階層構造情報の一例を示す図
【図５】上記実施形態に係るクラス情報の一例を示す図
【図６】上記実施形態に係る属性情報の一例を示す図
【図７】上記実施形態に係るインスタンス情報の例を幾つか示す図
【図８】上記実施形態に係る検索結果の例を幾つか示す図
【図９】上記実施形態に係るクラス参照条件の例を幾つか示す図
【図１０】上記実施形態に係る参照部品閲覧の画面構成例を示す図
【図１１】上記実施形態に係る属性による条件設定のためのダイアログ画面の一例を示す図
【図１２】上記実施形態に係る属性による範囲条件設定のためのダイアログ画面の一例を示す図
【図１３】上記実施形態に係る部品参照一括入力用ファイルの一例を示す図
【図１４】プロジェクトの構成例を示す図
【図１５】上記実施形態に係るユーザグループの階層構造の一例を示す図
【図１６】上記実施形態に係るユーザ情報のインスタンスの例を幾つか示す図
【図１７】上記実施形態に係る権限テーブルの例を幾つか示す図
【符号の説明】
１…入力部
２…解析部
３…検索分作成部
４…ＤＢＭＳ（データベース管理システム）
５…ライブラリ
６…ユーザ情報
７…リソース
８…検索結果編集部
９…表示部
【図１】
2004178014.tif 000003
【図２】
2004178014.tif 000004
【図３】
2004178014.tif 000005
【図４】
2004178014.tif 000006
【図５】
2004178014.tif 000007
【図６】
2004178014.tif 000008
【図７】
2004178014.tif 000009
【図８】
2004178014.tif 000010
【図９】
2004178014.tif 000011
【図１０】
2004178014.tif 000012
【図１１】
2004178014.tif 000013
【図１２】
2004178014.tif 000014
【図１３】
2004178014.tif 000015
【図１４】
2004178014.tif 000016
【図１５】
2004178014.tif 000017
【図１６】
2004178014.tif 000018
【図１７】
2004178014.tif 000019