連載：ADO.NET Entity Framework入門 第1回　最新DBアクセス・フレームワークの基本的な考え方 WINGSプロジェクト　土井 毅 著／山田 祥寛 監修 2010/06/04
Page1 Page2 Page3 Page4

■論理モデルによるプログラミングと概念モデルによるプログラミング

　開発の現場では、論理モデルとしてのリレーショナル・モデルは、リレーショナル・データベースとともに広く普及しているといってよいだろう。リレーショナル・モデルに慣れ親しんでいるため、概念モデルによる設計を飛ばして、要件から一気にリレーショナル・モデルを用いた論理モデル設計に入ってしまう開発者も多い（かくいう著者もその口だ）。

　しかし、プログラミング言語からSQL文を用いてリレーショナル・モデルを直接扱うというのは、何かと面倒なものだ。現在のプログラミング言語の主流であるオブジェクト指向言語では、前項で挙げた概念モデルを直接実装できるが、データの取得、保存といった際には、リレーショナル・モデルを基に構築されたデータベースに合わせ、モデルの変換を行う必要がある。これには例えば、SQL文でSELECT（取得）したデータをオブジェクトに変換したり、オブジェクトに加えられた変更内容をSQLのUPDATE（更新）文に変換したり、といった処理が含まれる。

　また、前項で述べたとおり、概念モデルと論理モデルはまったく同一ではない。例えば多対多の関係を表す際、概念モデルではそのまま表現できるのに対し、論理モデルにおいてはリレーショナル・モデルの限界ゆえに、中間テーブルの追加などが必要となる。論理モデルと概念モデル間のこうした違いは「インピーダンス・ミスマッチ」と呼ばれる*2（図2）。

*2 インピーダンス・ミスマッチはもともと電気工学の用語で、入出力のインピーダンスが不整合な様子を表すが、転じてソフトウェア・モデル間の不整合を表す用語となっている。

図2 インピーダンス・ミスマッチの例

　こうしたモデル変換で生じる問題に対応して、生産性を向上するために、これまでよく用いられてきたのが「O/Rマッパー」（Object / Relational Mapper）と呼ばれるフレームワークだ。

　O/Rマッパーはオブジェクト・モデル（Object Model）とリレーショナル・モデル（Relational Model）を仲立ちし、オブジェクト・モデルを用いたデータ・アクセスを可能とする。具体的には、データベースのテーブルをオブジェクトにマッピングし、リレーションシップをオブジェクト同士の参照としたオブジェクト・モデルを構築できる。これにより、オブジェクトに対する操作を行うと、背後でO/RマッパーがSQL文を発行して処理を行ってくれるため、SQL文を直接扱う場面は減り、生産性が向上するというわけだ。

図3 O/Rマッパーによる、リレーショナル・モデルとオブジェクト・モデルのマッピング例

　O/Rマッパーはすでに多くの環境で実装が進んでおり、JavaにはHibernateやCayenne、RubyにはRuby on Railsなどで使用されるActiveRecord、.NETには前述のHibernateの移植である「NHibernate for .NET」や、「ibatis.net」などのO/Rマッパーが存在する。また、ADO.NETで使用することのできる厳密な型指定を行ったDataSet（＝データセット）や、LINQ to SQLといった技術も、一種のO/Rマッパーと呼ぶことができるかもしれない。

　しかしながら、O/Rマッパーの説明や図から気付いた方も多いかもしれないが、O/Rマッパーは基本的に「テーブルとオブジェクトを1対1に対応させる」論理モデルを基にしたフレームワークであるため、概念モデルと論理モデル間のインピーダンス・ミスマッチへの根本的な解決策ではない。

　一方、Entity Frameworkが目指すのは、概念モデルによるプログラミングである。Entity Frameworkではエンティティ・データ・モデル（Entity Data Model、以降、EDM）という概念モデルを採用し、開発者はこのEDMに対して処理を行うことで、透過的にデータベースに対する操作を行うことができる。EDMはエンティティ、アソシエーション*3、継承*4といった要素を用いて構築されるモデルである。Entity Frameworkは、このEDMとリレーショナル・モデルの間で図4／表1のようなマッピングを行っている。

*3 エンティティ間の関連。リレーションシップに対応。 *4 オブジェクト指向言語の継承とほぼ同一。

図4 EDMとリレーショナル・モデル間のマッピング

CSDL、SSDL、MSLについては表1を参照。

名称 役割 CSDL（Conceptual Schema Definition Language） 概念スキーマ定義言語 概念モデルであるEDMを定義する SSDL（Store Schema Definition Language） ストア・スキーマ定義言語 論理モデルを定義する MSL（Mapping Schema Language） マッピング・スキーマ言語 CSDLとSSDLの間をマッピングする

表1 Entity Frameworkで用いられる3種類の言語

　前述のO/Rマッパーの図3では、オブジェクト・モデルがリレーショナル・モデルの限界に合わせて作られていたのに対し（本来、オブジェクト・モデルに中間テーブル・クラスは不要）、図4では、CSDLで定義された概念モデルは、SSDLで定義された論理モデルの限界による影響を受けていないことに注目したい。

　Entity FrameworkはCSDL、SSDL、MSLを用いることで、概念モデルと論理モデル、各モデルに対する操作をどのようにマッピングするかを定義する。これにより、開発者は概念モデルを使った実装を行うことができる。そして、以降のサンプルで見るとおり、Visual Studioを使うことで、これらの3種類のXMLを意識することなく、概念モデルおよび論理モデルの設計を行うことができる。

［参考］O/Rマッパーの多機能化とEntity Framework 　本文ではO/Rマッパーの限界について触れたが、O/Rマッパーによっては、テーブルとオブジェクトの1対1対応にとどまらず、オブジェクトの多対多関係など、リレーショナル・モデルでは直接表現できないモデルについてもサポートするものがある。こうした多機能なO/Rマッパーを使えば、Entity Frameworkの目指す概念モデルによるプログラミングと類似の機能を実現できる。 　そういう意味では、「Entity Frameworkは既存のO/Rマッパーより優れている」と単純にいうことはできない。O/Rマッパーには、多くのソフトウェア開発に用いられてきた実績に基づくノウハウがあり、特定の分野ではEntity Framework以上の機能を実現している。 　Entity Frameworkについては、当初よりO/Rマッパーを支持する開発者らとの間で白熱した議論が続いており、実際、.NET 4で搭載された新機能の中には、コミュニティからリクエストされた機能もいくつか含まれている。 　本連載を通じてEntity Frameworkの特徴について紹介していくが、Entity Frameworkがアプリケーション開発における唯一の解法ではない、という点を意識し、それぞれの技術のメリット・デメリットを検討してほしい。 　.NET上で使用可能なO/Rマッパーについては、以下の記事を参照のこと。 ASP.NETで実践するO/Rマッピング（NHibernate編） ASP.NETで実践するO/Rマッピング（iBATIS.NET編）

INDEX
	ADO.NET Entity Framework入門
	第1回　最新DBアクセス・フレームワークの基本的な考え方
	1．ADO.NET Entity Framework概要
	2．論理モデルによるプログラミングと概念モデルによるプログラミング
	3．EDMの作成と論理モデルの生成
	4．論理モデルの自動生成

　

「ADO.NET Entity Framework入門」

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