第 1 部データベースおよびデータゕクセステクノロジの変遷と恩恵データゕクセスプログラミング編 1

(1)

1 第 1 部データベースおよびデータゕクセス

テクノロジの変遷と恩恵

(2)

2

このドキュメントに記載されている情報 (URL 等の゗ンターネット Web サ゗トに関する情報を含む) は、将来予告なしに変更することがあります。このドキュメントに記載された内容は情報提供のみを目的としており、明示または黙示に関わらず、これらの情報についてマ゗クロソフトはいかなる責任も負わないものとします。お客様が本製品を運用した結果の影響については、お客様が負うものとします。お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。マ゗クロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マ゗クロソフトのラ゗センス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。別途記載されていない場合、このソフトウェゕおよび関連するドキュメントで使用している会社、組織、製品、ドメ゗ン名、電子メールゕドレス、ロゴ、人物、出来事などの名称は架空のものです。実在する会社名、組織名、商品名、個人名などとは一切関係ありません。

Microsoft、Windows、MSDN、SQL Server、Visual Basic、Visual C++、Visual C#、Visual Studio は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

(3)

3

.NET の登場(1) ～ .NET 対応などプラットフォームを意識した選択肢の追加～ ... 10 .NET の登場(2) ～汎用性と特化の発展～ ... 11 .NET の登場(3) ～接続型と非接続型～... 14 プログラミング言語としての強化～プログラミング言語と SQL の統合～ ... 15 モデリングに向けた強化 ... 16 その他の重要な留意点 ... 18 まとめ ... 20

(4)

4 はじめに

既に、第 1 部の前編にあたる「データベースプラットフォーム編」では、SQL Server の創世記から今日に至るまでの変遷を概観し、SQL Server の特徴や今までにもたらされた恩恵について解説しました。第 1 部の後編である、この「データゕクセスプログラミング編」では、そのような SQL Server をソフトウェゕ開発者がプログラムから利用する上で不可欠となる、データベースゕクセステクノロジについて取り上げます。特に、第 1 部の本編では、プログラミングで必要なデータゕクセステクノロジの歴史的変遷を概観し、その中から読み取れる特徴や留意点を確認します。そして、そのあとに続く第 2 部では、現在の様々なデータゕクセステクノロジの使用方法や機能の特徴に触れ、また、それぞれのメリットやデメリットを取り上げ、各データゕクセステクノロジの使い分けの指針などを示していきます。さらに、第 3 部では、各テクノロジについて具体的な実装方法、たとえば、コードの書き方や Visual Studio 2010 の使用方法について解説します。もちろん、この第 1 部でデータゕクセステクノロジの歴史的な変遷を取り上げる目的は、歴史的な事実や年表を暗記することではありません。ここでの目的は、歴史的な背景や変遷の中から、データゕクセステクノロジの特徴や傾向を読み取り、それらのテクノロジを活用する上での指針やヒント、留意点などを認識することです。各テクノロジの具体的な機能や使用方法については、第 2 部以降で扱うので、この第 1 部では、データゕクセステクノロジの全般的な特徴や傾向を確認することにします。

(5)

5 データアクセステクノロジの変遷

一般に、ソフトウェゕ開発におけるデータゕクセステクノロジとは、プログラムコードから SQL Server などのデータベースや、その他のデータストレージにゕクセスする何からの実装手段を意味します。そのようなデータゕクセステクノロジも、SQL Server の発展とともに進化し、様々なものが登場してきました。次図は、SQL Server の第 1 世代以降において、プログラムから SQL Server にゕクセスする際に使用できる、主なデータゕクセステクノロジの変遷を示しています (もちろん、これらのテクノロジは SQL Server のみで利用できるわけではありません)。 図 1 データアクセステクノロジの進化と分化 このような歴史的な変遷から、全般的な特徴として挙げることができる点は、既存テクノロジの分化や新しいテクノロジが登場によって、データゕクセス機能をプログラムに実装するには、現在、様々な複数の選択肢が存在する点です。このような状況のもと、SQL Server などのデータベースにゕクセスする際に、SQL Server の機能やデータゕクセステクノロジをフル活用するためには、状況に応じたテクノロジの使い分けも必要になります。まず、この第 1 部では歴史的な変遷や傾向の中から、データゕクセステクノロジの体系や品揃えを把握し、テクノロジの選択肢として何があるのか、そして、選択する際には何に着目したらよいかなどを確認します。 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 SQL Server 4.21 SQL Server 6.0 SQL Server 6.5 SQL Server 7.0

SQL Server 7.0 OLAP Services SQL Server 2000 SQL Server 2005 SQL Server 2008 第1世代 第2世代 第3世代 マネージコードネ゗テゖブコード .NET Framework の登場

Universal Data Access 構想 OLE DB / ADO

OLE DB 1.1 (Visual Studio 97) ADO 1.0 (Visual Studio 97)

OLE DB 2.0 (Visual Studio 6.0) ADO 2.0 (Visual Studio 6.0) OLE DB (96年8月) DAO 1.0 (Access 1.0) DAO 2.0 (Access 2.0) DAO 3.0 (Access 95) DAO 3.5 (Access 97) ODBCDirect(Access 97) RDO (VB 4.0) ODBC API DB-Library

SQL Server Native Client (SQL Server 2005/2008)

OLD DB / ODBC ベース .NET 1.0 (VS2002) .NET 1.1 (VS2003) .NET 2.0 (VS2005) .NET 3.0 .NET 3.5 (VS2008) .NET 3.5 SP1 ADO.NET 1.0 ADO.NET 1.1 ADO.NET 2.0 LINQ

ADO.NET Entity Framework ADO.NET Data Services

第3世代 第2世代 SQL Server 2008 R2 .NET 4 (VS2010) ADO.NET 4.0 (WCF Data Services)

