ER図 リレーションシップを正しく使い分けよう

 2017.11.27  株式会社システムインテグレータ

ER図 リレーションシップ基本のおさらい

こんにちは、皆さん頑張って設計していますか?

ER図とはご存知の通り「E=エンティティ(実体)」「R=リレーションシップ(関連)」を用いたデータモデル図です。

エンティティがテーブル、リレーションシップがその関連性を表しているのですが、リレーションシップにはいくつか種類があります。今回はいったん基本に立ち返り、リレーションシップを正しく使い分けられているかおさらいしてみましょう。

ER図 リレーションシップとは

リレーションシップとは参照整合性制約のことで、物理データベースでは外部キーが設定されます。単にリレーションと言う場合もありますが、正しくはリレーションシップです。

ER図では関係のあるエンティティ間に、条件に合った線を引いていくのですが、以下の三種類を使い分けて設計していくことになります。

種類

使用例

線種

依存リレーションシップ

子テーブルの存在が親に依存している場合

実線

親テーブル → 子テーブル

非依存リレーションシップ

子テーブルの存在が親に依存していない場合

点線

親テーブル → 子テーブル

多対多リレーションシップ

 2つのテーブルの関係が多対多となっている場合

実線

双方向

SI Object Browser ERでももちろんすべて選択可能です。ざっとまとめるとこんなところですが、それぞれ具体例をあげて解説していきます。

 

依存リレーションシップとは

はじめは依存リレーションシップです。SI Object Browser ERでは上部ツールバーのeri0.pngアイコンを選択しましょう。

依存リレーションシップは、親子関係であるテーブルの子テーブルが、親の存在に依存している場合に用います。具体的には、売上伝票のヘッダテーブルと明細テーブルがこの関係になります。この場合親がヘッダテーブル、子が明細テーブルとなるのはお解りいただけると思いますが、明細テーブルのデータ(売上明細)はヘッダテーブルが存在して初めて発生します。つまり、親の存在なくして子の存在はあり得ない、「子の存在が親に依存している」というわけです。

 物理的には、「親テーブルの主キーが子テーブルの主キー含まれている」ことになります。親の存在が必須なのですから、当然といえば当然ですね。

データベース設計・移行に関するお役立ち資料

er1.png依存リレーションシップ(実線)

エンティティは線から上の属性を主キーとして扱います。親の主キーである伝票NOが、子の主キー属性であり同時に外部キー(FK)であることがわかります。

非依存リレーションシップとは

続いて非依存リレーションシップです。ツールバーからeri1.pngを選択します。こちらは反対に、親子関係であるテーブルの子テーブルが、親の存在に依存していない場合に用います。具体的には、売上ヘッダテーブルと顧客マスタテーブルがこの関係になります。この場合親が顧客マスタ、子が売上ヘッダテーブルとなります。売上ヘッダが存在するために、顧客マスタは必須ではありませんので、「子の存在が親に依存していない」となります。

物理的には、「親テーブルの主キーが子テーブルの主キー含まれていない」ことになります。

er2.png

非依存リレーションシップ(点線)

顧客マスタの主キーである顧客NOは、売上ヘッダのエンティティの線から下にFKとして存在していることが見て取れます。

多対多リレーションシップとは

最後は少し特殊な多対多リレーションシップです。ツールバーのアイコンはeri2.pngです。

上の2つとは違ってER図の論理モデルに用います。リレーショナルデータベースでは、2つのテーブル間に多対多の関連性を持つことはできませんが、ER図に論理情報として持つことは可能です。たとえば、担当者マスタと地区マスタが多対多の関係になります。

AさんはA地区、B地区が担当であり、C地区はBさんとCさんが担当を受け持っています。

このように一人の担当が複数地区を受け持つ、あるいは一つの地区に複数の担当が存在している状況の場合、ER図上で多対多リレーションシップを用いて下記のように表現します。

er3.png

多対多リレーションシップ
 

ER図の論理モデル上ではこれでOKですが、物理モデルにこのまま反映することはできません。この場合は物理モデル上に中間テーブルを用意し、下記のように1対多対1として表現します。

er4.png

中間テーブルを用いて多対多を表現

 担当地区テーブルを新たに作成し、それぞれを1対多の親子関係にすることによってデータベース上で表現可能となります。 [RELATED_POSTS]

リレーションシップ まとめ

いかがでしたでしょうか。それぞれのリレーションシップをうまく使い分けられていましたか?

親の主キーが子の主キーであるかないかなど、いったん整理してみるとスムーズな設計が可能になります。
多対多リレーションシップは特殊で、物理データベース設計では特に用いる必要はありませんが、論理設計情報と割り切ってわかりやすさを優先する場合など、使ってみてはいかがでしょうか。
SI Object Browser ERでは、ツールならではの便利な機能をご用意しております。
上記の親子間の主キーの法則性も、設定するリレーションシップによって自動でカラムを設定してくれます。(該当カラムが子に存在しない場合)

er5.png

主キー属性を自動生成

依存関係なのに子の主キー属性に親の主キー属性が存在しないといった設計ミスを防ぐことが可能です。地味なようですが意外に重要な機能です。無料トライアル版もご用意しておりますのでER図を設計する際にはSI Object Browser ERをぜひご利用ください。

SI Object Browser ER ガイドブック

RECENT POST「OBERをトコトン極める」の最新記事


この記事が気に入ったらいいねしよう!