データベース設計の基本

データベース設計の基本

重要:  この記事は機械翻訳されています。機械翻訳についての「免責事項」をお読みください。この記事の英語版を参照するには、ここをクリックしてください。

適切に設計されたデータベースは、最新の正確な情報へのアクセスを提供します。適切な設計はデータベースでの作業の目標を達成するために不可欠であるため、時間をかけて優れた設計の原則について学習することは理にかなっています。最終的には、ニーズを満たし、変化にも容易に対応できるデータベースを構築できる可能性が高くなります。

この記事では、デスクトップ データベースを計画するためのガイドラインを提供します。必要な情報を決定する方法、その情報を適切なテーブルや列に分割する方法、テーブルを相互に関連付ける方法について学習します。この記事は、デスクトップ データベースを初めて作成する前にお読みください。

重要: Access では、Web 用のデータベース アプリケーションを作成することが可能な設計になっています。Web 用に設計する場合、さまざまなことを考慮する必要があります。この記事では、Web データベース アプリケーションの設計については説明しません。詳細については、「Web で共有するデータベースを作成する」の記事を参照してください。

この記事の内容

知っておく必要のあるいくつかのデータベース用語

適切なデータベース設計とは

デザインの手順

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

必要な情報を検索して整理する

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

情報の項目を列に変える

主キーを指定する

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

デザインを調整する

正規化ルールを適用する


知っておく必要のあるいくつかのデータベース用語

Access では、テーブルで情報を整理します。テーブルとは、帳簿やスプレッドシートのような、行との列からなるリストです。単純なデータベースでは、テーブルは 1 つのみの場合があります。多くのデータベースでは、2 つ以上あります。たとえば、製品情報を格納するテーブル、受注情報を格納する別のテーブル、顧客情報を格納するまた別のテーブルです。

データシート内の 3 つのテーブルを表している画像

各行は正しくはレコードと呼ばれ、各列は正しくはフィールドと呼ばれます。レコードとは、何かに関する情報を、わかりやすく一貫性のある方法でまとめたものです。フィールドとは、すべてのレコードが持つ、アイテムの種類 (1 項目の情報) です。たとえば、製品テーブルでは、各行または各レコードに 1 製品に関する情報があります。各列または各フィールドは、製品名や製品価格など製品に関する情報の一部を保持します。

ページの先頭へ

適切なデータベース設計とは

データベースの設計手順には、いくつかの原則があります。まず、情報の重複 (冗長データとも呼ばれる) は、スペースを無駄にし、エラーや不整合を発生させる可能性を高くするので、好ましくありません。2 番目に、情報の正確さと完全性が重要です。データベースに不正な情報があると、そのデータベースから情報を取得するすべてのレポートの情報も不正になります。その結果、それらのレポートを使用して行われるすべての決定は、不正になります。

したがって、適切なデータベース設計は次のようになります。

  • データの冗長性を少なくするために、情報が主題ごとのテーブルに分割されている。

  • 必要に応じてテーブル内の必要な情報を結合できるように Access に情報を提供できる。

  • 情報が正確で整合性が取れていることが保証されている。

  • データ処理とレポート作成のニーズに対応している。

ページの先頭へ

設計プロセス

設計プロセスは、次の手順で構成されています。

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

    これにより、残りの手順を準備することができます。

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

    製品名や注文番号など、データベースに記録する必要があるすべての種類の情報を収集します。

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

    情報の項目を主なエンティティや主題 (製品、注文など) に分割します。各主題がテーブルになります。

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

    各テーブルに格納する情報を決定します。各項目がフィールドになり、テーブルの列として表示されます。たとえば、従業員テーブルには、姓や雇用日などのフィールドが含まれます。

  • 主キーを指定する    

    各テーブルの主キーを選択します。主キーとは、各行を一意に識別するために使用される列です。例として、製品 ID や受注 ID があります。

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

    各テーブルを確認し、1 つのテーブルのデータと他のテーブルのデータとの関係を決定します。リレーションシップを明確にするため、必要に応じてテーブルにフィールドを追加したり、新しいテーブルを作成します。

  • 設計を調整する    

    設計にエラーがないか分析します。テーブルを作成し、サンプルのレコードをいくつか追加します。テーブルから必要な結果を得られるか確認します。必要に応じて設計を調整します。

  • 正規化ルールを適用する    

    データの正規化ルールを適用して、テーブルの構造が正しいか確認します。必要に応じてテーブルを調整します。