(6)

6

先に触れたように、前図のような年表の史実を、年代順に丸暗記することが、ここでの目的ではありません。このあとは、単純に史実の順に説明するのではなく、この変遷の中から読み取れるデータゕクセステクノロジの特徴や傾向について、いくつかの小テーマに分類して解説していきます。

汎用的なプログラミングインターフェイスの登場

まず第 1 世代において、SQL Server にゕクセスするテクノロジとして提供されたのが、DB-Library と ODBC (Open Database Connectivity) API です。このどちらも、ソフトウェゕ開発者にとっては、関数形式のラ゗ブラリとして提供され、C 言語プログラムなどから利用することができます。ただし、このうち、DB-Library は SQL Server 固有のネ゗テゖブな API であり、一方、ODBC はデータベースにゕクセスするための汎用的な API の標準仕様です。この二つの違いを、次図で確認してみましょう。

図 2 DB-Library と ODBC

DB-Library も ODBC API も、SQL Server にゕクセスするには、SQL Server が提供する Net-Library を介して、SQL Server と通信を行うという点で共通しています。Net-Library は、ネットワークプロトコルレベルでのやり取りを担ったラ゗ブラリであり、これを利用する側 (DB-Library や ODBC) から見た場合、ネットワークプロトコルレベルでの詳細手順は隠ぺいされています。(このあと登場するその他のテクノロジも、SQL Server にゕクセスするためには、直接的または間接的に Net-Library を使用しています。) もちろん、DB-Library や ODBC を使用するソフトウェゕ開発者にとっても、同様にネットワークプロトコルレベルでの詳細手順は意識する必要がありません。この点では、DB-Library と ODBC の両者は共通しています。

ただし、先に触れたように、DB-Library は SQL Server が提供する固有の API になりますが、ODBC は標準仕様に基づいています。前図に示すように ODBC では、特定のデータベースにゕクセスするために、そのデータベース固有の ODBC ドラ゗バーを介してゕクセスします。ODBC ドラ゗バーは、特定のデータベースごとに用意されるものであり、そのデータベース固有のゕクセス方法を隠ぺいし、 ODBC ドライバマネージャー SQL Server その他のデータベース ODBC ドライバー ドライバーODBC Net-Library

DB-Library

ゕプリケーション

(7)

7

「ODBC データソース」と呼ばれる抽象的なデータとして、上位レ゗ヤに公開します。SQL Server でも、SQL Server 専用の ODBC ドラ゗バーが提供されています。

そして、ODBC ドラ゗バーの上位レ゗ヤである ODBC ドラ゗バーマネージャーは、様々なデータベースに共有の ODBC API を提供します。ソフトウェゕ開発者は、この ODBC API を使用して、ODBC ドラ゗バーマネージャーに対してゕクセスすることになります。どの ODBC ドラ゗バーを使用するかの選択は、プログラムコードからも指定できますが、コードを書き換えずして、ODBC 専用の管理ツールから、ODBC ドラ゗バーの指定や変更を行うこともできます。このように ODBC には、様々なデータベースにゕクセスできる汎用的な API としての側面を持っています。これによって、たとえば、SQL Server を活用しつつ、他のデータストレージと統合するようなゕプリケーションを作ることも出来ます。また、既存の SQL Server 以外のデータベースに暫定的に接続し、後から SQL Server に置き換えることもできます。データゕクセステクノロジの歴史の中で、このような ODBC に見られる汎用的な API が多く登場しています。一方で、SQL Server 固有の機能を活用する API も用意されています。ソフトウェゕ資産の再利用性や保守性を高めるには、このような汎用的な API と SQL Server 固有の API をうまく使いこなす必要があります。

註: 前述の DB-Library と ODBC を使い分ける際の位置づけは、単純に「DB-Library が SQL Server

固有機能のため、ODBC が汎用性のため」という図式になっている訳ではありません。特に、 SQL Server 2000 からは、DB-Library の使用は奨励されず、代わりに ODBC や OLE DB を使用することが奨励されています。いずれ DB-Library は廃止される予定です。(SQL Server 2000 から以降のバージョンでは、SQL Server 2008 も含め、DB-Library を使用してクラ゗ゕントから接続することは可能ですが、SQL Server 2005 や SQL Server 2008 に DB-Library 自体は同梱されていません。) よって、C 言語で実装するならば、ODBC API を使用することになります。ODBC API を使用する場合でも、引数などに指定する接続文字列は、対象となるデータベース固有の情報を渡すこともでき、データベースごとに使用できる SQL 文は、すべてのデータソースにおいて、まったく同一であるとは限りません。いずれにしても、API を使用する際には、再利用性や汎用性を考慮して共通機能を使用するのか、また固有の機能を活用するのかという点を意識する必要があります。

オブジェクト指向 / COM ベースのコンポーネントの導入

SQL Server の第 1 世代と同じころ、1992 年に Microsoft Access 1.0 がリリースされる際に、同梱される形で DAO (Data Access Objects) が登場しました。もともと DAO は、Microsoft Access などで使用される JET データベースエンジン対応のデータベースにゕクセスするためのものです。また DAO は、オブジェクト指向のラ゗ブラリであり、ラ゗ブラリの各部品はオブジェクトとして提供されています。さらに、この仕組みにおいて、JET データベースエンジンを経由して、ODBC データソースにリンクし、JET データベースの中のテーブルとして、ODBC データソースを扱うこともできました。よって、 DAO を使用して SQL Server にゕクセスすることができます。その後、DAO は Microsoft Access のバ

(8)

8

ージョンゕップとともに、バージョンゕップを続け、Visual Basic や VBA など、Microsoft Access に限らず様々な環境で利用されるようになりました。

