MySQL Workbench の EER モデリングツールでリレーションシップ検証 3 （リレーションシップアイコンの種類と使い方）

前回、前々回の記事で、外部キーの設定と制約の定義方法について説明してきましたが、今回は EER モデリングツールのリレーションシップアイコンの種類と使い方について説明します。

EER モデリングでリレーションシップの設定を行う場合は、画面の左下に並ぶ 6 種類のアイコンを使います。

 既存のテーブル列を使ってリレーションシップを設定する

大抵の場合は、先に基本的なテーブルを予め定義しておき、後でリレーションシップを設定する作業手順となるでしょう。そのような場合は、上記赤囲みの一番下のアイコンを使用します。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]、および取扱商品テーブルの [ブランドID] は共に既存の列にが使われています。

 外部キー専用の列を子テーブルに新規追加し、1対1 の非依存型（non identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対1 の非依存型のリレーションシップを設定する場合は、一番上のアイコンをクリックします。

非依存型（non identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側、および取扱商品テーブル側の支線は枝分かれしていないため、このリレーションシップが 1対1 の関係となっていることがわかります。

非依存型リレーションシップの場合、コネクタは破線で表現されます。

 外部キー専用の列を子テーブルに新規追加し、1対多の非依存型（non identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対多の非依存型リレーションシップを設定する場合は、上から二番目のアイコンをクリックします。

非依存型（non identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側の支線が枝分かれしていないのに対し、取扱商品テーブル側の支線が三つに枝分かれしているため、ブランド 1 に対し、取扱商品が多の関係になっていることがわかります。

非依存型リレーションシップの場合、コネクタは破線で表現されます。

 外部キー専用の列を子テーブルに新規追加し、1対1 の依存型（identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対1 の依存型のリレーションシップを設定する場合は、上から三番目のアイコンをクリックします。

依存型（identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側、および取扱商品テーブル側の支線は枝分かれしていないため、このリレーションシップが 1対1 の関係となっていることがわかります。

依存型リレーションシップの場合、コネクタは実線で表現されます。

 外部キー専用の列を子テーブルに新規追加し、1対多の依存型（identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対多の依存型リレーションシップを設定する場合は、上から四番目のアイコンをクリックします。

依存型（identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側の支線が枝分かれしていないのに対し、取扱商品テーブル側の支線が三つに枝分かれしているため、ブランド 1 に対し、取扱商品が多の関係になっていることがわかります。

依存型リレーションシップの場合、コネクタは実線で表現されます。

 多対多のリレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと多対多のリレーションシップを設定する場合は、下から二番目のアイコンをクリックします。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

多対多の場合は、子テーブルの外部キーと親テーブルの主キーを結び付けると、テーブル名_has_テーブル名 という名前のテーブルが新たに作成されます。
このテーブルは、子テーブルに対する外部キーおよび親テーブルに対する外部キーをそれぞれ持っている点に注目してください。

上図の場合では、ブランド_has_取扱商品 というテーブルに、取扱商品テーブルの主キーに対する外部キー、およびブランドテーブルの主キーに対する外部キーが作成されることを示しています。


外部キーを確認すると、以下のようになっています。


○ブランドテーブルに対する外部キー

ブランドテーブルの主キー[ブランドID]に対する外部キーが作成されています。



○取扱商品テーブルに対する外部キー

取扱商品テーブルの主キー[商品ID]に対する外部キーが作成されています。



【関連リンク】
MySQL Workbench 基礎講習コース

MySQL Workbench の EER モデリングツールでリレーションシップ検証 2 （外部キー制約の種類と動作）

前回の記事では、リレーションシップ構築時の idendifying （依存型）および non identifying (非依存型) の考え方と設計方法について述べましたが、今回は外部キーで設定可能な制約の種類と動作について説明します。


【外部キー制約とは】

子テーブル側の外部キーと、親テーブルの主キーの参照整合性を維持するために、子テーブル側の外部キーの動作を制限するものです。

たとえば、前回のブランドと取扱商品との関係性では、取扱商品テーブル側に不明な外部キー（[ブランドID]）が存在しないように制御したり、ブランドテーブル側から特定のブランドを削除した場合、そのブランドに関連する商品を取扱商品から自動的に連動して削除させたりといった振る舞い（制約）を設定します。


MySQL Workbench の EER モデリングでは、下図のように Foreign Key タブ上の Foreign Key Option を選択するだけで外部キー制約の設定が行えます。

【On Update と On Delete】

外部キー制約のオプションは、更新時（On Update）、削除時（On Delete）に大別されます。

これらは、親テーブル側（上図ではブランド）側の動作を示しており、親テーブル側のレコードが更新されたり（On Update）、削除されたり（On Delete）したときに、子テーブル（上図では取扱商品）の関連レコードの扱いを定義するという意味です。
そして、実際の関連レコードの扱いは、上図の赤囲みのドロップダウンリストから選択します。


