September 2011

Volume 26 Number 09

SQL Server Developer Tools - "Juneau" データベース プロジェクト

Jamie Laflen | September 2011

SQL Server Developer Tools (SSDT、コードネーム "Juneau") は、Microsoft SQL Server を対象に開発を行う開発者向けに統合ツールを提供するという、マイクロソフトの継続的な取り組みを表すものです。Visual Studio における以前のバージョンのデータベース プロジェクトを使い慣れている方から見ると、Juneau は SQL Server 向けのこうした統合ツールを進化させ、多数の新機能を追加し、多数の機能強化を施したツールであることがわかります。Juneau は、SQL Server Business Intelligence Design Studio (BIDS) に含まれるプロジェクト (Reporting Services プロジェクト、Analysis Services プロジェクト、Integration Services プロジェクトなど) を SQL Server データベース プロジェクトと組み合わせた、統一ツールセットを提供します。

Juneau は単独でインストールでき、SQL Server を対象とするデータベース開発に必要なあらゆる機能が用意されていますが、アプリケーション開発と同じ環境でデータベース開発を行えるようになったことから、Visual Studio にとっても不可欠な要素となります。Juneau は、2011 年にリリース予定の SQL Server (コードネーム "Denali") の一部として入手可能になるほか、今後のバージョンの Visual Studio でも入手可能になる予定です。

今回の記事では、この Juneau データベース プロジェクトを取り上げます。このプロジェクト システムとその関連機能により、データベースの編集、コンパイル、リファクタリング、および特定のバージョンの SQL Server や SQL Azure へのパブリッシュを行うツールが提供されます。Juneau にはすべてのバージョンの SQL Server に対応するデータベース プロジェクトが 1 つ用意され、このプロジェクトには Transact-SQL (T-SQL) スクリプトと、SQL CLR オブジェクトを定義するコードの両方を含めることができます。では、データベース プロジェクトの設定から説明しましょう。

データベース プロジェクト

データベース プロジェクトは、SQL Server データベースをオフラインで開発できるようにする Visual Studio プロジェクトです。データベース開発チームは、プロジェクトを基盤とする開発に移行することで、共有ライブ データベースに対して開発を行うことになり、この種の開発から次のようなメリットを得ることができます。

• 開発者が加える変更の分離
• 多様な T-SQL 編集機能のサポート
• コード分析ルールによる、配置前のソース検証とチームのコーディング標準の適用
• 自動移行スクリプトの生成

中核となるプロジェクト システムは、前身の Visual Studio データベース プロジェクト (.dbproj) によく似ています。このプロジェクトでは、開発者はオブジェクトを CREATE ステートメントとして、宣言によって表現します。オフライン スキーマ開発の背景情報については、bit.ly/raDMNx を参照してください。

プロジェクトを設定する

Visual Studio によって作成される他の大半のプロジェクトと同様、データベース プロジェクトを初めて作成するときも、空のプロジェクトとして表示されます。つまり、プロジェクトにソース コードを追加し、ビルドおよびデバッグしてから、ソース コード管理にチェックインします。他の大半のプロジェクトはソース コードから開発に着手しなければなりませんが、データベース プロジェクトは既存の SQL Server データベースから作成することができます。プロジェクトにソース コードを追加する方法は、次のように希望する管理レベルに応じていくつかあります。

• 完全なデータベースをインポートする
• スクリプトをインポートする
• データベース パッケージ (.dacpac) をインポートする
• データベースを含むプロジェクトの比較に基づいて、特定のオブジェクトの更新を作成する
• サーバー エクスプローラーからドラッグ アンド ドロップする
• 既存の Visual Studio 2010 プロジェクト (データベース/SQL CLR) を SQL Server データベース プロジェクトに変換する

作成するプロジェクトではデータベースをモデル化します。つまり、データベース プロパティ (照合順序など) をプロジェクトのプロパティに格納し、ユーザー オブジェクトをソースとしてプロジェクト内に格納します。データベース プロジェクトは、データベースのソース コード形式のオフライン表現です。

データベース プロジェクトを説明するために、新しい空のデータベース プロジェクトを作成してから、そのさまざまな機能を紹介しましょう。データベース プロジェクトを作成する方法はいくつかあります。今回は、まず空のプロジェクトを作成するため、[ファイル] メニューをクリックし、[新規作成] の [プロジェクト] をクリックし、[SQL Server Database Project] (SQL Server データベース プロジェクト) を選択します (図 1 参照)。

図 1 新しい SQL Server データベース プロジェクトの作成

ソースをプロジェクトに追加する

ほとんどのデータベースには少なくとも 1 つテーブルが存在するためここでもテーブルを 1 つ追加します。SQL Server データベース プロジェクトには、よく使用される SQL オブジェクトの多くに対応する既定の T-SQL テンプレートが用意されています。新しいオブジェクトを作成するには、プロジェクト ノードを右クリックし、[追加] をポイントして [Table] (テーブル) をクリックし、ダイアログ ボックスでテーブル名を指定します。ここでは、"Customer" という名前を付けます。

図 2 に、新しいテーブル デザイナーで新しいテーブルがどのように表示されるかを示します。

図 2 新しいテーブル デザイナー

HTML デザイナーと同様、テーブル デザイナーは既定で分割ペイン形式で表示されます。デザイナー ウィンドウには、テーブルのグラフィカル表現と、テーブルのスクリプト定義が含まれています。どちらのビューで作業しても、もう一方のビューに変更が同期されます。

多くの場合はテーブルへの直接アクセスが制限されていることから、アプリケーションからテーブルのデータにプログラムでアクセスできるようストアド プロシージャを作成します。この点を踏まえて、ここでは Customer テーブルの追加と同じ方法で、CreateCustomer というストアド プロシージャを追加します。エディターが開き、プロジェクトに追加する既定のプロシージャのスケルトンが表示されます。開発者は、ストアド プロシージャを作成しながら実行して検証できるよう、ライブ データベースに対してストアド プロシージャを作成することが多いため、この方法は多少面倒に思わえるかもしれません。しかし、問題はありません。データベース プロジェクトが新しいデバッグ用データベースを作成するため、プロジェクトベースの開発では生産性が大幅に向上します。エディター内でテキストを選択して右クリックすると、図 3 のようなコンテキスト メニューが表示されます。

図 3 デバッグ用データベースに対するプロジェクト ソース コードの実行

接続文字列を構成していない場合、[Execute Query] (クエリの実行) を使用したテキストの実行は、どのように機能するのでしょう。ソース コードが開いている場合、エディターのスクリプトや選択したテキストを実行するよう指示すると、デバッグ用データベースに対して実行するようエディターが構成されます。また、デバッグを開始する (たとえば、F5 キーまたは Ctrl + F5 キーを押す) と、データベース プロジェクトのソースに合わせてデバッグ用データベースが更新されます。Juneau では、SQL Server Express LocalDB という Denali の新機能を利用して、開発およびデバッグ対象のインスタンスとデータベースが自動的に提供されます。詳細については、以下の「SQL Server Express LocalDB の概要」を参照してください。

ソースを開発する

LocalDB の概要を示し、開発者がストアド プロシージャをソース コード内で開発する方法について説明したので、次はデータベース プロジェクトで使用できる他の優れた機能について説明します。プロジェクト システム内の IntelliSense はいつでも優れた支援を提供しますが、SQL Server Management Studio (SSMS) とデータベース プロジェクトに関するフィードバックの両方に基づいてさらに強化されています。変更内容の多くは、以前のバージョンで不完全な部分を改修しているだけですが、いくつか重要な変更点もあります。

• Preview mode (プレビュー モード): T-SQL の IntelliSense に関する大きな不満の 1 つは、まだ定義していない型を参照する際に意図しない補完が行われることです。たとえば、次のように入力しようとしていたとします。

select t.id from Table1 as t

しかし、次の箇所まで入力してからピリオドを入力すると、

select t

次のように補完されます。

select Table1.

この問題は、IntelliSense に "preview mode" (プレビュー モード) を追加することで解決されました。プレビュー モードでは、一連の補完候補が表示され、ユーザーが (上方向キーまたは下方向キーを使用して) 補完候補を "アクティブ化" するまではオートコンプリートが行われません。

