Navrhovač ERD

Návrh relačnej schémy bez databázového servera: pridajú sa tabuľky, dajú sa im stĺpce s typmi, kľúčmi a predvolenými hodnotami a potom sa prepoja vzťahmi. Diagram entít a vzťahov sa prekresľuje počas písania a rovnaký model sa exportuje ako CREATE TABLE DDL pre MySQL, PostgreSQL, SQL Server, SQLite alebo Oracle, ako zdroj Mermaid erDiagram alebo ako prenosný JSON schémy, ktorý sa dá znova importovať sem alebo otvoriť v Generátore migrácií. Všetko beží lokálne.
Čo je ERD? ERD je skratka pre diagram entít a vzťahov a je to návrhový výkres databázy, nie záznam hotovej. Užitočné prirovnanie je stavebný plán: bežiaca databáza je budova, ERD je plán a nikto neleje betón skôr, než si niečo odmeria. Táto stránka je kreslenie pre tento plán — model sa tu tvaruje a DDL, zdroj Mermaid aj JSON schémy sa vypisujú z jedného modelu, takže obrázok nemôže odísť od SQL, ktoré vytvoril.
Ten istý diagram na troch úrovniach. Konceptuálny ERD pomenúva iba veci, na ktorých záleží, a ich vzťahy slovami, ktoré môže skontrolovať aj neprogramátor. Logický ERD pridáva kľúče, ktoré každú vec identifikujú, a rieši vzťahy mnoho-k-mnoho, pričom zostáva bez dialektu akéhokoľvek enginu. Fyzický ERD dopĺňa to, čo vyžaduje konkrétny produkt — šírky typov, predvolené hodnoty, prípustnosť NULL, jedinečné obmedzenia, pravidlá pri mazaní — a na tejto úrovni sa exportuje, keď sa vyberie MySQL, PostgreSQL, SQL Server, SQLite alebo Oracle.
Odkiaľ sa berú políčka. Prečíta sa opis systému a podčiarknu sa podstatné mená: zákazník, faktúra, produkt, zásielka. Sú to tabuľky. Fakty a vlastnosti pripojené k podstatnému menu — dátum faktúry, jednotková cena, e-mailová adresa — sú jeho stĺpce. Sloveso, ktoré spája dve podstatné mená, ako v „objednávku zadáva zákazník“, je vzťah a uloží sa tak, že sa identifikujúci kľúč rodičovského riadku skopíruje do podriadeného riadku ako cudzí kľúč.
Keď je prepojenie mnoho-k-mnoho. Jeden recept používa veľa ingrediencií a jedna ingrediencia sa objaví vo viacerých receptoch, takže žiadna tabuľka nemôže držať kľúč tej druhej bez opakovania. Odpoveďou je tretia entita, ktorej jediná úloha je ich spárovať — spojovacia (asociatívna) tabuľka, ktorá drží jeden cudzí kľúč pre každú stranu, často s týmto párom kľúčov ako vlastným primárnym kľúčom. Model, ktorý je väčšinou takýmito spárovacími tabuľkami, je úplne normálny: čiara mnoho-k-mnoho na tabuli sa v skutočnej schéme vždy musí stať políčkom.
Prečo sa s tým namáhať pred existenciou DDL. Chybná čiara na výkrese stojí minútu gumy; tá istá chyba zistená po vydaní stojí migráciu nad živými dátami. Diagram je navyše jediný artefakt, ktorý môžu skontrolovať neprogramátori, a chyby vzťahov — kardinalita naopak, chýbajúci jedinečný kľúč, podriadené riadky, ktoré môžu zostať bez rodiča — sa tu ukážu ako zjavne zlé čiary, kým v 400-riadkovom súbore DDL sa skryjú medzi obmedzeniami.
Vpred alebo vzad? Tento návrhár ide dopredu: najprv model, potom DDL. Súrodenecká stránka SQL na ERD ide opačne — vloží sa existujúci príkaz CREATE TABLE a obnoví sa diagram, čo je rýchlejšia cesta, keď databáza už existuje.
1 — Tabuľky
Upraviť Názov tabuľky Stĺpce Vzťahy Actions
2 — Stĺpce
Stĺpec Typ PK AI NN UQ Predvolený Actions
PK = primárny kľúč, AI = automatické zvyšovanie / identita, NN = nie NULL, UQ = jedinečný
3 — Vzťahy (cudzie kľúče)
Podriadená tabuľka Podriadený stĺpec Actions Nadradená tabuľka Rodičovský stĺpec Pri mazaní Actions
Cudzí kľúč sa v DDL zmení na riadok CONSTRAINT ... FOREIGN KEY.
4 — Export
Zdroj Mermaid erDiagram
Model JSON je výmenný formát rodiny databázových nástrojov: vloží sa do Generátora migrácií ako schéma pred a po zmene, alebo sa znova importuje sem, aby sa úprava mohla neskôr pokračovať.