Skip to content

Entity Relationship Diagrams#

1. Entity Relationship Diagrams#

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

ERモデリングの実践者は、ほとんどの場合、エンティティタイプを単にエンティティと呼んでいることに注意してください。 たとえば、CUSTOMERエンティティタイプは、単にCUSTOMERエンティティと呼ばれます。 これは非常に一般的であるため、他のことを行うことはお勧めできませんが、技術的には、エンティティはエンティティタイプの抽象インスタンスであり、これはER図が示すものです-抽象インスタンスとそれらの間の関係。 これが、エンティティが常に単数名詞を使用して命名される理由です。

mermaidはER図をレンダリングできます


erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ LINE-ITEM : contains
    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ LINE-ITEM : contains
    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses

2. Entity Relationship Diagrams#

エンティティ名は大文字で表記されることがよくありますが、これに関する承認された標準はなく、Mermaidでは必須ではありません。

エンティティ間の関係は、カーディナリティを表す終了マーカーの付いた線で表されます。 mermaidは最も人気のあるカラスの足の表記法を使用しています。 crow's foot は、それが接続するエンティティの多くのインスタンスの可能性を直感的に伝えます。

ERダイアグラムは、実装の詳細がない抽象的な論理モデルから、リレーショナルデータベーステーブルの物理モデルまで、さまざまな目的に使用できます。 エンティティの目的と意味を理解しやすくするために、ER図に属性定義を含めると便利な場合があります。 これらは必ずしも網羅的である必要はありません。 多くの場合、属性の小さなサブセットで十分です。 mermaidは、タイプと名前の観点から定義することができます。

