スポンサーリンク

テーブル設計でよくある落とし穴とその回避法

スポンサーリンク
Access
スポンサーリンク

こんにちは、なかぜんです。

業務アプリを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でのテーブル設計における「よくある落とし穴」とその回避法についてご紹介しました。

  • 構造化されたデータ設計を心がける
  • 主キーは変更されないものを使う
  • 正規化はバランスが命

こうした意識があるだけで、後々のシステム保守がぐっと楽になります。

次のステップ

次回は「フォーム設計でよくある落とし穴とその回避法」について解説予定です。お楽しみに!

それでは、なかぜんでした。