Załóżmy, że mam tabelę „Transakcje”, która zawiera kolumnę „Identyfikator klienta” (klucz obcy) i tabelę klientów z „ID” (klucz podstawowy) . Jak pokazać relację między dwiema tabelami i pokazać, że „Identyfikator klienta” jest kluczem obcym tabeli „Transakcje”, który jest kluczem podstawowym w tabeli „Klient”?

Przeszukałem to pytanie w Google a także sprawdziłem to forum w poszukiwaniu mojego zapytania, ale nie mogłem znaleźć dokładnego przykładu ze schematem odpowiadającym na moje pytanie.

Proszę wyjaśnić mi, jeśli to możliwe, diagramem.

Komentarze

  • Udało mi się znaleźć następujący link, który mówi, że możemy pokazać klucz obcy tylko w koncepcyjnym diagramie ER. lucidchart.com / pages / ER-diagram-symbols-and-mean . Powiedz mi, jak mam to zrobić.
  • ' uczyłem się w szkole (!!) że klucze podstawowe można przedstawić za pomocą prostego podkreślenia pod atrybutem (atrybutami), a klucze obce za pomocą linii przerywanej
  • OK. Ale jak mam pokazać, że klucz obcy w jednym table jest tym samym, co klucz podstawowy innej tabeli, której nazwy różnią się w odpowiednich ta bles (zgodnie z przykładem w pytaniu o ' ID ' i ' Klient ID ')?
  • Ponieważ to pytanie odnosi się do notacji „No-Chen” (ponieważ prosi o pokazanie relacji fk), otworzyłem nowy pytanie jawnie dla modelu ER w notacji Chen pod adresem dba.stackexchange.com/questions/271264/…

Odpowiedź

Diagramy ER były pierwotnie używane tylko do reprezentowania modelu ER. Model ER nie używa kluczy obcych do reprezentowania relacji. Używa linii między polami. Linie mają jakiś wskaźnik liczności na jednym lub obu końcach. Czasami związek będzie oznaczony osobno diamentem.

Obecnie ponad połowa diagramów ER krążących wokół to tak naprawdę diagramy modelu relacyjnego, a nie modelu ER. Model relacyjny ma klucze obce zawarte w tabelach, które służą do implementacji relacji, które identyfikuje model ER. Model relacyjny będzie miał dodatkową tabelę, często nazywaną „tabelą połączeń” między dwiema tabelami encji, które są połączone relacją wiele-do-wielu. Ta tabela skrzyżowań zawiera dwa lub więcej kluczy obcych.

Istnieje wiele sposobów przedstawiania modelu relacyjnego. Być może najprostszym jest „Diagram relacji”, który MS Access może utworzyć z kompletnej bazy danych. Będzie to dość kompletne, jeśli konstruktor bazy danych zidentyfikował klucze obce.

Istnieje wiele narzędzi, które są bardziej wyrafinowane niż MS Access do tworzenia diagramów na większą skalę. Niektóre z nich są używane przed budowaniem bazy danych. Niektóre są używane później.

Komentarze

  • Obecnie właśnie tworzę diagram na papierze. Czy możesz pokazać, jak powyższe dwie tabele (w pytaniu) można przedstawić na diagramie relacji?
  • Jeśli będziesz szukać na ” Diagram ER Transakcje klientów ” otrzymasz wiele obrazów, które pokazują różne sposoby robienia tego, co chcesz.

Odpowiedź

Podczas rysowania diagramów ER korzystałem z następującej konwencji graficznej: Oznacz linie relacji nazwami kolumn z kluczem obcym, w ten sposób:

Przykład ERD

To wyjaśnia, która kolumna w tabeli podrzędnej jest kluczem obcym do tabeli nadrzędnej. Aby wskazać stan klucza podstawowego, należy podkreślić odpowiedni atrybut.

Bardziej przydatna może być konwencja nazewnictwa, która wyjaśnia, jaki jest klucz podstawowy tabeli (łatwo to zrobić, jeśli używasz klucze zastępcze według konwencji) i czym jest kolumna klucza obcego.

