Microsoft Accessでシステム開発

Aceessでのシステム開発に関するコラム集です。

Accessのオブジェクト構成を理解すると、システム開発の考え方が変わる

Accessは「1枚岩のツール」ではない

Accessは一見すると、テーブルを作って、フォームを作って、クエリを書くだけのシンプルなツールに見えます。

しかし内部的には、役割の異なる複数のオブジェクトが明確に分離された構造を持っています。
このオブジェクト構成を意識するかどうかで、Access開発は「その場しのぎ」から「設計されたアプリ」へ変わります。

テーブルは「データの責任」を持つだけ

Accessにおけるテーブルは、データを正しく、矛盾なく保存することだけを役割としています。

・画面表示
・入力チェック
・業務ルール

これらは本来テーブルの責任ではありません。

Excel感覚でAccessを使うと、「テーブルを見やすくする」「意味のある列名を並べる」といったことを考えがちですが、Accessではテーブルは極力無機質である方が健全です。

この割り切りができると、データ構造が安定し、後工程が楽になります。

クエリは「処理」を担う中核オブジェクト

Accessのクエリは、
単なるSQLの実行結果ではありません。

・データの抽出
・加工
・集計
・更新

といった処理ロジックそのものを担う存在です。

フォームやVBAに処理を詰め込むよりも、クエリに任せられるものはクエリに任せる。この考え方ができると、

・処理の見通しが良くなる
・修正箇所が特定しやすくなる
・性能問題が起きにくくなる

といった効果が出てきます。

フォームは「UI専用オブジェクト」

Accessのフォームは、データ入力画面であると同時に、ユーザーとの接点を担うUI層です。

重要なのは、
フォームに「業務の正解」を持たせすぎないことです。

・入力補助
・操作性
・見やすさ

はフォームの責任ですが、業務ルールそのものはクエリやVBAに委ねる方が保守性は高くなります。

フォームは壊れやすい部分だからこそ、役割を限定する意識が重要です。

レポートは「結果を伝える」ための存在

Accessのレポートは、帳票作成ツールとして非常に優秀ですが、設計上は「出力専用」です。

データの加工や判断をレポート側で行い始めると、構造が一気に複雑になります。

「レポートは、すでに整ったデータを見やすく伝えるだけ」

この割り切りができると、帳票修正も怖くなくなります。

VBAは「接着剤」として使う

VBAはAccessの中で最も強力な存在ですが、何でも書けるがゆえに乱用されがちです。

VBAの本来の役割は、

・オブジェクト同士をつなぐ
・処理の流れを制御する
・例外的な判断を行う

といった接着剤的な位置づけです。

VBAにすべての処理を書いてしまうと、どこで何をしているのか分からないシステムになります。

オブジェクト構成を意識すると設計視点が変わる

Accessのオブジェクト構成を理解すると、自然と次のような考え方に変わります。

・データはどこで守るべきか
・処理はどこに置くべきか
・変更が多い部分はどこか

これは、他のシステム開発で言う「レイヤー設計」や「責務分離」と同じ発想です。

Accessは設計の練習台としても優秀

Accessは、小規模であっても本格的なアプリケーション設計を体験できる環境です。

オブジェクト構成を意識して作られたAccessは、「便利なツール」を超えて、立派な業務アプリケーションになります。

Accessを使っているのに、設計が見えないと感じるなら、まずはオブジェクト構成から見直してみる価値があります。