Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
連関エンティティ

#連関エンティティ

オプショナリティを加えた “商品” と “注文” が多対多の ER 図

多対多」のリレーションは、そのまま論理データモデルに転換していくと非正規形になる。これは、「多」の部分が繰り返し項目(非単純定義域)になってしまうためである。

注文テーブル
注文コード 注文日 商品
001 2072/09/21 冷蔵庫
002 2073/01/01 冷蔵庫
003 2095/07/17 テレビ
パソコン
004 2095/07/17 テレビ

上の注文テーブルの例では、 注文コード 003 の行で商品カラムに繰り返し項目が発生している。

そこで、「多対多」を排除するために、そのリレーションの間にエンティティを1つ設けることで、「1対多」のリレーションに変換することができる。この時、新たに設けられたエンティティを連関エンティティと呼ぶ。

##ER 図の中の連関エンティティ

“商品” と “注文” という「多対多」のリレーションの間に 、新たに“注文明細” という連関エンティティを設けると、ER 図は下図のようになる。

 “商品” と “注文” の間に “注文明細” 連関エンティティを設けた ER 図

さらに次の図を例に、連関エンティティについて考える。

 “商品” と “注文” の間に “注文明細” 連関エンティティを設けた論理モデル

##論理モデル化

ここでの業務ルールは「1つの商品に対し、複数の注文が入る。顧客は1回の発注で複数の商品を注文できる」というものである。ここから “商品” エンティティと “注文” エンティティを抽出すると、両者の間に「多対多」のリレーションになる。

そこで連関エンティティとして “注文明細” エンティティを両者の間に設ける。そうすることで、「多対多」のリレーションは排除され、「1対多」のリレーションのみで ER 図が完結する。

##インスタンス

  • 扇風機には注文がない
  • 注文1 には明細1 がある
    • 注文1 の明細1 で冷蔵庫を受注した
  • 注文2 には明細1 がある
    • 注文2 の明細1 で冷蔵庫を受注した
  • 注文3 には明細1 と明細2 がある
    • 注文3 の明細1 でテレビを受注した
    • 注文3 の明細2 でパソコンを受注した
  • 注文4 には明細1 がある
    • 注文4 の明細1 でテレビを受注した

#参考

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment