JP3910221B2 - オブジェクト指向データベース管理システム及び方法 - Google Patents
オブジェクト指向データベース管理システム及び方法 Download PDFInfo
- Publication number
- JP3910221B2 JP3910221B2 JP33805293A JP33805293A JP3910221B2 JP 3910221 B2 JP3910221 B2 JP 3910221B2 JP 33805293 A JP33805293 A JP 33805293A JP 33805293 A JP33805293 A JP 33805293A JP 3910221 B2 JP3910221 B2 JP 3910221B2
- Authority
- JP
- Japan
- Prior art keywords
- definition
- data
- information
- attribute
- change
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/289—Object oriented databases
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
Description
【０００１】
【産業上の利用分野】
本発明は、オブジェクト指向データベース管理システム及び方法に関し、特にオブジェクトの定義の変更に伴うオブジェクトの変更に好適なオブジェクト指向データベース管理 技術に関する。
【０００２】
【従来の技術】
従来のデータベースシステムでは、データの定義の集合であるスキーマを変更すれば、変更前のデータに影響を及ぼす。これは、データ構造が変更されてしまうからである。このデータ構造の変更をいつ行うかが問題となる。オブジェクト指向データベースでも同様の問題がある。対策方法として、即時更新（Ｉmmediate-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タイプに１：１で部品関連を持つプロセッサ関連３０４がある。実際に関連定義オブジェクト３０４で定義された関連を持つ関連定義オブジェクトの破線部は、各定義オブジェクトのオブジェクト識別子である。また関連対集合オブジェクト３０５及び関連対オブジェクト３０６から、関連名“プロセッサ”の関連は、オブジェクト識別子Ｏ２を持つオブジェクトとオブジェクト識別子Ｏ３を持つオブジェクトの間に成り立っていることがわかる。ただし、関連対集合オブジェクトは、定義情報を保持するディクショナリ１０８に保持されるが、関連対オブジェクトは、オブジェクトが保持されるＤＢ１０７に保持する。これは、オブジェクトの関連を管理する関連管理オブジェクトからも参照されるためである。図６では、関連対オブジェクトとの対応が分かりやすいように、関連対オブジェクトも示したものである。
【００２８】
図７は、図６の定義に付加されている部品オブジェクト（定義部品オブジェクト）の例である。これは、図６の定義のcomputerタイプの属性に、“ハードディスクサイズ”を追加し、“ＯＳ名”を削除し、手続き“onＵnix”を追加した場合である。この部品オブジェクトはＤＢ１０７に格納され、部品オブジェクト管理部１０２で管理される。
【００２９】
部品属性オブジェクト４０１は、オブジェクト識別子Ｐ１を持ち、computerタイプに、属性名“ハードディスクサイズ”を追加し、属性“ＯＳ名”を削除する情報を保持する。部品属性オブジェクト４０２は、オブジェクト識別子Ｐ２を持ち、属性名“所有月数”を追加する情報を保持する。この属性は、後の説明で表れる関連の属性の定義情報である。
【００３０】
部品手続きオブジェクト４０３は、オブジェクト識別子Ｐ３を持ち、computerタイプにセレクタ名“onＵnix”でパラメタなし、戻り値論理タイプ（boolean）を追加する情報を保持する。ただし、図７では、実行コードは「………」で記載し内部詳細コードは省略した。
【００３１】
図８は、図６のスキーマ定義に基づくオブジェクト例（データオブジェクト、データ部品オブジェクト））である。破線部はオブジェクトが持つシステム情報で、前半部はタイプのオブジェクト識別子、そのタイプのバージョン番号、自分のオブジェクト識別子を、後半部は、構成変更オブジェクトのオブジェクト識別子、関連管理オブジェクトのオブジェクト識別子を保持する。このオブジェクトはＤＢ１０７に格納され、オブジェクト管理部１０３で管理される。
【００３２】
オブジェクト５０１は、personタイプで、名前が日立太郎、１８才、オブジェクト５０２は、computerタイプで、型名がＨＴ３０１０、メモリサイズが３２（メガバイト）、ＯＳ名がＯＳ Ａ、オブジェクト５０３は、processorタイプで、型名がＰ rocessor Ａ、２５メガクロック、オブジェクト５０４は、processorタイプで、型名がＰ rocessor Ｂ、６６メガクロックであることを示す。ここで、オブジェクト（データオブジェクト）５０２ は、構成変更オブジェクト５０５のオブジェクト識別子ｐｐ１と関連管理オブジェクト５０６のオブジェクト識別子ｒｃ１を保持する。
【００３３】
構成変更オブジェクト（データ部品オブジェクト）５０５は、オブジェクト識別子ＰＰ１をもち、部品属性オブジェクト４０２で追加された属性“ハードディスクサイズ”の属性値“５００”を保持する。ここで、値“５００”は単なる例示である。
【００３４】
関連管理オブジェクト５０６は、computerオブジェクト５０２が持つ関連“プロセッサ”が、保持する関連元オブジェクト（computerオブジェクト５０２自身）と関連先オブジェクト群を保持する関連対オブジェクト３０６（図６）を保持する。図６では、関連対オブジェクト３０６は、関連元オブジェクトＯ２、関連先オブジェクトＯ３を持つ。これにより、オブジェクト５０２とオブジェクト５０３がプロセッサ関連を持つことがわかる。
【００３５】
図９は、関連変更後の関連定義オブジェクト、関連対集合オブジェクト、関連管理オブジェクト、関連対オブジェクトの例を示す。本例では、図６及び図８で示したオブジェクト５０２とオブジェクト５０３が持つプロセッサ関連の定義を名称、“プロセッサズ”、関連種別、１：ｎに変更し、新たにpersonタイプとcomputerタイプ間に”所有者”関連とその逆関連として”所有物”関連を定義する。また、“プロセッサズ”関連を新たにオブジェクト５０２とオブジェクト５０４にはり、オブジェクト５０１とオブジェクト５０２に所有者（及び所有物）関連を張る。これらの情報のうち、関連定義オブジェクトがディレクトリ１０８に格納される情報であり、それ以外はＤＢ１０７に格納される情報である。
【００３６】
関連定義オブジェクト６０１は、関連名“所有物”で１：ｎで関連元タイプperson、関連先タイプcomputerで、関連の属性定義４０２（図７）を持ち、関連対集合オブジェクト６０５を持つ事を示す。関連定義オブジェクト６０２は、関連名“所有者”で１：ｎで関連元タイプcomputer、関連先タイプpersonで、関連の属性定義４０２を持ち、関連対集合オブジェクト６０６を持つ事を示す。関連定義オブジェクト６０１と関連定義オブジェクト６０２は、関連と逆関連の関係になる。関連定義オブジェクト６０３は、関連名“プロセッサズ”で１：ｎで関連元タイプcomputer、関連先タイプprocessorで、部品関連関連の属性定義４０２を持ち、関連対集合オブジェクト６０４を持つ事を示す。これは、関連定義オブジェクト３０４（図６）の関連名と関連の種別が変更されたものである。ゆえに、オブジェクト識別子が同じＲ１になっている。
【００３７】
関連管理オブジェクト６０７は、関連管理オブジェクト５０６が変更されたものである。関連名“プロセッサ”がプロセッサズに変更され、新たに追加された関連の関連名“所有者”と関連対オブジェクト６１１が追加される。また、関連管理オブジェクト６０８に、新たに追加された関連の関連名“所有物”と関連対オブジェクト６１０を持つ。関連管理オブジェクト６０８は、オブジェクト５０１の関連管理オブジェクトとして保持されるよう変更される。つまり破線部後半の２番目に関連管理オブジェクトを保持する。
【００３８】
関連対オブジェクト６０９は、新たに追加されたオブジェクト５０２とオブジェクト５０４の関連が付加するため、関連先オブジェクトにオブジェクト５０４が付加される。また関連対オブジェクト６１０で、オブジェクト５０１とオブジェクト５０２の関連が示され、関連対オブジェクト６１１で、オブジェクト５０２とオブジェクト５０１の関連が示される。
【００３９】
図１０乃至図１２に、本発明によるオブジェクトの属性／関連／手続きの変更処理フローを示す。いずれの場合も、処理は基本的にオブジェクト管理部１０３が中心となって行い、必要に応じてスキーマ情報処理をディクショナリ管理部１０４、部品オブジェクト処理を部品オブジェクト管理部１０２に依頼し、必要なデータをもらってＤＢ１０７の内容に反映させる。
【００４０】
図１０は、属性変更の処理フローである。ユーザは本処理を要求するとき、ビュー管理部１０１を介してオブジェクト管理部１０３に、オブジェクト識別子、定義変更時のバージョン番号、変更要求コード（追加、削除、更新）、変更属性情報として、属性名、属性タイプ、タイプサイズ、属性値を渡す。指定する属性名、タイプ、タイプサイズ、属性値は正しい指定がされていることが保証されている。また、全てのオブジェクトの生成、更新、削除時に、ジャーナル生成し出力している。図１０で、ステップ７０１〜７０３がディクショナリ管理部１０４の処理、７０９〜７１５が部品オブジェクト管理部１０２の処理、それ以外はオブジェクト管理部１０３の処理である。
【００４１】
ステップ７０１で、必要なスキーマ情報、つまりオブジェクト識別子で示されたオブジェクトのタイプ定義オブジェクトとその属性定義オブジェクトをディクショナリ１０８から取り出す。ステップ７０２で、変更要求コードが更新で、指定された属性名が存在するかどうかを調べる。もし、存在するなら、ステップ７０３で、指定されたスキーマデータタイプがスキーマ情報と同じかどうかを調べる。もし、同じデータタイプなら、ステップ７０４で、直接、ＤＢ１０７のオブジェクトの属性値を変更して終了する。ステップ７０２で、スキーマ内に属性名が存在しないとき、ステップ７０５で、要求コードを追加に変更する。ステップ７０６で、要求コードが更新の時、ステップ７０７で、前属性の削除と、指定された属性の追加を保持する部品属性オブジェクトを生成する。ステップ７０８で、要求コードが削除なら、ステップ７０９で、削除用部品属性オブジェクトを生成し、ステップ７０８でそうでないなら、ステップ７１０で、追加用部品属性オブジェクトを生成する。ステップ７１１で、部品属性オブジェクトを指定したオブジェクトが同じバージョン番号で保持しているかどうかを調べ、もしもっているなら、ステップ７１２で、本処理で生成した部品属性オブジェクトが持つ情報を、ＤＢ１０７の既存部品属性オブジェクトに追加する。ステップ７１１で持っていないなら、ステップ７１３で、指定したオブジェクトに、本処理で生成した部品属性オブジェクトをタイプ定義オブジェクトに登録する。ステップ７１４で、属性追加処理が発生したかどうかを調べる。追加があれば、ステップ７１５で、構成変更オブジェクトを生成し、ＤＢ１０７のオブジェクトに登録して終了する。
【００４２】
図１１は関連変更の処理フローである。ユーザは本処理を要求する時、ビュー管理部１０１を介しオブジェクト管理部１０３に関連名、関連の意味、関連種別、関連元オブジェクト、関連元オブジェクトを指定する。指定する関連情報は正しい指定がされていることが保証されている。なお、追加の場合、ステップ８０４〜８０９を、削除の場合ステップ８０２〜８０３を実行する。全てのオブジェクトの生成、更新、削除時に、ジャーナルを作成し出力する。図１１で、ステップ８０１〜８０４のディクショナリ管理部１０４の処理、それ以外がオブジェクト管理部１０３の処理である。
【００４３】
ステップ８０１で、スキーマ情報、つまり関連名で関連定義オブジェクトを取り出す。ステップ８０２で、スキーマ内に関連名が存在するかどうかを調べる。もし存在するなら、ステップ８０３で、ディクショナリ１０８の既存の関連定義オブジェクトを削除する。ただし、関連対集合オブジェクトは、そのままにしておく。ステップ８０４で、指定されたパラメタに従って、関連定義オブジェクトを生成する。このとき、ステップ８０３で削除した関連定義オブジェクトが持っている関連対集合オブジェクトを保持させる。ステップ８０５で、ＤＢ１０７より関連定義オブジェクトが保持する関連対集合オブジェクトから関連対オブジェクトを順番に取り出す。ステップ８０６で、全てとりだされるまで以下の処理を繰り返す。ステップ８０７で、関連元オブジェクトが指定オブジェクトと一致した場合、ステップ８０８で、取り出した関連対オブジェクトの関連先オブジェクト群に、指定された関連先オブジェクトを追加する。関連元オブジェクトが一致しない場合、次の関連対オブジェクトを取り出す。もし全て取り出されてしまったら、関連対オブジェクトを生成し、関連対集合オブジェクトに登録する。
【００４４】
図１２は、手続き変更の処理フローである。ユーザは本処理を要求する時、ビュー管理部１０１を介してオブジェクト管理部１０３にオブジェクト識別子、変更要求コード（追加、削除、更新）、セレクタ名、パラメタ群（タイプ、値）、実行コードを指定する。全オブジェクトの生成、更新、削除に対してジャーナルを出力する。図１２で、ステップ９０１〜９０３、９０５、９０６がディクショナリ管理部１０４の処理、ステップ９０７以降が部品オブジェクト管理部１０２の処理、それ以外がオブジェクト管理部１０３の処理である。
【００４５】
ステップ９０１で、スキーマ情報を取り出す。ステップ９０２で、変更要求コードが更新で、指定オブジェクトのタイプ情報にセレクタ名が存在するかどうかを調べる。もし存在するなら、ステップ９０３で、パラメタの数、並びおよび各々のタイプが同じかどうかを調べる。もし、同じならステップ９０４で、実行コードを書き換えて終了する。ステップ９０３で、もし違うなら、ステップ９０５で、変更要求コードを追加に変更する。ステップ９０２で、存在しないなら、ステップ９０６で、変更要求コードを追加に変更する。ステップ９０７で、変更要求コードが更新なら、ステップ９０８で、前手続きを削除し、指定された手続きを追加する部品手続きオブジェクトを生成する。ステップ９０９で、変更要求コードが削除かどうか調べる。そうでないなら、ステップ９１０で、追加用部品オブジェクトを生成する。ステップ９０９でそうなら、ステップ９１１で、削除用部品オブジェクトを生成する。ステップ９１２で、指定したオブジェクトが部品手続きオブジェクトを持っているかどうかを調べる。もし持っているなら、ステップ９１３で、生成した手続情報を既存部品手続きオブジェクトに追加する。ステップ９１２で、もし持っていないなら、ステップ９１４で、生成した部品手続きオブジェクトを登録する。
【００４６】
図１３に、あるタイプ定義の変更をＤＢ再構成時に反映する処理フローを示す。ユーザは、ビュー管理部１０１を介してオブジェクト管理部１０３にタイプ定義オブジェクトのオブジェクト識別子を指定する。図１３で、ステップ１００１、１００４、１００８がディクショナリ管理部１０４の処理、それ以外はオブジェクト管理部１０３の処理である。
【００４７】
ステップ１００１で、タイプ定義オブジェクトを取得する。ステップ１００２で、部品属性オブジェクトの情報がなくなるまで以下の処理を行う。ステップ１００３で、部品属性オブジェクトがもつ変更情報のすべてに対して処理が終了したかを調べる。まだなら、ステップ１００４で、部品オブジェクト管理部１０２より属性変更情報を取得し、その情報を元にスキーマのタイプ定義オブジェクトが持つ属性情報を変更する。ステップ１００５で、変更後のタイプ情報に基づいて、該タイプに属する全オブジェクトを変更する。このとき、構成変更オブジェクトが持つ属性データを使用する。ステップ１００６で、手続き変更情報を持つ部品手続きオブジェクトがあるかどうか調べる。もしあるなら、ステップ１００７で部品手続きオブジェクトが持つ変更情報のすべてに対して処理が終了したかどうかを調べる。まだなら、ステップ１００８で部品オブジェクト管理部１０２より部品手続きオブジェクトを取得し、その情報を元にスキーマのタイプ定義オブジェクトの手続き情報を変更する。
【００４８】
図１４に、ビュー定義の一例を示す。本例は、スキーマ定義に対する属性の並びの順を設定する定義例である。computerタイプの属性は、バージョン番号で指定された変更までの定義に対して、型名、メモリサイズ、ハードディスクの順にならべてアクセスされることを示している。
【００４９】
図１５に、図１４に示したビューを実現する処理フローを示す。本処理はビュー管理部１０１が行うが、スキーマ情報の処理はディクショナリ管理部１０４に、部品オブジェクトの処理は部品オブジェクト管理部１０２に依頼する。図１４で、ステップ１２０３がディクショナリ管理部１０４の処理、ステップ１２０２、１２０８、１２０９が部品オブジェクト管理部１０２の処理である。また、ステップ１２０７はオブジェクト管理部１０３からのデータ転送となる。
【００５０】
ステップ１２０１で、ビュー定義が存在するかどうかを調べる。存在しなくなるまで処理を行う。もし存在するなら、ステップ１２０２で、ビュー定義からタイプ名を取得する。ステップ１２０３で、ステップ１２０２で取得したタイプ名を元にタイプ定義オブジェクトを取得する。ステップ１２０４で、指定バージョンまでの定義で、ビュー定義内に属性名が存在するかどうかを調べる。存在しなくなったら、ステップ１２０１に戻る。もし存在するなら、ステップ１２０５で、指定バージョンまでの定義で、スキーマ内に指定した名称があるかどうかを調べる。もし存在するなら、ステップ１２０６で、指定バージョンまでの部品属性オブジェクトで削除されていないかどうかを調べる。もし削除されていないなら、ステップ１２０７で、転送されたオブジェクトから属性値を取り出し、ユーザ領域に転送する。ステップ１２０５で、もし存在しないなら、ステップ１２０８で、指定バージョンまでの部品属性オブジェクトに名称が追加属性名として存在するかどうかを調べる。もし存在するなら、ステップ１２０９で、部品属性オブジェクトの追加属性の属性値を持つオブジェクトの構成変更オブジェクトの属性値をユーザ領域に転送する。ステップ１２０８で、もし存在しないなら、ステップ１２１０で、属性名が存在しない旨をエラーで通知する。ＮULLデータをユー
ザ領域に転送する。
【００５１】
以上、本発明の実施例を説明したが、定義オブジェクトが保持する属性、関連、手続きの各定義変更情報を保持する部品オブジェクトと該オブジェクトの構成変更情報を保持する部品オブジェクトに旧バージョン定義オブジェクト及び旧バージョンオブジェクトとの差分情報を保持し、該オブジェクトの定義情報の変更及び該オブジェクト自身の変更後であっても、旧バージョンの該オブジェクトの定義情報及び該オブジェクト自身を導出できるようにしてもよい。
【００５２】
また、ある時点で定義オブジェクトと該定義オブジェクトの更新情報を保持する部品オブジェクトから、該定義オブジェクトの新バージョンオブジェクトとして該定義オブジェクトに、オブジェクトと該オブジェクトの部品オブジェクトから、新バージョンのオブジェクトとして、該オブジェクトに統合するようにしてもよい。
【００５３】
【発明の効果】
以上説明したように、本発明によれば、スキーマ定義を変更することなく、オブジェクト（データオブジェクト）に属性、関連、手続きの追加、削除、定義変更が行える。また、ユーザ領域に通常のオブジェクトと同じ様にアクセスできるため、データ操作が簡単に行えるようになる。さらに、部品オブジェクト（定義部品オブジェクト、データ部品オブジェクト）そのものが、定義及びデータの変更歴として利用できるため、スキーマ変更に伴う定義及びデータの変更分の差分更新情報を新たに取る必要がない。
【図面の簡単な説明】
【図１】 本発明の一実施例のシステム構成図である。
【図２】 メタ定義情報中のタイプ定義情報、属性定義情報、手続き定義情報である。
【図３】 メタ定義情報中の関連定義情報、関連対定義情報である。
【図４】 メタ定義情報中の部品属性定義情報、部品手続定義情報である。
【図５】 メタ定義情報中の関連管理定義情報、構成変更定義情報である。
【図６】 タイプ定義オブジェクトと関連定義オブジェクトの例である。
【図７】 図６の定義オブジェクトに付加されている部品オブジェクトの例である。
【図８】 図６のスキーマ定義に基づくオブジェクトの例である。
【図９】 関連変更後の関連定義オブジェクト、関連対集合オブジェクト、関連管理オブジェクト、関連対オブジェクトの例である。
【図１０】 属性変更の処理フロー図である。
【図１１】 関連変更の処理フロー図である。
【図１２】 手続き変更の処理フロー図である。
【図１３】 タイプ定義変更をデータベース再構成に反映する処理フロー図である。
【図１４】 ビュー定義の例である。
【図１５】 図１４のビューを実現する処理フロー図である。
【符号の説明】
１０１ ビュー定義部
１０２ 部品オブジェクト管理部
１０３ オブジェクト管理部
１０４ ディクショナリ管理部
１０５ 更新履歴管理部
１０６ ジャーナル
１０７ データベース
１０８ ディクショナリ
【産業上の利用分野】
本発明は、オブジェクト指向データベース管理システム及び方法に関し、特にオブジェクトの定義の変更に伴うオブジェクトの変更に好適なオブジェクト指向データベース管理 技術に関する。
【０００２】
【従来の技術】
従来のデータベースシステムでは、データの定義の集合であるスキーマを変更すれば、変更前のデータに影響を及ぼす。これは、データ構造が変更されてしまうからである。このデータ構造の変更をいつ行うかが問題となる。オブジェクト指向データベースでも同様の問題がある。対策方法として、即時更新（Ｉmmediate-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タイプに１：１で部品関連を持つプロセッサ関連３０４がある。実際に関連定義オブジェクト３０４で定義された関連を持つ関連定義オブジェクトの破線部は、各定義オブジェクトのオブジェクト識別子である。また関連対集合オブジェクト３０５及び関連対オブジェクト３０６から、関連名“プロセッサ”の関連は、オブジェクト識別子Ｏ２を持つオブジェクトとオブジェクト識別子Ｏ３を持つオブジェクトの間に成り立っていることがわかる。ただし、関連対集合オブジェクトは、定義情報を保持するディクショナリ１０８に保持されるが、関連対オブジェクトは、オブジェクトが保持されるＤＢ１０７に保持する。これは、オブジェクトの関連を管理する関連管理オブジェクトからも参照されるためである。図６では、関連対オブジェクトとの対応が分かりやすいように、関連対オブジェクトも示したものである。
【００２８】
図７は、図６の定義に付加されている部品オブジェクト（定義部品オブジェクト）の例である。これは、図６の定義のcomputerタイプの属性に、“ハードディスクサイズ”を追加し、“ＯＳ名”を削除し、手続き“onＵnix”を追加した場合である。この部品オブジェクトはＤＢ１０７に格納され、部品オブジェクト管理部１０２で管理される。
【００２９】
部品属性オブジェクト４０１は、オブジェクト識別子Ｐ１を持ち、computerタイプに、属性名“ハードディスクサイズ”を追加し、属性“ＯＳ名”を削除する情報を保持する。部品属性オブジェクト４０２は、オブジェクト識別子Ｐ２を持ち、属性名“所有月数”を追加する情報を保持する。この属性は、後の説明で表れる関連の属性の定義情報である。
【００３０】
部品手続きオブジェクト４０３は、オブジェクト識別子Ｐ３を持ち、computerタイプにセレクタ名“onＵnix”でパラメタなし、戻り値論理タイプ（boolean）を追加する情報を保持する。ただし、図７では、実行コードは「………」で記載し内部詳細コードは省略した。
【００３１】
図８は、図６のスキーマ定義に基づくオブジェクト例（データオブジェクト、データ部品オブジェクト））である。破線部はオブジェクトが持つシステム情報で、前半部はタイプのオブジェクト識別子、そのタイプのバージョン番号、自分のオブジェクト識別子を、後半部は、構成変更オブジェクトのオブジェクト識別子、関連管理オブジェクトのオブジェクト識別子を保持する。このオブジェクトはＤＢ１０７に格納され、オブジェクト管理部１０３で管理される。
【００３２】
オブジェクト５０１は、personタイプで、名前が日立太郎、１８才、オブジェクト５０２は、computerタイプで、型名がＨＴ３０１０、メモリサイズが３２（メガバイト）、ＯＳ名がＯＳ Ａ、オブジェクト５０３は、processorタイプで、型名がＰ rocessor Ａ、２５メガクロック、オブジェクト５０４は、processorタイプで、型名がＰ rocessor Ｂ、６６メガクロックであることを示す。ここで、オブジェクト（データオブジェクト）５０２ は、構成変更オブジェクト５０５のオブジェクト識別子ｐｐ１と関連管理オブジェクト５０６のオブジェクト識別子ｒｃ１を保持する。
【００３３】
構成変更オブジェクト（データ部品オブジェクト）５０５は、オブジェクト識別子ＰＰ１をもち、部品属性オブジェクト４０２で追加された属性“ハードディスクサイズ”の属性値“５００”を保持する。ここで、値“５００”は単なる例示である。
【００３４】
関連管理オブジェクト５０６は、computerオブジェクト５０２が持つ関連“プロセッサ”が、保持する関連元オブジェクト（computerオブジェクト５０２自身）と関連先オブジェクト群を保持する関連対オブジェクト３０６（図６）を保持する。図６では、関連対オブジェクト３０６は、関連元オブジェクトＯ２、関連先オブジェクトＯ３を持つ。これにより、オブジェクト５０２とオブジェクト５０３がプロセッサ関連を持つことがわかる。
【００３５】
図９は、関連変更後の関連定義オブジェクト、関連対集合オブジェクト、関連管理オブジェクト、関連対オブジェクトの例を示す。本例では、図６及び図８で示したオブジェクト５０２とオブジェクト５０３が持つプロセッサ関連の定義を名称、“プロセッサズ”、関連種別、１：ｎに変更し、新たにpersonタイプとcomputerタイプ間に”所有者”関連とその逆関連として”所有物”関連を定義する。また、“プロセッサズ”関連を新たにオブジェクト５０２とオブジェクト５０４にはり、オブジェクト５０１とオブジェクト５０２に所有者（及び所有物）関連を張る。これらの情報のうち、関連定義オブジェクトがディレクトリ１０８に格納される情報であり、それ以外はＤＢ１０７に格納される情報である。
【００３６】
関連定義オブジェクト６０１は、関連名“所有物”で１：ｎで関連元タイプperson、関連先タイプcomputerで、関連の属性定義４０２（図７）を持ち、関連対集合オブジェクト６０５を持つ事を示す。関連定義オブジェクト６０２は、関連名“所有者”で１：ｎで関連元タイプcomputer、関連先タイプpersonで、関連の属性定義４０２を持ち、関連対集合オブジェクト６０６を持つ事を示す。関連定義オブジェクト６０１と関連定義オブジェクト６０２は、関連と逆関連の関係になる。関連定義オブジェクト６０３は、関連名“プロセッサズ”で１：ｎで関連元タイプcomputer、関連先タイプprocessorで、部品関連関連の属性定義４０２を持ち、関連対集合オブジェクト６０４を持つ事を示す。これは、関連定義オブジェクト３０４（図６）の関連名と関連の種別が変更されたものである。ゆえに、オブジェクト識別子が同じＲ１になっている。
【００３７】
関連管理オブジェクト６０７は、関連管理オブジェクト５０６が変更されたものである。関連名“プロセッサ”がプロセッサズに変更され、新たに追加された関連の関連名“所有者”と関連対オブジェクト６１１が追加される。また、関連管理オブジェクト６０８に、新たに追加された関連の関連名“所有物”と関連対オブジェクト６１０を持つ。関連管理オブジェクト６０８は、オブジェクト５０１の関連管理オブジェクトとして保持されるよう変更される。つまり破線部後半の２番目に関連管理オブジェクトを保持する。
【００３８】
関連対オブジェクト６０９は、新たに追加されたオブジェクト５０２とオブジェクト５０４の関連が付加するため、関連先オブジェクトにオブジェクト５０４が付加される。また関連対オブジェクト６１０で、オブジェクト５０１とオブジェクト５０２の関連が示され、関連対オブジェクト６１１で、オブジェクト５０２とオブジェクト５０１の関連が示される。
【００３９】
図１０乃至図１２に、本発明によるオブジェクトの属性／関連／手続きの変更処理フローを示す。いずれの場合も、処理は基本的にオブジェクト管理部１０３が中心となって行い、必要に応じてスキーマ情報処理をディクショナリ管理部１０４、部品オブジェクト処理を部品オブジェクト管理部１０２に依頼し、必要なデータをもらってＤＢ１０７の内容に反映させる。
【００４０】
図１０は、属性変更の処理フローである。ユーザは本処理を要求するとき、ビュー管理部１０１を介してオブジェクト管理部１０３に、オブジェクト識別子、定義変更時のバージョン番号、変更要求コード（追加、削除、更新）、変更属性情報として、属性名、属性タイプ、タイプサイズ、属性値を渡す。指定する属性名、タイプ、タイプサイズ、属性値は正しい指定がされていることが保証されている。また、全てのオブジェクトの生成、更新、削除時に、ジャーナル生成し出力している。図１０で、ステップ７０１〜７０３がディクショナリ管理部１０４の処理、７０９〜７１５が部品オブジェクト管理部１０２の処理、それ以外はオブジェクト管理部１０３の処理である。
【００４１】
ステップ７０１で、必要なスキーマ情報、つまりオブジェクト識別子で示されたオブジェクトのタイプ定義オブジェクトとその属性定義オブジェクトをディクショナリ１０８から取り出す。ステップ７０２で、変更要求コードが更新で、指定された属性名が存在するかどうかを調べる。もし、存在するなら、ステップ７０３で、指定されたスキーマデータタイプがスキーマ情報と同じかどうかを調べる。もし、同じデータタイプなら、ステップ７０４で、直接、ＤＢ１０７のオブジェクトの属性値を変更して終了する。ステップ７０２で、スキーマ内に属性名が存在しないとき、ステップ７０５で、要求コードを追加に変更する。ステップ７０６で、要求コードが更新の時、ステップ７０７で、前属性の削除と、指定された属性の追加を保持する部品属性オブジェクトを生成する。ステップ７０８で、要求コードが削除なら、ステップ７０９で、削除用部品属性オブジェクトを生成し、ステップ７０８でそうでないなら、ステップ７１０で、追加用部品属性オブジェクトを生成する。ステップ７１１で、部品属性オブジェクトを指定したオブジェクトが同じバージョン番号で保持しているかどうかを調べ、もしもっているなら、ステップ７１２で、本処理で生成した部品属性オブジェクトが持つ情報を、ＤＢ１０７の既存部品属性オブジェクトに追加する。ステップ７１１で持っていないなら、ステップ７１３で、指定したオブジェクトに、本処理で生成した部品属性オブジェクトをタイプ定義オブジェクトに登録する。ステップ７１４で、属性追加処理が発生したかどうかを調べる。追加があれば、ステップ７１５で、構成変更オブジェクトを生成し、ＤＢ１０７のオブジェクトに登録して終了する。
【００４２】
図１１は関連変更の処理フローである。ユーザは本処理を要求する時、ビュー管理部１０１を介しオブジェクト管理部１０３に関連名、関連の意味、関連種別、関連元オブジェクト、関連元オブジェクトを指定する。指定する関連情報は正しい指定がされていることが保証されている。なお、追加の場合、ステップ８０４〜８０９を、削除の場合ステップ８０２〜８０３を実行する。全てのオブジェクトの生成、更新、削除時に、ジャーナルを作成し出力する。図１１で、ステップ８０１〜８０４のディクショナリ管理部１０４の処理、それ以外がオブジェクト管理部１０３の処理である。
【００４３】
ステップ８０１で、スキーマ情報、つまり関連名で関連定義オブジェクトを取り出す。ステップ８０２で、スキーマ内に関連名が存在するかどうかを調べる。もし存在するなら、ステップ８０３で、ディクショナリ１０８の既存の関連定義オブジェクトを削除する。ただし、関連対集合オブジェクトは、そのままにしておく。ステップ８０４で、指定されたパラメタに従って、関連定義オブジェクトを生成する。このとき、ステップ８０３で削除した関連定義オブジェクトが持っている関連対集合オブジェクトを保持させる。ステップ８０５で、ＤＢ１０７より関連定義オブジェクトが保持する関連対集合オブジェクトから関連対オブジェクトを順番に取り出す。ステップ８０６で、全てとりだされるまで以下の処理を繰り返す。ステップ８０７で、関連元オブジェクトが指定オブジェクトと一致した場合、ステップ８０８で、取り出した関連対オブジェクトの関連先オブジェクト群に、指定された関連先オブジェクトを追加する。関連元オブジェクトが一致しない場合、次の関連対オブジェクトを取り出す。もし全て取り出されてしまったら、関連対オブジェクトを生成し、関連対集合オブジェクトに登録する。
【００４４】
図１２は、手続き変更の処理フローである。ユーザは本処理を要求する時、ビュー管理部１０１を介してオブジェクト管理部１０３にオブジェクト識別子、変更要求コード（追加、削除、更新）、セレクタ名、パラメタ群（タイプ、値）、実行コードを指定する。全オブジェクトの生成、更新、削除に対してジャーナルを出力する。図１２で、ステップ９０１〜９０３、９０５、９０６がディクショナリ管理部１０４の処理、ステップ９０７以降が部品オブジェクト管理部１０２の処理、それ以外がオブジェクト管理部１０３の処理である。
【００４５】
ステップ９０１で、スキーマ情報を取り出す。ステップ９０２で、変更要求コードが更新で、指定オブジェクトのタイプ情報にセレクタ名が存在するかどうかを調べる。もし存在するなら、ステップ９０３で、パラメタの数、並びおよび各々のタイプが同じかどうかを調べる。もし、同じならステップ９０４で、実行コードを書き換えて終了する。ステップ９０３で、もし違うなら、ステップ９０５で、変更要求コードを追加に変更する。ステップ９０２で、存在しないなら、ステップ９０６で、変更要求コードを追加に変更する。ステップ９０７で、変更要求コードが更新なら、ステップ９０８で、前手続きを削除し、指定された手続きを追加する部品手続きオブジェクトを生成する。ステップ９０９で、変更要求コードが削除かどうか調べる。そうでないなら、ステップ９１０で、追加用部品オブジェクトを生成する。ステップ９０９でそうなら、ステップ９１１で、削除用部品オブジェクトを生成する。ステップ９１２で、指定したオブジェクトが部品手続きオブジェクトを持っているかどうかを調べる。もし持っているなら、ステップ９１３で、生成した手続情報を既存部品手続きオブジェクトに追加する。ステップ９１２で、もし持っていないなら、ステップ９１４で、生成した部品手続きオブジェクトを登録する。
【００４６】
図１３に、あるタイプ定義の変更をＤＢ再構成時に反映する処理フローを示す。ユーザは、ビュー管理部１０１を介してオブジェクト管理部１０３にタイプ定義オブジェクトのオブジェクト識別子を指定する。図１３で、ステップ１００１、１００４、１００８がディクショナリ管理部１０４の処理、それ以外はオブジェクト管理部１０３の処理である。
【００４７】
ステップ１００１で、タイプ定義オブジェクトを取得する。ステップ１００２で、部品属性オブジェクトの情報がなくなるまで以下の処理を行う。ステップ１００３で、部品属性オブジェクトがもつ変更情報のすべてに対して処理が終了したかを調べる。まだなら、ステップ１００４で、部品オブジェクト管理部１０２より属性変更情報を取得し、その情報を元にスキーマのタイプ定義オブジェクトが持つ属性情報を変更する。ステップ１００５で、変更後のタイプ情報に基づいて、該タイプに属する全オブジェクトを変更する。このとき、構成変更オブジェクトが持つ属性データを使用する。ステップ１００６で、手続き変更情報を持つ部品手続きオブジェクトがあるかどうか調べる。もしあるなら、ステップ１００７で部品手続きオブジェクトが持つ変更情報のすべてに対して処理が終了したかどうかを調べる。まだなら、ステップ１００８で部品オブジェクト管理部１０２より部品手続きオブジェクトを取得し、その情報を元にスキーマのタイプ定義オブジェクトの手続き情報を変更する。
【００４８】
図１４に、ビュー定義の一例を示す。本例は、スキーマ定義に対する属性の並びの順を設定する定義例である。computerタイプの属性は、バージョン番号で指定された変更までの定義に対して、型名、メモリサイズ、ハードディスクの順にならべてアクセスされることを示している。
【００４９】
図１５に、図１４に示したビューを実現する処理フローを示す。本処理はビュー管理部１０１が行うが、スキーマ情報の処理はディクショナリ管理部１０４に、部品オブジェクトの処理は部品オブジェクト管理部１０２に依頼する。図１４で、ステップ１２０３がディクショナリ管理部１０４の処理、ステップ１２０２、１２０８、１２０９が部品オブジェクト管理部１０２の処理である。また、ステップ１２０７はオブジェクト管理部１０３からのデータ転送となる。
【００５０】
ステップ１２０１で、ビュー定義が存在するかどうかを調べる。存在しなくなるまで処理を行う。もし存在するなら、ステップ１２０２で、ビュー定義からタイプ名を取得する。ステップ１２０３で、ステップ１２０２で取得したタイプ名を元にタイプ定義オブジェクトを取得する。ステップ１２０４で、指定バージョンまでの定義で、ビュー定義内に属性名が存在するかどうかを調べる。存在しなくなったら、ステップ１２０１に戻る。もし存在するなら、ステップ１２０５で、指定バージョンまでの定義で、スキーマ内に指定した名称があるかどうかを調べる。もし存在するなら、ステップ１２０６で、指定バージョンまでの部品属性オブジェクトで削除されていないかどうかを調べる。もし削除されていないなら、ステップ１２０７で、転送されたオブジェクトから属性値を取り出し、ユーザ領域に転送する。ステップ１２０５で、もし存在しないなら、ステップ１２０８で、指定バージョンまでの部品属性オブジェクトに名称が追加属性名として存在するかどうかを調べる。もし存在するなら、ステップ１２０９で、部品属性オブジェクトの追加属性の属性値を持つオブジェクトの構成変更オブジェクトの属性値をユーザ領域に転送する。ステップ１２０８で、もし存在しないなら、ステップ１２１０で、属性名が存在しない旨をエラーで通知する。ＮULLデータをユー
ザ領域に転送する。
【００５１】
以上、本発明の実施例を説明したが、定義オブジェクトが保持する属性、関連、手続きの各定義変更情報を保持する部品オブジェクトと該オブジェクトの構成変更情報を保持する部品オブジェクトに旧バージョン定義オブジェクト及び旧バージョンオブジェクトとの差分情報を保持し、該オブジェクトの定義情報の変更及び該オブジェクト自身の変更後であっても、旧バージョンの該オブジェクトの定義情報及び該オブジェクト自身を導出できるようにしてもよい。
【００５２】
また、ある時点で定義オブジェクトと該定義オブジェクトの更新情報を保持する部品オブジェクトから、該定義オブジェクトの新バージョンオブジェクトとして該定義オブジェクトに、オブジェクトと該オブジェクトの部品オブジェクトから、新バージョンのオブジェクトとして、該オブジェクトに統合するようにしてもよい。
【００５３】
【発明の効果】
以上説明したように、本発明によれば、スキーマ定義を変更することなく、オブジェクト（データオブジェクト）に属性、関連、手続きの追加、削除、定義変更が行える。また、ユーザ領域に通常のオブジェクトと同じ様にアクセスできるため、データ操作が簡単に行えるようになる。さらに、部品オブジェクト（定義部品オブジェクト、データ部品オブジェクト）そのものが、定義及びデータの変更歴として利用できるため、スキーマ変更に伴う定義及びデータの変更分の差分更新情報を新たに取る必要がない。
【図面の簡単な説明】
【図１】 本発明の一実施例のシステム構成図である。
【図２】 メタ定義情報中のタイプ定義情報、属性定義情報、手続き定義情報である。
【図３】 メタ定義情報中の関連定義情報、関連対定義情報である。
【図４】 メタ定義情報中の部品属性定義情報、部品手続定義情報である。
【図５】 メタ定義情報中の関連管理定義情報、構成変更定義情報である。
【図６】 タイプ定義オブジェクトと関連定義オブジェクトの例である。
【図７】 図６の定義オブジェクトに付加されている部品オブジェクトの例である。
【図８】 図６のスキーマ定義に基づくオブジェクトの例である。
【図９】 関連変更後の関連定義オブジェクト、関連対集合オブジェクト、関連管理オブジェクト、関連対オブジェクトの例である。
【図１０】 属性変更の処理フロー図である。
【図１１】 関連変更の処理フロー図である。
【図１２】 手続き変更の処理フロー図である。
【図１３】 タイプ定義変更をデータベース再構成に反映する処理フロー図である。
【図１４】 ビュー定義の例である。
【図１５】 図１４のビューを実現する処理フロー図である。
【符号の説明】
１０１ ビュー定義部
１０２ 部品オブジェクト管理部
１０３ オブジェクト管理部
１０４ ディクショナリ管理部
１０５ 更新履歴管理部
１０６ ジャーナル
１０７ データベース
１０８ ディクショナリ
Claims (4)
- 属性と関連と手続きを持つオブジェクト（以下、データオブジェクト）を格納したデータベースと、
前記データオブジェクトの構造を定めた定義情報を持つ定義オブジェクトを格納したデクショナリファイルと、
前記定義オブジェクトの定義情報の変更に伴う属性、関連、手続きの変更情報を部品オブジェクト（以下、定義部品オブジェクト）として前記データベースに格納し、当該定義部品オブジェクトの識別子を前記定義オブジェクトに追加する手段と、
前記定義情報の変更情報に基づいて前記データオブジェクトを変更する情報を保持する部品オブジェクト（以下、データ部品オブジェクト）を生成して前記データベースに格納し、当該データ部品オブジェクトの識別子を前記データオブジェクトに追加する手段と、
前記定義オブジェクトの定義部品オブジェクト識別子をもとに前記データベースから前記定義部品オブジェクトを取得して、前記定義オブジェクトと前記定義部品オブジェクトとから定義変更後の定義オブジェクトを、前記データオブジェクトのデータ部品オブジェクト識別子をもとに前記データベースから前記データ部品オブジェクトを取得して、前記データオブジェクトと前記データ部品オブジェクトとから定義変更後のデータオブジェクトを動的にビューとして生成する手段と、
を備えることを特徴とするオブジェクト指向データベース管理システム。 - 請求項１記載のオブジェクト指向データベース管理システムにおいて、
前記部品オブジェクトからオブジェクトの変更情報を抽出し、更新履歴情報としてジャーナルに出力する手段を有することを特徴とするオブジェクト指向データベース管理システム。 - 属性と関連と手続きを持つオブジェクト（以下、データオブジェクト）をデータベースに格納し、前記データオブジェクトの構造を定めた定義情報を持つ定義オブジェクトをデクショナリファイルに格納して管理するオブジェクト指向データベース管理方法において、
前記定義オブジェクトの定義情報の変更に伴う属性、関連、手続きの変更情報を部品オブジェクト（以下、定義部品オブジェクト）として前記データベースに格納し、当該定義部品オブジェクトの識別子を前記定義オブジェクトに追加し、
前記定義情報の変更情報に基づいて前記データオブジェクトを変更する情報を保持する部品オブジェクト（以下、データ部品オブジェクト）を生成して前記データベースに格納し、当該データ部品オブジェクトの識別子を前記データオブジェクトに追加し、
前記定義オブジェクトの定義部品オブジェクト識別子をもとに前記データベースから前記定義部品オブジェクトを取得して、前記定義オブジェクトと前記定義部品オブジェクトとから定義変更後の定義オブジェクトを、前記データオブジェクトのデータ部品オブジェクト識別子をもとに前記データベースから前記データ部品オブジェクトを取得して、前記データオブジェクトと前記データ部品オブジェクトとから定義変更後のデータオブジェクトを動的にビューとして生成する、
ことを特徴とするオブジェクト指向データベース管理方法。 - 請求項３記載のオブジェクト指向データベース管理方法において、
前記部品オブジェクトからオブジェクトの変更情報を抽出し、更新履歴情報としてジャーナルに出力することを特徴とするオブジェクト指向データベース管理方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP33805293A JP3910221B2 (ja) | 1993-12-28 | 1993-12-28 | オブジェクト指向データベース管理システム及び方法 |
| US08/362,873 US5710920A (en) | 1993-12-28 | 1994-12-23 | Object extending method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP33805293A JP3910221B2 (ja) | 1993-12-28 | 1993-12-28 | オブジェクト指向データベース管理システム及び方法 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004242778A Division JP2005032271A (ja) | 2004-08-23 | 2004-08-23 | オブジェクト指向データベース管理システム及び方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07200381A JPH07200381A (ja) | 1995-08-04 |
| JP3910221B2 true JP3910221B2 (ja) | 2007-04-25 |
Family
ID=18314465
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP33805293A Expired - Fee Related JP3910221B2 (ja) | 1993-12-28 | 1993-12-28 | オブジェクト指向データベース管理システム及び方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5710920A (ja) |
| JP (1) | JP3910221B2 (ja) |
Families Citing this family (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6128771A (en) * | 1996-02-09 | 2000-10-03 | Sun Microsystems, Inc. | System and method for automatically modifying database access methods to insert database object handling instructions |
| JP3427918B2 (ja) * | 1996-07-02 | 2003-07-22 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プログラム開発支援システム及び支援方法 |
| US5991765A (en) * | 1997-05-06 | 1999-11-23 | Birdstep Technology As | System and method for storing and manipulating data in an information handling system |
| SE521056C2 (sv) * | 1997-07-21 | 2003-09-23 | Ericsson Telefon Ab L M | Metod för genomförande av schemaförändringar i en databas |
| US6195794B1 (en) | 1997-08-12 | 2001-02-27 | International Business Machines Corporation | Method and apparatus for distributing templates in a component system |
| US6093215A (en) * | 1997-08-12 | 2000-07-25 | International Business Machines Corporation | Method and apparatus for building templates in a component system |
| US5978579A (en) * | 1997-08-12 | 1999-11-02 | International Business Machines Corporation | Architecture for customizable component system |
| US5970252A (en) * | 1997-08-12 | 1999-10-19 | International Business Machines Corporation | Method and apparatus for loading components in a component system |
| US6182279B1 (en) | 1997-08-12 | 2001-01-30 | International Business Machines Corporation | Method and apparatus for storing templates in a component system |
| US6049807A (en) * | 1997-09-03 | 2000-04-11 | International Business Machines Corporation | Technique for maintaining object integrity during modification of a persistent store of objects |
| US6026408A (en) * | 1998-01-28 | 2000-02-15 | Unisys Corp. | Method for synchronizing the schema of a database with its representation in an object-oriented repository |
| US6857123B1 (en) * | 1998-12-18 | 2005-02-15 | International Business Machines Corporation | Method and apparatus for a Meta Data Service in a data processing system |
| US6880126B1 (en) * | 1999-08-03 | 2005-04-12 | International Business Machines Corporation | Controlling presentation of a GUI, using view controllers created by an application mediator, by identifying a destination to access a target to retrieve data |
| US6779177B1 (en) | 1999-10-28 | 2004-08-17 | International Business Machines Corporation | Mechanism for cross channel multi-server multi-protocol multi-data model thin clients |
| US7181686B1 (en) | 1999-10-29 | 2007-02-20 | International Business Machines Corporation | Selecting screens in a GUI using events generated by a set of view controllers |
| US6862686B1 (en) | 1999-10-29 | 2005-03-01 | International Business Machines Corporation | Method and apparatus in a data processing system for the separation of role-based permissions specification from its corresponding implementation of its semantic behavior |
| US7082609B2 (en) * | 2000-03-31 | 2006-07-25 | Schlumbergersema Telekom Gmbh & Co. Kg | Meta application system and method |
| US20020087341A1 (en) * | 2000-03-31 | 2002-07-04 | Jochen Kappel | Customer care and billing system |
| US6697797B1 (en) | 2000-04-28 | 2004-02-24 | Micro Data Base Systems, Inc. | Method and apparatus for tracking data in a database, employing last-known location registers |
| US6898783B1 (en) * | 2000-08-03 | 2005-05-24 | International Business Machines Corporation | Object oriented based methodology for modeling business functionality for enabling implementation in a web based environment |
| US6684388B1 (en) | 2000-08-22 | 2004-01-27 | International Business Machines Corporation | Method for generating platform independent, language specific computer code |
| US7171455B1 (en) | 2000-08-22 | 2007-01-30 | International Business Machines Corporation | Object oriented based, business class methodology for generating quasi-static web pages at periodic intervals |
| US6853994B1 (en) * | 2000-08-30 | 2005-02-08 | International Business Machines Corporation | Object oriented based, business class methodology for performing data metric analysis |
| US6983486B1 (en) * | 2000-11-14 | 2006-01-03 | Mcafee, Inc. | Method and apparatus for establishing security scanner attributes in a computer system |
| US9361593B2 (en) * | 2001-03-30 | 2016-06-07 | Oracle America, Inc. | System and method for using business services |
| JP2002328935A (ja) * | 2001-05-07 | 2002-11-15 | Fujitsu Ltd | オブジェクト指向データベースのデータ操作においてスキーマに自由度を持たせるプログラム及びデータ操作装置 |
| US6976244B2 (en) * | 2002-01-09 | 2005-12-13 | International Business Machines Corporation | Method, system, and product for storage of attribute data in an object oriented environment |
| JP2006146615A (ja) * | 2004-11-19 | 2006-06-08 | Fujitsu Ltd | オブジェクト関連情報管理プログラム、管理方法、および管理装置。 |
| US7437080B2 (en) * | 2005-02-03 | 2008-10-14 | Stratalight Communications, Inc. | Optical transmission system having optimized filter wavelength offsets |
| JP4533187B2 (ja) * | 2005-03-01 | 2010-09-01 | キヤノン株式会社 | 画像処理装置およびその制御方法 |
| US7840603B2 (en) * | 2005-11-14 | 2010-11-23 | International Business Machines Corporation | Method and apparatus for database change management |
| US8355317B1 (en) * | 2007-10-31 | 2013-01-15 | World Wide Packets, Inc. | Transaction-based coordination of data object modification for primary and backup control circuitry |
| JP5387015B2 (ja) | 2009-02-02 | 2014-01-15 | 株式会社リコー | 情報処理装置、および情報処理装置の情報処理方法 |
| US10705802B2 (en) | 2013-03-20 | 2020-07-07 | Microsoft Technology Licensing, Llc | Extensible and queryable strong types |
| US11204940B2 (en) * | 2018-11-16 | 2021-12-21 | International Business Machines Corporation | Data replication conflict processing after structural changes to a database |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4914568A (en) * | 1986-10-24 | 1990-04-03 | National Instruments, Inc. | Graphical system for modelling a process and associated method |
| US5327559A (en) * | 1990-10-23 | 1994-07-05 | International Business Machines Corporation | Remote and batch processing in an object oriented programming system |
| US5432940A (en) * | 1992-11-02 | 1995-07-11 | Borland International, Inc. | System and methods for improved computer-based training |
| US5353401A (en) * | 1992-11-06 | 1994-10-04 | Ricoh Company, Ltd. | Automatic interface layout generator for database systems |
| US5590330A (en) * | 1994-12-13 | 1996-12-31 | International Business Machines Corporation | Method and system for providing a testing facility in a program development tool |
| US5561752A (en) * | 1994-12-22 | 1996-10-01 | Apple Computer, Inc. | Multipass graphics rendering method and apparatus with re-traverse flag |
-
1993
- 1993-12-28 JP JP33805293A patent/JP3910221B2/ja not_active Expired - Fee Related
-
1994
- 1994-12-23 US US08/362,873 patent/US5710920A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH07200381A (ja) | 1995-08-04 |
| US5710920A (en) | 1998-01-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3910221B2 (ja) | オブジェクト指向データベース管理システム及び方法 | |
| JP7170701B2 (ja) | 高速コピー可能データベースを効率的に実装するための方法及び機器 | |
| JP3563692B2 (ja) | データベースのスキーマをオブジェクト指向リポジトリ内のその表現と同期化する方法 | |
| US6366921B1 (en) | System and method for data manipulation in a dynamic object-based format | |
| US6766334B1 (en) | Project-based configuration management method and apparatus | |
| US6356912B1 (en) | Compensation for different connection and cursor characteristics among heterogeneous database management systems | |
| JPH10505440A (ja) | プログラミング言語−具体的データファイルのｓｑｌベースの操作を可能にするコンピュータベースの情報アクセス方法および装置 | |
| KR100529661B1 (ko) | 오브젝트 통합 관리 시스템 | |
| Taniar et al. | A taxonomy of indexing schemes for parallel database systems | |
| US6453324B1 (en) | Method for maintaining a version history of objects in a repository | |
| JP4580390B2 (ja) | ハードウェア／ソフトウェアインターフェイスシステムによって管理可能な情報単位の拡張および継承のためのシステムおよび方法 | |
| JP2005032271A (ja) | オブジェクト指向データベース管理システム及び方法 | |
| JP2643811B2 (ja) | データベース再編成方式 | |
| CN113377836B (zh) | 用于高效地实现可快速复制的数据库的方法和装置 | |
| Krogh et al. | Developing Applications Using SQL with MySQL NDB Cluster | |
| Maier | Object-oriented database theory | |
| Avison et al. | Implementing Relational Data Bases: Automating the Mapping Processes | |
| JPH1063560A (ja) | データベース管理方式 | |
| JP2000057046A (ja) | データ管理方法及び装置、データ管理システム、記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040622 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060919 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061222 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070124 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100202 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110202 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120202 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130202 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |