JP4179557B2 - レガシー・アプリケーション移行を実施するシステム、方法およびコンピュータ・プログラム - Google Patents

Description

本発明は、一般にはレガシー・コンピューティング・アプリケーションの移行に関し、より詳細には、レガシー・コンピューティング・アプリケーションからの移行後に、データにアクセスし、データを表示するシステム、方法およびコンピュータ・プログラムに関する。

新しいアプリケーション・サーバ・プラットフォームは、潜在的に効率および機能を改善する。その結果、レガシー・アプリケーションがしばしば、最先端技術のプラットフォームに移行される。具体的には、Ｊａｖａ（商標）２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）に準拠するアプリケーション・サーバ・プラットフォームがますます普及している。その結果、他のアプリケーション・サーバ・プラットフォームに準拠する、表示ページを定義し、データベースにアクセスするアプリケーションが、多くの場合Ｊ２ＥＥ準拠のアプリケーション・サーバ・プラットフォームに移行される。

往々にして、このレガシー・アプリケーションからの移行が行われるとき、レガシー・データベース・スキーマに変更が行われる。企業は、新しいプラットフォームへの移行を、既存のレガシー・データベース・スキーマを再定義し、拡張する機会ととらえる。このデータベース・スキーマの再定義により、新しいプラットフォーム上のアプリケーションが、その企業のシステムの移行先の新しいアプリケーション環境で使用可能な新しい機能を利用することが可能となる。このようなデータベース・スキーマの再構成を行うと、レガシー・アプリケーションで提供される機能を新しいアプリケーションで維持するよう保証するためにアプリケーションに変更がある場合、移行コストが高くなる。

このような変更コストは、レガシー・アプリケーションが定義済みのスキーマを用いてリレーショナル・データベースにアクセスし、かつ定義済みのスキーマが新しいアプリケーション用に変更される場合に潜在的に高い。リレーショナル・データベースでのアクセスがウェブ・ベースの表示ページで行われるアプリケーションでは、アクセスは通常、リレーショナル・クエリ（例えばＳＱＬのＳＥＬＥＣＴステートメント）によって行われる。ウェブ・ベースのシステムでの表示ページの状況では、更新リレーショナル・オペレータ（例えば、ＵＰＤＡＴＥ、ＩＮＳＥＲＴ、ＤＥＬＥＴＥステートメント）は比較的少ない。一般的なＭＶＣ（Ｍｏｄｅｌ Ｖｉｅｗ Ｃｏｎｔｒｏｌｌｅｒ）デザイン・パターンに対して表示ページが定義される場合、表示ページは、更新リレーショナル・オペレータを含まないように意図される。表示ページ中のそのような機能は、モデル、ビュー、およびコントローラの分離と一致しないからである。存在する場合であっても、そのような更新は通常、比較的移行が容易である。一方、リレーショナル・データベース・クエリは、複雑かつ込み入った仕方で定義され、新しいスキーマ用にこのようなクエリを再定義することは潜在的にかなりの作業である。新しいスキーマ用にレガシー・リレーショナル・データベース・クエリを書き換える際に助けとなるツールを構築するための努力が払われているが、そのようなレガシー・リレーショナル・データベース・クエリの複雑さと潜在的差異により、そのようなクエリを書き換えるためのツールを定義し、使用することが、複雑かつ困難となる。

上記で参照したように、ウェブ・ベースのシステムでのレガシー・アプリケーションは、定義済みのウェブ・ベースの表示ページを含む可能性がある。しばしば、レガシー表示ページは、Ｊ２ＥＥで使用されるＪＳＰ（Ｊａｖａ（商標）Ｓｅｒｖｅｒ Ｐａｇｅ）定義と一致しない仕方で定義される。そのような表示ページをＪ２ＥＥアプリケーション・サーバ・プラットフォームに準拠するように書き換えることも、潜在的に複雑かつ費用のかかる作業である。

したがって、レガシー・アプリケーション中のデータベース・スキーマ用に定義されたリレーショナル・クエリを、新しいデータベース・スキーマへの移行後に使用することを可能にし、レガシー・アプリケーション中で定義された表示ページを書き換えることなく、Ｊ２ＥＥアプリケーション・サーバ・プラットフォームで実装されるシステムで使用する方法およびシステムを提供することが望ましい。

したがって、本発明は、レガシー・プラットフォームから新しいプラットフォームへの移行後に、レガシー・リレーショナル・クエリおよびレガシー表示ページの使用を改善するシステムおよび方法を提供する。

本発明の別の態様によれば、レガシー・アプリケーションを新しいアプリケーションに移行する際に使用する方法において、レガシー・アプリケーションが、レガシー・スキーマを有するレガシー・リレーショナル・データベースにアクセスするように定義され、新しいアプリケーションが、新しいスキーマを有する移行後リレーショナル・データベースにアクセスするように定義される方法であって、
レガシー・スキーマの新しいスキーマへの移行を表す１組の移行スキーマ変更を求めるステップと、
スキーマ変更に関する事前定義された１組のリレーショナル・データベース・ビューを参照し、その１組の移行スキーマ変更に対応する事前定義された組中のビューを識別することにより、移行後リレーショナル・データベースに関する１つまたは複数のリレーショナル・データベース・ビューを生成するステップとを含み、
１つまたは複数のリレーショナル・データベース・ビューが、新しいスキーマをレガシー・スキーマにマッピングするように生成され、それによって本来はレガシー・データベース用に定義されたデータベース・クエリを、移行後リレーショナル・データベースに対して実行することが可能となる方法が提供される。

本発明の別の態様によれば、事前定義された１組のリレーショナル・データベース・ビューが、列方向分割（column-wise split）、行方向分割、列方向マージ、行方向マージ、列名変更、列タイプ変更、ヌル可能−ヌル不能移行（nullableto not-nullable transition）、値マップ、列分割、列マージの集合から選択されたスキーマ変更に関するビューを含む上記の方法が提供される。

本発明の別の態様によれば、１組の移行スキーマ変更を求めるステップが、移行スキーマ変更の表現を定義するステップを含む上記の方法が提供される。

本発明の別の態様によれば、移行後リレーショナル・データベースに関する１つまたは複数のリレーショナル・データベース・ビューを生成するステップが、移行スキーマ変更の表現を入力として受諾するステップと、その表現に基づいて１つまたは複数のリレーショナル・データベース・ビューを生成するステップとをさらに含む上記の方法が提供される。

本発明の別の態様によれば、移行スキーマ変更の表現がＸＭＬファイルである上記の方法が提供される。

本発明の別の態様によれば、記録可能データ記憶媒体や被変調搬送波信号（インターネットを含むネットワークの伝送）などのコンピュータ可読信号運搬媒体を含むコンピュータ・プログラム製品であって、媒体が、上記方法のいずれか１つを実施する手段を含むコンピュータ・プログラム製品が提供される。

本発明の別の態様によれば、レガシー・アプリケーションを新しいアプリケーションに移行する際に使用するコンピュータ・プログラム製品において、レガシー・アプリケーションが、レガシー・スキーマを有するレガシー・リレーショナル・データベースにアクセスし、新しいアプリケーションが、新しいスキーマを有する移行後リレーショナル・データベースにアクセスし、２つのスキーマ間の関係が、定義データ表現（ＸＭＬファイルなど）内に定義されるコンピュータ・プログラム製品であって、媒体中に実施されたコンピュータ可読プログラム・コード手段を有するコンピュータ使用可能媒体を含み、定義データ表現を入力として取り、スキーマ変更に関する事前定義された１組のリレーショナル・データベース・ビューを使用し、新しいスキーマに関する１つまたは複数のビューを生成し、それによってレガシー・アプリケーション内で定義されたリレーショナル・クエリが新しいスキーマの１つまたは複数のビューに対して実行可能となるコンピュータ可読プログラム・コード手段を含むコンピュータ・プログラム製品が提供される。

本発明の別の態様によれば、新しいアプリケーションがＪ２ＥＥプラットフォーム上で実行するように定義される前述のコンピュータ・プログラム製品が提供される。

本発明の別の態様によれば、レガシー・アプリケーションを新しいアプリケーションに移行する際に使用するコンピュータ・プログラム製品において、レガシー・アプリケーションが、レガシー・ビュー・エンジンを使用して表示可能なレガシー表示ページを含み、レガシー・アプリケーションが、レガシー・スキーマを有するレガシー・リレーショナル・データベースにアクセスし、新しいアプリケーションが、新しいスキーマを有する移行後リレーショナル・データベースにアクセスし、２つのスキーマ間の関係が、定義データ表現内に定義されるコンピュータ・プログラム製品であって、媒体中に実施されたコンピュータ可読プログラム・コード手段を有するコンピュータ使用可能媒体を含み、定義データ表現を入力として取り、スキーマ変更に関する事前定義された１組のリレーショナル・データベース・ビューを使用し、新しいスキーマに関する１つまたは複数のビューを生成し、それによってレガシー・アプリケーション内で定義されたリレーショナル・クエリが新しいスキーマの１つまたは複数のビューに対して実行可能となるコンピュータ可読プログラム・コード手段と、ユーザに表示する定義済みビューに関係する表示要求を受諾し、したがってビュー・エンジン・レジストリにアクセスするビュー・エンジン・マネージャを実装するコンピュータ可読プログラム・コード手段と、ユーザに表示する定義済みビュー、表示ページ、およびビュー・エンジンの間のアソシエーションを格納し、アソシエーションに関する情報を、要求時にビュー・エンジン・マネージャに提供するビュー・レジストリを実装するコンピュータ可読プログラム・コード手段と、選択されたビューについてビュー・エンジンに関するパラメータを生成するレガシー・ビュー・エンジン・アダプタを実装するコンピュータ可読プログラム・コード手段とを含み、それによってレガシー表示ページを新しいアプリケーションによって参照することができ、レガシー表示ページが表示可能なレガシー・ビュー・エンジンを使用して要求時に表示することができるコンピュータ・プログラム製品が提供される。

本発明の別の態様によれば、レガシー・アプリケーションを新しいアプリケーションに移行する際に使用する方法において、レガシー・アプリケーションが、レガシー・ビュー・エンジンを使用して表示可能なレガシー表示ページを含む方法であって、ビュー・エンジン・マネージャ、ビュー・レジストリ、およびレガシー・ビュー・エンジン・アダプタを含むコンピュータ・システム上で実施され、
ユーザに表示する定義済みビュー、表示ページ、およびビュー・エンジン・レジストリ中のビュー・エンジンの間のアソシエーションを格納するステップと、
ビュー・エンジン・マネージャを使用して、ユーザに表示する定義済みビューに関係する表示要求を受諾するステップと、
ビュー・エンジン・マネージャによって受領される要求に基づいてビュー・エンジン・レジストリにアクセスするステップと、
上記のアクセスするステップで要求されたビュー・レジストリから、アソシエーションに関する情報を、要求時にビュー・エンジン・マネージャに提供するステップと、
ビュー・エンジン・アダプタを使用して、選択されたビューについてビュー・エンジンに関するパラメータを生成し、それによってレガシー表示ページを新しいアプリケーションによって参照することができ、レガシー表示ページが表示可能なレガシー・ビュー・エンジンを使用して要求時に表示することができるステップとを含む方法が提供される。

本発明の別の態様によれば、上記の方法を実施する手段を含むコンピュータ可読信号運搬媒体を含むコンピュータ・プログラム製品が提供される。

したがって本発明により、レガシー・アプリケーション用に定義されたリレーショナル・データベース・クエリを、新しく定義されたアプリケーションで、新しいスキーマを有する移行後データベースに対して実行することが可能となり、レガシー・表示エンジンにアクセスすることにより、レガシー・アプリケーション内で定義された表示ページに、新しいプラットフォーム上で動作する新しいアプリケーションによってアクセスし、それを表示することが可能となる。

図面は、本発明の好ましい実施形態を例示によって示すに過ぎない。

以下でより詳細に説明するように、好ましい実施形態の一定の諸構成要素を図１の例示的ブロック図に示す。

好ましい実施形態を説明する際に使用する実施例は、エンタープライズ・アプリケーションの設計においてしばしば好ましいＭｏｄｅｌ−Ｖｉｅｗ−Ｃｏｎｔｒｏｌｌｅｒデザイン・パターンに従う。この設計手法によれば、当業者には周知のように、トランザクションは通常、コントローラへの要求で開始する。ＭＶＣデザイン・パターンに従うウェブ・ベースのアプリケーションは通常、要求に対する応答として、ウェブ・ベースの表示ページ（ビュー）の決定を含む。Ｊ２ＥＥ（Ｊａｖａ（商標）２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）環境では、（ユーザへの情報の表示に関する）アプリケーションのビュー・コンポーネントは、ＪＳＰを使用して定義されるウェブ・ページである。要求の受領と表示ページの決定との間に実施されるオペレーションは、コントローラの制御下にある。好ましい実施形態は、ＭＶＣ設計原理に準拠せずに実装できることを当業者は理解されよう。