ページの先頭へ

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

データベースの目的、用途、その使用者などのデータベースの目的を用紙に書き出すとよいでしょう。たとえば、在宅ビジネス用の小さいデータベースが必要な場合は、"メーリング リストやレポートを生成するために、顧客データベースに顧客情報のリストを保持する" というような簡単な目的を書き出します。企業の設定でよくあるように、データベースがより複雑であったり、多数のユーザーが使用する場合、目的が 1 段落にも及ぶことが多く、各ユーザーがそのデータベースをいつ、どのように使用するかを含める必要があります。設計手順全体を通して参照できる、完成度の高いミッション ステートメントを作ることが目的です。そのようなステートメントがあると、意思決定のときに目的に焦点を絞ることができます。

ページの先頭へ

必要な情報を検索して整理する

必要な情報を検索して整理するには、既にある情報で始めます。たとえば、現時点ではおそらく、発注書を台帳に記録していたり、顧客情報をファイル キャビネット内に紙の用紙に記録したりしているでしょう。それらのドキュメントをまとめ、記載されている情報 (たとえば、フォームのボックスに入力する各情報) を種類ごとに列挙します。フォームがない場合は、顧客情報を記録するフォームを設計することを想定してください。フォームにはどのような情報を入れますか?どのような入力用のボックスを作成しますか?これらの各項目を判断し、列挙します。たとえば、現在顧客リストがインデックス カードで維持されているとします。これらのカードには、それぞれ顧客名、住所、市区町村、都道府県、郵便番号、電話番号があるとします。これらは、それぞれテーブルの列として使用できます。

リストを準備する場合、最初から完璧を目指す必要はありません。代わりに、頭に浮かんだものを順次列挙していきます。そのデータベースを使用するユーザーが他にもいる場合、そのユーザーにアイデアを求めます。リストは後で調整できます。

次に、データベースから作成するリストやメールの種類を考えます。たとえば、地域ごとの売り上げを示す売上高のレポート、製品の在庫レベルを示す在庫のサマリー レポートが必要であるとします。セールのイベントや景品の提供などを顧客に告知する定型書簡を生成したい場合もあります。レポートを頭の中でデザインしてみて、その外観を想像します。レポートにはどのような情報を入れますか?各項目を挙げます。これを定型書簡や作成する予定がある他のレポートでも実行します。

製品在庫レポートを想像している人

必要なレポートやメールを念頭に入れると、データベースに入れる必要のある項目を識別する助けとなります。たとえば、顧客がオプトイン (またはオプトアウト) することができる、定期的に送信されるメールによる更新情報があり、そのオプトインしている登録者のリストを印刷するとします。その情報を記録するには、顧客テーブルに “電子メールの送信” 列を追加します。顧客ごとに、このフィールドに、”はい” や ”いいえ” を設定します。

顧客にメールを送信する必要がある場合、もう 1 つ記録する項目があります。顧客が電子メール メッセージを受信することを希望している場合、その送信先の電子メール アドレスも必要になります。したがって、顧客ごとに電子メール アドレスを記録しなければなりません。

各レポートのひな形や出力リストを作り、そのレポートの生成に必要な項目を検討することをお勧めします。たとえば、定型書簡を考えている場合、いくつかのことが頭に浮かびます。たとえば、"Mr."、"Mrs." や "Ms." などのきちんとした敬称をあいさつ文の冒頭に入れたい場合、敬称項目を作成する必要があります。また、一般的に手紙は、“Dear Mr. Sylvester Smith” ではなく “Dear Mr. Smith” で開始したいでしょう。これは、名とは別に姓を通常保存する必要があることを意味します。

各情報は、有用な最小単位に分割することが重要であることを覚えておいてください。名前に関してであれば、すぐに使用できるように、名と姓の 2 つの部分に分割します。たとえば、姓でレポートを並べ替える場合、顧客の姓が別に保存されていると便利です。通常、情報を項目 (顧客の名など) で並べ替え、検索、計算、またはレポート作成する場合、その項目を別のフィールドに保存する必要があります。

データベースに求める質問を考えてみてください。たとえば、お買い得商品の契約は先月何件締結しましたか?お得意様の住所はどこですか?最もよく売れている商品は、どこから供給されていますか?これらの質問を予測することにより、記録するその他の項目を正確に決定できます。

