データベース・モダナイゼーションの重要性については、これまでも様々な記事でお伝えしてきた通りです。今回は、その実施に当たってSQLビューを活用することで、リスク、コストを低く抑えつつ、モダナイゼーションの価値を十分に享受できるということをご紹介します。（編集部）
スコット・フォースティーが、SQLビューから成る仮想レイヤを規定することが、データベース・モダナイゼーション戦略にいかに適合しているかについて語ります。
スコット・フォースティー
データベースのモダナイゼーションには様々な形態があり、それぞれコスト、リスク、そして一番重要な要素である価値を独特に混合したものになっています。この記事は、物理データモデル内にSQLビューの仮想レイヤを確立するという、非常に明確なアイディアに焦点を当てています。この記事の終わりまでに、これは価値に関しては決定点をあなたに残しながら、リスクがゼロに近く、コストがゼロに近い状態で実行できることが分かるでしょう。
よくあるデータベース・モダナイゼーション反対論
ちょっと待ってください。話がうますぎて本当とは思えません。私達のチームにはデータベース・エンジニアは居ません。私達には深いSQLスキルがありません。私達にはデータベース・モダナイゼーションに挑むために必要なスキルを獲得する時間がありません！
データベース・モダナイゼーションに対するよくある多くの反対論のいくつかを述べてみましょう：
| 反対論者 | 我が社の物理データモデルはSQLを使ってさえいない！ |
|---|---|
| 反論 | SQLビューはDDSで作成された物理ファイル、SQL表および他のSQLビューに対して作成できます。 |
| 反対論者 | SQLビューは危険です。 |
| 反論 | SQLビューはパフォーマンスに影響しません。SQLビューは最低限の記憶域しか使用せず、サイズが増えることはありませんし、安全に使えます。 |
| 反対論者 | 人材が配置されていません。経営陣は人材の配置にお金を使おうとしません。 |
| 反論 | バランスの取れたアプローチが可能であり、定量的で価値があることを経営陣が理解できるように、資金供給なしでモダナイゼーションを遂行することにより、経営陣の認識、信頼、支持を得なさい。 |
| 反対論者 | 時間がありません。 |
| 反論 | 今、考えは数分で片が付くでしょう。そのために時間を取ることができると思います。さらに、この話題について費やした少しの時間は、次第に価値を生み出し、投資に対する見返りをもたらす筈です。 |
プログラムとユーザーをSQLビューに方針転換させる
多くのIBM i クライアントにとって、物理データモデルはデータベース物理ファイルとキー付き論理ファイルだけで構成されています。ユーザーとアプリケーションに物理データモデルの最下層を直接使用するよう強制することにより、変更の際に大きな障壁が生じます。非SQL言語でデータベースファイルを使用する場合、ファイルの形式は使用するプログラムによって固定されます。後で、ビジネスがファイルに列を追加したい、あるいはする必要が出てきた場合、すべての使用プログラムをそれに対応して統合的に再作成しなければなりません。
データモデルにとってより近代的なアプローチは、たとえビューが基になる表にあるのと同じ列の単なる再射影であったとしても、プログラムとユーザーがSQLビューを使うように変更することでしょう。何故でしょうか？柔軟性です。アプリケーションがSQLビューの仮想レイヤに再注目すると、データセンター全体に変更を波及させることが必要な調整、交渉、その他の大変な作業を行うという従来の心配なしに物理ファイルへの列の追加が可能になります。
論理的な事柄を語るためにこの記事の残りを使う代わりに、実践的な解決策を提供します。詳細を語る前に一点だけ明確にさせてください。データベース・モダナイゼーションを支援する独立系ソフトウェアベンダー（ISV）の製品が数多く存在します。これらのオプションは強力であり検討すべきものなので、これらを仔細に調べることをお勧めします。
実施例
Db2 for i のSQLは数多くの素晴らしいことが行えます。以下の例で、SQLがどのように物理ファイルを発見し、それらの物理ファイルに対してSQLビューを確立するためのSQL文を作り出し、最終的にそのSQL文を実行できるかを示します。この実例は、IBM iの課題に対するSQLソリューションを共有することに主眼を置いたDb2 for i Tutorで公開されています。
▲図1. The Db2 for i のSQL講師（写真：デイビッド・ボウマン）
図1にあるように、SQL Tutorの歓迎ページには例題への様々な道があり、IBM iSeeビデオブログの集約リストさえもあります。ここでは同僚のティム・ローと私が、頻繁にSQLスクリプトの手引きを使ってIBM i に関するハウツー・トピックを視覚的に示しています。SQL Tutorからデータベース・エンジニアリングの話題に入って少し下にスクロールすると、表1に示されているようにSQLの例とIBM iSeeのビデオが表示されます。Virtually done.sql というリンクをクリックすると、SQL ソース・コードと build_view_ statement() SQL スカラー関数および build_views_ over_physicals() SQL プロシージャの呼び出し例が見られる筈です。この例をそのまま使用するために、IBM i でCREATE FUNCTIONとCREATE PROCEDURE というSQL文を1回ずつ実行します。
| GitHub要旨 | トピック |
|---|---|
| Row level auditing.sql 行レベルの詳細を表に組み込む方法を尋ねられました。生成された列を持つ一時表は強力な手筋ではあるものの、次の例は異なるアプローチを示しています。 |
トリガー 隠し列 デフォルト値 |
| SQL DDL with nc.sql データ変更をトランザクションに関与させないようにするために、SQL DMLにはWITH NC文節が含まれています。SQL DDLにはWITH NC文節がありませんが、SQLに精通したユーザーは、同じ振る舞いを実現するためにAUTONOMOUSプロシージャを活用できます。 |
トランザクション回避 |
| Virtually done.sql あなたの物理データモデルに仮想型は含まれていますか？もし含まれていないなら、これを参照するべきです。 |
ビューを使ってモダナイズする |
| iSeeビデオチュートリアル | トピック |
|---|---|
| Convert your DDS to DDL (DDSをDDLに変換する) 私たちの多くは、今日でもデータを記述するために使用されているDDSを持っています。「これをDDLに変換するにはどうすればよいですか？」、「魔法の道具はありますか？」と訊かれてきました。このセッションでは、魔法を紹介するつもりはありませんが、DDSで作成された主要なファイルを取り上げ、DDLを使ってそれらを簡単に表に変換できるようにするいくつかの方法を見ていきます。これは、最新のデータベーステクノロジーを利用できるようにするための重要なステップです。 |
モダナイゼーション |
| Extract your DDL and Save it (DDLを抽出し保管する) 私たちは皆、システムにデータを保存するための優れた手順を持っています。しかし、データベース表に何かが起こった場合、データはあるかもしれませんが、すべてを簡単に再構築できるDDLはありますか？このセッションでは、将来のために主要な説明情報を入手できるように、DDLを簡単に抽出する方法を見ていきます。 |
リバース・エンジニアリング SQLオブジェクト |
▲表1. SQLの操作やハウツービデオを含むデータベース・エンジニアリングの話題
build_view_statement() 関数には、既存のデータベース物理ファイルのスキーマ名と表名が渡されます。作成したいSQLビューの名前が３番目のパラメータになります。この例では表名の末尾に文字”V”を付加した命名法を使用しています。どのような命名規則を採用してもかまいません。私が好きなのは、ビュー名を覚えやすくするため、またデータベース・オブジェクトを一覧表示するツールでオブジェクトを隣り合わせに表示するために、ビュー名の最初の部分に表名と同じ文字列を使用することです。10文字の名前を使用する表がある場合、ビューにはシステムが生成したファイル名が付けられます。ユーザーはこの素敵で長い名前を使用することになりますが、システム名を調整したい場合は、Access Client Solutions (ACS)を介して行います。最後の4番目の入力パラメータは、ビューに対するオプションのシステム名です。これは、物理ファイルに対して不確かな長い名前を使用しているときだけ考慮する必要があります。
図3は、特定のファイルに対して build_view_ statement() 関数を呼び出し、CREATE VIEW 文の構築がうまく行っているのを確認することがいかに容易かを示しています。
▲図2. build_view_statement() スカラー関数がCREATE VIEW SQL文を構築
build_views_over_physicals() プロシージャがこのショーを進めます。これは、ユーザーが指定したスキーマ名の中にあるデータベースの物理ファイルを探すために、最近追加された Db2 for i カタログ (QSYS2/ SYSFILES) を利用します。
各ファイルに対して関数は以下の事をします：
- CREATE VIEW 文のテキストを生成さるために、coolstuff.build_view_statement() 関数を呼び出します
- CREATE VIEW 文を実行します
- ビューの所有権を譲り、物理ファイルの所有者と一致させます
- ビューに物理ファイルと同じ権限を与えます
- 操作の詳細をsession.views_createdという名前の宣言されたグローバル一時ファイル（Declared Global Temporary File 略してDGTF)に記録します。SQL DGTFは、現在のジョブのQTEMP内に存在します。プロシージャ呼び出しの結果を保存したい場合は、副選択付きのINSERTを使用して、session.views_createdにクエリを実行します
与えられたスキーマのすべてのデータベース物理ファイルが処理し終わると、図4に示すように、この関数の全体的な結果が結果セットとして返されます。
▲図3. build_views_over_physicals() 表関数の実行結果
これですべてです！SQLビューから成る仮想レイヤを規定するのが、どんなに簡単かお分かりになるでしょう？
私からの提言：コスト、価値、リスクを考慮し、現代的ツールを使用してデータベース・モダナイゼーションに取り組むこと。
いくつかのケースにおいて、Db2 for i を使ったSQLはIBM iをモダナイズするために使用するツールです。
著者紹介 スコット・フォースティーはIBM i開発部門のシニアテクニカルスタッフで、大半の時間をDb2 for iアーキテクトとして活動しています。1989年にIBMに入社して以来IBM OS開発に従事してきました。フォースティー氏は、頻繁に記事を書いたり世界中で業界イベントの講師を務めたりしており、＠Forstie_IBMiおよびforsie@us.ibm.comで探せます。フォースティー氏は熱心なランナーであり料理好きでもあります。
