Czy tabela skrzyżowań (tabela łączenia) może być również używana dla relacji jeden do wielu?

Question

Według definicji, Junction Table (tabela most/link tabela) jest używany przez wiele-do-wielu związkach, gdy używany tak:

CREATE TABLE Users 
(
UserLogin varchar(50) PRIMARY KEY, 
UserPassword varchar(50) NOT NULL, 
UserName varchar(50) NOT NULL 
) 


CREATE TABLE Permissions 
(
PermissionKey varchar(50) PRIMARY KEY, 
PermissionDescription varchar(500) NOT NULL 
) 


--This is the junction table. 
CREATE TABLE UserPermissions 
(
UserLogin varchar(50) REFERENCES Users (UserLogin), 
PermissionKey varchar(50) REFERENCES Permissions (PermissionKey), 
PRIMARY KEY (UserLogin, PermissionKey) 
) 

Ale nie może to być również używany tak łatwo na jeden-do-wielu relacji, jak w tym przykładzie, w którym jeden użytkownik jest związane z wielu zleceń:

(nie rozumiem bazy dobrze więc proszę mnie poprawić, jeśli mam coś źle .)

CREATE TABLE Users 
(
UserLogin varchar(50) PRIMARY KEY, 
UserPassword varchar(50) NOT NULL, 
UserName varchar(50) NOT NULL 
) 


CREATE TABLE Orders 
(
OrderKey varchar(50) PRIMARY KEY, 
OrderDescription varchar(500) NOT NULL 
) 


--This is the junction table. 
CREATE TABLE UserOrders 
(
UserLogin varchar(50) REFERENCES Users (UserLogin), 
OrderKey varchar(50) REFERENCES Orders (OrderKey), 
PRIMARY KEY (UserLogin, OrderKey) 
) 

Answer 1

Tak, ale potem pozostawiasz kontrolę, że nie ma wielu dla wielu aplikacji, zamiast wymuszać ją wewnątrz bazy danych.

Answer 2

Nie ma żadnego powodu, dla którego tabela skrzyżowanie nie mogłyby zostać wykorzystane do relacji jeden-do-wielu. Pytanie jest zwykle jednym z wyników. Dlaczego warto bazy danych dołączyć do dodatkowej tabeli, gdy nie jest to konieczne?

Answer 3

Po zbudowaniu stołu nie ma on w rzeczywistości typu tabeli "Łączenie", "asocjacyjnej" tabeli, "dołączania" tabeli - to tylko tabela.

Używamy tych terminów, aby opisać konkretny powód, dla którego jednostka (i wynikowa tabela) została pierwotnie utworzona. Jednostki asocjacyjne są początkowo tworzone w celu rozwiązania sytuacji wielu do wielu. Jednak te tabele często mają własne atrybuty (takie jak czas skojarzenia, powód stowarzyszenia itp.). Tak więc SQL Server, Oracle lub twój kod nie ma powodu, aby wiedzieć, dlaczego tabela została utworzona ... tylko, że jest to tabela.

Z technicznego punktu widzenia tak naprawdę nie ma żadnej różnicy między tabelą asocjacyjną a inną tabelą.

Te tabele mogą więc pełnić dowolną rolę, jaką spełnia każda inna tabela. Nie ma żadnych reguł dotyczących tego, jak inne tabele mogą być z nimi powiązane.

Answer 4

Byłoby wiele-do-wielu:

CREATE TABLE UserOrders 
(UserLogin varchar(50) REFERENCES Users (UserLogin), 
OrderKey varchar(50) REFERENCES Orders (OrderKey), 
PRIMARY KEY (UserLogin, OrderKey)); 

Byłby to jeden-do-wielu (jeden użytkownik ma wiele zamówień):

CREATE TABLE UserOrders 
(UserLogin varchar(50) REFERENCES Users (UserLogin), 
OrderKey varchar(50) REFERENCES Orders (OrderKey), 
PRIMARY KEY (OrderKey)); 

zauważyć różnicę w klucz podstawowy przymus.

Answer 5

Możesz wymusić ograniczenie "jeden" w tabeli łączenia/skrzyżowania, dodając wyjątkowe ograniczenie (lub uczynienie go kluczem podstawowym tabeli łączenia, ponieważ tylko ten atrybut identyfikuje relację) do kolumny, która jest obcą klucz do "wielkiej" strony. Dzieje się tak dlatego, że chcesz, aby rwos z wielu stron miało tylko jedną relację, a relacje są określone w tabeli sprzężenia/skrzyżowania.

Answer 6

Chyba masz niewłaściwej koncepcji - Oto proste wyjaśnienie, czy to może pomóc: Aby osiągnąć wiele-wielu relacji między dwiema tabelami (powiedzmy A i B), musimy skorzystać z pomocy stół skrzyżowania (na przykład tabela c), który będzie miał relację jeden-wiele z tabelami A i B.