JP4242056B2 - データベース用スキーマ変更方法 - Google Patents

Description

【０００１】
（発明の分野）
本発明は、データベース内でスキーマ変更を遂行する方法に関する。
【０００２】
本発明は、特に、複雑スキーマ変更がソフトかハードかどうかにかかわらず、その変更を遂行する方法に関する。しかしながら、本発明の方法を単純スキーマ変更を達成することにもまた等しく応用できることは、云うまでもない。
【０００３】
（発明の背景）
異なったトランザクションによって異なったやり方で連続的に更新され又は変更されるテーブルをデータベース内に使用することは長く知られてきている。このような変更は、スキーマ変更と呼ばれる。スキーマ変更を生じないトランザクションもまたある。
【０００４】
スキーマとは、データベース内のテーブルの支配的構成を意味する。この構成は、次を含むことがある。
【０００５】
− テーブルの書式、すなわち、テーブル名、プロパティ（ｐｒｏｐｅｒｔｉ
ｅｓ）、断片化、及び異なった安全アスペクト。
【０００６】
− 異なったテーブル・カラムに割り当てられた属性、すなわち、それらの属
性が記憶できる情報の型式。
【０００７】
− どんなキ−が存在するか、すなわち、いかに外部参照が内部参照に翻訳さ
れるか。
【０００８】
− どんな外部キーが見付けられるか、すなわち、テーブル間の異なったリン
クの性質。
【０００９】
− どんな異なった指標が見付けられるか、すなわち、どんな探索経路がテー
ブル内の異なった属性に対して見付けられるか。
【００１０】
− どんなトリガがテーブルに結合されるか、すなわち、テーブル内のデータ
の変更がその変更に従ってかつ現存するキー、ことによると、外部キーに従
って他のテーブルの更新をトリガすると云うように、他の事象を開始する、
「トリガする」特別事象。
【００１１】
しかしながら、用語スキーマは、上に説明したことより遥かに多くを暗に意味するが、この用語のこれらの意味は、しかしながら、本発明についての次の説明と関連して使用される意味のうちの或るいくつかである。
【００１２】
分散型データベース内で、異なったテーブルが複数の異なった断片に分割される。このような断片は、立ち代わって、テーブルの同じ部分についてのいくつもの複写又は複製を含む。異なった断片及びそれらのそれぞれの複写は、相互に調和する（ｃｏ−ｏｐｅｒａｔｉｎｇ）コンピュータのシステム内の異なったノード内に物理的に見付けられる。システムの信頼性は、断片に属する種々の複写を分散することによって改善される。それは、このことが、たとえ１つ以上のシステムノードがクラッシュしても、情報をシステム内のどこかで利用可能にするからである。
【００１３】
それゆえ、分散型データベース内のスキーマ変更は、比較的複雑である。それは、スキーマ変更によって影響された断片の全ての複写をその変更に従って更新しなければならないからである。
【００１４】
データベース内のスキーマ変更は、異なった条件に基づいておりかつ多数の異なった参加者（ｐａｒｔｃｉｐａｎｔｓ）をしばしば含み、スキーマ変更を引き起こして、異なったテーブル内に及び／又は、データベースが分散型データベースであるとき、そのデータベースの１つ以上のテーブルの異なった部分、断片内に変更を発生させる。
【００１５】
スキーマ変更は、データベースの全ての利用者に対する条件にかつまたこれらの利用者間のトランザクションに対する条件に変更を生じる。このことは、スキーマ変更が第１スキーマ・バージョンを第２スキーマ・バージョンで以て置換する結果となる異なったスキーマ・バージョンについてもまた云うことができる。
【００１６】
スキーマ変更は、異なったいくつかのカテゴリに分割することができる。第１に、スキーマ変更は、「単純」又は「複雑」であることがあり、及び第２に、「ソフト」又は「ハード」であることがある。これらの変更特性は、部分的に、互いに無関係である。複雑スキーマ変更がハード又はソフトのどちらかであることがあるのに反して、単純スキーマ変更は常にソフトである。
【００１７】
単純スキーマ変更は、スキーマをもっぱら変更しかつ影響されるテーブル内のデータを変更しない。複雑スキーマ変更は、１つ以上のテーブル内のスキーマ及びデータの両方を変更する。
【００１８】
簡単に云うと、第１及び第２スキーマ・バージョンがソフト・スキーマ変更においては互換である。しかしながら、第２スキーマ・バージョンは、ハード・スキーマ変更の場合に、第１スキーマ・バージョンと互換でない。
【００１９】
互換性とは、第１スキーマ・バージョンに従うトランザクションが、写像又は関数を経て、第２スキーマ・バージョンに従ってテーブル内のデータを更新でき、かつ第２スキーマ・バージョンに従うトランザクションが、写像又は関数を経て、第１スキーマ・バージョンに従ってテーブル内のデータを更新できることを意味する。
【００２０】
それゆえ、先行及び後続スキーマ・バージョンが互換であるソフト・スキーマ変更は、トランザクションを両スキーマ・バージョンに従って同時に実行することを可能とする。
【００２１】
ハード・スキーマ変更の場合、第２スキーマ・バージョン内のテーブルを第１スキーマ・バージョンからのデータで以て、又はこの逆に、それを通して更新できる写像又は関数は可逆的でない。換言すれば、第１スキーマ・バージョン内のテーブルを第２スキーマ・バージョンからのデータで以て、又はこの逆に、更新することができない。
【００２２】
それゆえ、開始したトランザクションがユニットに影響を及ぼし、これらのユニットが、立ち代わって、ハード・スキーマ変更によって影響を受けるような全ての開始したトランザクションは、或る１つのスキーマ変更を開始できるにはその前に第１スキーマ・バージョンに従って終結されなければならない。そのスキーマ変更を完了したときに限り、トランザクションを第２スキーマ・バージョンに従って開始できる。
【００２３】
それゆえ、進行中のトランザクションを終結しかつ関連したスキーマ変更を実行するのに要する時間中は、第２スキーマ変更に従うトランザクションを開始できない。これらのトランザクションは、第１スキーマ・バージョンに従うトランザクションの終結を及びこのスキーマ変更が実行されるのを待機しなければならず、結果としてかなりの時間損失になる。
【００２４】
複雑スキーマ変更は本質的にデータ及びスキーマの両方に影響するから、これらの変更はいくつかの段階で或る１つの変更を必要とする。複雑スキーマ変更は、いくつもの相互に順序に並ぶスキーマ変更とトランザクションとを含む。
【００２５】
次の刊行物は、スキーマ変更を遂行する方法に関連する既知の技術を説明し、及びまた種々のかつこの分野で遭遇する問題を開示する。
【００２６】
Ｒ・Ｊ・ペーターズ及びＭ・Ｔ・エーツによる「オブジェクトベース内のダイナミック・スキーム発展の公理化」、データ工学に関する第１１回国際会議、１９９５年３月、１５６〜１６４頁、（“Ａｘｉｏｍａｔｉｚａｔｉｏｎ ｏｆ Ｄｙｎａｍｉｃ Ｓｃｈｅｍｅ Ｅｖｏｌｕｔｉｏｎ ｉｎ Ｑｂｊｅｃｔｂａｓｅｓ”，１１ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ, Ｍａｒ．１９９５，ｐｐ．１５６−１６４，ｂｙ Ｒ．Ｊ．Ｐｅｔｅｒｓ ａｎｄ Ｍ．Ｔ．Ｏｅｚｓｕ．）
【００２７】
Ｂ・Ｓ・レーナー及びＡ・Ｎ・ヘーベルマンによる「スキーマ発展を越えてデータベース再編成へ」、ＡＣＭ ＯＯＯＰＳＬＡ／ＥＣＯＯＰ ’９０資料、６７〜７６頁、オッタワ、カナダ、１９９０年１０月（“Ｂｅｙｏｎｄ Ｓｃｈｅｍａ Ｅｖｏｌｕｔｉｏｎ ｔｏ Ｄａｔａ−ｂａｓｅ Ｒｅｏｒｇｎａｉｚａｔｉｏｎ”，Ｐｒｏｃ．，ＡＣＭ ＯＯＯＰＳＬＡ／ＥＣＯＯＰ ’９０，ｐｐ．６７−７６，Ｏｔｔａｗａ，Ｃａｎａｄａ，Ｏｃｔ．１９９０，ｂｙ Ｂ．Ｓ．Ｌｅｒｎｅｒ ａｎｄ Ａ．Ｎ．Ｈａｂｅｒｍａｎｎ．）
【００２８】
Ｂ・Ｓ・レーナーによる「複素型変更に対する型式発展支援」、技術報告ＵＭ−ＣＳ−９４−７１、マサチューセッツ大学、エマースト、１９９４年１０月３１日（“Ｔｙｐｅ Ｅｖｏｌｕｔｉｏｎ Ｓｕｐｐｏｒｔ ｆｏｒ Ｃｏｍｐｌｅｘ Ｔｙｐｅ Ｃｈａｎｇｅｓ”，Ｔｅｃｈｎｉｃａｌ Ｒｅｐｐｏｒｔ ＵＭ−ＣＳ−９４−７１，Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｍａｓｓａｃｈｕｓｅｔｔｓ； Ａｍｈｅｒｓｔ，Ｏｃｔ．３１， １９９４，ｂｙ Ｂ．Ｓ．Ｌｅｒｎｅｒ．）
【００２９】
Ｓ・Ｍ・クレーメンによる「スキーマ発展及び積分、分散型及び並列データベース」、２巻、１９９４年１月１日、ＩＳＳＮ ０９２６−８７８２（“Ｓｃｈｅｍａ Ｅｖｏｌｕｔｉｏｎ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ，Ｄｉｓｔｒｉｂｕｔｅｄ ａｎｄ Ｐａｒａｌｌｅｌ Ｄａｔａ−ｂａｓｅｓ”，Ｖｏｌ．２，Ｊａｎ．１，１９９４，ＩＳＳＮ ０９２６−８７８２，ｂｙ Ｓ．Ｍ．Ｃｌｅｍｅｎ．）
【００３０】
データベースと関連して云わゆるＳＡＧＡトランザクションの使用がこの分野で知られていることにまた言及しておかなければならない。これに関しては、第１トランザクションを、この第１トランザクションによって引き起こされた変更を取り消すことになる後続第２トランザクションを利用する可能性を伴って遂行できる。
【００３１】
この特定分野における技術のもっと早期の立場に関しては、コンピュータ・システム内でソフトウェアを変更するとき、新ソフトウェアを旧ソフトウェアと並列にインストールすることが知られていると述べることができる。
【００３２】
このインストールの結果として、旧ソフトウェアを除去する前に新ソフトウェアを評価又は試験できる。もしもその試験が新ソフトウェアが満足に機能しないことを示すならば、そのソフトウェアを除去しかつ旧ソフトウェアを再び使用に供することができる。もし試験が新ソフトウェアが満足に機能することを示すならば、新ソフトウェアを使用に供しかつ旧ソフトウェアを除去する。米国特許第５，４１０，７０３号は、このような方法の例を与える。
【００３３】
（発明の要約）
（技術的問題）
前述したような先行技術の状態を考えるとき、技術的問題はデータベース内で複雑スキーマ変更を遂行する方法を提供すると云う問題であることが判ろう。
【００３４】
他の技術的問題は、複雑ソフト・スキーマ変更のような又は複雑ハード・ソフト・スキーマ変更のような複雑スキーマ変更をそれで以て実行できる方法であってかつ第１スキーマ・バージョンに従うトランザクションの遂行を完了するのを待機する間及び実スキーマ変更を達成するのを待機する間のシステム停止のために複雑ハード・スキーマ変更に起こる時間損失の減少を可能とする方法を提供すると云う問題である。
【００３５】
他の技術的問題は、複雑スキーマ変更を異なった段階に分割することを可能とし、それぞれの段階が、それら自体内に、単純スキーマ変更又はテーブル更新を含むと云う問題である。
【００３６】
他の技術的問題は、スキーマ変更がソフト変更かハード変更かどうか考慮に入れるが、しかし両方の場合に機能する方法を提供することに存する。
【００３７】
他の技術的問題は、第１スキーマ・バージョンを除去するのに先立ち第２スキーマ・バージョンを所望機能に関して評価するのを許す方法を提供すると云う問題である。
【００３８】
他の技術的問題は、新たに実施されたソフトウェアを新ソフトウェアの実施と関連して必要とされたスキーマ変更と組み合わせて評価するのを可能とする方法であって、前記評価をソフトウェアの実施及びそれによって引き起こされたスキーマ変更を完了するべきか否かに関する決定の基礎として使用できる方法を提供すると云う問題である。
【００３９】
他の技術的問題は、第２スキーマ・バージョンが要件を満たさないことが発見されるとき第１スキーマ・バージョンへの復帰を行うことができる方法を提供すると云う問題である。
【００４０】
他の技術的問題は、複雑スキーマ変更において割り込みをハンドルする方法であって、かつスキーマ変更を連続することができる又は割り込みにかかわらず元のスキーマ・バージョンへの復帰を行うことができる方法を提供すると云う問題である。
【００４１】
（解 決）
前述の技術的問題の１つ以上を解決する意図を以て、本発明は、スキーマ変更に先立つ第１スキーマ・バージョンがそのスキーマ変更後の第２スキーマ・バージョンと互換である複雑ソフト・スキーマ変更、又はスキーマ変更の前の第１スキーマ・バージョンが前記スキーマ変更の後の第２スキーマ・バージョンと非互換である複雑ハード・スキーマ変更のような複雑スキーマ変更をデータベース内で遂行する方法を提供する。
【００４２】
このようなスキーマ変更の遂行をいくつもの段階に分割することが特に提案される。
【００４３】
異なった複雑スキーマ変更に対する全般方法を提供する意図を以て、複雑スキーマ変更を３段階に分割できることが本発明によれば提案される。
【００４４】
第１段階は、第１スキーマ・バージョンに従うトランザクションを完了する条件を保持する間に第２スキーマ・バージョンに従うトランザクションを開始する条件を作成することを含む準備段階を含む。
【００４５】
第１スキーマ・バージョンから第２スキーマ・バージョンへデータを転送する意図を以て、第２段階は、第２スキーマ・バージョンに従うデータへの第１スキーマ・バージョンに従うデータ転送を含む走査段階を含む。
【００４６】
全スキーマ変更は、スキーマ変更の完了の際に残っていないことになるユニットの除去を含む終結段階を含む第３段階で以て終結される。
【００４７】
第２スキーマ・バージョンの機能の評価及び第１スキーマ・バージョンへの復帰を行うことを可能とする目的を以て、２中間段階を走査段階と終結段階との間に使用できることが本発明によれば提案される。
【００４８】
第１中間段階は、或る種の評価トランザクションが第２スキーマ・バージョンに従って遂行され、それによって前記第２スキーマ・バージョンの機能を評価できる評価段階で構成される。
【００４９】
この段階に第２中間段階が続き、第２中間段階は決定段階を含み、決定段階ではスキーマ変更を完了するべきか打ち切るべきかどうかが決定され、この決定は評価段階の結果に基づいている。
【００５０】
複雑スキーマ変更がソフト・スキーマ変更でありかつその目的が第１及び第２スキーマ・バージョンを並列に動作させるのを可能とするとき、準備段階が異なったトリガ、キー、外部キー及び／又は指標の応用を含み、それによって第２スキーマ・バージョンを第１スキーマ・バージョンに影響するトランザクションに従って更新でき、かつトリガ、キー、外部キー及び／又は指標によって第１スキーマ・バージョンを第２スキーマ・バージョンに影響するトランザクションに従って更新できることが提案される。
【００５１】
この場合、評価トランザクションは、第２スキーマ・バージョンに従う通常トランザクションであってよい。
【００５２】
変更がソフト・スキーマ変更であるならば、たとえ第１スキーマ・バージョンに従うトランザクションがまだ進行中であっても、第２スキーマ・バージョンに従う通常トランザクションをデータ転送の完了の際直ちに、又は、中間段階が選択されるときは、決定段階においてそのスキーマ変更を完了する決定がなされたならば直ちに開始するのを許すことができる。
【００５３】
複雑スキーマ変更が複雑ハード・スキーマ変更であるとき、準備段階が異なったトリガ、キー、外部キー及び／又は指標の応用を含み、それによって第２スキーマ・バージョンを第１スキーマ・バージョンに影響するトランザクションに従って更新でき、又はトリガ、キー、外部キー及び／又は指標の応用によって、これら２つのスキーマ・バージョン間の支配的互換性に従ってデータを転送できる方向次第で、第１スキーマ・バージョンを第２スキーマ・バージョンに影響するトランザクションに従って更新できることが本発明によれば提案される。
【００５４】
第１スキーマ・バージョンと第２スキーマ・バージョンとが互換でないから、評価トランザクションが第１スキーマ・バージョンへの有害な影響を伴うことなく第２スキーマ・バージョンに従って遂行できる特別に設計された制御トランザクションで構成されることが本発明によれば提案される。
【００５５】
この特定の場合、第２スキーマ・バージョンに従う通常トランザクションが、第１スキーマ・バージョンに従う全てのトランザクションが完遂されるや直ちに及び、もし中間段階が選択されるならば、スキーマ変更を完了するように決定段階において決定がなされるや直ちに開始するのを許される。
【００５６】
中間段階は、スキーマ変更がハード変更かソフト変更かどうかにかかわらず、第１スキーマ・バージョンに従う全てのトランザクションが完遂された後、及び、もし中間段階が選択されるならば、スキーマ変更を完遂する決定に関して決定段階において到達した決定に従って、開始される。
【００５７】
終結段階は、スキーマ変更の後に支配的であるスキーマ・バージョンによって使用されない全てのトリガ、キー、外部キー、指標及び／又は他のユニットの除去を含む。
【００５８】
実施されることになるソフトウェアの評価を可能とするために、新ソフトウェアを実施するときに必要とされるスキーマ変更をその実施と並列に実行することが本発明によれば提案される。
【００５９】
本発明の一実施例によれば、スキーマ変更の評価段階における評価トランザクションとして新ソフトウェアによって発生されるトランザクションが新ソフトウェアを検査するときに使用される。
【００６０】
評価段階で以て得られた結果が新ソフトウェアの実施を終わらせるべきか否かに関する決定の、及びまたスキーマ変更を完了するべきか否かに関する決定の基礎として使用される。
【００６１】
割り込みの場合に第１スキーマ・バージョンを回復する又はスキーマ変更を完了することを可能とする意図を以て、スキーマ変更が云わゆるＳＡＧＡテーブル内の情報の記憶を含むことが本発明によれば提案される。
【００６２】
本発明によれば、この情報はＵＮＤＯ情報及びＲＥＤＯ情報を含み、ＵＮＤＯ情報は、スキーマ変更が準備段階、走査段階、評価段階又は決定段階においてなんらかの理由で打ち切られたスキーマ変更の場合に第１スキーマ・バージョンを再確立するために必要とされる情報を含み、及びＲＥＤＯ情報は、何らかの理由で終結段階において打ち切られたスキーマ変更の場合にスキーマ変更を終わらせる又は完了するために必要とされる情報を含む。
【００６３】
本発明の一実施例によれば、準備段階は必要なＵＮＤＯ情報の記憶を含み、及び走査段階、又は、中間段階が選択されるとき、決定段階が必要なＲＥＤＯ情報を記憶することを含む。
【００６４】
（利点）
発明の方法によって第１に与えられる利点は、複雑スキーマ変更がソフトかハードかどうかにかかわず、これらのスキーマ変更を遂行することの可能性にあり、この方法ではスキーマ変更及び、或る種の場合には、第１スキーマ・バージョンに従う全てのトランザクションの終結に先立ち第２スキーマ・バージョンに従うトランザクションをまた開始できる。実用的には、第１スキーマ・バージョンに従うトランザクションを終結する前に、終結段階を除いて、スキーマ変更の全体を実行でき、このことがスキーマ変更を開始できるにはその前に第１スキーマ・バージョンに従う全てのトランザクションを終結するのを待機することが必要である場合に対してかなりの時間利得を与える。
【００６５】
本発明によって提供される他の利点は、第１スキーマ・バージョンが喪失する前に第２スキーマ・バージョンを評価するのが可能であることである。本発明はまた、第２スキーマ・バージョンの評価がこのスキーマ・バージョンが満足に機能しないことを示すとき第１スキーマ・バージョンへ復帰するのを可能にする。
【００６６】
本発明はまた、スキーマ変更を完了する又は打ち切るのを可能とし、及びスキーマ変更によって影響されたテーブルを記憶する又はハンドルするハードウェアのクラッシュの場合におけるように、スキーマ変更の不随意な割り込みの場合に第１スキーマ・バージョンへの復帰を行うのを可能とする。
【００６７】
本発明による方法の主特性は、前掲の請求項１の特性表示部分に記載されている。
【００６８】
本発明がいっそう容易に理解されかつ更に他の特徴が明らかになるように、本発明をその例証実施例を参照してかつまた添付図面を参照して詳細に説明する。
【００６９】
（好適実施例の詳細な説明）
図１の流れ図は、本発明に従う方法を示す。
【００７０】
この方法に従うスキーマ変更は、第１スキーマ・バージョンを第２スキーマ・バージョンに変更することを引き起こす。図１に示されたように、スキーマ変更は、その変更をいくつもの段階１、２、３、４、５に分割することによって遂行される。
【００７１】
本発明の概念によれば、複雑スキーマ変更が３段階１、２、３に分割される。本方法は、第１スキーマ・バージョンを除去する前に第２スキーマ・バージョンを評価するのを可能とするように、２つの更に、中間段階４、５を含むのを許し得る。
【００７２】
もっぱら３基本段階を使用することは第２スキーマ・バージョンを使用し出す前にこれを評価するのを可能とはしないから不正確性が増すことになるが、３基本的段階１、２、３のみの使用は、或る種の場合にかなり高速の方法を提供する。更になお、或るハード・スキーマ変更の場合には２中間段階を使用するのが困難であることがある。
【００７３】
第１段階１は準備段階であって、この段階では第１スキーマ・バージョンに従うトランザクションを続行するのを許す条件を保持する間に、第２スキーマ・バージョンに従うトランザクションを開始するのを可能とする条件が発生される。
【００７４】
第２段階２は走査段階であって、この段階は第１スキーマ・バージョンに従うデータの第２スキーマ・バージョンに従うデータへの転送を含む。
【００７５】
第３段階３は終結段階であって、この段階はスキーマ変更を完了した後に残っていないことになるユニットの除去を含む。
【００７６】
前述の段階１、２、３は、３基本段階である。
【００７７】
第１中間段階４は、絶対的に必要ではないが、６で選択可能であって、評価段階である。この段階は、２つの中間段階のうちの最初でありかつ第２スキーマ・バージョンに従う或る種の評価トランザクションを遂行することを含み、それによって前記第２スキーマ・バージョンの機能を評価することができる。
【００７８】
スキーマ変更において、第２スキーマ・バージョンを、なにが可能でかつ望ましいか次第で、異なった程度に評価することができる。
【００７９】
或るいくつかのソフト・スキーマ変更においては、いくつもの評価トランザクションを遂行することを含む総合システム試験を実行するのが可能であり、それによって異なった利用者の機能及び彼らの可能な要件が評価される。
【００８０】
かなり少数の特別トランザクションを含む機能試験で充分であることが可能である。
【００８１】
或るいくつかのハード・スキーマ変更の場合、これら２スキーマ・バージョン間に不整合を生じることなく評価トランザクションを第２スキーマ・バージョンにおいて遂行できる程度次第で、単純試験、基本試験を実施すること又は試験を全くしないことが可能であるに過ぎないこともある。
【００８２】
第２中間段階５は、評価段階４が６で選択されるとき実行され、かつ決定段階でありこの段階においてスキーマ変更を完了するべきか打ち切るべきかどうかについての決定が行われる。決定は、評価段階４からの結果に基づく。
【００８３】
複雑スキーマ変更がソフト変更であるとき、準備段階１が異なったトリガ、キー、外部キー及び／又は指標の応用を含むことが本発明によれば提案される。
【００８４】
これらのトリガ及びキーは、第２スキーマ・バージョンを第１スキーマ・バージョンに影響するトランザクションに従って更新することを可能とする。トリガ、キー、外部キー及び／又は指標がまた応用されることによって、第１スキーマ・バージョンを第２スキーマ・バージョンに影響するトランザクションに従って更新することができる。
【００８５】
これは、トリガするトランザクションが第１スキーマ・バージョンに従うか又は第２スキーマ・バージョンに従うかどうかにかかわらず、１つのスキーマ・バージョンに従うトランザクションがそのトランザクション及び応用されたキーに従って他のスキーマ・バージョンの更新をトリガすることになるのを意味する。
【００８６】
もっぱら３基本段階を使用する概念によれば、たとえ第１スキーマ・バージョンに従うトランザクションがまだ進行中であっても、第２スキーマ・バージョンに従う通常トランザクションを、走査段階２が実行されたならば、すなわち、第１スキーマ・バージョンからのデータが第２スキーマ・バージョンへ転送されたとき、直ちに開始するのを許すことができる。
【００８７】
複雑スキーマ変更がハード・スキーマ変更であるとき、準備段階１が異なったトリガ、キー、外部キー、及び／又は指標を含み、このことが第２スキーマ・バージョンを第１スキーマ・バージョンに影響するトランザクションに従って更新するのを可能とし、又はトリガ、キー、外部キー及び／又は指標の応用によって第１スキーマ・バージョンを第２スキーマ・バージョンに影響するトランザクションに従って更新できることが本発明によれば提案される。
【００８８】
この場合、キーは、それら２スキーマ・バージョン間の互換性の欠如のせいで１方向にしか機能することができない。
【００８９】
ハード・スキーマ変更の場合、第２スキーマ・バージョンに従う通常トランザクションは、第１スキーマ・バージョンに従う全てのトランザクションを完了する否や開始するのを許される。
【００９０】
終結段階は、スキーマ変更がハード変更かソフト変更かどうかにかかわらず、第１スキーマ・バージョンに従う全てのトランザクションを完了したとき開始される。
【００９１】
２中間段階４、５をソフト・スキーマ変更において使用するとき、評価トランザクションが第２スキーマ・バージョンに従う通常トランザクションの選択を含んでよいことが本発明によれば提案される。
【００９２】
たとえ第１スキーマ・バージョンに従うトランザクションがまだ進行中であっても、第２スキーマ・バージョンに従う通常トランザクションを、決定段階５においてスキーマ変更を完了する決定に到達したならば、直ちに開始するのを許すことができる。
【００９３】
２つの中間段階４、５をハード・スキーマ変更において使用するとき、評価トランザクションが特別に設計された制御トランザクションであって、これらのトランザクションは第１スキーマ・バージョン又はデータベースに有害な影響を与えないで第２スキーマ・バージョンに従って遂行されるように設計されることが本発明によれば提案される。
【００９４】
有害な影響とはそれら２スキーマ・バージョン間に不整合が起こらないことを意味し、制御トランザクションが、前記制御トランザクションを実行するにかかわらず、それら２スキーマ・バージョン内の情報が等しいか又は整合していると云うような仕方で構成されなければならないことを意味する。
【００９５】
それで、第２スキーマ・バージョンに従う通常トランザクションを、評価段階５においてスキーマ変更を続行する決定に到達するや直ちに、及び第１スキーマ・バージョンに従う全てのトランザクションを完了するや直ちに、開始するのを許すことができる。
【００９６】
２中間段階４、５を使用するとき、終結段階３は決定段階５において到達した決定に従って開始され、かつ、もし決定がスキーマ変更を完了することであるならば、変更が第１スキーマ・バージョンに従う全てのトランザクションを完了した後に実行されることが本発明によればまた提案される。
【００９７】
２中間段階が使用されるか否かにかかわらず、かつ決定段階でなされることがあるどの決定にもかかわらず、第２スキーマ・バージョンによって使用されないあらゆるトリガ、キー、外部キー、指標及び／又は他のユニットがスキーマ変更を完了するとき除去され、他方、決定段階は、スキーマ変更が割り込まれる又は打ち切られるとき、第１スキーマ・バージョンによって使用されないあらゆるトリガ、キー、外部キー、指標及び／又は他のユニットの除去を含む。
【００９８】
本発明がいっそう容易に理解されるように、スキーマ変更のいくつもの具体的例及びいかにこれらを前述に従って異なった段階に分解できるかをこれから説明する。
【００９９】
第１例が図２を通して示されておりかつ第１スキーマ・バージョンＡを構成する１０属性を有するテーブルＡ１を２テーブルＢ１、Ｂ２に垂直分割することを伴い、これら２テーブルは、それぞれ、４属性及び５属性を有しかつ第２スキーマ・バージョンＢを形成し、旧テーブルＡ１内の最初の６属性は第１新テーブルＢ１を形成するものとし及び旧テーブルＡ１内の最後の４属性は第２新テーブルＢ２を形成するものとする。これは複雑ソフト・スキーマ変更である。
【０１００】
上の変更は異なったやり方で遂行でき、かつ下記の説明はいかにこのようなスキーマ変更を本発明に従って遂行できるかについてのほんの一例に関するものである。
【０１０１】
準備段階１： 図３に示されたように、この準備段階は、４属性を有する完全に新しいかつ空のテーブルＢ２の作成に至るスキーマ変更を含む。
【０１０２】
１０属性を有する旧テーブルＡ１は元のままである。これはソフト・スキーマ変更である。
【０１０３】
旧テーブルＡ１から新たに作成されたテーブルＢ２へデータを転送するために必要とされるトリガ及びキーＡＢ１、ＡＢ２、ＡＢ３、…、ＡＢｎが、第１スキーマ・バージョンＡに従う旧テーブルＡ１へのトランザクションに関して新たに作成されたテーブルＢ２を更新するために、更に他の属性ＡＢを通して旧テーブルＡ１内に作成される。
【０１０４】
簡単のためにこの更に他の属性ＡＢはこの図では単一属性として示されているが、実施では、この属性はいくつかの異なった属性で構成されてよい。これらの属性を作成する仕方は、当業者に明白であろう。同様のことは、下記の説明において同じやり方で作成される他の追加属性についても云える。
【０１０５】
第２スキーマ・バージョンに従う新テーブルＢ２へのトランザクションに関して旧テーブルＡ１を更新するために必要とされるトリガ及びキーＢＡ１、ＢＡ２、ＢＡ３、…、ＢＡｎが、新たに作成されたテーブルＢ２内の追加属性ＢＡを通してまた作成される。
【０１０６】
旧テーブルＡ１内の最初の６属性がまた新テーブルＢ１内の６属性を形成する。これは、旧テーブルＡ１内の最初の６属性と第１新テーブルＢ１間では更新のためにトリガ又はキーが必要でないことを意味する。それは、第１新テーブルＢ１に影響することになる第２スキーマ・バージョンＢに従うトランザクションが旧テーブルＡ１内の最初の６属性に直接作用することになるからであり、かつ旧テーブルＡ１内の最初の６属性に影響することになる第１スキーマ・バージョンＡに従うトランザクションが第１新テーブルＢ１に直接作用することになるからである。
【０１０７】
現存するテーブルＡ１内の各行が検査フラグＡｌｆを割り当てられ、このフラグは「０」にセットされておりかつこの行内の第１スキーマ・バージョンＡに従う情報が第２スキーマ・バージョンＢへ転送されたとき「１」に変更される。
【０１０８】
この検査フラグは、それぞれの行から第２スキーマ・バージョンＢへ情報を転送してしまうのに先立ち属性ＡＢ内のキーＡＢ１、ＡＢ２、ＡＢ３、…、ＡＢｎを「ＮＵＬＬ」にセットすることによってまた実施でき、その後、それぞれのキーＡＢ１、ＡＢ２、ＡＢ３、…、ＡＢｎはそれぞれの行について転送を行うことに関連してテーブルＢ２内の正しい行を指摘するようにセットされる。
【０１０９】
それゆえ、特定の行又はライン（ｌｉｎｅ）に対する値「ＮＵＬＬ」を有する属性ＡＢからのポインタが、新たに作成されたテーブルＢ２内の対応する行に対して意図された旧テーブルＡ１から新たに作成されたテーブルＢ２への情報がまだ転送されていないこと、及び旧テーブルＡ１内のこの行を変更するとき新たに作成されたテーブルＢ２内の対応する行を更新するべきでないことを示す。
【０１１０】
走査段階２： 旧テーブルＡ１内の最後の４属性が走査されかつ応用されたキーＡＢ１、ＡＢ２、ＡＢ３、…、ＡＢｎに従って第２新テーブルＢ２へ転送され、及び検査フラグＡＬｆが使用されるとき、このフラグが「０」から「１」へセットされる。
【０１１１】
第２新テーブルＢ２は、第１スキーマ・バージョンに従うまだ進行中であるトランザクションに従って連続的に更新され、かつ旧テーブルＡ１内の最後の４属性に関連する。情報の走査及び転送を完了したとき、第２スキーマ・バージョンＢに従うトランザクションは、まだ完了されていない第１スキーマ・バージョンＡに従うトランザクションと並列に開始するのを許されることがあり、それら４属性に関連するトランザクションが第２新テーブルＢ２へ実行され、及び第１新テーブルＢ１内の６属性に関連するトランザクションが旧テーブルＡ１内の６つの最初の属性へ実行される。
【０１１２】
第２スキーマ・バージョンＢに従うトランザクションが開始するのを許されるとき、旧テーブルＡ１は、第２の新たに作成されたテーブルＢ２内の属性ＢＡ内のキーＢＡ１、ＢＡ２、ＢＡ３、…、ＢＡｎを通して、新たに作成されたテーブルＢ２に影響するトランザクションに関して更新される。
【０１１３】
それゆえ、整合が２スキーマ・バージョンＡ、Ｂ間に得られ、及び正しいデータが利用可能であって、まだ完了しないかもしれないかつ旧テーブルＡ１内の最後の４属性に関連する第１スキーマ・バージョンＡに従うあらゆるトランザクションに対して旧テーブルＡ１が正しいデータを含むことを保証する。
【０１１４】
評価段階４： 第２スキーマ・バージョンに従う限定された数のトランザクションが、第２スキーマ・バージョンが正しく機能するか否かを確定するために、開始することを許される。
【０１１５】
決定段階５： 第２スキーマ・バージョンが正しく機能するとき、スキーマ変更を完了する、又は終わらせる決定がなされる。不正確な機能は、そのスキーマ変更を打ち切る決定を生じる。
【０１１６】
スキーマ変更を完了する決定がなされるとき、第２スキーマ・バージョンＢに従う通常トランザクションが第１スキーマ・バージョンＡに従う残りのトランザクションを完了するのと同時に行われるのを許される。
【０１１７】
スキーマ変更を打ち切る決定がなされるとき、第１スキーマ・バージョンＡに従う進行中のトランザクションが完了され、かつ第２スキーマ・バージョンＢに従う通常トランザクションは開始されない。
【０１１８】
終結段階３： 決定段階５においてスキーマ変更を完了する決定がなされるとき、第１スキーマ・バージョンＡに従う全ての進行中のトランザクションの終結を待機する。次いで、第２スキーマ・バージョンＢに使用されない旧テーブルＡ１の部分、すなわち、最後の４属性が図４に従って除去される。
【０１１９】
もし決定段階５においてスキーマ変更を打ち切る決定がなされるならば、新たに作成されたテーブルＢ２が除去され、かつ旧テーブルＡ１は元のままに維持される。これは、第１スキーマ・バージョンＡに従う全ての進行中のトランザクションの終結を待機することなく行うことができる。
【０１２０】
決定段階５においてなされた決定にかかわらず、異なったテーブルに関連するトランザクションにおいてそれぞれのテーブルを更新するために作成された更に他の属性内の全ての検査フラグＡｌｆ、トリガ、及びキーが除去される。ただし、それらが最終スキーマ・バージョンに使用されないならばである。
【０１２１】
それゆえ、テーブルの垂直分割を伴う複雑ソフト・スキーマ変更が５段階に分割されており、それらのうち第１段階及び最終段階は単純スキーマ変更であり、第２段階は情報の転送をもっぱら含み、及び第３段階及び第４段階は第２スキーマ・バージョン上の検査を構成し、このことが第１スキーマ・バージョンＡ及び第２スキーマ・バージョンＢの両方に従うトランザクションを同時に処理するのを許す。
【０１２２】
第２例は、テーブル内の属性の変更で以て確証されるものであって、複雑ハード・スキーマ変更であることがある。図示された場合では、この変更は、事実、複雑ハード・スキーマ変更である。
【０１２３】
図５は、異なる人びとの１時間当たり賃金（ｈｏｕｒｌｙ ｗａｇｅ）を表示する属性Ａ’１を含み、他方、他の属性Ａ’２がそれぞれの人が１箇月の過程にわたって働いた時間数を表示する。これは第１スキーマ・バージョンＡ’である。
【０１２４】
行われる変更はこれら２属性Ａ’１及びＡ’２を属性Ｂ’１で置換することを伴い、属性Ｂ’１はそれぞれの人の月給、又は月当たり賃金を表示する。
これは第２スキーマ・バージョンＢ’である。
【０１２５】
この例は、第１スキーマ・バージョンＡ’から第２スキーマ・バージョンＢ’への伝達関数「ｆ」を含む。関数「ｆ」は、「月給」＝「時間給（ｈｏｕｒｌｙ ｓｌａｒｙ）」＊「時間数」である。
【０１２６】
この場合、第２スキーマ・バージョンＢ’内の情報、すなわち、「月給」Ｂ’１を第１スキーマ・バージョンＡ’、すなわち、それぞれ「時間給」Ａ’１及び「時間数」Ａ’２へ転送する可能性はない。それは、「月給」Ｂ’１内の変更が「時間給」Ａ’１内の又は「時間数」Ａ’２の内の、又は、ことによると、これら両方内の変更のせいであるかどうか知られていないからである。
【０１２７】
したがって、それら２スキーマ・バージョンは互いに非互換性であり、かつそれゆえスキーマ変更がハード・スキーマ変更である。
【０１２８】
この例では、関連した属性のみが図示されている。しかしながら、これらの属性は、大方、また、おそらく、いくつかの属性を含むテーブルの部分であることは、云うまでもない。
【０１２９】
準備段階１： 図６は現存するテーブル内の属性Ｂ’１がいかに作成されるかを示し、この属性は第２スキーマ・バージョンＢ’に従う新属性「月給」を構成する。トリガＡ’Ｂ’１が作成され、それによって属性「時間給」Ａ’１及び「時間数」Ａ’２内のどれかの行内の変更がまた属性「月給」Ｂ’１内の対応する行の更新を生じる。
【０１３０】
走査段階２： この段階は属性「時間給」Ａ’１及び「時間数」Ａ’２内のそれぞれの行内の情報の走査を伴い、その後正しい情報が作成された関数「ｆ」及びトリガＡ’Ｂ’１である媒体を通して属性「月給」Ｂ’１内に置かれる。これは、第１スキーマ・バージョンＡ’に従う全てのトランザクションを完了してしまう前に開始される。
【０１３１】
評価段階４： 第２スキーマ・バージョンＢ’に従う特別評価トランザクションが開始される。これらのトランザクションは、第１スキーマ・バージョンＡ’に従う情報に有害な影響を及ぼしてはならない、換言すれば、これらのトランザクションは、２スキーマ・バージョンＡ’、Ｂ’間の不整合のような、誤りをデータベース内に発生してはならない。
【０１３２】
１つのこのような評価トランザクションは、第２スキーマ・バージョンＢ’に従って月給を挿入することが意図されるとおりに、属性「月給」Ｂ’１に現在の、正しい月給を挿入することであるかもしれない。「月給」Ｂ’１の値は、情報が両スキーマ・バージョンＡ’及びＢ’内で正しくあるために、「時間給」Ａ’１及び「時間数」Ａ’２の対応する値との関係で正しくあるべきである。
【０１３３】
それゆえ、走査段階２における第１スキーマ・バージョンＡ’から第２スキーマ・バージョンＢ’への情報の転送が複数の評価トランザクションを伴うことが判る。
【０１３４】
この例は、評価トランザクションを通しての、第２スキーマ・バージョンＢ’の試験の限定された機能のみを与える。
【０１３５】
決定段階５： 正しい機能が確立されるとき、スキーマ変更を完了する決定がなされる。不正確な機能は、スキーマ変更を打ち切る決定を招く。
【０１３６】
スキーマ変更を完了する決定がなされるとき、第１スキーマ・バージョンＡ’に従う全てのトランザクションを完了するや否や第２スキーマ・バージョンＢ’に従う通常トランザクションが開始するのを許される。
【０１３７】
もしスキーマ変更を打ち切る決定がなされるならば、第１スキーマ・バージョンＡ’に従う進行中のトランザクションが続行されかつ第２スキーマ・バージョンＢ’に従うトランザクションは開始されない。
【０１３８】
終結段階３： スキーマ変更を完了するように決定段階５において決定がなされるとき、第１スキーマ・バージョンＡ’に従う全てのトランザクションの終結を待機する。それゆえ、総合スキーマ変更がハード・スキーマ変更を構成するのにかかわらず、前述のプロセスの全ては、トランザクションが第１スキーマ・バージョンＡ’に従って続行するのと同時に実行できる。
【０１３９】
第１スキーマ・バージョンに従うトランザクションが終結されるとき、第２スキーマ・バージョンＢ’に従う通常トランザクションが開始される。図７から明らかなように、第２スキーマ・バージョンＢ’において使用されない属性「時間給」Ａ’１及び「時間数」Ａ’２が除去される。
【０１４０】
もし決定段階５においてスキーマ変更を打ち切る決定がなされるならば、新たに作成された属性Ｂ’１が除去される。これは、第１スキーマ・バージョンＡ’に従うトランザクションの終結を待機することなく、実行できる。
【０１４１】
決定段階５においてなされた決定にかかわらず、属性「１時間当たり賃金」Ａ’１及び「時間数」Ａ’２に影響したトランザクション内の属性「月給」Ｂ’１を更新するために作成された全てのトリガＡ’Ｂ’１が除去される。
【０１４２】
それゆえ、前述の複雑ハード・スキーマ変更が５段階に分割されており、これらのうち第１段階及び最終段階は単純スキーマ変更でありかつこれらのうち第２段階は単に情報の転送を含み、前記段階は第１スキーマ・バージョンＡ’に従うトランザクションと第２スキーマ・バージョンＢ’の先回り（ａｄｖａｎｃｅｄ）実施とを同時に実行するのを許す。
【０１４３】
前述で、スキーマ変更を２つの例を参照して説明したが、これらの例ではスキーマ変更によって直接影響されるテーブルのみを説明した。しかしながら、図３からまた判るように、スキーマ変更は、このスキーマ変更によって直接影響されるテーブル以外の他のテーブル、云わゆる外部テーブル（ｆｏｒｅｉｇｎ ｔａｂｌｅ）にも影響する。それは、これらのテーブルがスキーマ変更によって影響される１つ又はいくつかのテーブルと、あれこれのやり方で、調和すると云う事実のせいである。この調和がそれを通して行われるキーは、外部キーと呼ばれる。
【０１４４】
上に説明したかつ図２、３及び４に示したソフト・スキーマ変更に基づいている図示の場合には、この調和は、外部テーブルＣ１内の１つの要素の変更が第１スキーマ・バージョンに従う旧テーブルＡ１内にまた変更を生じ、かつ外部テーブルＣ１内の対応する変更がまた第１新テーブルＢ１及び第２新テーブルＢ２の両方内にまた変更を生じると云うことに存する。
【０１４５】
第１スキーマ・バージョンＡに従って存在する属性ＣＡ内の外部キーＣＡ４は、外部テーブルＣ１を旧テーブルＡ１と接続するリンクである。
【０１４６】
前述のトリガ及び外部キーに加えて、スキーマ変更の準備段階において外部テーブルＣ１と第２新テーブルＢ２とを相互に調和することを可能とするトリガ及び外部キーＣＢ４がまた作成される。外部テーブルＣ１はまた、属性ＣＡに属する外部キーを通して第１新テーブルＢ１と調和する。
【０１４７】
簡単のために、それぞれの属性ＣＡ及びＣＢ内の第４外部キーのみを示す。しかしながら、これらの属性が前述の調和に必要とされる全てのキーを含むことは、云うまでもない。
【０１４８】
変更の後に応用可能であるスキーマ・バージョンによって使用されない外部キーは、変更を完了するか否か次第で、終結段階において除去される。
【０１４９】
いかに外部テーブル及び外部キーをハンドルできるかについてのこの説明は、例としてのみ与えられる。このハンドル手順が異なったスキーマ変更と共に大きく変動することがあることは、明らかである。この手順は、上に説明した例におけるように、１つのかつ同じ例においても異なったやり方でまた実行できる。
【０１５０】
スキーマ変更がデータベースの異なった応用にまた影響することになると云う理由で、スキーマ変更をソフトウェアの起こり得る変更と、又はデータベース内の又はデータベース利用者の新ソフトウェアの実施と同期させるのが適当である。
【０１５１】
図８の流れ図は、いかにソフトウェア変更Ｙがスキーマ変更Ｘと並行に遂行されるかを示すことを意図している。
【０１５２】
スキーマ変更Ｘは、第１スキーマ・バージョンＡ’’から第２スキーマ・バージョンＢ’’への変更を伴いかつ準備段階Ｘ１及び走査段階Ｘ２で以て開始される。ソフトウェア変更Ｙの初期段階Ｙ１が同時に開始され、この段階はソフトウェアの実施を含み、この実施は同ソフトウェアを評価するのに充分である。
【０１５３】
次いで、評価段階ＸＹ１が開始され、かつ第２スキーマ・バージョンＢ’’を使用するトランザクションが新ソフトウェアＹによって発生されかつ評価段階ＸＹ１内の評価トランザクションを構成する。
【０１５４】
評価段階ＸＹ１内で実行された評価が第２スキーマ・バージョンＢ’’及び新ソフトウェアＹの両方及びそれらの相互調和の評価を含む。
【０１５５】
新ソフトウェアＹの実施を完了するか否かに関する決定が、評価段階ＸＹ１において得られた結果に基づいて決定段階ＸＹ２においてなされる。
【０１５６】
スキーマ変更Ｘ及びソフトウェアＹは、決定段階ＸＹ２において到達した決定に従って、終結段階Ｘ３、Ｙ２において完了されるか又は終結されるかのどちらかである。
【０１５７】
本発明はまた、好適実施例である実施例を提供し、この実施例ではスキーマ変更が云わゆるＳＡＧＡテーブル内の情報の記憶を含む。
【０１５８】
図９に示したように、ＳＡＧＡテーブルはデータベースＳ１で構成され、このデータベースはスキーマ変更によって影響された分散型データベース内の１つ以上のノード・クラッシングの場合にスキーマ変更を完了する又は打ち切るのを可能とする情報を含む。
【０１５９】
本発明によれば、ＳＡＧＡテーブルＳ１は、スキーマ変更中のハードウェア・クラッシュの場合にスキーマ変更を完了する又はデータベースを第１スキーマ変更バージョンへリセットするのに同じ可能性を与えるように、非分散型データベース内にもまた使用できる。
【０１６０】
ＳＡＧＡテーブルＳ１の目的は、もっと早期に知られている技術に従うＳＡＧＡトランザクションの実施に類似したやり方でスキーマ変更を実施するのを可能とすることである。しかしながら、スキーマ変更と関連した実施は、スキーマ変更がデータ及びスキーマの両方に異なった変更を生じ得る一連のトランザクションを含むと云う事実のせいでいくらか複雑である。
【０１６１】
ＳＡＧＡテーブルＳ１によって含まれた情報は、ＵＮＤＯ情報Ｓ１Ｕ及びＲＥＤＯ情報Ｓ１Ｒの両方で構成され、ＵＮＤＯ情報Ｓ１Ｕは何らかの理由で準備段階１又は走査段階２で及び、ことによると、評価段階４又は決定段階５でスキーマ変更の割り込みの場合に第１スキーマ変更Ａをリセットするために必要とされる情報を含み、及びＲＥＤＯ情報Ｓ１Ｒはもしもスキーマ変更が何らかの理由で終結段階３において割り込まれるならばそのスキーマ変更を完了するために必要な情報を含む。
【０１６２】
スキーマ変更の割り込みは、例えば、第２スキーマ・バージョンの評価がこのバージョンが満足に機能しないことを示していると云う事実のせいでそのスキーマ変更を完了しない決定による、計画された割り込みであることがある。
【０１６３】
割り込み又は停止は、無計画であることがありかつ、例えば、分散型データベース内のスキーマ変更によって影響されるノードのクラッシュ、又は非分散型データべース内の或る型式のハードウェア・クラッシュによって引き起こされることがある。
【０１６４】
もし３つの基本段階１、２、３のみが使用されるならば、準備段階１がＲＥＤＯ情報Ｓ１Ｒの記憶を含むこと、及び走査段階２がＵＮＤＯ情報Ｓ１Ｕの記憶を含むことが本発明によれば提案される。
【０１６５】
他方、もし２中間段階４、５がまた使用されるならば、準備段階１がＲＥＤＯ情報Ｓ１Ｒの記憶を含むこと、及び評価段階５がＵＮＤＯ情報Ｓ１Ｕの記憶を含むことが本発明によれば提案される。
【０１６６】
本発明によれば、ＳＡＧＡテーブルＳ１は、安全複写取り（ｓａｆｔｙ ｃｏｐｙｉｎｇ）と関連してあらゆる２次複写又は全２次データベースの更新にまた使用されることがある。
【０１６７】
本発明がその前述したかつ図示した例証実施例に限定されないこと及び修正を前掲の特許請求の範囲に定義された本発明の概念の範囲内で行えることは、云うまでもない。
【図面の簡単な説明】
【図１】 本発明に従う方法を示す流れ図である。
【図２】 ソフト・スキーマ変更の例に関連した第１スキーマ・バージョン及び第２スキーマ・バージョンの概略説明図である。
【図３】 図２に従うスキーマ変更のパフォーマンスの部分の概略説明図であり、かつ外部テーブルのハンドリングを示す。
【図４】 図２に従うスキーマ変更の可能な結果を示す概略説明図である。
【図５】 ハード・スキーマ変更の例と関連した第１スキーマ・バージョン及び第２スキーマ・バージョンの概略説明図である。
【図６】 図５に従うスキーマ変更のパフォーマンスの部分の概略説明図である。
【図７】 図５に従うスキーマ変更の可能な結果を示す概略説明図である。
【図８】 組み合わせられたスキーマ変更とソフトウェア変更を示す流れ図である。
【図９】 本発明によるＳＡＧＡテーブルの概略説明図である。

