JP2005032271A - オブジェクト指向データベース管理システム及び方法 - Google Patents

Abstract

【課題】オブジェクト指向データベースにおいて、スキーマ定義情報と独立に、オブジェクトへの属性、関連、手続きの変更を行えるようにする。
【解決手段】データベース１０７はオブジェクト及び該オブジェクトの変更情報を保持する部品オブジェクトを格納し、部品オブジェクト管理部１０２とオブジェクト管理部１０３が管理する。ディクショナリ１０８は、オブジェクトの定義情報と該定義情報の変更情報を保持する部品オブジェクトを格納し、ディクショナリ管理部１０４が管理する。ビュー管理部１０１は、ユーザの要求により、各管理部１０２、１０３、１０４を介して、定義変更後のオブジェクトの定義情報及びオブジェクトを動的に生成するビューを管理する。更新履歴管理部１０５は部品オブジェクトからオブジェクトの変更履歴を抽出し、ジャーナル１０６に出力する。
【選択図】図１

Description

本発明は、オブジェクト指向データベースシステムに係わり、特にオブジェクトの定義の変更に伴うオブジェクトの変更に好適なオブジェクト拡張方式に関する。

従来のデータベースシステムでは、データの定義の集合であるスキーマを変更すれば、変更前のデータに影響を及ぼす。これは、データ構造が変更されてしまうからである。このデータ構造の変更をいつ行うかが問題となる。オブジェクト指向データベースでも同様の問題がある。対策方法として、即時更新（Ｉｍｍｅｄｉａｔｅ−ｕｐｄａｔｅ）と遅延更新（ｄｅｆｅｒｒｅｄ−ｕｐｄａｔｅ）がある（例えば、非特許文献１参照）。

即時更新は、スキーマ更新時にその更新に対して、影響を受けるオブジェクトをスキーマ更新時に同時に影響を受けるすべてのオブジェクトを変更してしまう方法である。この方法は、オブジェクトが大量に存在するとき、スキーマ変更に伴う変更作業量が大きい。一方、遅延更新は、スキーマ更新後、その更新に影響を受けるオブジェクトがアクセスされた時に変更を反映する作業を行う方法である。属性追加／挿入はＮＵＬＬデータをいれ、オブジェクトを更新する。後者は、スキーマ更新の処理速度は前者より早いが、アクセスされないオブジェクトは、古いスキーマの構造のまま存在することになるため、アクセス時にどの定義構造の状態なのかを判定した上で該当する定義情報に従って変更を行わなくてはならない。

従来、これらの処理では、スキーマ変更後のオブジェクトの更新方法についてしか論じられていない。しかし、実際に問題となるのはスキーマ変更処理である。通常オブジェクトを操作するときは、その定義であるスキーマに共有ロック（ｓｈａｒｅｄ Ｌｏｃｋ）をかけて、スキーマ情報を参照していることを示し、他のプロセスがスキーマ更新を行えないようにしている。これは、データベースの整合性を保証するために必要な事である。したがって、そのオブジェクトを操作しているプロセスが存在するかぎり、そのスキーマを変更することができない。

Ｗom Ｋim：Ｉntroduction to Ｏbject−oriented Ｄatabases，ＭＩＴ press，pp．５０−５２

上記従来技術では、スキーマ変更とオブジェクト操作の同時操作について、スキーマ変更の実行可能条件が厳しく、スキーマ変更時に、オブジェクトの操作ができないという点について配慮されていない。

本発明の目的は、属性と関連と手続きを持つオブジェクトを格納するオブジェクト指向データベースにおいて、スキーマ定義情報と独立に、オブジェクトへの属性、関連、手続きの変更を行えるようにすることにある。

上記目的を達成するために、本発明は、属性と関連と手続きを持つオブジェクト、該オブジェクトの構造を定めた定義情報を持つ定義オブジェクトを有するオブジェクト指向データベースシステムにおいて、前記定義オブジェクトの変更に伴う属性、関連、手続きの各変更情報を部品オブジェクトとして定義オブジェクトに保持し、前記定義オブジェクトの変更で新たにオブジェクトに付加されるデータを各オブジェクトに部品オブジェクトとして保持するものである。

本発明では、スキーマ変更に伴う属性、関連、手続きの各変更情報を部品オブジェクトとして定義オブジェクトに保持することで、スキーマ定義を変更することなく、オブジェクトに属性、関連、手続きの追加、削除、定義変更などの操作が行えるようになる。定義変更で新たにオブジェクトに付加されるデータは、定義オブジェクトと同様、各オブジェクトに部品オブジェクトとして保持される。定義オブジェクトと定義オブジェクトが保持する部品オブジェクトによって、定義変更後の定義オブジェクトを仮想的に生成する。また、仮想的に生成された定義オブジェクトに対応するオブジェクトは、同様にオブジェクトと、オブジェクトが保持する部品オブジェクトによって仮想的に生成するため、ユーザはその仮想的に生成された定義オブジェクト及びオブジェクトだけが見えているので、変更前と同じ操作でオブジェクトが操作できる。

