JP2005293134A - 階層型データベース管理システム、階層型データベース管理方法及び階層型データベース管理プログラム - Google Patents

Abstract

【課題】階層型データベースのクラス間の管理を容易にする。
【解決手段】階層構造をなすクラスが定義され、各クラスの属性は上位クラスの属性を継承する辞書情報を記憶する辞書情報記憶部１９と、レギュラークラスに割り当てられた第１のクラスコードとは独立した第２のクラスコードが第１のクラスコードとともに割り当てられ、レギュラークラスと識別するための識別情報が関連づけられ、レギュラークラスとは独立に階層構造をなすシノニマスクラスを、識別情報を読み取ることによりレギュラークラスとは区別可能に表示する辞書処理部１５とを備える。
【選択図】 図３

Description

本発明は、いわゆる階層型データベースを管理するための階層型データベース管理システム、階層型データベース管理方法及び階層型データベース管理プログラムに関する。

マイクロソフト社のオペレーティング・システム（ＯＳ）Ｗｉｎｄｏｗｓや、その他ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）といった汎用ＯＳにおいては、グラフィック・ユーザ・インタフェース（ＧＵＩ）としてツリー表示が採用されている。このツリー表示では、ツリー状のディレクトリ構造やファイル構造をユーザに視覚的に明示し、ユーザを特定のディレクトリやファイルへ誘導・移動（ナビゲート）する。

しかしながら、このツリー表示の各ノード間においては、上位のノードに含まれる情報（ファイル等）と下位のノードに含まれる情報の間には継承関係あるいは包含ないし部分集合関係等の関係はない。ルート・ノードから始まるツリー上のノードは、ファイルなどの情報を納める入れ物、つまりコンテナがツリー状に相互に接続されていることを示すにすぎない。この種の構造のことを、本明細書の記述では階層型ディレクトリ構造と呼び、本明細書における階層型データベースとは区別して扱う。

一方、オブジェクト指向データベース（ＯＯＤＢ）やオブジェクト・リレーショナル型データベース（ＯＲＤＢ）を代表とするデータベースでは、下位が上位分類の属性を継承する階層構造を持つ。このデータベースにおいては、継承に従って下位の分類では属性が累増する。この上位の属性を下位に継承することを通常「インヘリタンス」と呼ぶ。このような技術はたとえば“Object-Oriented Concepts, Databases, and Applications, Edited by Won Kim, 1989, ACM Press”（非特許文献１）その他多くの文献に記載されている。また、オブジェクト指向データベースにおいては、階層中の分類は「クラス」と呼ばれることが多い。一方、オブジェクト・リレーショナル型データベース（ＯＲＤＢ）においては、継承を許したテーブルがこれに相当し、上下関係をもつテーブル間において、上位のテーブルから下位のテーブルへ属性が継承される。すなわち、上位テーブルを構成するコラムのヘッダ情報が下位テーブルへ継承される。本明細書においては、ＯＯＤＢおよびＯＲＤＢを総称して「階層型データベース」と称す。各階層の分類に属する同じ属性種を持つデータを「インスタンス」と呼び、その集合をデータの「ポピュレーション」と呼ぶ。データのポピュレーションは、関係データベース（ＲＤＢ）あるいはＯＲＤＢにおいては、テーブルと呼ばれる構造に格納されるのが普通である。テーブルにおいてそれを構成する属性の並びをテーブルのヘッダと呼ぶ。

オブジェクト指向データベースを代表とする下位が上位分類の属性を継承する階層構造を持つ階層型データベースにおいては、継承に従って下位の分類では属性が累増する構造を持つ。従って、一方の辞書１のクラスから他方の辞書２のクラスへ特定の属性を輸入あるいは全ての属性の多重継承を設定する場合、輸入した辞書１のクラス属性は辞書２の分類体系の中で下位のクラスへ継承される。この場合、一般的には、辞書２の分類体系の中の前出のクラス以下の下位クラスでは、辞書１の当該属性定義の改訂に影響を受ける。また、ISO13584 Parts Library 規格Part24（規格-第２４分冊）に従う場合、言語依存の値を持つ文字型の属性について、多言語による値の表記が可能なものについては、属性の異同の判断も本質的に言語的な意味を持たないコードにより決定されるよう取り決められている。従ってISO13584規格に従って、例えばクラスをデータベースのテーブルとして実装する場合、テーブルのヘッダ（属性の並び）について（その文字列が、例えば“Product Name”等に代表される通常の言語的意味を持つコードではなく）通常の言語的意味解釈に依存しないコードにより２つのクラスの同一性を判断する必要がある。

従来、２つの標準分類辞書間で同じ概念を持つクラスがある場合、一方が他方に関係なくコードを振り、その両方の辞書を格納するデータベースでは、単に参照する側に仮のクラスを表すＧＵＩ標識を設けることにより、一方から他方の辞書クラスへの参照を示すのが通常であった。ＧＵＩ標識としては、多くはフォルダやディレクトリと同じアイコンが用いられる。この場合の問題点は、まず
（ｉ）全く属性の継承関係のない単純リンクとして扱った場合、一方の辞書と他方の辞書の間でそれぞれ独立に属性の定義改定を行うことが可能である。この定義改訂を許した場合、時間の経過と共に双方のクラスの持つ属性の種類およびその定義内容が乖離していく。このように、２つの標準分類辞書の２クラス間で同じ概念を安定して共有することが困難であった。また、同様の理由で一方の辞書において多言語に対してクラス名称がそれぞれの言語で与えられている場合、単純リンク方式では、個別に処理を用意しなければ、被参照クラスを参照しているクラスの方で被参照クラスの全ての言語名称を使う機能は実現できない。

一方、この参照関係を継承関係として扱った場合には、
（ｉｉ）一方の辞書のクラスの属性を他方の辞書のクラスが継承することになる。その結果、双方の同一性は保たれるが、一方の辞書が他方の辞書の属性定義改訂に影響を受ける。例えば、一方の辞書のクラスにおいて、属性を追加すると、これを参照している他方の辞書のクラスにおいてもデータベースの構造を変更して属性を追加することが必要になる、勿論この場合、双方のクラスや属性の識別コード等も一致していなければならない。
Object-Oriented Concepts, Databases, and Applications, Edited by Won Kim, 1989, ACM Press

上述したように従来の階層型データベースを管理する手法において、２つの標準分類辞書間で同じ概念を持つクラスがある場合、単に参照する側に仮のクラスを表すＧＵＩ標識を設け、一方から他方の辞書クラスへの参照を示すのが通常であった。

しかしながら、単に全く属性の継承関係のない単純リンクとして扱った場合には、時間の経過とともに双方のクラスの持つ属性の種類やその定義内容が乖離していき、２つの分類辞書の２クラス間で同じ概念を安定して共有することが難しかった。

また、２つの参照関係を継承関係として扱った場合には、一方の辞書のクラスの属性を他方の辞書のクラスが継承することとなり、双方の同一性は保たれるが、一方の辞書が他方の辞書の属性定義改訂に影響を与える。この場合、辞書の改訂作業が煩雑となる。

本発明は上記課題を解決するためになされたもので、その目的とするところは、階層型データベースのクラス間の管理を容易にする階層型データベース管理システム、階層型データベース管理方法及び階層型データベース管理プログラムを提供することにある。

本発明のある観点によれば、下位クラスが上位クラスの属性を継承し、かつ、各クラスがクラスを識別するためのクラスコードを持つ第１及び第２の分類体系を持ち、前記第１の分類体系はレギュラークラスを有し、前記第２の分類体系は、前記レギュラークラスと前記第１の分類体系のレギュラークラスを参照利用するシノニマスクラスとを有し、前記シノニマスクラスは、シノニマスクラスであることを識別するための識別情報と、該シノニマスクラスのクラスコードと、該シノニマスクラスが参照する前記第１の分類体系の前記レギュラークラスのクラスコードとを併せ持つ階層型データベースと、前記識別情報に基づき、前記シノニマスクラスを前記レギュラークラスとは識別可能に表示する表示手段とを備えたことを特徴とする階層型データベース管理システムが提供される。

本発明によれば、階層型データベースのクラス間の管理が容易になる。

以下、図面を参照しながら本発明の実施形態を説明する。

（第１実施形態）
図１は本発明の第１実施形態に係る階層型データベース管理システムで用いられるＧＵＩの一例を示す図である。この図１は、階層木（クラスツリー）、分類（クラス）及び属性を表示するためのＧＵＩの例である。特願２００２−３４００４１号に記載した通り、クラスツリー表示部１０１からクラスを選択すると、図１のクラス情報表示部１０２に、例えば、クラスを識別するクラスコード、定義、注記、バージョンなどのクラス情報が表示される。また、同時にそのクラスで利用できる属性の一覧が、プロパティリスト表示部１０３に表示される。

図２はクラスの階層構造と、各クラスの属性の概念図である。上位クラスの属性は下位クラスへ継承される。したがって、各クラスが図２のように属性を持つ場合、例えば、クラス「Ｔ０５：デスクトップＰＣ」では、クラス「Ｔ０２：オフィス／家庭製品」が持つ属性である「ＰＲＰ００１：品名」、「ＰＲＰ００２：メーカ名」、「ＰＲＰ００３：製品コード」、「ＰＲＰ００４：標準価格」と、クラス「Ｔ０３：デジタル製品」が持つ属性である「ＰＲＰ００５：電圧」と、クラス「Ｔ０４：パソコン」が持つ属性である「ＰＲＰ００６：標準メモリ容量」と、「ＰＲＰ００７：ＨＤＤ容量」とを継承する。さらに、クラス「Ｔ０５：デスクトップＰＣ」自身が持つ属性である「ＰＲＰ００８：ディスプレイ」を加えた８つの属性を利用することが可能となる。

従って、図１のように、クラスツリー表示部１０１でクラスコード「Ｔ０５：デスクトップＰＣ」を選択した場合、クラス情報表示部１０２には「Ｔ０５：デスクトップＰＣ」のクラス情報が表示され、プロパティリスト表示部１０３には、上記の８つのプロパティ（属性）がリストされる。

クラスには、実際のコンテンツデータを格納するためのコンテンツテーブルを持つことができ、このコンテンツテーブルのスキーマとなる属性集合は、クラスで利用できる属性の集合に含まれる。

