データベース設計の基本

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

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

この記事の内容

• 知っておく必要のあるいくつかのデータベース用語
• 適切なデータベース設計とは
• デザインの手順
• データベースの目的を決定する
• 必要な情報を検索して整理する
• 情報をテーブルに分割する
• 情報の項目を列に変える
• 主キーを指定する
• テーブル リレーションシップを作成する
• デザインを調整する
• 正規化ルールを適用する

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

Access では、ユーザーの情報が テーブルに整理されます。たとえば、会計士のパッドやスプレッドシートを思わせる行と列のリストです。 単純なデータベースでは、テーブルが 1 つしかない場合があります。 ほとんどのデータベースでは、複数のデータベースが必要になります。 たとえば、製品に関する情報を格納するテーブル、注文に関する情報を格納するテーブル、顧客に関する情報を格納するテーブルなどがあります。

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

ページの先頭へ

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

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

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

• データの冗長性を少なくするために、情報が主題ごとのテーブルに分割されている。
• 必要に応じてテーブル内の必要な情報を結合できるように Access に情報を提供できる。
• 情報が正確で整合性が取れていることが保証されている。
• データ処理とレポート作成のニーズに対応している。

ページの先頭へ

設計プロセス

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

• データベースの目的を決定する
  これにより、残りの手順を準備することができます。
• 必要な情報を見つけて整理する
  製品名や注文番号など、データベースに記録する必要があるすべての種類の情報を収集します。
• 情報をテーブルに分割する
  情報の項目を主なエンティティや主題 (製品、注文など) に分割します。 各主題がテーブルになります。
• 情報の項目を列に変える
  各テーブルに格納する情報を決定します。 各項目がフィールドになり、テーブルの列として表示されます。 たとえば、従業員テーブルには、姓や雇用日などのフィールドが含まれます。
• 主キーを指定する
  各テーブルの主キーを選択します。 主キーとは、各行を一意に識別するために使用される列です。 例として、製品 ID や受注 ID があります。
• テーブル リレーションシップを設定する
  各テーブルを確認し、1 つのテーブルのデータと他のテーブルのデータとの関係を決定します。 リレーションシップを明確にするため、必要に応じてテーブルにフィールドを追加したり、新しいテーブルを作成します。
• 設計を調整する
  設計にエラーがないか分析します。 テーブルを作成し、サンプルのレコードをいくつか追加します。 テーブルから必要な結果を得られるか確認します。 必要に応じて設計を調整します。
• 正規化ルールを適用する
  データの正規化ルールを適用して、テーブルの構造が正しいか確認します。 必要に応じてテーブルを調整します。

ページの先頭へ

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

データベースの目的、用途、その使用者などのデータベースの目的を用紙に書き出すとよいでしょう。 たとえば、ホーム ベースのビジネス向けの小規模なデータベースの場合は、「顧客データベースには、メールとレポートを作成する目的で顧客情報のリストが保持されます」のような簡単な記述を行います。データベースがより複雑である場合や、企業環境でよくあるように多くの人が使用している場合は、目的は簡単に段落以上になる可能性があり、各人がデータベースをいつ、どのように使用するかを含める必要があります。 設計手順全体を通して参照できる、完成度の高いミッション ステートメントを作ることが目的です。 そのようなステートメントがあると、意思決定のときに目的に焦点を絞ることができます。

ページの先頭へ

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

必要な情報を見つけて整理するには、既存の情報から始めます。 たとえば、発注書を台帳に記録したり、紙のフォームの顧客情報をファイル キャビネットに保管したりできます。 それらのドキュメントを収集し、表示される各種類の情報 (たとえば、フォームに入力する各ボックス) を一覧表示します。 既存のフォームがない場合は、代わりに顧客情報を記録するフォームを設計する必要があると想像してください。 フォームにはどのような情報を入れますか? どのような記入ボックスを作成しますか? これらの各項目を特定して一覧表示します。 たとえば、現在、顧客リストをインデックス カードに保持しているとします。 これらのカードを調べると、各カードには顧客の名前、住所、市区町村、州、郵便番号、電話番号が含まれていることがわかる場合があります。 これらの各項目は、テーブル内の潜在的な列を表します。

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

