Database Development: Introducing New Features In The VSTS Database Edition GDR

[アーティクル]
06/10/2015

データベース開発

VSTS Database Edition GDR の新機能について

Jamie Laflen および Barclay Hill

この記事では、次の内容について説明します。

オフラインスキーマ開発
製品アーキテクチャの変更点
サーバープロジェクトの導入
SQL CLR プロジェクトのサポート

この記事では、次のテクノロジを使用しています。
VSTS 2008 Database Edition GDR

オフラインスキーマ開発
データベース管理
製品アーキテクチャの変更点
サーバープロジェクトの導入
サーバープロジェクトの参照
共有サーバーレベルオブジェクトを参照する
システムオブジェクトを参照する
プロジェクトのアップグレード
新しいデータベースプロジェクトのビルドと配置
VSDBCmd コマンドライン機能
SQL CLR プロジェクトのサポート
スタティックコード分析の機能強化
ヒントと秘訣

2008 年 11 月、Microsoft Visual Studio Team System 2008 (VSTS) Database Edition の一般配布版 (GDR) がリリースされました。GDR は VSTS 2008 Database Edition の初期リリースに上書きする形でインストールされますが、マイナーバージョン以上のアップグレードです。GDR では、SQL Server 2008 のサポートが追加され、既存の機能も強化されています。また、多くの新機能や拡張ポイントが追加され、それまでは Power Tool としてリリースされていた機能も組み込まれました。

この記事では、オフラインスキーマ開発のサポート、データベーススキーマの開発時に使用可能な新しいプロセスをサポートするツール、データベース管理をサポートする機能など、GDR の新機能を重点的に説明します。

これらのプロセスの機能強化に加えて、VSTS Database Edition の GDR には以下の機能があります。

プロジェクトのスキーマと依存関係の解釈および評価。オフライン処理により、配置の前に構文エラーや参照エラーを捕捉できます。
リファクタリング。VSTS Database Edition では、オブジェクト (テーブルや列など) の名前を変更すると、その新しい名前に対するすべての参照が更新されるようにすることができます。
自動差分エンジン。プロジェクトの配置時に、ターゲットデータベースをソースと照合するために必要な変更のみを格納する Transact-SQL (T-SQL) スクリプトを生成します。
データベースの単体テスト。デザイナを使用して T-SQL 指向のテストを開発し、コードをチェックインする前にスキーマを実行して検証することができます。
テストデータの生成。このツールで擬似乱数の実用的なテストデータを生成して、単体テストの実行時に使用できます。

これらの機能について説明し、その動作を示す実践的な例を紹介します。

オフラインスキーマ開発

これまでのデータベーススキーマ開発では、共有開発サーバーに対するコードを作成し、変更を別の環境に移行するための更新スクリプトを作成する必要がありました。この方法にはデータベースオブジェクトの変更を追跡およびマージする手段が欠けているため、環境間の変更の移行を手動で処理することになります。

VSTS Database Edition では、スキーマを構成するオブジェクト (テーブル、ストアドプロシージャ、ビューなど) は Visual Studio データベースプロジェクト内で CREATE スクリプトとして管理されます。これらのオブジェクトをスクリプトとして保存すると、スクリプトをソースコード管理システムで管理できるようになります。これにより、スクリプトを複数のデータベース開発者が同時に編集し、変更のチェックイン時に必要に応じて結合することができます。データベースに接続せずにスクリプトファイルを編集するプロセスをオフラインスキーマ開発と呼びます。データベースの定義をライブデータベースからオフライン環境またはモデル環境に移動すると、アジャイルまたは反復型の開発手法を適用してアプリケーション開発を効率化し、コストを削減することができます。

オフライン開発では、まず、Visual Studio でデータベースプロジェクトを作成し、現在の開発データベースをプロジェクトにインポートします。インポートしたプロジェクトで警告が発生する場合がありますが、警告に対処し、ビルドが成功した後で、プロジェクトをソースコード管理システムにチェックインすることができます。

プロジェクトとソースコードのチェックインが完了すると、チームの各開発者はそのプロジェクトおよびソースコードを取得し、ローカルコンピュータで処理できます。これで、変更をローカルのサンドボックスデータベースに配置し、手動でテストできるようになりました。この方法では、各開発者が分離された環境で作業できるので、共有データベース環境に不安定さを持ち込まずに済みます。この方法を応用し、1 つまたは複数のデータベース単体テストを作成して変更を検証することもできます。変更の検証が完了したら、サンドボックスデータベースに対してすべての単体テストを実行して変更後のコードを検証し、その変更が他のコードを損なっていないことを確認します。テストが成功したら、変更をソースコード管理システムにチェックインします。

変更のチェックインとチームの準備が完了したら、ソースコード管理システムからソースを取得してビルドを実行することができます。ビルドの完了後、新規に開発された製品をユーザーが操作する環境にデータベースとアプリケーションコードを配置できます。

データベース管理

VSTS Database Edition にはデータベース管理の一般的な作業を効率化するツールが用意されています。そのツールの 1 つであるスキーマ比較は、スキーマの比較と更新の作業を自動化します。スキーマ比較を使用して、2 つのデータベースを比較し、ターゲットデータベース内でオブジェクトの作成、変更、削除を行う更新スクリプトを生成できます。通常の配置プロセスの外部にあるライブデータベースに対して直接変更を加える必要がある場合、スキーマ比較を使用してデータベースをオフラインデータベースプロジェクトと比較し、ソースコード管理にチェックインするデータベースプロジェクトに更新をインポートして反映します。

GDR のスキーマ比較ツールにはさまざまな新機能があります。特に、使用セッション間で比較の設定およびオプションを保存する機能は注目に値します (保存されるのはオプションと設定のみで、比較の結果は保存されません)。

