SQL til ERD — visualiser CREATE TABLE-skjemaer som entitet-relasjonsdiagrammer
SQL til ERD
Lim inn en eller flere CREATE TABLE-setninger, og dette verktøyet tegner skjemaet: hver tabell blir en entitet, kolonner blir attributter merket PK / FK, og FOREIGN KEY-begrensninger blir relasjonslinjer. Når et skjema ikke erklærer noen fremmednøkler, tilbys kolonner som customer_id som utledede relasjoner som kan beholdes eller slettes. Kopier kildekoden for Mermaid erDiagram, eller eksporter diagrammet som SVG / PNG. Alt kjøres lokalt — ingen skjemaer forlater nettleseren.
Hva er et ERD? ERD står for Entity Relationship Diagram (entitet-relasjonsdiagram) — et bilde av hvordan en database er organisert. Det tegnes med tre slags former: entiteter (tabellene, tegnet som bokser), attributter (kolonnene listet inni en boks) og relasjoner (linjene som forbinder to bokser). Teknikken stammer fra Peter Chens entitet-relasjonsmodell fra 1976 og er fortsatt den vanlige måten å skissere et skjema på før man skriver noen DDL: et godt ERD viser med én gang hvilke tabeller som finnes, hva hver rad lagrer, og hvordan en rad i én tabell peker på en rad i en annen — lesbart for folk som ikke vil lese SQL.
Entity — one thing the system keeps data about, such as a customer, an order or a product. In a relational database each entity becomes one table.
Attribute — one fact recorded for every row of an entity, such as a name, a price or a date. Each attribute becomes one column.
Relationship — an association between two entities, implemented by a foreign key: the child table stores the parent’s key, and the diagram turns that column into a line.
PK / FK — a primary key (PK) identifies each row of a table uniquely; a foreign key (FK) holds the primary key of another table and is what a relationship line represents.
Kardinalitet — hvor mange rader som er tillatt i hver ende av en linje: én-til-én, én-til-mange eller mange-til-mange. Denne siden tegner kråkefot-notasjonen som Mermaid bruker (se forklaringen i steg 4).
Notasjoner: Chen-notasjon bruker diamanter for relasjoner og ellipser for attributter; kråkefot-notasjon (den som tegnes her) komprimerer en entitet til én boks med attributtene listet inni og markerer den mange-enden av en linje med en tretindet «kråkefot»; UML-klassediagrammer beskriver den samme strukturen med klasser, operasjoner og multiplisiteter. Alle tre sier det samme om skjemaet — bare symbolene er ulike.
1 — Tabellskjema (DDL)
2 — Entiteter
Tegn
Tabell
Kolonner
Relasjoner
Attributter
Ingen tabeller analysert ennå.
3 — Relasjoner
Bruk
Barn (mange)
Actions
Forelder (én)
Kilde
Actions
Ingen relasjoner ennå.
Legg til en relasjon manuelt:
→
4 — Diagram
Mermaid erDiagram-kilde
Slik leses relasjoner: en fremmednøkkel i barne-tabellen gir PARENT ||--o{ CHILD. Entiteter og attributter beholder sine DDL-navn, med tegn Mermaid ikke kan tegne (mellomrom, bindestreker) vist som understreker. Typer forenkles til sitt grunnord (DECIMAL(10,2) → DECIMAL), fordi diagramsyntaksen ikke tar parametere.
Kardinalitetssymboler (kråkefot): merket ved siden av en entitet sier hvor mange rader som kan stå i den enden av linjen — || nøyaktig én, o| null eller én, o{ null eller mange, |{ én eller mange. Så PARENT ||--o{ CHILD leses som «én forelderrad kan refereres av null, én eller mange barnerader, og hver barnerad peker på nøyaktig én forelder» — den klassiske en-til-mange-relasjonen.
Many-to-many is never a single line: a product can appear in many orders and an order can
hold many products, so the schema stores a join table (order_items) whose two foreign keys
become two one-to-many lines. Read through that middle box and the many-to-many is there.