リレーションシップは、あるエンティティと他のエンティティのインスタンスの数の対応関係であり、以下の4種類があるということは前回の記事で説明しました。
今回は、実際のデータを踏まえて、リレーションシップの実践例から理解を深めていきましょう。
1対1の例
1対1のリレーションシップを考えてみます。
図書館での本の予約・貸出システム向けE-R図の一部を切り出したものです。読みたい本が既に誰かに貸し出されている場合、その本を予約します。その本が返却されたら（もしくは図書館がもう一冊購入したら）、予約した人に貸し出します。この場合、予約エンティティと予約貸出エンティティの間には、1対1のリレーションシップが成立します。ある1つの予約インスタンスに対して、1つの予約貸出インスタンスが対応し、逆に、ある1つの予約貸出インスタンスに対して、1つの予約インスタンスが対応するからです。
オプショナリティを加える場合には、0を許容するかどうかを問題文から読み取らないといけませんません。0を許容するかどうかなんてどっちでも良いじゃないかと考えてしまうかもしれませんが、実際はそうではありません。
例えば、0を許容するかどうかで、
(1) 1つの予約に対して、貸出が0または1つ
(2) 1つの予約に対して、貸出が必ず1つ
と、なり、業務ルールがまったく変わってきます。これはつまり、(1)の場合（0を供する場合）は、予約のキャンセルが許されるが、(2)の場合はキャンセルは許されないと推測することができます。（但し、これだけでは断定できない点に注意してください。）上記例ではどちらのエンティティも「●」となっているため、予約インスタンスからみて、予約貸出インスタンスは必ず1となり、逆に、予約貸出インスタンスからみて、予約インスタンスも必ず1となるということを表します。
1対1のリレーションシップは実務では極端に少ない
1対1のリレーションシップについて考えましたが、この関係は特殊であり、実務では極端に事例が少ないということは覚えておきましょう。1対1のリレーションシップは「業務要件や強い制約条件がある」場合にしか使われません。
1対多の例
次に1対多のリレーションシップを考えてみます。実際に実務でE-R図を作成する際、この関係が最も多く成り立つことになるでしょう。
部署と社員の関係の例です。この会社では、1人の社員は1つの部門にしか所属せず、1つの部門には複数の社員が所属しています。この場合、部署エンティティと社員エンティティの間には、1対多のリレーションシップが成立します。上図のように、1つでも1対多のリレーションシップがあれば、残り全てが1対1のリレーションシップであっても、1対多のリレーションシップに該当します。
次に、オプショナリティを加えて考えてみます。「社員の1人もいない部署」や「どの部署にも所属しない社員」などが存在してもよいかをオプショナリティを加えることで判別可能になります。
例えば以下のような業務ルールがあったとします。
- 1つの部署に対して、社員が0人～複数人
- 1人の社員に対して、部署が必ず一つ
これはつまり、「社員の1人もいない部署」は存在し、「どの部署にも所属しない社員」は存在しない（許容されない）ことを表します。では、「社員の1人もいない部署」とはいったいどんな部署が考えられるのでしょうか。例えば、既に廃部となった部署をマスタに残している場合です。当然その部署には社員は1人もいません。
多対多の例
多対多のリレーションシップも特殊な関係と言えます。
1対多のリレーションシップの例で示したものと異なり、1人の社員は複数の部署に所属することがあり、1つの部署には複数の社員が所属していることがあります。この場合、部署エンティティと社員エンティティの間には、多対多のリレーションシップが成立します。
多対多のリレーションシップは、そのまま論理データモデルに転換していくと非正規形になります。これは「多」の部分が繰り返し項目になってしまうからです。それはつまり、多対多のリレーションシップは、未完成な設計に該当します。データベーススペシャリスト試験のE-R図問題では基本的に多対多のリレーションシップは排除されています。なぜなら、正規化することで多対多が排除されるからです。もし問題の中で多対多のリレーションシップが存在すれば、これを排除する（正規化する）設問があるでしょう。
では、設計を完成させるためにはE-R図で多対多のリレーションシップをどのようにすれば良いでしょう。それは、それら2つのリレーションシップの間に「連関エンティティ」と呼ばれるエンティティを一つ設けることで、1対多のリレーションシップに変換すれば良いです。
次の記事では、その「連関エンティティ」について詳しくみていきます。
