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

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

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

カーディナリティ

  • リレーションの相手のエンティティオカレンスが1つ特定されたときに、対応するこちらのエンティティオカレンスは
    「最大でも1」もしくは「複数を許す」のどちらか
  • 1つのリレーションにつき、一方から見た場合と他方から見た場合の2つがある
  • 最大数を表す:「最大でも1」または「多の場合がある」

カーディナリティやオプショナリティを検討する際、各エンティティの1オカレンスが具体的に特定できないと分析はできません。
オカレンスを特定するためには、まず一意識別子が決まっている必要があります。

このように、エンティティやリレーションシップを検討する場合には、並行して他の構成要素も考慮する必要があります。
また、カーディナリティやオプショナリティは、2つのエンティティそれぞれの立場から分析する必要があります。

いずれの場合も、相手のエンティティのオカレンスを1つ特定したときに、自分側のエンティティオカレンスがどのように対応するかというルールを自分に近い位置に記述します。

オプショナリティ

  • リレーションの相手のエンティティオカレンスが1つ特定されたときに、対応するこちらのエンティティオカレンスは
    「最大でも1」もしくは「複数を許す」のどちらか
  • 1つのリレーションにつき、一方から見た場合と他方から見た場合の2つがある
  • 最大数を表す:「最大でも1」または「多の場合がある」

オプショナリティは、「相手のいずれのエンティティオカレンスを特定した場合でも自分側のエンティティオカレンスが必ず1以上対応する必要があるか」を検討します。
また、「相手のオカレンスが作成されたとき、最初から自分側のオカレンスが対応する必要があるか」という検討も必要です。
最終的に必要という場合は、必須であるとはいえません。
時系列で考えて、作成時から常に必要であれば必須と判断します。

リレーションシップは、一般化できるものではありません。
業種が同じでも、ビジネスルールが異なれば、おのずとリレーションシップは異なるためです。
システム化しようとしている会社がどのようなビジネスルールを適用しているか、どのように運用しているかを十分ヒアリングする必要があります。
誤ったリレーションシップを記述すると、制約が多すぎて使いにくいデータベースになる可能性があります。
特に必須のリレーションは実装が難しくなる可能性が高いため、慎重に検討してください。

これまで解説してきたエンティティとリレーションの説明を受けて、次のクイズに挑戦してください。
クイズに答えながら、カーディナリティ、オプショナリティの意味を整理してみてください。

クイズ1

社員エンティティと部門エンティティを管理します。
あなたの会社で2つのエンティティを管理する場合、どのようなリレーションになるか考えてください。
ただし、リレーション名は以下のとおりとします。また、過去の所属履歴まで管理する必要はありません。

  • 社員は部門に所属する

クイズ1の解答例

1.社員は1つの部門にしか所属できない

  • 社員はどの部門にも所属しないという状態が考えられる
  • 新規社員オカレンスの登録をする際、その社員が所属する部門はまだ決まっている必要はない
  • 1つの部門には複数の社員が所属する可能性がある
  • 社員が1人も所属していない部門は存在し得る
  • 新規部門オカレンスの登録をする際の制約は特にない

2.社員は必ず1つの部門に所属する必要がある

  • 新規社員オカレンスの登録をする際は、その社員が所属する部門が1つ決まっている必要がある
    かつ、その部門はすでに登録されているか同時に登録する必要がある
  • 1つの部門には複数の社員が所属する可能性がある
  • 新規部門オカレンスの登銀をする際の制約はない
  • 社員が1人も所属していない部門が存在し得る

3.社員は必ず1つの部門に所属する

  • 新規社員オカレンスの登録をする際には、その社員が所属する部門がすでに決まっている必要がある
    かつ、その部門はすでに登録されているか、対象の部門オカレンスがまだ存在しないのであれば、同時に登録する必要がある
  • どの部門にも、最低1人以上の社員が所属する必要がある
  • 1つの部門には複数の社員が所属する可能性がある
  • 新規部門オカレンスの登録をする際は、同時に最低1人の社員オカレンスを登録する必要がある

4.社員は複数の部門に所属する可能性がある

  • 社員はどの部門にも所属しない状態もあり得る
  • 新規社員オカレンスの登録をする際には、その社員が所属する部門はまだ決まっている必要はない
  • 部門には、複数の社員が所属する可能性がある
  • 社員が1人も所属していない部門は存在し得る
  • 新規部門オカレンスの登銀をする際の制約はない

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

解説トレーナー

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

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

■認定・受賞

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

Page Top