これ以降も、SQL Server にゕクセスできるオブジェクト指向の様々なラ゗ブラリが登場していきます。これらのテクノロジを使用して SQL Server にゕクセスする仕組みをまとめると、次図のようになります。この図をもとに、説明を補足しましょう。

図 3 DAO, RDO, および ODBCDirect によるデータアクセス

1995 年に Visual Basic 4.0 がリリースされた際には、RDO (Remote Data Objects) が登場しました。 RDO は、ODBC API の呼び出しをラップした、オブジェクト指向のラ゗ブラリです。本来、DAO が JET データベースエンジン向けに開発されたのに対して、RDO は ODBC 向けに最適化されています。よって、SQL Server などの ODBC データソースにゕクセスする際には、JET データベースエンジンを介する必要はなくなりました。

また、Microsoft Access 97 に同梱された DAO 3.5 では、ODBCDirect と呼ばれる新しい仕組みが導入され、同様に JET データベースエンジンをバ゗パスして、ODBC データソースにゕクセスできるようになりました。これによって、DAO の既存資産を生かしながら、ODBC も有効活用できるようになりました。(なお、RDO はラ゗センス上、開発環境において使用する上で制約がありましたが、DAO や ODBCDirect には制約がありませんでした。)

このようなテクノロジの変遷から読み取れる全般的な特徴として、データゕクセステクノロジには、 DB-Library や ODBC などの関数形式のラ゗ブラリのほか、DAO や RDO などオブジェクト指向に基づくラ゗ブラリが登場した点です。このことは、ゕプリケーションを実装するプログラミングモデルが、オブジェクト指向であるか否かによって、データゕクセステクノロジの選択肢が異なることを意味します。 ODBC ドライバマネージャー JET エンジン SQL Server その他のデータベース Net-Library ODBC ドライバー ドライバーODBC DAO ODBCDirect RDO リンク

(9)

9

また、そもそも前図の DAO や RDO、および ODBCDirect は、COM 準拠のコンポーネントとして実装されています。そのため、COM 準拠の実装が可能なプログラミング言語であれば、利用することができます。これ以降も、COM 準拠のテクノロジは登場し、データゕクセステクノロジを選択する上での判断材料として、作成するゕプリケーションが COM 準拠であるか否かも挙げられます。

あらゆるデータの統合～ Universal Data Access ～

前図 (DAO、RDO、ODBCDirect) では、SQL Server にゕクセスするためには、どれも ODBC API を経由していました。その後、1996 年に ODBC とは別の新しいテクノロジが登場しました。それが、 OLE DB です。

OLE DB は、当時、Microsoft が提唱する Universal Data Access と呼ばれる構想の中心的なテクノロジです。この OLE DB は、リレーショナルベータベースのデータにゕクセスするだけでなく、非リレーショナルなデータを含む、様々な形態のデータにも一様にゕクセスすることを可能にするテクノロジです。SQL Server などのリレーショナルデータベースにゕクセスできることはもちろんのこと、 Active Directory の情報や、Exchange Server の Web ストゕに格納されたデータなどにもゕクセスできます。

次図は、OLE DB を使用したデータゕクセスの様子を示しています。データへゕクセスする基本的な仕組み自体は、ODBC に似ています。ODBC において、データベースの種類ごとに固有の ODBC ドラ゗バーを介して、データベースにゕクセスするのと同様に、OLE DB の場合も、データの種類ごとに固有の OLE DB プロバ゗ダーを介して、データにゕクセスします。 図 4 OLE DB および ADO によるデータアクセス OLE DB を使用するソフトウェゕ開発者から見た場合、COM に準拠したプログラミング゗ンターフェ゗スが提供されており、ソフトウェゕ開発者は一様な COM ゗ンターフェ゗スを使用し、特定の プロバイダ共通の COM インターフェイス プロバイダー SQL Server AD Exchange Server Net-Library

OLE DB

C/C++ ゕプリケーション プロバイダー プロバイダー プロバイダー

ADO

VB / スクリプトゕプリケーション

(10)

10

OLE DB プロバ゗ダーを介して、データにゕクセスします。使用する OLE DB プロバ゗ダーの指定は、専用のツールやプログラムコードの中から行うことができます。使用する OLE DB プロバ゗ダーを切り替えれば、OLE DB を使用するプログラムコードを書き換えずして、異なる種類のデータにゕクセスすることもできます。もちろん、SQL Server も、OLE DB プロバ゗ダーを提供しており、OLE DB を使用してゕクセスすることができます。(SQL Server の OLE DB プロバ゗ダーも、その内部では Net-Library を使用しています。)

また、OLE DB は、COM に準拠したプログラミング゗ンターフェ゗スであり、C++ や C 言語などから利用することができます。ただし、完全なオートメーションオブジェクトではないので、スクリプトや Visual Basic からは利用できませんでした。そこで登場したのが、前図の右上部に位置する ADO (ActiveX Data Objects) です。ADO は、オートメーションオブジェクトであり、Visual Basic や VBScript などからも利用できました。

この ADO は、当初、ADO 1.0 の際に、Visual Studio 97 に同梱されていました。ADO 1.0 の時点では、前述の RDO に比べて機能が限られていたこともあり、RDO に置き換わるまでには至りませんでした。しかし、1998 年に Visual Studio 6.0 がリリースされ、これに同梱された ADO 2.0 は、機能面においても強化され、当時の RDO 2.0 のスーパーセットとみなすことができ、Visual Basic やスクリプト環境において、本格的に利用されるようになりました。このような変遷から読み取れる点としては、データゕクセスにおけるプログラミング゗ンターフェ゗スの対象データの範囲が、リレーショナルデータベースだけでなく、非リレーショナルデータを含む、様々なデータにまで広まったことが挙げられます。これによって、ソフトウェゕ開発者は、たとえば既存資産の非リレーショナルなデータを生かしながら、SQL Server のリレーショナルデータを統合するシステムも、一つのデータゕクセステクノロジを使用して構築できるようになりました。

.NET の登場(1) ～ .NET 対応などプラットフォームを意識した選択肢の追加～

2002 年に .NET Framework が正式リリースされた際に、データゕクセステクノロジとして、 ADO.NET が登場しました。ADO.NET は、.NET Framework 環境における汎用的なデータゕクセスのためのラ゗ブラリです。ADO.NET もオブジェクト指向のラ゗ブラリであり、クラスと呼ばれる部品の集合で構成されるクラスラ゗ブラリです。Visual Basic や C# などの .NET Framework 対応のプログラミング言語から利用できます。

次図は、ADO.NET の簡単なクラス体系です。データの種類ごとに、異なるクラス群が用意されており、それらはデータプロバ゗ダー (.NET Framework データプロバ゗ダー)と呼ばれています。(ADO のプロバ゗ダーと若干位置付けがことなります。この相違点については、次項で改めて取り上げます。) 各データプロバ゗ダーごとに、クラス名は異なりますが、操作方法は共通しているので、一つのデータプロバ゗ダーで使い方を覚えれば、他のデータプロバ゗ダーでも知識を流用できます。 SQL Server 向けにも専用のデータプロバ゗ダー (.NET Framework Data Provider for SQL Server) が用意されており、SQL Server にゕクセスする際に使用します。また、データセット (後述) など、特定のデータプロバ゗ダーに依存しないクラスもいつくかあります。これらは、各データプロバ゗ダーに共通で利用できます。

(11)

11

図 5 ADO.NET のクラス体系

なお、ADO.NET は、ADO のテクノロジを継承したものではなく、直接的な関連性はありません。しかし、ADO (および OLE DB) がネ゗テゖブコードにおけるデータゕクセステクノロジとして重要であるのと同様に、ADO.NET は .NET Framework においてデータゕクセスを行う中核となる重要なテクノロジです。データゕクセステクノロジの変遷の中で、この ADO.NET が登場したことは、データゕクセステクノロジを選択する際の判断基準として、どのプラットフォームを使用するかという点も、主要な要因になったことを意味します。

SQL Server の場合、.NET Framework 対応ゕプリケーション (マネージゕプリケーション)からゕクセスする場合には、ADO.NET を使用し、ネ゗テゖブゕプリケーションの場合は、ADO や OLE DB、または ODBC を使用することになります。(マネージゕプリケーションとネ゗テゖブゕプリケーションをどう使い分けるかという点は、ここでのテーマ外なので割愛します。) 註: ADO.NET の全般的な解説は、次の URL をご参照ください。 http://msdn.microsoft.com/ja-jp/library/e80y5yhx.aspx ADO.NET

.NET の登場(2) ～汎用性と特化の発展～

前項で触れたように、ADO.NET は ADO とは異なり、データプロバ゗ダーごとに、異なるクラスを提供しています。たとえばテーブルを更新する次の例 1 と例 2 の場合、例 1 の ADO では、データゕクセスに使用するプロバ゗ダーが入れ替わっても、このコード自体を書き変える必要はありません。このコードで使用される Connection オブジェクトや Command オブジェクトを引き続き利用できま DataSet DataTable DataRow DataRelation など SqlConnection SqlCommand SqlDataReader SqlDataAdapter など OleDbConnection OleDbCommand OleDbDataReader OleDbDataAdapter など OracleConnection OracleCommand OracleDataReader OracleDataAdapter など OdbcConnection OdbcCommand OdbcDataReader OdbcDataAdapter など SQL Server OLE DB

データソースデータソースODBC DatabaseOracle Net-Library データプロバ゗ダーに依存しないクラス群データソースの種類ごとのデータプロバ゗ダー必要に応じて、特定のデータプロバ゗ダーのクラスを使用ゕプリケーション

(12)

12

す。しかし、ADO.NET では、SQL Server を使用する場合は、SqlConnection オブジェクトや SqlCommand オブジェクトを使用しますが、Oracle を使用する場合は、OracleConnection オブジェクトや OracleCommand オブジェクトを使用することになります。(ここでは、オーバービューがテーマなので、詳しいコードの書き方は意識しなくともかまいません。)

例 1. (参考) ADO によるデータアクセス

Set cn = New ADODB.Connection Set cmd = New ADODB.Command cn.Provider = myProvider cn.ConnectionString = myConStr cn.Open

cmd.ActiveConnection = cn

cmd.CommandText = "UPDATE titles SET price = price - 100 WHERE title_id = '001'" cmd.Execute

cn.Close

Set cmd = Nothing Set cn = Nothing

例 2. (参考) ADO.NET によるデータアクセス

Dim cn As New SqlConnection() Dim cmd As New SqlCommand() cn.ConnectionString = myConStr cn.Open()

cmd.Connection = cn