• 未保存のファイルでの IntelliSense: 以前のデータベース プロジェクトでは、ファイルを保存するまで、そのファイル内で定義しているオブジェクトを IntelliSense で使用できませんでした。たとえば、以前は、新しく追加したテーブルのファイルを保存するまで、そのテーブルは IntelliSense に表示されませんでした。新しいバージョンでは、ファイルを保存していなくても、テーブルが IntelliSense に表示されます。

Juneau の計画時、開発チームは、T-SQL の開発環境のレベルを他のマネージ言語の開発者が利用している環境のレベルまで引き上げることが重要だと考えました。この目標を達成する手段の一環としてプロジェクト システム内のエディターを強化し、[定義へ移動]、[すべての参照の検索]、オブジェクト定義や参照の右クリックによるエディターからの直接リファクタリングなど、よく使用する言語機能を提供するようにしました。

データベースのリファクタリングは、アプリケーション コードのリファクタリングよりはるかに難しい作業です。なぜなら、データベースにはデータが格納されているうえ、一見当たり障りのない名前の変更でも、他のオブジェクトとの依存関係によってさらに多数の変更が発生するおそれや、さらに悪いことにはこれらの変更の配置時にデータが失われるおそれがあるためです。Juneau では、MsdnDemo.refactorlog (この例の場合) の変更を追跡することで、プロジェクト内で実行したリファクタリング操作を追跡し、リファクタリング操作を考慮して適切な sp_rename または ALTER SCHEMA ステートメントを生成できるようにします。

他のマネージ言語では、新しいコードを実行する直前の最終作業がプロジェクトのビルドです。データベース開発では、運用中のインスタンス内のプロジェクトに含まれるすべてのデータベース オブジェクトを作成する作業がビルドに相当します。データベース プロジェクトのビルドで完全な検証機能を実行できるよう、Juneau では、SQL Server T-SQL Compiler Services (SQL Server T-SQL コンパイラ サービス) と呼ばれる SQL Server Denali の別の新機能を使用します。このコンポーネントでは、ライブ SQL Server に対してソースを実行しなくても、ソース コードを完全に検証できます。この機能の動作を確認するには、CreateCustomer プロシージャの後に以下のコードを追加します。

go

create table dbo.ExtendedVerificationDemo

(

  c1 int null,

  c2 as c2 + 5

)

プロジェクトをビルドすると、エラー一覧と出力ウィンドウに以下のエラーが表示されます。

E:\projects\MsdnDemo\MsdnDemo\CreateCustomer.sql(12,1): Error:  SQL01759: Computed column 'c2' in table 'ExtendedVerificationDemo' is not allowed to be used in another computed-column definition.

このエラー メッセージは、SQL Server エンジンによって表示されるメッセージと同じです (この例では、計算列で自己参照できないためエラーが発生します)。この機能は有益ですが、たとえば次のように、場合によっては無効にすることも必要です。

• 検証エンジンが SQL Server Denali エンジンを基盤として構築され、そのエンジンに基づいて規則を適用している。SQL Server Denali では使用されなくなった非推奨の構文をプロジェクトで使用すると、検証に失敗します。
• 3 つまたは 4 つの部分で構成される完全修飾名で参照されているオブジェクトが、検証エンジンで認識されない。SQL Server では、SQL Server の名前の遅延解決規則に基づいて、警告やエラーにフラグを付けます。詳細については、msdn.microsoft.com/library/ja-jp/ms190686 を参照してください。

このような制限に直面した場合は、ファイルまたはプロジェクト レベルの拡張検証を無効にできます。

ビルド時の警告とエラーにすべて対処したら、コードが機能することを確認します。

ソースを検証する

プロジェクトをビルドしたら、ソース コード管理にチェックインする前に、コードを実行 (場合によってはデバッグ) する必要があります。図 4 に示すように、開発サイクルの段階と目的の作業に応じて、いくつかのオプションが存在します。

図 4 コード検証のオプション

変更を移行する