図１の例は、レガシー・ウェブ・ベース・アプリケーションをＪ２ＥＥ環境に移行することに関するものである。レガシー・アプリケーションは、データベース・スキーマ１２を有するレガシー・データベース１０へのアクセスを含む。図１には、移行後アプリケーションと共に使用する、関連するスキーマ１６を有する移行後データベース１４も示す。レガシー・データベース１０を移行後データベース１４で置き換えることができ、２つのデータベースが同時に存在する必要はないことを当業者は理解されよう。好ましい実施形態は、データベースを新しいスキーマに従って再定義した場合の、レガシー・アプリケーションから新しいアプリケーションへの移行を扱う。

図１の例は、レガシー・リレーショナル・データベース１０の、新しいリレーショナル・データベース１４への移行に関するものである。スキーマ１６は、修正後のスキーマ１２、またはスキーマ１２の代替であり、レガシー・システムの移行先の新しいアプリケーション・サーバ・プラットフォームを利用するために更新される。（スキーマ１２中に定義される）レガシー・データベース１０中のデータの編成は、（スキーマ１６に従って）移行後データベース１４で修正される。

好ましい実施形態では、スキーマ１２とスキーマ１６との間の関係をＸＭＬファイル１８中に定義することができる。スキーマ１２およびスキーマ１６を含むこのＸＭＬファイルは、データベース管理者によって生成され、２つのスキーマ間の関係を反映する。ＸＭＬファイル１８中の情報は、レガシー・データベース１０のリレーショナル・データベース・テーブル定義が移行後データベース１４でどのように修正されたかを定義する。ＸＭＬファイル以外の代替定義データ表現もスキーマ変更を表現するのに使用できることを理解されたい。

リレーショナル・テーブルｔｓｏｕｒｃｅおよび２つのリレーショナル・テーブルｔｔａｒｇｅｔ１、ｔｔａｒｇｅｔ２の間の関係を定義するＸＭＬコードの単純な例を以下に与える。図２に略図で示す例では、レガシー・データベース・スキーマ・テーブルｔｓｏｕｒｃｅが、列ｉｄ、ｃ１、ｃ２を有する。新しい移行後データベース・スキーマで定義された２つのテーブルｔｔａｒｇｅｔ１、ｔｔａｒｇｅｔ２は、それぞれ列ｉｄ、ｃ１、およびｉｄ、ｃ２を含む。
<Source table="tsource">
<KeyColumn name="id">
<Target table="ttarget1"column="id" />
<Target table="ttarget2"column="id" />
</KeyColumn>
<Column name="c1">
<Target table="ttarget1"column="c1" />
</Column>
<Column name="c2">
<Target table="ttarget2"column="c2" />
</Column>
</Source>

上記の例で示すように、好ましい実施形態では、ＸＭＬファイル１８が、スキーマ１２と１６の間の関係の正式な表現を含む。以下でより詳細に説明するように、好ましい実施形態は、移行後データベース１４に対してレガシー・クエリを実行することが可能となるように、データベース１４に関する１つまたは複数のビューを定義する。好ましい実施形態では、ビュー生成ツールをプロセスの一部として使用して、このビューの組を定義する。ビュー生成ツール２０は、スキーマ１２からの修正を反映し、スキーマ１６を生成するＸＭＬファイル１８コンテンツを入力として取る。図１の例では、ビュー生成ツール２０の出力は、１組のビュー２２である。

１組のビュー２２は、ビューに関するＳＱＬ規格に従って定義される。その組内のビューの定義は、レガシー・アプリケーションでスキーマ１２を参照して当初定義されたクエリが、ビュー２２で表されるように移行後データベース１４に関連して移行後アプリケーションで使用可能となるように実施される（以下でより詳細に説明する）。その結果、スキーマ１２に従って以前にはレガシー・データベース１０中に位置していたデータが、そのスキーマに従って定義されたクエリによってアクセス可能となるが、そうしたデータは、移行後データベース１４中に位置する。実質上、ビュー２２は、レガシー・クエリが移行後データベース１４に対して実行されるときに、そうしたビューを使用して、スキーマ１６がレガシー・クエリにとって透過的となるように定義される。１組のビュー２２は、新しいスキーマ１６をレガシー・スキーマ１２にマッピングする。

図１の例では、レガシー表示ページ２４がデータベース・クエリ２６を含む。データベース・クエリ２６は、レガシー・データベース１０に関するスキーマ１２に対して定義される。好ましい実施形態によれば、１組のビュー２２は、ビュー２２を含む移行後データベース１４に対してデータベース・クエリ２６が実行可能となるように生成される。

このようにして、好ましい実施形態のシステムおよび方法により、レガシー・システムに対して定義されたデータベース・クエリを、スキーマが元のレガシー・スキーマからの変化を含む修正後データベースに対して実行することが可能となる。好ましい実施形態は、新しいスキーマをレガシー・スキーマにマッピングする１組のビュー２２を提供する。好ましい実施形態を、表示ページからのリレーショナル・データベース・アクセスを参照しながら説明するが、本発明のこの態様に従って、他のリレーショナル・データベース・アクセスも実施することができる。

理解するであろうが、ビュー２２は、ビュー生成ツール２０によって自動的に生成することができ、またはデータベース管理者が手動で定義することもできる。どちらの手法も、スキーマ１２と新しいスキーマ１６の比較に依拠する。この比較情報は、スキーマ１６を定義するためにスキーマ１２に行った修正を参照することによって得ることができる。このようなビュー生成ツールの作成は、以下で参照するテーブル・レベルの変更および列レベルの変更に関するビューを使用して当業者によって実施されることになる。このようなビュー生成ツールは、好ましい実施形態にとって必要ではない。

図１に示す好ましい実施形態の別の態様は、レガシー・システムに対して定義される表示ページに関するものである。この説明では、ウェブ・ページの表示または閲覧あるいはその両方のための旧型の独自技術を示すＡｌｅｇａｃｙ ｓｙｓｔｅｍ＠の用語を使用するが、あるアプリケーションから別のアプリケーションに適切な移行を行う場合に好ましい実施形態を使用できることを理解されよう。ある場合には、こうした旧型の独自技術から、表示ページが例えばＪＳＰで定義されるアプリケーションにウェブ・ページを移行することは、アプリケーションを、Ｊ２ＥＥなどの新しいプラットフォームに移行する際の障害となる可能性がある。多くの場合、レガシー・アプリケーションから新しいアプリケーションに移行した後に、ウェブ・ページのルック・アンド・フィールを同一に維持することが望ましい。既存のウェブ・サイトを定義し、またはその一部となるウェブ・ページは通常は貴重であり、ウェブ・ページを一貫して定義するように維持することが望ましい。レガシー・アプリケーションでのウェブ・ページの機能を反映するようにウェブ・ページをＪＳＰで書き換えることは、レガシー・アプリケーションを新しいアプリケーションに移行する際の潜在的に高価な要件である。

