要約
Microsoft Accessでデータベースを作るとき、最初に理解したいのはフォームの作り方やVBAではなく「データをどのような構造で保存するか」です。Accessでは、顧客・商品・受注など異なる種類の情報をテーブルごとに分け、主キーや外部キーを使って関連付けます。そして、保存されたデータをクエリで検索・集計し、フォームで入力し、レポートで帳票として出力します。本記事では、フィールド・レコード・主キー・外部キー・リレーション・正規化など、Accessを正しく設計するために欠かせないデータベースの基本を、顧客管理・受注管理の具体例と図解を使ってわかりやすく解説します。
この記事でわかること
この記事を読むと、Accessデータベースの基本構造、テーブル・フィールド・レコードの違い、主キーと外部キーの役割、テーブル同士をリレーションで結び付ける理由、データ重複を減らす正規化の考え方、そしてクエリ・フォーム・レポートがどのようにテーブルのデータを利用しているのかまで、一連の仕組みとして理解できます。
- AccessのデータベースとExcelの「表」の違い
- テーブル・フィールド・レコード・データ型の基本
- 主キー・外部キー・1対多リレーションの意味
- なぜ顧客・商品・受注を別テーブルに分けるのか
- 正規化を初心者向けにどう理解すればよいか
- クエリ・フォーム・レポートとテーブルのつながり
- 実務で失敗しにくいデータベース設計の考え方
この記事の主な内容
1.Accessデータベースとは？まず30秒で仕組みを理解しよう
2.テーブルの基礎｜フィールド・レコード・データ型・主キーとは？
3.なぜテーブルを分ける？リレーショナルデータベースの考え方
4.主キー・外部キー・リレーションを顧客・受注データで理解する
5.クエリ・フォーム・レポートはテーブルとどうつながっている？
6.初心者が知っておきたい良い設計・悪い設計
7.まとめ
8.よくある質問（FAQ）
想定読了時間：約12～18分
Accessデータベースとは？まず30秒で仕組みを理解しよう
Accessは、単にデータを一覧表として保存するソフトではありません。複数のテーブルに整理したデータを関連付け、検索・入力・集計・帳票出力まで一体として扱える「リレーショナルデータベース」です。
たとえば販売管理を考えると、顧客情報、商品情報、受注情報をすべて1つの表に詰め込むのではなく、「顧客」「商品」「受注」のように情報の主題ごとにテーブルを分けます。そのうえで顧客IDや商品IDを使って各テーブルを結び付けます。
データベースとExcelの表は何が違う？
Excelでも顧客一覧や売上一覧を作ることはできます。しかし、Excelは1枚の表の中で自由に入力・計算・加工することが得意な一方、Accessは「データを構造化して保存し、複数の情報を関連付けて利用する」ことを得意とします。
| 比較項目 | Excel | Access |
| 基本の考え方 | 1枚の表を中心に入力・計算 | 複数テーブルを関連付けて管理 |
| データの保存 | セル・シート | テーブル |
| データの関連付け | 関数・参照で対応 | 主キー・外部キー・リレーション |
| 検索・抽出 | フィルター・関数 | クエリ |
| 入力画面 | シートへ直接入力が中心 | フォームを作成可能 |
| 帳票 | 印刷レイアウトを作成 | レポートで帳票化 |
| 向く用途 | 自由な分析・単発集計 | 定型業務・継続的なデータ管理 |
| 初心者が最初に覚えたい考え方 |
| Accessでは「どんな画面を作るか」より先に「どの情報を、どのテーブルに保存するか」を決めます。画面は後から変更できますが、テーブル構造が崩れていると検索・集計・改修すべてが複雑になりやすいためです。 |
テーブルの基礎｜フィールド・レコード・データ型・主キーとは？
Accessのデータは基本的にテーブルへ保存します。テーブルを理解するうえで最初に覚えたいのが「フィールド」「レコード」「データ型」「主キー」です。
| 用語 | 意味 | 顧客テーブルの例 |
| テーブル | 同じ種類のデータを保存する場所 | 顧客テーブル |
| フィールド | 1つの項目・列 | 顧客名、住所、電話番号 |
| レコード | 1件分のデータ・行 | 顧客A社の1件分の情報 |
| データ型 | 保存する情報の種類 | 短いテキスト、日付/時刻など |
| 主キー | レコードを一意に識別する項目 | 顧客ID |
データ型は「見た目」ではなく用途で決める
電話番号や郵便番号は数字に見えますが、通常は計算に使いません。また先頭の0やハイフンを保持したい場合があります。そのため、数値型ではなく短いテキストとして管理するのが一般的です。
逆に、数量・単価・金額など計算する項目は数値型や通貨型、登録日や受注日は日付/時刻型のように、データの用途に合った型を選びます。
主キーは『この1件』を特定するためのID
顧客名を見れば誰のデータか分かるように思えますが、同じ会社名や同姓同名は存在します。また会社名が変更されることもあります。そこでAccessでは「顧客ID」のような重複しない値を主キーとして使い、各レコードを一意に識別します。
この主キーは、後で受注テーブルや案件テーブルと関連付ける際にも重要になります。
なぜテーブルを分ける？リレーショナルデータベースの考え方
初心者が最初につまずきやすいのが、「なぜわざわざ複数のテーブルに分けるのか」という点です。Excelの感覚では、顧客名・住所・商品名・単価・数量・受注日を1枚の表に並べた方が簡単に見えます。
しかし、同じ顧客が何度も注文するたびに、顧客名や住所を毎回入力すると、同じ情報が何度も重複します。住所変更があったときに過去レコードの一部だけ修正されると、同じ顧客なのに異なる住所が残ることもあります。
悪い例：1つのテーブルに全部入れる
| 顧客名 | 住所 | 商品名 | 単価 | 数量 | 受注日 |
| A商事 | 東京都中央区 | 商品A | 10,000 | 1 | 2026/08/01 |
| A商事 | 東京都中央区 | 商品B | 20,000 | 2 | 2026/08/03 |
| A商事 | 東京都中央区 | 商品A | 10,000 | 3 | 2026/08/10 |
| B工業 | 神奈川県横浜市 | 商品B | 20,000 | 1 | 2026/08/11 |
A商事の顧客名と住所が何度も保存されています。商品Aの単価も繰り返されています。この状態では、住所や単価を変更するときに複数行を修正する必要があります。
良い例：主題ごとにテーブルを分ける
| テーブル | 保存する内容 | 主キー |
| 顧客テーブル | 顧客名・住所・電話番号 | 顧客ID |
| 商品テーブル | 商品名・単価 | 商品ID |
| 受注テーブル | 顧客ID・商品ID・数量・受注日 | 受注ID |
顧客情報は顧客テーブルに1回だけ、商品情報は商品テーブルに1回だけ保存します。受注テーブルには、顧客名や商品名そのものではなく「どの顧客か」「どの商品か」を示すIDを保存します。
これが正規化の第一歩
正規化という言葉は難しく聞こえますが、初心者の段階では「同じ情報を何度も保存しない」「意味の違う情報を主題ごとに分ける」と理解するとよいでしょう。
| 正規化を難しく考えすぎない |
| 最初から第1正規形・第2正規形・第3正規形という用語を暗記する必要はありません。まずは『1セル1情報』『繰り返し項目を作らない』『顧客・商品・受注を分ける』という3点を意識するだけでも、設計品質は大きく変わります。 |
主キー・外部キー・リレーションを顧客・受注データで理解する
テーブルを分けただけでは、それぞれが独立した表のままです。そこで必要になるのが、主キー・外部キー・リレーションです。
主キーと外部キーの違い
| 項目 | 主キー | 外部キー |
| 役割 | 自分のテーブルの1件を一意に識別 | 他テーブルのレコードを参照 |
| 例 | 顧客テーブルの顧客ID | 受注テーブルの顧客ID |
| 重複 | 原則不可 | 同じ顧客の受注が複数あるため重複可 |
| 用途 | レコード特定 | テーブル間の関連付け |
『1対多』とは？
1人の顧客が複数回注文する場合、1件の顧客データに対して複数の受注データが存在します。この関係を「1対多」と呼びます。
顧客テーブル側では顧客IDは1回しか登場しません。一方、受注テーブルでは同じ顧客IDが何度も登場します。これにより、顧客情報を重複して保存せずに「この受注はA社のもの」という関係を持たせられます。
リレーションを使うと何ができる？
- 顧客名を変更しても、受注データを1件ずつ修正しなくてよい
- 顧客情報と受注情報をクエリで組み合わせられる
- 顧客別の売上・件数を集計できる
- 存在しない顧客IDを受注へ登録しないよう参照整合性を設定できる
- 将来SQL Serverへ移行する場合にも同じデータ構造を活かしやすい
参照整合性とは
参照整合性は、関連するテーブルのデータに矛盾が生じないようにする仕組みです。たとえば顧客テーブルに存在しない顧客IDを、受注テーブルへ登録しないようにできます。実務では、削除時の挙動や履歴保持なども考慮して設定する必要がありますが、初心者はまず「関連先が存在することをAccessにチェックさせる仕組み」と理解しておけば十分です。
クエリ・フォーム・レポートはテーブルとどうつながっている？
Accessではデータの保存場所はテーブルです。クエリ・フォーム・レポートは、それぞれテーブルやクエリのデータを目的に応じて利用します。
| オブジェクト | 役割 | データを保存する？ |
| テーブル | データを保存 | ○ |
| クエリ | 検索・抽出・結合・集計 | 基本は× |
| フォーム | 入力・編集・操作画面 | ×（テーブル等へ反映） |
| レポート | 一覧・帳票・印刷 | × |
| VBA・マクロ | 処理の自動化 | × |
クエリは複数テーブルをつなぐ『窓口』になる
顧客テーブルと受注テーブルをリレーションで結んだら、クエリを使って顧客名と受注日、金額などを1つの結果として表示できます。利用者から見ると1枚の表のように見えても、裏側では複数のテーブルから必要な情報を組み合わせています。
フォーム・レポートはデータベースを使いやすくする
利用者にテーブルを直接触らせず、フォームから入力させれば入力ミスや誤操作を減らしやすくなります。レポートを使えば、顧客一覧、請求書、売上一覧などを定型レイアウトで出力できます。
このため、Accessの画面開発ではテーブル設計を先に行い、その上にクエリ・フォーム・レポートを作るのが基本です。
初心者が知っておきたい良いデータベース設計と失敗しやすい設計
| よくある設計ミス | なぜ問題か | 改善の考え方 |
| 主キーを設定しない | 同じレコードを一意に識別できない | IDなど一意の主キーを設定 |
| 1テーブルに全部入れる | 重複・更新漏れが増える | 主題ごとに分ける |
| 商品1・商品2・商品3の列を作る | 件数が増えるたび列追加が必要 | 明細テーブルに行として保存 |
| 顧客名で関連付ける | 名称変更・同名で不整合 | 顧客IDで関連付ける |
| 電話番号を数値型 | 先頭0・ハイフンに不向き | 短いテキスト |
| フォームから先に作る | 裏側の構造が後付けになる | テーブル→リレーション→画面 |
| 将来の件数を考えない | 性能・容量で後から問題 | 利用人数・件数・連携を想定 |
『商品1・商品2・商品3』のような列は作らない
1件の受注に複数の商品があるからといって、商品1・商品2・商品3という列を作ると、4商品目が発生した瞬間に設計変更が必要です。この場合は「受注明細テーブル」を作り、1商品を1行として保存します。
Accessが遅い・改修しにくい原因がテーブル設計の場合もある
フォームやVBAの処理を改善しても、データが重複していたり、テーブル同士の関係が曖昧だったりすると、クエリが複雑になりやすくなります。既存Accessの改修では、画面やコードだけでなくデータ構造から確認することが重要です。
また、将来的にSQL Serverへアップサイジングする場合も、主キーやリレーションが整理されているデータベースの方が移行しやすく、Accessのフロントエンドを活かした段階的な拡張にもつなげやすくなります。
| そのAccess、本当に正しいテーブル設計になっていますか？ |
| Accessの不具合・処理速度・改修難易度は、フォームやVBAではなく、元のテーブル構造が原因になっている場合があります。 既存Accessのテーブル・主キー・リレーションを調査し、Excel業務のAccess化からSQL Serverへのアップサイジングまで、データベース設計を含めて支援可能ですのでお気軽にご相談ください。 |
まとめ｜Accessは『画面』より先に『データ構造』を考える
Accessデータベースの基礎で最も重要なのは、テーブル・クエリ・フォーム・レポートという機能名を覚えることだけではありません。どのデータを、どのテーブルに保存し、どのIDで関連付けるかを考えることです。
- データは主題ごとにテーブルへ分ける
- 1行＝レコード、1列＝フィールドとして考える
- 各テーブルには主キーを設定する
- 他テーブルを参照するIDは外部キーとして使う
- 1対多のリレーションで情報を結び付ける
- 同じ情報を何度も保存しないよう正規化を意識する
- クエリ・フォーム・レポートはテーブルの上に作る
この基本を理解すると、Accessのテーブル・クエリ・フォーム・レポートが別々の機能ではなく、1つのデータベースとしてつながって見えてきます。
よくある質問（FAQ）
関連する情報を複数のテーブルに整理して保存し、主キー・外部キー・リレーションによって結び付けて利用するリレーショナルデータベースです。
Excelは自由な表計算・分析に向き、Accessは複数テーブルを関連付けて継続的にデータを管理する用途に向いています。
小さな単純データであれば1テーブルでも構いませんが、顧客・商品・受注など意味の異なる情報は分ける方が重複や更新ミスを減らせます。
実務用データベースでは基本的に各テーブルへ主キーを設定することをおすすめします。レコードを一意に識別し、他テーブルとの関連付けにも利用できます。
他のテーブルの主キーを参照するためのフィールドです。受注テーブルの顧客IDなどが例です。
顧客1件に対して受注が複数件存在するような関係です。Accessの業務システムで非常によく使われます。
データの重複や矛盾を減らすために、情報を適切なテーブルへ分ける設計の考え方です。初心者はまず『同じ情報を何度も保存しない』ことから意識するとよいでしょう。
通常の選択クエリは、元のテーブルから条件に合うデータを表示する仕組みであり、検索結果を別に保存しているわけではありません。
小規模な練習用DBであれば可能です。実際の企業業務ではデータ量、複数人利用、履歴、権限、他システム連携などを考慮する必要があるため、規模によって専門家への相談を検討します。
参考情報
Microsoft Support：Learn the structure of an Access database
https://support.microsoft.com/en-us/access/learn-the-structure-of-an-access-database
Microsoft Support：Guide to table relationships
https://support.microsoft.com/en-us/access/guide-to-table-relationships
Microsoft Support：Add or change a table’s primary key in Access
https://support.microsoft.com/ja-jp/access/add-or-change-a-table-s-primary-key-in-access