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