これらの情報を収集したら、次の手順に移ります。

ページの先頭へ

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

情報をテーブルに分割する場合、主要なエンティティまたは主題を選択します。たとえば、製品の販売データベース用の情報を判別して整理すると、準備段階のリストは次のようになります。

種類別にグループ化された手書きの情報項目

これの主要なエンティティは、製品、仕入先、顧客、および注文です。したがって、製品、仕入先、顧客、受注の事実情報の 4 つのテーブルで開始するのが理にかなっています。このリストですべてではありませんが、開始地点としては適切です。設計が正しく機能するまで、このリストを調整し続けてください。

暫定的なリスト項目を最初に見直すとき、前の図の 4 つのテーブルではなく、すべてを 1 つのテーブルに配置してしまいたくなる場合もあります。これがなぜよくないのかこれからここで説明します。次のテーブルを少し考えてください。

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

ここでは、各行に、製品とその仕入先の両方に関する情報が含まれています。同じ仕入先から仕入れられた製品が複数ある場合、仕入先名と住所の情報を何度も繰り返す必要があります。これはディスク領域の無駄遣いです。代わりに、仕入先の情報を個別の仕入先テーブルに 1 回だけ記録し、そのテーブルを製品テーブルに関連付けるのがより適切な方法です。

この設計の 2 番目の問題は、仕入先に関する情報を修正する必要が生じた場合に発生します。仕入先の住所を変更する必要があるとしましょう。仕入先の住所は複数の場所に表示されているので、ある場所では住所を変更したのに、別の場所では無意識に変更を忘れてしまうことも考えられます。仕入先の住所を 1 か所だけに記録すれば、この問題は解決されます。

データベースを設計する際、それぞれの事実は常に 1 度のみ記録します。特定の仕入れ先の住所など、同じ情報を複数回繰り返し出現している場合、その情報は別のテーブルに配置します。

最後に、Coho Winery から仕入れている製品が 1 つしかなく、その製品を削除したいが、仕入先の名前と住所の情報は残しておきたいとしましょう。仕入先情報を消失せずに製品レコードを削除するにはどうすればよいでしょうか。それはできません。各レコードには、仕入先に関する事実に加えて製品に関する事実情報が含まれているので、一方を削除しないで他方を削除することは不可能です。これらの事実情報を分けて保存するには、このテーブルを 2 つのテーブル (1 つ目は製品情報、2 つ目は仕入先情報) に分割します。このようにすると、製品レコードを削除した場合、製品に関する事実情報だけが削除され、仕入先に関する事実情報は削除されません。

テーブルの主題を選択したら、そのテーブルの列にはその主題の事実情報のみが含まれるようにする必要があります。たとえば、製品テーブルには、製品の事実情報のみを格納します。仕入先の住所は仕入先の事実情報であり、製品に関する事実情報ではないため、それは仕入先テーブルに属します。

ページの先頭へ

情報の項目を列に変える

テーブルの列を決める場合、テーブルに記録する主題でどのような情報を追跡する必要があるかを決定します。たとえば、顧客テーブルの列を作るときは、名前、住所、市区町村/都道府県/郵便番号、電子メールの送信、敬称、電子メール アドレスから始めるのがよいでしょう。テーブルの各レコードには同じ列のセットがあるので、レコードごとに名前、住所、市区町村/都道府県/郵便番号、電子メールの送信、敬称および電子メール アドレス情報を格納できます。たとえば、住所列には顧客の住所があります。各レコードには 1 人の顧客のデータが含まれており、住所フィールドにはその顧客の住所が含まれています。

各テーブルに入れる最初の列のセットを決めてから、後で列をさらに調整できます。たとえば、顧客名を姓と名の 2 つの別の列で格納すれば、それらの列のみで並べ替え、検索、インデックス付けを行えます。同様に、住所は実際には、住所、市区町村、都道府県、郵便番号、国/地域の 5 つの別のコンポーネントで構成されるので、これらも別の列に格納するのが理にかなっています。たとえば、都道府県で検索、フィルター処理または並べ替え操作を実行する場合は、都道府県情報を別の列に格納します。

また、データベースには国内情報のみを入れるか、同様に海外の情報も入れるか考える必要があります。たとえば、海外の住所を格納する場合、都道府県ではなく地域列の方が、国内の都道府県と他国の地域を入れることが可能なのでより適しています。同様に、海外の住所を格納する場合、Zip コード (米国の郵便番号) を格納するより、郵便番号の方が理にかなっています。