図１に反映される好ましい実施例では、新しいＪ２ＥＥアプリケーション・プラットフォーム３０が示されている。Ｊ２ＥＥアプリケーション・プラットフォーム３０によってサポートされる、レガシー表示ページの使用に関する好ましい実施形態の諸構成要素が示されている。Ｊ２ＥＥを参照しながら好ましい実施形態を説明するが、好ましい実施形態は他のアプリケーション・プラットフォームにも適用できることを当業者は理解されよう。

したがって、好ましい実施形態によれば、アプリケーション・プラットフォーム３０に関連してビュー・エンジン・マネージャ３２が定義される（ここで参照するＡｖｉｅｗ＠はユーザへの表示に関するものであり、この説明の別の箇所で参照するリレーショナル・データベース・ビューではないことに留意されたい）。ビュー・エンジン・マネージャ３２は、ビュー・レジストリ３４にアクセスすることができる。アプリケーションは、従来の技術と同様に、情報を定義済みビューに関連して表示するよう要求することができる。アプリケーションは、情報を表示する表示ページの詳細を指定する必要はないが、定義済みビューを単に指定することができる。ビュー・レジストリ３４は、ビューと関連する表示ページとの間のアソシエーションを格納する。さらに、好ましい実施形態では、ビュー・レジストリ３４は、ビュー、表示ページ、およびビュー・エンジンの間のアソシエーションを格納する。好ましい実施形態では、サポートされる各ビュー・エンジン（ネイティブＪ２ＥＥビュー・エンジンを除く）は、ビュー・エンジン・アダプタ（図１の例ではレガシー・ビュー・エンジン・アダプタ３６として示す）を備える。

好ましい実施形態では、ビュー・レジストリ３４中のエントリに基づいて適切なビュー・エンジン・アダプタ（図１の例では、レガシー・ビュー・エンジン・アダプタ３６）を起動するビュー・エンジン・マネージャ３２が定義される。ビュー・エンジン・アダプタは、特定のビュー・エンジンの必要に応じてパラメータを整理し、次いで、ビュー・レジストリで指定された適切なビュー文書を用いてビュー・エンジンを起動する。ビュー・エンジンは、その要求への応答としてビューを送達する。

この構成は、アプリケーション・プラットフォームが、レガシー・ビュー・エンジンを含まない１つまたは複数のビュー・エンジンを使用するよう指定される場合に使用される。例えば、Ｊ２ＥＥは、ＪＳＰに対するビュー・エンジンのみをサポートする。ＪＳＰで定義されていないレガシー表示ページは、Ｊ２ＥＥプラットフォームから直接には表示することができない。好ましい実施形態の手法により、このようなレガシー表示ページを、ＪＳＰで書き換えることなく表示することが可能となる。

図１の例は、レガシー・ビュー・エンジン・アダプタ３６を示す。このアダプタは、（Ｊ２ＥＥ環境とは異なる技術環境で実装された）レガシー・ビュー・エンジンを起動することを可能にするブリッジとして使用される。レガシー・ビュー・エンジン・アダプタ３６はまた、転送されたデータを整理して、レガシー・ビュー・エンジンの動作が正しくなるよう保証する。図１の例では、レガシー・ビュー・エンジン３８を立ち上げるレガシー・ビュー・エンジン・アダプタ３６を示す。レガシー・ビュー・エンジン３８は、レガシー表示ページ２４を実行することができる（通常は、ページ２４は当初、レガシー・ビュー・エンジン３８による表示のために定義されたものである）。このようにして、レガシー・アプリケーションに関する、以前に定義した表示ページが、新しいＪ２ＥＥアプリケーション・プラットフォーム３０のアプリケーションに関連して使用される。表示ページを、新しいＪ２ＥＥアプリケーション・プラットフォーム３０上で動作する新しいアプリケーションに移行することは、必要に応じて、または利用可能な資源に従って、表示ページに関する新しいＪＳＰ定義を書き込むことが可能となるように時差式に（in a staggered manner）実施することができる。

関連するビュー・エンジン・マネージャ、レジストリ、およびアダプタと共にビュー・エンジンを使用することは、データベース・スキーマに対する変更を含まない移行にも適用できることは当業者には明らかであろう。このような移行では、レガシー表示ページを保持することが有利であることがある。ビュー・エンジン・マネージャ、ビュー・レジストリ、およびビュー・エンジン・アダプタを組み込むシステムは、レガシー表示ページと新しく定義した表示ページとをシームレスに利用できるようにする。

次に図１に戻ると、新しいデータベース・スキーマを有するデータベースに対してレガシー・クエリ定義を実行することが可能となるように１つまたは複数のビューを生成することができる。好ましい実施形態によれば、新しいスキーマに関する１つまたは複数のビューが、１組の可能なスキーマ変更を反映する事前定義された１組のビューを使用して生成される。これらは、テーブル・レベルの変更または列レベルの変更でよい。テーブル・レベルのスキーマ変更は、列方向分割、行方向分割、列方向マージ、行方向マージを含む。列レベルの変更は、列名変更、列タイプ変更、ヌル可能−ヌル不能移行、値マップ、列分割、列マージを含む。好ましい実施形態による１組のビュー定義の詳細を以下で説明する。

列方向分割であるスキーマ変更を、図２の略図表現に示す。列ｉｄ、ｃ１、ｃ２を有するテーブルｔｓｏｕｒｃｅが示されている。スキーマ変更の結果、ｔｔａｒｇｅｔ１（列ｉｄおよびｃ１を有する）およびｔｔａｒｇｅｔ２（列ｉｄおよびｃ２を有する）の２つのテーブルが得られる。ソース・テーブル中の各列が、複数のターゲット・テーブル内の各列に分割される。このようなスキーマ変更の一例は、当初他の従業員情報と共に単一テーブル中にあった従業員の住所データを、従業員テーブルとは別々のテーブルに分割する場合である。

新しいアプリケーションでテーブルｔｓｏｕｒｃｅをエミュレートすべき（テーブルｔｔａｒｇｅｔ１およびｔｔａｒｇｅｔ２に関して定義された）データベース・ビューは、以下のように定義される。
create view tsource (id, c1, c2) as
select ttarget1.id, ttarget1.c1,ttarget2.c2
from ttarget1, ttarget2
where ttarget1.id = ttarget2.id

新しいデータベース・スキーマに対してビューｔｓｏｕｒｃｅを定義した結果は、レガシー・アプリケーションでテーブルｔｓｏｕｒｃｅに対して以前に定義したクエリを、新しいスキーマを有する新しいアプリケーション・データベース内のビューｔｓｏｕｒｃｅを参照して実行できることである。当業者には明らかであろうが、上記で与えた例示的ビューは一般化されており、他の可能な列方向分割と共に使用するように修正することができる。

行方向分割であるスキーマ変更を、図３の略図表現に示す。列ｉｄ、ｃ１、ｃ２およびステータス（値ＰｅｎｄｉｎｇおよびＣｏｍｐｌｅｔｅを有する）を有するテーブルｔｓｏｕｒｃｅが示されている。スキーマ変更の結果、ｔｔａｒｇｅｔ１（列ｉｄ、ｃ１、ｃ２を有する）およびｔｔａｒｇｅｔ２（列ｉｄ、ｃ１、ｃ２を有する）の２つのテーブルが得られる。ソース・テーブルｔｓｏｕｒｃｅ中の行は、判別列（discriminator column）に基づいて、複数のターゲット・テーブル中の行に分割される。図３の例では、ステータス列が判別列であり、新しいスキーマへの移行は、受注テーブル・データ（ｔｓｏｕｒｃｅ）を受注保留テーブル（ｔｔａｒｇｅｔ１）と受注完了テーブル（ｔｔａｒｇｅｔ２）に分割することを反映する。このことは、行１００１（ステータスがＰｅｎｄｉｎｇ）が、行方向分割を反映するスキーマを有する新しいデータベース中のｔｔａｒｇｅｔ１に追加される図３の例から見ることができる。

テーブルｔｓｏｕｒｃｅをエミュレートすべきである（テーブルｔｔａｒｇｅｔ１およびｔｔａｒｇｅｔ２に対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource (id, c1, c2, status)as
select ttarget1.id, ttarget1.c1,ttarget1.c2, 'P'
from ttarget1
union
select ttarget2.id, ttarget2.c1,ttarget12c2, 'C'
from ttarget2

この説明で述べたビューのすべてがそうであるのと同様に、上記のビューは、同一のタイプ（この場合は行方向分割）の他の特定のスキーマ変更に適合させることができる。

列方向マージであるスキーマ変更を図４の略図表現で示す。列ｉｄおよびｃ１を有するテーブルｔｓｏｕｒｃｅ１と、列ｉｄおよびｃ２を有するテーブルｔｓｏｕｒｃｅ２が示されている。スキーマ変更の結果、単一のテーブルｔｔａｒｇｅｔ（列ｉｄ、ｃ１、ｃ２を有する）が得られる。複数のソース・テーブル中の列が、単一のターゲット・テーブル中の列にマージされる。このようなスキーマ変更の一例は、従業員記録テーブルと従業員給与テーブルを単一の従業員情報テーブルにマージすることである。

図４のテーブルｔｓｏｕｒｃｅ１およびｔｓｏｕｒｃｅ２をエミュレートすべき（テーブルｔｔａｒｇｅｔに対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource1 (id, c1) as
select ttarget.id, ttarget.c1
from ttarget

create view tsource2 (id, c2) as
select ttarget.id, ttarget.c2
from ttarget

行方向マージであるスキーマ変更を図５の略図表現に示す。列ｉｄ、ｃ１、およびｃ２を有するテーブルｔｓｏｕｒｃｅ１と、列ｉｄ、ｃ１、およびｃ２を有するテーブルｔｓｏｕｒｃｅ２が示されている。スキーマ変更の結果、単一のテーブルｔｔａｒｇｅｔ（列ｉｄ、ｃ１、ｃ２、およびステータスを有する）が得られる。このとき複数のソース・テーブル中の列が、単一のターゲット・テーブルにマージされ、判別列が追加される。一例は、受注保留テーブルおよび受注完了テーブルを単一の受注テーブルにマージすることである。

図５のテーブルｔｓｏｕｒｃｅ１およびｔｓｏｕｒｃｅ２をエミュレートすべきである（テーブルｔｔａｒｇｅｔに対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource1 (id, c1, c2) as
select ttarget.id, ttarget.c1, ttarget.c2
from ttarget
where ttarget.status = 'P'

create view tsource2(id, c1, c2) as
select ttarget.id, ttarget.c1, ttarget.c2
from ttarget
where ttarget.status = 'C'

好ましい実施形態では、データベース・スキーマ中の列レベルの変更に対して以下のビュー定義が生成される。

列名変更であるスキーマ変更を図６の略図表現に示す。列ｉｄ、ｃ１、およびｃｘを有するテーブルｔｓｏｕｒｃｅが示されている。スキーマ変更の結果、単一のテーブルｔｔａｒｇｅｔ（列ｉｄ、ｃ１、ｃｙを有する）が得られる。列名は、列の意味をより適切に反映するように変更される。一例として、ＬＮＡＭＥがＬＡＳＴＮＡＭＥに変更される。

図６のテーブルｔｓｏｕｒｃｅをエミュレートすべきである（テーブルｔｔａｒｇｅｔに対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource (id, c1, cx) as
select ttarget.id, ttarget.c1, ttarget.cy
from ttarget

列タイプ変更であるスキーマ変更を図７の略図表現に示す。列ｉｄ、ｃ１、およびｃ２を有するテーブルｔｓｏｕｒｃｅが示されている。ｃ２は整数型である。スキーマ変更の結果、単一のテーブルｔｔａｒｇｅｔ（列ｉｄ、ｃ１、ｃ２を有する。ただしｃ２はｃｈａｒ型）が得られる。このスキーマ変更では、適切な使用法を反映するように列タイプが変更される。

図７のテーブルｔｓｏｕｒｃｅをエミュレートすべきである（テーブルｔｔａｒｇｅｔに対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource (id, c1, c2) as
select ttarget.id, ttarget.c1,int(ttarget.c2)
from ttarget