次に、データベースから作成するレポートまたはメールの種類を検討します。 たとえば、製品売上レポートでは販売地域別に表示したり、在庫概要レポートでは製品の在庫レベルを表示できます。 また、セール イベントをお知らせしたり、プレミアムを提供したりするフォーム レターを生成して顧客に送信することもできます。 頭の中でレポートを設計し、それがどのようなものになるかを想像してください。 レポートにはどのような情報を入れますか? 各項目を一覧表示します。 フォームレターと作成予定のその他のレポートについても同じ操作を行います。

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

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

各レポートまたは出力リストのプロトタイプを構築し、レポートを作成するために必要な項目を検討することは理にかなっています。 たとえば、フォームレターを調べると、いくつかのことが思い浮かぶかもしれません。 挨拶を開始する "Mr."、"Mrs."、"Ms." などの適切な挨拶を含める場合は、挨拶項目を作成する必要があります。 また、通常、手紙は「親愛なるスミスさん」ではなく、「親愛なるスミスさん」で始めるかもしれません。 シルベスター・スミス氏」。 これは、通常、姓を名とは別に保存する必要があることを示唆しています。

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

データベースで回答してもらいたい質問について考えます。 たとえば、注目の商品の先月の売上は何件で成立しましたか? 最良の顧客はどこに住んでいますか? ベストセラー製品のサプライヤーはどこですか? これらの質問を予測することで、記録する追加の項目に絞り込むのに役立ちます。

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

ページの先頭へ

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

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

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

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

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

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

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

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

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

ページの先頭へ

情報の項目を列に変える

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

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

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

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

• 計算データを含めない
  ほとんどの場合、計算結果をテーブルに含めません。 代わりに、結果を表示するときに Access に計算を実行させます。 たとえば、データベース内の製品の分類項目ごとの注文総数の小計を示すレポートがあるとします。 しかし、どのテーブルにも注文総数の小計列がないとします。 その代わり、製品テーブルには各製品の注文総数を格納する注文総数列があります。 Access はこのデータを使用して、レポートを出力するたびに小計を計算します。 小計自体はテーブルに格納しないようにします。
• 情報は最小限の論理単位で格納する
  完全な名前、または製品名と製品の説明を 1 つのフィールドにしたくなるかもしれません。 1つのフィールドで複数の種類の情報を組み合わせると、後から個々の事実を取得することは困難です。 情報を論理的な部分に分解してみてください。たとえば、姓と名、製品名、カテゴリ、説明のフィールドを分けて作成します。

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

ページの先頭へ

主キーを指定する

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

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

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

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

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

主キーに適した列または列セットが頭に浮かばない場合は、オートナンバー型の列の使用を検討してください。 オートナンバー データ型を使用すると、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 つのテーブルに分割する必要があるテーブルがある場合などです。

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

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

• 列を忘れましたか? その場合、情報は既存のテーブルに属しますか? 他の何かに関する情報である場合は、別のテーブルを作成する必要がある場合があります。 追跡する必要があるすべての情報項目の列を作成します。他の列から情報を計算できない場合は、その列の新しい列が必要になる可能性が高くなります。
• 既存のフィールドから計算できるので不要な列はありますか? 情報項目を他の既存の列から計算できる場合 (小売価格から計算される割引価格など)、通常はそれだけを行う方が適切であり、新しい列を作成しないようにすることをお勧めします。
• いずれかのテーブルに繰り返し重複する情報を入力していませんか? その場合は、テーブルを 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 にキー付けされた別のテーブルに移す必要があります。

ページの先頭へ