設定およびオプションの保存機能では、プロジェクトシステムに .scmp ファイルという新しいファイルの種類が導入されています。このファイルは既定でプロジェクトシステムのスキーマ比較フォルダに保存されます。プロジェクト内に複数のスキーマ比較ファイルを作成し、保存することができます。スキーマ比較の設定をデータベースプロジェクト以外のファイルに保存し、使用頻度の高い比較設定を保持してトラブルシューティングなどの運用目的に利用することもできます。

スキーマ比較に、[スキーマ比較] ツールバーから表示可能なセッションレベルのオプション設定が追加されました (図 1 を参照)。オブジェクトをフィルタ処理して特定のオブジェクトの種類を比較対象から除外できます。プロジェクトに定義した SQLCMD 変数の値を置き換えて比較することができます。また、更新スクリプトの作成方法を制御するスクリプトオプションを定義できます。これらのオプションはすべて .scmp ファイルに保存できます。

図 1 スキーマ比較のオプション

[スキーマ比較] ツールバーを使用して、比較したスキーマ間の相違点を容易に確認できます。相違の種類をフィルタ処理して、新規オブジェクト、欠落しているオブジェクト、相違点のあるオブジェクト、同等のオブジェクト、またはこれらの種類の組み合わせを表示することができます。スキーマ比較は .dbschema ファイルの比較もサポートしています。プロジェクト、データベース、.dbschema ファイルを任意に組み合わせて比較できるようになりました。ターゲットが .dbschema ファイルの場合、このリリースでは更新を作成できませんが、その他のすべての組み合わせについては、比較とターゲットに対する更新の作成の両方をサポートしています。

VSTS Database Edition には、2 つのデータベースシステムのデータ比較を簡素化するツールもあります。データ比較を使用して、管理者は、主キーまたは一意キーを持つテーブルを比較し、2 つのシステム間の欠落しているデータ、余分なデータ、相違点のあるデータを検出できます。スキーマ比較と同様、データ比較でも、更新をターゲットシステムに直接書き込み、ターゲットシステムのデータをソースシステムのデータと一致させるスクリプトを生成できます。

製品アーキテクチャの変更点

GDR では、いくつかの重要なアーキテクチャの変更が行われています。特に重要な変更点は、SQL Server データベースの実モデル表現です。

VSTS Database Edition の以前のバージョンでは、SQL Server 2005 のデザインインスタンスが必要でした。プロジェクトシステムで、データベースプロジェクトのデータ定義言語 (DDL) スクリプトの最終的な検証ステップとしてデザインインスタンスを使用していました。この場合、SQL Server のインスタンスを各開発者がデスクトップ上でローカルに実行するか、データベースのオフライン表現を構築するためのコンピュータを別途用意する必要があります。

GDR では、デザインインスタンスは不要になり、プロジェクトシステムはデータベーススキーマの完全なモデル化表現によってサポートされています。SQL Server データベースを表現するモデルはデータベースプロジェクト内の DDL スクリプトから作成され、そのモデルは Visual Studio で使用可能なすべてのデータベースツールで利用できます。データベースプロジェクトを作成すると、.dbschema ファイルが生成されます。このファイルはモデルのシリアル化された XML 表現です。データベースプロジェクトを配置すると、プロジェクトのビルド出力とターゲットデータベースから作成したモデルとの比較に基づいて配置スクリプトが生成されます。

プロジェクトの使用セッション間では、データベースプロジェクトのモデルはプロジェクトのルートディレクトリ配下の .dbml ファイルに保存されます。.dbml ファイルはモデルのキャッシュを使用して、スキーマサイズが大きい既存データベースプロジェクトを開く処理およびビルドする処理を高速化します。

モデルはデータベーススキーマプロバイダ (DSP) によって実装されます。GDR には、以前のバージョンと同様、SQL Server のサポート対象バージョン (SQL Server 2000、SQL Server 2005、SQL Server 2008) ごとに 1 つずつ、合計 3 つの DSP が含まれています。プロバイダベースのモデルでは、VSTS Database Edition のリリースは SQL Server のリリースから切り離されました。SQL Server の新しいバージョンがリリースされたとき、またはサービスパックで既存のバージョンを新しい機能または構文に更新したときに、新しい DSP または更新された DSP をリリースして、これらの変更を SQL Server の機能でサポートすることができます。Visual Studio Team System の将来のリリースでは、このプロバイダベースのモデルを使用して、サードパーティが VSTS Database Edition のプロジェクト環境を他のデータベースプラットフォームで拡張サポートできるようになります。

サーバープロジェクトの導入

GDR の新機能、サーバープロジェクトを使用して、チームはスタンドアロンプロジェクトに SQL Server データベースのサーバーレベルの構成を定義できます。サーバープロジェクトの主な役割は、目的の構成およびオブジェクトをデータベースプロジェクト間で共有することです。サーバープロジェクトを複数のデータベースプロジェクトで参照する場合にサーバーオブジェクト定義を複製する必要はありません。たとえば、それぞれがターゲットサーバー上のユーザーデータベースを表す 3 つのデータベースプロジェクトがあるとします。各データベースプロジェクトに同じサーバープロジェクトへの参照を使用して、ターゲットデータベースサーバーの構成の整合性を確保する必要があります。

配置時にはサーバープロジェクトに定義されたサーバー構成の設定を使用して検証を行いますが、サーバー構成が実際に配置時に変更されるわけではありません。配置時に、サーバーの構成がサーバープロジェクトに指定された目的の構成と一致しているかどうかが確認されます。サーバープロジェクトに指定された構成の検証が失敗した場合、配置は失敗し、共有サーバーレベルオブジェクトまたはユーザーデータベースは変更されません。

サーバープロジェクトのサーバー設定を構成するには、サーバープロジェクトの Properties フォルダにある Server.sqlsettings ファイルを変更します (個々のサーバー設定の詳細については、ご使用のバージョンの SQL Server の SQL Server オンラインブックを参照してください)。サーバー設定の例を図 2 に示します。

