Jak reprezentovat cizí klíč v diagramu ER?

ER Diagramy byly původně použity pouze k reprezentaci ER modelu. Model ER nepoužívá cizí klíče k reprezentaci vztahů. Používá čáry mezi boxy. Řádky mají na obou koncích nebo na obou koncích nějaký druh indikátoru mohutnosti. Někdy bude vztah označen odděleně diamantem.

Dnes je více než polovina ER diagramů plovoucí kolem skutečně diagramy relačního modelu, nikoli ER modelu. Relační model má v tabulkách zahrnuty cizí klíče, které slouží k implementaci vztahů, které model ER identifikuje. A relační model bude mít další tabulku, která se často nazývá „spojovací tabulka“ mezi dvěma tabulkami entit, které jsou propojeny vztahem mnoho k mnoha. Tato spojovací tabulka obsahuje dva nebo více cizích klíčů.

Existuje mnoho způsobů, jak reprezentovat relační model. Snad nejjednodušší je „Diagram vztahu“, který může MS Access vytvořit z dokončené databáze. Bude to docela úplné, pokud tvůrce databáze identifikoval cizí klíče.

Existuje mnoho nástrojů, které jsou pro vytváření diagramů ve větším měřítku sofistikovanější než MS Access. Některé z nich se používají před vytvořením databáze. Některé se používají po.

Komentáře

• V současné době vytvářím pouze diagram na papíře. Můžete prosím ukázat, jak mohou být výše uvedené dvě tabulky (v otázce) zobrazeny v relačním diagramu?
• Pokud budete hledat v “ Transakcích zákazníků s ER diagramem “ získáte spoustu obrázků, které ukazují různé způsoby, jak dělat, co chcete.

Při kreslení diagramů ER jsem použil následující grafickou konvenci: Označte relační čáry názvy sloupců cizího klíče, například:

Tím je jasné, který sloupec v podřízené tabulce je cizím klíčem k nadřazené tabulce. Stav primárního klíče lze určit podtržením příslušného atributu.

Co může být užitečnější, než je tato, je konvence pojmenování, která objasňuje, jaký je primární klíč tabulky (snadno se provádí, pokud používáte náhradní klíče podle konvence) a co je sloupec cizího klíče.

Některé diagramy relačních modelů také obsahují označení účasti klíče nalevo od názvů sloupců v seznamu sloupců (např. “ PK „, “ FK1 „, “ FK2 „, …), které mohou pomoci, zejména pokud máte složené klíče.

Komentáře

• Je tato konvence také někde publikována, nebo je to jen váš (dobrý) nápad?
• @Lorenz it ‚ s můj adaptace pro diagram vztahu fyzických entit verze verze Crow ‚ s nožní notace ( en.wikipedia.o rg / wiki / … ) vydané Jamesem Martinem ( en.wikipedia.org/wiki/James_Martin_(author) ) ve své knize Information Engineering , která jako název vztahů použila název vztahu.Pro mě je to ‚ rozumné rozšíření z logického modelu na fyzický model.
• I když to pomůže, zůstane soukromým nápadem, nebylo to úplně jasné z výrazu „Použil jsem“.

Dávám přednost tomuto formátu, pro ilustraci spojování více ku jedné používám „vrány nohou“

Komentáře

• Mám rád také vrány pro ER diagramy. U relačních diagramů dávám přednost hrotu šipky. Všimněte si, že vrána chodidla jde na “ mnoha “ konci řádku, zatímco šíp jde na “ jeden “ konec řádku.
• V tomto grafu zde chybí pouze symboly FK / PK na koncích řádků 🙂 Přesto tato následná odpověď na první zveřejnění odkazu dlink ‚ získala podle mého názoru příliš málo hlasů. dříve zveřejněný odkaz dlink ‚ byl kritizován, již byl zmíněn v prvním komentáři otázky před @MKSingh, který se zeptal;), ALE! zdá se, že odkaz je lepší, než je tam uvedeno. Pokud sledujete video, které je nabízeno pod “ fyzickými symboly ERD „, ukazuje přesně, jak reprezentovat více FK v ERD, zde je přímý odkaz, přejděte na 7:28, youtube.com/watch?v=QpdhBUYk7Kk

O mnoho let později mějte na paměti různé notace ER diagramů, otázka tedy není dostatečně přesná.

Podívejte se na všechny odpovědi na

https://stackoverflow.com/questions/48191228/is-erd-considered-a-kind-of-uml-diagram#48198083

a

Který z nich je ER diagram? . Jedna odpověď zde dokonce uvádí, že notace Chen je ERD, zatímco notace Crow Foot se říká EAD (Entity Attribute Diagram), viz @JoshuaGuttman.

Notace Chen výslovně neukazuje vztahy FK , jak již vysvětluje přijatá odpověď, zatímco jiné notace to dokážou.

Pokud místo toho použijete například Crow Crow nebo Bakerovu notaci, můžete použít “ nejpřesnější “ odpověď @dlink, kde řádky vedou přesně k FK. Pak stále není jasné, co dělat s kompozitními FK, které vedou ke kompozitním PK, a pravděpodobně kvůli že profesionální programy jednoduše graficky nepropojují konce řádků s FK. Pak je vše, na co se můžete odkazovat, pojmenování, což je dost, pokud budete přísně dodržovat konvenci pojmenování (jako je CustomerID to Customer.ID nebo jiná pravidla) . Viz například Visual Paradigm at https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagram/

vp erd

Tato stránka, LucidCharts má pěkné shrnutí toho, jak by ERD mělo vypadat.

V části Fyzické symboly ERD ukazuje, jak reprezentovat klíče.

[ https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning]

Komentáře

• Welcome dlink. Pokuste se poskytnout důkladné odpovědi, které jsou více než jen odkaz , jinak mohou být odstraněny.