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

実体関係モデル(またはER モデル) は、特定の知識領域における相互に関連する関心対象を記述します。基本的な ER モデルは、関心対象を分類するエンティティ タイプで構成され、エンティティ (それらのエンティティ タイプのインスタンス) 間に存在できる関係を指定します。

ソフトウェア工学において、ERモデルは一般的に、ビジネスプロセスを実行するために企業が覚えておく必要のある事柄を表現するために形成されます。その結果、ERモデルは抽象データモデルとなり、^[1]データベース（通常はリレーショナルデータベース）に実装できるデータまたは情報構造を定義します。

実体関係モデリングは、ピーター・チェンによってデータベースと設計のために開発され、1976年の論文^[2]で発表されました。このアイデアのバリエーションはそれ以前にも存在していました。^[3]今日では、学生にデータベース構造の基礎を教えるためによく使用されています。一部のERモデルは、一般化-特殊化関係によって接続されたスーパーエンティティとサブタイプエンティティを示し、^{[4] ERモデルはドメイン固有の}オントロジーを指定するためにも使用できます。

ER モデルは通常、ビジネス分野のプロセスによって作成され、必要とされるデータを定義および記述するための体系的な分析から生まれます。通常、ER モデルは、プロセス自体ではなく、ビジネス プロセスによって監視および指示されるエンティティとイベントの記録を表します。通常、ER モデルは、エンティティ間の関連性と依存関係を表す線 (リレーションシップ)で接続されたボックス (エンティティ) としてグラフィカルに描画されます。また、言葉で表現することもできます。たとえば、1 つの建物は 0 個以上のアパートに分割できますが、1 つのアパートは 1 つの建物にしか配置できません。

エンティティは、リレーションシップだけでなく、「主キー」と呼ばれる識別子を含む追加のプロパティ (属性) によっても定義できます。エンティティとリレーションシップだけでなく属性も表すために作成された図は、エンティティ - リレーションシップ モデルではなく、エンティティ - 属性 - リレーションシップ図と呼ばれることがあります。

ER モデルは通常、データベースとして実装されます。単純なリレーショナル データベースの実装では、テーブルの各行はエンティティ タイプの 1 つのインスタンスを表し、テーブル内の各フィールドは属性タイプを表します。リレーショナル データベースでは、エンティティ間の関係は、あるエンティティの主キーを別のエンティティのテーブルにポインターまたは「外部キー」として保存することによって実装されます。

ER/データ モデルは、2 つまたは 3 つの抽象化レベルで構築されるのが一般的です。以下に示す概念的、論理的、物理的な階層は、他の種類の仕様で使用され、ソフトウェア エンジニアリングに対する3 つのスキーマ アプローチとは異なります。

概念データモデル

これは、最も粒度の細かい詳細を含みながらも、モデル セット内に含まれる内容の全体的な範囲を確立する、最高レベルの ER モデルです。概念 ER モデルは通常、組織でよく使用されるマスター参照データ エンティティを定義します。企業全体の概念 ER モデルを開発することは、組織のデータ アーキテクチャのドキュメント化をサポートするのに役立ちます。

概念 ER モデルは、1 つ以上の論理データ モデル(以下を参照)の基盤として使用できます。概念 ER モデルの目的は、論理 ER モデルのセット間でマスター データエンティティの構造メタデータの共通性を確立することです。概念データ モデルは、データ モデル統合の基盤として、ER モデル間の共通関係を形成するために使用できます。

論理データモデル

論理 ER モデルには概念 ER モデルは必要ありません。特に、論理 ER モデルの範囲に個別の情報システムの開発のみが含まれる場合はそうです。論理 ER モデルには、概念 ER モデルよりも詳細な情報が含まれています。マスター データ エンティティに加えて、運用データ エンティティとトランザクション データ エンティティが定義されています。各データ エンティティの詳細が開発され、これらのデータ エンティティ間の関係が確立されます。ただし、論理 ER モデルは、実装できる特定のデータベース管理システムとは独立して開発されます。

物理データモデル