本発明によれば、スキーマ定義を変更することなく、オブジェクトに属性、関連、手続きの追加、削除、定義変更が行える。また、ユーザ領域に通常のオブジェクトと同じ様にアクセスできるため、データ操作が簡単に行えるようになる。さらに、部品オブジェクトそのものが、定義及びデータの変更歴として利用できるため、スキーマ変更に伴う定義及びデータの変更分の差分更新情報を新たに取る必要がない。

以下、本発明の一実施例を図１乃至図１５を使用して詳述する。
本実施例では、オブジェクトは、あるタイプを持つデータで示される属性、オブジェクト間の関係を保持する関連、オブジェクトの振る舞いを決める手続きからなる。属性はタイプ内で一意で、属性名で識別する。関連は、スキーマ内で一意で、関連名で識別する。手続きは、タイプ内で一意で、セレクタ名とパラメタタイプの順序で識別する。これら属性、関連、手続きをオブジェクトの特性と呼ぶ。オブジェクトの属性には、オブジェクトのタイプを記述する（つまりオブジェクトそのものを保持、参照する）ことができる。実際は、オブジェクトを一意に決めるために、システムでオブジェクト識別子を使用しているため、オブジェクト識別子を属性のデータとして保持する。当該オブジェクトタイプ属性と関連の区別は、利用者にゆだねる。関連は、関連元タイプと関連先タイプの該関連元と該関連先にどんな関連があるかを規定する。該関連に定義された全該関連元タイプに属するオブジェクトと全該関連先タイプに属するオブジェクト間に存在する。また関連には、属性を保持することができる。

オブジェクトの特性を規定する定義をそのオブジェクトのタイプと呼ぶ。タイプの集合をスキーマと呼ぶ。タイプの定義情報をメタ定義情報と呼ぶ。該スキーマおよび該メタ定義情報には、部品オブジェクトのタイプおよび該部品オブジェクトタイプのメタ定義情報も含まれる。

あるオブジェクトに対する特性の追加、削除、更新は、該オブジェクトのタイプ（定義）変更を要する。このとき、該変更情報およびデータを部品オブジェクトとして、該オブジェクトのシステム情報として保持される。部品オブジェクトもオブジェクトの一種としてタイプを持ち、データベース（ＤＢ）に保持される。本実施例では、タイプ変更のうち、更新は削除と追加に置き換えられる。また追加は、常に最終位置に行われる。

図１に本発明の一実施例のシステム構成図を示す。ビュー管理部１０１は、ユーザ定義のオブジェクトをユーザがみたい構造（ビュー）に変換し、ユーザに提供したりユーザからコマンド、データなどを受け取る部分である。部品オブジェクト管理部１０２は、データベース（ＤＢ）１０７上に、既に定義してあるオブジェクトに新たな定義に基づく特性が規定された場合に保持する部品オブジェクトを管理する部分である。オブジェクト管理部１０３は、ＤＢ１０７上の既に定義されているオブジェクトを管理する部分である。ディクショナリ管理部１０４は、ディクショナリ１０８上の、既に定義されているオブジェクトのタイプ情報を管理する部分である。更新履歴管理部１０５は、部品オブジェクト管理部１０２を介してＤＢ１０７上の部品オブジェクトから取り出した更新履歴情報を管理し、ジャーナル１０６に出力する部分である。データベース（ＤＢ）１０７は、オブジェクトおよび部品オブジェクトを保持し、ディクショナリ１０８は、タイプ（定義）情報を保持する。

図２乃至図５は、メタ定義情報を示す。これらのメタ定義情報は、後述する図６の情報等のひな形で、ディクショナリ１０８に保存され、ディクショナリ管理部１０４で管理される。

２０１〜２０６がタイプのメタ定義情報、２０７〜２０９が属性のメタ定義情報、２１０〜２１４が手続きのメタ定義情報、２１５〜２２４が関連のメタ定義情報、２２５〜２２７が関連の組み合わせとなるオブジェクトを持つ関連対のメタ定義情報、２２８〜２３３が属性の定義変更情報を保持する部品属性オブジェクトのメタ定義情報、２３４〜２４０が手続きの変更情報を保持する部品手続きオブジェクトのメタ定義情報、２４１〜２４２が、オブジェクトが保持する関連を参照するための関連管理オブジェクトのメタ定義情報、２４３がオブジェクトの構成変更を伴う属性変更で付加されるデータを保持する構成変更オブジェクトのである。ここで、［］は該定義のタイプ、ａｒｒａｙＯｆ［］は、埋めこみ配列、ｅｎｕｍＯｆ［］は、列挙型、ｕｎｉｏｎＯｆ［］は、共用型をあらわす。また、ｏｉｄはオブジェクト識別子、ｂｉｎａｒｙＣｏｄｅは、可変長バイナリコードを示す。ここでは、タイプ定義で使用できるシステム提供のタイプとして整数（ｉｎｔ）と文字列（ｓｔｒｉｎｇ）を提供する。また、各タイプ情報は、すべてオブジェクトとして扱えるようになっているため、オブジェクト識別子を保持する。