コードが安定状態になったら、テスト用のインスタンスにそのコードを移行します (最終的にはこのインスタンスを顧客が使用します)。Juneau には、ソース データベースとターゲット データベースの違いに基づいて更新スクリプトを生成する、増分更新エンジンが備わっています。基盤となるエンジンは 1 つですが、変更の移行をサポートするために、Juneau では 3 種類の方法でエンジンが公開されます (図 5 参照)。

図 5 コード移行のオプション

これら 3 つのシナリオをサポートするために、増分更新エンジンでは動作を制御するさまざまなオプションが公開されています。このような設定の既定値は、チームが各シナリオを調整するにつれて、徐々に変化すると考えることができます。たとえば、デザイン時のシナリオでは、変更が確実に反映されることを重視し、デバッグ データベースを使用しているためデータの損失はそれほど重視しません。増分更新エンジンには多数のオプションがありますが、ここでは動作と対応するオプションの一部だけを紹介します (図 6 参照)。

図 6 更新動作の制御オプション

増分更新スクリプトを作成できると、ソース データベースからターゲット データベースへの変更の移行にとても便利です。ただし、増分更新スクリプトは厳密さが求められるため、スクリプトの正確な処理内容を把握したり、その概要をまとめたりするのは難しいことがあります。増分スクリプトの処理の要約や把握に役立つよう、Juneau では、スクリプトの処理に関する潜在的な問題を示し、スクリプトを実行した際の処理の概要をまとめたプレビュー レポートが作成されます。たとえば、プロジェクトを既定の LocalDB インスタンスにパブリッシュするには、次の手順を実行します。

1. [表示] メニューで、[その他のウィンドウ] をポイントし、[Database Activity Monitor] (データベース アクティビティ モニター) をクリックします。
2. プロジェクトを右クリックし、[Publish] (パブリッシュ) をクリックします。
3. [Publish Database] (データベースのパブリッシュ) ダイアログ ボックスに入力します (図 7 参照)。
4. [Publish] (パブリッシュ) をクリックします。

図 7 [Publish Database] (データベースのパブリッシュ) ダイアログ ボックス

パブリッシュが完了したら、パブリッシュの手順を開いて [View Plan] (プランの表示) リンクをクリックすると、図 8 のようなレポートが表示されます。

図 8 配置のプレビュー レポート

レポートには、スクリプトを実行すると 2 つのテーブル (ここでは ExtendedVerificationDemo テーブルのバグを修正しています) と先ほど記述した 1 つのプロシージャが作成されることが示されています。ハイライト セクションは空ですが、パフォーマンスに大きな影響を及ぼしたりデータが失われたりするおそれがある処理の概要がレポートに表示されるのがわかります。パブリッシュせずにスクリプトだけを生成した場合は、このレポートを使用して、実行前にスクリプトの処理を確認できます。

接続型の環境での開発

ここまでは、データベース プロジェクトを使用して、運用中のデータベースのコンテキスト外で、宣言によってコードを開発する方法について説明しました。チーム環境で作業する場合はこのようなテクノロジが非常に便利ですが、稼働中のサーバーを操作したい場合もあります。開発者にとって稼働中のサーバーが重要であることをマイクロソフトは認識しており、開発者向けに、機能豊富な接続型の環境に力を注いできました。この環境を説明するために、先ほどパブリッシュしたデータベースを開きます。このデータベースに接続するには、次の手順を実行します。

1. [表示] メニューをクリックします。
2. [サーバー エクスプローラー] をクリックします。
3. [SQL Server] ノードを右クリックします。
4. [SQL Server の追加] をクリックします。
5. 接続ダイアログ ボックスに「(localdb)\v11.0」と入力します。
6. 先ほどパブリッシュした MsdnDemo データベースに移動します (図 9 参照)。

図 9 サーバー エクスプローラーの新しい [SQL Server] ノードに表示されている MsdnDemo データベース

