データベース設計の基本

データベースを正しくデザインすることによって、最新の正しい情報にアクセスすることができます。データベースを使用する目的を達成するには、正しいデザインは必要不可欠なものですから、優れたデザインの原則について学ぶことに時間を費やすことは理にかなっています。最終的に、要求を満たし、変更に対しても柔軟に適応するデータベースを手に入れることになります。

ここでは、データベースの計画に対するガイドラインについて説明します。どんな情報が必要なのか、情報を適切なテーブルや列に分割するにはどのようにするとよいのか、そして、テーブルどうしはどのように関連付けるのかを学んでいきます。最初のデータベースを作成する前に、この記事を読むことをお勧めします。

この記事の内容


知っておいた方がよいデータベース用語

Microsoft Office Access 2007 では、情報をテーブルに整理します。テーブルとは、会計帳簿や Microsoft Office Excel 2007 のワークシートのような行と列によって構成されている表です。簡単なデータベースでは、テーブルが 1 つだけある場合もありますが、ほとんどの場合複数のテーブルが必要となります。たとえば、あるテーブルには商品の情報が保存されており、もう 1 つのテーブルには受注の情報が、さらに顧客の情報が保存されているテーブルがあるという具合です。

データシートの 3 つのテーブルを表す画像

それぞれの行は "レコード" と呼ばれ、列は、"フィールド" と呼ばれます。レコードとは、わかりやすく、一貫性のある方法でなんらかの情報を組み合わせる方法です。フィールドは、その中の 1 つの項目 (レコードごとに現れる 1 つの項目種別) です。たとえば、Products テーブルでは、それぞれの行 (またはレコード) に 1 つの商品に関する情報が保存されているとします。それぞれの列 (またはフィールド) には、商品名や単価などの特定の種類の情報が保存されています。

ページの先頭へ ページの先頭へ

良いデータベース デザインとは

データベースをデザインする手順には、ある法則があります。最初の法則は、重複する情報 (または冗長データとも呼ばれます) は、良くないということです。なぜなら、スペースを無駄遣いし、エラーや矛盾の可能性を膨らませるからです。2 番目の法則として、情報の正確性と完全性が重要といえます。もしデータベース内に正しくない情報が含まれていたとしたら、そのデータベースから情報を引き出して作成されたレポートは、やはり正しくない情報が掲載されていることになります。結果として、そのレポートに基づいてなされた判断は、誤解をまねくことになりかねません。

つまり、良いデータベース デザインとは、次のようになります。

  • 情報を主題ごとのテーブルに分け、冗長データを削減する。
  • 必要に応じて、テーブル内の情報を結合するのに必要な情報を提供する。
  • 情報の正確性と完全性をサポートし、保証する。
  • データ処理やレポート作成に対応する。

ページの先頭へ ページの先頭へ

デザインの手順

デザインは次の手順に従って行います。

  • データベースの目的を決定する    

これは、この先の手順の準備となります。

  • 必要な情報を見つけ、整理する    

商品の名前や受注番号など、データベースに記録する可能性のあるすべての種類の情報を集めます。

  • 情報をテーブルに分割する    

"商品" や "受注" など、情報の項目を主なエンティティや主題に分割します。各主題は次にテーブルになります。

  • 情報の項目を列に変える    

それぞれのテーブルにどの情報を保存するかを決定します。個々の項目はフィールドとなり、テーブルの列として表示されます。たとえば、[社員] テーブルには、"姓" フィールドや "入社日" フィールドなどが含まれるかもしれません。

  • 主キーを指定する    

それぞれのテーブルの主キーを選択します。主キーとは、各行を固有に識別するために使用される列のことです。たとえば、"商品コード" や "受注コード" などです。

  • テーブルのリレーションシップを設定する    

それぞれのテーブルを見て、あるテーブルのデータが他のテーブルのデータとどのような関係にあるかを決定します。必要に応じてテーブルにフィールドを追加したり、新しいテーブルを作成してリレーションシップを明確にします。

  • デザインを調整する    

デザインに間違いがないかを分析します。テーブルを作成し、サンプル データのレコードをいくつか追加してみます。テーブルから正しい結果が得られるかを確認します。必要に応じてデザインを調整します。

  • 正規化の規則を適用する    

テーブルが正しく構成されているかを確認するために、データに正規化の規則を適用します。必要に応じてテーブルを調整します。

ページの先頭へ ページの先頭へ

データベースの目的を決定する

データベースの目的を書き出してみるのは良いアイデアです。データベースの目的や使用方法、だれが使用するかなどを書き出してみましょう。たとえば自営業の小さいデータベースの場合、簡単に "顧客情報を保存して、郵送物やレポートを作成する顧客データベース" などと書くことができるかもしれません。企業で使用する場合など、データベースがより複雑で多くの人が使用する場合、目的はいくつかの段落になるかもしれませんし、それぞれのユーザーがいつどのようにデータベースを使用するかを含める必要があります。

ページの先頭へ ページの先頭へ

必要な情報を見つけ、整理する

必要な情報を見つけて整理するには、まず既存の情報から開始します。たとえば、注文書を台帳に記録していたり、キャビネットの中に紙の用紙に記録された顧客情報があるかもしれません。これらの書類を集めてそれぞれの情報の分類 (たとえば、用紙の記入欄など) をリストにします。既存の用紙がない場合は、顧客情報を記録する用紙をデザインしなければならない場合を想定してみましょう。何の情報をその用紙に記入するか、どのような記入欄を作るかなどを考えてみます。これらの項目を識別してリストにします。たとえば、インデックス カードに顧客の一覧表を保存しているとします。カードには顧客名、都道府県、市区町村、番地、郵便番号、電話番号などが記載されていることを確認します。これらの項目がテーブルの列となる可能性があります。

このリストを作成する際、最初から完璧にする必要はありません。思いついた項目をリストにすればよいのです。他にもデータベースを使用するユーザーがいれば、その人の意見も聞いてみましょう。リストは後から手直しできます。

次に、データベースから作成するレポートや郵便物の種類を考えます。たとえば、地域ごとの売上が表示された売上報告書や商品の在庫状況を記した棚卸集計表などです。また、特売や景品贈呈のお知らせを顧客に送るための定型文書も必要かもしれません。レポートのデザインを考えて、どのようなレイアウトにするかを想像してみます。レポートにはどの情報を表示するか、各項目を書き出してみます。定型文書やその他必要となりそうなレポートについても同様にします。

商品の在庫報告書を想像している人

レポートや郵便物の検討は、データベースで必要な項目を識別するのに役立ちます。たとえば、顧客に定期的に送信される最新情報オプトイン (またはオプトアウト) メールの登録を提供している場合、オプトイン メールの登録者一覧を出力する必要があるかもしれません。その情報を記録するためには、"電子メール送信" 列を顧客テーブルに追加し、それぞれの顧客に対し、そのフィールドで "Yes" または "No" を設定します。

顧客に電子メールを送信するには、そのほかにも記録する項目があります。顧客が電子メール メッセージを受信したい場合、送り先の電子メール アドレスが必要になります。ですから、顧客の電子メール アドレスも記録する必要があります。

それぞれのレポートや出力の一覧に対して、プロトタイプを作ってレポートを作成するのに必要な項目を検討してみることをお勧めします。たとえば、定型文書を検討している場合、いくつかの項目が考え付くでしょう。"拝啓" や "前略"、"謹啓" などの頭語など、正しいあいさつ文を含めたい場合、あいさつ項目を作成する必要があります。また、通常 "青木 俊之 様" ではなく、"青木 様" のように宛名に姓のみ使用する場合は、名前を姓と名に分けて保存する必要があります。

ここで重要なのは、それぞれの情報を使いやすい小さな要素に分けるということです。先の名前の例で言うと、姓を簡単に使用できるように姓と名を分けます。また、名前でレポートを並べ替える場合も、顧客の名前が姓とは分けて保存されていると便利です。一般的に並べ替えや検索、計算、特定の項目を基準としたレポートなどが必要な場合、その項目は個別のフィールドに保存されている必要があります。