２０１〜２０６がタイプのメタ定義情報で、２０１は、本タイプ定義の版を管理するためのバージョン番号、２０２は、タイプを一意に決定するタイプ名称、２０３は、タイプが持つ属性数、２０４は、タイプが持つ属性で、属性数２０２個の属性を持つ。２０５は、タイプが持つ手続数、２０６は、タイプが持つ手続きで手続数２０４個の手続きを持つ。つまり、属性は２０７〜２０９の属性メタ定義情報に基づく属性オブジェクトを持ち、手続きは２１０〜２１４の手続きメタ定義情報に基づく手続きオブジェクトを持つことを示す。

２０７〜２０９が属性のメタ定義情報で、２０７は、保持されているタイプ内で一意な属性名、２０８は、該属性のデータタイプで本実施例では整数と文字列のみ使用できる。２０９は、該属性のデータのデータ長でバイト数を保持する。よって、整数時は４、文字列時はユーザ指定数で任意である。

２１０〜２１４が手続きのメタ定義情報で、２１０は、手続きの名称となるセレクタ名、２１１は、手続きが保持するパラメタの数、２１２は、パラメタ数２１１個のパラメタのタイプ定義の集合、２１３は、手続きがかえす戻り値のタイプ、２１４は、手続きの本体である実行コードである。

２１５〜２２４が関連のメタ定義情報で、２１５は、関連を一意に決定する関連名、２１６は、関連の種別で、１対１、１対多、多対１、多対多の４種類がある。２１７は、関連元タイプ数、２１８は関連元タイプ数２１７個の関連元タイプのタイプ情報、２１９は、関連先タイプ数、２２０は、関連先タイプ数２１９個の関連先タイプのタイプ情報、２２１は、関連の意味情報で、本実施例では、何もない（ＮＵＬＬ）、つまり単に参照しているだけの関係と部品関連（Ｐａｒｔｓ）がある。２２２は、関連が保持する属性数、２２３は、関連属性数２２２個の属性情報、２２４は、実際関連を持つオブジェクトの対を保持する関連群である。

２２５〜２２７が関連の組み合わせとなるオブジェクトを持つ関連対のメタ定義情報で、２２５は、関連元となるオブジェクトのオブジェクト識別子、２２６は、関連元オブジェクト２２６から該関連を持つ関連先のオブジェクト群のオブジェクト識別子群、２２７は、関連のメタ定義内の関連属性２２３で定義された属性データを関連属性数２２２個分保持する。

２２８〜２３３が属性の定義変更情報を保持する部品属性オブジェクトのメタ定義情報で、２２８は、定義の版を管理するためのバージョン番号、２２９は、該部品属性オブジェクト生成時の属性の操作を示す操作コード、２３０は、タイプ定義中の属性の何番目が更新されたかを示す更新位置、２３１〜２３３は、操作コード２２９がａｐｐｅｎｄ（追加）時にのみ存在する。２３１は、追加された属性の属性名、２３２は、追加された属性のデータタイプ、２３３は、追加された属性のデータ長である。

２３４〜２４０が手続きの定義変更情報を保持する部品手続きオブジェクトのメタ定義情報で、２３４は、定義の版を管理するためのバージョン番号、２３５は、部品オブジェクト生成時の手続きの操作を示す操作コード、２３６は、セレクタ名、２３７は、パラメタ数、２３８は、パラメタ数２３７個のパラメタタイプ群、２３９〜２４０は、操作コード２３５がａｐｐｅｎｄ時のみ存在する。２３９は、戻り値のタイプ、２４０は、実行コードである。

２４１〜２４２は、オブジェクトが持つ関連を管理する関連管理のメタ定義情報で、２４１は、既に関連定義されていて該オブジェクトが持つ関連の関連名、２４２は、実際の関連元オブジェクト（該オブジェクト自身）と関連を持つ関連先のオブジェクト群を保持する関連対オブジェクトの集合である。

２４３は、属性定義変更時にオブジェクトに付加される属性データを保持する構成変更情報のメタ定義情報で、属性データ群を保持する。

図６は、あるスキーマ内に存在するタイプ定義オブジェクトと関連定義オブジェクトの一例である。これらの情報は、関連対オブジェクト３０６を除いてディクショナリ１０８に格納され、ディクショナリ管理部１０４で管理される。