図 2 サーバープロジェクトのサーバー設定例

既定では、配置時にサーバー設定の検証は行われません。配置時に設定が検証されるようにするには、[確認] チェックボックスをオンにして、[値] 列に値を設定します。

サーバープロジェクトの参照

サーバーレベルオブジェクトを参照するデータベースプロジェクト内のオブジェクトには、サーバーレベルのオブジェクトを定義する必要があります。サーバーレベルオブジェクトをサーバープロジェクト内でモデル化すると、そのオブジェクトをデータベースプロジェクトから参照できるようになります。たとえば、データベースプロジェクトにユーザーのログインを定義する場合、サーバープロジェクトを作成し、データベースプロジェクトのユーザーに必要なサーバーレベルのログインをモデル化する必要があります。システムオブジェクトのみを使用し、共有サーバーレベルオブジェクトを使用しない場合は、GDR と共にインストールされている master.dbschema ファイルに参照を追加するだけで済みます。

共有サーバーレベルオブジェクトを参照する

サーバープロジェクトは共有サーバーレベルオブジェクトのモデリングをサポートしています。共有サーバーレベルオブジェクトは、ユーザーデータベースレベルオブジェクトとは動作やスコープが異なります。データベースプロジェクトのオブジェクトによる無効なサーバーレベルオブジェクト参照にはフラグが設定され、サーバープロジェクトが特定されて、未解決の個々の参照がエラーまたは警告によって示されます。

共有サーバーレベルオブジェクトの一般的な例にログインがあります。データベースプロジェクトにユーザーオブジェクトを定義する場合、サーバープロジェクトでログインオブジェクトを参照することによって、複数のユーザーデータベースに同じログインを使用できます。ログインを参照するデータベースプロジェクトにユーザーオブジェクトを定義した場合、ログインが存在するサーバープロジェクトにデータベースの参照を設定し、ユーザーオブジェクトがデータベースプロジェクトで完全に解決されるようにする必要があります。そうしないと、図 3 のような検証エラーが返されます。

図 3 検証エラーの例

サーバープロジェクトでオブジェクトを参照するには、まず、マスタデータベースを表すサーバープロジェクトを作成します。サーバープロジェクトは、[新しいプロジェクト] ダイアログボックスの [データベースプロジェクト] ノードにあるサーバープロジェクトテンプレートから作成します。3 つのサーバープロジェクトテンプレート (SQL Server のサポート対象バージョンごとに 1 つずつ) があります。ターゲットサーバーが既に存在する場合、ターゲットサーバーのマスタデータベースを新しいサーバープロジェクトにインポートすることができます。サーバー内のすべてのユーザー定義オブジェクトがインポートされます。次に、サーバープロジェクトを作成して問題がないことを確認し、サーバーをモデル化する .dbschema ファイルを作成します。

データベースプロジェクトで、新しいデータベースの参照を設定してサーバープロジェクトを参照します。次の例では、サーバープロジェクト (MyServer) とデータベースプロジェクト (MyDatabase) を同じソリューションで使用します。ソリューションエクスプローラで、MyDatabase プロジェクトのデータベース参照フォルダを右クリックしてデータベースの参照を作成し、[データベース参照の追加] をクリックします。図 4 のようなダイアログボックスが表示されます。

図 4 [データベース参照の追加] ダイアログボックス

この種類の参照では、[データベース参照の追加] ダイアログボックスに表示された既定の設定を使用します。"master" というリテラルを使用し、リテラル "master" を 3 つの部分で構成される名前の一部に含めることによって、データベースオブジェクト (ストアドプロシージャなど) からマスタデータベース (テーブルなど) 内のオブジェクトを参照できるようになります。サーバーレベルオブジェクトに未解決の参照エラーが存在する場合、新しい参照によって修正する必要があります。図 5 に、参照が作成された後、ソリューションエクスプローラに表示された MyDatabase プロジェクトのデータベース参照を示します。

図 5 MyDatabase の参照

システムオブジェクトを参照する

データベースプロジェクトでシステムオブジェクトを使用する場合は、マスタデータベースへの参照も必要です。システムオブジェクトの例としては、システムストアドプロシージャ、システムテーブル、システムビュー、システムカタログが挙げられます。ユーザーデータベースで使用頻度の高いシステムオブジェクトは sysobjects ビューです。たとえば、図 6 のストアドプロシージャでは、sys.sysobjects および sys.schemas システムビューを使用しています。これらのオブジェクトの定義を含むマスタデータベースへの参照が存在しない場合、ストアドプロシージャで使用されているシステムオブジェクトが解決不能であることを通知する多数の警告が生成されます。ストアドプロシージャでは遅延名前解決が可能であるため、これらは未解決の参照に対する警告になります。VIEW 定義内の同じ SELECT ステートメントではエラーが生成されます。

図 6 マスタデータベースへの参照が存在しない場合に発生する警告およびエラー

これらの警告を削除するには、これらのオブジェクトの定義を含むマスタデータベースへの参照を作成する必要があります。ただし、システムオブジェクトを参照するためにサーバープロジェクトは必要ありません。サーバープロジェクトに含まれるのは定義されたオブジェクトと設定です。システムオブジェクトを含むマスタデータベースを参照するには、master.dbschema ファイルを参照してシステムオブジェクトへの参照を解決します。master.dbschema ファイルへの参照を作成するには、データベースの参照を前述と同じ方法で定義しますが、今度はプロジェクトを参照する代わりに .dbschema ファイルを参照します。master.dbschema ファイルは次のディレクトリにあります。

"%programfiles%\Microsoft Visual Studio 9.0\VSTSDB\Extensions\SqlServer\
<SQL Version>\DBSchemas"