データベースが答えてくれる質問を考えてみましょう。たとえば、主な商品の取引で先月成立したものはいくつあるか、得意先の住所はどこか、よく売れる商品の仕入先はどこか、などです。これらの質問を想定することで、レコードに追加する項目に焦点を絞りやすくなります。

これらの情報が集まったら、次の手順へ進みます。

ページの先頭へ ページの先頭へ

情報をテーブルに分割する

情報をテーブルに分割するために、主なエンティティや主題を選択します。たとえば、商品売上データベースの情報を見つけて整理した後の準備リストとしては、次のようになります。

主題ごとにグループ化されている手書きの情報項目

ここでの主なエンティティとしては、商品、仕入先、顧客、受注があります。そこで、商品に関するテーブル、仕入先に関するテーブル、顧客に関するテーブル、受注に関するテーブルの 4 つのテーブルから始めます。これは最終的なリストではありませんが、ここから開始して、うまく稼動するデザインに達するまで調整していけばよいのです。

最初に準備リストの項目を検討したときは、前の図のように 4 つのテーブルに分けるのではなく、すべての情報を 1 つのテーブルに入れようとするかもしれません。ここでは、なぜそれがいけないのかを説明します。次のテーブルをしばらく見てください。

商品と仕入先の両方の情報が含まれたテーブルを表す画像

この場合、各行には商品とその仕入先の両方の情報が含まれています。同じ仕入先から仕入れられた商品がいくつもあるので、同じ仕入先の業者名と住所が何度も繰り返されています。これはディスクの空き領域の無駄遣いです。仕入先の情報は、別の [仕入先] テーブルにそれぞれ 1 回だけ記録し、[商品] テーブルとリンクする方がずっと効率的な方法と言えます。

このデザインの 2 番目の問題点は、仕入先の情報を修正したい場合に起こります。たとえば、仕入先の住所を変更する必要があるとします。仕入先の住所はあちこちに表示されているので、間違えて 1 つの住所は変更したのに、もう片方は変更し忘れたということも考えられます。仕入先の住所が 1 か所にだけ記録されるようにすると、この問題は解決します。

データベースをデザインするときは、いつも各情報が 1 回だけ記録されるようにします。仕入先の住所同様、同じ情報が複数の場所に繰り返されているのを発見した場合は、その情報は別のテーブルに保存するようにします。

最後の問題点としては、たとえば、あじあ株式会社から仕入れられている商品が 1 つしかない場合、その商品を削除したいが、仕入れ業者の名前や住所の情報はとっておきたいとします。どうやって仕入先情報を残して商品のレコードだけを削除しますか。このデザインでは、それはできません。個々のレコードは商品情報と一緒に仕入先情報も保存しているので、片方だけ削除してもう片方を残すことはできないのです。これらの情報を分けて記録するために、商品情報のテーブルと仕入先情報のテーブルの 2 つにテーブルを分ける必要があります。商品レコードを削除したときは、その商品情報のみが削除され、仕入先に関する情報は削除されないようにする必要があります。

テーブルが表す主題を選択したら、そのテーブルの列は主題についてのみの情報を保存します。たとえば、商品のテーブルは商品に関する情報のみを保存する必要があります。仕入先の住所は仕入先に関する情報で、商品に関する情報ではありませんので、仕入先のテーブルに所属します。

ページの先頭へ ページの先頭へ

情報の項目を列に変える

テーブルの列を決定するためには、テーブルに記録される主題についてどの情報を調べる必要があるかを決めます。たとえば、[顧客] テーブルの列の構成リストとしては、名前、住所、郵便番号、電子メール送信、あいさつ文、電子メール アドレスがまず考えられます。テーブル内の各レコードは同じ列の組み合わせとなっているので、名前、住所、郵便番号、電子メール送信、あいさつ文、電子メール アドレスの情報をそれぞれのレコードに保存します。たとえば、住所の列には、顧客の住所が含まれます。それぞれのレコードは、1 人の顧客のデータが保存され、住所フィールドには、その顧客の住所が保存されます。

