エンティティ・リレーションシップ・モデル
チェン記法を用いたMMORPGのエンティティ-属性関係図

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

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

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

導入

ERモデルは通常、業務分野におけるプロセスによって作成され、必要とされるデータを定義・記述するための体系的な分析から生まれます。典型的には、業務プロセスそのものではなく、業務プロセスによって監視・指示されるエンティティとイベントの記録を表します。ERモデルは通常、エンティティ間の関連性と依存関係を表す線（リレーションシップ）で結ばれたボックス（エンティティ）としてグラフィカルに描画されます。また、例えば「1つの建物は0戸以上のアパートに分割できますが、1つのアパートは1つの建物にしか配置できません」のように、言葉で表現することもできます。[ 5 ]

実体は、関係性だけでなく、追加のプロパティ（属性）によっても定義できます。これには、「主キー」と呼ばれる識別子が含まれます。実体と関係性に加えて属性を表すために作成された図は、実体-関係モデルではなく、実体-属性-関係図と呼ばれることがあります。[ 6 ]

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モデルは通常、リレーショナルデータベースオブジェクトへの変更を設計したり、データベースの構造メタデータを維持したりするためにも使用されます。

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

コンポーネント

関連する2つのエンティティ
属性を持つエンティティ
属性との関係
主キー

実体とは、独立して存在し、一意に識別され、データを保存できるものと定義できる。[ 7 ]実体とは、ある領域の複雑さを抽象化した概念である。実体について語るとき、私たちは通常、現実世界の他の側面と区別できるある側面について語る。[ 8 ]

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

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

関係とは、実体同士の関係性を表すものです。関係は、2つ以上の名詞を結びつける動詞と考えることができます。 [ 9 ]例としては、会社とコンピュータの間の「所有する」関係、従業員と部署の間の「監督する」関係、アーティストと楽曲の間の「演奏する」関係、数学者と推測の間の 「証明する」関係などが挙げられます。

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

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

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

実体関連図（ERD）は、単一の実体や関係の単一のインスタンスを示すのではなく、実体セット（同じ実体タイプのすべての実体）と関係セット（同じ関係タイプのすべての関係）を示します。例えば、特定の曲は実体であり、データベース内のすべての曲の集合は実体セットであり、子供と昼食の間の「食べた」関係は単一の関係であり、データベース内のそのような子供と昼食の関係の集合は関係セットです。言い換えれば、関係セットは数学における関係に対応し、関係は関係のメンバーに対応します。

関係セットに対する特定のカーディナリティ制約も指定できます。

自然言語記述をER図にマッピングするためのガイドライン[ 10 ]
英語の文法構造ER構造
普通名詞エンティティタイプ
固有名詞実在物
他動詞関係の種類
自動詞属性タイプ
形容詞エンティティの属性
副詞関係の属性

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

関係、役割、基数

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

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

チェンの用語は、それ以前の概念にも適用されています。一部の図に見られる線、矢印、カラスの足跡などは、チェンの関係図よりも、むしろ初期のバックマン図に由来しています。

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

役割の命名

また、 「～の所有者です」や「～に所有されています」といった表現で役割を表すことも一般的になっています。この場合の正しい名詞は「所有者」と「所有物」です。つまり、 「～の役割を果たしている」 「～の所有者です」といった表現ではなく、「～が所有者の役割を果たし、車が所有物の役割を果たします」という表現が適切です。

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

基数

元の仕様を変更することは有益となる場合があります。Chen氏は、ルックアクロス・カーディナリティについて説明しました。ちなみに、 Oracle Designerで使用されているBarker-Ellis記法では、最小カーディナリティ（オプショナルに類似）とロールにはsame-sideを使用しますが、最大カーディナリティ（カラスの足跡）にはlook-acrossを使用します。

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

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

ファイネラーは次のように述べています。「UMLの関連付けに使用されているルックアクロスセマンティクスに基づいて操作すると、問題が発生します。ハートマン[ 17 ]はこの状況を調査し、さまざまな変換が失敗する理由と方法を示しています。」（ただし、ここで言及されている「縮小」は誤りであり、2つの図3.4と3.5は実際には同じものです）また、「次の数ページで説明するように、ルックアクロス解釈は、単純なメカニズムを2項関連付けからn項関連付けに拡張することを妨げるいくつかの困難をもたらします。」

同じ1対多の関係を表す様々な方法。いずれの場合も、図は人物と出生地の関係を示しています。各人物は必ず1つの場所で生まれなければなりませんが、各場所には0人以上の人が生まれている可能性があります。
クロウズフット記法を用いて表された2つの関連エンティティ。この例では、アーティストと楽曲の間にはオプションの関係が示されています。楽曲エンティティに最も近い分岐線で構成されたシンボルは「0、1、または複数」を表します。一方、楽曲には「ただ1人の」アーティストがおり、平行線で構成されたシンボルによってそれが強調されています。したがって、前者は「アーティストは0、1、または複数」の楽曲を演奏できる（ことができる）」と解釈されます。

