Antag, at jeg har en “Transaktioner” -tabel, der har en kolonne “Kunde-id” (fremmed nøgle) og en kundetabel med “ID” (primær nøgle) . Hvordan viser jeg forholdet mellem de to tabeller og viser, at “kunde-id” er den fremmede nøgle til “transaktioner” -tabellen, som er den primære nøgle i tabellen “kunde”?

Jeg googlede dette spørgsmål og tjekket også dette forum for min forespørgsel, men kunne ikke finde et eksakt eksempel med et diagram, der adresserer mit spørgsmål.

Forklar mig, hvis det er muligt, med et diagram.

Kommentarer

  • Jeg fandt følgende link, der siger, at vi kun kan vise en fremmed nøgle i et konceptuelt ER-diagram. lucidchart.com / sider / ER-diagram-symboler-og-betydning . Fortæl mig hvordan jeg kan gøre det.
  • Jeg ‘ har lært i skolen (!!) at primære nøgler kan repræsenteres med en lige understregning under attributten (erne) og fremmednøglen (e) med en stiplet linje
  • Okay. Men hvordan viser jeg, at den fremmede nøgle i en tabel er den samme ting som den primære nøgle til en anden tabel, hvis navne er forskellige i deres respektive ta bles (som stillet i eksemplet i spørgsmålet om ‘ ID ‘ og ‘ Kunde ID ‘)?
  • Da dette spørgsmål henviser til en “No-Chen” notation (fordi det beder om at vise fk-forhold), har jeg åbnet en ny spørgsmål eksplicit til en ER-model i Chen-notation på dba.stackexchange.com/questions/271264/…

Svar

ER Diagrammer blev oprindeligt kun brugt til at repræsentere ER-modellen. ER-modellen bruger ikke fremmede nøgler til at repræsentere relationer. Det bruger linjer mellem kasser. Linjerne har en slags indikator for kardinalitet i begge ender eller i begge ender. Nogle gange vil et forhold blive angivet separat med en diamant.

I dag er mere end halvdelen af ER-diagrammer, der flyder rundt, virkelig diagrammer over en relationsmodel og ikke af en ER-model. En relationsmodel har de fremmede nøgler inkluderet i tabellerne, og disse tjener til at implementere de forhold, som ER-modellen identificerer. Og en relationsmodel vil have en ekstra tabel, ofte kaldet en “krydstabel” mellem to enhedstabeller, der er forbundet med et mange-til-mange-forhold. Denne krydstabel indeholder to eller flere fremmednøgler.

Der er mange måder at repræsentere en relationel model på. Måske er det enkleste “Relationship Diagram”, som MS Access kan producere fra en færdig database. Dette vil være temmelig komplet, hvis databasebyggeren har identificeret de fremmede nøgler.

Der er mange værktøjer, der er mere sofistikerede end MS Access til at lave diagrammer i større skala. Nogle af disse bruges inden opbygning af databasen. Nogle bruges efter.

Kommentarer

  • I øjeblikket laver jeg bare et diagram på et papir. Kan du venligst vise, hvordan ovenstående to tabeller (i spørgsmålet) kan vises i et forholdsdiagram?
  • Hvis du søger på ” ER-diagram Kunder Transaktioner ” du får mange billeder, der viser forskellige måder at gøre, hvad du vil.

Svar

Når jeg tegner ER-diagrammer, har jeg brugt følgende grafiske konvention: Mærk forholdslinjerne med de (n) fremmednøglesøjlenavn (er) som sådan:

Eksempel ERD

Dette gør det klart, hvilken kolonne i underordnet tabel er den fremmede nøgle til overordnet tabel. Angivelse af primærnøglestatus kan gøres ved at understrege den pågældende attribut.

Hvad der kan være mere nyttigt end dette er en navngivningskonvention, der gør det klart, hvad der er den primære nøgle i en tabel (let udført, hvis du bruger surrogatnøgler efter konvention) og hvad der er en fremmed nøglekolonne.

Nogle relationelle modeldiagrammer inkluderer også en nøgledeltagelsesetiket til venstre for kolonnenavnene i kolonnelisten (f.eks. ” PK “, ” FK1 “, ” FK2 “, …) som kan hjælpe, især hvis du har sammensatte nøgler.

Kommentarer

  • Er denne konvention også offentliggjort et eller andet sted, eller er det bare din (gode) idé?
  • @Lorenz er det ‘ er min tilpasning til et fysisk enhedsforholdsdiagram af versionen af krage ‘ s fodnotation ( da.wikipedia.o rg / wiki / … ) udgivet af James Martin ( da.wikipedia.org/wiki/James_Martin_(author) ) i sin bog Information Engineering som brugte forholdsnavnet som etiket på forhold.For mig er det ‘ en fornuftig udvidelse fra den logiske model til den fysiske model.
  • Selvom det hjælper, forbliver det en privat idé, dette var ikke helt klart fra udtrykket “Jeg har brugt”.

Svar

indtast billedbeskrivelse her

Jeg foretrækker dette format ved hjælp af “krager” til at illustrere de mange-til-en-sammenføjninger

Kommentarer

  • Jeg kan også godt lide krage fødder til ER-diagrammer. For relationelle diagrammer foretrækker jeg pilespidsen. bemærk, at en krager fod går på ” mange ” slutningen af en linje, mens en pilespids går på ” en ” slutning af en linje.
  • Der mangler kun FK / PK-symboler ved linjen slutter i denne graf her 🙂 Alligevel fik dette opfølgende svar på dlink ‘ s første udstationering af linket for få stemmer efter min mening. dlink ‘ s tidligere indsendte link blev kritiseret, det blev allerede nævnt i den første kommentar af spørgsmålet før af @MKSingh, der havde stillet;), MEN! det ser ud til, at linket er bedre end angivet der. Hvis du ser den video, der tilbydes under ” fysiske ERD-symboler “, viser den nøjagtigt, hvordan man repræsenterer flere FK i en ERD, her er det direkte link, gå til 7:28, youtube.com/watch?v=QpdhBUYk7Kk

Svar

Mange år senere, vær opmærksom på de forskellige notationer af ER-diagrammer, spørgsmålet er således ikke præcist nok.

Se på alle svar på

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

og

Hvilket er et ER-diagram? . Et svar her siger endda, at Chen-notationen er ERD, mens Crow Foot-notering siges at være en EAD (Entity Attribute Diagram), se @JoshuaGuttman.

Chen-notationen viser ikke eksplicit FK-forholdet , som det accepterede svar allerede forklarer, mens andre notationer kan gøre dette.

Hvis du f.eks. tager Crow Foot eller Bakers notation i stedet, kan du tage ” mest præcise ” svar på @dlink hvor linjerne fører nøjagtigt til FKerne. Så er det stadig uklart, hvad man skal gøre med sammensatte FKer, der fører til sammensatte PKer, og sandsynligvis på grund af at professionelle programmer simpelthen ikke linker linieendelser grafisk med FKerne. Derefter er navngivning alt hvad du kan henvise til, hvilket alligevel er nok, hvis du nøje overholder en navngivningskonvention (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/

vp erd

Svar

Denne side af LucidCharts har en god skrivning om, hvordan ERD skal se ud.

Under fysiske ERD-symboler viser det, hvordan man repræsenterer nøgler.

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

Kommentarer

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *