ERD-ontwerper

Ontwerp een relationeel schema zonder databaseserver: voeg tabellen toe, geef ze kolommen met typen, sleutels en standaardwaarden, en verbind ze daarna met relaties. Het entity-relationshipdiagram tekent zich opnieuw terwijl u typt, en hetzelfde model exporteert als CREATE TABLE-DDL voor MySQL, PostgreSQL, SQL Server, SQLite of Oracle, als Mermaid erDiagram-bron, of als overdraagbaar schema-JSON dat u hier opnieuw kunt importeren of openen in de Migratiegenerator. Alles draait lokaal.
Wat is een ERD? ERD is kort voor entity-relationshipdiagram, en het is de ontwerp-tekening van een database in plaats van een registratie van een afgeronde. Een bruikbare vergelijking is een bouwtekening: de draaiende database is het gebouw, de ERD is de tekening, en niemand giet eerst beton en meet daarna. Deze pagina is de tekentafel voor die tekening — u vormt hier het model, en de DDL, de Mermaid-bron en het schema-JSON worden allemaal uit dat ene model afgedrukt, zodat het plaatje nooit kan afwijken van de SQL die het voortbracht.
Hetzelfde diagram op drie niveaus. Een conceptuele ERD benoemt alleen de dingen die ertoe doen en hoe ze zich tot elkaar verhouden, in woorden die een niet-programmeur kan controleren. Een logische ERD voegt de sleutels toe die elk ding identificeren en lost veel-op-veel-verbanden op, terwijl hij vrij blijft van het dialect van welke engine dan ook. Een fysieke ERD vult in wat één bepaald product vereist — typebreedten, standaardwaarden, nullability, unieke beperkingen, verwijderregels — en dat is het niveau dat u hier exporteert wanneer u MySQL, PostgreSQL, SQL Server, SQLite of Oracle kiest.
Waar de vakjes vandaan komen. Lees een beschrijving van het systeem en onderstreep de zelfstandige naamwoorden: klant, factuur, product, zending. Dat zijn de tabellen. De feiten en eigenschappen die aan een zelfstandig naamwoord hangen — een factuurdatum, een stukprijs, een e-mailadres — zijn zijn kolommen. Een werkwoord dat twee zelfstandige naamwoorden aan elkaar koppelt, zoals “een bestelling wordt door een klant geplaatst”, is een relatie, en die wordt opgeslagen door de identificerende sleutel van de bovenliggende rij als vreemde sleutel in de onderliggende rij te kopiëren.
Wanneer een verband veel-op-veel is. Eén recept gebruikt veel ingrediënten, en één ingrediënt komt in veel recepten voor, dus geen van beide tabellen kan de sleutel van de ander bewaren zonder zichzelf te herhalen. Het antwoord is een derde entiteit waarvan de enige taak is ze te koppelen — de koppeltabel (of associatieve tabel), met één vreemde sleutel per kant, vaak met dat sleutelpaar als eigen primaire sleutel. Een model dat grotendeels uit zulke koppeltabellen bestaat is volkomen normaal: een veel-op-veel-lijn op een whiteboard moet in het echte schema altijd een vakje worden.
Waarom er moeite voor doen voordat de DDL bestaat. Een verkeerde lijn op een tekening kost een minuut om uit te gummen; dezelfde fout na de release gevonden kost een migratie over live gegevens. Een diagram is ook het enige artefact dat niet-ontwikkelaars kunnen beoordelen, en relatiefouten — een kardinaliteit de verkeerde kant op, een ontbrekende unieke sleutel, onderliggende rijen die zonder ouder kunnen blijven — verschijnen hier als duidelijk foute lijnen, terwijl ze in een DDL-bestand van 400 regels tussen de beperkingen verborgen zitten.
Vooruit of achteruit? Deze ontwerper gaat vooruit: eerst modelleren, DDL eruit. De zusterpagina SQL naar ERD gaat de andere kant op — plak bestaande CREATE TABLE-statements en hij bouwt het diagram opnieuw, wat de snellere route is wanneer de database al bestaat.
1 — Tabellen
Bewerken Tabelnaam Kolommen Relaties Actions
2 — Kolommen
Kolom Type PK AI NN UQ Standaard Actions
PK = primaire sleutel, AI = automatisch ophogen / identiteit, NN = niet leeg, UQ = uniek
3 — Relaties (vreemde sleutels)
Kindtabel Kindkolom Actions Oudertabel Oudercolumn Bij verwijderen Actions
Een vreemde sleutel wordt een CONSTRAINT ... FOREIGN KEY-regel in de DDL.
4 — Exporteren
Mermaid-erDiagram-bron
Het JSON-model is het uitwisselingsformaat voor de familie databasetools: plak het in de Migratiegenerator als schema voor/na, of importeer het hier opnieuw om later verder te bewerken.