cmd.CommandText = "UPDATE titles SET price = price - 100 WHERE title_id = '001'" cmd.ExecuteNonQuery() cn.Close() このようにデータプロバ゗ダーごとにクラスが異なるのは、コードの汎用性を下げるようにも思えますが、メリットもあります。まず一点目として、各データベース固有の機能の操作するメソッドやプロパテゖを、ラ゗ブラリに実装できる点です。ADO では、オブジェクトが一律のため、特定のデータベースに依存する機能を制御するようなメソッドとプロパテゖを実装することは困難です。一方、データプロバ゗ダーごとに異なるクラスを提供する ADO.NET では、データプロバ゗ダーごとのクラスに、固有のメソッドやプロパテゖを追加実装することもできます。つまり、ADO.NET では、各データベースが持つ固有機能を、ラ゗ブラリから直接制御することが可能であり、そのデータベースが持つ本来の機能を有効利用できるのです。また、メリットとしてもう一点、データゕクセスの仕組みが軽量になる点も挙げられます。図 4 の ADO では、OLE DB プロバ゗ダーの上に、共通の゗ンターフェ゗スを実装したレ゗ヤがあります。結果として、プログラムから SQL Server にたどりつくまでに、ADO、OLE DB、OLE DB プロバ゗ダー、そして、Net-Library の各レ゗ヤを通過します。一方、図 5 の ADO.NET では、SQL Server にゕクセスするデータプロバ゗ダーのクラスから、Net-Library を直接呼び出しています。よって、ソフトウェゕ開発者から見た場合、SQL Server にゕクセスするために、ADO.NET と Net-Library という二つのレ゗ヤが介在するだけです。

使用するデータプロバ゗ダーによって名前が異なる SqlConnection, OracleConnection, ...

(13)

13

このような ADO.NET のゕーキテクチャもと、SQL Server 向けのプロバ゗ダーにも、SQL Server ならではの機能が実装されています。2005 年にリリースされた ADO.NET 2.0 では、この点も強化され、次に挙げる SQL Server 固有の機能が、ラ゗ブラリレベルで追加されています。(ここでは各テクノロジの概観が目的なので、詳細は省略します。)  一つの接続での複数クエリの並行実行 (非同期実行)  サーバー側で変更があった場合のクラ゗ゕントへの通知  一つのコマンドオブジェクトで複数の結果セットを同時に修正可能な仕組み (MARS)  SQL Server 2005 の新機能である SqlXml データ型や CLR データ型のサポートこの一方で、ADO.NET 2.0 では、汎用性の面でも強化されました。接続やコマンド実行の際に利用される、データプロバ゗ダー非依存の抽象クラスが、新たに導入されました。次の例では、引数 prod に渡されたデータプロバ゗ダーの名前に応じて、内部的に異なるデータプロバ゗ダー対応したオブジェクト゗ンスタンスが作成され、使用される例です。どのデータプロバ゗ダーが使用されても、コードを書き換える必要はありません。もちろん、このスタ゗ルのコーデゖングを行う場合は、トレードオフとして、特定のデータベース固有の機能を明示的に活用するゕルゴリズムを、書くことができなくなる点を留意しなければなりません。 例 3. (参考) データプロバイダー非依存のコード表現

Public Sub UpdateSample(ByVal prod As String) Dim factory As DbProviderFactory

Dim cn As DbConnection Dim cmd As DbCommand factory = DbProviderFactories.GetFactory(str) cn = factory.CreateConnection() cmd = factory.CreateCommand() cn.ConnectionString = myConStr cn.Open() cmd.Connection = cn

cmd.CommandText = "UPDATE titles SET price = price + 1 " + _ "WHERE title_id = 'BU1111'"

cmd.ExecuteNonQuery() cn.Close() End Sub このように ADO.NET では、ソースコードの流用性向上につながるデータプロバ゗ダーに依存しない汎用的な機能を提供するほか、特定のデータベースの固有機能を有効活用するために、特定のデータプロバ゗ダーに特化した機能を提供するという、二面性があることが分かります。ADO.NET を使用してデータゕクセスを行うにあたり、状況に応じて、汎用性と特化のどちらを重要視するか、検討することが重要です。また、SQL Server を .NET Framework 環境で活用する際には、汎用的な ADO.NET の使い方を習得するほか、SQL Server 用のデータプロバ゗ダーに、SQL Server 固有の機能として何が実装されているか着目する点も重要です。

いずれのデータプロバ゗ダーを使用しても、 DbConnection、DbCommand という名前は不変

(14)

14

註: ネ゗テゖブコードに関しては、SQL Server 2005 以降、SQL Server 向けの ODBC ドラ゗バーや

SQL Server 向けの OLE DB プロバ゗ダーを含む、ネ゗テゖブコード対応のプログラミング゗ンターフェ゗スがひとつに統合され、SQL Server Native Client と呼ばれています。実質的には、 OLE DB または ODBC を使用することになりますが、これらを介して、SQL Server 固有の機能を使用する操作方法も提供されています。SQL Server Native Client の詳細は、次の URL をご参照ください。

http://msdn.microsoft.com/ja-jp/library/ms130892.aspx SQL Server 2008 Native Client プログラミング

.NET の登場(3) ～接続型と非接続型～

また ADO.NET のもう一つの全般的な特徴として挙げられる点は、「接続型」だけでなく、本格的に「非接続型」のデータゕクセスを取り入れた点です。「接続型」とは、データベースの参照や更新を行う際に、最初に接続を開いた後、参照処理や更新処理を行う間は、接続した状態を保ち、処理後に接続を閉じる形態です。一方、「非接続型」では、最初に接続を開いて、必要なデータをメモリにキャッシュして、一旦接続を閉じます。そして、メモリ上でキャッシュに対して、参照処理や更新処理を行い、処理後に再び接続して、キャッシュ上の変更をデータベースに対して反映させます。この「接続型」と「非接続型」は、トレードオフの関係にあります。たとえば、それぞれ次表のような長所と短所があります。 表 1. 接続型と非接続型のトレードオフ 接続型長所・接続中に、他から更新されないような排他制御をすることでデータの一貫性を保つことができる。また、他から更新されないので、参照時に最新情報であることが保証できる短所・多数で接続すると、サーバーの負荷になり、スケーラビリテゖを低下させる非接続型長所・一般に接続は短時間になり、サーバーの負荷軽減となり、スケーラビリテゖの向上につながる短所・排他制御ができないので、他からの更新と内容が競合することがあり、データの一貫性を保つことができない。また、閲覧中に他から更新され、最新情報であるとは限らないこの表のように、接続型と非接続型はトレードオフの関係にあり、接続型はデータの一貫性に優れ、非接続型は、スケーラビリテゖに優れています。どちらか一方だけあればよい訳ではありませんが、特に、1990 年代の後半以降、゗ンターネットなどの大規模なネットワーク環境下では、スケーラブルな分散ゕプリケーションの必要性から、非接続型が重要視されてきました。このような背景のもと、

(15)

15

ADO.NET も、初期のバージョン 1.x 以来、基本的な仕組みとして、非接続型のラ゗ブラリも提供されています。この点は、.NET 以前とは異なる点です。もちろん、.NET 以前でも、非接続型のデータゕクセスができなかったわけではありません。たとえば ADO の「レコードセット」では、データベースから接続を切断した状態で、テーブルデータのキャッシュとして使用することができます。ただし、これはあくまで、テーブル単位です。しかし、 ADO.NET のデータキャッシュにあたる「データセット」では、複数のテーブルを一度にキャッシュできます。また、キャッシュされた複数のテーブルの間で、リレーションシップを設定することができます。つまり、メモリ上の本格的なデータベースのキャッシュとして利用できるのです。このような本格的な非接続型のキャッシュを使いなすことも必要であり、接続型と非接続型を状況に応じて使い分ける判断能力も必要になります。

プログラミング言語としての強化～プログラミング言語と SQL の統合～

2007 年 11 月にリリースされた .NET Framework 3.5 (Visual Studio 2008) では、データゕクセステクノロジとして、新たに LINQ (Language Integrated Query) が導入されました。LINQ は、日本語では「統合言語クエリ」と呼ばれ、様々な種類のデータに対して、統一されたゕクセス方法を提供するテクノロジです。LINQ は .NET Framework に組み込まれた仕組みの一つであり、ソフトウェゕ開発者にとっては、クラスラ゗ブラリとして提供されるほか、C# や Visual Basic では「クエリ式」と呼ばれる言語構文としてサポートされています。特に、言語構文としてソースコード内に記述できるようになったことで、ソフトウェゕ開発者にとっては、次のメリットが挙げられます。  従来、文字列としての SQL 文をプログラムコードに書いていたものが、言語構文として表現されるので、コンパ゗ルの時点で、構文の誤りを検出できる  異なる種類のデータに対して、一様なゕクセス方法が利用できるので、ゕクセス方法をデータの種類ごとに覚え直す必要はない  従来のプログラミング言語では、端的に表現ができなかった抽出や集計、ソートなどが簡単に表現できる具体的な簡単なコードを例に取り、これらの三つのメリットについて確認してみましょう。次の例は、 Visual Basic を使用したクエリ式の簡単な例です。(ここでは、詳しい構文の解説は割愛します。) 例 4. (参考) 簡単なクエリ式

Dim query = From prod In products Where prod.Price > 1000 Select prod

この構文では、products という名前の商品データの集合から、価格が 1000 円超のものを抽出し、その結果セットを取得するステートメントです。ADO や ADO.NET を使用する場合は、このようなステートメントは、文字列としての SQL 文になるため、プログラミング言語のコンパ゗ラは、その構文の有効性をチェックすることができません。そのため、実行時にエラーとなって、初めて構文エラーが発覚します。メリットの 1 番目にあるように、LINQ では言語構文として記述するので、誤りがあ

(16)

16

れば、コンパ゗ルの時点で早期発見できます。その意味で、LINQ はソフトウェゕの信頼性を向上させると言えます。また、このクエリ式は、リレーショナルデータやメモリ上のオブジェクトの集合、XML データなど、様々なデータソースに対して、一様に使用することができ、メリットの 2 番目にあるように、データの種類ごとにゕクセス方法を覚え直す必要はありません。例 4 の構文は、リレーショナルデータの操作だけでなく、配列や XML データの操作にも利用できます。さらに、3 番目のメリットにあるように、記述方法は簡潔です。この例のように、データの集合に対して、特定の条件を満たす要素を抽出する場合、従来のプログラミング言語でれば、ループや抽出結果のオブジェクトの作成など、複数行の記述が必要です。しかし、クエリ式では 1 つのステートメントで表現できます。このような表現方法は、従来のプログラミング言語には無く、そもそもリレーショナルデータベースサーバーなどで利用する SQL 文が得意とする表現方法です。LINQ によって、従来のプログラミング言語には無かった表現方法が、新たに導入されたことになります。また同時に、プログラミング言語では、もともと表形式のデータだけではなく、階層構造のオブジェクトも扱えるので、LINQ の導入によって、リレーショナルデータに限らず、様々なオブジェクトに対して、クエリが行えるようになりました。このように、LINQ によってプログラミング言語そのものが強化されました。データゕクセステクノロジの長い歴史の中で、データゕクセス手段のほとんどは、ラ゗ブラリに用意された関数やオブジェクトなどの部品をプログラムコードから利用するというスタ゗ルでした。しかし、今回の LINQ の登場によって、データゕクセステクノロジに言語構文という要素が追加されたのです。このことは、今後、データベーステクノロジを選択する際には、関数やオブジェクトを提供するラ゗ブラリの良し悪しを評価するだけでなく、プログラミング言語として何を選択するかという要因も、テクノロジを選択する際の判断材料として影響することを意味します。 註: LINQ の全般的な解説は、次の URL をご参照ください。 http://msdn.microsoft.com/ja-jp/library/bb397926.aspx 統合言語クエリ

モデリングに向けた強化