本実施例では、属性に名前、年齢を持ち、オブジェクト識別子Ｔ１を持つｐｅｒｓｏｎタイプ定義３０１、属性に型名、メモリサイズ、ＯＳ名を持ち、オブジェクト識別子Ｔ２を持つｃｏｍｐｕｔｅｒタイプ定義３０２、属性に型名、メガクロック数を持ち、オブジェクト識別子Ｔ３を持つｐｒｏｃｅｓｓｏｒタイプ定義３０３がある。タイプ定義オブジェクトの破線部は、前半が各定義オブジェクトのオブジェクト識別子、後半は、属性定義更新時に生成される部品属性オブジェクトである。手続き定義更新時に生成される部品手続きオブジェクトのオブジェクト識別子を保持する。図６の例では、ｃｏｍｐｕｔｅｒタイプが、オブジェクト識別子Ｐ１の属性部品オブジェクトとオブジェクト識別子Ｐ３の手続き部品オブジェクトを持っている。各部品オブジェクトについては、図７に示す。

また、本実施例では、関連名にプロセッサ、ｃｏｍｐｕｔｅｒタイプとｐｒｏｃｅｓｓｏｒタイプに１：１で部品関連を持つプロセッサ関連３０４がある。実際に関連定義オブジェクト３０４で定義された関連を持つ関連定義オブジェクトの破線部は、各定義オブジェクトのオブジェクト識別子である。また関連対集合オブジェクト３０５及び関連対オブジェクト３０６から、関連名“プロセッサ”の関連は、オブジェクト識別子Ｏ２を持つオブジェクトとオブジェクト識別子Ｏ３を持つオブジェクトの間に成り立っていることがわかる。ただし、関連対集合オブジェクトは、定義情報を保持するディクショナリ１０８に保持されるが、関連対オブジェクトは、オブジェクトが保持されるＤＢ１０７に保持する。これは、オブジェクトの関連を管理する関連管理オブジェクトからも参照されるためである。図６では、関連対オブジェクトとの対応が分かりやすいように、関連対オブジェクトも示したものである。

図７は、図６の定義に付加されている部品オブジェクトの例である。これは、図６の定義のｃｏｍｐｕｔｅｒタイプの属性に、“ハードディスクサイズ”を追加し、“ＯＳ名”を削除し、手続き“ｏｎＵｎｉｘ”を追加した場合である。この部品オブジェクトはＤＢ１０７に格納され、部品オブジェクト管理部１０２で管理される。

部品属性オブジェクト４０１は、オブジェクト識別子Ｐ１を持ち、ｃｏｍｐｕｔｅｒタイプに、属性名“ハードディスクサイズ”を追加し、属性“ＯＳ名”を削除する情報を保持する。部品属性オブジェクト４０２は、オブジェクト識別子Ｐ２を持ち、属性名“所有月数”を追加する情報を保持する。この属性は、後の説明で表れる関連の属性の定義情報である。

部品手続きオブジェクト４０３は、オブジェクト識別子Ｐ３を持ち、ｃｏｍｐｕｔｅｒタイプにセレクタ名“ｏｎＵｎｉｘ”でパラメタなし、戻り値論理タイプ（ｂｏｏｌｅａｎ）を追加する情報を保持する。ただし、図７では、実行コードは「………」で記載し内部詳細コードは省略した。

図８は、図６のスキーマ定義に基づくオブジェクト例である。破線部はオブジェクトが持つシステム情報で、前半部はタイプのオブジェクト識別子、そのタイプのバージョン番号、自分のオブジェクト識別子を、後半部は、構成変更オブジェクトのオブジェクト識別子、関連管理オブジェクトのオブジェクト識別子を保持する。このオブジェクトはＤＢ１０７に格納され、オブジェクト管理部１０３で管理される。

オブジェクト５０１は、ｐｅｒｓｏｎタイプで、名前が日立太郎、１８才、オブジェクト５０２は、ｃｏｍｐｕｔｅｒタイプで、型名がＨＴ３０１０、メモリサイズが３２（メガバイト）、ＯＳ名がＯＳＡ、オブジェクト５０３は、ｐｒｏｃｅｓｓｏｒタイプで、型名がＰｒｏｃｅｓｓｏｒＡ、２５メガクロック、オブジェクト５０４は、ｐｒｏｃｅｓｓｏｒタイプで、型名がＰｒｏｃｅｓｓｏｒＢ、６６メガクロックであることを示す。オブジェクト５０２は、オブジェクト識別子ＰＰ１の構成変更オブジェクト５０５とオブジェクト識別子ｒｃ１の関連管理オブジェクト５０６を保持する。

構成変更オブジェクト５０５は、オブジェクト識別子ＰＰ１をもち、部品属性オブジェクト４０２で追加された属性“ハードディスクサイズ”の属性値“５００”を保持する。ここで、値“５００”は単なる例示である。

