Access 2000 でのデータベースの正規化の基礎

文書翻訳 文書翻訳
文書番号: 209534 - 対象製品
難易度 : 低。シングル ユーザー コンピュータのユーザー インターフェイスに関する知識が必要です。

Microsoft Access 97 については、次の資料を参照してください。 100139
Microsoft Access 2002 については、次の資料を参照してください。 283878
すべて展開する | すべて折りたたむ

目次

概要

この資料では、データベースの正規化の専門用語を初心者向けに説明します。これらの専門用語の基礎を理解しておくと、リレーショナル データベースの設計について検討するときに役立ちます。

: マイクロソフトは、データベースの正規化の基礎を説明する WebCast も提供しています。この WebCast を表示するには、次のマイクロソフト Web サイトを参照してください。
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1
以前のバージョンの Access におけるこのトピックの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
100139 [ACC] データベースの正規化の基礎

詳細

正規化の説明

正規化とは、データベース内のデータを構築する処理のことです。正規化には、データを保護しながらデータベースをより柔軟にするよう設計された規則に従い、冗長性の除去および矛盾する従属関係を除去することによってテーブルを作成する作業、およびテーブル間のリレーションシップを確立する作業が含まれます。

冗長なデータがあると、ディスク領域が浪費され、保守上の問題点が生じます。複数の場所に存在するデータの変更が必要な場合、すべての場所でそれらのデータが常に同一になるように変更する必要があります。顧客の住所を変更する際に、データが保存されているのが顧客テーブルのみで、データベース内の他のテーブルに存在しない場合、変更作業を簡単に行うことができます。

"矛盾する従属関係" とは何でしょうか。特定の顧客の住所を探す場合に顧客テーブルを調べることは直感的にわかりますが、その顧客を担当している社員の給与を調べるために、顧客テーブルを参照するのは適切ではありません。社員の給与は、社員に関連付けられているか社員に従属するため、社員テーブルに移動する必要があります。しかし、矛盾する従属関係があると、データを見つけるパスが存在しないか破損していることになり、データの参照が困難になります。

データベースの正規化にはいくつかの規則があり、それぞれの規則を適用した状態は "正規形" と呼ばれます。最初の規則に従っているデータベースは "第 1 正規形" であるといわれます。最初の 3 つの規則に従っているデータベースは "第 3 正規形" であると見なされます。他のレベルの正規化も可能ですが、ほとんどのアプリケーションでは、第 3 正規形が最も高いレベルと見なされています。

多くの規則や規格がそうであるように、現実のシナリオは常に規則に完全に適合しているとは限りません。一般的に、正規化を行うと追加テーブルが必要となるため、わずらわしいと感じるユーザーもいます。正規化の最初の 3 つの規則のいずれかに違反した設計をする場合、冗長データや矛盾する従属関係など、アプリケーションで発生する可能性のある問題点を考慮しておく必要があります。

以下は、正規化の例です。

第 1 正規形

  • 各テーブルで繰り返し現れるグループを除去します。
  • 関連するデータごとに 1 つのテーブルを作成します。
  • 関連するデータ セットを主キーで識別します。
類似したデータを格納するために、1 つのテーブルで複数のフィールドを使用しないようにします。たとえば、在庫項目が 2 つの製造元から納入される場合、在庫レコードで "製造元コード 1" フィールドおよび "製造元コード 2" フィールドを使用して、その項目を追跡するケースを考えてみます。

3 つ目の製造元を追加するにはどうしたらよいでしょう。単にフィールドを追加しただけでは、プログラムとテーブルの変更が必要となり、製造元の数が動的に変化する場合に効率的に対応することができません。この場合は、すべての製造元の情報を別の製造元テーブルに格納し、項目番号キーを使用して製造元テーブルを在庫テーブルにリンクするか、製造元コード キーを使用して在庫テーブルを製造元テーブルにリンクします。

第 2 正規形

  • 複数のレコードに該当する値のセットごとに 1 つのテーブルを作成します。
  • これらのテーブルを外部キーと関連付けます。
レコードが、テーブルの主キー (必要な場合は、複合キー) 以外に従属しないようにする必要があります。たとえば、財務システムにおける顧客の住所を考えてみます。住所は顧客テーブルで必要ですが、受注、出荷、請求、売掛金、および回収の各テーブルでも必要です。これらすべてのテーブルに顧客の住所を個別のエントリとして格納するのではなく、顧客テーブルまたは個別の住所テーブルのいずれか 1 つに格納します。

第 3 正規形

  • キーに従属しないフィールドを除去します。
レコードに、キーの一部ではない値が含まれる場合、その値を別のテーブルに分離します。一般的に、一連のフィールドの内容が、テーブル内の複数のレコードに適用されるときは、それらのフィールドを別のテーブルに配置することを検討します。

