Access MDB のマルチユーザー使用について |
最終更新日 : 2005/04/25 ( オリジナル作成日:2002/08/26 )
廉価なため、Access の MDB を用いて、マルチユーザー環境を構築したいとの要望が多くありますが、私自身が今までに出会った現象、そして動作を観察しての推測に基づき、ポイントをまとめてみました。
●Access と JET
Access はユーザーインターフェースを、JET は物理的に保存されているデータの操作を提供するものとして、PC 環境でのデスクトップ・データベースを目的として開発されました (他社が開発したプロダクトを、Microsoft が買い取ったとの話も聞いたことがありますが、定かではありません)。
Windows 上でのデスクトップ型 PC をメインに考えられたデータベースが無かったため、他の開発言語からも扱えるように DAO という概念を設け、切り分けられたように思われます。
これらの背景もあり、Access と JET は同一 PC で稼動するようになっています。
●Access の基本動作
単体の PC で MDB ファイルを使用している場合の基本的なイメージは次のようになります。
ここで Access が MDB ファイルからデータを選択する動作について、選択クエリでのレコードの抽出を例に考察してみます。
クエリのデザインビューで表示フィールドや抽出条件を設定し、データシートビューに切り替えると、Access が解析(コンパイル)を行います。
解析結果に基づき、JET に対してデータの要求を行います。
JET は、MDB ファイルの処理対象のテーブルから順次レコードを取り出します。
抽出対象のレコードを選別します。指定があれば演算フィールド等の計算を行います。
抽出対象のレコードを Access へ返します。
受け取ったデータをデータシートビューに埋め込み、表示します。
●ネットワーク接続について
Windows
が提供している機能により、ネットワークに接続されている他の PC 上のファイルが簡単に参照でき、Access ではリンク(当初はアタッチと呼ばれていた)により他の PC 上にある
MDB ファイル内のテーブルを簡単に参照できるようになっています。
この場合、PC 内で IDE や SCSI で接続していた経路が、ネットワークに代わることになります。
ネットワークを介して他のPCに接続しているディスクの場合でも、レコードの選別は
ローカルマシンで稼動している JET が行うので、ネットワークを通してレコードを順次取り出してくることになります。
このため、ネットワークの回線速度や、ネットワークプロトコルの伝送処理がネックとなり、処理速度が低下します。
また、通常、LAN では、さまざまなデータがネットワーク上を行き来しています。
Access
での処理が遅くなるとともに、他のアプリケーションの動作もこの大量なデータの転送により影響を受けてしまいます。
LAN でよく使用されているイーサネットの CSMA/CD という方式では、データ量が大量になるとデータ送信の衝突が起こり、データの再送が起こることになります。
原因がはっきりとは分かりませんが、LAN 上を大量のデータ転送を伴う処理を行う場合(たとえば MDB の最適化)、データ再送が発生すると伝送完了検知を正しく行えないためか、無応答の状況に陥るケースもあります。
●SQL Server の場合
Access ADP から SQL Server を使用する場合の基本的なイメージは次のようになります。
こちらも ADP でのクエリ(ビュー)でのレコードの抽出を例に動作を考察してみます。
クエリのデザインビューから、新規にビューを作成し、データビューに切り替えると、Access から SQL Server に対してビューが登録されます。
クエリのビューを開くと、Access から OLEDB を介して、接続先のデータベースに対してView の実行を依頼します。
SQL Server は指定された View の内容に基づき、対象のテーブルからデータを順次取得します。
対象のレコードを選別します。指定があれば演算フィールド等の計算を行います。
対象のレコードを OLEDB を介して Access へ返します。
受け取ったデータをデータシートビューに埋め込み、表示します。
このため、ネットワーク上に流れるデータは、SQL Server に対するリクエストと、条件によって絞り込まれたレコードだけになります。
●ロック等、データベースの管理
SQL Server 等の DBMS では、各クライアントプログラムから要求された処理を、データベースエンジンが一元的に受付を行い、それぞれの要求に対する処理の順序付け、 ロックの設定および解除、データの読み取りおよび保存、そして処理の結果をクライアントプログラムへ返しています。
物理ファイルに対して操作が行われるのは、基本的には Database Engine に集約されています。
これに対して Access は、マルチユーザーで使用する場合、MDB を複数の Access からファイルを共有する形で使用しています。
ロックの管理は JET が行っています。その JET は各クライアント PC それぞれで動作しているため、それぞれのクライアント PC
から処理を行おうとする際に、その時点で MDB がどのような状態であるかを個々に把握し、管理しなければなりません。
LAN 等のネットワークが途中に介在し、多量のトランザクションが引き起こす伝送の遅延、セグメントの再送などや、
各クライアントから MDB ファイルに対して頻繁に更新が行われるような場合、各クライアントの JET が、それぞれ個別に管理している情報にズレを生じ、ロック
情報の更新タイミングがずれたり、あるいは検知が正しく行われない等が発生するようで、最悪は
MDB ファイルが破損する状況に陥ることが見受けられます。
●結論(?)
ネットワークを介した MDB の利用は、上記で述べた理由から大量に蓄積されたデータの中からの検索や、データを頻繁に更新するようなアプリケーションには向かないものと
思われます。
SQL Server 等のクライアントからの処理要求を一元管理し、必要最小限のデータのみがネットワークを伝送するような DBMS
を使用することを強くお勧めします。
5ユーザーまでであれば、MSDE も選択肢になるでしょう。
SQL Server のデスクトップバージョンである Microsoft Data Engine (MSDE) は、そのネーミングから今後の Microsoft のデスクトップ環境での標準データストア としての位置付けにあるように感じられます。
SQL Server および MSDE を接続 DB とした ADP が Access 2000 から新設されたのは、Access の今後の方向性を示しているのかもしれません。