各論理 ER モデルから 1 つ以上の物理 ER モデルが開発される場合があります。物理 ER モデルは通常、データベースとしてインスタンス化されるように開発されます。したがって、各物理 ER モデルには、データベースを作成するのに十分な詳細が含まれている必要があり、各データベース管理システムは多少異なるため、各物理 ER モデルはテクノロジに依存します。

物理モデルは通常、データベース管理システムの構造メタデータ内で、データベース テーブルなどのリレーショナル データベース オブジェクト、一意キーインデックスなどのデータベース インデックス、外部キー制約や共通性制約などのデータベース制約としてインスタンス化されます。ER モデルは通常、リレーショナル データベース オブジェクトの変更を設計したり、データベースの構造メタデータを維持したりするためにも使用されます。

情報システム設計の最初の段階では、要件分析中にこれらのモデルを使用して、情報のニーズやデータベースに保存する情報の種類を記述します。データ モデリング手法を使用すると、特定の関心領域のオントロジー(つまり、使用される用語とその関係の概要と分類)を記述できます。データベースに基づく情報システムの設計の場合、概念データ モデルは、後の段階 (通常は論理設計と呼ばれる) で、リレーショナル モデルなどの論理データ モデルにマッピングされます。これは、次に、物理設計中に物理モデルにマッピングされます。これらのフェーズの両方を「物理設計」と呼ぶこともあります。

エンティティは、一意に識別でき、データを保存できる独立した存在として定義できます。^[5]エンティティは、ドメインの複雑さからの抽象化です。エンティティについて話すとき、通常は現実世界の他の側面と区別できる現実世界のいくつかの側面について話します。^[6]

エンティティとは、物理的または論理的に存在するものです。エンティティは、家や車などの物理的なオブジェクト (物理的に存在します)、家の販売や車のサービスなどのイベント、または顧客取引や注文などの概念 (論理的に、つまり概念として存在します) である場合があります。エンティティという用語は最も一般的に使用されていますが、Chen に従って、エンティティとエンティティ タイプを区別する必要があります。エンティティ タイプはカテゴリです。厳密に言えば、エンティティは、特定のエンティティ タイプのインスタンスです。通常、エンティティ タイプのインスタンスは多数あります。エンティティ タイプという用語はやや扱いにくいため、ほとんどの人はエンティティという用語を同義語として使用する傾向があります。

実体は名詞として考えることができます。^[7]例としては、コンピューター、従業員、歌、数学の定理などが挙げられます。

関係は、エンティティが互いにどのように関連しているかを捉えます。関係は、2つ以上の名詞を結びつける動詞と考えることができます。 ^[7]例としては、会社とコンピューターの所有関係、従業員と部門の監督関係、アーティストと曲の演奏関係、数学者と推測の証明関係などが挙げられます。

上で説明したモデルの言語的側面は、自然言語構造を模倣する宣言型データベースクエリ言語ERROLで使用されます。ERROL のセマンティクスと実装は、エンティティ リレーションシップ モデルに適応し、その言語的側面を捉える リレーショナル代数である再形成リレーショナル代数 (RRA) に基づいています。

エンティティとリレーションシップはどちらも属性を持つことができます。たとえば、従業員エンティティには社会保障番号(SSN) 属性があり、証明されたリレーションシップには日付属性がある場合があります。

弱いエンティティを除くすべてのエンティティには、一意のキーまたは主キーとして使用できる、一意に識別する属性の最小限のセットが必要です。

エンティティ リレーションシップ ダイアグラム (ERD) は、単一のエンティティやリレーションの単一のインスタンスを表示するのではなく、エンティティ セット (同じエンティティ タイプのすべてのエンティティ) とリレーションシップ セット (同じリレーションシップ タイプのすべてのリレーションシップ) を表示します。たとえば、特定の曲はエンティティ、データベース内のすべての曲のコレクションはエンティティ セット、子供とランチの「食べた」リレーションシップは単一のリレーションシップ、データベース内のそのような子供とランチのリレーションシップのセットはリレーションシップ セットです。つまり、リレーションシップ セットは数学のリレーションシップに対応し、リレーションシップはリレーションシップのメンバーに対応します。