関連管理オブジェクト５０６は、ｃｏｍｐｕｔｅｒオブジェクト５０２が持つ関連“プロセッサ”が、保持する関連元オブジェクト（ｃｏｍｐｕｔｅｒオブジェクト５０２自身）と関連先オブジェクト群を保持する関連対オブジェクト３０６（図６）を保持する。図６では、関連対オブジェクト３０６は、関連元オブジェクトＯ２、関連先オブジェクトＯ３を持つ。これにより、オブジェクト５０２とオブジェクト５０３がプロセッサ関連を持つことがわかる。

図９は、関連変更後の関連定義オブジェクト、関連対集合オブジェクト、関連管理オブジェクト、関連対オブジェクトの例を示す。本例では、図６及び図８で示したオブジェクト５０２とオブジェクト５０３が持つプロセッサ関連の定義を名称、“プロセッサズ”、関連種別、１：ｎに変更し、新たにｐｅｒｓｏｎタイプとｃｏｍｐｕｔｅｒタイプ間に”所有者”関連とその逆関連として”所有物”関連を定義する。また、“プロセッサズ”関連を新たにオブジェクト５０２とオブジェクト５０４にはり、オブジェクト５０１とオブジェクト５０２に所有者（及び所有物）関連を張る。これらの情報のうち、関連定義オブジェクトがディレクトリ１０８に格納される情報であり、それ以外はＤＢ１０７に格納される情報である。

関連定義オブジェクト６０１は、関連名“所有物”で１：ｎで関連元タイプｐｅｒｓｏｎ、関連先タイプｃｏｍｐｕｔｅｒで、関連の属性定義４０２（図７）を持ち、関連対集合オブジェクト６０５を持つ事を示す。関連定義オブジェクト６０２は、関連名“所有者”で１：ｎで関連元タイプｃｏｍｐｕｔｅｒ、関連先タイプｐｅｒｓｏｎで、関連の属性定義４０２を持ち、関連対集合オブジェクト６０６を持つ事を示す。関連定義オブジェクト６０１と関連定義オブジェクト６０２は、関連と逆関連の関係になる。関連定義オブジェクト６０３は、関連名“プロセッサズ”で１：ｎで関連元タイプｃｏｍｐｕｔｅｒ、関連先タイプｐｒｏｃｅｓｓｏｒで、部品関連関連の属性定義４０２を持ち、関連対集合オブジェクト６０４を持つ事を示す。これは、関連定義オブジェクト３０４（図６）の関連名と関連の種別が変更されたものである。ゆえに、オブジェクト識別子が同じＲ１になっている。

関連管理オブジェクト６０７は、関連管理オブジェクト５０６が変更されたものである。関連名“プロセッサ”がプロセッサズに変更され、新たに追加された関連の関連名“所有者”と関連対オブジェクト６１１が追加される。また、関連管理オブジェクト６０８に、新たに追加された関連の関連名“所有物”と関連対オブジェクト６１０を持つ。関連管理オブジェクト６０８は、オブジェクト５０１の関連管理オブジェクトとして保持されるよう変更される。つまり破線部後半の２番目に関連管理オブジェクトを保持する。

関連対オブジェクト６０９は、新たに追加されたオブジェクト５０２とオブジェクト５０４の関連が付加するため、関連先オブジェクトにオブジェクト５０４が付加される。また関連対オブジェクト６１０で、オブジェクト５０１とオブジェクト５０２の関連が示され、関連対オブジェクト６１１で、オブジェクト５０２とオブジェクト５０１の関連が示される。

図１０乃至図１２に、本発明によるオブジェクトの属性／関連／手続きの変更処理フローを示す。いずれの場合も、処理は基本的にオブジェクト管理部１０３が中心となって行い、必要に応じてスキーマ情報処理ディクショナリ管理部１０４、部品オブジェクト処理を部品オブジェクト管理部１０２に依頼し、必要なデータをもらってＤＢ１０７の内容に反映させる。

図１０は、属性変更の処理フローである。ユーザは本処理を要求するとき、ビュー管理部１０１を介してオブジェクト管理部１０３に、オブジェクト識別子、定義変更時のバージョン番号、変更要求コード（追加、削除、更新）、変更属性情報として、属性名、属性タイプ、タイプサイズ、属性値を渡す。指定する属性名、タイプ、タイプサイズ、属性値は正しい指定がされていることが保証されている。また、全てのオブジェクトの生成、更新、削除時に、ジャーナル生成し出力している。図１０で、ステップ７０１〜７０４がディクショナリ管理部１０４の処理、７０９〜７１５が部品オブジェクト管理部１０２の処理、それ以外はオブジェクト管理部１０３の処理である。

