ERD-suunnittelija

Suunnittele relaatioskeema ilman tietokantapalvelinta: lisää taulukoita, anna niille sarakkeita tyyppeineen, avaimineen ja oletusarvoineen ja yhdistä ne sitten suhteilla. Entiteetti-suhdekaavio piirtyy uudelleen kirjoittaessasi, ja sama malli viedään CREATE TABLE -DDL:nä MySQL:lle, PostgreSQL:lle, SQL Serverille, SQLitelle tai Oraclelle, Mermaid erDiagram -lähdekoodina tai siirrettävänä skeema-JSON:na, jonka voidaan tuoda takaisin tänne tai avata migraatiogeneraattorissa. Kaikki toimii paikallisesti.
Mikä ERD on? ERD on lyhenne sanoista entiteetti-suhdekaavio, ja se on tietokannan suunnittelupiirros eikä valmiin tietokannan kirjaus. Hyödyllinen vertaus on rakennuspiirros: valmis tietokanta on rakennus, ERD on piirros, eikä kukaan valele betonia ensin ja mittaa sitten. Tämä sivu on piirtopöytä tälle piirrokselle — muotoilet mallin täällä, ja DDL, Mermaid-lähdekoodi ja skeema-JSON tulostetaan kaikki samasta mallista, joten kuva ei voi erkaantua SQL:stä, jonka se tuotti.
Sama kaavio kolmella tasolla. Käsitteellinen ERD nimeää vain ne asiat, jotka ovat tärkeitä, ja niiden suhteet sanoin, jotka ei-ohjelmoija voi tarkistaa. Looginen ERD lisää avaimet, jotka tunnistavat kunkin asian, ja ratkaisee moni-moneen-linkit, pysyen vapaana minkään moottorin murteesta. Fyysinen ERD täyttää sen, mitä yksi tietty tuote vaatii — tyyppien leveydet, oletusarvot, nullable-tila, uniikkirajoitteet, poistosäännöt — ja se on taso, jonka viet täällä, kun valitset MySQL:n, PostgreSQL:n, SQL Serverin, SQLiten tai Oraclen.
Mistä laatikot tulevat. Lue järjestelmän kuvaus ja alleviivaa substantiivit: asiakas, lasku, tuote, lähetys. Ne ovat taulukot. Substantiiviin liittyvät tosiasiat ja ominaisuudet — laskun päivämäärä, yksikköhinta, sähköpostiosoite — ovat sen sarakkeita. Verbi, joka sitoo kaksi substantiivia yhteen, kuten ”tilauksen tekee asiakas”, on suhde, ja se tallennetaan kopioimalla vanhemman rivin tunnisteavain lapsirivin vierasavaimeksi.
Kun linkki on moni-moneen. Yksi resepti käyttää monia ainesosia, ja yksi ainesosa esiintyy monissa resepteissä, joten kumpikaan taulu ei voi säilyttää toisen avainta toistamatta itseään. Vastaus on kolmas entiteetti, jonka ainoa tehtävä on yhdistää ne — liitostaulu (tai assosiatiivinen taulu), jossa on yksi vierasavain kummallekin puolelle, usein niin, että avainpari on sen oma pääavain. Malli, joka on enimmäkseen tällaisia paritustauluja, on täysin normaali: moni-moneen-viiva valkotaulussa pitää aina muuttua laatikoksi oikeassa skeemassa.
Miksi vaivautua ennen DDL:ää. Väärä viiva piirroksella maksaa minuutin pyyhkiä; sama virhe julkaisun jälkeen löydettynä maksaa migraation elävän datan päällä. Piirros on myös se yksi artefakti, jonka ei-kehittäjät voivat tarkistaa, ja suhdevirheet — väärinpäin oleva kardinaliteetti, puuttuva uniikki avain, lapsirivit, jotka voivat jäädä ilman vanhempaa — näkyvät täällä ilmeisen huonoina viivoina, kun taas 400 rivin DDL-tiedostossa ne piiloutuvat rajoitteiden joukkoon.
Eteenpäin vai taaksepäin? Tämä suunnittelija kulkee eteenpäin: ensin malli, sitten DDL ulos. Sisarsivu SQL ERD:ksi kulkee toiseen suuntaan — liitä olemassa olevat CREATE TABLE -lauseet, ja se rakentaa kaavion uudelleen, mikä on nopeampi reitti, kun tietokanta on jo olemassa.
1 — Taulukot
Muokkaa Taulukon nimi Sarakkeet Suhteet Actions
2 — Sarakkeet
Sarake Tyyppi PK AI NN UQ Oletus Actions
PK = pääavain, AI = automaattinen kasvu / identiteetti, NN = ei tyhjä, UQ = uniikki
3 — Suhteet (vierasavaimet)
Lapsitaulukko Lapsen sarake Actions Vanhempitaulukko Vanhemman sarake Poistettaessa Actions
Vierasavain muuttuu DDL:ssä riviksi CONSTRAINT ... FOREIGN KEY.
4 — Vienti
Mermaid erDiagram -lähdekoodi
JSON-malli on tietokantatyökalujen perheen vaihtomuoto: liitä se migraatiogeneraattoriin ennen-ja-jälkeen-skeemana tai tuo se takaisin tänne jatkaakseen muokkausta myöhemmin.