図３は本実施形態に係る階層型データベース管理システム１００の一構成例を示す図である。例えば、製品情報を記述するための、階層情報およびインスタンスデータを格納し、要求があった場合にはそれをユーザに提示するサーバ装置１と、サーバ装置１へ製品情報を要求するクライアント装置３と、ファイル等で記述された辞書情報や各種情報、あるいはコンテンツ情報などを記憶するための外部記憶装置５から構成されている。

サーバ装置１、クライアント装置３及び外部記憶装置５は、ネットワーク４に接続され、互いにデータを送受信できる構成をなす。

外部記憶装置５は、図３では、ネットワーク４によってサーバ装置１と接続されているが、サーバ装置１内にあってもよい。サーバ装置１の入力部１２およびクライアント装置３の入力部３２は、キーボード、マウスなどの入力装置である。サーバ装置１の出力部１３およびクライアント装置３の出力部３３はＣＲＴ、液晶画面などの表示デバイスである。

サーバ装置１の制御部１１およびクライアント装置３の制御部３１は、それぞれ入力部１２および３２からの要求に従い、必要な処理を、各処理部１４〜１８に行わせる。各処理部１４〜１８は、処理に必要な情報を、各記憶部１９〜２３あるいは３４〜３６、外部記憶装置５から取り出して処理を行い、出力部１３あるいは３３に提示あるいは、外部記憶装置５に格納する。

この階層型データベース管理システム１００の代表的な処理動作を説明する。入力部３２から入力された処理要求を受けて、制御部３１はネットワーク４を介してサーバ装置１に処理要求を送信する。サーバ装置１の制御部１１は、受信した処理要求に基づき必要な処理を処理部１４〜１８のうちのいずれかに実行させる。処理部１４〜１８は、例えば記憶部１９〜２３のいずれかから必要となるデータを読み出し、あるいはネットワーク４を介してクライアント装置３あるいは外部記憶装置５から受信したデータに基づき必要な処理を行う。処理結果は、記憶部１９〜２３のいずれかに格納してもよいし、ネットワーク４を介して外部記憶装置５に送信され格納されるようにしてもよいし、クライアント装置３に送信してもよい。クライアント装置３に送信された処理結果は、出力部３３に表示され、あるいは記憶部３４〜３６のいずれかに格納される。

辞書処理部１５は、辞書情報記憶部１９に記憶されている辞書情報を取得する。そして、辞書処理部１５は、この辞書情報に基づきクラスツリーを構成しユーザに提示する。ユーザへの提示は、例えばサーバ装置１の制御部１１からネットワーク４を介してクライアント装置３の制御部３１にクラスツリーのデータが送信される。制御部３１は、受信したクラスツリーのデータを出力部３３に表示する。図４はユーザに提示されたクラスツリーの一表示例を示す図である。図４のクラスツリー表示部４１において、ユーザによって入力部１２などにより階層分類（クラス）が選択されると、辞書処理部１５は、そのクラスの種類（レギュラークラス、シノニマスクラスなど）に応じて、定義や注釈などのクラスが持つ情報を図１のクラス情報表示部１０２として表示し、あわせてそのクラスで定義および上位クラスから継承された属性のリストを図１のプロパティリスト表示部１０３として表示する。

クラスの種類は辞書情報記憶部１９に格納される。図５は辞書情報記憶部１９に記憶されたクラスの種類の記憶形式の一例を示す図である。図５に示すように、クラス、と、相手クラスと、クラスと相手クラスとの関係が関連付けて記憶されている。図５において、クラスまたは相手クラスは、クラスコードとクラス名称とから構成されている。例えば、図５の１番上の辞書情報のクラスのデータは、「Ｚ０３」がクラスコードであり、「Ｔ社パソコン」がクラス名称である。辞書処理部１５はこの辞書情報に基づきクラスツリーを構成する。

以降、特にことわらない限り、全ての実施の形態の説明は図５の例を前提として説明する。図５において、通常のクラス（以下ではレギュラークラスと称する）は、あるクラスの「下位クラス」として表記されている。例えば図５の上から３番目の辞書情報では、クラス「Ｚ０３：Ｔ社パソコン」は、クラス「Ｚ０２：パソコン購買部門」の下位クラスであることを示している。また、同時に、図５の上から１番目の辞書情報では、クラス「Ｚ０３：Ｔ社パソコン」は、別のクラスツリーに存在するクラス「Ｔ０４：パソコン」のシノニマスクラスであることを示している。シノニマスクラスとは、例えば（製造部門における製品分類に対して）販売部門での製品分類というように、ある団体や組織に属するユーザについて共通に使われるクラスの分類および表現である。このシノニマスクラスは、レギュラークラスと対比される概念である。すなわち、参照する側の分類（クラス）がシノニマスクラスであり、このシノニマスクラスにより参照される側の分類（クラス）がレギュラークラスである。この相手クラスとの関係は、レギュラークラスとシノニマスクラスとを識別する識別情報として機能する。また、図５から分かるすように、レギュラークラスとは独立したエンティティとしてシノニマスクラスが記述されている。

辞書処理部１５は、図４に示すようにクラス「Ｚ０３」をクラス「Ｚ０２」の下位クラスとして、クラスツリーを表示するとともに、上記シノニム情報、すなわちシノニマスクラスであることを示す情報に基づき、クラスツリーにシノニマスクラスであるマーク「ＳＹＮ」を表示する。これにより、ユーザにはクラス「Ｚ０３」がシノニマスクラスであることを明示的に示され、ユーザは簡単にレギュラークラスと異なるクラスであることを認識することができる。

辞書入出力処理部１４は、外部記憶装置５に存在する例えばＰａｒｔ２１形式の辞書ファイルを読み込み、解釈して、辞書情報記憶部１９に記憶する。辞書の形式はＰａｒｔ２１が通常であるが、他の形式でもよい。また、シノニマス設定情報などが別ファイルに書き込まれている場合には、その補助ファイルを一緒に、あるいは前後して読み込み、辞書情報記憶部１９に記憶する。また、辞書情報記憶部１９に記憶されている辞書情報を、Ｐａｒｔ２１形式等のファイルまたはその他の形で、出力部１３又は３３に提示、あるいは、外部記憶装置５に出力する。

クラス編集処理部１６は、ＧＵＩを用いて別途入力されたシノニマスクラス情報を編集処理し、辞書情報記憶部１９に記憶する。

コンテンツテーブルビュー設定処理部１７は、コンテンツテーブル記憶部２３から各コンテンツテーブルの構成を取得し、インスタンスデータの検索や表示のための条件を設定するためのＧＵＩをユーザに提示し、ユーザの入力に従って、コンテンツテーブルビュー情報記憶部２１に記憶する。また、コンテンツテーブルビュー設定処理部１７は、ＧＵＩからではなく、外部記憶装置５などに記憶されているファイルから条件を読み込んで、同様の処理を行う。

関連付け処理部１８は、クラス、各コンテンツテーブルビュー情報、コンテンツテーブルを関連付けるためのＧＵＩをユーザに提示し、ユーザからの入力、具体的には関連づけの指示の入力に従って関連付けを行い、関連付け情報記憶部３２に記憶する。また、関連付け処理部１８は、ＧＵＩからではなく、外部記憶装置５などに記憶されているファイルから条件を読み込んで、同様の処理を行う。

またマイフェイバリット情報記憶部２０は、シノニマスクラスとほとんど同様であるがユーザあるいはグループごとに定義できるマイフェイバリットクラスをユーザあるいはグループごとに記憶する。マイフェイバリットクラスは、ユーザあるいはグループごとに勝手に定義可能であるため、シノニマスクラスのように、辞書情報として取り扱わない。

マイフェイバリットクラスの設定は、クラス編集処理部１６で、シノニマスクラスの設定と同様のＧＵＩを用いて行うことができる。しかしながら、その際には、シノニマスクラスとは異なり、辞書情報としては扱わず、辞書情報記憶部１９ではなく、マイフェイバリットクラス情報記憶部２０に記憶させる。

図３の例では、辞書処理部１５、クラス編集処理部１６、コンテンツテーブルビュー設定処理部１７、関連付け処理部１８がサーバ装置１の構成要素となっているが、これらは、クライアント装置３の構成要素として同様に、サーバ装置１にあるデータベースにアクセスして、得たデータを元に、クライアント装置３で処理を行っても構わない。この場合、これら各処理部１５〜１８のすべて、あるいはいずれかは、クライアント装置３に設けられる。

図４は、Ｚ社購買部門が資材を購入する際に利用するクラスツリーの表示例である。Ｔ社とＸ社のクラスツリーが一緒に表示されている。Ｚ社の購買部門では、Ｔ社とＸ社の製品クラスツリーの中から製品分類（クラス）を選択する。Ｔ社購買部門の中にはパソコン購買部門がある。このパソコン購買部門ではパソコン購入以外の購入行為は行わないため、このパソコン購買部門の担当者が、クラスツリーをたどってその都度「パソコン」を表示させるのは面倒な作業となる。従って、ブックマークのように、パソコン購買部門で共通に利用するクラスをパソコン購買部門向けシノニマスクラスとして辞書情報処理部１５が登録することにより、パソコン購買部門で簡単に必要な製品分類（クラス）にジャンプすることが可能となる。

図４の例の場合、辞書情報処理部１５は、購買部門用のクラスツリーを辞書として作成し、製品分類Ｚ０１購買部門の下に製品分類Ｚ０２パソコン購買部門を作成し、それ以下にＺ０３およびＺ０４を、それぞれＴ０４およびＸ０３のシノニマスクラスとして設定する。

図６は、シノニマスクラスを別のウィンドウに表示させた例である。図６に示すように、辞書情報処理部１５により、クラスツリー表示部６１とは別のウィンドウであるシノニマスクラス表示部６２にシノニマスクラスが表示される。このシノニマスクラス表示部６２は、例えばボタン６３をユーザが選択することにより表示するようにしてもよい。

このように本実施形態は、異なる複数の分類体系間において実質的なクラス分類が同一と何らかの方法で確認されている場合に、実際のコンテンツをそのうちの一つのクラスにおき、その他のクラスを別なコードを持つが意味の等しい「シノニマスクラス」として扱う。これにより、同じコンテンツを異なる名称もしくは分類コードを持つ二重登録を避けることができる。