GDR では 7 つの .dbschema ファイルがインストールされます (SQL Server のサポート対象バージョンごとに 2 つずつと、SQL Server 2008 で使用可能な新しい SQL 型用に追加された 1 つの dbschema ファイル)。SQL Server のサポート対象バージョンごとに対応する master.dbschema ファイルと msdb.dbschema ファイルがあります。これらの .dbschema ファイルにはターゲットとするバージョンの SQL Server のマスタデータベースに定義されたすべてのオブジェクトが含まれているため、master.dbschema ファイルへの参照を作成すると、プロジェクトのモデルの更新に多少時間がかかる可能性があります。また、サーバープロジェクトへの参照と静的 master.dbschema ファイルへの参照はそれぞれ目的が異なるため、両方を保持することが可能です。どちらの参照にも "master" リテラルを使用します。

プロジェクトのアップグレード

GDR より古いバージョンの VSTS Database Edition で作成したプロジェクトを操作する場合、配置前および配置後のスクリプトで作成したサーバーレベルオブジェクトを新しいサーバープロジェクトに移動する必要があります。プロジェクトのアップグレードプロセスで、配置前および配置後のスクリプトに定義されたサーバーオブジェクトが Upgraded.AllServerObjects.sql という名前のスクリプトファイルに移動します。このスクリプトファイルは Upgrade という名前のルートプロジェクトフォルダのサブフォルダに保存されています。このスクリプトファイルを新規に作成したサーバープロジェクトにインポートするには、スクリプトのインポートコマンドを使用します。参照のエラーまたは警告を解決するには、データベースプロジェクトから新しいサーバープロジェクトへの参照を作成します。

新しいデータベースプロジェクトのビルドと配置

データベースの配置を検討する際、すぐに思いつくシナリオがいくつかあります。

多くの IT グループでは、部門アプリケーションのビルドを運用環境およびエンドユーザーに提供する前に複数の環境に移行する必要があります。
ソフトウェアベンダはターゲットデータベースのスキーマを念頭において更新プログラムをリリースしますが、その際、以前のバージョンのスキーマと一致しない可能性がある顧客のスキーマを適切に更新できる必要があります。

以前のバージョンの VSTS Database Edition ではデータベースプロジェクトのビルド時に T-SQL 配置スクリプトが出力されるため、このようなシナリオの管理は困難でした。従来、ビルド出力を生成するには、データベースプロジェクトとターゲットインスタンス (またはデザインデータベースインスタンス) 上のデータベースとの差分を取得し、ターゲットインスタンスをプロジェクトのソースと同様に更新するスクリプトを作成していました。スクリプトはビルド時に生成されるため、ビルドの出力を取得して異なる環境 (しかも、場合によっては異なるスキーマ) で複数回実行する手段はありませんでした。

GDR では、ビルド時および配置時の処理は、前述のシナリオをより適切にサポートするように変更されました。高度なレベルで、ビルドはプロジェクトのコンテンツを集約し、配置パッケージを論理的に表現する一連のファイルを生成します。配置では、"配置パッケージ" ファイルを使用し、配置計画を生成し、T-SQL スクリプトを生成して配置計画を実行します。配置を構成して、ターゲットデータベースに対してスクリプトを適用することもできます。以前のバージョンと同様に、ビルドおよび配置は MSBuild タスクとして提供され、チームのビルドサーバーで使用できるようになっています。

1 つのビルドを複数の環境に配置できるようにするため、配置を指向した構成情報は別のファイルにファクタリングされます。複数のファイルを使用すると複雑になりますが、ソースコード管理下の複数の異なる環境への配置に使用する構成を設定できます。具体的な例を図 7 に示します。この例では、データベースプロジェクトのビルドを 4 つの異なる環境に配置します。

図 7 環境の例

環境	配置の構成
開発	この環境への配置では、常にデータベースを再作成します。これはデバッグプロジェクト構成です。SqlCmd 変数をカスタマイズしています。
統合	差分を配置します。この場合、プロジェクトに存在しないオブジェクトに対する ALTER ステートメントおよび DROP が生成されます。これはリリースプロジェクト構成です。SqlCmd 変数をカスタマイズしています。
ユーザーテスト	製品配置の準備。差分を配置します。SqlCmd 変数をカスタマイズしています。
運用	差分を配置します。SqlCmd 変数をカスタマイズしています。

これらの 4 つの環境に基づいて、4 つのカスタマイズされた配置構成ファイルおよび SqlCmd ファイルを定義できます。各ファイルにはターゲット環境固有の構成を保存します。これらのファイルを設定すると、プロジェクトのプロパティは図 8 のようになります。

図 8 カスタム配置用のプロジェクトプロパティの設定

この図では、前述のファイル以外に Development.sqldeployment ファイルをデバッグプロジェクト構成の既定の構成に設定しています。また、Development.sqlcmdvars ファイルは SqlCmd の変数および値の既定の定義です。

プロジェクトのビルドが完了したら、ビルド出力を使用して複数のデータベースインスタンスに配置できます。同じビルド出力を使用して、新しいデータベースの配置または既存データベースの更新を行うことができます。前述のように、既定の配置では、プロジェクトのビルド時にプロジェクトの構成を使用しますが、コマンドラインで .deploymanifest プロパティをオーバーライドすることもできます。たとえば、図 8 の一覧にあるすべての環境に配置するには、次のコマンドライン引数を使用します。

開発:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Development.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Development.sqlcmdvars /p:TargetConnectionString=
   "DataSource=DEV\sql2008;Integrated Security=true;Pooling=false"

統合:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Integration.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Integration.sqlcmdvars /p:TargetConnectionString=
    "DataSource=INT\sql2008;Integrated Security=true;Pooling=false"

ユーザーテスト:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\UserTest.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\UserTest.sqlcmdvars /p:TargetConnectionString=
   "DataSource=USERTEST\sql2008;Integrated Security=true;Pooling=false"

