目次へ

16. データベースの設計

優れたデータベースを構築するためには、設計段階からデータの構成を工夫しなければなりません。効率的なデータベースを設計するための方法論として、「正規化」という概念が存在します。また、この「正規化」の基本概念となるものに ER モデルというものがあります。ここでは、ER モデルについて説明し、具体的にどのようにして正規化を行うのかを説明していきます。

16.1. ER モデル

実世界に存在するものの中で、データベースとして表現すべき対象物をエンティティ (entity:実体) と呼びます。また、エンティティとエンティティの相互関係をリレーションシップ (relationship:関連) と呼びます。そして、この関係を図示し、エンティティとエンティティの間のリレーションシップを分析する技法を ER(Entity-Relationship) モデルといいます。

エンティティとエンティティのリレーションシップには、次のような対応関係があります。

1:1
エンティティ A に対して、エンティティ B は一つしか存在しなくて、エンティティ B に対してもエンティティ A は一つしか存在しないようなリレーションシップの場合、1:1 の対応であるといいます。例えば、エンティティ「学生」とエンティティ「学生番号」のリレーションシップは 1:1 です。

1:N
エンティティ A に対して、エンティティ B が複数存在し、エンティティ B に対してはエンティティ A が一つしか存在しないようなリレーションシップの場合、1:N の対応であるといいます。例えば、エンティティ「父親」とエンティティ「子」のリレーションシップは 1:N です。

M:N
エンティティ A に対して、エンティティ B が複数存在し、エンティティ B に対してもエンティティ A が複数存在するようなリレーションシップの場合、M:N の対応であるといいます。例えば、エンティティ「講義」とエンティティ「受講生」のリレーションシップは M:N です。

16.2. ER モデルの例

ER モデルは、エンティティとエンティティのリレーションシップを図で表したものです。ここでは、次の図に示す受注伝票を例に ER モデルを作ります。

受注伝票  

[備考]

  • 受注番号は、受注伝票が発生するごとに一意につけられる。
  • 同じ商品は一つの受注伝票に記入しない。同じ商品を扱う場合は、別伝票に記入する。
  • 一枚の受注伝票に記入できる商品は 5つまで、6つ以上受注した場合は別伝票とする。
  • 合計金額は数量×単価で求められる。

この受注伝票からエンティティを列挙すると次のようになる。

  • 受注番号
  • 受注日
  • 顧客名
  • 顧客住所
  • 商品番号
  • 商品名
  • 数量
  • 単価
  • 合計金額

ER モデルでは、先ほど説明したリレーションシップの対応によって、エンティティとエンティティを矢印で次のように結びます。1 の方を一つの矢印、M や N の方を二つの矢印で表示します。

ER モデル

受注伝票の各エンティティに関する ER モデルを作成すると次の図のようになります。

各エンティティに関する ER モデル

すべてのエンティティについて ER モデルを作成すると、左の図のようになりますが、点線の部分は記述しない方がよいと考えられます。そこで、点線の部分をのぞいて書き直したものが右の図です。点線の部分を記述しない方がよいと考える理由は次の通りです。

  • [商品番号] と [商品名、単価]:商品名と単価は商品番号に属しているものであり、エンティティとはせずに、商品番号の属性であるとした方が適切です。
  • [受注番号、商品番号] と [数量]:数量は受注番号と商品番号から決まるものであり、受注番号と商品番号をキーとする項目の属性であるとした方が適当です。
  • [顧客名] と [顧客住所]:顧客住所は顧客名が決まれば一意に決まるものであり、エンティティとする必要はありません。顧客名の属性とする方が適切です。

1:1 の対応関係にあるものは、通常は一方の付加的情報であるので、それの属性とすることができます。また、M:N の対応関係にあるものは、何らかの仲介項目を設けることで 1:N の対応関係に変換すると、そのリレーションシップが明確なものになります。

↑このページの先頭へ

こちらもチェック!

PR
  • XMLDB.jp