Insider's Eye 次期SQL Serverが.NETとXMLを強力サポート Yukonで革新されるDBサーバ・プログラミング ――　次期SQL Serverの強力な.NETとXMLサポートにより、DBサーバ・プログラミングは一変する　―― Chris Alliegro 2004/01/27 Copyright(C) 2004, Redmond Communications Inc. and Mediaselect Inc.

---

　

本記事は、（株）メディアセレクトが発行する月刊誌「Directions on Microsoft日本語版」 2004年1月15日号 p.14の「Yukonで革新するデータベース開発　サーバー側プログラミングはどう変わる？」を、許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。

　SQL Serverの次期バージョン（開発コード名：Yukon、ユーコン）は、.NET Frameworkの共通言語ランタイム（CLR）を統合し、XMLとWebサービスをネイティブでサポートする。.NET Frameworkを統合したことにより、財務ソフトウェアや請求処理ソフトウェアといった、サーバ側の固有なデータベース・コードに大きく依存するビジネス・システムの高い安定性が期待される。さらに、こうしたビジネス・システムを構築する開発者も、Visual StudioでVisual Basic（VB）.NETまたはC#を利用してデータベース常駐ロジックを作成できるため、生産性の向上が望める。ただし、SQL Serverのネイティブ・プログラミング言語であるTransact-SQL（T-SQL）をデータベース開発者が理解する必要は依然としてあり、T-SQLと.NET言語をどこで使い分けるかについては、注意深く検討しなければならない。

　.NET Frameworkを統合し、XMLとWebサービスのサポートを向上したYukonは、Microsoftにとって大きな意味がある。SQL Serverの成功をてこに、企業アプリケーション開発に.NET Frameworkを利用し、企業間のデータ交換にはXMLとWebサービスの利用を促進できる。YukonにVisual Studioの洗練された開発環境とツール・セットを組み合わせれば、IBMのDB2やOracleなど、プログラミングにJavaを使用している競合するデータベースの開発者に対して、優れた代替ソリューションを提供することができるからだ。

.NET Frameworkがサーバ側でのプログラミングを改善

　SQL Server Yukonに .NET Frameworkを統合したことで、サーバ側でのデータベース・プログラミングは大きく改善される。

　開発者とシステム・アーキテクトがサーバ側のデータベース・コードを構築するのには主に2つの理由がある。第1に、サーバ側のロジックにより、ビジネス・ロジックとデータ間のレイヤを提供できることだ。これによりアプリケーション開発者が、一般的に使用されているデータベース・クエリをプログラミング・インターフェイスとして利用できるようになる。ベースとなるデータベースに直接アクセスする（そしてデータベースを破壊する危険性もある）コードを記述しなくてもよくなるため、開発者はビジネス・ロジックの記述に専念できるようになる。第2に、データベースで一定のデータ集約的なコードを実行することにより、全体的なアプリケーションのパフォーマンスを向上できることも大きい。例えば、データベース・サーバと中間層のサーバとの間でネットワークを介してデータをやり取りすると、パフォーマンスが低下してしまう。これに対してシステム・アーキテクトは、データのアクセスと更新を主に行うコードを実際のデータにできるだけ近い場所に置き、パフォーマンスを高めるのだ。

■T-SQLに対する改善点
　現在のところ、SQL Serverにおけるサーバ側のプログラミングはT-SQLにより行われている。T-SQLは、リレーショナル・データベース管理システムの標準言語である構造化照会言語（SQL）をMicrosoftが拡張したものだ（T-SQLとSQL Serverのプログラミング・コンセプトについては、次の「SQL Serverのプログラミング・コンセプト」を参照）。