Chenによる実体関連モデリングの表記法では、実体セットを長方形で、第一級オブジェクトに適切な関係をひし形で表します。第一級オブジェクトは、独自の属性と関係を持つことができます。実体セットが関係セットに含まれる場合、それらは線で結ばれます。

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

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

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

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

カラスの足跡記法

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

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

この表記法では、関係は属性を持つことができません。必要に応じて、関係は独立したエンティティへと昇格されます。例えば、アーティストがいつどこで曲を演奏したかを記録する必要がある場合、「パフォーマンス」という新しいエンティティ（時間と場所を示す属性を持つ）が導入され、アーティストと曲の関係は、パフォーマンスを介した間接的な関係（アーティスト-演奏-パフォーマンス、パフォーマンス-フィーチャ-曲）になります。

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

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

これらの記号は、関係において実体が持つ可能性のある4種類の基数を表すためにペアで使用されます。表記の内側の要素は最小値を表し、外側の要素は最大値を表します。

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

モデルのユーザビリティの問題

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

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

ファントラップ

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

キャズムトラップ

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

例えば、建物に1つ以上の部屋があり、これらの部屋に0台以上のコンピューターが配置されているデータベースを想像してみてください。モデルに対してクエリを実行し、建物内のすべてのコンピューターを一覧表示しようとするかもしれません。しかし、コンピューターが一時的に部屋に割り当てられていない場合（修理中や別の場所に保管されている場合など）、クエリ結果には含まれません。クエリは、建物内のすべてのコンピューターではなく、現在部屋に割り当てられているコンピューターのみを返します。これはモデルの欠陥を反映しており、建物内にはあっても部屋にはいないコンピューターを考慮できていません。これを解決するには、建物とコンピューターを直接リンクする追加のリレーションシップが必要になります。

セマンティックモデリングでは

セマンティックモデル

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

「…概念の完全な意味は、その内包と外延という二つの側面から構成される。第一の部分は、概念の世界全体、すなわち他の概念との関係の全体性における概念の埋め込みから構成される。第二の部分は、概念の指示的意味、すなわち現実世界または可能世界における概念の対応関係を確立する。」

拡張モデル

拡張モデルとは、特定の方法論や技術の要素にマッピングされるモデルであり、したがって「プラットフォーム固有のモデル」です。UML仕様では、クラスモデル内の関連は拡張的であると明示的に規定されており、これは、UML仕様が、従来の「セマンティックモデリング言語」の候補で提供されているものに加えて、広範な追加「装飾」を提供していることからも自明です。「データモデリング表記法としてのUML、パート2」

実体関係の起源

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

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

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

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

他にもチェンのプログラムを支持する著者は数人いる: [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ]

哲学的整合性

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

制限事項

参照