運用:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Production.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Production.sqlcmdvars /p:TargetConnectionString=
   "DataSource=PRODUCTION\sql2008;Integrated Security=true;Pooling=false"

これらの例では、Deploy MSBuild タスクを使用して EnterpriseDB.dbproj の 1 つのビルドを構成の異なる複数の環境に配置しています。同様の配置を、GDR に含まれている新しいコマンドラインツール、VSDBCmd を使用して実行できます。

VSDBCmd コマンドライン機能

GDR には、VSDBCmd (vsdbcmd.exe) というコマンドラインツールが付属しています。このツールで、既存のデータベースから .dbschema ファイルを作成し、ビルド出力または .dbschema ファイルのみをターゲットインスタンスに配置できます。VSDBCmd は Visual Studio がインストールされていないコンピュータ上でも使用できます。コンピュータ間でコマンドラインツールを移動するには、VSTSDB ディレクトリの配下にある Deploy ディレクトリからコマンドラインツールの実行可能ファイルとコンポーネントをコピーします。Visual Studio の標準インストールでは、この場所は %programfiles%\microsoft visual studio 9.0\vstsdb\deploy\ です。Deploy ディレクトリをサムドライブにコピーしてから別のコンピュータに配置できます。

VSDBCmd を使用するには、このツールをコマンドラインから実行します。図 9 は結果を示しています。これらのオプションは一見すると複雑に思えるかもしれませんが、オプションのグループ化方法を理解するために役立つ注目ポイントがいくつかあります。

VSDBCmd は複数のデータベースプラットフォームで使用することを目的としています。現在の VSTS Database Edition でサポートされているのは SQL Server のみですが、将来のリリースでこの点が変更される可能性があります。
データベーススキーマのインポートまたはデータベースの配置を行うには、接続文字列を指定する必要があります。この接続文字列は、データベースプロバイダの標準の ADO.NET 接続文字列です。
VSDBCmd は特定のデータベースプロバイダに依存しないため、接続文字列を指定して使用するプロバイダに関する情報を与える必要があります。また、ターゲットデータベースのバージョンを確認するためにも接続文字列を定義する必要があります。たとえば、SQL Server の一部の配置オプションは SQL2005 以降でのみ使用可能です。

図 9 VSDBCmd からの出力

>"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" /?
Help for dynamic property usage
/help[+|-]                        (short form /?)
/Action:{Import|Deploy}           (short form /a)
/ConnectionString:<string>        (short form /cs)
/DatabaseSchemaProvider:<string>  (short form /dsp)
@<file>                           Read response file for more options

Help for command actions
/Action:{Import|Deploy}           (short form /a)
/Quiet[+|-]                       (short form /q)
/ConnectionString:<string>        (short form /cs)
/DeployToDatabase[+|-]            (short form /dd)
/ModelFile:<string>               (short form /model)
/ManifestFile:<string>            (short form /manifest)
/DeploymentScriptFile:<string>    (short form /script)
/DatabaseSchemaProvider:<string>  (short form /dsp)
/Properties:<string>              (short form /p)
@<file>                           Read response file for more options

Northwind データベースからモデルを作成するには、次のコマンドを実行します。

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Import 
/cs:"Data Source=(local)\sql2008;Integrated Security=true;Initial Catalog=Northwind08" 
/dsp:sql 
/model:northwind.dbschema

ここでは、接続文字列で指定したデータベースから northwind.dbschema という名前の .dbschema ファイルを作成します。VSDBCmd は複数のプロバイダをサポートしているため、.dbschema ファイルを作成するときに、使用するプロバイダ (この場合は "sql" プロバイダ) も指定する必要があります。ご覧のように、データベースをモデルにインポートするオプションはきわめて簡潔です。いくつかの SQL Server 固有の追加インポートオプションもあります。これらのオプションを表示するには、次の動的プロパティヘルプコマンドを使用します。

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Import 
/cs:"Data Source=(local)\sql2008;Integrated Security=true"
/dsp:sql 
/?

次に、新しいデータベースにインポートしたモデルを配置します。モデルを配置するには、次のコマンドを使用します。

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/cs:"Data Source=(local)\sql2008;Integrated Security=true" 
/model:northwind.dbschema 
/dd:+  
/p:TargetDatabase=NewNorthwind

このコマンドは、northwind.dbschema に含まれるモデルをインスタンス (local)\sql2008 と新しいデータベース NewNorthwind に配置します。データベースへの配置オプション (/dd:+) を指定せずに VSDBCmd を実行すると、配置スクリプトのみが生成されます。この配置スクリプトは、プロジェクトを配置した場合またはスキーマ比較を使用した場合に生成されるスクリプトに類似しています。前述の例で (/dd:+) を指定しなければ、差分スクリプトが出力されます (ここではファイル名を指定していないため、ファイル名は northwind.txt になります)。これは、ターゲットインスタンスに対してスクリプトを実行する前に検証および確認用のスクリプトを生成する便利な方法です。

オプション /p:TargetDatabase=NewNorthwind は他のオプションとは異なります。これはツールの拡張性フレームワークを通じて公開されている数多くのオプションの一例です。SQL Server で使用可能なすべてのオプションを表示するには、SQL Server 2008 データベースに対して次のコマンドを実行します。

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/cs:"Data Source=(local)\sql2008;Integrated Security=true" 
/dsp:sql 
/?

これらのオプションは、配置およびスキーマ比較のさまざまな構成ページで使用可能なオプションと同じです。

VSDBCmd は、.dbschema ファイルを配置する場合以外に、データベースプロジェクトのビルド出力を使用および配置する場合にも利用できます。VSDBCmd を使用して、先ほど MSBuild で行ったマルチ環境の配置を実行することもできます。VSDBCmd を使用する場合、配置タスクまたは VSTS Database Edition のインストールを実行するために .dbproj ファイルを使用する必要はありません。次の例では、VSDBCmd をビルド出力ディレクトリ内で実行します。

