「1つのテーブルに全部入れてしまうと、後から修正が大変になった」「同じ情報が何度も重複して入力されてしまう」「一部のデータを変えたらほかの行も変えなければならなくなった」——Accessでデータベースを作り始めると、こうした問題にぶつかることがあります。これらはすべて、データベースの設計段階で「正規化」を行っていないことが原因です。
データベース正規化(normalization)とは、テーブルのデータ構造を段階的に整理し、データの重複・矛盾・更新ミスを起きにくくするための設計手法です。正規化には「第1正規形(1NF)」「第2正規形(2NF)」「第3正規形(3NF)」という段階があり、それぞれのルールに従ってテーブルを分割・再構成していきます。正規化を正しく行うと、データの追加・変更・削除が安全になり、クエリやフォームの開発もスムーズになります。MOS Access 365試験(MO-500)では、テーブル設計に関する知識として正規化の概念が背景として問われるほか、リレーションシップ設計の実操作が出題範囲に含まれます。
「正規化って聞いたことはあるけれど何をすればいいか分からない」「第1・第2・第3正規形の違いがつかめない」「実際にAccessでどう設計すればいいの?」という方のために、本記事では非正規テーブルの問題から始め、各段階の変換手順を具体例を交えてステップごとに解説します。
データベース正規化とは
正規化とは、リレーショナルデータベースのテーブル構造を、一定のルール(正規形)に従って整理する作業です。正規化の目的は次の3点に集約されます。
- データの重複を排除する:同じ情報が複数の行に重複して保存される状態をなくす
- 更新異常を防ぐ:1箇所のデータを変更したら別の行でも同じ修正が必要になる状態をなくす
- 挿入異常・削除異常を防ぐ:本来とは無関係なデータとセットでしか登録・削除できない状態をなくす
正規化の段階は「第1正規形(1NF)→第2正規形(2NF)→第3正規形(3NF)」と進みます。実務の多くのケースでは第3正規形まで適用すれば十分な設計になります。Accessでは最終的に複数のテーブルをリレーションシップで結び、クエリで結合して使用する形が正規化後の標準的な構成です。
正規化前のテーブル(非正規テーブル)の問題を確認する
正規化の手順を学ぶ前に、問題のある「非正規テーブル」を例として見てみましょう。ここでは「受注管理テーブル」を例にします。
| 受注ID | 顧客名 | 顧客住所 | 商品コード1 | 商品名1 | 数量1 | 商品コード2 | 商品名2 | 数量2 |
|---|---|---|---|---|---|---|---|---|
| 001 | 山田太郎 | 東京都千代田区 | A001 | ノート | 3 | A002 | ペン | 5 |
| 002 | 鈴木花子 | 大阪府大阪市 | A001 | ノート | 2 | |||
| 003 | 山田太郎 | 東京都千代田区 | A003 | 消しゴム | 4 | A001 | ノート | 1 |
このテーブルには複数の問題があります。①1つのセルに複数の値(商品コード1/2)が列として並んでおり、商品が3つ以上になると列が足りなくなります。②「山田太郎」の住所が複数の行に繰り返し入力されており、住所が変わったときに全行を修正しなければなりません。③「ノート(A001)」の商品名が複数行に重複して存在し、商品名を変更したときに全行を更新する必要があります。これらが更新異常・重複の典型例です。
第1正規形(1NF)への変換
第1正規形のルール
第1正規形(First Normal Form:1NF)の条件は「各セルには1つの値だけを格納する(繰り返しグループを排除する)」ことです。上の例では「商品コード1/商品名1/数量1」「商品コード2/商品名2/数量2」という繰り返しグループが問題です。
1NFへの変換手順
繰り返しグループを排除するために、1受注1商品を1レコードとして縦に展開します。
| 受注ID | 顧客名 | 顧客住所 | 商品コード | 商品名 | 数量 |
|---|---|---|---|---|---|
| 001 | 山田太郎 | 東京都千代田区 | A001 | ノート | 3 |
| 001 | 山田太郎 | 東京都千代田区 | A002 | ペン | 5 |
| 002 | 鈴木花子 | 大阪府大阪市 | A001 | ノート | 2 |
| 003 | 山田太郎 | 東京都千代田区 | A003 | 消しゴム | 4 |
| 003 | 山田太郎 | 東京都千代田区 | A001 | ノート | 1 |
各セルに1つの値だけになりました。この状態が第1正規形です。ただし、「山田太郎」の情報が複数行に重複していること、「ノート(A001)」の商品名も繰り返されていることは残っています。これを解消するのが次のステップです。
なお1NFのテーブルでは「受注ID+商品コード」の組み合わせが主キー(複合主キー)になります。Accessではテーブルデザインビューで[主キー]ボタンを使い、Ctrlを押しながら複数フィールドを選択して複合主キーを設定できます。
第2正規形(2NF)への変換
第2正規形のルール
第2正規形(Second Normal Form:2NF)の条件は「第1正規形を満たしていること」+「主キーの一部にだけ依存する列(部分関数従属)を排除すること」です。1NFのテーブルでは複合主キーが「受注ID+商品コード」でしたが、いくつかの列はどちらか一方にしか依存していません。
- 「顧客名」「顧客住所」→「受注ID」だけに依存する(商品コードとは無関係)
- 「商品名」→「商品コード」だけに依存する(受注IDとは無関係)
- 「数量」→「受注ID+商品コード」の両方に依存する(完全関数従属)
「顧客名・顧客住所」が「受注ID」だけに依存しているのに、商品明細行ごとに繰り返されているのが問題です。これを「部分関数従属」と呼びます。
2NFへの変換手順:テーブルを分割する
部分関数従属を排除するために、テーブルを3つに分割します。
受注テーブル(主キー:受注ID)
| 受注ID | 顧客名 | 顧客住所 |
|---|---|---|
| 001 | 山田太郎 | 東京都千代田区 |
| 002 | 鈴木花子 | 大阪府大阪市 |
| 003 | 山田太郎 | 東京都千代田区 |
受注明細テーブル(主キー:受注ID+商品コード)
| 受注ID | 商品コード | 数量 |
|---|---|---|
| 001 | A001 | 3 |
| 001 | A002 | 5 |
| 002 | A001 | 2 |
| 003 | A003 | 4 |
| 003 | A001 | 1 |
商品テーブル(主キー:商品コード)
| 商品コード | 商品名 |
|---|---|
| A001 | ノート |
| A002 | ペン |
| A003 | 消しゴム |
これで「ノート」という商品名は商品テーブルの1箇所にだけ存在するようになり、商品名を変更するとき修正は1か所で済みます。これが第2正規形です。
第3正規形(3NF)への変換
第3正規形のルール
第3正規形(Third Normal Form:3NF)の条件は「第2正規形を満たしていること」+「主キー以外の列どうしの依存関係(推移関数従属)を排除すること」です。
2NF後の受注テーブルを見ると、「顧客名」と「顧客住所」はどちらも受注IDに依存していますが、「顧客住所」は実際には「顧客名(または顧客ID)」に依存しています。つまり「受注ID → 顧客名 → 顧客住所」という依存の連鎖(推移関数従属)が存在します。山田太郎が異なる受注IDを持つとき、両行に同じ住所が入っている点がこの問題を示しています。
3NFへの変換手順
推移関数従属を排除するために、顧客情報を別テーブルに分離し、受注テーブルには顧客IDを外部キーとして残します。
顧客テーブル(主キー:顧客ID)
| 顧客ID | 顧客名 | 顧客住所 |
|---|---|---|
| C001 | 山田太郎 | 東京都千代田区 |
| C002 | 鈴木花子 | 大阪府大阪市 |
受注テーブル(主キー:受注ID)
| 受注ID | 顧客ID(外部キー) | 受注日 |
|---|---|---|
| 001 | C001 | 2026-01-10 |
| 002 | C002 | 2026-01-12 |
| 003 | C001 | 2026-01-15 |
山田太郎の住所が変わっても、顧客テーブルの1行を修正するだけでよくなります。受注テーブルは顧客IDを外部キーとして参照するため、顧客情報との整合性も自動的に保たれます。これが第3正規形です。
正規化後の全体テーブル構成まとめ
3NFまで正規化した結果、テーブルは4つに分割されました。
| テーブル名 | 主キー | 外部キー | 保持する情報 |
|---|---|---|---|
| 顧客テーブル | 顧客ID | (なし) | 顧客名・住所 |
| 商品テーブル | 商品コード | (なし) | 商品名・単価など |
| 受注テーブル | 受注ID | 顧客ID | 受注日・顧客の参照 |
| 受注明細テーブル | 受注ID+商品コード | 受注ID・商品コード | 各商品の数量 |
Accessのリレーションシップウィンドウ([データベースツール]→[リレーションシップ])で4つのテーブルを追加し、外部キーと主キーをドラッグして結線します。「参照整合性を設定する」にチェックを入れることで、受注テーブルに存在しない顧客IDの入力や、受注明細テーブルに紐付いた商品コードの削除を自動的に防げます。
Accessで正規化テーブルを設計する実践手順
手順1:テーブルをデザインビューで作成する
[作成]タブ→[テーブルデザイン]をクリックしてデザインビューを開きます。フィールド名・データ型・説明を1行ずつ入力します。主キーにするフィールドの行を選択して[主キー]ボタン(鍵マーク)をクリックし、主キーを設定します。複合主キーの場合はCtrlを押しながら複数の行を選択してから[主キー]をクリックします。
手順2:リレーションシップを設定する
[データベースツール]タブ→[リレーションシップ]をクリックします。「テーブルの表示」ダイアログで全テーブルを追加し、[閉じる]をクリックします。結合したいフィールドをドラッグして結線し、「リレーションシップの編集」ダイアログで「参照整合性を設定する」にチェックを入れ、必要に応じて「フィールドの連鎖更新」「レコードの連鎖削除」を選択して[作成]をクリックします。
手順3:正規化の効果を確認する
テーブルを正規化し、リレーションシップを設定した後、クエリを作成して複数テーブルを結合します。[クエリデザイン]を開き、顧客テーブル・受注テーブル・受注明細テーブル・商品テーブルをすべて追加すると、リレーションシップで設定した結合線が自動的に表示されます。必要なフィールドを追加して実行すると、分散したテーブルが統合されたビューとして一覧表示されます。これが正規化後のAccessデータベースの基本的な使い方です。
正規化のメリットと実務上の注意点
| 項目 | 内容 |
|---|---|
| データ更新が1か所で済む | 顧客住所や商品名を変更するとき、1テーブルの1行を修正するだけで全体に反映される |
| データの整合性が保たれる | 参照整合性により、存在しない顧客IDの受注登録や、受注に紐付く商品の誤削除を防ぐ |
| ストレージ効率の向上 | 繰り返しデータがなくなるため、大量データでも容量を抑えられる |
| クエリの管理がしやすくなる | テーブル1つあたりの責任が明確になるため、クエリの設計・デバッグが容易になる |
| 注意点①:クエリの結合が増える | テーブルが増えるほどクエリの結合数が増え、設計の複雑さが上がる。不必要に細かく分割しすぎない |
| 注意点②:過度な正規化を避ける | レポートや集計の用途では意図的に非正規化(デノーマライズ)されたビューを別途用意する場合もある |
MOS Access試験での正規化・テーブル設計の出題ポイント
MOS Access 365試験(MO-500)のスキル領域「テーブルの作成と変更」および「データベースの作成と管理」では、正規化の概念を踏まえたテーブル設計の実操作が問われます。試験で正規化の理論そのものが直接出題されるわけではありませんが、リレーションシップ・参照整合性・主キー・外部キーの設定は頻出の実操作です。正規化の考え方を理解しておくと、試験中の問題の意図を素早く読み取ることができます。出題範囲に含まれます。分野別の出題数・配点は公表されていません。
- 主キーの設定:テーブルデザインビューで[主キー]ボタンを使い、単一フィールドまたは複合フィールドに主キーを設定できる
- 外部キーフィールドの作成:参照先テーブルの主キーと同じデータ型のフィールドを外部キーとして作成する
- リレーションシップの設定:[リレーションシップ]ウィンドウでテーブルを追加し、フィールドをドラッグして結合を作成できる
- 参照整合性の設定:「参照整合性を設定する」チェックにより整合性制約を有効化できる
- 連鎖更新・連鎖削除の設定:関連テーブルのレコードを自動更新・削除する設定を理解している
- テーブルの分割設計:1つの対象には1つのテーブルという設計原則を実践できる
MOS試験 テーブル設計・正規化チェックリスト
| 確認ポイント | 操作内容 | 難易度 |
|---|---|---|
| 1NFの確認 | テーブルに繰り返しグループ(列セット)がないか確認できる | ★☆☆ |
| 2NFの確認 | 複合主キーのテーブルで、一部にしか依存しない列がないか判断できる | ★★☆ |
| 3NFの確認 | 主キー以外の列どうしで依存関係がないか確認できる | ★★☆ |
| 主キー設定 | デザインビューで[主キー]ボタンを使い、単一・複合主キーを設定できる | ★☆☆ |
| 外部キーフィールド作成 | 参照先のデータ型に合わせた外部キーフィールドを作成できる | ★☆☆ |
| リレーションシップ設定 | [リレーションシップ]ウィンドウでテーブルを追加し、フィールドをドラッグして結合を作成できる | ★★☆ |
| 参照整合性の設定 | 「参照整合性を設定する」にチェックを入れ、整合性制約を有効化できる | ★★☆ |
| 連鎖設定の使い分け | 連鎖更新と連鎖削除の意味を理解して適切に設定できる | ★★☆ |
| 結合クエリ作成 | 正規化後の複数テーブルを結合したクエリを作成できる | ★★★ |
試験対策としては、非正規なテーブルを手元で再現して、テーブル分割→リレーションシップ設定→クエリ結合という一連の流れを繰り返し練習することが最も効果的です。MOS試験の試験時間は50分、採点は1,000点満点です。合格点は非公表で550点~850点が目安とされています。合格率は公表されていません。受験料は一般価格と学割価格の2種類(どちらも税込)があります。最新の受験料は公式サイトの「受験料・価格」(https://mos.odyssey-com.co.jp/exam/examfee.html)でご確認ください。
まとめ:正規化は「テーブルを何に分けるか」の設計判断
本記事のポイントをまとめます。
- データベース正規化とは:データの重複・更新異常・挿入・削除の不整合を防ぐために、テーブル構造をルールに従って整理する設計手法
- 第1正規形(1NF):各セルに1つの値だけを格納し、繰り返しグループを排除する。1レコード1行の原則を守る
- 第2正規形(2NF):1NFを満たした上で、複合主キーの一部にだけ依存する列(部分関数従属)を別テーブルに分離する
- 第3正規形(3NF):2NFを満たした上で、主キー以外の列どうしの依存関係(推移関数従属)を別テーブルに分離する
- Accessでの実装:テーブルデザインビューで主キーを設定し、リレーションシップウィンドウで外部キー結合と参照整合性を設定する
- 正規化のメリット:更新が1か所で済む・データ整合性が保たれる・ストレージ効率が上がる
- MOS試験との関係:正規化の概念はリレーションシップ設計・主キー・外部キーの実操作問題の背景知識として役立つ
正規化は「テーブルをいくつかに分けてリレーションシップで結ぶ」という設計判断です。最初は分割が増えることへの不安を感じるかもしれませんが、実際に非正規テーブルで運用を続けると、データ不整合や修正コストが後になって大きくのしかかってきます。まず小さなサンプルデータで非正規テーブルを作り、第1・第2・第3正規形への変換を自分の手で試してみることで、正規化の意味と効果が体感的に理解できるようになります。正規化の設計力が身につくと、Accessだけでなくあらゆるリレーショナルデータベースに応用できる汎用のスキルになります。
PR
MOS試験シリーズ共通の問題形式・採点方式・操作の確認方法を習得できる対策テキスト。Excel版ですが、試験の受け方や操作の覚え方はAccess試験にも直結する内容です。MOS全般の試験構造を把握したい方にお勧めします。
PR
Microsoft Copilot for Microsoft 365活用大全
Access・Excel・Word・PowerPointなどMicrosoft 365全体をAIで効率化するノウハウを網羅した一冊。正規化で整備したAccessデータを他のOfficeツールと連携して活用する方法のヒントにもなります。