Claims (16)

1. スキーマ変更に先立つ第１スキーマ・バージョンが前記スキーマ変更後の第２スキーマ・バージョンと互換性である複雑ソフト・スキーマ変更のような、又はスキーマ変更前の第１スキーマ・バージョンが前記スキーマ変更後の第２スキーマ・バージョンと非互換性である複雑ハード・スキーマ変更のようなスキーマ変更をデータベース内で遂行する方法であって、スキーマ変更手順を以下の３段階、
   ・ 第１段階、準備段階、が前記第１スキーマ・バージョンに従うトランザクションを続行することを可能とする条件を保持する間に前記第２スキーマ・バージョンに従うトランザクションを開始することを可能とする条件を作成することを含み、この第１段階が単純スキーマ変更であり、
   ・ 第２段階、走査段階、が前記第１スキーマ・バージョンに従うデータの前記第２スキーマ・バージョンに従うデータへの転送を含み、
   ・ 第３段階、終結段階、が単純スキーマ変更であるスキーマ変更の完了の際に存在しないことになるトリガ、キー、外部キー及び／又は指標（ indexes ）のようなユニットの除去を含む
   に分割し、
   複雑スキーマ変更が複雑ソフト・スキーマ変更の場合は、前記第１段階における条件の作成は、前記第１スキーマ・バージョンに影響を及ぼすトランザクションを含んで前記第２スキーマ・バージョンが更新され得るような、１つ以上のトリガ、キー、外部キー及び／又は指標の使用、かつ、前記第２スキーマ・バージョンに影響を及ぼすトランザクションを含んで前記第１スキーマ・バージョンが更新され得るような、１つ以上のトリガ、キー、外部キー及び／又は指標の使用を含み、
   前記複雑スキーマ変更が複雑ハード・スキーマ変更の場合は、前記第１段階における条件の作成は、前記第１スキーマ・バージョンに影響を及ぼすトランザクションを含んで前記第２スキーマ・バージョンが更新され得るような、１つ以上のトリガ、キー、外部キー及び／又は指標の使用、又は、前記第２スキーマ・バージョンに影響を及ぼすトランザクションを含んで前記第１スキーマ・バージョンが更新され得るような、１つ以上のトリガ、キー、外部キー及び／又は指標の使用を含むことを特徴とする方法。