次に、列を決定する場合のヒントをいくつか示します。

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

    ほとんどの場合、計算結果をテーブルに含めません。代わりに、結果を表示するときに Access に計算を実行させます。たとえば、データベース内の製品の分類項目ごとの注文総数の小計を示すレポートがあるとします。しかし、どのテーブルにも注文総数の小計列がないとします。その代わり、製品テーブルには各製品の注文総数を格納する注文総数列があります。Access はこのデータを使用して、レポートを出力するたびに小計を計算します。小計自体はテーブルに格納しないようにします。

  • 情報は最小限の論理単位で格納する    

    姓名を 1 つのフィールドに入れたり、製品名と製品の説明を同じフィールドに入れたくなる場合があります。フィールドに複数の情報を入れると、個々の事実を後で取得するのが困難になります。情報は論理的な部分に分割するようにしてください。たとえば、姓と名または、製品名、分類項目または製品でフィールドは分割します。

デザイン プロセス中の情報項目を表す画像

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

ページの先頭へ

主キーを指定する

各テーブルには、テーブルに格納されている各行を一意に識別する列 (または一連の列) を含める必要があります。これは、通常、従業員の ID 番号やシリアル番号などの一意の番号です。データベース用語では、この情報をテーブルの主キーと呼びます。Access では、主キー フィールドを使用して、複数のテーブルのデータをすばやく関連付けて、データを提供します。

カタログの各製品を一意に識別する製品番号などの一意の識別子が既にテーブルにあり、この列の値がレコードごとに必ず異なる場合、その識別子をテーブルの主キーとして使用できます。主キーには、同じ値は使用できません。たとえば、名前は一意ではないので、人名は主キーにしません。同じテーブルに同名の人が 2 人いることはよくあります。

主キーには必ず値が必要です。列値がある時点で割り当て解除される場合があったり、それが不明な (値がない) 場合、主キーのコンポーネントとして使用することはできません。

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

主キーには、多くの場合、任意の一意の数値が使用されます。たとえば、各注文には一意の注文番号が割り当てられます。注文番号の唯一の目的は、注文を識別することです。一度割り当てると、それが変わることはありません。

適切な主キーとなる列または列の組み合わせが思い浮かばない場合、オートナンバー データ型の列の使用を検討してください。オートナンバー データ型を使用すると、Access が自動的に値を割り当てます。このような識別子には、それが表す行を説明する事実情報は含まれません。事実情報を含まない識別子は、それが変わることがないため、主キーとして使用するのに最適です。電話番号や顧客名など、行の事実情報を含む主キーは、事実情報自体が変わる可能性があるため、変わる可能性が高くなります。

[商品] テーブルと主キー フィールドを示す画像

1.オートナンバー データ型に設定された列は、多くの場合、主キーに適しています。製品 ID が 2 つ同一であることはありません。

2 つ以上のフィールドを組み合わせて使用して、テーブルの主キーにすることもできます。たとえば、注文の明細を格納する受注明細テーブルの主キーとして、2 つの列 (受注 ID と製品 ID) を使用するとします。主キーに複数の列が使用される場合、これは複合キーと呼びます。

製品の販売データベースでは、次の各テーブルにオートナンバー列を作成して主キーにできます。製品テーブルの製品 ID、受注テーブルの受注 ID、顧客テーブルの顧客 ID、仕入先テーブルの仕入先 ID。

デザイン プロセス中の情報項目を表す画像


ページの先頭へ

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

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

注文書の画像

1. このフォームは、[得意先] テーブルと、

2. ...従業員テーブル...

3. ...受注テーブル...

4. ...製品テーブル...

5.… 受注明細テーブルからのものです。

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

ページの先頭へ

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

製品注文データベースの仕入先テーブルと製品テーブルの例を考えてみてください。仕入先が供給できる製品数に制限はありません。つまり、仕入先テーブルのすべての仕入先は、製品テーブルに多数の製品がある場合があります。したがって、仕入先テーブルと製品テーブル間のリレーションシップは、一対他リレーションシップになります。

一対多の概念