開発:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Development.sqldeployment 
/p:SqlCommandVariablesFile=Development.sqlcmdvars 
/cs:"Data Source=DEV\sql2008;Integrated Security=true"

統合:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Integration.sqldeployment 
/p:SqlCommandVariablesFile=Integration.sqlcmdvars 
/cs:"Data Source=INT\sql2008;Integrated Security=true"

ユーザーテスト:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=UserTest.sqldeployment 
/p:SqlCommandVariablesFile=UserTest.sqlcmdvars 
/cs:"Data Source=USERTEST\sql2008;Integrated Security=true"

運用:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Production.sqldeployment 
/p:SqlCommandVariablesFile=Production.sqlcmdvars 
/cs:"Data Source=PRODUCTION\sql2008;Integrated Security=true"

これらの例でわかるように、VSDBCmd を使用して、データベースプロジェクトのビルドを構成の異なる複数の環境に配置できます。

SQL CLR プロジェクトのサポート

SQL Server 2005 以降、開発者はデータ型、プロシージャ、関数、トリガを CLR 型として実装できるようになりました。GDR が登場するまで、これらの型をデータベースプロジェクトのスキーマの一部として使用することは困難でした。その理由は、C# または Visual Basic のプロジェクトによるアセンブリ出力を base64 エンコードテキストのスクリプトとして追加する必要があったためです。GDR では、SQL CLR プロジェクトのサポートが大幅に向上しました。SQL CLR プロジェクトをデザイン時にデータベーススキーマの一部として積極的に使用し、プロジェクトの配置時にインスタンス上で管理できるようになりました。具体的な例を使用して、そのしくみを説明します。

まず、ソリューションを作成して SQL Server 2008 データベースプロジェクトを追加します。次に、CustomTypes という名前の SQL CLR C# プロジェクトを追加します (図 10 を参照)。この C# プロジェクトを追加すると、配置ターゲットの入力を要求されます。アセンブリの配置はデータベースプロジェクトによって管理されるため、このダイアログボックスをキャンセルします。

図 10 SQL CLR プロジェクトを追加する

次に、データベースプロジェクトから C# プロジェクトへの参照を追加します。この参照は、C# プロジェクトの参照と同様に、参照先プロジェクトのコンテンツが参照元プロジェクトによって使用されていることを示しています。[データベース] プロジェクトの [参照] ノードを右クリックして参照を追加し、[参照の追加] をクリックします。[参照の追加] ダイアログボックスで、[CustomTypes] プロジェクトを選択します。

これで参照は追加されましたが、次に、参照の構成方法をカスタマイズして、参照が適切に配置されるようにする必要があります。アセンブリの構成を変更するには、参照を選択して F4 キーを押します。図 11 に、プロパティブラウザに表示される内容を示します。

図 11 CustomTypes のプロパティを設定する

この例では、AssemblyName をプロジェクト名と同じ名前に変更し、AssemblyOwner を明示的に dbo に設定しています。アセンブリのアクセス許可レベルの既定値は [セーフ] です。ただし、アンセーフコードを SQL Server インスタンスに配置する必要がある場合には、この設定を変更できます。

ここでは、[Database1] プロジェクトのプロパティから [配置] を選択して、CustomTypes CLR プロジェクトによって作成されたアセンブリを配置できます。プロジェクトの接続文字列を構成していないため、CREATE 配置スクリプトが生成されます。出力ウィンドウに図 12 のような出力結果が表示されます。

図 12 CustomTypes アセンブリを配置する

------ Build started: Project: CustomTypes, Configuration: Debug Any CPU ------
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig 
/nowarn:1701,1702 /warn:4 /define:DEBUG;TRACE /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.XML.dll /debug+ /debug:full 
/optimize- /out:obj\Debug\SqlClassLibrary.dll /target:library Properties\AssemblyInfo.cs

Compile complete -- 0 errors, 0 warnings
CustomTypes -> D:\Demos\Database1\CustomTypes\bin\Debug\SqlClassLibrary.dll
------ Build started: Project: Database1, Configuration: Debug Any CPU ------
    Loading project references...
    Loading project files...
    Building the project model and resolving object interdependencies...
    Validating the project model...
    Writing model to Database1.dbschema...
  Database1 -> D:\Demos\Database1\Database1\sql\debug\Database1.dbschema
------ Deploy started: Project: CustomTypes, Configuration: Debug Any CPU ------
Error: Cannot deploy. There is no database connection specified. To 
correct this error, add a database connection using the project properties.
Error: The operation could not be completed 
------ Deploy started: Project: Database1, Configuration: Debug Any CPU ------
    Deployment script generated to:
D:\Demos\Database1\Database1\sql\debug\Database1.sql

    The deployment script was generated, but was not deployed. You can 
    change the deploy action on the Deploy tab of the project properties.
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 1 failed, 0 skipped ==========

CustomTypes プロジェクトが Database1 によって参照されているため、Visual Studio は Database1 を配置する前にプロジェクトの配置を試行します。CustomTypes プロジェクトの接続文字列を指定していないため、配置は失敗し、エラーが発生します。アセンブリは Database1 配置スクリプトの一部として配置されるので、このエラーは無視してかまいません。このエラーが発生しないようにするには、構成マネージャで CustomTypes の配置をオフにします。

プロジェクトのビルドおよび配置が完了したら、Database1 の配置スクリプトを開いて、スクリプトの最後の方にアセンブリが作成されていることを確認できます。

GO
PRINT N'Creating CustomTypes...';

GO
CREATE ASSEMBLY [CustomTypes]
    AUTHORIZATION [dbo]
    FROM 0x4D5A90000300000004[snip…]    
    WITH PERMISSION_SET = SAFE;

GO

