あるエンティティの

属性を持つ関係

エンティティは、独立した存在が可能なもので、一意に識別できるものと定義できます。 実体とは、ある領域の複雑さを抽象化したものです。

実体とは、物理的にも論理的にも存在するものです。

エンティティとは、物理的または論理的に存在するもので、家や車などの物理的な物体（物理的に存在する）、家の販売や車のサービスなどのイベント、顧客との取引や注文などの概念（概念として論理的に存在する）などがあります。 一般的にはエンティティという言葉が使われていますが、チェン氏によれば、本当はエンティティとエンティティ・タイプを区別しなければならないそうです。 エンティティタイプとはカテゴリーのことです。 エンティティとは、厳密に言えば、あるエンティティタイプのインスタンスです。 あるエンティティタイプのインスタンスは、通常、多数存在します。 エンティティタイプという言葉はやや煩雑なので、多くの人はこの言葉の同義語としてエンティティという言葉を使う傾向があります

エンティティは名詞と考えることができます。 例：コンピュータ、従業員、歌、数学の定理など。

関係は、エンティティがお互いにどのように関係しているかを表します。 関係は動詞として考えることができ、2つ以上の名詞を結びつけます。

上述のモデルの言語的側面は、自然言語構造を模倣した宣言型データベース問い合わせ言語ERROLに利用されている。 ERROLのセマンティクスと実装は、RRA（reshaped relational algebra）と呼ばれる関係代数に基づいており、エンティティ-リレーションシップモデルに適応し、その言語的側面を捉えている。

弱いエンティティを除くすべてのエンティティは、一意に識別できる最小限の属性セットを持たなければならず、これを一意/主キーとして使用することができます。

エンティティ-リレーションシップ図では、単一のエンティティや単一のリレーションを示すのではなく、エンティティセット（同じエンティティタイプのすべてのエンティティ）とリレーションシップセット（同じリレーションタイプのすべてのリレーション）を示します。 例：特定の曲はエンティティであり、データベース内のすべての曲の集合はエンティティセットです。子供と彼のランチの間の食べられた関係は単一の関係であり、データベース内のそのようなすべての子供とランチの関係の集合は関係セットです。

Mapping natural languageEdit

Chen氏は、自然言語の記述をER図にマッピングするために、次のような「経験則」を提案した。 “ピーター・チェン著「英語、中国語、そしてER図」。

td

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

関係、役割、基数 編集

Chenのオリジナルの論文では、関係とその役割の例を挙げています。

ある人は結婚(関係)において夫の役割を果たし、別の人は(同じ)結婚において妻の役割を果たします。 これらの言葉は名詞です。

陳氏の用語は、それ以前の思想にも適用されています。

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

役割の命名

is the owner ofやis owned byなどのフレーズで役割を名付けることも一般的になっています。 この場合の正しい名詞は owner と possession です。 したがって、person が所有者の役割を果たし、car が所有物の役割を果たすのではなく、person plays the role of, is the owner of などとなります。

名詞の使用は、意味モデルから物理的な実装を生成する際に直接的な利点があります。ある人が車と 2 つの関係を持っている場合、owner_person や driver_person など、すぐに意味のある名前を生成することができます。 Chen は look-across cardinalities について説明しました。

Merise、Elmasri & Navathe などでは、役割や最小および最大のカーディナリティの両方について、同一側を優先しています。

Dulleaらは「UMLで使われているような “look across “表記は、次数が2以上の関係に課される参加制約のセマンティクスを効果的に表現していない」と述べています。

Feinererは「UMLのアソシエーションに使われているようなlook-acrossセマンティクスで運用すると問題が生じる。 Hartmann はこの状況を調査し、異なる変換がどのように、そしてなぜ失敗するのかを示している。” とあります。 また、”As we will see on the next few pages, the look-across interpretation introduces some difficulties that prevent the extension of simple mechanism from binary to n-ary associations.” (ただし、言及されている “reduction “は、2つの図3.4と3.5が実際には同じであるため、偽物です)。”

同じ一対多の関係を表現する様々な方法です。 いずれの場合も、図は人と出生地の関係を示しています。各人は1つの場所で生まれていなければなりませんが、各場所には0人以上の人が生まれている可能性があります。

カラスの足の記法を使って示された2つの関連するエンティティ。 この例では、ArtistとSongの間に任意の関係が示されています。Songのエンティティに最も近いシンボルは「0、1、または多」を表し、一方、Songには「1つだけ」のArtistがあります。