データベースの設計で一対多リレーションシップを表すには、リレーションシップの「一」側の主キーを、リレーションシップの「多」側のテーブルの 1 つ以上の列に追加します。この場合、たとえば、仕入先テーブルから仕入先 ID 列を製品テーブルに追加します。すると、Access は製品テーブルの仕入先 ID 番号を使用して、各製品の仕入先を正しく検索できます。

製品テーブルの仕入先 ID 列は外部キーと呼ばれます。外部キーとは、別のテーブルの主キーです。製品テーブルの仕入先 ID 列は、仕入先テーブルの主キーでもあるので、外部キーです。

デザイン プロセス中の情報項目を表す画像

主キーと外部キーを組み合わせることによって、関連するテーブルを結合する基準を用意します。どのテーブルで共通の列を共有すればよいかわからない場合、一対多リレーションシップを識別すると、2 つの関係するテーブルに実際に 1 つの共有列が必要であることがわかります。

ページの先頭へ

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

製品テーブルと受注テーブル間のリレーションシップを考えてください。

1 つの注文には、複数の製品を含めることができます。一方で、1 つの製品は、複数の注文に出現します。したがって、受注テーブルの各レコードには、製品テーブルに多数のレコードがある場合があります。そして製品テーブルの各レコードには、受注テーブルにレコードが多数ある場合があります。この種のリレーションシップは、すべての製品には注文が多数ある可能性があり、すべての注文には製品が多数ある可能性があるため、多対多リレーションシップと呼ばれています。テーブル間の多対多リレーションシップを見つけるには、リレーションシップの両側を考慮することが重要です。

受注テーブルと製品テーブルの 2 つのテーブルの主題には、多対多リレーションシップがあります。これでは問題が発生します。製品 ID フィールドを受注テーブルに追加して 2 つのテーブル間にリレーションシップを作成した場合、何か起こるかを想像すると、この問題は理解しやすくなります。1 つの注文に複数の製品を含めるには、各注文の受注テーブルにレコードが複数必要です。1 つの注文と関係する各行に、受注情報を繰り返し出現する設計は非効率的で、データが不正になる可能性があります。製品テーブルに受注 ID フィールドを入れた場合も同じ問題が発生します。各製品の製品テーブルには、レコードが複数あることになります。では、これはどのように解決するのでしょうか?

答えは、多対多リレーションシップを 2 つの一対多リレーションシップに分割して、しばしば交差テーブルと呼ばれる 3 番目のテーブルを作成します。2 つのそれぞれのテーブルの主キーを 3 番目のテーブルに挿入します。この結果、リレーションシップが発生するたびに、それが 3 番目のテーブルに記録されます。

多対多関係の概念

受注明細テーブルの各レコードは、注文の明細を表します。受注明細テーブルの主キーは、受注テーブルと製品テーブルの外部キーの 2 つのフィールドで構成されます。1 つの注文には明細が多数ある場合があるので、このテーブルの主キーとして受注 ID フィールドのみの使用は機能しません。注文の各明細に受注 ID が繰り返し出現するので、フィールドには一意の値が含まれません。製品 ID フィールドのみを使用しても、1 つの製品が多数の異なる注文にも出現する可能性があるため、同様に機能しません。しかし、2 つのフィールドが両方あれば、常にレコードごとに一意の値を生成できます。

製品の売上データベースでは、受注テーブルと製品テーブルは直接は関係しません。代わりに、受注明細テーブルで非間接的に関係します。注文と製品間の多対多リレーションシップは、データベースで 2 つの一対多リレーションシップを使用して示されています。

  • 受注テーブルと受注明細テーブルには一対多リレーションシップがあります。各注文には明細が複数ある場合がありますが、各明細は 1 つの注文のみとつながっています。

  • 製品テーブルと受注明細テーブルの間には、一対多リレーションシップがあります。各製品には多数の明細を関連付けることができますが、各明細は 1 つの製品のみを参照しています。

受注明細テーブルでは、特定の注文のすべての製品がわかります。また特定の製品のすべての注文もわかります。

受注明細テーブルを組み込むと、テーブルとフィールドのリストは次のようになります。

デザイン プロセス中の情報項目を表す画像


ページの先頭へ

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

もう 1 つのリレーションシップは、一対一リレーションシップです。たとえば、まれにしか使用しなかったり、少数の製品にしか該当しない、特殊な補足的な製品情報をいくつか記録する必要があるとします。この情報はあまり頻繁には使用せず、この情報を製品テーブルに格納すると、該当しないすべての製品で空白が生じてしまうため、これは別のテーブルに配置します。製品テーブルのように、製品 ID を主キーとして使用します。この補足テーブルと製品テーブル間のリレーションシップは、一対一リレーションシップになります。製品テーブルの各レコードには、補足テーブルに一致するレコードが 1 つあります。このようなリレーションシップがある場合、両テーブルに共通のフィールドが必要です。

