Loading article…
エンティティ関係モデル（またはERモデル）は、特定の知識領域における相互に関連する対象を記述するものです。基本的なERモデルは、対象を分類するエンティティ型と、エンティティ（それらのエンティティ型のインスタンス）間に存在する関係を規定する要素で構成されます。
ソフトウェアエンジニアリングでは、ERモデルは、ビジネスプロセスを実行するために企業が覚えておく必要がある事柄を表すために一般的に形成されます。その結果、ERモデルは抽象データモデル[ 1 ]となり、データベース、通常はリレーショナルデータベースに実装できるデータまたは情報構造を定義します。
エンティティ関係モデリングは、データベースと設計のためにピーター・チェンによって開発され、1976年の論文で発表されました[ 2 ]。このアイデアのバリエーションはそれ以前から存在していました[ 3 ] 。今日では、データベース構造の基本を学生に教えるためによく使用されています。一部のERモデルは、汎化-特殊化関係で接続されたスーパーエンティティとサブタイプエンティティを示しており[ 4 ] 、ERモデルはドメイン固有のオントロジーを指定するためにも使用できます。
ERモデルは通常、ビジネス領域におけるプロセスによって生成され、必要とされるデータを定義および記述するための体系的な分析から生まれます。一般的に、ERモデルはプロセス自体ではなく、ビジネスプロセスによって監視および指示されるエンティティとイベントの記録を表します。通常、ERモデルは、エンティティ間の関連性と依存関係を表す線（関係）で接続されたボックス（エンティティ）としてグラフィカルな形式で描画されます。また、たとえば、1つの建物は0個以上のアパートに分割できますが、1つのアパートは1つの建物にしか存在できません、のように、言葉で表現することもできます。[ 5 ]
エンティティは、関係だけでなく、追加のプロパティ（属性）によっても定義できます。これには、「主キー」と呼ばれる識別子が含まれます。エンティティと関係だけでなく属性も表現するために作成された図は、エンティティ-関係モデルではなく、エンティティ-属性-関係図と呼ばれることがあります。[ 6 ]
ERモデルは通常、データベースとして実装されます。単純なリレーショナルデータベースの実装では、テーブルの各行はエンティティ型のインスタンスを1つ表し、テーブルの各列は属性型を表します。リレーショナルデータベースでは、エンティティ間の関係は、あるエンティティの主キーを別のエンティティのテーブルにポインタ（外部キー）として格納することによって実現されます。
ERモデルやデータモデルは、2つまたは3つの抽象度レベルで構築するのが一般的です。以下に示す概念-論理-物理の階層構造は、他の種類の仕様記述で用いられるものであり、ソフトウェアエンジニアリングにおける3スキーマアプローチとは異なります。
情報システム設計の最初の段階では、要件分析の際にこれらのモデルを使用して、情報ニーズ、つまりデータベースに格納される情報の種類を記述します。データモデリング手法は、特定の関心領域に関するあらゆるオントロジー（つまり、使用される用語とその関係の概要と分類）を記述するために使用できます。データベースに基づく情報システムの設計の場合、概念データモデルは、後の段階（通常は論理設計と呼ばれる）で、リレーショナルモデルなどの論理データモデルにマッピングされます。これは、物理設計の際に物理モデルにマッピングされます。これらの2つの段階は、まとめて「物理設計」と呼ばれることもあります。
エンティティとは、独立した存在が可能で、一意に識別でき、データを保存できるものと定義できます。[ 7 ]エンティティは、ドメインの複雑さからの抽象化です。エンティティについて話すとき、通常は現実世界の他の側面と区別できる現実世界の何らかの側面について話します。[ 8 ]
エンティティとは、物理的または論理的に存在するものです。エンティティは、家や車などの物理的な物体（物理的に存在する）、住宅販売や自動車整備などのイベント、顧客の取引や注文などの概念（論理的に、つまり概念として存在する）のいずれかです。エンティティという用語は最も一般的に使用されていますが、Chen に従って、エンティティとエンティティタイプは区別されるべきです。エンティティタイプはカテゴリです。厳密に言えば、エンティティは特定のエンティティタイプのインスタンスです。通常、エンティティタイプのインスタンスは多数存在します。エンティティタイプという用語はやや冗長なため、ほとんどの人はエンティティという用語を同義語として使用する傾向があります。
実体は名詞と考えることができます。[ 9 ]例としては、コンピュータ、従業員、歌、数学の定理などがあります。
関係とは、エンティティ同士がどのように関連しているかを捉えるものです。関係は、2つ以上の名詞を結びつける動詞と考えることができます。 [ 9 ]例としては、会社とコンピュータの間の「所有」関係、従業員と部署の間の「監督」関係、アーティストと楽曲の間の「演奏」関係、数学者と予想の間の「証明」関係などがあります。
上述のモデルの言語的側面は、自然言語の構造を模倣した宣言型データベースクエリ言語ERROLで使用されています。ERROLのセマンティクスと実装は、エンティティ関係モデルに適合し、その言語的側面を捉える関係代数である再構成関係代数（RRA）に基づいています。
エンティティとリレーションシップの両方に属性を持たせることができます。たとえば、従業員エンティティには社会保障番号（SSN）属性があり、証明済みのリレーションシップには日付属性がある場合があります。
弱いエンティティを除くすべてのエンティティは、一意の識別属性の最小限のセットを持ち、それを一意のキー／主キーとして使用できる必要があります。
エンティティ関係図（ERD）は、単一のエンティティや単一の関係インスタンスを示すものではありません。むしろ、エンティティセット（同じエンティティタイプのすべてのエンティティ）と関係セット（同じ関係タイプのすべての関係）を示します。例えば、特定の曲はエンティティであり、データベース内のすべての曲の集合はエンティティセットです。子供と昼食の間の「食べた」という関係は単一の関係であり、データベース内のすべてのそのような子供と昼食の関係の集合は関係セットです。言い換えれば、関係セットは数学における関係に対応し、関係は関係の要素に対応します。
関係セットに対する特定の基数制約も示される場合がある。
物理的なビューは、データが実際にどのように保存されているかを示します。
陳氏の原著論文では、人間関係とその役割の例が挙げられている。彼は「結婚」という関係と、その二つの役割である「夫」と「妻」について述べている。
結婚（関係）において、ある人が夫の役割を担い、別の人が妻の役割を担う。これらは名詞である。
陳の用語は、それ以前の概念にも適用されてきた。いくつかの図に見られる線、矢印、カラスの足跡などは、陳の関係図よりも、むしろ初期のバッハマン図に由来する部分が大きい。
チェンのモデルに対するもう一つの一般的な拡張は、関係性や役割を動詞や句として「命名」することである。
また、 「～の所有者である」「～によって所有されている」といった表現で役割を表すことも一般的になっています。この場合、正しい名詞は「所有者」と「所有物」です。したがって、「人が所有者の役割を担う」「車が所有物の役割を担う」と言うべきであり、「人が～の役割を担う」 「～の所有者である」などと言うべきではありません。
名詞を使うことは、意味モデルから物理的な実装を生成する際に直接的な利点があります。人が車と2つの関係を持っている場合、所有者_人や運転者_人のような、すぐに意味がわかる名前を生成することができます。[ 11 ]
元の仕様への変更は有益な場合があります。Chen はルックアクロス カーディナリティについて説明しました。余談ですが、 Oracle Designer で使用されるBarker–Ellis表記法では、最小カーディナリティ (オプション性に類似) とロールには同じ側を使用しますが、最大カーディナリティ (カラスの足) にはルックアクロスを使用します。
Merise 、Elmasri & Navathe らによる研究では、役割と最小および最大カーディナリティの両方において同じ側を好む傾向があることが示されており、[ 12 ] [ 13 ] [ 14 ] また、研究者 (Feinerer、Dullea ら) は、これが2より大きい n 項関係に適用された場合により一貫性があることを示している。 [ 15 ] [ 16 ]
Dulleaらは、「 UMLで使用されるような『ルックアクロス』表記法は、二項関係よりも高い次数を持つ関係に課される参加制約の意味を効果的に表現するものではない」と述べている。
ファイネラーは次のように述べています。「UML の関連付けに使用されているルックアクロス意味論に基づいて操作すると問題が発生します。ハートマン[ 17 ]はこの状況を調査し、さまざまな変換がどのように、そしてなぜ失敗するのかを示しています。」（ただし、言及されている「削減」は、2 つの図 3.4 と 3.5 が実際には同じであるため、偽りです）また、「次の数ページで見るように、ルックアクロス解釈は、単純なメカニズムをバイナリ関連付けから n 項関連付けに拡張することを妨げるいくつかの困難をもたらします。」
Chenのエンティティ関係モデリング表記法では、エンティティ集合を長方形で、第一級オブジェクトに適した関係をひし形で表します。第一級オブジェクトは、独自の属性と関係を持つことができます。エンティティ集合が関係集合に参加する場合、それらは線で結ばれます。
属性は楕円形で描かれ、線で正確に1つのエンティティまたは関係セットに接続されます。
基数制約は次のように表現されます。
属性は図を煩雑にする可能性があるため、省略されることが多い。他の図解技法では、エンティティセットを表すために描かれた四角形の中に、エンティティの属性を列挙することが多い。
クローフット記法は、ゴードン・エベレストによる論文（1976年） [ 18 ]に始まり、バーカー記法、構造化システム分析設計法（SSADM）、および情報技術工学で使用されています。クローフット図では、エンティティはボックスとして、関係はボックス間の線として表されます。これらの線の端にある異なる形状は、関係の相対的なカーディナリティを表します。
クロウズフット記法は1978年にICLで使用され[ 19 ]、コンサルティング会社CACIでも使用されました。CACIのコンサルタントの多く（リチャード・バーカーを含む）はICL出身で、その後Oracle UKに移り、そこでOracleのCASEツールの初期バージョンを開発し、この記法をより多くの人々に紹介しました。
この表記法では、関係に属性を持たせることはできません。必要に応じて、関係は独立したエンティティとして扱われます。例えば、アーティストがいつどこで曲を演奏したかを記録する必要がある場合は、「パフォーマンス」という新しいエンティティが導入され（時間と場所を反映する属性を持つ）、アーティストと曲の関係は、パフォーマンスを介した間接的な関係となります（アーティスト→パフォーマンスを演奏、パフォーマンス→曲をフィーチャー）。
基数を表すために、3つの記号が使用されます。
これらの記号は、関係におけるエンティティが持ちうる4種類のカーディナリティを表すためにペアで使用されます。表記の内側の要素は最小値を、外側の要素は最大値を表します。
モデル化されたデータベースのユーザーは、クエリ作成者が想定した結果と異なる結果が返されるという、よく知られた2つの問題に遭遇する可能性があります。これらは「ファン・トラップ」と「キャズム・トラップ」と呼ばれ、エンティティ関係モデル（ERモデル）の設計時に適切に対処しないと、不正確なクエリ結果につながる可能性があります。
ファン・トラップとキャズム・トラップはどちらも、ERモデルが技術的に正しいだけでなく、それが表現しようとしている現実世界の関係性を完全に正確に反映していることを保証することの重要性を強調しています。設計プロセスの初期段階でこれらのトラップを特定して解決することで、特にビジネスインテリジェンスや意思決定支援を目的とした複雑なデータベースにおいて、後々の重大な問題を回避することができます。
最初の問題はファン・トラップです。これは、（マスター）テーブルが複数のテーブルと一対多の関係でリンクしている場合に発生します。この問題は、エンティティ関係図にモデルを描画した際の視覚的な外観に由来しており、リンクされたテーブルがマスターテーブルから「扇状に」広がっていく様子を表しています。このタイプのモデルは、データウェアハウスでよく見られるスター型スキーマに似ています。マスターテーブルに基づいて標準のSQLクエリを使用して集計の合計を計算しようとすると、関係の構造上、結果が予期せず、しばしば不正確になることがあります。SQLが各関係を個別に扱うため、二重カウントやその他の不正確さが生じる可能性があります。この問題は、意思決定支援システムで特に多く発生します。これを軽減するには、データモデルまたはSQLクエリ自体を調整する必要があります。意思決定支援用に設計されたデータベースクエリソフトウェアの中には、ファン・トラップを検出して対処するための組み込みメソッドを備えているものもあります。
2つ目の問題は、キャズムトラップです。キャズムトラップとは、モデルがエンティティタイプ間の関係の存在を示唆しているにもかかわらず、これらのエンティティ間の経路が不完全であったり、場合によっては欠落している場合に発生します。
例えば、建物に1つ以上の部屋があり、各部屋に0台以上のコンピュータが設置されているデータベースを想像してみてください。このモデルに対してクエリを実行して、建物内のすべてのコンピュータを一覧表示できると期待するかもしれません。しかし、コンピュータが一時的に部屋に割り当てられていない場合（修理中であったり、別の場所に保管されていたりする場合など）、クエリ結果には含まれません。クエリは、現在部屋に割り当てられているコンピュータのみを返し、建物内のすべてのコンピュータを返すわけではありません。これは、建物内には存在するものの、部屋には配置されていないコンピュータを考慮していないため、モデルの欠陥を示しています。この問題を解決するには、建物とコンピュータを直接リンクする追加の関係が必要になります。
意味モデルは概念のモデルであり、「プラットフォーム非依存モデル」と呼ばれることもあります。これは内包モデルです。少なくともカルナップ以来、次のことはよく知られています。[ 20 ]
拡張モデルとは、特定の方法論や技術の要素に対応するモデルであり、したがって「プラットフォーム固有のモデル」である。UML仕様では、クラスモデルにおける関連付けは拡張的であると明示的に述べられており、これは実際、以前の候補となる「意味論的モデリング言語」が提供するものに加えて、仕様が提供する広範な追加「装飾」を考慮すれば自明である。「データモデリング表記法としてのUML、パート2」
ERモデリングの父であるピーター・チェンは、彼の画期的な論文の中で次のように述べている。
チェンは1976年の原著論文で、エンティティ関係図とレコードモデリング手法を明確に対比させている。
他の著者数名もチェンのプログラムを支持しています: [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ]
陳は古代ギリシャの哲学者プラトンやアリストテレスの時代からの哲学的伝統に賛同している。[ 26 ]プラトン自身は知識を不変のイデア（すなわち、多くの種類の事物や性質の原型または抽象的な表現）とそれらの相互関係の把握と結びつけている。