各テーブルに対して、一度列の組み合わせを決定したら、その列をさらに調整します。たとえば、顧客の名前は姓と名の 2 つの列に分けて保存すると、並べ替えや検索を行ったり、インデックスを付けるのに便利です。同様に、住所は都道府県、市区町村、番地、郵便番号、そして国の 5 つの部分によって成り立っているので、それぞれ別の列に保存するのは、理にかなっています。たとえば、都道府県名で検索や抽出、並べ替えなどを行いたい場合、都道府県の情報が個別の列に保存されている必要があります。

また、データベースが国内の情報だけを保有するのか、または、国際的な情報も扱うのかも考慮する必要があります。たとえば、海外の住所を保存する場合、"都道府県" 列ではなく、"地域" 列とした方が、国内の都道府県と他の国の地域の両方に適応することができるでしょう。同様に "番地" は "住所" としておいたほうが、海外の住所を保存する場合はわかりやすいでしょう。

以下のリストは列を決定するためのヒントです。

  • 計算されたデータは含めない    

通常、計算の結果はテーブルに保存しません。計算結果が必要な場合は、Access で計算を実行します。たとえば、発注済み商品のレポートでデータベース内の商品分類ごとに発注済み件数の小計を表示しているとします。ただし、"発注済件数" の合計列はどのテーブルにも存在しません。代わりに [商品] テーブルには、[発注済件数] 列があり各商品の発注済件数を保存しています。Access ではレポートを出力するたびに小計を計算します。小計そのものは、テーブルに保存しないほうが良いでしょう。

  • 最小の論理単位で情報を保存する    

名前の姓と名を 1 つのフィールドに保存しようとしたり、商品名と商品の説明を同じフィールドに設定したりしようとする場合があるかもしれません。1 つのフィールドに複数の種類の情報を保存すると、後で個々の情報を扱うことが難しくなります。情報は論理単位に分割するようにします。たとえば、名前は姓と名に対して別々のフィールドを作成し、商品名、分類、説明にも個々のフィールドを用意します。

デザイン工程での情報項目一覧

それぞれのテーブルでデータ列を調整したら、テーブルの主キーを選択します。

ページの先頭へ ページの先頭へ

主キーを指定する

各テーブルには、各行を一意に識別する 1 つの列、または複数の列の組み合わせが必要です。これは、社員番号やシリアル番号などの一意な識別番号である場合が多いです。データベース用語としては、この情報をテーブルの "主キー" と呼びます。Access では、主キーのフィールドを使用して複数のテーブルのデータを関連付けて表示します。

カタログで商品を一意に識別する商品コードなどを一意識別子としてテーブルに設定している場合、その識別子をテーブルの主キーとすることができます。ただし、レコードごとにすべて違った値が設定されている列である必要があります。主キーに重複する値を設定することはできません。たとえば、人の名前は固有ではないので、主キーに使用することはできません。1 つのテーブル内に同じ名前の人が 2 人いることはよくあることです。

主キーは必ず値が設定されている必要があります。値が設定されない、または、未知 (存在しない値) である場合がある列は主キーの構成要素として使用できません。

主キーには変更されない値を選択する必要があります。複数のテーブルがあるデータベースでは、主キーは他のテーブルでの参照として使用されている場合があります。主キーが変更された場合は、そのキーを参照しているすべての場所で値を変更する必要があります。変更されない主キーを使用することで、そのキーを参照している他のテーブルと常に同期させることができます。

主キーには任意の固有の番号が使用されることがよくあります。たとえば、すべての受注に固有の受注番号を設定する場合があります。受注番号の目的はそれぞれの受注を識別することです。一度設定したら、変更しません。

主キーに適する列が思いつかない場合は、オートナンバー型の列を使用することも考えられます。オートナンバー型を使用すると、Access が自動的に値を設定します。オートナンバー型の識別子には意味はなく、行を説明する事実情報は含まれていません。情報を含まない識別子は変更されることがないので、主キーとして使用するのは理想的です。電話番号や顧客名など、事実情報を含むものを主キーとした場合、その情報そのものが変更される可能性があるので、主キーも変わる可能性が高いと言えます。