Chenのエンティティ-リレーションシップモデリングの表記法では、長方形はエンティティセットを表し、ダイヤモンドは第一級オブジェクトに適した関係を表します。

属性は楕円として描かれ、正確に1つのエンティティまたはリレーションシップ・セットに線で接続されます。

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

• 二重線は参加制約、全体性または射影性を示します。すなわち、エンティティセットのすべてのエンティティはリレーションシップセットの少なくとも1つのリレーションシップに参加しなければなりません。
• エンティティセットからリレーションシップセットへの矢印は、キー制約、すなわち、注入性：エンティティセットの各エンティティは、リレーションシップセットの最大1つのリレーションシップに参加できることを示します。
• 下線付きの属性名は、それがキーであることを示します。

属性は、図が煩雑になるため、省略されることが多いです。他のダイアグラム手法では、エンティティセットのために描かれた長方形の中に、エンティティの属性が記載されることが多いです。

関連するダイアグラムの規約テクニック。

• バッハマン記法
• バーカー記法
• EXPRESS
• IDEF1X
• カラスの足記法（マーティン記法とも）
• （min, max)表記
• UMLクラス図
• Merise
• オブジェクト・ロール・モデリング

Crow’s foot notationEdit

Crow’s foot notation, その始まりはGordon Everestの論文(1976年)に遡り、Barker’s notationやStructured Systems Analysis and Design Method(SSADM)、情報技術工学などで使用されています。 Crow’s foot diagramは、エンティティをボックスで表し、関係をボックス間の線で表す。

Crow’s foot notationは、コンサルタント会社のCACIで使われていました。

この記法では、リレーションシップは属性を持つことができません。 例えば、アーティストがいつどこで曲を演奏したかを把握する必要がある場合、新しいエンティティ「パフォーマンス」が導入され（時間と場所を反映した属性を持つ）、アーティストと曲の関係は、パフォーマンスを介した間接的な関係になります（artist-performs-performance、performance-features-song）。

カーディナリティを表現するために、3つのシンボルが使われています。

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

これらのシンボルはペアで使われ、エンティティが関係において持ちうる4種類のカーディナリティを表しています。 内側のコンポーネントは最小を、外側のコンポーネントは最大を表します。

• リングとダッシュ → 最小0、最大1（オプション）
• ダッシュとダッシュ → 最小1、最大1（必須）
• リングとカラスの足 → 最小0。 最大多数（オプション）
• ダッシュとカラスの足 → 最小1、最大多数（必須）

Model usability issuesEdit

モデル化されたデータベースを使用していると、ユーザーは、返された結果がクエリ作成者が想定した結果とは別の意味を持つ、よく知られた2つの問題に遭遇することがあります。

1つ目は「ファントラップ」です。 これは、一対多の関係で複数のテーブルにリンクしている (マスター) テーブルで発生します。 この問題は、実体関係図でモデルを描いたときに、リンクされたテーブルがマスター テーブルから「扇形に広がる」ように見えることから、その名前が付けられました。 このタイプのモデルは、データウェアハウスで使用されるスタースキーマに似ています。 マスターテーブル上で標準的なSQLを使用して集約の合計を計算しようとすると、予期しない（正しくない）結果が生じることがあります。 解決策は、モデルを調整するか、SQLを調整するかです。 この問題は主に意思決定支援システムのデータベースで発生し、そのようなシステムに問い合わせるソフトウェアには、この問題を処理するための特定のメソッドが含まれていることがあります。 キャズム トラップは、モデルがエンティティ タイプ間の関係の存在を示唆しているにもかかわらず、特定のエンティティの発生の間に経路が存在しない場合に発生します。 例えば、建物には1つ以上の部屋があり、その部屋には0つ以上のコンピュータが入っているとします。 人は、モデルを照会して建物内のすべてのコンピュータを見ることができると期待するでしょう。 しかし、現在Roomに割り当てられていないコンピュータ(修理中や他の場所にあるため)は、リストに表示されません。 建物内のすべてのコンピュータを把握するには、BuildingとComputersの間に別のリレーションが必要です。 この最後のモデリングの問題は、現実の世界に存在するすべての関係をモデルに取り込むことができなかった結果である。 詳細は、「エンティティ-リレーションシップ・モデリング2」を参照してください。