Microsoft Access

歴史

Microsoft Accessのバージョン1.0は、1992年12月にリリースされた。
Access 2007では新しいファイル形式を採用により拡張子.accdbを使用。添付ファイルデータ型やWindows SharePoint Servicesへの対応等が行われる。

用途

Accessは、規模としては中小企業や大企業の事業部といった場面から、データの作成や操作をするプログラムを作りたい趣味レベルのプログラマまで広く使われている。Accessの使いやすく強力な設計ツールは、データベースをよく知らない人間であっても、非常に効率的に開発を進められる。このため、Accessとは素人向けの開発環境であって、専門家にはあまり用いられていないかのように思われがちである。
Accessはデータアクセスがネットワーク経由の場合には力不足であるため、数名以上に利用されるようなアプリケーションが必要な場合、Oracle、DB2、Microsoft SQL Server、PostgreSQL、MySQL、MaxDB、またはFileMaker Proのようなクライアントサーバモデルのソリューションに頼りがちである。しかしAccessの「フロントエンド」（フォーム、レポート、クエリ、およびVBコード）は、Access自身、Microsoft SQL Server、Oracle、その他のODBC──適合する製品を含むデータベース・バックエンドのホストに対して使える。
Accessを使う利用者の多くがLeszynski命名規則を使用するが、これは万人共通ではない。これはDBMSが強制する規則ではなく、プログラミングの規則である。

特徴

プログラマから見たAccessの利点の1つは、そのSQLとの相対的な互換性である。──クエリはSQL文として表示や編集ができる。そしてSQL文はAccessのテーブルを操作するためにマクロやVBAモジュールの中で直接使用できる。ユーザーはプログラムの形式と論理、そしてオブジェクト指向の可能性の提示のために、VBAと「マクロ」の両方を結合して使える。SQL文の中ではVBAと同じ演算子や関数を用いることができ、モジュール内で定義された利用者独自の関数さえも使用できる。
Accessのレポート作成機能は、有能で洗練された報告書作成の仕事に適していたとしても、他の有名なデータベースレポート作成機能──Crystal Reportsほどには十分に特色があり力強いとは言えない。MSDE (Microsoft SQL Server Desktop Engine) 2000はMicrosoft SQL Server 2000のミニ・バージョンだが、Office XP Developer Editionに含まれており、Jet Database Engineの代わりにAccessと共に使われるかもしれない（MSDEとMicrosoft Exchange Serverの初期バージョンはデータの膨大な量を取り扱うのに実際にJet Engineを使用しており、その上にそれらのアプリケーション用に「偽の」アプリケーション層を置いた。この事実に関する知識不足は、特に「大規模な」プロジェクトについては、ソフトウェア製品Access/Jetファミリーに対する不当な軽視の一因となった）。
Accessのカット・アンド・ペースト機能は、他のデータベース間（例えばデータやデータベースを通じてOracleとMicrosoft SQL Serverと）を接続する便利なツールである。Accessにはテキスト形式やExcel形式を含め、Windowsと他のプラットフォーム・アプリケーションとの統合を許す様々なインポート・エクスポート機能（又はリンク機能）が付属しており、それらのいくつかはアプリケーション内部からの要求、又はユーザーが手動によって実行できる。例えば、完全実装されたAccessソフトウェアを持たない人たちと完全に書式化されたレポートを共有するための非常にコンパクトなAccessのスナップショット形式がある。Accessはまた、容易にMicrosoft SQL Serverにアップグレード（アップサイジングという）することができる。
Excelに慣れているユーザーから見れば、クリップボードを経由してAccessとデータを簡単にやりとりできる機能は大いに魅力的であろう。小さなデータベースなら、わずかな操作で全体をExcelに貼り付けることが可能なので、便利なだけセキュリティが甘くなることには注意が必要だ。
完全なRDBMSと異なり、AccessのデータベースエンジンJETにはデータベーストリガおよびストアドプロシージャが存在しない。Accessは基礎となるテーブルに対する変更を引き起こすようなコードをフォームに含めることを認めており、また、Accessに含まれるパススルー・クエリや他の技術を用いて、外部のRDBMSがサポートしているストアドプロシージャを実行することも一般的である。
Access内の各オブジェクト（テーブル、クエリ、フォーム、レポート、マクロ、モジュール等）は、拡張子がaccdbおよびmdbのデータベースファイルに保存されている。
運用上の注意点としては、Accessデータベースファイルはレコードの追加削除を繰り返すと、ファイルの容量が膨らみ大きくなってしまうので、適宜「最適化」を行う必要がある。
また、「最適化」後においてもAccessの特性上、必要以上に容量を確保するため、保存する場合はZipファイルなどに圧縮しておくと容量を削減できる場合が多い。

開発

