 | レベル: 中級 Rizwan Tejpar, DB2 Management Systems Developer, IBM
2008年 01月 03日 DB2 9 pureXML™ テクノロジーを使用することで、ビジネスでのデータ保全性を高めて、レガシー・データのロックインを回避できます。アプリケーション開発者はタスクに最適なストレージ・メディアを使用できるようになり、以前は Web サービスの利用に必要とされていた中間層アプリケーション・ロジックが不要になります。DBA は、データベース・サーバーにロジックを集中化できます。これはパフォーマンスの最適化に貢献します。さらに重要なことは、pureXML テクノロジーにより、データの記述、取得、保管というデータベースが最も得意とする部分にデータベースを使用して、従来のアプリケーション開発に立ち返ることで開発の複雑さを軽減することができます。この記事では、DB2 ヘルス・モニター・サンプル・アプリケーションを例として用いながら、どうすればこれが可能になるかを示します。
情報管理: DB2 9
パート 1 では、データを再記述して XML に再構成するために、アプリケーション開発者は PHP などの中間層プログラミング言語を使用し、さらに言語の個々の DOM パーサーを併用することが多いと説明しました。エンタープライズ・レベルでは、この数は何倍にもなります。複数のサービスおよびアプリケーションのそれぞれのデータが XML に変換される様子を想像してみてください。その上、異なる手法が用いられる場合もあります。これは、ソフトウェア・エンジニアリングの見地からすると、特に保守容易性、パフォーマンス、データ保全性に関して問題発生の原因となります。
まず、データが実際には 2 回操作される点に注目してください。データベース・エンジン内での SQL による操作と、もう一度アプリケーション・レベルでの操作があります。これによりリスクが増大します。データがデータベース・エンジンの外のアプリケーション・レベルで変更されたことで、データ保全性が保証されなくなります。また、アルゴリズムの複雑さは変わらないまま、データベース・エンジンの外でデータを解析して構成しなければならない追加作業が生じることにより、使用するプログラミング言語に応じてパフォーマンスが変動する可能性があります。
変化するビジネスで使用するアプリケーション・アーキテクチャーとしてはまったく不十分です。ビジネスを駆動するデータを管理する基礎となるテクノロジーもまた進化してゆく必要があります。
IBM DB2 9 データベース管理システムは、pureXML™ 機能およびハイブリッド・データベース・エンジンを使用することによってこの問題を解決します。かつては従来のリレーショナル・フォーマットでしか保管できなかったデータを、ネイティブに XML としても保管できるようになりました。DB2 ヘルス・モニター・サンプル・アプリケーションの場合と同様に、従来の SQL データをデータベース・エンジン内で処理中に XML 文書に変換することも可能です。
この意味では、DB2 9 によって次のことが可能になります。
- ビジネスでのデータ保全性を向上させて、データがレガシー・フォーマットにロックインされるのを防ぐ。
- アプリケーション開発者は、タスクに最適なストレージ・メディアを使用して、データを XML として再構成するためのアプリケーション・ロジックを組み込む必要がなくなる。
- データベース管理者は、データベース・サーバーにロジックを集中させ、パフォーマンスを最適化して特定レベルのパフォーマンスを保証できる
DB2 ヘルス・モニター・サンプル・アプリケーションでは最初から pureXML を使用していますが、以下のような実現可能な 3 つのアプローチの照会およびコードを検証することにより、pureXML への移行を試みる場合に必要な概念を説き明かすことができます。
- DOM 構文解析と併用する複数の SQL 照会
- DOM 構文解析と併用する複数の SQL-XML 照会
- 複数の SQL-XML 照会が組み込まれた 1つの XQUERY
上記のすべてのアプローチは、それぞれが従来のアプローチの上に作成されており、最後のバージョンよりさらに多くの pureXML が使用されています。
**分かりやすくするために、下記のコードおよび照会は、XML Schema Definition (XSD) によって定義されているとおり DB2 ヘルス・モニター・サンプル・アプリケーション・ヘルス・レポートのヘルス定義のセクションだけを作成しています。
シナリオ 1
下記の SQL 照会は、データベース・マネージャー、データベース、表スペース・コンテナー、および表スペース・オブジェクトの要求されたヘルス定義情報を抽出します。標準的な SQL 表が返されます。そのため、照会の下に示されている DOM 構文解析を使用して、データを XML として組み立てる必要があります。
リスト 1: 要求されたヘルス定義を抽出する SQL 照会
SELECT t1.ID, t1.NAME, t1.SHORT_DESCRIPTION, t1.LONG_DESCRIPTION, t1.TYPE, t1.FORMULA,
t1.UNIT, t2.EVALUATE, t2.SENSITIVITY, t2.ALARM_THRESHOLD, t2.WARNING_THRESHOLD
FROM table(health_get_ind_definition('en_US')) as t1,
table(
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD, WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('TS', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD, WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('TSC', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD, WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('DBM', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD, WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('DB', 'G', '','')) as t
) as t2
WHERE t1.ID = t2.ID
|
リスト 2: データを XML として組み立てる DOM 構文解析
$dom = new DOMDocument('1.0');
$root = $dom->appendChild(new DOMElement('DB2Health_Report'));
$defset = $root->appendChild(new DOMElement('HIDefinitionSet'));
for($i = 0; $i < count($result); $i++)
{
$def = $defset->appendChild(new DOMElement('HIDefinition'));
$def->setAttribute('hiIdentifier', $result[$i]['ID']);
$def->setAttribute('hiName', $result[$i]['NAME']);
$def->setAttribute('hiShortDesc', $result[$i]['SHORT_DESCRIPTION']);
$def->setAttribute('hiLongDesc', $result[$i]['LONG_DESCRIPTION']);
$def->setAttribute('hiType', $result[$i]['TYPE']);
$def->setAttribute('hiFormula', $result[$i]['FORMULA']);
$def->setAttribute('hiUnit', $result[$i]['UNIT']);
$settings = $def->appendChild(new DOMElement('HISettings'));
$settings->setAttribute('sensitivity', $result[$i]['SENSITIVITY']);
$settings->setAttribute('evaluate', $result[$i]['EVALUATE']);
$settings->setAttribute('alarmThreshold', $result[$i]['ALARM_THRESHOLD']);
$settings->setAttribute('warningThreshold', $result[$i]['WARNING_THRESHOLD']);
}
$xml = $dom->saveXML();
|
シナリオ 2
SQL-XML は、XML 構造を照会自体の中で定義できるようにするための新たな標準です。リスト 3 に示すように、DOM の中でエレメントおよび属性を定義するのではなく、照会によって行っています。言い換えると、以前は列セットとして返されていた各行の代わりに、単一の XML 文書が返されます。
リスト 3: 単一の XML 文書を返す SQL-XML 照会
SELECT
XMLELEMENT
(
NAME "HIDefinition",
XMLATTRIBUTES
(
t1.ID as "hiIdentifier",
t1.NAME as "hiName",
t1.SHORT_DESCRIPTION as "hiShortDesc",
t1.LONG_DESCRIPTION as "hiLongDesc",
t1.TYPE as "hiType",
t1.FORMULA as "hiFormula",
t1.UNIT as "hiUnit"
),
XMLELEMENT
(
NAME "HISettings",
XMLATTRIBUTES
(
t2.SENSITIVITY as "sensitivity",
t2.EVALUATE as "evaluate",
t2.ALARM_THRESHOLD as "alarmThreshold",
t2.WARNING_THRESHOLD as "warningThreshold"
)
)
)
FROM table(health_get_ind_definition('en_US')) as t1,
table(
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD, WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('TS', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD, WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('TSC', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD, WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('DBM', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD, WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('DB', 'G', '','')) as t
) as t2
WHERE t1.ID = t2.ID
|
結果として、すべての定義を単一の XML 文書構造に組み立てるのに必要な DOM 構文解析の量が最小限で済みます。次のリスト 4 は、この最小限の DOM 構文解析を示しています。
リスト 4: すべての定義を単一の XML 文書に構成する最小限の DOM 構文解析
$dom = new DOMDocument('1.0');
$dom->loadXML('<DB2Health_Report></DB2Health_Report>');
$def_set = new DOMDocument('1.0');
$def_set->loadXML('<HIDefinitionSet>'. $result .'</HIDefinitionSet>');
$root = $dom->getElementsByTagName('DB2Health_Report')->item(0);
$def_set_root = $def_set->getElementsByTagName('HIDefinitionSet')->item(0);
$import = $dom->importNode($def_set_root, true);
$root->appendChild($import);
$xml = $dom->saveXML();
|
シナリオ 3
下記の照会では、シナリオ 1 で説明した処理に代わる pureXML による方法が示されています。このアプローチを使用すると、DOM 構文解析が完全に消滅し、外部の連結メカニズムが必要なくなります。XQuery は、XML 文書の構造全体を定義するためのラッピング・メカニズムとして使用され、レポート内にヘルス定義サブセクションを作成するために、シナリオ 2 に登場した SQL-XML 照会が構造の中に組み込まれます。通常、必要なのは XQuery ステートメントだけです。ただし、ヘルス・データが従来の SQL フォーマットであるため、データを XML フォーマットに変換するために SQL-XML を使用する必要があります。
リスト 5: XML 文書全体の構造を定義するための XQuery
xquery
<DB2Health_Report>
<HIDefinitionSet>
{
for $def in db2-fn:sqlquery('
SELECT
XMLELEMENT
(
NAME "HIDefinition",
XMLATTRIBUTES
(
t1.ID as "hiIdentifier",
t1.NAME as "hiName",
t1.SHORT_DESCRIPTION as "hiShortDesc",
t1.LONG_DESCRIPTION as "hiLongDesc",
t1.TYPE as "hiType",
t1.FORMULA as "hiFormula",
t1.UNIT as "hiUnit"
),
XMLELEMENT
(
NAME "HISettings",
XMLATTRIBUTES
(
t2.SENSITIVITY as "sensitivity",
t2.EVALUATE as "evaluate",
t2.ALARM_THRESHOLD as "alarmThreshold",
t2.WARNING_THRESHOLD as "warningThreshold"
)
)
)
FROM table(health_get_ind_definition('en_US')) as t1,
table(
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD,WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('TS', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD,WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('TSC', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD,WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('DBM', 'G', '','')) as t
UNION
SELECT ID, EVALUATE, SENSITIVITY, ALARM_THRESHOLD,WARNING_THRESHOLD
FROM table(HEALTH_GET_ALERT_CFG('DB', 'G', '','')) as t
) as t2
WHERE t1.ID = t2.ID
')
return $def
}
</HIDefinitionSet>
</DB2Health_Report>
|
完全なヘルス・レポート
繰り返しますが、上記 3 つのシナリオではヘルス・レポートの定義セクションのみを作成しています。XSD に定義されているような完全な構造を作成するために、この pureXML ソリューションを使用しました。
上記の照会は難しそうに見えますが、単一の XQuery ステートメントです。4 つのタイプのデータベース・オブジェクトに関するヘルス情報を収集するために、複数の SQL-XML 照会が組み込まれています。XQuery は、下位のすべての XML 文書をまとめるラッパーとしての役割だけを果たします。使用された照会の数を把握するために、ヘルス・レポート・セクションごとの内訳を示します。
表 1: ヘルス・レポート・セクションごとの XQuery 副照会の内訳
| ヘルス・レポート・セクション | 副照会の数 | 説明 |
|---|
| InfoSet | 6 | ヘルス・ダッシュボード情報 |
|---|
| HIDefinitionSet | 1 | ヘルス定義情報 |
|---|
| AlertSet | 7 | ヘルス・アラート情報 |
|---|
| ErrorSet | 0 | エラー情報 |
|---|
| 合計 | 14 | |
|---|
シナリオ間の明確なオーバーラップ・レベル、およびアセンブリー・ロジックの配置に関する異なるパターンに注目してください。
-
シナリオ 1: 指定されたヘルス UDF の列によってデータを表構造で取得します。DOM 構文解析を使用して XML 構造全体を組み立てます。
-
シナリオ 2: 同じソースのデータを取得します。ただし、列を定義するのではなく、エレメントおよび属性を定義します。DOM 構文解析を使用して XML 構造全体にデータを配置します。
-
シナリオ 3: XQuery をラッピング・メカニズムとして使用して、XML 構造全体にシナリオ 2 の構造を配置します。
上記の結果をまとめると、以下の図のようになります。
図 1: シナリオの要約
結果として、1 つの照会のみが使用されることで、アプリケーションの保守が簡素化されました。また DBA の立場からは、トラブルシューティング・プロセスが改善されました。例えばストアード・プロシージャーなどの方法で、ロジック全体をデータベース・サーバーに集中させることができたので、DBA はパフォーマンスおよびデータ保全性を保証するために、データベースの最適化という本来の業務を実施できるようになりました。データが XML になる場合もありますが、SQL の場合と同様に、索引付け、サーバー・サイド・ロジック、照会の最適化も適用できます。
まとめ
この記事では、従来の既存の SQL データに基づく単一のDB2 ヘルス・モニター・サンプル・サービスの作成を検証し、SOA およびデータ中心という両方の観点から分析を行いました。SOA の見地からは、ソフトウェア・スタックの柔軟性という概念がもたらされます。タスクに最適なテクノロジーを使用すると同時に、プレゼンテーション層、ビジネス・ロジック層、データ層を明確に分離するという考え方です。さらに重要なことは、データの記述、取得、保管というデータベース・エンジンが最も得意とする部分を使用して、従来のアプリケーション開発に立ち返ることで、データの観点から SOA アプリケーションの複雑さを軽減する考え方がもたらされることです。
今後は、どのような方向に進むのでしょうか。
単一のサービスが任意のサーバー上の DB2 データベースをモニターできるとしたら、複数のサーバー上の複数のデータベースをモニターする場合を想像してみてください。この考え方をさらに推し進めると、すべての XML ヘルス・レポートをマイニングできるとしたら、それを単一のヘルス・レポートに統合し、最終的には XSLT を使用して RSS/ATOM フィードに変換できる可能性があります。
それを文書化するには、まさに本書でデータベース・エンジンを使用してきたように、データを全社にわたって DB2 データベース/サーバーのヘルス状況の変化を要約表示できるフォームに再記述して再構成します。
DB2 が、管理の観点からビジネスの運用効率を改善するためにこれを実現できるとしたら、同様な手法をお客様関連のデータ分析に適用できるのではないでしょうか。
ダウンロード
注 - ヘルス・モニター・デモは、Web 2.0 Starter Toolkit for DB2 (PHP) にバンドルされています。
参考文献 学ぶために
- このシリーズのパート 1 を読んで、DB2 9 を使用して SOA をインプリメントする方法を学習します。
- テクノロジーのブック・ストアで、この記事で取り上げた技術やその他の技術に関する本を探してください。
製品や技術を入手するために
- IBM 製品の評価版をダウンロードし、DB2® や Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品をお試しください。
議論するために
著者について | 
| | Rizwan Tejpar は、IBM の業界別インターンシップ・プログラム (IIP) の学生であり、IIP において DB2 のオープン・ソース・テクノロジーとの連係を示すサンプル・アプリケーションを開発しています。Tejpar は、2006 年には ZendCon コンファレンスに、2007 年には SDWest コンファレンスに出席して、トレード・ショーの会場で開発者向けの DB2 pureXML™ 機能のデモンストレーションを行いました。最近では PHP 用のDB2 ヘルス・モニター・サンプル・アプリケーションに貢献し、これはデータベースのヘルス・モニターに SOA の着想を取り入れたものでした。Tejpar には、これ以外にも C++、C#、.NET、SQL、XQuery、および JSP などのプログラミング言語の経験があります。 |
記事の評価
| |
