SQL у ERD

Вставте один або кілька операторів CREATE TABLE, і цей інструмент намалює схему: кожна таблиця стає сутністю, стовпці — атрибутами з позначками PK / FK, а обмеження FOREIGN KEY — лініями зв'язків. Коли схема не оголошує зовнішніх ключів, стовпці на кшталт customer_id пропонуються як виведені зв'язки, які можна залишити або прибрати. Скопіюйте джерело Mermaid erDiagram або експортуйте діаграму як SVG / PNG. Усе працює локально — жодна схема ніколи не покидає ваш браузер.
Що таке ERD? ERD означає Entity Relationship Diagram — діаграма сутність-зв'язок, картина того, як організовано базу даних. Вона малюється з трьох видів фігур: сутностей (таблиць, намальованих як прямокутники), атрибутів (стовпців, перелічених всередині прямокутника) і зв'язків (ліній, що з'єднують два прямокутники). Прийом походить з моделі сутність-зв'язок Пітера Чена 1976 року і досі є звичайним способом накреслити схему перед написанням будь-якого DDL: добра ERD показує з першого погляду, які таблиці існують, що зберігає кожен рядок і як рядок однієї таблиці вказує на рядок іншої — читабельно для людей, які не хочуть читати SQL.
Entity — one thing the system keeps data about, such as a customer, an order or a product. In a relational database each entity becomes one table.
Attribute — one fact recorded for every row of an entity, such as a name, a price or a date. Each attribute becomes one column.
Relationship — an association between two entities, implemented by a foreign key: the child table stores the parent’s key, and the diagram turns that column into a line.
PK / FK — a primary key (PK) identifies each row of a table uniquely; a foreign key (FK) holds the primary key of another table and is what a relationship line represents.
Кардинальність — скільки рядків дозволено на кожному кінці лінії: один-до-одного, один-до-багатьох або багато-до-багатьох. Ця сторінка малює нотацію «воронина лапка», яку використовує Mermaid (див. легенду на кроці 4).
Нотації: нотація Чена використовує ромби для зв'язків і еліпси для атрибутів; нотація «воронина лапка» (та, що тут малюється) стискає сутність в один прямокутник з атрибутами всередині і позначає багатий кінець лінії трипалою «вороновою лапкою»; діаграми класів UML описують ту саму структуру класами, операціями й кратностями. Усі три кажуть те саме про схему — відрізняються лише символи.
1 — Схема таблиці (DDL)
2 — Сутності
Намалювати Таблиця Стовпці Зв'язки Атрибути
Таблиць ще не розібрано.
3 — Зв'язки
Використання Дитина (багато) Actions Батько (один) Джерело Actions
Зв'язків ще немає.
Додати зв'язок вручну:
→
4 — Діаграма
Вихідний код Mermaid erDiagram
Як читаються зв'язки: зовнішній ключ у дочірній таблиці дає PARENT ||--o{ CHILD. Сутності й атрибути зберігають імена з DDL, а символи, яких Mermaid не може намалювати (пробіли, тире), показуються як підкреслення. Типи спрощуються до базового слова (DECIMAL(10,2) → DECIMAL), бо синтаксис діаграми не приймає параметрів.
Позначення кардинальності (лапка «воронина лапка»): позначка біля сутності каже, скільки рядків може стояти на цьому кінці лінії — || рівно один, o| нуль або один, o{ нуль або багато, |{ один або багато. Отже, PARENT ||--o{ CHILD читається як «один рядок батька може бути на посилання нульових, одного або багатьох рядків дитини, і кожен рядок дитини вказує рівно на одного батька» — класичний зв'язок «один до багатьох».
Many-to-many is never a single line: a product can appear in many orders and an order can hold many products, so the schema stores a join table (order_items) whose two foreign keys become two one-to-many lines. Read through that middle box and the many-to-many is there.