ヌル可能列がヌル不能となる変更であるスキーマ変更を図８の略図表現に示す。列ｉｄ、ｃ１、およびヌル可能であるｃ２を有するテーブルｔｓｏｕｒｃｅが示されている。スキーマ変更の結果、単一のテーブルｔｔａｒｇｅｔ（列ｉｄ、ｃ１、ｃ２を有する。ただしｃ２はヌル不能であり、デフォルト値０を有する）が得られる。ヌル可能列が、デフォルト値を有するヌル不能に変更される。一例は、ヌル可能となるべきでない列に対して正しい値表現を与えるようにスキーマがこのように変更される場合である。

図８のテーブルｔｓｏｕｒｃｅをエミュレートすべきである（テーブルｔｔａｒｇｅｔに対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource (id, c1, c2) as
select ttarget.id, ttarget.c1, casettarget.c2
when 0 then null else ttarget.c2 end
from ttarget

値マップ変更であるスキーマ変更を図９の略図表現に示す。列ｉｄ、ｃ１、およびｃ２を有するテーブルｔｓｏｕｒｃｅが示されている。スキーマ変更の結果、単一のテーブルｔｔａｒｇｅｔ（列ｉｄ、ｃ１、ｃ２を有する）が得られる。列ｃ２中の値は、新しいデータベース・スキーマでは、マッピングに基づいて別の値に変更される。図９の例では、テーブルｔｓｏｕｒｃｅ中の受注状況列ｃ２は値０、１、２を有する。ただし０は保留を表し、１は完了を表し、２は削除済みを表す。新しいデータベース・スキーマでは、列ｃ２中の値が、保留、完了、削除済みをそれぞれ表す、より意味のある値Ｐ、Ｃ、Ｄに変更される。

図９のテーブルｔｓｏｕｒｃｅをエミュレートすべきである（テーブルｔｔａｒｇｅｔに対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource (id, c1, c2) as
select ttarget.id, ttarget.c1, casettarget.c2
when 'P' then '0' when 'C' then '1' when'D'
then '2' end
from ttarget

列分割変更であるスキーマ変更を図１０の略図表現に示す。列ｉｄ、ｃ１、およびｃ２を有するテーブルｔｓｏｕｒｃｅが示されている。スキーマ変更の結果、単一のテーブルｔｔａｒｇｅｔ（列ｉｄ、ｃ２１、ｃ２２を有する）が得られる。図１０の例では、文字１〜２をｔｓｏｕｒｃｅ．ｃ２からｔｔａｒｇｅｔ．ｃ２１に移動し、文字３〜４をｔｔａｒｇｅｔ．ｃ２２に移動することによってｔｓｏｕｒｃｅ．ｃ２中のデータの分割が達成される。図示するように、このときソース・テーブルの列が、ターゲット・テーブル中の複数の列に分割される。一例は、日付列（ｄｄｍｍ）を日（ｄｄ）、月（ｍｍ）を表す２つの列に分離することである。

図１０のテーブルｔｓｏｕｒｃｅをエミュレートすべきである（テーブルｔｔａｒｇｅｔに対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource (id, c1, c2) as
select ttarget.id, ttarget.c1,concat(ttarget.c21,
ttarget.c22)
from ttarget

列マージ変更であるスキーマ変更を図１１の略図表現に示す。列ｉｄ、ｃ１、ｃ２１、およびｃ２２を有するテーブルｔｓｏｕｒｃｅが示されている。スキーマ変更の結果、単一のテーブルｔｔａｒｇｅｔ（列ｉｄ、ｃ１、ｃ２を有する）が得られる。ソース・テーブル中の複数の列が、そのときターゲット・テーブル中の単一の列にマージされる。一例は、日（ｄｄ）列および月（ｍｍ）列を単一の日付（ｄｄｍｍ）列にマージすることである。図１１では、ｔｔａｒｇｅｔ．ｃ２は、ｔｓｏｕｒｃｅ．ｃ２１およびｔｓｏｕｒｃｅ．ｃ２２に関してそれぞれ示した長さｍおよびｎの文字データの連結である値を有する。

図１１のテーブルｔｓｏｕｒｃｅをエミュレートすべきである（テーブルｔｔａｒｇｅｔに対して定義された）好ましい実施形態におけるデータベース・ビューは、以下のように定義される。
create view tsource (id, c1, c21, c22) as
select ttarget.id, ttarget.c1,substr(ttarget.c2,
1, m), substr(ttarget.c2, m+1, n)
from ttarget

理解するであろうが、テーブル・スキーマ変更は、テーブル・レベルの変更と、任意の数の列レベルの変更との組合せでよい。以下は、テーブル・レベルの列方向分割と、いくつかの異なる列レベルの変更との組合せに対して生成することができるデータベース・ビューの一例である。
create view tsource (id, c1, c2, c3, c4,c5) as
select ttarget1.id,
int(ttarget1.c1x),
case ttarget2.c2 when 0 then null elsettarget.c2
end,
case ttarget3.c3 when 'P' then '0' when 'C'then
'1' when 'D' then '2' end,
substr(ttarget1.c4, 4, 7),
concat(ttarget3.c5, ttarget2.c6)
from ttarget1, ttarget2, ttarget3
where ttarget1.id = ttarget2.id and
ttarget2.id = ttarget.3.id

スキーマ変更を分析および分類することにより、データベース・ビューの作成は、潜在的に複雑であるレガシー・アプリケーション・クエリを変換する（書き換える）ことを試みるよりも単純であることがわかる。

好ましい実施形態では、上記のタイプのスキーマ変更が、移行後リレーショナル・データベース・スキーマに対して１組のビューを定義するのに使用される。図１に示すように、レガシー・スキーマから新しいスキーマへの変更を表現するのにＸＭＬファイル（ＸＭＬファイル１８など）が定義される。前述のタイプのスキーマ変更を使用して、ビュー生成ツール（ビュー生成ツール２０など）が定義される。図１の例では、ＸＭＬファイル１８が、ビュー生成ツール２０に対する入力として取得される。ビュー生成ツール２０は、前述の１組のスキーマ変更と共にＸＭＬファイル１８中にカプセル化された情報を使用することによってＸＭＬファイル１８を処理し、図１にビュー２２として示す１組のビューを定義する。

例えば、実施例１で説明した前述のＸＭＬコードは、図２の列方向分割を定義する。ビュー生成ツール２０は、このようなＸＭＬコードを解析して、図２の例に関して上記で説明したビューを定義する。したがってビュー生成ツール２０は、移行の際に実施されるスキーマ変更のタイプを詳細に定義するＸＭＬ入力に基づいて、ビュー生成を実施する。