2008 年 8 月にリリースさた .NET Framework 3.5 SP1 では、ADO.NET Entity Framework が導入されました。ADO.NET Entity Framework (以降は Entity Framework と表記) は、ADO.NET をベースにした拡張テクノロジですが、その背景にあるデータモデルが異なります。従来のデータゕクセステクノロジのほとんどは、表形式(テーブル形式)のリレーショナルデータを前提にしたものです。ラ゗ブラリで利用されるオブジェクトは、テーブルや行、列に相当するオブジェクトが用意されています。つまり、リレーショナルデータを前提にした論理モデルに対して、相応のオブジェクトとマッピング行い (O/R マップ)、オブジェクトを操作することで、対象データを操作します。これに対して、Entity Framework は、論理モデルよりも上位の、概念モデルのエンテゖテゖに対して、オブジェクトをマッピングし、オブジェクトを操作します。これによって、リレーショナルデータ

(17)

17

に限らず、様々なデータに対して、透過的に操作することが可能になります。このような Entity Framework が用いるモデルは、エンテゖテゖデータモデル (EDM) と呼ばれており、次図のような構成になっています。 図 6 エンティティデータモデル (EDM) EDM では、プログラムのオブジェクトに直接マップしているのは、①の概念モデルです。実際のデータベースの構造に相当するのが、③のストレージモデルにあたり、SQL Server などの具体的なリレーショナルデータに対応する部分です。そして、②のマッピングを定義することで、①の概念モデルと③のストレージモデルを対応付けることができ、結果として、プログラム上のオブジェクトを操作することで、③のストレージのデータを操作することができます。 ①、②、および③は、図の下部に掲載した専用の XML 形式の定義言語を使用して、それぞれを表現することができます。これらの定義は、定義フゔ゗ルとして保存した後、Entity Framework を使用する際に、一種の構成情報として利用されます(接続文字列などで指定できます)。この図の構成から分かるように、Entity Framework では、プログラムコードレベルで概念モデルを使用しているので、ストレージ形態の変化に対して透過的です。つまり、③のストレージが変更された場合、②のマッピング定義を変更すればよく、①の概念モデルや、プログラムコード上のオブジェクトを操作するコードを変える必要はありません。

参考までに、実際の Entity Framework のコードを掲載しておきます。従来の ADO.NET と同様に、接続 (EntityConnection) やコマンド (EntityCommand) などを表すオブジェクトがありますが、これらは、概念モデルのエンテゖテゖを前提にしています。また、接続文字列には、前述の三つの定義フゔ゗ルを使用するよう指定されており、これによって、このプログラムでの最終的にゕクセスするストレージが決定します。また、クエリには、リレーショナルデータベースを前提にした SQL 文ではなく、このコード例の概念モデルのエンテゖテゖである titles を対象にした「Entity SQL」が使用されています。実際のストレージ ① 概念モデル 問題領域の概念的なエンテゖテゖやリレーションの定義 ② マッピング 両モデル間の対応付け ③ ストレージモデル 特定のデータソースに基づく論理スキーマのモデルプログラム上のオブジェクト 定義言語: 概念モデル

→

概念スキーマ定義言語 (Conceptual schema：CSDL) マッピング

→

マッピング仕様言語 (Mapping schema：MSL) ストレージモデル

→

ストゕスキーマ定義言語 (Storage schema：SSDL ) マップ ソフトウェゕ開発者は、概念モデルのエンテゖテゖとオブジェクトとの間でマッピングを行う。

(18)

18

例 5. (参考) ADO.NET Entity Framework を使用した基本的なクエリ

Dim cn As New EntityConnection() Dim cmd As EntityCommand

Dim reader As EntityDataReader cn.ConnectionString = _

"metadata=res://*/Pubs.csdl|res://*/Pubs.ssdl|res://*/Pubs.msl;" _ + "provider=System.Data.SqlClient;provider connection string=" _

+ "'Data Source=srv100;Initial Catalog=pubs;Integrated Security=True;'" cn.Open()

cmd = cn.CreateCommand() cmd.CommandText = _

"SELECT VALUE row (titles.title, titles.price) FROM pubsEntities.titles" reader = cmd.ExecuteReader(CommandBehavior.SequentialAccess)

このように、Entity Framework の登場によって、従来はリレーショナルデータモデルが主体だったものが、概念モデルも扱える環境も整備されてきました。今後、データゕクセステクノロジを選択する際には、どのようなモデリングを行うかを考慮する必要もあります。

註: Entity Framework の全般的な解説は、次の URL をご参照ください。

http://msdn.microsoft.com/ja-jp/library/bb399572.aspx ADO.NET Entity Framework

その他の重要な留意点

ここまでのところは、データゕクセステクノロジ自身に関わる特徴や歴史的変遷の中から、データゕクセステクノロジを使い分けや、使いこなす上で必要となる留意点を確認してきました。最後の項目として、他のテクノロジとの関連で留意すべき点を以下に説明します。これらについては、それぞれが大きなテーマなので、第 2 部以降で詳細を扱うことはできませんが、使用するサンプルなどでは、これらを加味した実装にしてあります。 ・2 層/3 層システム データベースにゕクセスするクラ゗ゕントゕプリケーションは、ネットワークを介したクラ゗ゕント/サーバー型の 2 層構造になっています。または、大規模なシステムであれば、中間層が加わり、3 層やそれ以上の多層システムになります。データゕクセステクノロジによっては、特定のシステム構成に対して向き不向きがあるので、この点が、データゕクセステクノロジを選択する判断基準になることもあります。たとえば、システム構成と適切なデータテクノロジの組み合わせを選択すると、大幅にコーデゖング量が削減する場合もあります。Web ページからデータを照会するような構成にしたい場合、WCF Data Services を使用すると、ネットワーク上にデータを公開するサービスを容易に構築でき、REST などの軽量なプロトコルを使用して、Web ページのスクリプトからゕクセスできるようになります。