主キー フィールドが設定された [商品] テーブルを表す画像

コールアウト 1 オートナンバー型に設定されている列は、主キーに適しています。商品コードが重複することはありません。

複数のフィールドを組み合わせてテーブルの主キーとして使用したい場合があります。たとえば、注文の一覧を保存している [受注明細] テーブルでは、"受注コード" フィールドと "商品コード" フィールドの 2 つの列を使用したりします。複数の列を使用している主キーは、複合キーとも呼ばれます。

このような商品売上データベースでは、オートナンバー型の列を作成しそれぞれのテーブルの主キーとすることができます。たとえば、[商品] テーブルには "商品コード" フィールド、[受注] テーブルには "受注コード" フィールド、[得意先] テーブルには "得意先コード" フィールド、[仕入先] テーブルには "仕入先コード" フィールドをオートナンバー型で作成し、主キーとすることができます。

デザイン工程で情報の項目を示す

ページの先頭へ ページの先頭へ

テーブルのリレーションシップを作成する

情報をテーブルに分割しましたので、次はそれらの情報が意味をなすように再び結合する方法が必要となります。たとえば、次のフォームではいくつかのテーブルの情報を含んでいます。


[受注] フォーム

コールアウト 1 このフォームは、[得意先] テーブルと、
コールアウト 2 [社員] テーブル、
コールアウト 3 [受注] テーブル、
コールアウト 4 [商品] テーブル、
コールアウト 5 [受注明細] テーブルの情報を表示しています。

Access は、リレーショナル データベース管理システムです。リレーショナル データベースでは、情報を主題によって別々のテーブルに分割します。そして、必要に応じて、テーブルのリレーションシップを使用して情報を結合します。

ページの先頭へ ページの先頭へ

一対多リレーションシップ

次の例を考えてみてください。受注管理データベースには、[仕入先] テーブルと [商品] テーブルがあります。仕入先から仕入れられる商品の個数は限定されていません。つまり、[仕入先] テーブルの 1 つの仕入先が、[商品] テーブルの複数の商品を提供している可能性があります。この場合、[仕入先] テーブルと [商品] テーブルのリレーションシップは、一対多リレーションシップです。

一対多の概念

データベース デザインで一対多リレーションシップを設定するには、一対多リレーションシップの "一" 側の主キーを "多" 側に追加します。前述の例では、[仕入先] テーブルの "仕入先コード" 列を [商品] テーブルに追加します。Access は、[商品] テーブルの仕入先コードを使用して、各商品の正しい仕入先を特定します。

[商品] テーブルの "仕入先コード" 列は外部キーと呼ばれます。外部キーは他方のテーブルの主キーです。[商品] テーブルの "仕入先コード" 列は、[仕入先] テーブルの主キーですので、外部キーです。

デザイン工程での情報項目一覧

主キーと外部キーの組み合わせを作成して、関連するテーブルを結合する基礎を設定しました。もし、どのテーブルが共通する列を持つのかを判断できない場合は、一対多リレーションシップを確認すると、関連する 2 つのテーブルが共有する列を必要とすることがはっきりします。

ページの先頭へ ページの先頭へ

多対多リレーションシップを作成する

[商品] テーブルと [受注] テーブルの関係を考えてみましょう。

1 つの注文には、複数の商品が含まれる可能性があります。また、1 つの商品は、複数の注文に表示される可能性があります。つまり、[受注] テーブルの各レコードは [商品] テーブルの複数のレコードとなり得ます。また、[商品] テーブルの各レコードは、[受注] テーブルの複数のレコードとなり得ます。この種類のリレーションシップは多対多リレーションシップと呼ばれ、どの商品も複数の注文に含まれ、どの注文も複数の商品を含むことができます。テーブルから多対多リレーションシップを見つけ出すには、リレーションの両側を考慮することが重要です。