■SQL Serverのプログラミング・コンセプト 　Yukon以前は、SQL Serverに保存されたデータのアクセスと操作は主にTransact-SQL（T-SQL）でコマンド、クエリ、そのほかの命令を発行することにより行われていた。T-SQLはデータベース開発者に次のようないくつかの重要な機能を提供する。 ●データ定義言語（DDL：Data Definition Language）のセット 　SQL Server上の実際のデータベースとそれらに含まれるテーブルやデータ型を作成、定義および変更するコマンド。 ●データ操作言語（DML：Data Manipulation Language）のセット 　テーブルに含まれるデータを読み込み、変更するコマンド。 ●制御ステートメント（IF-ELSEブロックなど） 　実行フローの制御用。そのほか、算術操作や文字列操作のための各種演算子や関数が用意されている。 　サーバ側でのプログラミングでは、T-SQLコマンドは主にストアド・プロシージャとトリガの2種類の機能に分けられる。ストアド・プロシージャは通常、データ・アクセスかデータ更新のクエリをカプセル化したものであり（呼び出し側アプリケーションにデータ・テーブルの一部の行を返すなど）、トリガはデータベースのデータを変更する試みが行われたときに一定の処理を起動するものだ（テーブルに行を挿入する試みが行われたときに検証を実行するなど）。 　データベース・サーバにストアド・プロシージャやトリガを組み込むのには、2つの重要な目的がある。1つ目は、ビジネス・ロジックとデータ間の抽象化層を提供することだ。一般的なクエリはストアド・プロシージャに取り込み、経験豊かなデータベース開発者か管理者が最適化した上で、アプリケーション開発者にプログラミング・インターフェイスとして提供する。このようなインターフェイスが利用できれば、アプリケーション開発者はベースとなるデータの複雑さに煩わされることなくビジネス・ロジックの記述に専念できる。また十分にテストされたストアド・プロシージャを必ず経由してデータベースへのアクセスが行われるよう制限でき、データベースへの直接アクセス（そして破壊の可能性）を防止できる。2つ目は、この手法によりデータ集約的なコードをデータの近くに置き、パフォーマンスを向上できる点だ。プロシージャを最適化しテストした後は、そのパフォーマンスが最大になるロケーション、つまりSQL Serverのプロセス内に配置できる。

　しかし、SQL Serverデータベースのプログラミングでは標準的に使用されているとはいえ、T-SQLは最新の言語ではない。例えば、配列などの基本的な構造をサポートしておらず、文字列操作や算術演算機能も制限されている。こうした制限のため、最新の言語では実に簡単なプログラミングがT-SQLでは面倒な仕事になる。

　.NET Frameworkには、データベース開発者がサーバ側のプログラミングをする上でT-SQLに比べて次のようなメリットがある。

●最新のプログラム言語
　Yukonでは、データベース・プログラマはサーバ側のデータベース・コードをVB.NETまたはC#で開発できる。つまり、オブジェクト指向による構成概念、構造化例外処理、配列のサポートなど、最新のプログラミング言語に共通する基本的な機能を利用できるようになる。これらの機能は、ソフトウェア開発プロジェクトが規模や複雑さを増すにつれて、ますます重要になっている。

●より大規模なライブラリ
　.NET Frameworkには、組み込みクラスやルーチンの広範なライブラリが付属する。文字列操作関数、算術関数、日付／時刻操作、暗号化アルゴリズム、システム・リソースにアクセスする関数など、多彩に揃っているこれらのライブラリは、特に複雑な演算や文字列操作を含むプログラミング作業に役に立つ。データベース開発者にとっては、T-SQLだけではコーディングできないようなサーバ側のデータベース・プロシージャや関数を記述する強力な組み込みツール・セットとなるだろう。例えば、複雑な文字列（電子メール・アドレスなど）をデータベースに入力する前にそのフォーマットを検証することは、T-SQLでは困難な作業だが、.NET Frameworkがサポートする正規表現を利用すれば簡単である。

●高度な開発環境
　MicrosoftのVisual Studio .NET開発環境の次期バージョン（開発コード名：Whidbey）では、サーバ側のプログラミングがフル・サポートされ、データベース開発者もほかの.NET開発者と同じ高度な開発環境とツールを利用できるようになる。例えば、Visual Studioの前バージョンではT-SQLコードのデバッグをサポートしていたが、WhidbeyではVB.NETとC#でサーバ側のデータベース開発とデバッグが行える。さまざまな言語で記述され、複数の層で実行されるプロシージャを多数含むようなデータベース・アプリケーションでも、自在に扱えるようになる。

●ユーザー定義データ型とユーザー定義データ集計
　ユーザー定義データ型とは、よく使われるデータ型に一貫した名前を定義できるもので、大規模で複雑なソフトウェア開発プロジェクトに有用である。例えば、米国の社会保障番号を12桁のデータ型として定義し、複数のデータベース・テーブルで共有できる。SQL Server 2000でもデータベースの型システムを拡張可能だが、SQL Serverで定義済みのデータ型をベースにしなければならない。Yukonならば、自分で定義したどのような.NETデータ構造でもデータ型作成のベースにすることができる。これらのデータ型はSQL Serverでいったん定義して登録すれば、事前定義済みのシステム・データ型を使用するのと同様にデータベースで使用できる。例えば、テーブルの列の定義、関数へのパラメータ入力などに使用できる。