関係セットに対する特定の基数制約も示される場合があります。

物理ビューは、データが実際にどのように保存されるかを示します。

チェンの元の論文では、関係とその役割の例が示されています。彼は、「結婚」という関係と、「夫」と「妻」という 2 つの役割について説明しています。

ある人が結婚（関係）において夫の役割を果たし、別の人が（同じ）結婚において妻の役割を果たします。これらの単語は名詞です。

チェンの用語は、以前のアイデアにも適用されています。一部の図の線、矢印、カラスの足跡は、チェンの関係図よりも、以前のバッハマン図に由来しています。

Chen のモデルのもう 1 つの一般的な拡張は、関係と役割を動詞またはフレーズとして「命名」することです。

また、役割を「 の所有者である」や「 に所有されている」などのフレーズで命名することも一般的になってきました。この場合の正しい名詞は、所有者と所有物です。したがって、「の役割を果たす」 、 「 の所有者である」など ではなく、 「人は所有者の役割を果たし、車は所有物の役割を果たします」となります。

名詞を使用すると、セマンティックモデルから物理的な実装を生成するときに直接的な利点があります。人が車と2つの関係を持っている場合、 owner_personやdriver_personなど、すぐに意味がわかる名前を生成することができます。^[9]

元の仕様を変更すると、有益な場合があります。Chen は、ルックアクロス カーディナリティについて説明しました。余談ですが、 Oracle Designer で使用されるBarker-Ellis表記法では、最小カーディナリティ (オプションに類似) とロールには same-side を使用しますが、最大カーディナリティ (カラスの足跡) にはルックアクロスを使用します。^{[説明が必要]}

Merise、Elmasri、Navatheらによる研究では、役割と最小および最大の基数の両方において同じ側が好まれることが示されており、 ^{[10] [11] [12]}、研究者（Feinerer、Dulleaら）は、これが2以上のn項関係に適用された場合により首尾一貫していることを示している。^{[13] [14]}

Dullea らは次のように述べています。「UMLで使用されるような「全体を見る」表記法は、次数が 2 進数よりも高い関係に課せられる参加制約のセマンティクスを効果的に表現しません。」

Feinerer 氏は次のように語っています。「UML の関連付けに使用されるルックアクロス セマンティクスで操作すると、問題が発生します。Hartmann ^{[15] は}この状況を調査し、さまざまな変換が失敗する理由と方法を示しています。」(ただし、ここで言及されている「削減」は、2 つの図 3.4 と 3.5 は実際には同じであるため、偽りです)。また、「次の数ページで説明するように、ルックアクロス解釈は、単純なメカニズムを 2 項関連付けから n 項関連付けに拡張することを妨げるいくつかの困難をもたらします。」

Chen のエンティティ リレーションシップ モデリング表記では、長方形を使用してエンティティ セットを表し、ダイヤモンドを使用してファーストクラス オブジェクトに適したリレーションシップを表します。これらのオブジェクトは、独自の属性とリレーションシップを持つことができます。エンティティ セットがリレーションシップ セットに参加している場合、それらは線で接続されます。

属性は楕円として描画され、1 つのエンティティまたは関係セットに線で接続されます。

カーディナリティ制約は次のように表現されます。

• 二重線は参加制約、全体性、または全射性を示します。エンティティ セット内のすべてのエンティティは、関係セット内の少なくとも 1 つの関係に参加する必要があります。
• エンティティ セットからリレーションシップ セットへの矢印は、キー制約、つまり、単射性を示します。エンティティ セットの各エンティティは、リレーションシップ セット内の最大 1 つのリレーションシップに参加できます。
• 太い線は両方、つまり全単射性を示します。つまり、エンティティ セット内の各エンティティは、正確に 1 つの関係に関係しています。
• 下線付きの属性名はその属性がキーであることを示します。つまり、この属性を持つ 2 つの異なるエンティティまたは関係では、常にこの属性の値が異なります。