図１を参照しながら行った上記の好ましい実施形態の説明は、新しいＪ２ＥＥアプリケーション・プラットフォーム３０から、データベース・クエリ２６を含むレガシー表示ページ２４にどのようにアクセスすることができるかを示す。図１２のブロック図は、レガシー表示ページ２４自体が、ＪＳＰで定義される新しい表示ページへの移行の対象となるときに、別法としてどのように好ましい実施形態を実装することができるかを示す。図１２では、データベース・クエリ２６を有するレガシー表示ページ２４が再び示されている。図１２では、レガシー・データベース１０（スキーマ１２を有する）に対して実行されるデータベース・クエリ２６が示されている。図１２では、図１と同様に、移行後データベース１４はスキーマ１６を有する。やはり図１で示すのと同様に、ＸＭＬファイル１８およびビュー生成ツール２０が、ビュー２２を定義するのに使用される。

しかし図１２の例では、移行を行うアプリケーションがＪＳＰ表示ページ５０を含む。新しいＪ２ＥＥ環境への移行により、レガシー表示ページ２４をＪＳＰで再定義することができる。しかし、上記で指摘したように、新しい１組のビュー（ビュー２２）が新しいデータベース・スキーマをレガシー・データベース・スキーマに実質上マッピングするように定義される限り、好ましい実施形態により、リレーショナル・データベース・クエリ２６を、新しいスキーマ用に書き換える必要なしに保持することが可能となる。図１２の例では、データベース・クエリ２６がJava（商標） bean ５２中にカプセル化される。したがって、ＪＳＰ表示ページ定義５０は、データベース・クエリ２６を書き換えなくとも、レガシー・クエリ２６をカプセル化するように定義されるJava（商標）bean ５２へのアクセスを介してデータベース・クエリ２６を使用することができる。

図１に示す構成要素と図１２に示す構成要素との比較から明らかとなるように、好ましい実施形態により、（図１と同様に）レガシー・システムから移行した後であってもレガシー表示ページ定義を引き続き使用することが可能となる。ユーザにとって都合の良いときに、新しいＪＳＰページ定義を作成して、Ｊ２ＥＥ環境用のＪＳＰ中のレガシー表示ページを複製する（または置き換える）ことができる（結果として得られる構成を図１２の例に示す）。このようにして、レガシー・システムから、ＪＳＰ表示ページを有するＪ２ＥＥベースのシステムへの系統的かつ段階的な移行を実施することができる。

上記で示したように、好ましい実施形態は、レガシー・アプリケーションの、新しいアプリケーション、具体的にはＪ２ＥＥ環境で実装されたアプリケーションへの移行を実施する際に助けとなるシステムおよび方法を提供する。

以上、本発明の様々な実施形態を例示によって詳細に説明したが、本発明から逸脱することなく変形形態および修正形態を作成できることは当業者には明らかであろう。本発明は、添付の特許請求の範囲に包含されるこのようなすべての変形形態および修正形態を含む。

好ましい実施形態の実装における諸構成要素を示すブロック図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 レガシー・リレーショナル・データベース・スキーマから移行後リレーショナル・データベース・スキーマへの例示的移行を示す概略図である。 Ｊ２ＥＥ環境内のレガシー・アプリケーションで定義された表示ページの実行に関する好ましい実施形態の実装における諸構成要素を示すブロック図である。

符号の説明

１０ レガシー・データベース
１２ スキーマ
１４ 移行後データベース
１６ スキーマ
１８ ＸＭＬファイル
２０ ビュー生成ツール
２２ ビュー
２４ レガシー表示ページ
２６ データベース・クエリ
３０ Ｊ２ＥＥアプリケーション・プラットフォーム
３２ ビュー・エンジン・マネージャ
３４ ビュー・レジストリ
３６ レガシー・ビュー・エンジン・アダプタ
３８ レガシー・ビュー・エンジン
５０ ＪＳＰ表示ページ
５２ Ｊａｖａ（商標）ｂｅａｎ

Claims (18)

1. レガシー・アプリケーションを新しいアプリケーションに移行する際に使用する方法において、
   前記レガシー・アプリケーションが、レガシー・スキーマを有するレガシー・リレーショナル・データベースにアクセスするように定義する第１のステップと、
   前記新しいアプリケーションが、新しいスキーマを有する移行後リレーショナル・データベースにアクセスするように定義する第２のステップと、
   前記レガシー・スキーマの前記新しいスキーマへの移行を表す１組の移行スキーマ変更を求める第３のステップと、
   スキーマ変更に関する事前定義された１組のリレーショナル・データベース・ビューを参照し、前記１組の移行スキーマ変更に対応する前記事前定義された組中のビューを識別して、前記移行後リレーショナル・データベースに関する１つまたは複数のリレーショナル・データベース・ビューを生成して前記新しいスキーマを前記レガシー・スキーマにマッピングする第４のステップと、
   レガシー・データベース用に定義されたデータベース・クエリを、前記移行後リレーショナル・データベースに対して実行する第５のステップとを含む方法。
2. 前記事前定義された１組のリレーショナル・データベース・ビューが、列方向分割、行方向分割、列方向マージ、行方向マージ、列名変更、列タイプ変更、ヌル可能−ヌル不能移行、値マップ、列分割、列マージの集合から選択されたスキーマ変更に関するビューを含む請求項１に記載の方法。
3. 前記第３のステップは、移行スキーマ変更の表現を定義するステップを含む請求項１に記載の方法。
4. 前記４のステップは、前記移行スキーマ変更の前記表現を入力として受諾するステップと、前記表現に基づいて前記１つまたは複数のリレーショナル・データベース・ビューを生成するステップをさらに含む請求項３に記載の方法。
5. 前記移行スキーマ変更の前記表現がＸＭＬファイルである請求項３に記載の方法。
6. 前記３のステップは、前記移行スキーマ変更を表すＸＭＬファイルを定義するステップを含む請求項２に記載の方法。
7. 前記４のステップは、前記ＸＭＬファイルを入力として受諾するステップと、前記ＸＭＬファイルの内容に基づいて前記１つまたは複数のリレーショナル・データベース・ビューを生成するステップとをさらに含む請求項６に記載の方法。
8. 請求項１ないし７のいずれかに記載の方法をコンピュータに実行させるコンピュータ・プログラム。
9. 請求項８に記載のコンピュータ・プログラムが記録された記録可能データ記憶媒体。
10. レガシー・アプリケーションを新しいアプリケーションに移行する際に使用するコンピュータ・プログラムにおいて、コンピュータに、
    前記レガシー・アプリケーションが、レガシー・スキーマを有するレガシー・リレーショナル・データベースにアクセスし、前記新しいアプリケーションが、新しいスキーマを有する移行後リレーショナル・データベースにアクセスし、２つのスキーマ間の関係を、定義データ表現内に定義する第１の機能と、
    前記定義データ表現を入力として受け、スキーマ変更に関する事前定義された１組のリレーショナル・データベース・ビューを使用して、前記新しいスキーマに関する１つまたは複数のビューを生成して前記新しいスキーマを前記レガシー・スキーマにマッピングする第２の機能と、
    前記レガシー・アプリケーション内で定義されたリレーショナル・クエリを前記新しいスキーマの１つまたは複数のビューに対して実行する第３の機能とを実現させるためのコンピュータ・プログラム。