　T-SQLには、選択したデータ要素のグループに操作を行う関数のセット（集計関数という）もある。例えば、SUM関数はテーブル列の数値の合計を返す。Yukonの場合は開発者が自分で集計関数を定義でき、複雑な内部ロジックも任意に構築できる。複雑な為替変換や税計算をともなう国際企業の収益計算など、複雑な集計関数を作成するのに特に役立つだろう。

●ポータビリティ
　Yukonにおけるサーバ側のデータベース・プログラミングのための言語と開発環境は、ほかの多くの種類のソフトウェア開発プロジェクトと同じで、.NET言語とVisual Studioである。また、Yukonでサーバ側のデータ・アクセスに使用されるクラスとメソッドは、クライアント側のデータ・アクセスで使用されるものをベースとする。これにより2つのメリットが生まれる。1つ目はスキルの流用がきくことにある。例えば、VBアプリケーションの開発に専念してきた開発者は、サーバ側データベースの開発への移行が非常に簡単なことに気付くはずだ。2つ目は、クライアント層、中間層およびサーバ層間でのコードの移動が比較的分かりやすく行えることだ。システムのパフォーマンスを最適化しようとする開発者やシステム・アーキテクトには特に役に立つだろう。例えば、データ集約型のクライアント・コードをデータベースに移動させる場合も、追加修正せずに済みそうだ。

■安全性の高い拡張
　SQL Serverの現行バージョンにはT-SQLの代替ソリューションとして拡張ストアド・プロシージャ（XP）があるが、.NETの統合の方がサーバ側のプログラミングにはより安全な選択肢となる。拡張ストアド・プロシージャは、データベース・サーバで実行されるコードのブロックで、通常はCまたはC++で記述される。拡張ストアド・プロシージャを使えばT-SQLでは困難なサーバ側のコードでも記述できるが、1つ大きな欠点がある。T-SQLのコードとは異なり、拡張ストアド・プロシージャは安全性が低いのだ。拡張ストアド・プロシージャにバグがあると、データベース・サーバが停止する可能性もある。また拡張ストアド・プロシージャは、バッファ・オーバーフローなど、ワームやウイルスが攻撃に利用するセキュリティの脆弱性の原因となる可能性もある。

　.NET言語で記述したコードならより安全性が高い。これらのコードはCLRの管理のもとで実行され、そのため「マネージ・コード（管理されたコード）」と呼ばれる。CLRはコードが安全に実行できるかどうかを検証する処理を行う。例えば、バッファ・オーバーフロー防止に役立つよう設計された検査を自動実行する。

■T-SQLも進化
　.NET Frameworkの統合に加えて、MicrosoftはYukonにおいてT-SQLも改善する。

　例えば、Yukonでは共通テーブル式（CTE：Common Table Expressions）と呼ばれる機能が導入される。これは、ある巨大な多層構造の組織での従業員とその報告関係を含むデータベースなど、ネスト化された構造のデータベースに対するクエリが構築しやすくなるというものだ。CTEはまた、「組織の特定のマネージャを経由して報告を行う従業員をすべて検索せよ」というようなクエリへの応答に必要なT-SQLコード量を大幅に減らすこともできるようだ。

　YukonではT-SQLトランザクションのエラー処理も改善される。SQL Server 2000とそれ以前のバージョンでは、エラー処理は概して場当たり的に行われる。開発者自身が、エラーが発生しそうなステートメントそれぞれの後に適切なエラー処理コードを挿入する必要があった。最悪の場合、エラーによりトランザクションとトランザクションを処理するプロシージャが停止し、開発者にもエラー処理をする余地がなくなってしまう。Yukonでは、C#やVB.NETと同様の構造化例外処理が導入される。これらの機能を使用すると、開発者はSQL Server 2000ではトランザクションを停止させてしまうようなエラーでも確実に検出、記録し、エラーで中断したトランザクションをロールバックするといったことも行える。

XMLとWebサービスがますます重要に

　XMLとWebサービスが、重要な企業情報や文書（発注書や請求書など）を保存し、やり取りする手段として普及するにつれ、XMLデータの保存、検索および更新をいかに効率よく、信頼性が高く、かつトランザクション的な作法で行うかがますます重要になっている。

