要約 : このホワイトペーパーは、SQL Server 2005 DTS プラットフォームの新機能を調査するための実用ガイドです。

トピック

はじめに
概要
データ フローの要素
開発とテスト
まとめ

はじめに

SQL Server 2005 データ変換サービス (DTS) に含まれる新機能を理解するには、いろいろな意味で DTS の以前のリリースの知識からいったん離れ、この製品を新鮮な観点で見直す必要があります。 と言っても、この新しいリリースが以前のバージョンとまったく異なるわけではありません。 その類似点が、せいぜい機能レベル (これが、このホワイトペーパーで繰り返し取り上げるテーマです) にとどまっているためです。SQL Server 2005 DTS をエンタープライズ級の ETL ツールにするために、そのアーキテクチャの大部分に変更が施されました。 きわめて重要な要素が再考され、その設計は、注目に値するいくつかの特性を備えているように見えます。 DTS の最終的な形を表現すると、次のような言葉になります。

• 徐々に機能追加されるリリースではなく、価値ある多くの新機能を備えた新鮮な製品という意味で、"新鮮である"。

• DTS の他のすべてのリリースより使いやすいという意味で、"便利に使用できる"。

• 企業の開発力と生産性を向上させるための進化した理念とアーキテクチャを備えているという意味で、"成熟している"。

• 開発と展開の環境全体が、総合的に見て、その他の開発テクノロジーと同等であるという意味で、"管理しやすい"。

• 構築されるソリューションが、最も複雑なロジック要件を満たせるにもかかわらず、コーディング量も格段に少なく、きわめて単純な方法で表現されるという意味で、"単純な複雑さ"。

ただし、読者が DTS に精通していたとしても、あるいはまったく初めての方だとしても、これらの言葉はこのドキュメントの内容をほんのわずかしか表していません。 このドキュメントでは、この製品の全体的なアーキテクチャを詳細に調査し始める前の段階として、SQL Server 2005 DTS の概要について説明します。 このドキュメントの最後では、DTS のライフサイクル全体の中のソリューションの開発、テスト、および展開を理解するために必要な実用的な要素を確認します。 説明の過程では、SQL Server 2005 データ変換サービスが備える多数の新機能の単純な解説だけでなく、実環境の実用的な例も取り上げています。

では、早速始めることにしましょう。

概要

SQL Server 2005 の DTS は、SQL Server 2000 の DTS から再設計され、完全に再コーディングされています。 その過程では、設計と管理のパラダイムの多くに再考が加えられました。 DTS は、もはや、スタンドアロンの設計ツールではありません。SQL Server 2005 の DTS には "ワークベンチ" の概念が導入されており、開発者や DBA は、開発または管理の特定のタスクに集中することが可能になりました。 このワークベンチには、BI "ワークベンチ" と SQL Server "ワークベンチ" の 2 つがあります。

どちらのワークベンチでも、同様のタスクを実行できます。 また、どちらも、プロジェクトとソリューションの開発をサポートしています。 ソリューションには、1 つまたは複数のプロジェクトが含まれます。 また、プロジェクトには、データ ソース、データ ソース ビュー、DTS パッケージ、その他のファイル類が含まれます。 たとえば、新しいプロジェクトには、現在開発中の DTS パッケージだけでなく、そのパッケージから呼び出される可能性のある任意のパッケージを含めることができます。 また、操作対象のデータベースに対する DDL や DML など、サポートしているすべてのファイルを含めることもできます。 運用環境に展開する場合は、必要なすべてのファイルを 1 か所に集めます。

BI "ワークベンチ" の場合は、パッケージを設計するために、SQL Server RDBMS に直接接続されている必要はありません。 また、作業を保存するための接続も必要ありません。 BI "ワークベンチ" では、Visual Studio と同様に、各プロジェクトがプロジェクト フォルダに保存されます。 また、設計環境から Visual SourceSafe への直接の統合も用意されています。 プロジェクトに変更が発生すると、その変更は VSS に直ちにチェックインされます。

BI "ワークベンチ" とは異なり、SQL Server "ワークベンチ" は主に、SQL、Analysis Services、および Reporting Services サーバーを管理する DBA 用に作成されています。 また、DTS パッケージの設計、実行、およびスケジュール設定もサポートされていますが、ファイル システムではなく、SQL Server に保存されたパッケージのソース管理は含まれていません。

この 2 つの環境は Visual Studio と深く統合されているため、多くの共通部分を含んでいます。 目標がパッケージの実行にあるのであれば、SQL Server "ワークベンチ" を選択してください。 そうでなければ、BI "ワークベンチ" を使用して、パッケージの開発とテスト、さらには複数プラットフォームに対応した開発を行う必要があります。

また、SQL Server 2005 の DTS も .NET Framework をベースに構築されています。 DTS の中核コンポーネントはネイティブ コードですが、マネージ ラッパーと相互運用機能アセンブリを使用すると、C# や Visual Basic .NET などの .NET 言語で、マネージ コードを使用してカスタムのタスクや変換を作成できます。 これにより、この機能の開発が、DTS と Visual Studio の以前のバージョンに比べて格段に容易になります。

DTS 2005 のウィザード

DTS 2005 の設計者は、繰り返しタスクの自動化に役立てるために、BI "ワークベンチ" と SQL Server "ワークベンチ" の両方の環境に、次に示す新しいウィザードを組み込みました。

• DTS パッケージ インストーラ ウィザード

• DTS 構成ウィザード

インポート/エクスポート ウィザードは、DTS 2000 から一部再設計され、調整されていますが、ユーザー インターフェイスから見るとほとんど変わっていません。

DTS インポート/エクスポート ウィザード

DTS 2000 の中で最も単純で、最もよく使用されるウィザードは、インポート/エクスポート ウィザードでした。 このウィザードを使用すると、DBA、開発者、および経験の浅いユーザーは、コードを記述する必要もなく、非常に簡単に、また非常に迅速に、任意の種類の変換元から任意の種類のターゲットにデータを移動することができました。 さらに、このウィザードは、DTS パッケージの作成と設計の方法を学ぶための出発点でもありました。SQL Server 2005 のインポート/エクスポート ウィザードは、外観上はほとんど変わっていませんが、UI 設計は変更されており、結果を SQL Server または .dtsx ファイルに保存した場合のパッケージ結果は大きく異なります。 結果のパッケージが作成、保存、または実行されるときの状態ダイアログも、DTS 2000 とは大きく変わっています。 下の画面は、進行状況ダイアログを示しています。

パッケージが SQL Server またはファイルに保存されたら、そのパッケージを開くことができます。 下の画面は、インポート/エクスポート ウィザード パッケージの制御フローの部分を示しています。

DTS 2000 のインポート/エクスポート ウィザードで作成されたパッケージとは異なり、すべての CREATE TABLE DDL が、最初の SQL 実行タスクである "SQL 準備タスク" に含まれています。 実際のデータの移動は、パイプライン タスクでテーブルが作成された後に実行されます。

パイプライン タスクを開くと、データ フロー コンポーネントが表示されます。 下の例では、3 つのテーブルだけがエクスポートされており、その結果、3 つの変換元と 3 つの変換先 (各テーブルに対して 1 組) が作成されています。

SQL Server 2000 の場合と同じく、インポート/エクスポート ウィザードは、新しい DTS の内部で実行されている実際の動作を初めて見るための便利な方法です。

DTS パッケージ インストーラ ウィザード

DTS パッケージ インストーラ ウィザードは、DTS プロジェクトのインストールを自動的に作成するための手順をガイドします。 このウィザードでは、使い慣れたインターフェイスである Microsoft インストーラを通して構成とパッケージを展開するように選択できます。 展開用にプロジェクトをセットアップするには、BI "ワークベンチ" でプロジェクトを開き、そのプロジェクトを右クリックします。 [プロパティ] を選択すると、そのプロジェクトのプロパティ ページがダイアログとして開きます。 左のプロパティ シートのツリー ビューから [展開ユーティリティ] オプションを選択し、CreateDeploymentUtility プロパティが True に設定されていることを確認します。 これによって、プロジェクトが作成または再作成されたときに、展開ファイルが DeploymentOutputPath パス (既定では、<プロジェクト ディレクトリ>\bin\Deployment) に自動的に作成されます。

プロジェクトが展開用に構成され、また再作成されると、DeploymentOutputPath ディレクトリ内にいくつかのファイルが作成されます。 これらのファイルには、DTS パッケージ、DTSInstall.EXE ファイル、DTSDeploymentUtility.Msi、および DtsDeploymentManifest.xml ファイルがあります。 インストールを起動するには、DTSInstall.EXE を実行します。 これによって、DTS パッケージ インストーラ ウィザードが起動されます。 このウィザードでは、ファイル システムと SQL Server のどちらに展開するかを選択できます。

どちらに展開する場合も、インストール ディレクトリが作成され、インストール ログ ファイルと DTS パッケージ ファイルが格納されます。

DTS 構成ウィザード

DTS 構成ウィザードは、その名前が示すように、構成を作成するための手順をガイドします。 しかし、構成が何に使用されるかは明らかではない可能性があります。 構成は、パッケージの変数とプロパティを実行時に構成できるという点で、SQL 2000 の動的プロパティ タスクに似ています。 ただし、構成は、パッケージの外部に存在する点、形式を XML にできる点、および値の割り当てがパッケージの実行中ではなく実行前に行われる点が異なります。

構成は、動的プロパティ タスクに比べると、より一般的な方法で使用できます。 構成は、作成し、名前を付けることができるため、開発、QA、および運用のために構成を別々に作成することができます。 構成をこのように使用することで、パッケージ自体の変更が避けられます。 構成の場合は、パッケージを開かなくても、パスや接続情報を更新できます。 簡単に言うと、構成は、プロジェクトに対する 1 つのプロパティ セットを表します。

構成ウィザードでは、複数の構成を作成し、パッケージに割り当てることができます。 ただし、構成を割り当てる順序によって混乱が生じる場合があることに注意してください。 パッケージ内に、同じ変数に新しい値を割り当てる複数の構成が含まれている場合、一覧内の構成 LOWER によって一般的な変数が割り当てられます。 構成オーガナイザは上から下に読み込むため、最後の構成が優先されます。

新しい構成を作成するには、デザイナ領域を右クリックし、[構成...] を選択します。 パッケージ構成がまだ有効になっていない場合は有効にした後、[追加] をクリックしてウィザードを開きます。

ここでは [構成の種類] を、[XML 構成ファイル] (既定)、[環境変数]、[レジストリ エントリ]、[親パッケージの変数] の中から選択する必要があります。

XML 構成ファイルのパスを使用すると、パッケージにこの物理ファイルが割り当てられ、このファイルがパッケージの実行のたびに読み取られます。 ファイルが見つからないか、またはパスが無効な場合、パッケージの実行は継続されますが、値は更新されずに、パッケージに既に格納されている値が使用されます。

環境変数を使用するようにした場合、その値を割り当てることができるのは既存のグローバル変数のみです。 将来は、環境変数を使用してパッケージ変数やプロパティを構成できるようになる予定です。

BI ワークベンチ