erDiagram
    CUSTOMER ||--o{ ORDER : places
    CUSTOMER {
        string name
        string custNumber
        string sector
    }
    ORDER ||--|{ LINE-ITEM : contains
    ORDER {
        int orderNumber
        string deliveryAddress
    }
    LINE-ITEM {
        string productCode
        int quantity
        float pricePerUnit
    }
erDiagram
    CUSTOMER ||--o{ ORDER : places
    CUSTOMER {
        string name
        string custNumber
        string sector
    }
    ORDER ||--|{ LINE-ITEM : contains
    ORDER {
        int orderNumber
        string deliveryAddress
    }
    LINE-ITEM {
        string productCode
        int quantity
        float pricePerUnit
    }

ERダイアグラムに属性を含める場合は、属性として外部キーを含めるかどうかを決定する必要があります。 これはおそらく、リレーショナルテーブル構造をどれだけ厳密に表現しようとしているかによって異なります。 ダイアグラムがリレーショナル実装を意味することを意図していない論理モデルである場合、関連関係はエンティティの関連付け方法をすでに伝えているため、これらを除外することをお勧めします。 たとえば、JSONデータ構造は、配列を使用して、外部キープロパティを必要とせずに1対多の関係を実装できます。 同様に、オブジェクト指向プログラミング言語は、コレクションへのポインターまたは参照を使用する場合があります。 リレーショナル実装を目的としたモデルの場合でも、外部キー属性を含めると、リレーションシップによってすでに示されている情報が複製され、エンティティに意味が追加されないと判断する場合があります。 最終的に、それはあなたの選択です。

3. Syntax#

Entities and Relationships ER図のマーメイド構文はPlantUMLと互換性があり、関係にラベルを付けるための拡張機能があります。 各ステートメントは、次の部分で構成されています。

    <first-entity> [<relationship> <second-entity> : <relationship-label>]

Where: * first-entity はエンティティの名前です。 名前は英字で始まる必要があり、数字、ハイフン、およびアンダースコアを含めることもできます。 * relationship は、両方のエンティティが相互に関連する方法を表します。 下記参照。 * second-entity は、他のエンティティの名前です。 * relationship-label は、最初のエンティティの観点から関係を記述します。

For example:

    PROPERTY ||--|{ ROOM : contains
このステートメントは、プロパティに1つ以上の部屋が含まれ、部屋が1つだけのプロパティの一部であると読むことができます。 ここでのラベルは、最初のエンティティの観点からのものであることがわかります。プロパティには部屋が含まれていますが、部屋にはプロパティが含まれていません。 2番目のエンティティの観点から検討すると、同等のラベルは通常、非常に簡単に推測できます。 (一部のERダイアグラムは、両方の観点から関係にラベルを付けますが、これはここではサポートされておらず、通常は不要です)。

ステートメントの <font color='Pink'>first-entity</font>の部分のみが必須です。 これにより、関係のないエンティティを表示できるようになります。これは、ダイアグラムを繰り返し作成するときに役立ちます。 ステートメントの他の部分が指定されている場合、すべての部分が必須です。

4. Relationship Syntax#

各ステートメントの <font color='Pink'>relationship</font> の部分は、次の3つのサブコンポーネントに分類できます。

  • 2番目のエンティティに対する最初のエンティティのcardinality
  • relationship が「子」エンティティにアイデンティティを与えるかどうか
  • 最初のエンティティに対する2番目のエンティティのcardinality

カーディナリティは、別のエンティティの要素の数を問題のエンティティに関連付けることができることを表すプロパティです。 上記の例では、<font color = 'Pink'> PROPERTY </ font> に1つ以上の <fontcolor = 'Pink'> ROOM </ font> インスタンスを関連付けることができますが、<font color = 'Pink' > ROOM </ font> は、1つの <font color = 'Pink'> PROPERTY </ font> にのみ関連付けることができます。 各カーディナリティマーカーには2つの文字があります。 最も外側の文字は最大値を表し、最も内側の文字は最小値を表します。 次の表は、考えられるカーディナリティをまとめたものです。

Value (left) Value (right) Meaning
|o o| Zero or one
|| || Exactly one
}o o{ Zero or more (no upper limit)
}| |{ One or more (no upper limit)

5. Identification#

関係は、識別または非識別のいずれかに分類でき、これらはそれぞれ実線または破線で表示されます。 これは、問題のエンティティの1つが他のエンティティなしでは独立して存在できない場合に関連します。 たとえば、人々に車の運転を保証する会社は、 <font color = 'Pink'> NAMED-DRIVE </ font>にデータを保存する必要があるかもしれません。

In modelling this we might start out by observing that a <font color='Pink'>CAR</font> can be driven by many <font color='Pink'>PERSON</font> instances, and a <font color='Pink'>PERSON</font> can drive many <font color='Pink'>CAR</font> - both entities can exist without the other, so this is a non-identifying relationship that we might specify in Mermaid as: <font color='Pink'>PERSON }|..|{ CAR : "driver"</font>.

これをモデル化する際に、 <font color = 'Pink'> CAR </ font>が多くの <font color = 'Pink'> PERSON </ font>インスタンスによって駆動されることを観察することから始めるかもしれません。 また、 <font color = 'Pink'> PERSON </ font>は多くの <font color = 'Pink'> CAR </ font>を駆動できます。どちらのエンティティも他方なしで存在できるため、これは非 Mermaidで次のように指定する可能性のある関係を識別します: <font color = 'Pink'> PERSON} | .. | {CAR:" driver "</ font>

関係の中央にある2つのドットに注意してください。これにより、2つのエンティティ間に破線が描画されます。 しかし、この多対多の関係が2つの1対多の関係に解決されると、NAMED-DRIVERは <font color = 'Pink'> PERSON </ font>の両方なしでは存在できないことがわかります。 <font color = 'Pink'> CAR </ font>-関係は識別可能になり、ハイフンを使用して指定されます。これは実線に変換されます。

    CAR ||--o{ NAMED-DRIVER : allows
    PERSON ||--o{ NAMED-DRIVER : is

6-1. Attributes#

エンティティ名の後に複数のタイプ名のペアを含むブロックを指定することにより、エンティティの属性を定義できます。ブロックは、開始{と終了}で区切られます。 例えば:

erDiagram
    CAR ||--o{ NAMED-DRIVER : allows
    CAR {
        string registrationNumber
        string make
        string model
    }
    PERSON ||--o{ NAMED-DRIVER : is
    PERSON {
        string firstName
        string lastName
        int age
    }
erDiagram
    CAR ||--o{ NAMED-DRIVER : allows
    CAR {
        string registrationNumber
        string make
        string model
    }
    PERSON ||--o{ NAMED-DRIVER : is
    PERSON {
        string firstName
        string lastName
        int age
    }

6-2. Entity Relationship Diagrams Attributes#

属性はエンティティボックス内にレンダリングされます。

erDiagram
    CAR ||--o{ NAMED-DRIVER : allows
    CAR {
        string registrationNumber
        string make
        string model
    }
    PERSON ||--o{ NAMED-DRIVER : is
    PERSON {
        string firstName
        string lastName
        int age
    }

<font color = 'Pink'> type </ font><font color = 'Pink'> name </ font>の値はアルファベット文字で始まる必要があり、数字、ハイフン、またはアンダースコアを含めることができます。 それ以外に制限はなく、有効なデータ型の暗黙のセットはありません。

Other Things * 関係ラベルを複数の単語にする場合は、フレーズを二重引用符で囲む必要があります * リレーションシップにラベルがまったく必要ない場合は、空の二重引用符で囲まれた文字列を使用する必要があります

8Styling#

Config options#

簡単な色のカスタマイズの場合:

Name Used as
fill エンティティまたは属性の背景色
stroke エンティティまたは属性の境界線の色、関係の線の色

Classes used#

次のCSSクラスセレクターは、よりリッチなスタイリングに使用できます。

Selector Description
.er.attributeBoxEven 偶数行の属性を含むボックス
.er.attributeBoxOdd 奇数行の属性を含むボックス
.er.entityBox エンティティを表すボックス
.er.entityLabel エンティティのラベル
.er.relationshipLabel 関係のラベル
.er.relationshipLabelBox 関係ラベルを囲むボックス
.er.relationshipLine エンティティ間の関係を表す線