2.3 概念設計の手順(1/3)

できるエンジニアになるためのちょい上DB術/第2章 概念設計

2.3 概念設計の手順(1/3)

2.3.3 リレーションシップを検討する

リレーションシップの抽出

リレーションは、2つのエンティティ間に存在する、業務上意味のある関係で、2つのエンティティを結ぶ動詞として表現されます。
片方のエンティティを主語とし、もう片方のエンティティを目的語とし、それを結ぶ動詞がリレーションとして表されます。

ところが、動詞はリレーションではなく、イベント系のエンティティとして抽出されることもあります。
動詞として管理すべき内容が複数のデータ項目で表現される場合は、イベント系のエンティティになり、単純な動詞として表されるのであれば、リレーションということができます。

リレーションシップの表記方法

リレーションシップは、エンティティとエンティティの間の意味のある関連を示します。
表記の例と、コンポーネントの名称を図2-5に示します。

リレーションシップは以下の手順で描きます。

  • 1. 2つのエンティティの間で、ある意味をもった関連ごとに1本の線を引きます
  • 2. 線の上下(または左右)にリレーションシップの名前(動詞)を記述します
  • 3. 線の両端にオプショナリティ、カーディナリティを記述します

複数のリレーションが存在する場合の表記例を以下に示します。

リレーションシップを見つけ出すには、まず対象となる2つのエンティティの各オカレンスを正確に認識する必要があります。
その上で、どちらか(のエンティティ名)を主語とし、もう一方を目的語として文を形成する動詞を考えます。

2つのエンティティの問に複数の関係(動詞)が存在する場合、リレーションシップは複数引く必要があり、それぞれにリレーションシップ名を記述します。
図2-6の場合、以下のように明らかに異なる動詞(関係)が存在します。

  • 社員は製品を製造する
  • 社員は製品を販売する

リレーションが複数存在するか迷う場合、リレーションが発生するタイミングを考えてみるとわかりやすい場合があります。
たとえば、図2-6の例で考えてみましょう。
製品を製造するというタイミングと販売するというタイミングは、明らかに異なるタイミングです。
したがって、複数のリレーションが必要であることがわかります。

リレーション名をER図に記述することは少ないのですが、後に残すドキュメントであるという観点からすれば、記述すべきといえるでしょう。
特に複数のリレーションを引いた場合は、その意味がわかりにくくなるため、リレーション名を明記することをお勧めします。

ER図は複数の関係者のコミュニケーションツールとして使用されるものであり、時系列で考えると、後でアプリケーションの拡張など、メンテナンスを行うメンバーが見る可能性が高いはずです。
後から参照する人たちが迷うことがないように、リレーション名をER図の情報としてどこかに記述しておくべきでしょう(図上に名前が書いてあると、図自体が煩雑になってしまうため、プロパティシートなどに記述するのが適当でしょう)。

社員がどの企業に所属するかは、組織エンティティを経由して企業エンティティのオカレンスを特定することができます。
この場合、社員から企業へのリレーションは冗長なので、正規化の観点から、リレーションを引いてはいけません。
同じ意味をもつリレーションが2つ存在するということは、関連する情報が変更されたとき、変更を1箇所に特定することができないことになるからです。

実際には、パフォーマンスの観点から(正規化されている場合、企業を特定するために1つ余分な結合を行う必要があるため、パフォーマンス的には不利)社員エンティティから企業エンティティに直接リレーションを引くケースはあり得るのですが、概念設計では正規化された理想的なモデルを目指すので、冗長なリレーションは排除します。

< 前へ | 2.3 概念設計の手順(1/3) | 次へ >

解説トレーナー

Oracle / 上流工程 担当 中村 才千代

データベース設計、システム構築の上流~下流工程全般のインストラクターです。SE時代の経験を生かし「業務を知るエンジニアこそDB設計に関わるべき」「DB設計に携わるエンジニアは業務を知る人に知恵を貸してもらう」ことを伝えたいと思っています。

■認定・受賞

2000年 Oracle University「Best Instructor of the Year」受賞
2002年 Oracle University「Best Instructor of the Year」受賞

Page Top