Anta at jeg har en «Transaksjoner» -tabell som har en kolonne «Kunde-ID» (utenlandsk nøkkel) og en kundetabell med «ID» (Primær nøkkel) . Hvordan viser jeg forholdet mellom de to tabellene og viser at «Kunde-ID» er den utenlandske nøkkelen til «Transaksjoner» -tabellen, som er den primære nøkkelen i «Kunde» -tabellen?
Jeg googlet dette spørsmålet og også sjekket dette forumet for spørsmålet mitt, men kunne ikke finne et eksakt eksempel med et diagram som adresserer spørsmålet mitt.
Forklar meg, hvis mulig, med et diagram.
Kommentarer
- Jeg fant følgende lenke som sier at vi bare kan vise en fremmed nøkkel i et konseptuelt ER-diagram. lucidchart.com / sider / ER-diagram-symboler-og-betydning . Fortell meg hvordan jeg kan gjøre det.
- Jeg ‘ har lært på skolen (!!) at primærnøkler kan vises med en rett understrekning under attributtet (e) og fremmednøkkel (r) med en stiplet linje
- Ok. Men hvordan viser jeg at den utenlandske nøkkelen i en tabellen er den samme som hovednøkkelen til en annen tabell hvis navn er forskjellige i deres respektive ta bles (som spurt i eksemplet i spørsmålet om ‘ ID ‘ og ‘ Kunde ID ‘)?
- Da dette spørsmålet refererer til en «No-Chen» notasjon (fordi den ber om å vise fk relasjoner), har jeg åpnet en ny spørsmål eksplisitt for en ER-modell i Chen-notasjon på dba.stackexchange.com/questions/271264/…
Svar
ER Diagrammer ble opprinnelig bare brukt til å representere ER-modellen. ER-modellen bruker ikke fremmede nøkler til å representere relasjoner. Den bruker linjer mellom boksene. Linjene har en slags indikator for kardinalitet i hver ende eller begge ender. Noen ganger vil et forhold være angitt separat med en diamant.
I dag er mer enn halvparten av ER-diagrammer som flyter rundt, virkelig diagrammer over en relasjonsmodell, og ikke av en ER-modell. En relasjonsmodell har utenlandske nøkler inkludert i tabellene, og disse tjener til å implementere relasjonene som ER-modellen identifiserer. Og en relasjonsmodell vil ha en ekstra tabell, ofte kalt en «koblingstabell» mellom to enhetstabeller som er knyttet sammen av et mange-til-mange forhold. Denne veikryssingstabellen inneholder to eller flere utenlandske nøkler.
Det er mange måter å representere en relasjonsmodell på. Kanskje det enkleste er «Relationship Diagram» som MS Access kan produsere fra en fullført database. Dette vil være ganske komplett hvis databasebyggeren har identifisert de utenlandske nøklene.
Det er mange verktøy som er mer sofistikerte enn MS Access for å lage diagrammer i større skala. Noen av disse brukes før man bygger databasen. Noen brukes etter.
Kommentarer
- For øyeblikket lager jeg bare et diagram på et papir. Kan du vise hvordan de to ovennevnte tabellene (i spørsmålet) kan vises i et relasjonsdiagram?
- Hvis du vil søke på » ER Diagram Kunder Transaksjoner » du får mange bilder som viser forskjellige måter å gjøre det du vil.
Svar
Når jeg tegner ER-diagrammer, har jeg brukt følgende grafiske konvensjon: Merk forholdslinjene med kolonnenavn (e) for den utenlandske nøkkelen, slik:
Dette gjør det klart hvilken kolonne i underordnet tabell som er fremmednøkkelen til overordnet tabell. Å indikere status for primærnøkkel kan gjøres ved å understreke det aktuelle attributtet.
Det som kan være mer nyttig enn dette, er en navngivningskonvensjon som gjør det klart hva som er primærnøkkelen til en tabell (lett gjort hvis du bruker surrogatnøkler etter konvensjon) og hva som er en utenlandsk nøkkelkolonne.
Noen relasjonsmodelldiagrammer inkluderer også en nøkkeldeltakelsesetikett til venstre for kolonnenavnene i kolonnelisten (f.eks. » PK «, » FK1 «, » FK2 «, …) som kan hjelpe spesielt hvis du har sammensatte nøkler.
Kommentarer
- Blir denne konvensjonen også publisert et sted, eller er det bare din (gode) idé?
- @Lorenz det ‘ er min tilpasning for et fysisk forholdsdiagram av versjonen av kråke ‘ s fotnotasjon ( en.wikipedia.o rg / wiki / … ) publisert av James Martin ( en.wikipedia.org/wiki/James_Martin_(author) ) i sin bok Information Engineering som brukte forholdsnavnet som merkelapp på relasjoner.For meg er det ‘ en fornuftig utvidelse fra den logiske modellen til den fysiske modellen.
- Selv om det hjelper, forblir det en privat idé da, dette var ikke helt klart fra uttrykket “Jeg har brukt”.
Svar
Jeg foretrekker dette formatet ved å bruke «kråkeben» for å illustrere de mange-til-en-sammenføyningene
Kommentarer
- Jeg liker også kråkeføtter for ER-diagrammer. For relasjonsdiagrammer foretrekker jeg pilspissen. Vær oppmerksom på at en kråkefot går på » mange » enden av en linje, mens et pilspiss går på » en » slutten av en linje.
- Det er bare FK / PK-symbolene som mangler på linjen slutter i denne grafen her 🙂 Likevel fikk dette oppfølgingssvaret til dlink ‘ sitt første innlegg av lenken for få stemmer etter min mening. dlink ‘ s tidligere postede lenke ble kritisert, det ble allerede nevnt i den første kommentaren til spørsmålet før av @MKSingh som hadde spurt;), MEN! det ser ut til at lenken er bedre enn oppgitt der. Hvis du ser på videoen som tilbys under » fysiske ERD-symboler «, viser den nøyaktig hvordan du skal representere flere FK i en ERD, her er den direkte lenken, gå til 7:28, youtube.com/watch?v=QpdhBUYk7Kk
Svar
Mange år senere, vær oppmerksom på de forskjellige notasjonene av ER-diagrammer, spørsmålet er dermed ikke presist nok.
Ta en titt på alle svar på
https://stackoverflow.com/questions/48191228/is-erd-considered-a-kind-of-uml-diagram#48198083
og
Hvilken er et ER-diagram? . Et svar her sier til og med at Chen-notasjonen er ERD, mens Crow Foot-notasjon sies å være en EAD (Entity Attribute Diagram), se @JoshuaGuttman.
Chen-notasjonen viser ikke eksplisitt FK-forholdet , som det aksepterte svaret allerede forklarer, mens andre notasjoner kan gjøre dette.
Hvis du for eksempel tar Crow Foot eller Bakers notasjon i stedet, kan du ta » mest presise » svar på @dlink hvor linjene fører nøyaktig til FK-ene. Da er det fortsatt uklart hva du skal gjøre med sammensatte FK-er som fører til sammensatte PK-er, og sannsynligvis pga. at profesjonelle programmer rett og slett ikke kobler linjeavslutningene grafisk til FK-ene. Da er navngivning alt du kan referere til, noe som uansett er nok hvis du følger en navngivningskonvensjon (som CustomerID til Customer.ID, eller andre regler) Se for eksempel Visual Paradigm på https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagram/
Svar
Denne siden av LucidCharts har en fin skriving om hvordan ERD skal se ut.
Under Physical ERD Symbols viser den hvordan du representerer nøkler.
[ https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning]
Kommentarer
- Velkomstdlink. Prøv å gi grundige svar som er mer enn bare en lenke ellers kan de bli fjernet.