　SQL Server 2000もXMLをサポートしており、XML文書の内部コンポーネントを分解してデータベースのリレーショナル・テーブルに展開できる（XMLの「シュレッディング」と呼ばれるプロセス）。また、リレーショナル・テーブルをXML文書として表示することもできる。例えば、データベースを呼び出したアプリケーションに結果をXMLフォーマットで返すことも可能だ。また、XML文書を構造化されていないテキストあるいはキャラクタ・データとして保存できる。

　そのため、開発者がSQL Server 2000でXML文書を扱う場合、XMLをテキストとして保存するか、SQL Serverのデータ・テーブルへとシュレッディングするかを選ぶことができる。ただし前者の場合は、データに対して効率的にクエリを実行し、XML文書の要素に更新やそのほかの操作を行うSQL Serverの機能が制限される。後者の場合は、文書本来のフォーマットが失われてしまう。

■XMLデータ型をサポート
　YukonのXMLサポートは、次の点でSQL Server 2000のXML機能よりも改善されている。

●ネイティブのXMLデータ型
　新たに導入されたXML型により、XML文書を本来のフォーマットで扱える。XMLデータ型はSQL Serverデータの他の型と同様に扱われる。例えば、XMLを含むテーブルに対して、そのXMLのコンテンツについての索引を設定できる。また、XML型の列に入力されたXMLデータを、その列に関連付けられたスキーマを基準に検証し、データが正しくフォーマットされているか確認可能だ。しかし最も重要なのは、XML文書がデータベースに本来のフォーマットで保存される点だろう。これにより、XML文書にもSQL Serverデータのほかの型と同じ操作上のメリット（トランザクションの一貫性やロギングなど）が得られる。

●クエリ機能の向上
　Yukonには、XML照会言語（XQuery）と呼ばれる、新しいクエリ言語が実装される。XML文書に適したクエリを構築するよう設計されたものだ。また、MicrosoftはYukonのXQueryを2つの重要な点で拡張する。第1に、YukonがサポートするXQueryは、リレーショナル・データとXMLデータが混在するテーブル（XMLデータ型の列とほかのSQLデータ型を含む列が混在するテーブルなど）に対してもクエリが実行できる。第2に、YukonのXQueryはXMLでのデータ操作をサポートしており、XML列から問い合わせ結果となるデータ・セットを返すだけではなく、その列のXMLデータ内の要素を更新、挿入、および削除するクエリを記述可能だ。

●Webサービスへの直接アクセス
　SQL Server 2000にはアドオンが導入され、MicrosoftのInternet Information Services（IIS）との組み合わせにより、データベース・ロジック（ストアド・プロシージャなど）をWebサービスとして公開することができた。このプロセスは、とりわけ、SQL Serverを異種のシステムが混在するビジネス・アプリケーションと統合するのに有効である。例えば、ロジックはLinuxサーバ上にあり、ビジネス・データはSQL Serverデータベースに保存されているようなビジネス・アプリケーションである。

　Yukonでは、このプロセスから中間層が取り除かれる。IISなしで直接SQL ServerにHTTPアクセスする機能がサポートされ、展開が容易になり、運用上のコストと複雑さが軽減される。（図「YukonベースのWebサービス」を参照。）

YukonベースのWebサービス

図に示すのはYukonベースのWebサービスを単純化したものだ。（メーリング・リストへの登録などのために）顧客自身に名前と連絡先を企業の顧客データベースに入力してもらい、その企業のスタッフがそれらのレコードにアクセスできるというものである。顧客は、企業が運用するLinuxベースのWebサービス・アプリケーションへインターネットを経由して接続することにより、自分のレコードを追加する。企業のスタッフは、会社のイントラネット内にあるWindows SharePoint Services（WSS）サイト上で運用されている顧客管理（CRM）セルフサービス・アプリケーションにより顧客のレコードにアクセスする。レコードはWindows Server 2003で稼働するYukon SQL Serverに保存され、LinuxおよびWSSベースのアプリケーションとの間で、ハイパーテキスト転送プロトコル（HTTP）によりXML文書としてやり取りされる。 　Yukonでは、図に示すようなWebサービスの構築を容易にする改善がいくつかなされている。例えば、HTTPによりXMLを送受信する機能が組み込まれている。従来は別のWebサーバで実行するアドオンが必要だったものだ。図のYukon SQL Serverの枠内にある「Customer Sign-Up（顧客サインアップ）」と「View Customers（顧客表示）」という名称のついたボックスは、Webサービスとして公開されるストアド・プロシージャである。これらのプロシージャはVisual Studioツール・セットを使って.NET言語（VB.NETなど）で記述でき、プログラミングとデバッグが容易に行える。さらに、YukonではXMLがネイティブ・データ型としてサポートされる。つまり、顧客レコードをSQL Serverの列にネイティブ・フォーマットで保存し、スキーマを基準に検証し、フォーマットが適切かどうかを確認した上でデータベースに登録できる。

