Projektant ERD

Projektuj schemat relacyjny bez serwera bazy danych: dodawaj tabele, nadawaj im kolumny z typami, kluczami i wartościami domyślnymi, a następnie łącz je relacjami. Diagram związków encji rysuje się na nowo podczas pisania, a ten sam model eksportuje się jako DDL CREATE TABLE dla MySQL, PostgreSQL, SQL Server, SQLite lub Oracle, jako źródło Mermaid erDiagram albo jako przenośny JSON schematu, który można tu ponownie zaimportować albo otworzyć w Generatorze migracji. Wszystko działa lokalnie.
Czym jest ERD? ERD to skrót od diagram związków encji i jest to rysunek projektu bazy danych, a nie zapis gotowej. Pomocne porównanie to plan budynku: działająca baza to budynek, ERD to plan, a nikt nie wylewa betonu najpierw i nie mierzy potem. Ta strona to stół kreślarski tego planu — kształtuje się tu model, a DDL, źródło Mermaid i JSON schematu są drukowane z jednego modelu, więc rysunek nie może odjechać od wygenerowanego SQL.
Ten sam diagram na trzech poziomach. Diagram pojęciowy nazywa tylko to, co ważne, i jak jest powiązane, słowami, które sprawdzi osoba niebędąca programistą. Diagram logiczny dodaje klucze identyfikujące każdą rzecz i rozstrzyga powiązania wiele-do-wielu, nie wchodząc w dialekt żadnego silnika. Diagram fizyczny uzupełnia to, czego wymaga konkretny produkt — szerokości typów, wartości domyślne, dopuszczalność NULL, ograniczenia unikalności, reguły usuwania — i to ten poziom eksportowany tutaj, wybierając MySQL, PostgreSQL, SQL Server, SQLite lub Oracle.
Skąd biorą się pudełka. Przeczytaj opis systemu i podkreśl rzeczowniki: klient, faktura, produkt, przesyłka. To tabele. Fakty i cechy przypisane do rzeczownika — data faktury, cena jednostkowa, adres e-mail — to jego kolumny. Czasownik łączący dwa rzeczowniki, jak w „zamówienie składa klient”, to relacja, a zapisuje się ją przez skopiowanie klucza identyfikującego wiersza nadrzędnego do wiersza podrzędnego jako klucza obcego.
Kiedy połączenie jest wiele-do-wielu. Jeden przepis używa wielu składników, a jeden składnik występuje w wielu przepisach, więc żadna tabela nie może trzymać klucza drugiej bez powtarzania się. Odpowiedzią jest trzecia encja, której jedynym zadaniem jest sparowanie ich — tabela łącząca (asocjacyjna), z jednym kluczem obcym dla każdej strony, często z tą parą kluczy jako własnym kluczem głównym. Model złożony głównie z takich tabel parujących jest całkowicie normalny: linia wiele-do-wielu na tablicy zawsze musi stać się pudełkiem w prawdziwym schemacie.
Po co się męczyć, zanim powstanie DDL. Zła linia na rysunku kosztuje minutę, żeby ją wymazać; ten sam błąd znaleziony po wydaniu kosztuje migrację na żywych danych. Diagram to też jedyny artefakt, który osoby niebędące programistami mogą przejrzeć, a błędy relacji — kardynalność odwrotnie, brak unikalnego klucza, wiersze podrzędne, które mogą zostać bez rodzica — widać tu jako oczywiście złe linie, podczas gdy w pliku DDL o 400 wierszach kryją się wśród ograniczeń.
W przód czy wstecz? Ten projektant idzie w przód: najpierw model, potem DDL. Sąsiednia strona SQL do ERD idzie w drugą stronę — wkleja się istniejące instrukcje CREATE TABLE, a ona odtwarza diagram, co jest szybszą drogą, gdy baza już istnieje.
1 — Tabele
Edytuj Nazwa tabeli Kolumny Relacje Actions
2 — Kolumny
Kolumna Typ PK AI NN UQ Domyślny Actions
PK = klucz główny, AI = autoinkrementacja / tożsamość, NN = nie NULL, UQ = unikalny
3 — Relacje (klucze obce)
Tabela podrzędna Kolumna podrzędna Actions Tabela nadrzędna Kolumna nadrzędna Przy usuwaniu Actions
Klucz obcy zamienia się w linię CONSTRAINT ... FOREIGN KEY w DDL.
4 — Eksport
Źródło Mermaid erDiagram
Model JSON to format wymiany dla rodziny narzędzi baz danych: wklej go do Generatora migracji jako schemat przed/po albo zaimportuj go tutaj ponownie, aby kontynuować edycję później.