Niektóre diagramy modelu relacyjnego zawierają również etykietę udziału klucza po lewej stronie nazw kolumn na liście kolumn (np. ” PK „, ” FK1 „, ” FK2 „, …), które mogą być pomocne, zwłaszcza jeśli masz klucze złożone.

Komentarze

  • Czy ta konwencja również została gdzieś opublikowana, czy jest to tylko twój (dobry) pomysł?
  • @Lorenz it ' jest mój dostosowanie do diagramu relacji między jednostkami fizycznymi w wersji wrona ' notacja stóp ( en.wikipedia.o rg / wiki / … ) opublikowane przez Jamesa Martina ( en.wikipedia.org/wiki/James_Martin_(author) ) w swojej książce Inżynieria informacyjna , w której nazwa relacji była etykietą relacji.Dla mnie jest to ' rozsądne rozszerzenie od modelu logicznego do modelu fizycznego.
  • Nawet jeśli to pomaga, pozostaje prywatną ideą, nie było to całkowicie usunąć z wyrażenia „Użyłem”.

Odpowiedź

enter opis obrazu tutaj

Wolę ten format, używając „wrony łapki” do zilustrowania łączenia typu „wiele do jednego”

Komentarze

  • Lubię też wronie łapki do diagramów ER. W przypadku diagramów relacyjnych wolę grot strzałki. zwróć uwagę, że kurze łapa idzie na ” wielu ” końcu linii, a grot strzałki na ” jeden ” koniec linii.
  • Na tym wykresie brakuje tylko symboli FK / PK na końcach linii 🙂 Mimo to ta uzupełniająca odpowiedź dotycząca pierwszego opublikowania linku przez dlink ' otrzymała moim zdaniem zbyt mało głosów. Wcześniej opublikowany link dlink ' został skrytykowany, był już wspomniany w pierwszym komentarzu do pytania przez @MKSingh, który zadał;), ALE! wydaje się, że link jest lepszy niż tam podano. Jeśli obejrzysz film oferowany pod ” fizycznymi symbolami ERD „, pokazuje on dokładnie, jak przedstawić wiele FK w ERD, tutaj jest bezpośredni link, przejdź do 7:28, youtube.com/watch?v=QpdhBUYk7Kk

Odpowiedź

Wiele lat później proszę zwrócić uwagę na różne notacje na diagramach ER, dlatego pytanie nie jest wystarczająco precyzyjne.

Spójrz na wszystkie odpowiedzi na

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

i

Który z nich jest diagramem ER? . Jedna odpowiedź mówi nawet, że notacja Chen to ERD, podczas gdy notacja Crow Foot jest uważana za EAD (diagram atrybutów encji), patrz @JoshuaGuttman.

Notacja Chen nie pokazuje wyraźnie relacji FK , jak już wyjaśnia zaakceptowana odpowiedź, podczas gdy inne notacje mogą to zrobić.

Jeśli zamiast tego weźmiesz na przykład notację Crow Foot lub Baker, możesz wziąć ” najbardziej precyzyjna ” odpowiedź @dlink, gdzie linie prowadzą dokładnie do SK. Wciąż nie jest jasne, co zrobić ze złożonymi SK prowadzącymi do złożonych PK i prawdopodobnie z powodu że profesjonalne programy po prostu nie łączą graficznie końcówek linii z kodami SK. Wówczas nazewnictwo jest wszystkim, do czego możesz się odwołać, co i tak wystarczy, jeśli trzymasz się ściśle konwencji nazewnictwa (np. CustomerID do Customer.ID lub innych reguł) . Zobacz na przykład Visual Paradigm pod adresem https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagram/

vp erd

Odpowiedź

Ta strona autorstwa LucidCharts ma ładny opis, jak powinien wyglądać ERD.

W Fizycznych symbolach ERD pokazuje, jak reprezentować klucze.

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

Komentarze

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *