ER-diagram
Et entitetsrelationsdiagram (kort kaldet ER-diagram) beskriver indbyrdes forbundne interesser i et bestemt vidensområde. Et grundlæggende ER-diagram består af entitetstyper (til at klassificere de interesser, der er tale om) og angiver de relationer, der kan findes mellem entiteter (instanser af disse entitetstyper).,Bemærk, at man i praksis med ER-diagrammer næsten altid blot kalder 'entitetstype' for 'entitet'. F.eks. kaldes 'CUSTOMER-entitetstypen' normalt blot 'CUSTOMER-entiteten'. Denne praksis er meget udbredt, og andre måder frarådes, men teknisk set er en entitet en abstrakt instans af en entitetstype, og det er netop disse abstrakte instanser og deres indbyrdes relationer, ER-diagrammet viser. Det er derfor, entiteter altid navngives med et substantiv i ental.
Kopiér
Integrer
---
title: Order example
---
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
Entitetsnavne skrives normalt med store bogstaver, selvom der ikke findes nogen anerkendt standard for dette, og Mermaids syntaks kræver det heller ikke.
Relationerne mellem entiteter vises med linjer, der har endemærker, som angiver kardinaliteten. Mermaid bruger det mest udbredte kragefodssymbol, som intuitivt viser, at den entitet, det er forbundet til, kan have flere instanser.
ER-diagrammer kan bruges til mange formål, fra abstrakte logiske modeller uden implementeringsdetaljer til fysiske modeller af relationelle databasetabeller. At medtage attributdefinitioner i et ER-diagram hjælper med at forstå entiteternes formål og betydning; disse attributdefinitioner behøver ikke være udtømmende, og ofte er en lille delmængde af attributter tilstrækkelig. Mermaid giver dig mulighed for at definere dem med deres type og navn.
Kopiér
Integrer
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
}
Når du medtager attributter i et ER-diagram, skal du beslutte, om fremmednøgler skal medtages som attributter; dette kan afhænge af, i hvor høj grad du ønsker at repræsentere den relationelle tabelstruktur. Hvis dit diagram er en logisk model, der ikke skal antyde en relationel implementering, er det bedst ikke at medtage disse attributter, da associationsrelationerne allerede formidler, hvordan entiteterne er forbundet. F.eks. kan en JSON-datastruktur implementere en en-til-mange-relation med et array uden fremmednøgleattributter. Tilsvarende kan objektorienterede programmeringssprog bruge pointere eller referencer til samlinger. Selv for modeller, der sigter mod en relationel implementering, kan man mene, at medtagelse af fremmednøgleattributter gentager den information, relationerne viser, og ikke tilfører entiteten betydning.
Syntaks
Entiteter og relationer
Mermaids syntaks for ER-diagrammer er kompatibel med PlantUML og udvider funktionaliteten til at mærke relationer. Hvert udsagn indeholder følgende:
Kopiér
Integrer
<first-entity> [<relationship> <second-entity> : <relationship-label>]
- first-entity er navnet på den første entitet. Navnet understøtter alle Unicode-tegn og kan indeholde mellemrum, hvis det omsluttes af dobbelte anførselstegn.
- relationship beskriver den indbyrdes relation mellem to entiteter.
- second-entity er navnet på den anden entitet.
- relationship-label beskriver relationen set fra den første entitets synsvinkel.
For eksempel:
Kopiér
Integrer
PROPERTY ||--|{ ROOM : contains
Denne erklæring kan forstås som: En ejendom indeholder et eller flere værelser, og et værelse tilhører kun én ejendom. Etiketten her ses fra den første entitets synsvinkel: En ejendom indeholder et værelse, men et værelse indeholder ikke en ejendom. Fra den anden entitets synsvinkel kan den tilsvarende etiket normalt let udledes.
Kun first-entity-delen er obligatorisk. Dette gør det muligt at vise entiteter uden relationer, hvilket er meget nyttigt, når diagrammet bygges op iterativt. Hvis andre dele af udsagnet angives, er alle dele obligatoriske.
Unicode-tekst
Entitetsnavne, relationer og attributter understøtter alle unicode-tekst.
Kopiér
Integrer
erDiagram
"This ❤ Unicode"
Relationssyntaks
Relationsdelen af hvert udsagn kan opdeles i tre underdele:
- Den første entitets kardinalitet i forhold til den anden entitet
- Om relationen giver underentiteten identifikation
- Den anden entitets kardinalitet i forhold til den første entitet
Kardinalitet er en egenskab, der beskriver, hvor mange elementer af en anden entitet der kan knyttes til den pågældende entitet. I eksemplet ovenfor kan en PROPERTY knyttes til en eller flere ROOM-instanser, mens en ROOM kun kan knyttes til én PROPERTY. Hvert kardinalitetsmærke består af to tegn, hvor det yderste tegn repræsenterer maksimumværdien og det inderste tegn minimumværdien. Tabellen nedenfor opsummerer kardinalitetsmulighederne:
| Værdi (venstre) | Værdi (højre) | Betydning |
|---|---|---|
| |o | o| | Nul eller én |
| || | || | Præcis én |
| }o | o{ | Nul eller flere (uden øvre grænse) |
| }| | |{ | Én eller flere (uden øvre grænse) |
| Værdi (venstre) | Værdi (højre) | Betydning |
|---|---|---|
| one or zero | one or zero | Nul eller én |
| zero or one | zero or one | Nul eller én |
| one or more | one or more | Én eller flere |
| one or many | one or many | Én eller flere |
| many(1) | many(1) | Én eller flere |
| 1+ | 1+ | Én eller flere |
| zero or more | zero or more | Nul eller flere |
| zero or many | zero or many | Nul eller flere |
| many(0) | many(0) | Nul eller flere |
| 0+ | 0+ | Nul eller flere |
| only one | only one | Præcis én |
| 1 | 1 | Præcis én |
Identifikation
Relationer kan være identificerende eller ikke-identificerende og rendres henholdsvis med en fuldt optrukket eller stiplet linje. Dette er vigtigt, når én af entiteterne ikke kan eksistere uafhængigt uden den anden. For eksempel kan et forsikringsselskab, der forsikrer folk i at føre biler, have brug for at gemme data om NAMED-DRIVER. Når vi modellerer, kan vi først observere, at en CAR kan føres af mange PERSON, og at en PERSON kan føre mange CAR, og begge kan eksistere uden den anden; derfor er dette en ikke-identificerende relation, som vi i Mermaid kan angive som: PERSON }|..|{ CAR : "driver". Bemærk de to prikker midt i relationen, hvilket resulterer i en stiplet linje mellem de to entiteter. Men når denne mange-til-mange-relation opdeles i to en-til-mange-relationer, observerer vi, at NAMED-DRIVER ikke kan eksistere uden PERSON og CAR. Disse relationer bliver identificerende relationer og vises med en bindestreg, hvilket svarer til en fuldt optrukket linje:
| Værdi | Alias |
|---|---|
| -- | Identificerende |
| .. | Ikke-identificerende |
| Værdi | 别名为 |
|---|---|
| to | Identificerende |
| optionally to | Ikke-identificerende |
Kopiér
Integrer
erDiagram
CAR ||--o{ NAMED-DRIVER : allows
PERSON }o..o{ NAMED-DRIVER : is
Kopiér
Integrer
erDiagram
CAR ||--o{ NAMED-DRIVER : allows
PERSON }o--o{ NAMED-DRIVER : is
Attribut
Du kan definere attributter for en entitet ved at angive entitetsnavnet efterfulgt af en blok med flere type name-par, hvor blokken er omsluttet af klammerne {}. Attributter vises inde i entitetsboksen, f.eks.:
Kopiér
Integrer
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
}
type-værdier skal begynde med et alfabetisk tegn og kan indeholde tal, bindestreger, underscore, runde parenteser og kantede parenteser. name-værdier følger et format, der ligner type, men kan også begynde med en stjerne som en anden måde at angive, at attributten er en primærnøgle. Derudover er der ingen andre begrænsninger og ingen implicit samling af gyldige datatyper.
Entitetsalias
Du kan tilføje et alias til en entitet med kantede parenteser. Hvis der angives et alias, vises aliaset i diagrammet i stedet for entitetsnavnet, og aliaset følger alle de samme regler som entitetsnavne.
Kopiér
Integrer
erDiagram
p[Person] {
string firstName
string lastName
}
a["Customer Account"] {
string email
}
p ||--o| a : has
Attributnøgler og kommentarer
Attributter kan også definere nøgler eller kommentarer. En nøgle kan være en primærnøgle (PK), en fremmednøgle (FK) eller en unik nøgle (UK). For at angive flere nøglebegrænsninger på en enkelt attribut skal du adskille dem med kommaer (f.eks. PK, FK). Kommentarer defineres med dobbelte anførselstegn i slutningen af attributten, og kommentaren må ikke indeholde anførselstegnstegn.
Kopiér
Integrer
erDiagram
CAR ||--o{ NAMED-DRIVER : allows
CAR {
string registrationNumber PK
string make
string model
string[] parts
}
PERSON ||--o{ NAMED-DRIVER : is
PERSON {
string driversLicense PK "The license #"
string(99) firstName "Only 99 characters are allowed"
string lastName
string phone UK
int age
}
NAMED-DRIVER {
string carRegistrationNumber PK, FK
string driverLicence PK, FK
}
MANUFACTURER ||--o{ CAR : makes
Retning
Et retningsudsagn erklærer diagrammets retning.
TB erklærer, at diagrammets retning er fra top til bund, og BT kan vende den til fra bund til top.
Kopiér
Integrer
erDiagram
direction TB
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
}
LR erklærer, at diagrammets retning er fra venstre til højre, og RL kan vende den til fra højre til venstre.
Kopiér
Integrer
erDiagram
direction LR
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
}
Angiv knudestil
Du kan anvende en bestemt stil på en knude, f.eks. en tykkere kant eller en anden baggrundsfarve.
Kopiér
Integrer
erDiagram
id1||--||id2 : label
style id1 fill:pink,stroke:yellow,stroke-width:4px
style id2 fill:#69d,stroke:#f96,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
Du kan også knytte stil til en liste af knuder i et enkelt udsagn:
Kopiér
Integrer
style nodeId1,nodeId2 styleList
Klasse
I stedet for at definere stil hver gang er det nemmere at definere en stilklasse og knytte denne klasse til de knuder, der skal se anderledes ud.
En klassedefinition er som vist i følgende eksempel:
Kopiér
Integrer
classDef className fill:pink,stroke:#333,stroke-width:4px
Du kan også definere flere klasser i et enkelt udsagn:
Kopiér
Integrer
classDef firstClassName,secondClassName font-size:12pt
Syntaksen til at knytte en klasse til en knude er som følger:
Kopiér
Integrer
class nodeId1 className
Du kan også knytte en klasse til en liste af knuder i et enkelt udsagn:
Kopiér
Integrer
class nodeId1,nodeId2 className
Du kan også knytte flere klasser på samme tid:
Kopiér
Integrer
class nodeId1,nodeId2 className1,className2
En nem måde at tilføje en klasse på er at bruge operatoren ::: til at knytte klassenavnet til knuden, som vist nedenfor:
Kopiér
Integrer
erDiagram
direction TB
CAR:::someclass {
string registrationNumber
string make
string model
}
PERSON:::someclass {
string firstName
string lastName
int age
}
HOUSE:::someclass
classDef someclass fill:#f96
Du kan deklarere relationer mellem entiteter med følgende syntaks:
Kopiér
Integrer
erDiagram
CAR {
string registrationNumber
string make
string model
}
PERSON {
string firstName
string lastName
int age
}
PERSON:::foo ||--|| CAR : owns
PERSON o{--|| HOUSE:::bar : has
classDef foo stroke:#f00
classDef bar stroke:#0f0
classDef foobar stroke:#00f
I lighed med class-udsagnet kan den korte syntaks også anvende flere klasser på én gang:
Kopiér
Integrer
nodeId:::className1,className2
Standardklasse
Hvis en klasse hedder default, tildeles den til alle klasser, der ikke har en bestemt klassedefinition.
Kopiér
Integrer
classDef default fill:pink,stroke:#333,stroke-width:4px;
Bemærk: Brugerdefineret stil fra style- eller andre klasseudsagn har forrang og tilsidesætter standardstilen. (F.eks. angiver default-klassen en lyserød baggrund for en knude, men hvis blue-klassen anvendes, får knuden en blå baggrundsfarve.)
Kopiér
Integrer
erDiagram
CAR {
string registrationNumber
string make
string model
}
PERSON {
string firstName
string lastName
int age
}
PERSON:::foo ||--|| CAR : owns
PERSON o{--|| HOUSE:::bar : has
classDef default fill:pink,stroke-width:4px
classDef foo stroke:#f90
classDef bar stroke:#ff0
classDef foobar stroke:#69f
Konfiguration
Layout
Diagrammets layout håndteres af render(), og standardlayoutet er ELK-layoutet, som passer til større og mere komplekse diagrammer.
For at bruge det klassiske Dagre-layout i stedet kan du angive det i config i YAML-frontmatter
Kopiér
Integrer
---
config:
layout: dagre
---
Mermaid-kodens indhold er som følger:
Kopiér
Integrer
---
title: Order example
config:
layout: elk
---
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