以下、ISO13584 Parts Library（通称「ＰＬＩＢ」）規格を例に本実施形態の作用効果を詳述する。ＰＬＩＢ規格においては、シノニマスクラスの概念は存在しない。このＰＬＩＢ規格に従えば、世界中の概念は、その根源をISO 6523 Internatioal Code Designator (ICD)規格により一意に定められる分類を発行する団体のコード（Supplier_BSU）、この団体が発行するクラスのコード（Class_BSU）、およびクラス毎に定義され下位クラスに継承される属性に割り当てられたコード（Property_BSU）により一意に特定される。これらSupplier_BSUとClass_BSUの組、およびSupplier_BSUとClass_BSUとProperty_BSUの組を用いる限り、同じ概念が２つの異なるコードで表されることはなく、またその必要もない。

ところが現実には、ＰＬＩＢ規格に厳密に従わない団体規格が存在する。そして、企業における分類は企業の生産や販売の組織体系の差異や都合によっても異なることが多い。この分類の相違に基づく混同を避けるために、意図的に他社の分類とは異なる名称や識別コードを割り当てる場合もある。従って、ＰＬＩＢ規格のみを利用して統一的分類を期待することはできない。

そこで本実施形態では、ＰＬＩＢ規格に厳密に従わない分類コード体系とISO13584規格とを関連づける。そして、この分類コード体系における分類が定義上実質的にISO13584規格に従って分類されたクラスと同一と判断可能な場合には、ＧＵＩ上の分類クラスにおいては、ＰＬＩＢ規格とは別のコードを持つ異なるクラス標識として扱う。一方、辞書情報記憶部１９上は、同一の分類としてコンテンツ（インスタンス）が生成される。したがって、コンテンツの二重登録の問題を避けることができる。また、同じ概念であるのに、一方の分類からは検索可能であるが他の分類からは検索できないという問題を避けることができる。

また、このようにして作られた見出しとしての分類情報であるシノニマスクラスを、ISO13584-Part42規格で定義されるCASE_OFを用いて記述する。または、このシノニマスクラスを、辞書形式を規定するISO13584-Part42（規格第42分冊）規格との上位互換性を保ちつつ特殊化した形式で国際規格に準拠する辞書情報として記述することができる。

これにより、他のデータベースシステムあるいはライブラリ管理システム（ＬＭＳ）においても、同じ分類を簡単に移植することにより実現することができる。シノニマスクラスとは、ある団体や組織に属するユーザについて共通に使われるクラスの分類および表現である。従って、異なる分類体系としてファイル出力し、他のデータベースもしくはＬＭＳに読み込ませて同一の分類を利用できることは非常に重要である。

また、シノニマスクラスには、レギュラークラスとは独立したエンティティとして記述するための付帯情報が関連づけられており、そこに記述されたシノニマスクラスとレギュラークラスの識別情報を読み出すことにより、シノニマスクラスを生成することができる。

このように本実施形態によれば、レギュラークラスに割り当てられたクラスコードとは独立したクラスコードがレギュラークラスのクラスコードとともに割り当てられ、レギュラークラスと識別するための識別情報が関連づけられ、レギュラークラスとは独立に階層構造をなすシノニマスクラスを、識別情報を読み取ることによりレギュラークラスとは区別可能に表示する。これにより、ある分類に付随する情報を他の標準分類から参照利用することが可能となる。ここで、付随情報とは、（i）ある分類の定義情報、(ii)ある分類に属する属性の定義やデータ型情報、(iii)ある分類に属するインスタンス・データまたはその集合であるコンテンツテーブルの一部または全部の属性のデータ値などである。また、この識別情報により、コンピュータ内の内部表現においてもシノニマスクラスをレギュラークラスと区別することができる。

その結果、あるユーザの集団が集団における慣習や通例に適合する辞書に従って分類構造を辿ることができる。そして、より馴染みやすい分類記号や標準名称を用いてユーザが分類を識別し選択することができる。

また、(i)システムにより出力するデータベースの階層構造において、レギュラークラスとは異なるエンティティとして記述する。入出力ファイルにおける階層構造の記述においても同様である。すなわち、レギュラークラスとは独立に、シノニマスクラスが名称、コード、シノニマスクラスの定義団体、あるいは利用組織、その他の付帯情報を持つことが可能になる。また、（ii）システムへの入力ファイルに記述されたシノニマスクラスの記述により、システム内部にシノニマスクラスを自動生成可能になる。さらに、（iii）(i)及び（ii）において使用するファイルを、他のデータベースに読み込ませてそのデータベースに同様のシノニマスクラスを自動生成することができる。

（第２実施形態）
図７〜図１０は、本発明の第２実施形態を説明するための図である。クラス「Ｚ０３：Ｔ社パソコン」とクラス「Ｔ０４：パソコン」は、シノニマスクラスとそのソースクラスの関係にあるものとする。

図７は、ソースクラス表示例を示す図である。ユーザが入力部１２を用いて、図７のクラスツリー表示部７１のシノニマスクラスにマウスカーソルを置く操作を行うことによって、バルーン７２などを用いてソースクラスのクラスコードなどを表示する。図７の例では、バルーン７２は、クラス名称およびクラスコードを表示している。このように、シノニマスクラスを入力部１２により選択すると、辞書処理部１５又はクラス編集処理部１６が、ソースクラスであるレギュラークラスのクラスコードを、シノニマスクラスのクラスコードとともに表示する。

図８は、シノニマスクラス表示例を示す図である。図８のクラスツリー表示部８１のソースクラスにカーソルを置くことによって、バルーン８２などを用いてシノニマスクラスのクラスコードなどを表示する。図８の例では、バルーン８２は、クラス名称およびクラスコードを表示している。このように、レギュラークラスを入力部１２により選択すると、辞書処理部１５又はクラス編集処理部１６が、シノニマスクラスのクラスコードを、ソースクラスであるレギュラークラスのクラスコードとともに表示する。

また、特別な表示要求があった場合に、クラスツリー内にそれぞれのシノニマスクラスの下位クラスとしてソースクラスのコードを表示する方法や、ソースクラスの下位クラスとしてシノニマスクラスを表示する方法も考えられる。

図９はソースクラス表示のための画面例を示す図である。図９のクラスツリー表示部９１において、例えばボタン３３が押された場合、辞書情報処理部１５により、シノニマスクラス「Ｚ０３：Ｔ社パソコン」の下位クラスと同様に、ソースクラス「Ｔ０４：パソコン」が表示される。

図１０はシノニマスクラス表示のための画面例を示す図である。図１０のクラスツリー表示部９６において、例えばボタン３４が押された場合、辞書情報処理部１５により、ソースクラス「Ｔ０４：Ｔ社パソコン」の下位クラスと同様に、シノニマスクラスが表示される。それぞれ下位クラスと同様に表示されたソースクラスおよびシノニマスクラスは、通常の下位クラスと表示を別に、例えば、斜字を用いたり或いはマークを併記することで、はっきりとそれらがシノニマスクラスにおけるソースクラスであること、あるいは、ソースクラスにおけるシノニマスクラスであることを示している。

シノニマスクラスおよびそのソースクラスにおけるお互いの表示方法は、上記に限らず、例えば、バルーンの代わりに、右クリックなどで別画面を出して表示する方法、図１のクラス情報表示領域１０２に表示する方法など、様々な方法が考えられる。

このように本実施形態によれば、レギュラークラスのクラスコードをシノニマスクラスの参照先コードとして表示し、かつシノニマスクラスのコードをシノニマスクラスコード（同義分類コード）として表示することができる。

（第３実施形態）
本実施形態はＩＳＯ１３５８４規格で定義できる辞書におけるＣａｓｅＯｆを利用してシノニマスクラスを記述する実施形態に関わる。

ＩＳＯ１３５８４規格で定義できる辞書は単純木である。すなわち、クラスは一つの上位クラスしか持たない単純継承関係をなす。しかしながら、複数のクラスから、それぞれが利用できる属性を複数、インポートすることができるＣａｓｅＯｆという概念がある。このＣａｓｅＯｆを利用することにより、クラス間で部分継承が可能となる。

辞書処理部１５又はクラス編集処理部１６が、このＣａｓｅＯｆを参照してクラスツリーを生成する。

図１１は本実施形態に係るクラスツリーの一例を示す図である。図１１では、クラス１、クラス２、クラス３は単純木であり、単純継承の階層関係で結ばれており、クラス１１、クラス１２も単純木であり、階層関係で結ばれており、それぞれ上位クラスの属性を継承している。

図１１中、ドットプリントが背景となっている属性は、上位階層から継承されたものをあらわしている。すなわち、クラス２では、クラス１から継承された属性１と属性２を属性として持つ。このように、子クラスが複数の親クラスから属性を継承する多重継承関係をなす。

クラス２はＣａｓｅＯｆクラスで定義されており、クラス１１から属性１１をインポートしている。属性をインポートすることにより、クラス２では、それ以降、属性１１を自身の属性として利用することが可能となる。

なお、以下の実施形態の説明では、ＣａｓｅＯｆで参照される側のクラス（レギュラークラス）を「参照クラス」、インポートされた属性を「インポートプロパティ」と呼ぶ。図１１の例では、「参照クラス」はクラス１１、「インポートプロパティ」は、属性１１である。

本実施形態では、このＣａｓｅＯｆという概念を拡張することにより、クラス間の参照関係を利用したシノニマスクラスの表現が可能となる。

図１２はＰａｒｔ２１ファイル形式を利用したＩＳＯ１３５８４規格における辞書情報の記述例を示す図である。Ｐａｒｔ２１ファイルは、ＩＳＯ１３５８４規格で定義されているＥＸＰＲＥＳＳによるスキーマに従い記述される。スキーマはスキーマを構成する基本単位であるエンティティと、そのアトリビュートからなる。エンティティはそれぞれ名称をもつ。

図１２の中段に記載の“ＤＡＴＡ；”以降の記述において、各行の先頭のシャープ記号から始まる番号は各エンティティに割り当てられた番号であり、これによりエンティティが識別可能である。イコール記号の後ろには、エンティティ名が記載されている。エンティティ名の後ろには、括弧記号でくくられたアトリビュートがカンマ区切りで並べられる。アトリビュートの中に記載されたシャープ記号で始まる番号は、別の行で定義されているエンティティを参照することを示している。

図１３は、Ｐａｒｔ２１ファイルにおけるクラス情報を記述した部分を抜粋して示した図である。図１３中、符号１３１で示される＃１０２６から＃１０２５の行には、クラスＺ０２：パソコン購買部門に関わる情報が記述されている。符号１３２で示される＃１０１９から＃１０１８の行には、クラスＺ０３：Ｔ社パソコンに関わる情報が記述されている。符号１３３で示される＃１０１２から＃１０１１の行には、クラスＺ０４：Ｘ社パソコンに関わる情報が記述されている。

ＣａｓｅＯｆクラスを表すエンティティは通常のクラスを表すエンティティの下位エンティティとして定義されている。ＣａｓｅＯｆクラスを表すエンティティの１５番目までがクラスを表すエンティティから継承したクラスの情報を表すためのアトリビュートである。１６番目以降のアトリビュートは、ＣａｓｅＯｆの情報を表す。

すなわち、符号１３２の＃１０２０の行を例に取ると、１番目のアトリビュート「＃１０１９」から、１５番目のアトリビュート「＄」までがＺ０３：Ｔ社パソコンのクラス情報を、１６番目のアトリビュート「＊」以降がＣａｓｅＯｆの情報を表している。各アトリビュートはそれぞれ、
１番目がクラスを一意に識別するコードすなわち「クラスＢＳＵ」、
４番目がクラスの「標準名称」、
８番目がクラスの「備考（リマーク）」、
９番目が「上位クラス」、
２１番目がＣａｓｅＯｆで参照するクラスの識別子「参照クラスＢＳＵ」、
２２番目がＣａｓｅＯｆで参照したクラスからインポートした属性、すなわち「インポートプロパティ」の集合
を表している。したがって、符号１３２の＃１０２０およびこの行が参照している行から読み取れる情報は具体的には次の通りである。

エンティティ名からわかるように、クラスの種類はＣａｓｅＯｆクラス（component_class_case_of）である。「クラスＢＳＵ」はＺ０３、「標準名称」はＴ社パソコン、「備考」は＄ＳＹＮＯＮＹＭ、「上位クラス」はＺ０２、「参照クラス」はＴ０４である。「インポートプロパティ」はヌル（存在しない）ということを表している。

この図１３に示されるＰａｒｔ２１ファイルにおけるクラス情報を通常のＩＳＯ１３５８４準拠のデータベース管理システムに読み込ませても、クラスＺ０３は、クラスＴ０４を参照クラスとする通常のＣａｓｅＯｆクラスとして認識される。また、アトリビュート備考に書かれた“＄ＳＹＮＯＮＹＭ”もユーザが読み取り可能な（ヒューマンリーダブルな）文字列以外の情報をもたない。

本実施形態では、予め決めておいた特殊な文字列「$SYNONYM」をＣａｓｅＯｆエンティティのアトリビュートの一つ「備考」に記述する。これにより、本実施形態の階層型データベース管理システム１００で読み込んだ場合、そのクラスをシノニマスクラスとして、且つその参照クラスをシノニマスクラスのソースクラスとして認識し、辞書情報記憶部１９に格納し、シノニマスクラスとして階層型データベース管理システム１００内で扱うことができる。すなわち、備考欄の“＄ＳＹＮＯＮＹＭ”は、他のクラスからシノニマスクラスを識別する識別情報として認識される。

また、通常ＣａｓｅＯｆエンティティのアトリビュートの一つを利用してシノニマスクラスであるという情報を付加していることにより、通常のＰａｒｔ２１ファイルとしてもコンパチビリティが保証される。

このように本実施形態は、階層型データベースの有する分類体系とは異なる分類体系のクラス及び属性をインポートするエンティティによりシノニマスクラスが記述され、かつ階層型データベースは子クラスが唯一の親クラスを備える単純継承構造をなし、しかもクラス編集処理部１６は、階層型データベースに基づき、子クラスが複数の親クラスを備えた多重継承関係として処理することができる。

（第４実施形態）
本実施形態は、第３実施形態とは異なる手法によりシノニマスクラスを記述する実施形態に係わる。

本実施形態では、シノニマスクラスをＣａｓｅＯｆクラスではなく、通常クラスとして記述する。そして、アトリビュート備考に、１）シノニマスクラスであるという情報、２）ソースクラスを識別するための情報を付加することにより、シノニマスクラスを記述する。

図１４は、本実施形態に係るＰａｒｔ２１ファイルにおけるクラス情報を記述した部分を抜粋して示した図である。符号１４１，１４２及び１４３で示される行は、それぞれ第３実施形態の図１３の符号１３１，１３２及び１３３で示される行の記述に対応する。

すなわち、符号１４２で示される＃１０１９から＃１０１８の行には、クラスＺ０３：Ｔ社パソコンに関わる情報が記述されている。符号１４０３で示される＃１０１２から＃１０１１の行には、クラスＺ０４：Ｘ社パソコンに関わる情報が記述されている。

符号１４２の行＃１０２０を例に取ると、クラスの種類は、エンティティ名より、通常クラス（Ｃｏｍｐｏｎｅｎｔ＿ｃｌａｓｓ）、「クラスＢＳＵ」はＺ０３、「標準名称」はＴ社パソコン、「備考」は＄SYNONYM-140/T_Company//.T04-001、「上位クラス」はＺ０２、「インポートプロパティ」はヌル（存在しない）ということを表していることになる。図１３の場合と同様に、「備考」に記述された、「$SYNONYM-140/T_Company//.T04-001」は、通常のデータベース管理システムに読み込ませても文字列以外の意味を持たない。

これに対して本実施形態の階層型データベース管理システム１００の場合、例えば、通常クラスとして記述されたクラス情報のアトリビュート備考にある最初の８文字が$SYNONYMと一致する場合には、辞書情報処理部１５は、そのクラスをシノニマスクラスとして、且つその９文字目のハイフン記号から先の文字列をシノニマスクラスのソースクラスの識別子として認識し、辞書情報記憶部１９に格納する。これにより、シノニマスクラスとして階層型データベース管理システム１００内で扱うことができる。

また、通常ＣａｓｅＯｆエンティティのアトリビュートの一つを利用してシノニマスクラスであるという情報を付加していることにより、通常のＰａｒｔ２１ファイルとしてもコンパチビリティが保証される。

このように本実施形態は、第３実施形態と同様に、階層型データベースの有する分類体系とは異なる分類体系のクラス及び属性をインポートするエンティティによりシノニマスクラスが記述され、かつ階層型データベースは子クラスが唯一の親クラスを備える単純継承構造をなし、しかもクラス編集処理部１６は、階層型データベースに基づき、子クラスが複数の親クラスを備えた多重継承関係として処理することができる。

例えば、シノニマスクラスコードを持つクラスについて、ISO10303-21（所謂「STEPファイル」）に定めるファイルを用いた場合の入出力では、ISO13584−24において定義されている他の分類体系からのクラスや属性のインポートのための構造、すなわち”CASE_OF”（item_class_case_of, component_class_case_of, material_class_case_of、等）のエンティティを利用して記述する。かつ、CASE_OFに付帯するコメントや注釈を用いる。これにより、その記述が実際にはシノニマスクラスであることが明記され、ISO13584規格とのコンパチビリティが保持される。また、ISO13584規格の要請するクラスが唯一つの親クラスを持つ単純継承を入出力ファイルにおいて維持することができる。これとともに、一旦データが読み込まれると、実質的には多重継承もしくは多重分類が可能となる。

（第５実施形態）
本実施形態はＰａｒｔ２１ファイル形式以外のファイル形式を利用したシノニマスクラスの記述の実施形態に関する。

ＩＳＯ１３５８４規格では、辞書情報はＰａｒｔ２１ファイルで交換するのが通常であるが、Ｐａｒｔ２１ファイル以外にも、ＸＭＬの形式（Ｓｉｍｐｌｉｂ）やクラス問い合わせ言語（ＣＱＬ）或いは、ＣＳＶ等によるテーブルライクな辞書記述方法等もある。これらの記述形式も、Ｐａｒｔ２１ファイルのエンティティとアトリビュートを簡素化して、記述することができるため、第３実施形態や第４実施形態のＰａｒｔ２１ファイルと同様の処理が実現できる。

図１５〜図１７は本実施形態に係るシノニマスクラスの記述例を示す図である。

図１５は、ＣＳＶ等によるテーブルライクな辞書記述方式の一例を示す図である。図１５に示すように、クラス情報を表すエンティティのアトリビュートを項目とし、ＣＳＶファイルの一行でクラス一個の情報を表す。この図１５の場合、項目「クラスタイプ」にエンティティ名を記述する。この項目「クラスタイプ」に、シノニマスクラスであることを示す特殊な文字列、例えば、SYNONYM_COMPONENT_CLASSと記述する。これにより、階層型データベース管理システム１００で他の通常クラスとは異なるシノニマスクラスとして扱うことができる。また、項目「参照先クラス」には、通常ＣａｓｅＯｆクラスの参照クラスが記述されるが、この項目「クラスタイプ」を利用して、シノニマスクラスのソースクラスを記述することができる。

同様に、他の項目、例えば項目「備考」に、前述したように、シノニム情報を記述することによっても実現できる。

図１６は、クラス問い合わせ言語（ＣＱＬ）でクラス定義を行う一例を示す図である。図１６では、通常クラスで定義する例を示しており、Remarkアトリビュートにシノニム情報（シノニマスクラスであること、およびソースクラスの情報）を含む。

図１７は、クラス問い合わせ言語（ＣＱＬ）でクラス定義を行う別の一例を示す図である。図１７では、ＣａｓｅＯｆクラスで定義する例を示しており、Remarkアトリビュートにシノニム情報（シノニマスクラスであること）を含み、is_case_ofアトリビュートにソースクラスの情報を含んでいる。

このように本実施形態によれば、シノニマスクラスはインスタンスを持たない場合に、クラス編集処理部１６は、シノニマスクラスであることを示す識別情報が記述されたファイルを読み出すと、その識別情報に基づきシノニマスクラスであることを検出することができる。

例えば、シノニマスクラスであることを、参照する側のクラスに付加属性(アトリビュート)、もしくはNotesあるいはremark等の欄を利用した特殊なコメント等の付加情報を持たせることで表現できる。これにより、通常のクラスと区別可能にしてデータベースに入出力することにより、シノニマスクラスであることを検出できる。

（第６実施形態）
本実施形態は、ＥＸＰＲＥＳＳによるシノニマスクラスの記述に関する実施形態である。

図１８は、ＩＳＯ１３５８４規格で定められているエンティティを拡張したＥＸＰＲＥＳＳによるシノニマスクラスの記述の一例を示す図である。また、図１９は関連エンティティを含んだＥＸＰＲＥＳＳ−Ｇの記述例を示す図。図１９に示す例では、通常クラスエンティティ（item_class１８１, component_class１８２, material_class１８３, feature_class１８４）の下位エンティティとして定義されているＣａｓｅＯｆクラスエンティティ(それぞれ、item_class_case_of１８５, component_class_case_of１８６, material_class_case_of１８７, feature_class_case_of１８８)のさらに下位エンティティとして、シノニマスクラス（それぞれ、synonym_item_class１８９, synonym_component_class１９０, synonym_material_class１９１,
synonym_feature_class１９２）を拡張して定義する。

図２０は、この図１９に示す拡張エンティティを利用してＰａｒｔ２１ファイルを記述した例である。符号２０１は、クラス「Ｚ０２：パソコン購買部門」の定義情報を記述したもの、符号２０２は、クラス「Ｚ０３：Ｔ社パソコン」の定義情報を記述したもの、符号２０３は、クラス「Ｚ０４：Ｘ社パソコン」の定義情報を記述したものである。

これら図１９や図２０に示したように、ＣａｓｅＯｆクラスの下位エンティティとして、アトリビュートを追加せずにシノニマスクラスを表すエンティティを拡張する。すなわち、レギュラークラスのサブクラスとしてシノニマスクラスを定義する。これにより、シノニム名を上位のエンティティに変換するだけで、シノニマスクラスを解さないＩＳＯ１３５８４規格に対応した通常のデータベース管理システムに対しても、送ることができる。

また、この例では、ＣａｓｅＯｆクラスの下位エンティティとしたが、直接、通常クラスの下位エンティティとして定義するなど、他のＥＸＰＲＥＳＳ拡張でもよい。

このように本実施形態によれば、シノニマスクラスはインスタンスを持たず、シノニマスクラスは階層型データベースの有する分類体系において定義されたエンティティのサブクラスとして階層型データベースで定義される場合に、クラス編集処理部１６は、サブクラスに基づきシノニマスクラスであることを検出することができる。

（第７実施形態）
本実施形態は、シノニマス情報を別のファイルに持たせた実施形態に係わる。

図２１〜図２４は本実施形態に係るシノニマス情報の記述を説明するための図である。

図２１及び図２２は、第１の記述例を示しており、図２３及び図２４は第２の記述例を示している。

図２１と図２２は対になっている。図２１は、シノニマスクラスを通常のクラス、すなわちレギュラークラスとして記述したＰａｒｔ２１ファイルの一例を示す図である。符号２１１はクラスコードＺ０２のクラスの定義情報、符号２１２はクラスコードＺ０３のクラスの定義情報、符号２１３はクラスコードＺ０４のクラスの定義情報を示している。図２２は、図２１で通常クラスで定義されたシノニマスクラスを、シノニマスクラスとして認識するための情報を記述したシノニマス情報ファイルの一例を示す図である。図２２のシノニマス情報ファイルには、シノニマスクラスとするクラス（図２２ではクラスＺ０３、Ｚ０４）の識別子（クラスＢＳＵ）、ソースクラスとするクラス（図２２ではクラスＴ０４、Ｘ０３）の識別子（クラスＢＳＵ）が記述されている。階層型データベース管理システム１００は、図２１のＰａｒｔ２１ファイルを階層型データベース管理システム１００に読み込む際に、辞書入出力処理部１４が、補助ファイルである図２２のシノニマス情報ファイルをＰａｒｔ２１ファイルとともに、あるいは、前後して読み込むことにより、クラスコードＺ０３及びＺ０４のクラスをシノニマスクラスとして登録する。

図２３と図２４は対になっている。図２３は、シノニマスクラスを通常のＣａｓｅＯｆクラスとして記述したＰａｒｔ２１ファイルの一例を示す図である。図２４は、通常ＣａｓｅＯｆクラスで定義されたシノニマスクラスを、シノニマスクラスと認識するための情報を記述したシノニマス情報ファイルの一例を示す図である。図２４のシノニマス情報ファイルには、シノニマスクラスとするクラス（図２４ではクラスＺ０３、Ｚ０４）のクラス識別子（クラスＢＳＵ）が記述されている。階層型データベース管理システム１００は、図２３のＰａｒｔ２１ファイルをシステムに読み込む際に、辞書入出力処理部１４は、補助ファイルである図２４のシノニマス情報ファイルをＰａｒｔ２１ファイルとともに、あるいは、前後して読み込むことにより、クラスＺ０３及びＺ０４をシノニマスクラスとして登録する。

したがって、シノニマスクラス情報を、Ｐａｒｔ２１ファイルとは別ファイルにもたせることにより、通常のＩＳＯ１３５８４に準拠したデータベース管理システムとしては、シノニマス情報を含まずにＰａｒｔ２１ファイルを扱うことができる。

このように本実施形態によれば、シノニマスクラスがインスタンスを持たず、階層型データベースの有する第１の分類体系に従った第１のファイルやデータベースと、第１の分類体系とは異なる第２の分類体系に従った第２のファイルやデータベースと、第１の分類体系と第２の分類体系のシノニマス参照情報が記述された第３のファイルやデータベースとによりシノニマスクラスを記述しておけば、クラス編集処理部１６は、第３のファイルやデータベースのシノニマス参照情報に基づきシノニマスクラスであることを検出することができる。

（第８実施形態）
本実施形態は、シノニマスクラスの表示の実施形態に関する。

図２５は本実施形態に係るシノニマスクラスの表示例を示す図である。クラスツリー表示部２５１、クラス情報表示領域２５２及びプロパティリスト表示領域２５３からなる。

図２６はクラス編集処理部１６によるシノニマスクラス表示動作のフローチャートを示す図である。

図２５に示すように、ユーザがクラスツリー表示部２５１で、マウスをクリックするなどの入力部１２の操作によりクラスを選択した場合（ステップＳ２６１）、クラス編集処理部１６は、そのクラスが通常クラスかシノニマスクラスかを判定する（ステップＳ２６２）。通常クラスの場合は、クラス編集処理部１６は、選択されたクラスのクラス情報やプロパティリストを表示する（ステップＳ２６８）。選択したクラスがシノニマスクラスの場合には、クラス編集処理部１６は、参照クラス履歴リストに選択されたクラスを追加する（ステップＳ２６３）。そして、この参照クラス履歴リストに記述されたクラスの参照先クラスを例えばクラス編集処理部１６が辞書情報記憶部１９を参照することにより特定する（ステップＳ２６４）。そして、クラス編集処理部１６は、参照先クラスがシノニマスクラスか否かを判定する（ステップＳ２６５）。シノニマスクラスでない場合には、参照クラス履歴リストに含まれるクラスと、参照先クラスとを選択状態にし（ステップＳ２６９）、これら選択されたクラスの情報を表示し、さらにプロパティリスト表示部に選択されたクラスが持つプロパティのリストを表示する（ステップＳ２６８）。

（ステップＳ２６５）で参照先クラスがシノニマスクラスと判定された場合、クラス編集処理部１６は、さらに参照先クラスが既に参照クラス履歴リストに含まれていないか判定する（ステップＳ２６６）。含まれていない場合、その参照先クラスを参照クラス履歴リストに追加する処理（ステップＳ２６３）に戻る。含まれている場合、クラス編集処理部１６は、参照クラス履歴リストに含まれるクラスをすべて選択状態にし、参照がループになっている旨のエラーメッセージを表示する（ステップＳ２６７）。

このように、ソースクラスも選択状態にし、ソースクラスのクラス情報やプロパティリストを表示することにより、シノニマスクラスがブックマークと同じような役割を果たし、ユーザが簡単にソースクラスへアクセスできるようになる。

図２５に示す例では、Ｚ０３：Ｔ社パソコンを選択すると、同時に、Ｔ０４：パソコンも選択状態となり、クラス情報表示領域２５２には、Ｔ０４：パソコンのクラス情報が、プロパティリスト表示領域２５３には、Ｔ０４のプロパティリストがクラス編集処理部１６により表示される。これは、シノニマスクラスＺ０３が選択されている以外は、Ｔ０４が選択されている画面と変わらない。

また、クラスツリー表示部２５１でのシノニマスクラスからソースクラスへの参照を、図９のような形態をとった場合で、Ｚ０３：パソコンが選択された場合には、クラス編集処理部１６は、クラスＺ０３のクラス情報とプロパティリストを表示する。クラスＺ０３の下位に仮想的に表示されているＴ０４：Ｔ社パソコン（斜字体）が選択された場合には、クラス編集処理部１６が、実体であるソースクラスＴ０４：Ｔ社パソコンのクラス情報とプロパティリストを表示するように、さらに一段階設けてもよい。

このように本実施形態によれば、画面に表示されたシノニマスクラスをユーザが入力部１２を用いて選択した場合、クラス編集処理部１６は、そのシノニマスクラスの選択を検出し、シノニマスクラスが参照するレギュラークラスを読み出し画面に表示することができる。

（第９実施形態）
本実施形態は検索クエリーの自動変換の実施形態に係わる。

図２７は本実施形態の自動変換機能を説明するための図である。

本実施形態ではシノニマスクラスはインスタンスデータを持たない。仮に持っていたとしても、それはソースクラスに存在するインスタンスデータの補足情報に過ぎず、それ自体では意味を持たない。

図２７のように、クラスツリーが構成されていると仮定する。すなわち、クラス「Ｚ０３：Ｔ社パソコン」は、クラス「Ｔ０４：パソコン」のシノニマスクラスであるとする。そして、ソースクラス「Ｔ０４：パソコン」の下位クラス「Ｔ０５：デスクトップＰＣ」にインスタンスデータの集合であるコンテンツテーブルＴａｂｌｅ０１が、同じく下位クラス「Ｔ０６：ノートＰＣ」にコンテンツテーブルＴａｂｌｅ０２が存在していたとする。

通常のクラスであるＴ０４に対して、例えば、以下の（１）コンテンツの検索クエリーが要求されるとする。

Select PRP001, PRP003 from T04* where PRP006 = 512； …（１）
この検索クエリー（１）により、クラス編集処理部１６によりクラスＴ０４以下（この場合、Ｔ０４、Ｔ０５、Ｔ０６）のクラスに存在するインスタンスデータで、メモリが５１２であるものをプロパティが品名、製品コードについて表示される。すなわち、Ｔａｂｌｅ０１のエクイエム０１、エクイエム０３及びＴａｂｌｅ０２のダイナ００１のインスタンスデータが結果として表示される。