アセンブリの内容は、ビルド時の型参照の検証にも使用されます。このことを確認するため、既定のテンプレートを使用して CustomTypes プロジェクトにユーザー定義型 (UDT) を追加します。このファイルに Type1.cs という名前を付けます。この型をデータベースで使用するには、データベースプロジェクト内で宣言する必要があります。ユーザー定義型を追加するには、Database1 を右クリックして [項目の追加] をクリックし、ユーザー定義型 (CLR) テンプレートを使用します。既定では、テンプレートによって作成されるファイルは次のようになります。

CREATE TYPE [dbo].[Type1]
  EXTERNAL NAME [assembly_name].[type_name]

この T-SQL を次のように変更し、CustomTypes の Type1 を参照します。

CREATE TYPE [dbo].[Type1]
  EXTERNAL NAME [CustomTypes].[Type1]

このファイルを保存し、エラー一覧を確認します。次のようなエラーが表示されます。

TSD04117: The referenced type with the required Clr attribute was not found in the loaded 
assembly.

このエラーが表示される原因は、Type1.cs を追加した後、CustomTypes プロジェクトがビルドされていないことにあります。CustomTypes プロジェクトをリビルドすれば、このエラーは表示されなくなります。このカスタム型を列型として使用するには、プロジェクトに次のテーブルを追加します。

CREATE TABLE [dbo].[Table1]
(
  column_1 int NOT NULL, 
  column_2 dbo.Type1 NULL
)

このテーブルをプロジェクトに追加すると、dbo.Type1 への参照がプロジェクトシステムによって評価され、dbo.Type1 が存在しない場合はエラーが発生します。

配置スクリプトを作成する以外に、このプロジェクトを図 13 のように SQL 2008 インスタンスに配置することもできます。プロジェクトをターゲットインスタンスに配置すると、データベースを作成する必要があることを配置エンジンが検出し、プロジェクトのコンテンツが適切な依存関係順序で作成されます。

図 13 CustomTypes プロジェクトを配置する

------ Build started: Project: CustomTypes, Configuration: Debug Any CPU ------
CustomTypes -> D:\Demos\Database1\CustomTypes\bin\Debug\SqlClassLibrary.dll
------ Build started: Project: Database1, Configuration: Debug Any CPU ------
    Loading project references...
    Loading project files...
    Building the project model and resolving object interdependencies...
    Validating the project model...
    Writing model to Database1.dbschema...
  Database1 -> D:\Demos\Database1\Database1\sql\debug\Database1.dbschema
------ Skipped Deploy: Project: CustomTypes, Configuration: Debug Any CPU ------
Project not selected to build for this solution configuration 
------ Deploy started: Project: Database1, Configuration: Debug Any CPU ------
    Deployment script generated to:
D:\Demos\Database1\Database1\sql\debug\Database1.sql

    Creating Database1...
    Creating CustomTypes...
    Creating dbo.Type1...
    Creating dbo.Table1...
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 0 failed, 1 skipped ==========

スタティックコード分析の機能強化

GDR がリリースされる以前には、スタティックコード分析は Power Tool の機能として提供されていました。GDR は統合スタティックコード分析機能を備え、スタティックコード分析 (SCA) エンジンにいくつかの変更を加えて処理の柔軟性を高めています。

スタティックコード分析は、各ビルドの一部として実行するか、または MSBuild を使用してコマンドラインから実行することができるようになりました。ビルドのたびにスタティックコード分析が実行されるように設定するには、プロジェクトのプロパティの [コード分析] セクションで、[コード分析を有効にする] をオンにします。各ルールまたはルールグループを警告 (既定) またはエラーとして扱うことができます。スタティックコード分析のルールでは、プロジェクト内でエラーが検出された場合にはビルドは失敗し、配置は停止されます。SCA の警告およびエラーをルールレベルおよびファイルレベルで非表示にすることもできるようになりました。

ルールを非表示にするには、エラー一覧でスタティックコード分析の警告またはエラーを右クリックし、[Suppress Static Code Analysis Message(s)] (スタティックコード分析メッセージを表示しない) を選択します。非表示にしたルールは、プロジェクトシステムのルートにある StaticCodeAnalysis.SupressMessages.xml ファイルに追加されます。非表示にしたルールを含めるには、このファイルをプロジェクトから削除するか、このファイルの特定のルールとファイルの組み合わせを削除します。図 14 に、新しいオプションが表示されたプロジェクトプロパティウィンドウの [コード分析] セクションを示します。

図 14 スタティックコード分析のオプション

スタティックコード分析をデータベースプロジェクトのビルド時に実行することができます。スタティックコード分析を有効にすると、プロジェクトをビルドするたびに分析が実行され、エラーが検出された場合にはビルドが失敗します。これは、MSBuild を使用してコマンドラインからビルドを起動した場合も同様です。GDR には SCA MSBuild ターゲット (StaticCodeAnalysis) も用意されています。この機能により、[Enable SCA For Build] (ビルド時にスタティックコード分析を有効にする) の設定に関係なくスタティックコード分析を実行できます。

スタティックコード分析はプロジェクトごとに構成可能なため、構成または環境ごとに異なるルールおよびエラーオプションの組み合わせを定義できます。スタティックコード分析をコマンドラインから実行すると、StaticCodeAnalysis.Results.xml という名前の結果ファイルが生成されます。このファイルは MSBuild の起動元ディレクトリに書き込まれます。結果ファイルの名前と場所を変更するには、ResultsFile プロパティをオーバーライドします。

MSBuild でスタティックコード分析をコマンドラインから実行するには、次のコマンドを使用します。

msbuild MyDatabase.dbproj /t:StaticCodeAnalysis

図 15 に、生成されたスタティックコード分析結果ファイルの例を示します。

図 15 サンプルスタティックコード分析結果ファイル

<?xml version="1.0" encoding="utf-8" ?> 
<Problems>
<Problems>
      <Rule>Microsoft.Design#SR0001</Rule> 
    <ProblemDescription>The shape of the result set produced by a SELECT 
    * statement will change if the underlying table or view structure 
    changes.</ProblemDescription> 
