DDS から SQL への変換を簡略化する
最新の DB2 への機能強化は、ほとんどすべて SQL で定義された DB2 オブジェクトのみで利用できます。当然のことながら、ID 列属性、XML データ型、行変更タイムスタンプ・サポートといった、これら SQL 専用機能にアクセスするために、データベース・オブジェクトを DDS から SQL に変換する IBM i 開発チームの数はますます増えています。
DDS から SQL への DB2 オブジェクト変換を自動化するツールが、IBM i Navigator Generate SQL ユーティリティーです。IBM i 7.1 の Technology Refresh では、DDS で作成されたキー付き論理ファイル・オブジェクトと、キー付き物理ファイル・オブジェクトを機能強化することで、Generate SQL ツールの有効性が向上しています。この記事では、この新しいサポートがどのように機能するかを詳しく見てみましょう。
SQL による DDS キーの処理
SQL がどのように DDS キー付きファイル・オブジェクトを処理するかを知ることは大切です。これらのオブジェクトが SQL データ定義に移動する場合、実際に 2 つのオブジェクトを作成する必要があります。TR7 以前は、Generate SQL ユーティリティー (および対応する QSQGNDDL API) は、単一の SQL オブジェクトのソースのみ生成できました。CREATE TABLE ステートメントはキー付き物理ファイル向けに生成され、CREATE VIEW ステートメントはキー付き論理ファイル向けに生成されました。Generate SQL 関数はそれらの DDS オブジェクトのキー定義を無視しました。
DDS キー・フィールド属性はデフォルトでも無視されています。これは主に SQL 規格では、そのキー付きオブジェクト同等物 (SQL 索引など) を、 SELECT、INSERT、UPDATE といったデータ操作言語ステートメントで直接参照できないためです。SELECT ステートメントのキー付き論理ファイルまたはキー付き物理ファイルを参照しようしていた場合、SQL が DDS キー定義を無視した可能性が高いです。
Generate SQL 機能強化の詳細を説明する前に、この点についていくつか例を挙げながら探ってみたいと思います。図 1 は、キー付き物理ファイルとそのファイルを参照する SQL SELECT ステートメントの DDS 定義を示しています。SQL ステートメントがキー付き物理ファイルを参照する場合、SQL はその「テーブル」部分のみ認識します。青色で示したフィールド定義部分です。これにより SQL は、DDS ファイルのフィールドに保存された値を返すことができます (ほとんどの開発者はこの SQL 動作は簡単に把握できます)。
しかし、この SELECT ステートメントが ORDID キー・フィールドで順序付けされていない行を返すと多くの開発者は混乱します。この未定義の順序付け動作は、SQL がこのファイルに関連付けられたキー順アクセス・パスを自動的に使用しないため発生します。そのキー順アクセス・パスは、SELECT ステートメントの照会計画を構築する際に、 SQL 照会最適化機能が考慮する索引の 1 つに過ぎません。キー・フィールド定義は図 1 で赤色で、SQL はキー付き物理ファイルのこの側面を無視できると言う事実を強調表示しています。
図 2 は、前述の例のキー付き物理ファイルに対して定義されたキー付き論理ファイルのシナリオを表現しています。論理ファイル・フィールド定義 (青色) は、それらのフィールド値が SELECT ステートメントで利用できるように SQL ビューの列のように処理されています。DDS 選択指定は View と Index パースペクティブ両方に伝搬されます。その指定が青色と赤色両方になっているのはそのためです。
ここで非常に興味深い点があるのですが、それは SQL SELECT ステートメントへの DDS 選択指定の自動伝搬です。ユーザーの元々の照会、SELECT * FROM KEYEDLF WHERE ordqty > =50 は黒色です。SELECT ステートメントはキー付き論理ファイルの select 指定を引き受ける必要があるため、SQL 照会機能が ordamnt 選択基準 (ordamnt > 999) により、このファイルを参照する SQL ステートメントを自動的に機能強化します。ordamnt 比較は青色で描写され、それが元の SELECT ステートメントの一部でなかったという事実を強調表示します。
繰り返しますが、論理ファイルのキー付き属性は無視されます。その結果、この SELECT ステートメントにより返された順序は、 ORDCUST フィールドによりソートされない場合があります。ORDER BY ordcust 節を追加することで、 SELECT ステートメント結果を明示的にソートできるかどうかと思うかもしれません。ただし、その場合でも SQL 照会機能は、論理ファイルのキー順アクセス・パスを使用する、または使用しない可能性があります。返された行数が少ない場合、メモリー中の返されたレコードをソートする方が、キー付き論理ファイルのアクセス・パスを使用するより早いと照会機能は判断する可能性があります。
SQL がキー付き DDS オブジェクトを 2 つの SQL オブジェクトとしてどのように処理されるか深く理解したと思いますので、新たに向上した Generate SQL サポートがこれらのオブジェクト・タイプにどのように作用するかを見ていきます。
Generate SQL の進歩
図 3 に示すように、IBM i Navigator ツリーのオブジェクトを右クリックすることで、Generate SQL ユーティリティーにアクセスします。単一のオブジェクト、複数のオブジェクト、またはライブラリー内のすべてのオブジェクトの SQL ソースを生成することができます。キー付き物理ファイルやキー付き論理ファイルなどの DDS オブジェクトを選択する場合、DB2 は、元の DDS ソースに一番近いと思われる SQL ステートメントを生成します。
Generate SQL ユーティリティーが起動したら、Options ウィンドウ (図 4) が表示されます。Output タブはデフォルトで表示されます。Options タブをクリックすると、図 4 に表示された Options ビューと一致するようにビューが変化します。一番下に DDS キー付きファイル・オブジェクトの機能強化をサポートする、新しい Generate SQL オプションが 2 つ表示されます。これらは次のオプションです。
- Generate additional indexes (for keyed physical and logical files)
- Generate index instead of view (for keyed logical files)
Generate additional indexes オプションにより、キー付き物理ファイルまたはキー付き論理ファイルと置き換える 2 つの SQL オブジェクトを生成できます。このオプションを指定すると、DB2 は、 DDS キー・フィールドを索引キーとして使用して CREATE INDEX ステートメントを生成し、通常物理ファイルおよび論理ファイル向けにそれぞれ生成される、CREATE TABLE ステートメントおよび CREATE VIEW ステートメントと足並みを揃えます。
図 5 は、前述の例で使用した DDS オブジェクト (KeyedPF と KeyedLF) の生成出力を示しています。予想通り、CREATE TABLE と CREATE INDEX の両ステートメントが KeyedPF DDS オブジェクトについて生成されています。KeyedPF は SQL テーブル名として使用されているため、DB2 は索引名を生成しています。この生成された名前はよりわかりやすい名前に変更できます。
図 5 の二番目の 2 つのステートメントは、KeyedLF オブジェクトについて生成された CREATE VIEW ステートメントと CREATE INDEX ステートメントです。ビュー定義および索引定義の両方とも、論理ファイル定義から選択指定が含まれている点に注目してください。SQL ステートメントの WHERE 節により、ビューは DDS 選択基準を満たす行のみを返し、索引には DDS 選択基準を満たしたキーのキー値のみが入ります。
Generate index instead of view オプションは、キー付き論理ファイルにのみ利用できます。この場合、SQL で論理ファイルのビュー部分にアクセスする必要はありません。むしろ、モダンな SQL 構文に変換された DDS に基づきすべてのキー順アクセス・パス定義の取得に集中しています。(必要な場合、依然としてネイティブ・レコードレベルのアクセス要求により SQL Index にアクセスできます。)
次にあるのは、 simplelf という名前の単純なキー付き論理ファイルと新しい Generate index instead of view サポートにより生成された CREATE INDEX ステートメントの DDS ソースです。
Generate SQL の考慮事項
Generate SQL ツールは、データベースを DDS 定義から SQL 定義に効率的に変換しますが、2 つの点を念頭に置いておく必要があります。まず、Generate SQL ユーティリティーは、物理ファイル定義のみを SQL に変換します。この生成プロセス中にデータは移行されません。物理ファイルから SQL テーブルへのデータ移行は自分で行います。物理ファイルのサイズが大きい場合、適切な計画とテストを実施するようお勧めします。次に、生成された CREATE ステートメントは、たとえデータ・タイプや長さなどの列属性が完全一致する場合でも、元の DDS ファイルと異なるレコード・フォーマット・レベル ID を持った SQL オブジェクトを作成する可能性があります。そうした変更は、データベース・オブジェクトを参照するすべてのプログラム・オブジェクトを再コンパイルして、テストするという耐えがたい作業に取り組む必要があることを意味します。
SQL への移行が既存のアプリケーションに影響しないようにしたい場合は、IBM のサロゲート論理ファイル・アプローチを採用できます。ほとんどのお客様はこのアプローチで SQL 定義データベースにシームレスに移行しています。さらに、サロゲート・ファイルの作成と DDS から SQL への変換を自動化するサード・パーティー・ツールが利用できます。
SQL への道
これで、キー付きオブジェクト機能強化によって、 Generate SQL がいかに簡単に DDS から SQL へのデータベース定義をリエンジニアリングできるかおわかりになったでしょう。明らかに IBM は別の成果物に SQL を採用し、それを使用して簡単に始められるようにしようとしています。SQL を使用した場合の利点も、すでにお分かりいただけたと思います。
