最近になってデータベースを使い始めた人や，「SQL Server 2005」の新機能をチェックしている人にとって，共通言語ランタイム（CLR）とSQL Server 2005の関係は，ちょっとした謎に感じられることだろう。今回はデータベース技術者が知っておくべきCLRとSQL Serverの関わり合いに関する事実を紹介する。

　多くの.NETプログラマーは，CLRが本質的には.NETアプリケーションとOSの間に存在する「ランタイム・レイヤー」であることを知っている。CLRの仕事は，.NETプログラムから出された命令を，Windows OSが実行できるネイティブのWin32命令に変換することだ。CLRによってもたらされる主な利点は，アプリケーションのセキュリティと安定性が向上することだ。さらにCLRは，メモリー・リークやバッファ・オーバーフローのぜい弱性といった問題のあるアプリケーションからOSを守る上でも，力を発揮する。CLRの根底にある発想は新しいものではない。Javaとそれに関連するJava Virtual Machine（JVM）レイヤーが，この種のアーキテクチャを用いた最初のプログラミング言語である。

　それではCLRとSQL Serverは，どのようにかかわり合っているのだろうか？

　CLRは，SQL Server Expressを含むすべてのSQL Server 2005と統合されている。CLRオブジェクトを使ったデータベース・オブジェクトを作成することには，いくつかの重要な利点がある。まず第一に，Visual Basic（VB）やC#のような.NET言語を使うことによって，ストアド・プロシージャやトリガ，関数といったデータベース・オブジェクトの作成が可能になることだ。

　CLR登場前は，データベース・オブジェクトを作りたければ，T-SQLコマンドを使わなければならなかった。T-SQLは優れた集中指向のデータ検索能力を持っているものの，複雑なロジックや数学的演算の処理という点では，.NET言語の方が勝っている。CLRを使うことによって，SQL Serverにはデータベース・オブジェクト・プログラミング機能が追加されるのだ。

　第二に，T-SQLはリレーショナル・データベース指向の言語として設計されているため，リレーショナル・データベースの外側にあるリソースにアクセスする機能は含まれていない。言い換えると，T-SQLはファイル・システムやレジストリなどの読み出し・書き込みができないのである。

　そこでMicrosoftは，SQL Serverにリレーショナル・データベースの外側にあるリソースにアクセスする機能を付加するために「拡張ストアド・プロシージャ」という機能を追加した。これは本質的には，ネイティブのWin32プログラムであり，SQL Serverエンジンと同じメモリー上のプロセス空間内で作動する。拡張ストアド・プロシージャは，外部リソースへのアクセスを提供することによって，SQL Serverに足りない機能を補完している。しかしこれらのプロシージャはデータベース・エンジンと同じプロセスで動作するため，拡張ストアド・プロシージャにバグがあると，SQL Serverエンジンがダウンしてしまうのだ。これでは理想的な状態とは言えない。

　ところがCLRをSQL Server Expressに統合すると，これらの問題はどちらも解決する。CLRオブジェクトは，ファイル・システムやレジストリといった外部リソースにアクセスできる。だがCLRオブジェクトはCLRの制限内で作動するので，SQL Serverエンジンから独立している。従ってバグがあっても，コアのデータ・ベースエンジンの機能に影響を及ぼすことはない。

　SQL Server 2005の製品群にCLRを統合することによって，SQL Server Expressに機能が追加され，複雑なロジックを含むデータベース・オブジェクトを作成したり，外部リソースにアクセスしたりできるようになった。CLRの利点を引き出すには，何らかの.NET言語を使ってCLRオブジェクトをプログラムし，SQL Server Surface Area Configuration（SQL Serverセキュリティ構成）ツールを使って，CLR機能を有効にする必要がある（セキュリティ上の理由から，CLRはデフォルトでは無効になっている）。読者の皆様がCLRのことを把握し，CLRはSQL Serverの開発ツールの1つであるということを理解するのに，この記事が少しでも役に立てば幸いである。