BI "ワークベンチ" の場合は、ソリューション内の 1 つのデータ変換プロジェクトで DTS パッケージを開発します。 このワークベンチは、エンタープライズ級の DTS ソリューションを開発するための一連のツールを使用して、複数の Visual Studio プロジェクトを同時に操作できるコンテナです。 BI "ワークベンチ" は Visual Studio.NET 2003 をベースに構築されており、統合された開発環境で DTS パッケージの設計、構築、テスト、展開、および拡張を行うことができます。 また、BI "ワークベンチ" は、他のマイクロソフト開発ツール (VB.NET、C#、C++、J#) での .NET フレームワークの使用もサポートしています。 Visual Studio.NET 2003 と統合されているため、BI "ワークベンチ" には統合された開発機能、たとえば、堅牢なデバッガ、複数の開発者から成る環境のための統合されたソース コード管理、統合されたヘルプなどが用意されています。 BI "ワークベンチ" は開発者用に作成されているため、開発者は、従来のアプリケーション構築に使用していたのと同じプログラミング モデル、開発ツール、およびスキルを使用してパッケージやカスタム タスクを構築することができます。

このプロジェクト ベースのモードで操作する方法には、開発作業が SQL Server には縛られなくなることや、ソリューションまたはプロジェクトのすべてのファイルに対するソース管理へのアクセスが自動化され、統合されることなどの利点があります。

最初に BI "ワークベンチ" を開くと、環境のきわめて単純なビューが表示されます。 この段階では、まだ空のソリューションが作成されただけであり、タスク、オブジェクト、パッケージなどは表示されません。 ただし、既にいくつかのウィンドウが開いていることがわかります。 これらのウィンドウには、ツールボックス、ソリューション エクスプローラ、プロパティなどがあり、出力ウィンドウや検索結果ウィンドウが表示される場合もあります。 これらのウィンドウはすべて、現在の場所から非ドッキング状態にしたり、別の場所に再ドッキングしたり、または移動したり閉じたりすることができます。 あるいは、領域を解放して生産性を上げるために、自動的に隠すように設定することもできます。 ウィンドウをいったん閉じた後で再度開くには、メイン メニューの [ビュー] を選択し、メニュー オプションの 1 つを選択します。 また、ソリューション エクスプローラ、プロパティ ウィンドウ、ツールボックス、その他のいくつかのウィンドウは、ツール バーからも直接再度開くことができます。 その場合は、次のグループのアイコンの 1 つをクリックします。

最初に BI "ワークベンチ" を開くと、次のような画面が表示されます。

"ワークベンチ" の既定の構成は、中央にメインの作業領域があり、その周りにサポート ウィンドウが配置されていることに注目してください。 この構成のほとんどは、ニーズに応じてカスタマイズすることが可能であり、それについてはこの後のセクションで説明します。

ソリューション エクスプローラ ウィンドウ

BI "ワークベンチ" で操作を開始するには、最初に、プロジェクトまたはソリューションを開くか、新規作成する必要があります。 最初にデータ変換プロジェクトを作成すると、新しい DTS プロジェクトを含む既定のソリューションが作成されます。 また、最初に空のソリューションを作成して、それにいくつかのプロジェクト、たとえば、Analysis Services プロジェクトや Reporting Services プロジェクトが含まれたデータ変換プロジェクトなどを追加することもできます。 このソリューション/プロジェクトの関連付けを使用すると、開発者は、展開やテストのために多様な作業単位をグループ化することができます。

下の画面は、BI "ワークベンチ" に存在する可能性のある構成の例を示しています。 この例では、3 つの ETL プロジェクト (変換元 1 からステージングへ、変換元 2 からステージングへ、ステージングから EDW へ) と 1 つの Analysis Services プロジェクトがグループ化されています。 この環境は Visual Studio に統合されているため、多数の開発者がソリューションの各部分に対して同時に作業できます。

ただし、下の例は、[DTS パッケージ] フォルダを右クリックし、[新規 DTS パッケージ] を選択した場合のみ表示されます。

dtsx という拡張子の付いたファイルは、すべての情報が保存される中核のパッケージです。 dtsx ファイルを含むソリューションやプロジェクトは、グループ化と構成上の利点のためにのみ存在します。 dtsx ファイルを開くには、単に DTS プロジェクトを作成して、そのプロジェクトに既存の dtsx ファイルを追加します。

ツールボックス

"ワークベンチ" を眺めると、通常はウィンドウの左側に沿って、ツールボックスと呼ばれる別のウィンドウが表示されていることにも気が付きます。 このツールボックスは、操作しているプロジェクトの種類に応じた多くのタブから構成され、DTS プロジェクトには適用されないタブも多く含まれています。 DTS に適用されるタブは、[制御フロー項目] と [データ フロー項目] の 2 つです。 ツールボックスに表示されるタスクとオブジェクトについては、このドキュメントで後述します。 また、画面の解像度によっては、タブ名の横に 2 つのスクロール矢印も表示されます。 すべてのタスクを表示するだけの十分な領域がない場合は、スクロール矢印が有効になり、項目の一覧を上下に移動できるようになります。

ツールボックスを使用していると、既定のビューからタスクやタブを削除してビューをカスタマイズしたくなることがあります。 特定のタスクを右クリックすると、ポップアップ メニューが表示されるため、そこでタブの追加または削除、項目の追加、名前の変更、または削除を行ってビューをカスタマイズできます。 また、項目やタブが表示される順序も、クリックして元の位置から移動先にドラッグするだけで変更できます。

プロパティ ウィンドウ

既定では、プロパティ ウィンドウは "ワークベンチ" の右下隅に表示されます。 このウィンドウが表示されるのは、DTS デザイナで Visual Studio を使用してパッケージの作成を開始し、描画領域、タスク、またはオブジェクトをクリックしたときです。 プロパティ ウィンドウは状況依存のウィンドウであり、クリックした項目に応じて変化することがわかります。

これをテストするには、デザイナのメイン ウィンドウをクリックします。 下の例に示すように、プロパティ ウィンドウにパッケージのプロパティ ページが表示されます。

その他のウィンドウ

デザイン時、BI "ワークベンチ" にはこの他にもいくつかのウィンドウが表示され、それらに対してドッキング、非ドッキング、表示、非表示、または自動的に隠す設定を選択できます。 これらのウィンドウには、次のものがあります。

• [タスク リスト] ウィンドウ - 開発者が説明のためや、後の開発のためのフォローアップとして作成する説明タスクを表示します。

• [出力] ウィンドウ - "ワークベンチ" で発生するほとんどのビルドや実行の操作の結果を表示します。 たとえば、[出力] ウィンドウには、ビルドや展開の最中、または実行時に発生する任意のエラーが表示されます。

• [ヘルプ検索と結果] ウィンドウ - SQL Server Books Online を検索し、その結果を表示することができます。

パッケージをテストするには、まず BI "ワークベンチ" 内で実行する必要があります。 実行時モードに移行すると、パッケージの実行が完了するまで編集は一切できなくなります。 実行時モードでは、次に示すいくつかのウィンドウも表示されます。

• [呼び出し履歴] ウィンドウ - スタック上の関数またはタスクの名前を表示します。

• [スレッド] ウィンドウ - DTS はマルチスレッドのため、このウィンドウは実行されている可能性のあるすべてのスレッドを表示します。

• [ブレークポイント] ウィンドウ - 現在のプロジェクトで設定されているすべてのブレークポイントを表示します。

• [ローカル] ウィンドウ - 現在のスコープ内のすべてのローカル変数を表示します。

• [ウォッチ] ウィンドウ - このウィンドウには、パッケージの実行中に表示できる特定の変数を追加することができます。 また、このウィンドウでは、読み取り/書き込み変数を直接変更することもできます。

パン ナビゲーション コントロール

設計しているパッケージがデザイン画面より大きくなると、スクロールが必要になり、デザイン画面の右下隅に小さな十字の矢印が表示されます。

この部分をクリックすると、ポップアップ ウィンドウが開いてパッケージ全体が小さく表示され、現在の表示可能な領域が点線で示されます。

UI のカスタマイズ

BI "ワークベンチ" の最も優れた機能の 1 つは、そのユーザー インターフェイスを各ユーザーの希望に合わせてほぼ完全にカスタマイズできることです。 ここまでに説明したウィンドウはすべて、非ドッキング状態にしたり、移動したりすることができます。 また、画面内のさまざまな場所にドッキングしたり、他のウィンドウと結合してタブとして表示したりすることもできます。 さらに、自動的に隠すように設定すれば、使用が終了したら、再度必要になるまでは画面に表示されなくなります。

DTS デザイナ

DTS デザイナは、パッケージ開発のためのメイン画面であり、BI ワークベンチと SQL Server ワークベンチの両方に組み込まれています。 このデザイナには、一連のグラフィカル ツールが含まれており、最小のコーディングで、またはまったくコーディングなしで、データ移動、ワークフロー、複雑なデータ変換などを実現できます。 このデザイナには、制御フロー、データ フロー、接続の作成、変数の作成などに使用されるいくつかのウィンドウがあります。

制御とデータのフローが混在していた DTS 2000 とは異なり、制御フローとデータ フローのエディタは完全に分かれています。 制御フローとデータ フローが分離されたことで、複雑な DTS パッケージの開発が格段に容易になり、制御もしやすくなります。 この分離によって、ユーザー インターフェイスがより直感的になり、パッケージの実行が細かく制御でき、データ変換の可視性も向上します。 さらには、カスタムのタスクや変換を開発し、実装するためのプロセスが簡略化されるため、DTS の拡張性も向上します。 複雑な DTS パッケージが簡略化されるだけでなく、インポートとエクスポートの単純なデータ フローも制御フローを気にしないで作成できるようになります。

この 2 つのエディタが分かれたことで、それぞれに別のタスク セットが含まれることになります。 この 2 つのフロー エディタを連携させるには、データ フロー タスク コンテナを通すしか方法がありません。 すべてのデータ移動とデータ変換は、これらの 1 つまたは複数のデータ フロー タスクの内部で発生します。

制御フロー

制御フロー デザイナは、タスクと優先順位制約を含んでいるという点では DTS 2000 に似ていますが、注目する必要のある新しいコンテナ オブジェクトもいくつか導入されています。 これらのコンテナ、すなわち、For ループ、For Each ループ、シーケンス、およびデータ フロー タスクにはすべて、何らかの種類の作業を実行する他のコンポーネントが含まれています。 パッケージのワークフローは、制御フロー デザイナを使用して作成されます。 このデザイナは、各タスクの互いの通信方法や、各タスクの実行順序を図形的に定義できる描画領域です。

制御フロー デザイナにタスクを追加すると、デザイナはそのタスクに、別のタスクに接続するための矢印、つまり優先順位制約を自動的に追加します。

その矢印の線の任意の場所を 1 回クリックすると、DTS によってその矢印が点線に変更されます。 次に、その矢印を別のタスクにドラッグし、その後続のタスクをマウスで再度クリックします。 DTS によってこの 2 つのタスクが連結され、矢印が入力されているタスクは前のタスクが正常に完了した時点で実行されるようになります。

前のタスクが失敗したときだけ後続のタスクが実行されるようにする場合は、2 つのタスクを接続している線をダブルクリックして [優先順位制約] ダイアログを表示します。 このダイアログでは実行結果をいくつかの値に変更できますが、[失敗時] に変更して [OK] をクリックすると、線の色が赤に変わります。

前のタスクの結果に関係なく後続のタスクが実行されるようにする場合は、制約を [完了時] に変更します。 その場合は、線の色が青に変わります。

パッケージ内に 2 つのタスクしか存在しなければ、その 2 つのタスクの間に 1 つの制約しか存在しません。 パッケージに追加のタスクが必要な場合は、多数のタスクの間に複数の制約を追加することで、パッケージに必要なだけの複雑さを設定できます。

論理的なタスクのグループ化

制御フロー デザイナにある、操作性向上のためのもう一つの機能が、タスクのグループ化です。 いくつかのタスクを図形的に 1 つに折りたたむには、追加するすべてのタスクを選択し、右クリックして [グループ化] を選択します。 これによって、選択したタスクの周りに論理的なコンテナが作成されます。 グループを作成すると、容易に 1 つのタスクに折りたたむことができるため、複雑なパッケージが簡略化されます。 コンテナ オブジェクトとは異なり、このグループ化は、実行、ログ記録、変数のスコープなどにはまったく影響しません。 その目的は、図形的な表現だけです。

次の例では、DTS パッケージはデータの読み込みを開始する前に、テーブルとファイル システム ディレクトリをクリーンアップする必要があります。 これを、"クリーンアップ" という名前のコンテナに論理的にグループ化してみます。

最初のタスク "変換元 1 ステージング テーブルの切り捨て" をクリックし、Ctrl キーを押しながら 2 番目のタスクをクリックするか、またはクリックしドラッグして、両方のタスクを選択します。 次に、どちらかのタスクを右クリックしてポップアップ メニューを表示し、[グループ化] を選択します。

DTS によって、2 つのタスクの周りに "Groupbox" という名前の論理的なグループ ボックスが作成されます。 この名前をクリックすれば、"クリーンアップ" に変更できます。 名前の右にある 2 つの山形をクリックすると、

グループを折りたたむことができます。 また、パッケージに合うようにサイズを変更することもできます。

注釈

タスクをグループ化してもパッケージがまだ複雑すぎて直感的に把握できない場合や、単にパッケージ動作について説明したい場合は、パッケージ レイアウトにテキスト注釈を直接追加できます。 テキスト ボックスを配置する場所を右クリックし、[注釈の追加] を選択します。 デザイナによってテキスト ボックスが作成され、そこに直接テキストを入力したり、必要に応じてサイズを変更したりすることができます。 また、注釈ボックスを選択して右クリックし、[テキスト注釈フォントの設定] を選択することによって、フォント、サイズ、および色を変更することもできます。 注釈はデータ フロー デザイナにも追加できることに注意してください。 これについては、このすぐ後で説明します。

接続

気付きにくいかもしれませんが、制御フロー デザイナ ウィンドウの一番下には 2 つのタブがあります。 最初のタブには、制御フローとデータ フローの両方のタスクが利用できるデータ接続の一覧が含まれています。 これらの接続は、任意の操作で変換元またはターゲットのどちらとしても参照でき、リレーショナル データベースまたは Analysis Services データベース、フラット ファイル、その他のデータ ソースに接続できます。

新しいパッケージを作成した時点では、接続はまだ定義されていません。 接続を作成するには、[接続] 領域を右クリックし、適切なデータ接続の種類を選択します。 ここで選択できる種類にはいくつかあり、これについてはこのドキュメントで後述します。 接続を作成した後は、その名前を変更することによって、名前付け規則により適合させたり、この接続に含まれる内容をより適切に表現したりすることができます。

変数

制御フロー デザイナ ウィンドウの一番下の 2 番目のタブには、変数の一覧が表示されます。 変数は、タスクの間で値を渡したり、実行時のパッケージの実行方法を動的に制御したりするためにパッケージの全体にわたって使用されます。 [変数] ウィンドウには、変数の名前、スコープ、および名前空間が表示されます。

DTS 2000 のグローバル変数と SQL Server 2005 の変数の主な違いは、各変数にスコープが存在するようになった点です。 スコープを使用すると、変数とパッケージやオブジェクトとの関連付けを、より厳密に定義され、制御された方法で行うことができます。

各パッケージ、タスク、イベント ハンドラ、さらには For ループ、For Each ループ、シーケンスのコンテナはすべて、それぞれのスコープ内にある変数を持つことができます。 これによって、SQL 実行タスクと For ループ コンテナの両方で、それぞれのオブジェクトだけが参照できる同じ名前の変数を定義できます。

変数については、この後のセクションでさらに詳しく説明します。

データ フロー

データ フロー デザイナは、変換元とターゲットの間のすべてのデータ移動とデータ変換を管理します。 パッケージ内にデータ フローを含めるには、制御フロー デザイナにデータ フロー タスクを手作業で追加するか、またはデータ フロー デザイナ ウィンドウを開いたときに DTS にその操作を実行させる必要があります。 データ移動とデータ変換は、このデータ フロー タスク内にカプセル化されます。 データ フロー タスクはデータ移動とデータ変換のステップの論理的なコンテナですが、これらの移動または変換ステップの 1 つが失敗すると、データ フロー タスクの全体が失敗します。

1 つのパッケージには、複数のデータ フロー タスクを含めることができます。 各データ フロー タスクの内部には、変換元と変換先の間のいくつかの "フロー" が存在する可能性があります。 データ フロー タスク内のこれらの変換元-変換先フローのそれぞれはグラフと呼ばれ、1 つのグラフには変換の複数の段階が含まれる可能性があります。 グラフには、通常、データを供給する変換元アダプタと、データを消費するターゲット アダプタの両方が存在します。 変換は、このアダプタ間に作成されます。 データが変換元と変換先の間で変更される場合、その変更は変換の内部で実行されます。 データが変換元と変換先のアダプタの間で移動されるだけの場合、制御フロー デザイナの優先順位制約に似たパスがプロセスによって使用されます。

パス内の列のプロパティは、アダプタの間の矢印をダブルクリックすることによって表示できます。

これらの制御フローとデータ フローのコンテナ オブジェクトについては、この後のセクションでさらに詳しく説明します。

パッケージの実行

ここまでは、パッケージの設計についてのみ説明してきました。 パッケージを実行するには、ツール バーの [再生] アイコンをクリックするか、F5 キーを押すか、あるいは [デバッグ] メニューの [開始] を選択します。 これによって、設計環境が実行モードに移り、いくつかの新しいウィンドウが開かれ、メニューとツール バーの新しい項目がいくつか使用可能になり、さらにパッケージの実行が開始されます。 ただし、パッケージが実行を完了しても、BI "ワークベンチ" はすぐにはデザイン モードに戻らず、実行モードにとどまります。 このため、開発者は、任意の実行時変数を調べたり、任意の実行出力を表示したりすることができます。 このとき、パッケージ内のオブジェクトを変更することはできず、変数とオブジェクトの読み取り/書き込みプロパティの変更だけが可能になります。

デザイン モードに戻るには、デバッグ ツール バーの [停止] アイコンをクリックするか、Shift キーを押しながら F5 キーを押すか、あるいは [デバッグ] メニューの [デバッグの中断] を選択します。

SQL Server ワークベンチ

DTS に関しては、SQL Server "ワークベンチ" と BI "ワークベンチ" の違いはほとんどありません。 SQL Server "ワークベンチ" は、管理しているサーバー上の DTS パッケージやジョブを管理することと、より簡易な DTS パッケージの構築と設計を行うことを DTS の主な使用目的にしている DBA 用に作成されています。 この 2 つの "ワークベンチ" の最も大きな違いは、SQL Server "ワークベンチ" では DTS パッケージを SQL Server に展開できる点 (これに対して、BI "ワークベンチ" ではファイル システムに対してのみ) と、SQL Server "ワークベンチ" では DTS オブジェクトの操作のために SQL Server への接続が必要な点です。 SQL Server "ワークベンチ" の場合、オブジェクト エクスプローラを使用して新しいパッケージを作成するように選択すると ([データ変換サービス] フォルダに移動し、次に [パッケージ] に移動して、右クリックします)、パッケージを SQL Server またはファイルに保存できますが、この方法ではプロジェクトまたはソリューションは作成できません。 また、オブジェクト エクスプローラでは、既存のパッケージをファイルから SQL Server にコピーすることもできます。

SQL Server "ワークベンチ" で新しいプロジェクトまたはソリューションを作成するには、[ファイル] メニューの [新規] を選択します。 いったん作成した後は、BI "ワークベンチ" の場合と同様にプロジェクトやソリューションを操作できます。 同じツールやウィンドウがすべて利用でき、また、SQL Server "ワークベンチ" 内で SQL ステートメントの実行やテストを行うこともできます。

アーキテクチャ

データ変換サービスが、SQL Server プラットフォーム上の価値あるオプション テクノロジーから、ETL (抽出、変換、ロード) プロセスを流れるエンタープライズ データのための主要な通路に進化したことにより、SQL Server 2005 のデータ変換サービスに見られる、まったく新しい、リッチなアプリケーション アーキテクチャが生まれました。SQL Server 2005 プラットフォーム上の DTS のアーキテクチャは、一見すると以前の DTS アーキテクチャに似た要素で構成されていますが、各構成要素ははるかに成熟しています。

SQL Server 2005 DTS のアーキテクチャは、下の図に示す多くの要素で構成されています。

図に示すように、制御フロー (データ変換ランタイム) は、DTS パッケージ環境のメインの機能のほとんどに対して主要な役割を果たしています。 制御フローは、DTS ランタイム エンジンと等価なユーザー インターフェイスとして、パッケージ内のオーケストレーションの要件を解決し、また、タスクの実行を起動するために開発された任意のレベルのロジックを満たします。 このランタイム エンジンは、多くの点で DTS の以前のバージョンの全体的なアーキテクチャに似ています。 ただし、このアーキテクチャは、次の基本的な 2 つの点で大きく異なっています。 特に目立つのが、パイプライン エンジン (つまり、データ フロー) と呼ばれる、データの移行と集計のための二次的なエンジンの存在であり、もう一つが、ランタイム エンジンが備える機能の豊富さです。

SQL Server 2005 DTS プラットフォームの 2 つの中核のエンジンに加えて、「概要」のセクションで説明した DTS 開発環境によって定義されるいくつかの要素も存在します。 データ ソース定義とデータ ソース ビューは、デザイン時に DTS プロジェクト内の複数のパッケージにわたる接続とリレーショナル ソースの情報を使用するための 2 つの要素です。 これらのさまざまな要素によって、密接に連携し、また複雑でもあるが、視覚的には単純な ETL プロセスを開発できるプラットフォームが生まれています。

このセクションでは、アーキテクチャ上の各種の要素に焦点を当て、これらの各要素が実環境のソリューションにどのように役立つかを示す多様な実際の例について説明します。

データ ソースの要素

DTS アーキテクチャの基本的な要素は、接続として使用するリレーショナル スキーマ接続情報を作成するための手段です。 データの抽出や読み込みは、これらの接続を通して実行されます。

データ ソース

DTS ソリューションの内部では、プロジェクトのソリューション内のデータ プロバイダに関する情報は、最終的にデータ ソース内にキャプチャされます。 データ ソースは、単純には、データの変換元または変換先への接続情報を定義します。 データ ソースの定義のためのユーザー インターフェイスを確認すると、ユーザーには、使い慣れた Microsoft データ リンクのユーザー インターフェイスが提供されます。 下の画面は、データ ソースの "データ リンクのプロパティ" の典型的な定義を示しています。

データ ソースはソリューション全体に対して定義されるため、データ ソースが接続だけを表すわけではありません。 このデータ要素、パッケージ接続マネージャ、および接続の間の通信については、このセクションの後の方で説明します。

データ ソース ビュー

データ接続を定義するための二次的な手段が、抽象化されたスキーマ情報を作成するためのアーキテクチャ上の新しいアプローチである、データ ソース ビューによる方法です。

抽象化されたスキーマ

データ ソース ビューは、その名前が示すように、基になるリレーショナル スキーマ オブジェクトを定義したり、あるいは、名前付きクエリの定義を通して、データ変換プロジェクト ソリューション内のパッケージに提供されるテーブル、ビュー、および行を定義したりできるという点で、リレーショナル ビューと同様の目的を果たします。 データ ソース ビューでは、その定義の前に、"データ ソース" が既に確立されていることが必要です。 既存のデータ ソースが存在すれば、パッケージ ソリューション設計環境内の別の場所で、複数の関連するテーブルや関連のないテーブル、またはリレーショナル クエリ定義を作成したり利用したりすることができます。

簡略化されたスキーマ

データ ソース ビューの固有の利点として、次の 2 つの点を上げることができます。 つまり、データ ソースの基になるスキーマからテーブルとビューを選択的に追加することによってスキーマを簡略化できること、および、リレーショナル ビューに似た名前付きクエリを基になるデータに適用できることです。

データ ソース ビューがきわめて有効な典型的なシナリオは、従来のパッケージ化された ERP (Enterprise Resource Planning) システムであり、特に、特殊なプロバイダが利用できない場合です。 これらのシステムには、システムが提供する "エンタープライズ" 機能を構成している基になるテーブルとビューが、文字どおり数千の単位で存在します。 データ ソース ビューを使用した場合、複数のデータ ソース ビューを定義することによって、これらのスキーマ オブジェクトを管理しやすい、より小さなグループにセグメント化できます。 データ ソース ビュー (DSV) の候補の例には、売掛金 DSV、買掛金 DSV、販売注文管理 DSV、在庫管理 DSV、および、パッケージ化されたより大きなシステムによって提供されるその他いくつかの機能領域があります。

数千のスキーマ オブジェクトによって生じる純粋な複雑さに加えて、これらのシステムでは、通常、オブジェクト名の定義に一般的な英語の表現は使用されず、暗号のような規則を使用してエンティティ (たとえば、顧客マスタのエンティティが A54210) やその列 (たとえば、顧客のファーストネーム列が A5FNM8) を定義します。 この後者の問題は、データ ソース ビューの機能、つまり、1 つまたは複数の名前付きクエリを使用して、スキーマ内の 1 つまたは複数の基になるテーブルに独自の命名規則やフィルタ選択ロジックを適用する機能によって解決されます。

接続

接続は、依然として、DTS パッケージ内のデータ接続を制御する基本的な要素です。 接続は、データ移動のための変換元または変換先であり、一般的には、データ ソースと通信するための手段です。

データ ソースに基づく接続

DTS パッケージ内の接続 (より正確には、接続マネージャ) は、ビジネス インテリジェンス "ワークベンチ" または SQL Server "ワークベンチ" ソリューション全体の中の既存のデータ ソースに基づいて構築できます。 こうすることで、接続情報の保守をパッケージの外に出すことができ、独立したデータ ソース ファイルも不要になります。 このアプローチの利点は、データ ソース (つまり、接続情報またはスキーマ所有者情報) の変更が可能であり、そのデータ ソースを利用している DTS パッケージを編集する必要がない点にあります。 さらに、接続を全体的なソリューションのデータ ソースの外で定義すれば、DTS パッケージのデータ フロー指向の要素を開発する場合に、データ ソース ビューをすべてパッケージ設計環境に取り込むことができます。

データ ソースとは独立した接続

接続を既存のデータ ソース定義に基づいて定義する機能は存在しますが、それが要件ではありません。 1 つのパッケージのコンテキスト内で、接続のソースとして任意の OLEDB または ODBC 準拠の接続を定義する機能が別のオプションとしてあります。 さらに、全体的なソリューションに含まれている Analysis Services プロジェクトや、ファイル システム内のファイルに基づいて接続を定義することもできます。

下の例は、パッケージの接続を既存のデータ ソースに基づいて定義しているようすを示しています。

制御フローの要素

制御フローは、DTS パッケージ内の機能的なやり取り、条件処理、および全体的な実行のオーケストレーションを制御するための基本的なコンポーネントです。 制御フローは、制約を通して互いに接続されているタスクから構成されています。 この点は、DTS の以前のバージョンにあった設計環境の中核の要素とそれほど変わっていません。 ただし、この類似点は見た目だけにすぎません。 それは、SQL Server 2005 DTS 設計環境内の制御フローが、視覚的な定義とは別に、アーキテクチャ的には DTS ランタイム エンジンの全体的な機能を起動するからです。 このエンジンは、パッケージのワークフローを実行する場合に制御フローの定義を利用します。

タスク

タスクは、引き続き、DTS 環境内の基本的な単位です。 タスクは、アーキテクチャのこの特定の実行可能要素に特有の機能をカプセル化します。 タスクによって、パッケージを論理的に定義する手段、さらには、パッケージがそれ自身を物理的に実行する手段が提供されます。

一般的なアーキテクチャ

タスクのアーキテクチャは、各タスクが、ランタイム環境と通信するためのプロパティと関数の標準化されたセットをサポートしているという点にあります。 ほとんどのタスクに含まれている標準のプロパティには、次のものがあります。

• 名前 - パッケージ内のタスクに割り当てられた一意名 (たとえば、"ファイル システム タスク 1")。

• ID - パッケージ内のタスクに割り当てられた一意識別子 (たとえば、{D1938EBB-6DC3-48E1-B7D7-97F5A04928EA} などの GUID)。

• 説明 - ユーザーにタスクの内容を示す説明テキスト (たとえば、"ファイル コピー プロセス")。

• 実行値変数 - タスクの実行結果を格納するための変数。

• 失敗時にパッケージを失敗とする - 失敗を報告したタスクがあった場合に、パッケージ全体を失敗させるかどうかを示すブール値。

• 失敗時に親を失敗とする - 失敗を報告したタスクがあった場合に、そのタスクの親を失敗させるかどうかを示すブール値。 親には、パッケージまたはコンテナを指定できます。 これについては、この後のページで説明します。

• トランザクション属性 - パッケージの実行におけるタスクの参加またはトランザクション コンテキストの作成の性質を定義します。

• ログ記録 - このセクションの後の方で説明する多数のログ記録プロバイダの 1 つに対して、必要に応じてログ記録を実行するためのインターフェイス。

• イベント ハンドラ - タスクにイベントを発生させ、そのイベントを処理する機能を公開するためのインターフェイス。

• ブレークポイント インターフェイス - パッケージやタスクの実行をデバッグする場合に、ブレークポイントを設定し、認識するためのインターフェイス。

• 構成インターフェイス - 動的なパッケージ構成をタスクの特定のプロパティにマップするためのインターフェイス。

この一般的なプロパティの一覧を DTS の以前のバージョンと比較すると、ランタイム環境の機能が新しいレベルに達していることがよくわかります。 DTS の制御フローとランタイム アーキテクチャを構成しているタスクを見直してみれば、ランタイム環境の堅牢性がより深く理解できます。

実用的なタスク

このドキュメントの構成上、実用的なタスクとは、パッケージの実行環境を変更したり、オペレーティング システムと通信したり、あるいは、基になるその他のシステムとの統合を促進したりするタスクを指します。

ActiveX スクリプト タスク

ActiveX スクリプト タスクには、実行時に実行される ActiveX スクリプトを開発するという点で、DTS の以前のバージョンにあったのと同じ機能が維持されています。 以前のバージョンでは、これが非常に高度な実行時の機能を実現するためのの唯一の手段でしたが、これらの機能は、現在ではランタイム エンジンに標準で含まれています。 このため (このセクションの後の方で説明する別の理由もありますが)、現在では、同じ結果を達成する代わりの "ストック" の手段を調べる前に ActiveX スクリプト タスクを検討する理由はほとんど見当たりません。

パッケージ実行タスク

パッケージ実行タスクは、パッケージのワークフローの中で実行時に二次的な子パッケージを実行するという点で、DTS の以前のバージョンにあった機能と同様の目的を果たします。 アーキテクチャ上の違いは、現在は、子パッケージには変数の形では値が "プッシュ" されていない点です。 子パッケージは、実行時に親パッケージにアクセスして、構成値を "プル" する役割だけを果たします。 それにより、子パッケージには、その構成に対するより大きな実行権限が与えられ、また、他のパッケージから呼ばれる子パッケージとスタンドアロン パッケージの両方として応用の幅も広がります。

プロセス実行タスク

プロセス実行タスクもまた、DTS の以前のバージョンから拡張されています。 以前のバージョンと同じく、このタスクは、コマンド ライン経由で実行可能な要素を実行するという役割を果たします。 下の画面に示す拡張機能では、現在ではパッケージまたはコンテナ スコープ変数 (後で説明します) を定義し、それらの変数に標準入力、標準出力、および標準エラー I/O のストリームをリダイレクトできるようすが示されています。 これにより最終的には、必ずしも十分に詳細であるとはいえないリターン コード以上に、プロセス実行の状態をキャプチャすることが可能になります。

その後、必要に応じてこの I/O ストリーム情報を含む変数をテストして、コマンドの成功または失敗の程度を判定することができます。

ファイル システム タスク

ファイル システム タスクは DTS に新しく追加された機能であり、ファイル システムと通信する場合に頻繁に必要になる機能を提供します。 ファイル システム タスクは、次に示すいくつかの操作を実行できます。

• ディレクトリの作成

• ディレクトリやファイルのコピー、移動、および削除

• ファイルの名前の変更

• ファイルの属性の設定

このタスクの実際の威力は、この製品の以前のリリースのように大量の ActiveX スクリプトを作成しなくても、これらの操作を任意の数だけ所定の順序で実行できる機能にあります。

ファイル転送プロトコル タスク

ファイル転送プロトコル (FTP) タスクは、FTP 経由でアクセス可能なリモート サイトと通信して、リモート サイトにファイルを移動したり、リモート サイトからファイルをコピーしたりする機能を提供します。 このタスクには、ファイル システム タスクにある機能の多くが含まれています。 これらの機能を下の図に示します。

このタスクは、同じタスクの実行内で、リモート サイトへのアクセス、リモート フォルダの作成、既存のファイルの削除、新しいファイルの送信、およびローカル ディレクトリへのファイルの読み込みのすべてを実行できるという高い柔軟性を提供します。 このタスクの機能によって、リモート データ ソースの利用機会がより現実的になります。

メッセージ キュー タスク

メッセージ キュー タスクは、もともと DTS の以前のリリースにもありましたが、送信 (または受信) するメッセージに応答してトリガされる機能との間でエンタープライズ アプリケーション統合を実現するための非常に強力なオプションになっています。 送信できるメッセージの形式は、静的文字列、グローバル変数の値、またはデータ ファイルです。 最後のオプションは、特に、リモート サーバー上で実行され、ローカライズされたシステムからデータを抽出して、それをメッセージ キュー経由でデータ ファイルの集中管理コンシューマ (データ ウェアハウスや運用データ ストアなど) にルーティングする DTS パッケージによる分散型抽出アーキテクチャが必要なシナリオにおいて最も有効です。

メール送信タスク

DTS 2005 にある "実用的な" タスク グループの最後のメンバは、メール送信タスクです。 DTS の以前のリリースにも同様のタスクは存在しますが、このタスクは、その基になるアーキテクチャの面で 1 つ大きく異なる点があります。 それは、SQL Server 2005 DTS のメール送信タスクが、サーバー間での電子メール メッセージの送信に SMTP (Simple Mail Transfer Protocol) を利用している点です。 これによって、このタスクの以前のバージョンにあった同じアーキテクチャの "構成" 要件や従属関係がなくなり、複数のサーバー上に存在するパッケージでこのタスクを利用することが格段に容易になります。

これらの実用的なタスクによって、運用環境と動的に通信し、その多くの要素を利用するための機能が提供されます。 これらの機能は、異種環境に対応した高度な ETL 設計の土台であり、これをベースにして初めて、SQL Server 2005 DTS が備える残りの "データセンター" タスクが実現されます。

データセンター タスク

データセンター タスクは、クエリの実行またはデータセンター プロセスのトリガのどちらかを通して、データ リポジトリと直接通信するタスクです。 "実用的な" タスクが運用環境との通信を可能にするのに対して、これらのタスクは、各種のリレーショナル データ リポジトリやマルチディメンション データ リポジトリ内のデータやスキーマ情報を接続、操作、および格納するための基礎になります。

Analysis Services 実行 DDL タスク

Analysis Services 実行 DDL タスクは、Analysis Services OLAP データベースに DDL を発行して、OLAP スキーマ オブジェクトの作成と変更に影響を与える機能を備えています。 これは、SQL Server 2005 ビジネス インテリジェンス ソリューション アーキテクチャ全体への価値ある機能追加です。 OLAP スキーマ オブジェクトの作成または変更の詳細については、Books Online を参照してください。

Analysis Services 処理タスク

Analysis Services 処理タスクは、DTS の以前のバージョンの OLAP 処理タスクまたは Analysis Services 処理タスクと同様の目的を果たしますが、この新しいタスクではいくつかの機能が強化されています。 このタスクの機能はこのホワイトペーパーの後の方でさらに詳しく説明しますが、このタスクの一般的な考え方は、SQL Server 2005 DTS アーキテクチャの全体にわたって同じレベルのエンタープライズ処理を可能にすることにあります。 このタスクでは、マルチディメンション スキーマ オブジェクトの処理での各種のトランザクション方式や、新機能の可変並列度がサポートされています。

データ マイニング クエリ タスク

データ マイニング クエリ タスクは、DTS の以前のリリースのデータ マイニング クエリ タスクが進化したものになっています。 SQL Server 2005 DTS では、データ マイニング クエリをより柔軟に定義できるようになりました。 つまり、パラメータが使用可能になり、また、結果を DTS 変数に 1 つの行または結果セットとしてマップできます。 以前のバージョンと同様に、マイニング出力をリレーショナル テーブルに格納する機能も存在します。

SQL 実行タスク

SQL 実行タスクは、基になるリレーショナル データ ソースに対してリレーショナル クエリ (DDL または DML) を実行する機能を提供します。 このタスクの動作は、基本的には以前のバージョンと同じですが、タスクの機能を拡張するための最小限の新機能が導入されています。 最初の拡張機能は、新しい [パラメータ マッピング] タブでパラメータを定義する機能です。 現在、パラメータは下の図に示すように定義できます。

これらのマッピングによって、タスクで定義された SQL ステートメントとの間で発生するパラメータ化された情報のフローをはるかに柔軟に管理できるようになります。

SQL Server 2005 で変更されたもう 1 つの要素は、結果を複数の種類にキャプチャする機能、および、それをメモリ内で実行する機能のサポートです。 下の図に示すように、現在では、結果を複数の DTS 変数に、異なる結果セットの種類 (XML を含む) として保存できます。

これらの拡張機能が組み合わされてタスクの使いやすさが向上し、タスクは、制御フローの中で最も強力な、データ中心の要素の 1 つになっています。

一括挿入タスク

一括挿入タスクは、基本的には、DTS の以前のリリースにあったタスクと同じです。 従来と同様、このタスクは、データをまったく変更しないでテキスト ファイルから SQL Server リレーショナル テーブルに読み込む場合にはほぼ自動的に選択されます。 前のリリースとの主な違いは、タスク自体というより、このタスクを使用して、データ フロー タスク内の DTS 独自の "データ ポンプ" 機能に見られる速度の改善を生かすという、新しいアーキテクチャ上の工夫にあります。

データ フロー タスク

いくつかの点で、データ フロー タスクをタスクと呼ぶのは正しい表現ではありません。 それは、データ フロー タスクが、実際には、ランタイムの制御フロー エンジンから、DTS アーキテクチャの二次的な要素であるデータ フローまたはパイプライン エンジンへのエントリ ポイントを表しているためです。 このセクションの後の方では、データ フローとパイプライン エンジンの機能に焦点を当てて説明します。

優先順位制約

優先順位制約は、SQL Server 2005 DTS アーキテクチャの制御フローの部分に存在するもう一つの中核コンポーネントです。 優先順位制約が存在することにより、主として ETL ソリューション内の経路を定義する条件ロジックを設定することが可能になります。 制約を使用すると、DTS パッケージ内で、成功と失敗の基本的な状態を超えるロジックを柔軟に設計できます。 つまり、SQL Server 2005 DTS は、実行の標準の状態をサポートするように大幅に拡張されているだけでなく、ワークフローの要素を制御フロー環境に適用するための実行時の条件ロジックも動的にサポートしています。

制約の値

優先順位制約は、初期状態では次の 3 つのいずれかに定義できます。

• 成功 - 成功の制約は、制御フローのそのブランチを継続するには、前のタスクが正常に完了する必要があることを示します。

• 失敗 - 失敗の制約は、制御フローのそのブランチを継続するには、前のタスク (1 つまたは複数) が失敗で終了する必要があることを示します。

• 完了 - 完了の制約は、前のタスク (1 つまたは複数) が完了すると、制御フローのそのブランチが継続することを示します。

評価における式

優先順位制約での注目すべき変更は、条件式のサポートです。 この条件式を制約の値と共に使用すると、適切に制御されたいくつかのインフローを生成できます。 この例については、このセクションの後の方で説明します。

評価演算子

優先順位制約のプロパティとして評価演算子を導入したことによって、複数レベルの成功または失敗のサポートが可能な、はるかに動的な条件ワークフローが使用できるようになります。 評価演算子は、制御フロー エンジンが実行時に制約をどのように解釈すべきかを示します。 評価演算子として受け付けられる値は次のとおりです。

• 制約の値のみを評価する (DTSPEO_CONSTRAINT)

• 式の値のみを評価する (DTSPEO_EXPRESSION)

• 式の値と制約の値を評価する (DTSPEO_CONSTRAINTANDEXPRESSION)

• 式の値または制約の値を評価する (DSTPEO_CONSTRAINTOREXPRESSION)

評価演算子の設定に応じて上記のいずれかが評価され、結果が論理的な True になるかどうかが判定されます。

論理的な評価

制御フロー内の制約アーキテクチャとして確認する必要のある最後の拡張機能は、制約の論理的な "AND" 操作 (SQL Server 2000 の DTS と同じ) と論理的な "OR" 操作のサポートです。

下の図では、2 つの "失敗時" 制約は論理的に "AND" 操作されるように設定され、どちらも論理的に true でなければならないことを意味しています。 この構成の結果は、"正常なクエリ" は正常に実行され、"不正なクエリ" だけが失敗するため、

後続のタスクである "プロセスの実行" は実行されません。

上の例では、失敗を処理するタスク "プロセスの実行" を、どちらかの項目が失敗した場合に実行されるようにする方が適切です。 この制約を論理的な "OR" に変更すると、下に示すような結果が得られます。

コンテナ

制御フロー アーキテクチャの中で、"コンテナ" と呼ばれるコンポーネントは、タスクまたはタスク グループの基本レベルの親です。 コンテナは、特殊な機能をサポートすることもできますし、個々のタスクを囲むきわめて汎用のラッパーになることもできます。 コンテナは、エラーの最大数などのイベントの公開や集計を処理することや、コンテナ内のタスクの累積成功数に基づいて成功制約をトリガすることだけを目的にしています。 制御フロー環境内には、目に見えるコンテナが 3 種類、目に見えないコンテナが 1 種類存在します。

タスク ホスト

タスク ホストは、すべてのタスクに対する既定のコンテナです。 実際、各タスクには、常にタスク ホストが含まれます。 タスク ホストは目に見えないコンテナであり、設計環境内のホストする対象のタスクとシームレスに混在します。 タスク ホストは、基本プロパティで構成されるタスクへの基本的な環境の提供、インターフェイスのログ記録、ブレークポイントのサポート、および DTS ランタイム エンジンへの実行インターフェイスの提供の役割を果たします。

シーケンス コンテナ

シーケンス コンテナは、設計環境内の 3 つの目に見えるコンテナの中では最も汎用的です。 シーケンス コンテナは、表面的には、DTS パッケージ設計環境の制御フロー レイヤで利用できる、タスクのグループ化に似ています。 ただし、この表面上の類似点では、シーケンス コンテナによって提供される、タスクのカプセル化は表現されません。 シーケンス コンテナは、コンテナの "下位の" タスクの間で全体として単一の成功または失敗を表す 1 つまたは複数のタスクのコレクションを表します。 以前の DTS アーキテクチャに精通している人にとってみると、シーケンス コンテナは機能的に、SQL Server 2000 のパッケージ実行タスクを使用して実行された子 DTS パッケージに似ています。

For ループ コンテナ

For ループ コンテナは、"初期化式"、"評価式"、および "割り当て式" プロパティのエントリに基づいて、コンテナ自体の中に定義されたタスクまたはタスクのセットをループする機能を提供します。 タスクまたはタスクのセットをループするこの種の機能は、以前は、ワークフロー エンジンを制御する DTS の非標準の ActiveX スクリプトを使用して実装されていました。 この追加によって、DTS 環境内に重複した機能を構築するための機能が提供されます。 きわめて単純な For ループ コンテナの例を下の図に示します。

For Each ループ コンテナ

For ループ コンテナが基本的なループを実行するための基本的な機能を提供するのに対して、For Each ループ コンテナは、最も一般的なループ タスクを実行するための一層の使いやすさを提供します。 For Each ループ コンテナは、コレクション内の各オブジェクトをループする機能を提供します。 このコレクションは、列挙子を通して公開されます。 DTS では、次の 4 つの列挙子がサポートされています。

For Each File - 特定のファイル仕様に従う、ディレクトリ内のファイルを列挙します。

For Each Item - 特定の DTS 変数に対する、コレクション内のオブジェクトを列挙します。

For Each ADO - 特定の DTS 変数に含まれる、ADO.NET データセット内のテーブルおよび行オブジェクトを列挙します。

For Each SMO - デザイン時に定義されたサーバー、または実行時に DTS 変数で名前が指定されたサーバーのどちらかにある、SQL Server 管理インターフェイス オブジェクト (データベース、テーブル、ファイル グループ、その他) を列挙します。

コレクションがループされるとき、コレクション内のオブジェクトの値を、コンテナ内のタスクのプロパティに割り当てることができます。 この機能によって、カプセル化されたソリューションが提供されます。 これを使用すれば、多くのエンタープライズ レベル ETL アーキテクチャに見られる一般的な冗長性に対応できます。

変数

変数は、DTS の最初から、パッケージ内通信のための基本的な要素でした。 現在、変数は、SQL Server 2005 の DTS アーキテクチャの進化に対応できるだけの、さらに成熟した動作を行うことができます。

スコープ

従来は、グローバル変数という 1 種類の変数しか存在しませんでした。 現在は、ランタイム (システム)、パッケージ、シーケンス、またはタスクのスコープ (または有効期間) 内で変数を宣言する機能が存在します。 この柔軟性によって、値の寿命をより細かく制御する機能が提供され、さらに、値をきわめて限定されたオブジェクト参照の中で変化させることも可能になります。

完全修飾変数

変数を複数のオブジェクト コンテキスト内で定義する機能があると、変数を完全修飾名で参照することが必要になります。 たとえば、"System::PackageName" は、ランタイムの "System" 名前空間にある "PackageName" 変数を指します。 タスクまたはシーケンスに関連付けられたユーザー定義変数は、<User>::<VariableName> として定義されます。

プロパティの動的マッピング

SQL Server 2005 DTS 内の変数への大きな拡張機能として、変数 (および、その値) をパッケージのプロパティ内のオブジェクトに関連付ける、つまり "マップ" する機能があります。 このマッピングによって、特定の変数に対する値の更新を、この値に基づいてマップされたすべてのプロパティに連鎖するための非常に動的なメカニズムが提供されます。 下の図は、SQL 実行タスクの SQLStatement プロパティへの "SQLStatement" 変数の基本的なマッピングを示しています。

その他の機能

これまでに説明したすべての拡張機能に加えて、注目に値する変数のその他の機能があります。 その最初は、変数を "読み取り専用" として定義する機能です。 これによって、変数を、デザイン時には変更できるが、実行時には値を変更できない定数を超えるものとして使用できます。

アーキテクチャの高い成熟度を示す追加の機能に、変数の値の変更によってパッケージ レベルのイベントをトリガする機能のサポートがあります。 イベントについてはこのドキュメントの後の方でさらに詳しく説明しますが、イベントを変数の変更と結び付けることで、全体的なアーキテクチャに大きな機能が追加される点を理解する必要があります。 たとえば、変数の変更によって、他のいくつかの変数の値を、式や、クエリ結果などの外部のソースから再計算させることもできます。 これらの複数の変更がすべて、プロパティの動的マッピングによる場合は、非常に動的な、構成可能なパッケージが生成されます。

プログラミング性と拡張性

制御フローの標準の要素にはネイティブに提供されている多くの機能が存在しますが、同時に、制御フロー内には、比較的容易に実装できる "拡張性" のレイヤも "カスタム タスク" の形で存在します。 ただし、このドキュメントでは、この事実を深く究明することはできません。 カスタム タスクは、その名前が示すように、開発者によって定義され、制御フロー環境にプラグインすることが可能なタスクです。

プログラミング性と拡張性のトピックの深さを考慮した場合、このホワイトペーパーで指摘できるのは、この製品の DTS 機能セットの拡張機能としてカスタム タスクやカスタム変換を開発する機能が存在するという点だけです。

制御フローの例

このセクションでは、制御フローの要素をどのように実装すればよいかを示す実際の例に焦点を移します。

条件ワークフローの例

下の図は、条件ワークフローを提供する制御フローの機能の例を示しています。 この例では、ファイルを評価して、そのファイルが、ファイルのデータを完全に処理する 2 つのデータ フローのうちの 1 つに宛てられているかどうかを判定し、その後でパッケージが開始されています。 2 つの "成功時" 優先順位制約が定義されていますが、以前のリリースでは、これにより両方のデータ フロー タスクが実行されていた点に注意してください。 ここで、デザイン時の制御フローと、実行時の実行の詳細について確認してみましょう。

上の例の場合、ワークフローの条件式の構成をより詳細に見てみる必要があります。

上の式は、パッケージ内の変数の値の評価です。 この例では、読み込むファイルの種類が、クレンジングの必要があるのか (LoadType が 0)、または読み込む準備ができているのか (LoadType が 1) を判定します。 これらの各制約を共に "式" および "実行結果" 制約で起動できるようにするための第 2 の要素として、次の図に示す制約 "EvalOp" プロパティを調整します。

パッケージ内の @FileToLoad 変数の評価では、@LoadType は 0 であると判定されます。 実行時に条件実行がどのように表示されるかを見てみましょう。

この図は、"ファイルのクレンジング" タスクと "ファイルの読み込み" タスクの両方に "成功" の優先順位制約が設定されていたにもかかわらず、最終のワークフローでは式が決定的な役割を果たしたことを示しています。 この例は、条件ワークフローの新しい機能を表しており、DTS ランタイム エンジン全体にわたる変数と式の威力を示しています。

ループの例

前の例を拡張するために、ディレクトリ内の一連のファイルをループする機能を導入してみましょう。 下の図では、ソリューションは "ファイルのループ" という名前の Foreach ループ シーケンスを採用しています。

このループ タスクの構成を次の図に示します。

Foreach ループ コンテナを使用すると、"*.txt" のファイル フィルタに従う、"C:\" フォルダ内のすべての読み込みファイルを列挙できます。

これらの例は、一見、きわめて単純に見えるかもしれませんが、DTS の以前のリリースではどういう形で実現されたかを考えてみることが重要です。 その場合、必要になる要素には次のものがあります。

• ランタイム ファイル システム オブジェクトの自動スクリプト化を含む、カスタム ActiveX スクリプト タスク

• 条件実行ロジックのレプリケーションを試みる、ワークフロー ActiveX スクリプト内のカスタム ActiveX スクリプト タスク

• ループ機能を処理する DataPump の後続のタスクとしての、カスタム ActiveX スクリプト タスク

これらの ActiveX スクリプトの要件に加えて、構築を複雑にするその他の多くの要素が存在します (たとえば、標準で用意されている機能が少ないために必要になる、膨大な量のカスタム作業)。

データ フローの要素

制御フローがパッケージの機能的なワークフローの大部分の所有者であるのと同様に、データ フローは、データ移行プロセスの重要な抽出、変換、およびロード ルーチンを実行するための主要な手段です。

データ フロー処理のためのこの環境 (先に、パイプライン エンジンとして説明しました) は、機能的には SQL Server の以前のリリースにあったデータ ポンプ環境に関連しています。 以前のリリースと SQL Server 2005 の目的には類似点もありますが、データ フローは、超高性能な変換、集計、その他のデータ操作を連携した方法で開発できる、完全に新しい、総合的な環境です。

変換元

変換元項目は、データ フロー アーキテクチャの最初の変更された要素であり、通常、データ移行パッケージの開発で使用されます。 入門者を考慮して、変換元項目は、以前のリリースのような接続自体ではなく、接続マネージャに関連付けられています。 これによって、接続情報を、実行の複数のスレッドにわたって効率的に再利用できるようになります。 次の図は、パッケージのデータ ソース接続マネージャと変換元データ フロー項目の関係を示しています。

接続 "FlatFileToLoad" が、"フラット ファイル変換元" によって利用されています。 これにより、実行時に接続を変更し、"フラット ファイル変換元" 項目の変更に影響を与える機能が提供されています。 この機能のために、以前のリリースに比べて柔軟性が大幅に向上しています。

OLE DB 変換元

データ フロー項目の中で最も重要なのが、OLE DB 変換元項目です。 OLE DB 変換元は、いくつかあるうちの任意の OLE DB プロバイダへのアクセス ポイントを提供します。 これらのプロバイダは、マイクロソフトや、このアーキテクチャ内でのすべての種類の異種データ アクセスへの道を開いているサード パーティ ベンダから提供されています。 この変換元は、DTS アーキテクチャの新機能の多くを表しています。 OLE DB 変換元は、パッケージで定義されている任意の接続を指すための機能を提供し、ソリューションのデータ ソースを使用してパッケージ接続の上に構築された、基になるデータ ソース ビュー (先に説明しました) を認識しています。 下の図は、ソリューション内の "Pubs" データ ソース (および、パッケージ接続) に関連付けられている "タイトル ビュー" データ ソース ビューを選択するためのプロセスを示しています。

データ ソース ビューの選択を通して、テーブルのリストは、データ ソース ビューで定義されたものに制限されます。 また、ここで示されている機能に加えて、変換元データ フロー項目は、基になる接続上で定義されたクエリ以外からも起動できます。

ファイル ベースの変換元

データ移行ソリューションに含まれるすべてのデータが、OLE DB に準拠したデータ ソースから来るわけではありません。 場合によっては、その他のデータ取得プロセスによって提供される、フォーマットされたファイルや DTS 生ファイルからデータを取り出す必要があります。 このため、他の 2 つの変換元データ フロー項目が存在します。 これが、フラット ファイル変換元と生ファイル変換元です。

フラット ファイル変換元の構成はフラット ファイル接続上で発生し、一方、生ファイル変換元は DTS 生ファイルを直接指します。

DTS 生ファイル

DTS 生ファイルは、DTS のパイプライン操作によって生ファイル変換先に生成されたファイルです。 生ファイルの一般的な目的は、このドキュメントの後の方でさらに詳しく説明します。

変換先

データ フロー アーキテクチャ内には、データを供給する変換元と、データを受け付ける変換先の両方が存在します。 この点は、DTS の以前のリリースでの "テキスト ファイル変換先" 接続の存在と変わりません。 主な違いは、アーキテクチャ的に、現在ではすべての変換先がデータ フロー変換先項目を利用する必要がある点です。 データ フロー変換先項目は多数存在し、データを 1 つまたは複数の異種データ変換先に効率的に渡すための機能を提供しています。

OLE DB 変換先

OLE DB 変換先は、SQL Server 2005 DTS のデータ フロー アーキテクチャにある変換先の種類の 1 つです。 この変換先によって、OLE DB に準拠した変換先との接続が可能になります。

SQL Server 変換先

SQL Server 変換先は、SQL Server のネイティブな一括挿入機能を利用するように最適化された変換先です。 SQL Server 変換先の種類に対しては、[詳細] タブを通して、きわめて高度な制御が可能です。 このタブでは、SQL Server の一括挿入に関連したすべての機能についての具体的な詳細事項を設定できます。 下の図は、SQL Server 変換先項目の詳細なプロパティを示しています。

生ファイル変換先

生ファイル変換先は、データをネイティブな SQL Server 2005 DTS パイプライン データ フロー形式のファイルに保存するための手段を提供します。 生ファイル変換先では、出力形式を構成するためのプロパティが提供されます。 そのプロパティには次のものがあります。

AllowAppend - 既存のファイルへの追加を許可するかどうかを定義します。

ForceTruncate - 既存の生ファイルの内容を破棄するかどうかを定義します。

SizedStrings - 出力文字列のサイズに文字列の実際の長さを反映するか、または列内のすべての行を同じサイズで出力するかを決定します。

また、データの典型的なエンドポイント (通常は、テーブルまたはファイル) に加えて、SQL Server 2005 DTS では、さらに拡張された変換先も提供されます。

OLE DB コマンド変換先

OLE DB コマンド変換先は、OLE DB ターゲットのネイティブな言語で作成されたパラメータ化されたコマンドに従って、パイプラインを通してデータを流す機能を提供します。 これに比べると直感性には欠けますが、DTS の以前のリリースにあったデータ ドリブン クエリ タスクにも、コマンドを使用してデータを変換先にプッシュするための同様の方法が存在しました。

[入力列] タブでパラメータ プレースホルダ (一般には、疑問符記号 "?") を入力することによって、入力列をパラメータにマップできます。

このマッピングを次の図に示します。 ここで、SQLCommand プロパティの値は、"INSERT INTO titleauthor_temp VALUES (?,?,?,?)" です。

OLE DB コマンド変換先によって、利用するクエリ コマンドに対する無制限の可能性が提供されます。 ストアド プロシージャ、または条件付きの挿入、更新、および削除への呼び出しを、次に説明する変換と共に使用すれば、OLE DB コマンドを経由してデータを 1 つまたは複数の変換先に提供するための柔軟なメカニズムが生成されます。

レコードセット変換先

レコードセット変換先は、パイプライン データ ストリームの結果をレコードセットとして変数に格納する機能を提供します。 レコードセット変換先と SQL 実行タスクの [結果セット] タブの役割の主な違いは、パイプライン経由でこの変換先にプッシュされたデータには、そのデータがデータ パイプラインの一部であったにもかかわらず、多数の変換を通すことができる点にあります。

変換

変換元と変換先の間のパイプライン データ ストリーム内のデータに影響を与えるために使用できる変換には、きわめて多様な種類があります。 このドキュメントでは、変換を、データ フロー アーキテクチャ内の 3 つの基本的なカテゴリとして説明します。

データ変更の変換

データ変更の変換は、このドキュメントでの 1 つのカテゴリであり、データがパイプライン内にある間にデータを変更するか、またはデータに関する集計操作を実行する変換要素です。 これらの変換要素には次のものがあります。

集計

集計データ フロー変換では、データ ストリームからの入力データを、さまざまな集計グループ化のレベルで、複数の集計出力に集計できます。 次に示す各種の高性能な集計が利用できます。

• Sum

• Average

• Count

• CountDistinct

• Minimum

• 最大値

これらの集計の任意の組み合わせを、"GROUP BY" 列としてセットアップされた入力列と共に使用すると、1 つまたは複数の出力データ ストリームが提供されます。 これらの出力から、集計を消費し、各種の下流の変換先に提供することができます。 下の図は、集計変換から複数の出力を構成する例を示しています。

上の集計変換では、集計の 2 つのセットが "AvgQtySold" と "TotalSalesQty" という名前で定義されています。

文字コード表

文字コード表変換は、大文字小文字の変換、関連した言語の別の文字コードの利用 (たとえば、"ひらがな" から "カタカナ" へ)、Unicode バイト幅の文字変換の処理などの変換要件を処理します。 文字コード表変換では、入力列は削除されず、文字変換を補助的な出力または "ボルトオン" としてデータ ストリームに追加することができます。 追加の "文字コード表変換された" 列を新しい出力にしたくない場合は、代わりに、既存の列のデータに影響を与えるように変更できます。

文字コード表変換によって、データ ストリーム間の文字列変更の基本的な要件が解決されます。 また、この機能のサブセットは、DTS の以前のリリースにあったストック変換に似ています。

コピー/マップ

コピー/マップ変換は、下流での変更のために、パイプラインを入力列のコピーで拡張する機能を提供します。 この変換を使用すると、データ変換や照合といったそれ以降の変換で入力データの整合性を維持することができます。 あるいは、データに対してリレーショナル SQL DML ステートメントを実行する前の最後の変換として整合性を確保したい場合にも使用できます。

データ変換

データ変換の変換は、以前の DTS では提供されていなかった、列のデータ型を明示的に変換する機能を提供します。 明示的な変換を使用すると、データを実際に変換先に書き込む前に、そのデータが変換先のデータ型に "従っている" ことを確認できます。 現在では、変換プロセスに例外をプッシュするエラー出力によって、データを検証し、リダイレクトされた適切な経路を構築する機能が提供されています。

派生列

派生列変換は、その名前が示すように、1 つまたは複数の入力列に式を適用することによって新しい出力を構築する機能を提供します。 この変換を利用すると、以前のリリースにあった多くの変換機能が拡張されます。 以前のリリースにあったこの変換には、日付と時刻のフォーマットの実行、文字列のトリミング、部分文字列の情報などに使用される機能が含まれていました。 このリリースでは、これらの基本的な機能に加えて、値の連結、文字列量の解析、ドメイン データ検証の実行、その他多くの機能も提供されています。 これらの機能は作成される式によってのみ制限されるため、この変換は SQL Server 2005 DTS で最もよく使用される変換の 1 つになっています。

並べ替え

並べ替え変換は、パイプライン データ ストリーム内のデータを 1 つまたは複数の列によって昇順または降順で並べ換えるという、単純な機能を提供します。 並べ替え変換は、クラスタ化インデックスを含むテーブルを読み込む場合に有効です。

ピボット

ピボット変換は、ほぼ正規化されたパイプライン データ ストリームをピボット変換済み結果セットとして構築する機能を提供します。 このピボット変換済み結果セットは、1 つまたは複数の列に多くの行にわたる繰り返しの値があり、それが出力ではグループ見出しになることが特徴です。 下の表は、ピボット変換によってデータがどのように影響されるかの単純な例を示しています。

変換前のストリーム内のデータ

列名	状態	製品	量
データ コード	CA CA CA CA WA WA WA FL FL FL FL	ワイン ソーダ ミルク ビール ミルク ビール コーヒー ビール ソーダ ミルク オレンジ ジュース	25 60 100 82 30 24 42 120 92 59 44

変換の出力データ

変換元列	状態	量	量	量	量	量	量
列名	状態	ワイン	ソーダ	ミルク	ビール	オレンジ ジュース	コーヒー
データ コード	CA WA FL	25	60 92	100 30 59	82 24 120	44	42

逆ピボット

逆ピボット変換は、ピボット変換された状態のデータ入力を、より正規化に近い表現に変換する機能を提供します。 この変換は、ピボット変換された状態のデータを含む、レポートまたは分析ソリューションの結果のデータ ファイルを分解する場合に有効です。

データ収集と分散変換

条件分割

条件分割変換は、適合する条件に基づいて、データのリダイレクトを処理します。 これらの条件式は、データ フロー タスクや変換のスコープ内にある列の値または変数で起動できます。 多数の条件を定義することもできるため、パイプライン内にデータの下流の経路を複数設けることも可能になります。

条件分割の実環境の例としては、行または外部に影響する変数の値に基づいて、複数月分のデータを 1 か月または複数月分のパーティショニング テーブルに配信するような場合があります。

あいまいグループ化

あいまいグループ化変換は、入力キー値の数学的な評価に基づいて近似値を計算し、それによってデータの類似のグループを特定する "ファジー" 理論をベースにしています。

あいまいグループ化のロジックは、重複を解消する "de-dupe" プロセスのためにデータの整合性が維持されていないいくつかのシナリオで適用できます。 この 1 つの例として、組織の顧客ベースを評価して、"顧客マスタ" テーブル内の類似の重複エントリに基づいてどの顧客が同じかを特定するような場合があります。

あいまい照合

あいまい照合変換は、セカンダリ テーブル内の類似の一致データを見つけるという困難なタスクを処理します。 一般に、データ クレンジングの 1 つの要素として、ETL プロセスに入力されるデータに対して、ぴったり一致はしないが、確率の高い一致を検出できるかどうかという点があります。 あいまい照合は、概略的な照合を実行することによって、ユーザーが入力した文字列 (通常、外部キーになる) の不正確さの問題を克服する機能を提供します。

照合

照合変換は、DTS の以前のリリースにあった照合に似た機能を提供します。 機能的には似ていますが、アーキテクチャ的にはまったく異なった方法で実装されています。SQL Server 2005 DTS の新しい照合機能は、"照合された" 情報のデータ ストリームとの統合や、参照データのキャッシュをきめ細かく管理する機能などを提供します。

照合変換で提供される機能を使用すれば、リレーショナル コンテキスト内のデータを結合して変換またはデコードを実行するという要件をなくす大きな機会が生まれます。 照合変換は、ストリームを流れるデータとは別のデータ接続に対して実行できるため、データ ストアに入力される異種データを "標準化する" ための強力な環境が提供されます。

マルチキャスト

マルチキャスト変換は、1 つの着信データセットを複数の出力に分散する機能を実装します。 同じデータセットを 2 つ以上の変換先にプッシュする必要がある場合は、マルチキャストの利点が明らかになります。

マルチキャスト機能を、従来の OLE DB 変換先や DTS 生ファイル変換先と共に使用すると、最大の復旧可能性/信頼性を備えたシナリオが提供されます (このセクションの後の方で説明します)。

Union All

UNION ALL 変換は、Transact SQL の "UNION ALL" 構文と同様の動作をします。 UNION ALL 変換は、同じスキーマ属性の複数の入力を受け付け、すべての着信ストリームに含まれていたデータから成る、結合された単一のストリームを出力することができます。

UNION ALL 変換の利点は、複数の変換元 (たとえば、複数の店舗の POS システム) からデータ (たとえば、ファクト レコードの抽出) を入力するような場合に理解できます。

以上の一般的な変換に加えて、ビジネス インテリジェンスのシナリオでのリッチな ETL を促進するために設計された一連の変換も存在します。

マージ

マージ変換は、UNION ALL 変換に非常に似た機能を提供します。 "UNION ALL" 変換が 2 つのデータセットを順番に結合するのに対して、マージ変換は、出力を実際に並べ替えることで、指定されたクラスタリング方式に従ってテーブルに書き込むのに理想的なデータを生成します。

マージ結合

マージ結合変換は、SQL で 2 つのデータセットで実行されるのと同じ方法で JOIN を実行する機能を提供します。 マージ結合は、異種の変換元からのデータを結合し、非等価結合機能をサポートするための優れた方法です。

ビジネス インテリジェンス変換

SQL Server 2005 DTS アーキテクチャの変換には、ビジネス インテリジェンスのシナリオでのリッチな ETL を促進するために設計された一連の変換が存在します。 これらのビジネス インテリジェンス変換は、リレーショナル データ ウェアハウスの読み込み、OLAP 統合、変換プロセス中のデータ マイニングの統合などのニーズに対応します。

データ マイニングの統合

データ マイニングは、SQL Server 2005 DTS の機能セットの中でさらに重要な位置を占めるようになっています。 以前のリリースには少数のマイニング モデル機能しかありませんでしたが、SQL Server 2005 では、次の機能を実現する統合された変換が提供されます。

データ マイニング モデル精度変換 - マイニング モデルに学習されていないデータを供給することによって、以前に構築されたマイニング モデルの有効性を計測します。

データ マイニング モデル学習変換 - 入力ストリームで供給されるデータに基づいて、1 つまたは複数のマイニング モデルを学習させる機能を提供します。

データ マイニング クエリ変換 - 入力ストリームで供給されるデータに対して、1 つまたは複数の、予測指向のデータ マイニング クエリを実行する機能を提供します。

Analysis Services と OLAP 統合

DTS の各リリースでは、データ移行と OLAP 処理の間の統合を構築する機能が提供されて来ましたが、データ フローではこの機能が大幅に拡張されています。 現在では、パイプライン データ ストリームから、次の 2 つの非常にユニークな変換にリレーショナル データを直接プッシュすることが可能になっています。

ディメンション処理 - ディメンション処理変換は、リレーショナル データを OLAP データベース内のディメンションに流す機能を提供します。

パーティション処理 - パーティション処理は、ディメンション処理変換に似た機能を提供し、データを OLAP キューブのパーティションに流すことができます。

どちらの場合も、Analysis Services データ フロー項目はエンドポイント変換先の役割をより密接に満たしているため、これを単なる変換と見なすことが正しいとは言えません。 Analysis Services データ フロー項目をどのように特徴付けたとしても、読み込みプロセスが大きく拡張されたことによる実際の利点はきわめて明らかです。

リレーショナル データ ウェアハウジング

標準化されたリレーショナル ウェアハウジングのプロセスでは、徐々に変更可能なディメンションの管理ほど重要なタスクはありません。 一般に、徐々に変更可能なディメンションには、新しいレコードが作成され、レコードの以前のバージョンのヒストリが保持されている状態か、または、元のレコードが更新され、データが上書きされてすべてのヒストリ情報が破棄され状態かを判定するための多様なロジックが必要になります。

DTS 内の複雑さのこの要素を緩和するために、次の DTS 変換が用意されています。

徐々に変更可能なディメンション - 徐々に変更可能なディメンション変換は、ディメンション変更の管理方法に従って、複数の列レベル ストリームの出発点と見なすのが最適です。

ディメンション読み込みウィザード - ディメンション読み込みウィザードは、単一の変換というより、データ フロー内にある多数の変換から成る総合的なディメンション読み込み変換コレクションを構築するためのツールです。 ディメンション読み込みウィザードは、徐々に変更可能なディメンション変換を利用するために必要な要素を構築します。

データ フローの例

このセクションでは、データ フローの多くの要素をどのように利用すればよいかを示す実際の例に焦点を移します。

徐々に変更可能なディメンションを読み込むためのプロセスの例

リレーショナル データ ウェアハウジングで、一般的であり、通常は複合したプロセスになるのが、"徐々に変更可能なディメンション" の管理です。 タイプ II の徐々に変更可能なディメンションの読み込みは、読み込むレコードが既にディメンション テーブルにある以前のバージョンと同じか、まったく新しいレコードか、あるいは、既存のレコードの更新されたバージョンかを特定することが必要になるため、特に複雑です。 そのデータが既存のレコードの更新されたバージョンであれば、レコードの古いバージョンにもう最新のレコードではないことを示すマークを付け、古いレコードの有効期限を設定することが必要になります。 更新されたレコードは新しいレコードとして挿入され、レコードの現在のバージョンであることを示すフラグと、古いレコードの有効期限に等しい有効開始日が設定されます。

下の図は、このロジックが SQL Server 2005 DTS でどのように実装されるかを示しています。

ここで使用されているデータ フローの要素は、次のとおりです (図の数字に対応)。

1. ディメンションのリレーショナル ステージング テーブルを指している OLE DB 変換元。

2. 変更管理ロジックのほとんどを初期化し、複数の出力を提供する、徐々に変更可能なディメンション変換。

3. "新しいバージョン" 出力と "まったく新しいレコード" 出力の両方の結果を結合する UNION ALL 変換。

4. "もう最新ではない" レコードの有効期限を派生させる派生列変換。

5. "有効開始日" および "現在のレコード" フラグに新しい列を割り当てる派生列変換。

6. ディメンション レコードを挿入するための OLE DB 変換先。

7. パラメータ化された更新ステートメントを発行するための OLE DB コマンド変換先。

SQL Server 2005 DTS の前は、これと同じ種類の操作を行うために、DTS データ ポンプ、ActiveX スクリプト変換、大量の Transact SQL などの組み合わせを使用する必要がありました。 複合プロセスをきわめて単純な図で表すことができる機能は、DTS データ フロー内の各種の高機能な変換が持つ多くの利点のうちの 1 つですが、この出力を生成する徐々に変更可能なディメンション ウィザードではさらに機能が向上しています。

イベント処理の要素

SQL Server 2005 DTS アーキテクチャでは、イベントとイベント ハンドラの概念が拡張されています。 以前のリリースでは、パッケージ レベルのイベントにアクセスするには、Visual Basic または Visual C++ の環境でパッケージをプログラム的に実行する必要がありました。 現在、SQL Server 2005 DTS では、パッケージのイベント (実際には、パッケージのランタイム環境内にあるすべての実行可能なコンテナ タスクに対するイベント) はユーザー インターフェイスで公開され、しかも、各イベントには、複合ワーク フローを実装するための独自のイベント ハンドラ デザイン画面を設定できます。 DTS ランタイムで用意されているイベント ハンドラには次のものがあります。

• OnCustomEvent

• OnError

• OnExecStatusChanged

• OnNMProgress

• OnPostExecute

• OnPostValidate

• OnPreExecute

• OnPreValidate

• OnProgress

• OnQueryCancel

• OnTaskFailed

• OnVariableValueChanged

• OnWarning

多数のイベント ハンドラ (このすべては、SQL Server 2005 Books Online で詳細に説明されています) を備えるイベント アーキテクチャによって、パッケージまたはコンテナ全体にわたるエラー処理やレポートなどの、より簡略化され、一般化されたハンドラ ソリューションの開発が可能になります。 また、アーキテクチャ内のイベント モデルの幅も広がっているため、低レベルのイベントを処理する、より深いソリューションも開発できます。 これらの低レベルのソリューションは、制御フロー タスクまたはデータ フロー タスクのレベルで構築することができ、それによって ETL をきめ細かく制御できます。

エラー処理の要素

SQL Server 2005 のエラー処理は、DTS2000 に比べて格段に堅牢になっています。 DTS 2005 には、いくつかの新機能を使用して、多様な方法でエラーを管理する機能が含まれています。 エラーの種類、またはエラーが発生した時間や場所に基づいて、エラーを適切に処理または無視することができます。 DTS 2005 を使用すれば、開発者はロジック エラーとデータ エラーの両方を効果的に処理できます。

ロジック エラー

先に説明したように、DTS では "失敗時" の優先順位制約がサポートされており、タスクが失敗した場合は、エラーを処理する代わりのタスクに実行フローを図形的にルーティングすることができます。 また、制約の実行結果を "完了時" に変更することによって、発生するエラーを無視することもできます。 しかし、DTS 2000 では、この失敗が軽微で、回復可能であったとしても、パッケージは呼び出し元のアプリケーション (つまり、SQL エージェント) に失敗を報告します。

DTS 2005 では、ForceExecutionResult という新しいプロパティがサポートされており、設計者にはさらに高い柔軟性が提供されます。 このプロパティは、"なし"、"成功"、"失敗"、"完了" のいずれかに設定できます。 このプロパティを "成功" または "完了" に設定すると、実際の結果には関係なく、DTS がタスクを実行した後に常に成功を返すようにすることができます。

また、DTS は、データ フロー タスクを含む任意の制御フロー項目の OnError および OnTaskFailed イベントもトラップできます。 イベント ハンドラを使用すると、プロジェクトの設計を簡略化でき、イベント レベルの変数も利用できます。 必要に応じて、パッケージの OnError または OrTaskFailed にエラー ハンドラを 1 つだけ記述することも可能です。

データ エラー

DTS では、データ エラーまたはデータの矛盾を、データ フロー デザイナで直接処理することができます。 データ エラーの原因には、変換元データの不整合やプログラミング エラーなどいくつかありますが、DTS では、パッケージ エラーをトリガしないで、問題のデータを成功させるか、失敗させるか、またはリダイレクトすることができます。 また、インラインで修復して再処理したり、ディスクに保存して後で処理したりすることも可能です。 これらをすべて、データ フロー デザイナで設定できます。

たとえば、主キーまたは外部キーの制約に違反する行が挿入されるときは、その行をエラー テーブルにプッシュして後で処理することができます。

変換でエラー処理を有効にするには、エラー行を出力するための追加の変換先 (OLE DB、フラット ファイル、または生ファイル) を作成します。 変換のターゲットをクリックすると、"失敗時" 優先順位制約に似た、赤い矢印が表示されます。 この矢印を新しい変換先にドラッグすると、[エラーの配置] ダイアログが表示されます。

ここでは、重大なエラー (たとえば、PK 違反) と切り捨てのエラーの 2 種類のデータ エラーを自動的に処理できます。 これらのエラーは、成功させるか、失敗させるか、または代わりのターゲットにリダイレクトするかを選択できます。 上の例では、Col1、Col2、または Col3 に発生する任意の重大なエラーをエラー データ ソースに渡していますが、切り捨ては成功させるように設定しています。 下の表は、配置のオプションを示しています。

オプション	説明
失敗	任意のハード エラーにより、データ フロー タスク全体が失敗します。
成功	エラーが発生したかどうかには関係なく、データ フロー タスクは成功します。
リダイレクト	問題のあるデータ行は、データ エラー変換先にリダイレクトされます。

エラーの配置を (無視や、パッケージの失敗ではなく) 新しい変換先にプッシュするようにした場合は、エラーのマッピングを設定する必要があります。 エラー変換先の接続をダブルクリックし、エラー データのコピー先のテーブルを選択して、[マッピング] タブを選択します。 使用可能な入力列の一覧には、ErrorCode と ErrorColumn 2 つの列が追加されています。 これらの列には、変換に失敗した特定の行のエラー情報が格納され、この列がエラー テーブルにプッシュされます。

最後の手順は、変換先の "高速読み込み" プロパティを無効にすることです。 このプロパティが有効になっていると、DTS は行の挿入をバッチで処理しようとし、行レベルのエラーは取得できなくなります。 この設定はパフォーマンス的には明らかに不利ですが、目的がすべてのデータ エラーをリダイレクトすることにある以上、そうするだけの価値はあります。

ログ記録と監査の要素

DTS 2005 のログ記録は大幅に変更され、はるかにきめ細かいログ記録機能がサポートされるようになっています。 以前と同様、DTS ではパッケージ レベルとタスク レベルのログ記録がサポートされていますが、現在では、設計者が各タスクやパッケージに対して異なるログ記録オプションを定義できます。 また、新しいログ記録では、タスクまたはパッケージの各イベントに対するログ エントリの作成もサポートされています。 つまり、タスクがエラーや警告をスローするか、または変数の値が変化するたびに情報をログに記録するように選択できます。

パッケージのログ記録を有効にするには、制御フロー デザイナを右クリックして [ログ記録] を選択するか、または DTS デザイナのメニューから [ログ記録] を選択します。 既定では、ログ記録は有効になっていないため、構成を開始するにはパッケージのレベルで少なくとも 1 つのプロバイダを追加する必要があります。 下の例では、パッケージに対して 3 つのプロバイダが有効になっています。

ログ記録を有効にした後、特定のタスクのログ記録を選択し、そのログ記録の詳細を構成することができます。 [ログ記録の詳細] タブには、[詳細] というラベルの付いたボタンがあります。 このボタンをクリックすると、ログに記録できる属性の完全な一覧が表示されます。

タスクのレベルでは、次のイベントをログに記録できます。

• PreExecute

• PostExecute

• PreValidate

• PostValidate

• Warning

• Error

• TaskFailed

• Progress

• QueryCancel

• ExecStatusChanged

• VariableValueChanged

• CustomEvent

これらの各イベントに対して、DTS では、テキスト ファイル、SQL プロファイラ、SQL Server、Windows イベント ログ、および XML ファイルの 5 つのすべてのログ記録方法 (つまり、プロバイダ) がサポートされています。

ログに記録するタスクとイベントを決定したら、次は、ログにキャプチャする属性を選択できます。 これらの属性には次のものがあります。

• EventDate

• Computer

• Operator

• SourceName

• SourceGUID

• ExecutionGUID

• MessageText

• StartTime

• EndTime

• ElapsedTime

• DataCode

• DataBytes

このように、パッケージ内で構成できる組み合わせの数は、文字どおり数千種類に上ります。 希望のログ記録オプションを構成したら、それを外部ファイルに保存したり、逆に外部ファイルから読み込んだりすることができます。 これにより、開発、QA、および運用の各環境のニーズが異なる場合は、それぞれに対して異なるログ記録を構成できます。

最後に、DTS では、カスタム ログ記録プロバイダの作成がサポートされているため、実際のニーズを満たす独自のプロバイダを開発することができます。

信頼性の要素

SQL Server 2005 アーキテクチャには、DTS ユーザーが構築するソリューションを、カスタムの開発を減らして "そのままで" より信頼性の高いものにするためのいくつかの要素が導入されています。 確かに、SQL Server 2005 DTS アーキテクチャに含まれているエラー処理、監査、およびログ記録の機能は、ソリューションの機能を理解するための多くのリソースを提供し、問題が存在する可能性のある場所を特定するのに役立ちます。 しかし、問題を理解すること自体が、直接信頼性につながるわけではありません。 これらの要素では、失敗したプロセスを継続して、ダウン時間の最小化と、DTS ソリューション経由で配信されている情報の可用性の最大化をはかるような、ETL ソリューションの動的な復旧はサポートされていません。

そのため、DTS アーキテクチャには、全体的な信頼性につながる、豊富な新機能や拡張機能が導入されています。

データの信頼性

一般に、全体的な ETL 設計で最後に問題になるのは、「ソリューションは、ETL プロセスの途中のデータ エラーまたは環境エラーからどのように復旧できるか」という点です。 DTS の以前のリリースで開発されたほとんどのソリューションでは、失敗したプロセスの途中のデータを復旧できるようにするために、データを中間テキスト ファイルまたはカスタム ログ記録に保存したり、問題が解決された後で一定レベルの再起動機能を実現するために、運用 DTS パッケージをカスタムで変更して "1 回限りの" 復旧ソリューションを生成したりする必要がありました。 この面倒な復旧プロセスは、人為的ミスが入り込む余地を残し、復旧を試みた場合の信頼性が高いデータ フローの開発には役立ちませんでした。

これらの問題に、多様な環境上の問題も加わり、運用時の読み込みの最終段階のデータは、プロセスが正常に実行されている間は信頼性を保持できましたが、運用上の課題を克服するための特別なステップを実行するとその信頼性は格段に低下しました。

接続の管理

このドキュメントの最初の方では、接続 (パッケージのために構築された接続、またはソリューションのためのデータ ソース上の接続) と、アーキテクチャ的に "接続マネージャ" と呼ばれるものとの違いについて、アーキテクチャの観点からの詳しい説明は行いませんでした。 接続マネージャは、パッケージのランタイム環境内で接続がどのように作成、消費、および破棄されるかを管理し、それによって、複数の接続が消費されるかどうか、あるいは接続プールが維持されるかどうかを決定する役割を果たします。

これらの要因はすべて、データの信頼性の基本的な要素につながります。 以前のリリースでは、接続プロバイダ (OLE DB または ODBC) が自分自身を適切にクリーンアップしていなければ、パッケージ全体にわたって利用される接続は悲惨な結果に陥る可能性があります。 現在では、接続マネージャが導入されているため、接続、特に、通知の失敗のより信頼性の高い管理が達成されます。

これらの要因のために、以前のリリースでのワークフローの無条件の継続 (つまり、"完了時" 優先順位制約) によって、予期しないデータ パスが生成される可能性がありました。 接続マネージャを使用すると、この同じパスは "そのままで" はるかに強固なものになります。 接続マネージャによって、接続エラーのない、より信頼性に優れたアーキテクチャが実現されます。

マルチキャスト変換

マルチキャスト変換については先に説明しましたが、この変換が、データの信頼性にも効果があることに注意する必要があります。 DTS の開発者は、マルチキャスト変換を使用して、データを複数の変換先に出力することができます。 これを重要な場面で使用すると、データ フローの処理時間を大幅に節約できる場合があります。 データを主要なエンドポイント (たとえば、SQL Server OLE DB 変換先) と、条件付きの二次的な変換先の両方に "マルチキャストする" ことによって、主要な変換先でディスク領域の不足やデータ接続の損失、その他の運用上/環境上の問題が発生した場合に、二次的な変換先からデータを復旧することが可能になります。

DTS 生変換先

DTS 生変換先は、マルチキャスト変換からの二次的なエンドポイントとして有効なオプションです。 先に説明したように、DTS 生変換先は、データ フローのパイプライン データ ストリームを保存するためのメカニズムであり、これを使用することによって、変換途中の特定の時点でのみ使用可能であった元のデータに戻すことが可能になるため、信頼性が向上します。

"時間を指定した" データ ソースの 1 つの例が、POS システムまたは注文管理システムからリアルタイムに更新される、組織の在庫システムです。 失敗のために ETL プロセスが失われると、何らかの種類の保存がされていなければ、その失敗の前にストリームに入力されたデータは失われます。 DTS 生形式に保存することによって、パイプライン内で発生したすべてのデータを確実に再キャプチャできます。

プロセスの信頼性

現在、全体的な DTS アーキテクチャの 1 つの要素として、データに関連しないプロセス (基本的には、DTS アーキテクチャ内の 1 つおきの実行可能ファイル) の信頼性を確保するための機能があります。

チェックポイント

DTS 2005 では、パッケージの状態を保存する "チェックポイント"、つまり論理的な停止ポイントの概念が導入されています。 また、この "チェックポイント" のプロセスを通して、論理的な復旧ポイントも作成されます。 これによって、失敗のポイントか、または失敗の前の制御フロー内の最も妥当な場所での、失敗したソリューションの信頼性の高い再起動が可能になります。

DTS 2005 では、パッケージ レベルと制御フロー コンテナ (シーケンスまたはタスク) レベルのプロパティの組み合わせを使用してチェックポイントを有効にします。 チェックポイントを記録するためのプロパティには、次のものがあります。

SaveCheckpoints - パッケージに対してチェックポイント機能が有効になっているかどうかを示す、パッケージ レベルのプロパティです。

CheckpointFileName - どの時点のチェックポイント情報を XML 形式に保存するかを示す、パッケージ レベルのプロパティです。

FailPackageOnFailure - タスクに対してチェックポイントが必要な場合は、タスクのレベルでこのプロパティを true に設定する必要があります。

FailParentOnFailure - シーケンス全体をチェックポイントと見なすようにするには、コンテナのレベル (つまり、関連するタスクから成るシーケンス) で、タスク レベルの "FailPackageOnFailure" 設定の代わりにこのプロパティを設定する必要があります。

CheckpointUsage

"checkpointusage" プロパティは、失敗の後でパッケージが再起動されたときに、チェックポイント ファイルをどのように使用するかを定義します。 このプロパティを使用する場合の一般的な設定は、"IfExists" 値です。 この場合、チェックポイント ファイルが存在すれば、パッケージはこのファイルを使用して以前の実行を再開します。

信頼性の例

このセクションでは、信頼性の要素をどのように利用すればよいかを示す実際の例に焦点を移します。

データの信頼性の例

下の例では、データの信頼性を獲得する機能が、次の 2 つに絞られています。 最初の機能は、データ フロー内の 2 か所にあるマルチキャスト変換です。 マルチキャストによって、パイプライン上の各ポイントで、変換されたデータを次のステップに進む前にディスクに保存できるようになります。

赤い線で示した、要素の 2 番目のセットが、生ファイル変換先アダプタです。 これらのアダプタによって、"生ファイル変換先" への書き込みで "派生列" 変換と "照合" 変換を保持することができます。 パイプラインのさらに下流には、"データ変換" と "集計" の操作を同時に実行したデータを "SQL Server 変換先" へのデータの書き込みを使用して保存する機能が存在します。

開発とテスト

デバッグ

DTS パッケージを作成し、ビルド エラーをすべて解決した後は、潜在的なロジック エラーまたはデータ エラーの対応に進むことができます。 この作業は、Visual Studio のデバッグ機能を使用して、どちらの "ワークベンチ" からでも直接実行できます。 これらの機能を使用すれば、タスクまたはイベントへのブレークポイントの設定、変数のチェックまたは変更、呼び出し履歴の検証、複数のプロジェクトや言語 (SQL ストアド プロシージャを含む) にわたるデバッグ、パッケージの徹底的な調査などが可能になります。

デバッグ ツールでは、手順を追ったデバッグ、ブレークポイント、およびスクリプト デバッグがサポートされています。 変換が実行されている間のデータ (変換の前または後) の表示または変更が可能です。 また、データ ソースからサンプル データを表示したり、データ値を挿入したりすることもできます。

ブレークポイント

開発環境では、任意のタスクのイベントについてのブレークポイントがサポートされています。 新しいブレークポイントを設定するには、対象のタスクを右クリックし、[ブレークポイントの編集] を選択します。 ブレークポイントは、最初の発生で停止するようにも、指定された実行回数の後で停止するようにも構成できます。 下の例では、実行は OnPreExecute イベントの発生回数が 2 に等しくなった場合のみ停止します。

まとめ

SQL Server 2005 の DTS は、以前の 2 つのリリースを合わせたよりも多くの機能を提供します。 製品がこのような幅と深さを持っているため、特に、多数の新機能を目の当たりにした場合は往々にして、最適なパッケージを構築するには、古い設計パターンを再考し、忘れ去らなければならないという感覚に圧倒されがちになります。

現実には、ただ 1 つの最善の方法というものはもはや存在しません。 DTS は、妥当な方法で作業を遂行するための十分な機能を提供します。 製品が進化するにつれて、新しい機能が明らかになり、こうした圧倒される感覚がよみがえる可能性があります。 重要な点は、より "コード中心" ではない設計を実現し、また、より "ワークフロー リッチ" で "使いやすい" アーキテクチャを実現することを望んでいるのであれば、DTS について常により多くのことを習得でき、そういう感覚を払拭できるということを忘れないでいることです。

DTS は、提供する機能の深さと幅によって類似ツールの市場を再構築する可能性を秘めた、エンタープライズ級の ETL ツールに進化しています。 このホワイトペーパーで説明されている機能は、SQL Server 2005 のこの部分の構成を初めて示し、読者を新しい機能に導くために、意図的に導入向けになっています。 しかし、これらはすべて、走る前の歩みとして位置付けられます。 つまり、将来の成功のために、知識の中核となる本体を構築していると考えてください。

製品が進化するにつれ、それを使用してより多くのことを実現する機能も進化していきます。 掘り下げて調査し、構築し、制限を押し出してください。 DTS が公開に向けて準備できたときには、読者の準備もできているはずです。

このドキュメントで説明されている機能と計画は、SQL Server の次のバージョンの現在の方向性を示しています。 これらの機能と計画はこの製品の仕様ではなく、また、変更されることもあります。 黙示されているかどうかにかかわらず、これらの機能が最終の製品リリースに含まれる保証はありません。

このドキュメントでは、いくつかの機能について、読者が SQL Server 2000 の機能とサービスに精通していることを前提にしています。 SQL Server の機能とサービスに関する基礎的な情報については、公式の製品 Web サイト http://www.microsoft.com/japan/sql/、または Microsoft Press から入手可能な SQL Server 2000 リソース キットを参照してください。

免責条項

このドキュメントは製品仕様ではありません。

本書に記載された情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。 Microsoftは絶えず変化する市場に対応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、情報の信憑性については保証できません。 本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。

このドキュメントは、最終版ドキュメントの初期リリースであり、その内容は製品リリース前に大幅に変更される場合があります。これは Microsoft Corporation が所有する機密情報です。 受取人と Microsoft の間で結ばれた機密保持契約に従って開示されます。 本書の情報は、URL や他のインターネット Web サイト参照を含めて、予告なく変更されることがあります。 このドキュメントの使用に伴うリスクや結果は全て、使用するユーザーの責任となります。 特に断りのない限り、本書に例示したすべての会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、およびイベントは架空のもので、実在の会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、あるいはイベントとは一切無関係です。 すべての当該著作権法を遵守することはユーザーの責務です。 Microsoftの書面による明示的な許可なく、本書の一部または全部について、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段（電子的、機械的、複写、レコーディング、その他）、および目的を問わず、禁じられています。これらは著作権保護された権利を制限するものではありません。

Microsoft Corporation は、本書の内容を保護する特許または特許申請中のアプリケーション、商標、著作権、またはその他の知的所有権を保有している場合があります。 Microsoft から書面による明示的な使用許諾契約書が供給される場合を除き、本書の提供はこれらの特許、商標、著作権、またはその他の知的財産へのライセンスを与えるものではありません。

Microsoft は、このドキュメントで言及された仕様、およびこれらの仕様に基づいて開発されたすべての製品または品目に関する一切の説明および保証を行いません。 Microsoft は、商品性の保証や特定目的の適合性、侵害からの免除などに限らず、明示的または暗示的ないかなる保証も与えるものではありません。 上述の一般原則を制限することなく、Microsoft はこれらの仕様またはその任意の一部に基づいて開発されたあらゆる種類のあらゆる品目に対して一切の保証を行いません。また、あらゆる著作権、特許、企業秘密、その他あらゆる国家のいずれの個人または企業体の知的所有権を侵害することはありません。 適切な場合において、そうした知的所有権のライセンスを求めることはその方自身の責任です。 Microsoft は、利益損失、事業の中断、その他任意の損害などを含め、これらの仕様の利用に起因または関連するいかなる損害についても一切責任を負いません。 州によっては、重大または付随的な損害に対する責任の排除または制限を許していないところがあり、上記の内容は該当しないことがあります。

Active Directory、ClearType、Direct3D、DirectDraw、DirectInput、DirectMusic、DirectShow、DirectSound、DirectX、DirectVA、Exchange、IntelliMirror、Internet Explorer、Microsoft、Microsoft Word、MS-DOS、NetMeeting、Office、Office XP、Paint、SharePoint、SQL Server、Visual Basic、Win32、Win64、Windows、Windows 95、Windows 98、Windows Millennium Edition、Windows 2000、Windows NT、Windows XP、および Windows .NET Server ファミリ (Windows .NET Standard Server、Windows .NET Enterrpise Server、Windows .NET Datacenter Server、Windows .NET Web Server) は米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、各社の商標または登録商標です。

© 2003 Microsoft Corporation. All rights reserved.