ステップ７０１で、必要なスキーマ情報、つまりオブジェクト識別子で示されたオブジェクトのタイプ定義オブジェクトとその属性定義オブジェクトをディクショナリ１０８から取り出す。ステップ７０２で、変更要求コードが更新で、指定された属性名が存在するかどうかを調べる。もし、存在するなら、ステップ７０３で、指定されたスキーマデータタイプがスキーマ情報と同じかどうかを調べる。もし、同じデータタイプなら、ステップ７０４で、直接、ＤＢ１０７のオブジェクトの属性値を変更して終了する。ステップ７０２で、スキーマ内に属性名が存在しないとき、ステップ７０５で、要求コードを追加に変更する。ステップ７０６で、要求コードが更新の時、ステップ７０７で、前属性の削除と、指定された属性の追加を保持する部品属性オブジェクトを生成する。ステップ７０８で、要求コードが削除なら、ステップ７０９で、削除用部品属性オブジェクトを生成し、ステップ７０８でそうでないなら、ステップ７１０で、追加用部品属性オブジェクトを生成する。ステップ７１１で、部品属性オブジェクトを指定したオブジェクトが同じバージョン番号で保持しているかどうかを調べ、もしもっているなら、ステップ７１２で、本処理で生成した部品属性オブジェクトが持つ情報を、ＤＢ１０７の既存部品属性オブジェクトに追加する。ステップ７１１で持っていないなら、ステップ７１３で、指定したオブジェクトに、本処理で生成した部品属性オブジェクトをタイプ定義オブジェクトに登録する。ステップ７１４で、属性追加処理が発生したかどうかを調べる。追加があれば、ステップ７１５で、構成変更オブジェクトを生成し、ＤＢ１０７のオブジェクトに登録して終了する。

図１１は関連変更の処理フローである。ユーザは本処理を要求する時、ビュー管理部１０１を介しオブジェクト管理部１０３に関連名、関連の意味、関連種別、関連元オブジェクト、関連元オブジェクトを指定する。指定する関連情報は正しい指定がされていることが保証されている。なお、追加の場合、ステップ８０４〜８０９を、削除の場合ステップ８０２〜８０３を実行する。全てのオブジェクトの生成、更新、削除時に、ジャーナルを作成し出力する。図１０で、ステップ８０１〜８０４のディクショナリ管理部１０４の処理、それ以外がオブジェクト管理部１０３の処理である。

ステップ８０１で、スキーマ情報、つまり関連名で関連定義オブジェクトを取り出す。ステップ８０２で、スキーマ内に関連名が存在するかどうかを調べる。もし存在するなら、ステップ８０３で、ディクショナリ１０８の既存の関連定義オブジェクトを削除する。ただし、関連対集合オブジェクトは、そのままにしておく。ステップ８０４で、指定されたパラメタに従って、関連定義オブジェクトを生成する。このとき、ステップ８０３で削除した関連定義オブジェクトが持っている関連対集合オブジェクトを保持させる。ステップ８０５で、ＤＢ１０７より関連定義オブジェクトが保持する関連対集合オブジェクトから関連対オブジェクトを順番に取り出す。ステップ８０６で、全てとりだされるまで以下の処理を繰り返す。ステップ８０７で、関連元オブジェクトが指定オブジェクトと一致した場合、ステップ８０８で、取り出した関連対オブジェクトの関連先オブジェクト群に、指定された関連先オブジェクトを追加する。関連元オブジェクトが一致しない場合、次の関連対オブジェクトを取り出す。もし全て取り出されてしまったら、関連対オブジェクトを生成し、関連対集合オブジェクトに登録する。

図１２は、手続き変更の処理フローである。ユーザは本処理を要求する時、ビュー管理部１０１を介してオブジェクト管理部１０３にオブジェクト識別子、変更要求コード（追加、削除、更新）、セレクタ名、パラメタ群（タイプ、値）、実行コードを指定する。全オブジェクトの生成、更新、削除に対してジャーナルを出力する。図１２で、ステップ９０１〜９０３、９０５、９０６がディクショナリ管理部１０４の処理、ステップ９０７以降が部品オブジェクト管理部１０２の処理、それ以外がオブジェクト１０３の処理である。

ステップ９０１で、スキーマ情報を取り出す。ステップ９０２で、変更要求コードが更新で、指定オブジェクトのタイプ情報にセレクタ名が存在するかどうかを調べる。もし存在するなら、ステップ９０３で、パラメタの数、並びおよび各々のタイプが同じかどうかを調べる。もし、同じならステップ９０４で、実行コードを書き換えて終了する。ステップ９０３で、もし違うなら、ステップ９０５で、変更要求コードを追加に変更する。ステップ９０２で、存在しないなら、ステップ９０６で、変更要求コードを追加に変更する。ステップ９０７で、変更要求コードが更新なら、ステップ９０８で、前手続きを削除し、指定された手続きを追加する部品手続きオブジェクトを生成する。ステップ９０９で、変更要求コードが削除かどうか調べる。そうでないなら、ステップ９１０で、追加用部品オブジェクトを生成する。ステップ９０９でそうなら、ステップ９１１で、削除用部品オブジェクトを生成する。ステップ９１２で、指定したオブジェクトが部品手続きオブジェクトを持っているかどうかを調べる。もし持っているなら、ステップ９１３で、生成した手続情報を既存部品手続きオブジェクトに追加する。ステップ９１２で、もし持っていないなら、ステップ９１４で、生成した部品手続きオブジェクトを登録する。