たとえば、注文や商品のような 2 つのテーブルの主題は、多対多リレーションシップとなっています。これが問題を起こします。この問題を理解するために、"商品コード" フィールドを [受注] テーブルに追加することでこの 2 つのテーブルにリレーションシップを作成すると何が起こるのかを考えてみてください。注文ごとに複数の商品を持つには、[受注] テーブルの各注文に複数のレコードが必要となります。1 つの注文の情報が入力された行が繰り返し必要となります。その結果、効率の悪いデザインとなり、不正確なデータとなる可能性があります。[商品] テーブルに "受注コード" フィールドを追加した場合も同じ問題が起こります。[商品] テーブルの 1 つの商品に対して複数のレコードが必要となってしまうのです。どのようにこの問題を解決すればよいでしょうか。

それには、結合テーブルと呼ばれる第 3 のテーブルを作成して多対多リレーションシップを一対多リレーションシップに分解します。第 3 のテーブルには、2 つのテーブルの主キーをそれぞれ挿入します。その結果、第 3 のテーブルには 2 つのテーブルのリレーションシップを記録します。

多対多リレーションシップ

[受注明細] テーブルの各レコードは、注文の各行項目を表しています。[受注明細] テーブルの主キーは、[受注] テーブルと [商品] テーブルからの外部キーの 2 つのフィールドから成っています。1 件の注文に複数の行項目があるので、"受注コード" フィールドのみを主キーにしたのでは、うまく稼動しません。[受注コード] は同じ注文の各行に対して繰り返され、フィールドは固有の値を保有しません。各商品は複数の注文内に存在するので、[商品コード] フィールドのみでもうまく稼動しません。しかし、その 2 つを組み合わせると、各レコードに対して固有の値となるのです。

この商品売上データベースでは、[受注] テーブルと [商品] テーブルは直接関連していません。代わりに [受注明細] テーブルをとおして間接的に関連しているのです。受注と商品間の多対多リレーションシップは、データベース間で次の 2 つの一対多リレーションシップを使用して表されています。

  • [受注] と [受注明細] テーブルは、一対多リレーションシップです。各注文は複数の行項目を持つことができますが、各行項目は 1 つの注文に結び付けられています。
  • [商品] テーブルと [受注明細] テーブルは一対多リレーションシップです。各商品は複数の行項目に関連していますが、各行項目は 1 つの商品に結び付けられています。

[受注明細] テーブルによって、注文内のすべての商品を確認することができます。また、ある商品のすべての注文を確認することもできます。

[受注明細] テーブルを組み込んだ後は、テーブルとフィールドの一覧は次のようになっています。

デザイン工程での情報項目一覧

ページの先頭へ ページの先頭へ

一対一リレーションシップの作成

もう 1 つのリレーションシップは、一対一リレーションシップです。たとえば、商品に関してまれにしか使用しない補足情報や、ある限られた商品のみ必要な追加情報を記録する必要があるとします。その情報は頻繁には使用しないうえに、[商品] テーブルにその情報を保存すると、該当しない多くの商品のレコードに対して空の領域が作られることになるので、別のテーブルに保存することにします。主キーは、[商品] テーブル同様、"商品コード" を使用します。この追加情報のテーブルと [商品] テーブルの間のリレーションシップが一対一リレーションシップです。[商品] テーブルのレコードに対して該当する追加情報テーブルのレコードは 1 件だけです。このリレーションシップを使用する場合は、両方のテーブルに同じフィールドが存在する必要があります。

一対一リレーションシップの必要性を探るときは、ある情報を 2 つのテーブルから取り出して、1 つのテーブルに置くことができるかどうかを考えます。次の一覧は、空の領域がたくさんできてしまうという理由などでそうしたくない場合、どうリレーションシップを設定するかを示しています。

  • 2 つのテーブルが同じ主題の場合、同じ主キーを両方のテーブルで使用してリレーションシップを正しく設定できます。
  • 2 つのテーブルが違う主題で違う主キーの場合、どちらか一方のテーブルを選択して他方のテーブルの主キーを外部キーとして挿入します。

テーブル間のリレーションシップを決定すると正しいテーブルと列が設定されていることを確認できます。一対一、または、一対多リレーションシップがある場合、テーブルは 1 つ、または、複数の列を共有する必要があります。多対多リレーションシップがある場合、リレーションを設定するために第 3 のテーブルが必要です。

