ERの基礎知識とツールの活用法

前回の復習

   前回の説明でデータモデリングツールを使った設計作業の効率化をテーマとしました。ER図のEとRの意味の解説にはじまり、表1のことが理解できたかと思います。

---

• 概念モデルから論理モデル
• 物理モデルへ展開する手法
• フォワード／リバース機能によりトップダウン／ボトムアップを繰り返す設計作業
• 論理モデルと物理モデルの表裏一体アーキテクチャ

   前回からデータモデリング全体の利用法が理解できたかと思います。今回はデータモデリングの中身の話に入り、ERの基礎知識とツールの活用方法について解説します。データ中心設計（DOA）の基礎となるERについて、ぜひマスターしてください。

依存型リレーションと非依存型リレーション

   ERの醍醐味はリレーションです。リレーションの線がなければERはただの箱（エンティティ）の羅列で、無味乾燥したものになります。エンティティとエンティティの関係が一目であらわされることがER図の意義なのです。

   ERのリレーションには依存型と非依存型があります。親エンティティがなければ子エンティティが存在できないものが依存型リレーション、親がなくとも子が独立して存在できるものが非依存型リレーションです。

   図1はSQL ServerのサンプルデータベースNorthwindをリバースしたER図の一部です。


   「受注」と「受注明細」の関係は、依存／非依存のどちらでしょうか。この2つは受注伝票のヘッダとボディの関係ですので、「受注」エンティティがなければ「受注明細」エンティティは存在し得ません。つまり、この2つのエンティティは依存関係にあります。

   では、「受注」と「顧客」はどうでしょうか。この2つは非依存関係となります。「受注」がなくても「顧客」データは存在できますし、「顧客」がなくても「受注」は存在できます。図1のように、ER図上では依存関係が実線、非依存関係が破線のリレーションであらわします。

   リレーション（関係）が依存型／非依存型かはモデリング上の定義ですが、実装面では主キー項目で判断することができます。依存型の場合、子の主キー項目に親の主キーが含まれます。「受注」と「受注明細」の例で見てみると、子（受注明細）の主キーに親（受注）の主キー「受注番号」が含まれていますので、依存関係であることがわかります。

   一方、非依存型の場合は親の主キー項目が子の主キー項目に含まれません。「受注」と「顧客」の例ですと、親の主キー「顧客番号」は子の非主キー部分に外部キー（フォーリンキー）として存在していますので、非依存関係ということになります。

カーディナリティ

   エンティティとエンティティの関係には、次の3種類のリレーションがあります。

• 1対1
• 1対n
• n対n

   このような対応関係をカーディナリティと言います。簡単にいえば「あるテーブルの1レコードに対して、他のテーブルのレコードが複数存在するか」というようなものです。例えば図1の「受注」と「受注明細」の場合は、1つの受注（伝票）に対して明細行が複数存在するので1対nの関係になります。

   カーディナリティはリレーションの形状で表されます。図1の例でいえば、線の端っこが太丸ならn（多）、線のままなら1ということになります。このリレーションの形は重要です。例えば、「受注明細」側の終端が太丸でなく線のまま結合すると、「受注」と「受注明細」は1対1の関係となります。つまり、この場合は1回の受注では1品目しか注文を受けないというアプリケーションを示すのです。

   ER図のカーディナリティは、RDBMSへの実装においては内部結合と外部結合に関連します。1対1は内部結合、1対nなら外部結合に相当しますので、複数テーブルを組み合わせたSQLを作成する時の結合方法になります。

IDEF1X表記とIE表記

   ER図にはいくつかの表記法があります。図1の描き方はIDEF1X（アイデフワンエックス）と呼ばれる表記法で、著者はもっぱらこちらを使っています。これと人気を2分しているのが図2のようにn側を鳥の足のように表示すIE表記です。データモデリングツールは両方の表記をサポートしていますので、ワンタッチで切り替えることができます。