30分でわかるER図の書き方 (10)
前々回、前回に引き続き、ER図に関する補足的なトピックを扱います。今回は、交差エンティティについて説明します。
前回: id:simply-k:20100714:1279071645
次回: -
目次: id:simply-k:20100716:1279237959
多対多のリレーションシップ
次の図を見てください。
この図を見ると、「商品」と「仕入先」の間に、多対多の関連がある事をがわかります。ER図としては、特に問題はありません。しかし、このER図を元にしてリレーショナル・データベースのテーブル設計をする場合、次のような問題が発生します。
このような場合、交差エンティティ(intersection entity)と呼ばれるエンティティを導入することで、多対多のデータを保持できるようになります。
交差エンティティ
次の図は、先ほどの図に交差エンティティを導入したものです。
「商品仕入先」エンティティが、「商品」エンティティと「仕入先」エンティティの交差エンティティとなります。「商品仕入先」エンティティは、「商品」エンティティの主キーである「商品ID」と、「仕入先」エンティティの主キーである「仕入先ID」を、複合主キーとしています。このため、関連する商品と仕入先の組み合わせを、データとして登録することができます。また、「適用開始日」や「適用終了日」といった、付加的な属性を追加することもできるようになります。
交差エンティティを導入すると、多対多のリレーションシップは、1対多のリレーションシップに分解されます。このため、リレーショナル・データベースの設計において、エンティティをテーブル、リレーションシップを外部キー制約で実現できるようになります。
ところで、上の交差エンティティには、まだ少し問題があります。それは、ある商品とある仕入先の組み合わせに対し、複数の適用開始日・適用終了日を登録できないということです。この問題に対処したのが、次の図です。
「商品仕入先」エンティティに枝番を導入することにより、ある商品とある仕入先の組み合わせに対し、複数の適用開始日・適用終了日を登録可能としています。このように、交差エンティティの主キーには、外部キーでない属性が含まれることもあります。また、これと同じことを実現する場合に、次のようにすることも可能です。
この例では、「商品仕入先」の主キーとして「商品仕入先ID」を導入したため、「商品仕入先」が独立エンティティとなっています。このように、交差エンティティの主キーに外部キーを含めない設計も可能です。
その他の例
交差エンティティの例を、もう1つ紹介します。次の図をみてください。
この図は、顧客と商品の購入における関わりが多対多であることを示しています。この図に、単純に交差エンティティを導入すると、次のようになります。
「受注」エンティティが交差エンティティです。しかし、この「受注」エンティティには、次のような問題があります。
- ある顧客が同じ商品を複数回購入した場合に、その事実をデータとして保持できない。
- 受注単位のデータ(受注日など)を保持できない。
この問題に対処したのが、次の図です。
この図では、交差エンティティとして導入された「受注」エンティティを、さらに「受注」エンティティと「受注明細」エンティティに分解しています。このように、多対多のリレーションシップに対して交差エンティティを導入した場合、結果的に複数のエンティティが導入されるということも起こりえます。
最後に
今回で、「30分でわかるER図の書き方」は終了です。ER図を読み書きする上での基本的な知識について、一通りの事を網羅したつもりです。ここまで読んでくれた方で、どうもまだ理解できないという方がいましたら、実際にER図を書いてみることをお勧めします。ER図は、書き方自体は決して難しいものではありません。*1 いろいろなER図を書いているうちに、自然と理解できると思います。
前回: id:simply-k:20100714:1279071645
次回: -
目次: id:simply-k:20100716:1279237959