属性は、ダイアグラムが乱雑になる可能性があるため、省略されることがよくあります。他のダイアグラム手法では、エンティティ セット用に描画された四角形内にエンティティ属性がリストされることがよくあります。

• バックマン表記
• バーカー記法
• 急行
• IDEF1X
• § クロウズフット記法（マーティン記法ともいう）
• 1974 年のJean-Raymond Abrialの (最小、最大) 表記
• UML クラス図
• メリセ
• オブジェクトロールモデリング

^{クロウズフット記法は、ゴードン・エベレスト(1976)の論文[16]}に遡り、バーカー記法、構造化シ​​ステム分析設計法(SSADM)、情報技術工学で使用されています。クロウズフット図では、エンティティをボックスで表し、関係をボックス間の線で表します。これらの線の端にあるさまざまな形状は、関係の相対的な濃度を表します。

クロウズフット記法は1978年にICLで使用されており、^[17]コンサルタント会社CACIでも使用されていました。CACIのコンサルタントの多くは（リチャード・バーカーを含む）ICL出身で、その後オラクルUKに移り、そこでオラクルのCASEツールの初期バージョンを開発し、より広いユーザーにこの記法を紹介しました。

この表記法では、関係に属性を持たせることはできません。必要な場合、関係は独自のエンティティに昇格されます。たとえば、アーティストが曲を演奏した場所と時間を把握する必要がある場合、新しいエンティティ「パフォーマンス」が導入され (時間と場所を反映する属性を持つ)、アーティストと曲の関係はパフォーマンスを介した間接的な関係になります (アーティスト - 演奏 - パフォーマンス、パフォーマンス - 特徴 - 曲)。

基数を表すために 3 つの記号が使用されます。

• リングは「ゼロ」を表します
• ダッシュは「1」を表します
• カラスの足跡は「多くの」または「無限」を表します

これらの記号はペアで使用され、関係においてエンティティが持つ可能性のある 4 種類の基数を表します。表記の内側のコンポーネントは最小値を表し、外側のコンポーネントは最大値を表します。

• リングとダッシュ→最小ゼロ、最大 1 (オプション)
• ダッシュとダッシュ→最小 1、最大 1 (必須)
• 指輪とカラスの足跡→最小値ゼロ、最大値多数（オプション）
• ダッシュとカラスの足跡→最小 1 つ、最大複数 (必須)

モデル化されたデータベースのユーザーは、返される結果がクエリ作成者の想定と異なるという 2 つのよく知られた問題に遭遇する可能性があります。これらはファン トラップとキャズム トラップと呼ばれ、エンティティ リレーションシップ モデル (ER モデル) の設計時に適切に処理されないと、不正確なクエリ結果につながる可能性があります。

ファン トラップとキャズム トラップはどちらも、ER モデルが技術的に正しいだけでなく、表現するように設計された現実世界の関係を完全に正確に反映していることの重要性を強調しています。設計プロセスの早い段階でこれらのトラップを特定して解決すると、特にビジネス インテリジェンスや意思決定サポートを目的とした複雑なデータベースでは、後で重大な問題が発生するのを防ぐのに役立ちます。

最初の問題はファン トラップです。これは、(マスター) テーブルが 1 対多の関係で複数のテーブルにリンクされている場合に発生します。この問題の名前は、モデルをエンティティ リレーションシップ図に描画したときの外観に由来しています。リンクされたテーブルがマスター テーブルから「ファン アウト」します。このタイプのモデルは、データ ウェアハウスで一般的な設計であるスター スキーマに似ています。マスター テーブルに基づいて標準の SQL クエリを使用して集計の合計を計算しようとすると、関係の構造化方法が原因で、予期しない結果や誤った結果になることがよくあります。SQL は各関係を個別に処理するため、計算ミスが発生し、二重カウントやその他の不正確さが発生する可能性があります。この問題は、意思決定支援システムで特によく発生します。この問題を軽減するには、データ モデルまたはSQL クエリ自体を調整する必要があります。意思決定支援用に設計された一部のデータベース クエリ ソフトウェアには、ファン トラップを検出して対処するための組み込みメソッドが含まれています。