ページの先頭へ ページの先頭へ

デザインを調整する

必要なテーブルやフィールド、リレーションシップが用意できたら、サンプル データを使用してテーブルを作成し、クエリを作成したり、新しいレコードを追加したりして、操作してみます。そうすることによって潜在的な問題点を見つけ出すことができます。たとえば、デザイン工程で抜けていた列を追加したり、重複する情報を取り除くために、2 つのテーブルに分ける必要があるテーブルがあるかもしれません。

データベースを使用してみて、期待どおりの結果が得られるかどうかを確認します。フォームおよびレポートを大まかに作成し、期待どおりにデータが表示されるかどうかを確認してください。不必要なデータの重複が見つかった場合は削除します。問題がある場合はデザインを調整します。

初期段階のデータベースを試してみると、改善の余地があることを発見するでしょう。いくつかの確認する点を次に示します。

  • 足りない列があった場合は、既存のテーブルにその情報を追加することができるかどうかを確認します。その情報が既存のテーブルとは無関係な場合は、テーブルをもう 1 つ作る必要があるかもしれません。必要な情報のすべての列を作成します。他の列から計算して表示することのできない情報は、新しい列を用意する必要があるかもしれません。
  • 既存のフィールドから算出することができる列は不要です。たとえば、小売り価格から計算できる値引額など、その情報項目が既存の列から計算できる場合は、一般的に列を用意せずに計算して値を取得した方がよいと言えます。
  • 同じ情報が繰り返し保存されているテーブルがある場合は、2 つのテーブルに分割し、一対多リレーションシップを設定する必要があるかもしれません。
  • フィールドの数が多いテーブルや、レコード数が限られているテーブル、または、個々のレコードにデータのないフィールドが多いテーブルがある場合は、テーブルをデザインし直して、フィールドの数を減らしたり、レコード数が増えるようにすることも考えられます。
  • 情報項目が小さく使いやすい要素に分けられているかを確認します。レポートや並べ替え、検索、または、計算をその項目に対して行う必要があるとき、該当する列のみで操作することができます。
  • 各列の情報がテーブルの主題に合っているかを確認します。列の情報がテーブルの主題と合っていない場合は、他のテーブルに移動します。
  • テーブル間のすべてのリレーションシップは、共通のフィールド、または、第 3 のテーブルによって設定されているかを確認します。一対一や一対多リレーションシップの場合は、共通の列が必要です。多対多リレーションシップの場合は、第 3 のテーブルが必要となります。

[商品] テーブルを調整する

商品売上データベースの各商品は、飲み物、調味料、魚介類などの一般的な区分に当てはまるとします。その場合、[商品] テーブルには各商品の区分を表示するフィールドを含めることができます。

データベースのデザインを検証し、調整した後で、その区分の説明を区分名と一緒に保存することにしたとします。もし、[商品] テーブルに "区分の説明" フィールドを追加したとしたら、その区分の説明をすべての商品に対して繰り返さなければならなくなるので、よい解決策とは言えません。

データベースに [区分] という新しい主題を作り、そのテーブルと主キーを作成することをお勧めします。その後、[区分] テーブルの主キーを [商品] テーブルに外部キーとして追加します。

[区分] テーブルと [商品] テーブルは一対多リレーションシップとなっています。1 つの区分は複数の商品に設定されますが、商品には 1 つの区分にしか所属することができません。

テーブルの構造を検証する時は、繰り返しグループに注意してください。たとえば、次に示すような列を含むテーブルは注意が必要です。

  • 商品コード
  • 名前
  • 商品コード1
  • 名前1
  • 商品コード2
  • 名前2
  • 商品コード3
  • 名前3

ここでは、各商品は列の繰り返しグループに保存されていて、列名の最後に番号を足しただけで識別されています。このように列に番号が振られているのを見つけたら、デザインに立ち戻ってみるべきです。

このようなデザインには、数々の欠陥があります。たとえば、商品の数に上限があります。上限に達した場合は、テーブルに新しい列のグループを追加しなければならなくなり、それはたいへんな管理業務です。

