Devo aggiungere chiavi esterne transitive?

Esempio semplice: esiste una tabella di clienti.

create table Customers (
  id integer,
  constraint CustomersPK primary key (id)
)

Tutti gli altri dati nel database devono essere collegati a un Customer, quindi ad esempio Ordersè simile al seguente:

create table Orders (
  id integer,
  customer integer,
  constraint OrdersPK primary key (customer, id),
  constraint OrdersFKCustomers foreign key (customer) references Customers (id)
)

Supponiamo ora che ci sia una tabella che collega a Orders:

create table Items (
  id integer,
  customer integer,
  order integer,
  constraint ItemsPK primary key (customer, id),
  constraint ItemsFKOrders foreign key (customer, order) references Orders (customer, id)
)

Devo aggiungere una chiave esterna separata da Itemsa Customers?

...
constraint ItemsFKCustomers foreign key (customer) references Customers (id)

Un'immagine invece: dovrei aggiungere la linea tratteggiata / FK?

Modifica: ho aggiunto le definizioni delle chiavi primarie alle tabelle. Vorrei ripetere il punto che ho esposto sopra: il database è sostanzialmente messo a tacere dai clienti, come misura di correttezza / sicurezza. Pertanto, tutte le chiavi primarie contengono l' customerID.

Penso che questa sia l'idea originale.

La prima cosa da notare è che il PK sulla tabella LineItem ha tre attributi {CustomerID, CustomerOrderNo, OdrerItemNo}, a differenza di solo due nel tuo esempio.

La seconda cosa da notare è la confusione derivante dall'uso del idnome generico per un attributo.

Il CustomerOrderNodovrebbe essere idealmente (1,2,3 ..) per ogni cliente e OrderItemNo(1,2,3 ...) per ogni ordine.

Bene, questo è bello se possibile, ma richiede una query alla ricerca del valore massimo precedente, come

select max(CustomerOrderNo)
from Order 
where CustomerID = specific_customer ; 

che spesso non è preferito negli ambienti ad alto volume di transazioni, quindi è comune vederli sostituiti da un auto-incremento, essenzialmente per lo stesso scopo. È vero che questo auto-incremet è ora unico, quindi può essere usato come un CHIAVE - ma puoi scegliere di vederlo come un compromesso necessario per il OrderItemNo.

Quindi, con qualche ridenominazione CustomerOrderNo -> OrderNoe OrderItemNo-> ItemNopotresti arrivare a questo modello

Quindi ora se guardi Orderquanto segue sono unici

{OrderNo}             -- PK
{CustomerID, OrderNo} -- superkey,  AK on the diagram.

Si noti che {CustomerID, OrderNo}viene propagato in modo LineItemche funga da FK.

Se strizzi gli occhi un po ', questo è vicino al tuo esempio, ma con PKs {ItemNo} and {OrderNo}solo - al contrario di due colonne PK dal tuo esempio.

Ora la domanda è: perché non semplificare qualcosa del genere?

Che va bene, ma introduce PATH DIPENDENZA - non si può unire LineItemcon Customerdirettamente, necessario utilizzare Ordernel join.

Preferisco il primo caso, quando possibile: scegli il tuo preferito. E ovviamente, in questi tre casi non è necessario un FK diretto da LineItema Customer.

L '"articolo" non deve fare riferimento direttamente al "cliente", poiché ciò è implicito nell' "ordine" dell'articolo. Pertanto, non avrai assolutamente bisogno delle colonne "cliente" nella tabella "articoli".

La relazione dell'articolo con il cliente è assicurata con la chiave esterna esistente.

Se ordini.id è una colonna di identità, prendere in considerazione la rimozione completa di items.customer.