LINQが目指すもの：Microsoft Tech・Ed 2007 Yokohama Report

データソースを選ばずに利用できるのがLINQの優れた点だ。では、そこに投入された考えや技術とはどのようなものなのだろうか。

[下村恭（ハンズシステム），ITmedia]

　Tech・Ed 2007でも注目度が高いLINQは、単なる言語組み込み型のクエリというだけのものではない。その裏に隠されているものは、壮大な未来を予見させる。

　前回、「LINQってどんなもの？」で説明したように、LINQテクノロジーを使うとデータソースを選ばないクエリ処理を実現できる。SQL Server内のデータであっても、メモリ上のCLRオブジェクトのコレクションであっても、まったく同じ文法でクエリを記述できるのを見てもらった。では、なぜこんなことが可能になったのだろうか。よく考えてみれば、とても不思議なことだ。

　現在一般的に使用されているデータのモデリング手法は、RDBMS使用を前提としたリレーショナルデータモデルと、UMLなどの手法を用いて設計されるオブジェクトデータモデルの2種類が代表的なものだ。Tech・Ed 2007でLINQについてのスペシャルセッションを担当した赤間信幸氏（マイクロソフト コンサルティングサービス統括本部 プリンシパルコンサルタント）は、セッション内で「この2つの手法には、それぞれトレードオフがある。」と語った。それは、リレーショナルデータモデルの場合はSQLを用いた検索や一括処理が得意だが、継承関係を表現したりといったデータの構造表現力に乏しい。逆にオブジェクトデータモデルでは、継承関係などを的確に表現できるが、ループを回すようなコードを自力で書く必要があり、データの一括処理などが不得手というのが理由だ。そのため、現実的にはプログラム上でのデータの表現にオブジェクトデータモデルを使用しても、実際のデータの格納にはRDBMSを使用し、格納されたデータをプログラムで使用したり、プログラム上のデータを保管する場合に、お互いにデータ受け渡しする必要が出てきている。いわゆる「インピーダンスミスマッチ問題」だ。

　このようなインピーダンスミスマッチ問題に対処するために、さまざまなツールが考案され使用されてきた。SQL ServerなどのRDBMSに接続し、実際に格納されているデータベースのスキーマを取得して、テーブルを格納するためのクラスを表現するコードを自動的に吐き出すようなツールはどこにでもある。また、UMLなどで設計したデータクラスをRDBMSのスキーマに変換するツールもある。

　実際、Visual Studio 2008でLINQ to SQL経由でLINQを使う場合も、データベースエクスプローラからテーブルをドラッグ＆ドロップするだけで、テーブルデータを格納するための簡素（Datasetクラスと比べて、メソッドなどがデータを表現するための最低限しかないため）なクラスを自動生成してくれるようになっている。

　だからと言って、LINQもインピーダンスミスマッチに対応するツールを組み合わせて出来ているというわけではない。LINQにはもっと壮大な構想が画されているのである。

　そもそも、インピーダンスミスマッチ問題が起こる理由は何だろうか。リレーショナルデータモデルもオブジェクトデータモデルも、ともに論理データモデル（LDM）を記述するための手法だ。それぞれに、実装に適した、言い換えれば結合の強い物理データモデル（PDM）があるため、LDMの段階でインピーダンスミスマッチが起こっても不思議ではない。これらの手法を統一的に扱おうとした場合、さらに上位のレイヤである概念データモデル（CDM）でのデータモデリングを行う必要がある。だが、CDMレベルでの確立した手法や処理手順がないのが現状だ。

　ここに一石を投じるのが、LINQの基礎技術となるADO.NET Entity Framework（EF）だ。EFは、.NET Frameworkの世界に、概念データモデリング手法としてEntity Data Model（EDM）と、このEDMに対するクエリ言語としてのeSQLを導入した。このおかげで、CDMのレイヤのままでデータの定義やクエリの記述ができるようになったのだ。つまり、物理的なデータ格納方法に縛られない概念レベルでデータを定義し、この概念データに対してのクエリを記述することで、あらゆるデータを表現できるようになり、さらにクエリの記述もできるというわけだ。つまり、LINQで記述するクエリは、論理データモデルに対するクエリではなく、概念データモデルに対するクエリとなっているのだ。

　実際にクエリを実行するに当たっては、それぞれの物理データモデルに合ったクエリに変換しなければならないが、これをLINQプロバイダが受け持つことになる。当然ながら、概念データモデルから論理データモデルへのマッピングも不可欠となる。先に書いた、データベースエクスプローラのテーブルからデータクラスを自動生成する仕組みは、まさにこのマッピングを逆方向に行っているというわけだ。

　このようにLINQおよびADO.NET Entity Frameworkは、データを扱うやり方を根本から考え直させるものであり、将来がとても期待できる重要なテクノロジーと言える。しかし、未成熟であるということも考慮する必要がある。.NET Framework 3.5に含まれるLINQ／EFは、まだバージョン1であり、実際に動作させるに当たっての制限事項もある。そのため、実際に開発現場でLINQを使う場合には注意が必要だ。

　LINQ／EF v1における制限事項とは、1つは、LINQ to SQLでSELECTは問題ないがINSERT／DELETE／UPDATEをサポートしていないという点だ。このため、LINQでデータの一括更新処理がサポートされない。また、楽観同時実行制御機能付きのデータ更新、つまりトランザクション処理は可能だが、悲観同時実行制御がサポートされないという問題もある。このため、現場でLINQを使用する場合は、参照系アプリケーションでのクエリ処理や、メモリ内でのデータ変形加工処理に限って導入することになるだろう。

　こうした制限はあるものの、メモリ内のデータを扱う場合には、インテリセンスが利き、コンパイル時に型チェックも行われることを考えれば、LINQを使うメリットは大きい。LINQ to Objectを使用すれば、従来のDatasetクラスとの併用も可能であるので、使用できる場所は限定されるとは言え、利用価値は高いだろう。加えて、LINQ／EFによって、次世代のデータ処理手法の一端をのぞかせてもらったというインパクトは大きい。ここしばらくの間はLINQテクノロジーから目を離すことができない。