Design et relationelt skema uden en databaseserver: tilføj tabeller, giv dem kolonner med typer, nøgler og standardværdier, og forbind dem derefter med relationer. Entity-relationsdiagrammet tegnes om, mens der skrives, og den samme model eksporteres som CREATE TABLE-DDL til MySQL, PostgreSQL, SQL Server, SQLite eller Oracle, som Mermaid erDiagram-kilde, eller som bærbar skema-JSON, der kan importeres igen her eller åbnes i Migreringsgeneratoren. Alt kører lokalt.
Hvad er et ERD? ERD er forkortelse for entity-relationsdiagram, og det er databasens design-tegning frem for en registrering af en færdig. En nyttig sammenligning er en byggetegning: den kørende database er bygningen, ERD'et er tegningen, og ingen hælder beton først og måler bagefter. Denne side er tegnebordet til den tegning — modellen formes her, og DDL, Mermaid-kilden og skema-JSON'en udskrives alle fra den ene model, så billedet ikke kan glide væk fra den SQL, det producerede.
Det samme diagram på tre niveauer. Et konceptuelt ERD navngiver kun de ting, der betyder noget, og hvordan de hænger sammen, med ord en ikke-programmør kan kontrollere. Et logisk ERD tilføjer de nøgler, der identificerer hver ting, og løser mange-til-mange-forbindelser, mens det forbliver fri for enhver motors dialekt. Et fysisk ERD udfylder, hvad et bestemt produkt kræver — typebredder, standardværdier, nullbarhed, unikke begrænsninger, slettereglerne — og det er det niveau, der eksporteres her, når der vælges MySQL, PostgreSQL, SQL Server, SQLite eller Oracle.
Hvor kasserne kommer fra. Læs en beskrivelse af systemet og understreg substantiverne: kunde, faktura, produkt, forsendelse. Det er tabellerne. De fakta og egenskaber, der hører til et substantiv — en fakturadato, en enhedspris, en e-mailadresse — er dets kolonner. Et verbum, der binder to substantiver sammen, som i “en ordre afgives af en kunde”, er en relation, og den gemmes ved at kopiere den identificerende nøgle fra forældrerækken ind i børnerækken som en fremmednøgle.
Når en forbindelse er mange-til-mange. En opskrift bruger mange ingredienser, og en ingrediens optræder i mange opskrifter, så ingen af tabellerne kan beholde den andens nøgle uden at gentage sig selv. Svaret er en tredje entitet, hvis eneste opgave er at parre dem — forbindelsestabellen (eller den associative tabel), som holder én fremmednøgle for hver side, ofte med parret af nøgler som sin egen primærnøgle. En model, der for det meste består af sådanne parringstabeller, er helt normal: en mange-til-mange-linje på en tavle skal altid blive til en boks i det rigtige skema.
Hvorfor besvære sig før DDL'en findes. En forkert linje på en tegning koster et minut at viske ud; den samme fejl, fundet efter udgivelse, koster en migrering over live data. Et diagram er også det ene artefakt, ikke-udviklere kan gennemgå, og relationsfejl — en kardinalitet vendt forkert, en manglende unik nøgle, børnerækker der kan stå uden en forælder — viser sig her som åbenlyst dårlige linjer, mens de i en 400-linjers DDL-fil gemmer sig blandt begrænsningerne.
Forlæns eller baglæns? Denne designer går forlæns: model først, DDL ud. Søgesiden
SQL til ERD går den anden vej — indsæt eksisterende
CREATE TABLE-udsagn, og den bygger diagrammet igen, hvilket er den hurtigere vej, når databasen allerede findes.
