Diagram ER
Diagram relacji encji (w skrócie diagram ER) opisuje powiązane ze sobą obiekty zainteresowania w określonej dziedzinie wiedzy. Podstawowy diagram ER składa się z typów encji (służących do klasyfikowania obiektów zainteresowania) i określa relacje, które mogą istnieć między encjami (wystąpieniami tych typów encji),Należy zauważyć, że w praktyce na diagramach ER prawie zawsze 'typ encji' nazywa się po prostu 'encją'. Na przykład 'typ encji CUSTOMER' jest zwykle nazywany po prostu 'encją CUSTOMER'. Praktyka ta jest bardzo powszechna, dlatego nie zaleca się innych sposobów; technicznie jednak encja jest abstrakcyjnym wystąpieniem typu encji, a diagram ER pokazuje właśnie te abstrakcyjne wystąpienia i relacje między nimi. Dlatego encje zawsze nazywa się rzeczownikami w liczbie pojedynczej.
Kopiuj
Osadź
---
title: Order example
---
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
Nazwy encji są zwykle pisane wielkimi literami, chociaż nie ma na to powszechnie przyjętego standardu, a składnia Mermaid tego nie wymaga.
Relacje między encjami są przedstawiane za pomocą linii z oznaczeniami końców wskazującymi liczebność. Mermaid stosuje najpopularniejszą notację stopki wrony; stopka wrony wizualnie wskazuje, że połączona encja może mieć wiele wystąpień.
Diagramy ER można stosować do różnych celów, od abstrakcyjnych modeli logicznych niezawierających szczegółów implementacyjnych po modele fizyczne tabel relacyjnych baz danych. Umieszczenie definicji atrybutów na diagramie ER pomaga zrozumieć przeznaczenie i znaczenie encji; te definicje atrybutów nie muszą być wyczerpujące, zwykle wystarczy niewielki podzbiór atrybutów. Mermaid pozwala definiować je według typu i nazwy.
Kopiuj
Osadź
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
}
Podczas umieszczania atrybutów na diagramie ER musisz zdecydować, czy uwzględnić klucze obce jako atrybuty; może to zależeć od tego, w jakim stopniu chcesz przedstawić strukturę tabel relacyjnych. Jeśli Twój diagram jest modelem logicznym, który nie ma sugerować implementacji relacyjnej, najlepiej jest pominąć te atrybuty, ponieważ relacja asocjacji już przekazuje sposób powiązania encji. Na przykład struktura danych JSON może implementować relację jeden-do-wielu za pomocą tablicy bez atrybutów klucza obcego. Podobnie obiektowe języki programowania mogą używać wskaźników lub odwołań do kolekcji. Nawet w przypadku modeli przeznaczonych do implementacji relacyjnej można uznać, że uwzględnienie atrybutów klucza obcego powiela informacje przekazywane przez relację i nie dodaje encji znaczenia.
Składnia
Encje i relacje
Składnia Mermaid diagramu ER jest zgodna z PlantUML i rozszerza funkcje o oznaczanie relacji. Każda instrukcja obejmuje następujące elementy:
Kopiuj
Osadź
<first-entity> [<relationship> <second-entity> : <relationship-label>]
- first-entity to nazwa pierwszej encji. Nazwa obsługuje dowolne znaki Unicode i może zawierać spacje, jeśli zostanie ujęta w podwójne cudzysłowy.
- relationship opisuje wzajemną relację między dwiema encjami.
- second-entity to nazwa drugiej encji.
- relationship-label opisuje relację z punktu widzenia pierwszej encji.
Na przykład:
Kopiuj
Osadź
PROPERTY ||--|{ ROOM : contains
To stwierdzenie można rozumieć następująco: jedna nieruchomość zawiera jeden lub więcej pokoi, a jeden pokój należy tylko do jednej nieruchomości. Etykieta tutaj jest podana z punktu widzenia pierwszej encji: nieruchomość zawiera pokój, ale pokój nie zawiera nieruchomości. Z punktu widzenia drugiej encji równoważną etykietę zwykle łatwo wywnioskować.
Tylko część first-entity jest obowiązkowa. Umożliwia to pokazanie encji bez relacji, co jest bardzo przydatne podczas iteracyjnego budowania diagramu. Jeśli określono inne części instrukcji, wszystkie części są wymagane.
Tekst Unicode
Nazwy encji, relacje i atrybuty obsługują tekst unicode.
Kopiuj
Osadź
erDiagram
"This ❤ Unicode"
Składnia relacji
Część relacji każdej instrukcji można podzielić na trzy podczęści:
- Liczebność pierwszej encji względem drugiej encji
- Czy ta relacja nadaje tożsamość encji podrzędnej
- Liczebność drugiej encji względem pierwszej encji
Liczebność to właściwość opisująca liczbę elementów, z którymi inna encja może być powiązana z daną encją. W powyższym przykładzie jedna nieruchomość PROPERTY może być powiązana z jednym lub więcej wystąpieniami ROOM, a jeden ROOM może być powiązany tylko z jedną nieruchomością PROPERTY. W każdym oznaczeniu liczebności znajdują się dwa znaki: najbardziej zewnętrzny znak reprezentuje wartość maksymalną, a najbardziej wewnętrzny wartość minimalną. Poniższa tabela podsumowuje możliwe liczebności:
| Wartość (lewa) | Wartość (prawa) | Znaczenie |
|---|---|---|
| |o | o| | Zero lub jeden |
| || | || | Dokładnie jeden |
| }o | o{ | Zero lub więcej (bez górnego limitu) |
| }| | |{ | Jeden lub więcej (bez górnego limitu) |
| Wartość (lewa) | Wartość (prawa) | Znaczenie |
|---|---|---|
| one or zero | one or zero | Zero lub jeden |
| zero or one | zero or one | Zero lub jeden |
| one or more | one or more | Jeden lub więcej |
| one or many | one or many | Jeden lub więcej |
| many(1) | many(1) | Jeden lub więcej |
| 1+ | 1+ | Jeden lub więcej |
| zero or more | zero or more | Zero lub więcej |
| zero or many | zero or many | Zero lub więcej |
| many(0) | many(0) | Zero lub więcej |
| 0+ | 0+ | Zero lub więcej |
| only one | only one | Dokładnie jeden |
| 1 | 1 | Dokładnie jeden |
Identyfikacja tożsamości
Relacje można podzielić na identyfikujące i nieidentyfikujące, renderowane odpowiednio linią ciągłą lub kreskowaną. Jest to istotne, gdy jedna z encji nie może istnieć niezależnie bez drugiej. Na przykład firma ubezpieczająca ludzi prowadzących samochody może potrzebować przechowywania danych NAMED-DRIVER. Podczas modelowania możemy najpierw zauważyć, że CAR może być prowadzony przez wiele PERSON, a PERSON może prowadzić wiele CAR; oba mogą istnieć bez siebie, więc jest to relacja nieidentyfikująca, którą w Mermaid możemy określić jako: PERSON }|..|{ CAR : "driver". Należy zwrócić uwagę na dwie kropki w środku relacji, co spowoduje narysowanie linii kreskowanej między dwiema encjami. Jednak gdy ta relacja wiele-do-wielu zostanie rozłożona na dwie relacje jeden-do-wielu, zauważamy, że NAMED-DRIVER nie może istnieć bez PERSON i CAR. Te relacje stają się relacjami identyfikującymi i będą oznaczone myślnikiem, co odpowiada linii ciągłej:
| Wartość | Alias |
|---|---|
| -- | Identyfikująca |
| .. | Nieidentyfikująca |
| Wartość | 别名为 |
|---|---|
| to | Identyfikująca |
| optionally to | Nieidentyfikująca |
Kopiuj
Osadź
erDiagram
CAR ||--o{ NAMED-DRIVER : allows
PERSON }o..o{ NAMED-DRIVER : is
Kopiuj
Osadź
erDiagram
CAR ||--o{ NAMED-DRIVER : allows
PERSON }o--o{ NAMED-DRIVER : is
Atrybut
Atrybuty encji można zdefiniować, określając nazwę encji, a następnie blok zawierający wiele type name, przy czym blok jest otoczony nawiasami klamrowymi {}. Atrybuty są wyświetlane wewnątrz ramki encji, na przykład:
Kopiuj
Osadź
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
}
Wartość type musi zaczynać się od znaku alfabetycznego i może zawierać cyfry, myślniki, podkreślenia, nawiasy okrągłe i nawiasy kwadratowe. Wartość name podlega podobnemu formatowi jak type, ale może również zaczynać się od gwiazdki jako innej opcji wskazującej, że atrybut jest kluczem głównym. Poza tym nie ma innych ograniczeń ani niejawnego zestawu prawidłowych typów danych.
Alias encji
Do encji można dodać alias za pomocą nawiasów kwadratowych. Jeśli podano alias, na diagramie będzie wyświetlany alias zamiast nazwy encji; alias podlega tym samym zasadom co nazwa encji.
Kopiuj
Osadź
erDiagram
p[Person] {
string firstName
string lastName
}
a["Customer Account"] {
string email
}
p ||--o| a : has
Klucze atrybutów i komentarze
Atrybuty mogą również definiować klucze lub komentarze. Klucz może być kluczem głównym (PK), kluczem obcym (FK) lub kluczem unikalnym (UK). Aby określić wiele ograniczeń klucza na jednym atrybucie, oddziel je przecinkami (np. PK, FK). Komentarze definiuje się za pomocą podwójnych cudzysłowów na końcu atrybutu; komentarz nie może zawierać znaku podwójnego cudzysłowu.
Kopiuj
Osadź
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
Kierunek
Instrukcja kierunku deklaruje kierunek diagramu.
TB deklaruje kierunek diagramu od góry do dołu; BT może go odwrócić na od dołu do góry.
Kopiuj
Osadź
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 deklaruje kierunek diagramu od lewej do prawej; RL może go odwrócić na od prawej do lewej.
Kopiuj
Osadź
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
}
Ustawianie stylu węzła
Do węzła można zastosować określony styl, na przykład pogrubioną ramkę lub inny kolor tła.
Kopiuj
Osadź
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
Możesz także dołączyć styl do listy węzłów w jednej instrukcji:
Kopiuj
Osadź
style nodeId1,nodeId2 styleList
Klasa
Wygodniejszym niż każdorazowe definiowanie stylu jest zdefiniowanie klasy stylu i dołączenie jej do węzłów wymagających innego wyglądu.
Definicja klasy jest pokazana w poniższym przykładzie:
Kopiuj
Osadź
classDef className fill:pink,stroke:#333,stroke-width:4px
Można także zdefiniować wiele klas w jednej instrukcji:
Kopiuj
Osadź
classDef firstClassName,secondClassName font-size:12pt
Składnia dołączania klasy do węzła jest następująca:
Kopiuj
Osadź
class nodeId1 className
Możesz także dołączyć klasę do listy węzłów w jednej instrukcji:
Kopiuj
Osadź
class nodeId1,nodeId2 className
Możesz także dołączyć wiele klas jednocześnie:
Kopiuj
Osadź
class nodeId1,nodeId2 className1,className2
Prostym sposobem dodania klasy jest użycie operatora :::, aby dołączyć nazwę klasy do węzła, jak pokazano poniżej:
Kopiuj
Osadź
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
Do zadeklarowania relacji między encjami można użyć następującej składni:
Kopiuj
Osadź
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
Podobnie jak instrukcja class, składnia skrócona może również zastosować wiele klas naraz:
Kopiuj
Osadź
nodeId:::className1,className2
Klasa domyślna
Jeśli klasa nosi nazwę default, zostanie przypisana do wszystkich klas bez określonej definicji klasy.
Kopiuj
Osadź
classDef default fill:pink,stroke:#333,stroke-width:4px;
Uwaga: niestandardowe style pochodzące ze stylu lub innych instrukcji klas mają priorytet i nadpisują styl domyślny. (Na przykład klasa default ustawia różowe tło dla węzła, ale jeśli zastosowano klasę blue, węzeł otrzyma niebieski kolor tła.)
Kopiuj
Osadź
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
Konfiguracja
Układ
Układ diagramu jest obsługiwany przez render(); domyślnym układem jest układ ELK, odpowiedni dla większych i bardziej złożonych diagramów.
Aby zamiast tego użyć klasycznego układu Dagre, możesz ustawić go w config w YAML frontmatter
Kopiuj
Osadź
---
config:
layout: dagre
---
Treść kodu Mermaid jest następująca:
Kopiuj
Osadź
---
title: Order example
config:
layout: elk
---
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ LINE-ITEM : contains
CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
