Entity-Relationship-Diagramme

Ein Entity-Relationship-Modell (oder ER-Modell) beschreibt miteinander verbundene Dinge von Interesse in einem spezifischen Wissensbereich. Ein grundlegendes ER-Modell besteht aus Entitätstypen (die die interessierenden Dinge klassifizieren) und spezifiziert Beziehungen, die zwischen Entitäten (Instanzen dieser Entitätstypen) bestehen können Wikipedia.

Beachten Sie, dass Praktiker des ER-Modellierens fast immer auf Entitätstypen einfach als Entitäten verweisen. Zum Beispiel würde der CUSTOMER Entität typ einfach als CUSTOMER Entität bezeichnet. So häufig ist das, dass es unklug wäre, etwas anderes zu tun, aber technisch gesehen ist eine Entität eine abstrakte Instanz eines Entitätstyps, und das ist es, was ein ER-Diagramm zeigt - abstrakte Instanzen und die Beziehungen zwischen ihnen. Aus diesem Grund werden Entitäten immer mit Singularnomen benannt.

Mermaid kann ER-Diagramme rendern.

Code:

Entitätsnamen werden oft in Großbuchstaben geschrieben, obwohl es keinen anerkannten Standard dafür gibt und es in Mermaid nicht erforderlich ist.

Beziehungen zwischen Entitäten werden durch Linien dargestellt, deren Endmarker die Kardinalität repräsentieren. Mermaid verwendet die beliebteste Krallenfuß-Notation. Der Krallenfuß vermittelt intuitiv die Möglichkeit vieler Instanzen der Entität, zu der er verbindet.

ER-Diagramme können für verschiedene Zwecke verwendet werden, von abstrakten logischen Modellen ohne Implementierungsdetails bis hin zu physischen Modellen relationaler Datenbanktabellen. Es kann nützlich sein, Attributdefinitionen in ER-Diagrammen einzuschließen, um das Verständnis für den Zweck und die Bedeutung von Entitäten zu unterstützen. Diese müssen nicht unbedingt umfassend sein; oft reicht eine kleine Teilmenge von Attributen aus. Mermaid ermöglicht es, sie in Bezug auf ihren Typ und Namen zu definieren.

Code:

Beim Einschließen von Attributen in ER-Diagramme müssen Sie entscheiden, ob Sie Primärschlüssel als Attribute einfügen möchten. Dies hängt wahrscheinlich davon ab, wie genau Sie versuchen, relationale Tabellenstrukturen darzustellen. Wenn Ihr Diagramm ein logisches Modell ist, das nicht implizieren soll, dass eine relationale Implementierung vorliegt, ist es besser, diese wegzulassen, da die assoziativen Beziehungen bereits die Weise vermitteln, in der Entitäten assoziiert sind. Zum Beispiel kann eine JSON-Datenstruktur eine Eins-zu-viele-Beziehung implementieren, ohne dass Primärschlüssel-Eigenschaften erforderlich sind, indem sie Arrays verwendet. Ähnlich kann eine objektorientierte Programmiersprache Zeiger oder Referenzen auf Sammlungen verwenden. Selbst bei Modellen, die für relationale Implementierungen gedacht sind, könnten Sie entscheiden, dass die Einbeziehung von Primärschlüsselattributen Informationen dupliziert, die bereits durch die Beziehungen dargestellt werden, und nicht zur Bedeutung der Entitäten beiträgt. Letztendlich liegt die Entscheidung bei Ihnen.

Syntax

Entitäten und Beziehungen

Die Mermaid-Syntax für ER-Diagramme ist mit PlantUML kompatibel, mit einer Erweiterung zur Kennzeichnung der Beziehung. Jeder Satz besteht aus den folgenden Teilen:

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

Wo:

• first-entity ist der Name einer Entität. Namen müssen mit einem alphabetischen Zeichen oder einem Unterstrich (ab v10.5.0+) beginnen und können auch Ziffern und Bindestriche enthalten.
• relationship beschreibt die Art und Weise, wie beide Entitäten miteinander in Beziehung stehen. Siehe unten.
• second-entity ist der Name der anderen Entität.
• relationship-label beschreibt die Beziehung aus der Perspektive der ersten Entität.

Zum Beispiel:

    PROPERTY ||--|{ ROOM : contains

Diese Aussage kann als eine Immobilie enthält ein oder mehrere Zimmer, und ein Zimmer ist Teil einer und nur einer Immobilie gelesen werden. Sie können sehen, dass das Label hier aus der Perspektive der ersten Entität stammt: eine Immobilie enthält ein Zimmer, aber ein Zimmer enthält keine Immobilie. Wenn man die Perspektive der zweiten Entität betrachtet, ist das äquivalente Label in der Regel sehr leicht abzuleiten. (Einige ER-Diagramme kennzeichnen Beziehungen aus beiden Perspektiven, aber dies wird hier nicht unterstützt und ist normalerweise überflüssig).

Nur der first-entity Teil einer Aussage ist obligatorisch. Dies macht es möglich, eine Entität ohne Beziehungen darzustellen, was während der iterativen Erstellung von Diagrammen nützlich sein kann. Wenn andere Teile einer Aussage angegeben werden, sind alle Teile obligatorisch.

Beziehungssyntax

Der relationship Teil jeder Aussage kann in drei Unterkomponenten zerlegt werden:

• die Kardinalität der ersten Entität im Hinblick auf die zweite
• ob die Beziehung der 'Kind'-Entität Identität verleiht
• die Kardinalität der zweiten Entität im Hinblick auf die erste

Kardinalität ist eine Eigenschaft, die beschreibt, wie viele Elemente einer anderen Entität mit der betreffenden Entität in Beziehung stehen können. Im obigen Beispiel kann eine PROPERTY ein oder mehrere ROOM Instanzen zugeordnet haben, während ein ROOM nur mit einer PROPERTY verbunden sein kann. In jedem Kardinalitätsmarker gibt es zwei Zeichen. Das äußerste Zeichen repräsentiert einen Maximalwert, und das innerste Zeichen repräsentiert einen Minimalwert. Die Tabelle unten fasst mögliche Kardinalitäten zusammen.

Wert (links)	Wert (rechts)	Bedeutung
|o	o|	Null oder eins
||	||	Genau eins
}o	o{	Null oder mehr (keine obere Grenze)
}|	|{	Eins oder mehr (keine obere Grenze)

Alias

Wert (links)	Wert (rechts)	Alias für
eins oder null	eins oder null	Null oder eins
null oder eins	null oder eins	Null oder eins
eins oder mehr	eins oder mehr	Eins oder mehr
eins oder viele	eins oder viele	Eins oder mehr
viele(1)	viele(1)	Eins oder mehr
1+	1+	Eins oder mehr
null oder mehr	null oder mehr	Null oder mehr
null oder viele	null oder viele	Null oder mehr
viele(0)	viele(0)	Null oder mehr
0+	0+	Null oder mehr
genau eins	genau eins	Genau eins
1	1	Genau eins

Identifizierung

Beziehungen können entweder als identifizierend oder nicht identifizierend klassifiziert werden, und diese werden entsprechend mit durchgehenden oder gestrichelten Linien dargestellt. Dies ist relevant, wenn eine der betroffenen Entitäten ohne die andere nicht unabhängig existieren kann. Zum Beispiel könnte eine Firma, die Personen versichert, um Autos zu fahren, möglicherweise Daten zu NAMED-DRIVERs speichern müssen. Bei der Modellierung könnte man zunächst beobachten, dass ein CAR von vielen PERSON Instanzen gefahren werden kann und eine PERSON viele CARs fahren kann - beide Entitäten können unabhängig voneinander existieren, also ist dies eine nicht identifizierende Beziehung, die wir in Mermaid so angeben könnten: PERSON }|..|{ CAR : "driver". Beachten Sie die zwei Punkte in der Mitte der Beziehung, die dazu führen werden, dass eine gestrichelte Linie zwischen den beiden Entitäten gezeichnet wird. Wenn jedoch diese viele-zu-viele-Beziehung in zwei Eins-zu-viele-Beziehungen aufgelöst wird, stellen wir fest, dass ein NAMED-DRIVER nicht ohne sowohl eine PERSON als auch ein CAR existieren kann - die Beziehungen werden identifizierend und würden mit Bindestrichen angegeben, was zu einer durchgehenden Linie führt.

Alias

Wert	Alias für
zu	identifizierend
optional zu	nicht identifizierend

Attribute

Attribute können für Entitäten definiert werden, indem der Entitätsname gefolgt von einem Block mit mehreren type name Paaren angegeben wird, wobei ein Block durch eine öffnende { und eine schließende } begrenzt ist. Die Attribute werden innerhalb der Entitätsboxen dargestellt. Zum Beispiel:

Code:

Die type-Werte müssen mit einem alphabetischen Zeichen beginnen und können Ziffern, Bindestriche, Unterstriche, Klammern und eckige Klammern enthalten. Die name-Werte folgen einem ähnlichen Format wie type, dürfen jedoch auch mit einem Sternchen beginnen, um anzuzeigen, dass ein Attribut ein Primärschlüssel ist. Abgesehen davon gibt es keine Einschränkungen, und es gibt kein implizites Set von gültigen Datentypen.

Entitätsnamen-Alias (v10.5.0+)

Ein Alias kann einer Entität mit eckigen Klammern hinzugefügt werden. Wenn angegeben, wird der Alias im Diagramm anstelle des Entitätsnamens angezeigt.

Code:

Attributschlüssel und Kommentare

Attribute können auch einen key oder Kommentar definiert haben. Schlüssel können PK, FK oder UK für Primärschlüssel, Fremdschlüssel oder eindeutigen Schlüssel sein. Um mehrere Schlüsselbeschränkungen für ein einzelnes Attribut anzugeben, trennen Sie sie durch ein Komma (z.B. PK, FK). Ein comment wird durch doppelte Anführungszeichen am Ende eines Attributs definiert. Kommentare selbst dürfen keine doppelten Anführungszeichen enthalten.

Code:

Andere Dinge

• Wenn Sie möchten, dass das Beziehungsetikett mehr als ein Wort umfasst, müssen Sie doppelte Anführungszeichen um den Satz verwenden.
• Wenn Sie überhaupt kein Etikett für eine Beziehung möchten, müssen Sie einen leeren doppelten Anführungszeichen-String verwenden.
• (v11.1.0+) Wenn Sie ein mehrzeiliges Etikett für eine Beziehung wünschen, verwenden Sie <br /> zwischen den beiden Zeilen ("erste Zeile<br />zweite Zeile").

Stil

Konfigurationsoptionen

Für einfache Farbänderungen:

Name	Wird als
fill	Hintergrundfarbe einer Entität oder eines Attributs
stroke	Rahmenfarbe einer Entität oder eines Attributs, Linienfarbe einer Beziehung

Verwendete Klassen

Die folgenden CSS-Klassenauswahlen sind für eine reichere Gestaltung verfügbar:

Selektor	Beschreibung
.er.attributeBoxEven	Die Box, die Attribute in geraden Reihen enthält
.er.attributeBoxOdd	Die Box, die Attribute in ungeraden Reihen enthält
.er.entityBox	Die Box, die eine Entität darstellt
.er.entityLabel	Das Etikett für eine Entität
.er.relationshipLabel	Das Etikett für eine Beziehung
.er.relationshipLabelBox	Die Box, die ein Beziehungsetikett umgibt
.er.relationshipLine	Die Linie, die eine Beziehung zwischen Entitäten darstellt