こんにちは、なかぜんです。
業務アプリをAccessで作り込むうえで、最も重要な基盤といえるのが「テーブル設計」。しかし、ここに落とし穴があることを見落としてしまうと、後々フォームやクエリ、さらにはメンテナンス時に大きな手戻りが発生します。
この記事では、Accessのプロとして知っておきたい「よくあるテーブル設計の落とし穴」と「そのスマートな回避方法」を、実務での経験を交えて丁寧に解説します。
「最初に正しく設計することで、10年後も壊れないデータベースを作る」——そんな設計術を一緒に学んでいきましょう。
よくある落とし穴とその原因
1. フィールドに複数の意味を持たせてしまう
典型的な例が「住所」や「商品仕様」などを1つのメモ型や長文テキスト型に詰め込んでしまうケース。将来的に検索や集計が難しくなります。
NG例:
住所: 東京都新宿区西新宿1-1-1 ビル名5F 担当:山田
この設計の問題点:都道府県、市区町村、番地、担当者などが一体化しており、条件検索・抽出が困難。
回避法:フィールドを意味ごとに分割し、構造化データとして設計しましょう。
OK例:
都道府県: 東京都
市区町村: 新宿区
番地: 西新宿1-1-1
ビル名: ビル名5F
担当者: 山田
2. プライマリキーを誤って自然キーにしてしまう
社員番号や商品コードなど「人が考える識別子」をそのまま主キーにすると、変更リスクが生じます。
NG設計:社員コードを主キーに設定
推奨設計:AutoNumber型の「ID」を主キーにし、社員コードは別フィールドとして扱う
社員ID(AutoNumber)← 主キー
社員コード(Text)← 管理用
社員名(Text)
これにより、コード変更時の影響範囲が最小限に抑えられます。
3. 正規化のやりすぎ・やらなさすぎ
テーブル設計のバランスを欠くと、開発や運用に悪影響が出ます。
- やらなさすぎ:同じ顧客名や商品名を何度も手入力
- やりすぎ:少量データまで別テーブル化しすぎてJOIN地獄
なかぜんの提案:
業務アプリでは「第3正規形をベースにしつつ、参照のしやすさ・クエリの書きやすさとのバランスをとる」ことが重要です。
実務で役立つテーブル設計の具体例
例:受注管理システムのベース構造
'【T_顧客】テーブル
顧客ID (AutoNumber) ← 主キー
顧客名 (Text)
住所 (Text)
'【T_商品】テーブル
商品ID (AutoNumber)
商品名 (Text)
単価 (Currency)
'【T_受注ヘッダ】テーブル
受注ID (AutoNumber) ← 主キー
受注日 (Date)
顧客ID (Number) ← 外部キー(T_顧客)
'【T_受注明細】テーブル
明細ID (AutoNumber)
受注ID (Number) ← 外部キー(T_受注ヘッダ)
商品ID (Number) ← 外部キー(T_商品)
数量 (Number)
このように「ヘッダ+明細」の2層構造で受注管理を行うと、集計や帳票出力がしやすくなります。
注意点とよくあるミス
- Yes/No型の多用:条件が複雑になると逆に扱いづらくなる
- 日付フィールドの未分離:年月日をバラした方が集計がしやすいケースも
- 初期値の未設定:「未入力」を放置すると集計時に誤認識されやすい
特に「NULL」と「0」や「False」を区別して考えるクセを持つことが重要です。
応用ポイント:設計フェーズでのVBA活用
テーブル項目を自動生成するVBA例
Sub CreateTable()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Set db = CurrentDb
Set tdf = db.CreateTableDef("T_ログ")
With tdf
.Fields.Append .CreateField("ID", dbLong)
.Fields("ID").Attributes = dbAutoIncrField
.Fields.Append .CreateField("操作内容", dbMemo)
.Fields.Append .CreateField("操作日時", dbDate)
End With
db.TableDefs.Append tdf
MsgBox "T_ログテーブルを作成しました", vbInformation
End Sub
設計ミスが致命的になる前に、テンプレートやツールで自動生成・管理するのも上級者の戦略です。
まとめ:正しい設計がすべてを救う
今回は、Accessでのテーブル設計における「よくある落とし穴」とその回避法についてご紹介しました。
- 構造化されたデータ設計を心がける
- 主キーは変更されないものを使う
- 正規化はバランスが命
こうした意識があるだけで、後々のシステム保守がぐっと楽になります。
次のステップ
次回は「フォーム設計でよくある落とし穴とその回避法」について解説予定です。お楽しみに!
それでは、なかぜんでした。