参考文献

  1. ^ Bagui & Earp 2022、p. 72、§4.2.1。
  2. ^ a b Chen, Peter (1976年3月). 「エンティティ・リレーションシップ・モデル - データの統一的なビューに向けて」. ACM Transactions on Database Systems . 1 (1): 9– 36. CiteSeerX  10.1.1.523.6679 . doi : 10.1145/320434.320440 . S2CID  52801746 .
  3. ^ APG Brown、「現実世界のシステムのモデリングとそれを表現するスキーマの設計」、Douque and Nijssen（編）、 Data Base Description、North-Holland、1975年、 ISBN 0-7204-2833-5。
  4. ^ 「レッスン 5: スーパータイプとサブタイプ」。docs.microsoft.com 。
  5. ^ “ERモデルの紹介” .オタクのためのオタク。 2015-10-13 。2026 年 1 月 5 日に取得。
  6. ^ 「エンティティ関係図（ERD）とは何か？」 www.visual-paradigm.com . 2026年1月5日閲覧。
  7. ^ Bagui & Earp 2022、p. 73-74、§4.3。
  8. ^ Beynon-Davies, Paul (2004).データベースシステム. 英国ベイジングストーク: Palgrave: Houndmills. ISBN 978-1403916013。
  9. ^ a b Bagui & Earp 2022、p. 112-116、§5.5。
  10. ^「英語、中国語、ER図」ピーター・チェン著
  11. ^ 「パングラマティコン：感情と社会」 2013年1月3日。
  12. ^ユベール・タルデュー、アーノルド・ロシュフェルド、ルネ・コレッティ『La Methode MERISE: Principes et outils』 (ペーパーバック - 1983)
  13. ^ Elmasri、Ramez、B. Shamkant、Navathe、「データベース システムの基礎」、第 3 版、Addison-Wesley、Menlo Park、CA、USA、2000 年。
  14. ^ Atzeni, Paolo; Chu, Wesley; Lu, Hongjun; Ling, Tok Wang; Zhou, Shuigeng (2004-10-27). ER 2004 : 23rd International Conference on Conceptual Modeling, Shanghai, China, November 8-12, 2004. Springer. ISBN 9783540237235。
  15. ^ 「UMLクラス図の形式的処理：構成管理のための効率的な手法 2007」（PDF） 。 2011年10月6日時点のオリジナル（PDF）からアーカイブ。 2011年7月26日閲覧。
  16. ^ 「James Dullea、Il-Yeol Song、Ioanna Lamprou - 実体関連モデリングにおける構造的妥当性の分析 2002」（PDF） 。 2009年4月24日時点のオリジナル（PDF）からアーカイブ。
  17. ^ハートマン、スヴェン。「参加制約とチェンの制約に関する推論」 Wayback Machineに2013年5月10日にアーカイブ。第14回オーストラレーシア・データベース会議議事録-第17巻。オーストラリア・コンピュータ協会、2003年。
  18. ^ G. Everest, 「BASIC DATA STRUCTURE MODELS EXPLAINED WITH A COMMON EXANY」, Computing Systems 1976, Proceedings Fifth Texas Conference on Computing Systems, Austin, TX, 1976 October 18-19, pages 39-46. (Long Beach, CA: IEEE Computer Society Publications Office).
  19. ^「データ分析入門」、ICLトレーニング出版物T2384第2号、1978年11月
  20. ^ 「意味表現における内包的解釈と外延的解釈の役割」。
  21. ^ケント著「データと現実」より ：
    「モデリングに取り組む際に念頭に置いておくべきことの一つは、私たちが「現実」（何らかの人間の活動）の一部を記述しようとしているのか、それともデータ処理活動を記述しようとしているのかということです。」
  22. ^ Abrial著「データセマンティクス」：「データのいわゆる「論理的」な定義と操作は、依然として（時には無意識のうちに）現在コンピュータシステムで利用可能な「物理的な」保存および検索メカニズムの影響を受けています。」
  23. ^ Stamper：「これらはエンティティタイプを記述しているように見えますが、使用されている語彙はデータ処理の用語、つまりフィールド、データ項目、値です。命名規則は、人や物に名前を付ける際に使用する慣習を反映したものではなく、ファイル内のレコードを見つけるための手法を反映しています。」
  24. ^ジャクソンの言葉によれば、「開発者は、システムが関係する現実、つまりシステムの主題となる現実のモデルを作成することから始めます...」
  25. ^ Elmasri、Navathe：「ER モデルの概念は、ユーザーのデータに対する認識に近づくように設計されており、データがコンピューターに保存される方法を説明するものではありません。」
  26. ^ Paolo Rocchi、 Janus-Faced Probability、Springer、2014、p. 62.
  27. ^ P. Chen. 「新たなフロンティアに向けた研究方向性の提案：アクティブ概念モデリング」ER 2006、Lecture Notes in Computer Science 4215巻、1～4ページ。Springer Berlin / Heidelberg、2006年。
  28. ^ Carte, Traci A.、Jasperson, Jon (Sean)、Cornelius, Mark E. (2020)「データモデリングを教える際のERDとUMLの概念の統合」、Journal of Information Systems Education：Vol. 17：Iss. 1、記事9。
  29. ^情報エコシステム時代におけるリレーショナルテクノロジーの力と限界 2016年9月17日アーカイブ、Wayback Machine。On The Move Federated Conferences、2010年。
  30. ^ A. BadiaとD. Lemire.「戦いへの呼びかけ：データベース設計の再考」Citeseerx,
  31. ^ Gregersen, Heidi; Jensen, Christian S. (1999). 「時間的エンティティ・リレーションシップモデル—概観」. IEEE Transactions on Knowledge and Data Engineering . 11 (3): 464– 497. Bibcode : 1999ITKDE..11..464G . CiteSeerX 10.1.1.1.2497 . doi : 10.1109/69.774104 . 
  32. ^ RICCARDO TORLONE (2003). 「概念的多次元モデル」(PDF) . Maurizio Rafanelli (編).多次元データベース：問題と解決策. Idea Group Inc (IGI). ISBN 978-1-59140-053-0。

さらに読む

ウィキメディア コモンズには、エンティティ リレーションシップ モデルに関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=Entity–relationship_model&oldid=1334415993」より取得