身近なデータベース Microsoft Access をマジメにエンジニアが使ってみた

Microsoft Access の使い方を工夫すれば強力なデータベースメンテナンスツールとなる

昨今、様々なデータ活用が進み、それに伴い様々なツールやサービス、ハードウェアが毎日のように生まれては消えていきます。そんなカンブリア紀並みに進化激しい時代、20年以上前から殆ど変わらぬ姿を保っている奇跡的なデータベースがあります。今回はガラデービーこと Microsoft Access について、マジメにデータベースエンジニアがイケている使い方を探してみました。(たぶん、一般的な使い方と違うと思います)

そもそも Microsoft Access って何よ？

Microsoft Access(以下、Access) は簡易的な開発が行えるデータベースアプリです。単品で購入することも可能ですが、Microsoft Office のある一定上のグレードを購入すると付いてきます。リリースされたのが1992年と古く、Windowsの普及共に2000年初めぐらいまでは使われてきました。しかし、取り扱うデータ量が増えたことで ORACLE や SQL Server などの専用のデータベースへのシフトが進み、今では細々と命を繋いでアプリと言えるかもしれません。

データベース ＋ 開発環境 ＋ 実行環境 が1つに纏まっている

Accessが「データベース」ではなく、「データベース ＋ アプリ」であることが最大の特徴です。Accessファイルの中には一般的なデータベースのテーブルやビューの代わりになるクエリなどが存在します。そして、フォームと言われるボタンやテキストボックスを配置して、テーブル更新などができる入力画面機能を開発・実行できることがメリットです。フォームに張り付けるボタンには初めから操作(アクション)を割り振ることができ、これらを使うことでプログラムを全く書かずにテーブル内のデータ検索、データ追加・変更・削除を行うことができます。

また、ExcelやCSVファイルなどのインポート/エクスポート処理が簡単に行えるため、非エンジニアでも簡単なデータベースシステムが作れるため、今でも中小企業では自社で開発・運用しているところはあるらしいです。

また、20年前から殆ど変わっていないシンプルな開発画面はノスタルジーさえ感じられ、昔からのWindowsアプリ開発者は抵抗なく開発を進められると思います。(私もその一人でした)

VBAマクロっていいよね

上記のように基本的な機能はノンプログラミングで実装可能です。そして、更に複雑な処理を実装したい場合はVBAマクロによって実現することが可能です。

VBAもAccess本体と同様に20年前から全く変わっていません。VBAは最近のプログラミング言語のような処理速度や自由度はありませんが、自然言語に近いプログラミング言語のため、比較的に習得のハードルが低いことが特徴です。また、VBAマクロはExcelなどでも使われているため、事例や技術者も多く、インターネットで検索すれば参考になる情報は沢山あります。

でもデータベースには色々と問題が。。。

20年前から殆ど変わっていないAccessですが、軽微な機能拡張が行われ外部へのインターフェースが増えたり、ウィザード機能でマクロを作れたりするようになりました。昔は10万件程度のテーブルの検索にちょっとした時間が掛かっていましたが、最新の Microsoft Access 2016 では一瞬で処理が終わります。「おっ！ なかなか使えるな！」っと思っていましたが、やっぱり以下のような昔からのデータベースとしての残念なところも変わっていませんでした。

1. テーブル結合を3つ以上できない(副問合せ風にすると回避可能)
2. SQL命令の副問合せなどで複雑な事をすると「クエリが複雑すぎます」とエラーダイアログが出る
3. 普通のSQL関数と命令が違う(CASE命令の代わりにSWITCH命令があるとか)
4. テーブル更新をやっていくとAccessファイルが肥大化する(テーブル削除してもファイルサイズが減らない)
5. テーブル更新処理の途中でコケるとAccessファイルが破損する

他にも色々と残念なところがありますが、書いているとキリがないのでこの辺にします。しかし、Accessファイルが壊れやすいというのはデータベースとして致命的です。これの回避策として「データベースの最適化/修復」という機能がAccessに付いていますが、100%修復でいる保証はありません。私もこのブログを書く前に1回壊して、痛い目を見ています。

データベース部分を外部データベースにすれば可能性が広がる

この様にAccessはちょっとした機能開発はクイックに行えるが、データベース機能には欠点があるという事はご理解いただけたと思います。そこでAccessのデータベース部分を外部データベースに置き換えて、Accessのデータベースとしての機能を補完する方法を取ります。

方法は簡単です。以下のようにAccessからODBC接続で外部データベースのテーブルにデータリンクするだけです。これによって、仮にAccessファイルが壊れてもデータベースのデータは救えます。(データリンクのためSQL命令の残念なところは継承されています)

この仕組みの導入個所としてはマスタメンテナンス機能としてAccessをツールとして使えます。AccessのテーブルのユーザーインターフェースはExcelのような表形式になっており、セルの中の値を変更することによって、データベースのテーブルの値を変更することができます。内部ではSQL命令によってテーブル変更が行われるため、大量データを持ったテーブル更新には不向きですが、部署マスタや社員マスタなど1,000行程度のマスタテーブルの更新なら問題なく行えます。また、ちょっとした機能を作りたい場合は、Accessのフォームを使うことで比較的短時間で実装可能だと思います。

Microsoft Access によって本流以外の隙間を埋める事ができる

一般的なシステム開発には、それなりの時間と費用、そして技術者が必要とされます。確かに利用頻度の多い機能やミスの許されないような機能ではきちんとした設計・開発を行う必要はあります。しかし、月に1回程度の使用頻度の機能や基幹系ではない社内向けの機能では、そこまで大掛かりな開発は費用対効果に合っていないと思います。この様なちょっとした機能開発では、クイックに作れて、比較的に誰でもカスタマイズが可能なAccessのようなツール系のアプリ開発環境でも十分だと思います。

システムを構築ではなく、ちょっとした要望を実現するための選択肢として Microsoft Access のような枯れた技術を選択肢として考えてみては如何でしょうか？