SQL în ERD

Se lipesc una sau mai multe instrucțiuni CREATE TABLE și acest instrument desenează schema: fiecare tabelă devine o entitate, coloanele devin atribute marcate PK / FK, iar constrângerile FOREIGN KEY devin linii de relație. Când o schemă nu declară chei externe, coloane precum customer_id sunt propuse ca relații deduse, care se pot păstra sau elimina. Se copiază sursa Mermaid erDiagram sau se exportă diagrama ca SVG / PNG. Totul rulează local — nicio schemă nu părăsește vreodată browserul.
Ce este un ERD? ERD înseamnă Diagramă Entitate-Relație — o imagine a modului în care este organizată o bază de date. Se desenează din trei tipuri de forme: entități (tabelele, desenate ca niște casete), atribute (coloanele listate în interiorul casetei) și relații (liniile care unesc două casete). Tehnica provine din modelul entitate-relație al lui Peter Chen din 1976 și rămâne modul obișnuit de a schița o schemă înainte de a scrie orice DDL: un ERD bun arată dintr-o privire ce tabele există, ce stochează fiecare rând și cum indică un rând dintr-o tabelă spre un rând dintr-o altă tabelă — ușor de citit și pentru cei care nu vor să citească 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.
Cardinalitate — câte rânduri sunt permise la fiecare capăt al unei linii: unu-la-unu, unu-la-mai-mulți sau mai-mulți-la-mai-mulți. Pagina desenează notația cu laba cioarei pe care o folosește Mermaid (vezi legenda de la pasul 4).
Notații: notația Chen folosește romburi pentru relații și elipse pentru atribute; notația cu laba cioarei (cea desenată aici) comprimă o entitate într-o singură casetă cu atributele listate înăuntru și marchează capătul „multiplu” al unei linii cu o „labă de cioară” cu trei degete; diagramele de clase UML descriu aceeași structură prin clase, operații și multiplicități. Toate trei spun același lucru despre schemă — diferă doar simbolurile.
1 — Schema tabelelor (DDL)
2 — Entități
Desenează Tabelă Coloane Relații Atribute
Încă nu s-a analizat niciun tabel.
3 — Relații
Utilizare Copil (mai mulți) Actions Părinte (unul) Sursă Actions
Încă nu există relații.
Se adaugă o relație manual:
→
4 — Diagrama
Sursa erDiagram Mermaid
Cum se citesc relațiile: o cheie externă din tabela copil produce PARENT ||--o{ CHILD. Entitățile și atributele păstrează numele din DDL, iar caracterele pe care Mermaid nu le poate desena (spații, liniuțe) apar ca liniuțe de subliniere. Tipurile sunt simplificate la cuvântul de bază (DECIMAL(10,2) → DECIMAL), deoarece sintaxa diagramei nu acceptă parametri.
Simboluri de cardinalitate (laba cioarei): marcajul de lângă o entitate arată câte rânduri pot sta la acel capăt al liniei — || exact unul, o| zero sau unul, o{ zero sau mai multe, |{ unul sau mai multe. Așadar PARENT ||--o{ CHILD se citește „un rând părinte poate fi referit de zero, unu sau mai multe rânduri copil, iar fiecare rând copil indică exact un părinte” — legătura clasică unu-la-mai-mulți.
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.