ERD-designer

Design et relasjonelt skjema uten en databaseserver: legg til tabeller, gi dem kolonner med typer, nøkler og standardverdier, og koble dem deretter med relasjoner. Entity-relationship-diagrammet tegnes om underveis, og den samme modellen kan eksporteres som CREATE TABLE-DDL for MySQL, PostgreSQL, SQL Server, SQLite eller Oracle, som Mermaid erDiagram-kilde, eller som bærbar skjema-JSON som kan importeres på nytt her eller åpnes i migreringsgeneratoren. Alt kjører lokalt.
Hva er et ERD? ERD er forkortelse for entity relationship diagram, og det er designtegningen av en database, ikke en oversikt over en ferdig. En nyttig sammenligning er en bygningstegning: den kjørende databasen er bygningen, ERD-en er tegningen, og ingen heller betong først og måler etterpå. Denne siden er tegnebordet for den tegningen — modellen formes her, og DDL, Mermaid-kilden og skjema-JSON skrives alle ut fra den ene modellen, så bildet kan ikke drive bort fra SQL-en det produserte.
Det samme diagrammet på tre nivåer. Et konseptuelt ERD navngir bare tingene som betyr noe og hvordan de henger sammen, med ord en ikke-programmerer kan kontrollere. Et logisk ERD legger til nøklene som identifiserer hver ting og løser mange-til-mange-koblinger, samtidig som det er fritt for enhver motors dialekt. Et fysisk ERD fyller inn det ett bestemt produkt krever — typebredder, standardverdier, nullbarhet, unike begrensninger, slettereguler — og det er nivået som eksporteres her når man velger MySQL, PostgreSQL, SQL Server, SQLite eller Oracle.
Hvor boksene kommer fra. Les en beskrivelse av systemet og understrek substantivene: kunde, faktura, produkt, forsendelse. Det er tabellene. Fakta og egenskaper knyttet til et substantiv — en fakturadato, en enhetspris, en e-postadresse — er kolonnene. Et verb som binder sammen to substantiver, som i “en ordre legges inn av en kunde”, er en relasjon, og den lagres ved å kopiere primærnøkkelen til forelderraden inn i barnraden som en fremmednøkkel.
Når en kobling er mange-til-mange. En oppskrift bruker mange ingredienser, og en ingrediens dukker opp i mange oppskrifter, så ingen av tabellene kan beholde den andres nøkkel uten å gjenta seg selv. Svaret er en tredje entitet hvis eneste jobb er å pare dem — kobletabellen (eller assosiasjonstabellen), som holder én fremmednøkkel for hver side, ofte med det paret av nøkler som sin egen primærnøkkel. En modell som for det meste består av slike paretabeller er helt normal: en mange-til-mange-linje på en tavle må alltid bli til en boks i det virkelige skjemaet.
Hvorfor bry seg før DDL-en finnes. En feil linje på en tegning koster et minutt å viske ut; den samme feilen oppdaget etter utgivelse koster en migrering over levende data. Et diagram er også det ene artefaktet ikke-utviklere kan gjennomgå, og relasjonsfeil — en kardinalitet snudd feil vei, en manglende unik nøkkel, barnrader som kan stå uten forelder — viser seg som åpenbart dårlige linjer her, mens de i en DDL-fil på 400 linjer gjemmer seg blant begrensningene.
Forover eller bakover? Denne designeren går forover: modell først, DDL ut. Søskensiden SQL to ERD går den andre veien — lim inn eksisterende CREATE TABLE-setninger, og den bygger diagrammet på nytt, som er den raskeste veien når databasen allerede finnes.
1 — Tabeller
Rediger Tabellnavn Kolonner Relasjoner Actions
2 — Kolonner
Kolonne Type PK AI NN UQ Standard Actions
PK = primærnøkkel, AI = auto-økning / identitet, NN = ikke null, UQ = unik
3 — Relasjoner (fremmednøkler)
Barntabell Barnkolonne Actions Foreldertabell Forelderkolonne Ved sletting Actions
En fremmednøkkel blir til en linje CONSTRAINT ... FOREIGN KEY i DDL-en.
4 — Eksport
Mermaid erDiagram-kilde
JSON-modellen er utvekslingsformatet for databaseverktøyfamilien: lim den inn i migreringsgeneratoren som et før/etter-skjema, eller importer den på nytt her for å fortsette å redigere senere.