2 番目の問題はキャズム トラップです。キャズム トラップは、モデルがエンティティ タイプ間の関係性の存在を示唆しているものの、これらのエンティティ間の経路が不完全であったり、特定のインスタンスで欠落している場合に発生します。

たとえば、建物に 1 つ以上の部屋があり、これらの部屋に 0 台以上のコンピューターがあるデータベースを想像してください。モデルをクエリして、建物内のすべてのコンピューターを一覧表示することが予想されるかもしれません。ただし、コンピューターが一時的に部屋に割り当てられていない場合 (修理中または別の場所に保管されている可能性があります)、そのコンピューターはクエリ結果に含まれません。クエリは、現在部屋に割り当てられているコンピューターのみを返し、建物内のすべてのコンピューターは返しません。これはモデルの欠陥を反映しており、建物内にはあるが部屋にはないコンピューターを考慮していないためです。これを解決するには、建物とコンピューターを直接リンクする追加の関係が必要になります。

意味モデルは概念のモデルであり、「プラットフォームに依存しないモデル」と呼ばれることもある。意味モデルは内包的モデルである。少なくともカルナップ以来、次のことはよく知られている。^[18]

「...概念の完全な意味は、その内包と拡張という 2 つの側面から構成されます。最初の部分は、概念の世界全体への概念の埋め込み、つまり他の概念とのすべての関係の全体性で構成されます。2 番目の部分は、概念の参照意味、つまり現実世界または可能世界における概念の対応物を確立します。」

拡張モデルは、特定の方法論またはテクノロジの要素にマッピングされるモデルであり、したがって「プラットフォーム固有のモデル」です。UML 仕様では、クラス モデル内の関連付けは拡張的であると明示的に述べられています。これは、以前の候補である「セマンティック モデリング言語」のいずれかによって提供されるものに加えて、仕様によって提供される広範な追加の「装飾」を考慮すると、実際に自明です。「データ モデリング表記法としての UML、パート 2」

ER モデリングの父であるピーター・チェンは、彼の画期的な論文で次のように述べています。

「実体関係モデルは、現実世界が実体と関係性で構成されているというより自然な見方を採用しています。このモデルには、現実世界に関する重要な意味情報の一部が組み込まれています。」^[2]

1976 年のオリジナルの論文で、Chen はエンティティ リレーションシップ図とレコード モデリング手法を明確に対比しています。

「データ構造図はレコードの構成を表現したものであり、エンティティと関係を正確に表現したものではありません。」

他の著者もチェンのプログラムを支持している: ^{[19] [20] [21] [22] [23]}

チェンは、古代ギリシャの哲学者プラトンとアリストテレスの時代からの哲学的伝統に一致している。^{[24]プラトン自身は、知識を不変の}形態（つまり、多くの種類の事物や特性の原型または抽象的な表現）とそれらの相互関係 の把握と関連付けている。