課題と検討事項

　YukonはSQL Serverを大幅に見直したもので、データベース製品のプログラミングを革新する可能性もある。しかし、こうした変更によりいくつかの課題と検討事項も生じる。Yukonを評価する場合には次の点を考慮する必要があるだろう。

●T-SQLの知識はやはり必要
　T-SQLは.NETのプログラム言語で置き換えられるわけではない。実際には、データ定義とデータ操作はやはりT-SQLで行う。例えば、データベースから行を選択するC#で記述されたストアド・プロシージャの場合、T-SQLの適切な選択コマンドを含む文字列を定義しなければならない。この文字列がC#のメソッド・コールによりT-SQLパーサーに受け渡された後、実行されることになる。従って、サーバ側のデータベース開発者は、少なくともT-SQLの基本には通じておく必要があるだろう。

●T-SQLかマネージ・コードか?
　マネージド・コードとT-SQLをいつ、どこで使い分けるかについて、いくつか複雑な意思決定をしなければならない。.NET言語は、特定の操作（テーブルまたは索引の作成、テーブルの行の挿入、更新、削除など）をT-SQLに依存するため、これらの操作を.NETで実行するとオーバーヘッドが生じる。従って、このような種類の操作を主に含むプロシージャや関数はT-SQLで記述すればパフォーマンスが向上する。一方、複雑なアルゴリズムや演算ステップを含むプロシージャは、.NET言語を利用した方が、記述が容易で実行速度も速い。

●ほかの.NET言語のサポート
　MicrosoftはYukonでVB.NETとC#をサポートする予定だ。ほかの.NET言語もゆくゆくサポートされる可能性がある（例えば、MicrosoftはJ#のサポートを検討している）。

●コードをどこに置くか？
　最近のビジネス・システムやアプリケーションでは、複雑なビジネス・ロジックはSQL Serverの外で実行されることが多い。具体的には、クライアントとデータベース・サーバの両方に接続する中間層のサーバなどがそうだ。これには主に2つの理由がある。第1に、T-SQLは機能的に貧弱であるため、大規模で複雑な演算を要するシステムの構築には最適な選択肢ではない。第2に、システム・アーキテクトの多くが演算集約的なロジックをデータベース・サーバから切り離す傾向にある。高速で効率的なデータの検索、更新、挿入といったデータベースの主要なジョブが干渉されるのを避けるためだ。

　Yukonは第1の問題には対応しているが、大量の演算コードをデータベース・サーバに置くとサーバのパフォーマンス、ひいてはビジネス・システムやアプリケーション全体のパフォーマンスにも影響するという事実に変わりはない。開発者とアーキテクトは、プロシージャや関数からSQL Serverのデータへ直接インプロセスでアクセスする場合に得られるパフォーマンスの向上と、データベース・サーバ上にあまりに大量のコードを置くと間違いなく発生するパフォーマンスへの悪影響とのバランスを慎重に検討する必要があるだろう。

今後のリリース・マイルストーン

　2003年10月のPDC（Professional Developers Conference）で、Microsoftは製品サンプルを含むYukonキット（正式ベータ1の初期バージョンで、製品紹介のみのベータ）、暫定版製品マニュアル、およびいくつかのテクニカル・ホワイト・ペーパーを配布した。

　より製品に近いベータ2は2004年の上半期にリリースされる見込みだ。製品版のリリースは2004年末の予定である。

参考資料

• Yukonに関するテクニカル・ホワイト・ペーパーとそのほかの情報については、http://www.microsoft.com/japan/sql/yukon/productinfo/default.asp
  を参照。

	関連記事
		見え始めた「Yukon」の全貌（Windows Server Insider／Insider's Eye）
		PDC 2003レポート No.1　Longhorn、Yukon、Whidbey。次世代コンピューティングに高まる開発者の熱き期待（Windows Server Insider／Insider's Eye）
		.NET開発者のためのPDC 2003レポート（Insider.NET）
		【連載】初めてのSQL Server 2000（Windows Server Insider）

Directions on Microsoft日本語版 本記事は、（株）メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申し込みができます。

　

「Insider's Eye」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）