図１３に、あるタイプ定義の変更をＤＢ再構成時に反映する処理フローを示す。ユーザは、ビュー管理部１０１を介してオブジェクト管理部１０３にタイプ定義オブジェクトのオブジェクト識別子を指定する。図１３で、ステップ１００１、１００４、１００８がディクショナリ管理部１０４の処理、それ以外はオブジェクト管理部１０３の処理である。

ステップ１００１で、タイプ定義オブジェクトを取得する。ステップ１００２で、部品属性オブジェクトの情報がなくなるまで以下の処理を行う。ステップ１００３で、部品属性オブジェクトがもつ変更情報のすべてに対して処理が終了したかを調べる。まだなら、ステップ１００４で、部品オブジェクト管理部１０２より属性変更情報を取得し、その情報を元にスキーマのタイプ定義オブジェクトが持つ属性情報を変更する。ステップ１００５で、変更後のタイプ情報に基づいて、該タイプに属する全オブジェクトを変更する。このとき、構成変更オブジェクトが持つ属性データを使用する。ステップ１００６で、手続き変更情報を持つ部品手続きオブジェクトがあるかどうか調べる。もしあるなら、ステップ１００７で部品手続きオブジェクトが持つ変更情報のすべてに対して処理が終了したかどうかを調べる。まだなら、ステップ１００８で部品オブジェクト管理部１０２より部品手続きオブジェクトを取得し、その情報を元にスキーマのタイプ定義オブジェクトの手続き情報を変更する。

図１４に、ビュー定義の一例を示す。本例は、スキーマ定義に対する属性の並びの順を設定する定義例である。ｃｏｍｐｕｔｅｒタイプの属性は、バージョン番号で指定された変更までの定義に対して、型名、メモリサイズ、ハードディスクの順にくらべてアクセスされることを示している。

図１５に、図１４に示したビューを実現する処理フローを示す。本処理はビュー管理部１０１が行うが、スキーマ情報の処理はディクショナリ管理部１０４に、部品オブジェクトの処理は部品オブジェクト管理部１０２に依頼する。図１４で、ステップ１２０３がディクショナリ管理部１０４の処理、ステップ１２０２、１２０８、１２０９が部品オブジェクト管理部１０２の処理である。また、ステップ１２０７はオブジェクト管理部１０３からのデータ転送となる。

ステップ１２０１で、ビュー定義が存在するかどうかを調べる。存在しなくなるまで処理を行う。もし存在するなら、ステップ１２０２で、ビュー定義からタイプ名を取得する。ステップ１２０３で、ステップ１２０２で取得したタイプ名を元にタイプ定義オブジェクトを取得する。ステップ１２０４で、指定バージョンまでの定義で、ビュー定義内に属性名が存在するかどうかを調べる。存在しなくなったら、ステップ１２０１に戻る。もし存在するなら、ステップ１２０５で、指定バージョンまでの定義で、スキーマ内に指定した名称があるかどうかを調べる。もし存在するなら、ステップ１２０６で、指定バージョンまでの部品属性オブジェクトで削除されていないかどうかを調べる。もし削除されていないなら、ステップ１２０７で、転送されたオブジェクトから属性値を取り出し、ユーザ領域に転送する。ステップ１２０５で、もし存在しないなら、ステップ１２０８で、指定バージョンまでの部品属性オブジェクトに名称が追加属性名として存在するかどうかを調べる。もし存在するなら、ステップ１２０９で、部品属性オブジェクトの追加属性の属性値を持つオブジェクトの構成変更オブジェクトの属性値をユーザ領域に転送する。ステップ１２０８で、もし存在しないなら、ステップ１２１０で、属性名が存在しない旨をエラーで通知する。ＮＵＬＬデータをユーザ領域に転送する。

以上、本発明の実施例を説明したが、定義オブジェクトが保持する属性、関連、手続きの各定義変更情報を保持する部品オブジェクトと該オブジェクトの構成変更情報を保持する部品オブジェクトに旧バージョン定義オブジェクト及び旧バージョンオブジェクトとの差分情報を保持し、該オブジェクトの定義情報の変更及び該オブジェクト自身の変更後であっても、旧バージョンの該オブジェクトの定義情報及び該オブジェクト自身を導出できるようにしてもよい。

また、ある時点で定義オブジェクトと該定義オブジェクトの更新情報を保持する部品オブジェクトから、該定義オブジェクトの新バージョンオブジェクトとして該定義オブジェクトに、オブジェクトと該オブジェクトの部品オブジェクトから、新バージョンのオブジェクトとして、該オブジェクトに統合するようにしてもよい。