【外部キー制約の種類】

ドロップダウンリストから選択可能な外部キー制約は次のとおりです。

RESTRICT/NO ACTION
子テーブルに関連レコードがあったら、親レコードの更新/削除を許可しない。

NO ACTION はステートメントおよびすべてのトリガーが起動された後に子テーブルの値がまだ有効であれば変更は許可される。
これに対し、RESTRICT は、子テーブルに関連レコードが存在する場合、変更は絶対に許可されない。
RDBMS ではこのような厳密な動作の違いがあるものもあるが、MySQL では RESTRICT と NO ACTION の挙動は同じ。


たとえば、取扱商品（子テーブル側）の登録を始めたら、ブランド名（親テーブル側）の変更をさせないようにする場合がこれに相当します。

CASCADE
親テーブルのレコードを更新/削除したら、子テーブルのレコードも更新/削除する。
厳密には、親テーブルの主キーの値を更新したら、子テーブルの外部キーの値も同じ値で更新され、親テーブルのレコードを削除したら、そのレコードに関連する子テーブルのレコードも連動して削除される。

たとえば、特定のブランド（親テーブル側）を削除したら、そのブランドを持つすべての取扱商品（子テーブル側）を削除するようにする場合がこれに相当します。

SET NULL
親テーブルのレコードを更新/削除したら、子テーブルの外部キーの値を NULL に設定する。
これにより、当該レコードの親子関係が解除されることになる。

たとえば、ブランド（親テーブル側）を削除したとしても、取扱商品（子テーブル側）は将来の管理用にデッドストックとして残しておく場合がこれに相当します。


親テーブルの主キーを変更した場合、および親レコードを削除した場合の外部キー制約の振る舞いを表にすると、以下のようになります。

動作条件	挙動	親（子なし）	親（子あり）	子
On Update	RESTRICT/NO ACTION	親主キー更新可	親主キー更新不可	変化なし
	CASCADE	親主キー更新可	親主キー更新可	外部キー連動更新
	SET NULL	親主キー更新可	親主キー更新可	外部キーNULL
On Delete	RESTRICT/NO ACTION	親レコード削除可	親レコード削除不可	変化なし
	CASCADE	親レコード削除可	親レコード削除可	子レコード連動削除
	SET NULL	親レコード削除可	親レコード削除可	外部キーNULL

【SQL による外部キー制約の例】

前述の外部キー制約のパターンのうちのいくつかを、実際の SQL による定義でいくつか確認してみましょう。太字が外部キーの設定と制約を定義している部分です。特に赤字の部分に注目してください。

挙動については、前項のテーブルをご覧ください。

---

例1: 
On Update: NO ACTION

On Delete: CASCADE

---

--

-- Table structure for table `取扱商品`

--

DROP TABLE IF EXISTS `取扱商品`;

SET @saved_cs_client     = @@character_set_client;

SET character_set_client = utf8;

CREATE TABLE `取扱商品` (

  `ブランドID` int(11) DEFAULT NULL,

  `商品ID` int(11) NOT NULL AUTO_INCREMENT,

  `商品名` varchar(45) CHARACTER SET utf8 DEFAULT NULL,

  PRIMARY KEY (`商品ID`),

  KEY `fk_取扱商品_ブランド` (`ブランドID`),

  CONSTRAINT `fk_取扱商品_ブランド` FOREIGN KEY (`ブランドID`) REFERENCES `ブランド` (`ブランドID`) ON DELETE CASCADE ON UPDATE NO ACTION

) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1;

SET character_set_client = @saved_cs_client;

---

例2: 
On Update: CASCADE

On Delete: SET NULL

---

--
-- Table structure for table `取扱商品`
--