また、列のグループより少ない商品しかなかった場合は、余分な列は空となり、スペースの無駄遣いとなります。このデザインの最も重大な欠陥としては、並べ替えや、商品コードまたは名前でテーブルにインデックスを付けるなど、多くの作業が困難となることです。

繰り返しグループを発見したら、テーブルを 2 つに分けることを意識してデザインを見直してください。前述の例の場合、仕入先と商品を仕入先コードでリンクした 2 つのテーブルを使用することをお勧めします。

ページの先頭へ ページの先頭へ

正規化の規則を適用する

デザインの次の手順としては、データの正規化の規則 (ただ正規化の規則と呼ばれることもあります) を適用します。この規則は、テーブルが正しく構成されているかを確認するために使用します。データベース デザインに規則を適用する作業は、データベースの正規化、または、ただ正規化と呼ばれます。

すべての情報項目が決まり、基本的なデザインが終了した後で、正規化は最も有用です。正規化は、情報項目が適切なテーブルに分割されているかを確認するために使用します。正しいデータ項目がすべて揃っているかどうかは、正規化では確認できません。

正規化の規則の適用は、各段階で "正規形" として知られている形の 1 つにデータベースがデザインされているかを確認しながら、連続して行います。第 1 正規形から第 5 正規形までの 5 つの正規形が広く認められています。この記事では、多くのデータベース デザインに対して要求される、第 3 正規形までを説明します。

第 1 正規形

第 1 正規形は、テーブル内で各行と列が交差するところで 1 つの値が存在し、値がリスト状になってはいない状態のことです。たとえば、"単価"という名前のフィールドがあるテーブルに、複数の単価を保存することはできません。行と列の交差するところをセルと見なせば、それぞれのセルは 1 つの値しか保存できないでしょう。

第 2 正規形

第 2 正規形は、キー以外の列が主キーすべてに従属していて、キーの一部に従属することが無い状態です。この規則は複数の列から成る主キーがある場合に適用されます。たとえば、テーブルに次の列があるとします。"受注コード" フィールドと "商品コード" フィールドで主キーを形成しています。

  • 受注コード (主キー)
  • 商品コード (主キー)
  • 商品名

これは第 2 正規形に違反しています。"商品名" は、"商品コード" に従属していて、"受注コード" には従属していないので、主キーすべてに従属していると言えないからです。"商品名" フィールドはテーブルから削除する必要があります。"商品名" フィールドは別のテーブル ([商品] テーブル) に属します。

第 3 正規形

第 3 正規形は、キー以外の列が主キーすべてに従属しているだけではなく、キー以外の列が互いに独立している状態です。

他の言い方をすると、主キー以外の列は主キーに従属していて、主キー以外には従属していないということです。たとえば、テーブルに次の列があるとします。

  • 商品コード (主キー)
  • 商品名
  • SRP
  • 割引

割引は希望小売り価格 (SRP) によって決まるとします。このテーブルは第 3 正規形に違反しています。主キー以外の列である "割引" は、もう 1 つのキー以外の列の "SRP" に従属しているからです。列が独立しているということは、主キー以外の列は他の列に影響することなく変更することができるという意味です。"SRP" フィールドの値を変更すると、"割引" フィールドの値も必然的に変わるので規則違反となります。この場合、"割引" フィールドは "SRP" フィールドをキーとした他のテーブルに移動する必要があります。

ページの先頭へ ページの先頭へ

詳細情報

基本的なテーブル デザインの詳細については、「データベースのテーブルを作成する」を参照してください。

データベース デザインの詳細については、以下の書籍を参照してください。

  • Hernandez, Michael J. 著『Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design, Second Edition』Addison-Wesley Professional. 2003 年発行
  • Fleming, Candace C.、von Halle, Barbara 共著『Handbook of Relational Database Design』Addison-Wesley Professional. 1989 年発行
  • Riordan, Rebecca M. 著『Designing Effective Database Systems』Addison-Wesley Professional. 2005 年発行

ページの先頭へ ページの先頭へ

 
 
適用対象:
Access 2007