JPH07200381A

JPH07200381A - オブジェクト拡張方式

Info

Publication number: JPH07200381A
Application number: JP5338052A
Authority: JP
Inventors: Takeo Maruyama; 剛男丸山; Satoru Wakayama; 哲和歌山; Yoichi Yamamoto; 洋一山本
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1993-12-28
Filing date: 1993-12-28
Publication date: 1995-08-04
Anticipated expiration: 2022-04-25
Also published as: US5710920A; JP3910221B2

Abstract

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

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】従来のデータベースシステムでは、デー
タの定義の集合であるスキーマを変更すれば、変更前の
データに影響を及ぼす。これは、データ構造が変更され
てしまうからである。このデータ構造の変更をいつ行う
かが問題となる。オブジェクト指向データベースでも同
様の問題がある。対策方法として、即時更新（Ｉmmedia
te-update）と遅延更新（deferred-update）がある。

【０００３】即時更新は、スキーマ更新時にその更新に
対して、影響を受けるオブジェクトをスキーマ更新時に
同時に影響を受けるすべてのオブジェクトを変更してし
まう方法である。この方法は、オブジェクトが大量に存
在するとき、スキーマ変更に伴う変更作業量が大きい。
一方、遅延更新は、スキーマ更新後、その更新に影響を
受けるオブジェクトがアクセスされた時に変更を反映す
る作業を行う方法である。属性追加／挿入はNULLデータ
をいれ、オブジェクトを更新する。後者は、スキーマ更
新の処理速度は前者より早いが、アクセスされないオブ
ジェクトは、古いスキーマの構造のまま存在することに
なるため、アクセス時にどの定義構造の状態なのかを判
定した上で該当する定義情報に従って変更を行わなくて
はならない。即時更新及び遅延更新については、例え
ば、Ｗom Ｋim：Ｉntroduction toＯbject-oriented Ｄ
atabases，ＭＩＴ press，pp．５０−５２に記載されて
いる。

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

【０００５】

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

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

【０００７】

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

【０００８】

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

【０００９】

【実施例】以下、本発明の一実施例を図１乃至図１５を
使用して詳述する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００２８】図７は、図６の定義に付加されている部品
オブジェクトの例である。これは、図６の定義のcomput
erタイプの属性に、“ハードディスクサイズ”を追加
し、“ＯＳ名”を削除し、手続き“onＵnix”を追加し
た場合である。この部品オブジェクトはＤＢ１０７に格
納され、部品オブジェクト管理部１０２で管理される。

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

【００３０】部品手続きオブジェクト４０３は、オブジ
ェクト識別子Ｐ３を持ち、computerタイプにセレクタ名
“onＵnix”でパラメタなし、戻り値論理タイプ（boole
an）を追加する情報を保持する。ただし、図７では、実
行コードは「………」で記載し内部詳細コードは省略し
た。

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

【００３２】オブジェクト５０１は、personタイプで、
名前が日立太郎、１８才、オブジェクト５０２は、comp
uterタイプで、型名がＨＴ３０１０、メモリサイズが３
２（メガバイト）、ＯＳ名がＤＯＳ／Ｖ、オブジェクト
５０３は、processorタイプで、型名がｉ３８６ＳＸ、
２５メガクロック、オブジェクト５０４は、processor
タイプで、型名がｉ４８６ＤＸ２、６６メガクロックで
あることを示す。オブジェクト５０２は、オブジェクト
識別子ＰＰ１の構成変更オブジェクト５０５とオブジェ
クト識別子ｒｃ１の関連管理オブジェクト５０６を保持
する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００５３】

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

【図面の簡単な説明】

【図１】本発明の一実施例のシステム構成図である。

【図２】メタ定義情報中のタイプ定義情報、属性定義情
報、手続き定義情報である。

【図３】メタ定義情報中の関連定義情報、関連対定義情
報である。

【図４】メタ定義情報中の部品属性定義情報、部品手続
定義情報である。

【図５】メタ定義情報中の関連管理定義情報、構成変更
定義情報である。

【図６】タイプ定義オブジェクトと関連定義オブジェク
トの例である。

【図７】図６の定義オブジェクトに付加されている部品
オブジェクトの例である。

【図８】図６のスキーマ定義に基づくオブジェクトの例
である。

【図９】関連変更後の関連定義オブジェクト、関連対集
合オブジェクト、関連管理オブジェクト、関連対オブジ
ェクトの例である。

【図１０】属性変更の処理フロー図である。

【図１１】関連変更の処理フロー図である。

【図１２】手続き変更の処理フロー図である。

【図１３】タイプ定義変更をデータベース再構成に反映
する処理フロー図である。

【図１４】ビュー定義の例である。

【図１５】図１４のビューを実現する処理フロー図であ
る。

【符号の説明】

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

Claims

【特許請求の範囲】

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