• ER モデルは主に概念的なものであり、知識の領域内の述語を表現するオントロジーです。
• ER モデルは、リレーショナル データベース構造を表現するためによく使用されます (Codd と Date 以降)。ただし、他の種類のデータ構造 (データ ウェアハウスやドキュメント ストアなど) を表現するためにはあまり使用されません。
• 一部の ER モデル表記には、スーパーサブタイプの関係や関係間の排他性を示す記号が含まれていますが、含まれていないものもあります。
• ER モデルは、エンティティのライフ ヒストリー (イベントに応じてエンティティの属性や関係が時間の経過とともにどのように変化するか) を示しません。多くのシステムでは、このような状態の変化は重要であり、明示的な仕様を必要とするほどです。
• 状態変化を表現するためにERモデリングを拡張した研究者^{[誰? ]}もおり、このアプローチは元の著者も支持している。^[25]一例としてはアンカーモデリングがある。
• その他には、状態遷移図やその他のプロセス モデリング手法を使用して、状態の変化を個別にモデル化します。
• UMLが提供する14種類のダイアグラムを含む、システムの他の側面をモデル化するために、他の多くの種類のダイアグラムが描かれます。^[26]
• 現在、ER モデリングが役立つ場合でも、多くの人が同様の種類のモデル (特に OO プログラミングのクラス図やリレーショナルデータベース管理システムのデータ モデル) をサポートするツールを使用しているため、ER モデリングは一般的ではありません。これらのツールの一部は、図からコードを生成したり、コードから図をリバース エンジニアリングしたりできます。
• ^{BrodieとLiu [27]}は、調査で、Fortune 100企業10社のサンプルの中で、エンティティ・リレーションシップ・モデリングの例を1つも見つけることができませんでした。BadiaとLemire ^[28]は、この使用不足の原因はガイダンスの欠如だけでなく、データ統合のサポート不足などの利点の欠如にあると考えています。
• 拡張エンティティ リレーションシップ モデル(EER モデリング) では、ER モデリングにはないが、 is-a関係など、オブジェクト指向設計に密接に関連するいくつかの概念が導入されています。
• 時系列データベースのモデリングでは、数多くのER拡張が検討されてきた。^[29]同様に、ERモデルは多次元データベース（ OLAPアプリケーションで使用される）には適していないことが判明した。この分野ではまだ支配的な概念モデルは現れていないが、一般的にはOLAPキューブ（この分野ではデータキューブとも呼ばれる）の概念を中心に展開されている。 ^[30]

• 連想実体 – 関係理論および実体関係理論における用語
• コンセプトマップ – 概念間の関係を示す図
• データベース設計 – データベース内でデータを保持する方法の設計
• データ構造図 – エンティティ、それらの関係、およびそれらに課せられた制約を含む特定の種類のデータ モデルの視覚的表現フォールバックとしてウィキデータの説明を表示するページ
• 強化されたエンティティ・リレーションシップ・モデル - データ・モデル
• エンタープライズアーキテクチャフレームワーク – 企業のアーキテクチャを定義するフレーム
• エンティティ データ モデル – オープンソースのオブジェクト リレーショナル マッピング フレームワークリダイレクト先の簡単な説明を表示するページ
• 値の範囲構造図
• データ モデリング ツールの比較 – 注目すべきデータ モデリング ツールの比較
• オントロジー – 概念化の仕様
• オブジェクトロールモデリング - プログラミングテクニックリダイレクト先の簡単な説明を表示するページ
• 3つのスキーマアプローチ - 情報システム構築へのアプローチリダイレクト先の簡単な説明を表示するページ
• 構造化エンティティ関係モデル
• スキーマに依存しないデータベース – データバンクの種類フォールバックとしてウィキデータの説明を表示するページ

• Chen, Peter (2002)。「エンティティ リレーションシップ モデリング: 歴史的出来事、将来の傾向、そして学んだ教訓」(PDF)。ソフトウェアのパイオニア。Springer-Verlag。pp. 296–310。ISBN 978-3-540-43081-0。
• バーカー、リチャード (1990)。CASE メソッド: エンティティ リレーションシップ モデリング。Addison- Wesley。ISBN 978-0201416961。
• バーカー、リチャード (1990)。CASE メソッド: タスクと成果物。Addison- Wesley。ISBN 978-0201416978。
• マニラ, ヘイキ;ライハ、カリ・ジョウコ (1992)。リレーショナル データベースの設計。アディソン・ウェスリー。ISBN 978-0201565232。
• Thalheim, Bernhard (2000)。エンティティ・リレーションシップ・モデリング: データベース技術の基礎。Springer。ISBN 978-3-540-65470-4。
• Bagui, Sikha; Earp, Richard Walsh (2022).エンティティ関係図を使用したデータベース設計。Auerbach Publications。ISBN 978-1-032-01718-1。

ウィキメディア・コモンズには、エンティティ・リレーションシップ・モデルに関連するメディアがあります。

• 「エンティティ リレーションシップ モデル: データの統一されたビューに向けて」
• エンティティ関係モデリング
• 論理データ構造 (LDS) - Tony Drewry による入門。
• カラスの足跡記法
• データ モデルの種類と命名方法 (David Hay によるプレゼンテーション)