2. 請求項１記載の方法において、前記複雑スキーマ変更が複雑ソフト・スキーマ変更であり、たとえ前記第１スキーマ・バージョンに従うトランザクションがまだ進行中であっても、前記第２スキーマ・バージョンに従う通常トランザクションが前記データ転送の完了の際に直ちに開始するのを許されることを特徴とする方法。
3. 請求項１記載の方法において、前記複雑スキーマ変更が複雑ハード・スキーマ変更であり、前記方法であって、前記第２スキーマ・バージョンに従う通常トンランザクションが、前記第１スキーマ・バージョンに従う全てのトランザクションを完了したならば直ちに開始するのを許されることを特徴とする方法。
4. 請求項１記載の方法であって、前記終結段階が、前記第１スキーマ・バージョンに従う全てのトランザクションを完了した後に開始されることを特徴とする方法。
5. 請求項１記載の方法であって、前記複雑スキーマ変更が２つの更に他の段階を含むことと、前記２段階が前記走査段階と前記終結段階との間に位置を定められ、
   ・ 第１中間段階、評価段階、が前記第２スキーマ・バージョンに従う或る種の評価トランザクションを遂行することを含み、それによって前記第２スキーマ・バージョンの機能を評価でき、
   ・ 第２中間段階、決定段階、が前記スキーマ変更を完了するべきか止めるべきかどうか決定し、この決定が前記第３評価段階の結果に基づいている
   こととを特徴とする方法。
6. 請求項５記載の方法において、前記複雑スキーマ変更が複雑ソフト・スキーマ変更であり、前記方法であって、前記評価トランザクションが特別に構成された制御トランザクションであることを特徴とする方法。
7. 請求項５記載の方法において、前記複雑スキーマ変更が複雑ソフト・スキーマ変更であり、評価トランザクションが前記第２スキーマ・バージョンに従う通常トランザクションであることを特徴とする方法。
8. 請求項５記載の方法において、前記複雑スキーマ変更が複雑ソフト・スキーマ変更であり、たとえ前記第１スキーマ・バージョンに従うトランザクションがまだ進行中であっても、前記第２スキーマ・バージョンに従う通常トランザクションが、前記スキーマ変更を完了するように前記決定段階において決定に達するや直ちに開始するのを許されることを特徴とする方法。
9. 請求項５記載の方法において、前記複雑スキーマ変更が複雑ハード・スキーマ変更であり、評価トランザクションが、前記第１スキーマ・バージョンに有害な影響を伴うことなく前記第２スキーマ・バージョンに従って遂行できる特別に構成された制御トランザクションであることを特徴とする方法。
10. 請求項５記載の方法において、前記複雑スキーマ変更が複雑ハード・スキーマ変更であり、前記第２スキーマ・バージョンに従う通常トランザクションが、前記スキーマ変更を完了するように前記評価段階において決定がなされるや直ちに、及び前記第１スキーマ・バージョンに従う全てのトランザクションを完了したならば直ちに開始するのを許されることを特徴とする方法。
11. 請求項５記載の方法であって、前記終結段階が、前記評価段階において到達した決定に従って、及びもし前記決定が前記スキーマ変更を完了することであるならば前記第１スキーマ・バージョンに従う全てのトランザクションを完了した後に、開始されることを特徴とする方法。
12. 請求項１記載の方法であって、前記第２スキーマ変更が実行されるとき、前記終結段階が前記第２スキーマ・バージョンによって使用されないあらゆるトリガ、キー、外部キー、指標及び／又は他のユニットの除去を含むことと、前記スキーマ変更が打ち切られるとき、前記終結段階が前記第１スキーマ・バージョンによって使用されないあらゆるトリガ、キー、外部キー、指標及び／又は他のユニットの除去を含むこととを特徴とする方法。
13. 現在ソフトウェアを新ソフトウェアによって置換されることになる、又はもっと早期の対応するものを有さない新ソフトウェアが前記データベース内で又は前記データベースの利用者によって実施されることになるソフトウェア変更と関連した、請求項５記載の方法であって、前記スキーマ変更が前記ソフトウェア変更と同期させられることと、前記新ソフトウェアによって発生されるトランザクションが前記評価トランザクションを構成することと、前記評価段階における評価が前記第２スキーマ・バージョンの評価と、前記新ソフトウェアの評価と、それらの相互調和の評価とを含むことと、前記新ソフトウェアを実施するべきかどうか及び前記スキーマ変更を実行するべきかどうかに関する決定が前記評価段階から得られた結果に基づいてなされることを特徴とする方法。
14. 請求項１又は５記載の方法であって、前記スキーマ変更がＳＡＧＡテーブル内の情報の記憶を含むことと、前記情報がＵＮＤＯ情報とＲＥＤＯ情報との両方を含み、前記ＵＮＤＯ情報はスキーマ変更が何らかの理由で前記準備段階又は前記走査段階において及び、ことによると、評価段階又は決定段階において割り込みされる又は打ち切られる場合に前記第１スキーマ・バージョンをリセットするために必要とされる情報を含み、かつ前記ＲＥＤＯ情報は前記スキーマ変更が何らかの理由で前記終結段階において割り込まれる又は打ち切られる場合に前記スキーマ変更を完了するために必要とされる情報を含むこととを特徴とする方法。
15. 請求項１及び１４記載の方法であって、前記準備段階が前記ＵＮＤＯ情報の記憶を含むことと、前記走査段階が前記ＲＥＤＯ情報の記憶を含むこととを特徴とする方法。
16. 請求項５及び１４記載の方法であって、前記準備段階が前記ＵＮＤＯ情報の記憶を含むことと、前記評価段階が前記ＲＥＤＯ情報の記憶を含むこととを特徴とする方法。

Images