クラス編集処理部１６は、このインスタンスデータ表示をクラスコードＺ０３のシノニマスクラスに対して実行した場合でも、Ｚ０３以下に存在するインスタンスデータではなく、クラスコードＴ０４のソースクラスに対して行った結果を出力するものとする。すなわち、クラス編集処理部１６は、以下の検索クエリー（２）を、図５に記述された情報から、クラスコードＺ０３のクラスがシノニマスクラスであり、そのソースクラスのクラスコードがＴ０４であることを読取り、クラスコードＺ０３のクラスをクラスコードＺ０４のクラスに変換した検索クエリー（１）を実行する。

Select PRP001, PRP003 from Z03* where PRP006=512； …（２）
上記の例は、インスタンスデータの検索ターゲットにシノニマスクラスが選ばれたときの処理であるが、同様に、他の処理要求がシノニマスクラスに対して発生した場合にも、そのソースクラスに対して処理を行う。

このように本実施形態によれば、入力部１２を用いた操作や、データ処理の対象がシノニマスクラスであることをクラス編集処理部１６が検出した場合に、シノニマスクラスが参照するレギュラークラスの処理を実行する。これにより、シノニマスクラスが参照するレギュラークラスの処理が容易になる。

本実施形態は、例えばインスタンスデータのコピーや検索ターゲットを選ぶ等の操作時に、対象を直接ＧＵＩ上で選択する場合に利用可能である。あるいは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）における処理要求の記述時にコードやシンボルを用いて対象を記述する場合にも利用可能である。

（第１０実施形態）
本実施形態はシノニマスクラスに関する具体的な処理を示した実施形態に係わる。

図２８は、シノニマスクラスとソースクラスの関係を示した図である。

クラス２をシノニマスクラスとする。クラス２のソースクラスは、クラス１１である。クラス１、クラス２、クラス３は、それぞれ上位／下位の階層関係を持つため、上位クラスの属性を継承する。また、クラス１１はシノニマスクラス２のソースクラスであるが、通常クラスである。クラス１１は、クラス１２を下位クラスとして持つ。

シノニマスクラスとソースクラスはそれぞれ独立に階層をなし、属性などのインポートは許さずお互いに干渉しない。ただし、シノニマスクラスに対する処理に関しては、ソースクラスに対するものとして処理する。また、シノニマスクラスは、通常の製品情報を表すようなインスタンスデータを持たない。仮に持っていた場合でも、それはソースクラスが持つインスタンスデータの補助情報にすぎない。

なお、このシノニマスクラスとレギュラークラスとの間における属性などのインポートや継承の禁止は、例えばクラス編集処理部１６が、そのようなインポートを要求するＧＵＩ上の操作や、入出力ファイルの記述を検出した場合に、そのような継承等の禁止を示す表示をすることにより、ユーザに知らされる。もちろん、クラス編集処理部１６は、そのような継承等を含むデータ処理は実行しない。

このように、シノニマスクラスはソースクラスへの参照だけを表すという形態をとることにより、同等のクラスを二つの辞書で用意する場合と異なり、インスタンスデータの重複分散を避けることができる。また、参照する側であるＣａｓｅＯｆクラスと参照される側である参照クラスの関係では、各々にインスタンスデータの作成が可能であるが、参照クラスで定義されているインポートプロパティに変更があった場合に、ＣａｓｅＯｆクラスでの反映が容易でないなどの問題がある。しかしながら、この問題も、参照する側のシノニマスクラスでインスタンスデータの作成および属性のインポートを許さないことにより、参照される側の属性の変更を考慮しなくてもよいという利点がある。

本実施形態の階層型データベース管理システム１００内に、シノニマスクラスを登録する様々な方法を記述しているが、本効果のために、登録時に、シノニマスクラスに対しては、インポートプロパティおよび通常のインスタンスデータの登録は無視あるいはリジェクトし得る。

このように本実施形態では、２つの辞書体系間で、一方から他方への属性の輸入もしくは属性の部分的継承に基づく参照関係を保持し、かつ各々の辞書において独立に属性の継承を行う。例えば、辞書１と辞書２があり、それぞれ継承される属性の組が複数あるとする。そして、属性の組のうちの１つを用いてクラス間の親子関係が決定され、すなわち辞書に属するクラスの構成するグラフ構造が決定されるとする。この場合、この親子関係を決定するための属性は辞書の分類属性と呼ばれる。辞書１から輸入された属性Ｐ１が辞書２の分類属性に編入されない限りは、属性Ｐ１が辞書２の辞書構造に影響を与えることはない。クラスにおいて、継承する属性を複数のサブグループに分割してそれぞれに継承する方式は、既に特願２００２−３３９９２９号に「複数の典型属性の継承」として詳述されている。本実施形態は、この「複数の典型属性の継承」を異なる辞書間のクラスの参照関係に適用する。この場合、属性の継承を実現しつつ、かつ複数の辞書において独自にクラス分類体系を構築する手法と構造が提供される。

このように、本実施形態によれば、レギュラークラスが第１の属性を有し、シノニマスクラスは第２の属性を有する場合に、レギュラークラスを含む第１の分類体系において第１の上位クラスから第１の下位クラスに継承される第１の継承属性を設定し、この際に、第１の下位クラスには、シノニマスクラスの持つ第２の属性が継承されないように第１の分類体系を設定することができる。また、シノニマスクラスを含む第２の分類体系において第２の上位クラスから第２の下位クラスに継承される第２の継承属性を設定し、この際に、第２の下位クラスには、レギュラークラスの持つ第１の属性が継承されないように第２の分類体系を設定することができる。

（第１１実施形態）
本実施形態はコンテンツテーブルビューを利用した実施形態に係わる。

図２９はクラスが持つ各種情報を示す図である。

クラスは、属性のほかに、インスタンスデータの集合であるコンテンツテーブルを持つ。また、それ以外に、典型属性の組、表示属性の組、表示条件（表示順など）、クエリーコンディション、セキュリティ条件などのインスタンスデータの検索や表示のための条件を持つ。以下では、これらインスタンスデータの検索や表示のための条件（処理条件）を、クラスが持つコンテンツテーブルビューと呼ぶ。このコンテンツテーブルビューは階層構造に従い、属性と同様に上位クラスから下位クラスへ継承されるものとする。

典型属性とは、ユーザに特に注目させたい属性である。この典型属性は、例えば、検索の際には条件入力が必須または推奨の属性、インスタンスデータ登録時に入力が必須または推奨の属性などを指し、インスタンスデータを一意に識別するためのキー属性とは異なる。典型属性は、特願２００２−３３９９２９号に記載されているように、他の属性とは表示を代えて、例えば、属性名にマークを付けるなどして表示されてもよい。

表示属性とは、コンテンツテーブルを形成する属性集合の中から、ユーザに表示する属性を指す。表示条件とは、表示属性の中での表示順番などを指す。クエリーコンディションとは、コンテンツテーブルの要素であるインスタンスデータの中で、そのインスタンスデータを表示させるかを絞り込むための条件を指す。また、セキュリティ条件とは、前述の各種条件をユーザ或いはグループごとに、制限するものである。

例えば、図２７にあるＴａｂｌｅ０１に対して、典型属性の組がＰＲＰ００１、ＰＲＰ００２、ＰＲＰ００３、表示属性の組がＰＲＰ００１、ＰＲＰ００２、ＰＲＰ００８、クエリーコンディションがＰＲＰ００６＞＝５１２、セキュリティ条件が全員であったとする。この場合、これらコンテンツテーブルビューを組み合わせて、コンテンツテーブルがコンテンツテーブルビュー設定処理部１７により全てのユーザに対して表示される。図３１はこのコンテンツテーブルビューの表示例を示す図である。この図３１の例の場合は、典型属性が表示属性よりも優先されているため、典型属性の組に含まれていて表示属性の組には含まれないＰＲＰ００３も表示されるが、表示属性を優先させても構わない。

これらコンテンツテーブルビューは、コンテンツテーブルビュー設定処理部１７により１つのクラスに複数ずつ作成可能であり、どのように組み合わせてクラスと関連付けてもよい。

図３２はコンテンツテーブルビューの登録のためのＧＵＩの一例を示す図である。図３３はコンテンツテーブルビューの登録のための設定ファイルの一例を示す図である。コンテンツテーブルビューはこの図３２のようなＧＵＩからコンテンツテーブルビュー設定処理部１７により登録してもよいし、図３３のような設定ファイルなどを用いてコンテンツテーブルビュー設定処理部１７により登録してもよい。図３３の設定ファイルは、コンテンツテーブルビューの種類をいくつか組み合わせて一つのものとして取り扱うことも可能である。

図３２は、表示属性の組、セキュリティ条件およびテーブルコンテンツを組み合わせてコンテンツテーブルビューを作成するＧＵＩの例である。ユーザは、メイン画面３２１のクラスツリー表示部３２３でクラスを選択し、コンテンツ／ビュー作成ボタン３２４を選択すると、コンテンツテーブルビュー設定処理部１７は、そのクラスに対して、コンテンツテーブルビューを設定するための画面３２２を表示させる。コンテンツテーブルビューを設定する画面３２２では、プルダウンメニュー３２５には、コンテンツテーブルビュー設定処理部１７により、選択したクラスに存在するコンテンツテーブルの一覧が表示される。ユーザはコンテンツテーブルを一つ選択することにより、組み合わせるコンテンツテーブルを決定する。ラジオボタン３２６ａ，３２６ｂでセキュリティ条件を設定し、チェックボックスボタン３２７を選択して表示属性の組を決定する。さらに、テキストボックス３２８にコンテンツテーブルビューの名称を入力し、実行ボタン３２９を押すことにより、コンテンツテーブルビューの設定が完了する。

チェックボックス３３０をクリックすることにより、コンテンツテーブルビュー設定処理部１７が設定データをデフォルトのコンテンツテーブルビューとして設定し、クラスとの関連付けが行われていない場合でも、コンテンツテーブルの表示に利用される。

図３３のＴｙｐｉｃａｌ設定ファイルでは、典型属性の組、属性の表示条件（表示順）、クエリーコンディションを組み合わせたコンテンツテーブルビューの設定を行うものである。ファイルは、プロパティの識別子と検索条件を一行として記述しており、記載されている全てのプロパティが典型属性の組であり、記載順を、属性の表示順としている。このファイルで設定されたコンテンツテーブルビューに従って、図２７のＴａｂｌｅ０１を表示すると、図３１のようになる。

