Transcript エンティティ・リレーションシップ・モデル

エンティティ・リレーションシップ・
モデル
池本、梶取
最初に
エンティティ・リレーション
シップ・モデル
セマンティック・オブジェク
ト・モデル
データベース処理システムの要件を解釈し、記述し、
文書化する為に使用出来る
要件の全体的な構造を示 よりユーザに近く、詳細な
す為の構成が提供される
仕様を記述出来る
↓
↓
トップダウンのデータベー ボトムアップのデータベー
ス設計に有用
ス設計に有用
3.1 エンティティ・リレーションシップ・
モデルの定義
• 1976年 Peter Chenにより紹介された。
（このモデルの基本について）
• 単一の標準化されたE-Rモデルは存在しない
が、変形バージョンの基盤となっている共通
の構成要素群は存在。
• 今から見ていくのはその共通の構成要素に
ついて！
3.1.1 エンティティ
• ユーザの業務環境において識別でき、システ
ムのユーザによって重要性の高い事物。
• エンティティ・クラス（＝同一タイプのエンティ
ティの集合）にグループ化することが出来る。
• エンティティとエンティティ・クラスはしばしば
同義で使用される。
• エンティティには多くのインスタンスがある。
（インスタンスについては次！）
3.1.1 クラスとインスタンスの違い
エンティティ・
クラス
エンティティ・
インスタンス
定義
あるものの一般形・
一般的記述
ある特定の
エンティティの表現
例
学生
学籍番号14050166の学生
3.1.2 アトリビュート（プロパティ）
• エンティティの特性を記述。
• 1つのエンティティ・クラス内の全インスタンス
が同じアトリビュートの組を持っている。
• アトリビュートは1つの値でも多値でも良い。
• 複合アトリビュート
ex.住所
3.1.3 識別子
• エンティティ・インスタンスの識別子
– 1つ以上のインスタンス自身を識別する為のアト
リビュート
• 識別子がユニークな場合・・・
識別子の値により正確にただ1つのエンティ
ティ・インスタンスが識別される。
• 識別子がユニークでない場合・・・
ユニークなインスタンスを見つける為にデータ
を追加しなくてはならない。
エンティティ・クラス
「顧客」
アトリビュート
「顧客番号」
「顧客名」
「住所（番地）」
「県」
「市区町村」
複合アトリビュート
「郵便番号」
「電話番号」
エンティティ・インスタンス
12345
Ajax Manufacturing
・
・
・
3.1.4 リレーションシップ（関連性）
• リレーションシップによってエンティティをお互いに
関連付ける。
• 2種類のリレーションシップが存在する。
リレーションシップ・
クラス
エンティティ・クラス間の
対応付け
リレーションシップ・
インスタンス
エンティティ・インスタン
ス間の対応付け
• リレーションシップはアトリビュートを持てる。
次数（P.64）
• リレーションシップの次数・・・
リレーションシップ内のエンティティの数
– 図3-2参照
• E-Rモデルのリレーションシップの次数はいく
つでもよい。しかし、実際の適用例では次数2
のリレーションシップのみ使用されている。
• 次数2のリレーションシップ
＝バイナリー・リレーションシップ
3種類のバイナリー・
リレーションシップ（P.64～65）
• 1:1（1対1）
• 1:N（1対多）
• N:M（多対多）
バイナリー・リレーションシップ
＝HAS-A リレーションシップ
エンティティの最大個
数に対する制約！
※ M・・・最大濃度
リレーションシップの一方において許される
エンティティの個数の最大値
エンティティ・リレーションシップ図
（E-R図）（P.66）
•
•
•
•
•
エンティティ・クラス･･･四角形
エンティティの名前･･･四角形の内部 エンティティ名
リレーションシップ･･･菱形
リレーションシップの最大濃度･･･菱形内部
リレーションシップの名前･･･菱形の近く
– 確固たる標準はない
– 図3-3(d)
最大濃度
「リレーション名」
最小濃度（P.66）
• 最小濃度
– エンティティがリレーション中に存在しなければい
けないかどうかを示す。
• エンティティが必ず存在しなければいけない
場合･･･リレーションシップの線を横切る短い
線。
• エンティティが存在してもしなくても良い場
合･･･楕円
• 図3-4
再帰的リレーションシップ（P.66）
• 単一クラスのエンティティ間のリレーションシッ
プ
• 図3-5
学生
1:N
「～と同室である」
E-R図におけるアトリビュート(P.67）
• E-R図にアトリビュートを示すには2通りある。
– アトリビュートを楕円の中に示し、それが属するエ
ンティティ、又はリレーションに線を引く。
（図3-6.a）
– 別個に示す。（図3-6.b）
・・・アトリビュートの数が多くなり、煩雑になる場
合
弱エンティティ
• 特別なタイプのエンティティ。
• データベース中に存在するか否かが他のエ
ンティティの存在に依存するエンティティ。
• ex.従業員と扶養家族（図3-7.a）。
ID依存エンティティ（P.69）
• 弱エンティティの特別なタイプ（図3-7.b）。
• 他のエンティティに論理的に依存するエンティ
ティ。
• ID依存エンティティは必ず複数のアトリビュー
トからなる識別子を持ち、その中に論理的に
依存しているエンティティの識別子を含んで
いる。
• ex.製品－バージョン、教科書－版
サブタイプ・エンティティ
• 省略可能なアトリビュートをもつエンティティ
• サブタイプ・エンティティはスーパータイプ・エ
ンティティに属していなければならない。
• ∈･･･サブタイプであることを示す記号
スーパータイプ
∈
サブタイプ
∈
サブタイプ
∈
サブタイプ
一般化階層、継承（P.70）
• 一般化階層
– サブタイプを一般化したもの
– このようなタイプのリレーションシップをIS-Aリ
レーションシップと呼ぶこともある。
• 継承
– サブタイプのエンティティが、スーパータイプ・エン
ティティ・クラスのアトリビュートを引き継ぐこと。
図3-9（P.72）
従業員
「トラック割当」
トラック
∈
技術者
1:1
:N
「サービス－提供者」
「技術者－技術」
1
サービス
「顧客－サービス」
顧客
1:N
「～に紹介される」
N:
N:M
料金
技術者資格
1
資格
「資格－技術者」
3.1.7 ビジネス・ルールの文書化
• データベース・スキーマ
– テーブル
E-Rモデルから情報獲得ないし類推が出来る
– リレーション
– ドメイン
– ビジネス・ルール・・・モデルから情報を得られない為、
データ・モデリングの段階において
E-Rモデルに追加されることがある。
• この時点ではルールを文書化し、システム要
件の一部とすることが重要！
3.1.8 エンティティ・リレーションシッ
プ・モデルとCASEツール
• 多くの一般的CASE製品がE-R図を作成する
ツールを装備している。
↓
E-Rモデルを使用してデータ・モデルを作成
することが容易に！