おそらく最初に気付くのは、Juneau のツリーが SSMS のツリーによく似ていることでしょう。開発チームは Juneau への移行時に学習し直さなければならない項目を少なくすることを目指していたため、これは当然です。SSMS での通常の作業と同様、ツリーから直接 T-SQL Query editor (T-SQL クエリ エディター) を開いてコードの記述を開始できます。これは、既に説明したエディターと同じものです。一部の SSMS 機能とは異なり、Juneau のツリーは明確に開発者向け作業を意識しています。たとえば、Customer テーブルを右クリックして [Delete] (削除) をクリックすると、データベースのパブリッシュ時と同じプレビュー レポートがダイアログ ボックスに表示されます。ただし今度は、削除を実行すると dbo.CreateCustomer プロシージャが機能しなくなるという警告が表示されます (図 10 参照)。

図 10 データベースの更新をプレビューするダイアログ ボックス

** Warnings

     The object [dbo].[CreateCustomer] will be broken if the

       change is executed.

 

** Highlights

     Tables that will be rebuilt

       None

     Clustered indexes that will be dropped

       None

     Clustered indexes that will be created

       None

     Possible data issues

       None

 

** User actions

     Drop

       [dbo].[Customer] (Table)

 

** Supporting actions

テーブルの名前を変更する場合も、同様のレポートが作成されます。どちらの場合も、操作の実行前にその変更内容の影響が通知されます。したがって、このレポートを使用すると、変更がデータベースに及ぼす影響と、変更を適用する場合に修正 (または削除) する必要がある項目を確認できます。

削除を取り消し、Customer テーブルを右クリックして [View Designer] (デザイナーの表示) をクリックすると、このプロジェクト システムではおなじみとなったテーブル デザイナーが表示されます。ただし、今回はサーバーから取得したテーブル定義に対してホストされています。デザイナーには、プロジェクト システムと同じ宣言型プログラミング モデルを使用した CREATE TABLE ステートメントが表示されています。デザイナーで、Id 列の名前を CustomerId に変更し、Age という 2 つ目の int 型の列を追加します。ここでエラー一覧を確認すると、列名を変更したために CreateCustomer プロシージャが機能しなくなっているという警告が表示されています (図 11 参照)。

図 11 列名の変更によるエラー

このエラーを修正するには、CreateCustomer プロシージャで [View Code] (コードの表示) を使用するか、警告をダブルクリックします。続いて insert ステートメントを変更し、列名を更新して Age 列の値として @param2 を指定します。この時点で、2 つのウィンドウ (ソース ウィンドウとデザイナー ウィンドウ) に、サーバー上のオブジェクトに対する一連の変更を定義する、データベースから取得した宣言型のオブジェクト定義が表示されます。[Update Database] (データベースの更新) ボタンをクリックすると、列名が変更されることとテーブルとプロシージャの両方が変更されることを通知する、今ではおなじみのレポートが表示されます。[Update Database] (データベースの更新) をクリックしてスクリプトを実行してから、サーバー エクスプローラーの Customer テーブルに移動すると、CustomerId 列と Age 列が含まれるようツリーが更新されていることがわかります。

接続型の開発環境をサーバー エクスプローラーで利用すると、同じ宣言型プログラミング モデルがサポートされ、変更に応じたリアルタイムの警告とエラーのサポートによってオンラインでの変更が強化されるため、開発者向けの機能が大幅に向上します。

Juneau を入手する

Juneau は、SQL Server Denali CTP3 リリースの一部として入手できます。また、Web からスタンドアロン版もダウンロードできます。これは、Visual Studio 2010 の既存のインストールや次期バージョンの Visual Studio に統合される予定です。さらに、Visual Studio をインストールせずにデータベースをパブリッシュでき Team Foundation Server の自動ビルド シナリオをサポートする、独立したコマンド ライン ツールのインストーラーも Juneau に用意されています。

SQL Server Express LocalDB の概要

