Stel dat ik een “Transactions” -tabel heb met een kolom “Customer ID” (externe sleutel) en een klantentabel met “ID” (primaire sleutel) . Hoe laat ik de relatie tussen de twee tabellen zien en laat ik zien dat de “Klant-ID” de externe sleutel is van de “Transactietabel”, die de primaire sleutel is in de “Klant” -tabel?
Ik heb deze vraag gegoogled en controleerde ook dit forum voor mijn vraag, maar kon geen exact voorbeeld vinden met een diagram dat mijn vraag behandelt.
Leg me, indien mogelijk, uit met een diagram.
Opmerkingen
- Ik vond de volgende link die zegt dat we alleen een Foreign Key kunnen tonen in een conceptueel ER-diagram. lucidchart.com / pages / ER-diagram-symbolen-en-betekenis . Vertel me alsjeblieft hoe ik het kan doen.
- Ik ‘ heb op school geleerd (!!) dat primaire sleutels kunnen worden weergegeven met een rechte onderstreping onder het attribuut (en) en externe sleutel (s) met een stippellijn.
- Oké. Maar hoe laat ik zien dat de externe sleutel in één table is hetzelfde als de primaire sleutel van een andere tabel waarvan de namen verschillen in hun respectievelijke ta bles (zoals gevraagd in het voorbeeld in de vraag over ‘ ID ‘ en ‘ klant ID ‘)?
- Aangezien deze vraag verwijst naar een “No-Chen” -notatie (omdat er wordt gevraagd om fk-relaties te tonen), heb ik een nieuwe vraag expliciet naar een ER-model in Chen-notatie op dba.stackexchange.com/questions/271264/…
Answer
ER-diagrammen werden oorspronkelijk alleen gebruikt om het ER-model weer te geven. Het ER-model gebruikt geen externe sleutels om relaties weer te geven. Het maakt gebruik van lijnen tussen dozen. De lijnen hebben aan beide uiteinden of beide uiteinden een soort indicator voor kardinaliteit. Soms wordt een relatie afzonderlijk aangegeven met een diamant.
Tegenwoordig zijn meer dan de helft van de ER-diagrammen die rondzweven in feite diagrammen van een relationeel model, en niet van een ER-model. Een relationeel model heeft de externe sleutels in de tabellen, en deze dienen om de relaties te implementeren die het ER-model identificeert. En een relationeel model zal een extra tabel hebben, vaak een “junctietabel” genoemd tussen twee entiteitstabellen die zijn verbonden door een veel-op-veel-relatie. Deze junctietabel bevat twee of meer externe sleutels.
Er zijn veel manieren om een relationeel model weer te geven. Misschien wel het eenvoudigste is het “Relatiediagram” dat MS Access kan produceren vanuit een voltooide database. Dit zal redelijk compleet zijn, als de databasebouwer de externe sleutels heeft geïdentificeerd.
Er zijn veel tools die geavanceerder zijn dan MS Access voor het maken van diagrammen op grotere schaal. Sommige hiervan worden gebruikt voordat de database wordt gebouwd. Sommige worden daarna gebruikt.
Opmerkingen
- Momenteel maak ik alleen maar een diagram op papier. Kunt u alstublieft laten zien hoe de bovenstaande twee tabellen (in de vraag) kunnen worden afgebeeld in een relatiediagram?
- Als u zoekt op ” ER-diagram Klantentransacties ” je krijgt veel afbeeldingen die verschillende manieren laten zien om te doen wat je wilt.
Antwoord
Bij het tekenen van ER-diagrammen heb ik de volgende grafische conventie gebruikt: Label de relatielijnen met de kolomnaam (-namen) van de externe sleutel, zoals:
Dit maakt duidelijk welke kolom in de onderliggende tabel de externe sleutel is naar de bovenliggende tabel. Het aangeven van de status van de primaire sleutel kan worden gedaan door het attribuut in kwestie te onderstrepen.
Wat wellicht nuttiger is dan dit, is een naamgevingsconventie die duidelijk maakt wat de primaire sleutel van een tabel is (gemakkelijk te doen als u surrogaatsleutels volgens afspraak) en wat is een kolom met een externe sleutel.
Sommige relationele modeldiagrammen bevatten ook een sleutelparticipatielabel links van de kolomnamen in de lijst met kolommen (bijv. ” PK “, ” FK1 “, ” FK2 “, …) wat vooral kan helpen als u samengestelde sleutels heeft.
Opmerkingen
- Wordt deze conventie ook ergens gepubliceerd, of is het gewoon jouw (goede) idee?
- @Lorenz it ‘ s mijn aanpassing voor een fysieke entiteit-relatiediagram van de versie van crow ‘ s voetnotatie ( en.wikipedia.o rg / wiki / … ) gepubliceerd door James Martin ( en.wikipedia.org/wiki/James_Martin_(author) ) in zijn boek Information Engineering , waarin de relatienaam als label voor relaties werd gebruikt.Voor mij is het ‘ een verstandige uitbreiding van het logische model naar het fysieke model.
- Zelfs als het helpt, blijft het een privé-idee, maar dit was niet helemaal duidelijk uit de uitdrukking “ik heb gebruikt”.
Antwoord
Ik geef de voorkeur aan dit formaat, gebruik “kraaienpootjes” om de veel-op-een joins te illustreren.
Reacties
- Ik hou ook van kraaienpootjes voor ER-diagrammen. Voor relationele diagrammen geef ik de voorkeur aan de pijlpunt. merk op dat er een kraaienpoot op het ” vele ” uiteinde van een regel gaat, terwijl een pijlpunt op het één ” einde van een regel.
- Er ontbreken alleen de FK / PK-symbolen aan de regeluiteinden in deze grafiek hier 🙂 Toch kreeg dit vervolgantwoord op de eerste plaatsing van de link door dlink ‘ naar mijn mening te weinig stemmen. dlink ‘ s eerder geplaatste link werd bekritiseerd, deze werd al eerder genoemd in de eerste opmerking van de vraag door @MKSingh die had gevraagd;), MAAR! het lijkt erop dat de link beter is dan daar vermeld. Als u de video bekijkt die wordt aangeboden onder ” fysieke ERD-symbolen “, laat deze precies zien hoe u meerdere FK in een ERD weergeeft, hier is de directe link, ga naar 7:28, youtube.com/watch?v=QpdhBUYk7Kk
Answer
Let vele jaren later op de verschillende notaties van ER-diagrammen, de vraag is dus niet precies genoeg.
Kijk eens naar alle antwoorden op
https://stackoverflow.com/questions/48191228/is-erd-considered-a-kind-of-uml-diagram#48198083
en
Welke is een ER-diagram? . Een antwoord hier stelt zelfs dat de Chen-notatie de ERD is, terwijl Crow Foot-notatie een EAD (Entity Attribute Diagram) zou zijn, zie @JoshuaGuttman.
De Chen-notatie toont niet expliciet de FK-relaties , zoals het geaccepteerde antwoord al uitlegt, terwijl andere notaties dit kunnen.
Als je bijvoorbeeld de Crow Foot of Baker s notatie gebruikt, zou je de ” meest nauwkeurige ” antwoord van @dlink waar de regels precies naar de FKs leiden. Dan is het nog steeds onduidelijk wat te doen met samengestelde FKs die tot samengestelde PKs leiden, en waarschijnlijk vanwege dat professionele programmas de regeluitgangen simpelweg niet grafisch koppelen aan de FKs. Dan is naamgeving alles waarnaar u kunt verwijzen, wat sowieso voldoende is als u zich strikt aan een naamgevingsconventie houdt (zoals CustomerID tot Customer.ID of andere regels) . Zie bijvoorbeeld Visual Paradigm op https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagram/
Antwoord
Deze pagina, door LucidCharts heeft een mooie beschrijving van hoe ERD eruit zou moeten zien.
Onder Fysieke ERD-symbolen laat het zien hoe sleutels moeten worden weergegeven.
[ https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning]
Reacties
- Welkom dlink. Probeer grondige antwoorden te geven die meer zijn dan alleen een link , anders kunnen ze worden verwijderd.