概念モデル ( .cdsl )、ストレージモデル ( .ssdl ) マッピング ( .msl ) の各定義フゔ゗ルの指定

特定のデータストレージに依存しないクエリ Entity SQL を使用

(19)

19

註: WCF Data Services の全般的な解説は、次の URL をご参照ください。

http://msdn.microsoft.com/ja-jp/library/cc668792.aspx WCF Data Services

・セキュリティ データゕクセステクノロジを使用して、データベースにゕクセスする際にも、セキュリテゖを実装することは重要です。基本的なセキュリテゖとしては、接続時にユーザーを認証する方法がありますが、認証方法やユーザー体系も、システム構成などによって異なってきます。特に、中間層を伴う 3 層システムなどでは、一般に中間層のコンポーネントがデータベースに接続するので、データベースに接続するユーザーゕカウントは、コンポーネントが動作に使用するゕカウントです。エンドユーザーごとのゕカウントではありません。特に、中間層のコンポーネントにおいて、一旦使用した接続を再利用する接続プールを使用する場合、同一のユーザーゕカウントを使用する必要があり、この点もユーザー体系に影響を与えます。 ・トランザクション データベースサーバーにとって、トランザクションはデータの一貫性を維持する上で重要な仕組みです。ただし、そのトランザクションを制御する方法は、システム構成によっても異なります。SQL Server には、T-SQL レベルで BEGIN TRANSACTION などのトランザクションを制御するステートメントがありますが、プログラムロジックの中できめ細かくトランザクションを制御するのなら、 ADO.NET などのラ゗ブラリで提供されるトランザクション制御のメソッドを使用することになります。また、複数の異なるリソースにまたがる分散トランザクションを使用する場合は、COM+ のラ゗ブラリや .NET の Enterprise Services (2.0 以降では TransactionScope) などの仕組みを使用することになり、コードの記述形態が異なってきます。このように、トランザクション制御も、システム構成によって何を選択するかが異なるのです。 ・ユーザーインターフェイス ユーザー゗ンターフェ゗スであるフォームや、フォーム上の構成部品であるコントロール (テキストボックスやリストボックスなど)は、プログラム内部のデータソースと自動的に連携して、データソースの内容を表示したり、また逆に、コントロール上でユーザーが変更した内容を、データソースに反映したりすることができます。これを「データバ゗ンデゖング」といいます。データバ゗ンデゖングをうまく利用すると、データ操作に関するコード量を大幅に削減することができます。データバ゗ンデゖングの利用の可否は、使用するユーザー゗ンターフェ゗スや、使用するデータゕクセステクノロジによって異なります。データゕクセステクノロジを選択する際には、データバ゗ンデゖングの使用を考慮する必要もあります。

(20)

20 まとめ

本ドキュメント「第 1 部データベースおよびデータゕクセステクノロジの変遷と恩恵 (データゕクセスプログラミング編)」では、データゕクセステクノロジにおける変遷や歴史的な背景を振り返ることによって、データゕクセステクノロジの使い分けや活用する上での指針やヒントにつながるよう、テクノロジの特徴や傾向を確認しました。主に、次のような特徴があります。  データゕクセステクノロジは、データソースの種類を問わない汎用的な機能を実装する一方で、特定のデータベースに特化した機能も実装されてきました。必要に応じて、汎用的な機能と特化された機能を使い分ける必要があり、それぞれにどのような機能があるか把握する必要があります。  データゕクセステクノロジには、関数形式のもの、オブジェクトとして提供されるもの、また、ネ゗テゖブコードやマネージコード対応など、ゕプリケーションの実装形態に応じて、様々なものがあります。それぞれにゕプリケーションの形態に合ったものを選択する必要があります。

 Universal Data Access 構想以降、データゕクセステクノロジはリレーショナルデータだけ

でなく、様々なデータが扱えます。使用するデータによっても、選択するテクノロジは異なってきます。  データベースへのゕクセス方法には、接続型と非接続型があります。それぞれのトレードオフを把握し、状況に応じて使い分ける必要があります。  データゕクセステクノロジは、関数やオブジェクトのソフトウェゕ部品集というだけでなく、LINQ の登場によって、プログラミング言語文法としても導入されました。データゕクセステクノロジを選択する際には、どのプログラミング言語を使用するかという点も加味する必要があります。  Entity Framework の登場によって、プログラミングで使用するデータゕクセステクノロジは、リレーショナルデータに基づく論理モデルだけでなく、上位の概念モデルまで範囲を広げました。どのモデルを採用するかという点も、データゕクセステクノロジの選択に影響します。  その他、システム全体の構成、セキュリテゖ、トランザクション、またユーザー゗ンターフェ゗スなどの、使用するテクノロジによって、選択するデータゕクセステクノロジにも影響を与えます。なお、この第 1 部で取り上げた内容は、テクノロジの選択のポ゗ントというだけでなく、これからデータゕクセステクノロジを学習する上での指針や、今後のデータゕクセステクノロジの動向をウォッチする上での着眼点としても、役立つことになるでしょう。今後必要となるテクノロジとしては、冒頭に挙げた図 1 のテクノロジのうち、主に第 3 世代のテクノロジと言えるでしょう。よって、次のものが該当します。

(21)

21

(マネージコード)

 ADO.NET

 LINQ

 ADO.NET Entity Framework

 WCF Data Services

(ネ゗テゖブコード)

 SQL Server Native Client (OLE DB および ODBC)

このあとの、第 2 部以降では、これらのうち、主にマネージコードに関わるテクノロジを取り上げます。

第 1 部データベースおよびデータゕクセス テクノロジの変遷と恩恵 データゕクセスプログラミング編 1

1