データベースに一対一リレーションシップが必要な場合、2 つのテーブルの情報を 1 つのテーブルに結合できるか考えてください。空きスペースがたくさんできてしまうなど、何らかの理由によりそれを行いたくない場合は、次のように、設計でこのリレーションシップを表現できます。

  • 2 つのテーブルに同じ主題がある場合、同じ主キーを両テーブルで使用してリレーションシップを作成することもできます。

  • 2 つのテーブルに異なる主キーで異なる主題がある場合、いずれかの (片方の) テーブルを選択し、その主キーを外部キーとしてもう 1 つのテーブルに挿入します。

テーブル間のリレーションシップを決定すると、テーブルや列が正しいことを確認できます。一対一または一対多リレーションシップがある場合、それらのテーブルで共通の列を 1 つ以上、共有する必要があります。多対多リレーションシップがある場合、リレーションシップを表現する 3 番目のテーブルが必要です。

ページの先頭へ

デザインを調整する

必要なテーブル、フィールド、リレーションシップが用意できたら、テーブルを作成してサンプル データを設定し、クエリの作成、新規レコードの追加などを行って情報を操作してみます。これを行うと、問題がある場合にそれに焦点を当てることができます。たとえば、設計段階で入れ忘れた列を追加したり、重複を避けるためにテーブルを 2 つに分割する必要がある場合があります。

データベースを使用して、必要な回答を得られるかご確認ください。フォームとレポートの下書きを大まかに作成し、期待しているデータが表示されるか確認します。不要なデータの重複を探し、それを見つけたら、設計を変更してそれを削除します。

最初のデータベースを試すと、おそらく改善点が見つかるでしょう。次に確認すべき、いくつかの事柄を示します。

  • 列の作り忘れはありませんか?ある場合、情報は既存のテーブルのものですか?他の情報である場合、別にテーブルを作成する必要があります。追跡する必要のあるすべての情報項目ごとに列を作成します。情報が他の列から計算できない場合、新しい列が必要な場合があります。

  • 既存のフィールドから計算できるため、不要な列はありませんか?小売価格から値引き価格を計算するなど、別の既存の列から情報項目を計算できる場合、通常は、新しい列を作成するのではなく、それのみを実行するのが適切です。

  • テーブルの 1 つに重複する情報を繰り返し入力していませんか?その場合は、テーブルを一対多リレーションシップを持つ 2 つのテーブルに分割する必要がある場合があります。

  • テーブルにフィールドが多数あったり、レコード数が限られていたり、個々のレコードに多数の空きフィールドはありませんか?その場合、フィールド数を少なく、レコードを多く入れられるようテーブルの再設計を検討してください。

  • 各情報項目は、最小の有用な部分に分割されていますか?情報項目をレポートしたり、並べ替えたり、検索したり、計算する必要がある場合、それらの項目は独立した列に入れます。

  • 各列には、テーブルの主題の事実情報が含まれていますか?列にテーブルの主題に関する情報が含まれていない場合、それは別のテーブルに属します。

  • 複数のテーブル間のすべてのリレーションシップは、共通のフィールドや 3 番目のテーブルのいずれかで示されていますか?一対一と一対多のリレーションシップでは、共通の列が必要です。多対多リレーションシップでは 3 番目のテーブルが必要です。

製品テーブルを調整する

製品の販売データベースの各製品が、飲料、調味料や魚介などの一般的な分類項目に分類できるとします。製品テーブルには、各製品の分類項目を示すフィールドを含めることができます。

データベースの設計を確認および調整後、分類項目名と共にその説明を格納しようと決めたとします。製品テーブルに分類項目の説明フィールドを追加すると、その分類項目の各製品に分類項目の説明を繰り返し入力しなければならず、これはよい解決策ではありません。

独自のテーブルと独自の主キーを使用して、データベースが追跡する新しい主題に分類項目をするのがよりよい解決策です。それから分類項目テーブルの主キーを、製品テーブルに外部キーとして追加します。