たとえば、社員募集テーブルに、志願者の大学の名前と住所が含まれているとします。しかし、大学に募集要項を送付するには、大学の完全な一覧を必要とします。大学の情報が志願者テーブルに格納されている場合、現在志願者がいない大学の一覧を取得することができません。この場合、別に大学テーブルを作成し、大学コード キーを使用して志願者テーブルにリンクします。

例外 : 第 3 正規形を遵守することが理論上望ましくても、常に実用的とは限りません。顧客テーブルで、起こり得る内部フィールドの従属関係をすべて除去するには、都市、郵便番号、顧客担当者、顧客クラス、および複数のレコードで重複する可能性があるその他すべての要因に対して個別にテーブルを作成する必要があります。理論上、正規化は実践する価値がありますが、小さいテーブルを数多く作成するとパフォーマンスが低下し、開くことのできるファイルおよびメモリの容量を超える場合があります。

第 3 正規形は、頻繁に変更されるデータに対してのみ適用する方がより現実的です。従属フィールドが残っている場合、それらのいずれかが変更されるときに、関連付けられたすべてのフィールドの確認がユーザーによって行われるようにアプリケーションを設計します。

その他の正規形

ボイスコッド正規形 (BCNF) とも呼ばれる第 4 正規形、および第 5 正規形が存在しますが、実用的な設計と見なされることはほとんどありません。これらの規則を無視すると、完全なデータベース設計とはならないことがありますが、機能的には影響しません。

サンプル テーブルを正規化する

以下の手順は、架空の学生テーブルを正規化するプロセスの例です。
  1. 正規化されていないテーブル
    元に戻す全体を表示する
    Student# Advisor Adv-Room Class1 Class2 Class3
    1022 Jones 412 101-07 143-01 159-02
    4123 Smith 216 201-01 211-02 214-01
  2. 第 1 正規形 : 繰り返しグループの除去

    テーブルは、2 次元にする必要があります。1 人の学生が複数のクラスを受講するため、これらのクラスは別のテーブルにまとめる必要があります。上記のレコードで Class1、Class2、および Class3 のフィールドに設計上の問題点があります。

    スプレッドシートでは、3 次元を頻繁に使用しますが、テーブルでは使用するべきではありません。この問題は "一対多の関係" から検討することもできます。"一対多" の "一" の側と "多" の側の両方を同じテーブルに配置しないようにします。次のように、繰り返しグループ (Class#) を除去し、別のテーブルを作成して第 1 正規形にします。
    元に戻す全体を表示する
    Student# Advisor Adv-Room Class#
    1022 Jones 412 101-07
    1022 Jones 412 143-01
    1022 Jones 412 159-02
    4123 Smith 216 201-01
    4123 Smith 216 211-02
    4123 Smith 216 214-01
  3. 第 2 正規形 : 冗長データの除去

    上記の表では、各 Student# 値に複数の Class# 値があることに注目します。Class# は機能的上、Student# (主キー) に従属していません。そのため、このリレーションシップは、第 2 正規形ではありません。

    第 2 正規形にまとめると、以下の 2 つのテーブルのようになります。

    学生テーブル

    元に戻す全体を表示する
    Student# Advisor Adv-Room
    1022 Jones 412
    4123 Smith 216

    受講登録テーブル

    元に戻す全体を表示する
    Student# Class#
    1022 101-07
    1022 143-01
    1022 159-02
    4123 201-01
    4123 211-02
    4123 214-01
  4. 第 3 正規形 : キーに従属しないデータの除去

    上記の例で、Adv-Room (教授の部屋番号) は機能上 Advisor (教授) 属性に従属しています。この場合の解決法は、以下のように、その属性を学生テーブルから教授テーブルに移動することです。

    学生テーブル

    元に戻す全体を表示する
    Student# Advisor
    1022 Jones
    4123 Smith

    教授テーブル

    元に戻す全体を表示する
    Name Room Dept
    Jones 412 42
    Smith 216 42

関連情報

『FoxPro 2: A Developer's Guide: Expert Guidance for Industrial-Strength Programming』Hamilton M. Ahlo、Randy Brown、Peter Colclough、220 〜 225 ページ、M & T Books、1991 年 10 月

『Using Access 1.1 for Windows』Roger Jennings、799 〜 800 ページ、Que Corporation、1993 年 7 月

関連情報

この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 209534 (最終更新日 2004-08-06) を基に作成したものです。

プロパティ

文書番号: 209534 - 最終更新日: 2005年6月10日 - リビジョン: 2.2
この資料は以下の製品について記述したものです。
  • Microsoft Access 2000 Standard Edition
キーワード:?
kbdatabase kbdesign kbinfo kbusage KB209534
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com