<SourceFile>C:\USERS\XXXX\DOCUMENTS\VISUAL STUDIO 2008\PROJECTS\ \
MYDATABASE\MYDATABASE\SCHEMA OBJECTS\SCHEMAS\DBO\PROGRAMMABILITY\STORED 
PROCEDURES\MYSTOREDPROC.PROC.SQL</SourceFile> 
  <Line>6</Line> 
  <Column>8</Column> 
  <Severity>Warning</Severity> 
  </Problems>
</Problems>

ヒントと秘訣

この記事のまとめに入る前に、GDR に関するその他の重要な変更点を示しておきます。

GDR では、スキーマ間でオブジェクトを移動する機能が追加されました。また、リファクタリングの変更を保持し、適切な T-SQL を生成して、その変更を配置時にターゲットサーバーに適用する機能もあります。たとえば、テーブル名を変更すると、テーブルを削除して再作成するのではなく、次回の配置時に sp_rename が発行されます。

データベースプロジェクトで参照可能なファイルの種類が増えました。GDR で参照を作成可能なファイルの種類は次のとおりです。

プロジェクト
.dbschema ファイル
.dll (SQL CLR のサポート)
.xsd (XSD)

データベースプロジェクトまたは .dbschema ファイルの参照では、プロジェクトは他のデータベースを論理的に参照します。参照に 3 つまたは 4 つの部分で構成される名前が存在しない場合は、複合プロジェクトの参照として認識されます。複合プロジェクトはデータベースを論理的に複数のプロジェクトに分割する新機能です。その目的は、開発のためにデータベーススキーマをセキュリティまたは組織の境界に従って分割し、手動で適切な順序で配置することです。複合プロジェクトはデータベース間参照のみをサポートし、データベースとサーバー間またはサーバー間の参照はサポートしません。データベースとサーバー間の参照では、参照に "master" というリテラルを指定します。

前述したように、SQL CLR プロジェクト、.dll、および .xsd への参照では、参照先オブジェクトがデータベースに登録され、その参照先オブジェクトをソースコードの他の部分で使用できます。これらの参照先オブジェクトはデータベースプロジェクトの配置の一部として配置されます。

GDR のリリースでは、配置のプロパティページが改変され、設定をプロジェクトファイル (.dbproj) に保存するか、ユーザー設定ファイル (.user) に保存するかを簡単に指定できるようになりました。図 16 に例を示します。

図 16 サンドボックスの構成設定

この新しいプロパティページでは、設定の保存場所を指定できます。既定では、接続文字列とその他の配置構成はプロジェクトファイルに保存され、チームメンバー間で共有されます。設定のドロップダウンを [My Isolated Development Environment] (分離開発環境) に変更すると、[ターゲットデータベースの設定] の設定は .user ファイルに保存されます。

データベースの単体テストも GDR リリースで若干変更されました。テスト駆動型開発のサポートが強化され、データベースプロジェクトはテストを実行するたびに配置されるようになりました。ビルドと配置を分割した新機能では、テストを実行するたびにデータベースプロジェクトが配置されるため、テスト駆動型の開発でのパフォーマンスが低下します (以前のリリースでは、配置スクリプトは実行済みであれば省略されるため、この問題は発生しません)。

多くの開発者は単体テストの実行にサンドボックスデータベースを使用し、更新はテストの実行時のみに行うという実情を考慮して、プロジェクトの .dbschema が .sql スクリプトより新しい場合にのみデータベースプロジェクトの配置を実行する設定が追加されました。この設定を有効にするには、テストプロジェクトの app.config を次のように変更します。

<DatabaseDeployment 
 DatabaseProjectFileName="..\..\..\Database1\Database1.dbproj"
 Configuration="Debug" ForceDeployment="false"/>

配置を実行する必要があるかどうかを判別し、他のコンピュータへの配置と区別するために、配置スクリプトにはサンドボックスデータベースの名前が付けられます。たとえば、サンドボックスデータベースの名前が Database1Sandbox の場合、配置スクリプト名は UnitTestDeployment_Database1Sandbox.sql になります。前述のように、サンドボックスデータベースのスキーマを単体テストの実行以外の方法で変更する場合には、この設定は使用しないでください。

GDR では拡張機能も更新され、異なるデータベースプロバイダをターゲットとする拡張の手段が用意されました。特定のプロバイダをターゲットとする拡張機能としてクラスを定義するには、DatabaseSchemaProviderCompatibilityAttribute で修飾する必要があります。すべての SQL バージョンをターゲットにするデータジェネレータの場合は次のようになります。

[DatabaseSchemaProviderCompatibility(typeof(SqlDatabaseSchemaProvider))]

現時点では、単体テストにはターゲットデータベースプロバイダの概念は導入されておらず、既存のすべてのテスト条件はプロバイダに依存しません。新しいテスト条件を定義するには、次の属性を追加します。

[DatabaseSchemaProviderCompatibility(DspCompatibilityCategory.Any)]
[DatabaseSchemaProviderCompatibility(DspCompatibilityCategory.None)]

これらの属性はそれぞれ、このテスト条件はデータベーススキーマプロバイダが存在しない場合に有効であること、テスト条件はすべてのデータベーススキーマプロバイダに対して有効であることを示しています。

Jamie Laflen は DBPro チームのテクニカルリードで、単体テスト、データ生成、およびビルド機能や配置機能を担当しています。開発チームに参加する前は、マイクロソフトのサービス部門に在籍しており、顧客が Visual Studio で .NET アプリケーションを実装する際の支援に携わっていました。

Barclay Hill はプログラムマネージャとして DBPro チームの一員に新たに加わりました。それ以前には、長年、さまざまな業界の主要エンタープライズデータベースアプリケーションの開発に携わっていました。

次の方法で共有

その他のリソース