分類項目テーブルと製品テーブルには一対多リレーションシップがあり、分類項目には 1 つ以上の製品を含めることができますが、製品は 1 つの分類項目にしか属せません。

テーブルの構造を確認するとき、繰り返しグループがないかご注意ください。たとえば、次の列があるテーブルがあるとします。

  • プロダクト ID

  • 名前

  • プロダクト ID 1

  • 名前 1

  • プロダクト ID 2

  • 名前 2

  • プロダクト ID 3

  • 名前 3

ここでは、各製品は、列名の末尾に数値が追加されている点だけが異なる、列の繰り返しグループです。このように番号付けされた列がある場合、設計を見直す必要があります。

そのような設計には、欠点がいくつかあります。まず、製品数に上限が強制されます。その上限を超過すると、テーブル構造に列の新しいグループを追加しなければならなくなり、これは大掛かりな管理作業です。

もう 1 つの問題として、製品の最大数よりも少数の製品しかない仕入先は、余分な空白列ができるため、空間が無駄になります。このような設計の最も深刻な欠陥は、製品 ID や名前を使用してテーブルを並べ替えたり、インデックスを付けるなどの多くの作業が実行困難になるという点です。

繰り返しグループがある場合、テーブルを 2 つに分割できるか、設計を目でよく確認します。前述の例では、仕入先テーブルと製品テーブルの 2 つのテーブルを仕入先 ID でリンクして使用するのが適切です。

ページの先頭へ

正規化ルールを適用する

設計の次の手順では、(正規化ルールと呼ばれることもある) データの正規化ルールを適用します。これらのルールを使用すると、テーブルの構造が正しいか確認することができます。データベースの設計にこのルールを適用する手順は、データベースの正規化または単に正規化と呼ばれています。

正規化は、すべての情報項目を表現し、仮の設計に到達した後に便利です。これで、情報項目を正しいテーブルに分割したかを確認することができます。正規化でできないことは、まず正しいデータ項目がすべてあることを確認することです。

ルールは連続して適用し、各手順で設計が "正規形" と呼ばれる形式になることを確認します。正規形には、第 1 正規形から第 5 正規形までの広く受け入れられている 5 つのものがあります。この記事では、多くのデータベース設計ではここまで行えば十分である最初の 3 つについて説明します。

第 1 正規形

第 1 正規形では、テーブルの行と列が交差する場所には、一連の値ではなく、1 つの値のみがある必要があります。たとえば、複数の価格が入れられる価格というフィールドは作成できません。行と列の各交差をセルと考えると、各セルには値は 1 つしか入れられません。

第 2 正規形

第 2 正規形では、キーではない各列は、主キーの一部ではなく、すべての主キーに依存している必要があります。このルールは、主キーが複数の列で構成される場合に適用されます。たとえば、受注 ID と製品 ID で主キーを構成する次の列を含むテーブルがあるとします。

  • 受注 ID (主キー)

  • プロダクト ID (主キー)

  • 製品名

この設計は、製品名が受注 ID には依存せず製品 ID に依存し、主キー全体には依存しないため、第 2 正規形に違反します。テーブルから製品名を削除する必要があります。これは別のテーブル (製品) に属します。

第 3 正規形

第 3 正規形では、キーではないすべての列がすべての主キーに依存するのみでなく、キーでない列が相互に依存している必要があります。

これは言い換えると、キー以外の列は、主キーのみに依存している必要があるということです。たとえば、次の列があるテーブルがあるとします。

  • プロダクト ID (主キー)

  • 名前

  • SRP

  • 割引

割引率が、提示小売価格 (SRP) に依存しているとします。このテーブルは、キーではない列の割引率が別のキー列ではない列に依存するため、第 3 正規形に違反します。列の独立とは、キー列ではない列を変更する場合に、他の列には影響を与えずに行えることを意味します。SRP フィールドの値を変更すると、割引率もそれに応じて変わり、ルール違反となります。この場合、割引率は SRP にキー付けされた別のテーブルに移す必要があります。

ページの先頭へ

注: 機械翻訳についての免責事項: この記事の翻訳はコンピューター システムによって行われており、人間の手は加えられていません。マイクロソフトでは、英語を話さないユーザーがマイクロソフトの製品、サービス、テクノロジに関するコンテンツを理解するのに役立てるため、こうした機械翻訳を提供しています。記事は機械翻訳されているため、用語、構文、文法などに誤りがある場合があります。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×