Różnica między relacją jeden do wielu i wiele do jednego

Jaka jest prawdziwa różnica między relacją jeden do wielu i wiele do jednego? To jest tylko odwrócone, jakby?

Nie mogę znaleźć żadnego `` dobrego i łatwego do zrozumienia '' samouczka na ten temat innego niż ten: SQL dla początkujących: Część 3 - Relacje w bazie danych

Tak, to na odwrót. To zależy od tego, po której stronie relacji znajduje się jednostka.

Na przykład, jeśli jeden dział może zatrudniać kilku pracowników, wtedy dział do pracownika to relacja jeden do wielu (1 dział zatrudnia wielu pracowników), podczas gdy relacja między pracownikami to wiele do jednego (wielu pracowników pracuje w jednym dziale).

Więcej informacji o typach relacji:

Relacje z bazą danych - dokumentacja IBM DB2

Z tej strony o terminologii baz danych

Większość relacji między tabelami to jeden do wielu.

Przykład:

• Jeden obszar może być siedliskiem wielu czytelników.
• Jeden czytelnik może mieć wiele subskrypcji.
• Jedna gazeta może mieć wiele subskrypcji.

Relacja wiele do jednego to to samo, co jeden do wielu, ale z innego punktu widzenia.

• Wielu czytelników mieszka w jednej okolicy.
• Wiele subskrypcji może dotyczyć jednego i tego samego czytelnika.
• Wiele subskrypcji dotyczy jednej i tej samej gazety.

Jaka jest prawdziwa różnica między relacją jeden do wielu i wiele do jednego?

Istnieją koncepcyjne różnice między tymi terminami, które powinny pomóc w wizualizacji danych, a także możliwe różnice w wygenerowanym schemacie, które należy w pełni zrozumieć. Głównie różnica polega jednak na perspektywie.

W relacji jeden do wielu lokalna tabela ma jeden wiersz, który może być powiązany z wieloma wierszami w innej tabeli. W przykładzie z SQL dla początkujących jeden Customermoże być powiązany z wieloma Orderplikami.

W odwrotnej relacji wiele do jednego tabela lokalna może mieć wiele wierszy powiązanych z jednym wierszem w innej tabeli. W naszym przykładzie wiele Orders może być skojarzonych z jednym Customer. Ta różnica pojęciowa jest ważna dla reprezentacji umysłowej.

Ponadto schemat obsługujący relację może być różnie reprezentowany w tabelach Customeri Order. Na przykład, jeśli klient ma kolumny idi name:

id,name
1,Bill Smith
2,Jim Kenshaw

Następnie, aby a Orderbyło skojarzone z a Customer, wiele implementacji SQL dodaje do Ordertabeli kolumnę, która przechowuje idskojarzone Customer(w tym schemacie customer_id:

id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2

W powyższych wierszach danych, jeśli spojrzymy na customer_idkolumnę id, zobaczymy, że Bill Smith(identyfikator klienta nr 1) ma 2 powiązane z nim zamówienia: jedno za 12,34 USD i jedno za 7,58 USD. Jim Kenshaw(identyfikator klienta nr 2) ma tylko 1 zamówienie za 158,01 USD.

Ważne jest, aby zdać sobie sprawę, że zazwyczaj relacja jeden do wielu w rzeczywistości nie dodaje żadnych kolumn do tabeli, która jest „jedynką”. Nie Customerma dodatkowych kolumn opisujących relację z Order. W rzeczywistości Customermoże mieć również związek jeden-do-wielu z nich ShippingAddressi SalesCallstoły, a jednocześnie nie mają dodatkowe kolumny dodane do Customertabeli.

Jednak aby opisać relację wiele do jednego, często iddo tabeli „wiele” dodawana jest kolumna, która jest kluczem obcym do tabeli „jedna” - w tym przypadku customer_idkolumna jest dodawana do tabeli Order. Do powiązanego zamówienia nr 10 dla 12,34 USD Bill Smithprzypisujemy customer_idkolumnę do Bill Smithidentyfikatora 1.

Możliwe jest jednak również istnienie innej tabeli opisującej relację Customeri Order, dzięki czemu do Ordertabeli nie trzeba dodawać żadnych dodatkowych pól . Zamiast dodawać customer_idpole do Ordertabeli, może istnieć Customer_Ordertabela zawierająca klucze zarówno dla, jak Customeri Order.

customer_id,order_id
1,10
1,11
2,12

W tym przypadku operacje jeden do wielu i wiele do jednego są koncepcyjne, ponieważ nie ma między nimi zmian schematu. Który mechanizm zależy od Twojego schematu i implementacji SQL.

Mam nadzieję że to pomoże.

Nie ma różnicy. To tylko kwestia języka i preferencji, w jaki sposób określisz związek.

Odpowiedź na pierwsze pytanie brzmi: oba są podobne,

Odpowiedź na twoje drugie pytanie brzmi: jeden do wielu -> MĘŻCZYZNA (stół MĘŻCZYZNA) może mieć więcej niż jedną żonę (stół KOBIETA) wiele do jednej -> więcej niż jedna kobieta poślubiła jednego MĘŻCZYZNĘ.

Teraz, jeśli chcesz powiązać tę relację z dwiema tabelami MAN i WOMEN, jeden wiersz tabeli MAN może mieć wiele relacji z wierszami w tabeli WOMEN. mam nadzieję, że to jasne.

Przykład

Dwie tabele z jedną relacją

SQL

W SQL istnieje tylko jeden rodzaj relacji, nazywany referencją. (Twój interfejs użytkownika może być pomocny lub dezorientujący [na przykład w niektórych Odpowiedziach], ale to już inna historia).

• Klucz obcy w jednej tabeli (the referenc ing tabela)
  Referencje
  na klucz podstawowy w innej tabeli (The referenc ed tabela)

• W języku SQL, Bar odwołuje się do Foo, a
  nie na odwrót

  CREATE TABLE Foo (
      Foo   CHAR(10)  NOT NULL, -- primary key
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK             -- constraint name
          PRIMARY KEY (Foo)     -- pk
      )  
  CREATE TABLE Bar (
      Bar   CHAR(10)  NOT NULL, -- primary key
      Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
      Name  CHAR(30)  NOT NULL
      CONSTRAINT PK                -- constraint name
          PRIMARY KEY (Bar),       -- pk
      CONSTRAINT Foo_HasMany_Bars  -- constraint name
          FOREIGN KEY   (Foo)      -- fk in (this) referencing table
          REFERENCES Foo(Foo)      -- pk in referenced table
      )

• Ponieważ Foo.Foojest to klucz podstawowy, jest unikalny, istnieje tylko jeden wiersz dla dowolnej wartościFoo

• Ponieważ Bar.Foojest to odniesienie, klucz obcy i nie ma na nim unikalnego indeksu, może istnieć wiele wierszy dla dowolnej wartościFoo
• Dlatego relacja Foo::Bar jest jeden do wielu
• Teraz możesz dostrzec (popatrzeć) relację na odwrót, Bar::Foojest wiele do jednego
  • Ale niech cię to nie zmyli: w każdym Barwierszu jest tylko jeden Foowiersz, do którego się on odnosi
• W SQL to wszystko, co mamy. To wszystko, co jest konieczne.

Jaka jest prawdziwa różnica między relacją jeden do wielu i wiele do jednego?

Jest tylko jedna relacja, dlatego nie ma różnicy. Postrzeganie (z jednego „końca” lub drugiego „końca”) lub czytanie go od tyłu nie zmienia relacji.

Kardynalność

Kardynalność jest deklarowana najpierw w modelu danych, czyli logicznym i fizycznym (intencja), a następnie w implementacji (zamiar zrealizowany).

Kardynalność

Jeden do zera do wielu
W SQL to (powyższe) jest wszystkim, czego potrzeba.

Jeden do jednego do wielu
Aby wymusić transakcję z tabeli referencyjnej, potrzebna jest transakcja .

Jeden do zera do jednego
Potrzebujesz Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

Jeden do jednego
Potrzebujesz transakcji, aby wymusić tę z tabeli referencyjnej.

Wiele do wielu
Na poziomie fizycznym nie ma czegoś takiego (przypomnijmy sobie, w SQL jest tylko jeden typ relacji).

Na wczesnych poziomach logicznych podczas ćwiczenia modelowania wygodnie jest narysować taką relację. Zanim model zbliży się do wdrożenia, lepiej będzie, gdy zacznie używać tylko rzeczy, które mogą istnieć. Taka relacja jest rozwiązywana poprzez implementację tabeli asocjacyjnej.

Wiele do wielu rozwiązanych

Jeden do wielu i wiele do jednego są podobne pod względem różnorodności, ale nie aspektu (tj. Kierunkowości).

Mapowanie asocjacji między klasami jednostek i relacji między tabelami. Istnieją dwie kategorie relacji:

1. Wielość (termin ER: liczność)
   • Relacje jeden do jednego : przykład mąż i żona
   • Relacje jeden-do-wielu : przykład matka i dzieci
   • Relacje wiele-do-wielu : przykład ucznia i przedmiotu
2. Kierunkowość : nie wpływa na mapowanie, ale ma wpływ na sposób, w jaki możemy uzyskać dostęp do danych.
   • Relacje jednokierunkowe : pole lub właściwość relacji, która odwołuje się do innej jednostki.
   • Relacje dwukierunkowe : każda encja ma pole relacji lub właściwość, która odwołuje się do innej encji.

Nie ma praktycznej różnicy. Po prostu użyj relacji, która jest najbardziej sensowna, biorąc pod uwagę sposób, w jaki postrzegasz swój problem, jak zilustrował Devendra.

• --- Jeden do wielu --- Rodzice mogą mieć dwoje lub więcej dzieci.

• --- Wiele do jednego --- Te troje dzieci może mieć samotnych rodziców.

  Obie są podobne. To może być wykorzystane należy do potrzeby. Jeśli chcesz znaleźć dzieci dla określonych rodziców, możesz wybrać opcję Jeden do wielu. albo chcesz znaleźć rodziców dla bliźniaków, możesz iść z wieloma do jednego. Również....,

jeden do wielu ma klasę nadrzędną zawierającą n liczby potomków, więc jest to mapowanie kolekcji.

wiele do jednego ma n liczba elementów potomnych zawiera jednego rodzica, więc jest to mapowanie obiektów