DROP TABLE IF EXISTS `取扱商品`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `取扱商品` (
  `ブランドID` int(11) DEFAULT NULL,
  `商品ID` int(11) NOT NULL AUTO_INCREMENT,
  `商品名` varchar(45) CHARACTER SET utf8 DEFAULT NULL,
  PRIMARY KEY (`商品ID`),
  KEY `fk_取扱商品_ブランド` (`ブランドID`),
  CONSTRAINT `fk_取扱商品_ブランド` FOREIGN KEY (`ブランドID`) REFERENCES `ブランド` (`ブランドID`) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

【関連リンク】
MySQL Workbench 基礎講習コース

MySQL Workbench の EER モデリングツールでリレーションシップ検証 1 （Identifying と Non identifying）

MySQL Workbench の便利な機能に EER モデリングツールがあります。

MySQL Workbench の EER モデリング例 

http://www.mysql.com/common/images/products/MySQL_Workbench_Visual_Design_Windows.gif 

EER モデリングツールを使うことによって、データベースの基本設計を行い、それを使って MySQL 　データベース本体を生成したり（フォワードエンジニアリング）、既存の MySQL データベースを EER モデリングツールに読み込ませて（リバースエンジニアリング）設計内容を修正した後で再び MySQL データベースに同期（シンクロナイジング）させたりすることができます。

EER モデリングツールの魅力は、何といってもデータベース設計を視覚的に行えるところにあることでしょう。
テーブル定義、列定義はもちろんのこと、テーブルオブジェクトの配置、リレーションシップの設定などもマウスクリックや簡単な入力作業である程度の設計が可能です。

MySQL Workbench は、MySQL の公式サイトからダウンロードできます。

ダウンロード先：MySQL Workbench 5.2


今回より、MySQL Workbench の EER モデリング機能で設定可能なリレーションシップの種類と、その動作の違いについて数回に分けて説明します。

リレーションシップの種類には、一対一、一対多、多対多、自己リレーションなどがありますが、それらの基本的な概念は他のサイトでも多く触れられているため、本記事では省略します。


【Identifying と Non identifying】

EER でリレーションシップ設定を行い、外部キーの設定情報を確認したときに以下のようなチェックボックスが気になった方もいらっしゃるのではないでしょうか。

そこで、今回は、上記のリレーションの外部キー属性となる、identifying と non identifying の違いについて説明します。

---

Identifying relationship （依存リレーションシップ）--- 子テーブルの外部キーの一部に親テーブルの主キーが組み込まれた形となり、親テーブルなしでは成り立たない関係。

---

たとえば、ブランド契約で販売する商品が、撤退時に商品の取扱いも同時に終了するように、ブランドテーブルと取扱い商品テーブルを関連づける場合、[商品ID] および[ブランドID] の組み合わせで外部キーを作り、[ブランドID]  が存在しなければその商品は存在し得ないような厳密な設計を行います。

本来、子テーブル側の主キーは一つ（[商品ID]）ですが、依存型リレーションシップの場合は親テーブル側のIDを識別するための列（[ブランドID]）も主キー扱いとなりますので、上図のように子テーブルの主キーは二つとなります（どちらも欠かせません）。

　

　EERモデリングでは、identifying リレーションのコネクタは、上図のように実線で表現されます。

　この場合、外部キー設定がされている取扱商品テーブル構成をダンプ（SQL表記）させると、以下のようになります。
　太字表記の部分が今回のチェック項目になりますが、特に赤字の部分に注目してください。[商品ID] および [ブランドID] の両方が主キー となっています。

--

-- Table structure for table `取扱商品`

--

DROP TABLE IF EXISTS `取扱商品`;

SET @saved_cs_client     = @@character_set_client;

SET character_set_client = utf8;

CREATE TABLE `取扱商品` (

  `ブランドID` int(11) NOT NULL,

  `商品ID` int(11) NOT NULL AUTO_INCREMENT,

  `商品名` varchar(45) CHARACTER SET utf8 DEFAULT NULL,

  PRIMARY KEY (`商品ID`,`ブランドID`),

  KEY `fk_取扱商品_ブランド` (`ブランドID`),

  CONSTRAINT `fk_取扱商品_ブランド` FOREIGN KEY (`ブランドID`) REFERENCES `ブランド` (`ブランドID`) ON DELETE NO ACTION ON UPDATE NO ACTION

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

SET character_set_client = @saved_cs_client;

---

Non identifying relationship（非依存リレーションシップ）--- 親テーブルの主キーと子テーブルの外部キーでリレーションシップを構築するが、子テーブルに外部キーとは独立した主キーを持っている関係。

---

前述のモデルの応用例として、ブランド管理が廃止され商品だけが残った場合にも、在庫商品を処分（販売）できるように、ブランドを問わず商品を管理して扱う場合は、親テーブルが削除された場合にも、子テーブルの商品だけは残して管理できるように設計します。

EERモデリングでは、non-identifying リレーションのコネクタは、上図のように破線で表現されます。


この場合、外部キー設定がされている取扱商品テーブル構成をダンプ（SQL表記）させると、以下のようになります。
太字表記の部分が今回のチェック項目になりますが、特に赤字の部分に注目してください。[商品ID] のみが主キー となっています。

--
-- Table structure for table `取扱商品`
--


DROP TABLE IF EXISTS `取扱商品`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `取扱商品` (
  `ブランドID` int(11) NOT NULL,
  `商品ID` int(11) NOT NULL AUTO_INCREMENT,
  `商品名` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`商品ID`),
  KEY `fk_取扱商品_ブランド` (`ブランドID`),
  CONSTRAINT `fk_取扱商品_ブランド` FOREIGN KEY (`ブランドID`) REFERENCES `ブランド` (`ブランドID`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
SET character_set_client = @saved_cs_client;

【関連リンク】
MySQL Workbench 基礎講習コース