本発明の一実施例のシステム構成図である。 メタ定義情報中のタイプ定義情報、属性定義情報、手続き定義情報である。 メタ定義情報中の関連定義情報、関連対定義情報である。 メタ定義情報中の部品属性定義情報、部品手続定義情報である。 メタ定義情報中の関連管理定義情報、構成変更定義情報である。 タイプ定義オブジェクトと関連定義オブジェクトの例である。 図６の定義オブジェクトに付加されている部品オブジェクトの例である。 図６のスキーマ定義に基づくオブジェクトの例である。 関連変更後の関連定義オブジェクト、関連対集合オブジェクト、関連管理オブジェクト、関連対オブジェクトの例である。 属性変更の処理フロー図である。 関連変更の処理フロー図である。 手続き変更の処理フロー図である。 タイプ定義変更をデータベース再構成に反映する処理フロー図である。 ビュー定義の例である。 図１４のビューを実現する処理フロー図である。

符号の説明

１０１ ビュー定義部
１０２ 部品オブジェクト管理部
１０３ オブジェクト管理部
１０４ ディクショナリ管理部
１０５ 更新履歴管理部
１０６ ジャーナル
１０７ データベース
１０８ ディクショナリ

Claims (10)

1. 属性と関連と手続きを持つオブジェクト、該オブジェクトの構造を定めた定義情報を持つ定義オブジェクトを有するオブジェクト指向データベースシステムにおいて、
   前記定義オブジェクトの変更に伴う属性、関連、手続きの各変更情報を部品オブジェクトとして定義オブジェクトに保持し、
   前記定義オブジェクトの変更で新たにオブジェクトに付加されるデータを各オブジェクトに部品オブジェクトとして保持することを特徴とするオブジェクト拡張方式。
2. 請求項１記載のオブジェクト拡張方式において、定義オブジェクトの変更情報を保持する部品オブジェクトを識別するための部品オブジェクト識別子群を保持する領域を定義オブジェクトに、またオブジェクトの構成変更情報を保持する部品オブジェクトを識別するための部品オブジェクト識別子群を保持する領域を該オブジェクトに保持することを特徴とするオブジェクト拡張方式。
3. 請求項１および２記載のオブジェクト拡張方式において、定義オブジェクトの変更情報を保持する部品オブジェクト群から定義オブジェクトの変更履歴を、オブジェクトの構成変更情報を保持する部品オブジェクトから該オブジェクト自身の変更履歴として保持することを特徴とするオブジェクト拡張方式。
4. 請求項１乃至３記載のオブジェクト拡張方式において、定義オブジェクトの変更情報を保持する部品オブジェクト生成時に、定義オブジェクトの更新ジャーナルを、オブジェクトの構成変更情報を保持する部品オブジェクト生成時に、オブジェクトの更新ジャーナルを生成することを特徴とするオブジェクト拡張方式。
5. 請求項１乃至４記載のオブジェクト拡張方式において、定義オブジェクトと該定義オブジェクトが保持する部品オブジェクトから、新バージョンの定義オブジェクトを、オブジェクトと該オブジェクトが保持する部品オブジェクトから、新バージョンのオブジェクトを生成することを特徴とするオブジェクト拡張方式。
6. 請求項１乃至５記載のオブジェクト拡張方式において、属性の定義変更情報を持つ部品オブジェクトに、バージョン番号、変更種別（追加／削除）、変更位置、属性名称、データタイプ、データ長を保持することを特徴とするオブジェクト拡張方式。
7. 請求項１乃至５記載のオブジェクト拡張方式において、手続の定義変更情報を持つ部品オブジェクトに、バージョン番号、変更種別（追加／削除）、セレクタ名、パラメタ数、パラメタタイプ、戻り値のタイプ、実行コード情報を保持することを特徴とするオブジェクト拡張方式。
8. 請求項１乃至５記載のオブジェクト拡張方式において、関連定義オブジェクトに、関連名、関連種別、関連元タイプ数及びタイプ情報群、関連先タイプ数及びタイプ情報群、関連意味情報、関連が保持する属性情報群、関連元オブジェクト及び関連先オブジェクト群及び関連の属性データ群を持つ関連対オブジェクトの集合を保持することを特徴とするオブジェクト拡張方式。
9. 請求項１乃至８記載のオブジェクト拡張方式において、該オブジェクトに関連名、関連対オブジェクト群を保持する関連管理オブジェクト群を保持することを特徴とするオブジェクト拡張方式。
10. 請求項１乃至９記載のオブジェクト拡張方式において、定義オブジェクトと定義変更情報を持つ部品オブジェクトから、定義変更後の定義オブジェクトを、オブジェクトと該オブジェクトの構成変更情報を保持する部品オブジェクトから、定義変更後のオブジェクトを動的にビューとして生成することとを特徴とするオブジェクト拡張方式。

Images