DB2 for i 7.2 TR3 および 7.1 TR11 機能
他の最新の DB2 機能について報告が終わっていなかったと気付いたときは、IBM i 7.3 新機能についてエキサイティングな内容を詳しく書いていました。以下に示すのは、DB2 for i 7.2 TR3 および 7.1 TR11 から提供開始された目玉の新機能です。
グローバル変数にシステム名を割り当てる
グローバル変数を作成する場合、その裏で SQL Server が、変数のロジックと値取得ロジックをサービス・プログラムとして実装する点を思い出してください。以下は、ロング・ネーム (10 文字超) の変数定義です。
これは、以下のシステム名とテキストのある C ILE サービス・プログラムとして実装されます。
もちろん、オブジェクトの名前をこのように付けるのはうっとうしいかもしれません。その他の多くの SQL オブジェクトと同様、変数のサービス・プログラムのシステム名を制御するオプションが登場しました。
新しい構文では、グローバル変数は依然としてロング・ネームですが、システム名は A_TOWER になっています。
グローバル変数を参照する更新可能ビュー
グローバル変数の話をしているわけですが、グローバル変数をビューで使用したことがある場合、おそらく、グローバル変数を参照すると DB2 がビューを読み取り専用と見なすことに気付いたと思います。最新の DB2 PTF がインストールされている場合、グローバル変数を使用するビューを作成できます。
ビューに対して DML ステートメント (INSERT/UPDATE/DELETE/MERGE) いくつかを発行してビューが更新可能であることを確認したり、SYSVIEWS システム・カタログでビューのプロパティを照会したりすることができます。
列 IS_UPDATABLE と IS_DELETABLE が Y または N を返すのに対して、IS_INSERTABLE_INTO は YES または NO を返す点で、SYSVIEWS は少し奇妙な動作をします。
グローバル変数とビューの組み合わせは強力です。ビューは (表関数のように) 制限があっても柔軟性があるパラメーター化のような機能を持ちながらも、ビューの単純性 (多くのデータベース・ツールは表関数にアクセスできません) と更新可能性を維持できるためです。
LOCATE_IN_STRING 関数
LOCATE_IN_STRING は DB2 for i の新しいスカラー関数で、(LOCATE 関数のように) ストリング内の特定のサブストリングの位置を特定するのに便利です。この関数は最大 4 つのパラメーターを受け付けます (最後の 2 つはオプションです)。ソース・ストリング、検索ストリング、開始位置 (ソース・ストリング内)、とインスタンスです。検索で複数のストリングを検出できそうな場合、最後のパラメーターであるインスタンスは、検索のどの検索結果を返すか指定する整数です。
下記のサンプルは LOCATE_IN_STRING を使用して XML テキストを検査し、ストリング内の 4 番目の等号 (=) の位置を返しています。その後、SUBSTRING 関数を使用して、それに続く郵便番号を抽出しています。
結果は以下のとおりです。
この例は少し不自然です。コードでは、郵便番号が常に 4 番目の等号の後に来て、米国の郵便番号が常に 5 桁になると求められているためです。REGEXP_SUBSTR 関数でもっと簡単に実現できなかった (必ずしもループではなく、単一の実行として) この関数の使用法を理解するのは大変でした。例えば、(REGEXP_SUBSTR ではより多くのオーバーヘッドが必要と思いますが) REGEXP_SUBSTR は同じことができ、XML 形式が変化する場合により柔軟性があります。
2 番目の例として、LOCATE_IN_STRING を使用して電話番号または他の厳密にフォーマットされた値の妥当性を確認するのに使用できます。この場合、電話番号にはダッシュが 2 つ付くことになります。ダッシュの 2 番目のインスタンスが見つからない場合、番号は「無効 (invalid)」として返されます。
以下の 1 行を返します。
もちろん、無効な電話番号 616-4-234 はこのテストに合格し、さらに開発者はフォーマット済みデータに依存できる余裕がないことが多いため、私の意見としては、まだ REGEXP 関数は LOCATE_IN_STRING よりはるかにうまくこの種の作業ができます。
OVERLAY 関数
新しいオーバーレイ関数は、特殊化されたタイプのストリング置換関数で、ソース・ストリングの位置、長さ (検索ストリングではなく)、およびターゲット・ストリング (またはデータ型と互換性があるストリング) を指定する機能を実現しています。
オーバーレイ関数のパラメーターは以下のとおりです。
- ソース・ストリング
- 置換ストリング
- ソース・ストリング開始位置
- 置換する文字数
この例を考えてください。
ソース・ストリングのテキスト「ooo」は、可変長のオーダー番号をストリングに挿入する位置を示すための任意のプレースホルダーです。例にあるオーダー番号は 105320 です。置換はソース・ストリングの位置 7 で行われ、位置 7 にある既存の 3 つの文字 ('ooo') を置き換えます。実行すると、上記の式が返ります。
同じ結果を生成する OVERLAY の代替構文を以下に示します。
これにより関数の使用が多少冗長になりますが、パラメーターの目的は簡単に理解できます。
OVERLAY 関数は入れ子にできます。プレースホルダー「x」と「y」がライブラリー名とタイムスタンプに置き換えられる、以下の例を考えてみましょう。
関数は以下を返します。
OVERLAY で複数の置換を行う場合、可変長置換値があるときに逆行しても割に合います。上記の例では、位置 28 で始まるソース・ストリングの「y」部分に続いて位置 9 で始まるライブラリー名の現在時間を置換しました。最初にライブラリー名を挿入していたら、タイムスタンプ・マーカーの開始位置を投げ捨てていたでしょう。OVERLAY の特筆すべき制限は、正確な位置を提供する必要があるということです。位置が変わる場合 (非リテラル値など)、位置の計算に別の関数が必要で、すぐにコードが理解しにくくなる可能性があります。
全体として、細かな問題を除いて、REGEXP 関数は LOCATE_IN_STRING および OVERLAY より柔軟性が高いと思います。にもかかわらず、LOCATE_IN_STRING および OVERLAY は重要な追加です。それらは他の DB2 製品に存在するため、DB2 for i のそのメンバーシップは、クロスプラットフォーム・コードの互換性が増すためです。
時代に遅れないために
開発者と管理者は DB2 ツールボックスのツールに遅れをとらないことが大切です。適宜新機能を使用することは、DB2 コードの作成やメンテナンス時に重宝します。
