ERD-tervező

Relációs séma tervezése adatbázisszerver nélkül: táblák hozzáadása, oszlopok adása típusokkal, kulcsokkal és alapértékekkel, majd összekapcsolásuk kapcsolatokkal. Az entitáskapcsolati diagram gépelés közben újrarajzolódik, ugyanez a modell CREATE TABLE DDL-ként exportálható MySQL, PostgreSQL, SQL Server, SQLite vagy Oracle számára, Mermaid erDiagram forrásként, vagy hordozható sémajsonként, amely itt újraimportálható, vagy a Migrációgenerátorban nyitható meg. Minden helyben fut.
Mi az az ERD? Az ERD az entitás-kapcsolati diagram rövidítése, és egy adatbázis tervrajza, nem egy kész adatbázis nyilvántartása. Hasznos hasonlat az épülettervrajz: az futó adatbázis az épület, az ERD a tervrajz, és senki nem önti először a betont, és mér utólag. Ez az oldal a tervrajz rajzasztala — itt formálható a modell, és a DDL, a Mermaid-forrás és a sémajson mind ebből a modellből készül, így a kép nem térhet el attól az SQL-től, amelyet létrehozott.
Ugyanaz a diagram három szinten. A fogalmi ERD csak a lényeges dolgokat és azok kapcsolatát nevezi meg olyan szavakkal, amelyeket egy nem programozó is ellenőrizhet. A logikai ERD hozzáadja azokat a kulcsokat, amelyek azonosítják az egyes dolgokat, és feloldja a sok-a-sokhoz kapcsolatokat, miközben nem tartalmaz egyetlen motor dialektusát sem. A fizikai ERD kitölti azt, amit egy adott termék megkövetel — típusszélességek, alapértékek, nullázhatóság, egyedi megkötések, törlési szabályok — ez az a szint, amelyet itt exportálnak, ha MySQL, PostgreSQL, SQL Server, SQLite vagy Oracle mellett döntenek.
Honnan származnak a dobozok. A rendszer leírásából alá kell húzni a főneveket: vásárló, számla, termék, szállítmány. Ezek a táblák. A főnévhez kapcsolódó tények és tulajdonságok — számladátum, egységár, e-mail-cím — annak oszlopai. Az az ige, amely két főnevet köt össze, mint az „a rendelést a vásárló adja le”, kapcsolat, és úgy tárolják, hogy a szülősor azonosító kulcsát idegen kulcsként a gyermeksorba másolják.
Amikor a kapcsolat sok-a-sokhoz. Egy recept sok hozzávalót használ, és egy hozzávaló sok receptben szerepel, így egyik tábla sem tarthatja meg a másik kulcsát anélkül, hogy ismétlődne. A válasz egy harmadik entitás, amelynek egyetlen feladata az összepárosítás — az összekötő (vagy asszociatív) tábla, amely mindkét oldalhoz egy idegen kulcsot tartalmaz, gyakran ezt a kulcspárt saját elsődleges kulcsaként. Egy olyan modell, amely többnyire ilyen párosító táblákból áll, teljesen normális: a táblán húzott sok-a-sok vonalnak a valódi sémában mindig dobozzá kell válnia.
Miért érdemes a DDL előtt foglalkozni vele. Egy rossz vonal a rajzon egy percbe kerül a törlés; ugyanaz a hiba a kiadás után egy élő adatokon futó migrációba kerül. A diagram emellett az egyetlen olyan műtárgy, amelyet a nem fejlesztők is átnézhetnek, és a kapcsolati hibák — fordítva álló számosság, hiányzó egyedi kulcs, olyan gyermeksorok, amelyek szülő nélkül maradhatnak — itt nyilvánvalóan rossz vonalakként jelennek meg, míg egy 400 soros DDL-fájlban a megkötések közé vegyülnek.
Előre vagy visszafelé? Ez a tervező előre megy: előbb a modell, aztán a DDL. A testvéroldal, a SQL-ből ERD oldal az ellenkező irányban dolgozik — meglévő CREATE TABLE utasításokat illesztve újraépíti a diagramot, ami gyorsabb út, ha az adatbázis már létezik.
1 — Táblák
Szerkesztés Táblanév Oszlopok Kapcsolatok Actions
2 — Oszlopok
Oszlop Típus PK AI NN UQ Alapértelmezett Actions
PK = elsődleges kulcs, AI = automatikus növelés / identitás, NN = nem nulla, UQ = egyedi
3 — Kapcsolatok (idegen kulcsok)
Gyermek tábla Gyermek oszlop Actions Szülő tábla Szülő oszlop Törléskor Actions
Az idegen kulcs a DDL-ben egy CONSTRAINT ... FOREIGN KEY sort eredményez.
4 — Exportálás
Mermaid erDiagram forrás
A JSON-modell az adatbázis-eszközcsalád csereformátuma: beilleszthető a Migrációgenerátorba korábbi/későbbi sémaként, vagy itt újraimportálható, hogy később tovább lehessen szerkeszteni.