図３０は、図３２で設定した表示属性の組、セキュリティ条件およびテーブルコンテンツを組み合わせたコンテンツテーブルビューと、図３３で設定した典型属性の組、属性の表示条件、クエリーコンディションを組み合わせたコンテンツテーブルビューを関連づけるためのＧＵＩの例である。図３２で設定したコンテンツテーブルビューは図３０では関連付けるビューのボックス３０２で選択し、図３３で設定したコンテンツテーブルビューは図３０では関連付ける検索ビューのボックス３０３で選択される。

図３０は、例えばクラスツリー表示部３２３から、コンテンツテーブルビュー設定処理部１７によりクラス選択後呼び出される。この場合、選択したクラスがクラス名称のボックス３０１に自動的に表示される。また、そのクラスで定義されているコンテンツテーブルビューの組をボックス３０２及び３０３のプルダウンメニューに表示し、ユーザに組み合わせを選択させることにより、各コンテンツテーブルビューを関連付けることができる。また、ボタン３０４〜４０６の選択により、それぞれクラスやコンテンツテーブルビューの削除、関連付けの決定、関連付けの取消処理の指示がなされる。

このように本実施形態は、コンテンツテーブルビュー設定処理部１７は、シノニマスクラス又はレギュラークラスの処理条件（コンテンツテーブルビュー）を設定し、この設定された処理条件をシノニマスクラス又はレギュラークラスに関連づけて関連付け情報記憶部２２に記憶しておき、この格納しておいた処理条件に従ってシノニマスクラス又はレギュラークラスの表示等の処理を行うことができる。すなわち、ＧＵＩを用いてシノニマスクラスであることを設定し、通常のクラスと区別可能にしてデータベースに入出力することにより、シノニマスクラスであることを検出することができる。

例えば、企業内の標準部品や推奨部品の選定条件や、その他表示条件を、ＧＵＩやファイルで設定することができる。

（第１２実施形態）
本実施形態はシノニマスクラスの具体的な設定手法の実施形態に係わる。

図３４は本実施形態のシノニマスクラスの具体的な設定のための画面表示例を示す図である。

クラスツリー表示部３４１で、シノニマスクラスを作成するクラスＺ０２を選択し、シノニマスクラス作成ボタン３４３を押すと、シノニマスクラス設定部３４２が表示される。シノニマスクラスＢＳＵを入力するテキストボックス３４４に作成したいシノニマスクラスのＢＳＵを入力する。また、シノニマスクラス名称を入力するテキストボックス３４５に同名称を入力する。シノニマスクラスとして参照したいクラスコードＴ０４のクラスをクラスツリー表示部３４１で選択すると、自動的にシノニマスクラス設定部３４２のソースクラスのテキストボックス３４６に表示される。

ユーザは、ボタン３４８を押すと、シノニマスクラスとして、クラスコードＺ０３のクラスが設定される。クラスを一意に識別するＢＳＵは、その文字列には意味を持たないことが多いため、シノニマスクラスＢＳＵの入力は、システムで自動的に行っても構わない。なお、ボタン３４７及び３４９によりクラスやコンテンツテーブルビューの削除、関連付けの取消処理が実行される。

このように本実施形態によれば、シノニマスクラスがインスタンスを持たない場合に、入力部１２によりシノニマスクラスに設定するための指示情報が入力された場合に、指示情報の指示するクラスに、シノニマスクラスとレギュラークラスの別を示す識別情報を関連づけることができる。

例えば、ソースクラスとしてレギュラークラスを選んだ場合には、レギュラークラスの持つ各言語毎の推奨名をシノニマスクラスのディフォールの名称としてＧＵＩに表示することができる。

（第１３実施形態）
本実施形態はシノニマスの具体的設定手法の別の実施形態に係わる。

図３５は本実施形態のシノニマス設定部３５１の一例を示す図である。他の表示は図３４と共通するので省略する。すなわち、本実施形態では、図３４と同様に、クラスツリー表示部３４１とシノニマス設定部３５１が表示されている。この図３５は、シノニマスクラス作成ボタン３４３を押すことにより自動表示された状態を示している。この図３５に示すように、シノニマスクラス名称の入力を助けるために、シノニマスクラスの名称「パソコン」をあらかじめシノニマスクラス名称のテキストボックス３５３に表示しておいてもよい。テキストボックス３５２〜３５４、ボタン３５５〜３５７は、図３４のテキストボックス３４４〜３４６とボタン３４７〜３４９に対応する。

また、シノニマスクラス名称の入力を助けるために、ソースクラスがシノニマスクラスであった場合には、さらにそのソースクラスである名称をあらかじめシノニマスクラスの名称のテキストボックス３５３に表示しておいてもよい。

このように、本実施形態によれば、入力部１２によりシノニマスクラスが参照するレギュラークラスが指定された場合には、指定されたレギュラークラスの持つ属性をシノニマスクラスの属性として表示することができる。

（第１４実施形態）
本実施形態はシノニマスクラスの表示の別の実施形態に係わる。

図３６は本実施形態の表示画面の一例を示す図である。

シノニマスクラスであるＺ０３をソースクラスとするシノニマスクラスＹ０１：ＰＣが定義されているとする。クラスコードＹ０１のシノニマスクラスがクラスツリー表示部３６１で選択された場合、そのソースクラスであるＺ０３：Ｔ社パソコンの情報が、クラス情報表示領域３６２およびプロパティリスト表示領域３６３に表示されるが、クラスコードＺ０３のクラスはシノニマスクラスであるため、さらにそのソースクラスであるＴ０４：パソコンのクラス情報および、プロパティリストが表示される。

このように本実施形態によれば、クラス編集処理部１６は、シノニマスクラスが参照するクラスを探索する処理を１回又は繰り返し実行することにより、シノニマスクラスのソースクラスとしてのレギュラークラスを取得し、シノニマスクラスが参照するレギュラークラスを他と区別して表示する処理を実行することができる。

（第１５実施形態）
本実施形態はマイフェイバリットクラスという仮想クラスを利用した実施形態に係わる。

図３７は本実施形態の画面表示の一例を示す図である。クラスツリー表示部３７１には、クラスツリー上のマイフェイバリットクラスという仮想クラスの下位クラスのように、ユーザが個人で設定したクラス、ソースクラスが「Ｚ０４：Ｔ社パソコン」である「ＰＣ」、ソースクラスが「Ｔ１３：デジタルカメラ」である「デジカメ」が表示されている。マイフェイバリットクラスは、辞書情報として格納しておく意味がないため、ＩＳＯ１３５８４規格のクラスでは必ず必要なクラス識別子（クラスＢＳＵ）が必要ない。また、階層を構成している必要もない（階層を構成してもよい）。マイフェイバリットクラスの設定は、クライアントに保存されていてもよいし、サーバにあってもよい。

図３８はマイフェイバリットの設定ファイルの一例を示す図である。この図３８は、特にマイフェイバリットクラスにクラス階層をもたせない例である。クラス識別子の後の、「ＪＡ」は言語の指定（この場合は、日本語）であり、言語ごとに名称をもつクラスに対して、各言語でマイフェイバリット名称をつけることが可能である。

また、クラス編集処理部１６はユーザから要求があると、マイフェイバリットクラスをシノニマスクラスに変換する。その際、マイフェイバリットクラスにはクラスＢＳＵは必須ではないため、シノニマスクラスでは必須であるクラスＢＳＵを自動的にシステム内で付加するか、あるいはユーザに設定を促してもよい。

すなわち、本実施形態では、クラス編集処理部１６は、シノニマスクラスをユーザあるいはグループ単位で生成するためのマイフェイバリットクラスを示す図像を表示し、またマイフェイバリットクラスを階層型データベースにおけるクラスの１つとして表示し、マイフェイバリットクラスと他のクラスとの継承関係を格納する。

このように本実施形態は、既存のクラスに基づき、個々のユーザ毎に別分類を生成し、ビュー（プレゼンテーション）をカスタマイズする。個々のユーザにカスタマイズされたクラス（以下、マイフェイバリットクラス）は、そのユーザ個人のための分類といえる。したがって、このマイフェイバリットクラスは、分類及びプレゼンテーションの方法において被参照標準クラス（レギュラークラスおよびシノニマスクラス）とは異なる。一般には、マイフェイバリットクラスに関する情報を他のユーザと共有する必要はない。従って、マイフェイバリットクラスについて、クラスや属性についてある団体で共有される標準コードを持つ必要はない。しかしながら、クラスの標識となるオブジェクトを分類体系をＧＵＩ表示するクラスツリー上にユーザの都合に合わせ配置する。また、マイフェイバリットクラスにおいて通常検索に用いる属性や検索値を予め設定しておく。これにより、ユーザにより分かりやすく簡便な分類が提供され得る。

勿論、マイフェイバリットクラス、即ち個人用のクラスは、このマイフェイバリットクラスが参照しているレギュラークラスの情報を利用して、シノニマスクラスに変更し得る。または、マイフェイバリットクラスがシノニマスクラスを参照している場合にはその参照先のレギュラークラスの情報を利用して、マイフェイバリットクラスをシノニマスクラスに変更し得る。また、ある団体や組織に属するユーザについて共通に、通常検索に用いる属性や検索値があるならば、これを標準ビューとしてシノニマスクラスに設定可能なことは言うまでもない。

例えば、以下のような利用が考えられる。
ユーザあるいはグループ単位のＧＵＩ要素として、アイコン、ボタン、スイッチ、ラベル等を画面上に用意し、ユーザ毎に個別にマイフェイバリットのオブジェクトを生成し表示する。そして、このマイフェイバリットクラスに関する情報を記憶して再利用することができる。そして、この記憶データを分類ツリー上に仮想的に分類クラスであるかのように挿入し表示する。ユーザが再度システムを利用する際には自動あるいは半自動的に、マイフェイバリット・クラスを読み込んでユーザに表示する。さらに、ユーザからの指示に応じてマイフェイバリットクラスに関する情報をファイルに出力し、シノニマスクラスに変換する。そして、不足する情報を予め埋めておいて、その情報をユーザが上書きして入力するためのＧＵＩを用意する。

本発明は上記実施形態に限定されるものではない。ＰＬＩＢ規格に基づくデータ構造に準拠するクラス分類体系を備えた辞書情報を例に説明したが、ＰＬＩＢ規格に部分的に準拠したものであっても、完全に準拠したものであってもよい。

本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

以上説明したようにこの発明は、いわゆる階層型データベースを管理する階層型データベース管理システム、階層型データベース管理方法及び階層型データベース管理プログラムの技術分野に有効である。

