Návrhář ERD

Navrhněte relační schéma bez databázového serveru: přidejte tabulky, dejte jim sloupce s typy, klíči a výchozími hodnotami a poté je propojte vztahy. Diagram vztahů entit se při psaní překresluje a stejný model lze exportovat jako CREATE TABLE DDL pro MySQL, PostgreSQL, SQL Server, SQLite nebo Oracle, jako zdroj Mermaid erDiagram, nebo jako přenosné JSON schématu, které zde můžete znovu importovat nebo otevřít v Generátoru migrací. Vše běží lokálně.
Co je ERD? ERD je zkratka pro diagram vztahů entit a je to návrhový výkres databáze, nikoli záznam hotové. Užitečné přirovnání je stavební plán: běžící databáze je budova, ERD je plán a nikdo nejdřív nalije beton a měří až potom. Tato stránka je kreslicí stůl pro tento plán — model tvarujete zde a DDL, zdroj Mermaid i JSON schématu se všechny tisknou z jednoho modelu, takže obrázek nemůže odplout od SQL, které vytvořil.
Stejný diagram na třech úrovních. Konceptuální ERD pojmenovává jen věci, na nichž záleží, a to, jak spolu souvisejí, slovy, která ověří i nevývojář. Logický ERD přidává klíče, které každou věc identifikují, a řeší vazby mnoho-k-mnoha, ale zůstává bez dialektu kteréhokoli enginu. Fyzický ERD doplňuje to, co vyžaduje konkrétní produkt — šířky typů, výchozí hodnoty, nulovatelnost, unikátní omezení, pravidla mazání — a na této úrovni exportujete zde, když zvolíte MySQL, PostgreSQL, SQL Server, SQLite nebo Oracle.
Odkud se berou krabice. Přečtěte si popis systému a podtrhněte podstatná jména: zákazník, faktura, produkt, zásilka. To jsou tabulky. Skutečnosti a vlastnosti připojené k podstatnému jménu — datum faktury, jednotková cena, e-mailová adresa — jsou jeho sloupce. Sloveso, které spojuje dvě podstatná jména, jako v „objednávku zadá zákazník“, je vztah a ukládá se tak, že se identifikační klíč rodičovského řádku zkopíruje do podřízeného řádku jako cizí klíč.
Kdy je vazba mnoho-k-mnoha. Jeden recept používá mnoho ingrediencí a jedna ingredience se objeví v mnoha receptech, takže žádná z tabulek nemůže držet klíč té druhé, aniž by se opakovala. Odpovědí je třetí entita, jejímž jediným úkolem je je spárovat — spojovací (nebo asociativní) tabulka, která drží jeden cizí klíč za každou stranu, často s touto dvojicí klíčů jako vlastním primárním klíčem. Model, který je z velké části takovými spárovacími tabulkami, je zcela normální: čára mnoho-k-mnoha na tabuli se vždy musí v reálném schématu proměnit v krabici.
Proč to řešit dřív, než existuje DDL. Špatná čára na výkresu stojí minutu vymazání; táž chyba nalezená po vydání stojí migraci nad živými daty. Diagram je také jediný artefakt, který mohou posoudit i nevývojáři, a chyby vztahů — kardinalita obráceně, chybějící unikátní klíč, podřízené řádky, které mohou zůstat bez rodiče — se zde ukážou jako zjevně špatné čáry, zatímco v souboru DDL o 400 řádcích se schovají mezi omezeními.
Dopředu, nebo zpětně? Tento návrhář jde dopředu: nejprve model, DDL ven. Sesterská stránka SQL do ERD jde opačným směrem — vložíte existující příkazy CREATE TABLE a ona diagram znovu sestaví, což je rychlejší cesta, když databáze už existuje.
1 — Tabulky
Upravit Název tabulky Sloupce Vztahy Actions
2 — Sloupce
Sloupec Typ PK AI NN UQ Výchozí Actions
PK = primární klíč, AI = automatické číslování / identita, NN = není null, UQ = unikátní
3 — Vztahy (cizí klíče)
Podřízená tabulka Podřízený sloupec Actions Nadřazená tabulka Nadřazený sloupec Při smazání Actions
Cizí klíč se v DDL promění na řádek CONSTRAINT ... FOREIGN KEY.
4 — Export
Zdroj Mermaid erDiagram
Model JSON je výměnný formát rodiny databázových nástrojů: vložte jej do Generátoru migrací jako schéma před/po, nebo jej zde znovu importujte, abyste mohli později dál upravovat.