SQL Server Express LocalDB (LocalDB) は、基本的には次世代の SQL Server Express ユーザー インスタンスですが、SQL Server Express インスタンスをデスクトップ上で明示的に管理する必要がありません。LocalDB には、名前付きインスタンスをホストするバックグラウンド サービスがありません。その代わり、開発者が名前付きカスタム インスタンスを定義して操作できます。LocalDB インスタンスを起動すると、そのインスタンスを起動したユーザーの資格情報で、プロセスとして実行されます。たとえば、LocalDB インスタンスを起動すると、自分の資格情報で実行する sqlservr.exe をタスク マネージャーで確認できます。T-SQL コードのデバッグを設定しないで済むので、この機能は単独でも優れています。起動したインスタンスは、SQL Server Express インスタンスとほぼ同じです。インスタンスを一定期間使用しないと、アイドル状態の SQL Server インスタンスがコンピューター上のリソースを消費しないように、そのインスタンスはシャットダウンされます。

LocalDB には、作成した LocalDB インスタンスの管理に使用できるコマンド ライン ツールが付属しています。たとえば、次のツールを実行すると、LocalDBDemo という 新しい LocalDB インスタンスを作成できます。

C:\Program Files\Microsoft SQL Server\110\Tools\Binn>SqlLocalDB.exe create LocalDBDemo

Local Database instance "LocalDBDemo" created with version 11.0. (バージョン 11.0 のローカル データベース インスタンス "LocalDBDemo" が作成されました)

インスタンスを作成したら、コマンド ライン ツールを使用してインスタンスを起動することも、Juneau、SQL Server Management Studio (SSMS)、またはアプリケーションを使用してインスタンスへの接続を試みることもできます。LocalDB のインスタンスはローカル コンピューターに常駐するインスタンスではないため、ローカル コンピューター上のインスタンスの操作に使用する (local) プレフィックスではアクセスできません。代わりに、(localdb) を使用します。この例では、インスタンスに接続して管理するには、Juneau に「(localdb)\LocalDBDemo」と入力します。

新しいインスタンスを作成すると、ユーザー プロファイルに新しいディレクトリが作成され、このディレクトリ内に 4 つの組み込みデータベース (master、tempdb、msdb、および model) が配置されます。既定では、すべての新しいデータベースがインスタンスのディレクトリに既定のデータ パスとして配置されます。今回の例では、このディレクトリのパスは次のとおりです。

C:\Users\user1\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\LocalDBDemo

カスタム インスタンスを作成しない場合は、v11.0 という名前の、LocalDB の既定の組み込みインスタンスを使用できます。このインスタンスにアクセスするには、Juneau で "(localdb)\v11.0" への接続を登録します。登録すると、LocalDB によってインスタンスが自動的に作成されます。

LocalDB は新機能なので、SSMS やマネージ アプリケーション コードを通じてインスタンスにアクセスする際に (LocalDB) プレフィックスを使用するには、Microsoft .NET Framework 4 の更新プログラムが必要です。この更新プログラムは、Juneau のインストール時に適用されます。プレフィックスのサポートは、次のバージョンの .NET Framework に組み込まれる予定です。

現在のデータベース開発者は、以前の Web 開発者が直面した (IISExpress によって解決された) 問題と同様の問題を抱えています。それは、サーバーを必要とするコードを、サーバー製品全体を開発用コンピューターのローカルで実行しなくても、開発してデバッグする方法についての問題です。LocalDB を利用すると、データベース開発者にも解決策が提供されます。LocalDB はデータベース開発に不可欠な要素なので、Juneau のインストール時にデスクトップにインストールされます。ソリューションにデータベース プロジェクトを追加すると、Juneau によってソリューション名に基づく名前の新しい LocalDB インスタンスが作成され、各データベース プロジェクトのインスタンス内にデータベースが作成されます。Juneau では、プロジェクト ディレクトリ内のディレクトリに、各データベース プロジェクトのデータとログ ファイルが作成されます。LocalDB の詳細については、go.microsoft.com/fwlink/?LinkId=221201 (英語) を参照してください。

Jamie Laflen は、SQL Server Developer Tools に携わっている開発者です。以前は、Visual Studio データベース プロジェクトに携わっていました。

Barclay Hill は、SQL Server Developer Tools に携わっているシニア プログラム マネージャーです。以前は、Visual Studio データベース プロジェクトに携わっていました。

この記事のレビューに協力してくれた技術スタッフの Jeffrey Davis、Mike Kaufman、Dave Langer、Genevieve Orchard、および Patrick Sirr に心より感謝いたします。