ERD-designer

Designa ett relationsschema utan databasserver: lägg till tabeller, ge dem kolumner med typer, nycklar och standardvärden och koppla sedan ihop dem med relationer. ER-diagrammet ritas om medan man skriver, och samma modell exporteras som CREATE TABLE-DDL för MySQL, PostgreSQL, SQL Server, SQLite eller Oracle, som Mermaid erDiagram-källkod, eller som portabel schema-JSON som kan importeras igen här eller öppnas i migreringsgeneratorn. Allt körs lokalt.
Vad är en ERD? ERD är en förkortning för entity relationship diagram (entitets-relationsdiagram), och det är databasens konstruktionsritning snarare än ett protokoll över en färdig. En användbar jämförelse är en husritning: den färdiga databasen är huset, ERD:n är ritningen, och ingen gjuter betong först och mäter efteråt. Den här sidan är ritbordet för den ritningen — modellen formas här, och DDL, Mermaid-källan och schema-JSON skrivs ut från den ena modellen, så bilden kan inte glida från SQL:en den producerade.
Samma diagram på tre nivåer. En konceptuell ERD namnger bara de saker som spelar roll och hur de hänger ihop, med ord som en icke-programmerare kan kontrollera. En logisk ERD lägger till de nycklar som identifierar varje sak och löser många-till-många-kopplingar, samtidigt som den förblir fri från någon motors dialekt. En fysisk ERD fyller i det en viss produkt kräver — typbredder, standardvärden, nullbarhet, unika villkor, raderingsregler — vilket är nivån som exporteras här när MySQL, PostgreSQL, SQL Server, SQLite eller Oracle väljs.
Var lådorna kommer ifrån. Läs en beskrivning av systemet och understryk substantiven: kund, faktura, produkt, leverans. Det är tabellerna. De fakta och egenskaper som hör till ett substantiv — ett fakturadatum, ett styckpris, en e-postadress — är dess kolumner. Ett verb som binder ihop två substantiv, som i “en beställning läggs av en kund”, är en relation, och den lagras genom att kopiera den identifierande nyckeln för föräldraraden in i barnraden som en främmande nyckel.
När en koppling är många-till-många. Ett recept använder många ingredienser och en ingrediens förekommer i många recept, så ingen av tabellerna kan hålla den andras nyckel utan att upprepa sig. Svaret är en tredje entitet vars enda uppgift är att para ihop dem — kopplingstabellen (eller associationstabellen), som innehåller en främmande nyckel för varje sida, ofta med det nyckelparet som sin egen primärnyckel. En modell som mestadels består av sådana parningstabeller är helt normal: en många-till-många-linje på en whiteboard måste alltid bli en låda i det verkliga schemat.
Varför bry sig innan DDL:en finns. En fel linje på en ritning kostar en minut att sudda bort; samma misstag som upptäcks efter release kostar en migrering över levande data. Ett diagram är också det enda artefakt som icke-utvecklare kan granska, och relationsfel — en kardinalitet åt fel håll, en saknad unik nyckel, barnrader som kan lämnas utan förälder — syns här som uppenbart felaktiga linjer, medan de i en DDL-fil på 400 rader gömmer sig bland villkoren.
Framåt eller bakåt? Den här designern går framåt: modellera först, DDL ut. Systersidan SQL till ERD går åt andra hållet — klistra in befintliga CREATE TABLE-satser och den bygger upp diagrammet igen, vilket är den snabbare vägen när databasen redan finns.
1 — Tabeller
Redigera Tabellnamn Kolumner Relationer Actions
2 — Kolumner
Kolumn Typ PK AI NN UQ Standard Actions
PK = primärnyckel, AI = automatisk ökning / identitet, NN = inte null, UQ = unik
3 — Relationer (främmande nycklar)
Barntabell Barnkolumn Actions Föräldertabell Förälderkolumn Vid radering Actions
En främmande nyckel blir en rad CONSTRAINT ... FOREIGN KEY i DDL:en.
4 — Export
Mermaid erDiagram-källa
JSON-modellen är utbytesformatet för familjen databasverktyg: klistra in den i Migreringsgeneratorn som ett schema före/efter, eller importera den igen här för att fortsätta redigera senare.