本発明の第１実施形態に係る階層型データベース管理システムで用いられるＧＵＩの一例を示す図。 同実施形態に係るクラスの階層構造と各クラスの属性の概念図。 同実施形態に係る階層型データベース管理システムの一構成例を示す図。 同実施形態に係るユーザに提示されたクラスツリーの一表示例を示す図。 同実施形態に係る辞書情報記憶部に記憶されたクラスの種類の記憶形式の一例を示す図。 同実施形態に係るシノニマスクラスを別のウィンドウに表示させた例を示す図。 本発明の第２実施形態に係るバルーンを用いてソースクラスのコードを表示した例を示す図。 同実施形態に係るシノニマスクラスをバルーンに表示した例を示す図。 同実施形態に係るクラスツリー表示部の表示例を示す図。 同実施形態に係るクラスツリー表示部の表示例を示す図。 本発明の第３実施形態に係るクラスツリーの一例を示す図。 同実施形態に係る辞書情報の記述例を示す図。 同実施形態に係るＰａｒｔ２１ファイルにおけるクラス情報を記述した部分を抜粋して示した図。 本発明の第４実施形態に係るＰａｒｔ２１ファイルにおけるクラス情報を記述した部分を抜粋して示した図。 本発明の第５実施形態に係るシノニマスクラスの記述例を示す図。 同実施形態に係るシノニマスクラスの記述例を示す図。 同実施形態に係るシノニマスクラスの記述例を示す図。 本発明の第６実施形態に係るシノニマスクラスの記述の一例を示す図。 同実施形態に係る関連エンティティを含んだＥＸＰＲＥＳＳ−Ｇの記述例を示す図。 同実施形態に係る図１９に示す拡張エンティティを利用してＰａｒｔ２１ファイルを記述した例を示す図。 本発明の第７実施形態に係るシノニマス情報の記述を説明するための図。 同実施形態に係るシノニマス情報の記述を説明するための図。 同実施形態に係るシノニマス情報の記述を説明するための図。 同実施形態に係るシノニマス情報の記述を説明するための図。 本発明の第８実施形態に係るシノニマスクラスの表示例を示す図。 同実施形態に係るシノニマスクラス表示動作のフローチャートを示す図。 本発明の第９実施形態に係る自動変換機能を説明するための図。 本発明の第１０実施形態に係るシノニマスクラスとソースクラスの関係を示した図。 本発明の第１１実施形態に係るクラスが持つ各種情報を示す図。 同実施形態に係る２つのコンテンツテーブルビューを関連づけるためのＧＵＩの例を示す図。 同実施形態に係るコンテンツテーブルビューの表示例を示す図。 同実施形態に係るコンテンツテーブルビューの登録のためのＧＵＩの一例を示す図。 同実施形態に係るコンテンツテーブルビューの登録のための設定ファイルの一例を示す図。 本発明の第１２実施形態に係るシノニマスクラスの具体的な設定のための画面表示例を示す図。 本発明の第１３実施形態に係るシノニマス設定部の一例を示す図。 本発明の第１４実施形態に係る表示画面の一例を示す図。 本発明の第１５実施形態に係る画面表示の一例を示す図。 同実施形態に係るマイフェイバリットの設定ファイルの一例を示す図。

符号の説明

１…サーバ装置、３…クライアント装置、４…ネットワーク、５…外部記憶装置、１１…制御部、１２…入力部、１３…出力部、１４…辞書入出力処理部、１５…辞書処理部、１６…クラス編集処理部、１７…コンテンツテーブルビュー設定処理部、１８…関連付け処理部、１９…辞書情報記憶部、２０…マイフェイバリットクラス情報記憶部、２１…コンテンツテーブルビュー情報記憶部、３１…制御部、３２…入力部、３３…出力部、３４…コンテンツテーブルビュー情報記憶部、３５…関連付け情報記憶部、３６…マイフェイバリットクラス情報記憶部、１００…階層型データベース管理システム

Claims (15)

1. 下位クラスが上位クラスの属性を継承し、かつ、各クラスがクラスを識別するためのクラスコードを持つ第１及び第２の分類体系を持ち、
   前記第１の分類体系はレギュラークラスを有し、
   前記第２の分類体系は、前記レギュラークラスと前記第１の分類体系のレギュラークラスを参照利用するシノニマスクラスとを有し、前記シノニマスクラスは、シノニマスクラスであることを識別するための識別情報と、該シノニマスクラスのクラスコードと、該シノニマスクラスが参照する前記第１の分類体系の前記レギュラークラスのクラスコードとを併せ持つ階層型データベースと、
   前記識別情報に基づき、前記シノニマスクラスを前記レギュラークラスとは識別可能に表示する表示手段と
   を備えたことを特徴とする階層型データベース管理システム。
2. 前記シノニマスクラスには、前記レギュラークラスとは独立したエンティティとして記述するための付帯情報が関連づけられており、
   さらに、入力データに記述された前記識別情報を読み出すことにより、前記シノニマスクラスを生成する手段と
   を備えたことを特徴とする請求項１に記載の階層型データベース管理システム。
3. 前記表示手段は、前記レギュラークラスのクラスコードを前記シノニマスクラスの参照先コードとして表示し、または、前記シノニマスクラスのクラスコードを前記レギュラークラスの同義分類コードとして表示することを特徴とする請求項１または請求項２に記載の階層型データベース管理システム。
4. 前記階層型データベースは、前記第１の分類体系から前記第２の分類体系にクラス及び属性をインポートするインポート構造を持ち、かつ、子クラスが唯一の親クラスを備える単純継承構造をなし、
   前記シノニマスクラスは、該シノニマスクラスが参照する前記第１の分類体系のレギュラークラスをインポートしたクラスとして、前記インポート構造で記述され、前記シノニマスクラスに付帯する情報には、前記シノニマスクラスであることが記述され、
   さらに、前記インポート構造を、子クラスが複数の親クラスを備えた多重継承関係として処理する手段とを備えたことを特徴とする請求項１乃至３のいずれか１項に記載の階層型データベース管理システム。
5. 前記階層型データベースは、子クラスが唯一の親クラスを備える単純継承構造をなし、
   前記シノニマスクラスの参照するレギュラークラスの情報と、シノニマスクラスであることが、シノニマスクラスに付帯する情報に記述され、
   前記シノニマスクラスを、子クラスが複数の親クラスを備えた多重継承関係として処理する手段を備えたことを特徴とする請求項１乃至３のいずれか１項に記載の階層型データベース管理システム。
6. 前記シノニマスクラスはインスタンスを持たず、
   前記シノニマスクラスは、前記第１の分類体系とは異なる分類体系のクラス及び属性をインポートするエンティティの特殊化として新たに定義された特殊化エンティティにより記述され、
   さらに、前記シノニマスクラスが、前記特殊化エンティティで記述されていることに基づきシノニマスクラスであることを検出する手段を備えたことを特徴とする請求項１乃至３のいずれか１項に記載の階層型データベース管理システム。
7. 前記シノニマスクラスはインスタンスを持たず、前記第１の分類体系に従った第１のデータと、前記第２の分類体系に従った第２のデータと、第１の分類体系と第２の分類体系のシノニマス参照情報が記述された第３のデータとにより前記レギュラークラス及びシノニマスクラスが記述され、
   さらに、前記第３のデータのシノニマス参照情報に基づきシノニマスクラスであることを検出する手段を備えたことを特徴とする請求項１乃至５のいずれか１項に記載の階層型データベース管理システム。
8. 前記シノニマスクラスはインスタンスを持たず、
   さらに、入力装置によりシノニマスクラスに設定するための指示情報が入力された場合に、該指示情報の指示するクラスに前記識別情報を関連づける手段
   を備えたことを特徴とする請求項１乃至５のいずれか１項に記載の階層型データベース管理システム。
9. 前記表示手段は、前記シノニマスクラスが参照する入力装置により指定されたレギュラークラスのクラス情報を、シノニマスクラスのクラス情報の第一候補として表示することを特徴とする請求項８に記載の階層型データベース管理システム。
10. （もと原稿ではクレーム８）
    さらに、前記表示手段により表示されたシノニマスクラスを選択する手段と、
    前記シノニマスクラスの選択を検出し、前記シノニマスクラスが参照する前記レギュラークラスを読み出し表示する手段と
    を備えたことを特徴とする請求項１乃至９のいずれか１項に記載の階層型データベース管理システム。
11. 入力装置を用いた操作、又はデータ処理の対象が前記シノニマスクラスであることを前記識別情報に基づき検出した場合に、前記シノニマスクラスが参照する前記レギュラークラスの処理を実行する手段と
    を備えたことを特徴とする請求項１乃至１０のいずれか１項に記載の階層型データベース管理システム。
12. 前記レギュラークラスは第１の属性を有し、前記シノニマスクラスは第２の属性を有し、
    さらに、レギュラークラスを含む第１の分類体系において第１の上位クラスから第１の下位クラスに継承される第１の継承属性を設定するものであって、前記第１の下位クラスには、前記第２の属性が継承されないように第１の分類体系を設定する手段と、
    シノニマスクラスを含む第２の分類体系において第２の上位クラスから第２の下位クラスに継承される第２の継承属性を設定するものであって、前記第２の下位クラスには、前記第１の属性が継承されないように第２の分類体系を設定する手段と
    を備えたことを特徴とする請求項１乃至１１のいずれか１項に記載の階層型データベース管理システム。
13. シノニマスクラスが参照するクラスがシノニマスクラスであった場合、参照先クラスを探索する処理を１回又は繰り返し実行することにより、該シノニマスクラスのソースクラスとしてのレギュラークラスを取得し、前記シノニマスクラスが参照する前記レギュラークラスの処理を実行する手段
    を備えたことを特徴とする請求項１０又は１１に記載の階層型データベース管理システム。
14. 前記シノニマスクラスをユーザあるいはグループ単位で生成するための第１のクラスを示す図像を表示する手段と、
    前記第１のクラスを前記階層型データベースにおけるクラスの１つとして表示する手段と、
    前記第１のクラスと他のクラスとの継承関係を格納する手段と
    を備えたことを特徴とする請求項１乃至１３のいずれか１項に記載の階層型データベース管理システム。
15. 前記シノニマスクラス又は前記レギュラークラスの処理条件を設定する手段と、
    前記設定された処理条件を前記シノニマスクラス又は前記レギュラークラスに関連づける手段と、
    前記処理条件に従って前記シノニマスクラス又は前記レギュラークラスを処理する手段と
    を備えたことを特徴とする請求項１乃至１４のいずれか１項に記載の階層型データベース管理システム。

Images