Accessで利用できるプログラミング言語は、他のMicrosoft Officeスイートの製品同様、Visual Basic for Applicationsである。COMコンポーネントの2つのデータベース・アクセス・ライブラリが提供されている。すなわち、Accessのみで利用可能な従来のData Access Objects (DAO) と、新しいActiveX Data Objects (ADO) である。
Microsoft Accessは小さなプロジェクトには容易に使えるが、アプリケーションの設計が貧弱な場合、大規模なプロジェクトに対しては非効率的に働く。
また、ADOやODBC経由でWebサーバとの連携も可能であり、Webアプリケーションのデータベースとしても利用可能ではあるが、Access自体がWebDBとしての利用を想定した設計がされていないものであるため、WebDBとして利用した場合、予期せぬ、かつ解決困難な不具合が生ずる可能性がある。
すべてのデータベースのクエリ、フォーム、及びレポートはデータベースの中に格納され、リレーショナル・モデルの理想と一致するように、それらを物理的に構造化した階層は作れない。
1つの設計技術はAccessのアプリケーションをデータとプログラムに分割することである。1つのデータベースはテーブルとリレーションシップのみを含むべきであり、一方他のデータベースはすべてのプログラム、フォーム、レポート、及びクエリを含み、最初のデータベースのテーブルにリンクする。なお、Accessはリンクする場合に相対パスを許可しないため、開発環境は製品環境と同じパスを持たなければならない（ただし、Accessがカレント・パスにバックエンド・ファイルを見つけられない時、ディレクトリ・ツリー内を検索して、あるバックエンド・ファイルを捜し出せる独自の「動的リンカ」をVBA内に記述できる）。
この技術はまた、開発者がアプリケーションを周囲の異なるファイルに分割することを可能にするため、ある種の構造は可能となる。Accessではデータベース・ファイルが大きくなり過ぎたり、ネットワーク上で多人数が同時にデータベースにアクセスした場合などで、データベースが損傷を受ける可能性が高まることが指摘されており、分割は有効な対応策と考えられている。
Accessはもともとスタンドアローンで使われることを想定されている製品なので、入門書で紹介されているような、スタンドアローンで開発したデータベースを複数のユーザーが共有するような使い方では、しばしばパフォーマンスが極端に低下する。このようなケースでは、後述のようにテーブル本体をサーバのMicrosoft SQL Serverなどの中におき、ODBCでリンクする方法がある。ODBCリンクは遅いという偏見があるが、データ検索をテーブル直接でなく、インデックスから行うようにすると、ネットワークトラフィックを大幅に軽減でき、実用的なパフォーマンスが得られるようになる。Access 2000以降にはMSDEというMicrosoft SQL Serverのサブセット版が付属しているので、小規模C/Sデータベースの開発も可能となっているが、ODBCリンクを活用すればOracleやMySQL、PostgreSQLなどのフロントエンド開発ツールとしてAccessを利用する道も開けている。
システムの中核にAccessを据えた場合、競争が熾烈なオフィススイート製品ゆえの頻繁なプログラムの更新には注意が必要である。たとえば、Access 2003ではSP2にアップデートをするとデータベースファイルにリンクしているExcelワークシートのデータは参照のみが可能であり、リンク先ワークシート上のデータを直接更新できないようにその機能に制約が設けられた。Accessを使ったシステム開発においても、このように業務アプリケーションの機能に影響を及ぼすことが起こり得るため、システム運用中のツール（Accessのバージョン（リビジョン））自体の管理にも注意を払う必要がある。

アップサイジング

Access2000以降、スタンドアローンのデータベース（accdbファイルとmdbファイル形式）に加えて、別のMicrosoft SQL Server（またはMSDE）内にテーブルをおき、ビューやストアドプロシージャ、トリガーを定義するプロジェクトと呼ばれる開発手法（adpファイル形式）が備わった。accdbやmdbからadpへの移行をアップサイジングと呼んでいる。Accessのデータベースユーティリテイとしてアップサイジングウイザードが用意されているが、システム全体の移行にはクエリの手直しなどが必要で、決して容易な作業ではない。困難を回避するには、accdbやmdbシステムが肥大化する前にアップサイジングを行い、固有のノウハウを早く蓄積すべきである。なおアップサイジングウイザードは2013から廃止された。
mdbファイルの中のテーブルやクエリの実体はローカルにそのまま存在するが、adpファイルの中のテーブルやクエリ（ビュー、ストアドプロシージャなど）の実体はMicrosoft SQL Server内に存在する。そのためadpファイルはMicrosoft SQL Serverの管理ツールとしても機能する。ただしダイレクトにテーブルなどの定義・編集が可能となるのは、Access2000ではMicrosoft SQL Server7.0（またはMSDE）、Access2003ではMicrosoft SQL Server 2000（またはMSDE2000）である。いずれもMicrosoft SQL Server 2005（Expressを含む）と接続はできるが、テーブルなどの編集・改変はできない。Microsoft SQL Server 2005のテーブルの編集などはAccess2007およびSQL Server Management Studio（無償のExpressもある）で行える。
adpにおけるMicrosoft SQL Serverとの接続についてはODBCリンクより効率がよく有益な手法だが、プロジェクト開発に関する参考書籍など必要な情報が極端に少ないのが現状である。なおテーブルとリレーションシップの定義、ビューの作成など基本的なデータベース設計をadpで行い、入力フォームと出力レポートの設計をaccdbやmdbで行い、データをODBCリンクで結ぶという、併用的折衷的な開発スタイルもある。この場合、accdbやmdbにおいて各種外部ファイルのリンクテーブルとローカルテーブルを使い分けるといった、柔軟なシステム設計が可能となる。
ともあれ、データベース本体とフロントエンドを分離するアップサイジング開発においては、常にネットワークトラフィックの軽減を意識しなければならず、1台のPC内で完結でき、それだけわがままが許されるスタンドアローン開発とは発想の転換が必要となり、必然的にVBAコーディングが増加して、Access本来の魅力である手軽さが失われることになる。

Microsoft Access Runtime

Accessで開発されたアプリケーションを他のコンピュータで実行させたい場合、Accessが必要となる。しかし開発せずに実行のみの場合においてはAccessライセンスを購入せずとも、適切なMicrosoft Access Runtimeをインストールすることで開発されたアプリケーションを実行できる。ランタイムであるため開発に必要な機能は使用できない。