データベース・アクセス用のAPIを利用する

図5●データベース・ドライバ
アプリケーションとデータベース・サーバーの間で，データベースへのアクセスを標準化する役割を担う。アクセス手順なども決められている。アプリケーション側でデータベースの違いを意識しなくても済む仕組みである。
図6●ADO .NET
アプリケーション・ソフトとデータベース管理システムを独立させるために，データセット・オブジェクトを介在させている。またデータセットがデータベースのデータを保持することによって，データベースとの接続は切れた状態にしている。
写真1●Delphiを使ったデータベース・アプリケーション
開発中の画面。大きくデータベース関連のモジュールをまとめた「データモジュール」と，フォームから成る。コードが見ているのはフォームの部分。ここにほとんどプログラムを書いていない。データモジュールに登録されているデータソースを指定しているだけである。

　こういったDBMSを利用したプログラムを組む場合，以前はそれぞれのDBMSに合わせてライブラリやリクエストを発行するプログラムを組み込む必要があった。ただ最近では，アプリケーションが利用する標準の層が規定されているので，個々のDBMSの操作方法の違いを意識することはほとんどない（図5[拡大表示]）。Windowsでは「ODBC（Open Database Connectivity）」，Javaでは「JDBC」が規定されている注4）。

　ただODBCやJDBCでは，個々にデータベース・サーバーに対応したドライバを組み込まなければならない。また，これらの規約で定めているAPIの範囲内でしかデータベースを操作できない。その一方で，個別のDBMSが受け入れるSQLの拡張仕様はそのまま通ってしまう。つまり，SQLの仕様やストアド・プロシジャの仕様など，DBMS固有の処理は共通化できない。またODBCやJDBCの標準規約に則っていることによるオーバーヘッドもある。

　そこで米Borland Software社や米Microsoft社は，独自のデータベース処理機構を開発ツールに盛り込んでいる。MicrosoftがVisual Studio .NETで取り入れたデータベース・アクセス機構は「ADO .NET」だ。DBMS自体と，DBMSに対する操作を隠蔽する「データプロバイダ」と，それを実データとして表現する「DataSet」と呼ぶオブジェクトを使う（図6[拡大表示]）。DataSetオブジェクトは，アプリケーション・プログラムから見たデータベース操作の違いを吸収するレイヤーである。またADO .NETでは，XMLデータを直接生成するという意味合いもある。このようなアーキテクチャを採ることによって，データベースへのアクセスを集中させないようにしている。基本的にアプリケーション・プログラムは，データベースにコネクションを張り続けない。だから複数のアプリケーションが同じデータベースを参照する場合でも，競合の解消はアプリケーション側であまり意識しなくてよくなるのである。

　Delphiでも事情はほぼ同じだ。Delphiではデータベース・アクセス関連の処理を「データモジュール」にまとめることができる。こうすることにより，データベース・アクセスに関する部分を再利用しやすくしている。

　データベースにアクセスする「コネクション」オブジェクトと，それをデータベース操作を記述した「データセット」，それを実データとして表現する「データソース」から成る。名称はADO .NETとは違うが，前2者がADO .NETにおけるデータプロバイダ，データソースがADO .NETにおけるデータセットだと思えばいい。Delphiの場合，設計時にデータソースを有効にしておくと，写真1[拡大表示]のようにテーブルの内容を表示してくれる。設計時には便利な機能だ。

「でも，データベースってカンタンじゃないですね」
「最初はなかなか慣れないかもしれないね。シングル・ユーザーで使っているうちは，それほどややこしくないと思うんだけど」
「Accessとかだったら，まだわかるんですけど」
「やってることは同じだよ。ただ，データベースを操作するための機能を多く備えているところが違うかな」

（北郷　達郎、八木　玲子）