ER-diagram
Entitetsrelasjonsdiagrammet (forkortet ER-diagram) beskriver gjensidig relaterte ting av interesse innenfor et bestemt kunnskapsområde. Et grunnleggende ER-diagram består av entitetstyper (brukt til å klassifisere ting av interesse), og spesifiserer relasjonene som kan finnes mellom entiteter (forekomster av disse entitetstypene),Vær oppmerksom på at i praktisk bruk av ER-diagrammer forkortes nesten alltid 'entitetstype' til 'entitet'. For eksempel kalles 'CUSTOMER entitetstype' vanligvis ganske enkelt 'CUSTOMER entitet'. Denne praksisen er svært vanlig, og andre måter anbefales derfor ikke, men teknisk sett er en entitet en abstrakt forekomst av en entitetstype, og det er nettopp disse abstrakte forekomstene og forholdene mellom dem som ER-diagrammet viser. Dette er grunnen til at entiteter alltid navngis med entallsord.
Kopier
Bygg inn
---
title: Order example
---
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
Entitetsnavn skrives vanligvis med store bokstaver, selv om det ikke finnes noen allment anerkjent standard for dette, og Mermaid-syntaksen krever det heller ikke.
Forholdet mellom entiteter vises med linjer med endepunktmarkører som angir kardinalitet. Mermaid bruker det mest populære kråkefot-symbolet, og kråkefoten viser intuitivt at entiteten den er koblet til, kan ha flere forekomster.
ER-diagrammer kan brukes til ulike formål, fra abstrakte logiske modeller uten noen implementeringsdetaljer, til fysiske modeller av relasjonsdatabasetabeller. Å inkludere attributtdefinisjoner i et ER-diagram hjelper med å forstå entitetens formål og betydning. Disse attributtdefinisjonene trenger ikke være uttømmende, vanligvis er en liten delmengde av attributter tilstrekkelig. Mermaid lar deg definere dem med type og navn.
Kopier
Bygg inn
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 inkluderer attributter i et ER-diagram, må du bestemme om du vil inkludere fremmednøkler som attributter, noe som kan avhenge av i hvilken grad du ønsker å representere relasjonstabellstrukturen. Hvis diagrammet ditt er en logisk modell som ikke er ment å antyde en relasjonsimplementering, er det best å ikke inkludere disse attributtene, siden assosiasjonsrelasjonen allerede formidler hvordan entitetene er knyttet sammen. For eksempel kan en JSON-datastruktur implementere én-til-mange-relasjoner ved hjelp av arrayer uten fremmednøkkelattributter. På samme måte kan objektorienterte programmeringsspråk bruke pekere eller referanser til samlinger. Selv for modeller som er ment for relasjonsimplementering, kan det hevdes at inkludering av fremmednøkkelattributter gjentar informasjonen som relasjonen viser, og ikke tilfører entiteten mening.
Syntaks
Entiteter og relasjoner
Mermaids syntaks for ER-diagrammer er kompatibel med PlantUML, og utvider funksjonaliteten for å merke relasjoner. Hver setning inkluderer følgende:
Kopier
Bygg inn
<first-entity> [<relationship> <second-entity> : <relationship-label>]
- first-entity er navnet på den første entiteten. Navnet støtter alle Unicode-tegn, og kan inneholde mellomrom hvis det omsluttes av doble anførselstegn.
- relationship beskriver det gjensidige forholdet mellom to entiteter.
- second-entity er navnet på den andre entiteten.
- relationship-label beskriver relasjonen fra den første entitetens perspektiv.
For eksempel:
Kopier
Bygg inn
PROPERTY ||--|{ ROOM : contains
Denne deklarasjonen kan forstås som: en eiendom inneholder ett eller flere rom, og ett rom tilhører bare én eiendom. Etiketten her ses fra den første entitetens perspektiv: en eiendom inneholder et rom, men et rom inneholder ikke en eiendom. Fra den andre entitetens perspektiv kan den tilsvarende etiketten vanligvis lett utledes.
Bare first-entity -delen er obligatorisk. Dette gjør det mulig å vise entiteter uten relasjoner, noe som er svært nyttig når du bygger diagrammer iterativt. Hvis andre deler av setningen er angitt, er alle delene obligatoriske.
Unicode-tekst
Entitetsnavn, relasjoner og attributter støtter alle unicode-tekst.
Kopier
Bygg inn
erDiagram
"This ❤ Unicode"
Relasjonssyntaks
Relasjonsdelen av hver setning kan deles inn i tre deldeler:
- Den første entitetens kardinalitet i forhold til den andre entiteten
- Om relasjonen gir underentiteten identifisering
- Den andre entitetens kardinalitet i forhold til den første entiteten
Kardinalitet er en egenskap som beskriver antall elementer en annen entitet kan assosieres med for den aktuelle entiteten. I eksempelet ovenfor kan én PROPERTY assosieres med én eller flere ROOM-forekomster, mens én ROOM bare kan assosieres med én PROPERTY. Hvert kardinalitetsmerke inneholder to tegn, der det ytterste tegnet representerer maksimumsverdien og det innerste tegnet representerer minimumsverdien. Tabellen nedenfor oppsummerer kardinalitetsmulighetene:
| Verdi (venstre) | Verdi (høyre) | Betydning |
|---|---|---|
| |o | o| | Null eller én |
| || | || | Nøyaktig én |
| }o | o{ | Null eller flere (uten øvre grense) |
| }| | |{ | Én eller flere (uten øvre grense) |
| Verdi (venstre) | Verdi (høyre) | Betydning |
|---|---|---|
| one or zero | one or zero | Null eller én |
| zero or one | zero or one | Null 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 | Null eller flere |
| zero or many | zero or many | Null eller flere |
| many(0) | many(0) | Null eller flere |
| 0+ | 0+ | Null eller flere |
| only one | only one | Nøyaktig én |
| 1 | 1 | Nøyaktig én |
Identifisering
Relasjoner kan deles inn i identifiserende og ikke-identifiserende, og rendres henholdsvis med hel linje eller stiplet linje. Dette er viktig når en av entitetene ikke kan eksistere uavhengig uten den andre. For eksempel kan et selskap som tilbyr forsikring for folk som kjører bil, trenge å lagre data om NAMED-DRIVER. Når vi modellerer, kan vi først observere at en CAR kan kjøres av mange PERSON-er, og en PERSON kan kjøre mange CAR-er, og begge kan eksistere uten den andre, så dette er en ikke-identifiserende relasjon, som vi i Mermaid kan angi som: PERSON }|..|{ CAR : "driver". Legg merke til de to punktene midt i relasjonen, noe som fører til at det tegnes en stiplet linje mellom de to entitetene. Men når denne mange-til-mange-relasjonen løses opp i to én-til-mange-relasjoner, observerer vi at NAMED-DRIVER ikke kan eksistere uten PERSON og CAR. Disse relasjonene blir identifiserende relasjoner og vises med bindestrek, som tilsvarer en hel linje:
| Verdi | Alias |
|---|---|
| -- | Identifiserende |
| .. | Ikke-identifiserende |
| Verdi | 别名为 |
|---|---|
| to | Identifiserende |
| optionally to | Ikke-identifiserende |
Kopier
Bygg inn
erDiagram
CAR ||--o{ NAMED-DRIVER : allows
PERSON }o..o{ NAMED-DRIVER : is
Kopier
Bygg inn
erDiagram
CAR ||--o{ NAMED-DRIVER : allows
PERSON }o--o{ NAMED-DRIVER : is
Attributt
Du kan definere attributter for en entitet ved å angi entitetsnavnet og deretter en blokk som inneholder flere type name , der blokken omsluttes av klamrene {} . Attributtene vises inne i entitetsboksen, for eksempel:
Kopier
Bygg inn
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 -verdien må begynne med et bokstavtegn og kan inneholde tall, bindestreker, understreker, parenteser og hakeparenteser. name -verdien følger et format som ligner type , men kan også begynne med en stjerne, som er et annet alternativ for å indikere at attributtet er en primærnøkkel. Utover dette finnes det ingen andre begrensninger, og det finnes heller ikke et implisitt sett med gyldige datatyper.
Entitetsalias
Du kan bruke hakeparenteser for å legge til et alias for en entitet. Hvis et alias er angitt, viser diagrammet aliaset i stedet for entitetsnavnet. Aliaset følger alle de samme reglene som entitetsnavn.
Kopier
Bygg inn
erDiagram
p[Person] {
string firstName
string lastName
}
a["Customer Account"] {
string email
}
p ||--o| a : has
Attributtnøkler og kommentarer
Attributter kan også definere nøkler eller kommentarer. Nøkler kan være primærnøkkel (PK), fremmednøkkel (FK) eller unik nøkkel (UK). For å angi flere nøkkelbegrensninger på ett attributt skiller du dem med komma (for eksempel PK, FK). Kommentarer defineres med doble anførselstegn på slutten av attributtet, og kommentaren kan ikke inneholde tegnet dobbelt anførselstegn.
Kopier
Bygg inn
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
Retningssetningen deklarerer diagrammets retning.
TB erklærer at diagrammets retning er fra topp til bunn, og BT kan reversere den til fra bunn til topp.
Kopier
Bygg inn
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øyre, og RL kan reversere den til fra høyre til venstre.
Kopier
Bygg inn
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
}
Angi nodestil
Du kan bruke bestemte stiler på noder, for eksempel tykkere rammer eller en annen bakgrunnsfarge.
Kopier
Bygg inn
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 over noder i én setning:
Kopier
Bygg inn
style nodeId1,nodeId2 styleList
Klasse
I stedet for å definere stilen hver gang, er det mer praktisk å definere en stilklasse og knytte den klassen til de nodene som skal ha et annet utseende.
Klassedefinisjonen vises i følgende eksempel:
Kopier
Bygg inn
classDef className fill:pink,stroke:#333,stroke-width:4px
Du kan også definere flere klasser i én setning:
Kopier
Bygg inn
classDef firstClassName,secondClassName font-size:12pt
Syntaksen for å knytte en klasse til en node er som følger:
Kopier
Bygg inn
class nodeId1 className
Du kan også knytte en klasse til en liste over noder i én setning:
Kopier
Bygg inn
class nodeId1,nodeId2 className
Du kan også knytte flere klasser samtidig:
Kopier
Bygg inn
class nodeId1,nodeId2 className1,className2
En enkel måte å legge til en klasse på er å bruke ::: -operatoren til å knytte klassenavnet til en node, som vist nedenfor:
Kopier
Bygg inn
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
For å deklarere forholdet mellom entiteter kan du bruke følgende syntaks:
Kopier
Bygg inn
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 likhet med class -setningen kan snarveissyntaksen også bruke flere klasser samtidig:
Kopier
Bygg inn
nodeId:::className1,className2
Standardklasse
Hvis en klasse heter default , tildeles den til alle klasser som ikke har en bestemt klassedefinisjon.
Kopier
Bygg inn
classDef default fill:pink,stroke:#333,stroke-width:4px;
Merk: egendefinerte stiler fra style - eller andre klasse-setninger har prioritet og overstyrer standardstilen. (For eksempel setter default -klassen en rosa bakgrunn for noden, men hvis blue -klassen brukes, får noden blå bakgrunnsfarge.)
Kopier
Bygg inn
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
Konfigurasjon
Oppsett
Diagrammets oppsett håndteres av render() , og standardoppsettet er ELK-oppsettet, som passer for større og mer komplekse diagrammer.
For å bruke det klassiske Dagre-oppsettet i stedet kan du angi det i config i YAML-frontmatter
Kopier
Bygg inn
---
config:
layout: dagre
---
Mermaid-koden er som følger:
Kopier
Bygg inn
---
title: Order example
config:
layout: elk
---
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