11. 前記定義データ表現がＸＭＬファイルである請求項１０に記載のコンピュータ・プログラム。
12. 前記事前定義された１組のリレーショナル・データベース・ビューが、列方向分割、行方向分割、列方向マージ、行方向マージ、列名変更、列タイプ変更、ヌル可能−ヌル不能移行、値マップ、列分割、列マージの集合から選択されたスキーマ変更に関するビューを含む請求項１１に記載のコンピュータ・プログラム。
13. レガシー・アプリケーションを新しいアプリケーションに移行する際に使用するコンピュータ・プログラムにおいて、
    前記レガシー・アプリケーションが、レガシー・ビュー・エンジンを使用して表示可能なレガシー表示ページを含み、
    コンピュータに、
    ユーザに表示する定義済みビューに関係する表示要求を受諾し、ビュー・エンジン・レジストリにアクセスするビュー・エンジン・マネージャを実装する第１のコンピュータ可読プログラム・コードと、
    ユーザに表示する前記定義済みビュー、表示ページ、およびレガシー・ビュー・エンジンの間のアソシエーションを格納し、前記アソシエーションに関する情報を、要求時に前記ビュー・エンジン・マネージャに提供するビュー・エンジン・レジストリを実装する第２のコンピュータ可読プログラム・コードと、
    選択されたビューについて前記レガシー・ビュー・エンジンに関するパラメータを生成するレガシー・ビュー・エンジン・アダプタを実装する第３のコンピュータ可読プログラム・コードと、
    前記レガシー表示ページを前記新しいアプリケーションによって参照して、前記レガシー表示ページを表示可能なレガシー・ビュー・エンジンを使用して要求時に表示する第４のコンピュータ可読プログラム・コードとを実行させるコンピュータ・プログラム。
14. 前記新しいアプリケーションがＪ２ＥＥプラットフォーム上で実行されるように定義される請求項１３に記載のコンピュータ・プログラム。
15. レガシー・アプリケーションを新しいアプリケーションに移行する際に使用するコンピュータ・プログラムにおいて、
    前記レガシー・アプリケーションが、レガシー・ビュー・エンジンを使用して表示可能なレガシー表示ページを含み、
    コンピュータに、
    前記レガシー・アプリケーションが、レガシー・スキーマを有するレガシー・リレーショナル・データベースにアクセスし、前記新しいアプリケーションが、新しいスキーマを有する移行後リレーショナル・データベースにアクセスし、２つのスキーマ間の関係を、定義データ表現内に定義する第１のコンピュータ可読プログラム・コードと、
    前記定義データ表現を入力として受け、スキーマ変更に関する事前定義された１組のリレーショナル・データベース・ビューを使用して、前記新しいスキーマに関する１つまたは複数のビューを生成する第２のコンピュータ可読プログラム・コードと、
    前記レガシー・アプリケーション内で定義されたリレーショナル・クエリを前記新しいスキーマの１つまたは複数のビューに対して実行可能とする第３のコンピュータ可読プログラム・コードと、
    ユーザに表示する定義済みビューに関係する表示要求を受諾し、ビュー・エンジン・レジストリにアクセスするビュー・エンジン・マネージャを実装する第４のコンピュータ可読プログラム・コードと、
    ユーザに表示する前記定義済みビュー、表示ページ、およびレガシー・ビュー・エンジンの間のアソシエーションを格納し、前記アソシエーションに関する情報を、要求時に前記ビュー・エンジン・マネージャに提供するビュー・エンジン・レジストリを実装する第５のコンピュータ可読プログラム・コードと、
    選択されたビューについて前記レガシー・ビュー・エンジンに関するパラメータを生成するレガシー・ビュー・エンジン・アダプタを実装する第６のコンピュータ可読プログラム・コードと、
    前記レガシー表示ページを前記新しいアプリケーションによって参照して、前記レガシー表示ページを表示可能なレガシー・ビュー・エンジンを使用して要求時に表示する第７のコンピュータ可読プログラム・コードとを実行させるコンピュータ・プログラム。
16. レガシー・アプリケーションを新しいアプリケーションに移行する際に使用する方法において、
    前記レガシー・アプリケーションが、レガシー・ビュー・エンジンを使用して表示可能なレガシー表示ページを含み、ビュー・エンジン・マネージャ、ビュー・エンジン・レジストリ、およびレガシー・ビュー・エンジン・アダプタを含むコンピュータ・システム上に実装され、
    コンピュータに、
    ユーザに表示する定義済みビュー、表示ページ、および前記ビュー・エンジン・レジストリ内のレガシー・ビュー・エンジンの間のアソシエーションを格納する第１のステップと、
    前記ビュー・エンジン・マネージャを使用して、ユーザに表示する定義済みビューに関係する表示要求を受諾する第２のステップと、
    前記ビュー・エンジン・マネージャによって受け取った要求に基づいてビュー・エンジン・レジストリにアクセスする第３のステップと、
    前記アクセスするステップで要求された前記ビュー・エンジン・レジストリから、前記アソシエーションに関する情報を、要求時に前記ビュー・エンジン・マネージャに提供する第４のステップと、
    レガシー・ビュー・エンジン・アダプタを使用して、選択されたビューについて前記レガシー・ビュー・エンジンに関するパラメータを生成する第５のステップと、
    前記レガシー表示ページを前記新しいアプリケーションによって参照して、前記レガシー表示ページを表示可能なレガシー・ビュー・エンジンを使用して要求時に表示する第６のステップとを実行させる方法。
17. 請求項１６に記載の方法をコンピュータに実行させるコンピュータ・プログラム。
18. 請求項１７に記載のコンピュータ・プログラムが記録された記録可能データ記憶媒体。

Images