Come mantenere coerenti le relazioni con le chiavi estere in un sistema di relazioni a forma di diamante

Question

Considerare questa situazione: a L'automobile viene acquistata da un venditore Venditore. Un venditore lavora in uno Showroom (e in un solo Showroom). Uno showroom è affiliato a un produttore e vende esclusivamente automobili prodotte da tale produttore. Allo stesso tempo, un'auto è di un particolare modello e un modello è prodotto da un produttore.

Restrizione R: Il produttore di un modello di auto deve essere lo stesso produttore del produttore affiliato dello showroom del venditore.

Il diagramma mostra le ovvie relazioni con le chiavi esterne.

 ----> Manufacturer <---- 
    |      | 
    |      | 
Showroom      | 
    ^      | 
    |      Model 
    |      ^
Salesperson     | 
    ^      | 
    |      | 
    --------- Car ---------- 

Come si applica la restrizione R? È possibile aggiungere una relazione di chiave esterna Car --> Manufacturer. Eppure il produttore di una macchina può essere stabilito unendo le tabelle in un modo o nell'altro intorno al "diamante", quindi sicuramente per fare questo non sarebbe normalizzato? Eppure non so diversamente come applicare il vincolo.

Answer 1

Se ho capito bene la domanda, questo dovrebbe essere vicino.

Ecco alcuni dettagli per chiavi

-- 
-- Keys for SalesPerson 
-- 
alter table SalesPerson 
    add constraint PK_salesperson primary key (PersonID) 

, add constraint AK1_salesperson unique (ManufacturerID, ShowRoomNo, PersonID) 

, add constraint FK1_salesperson foreign key (PersonID) 
          references Person (PersonID) 

, add constraint FK2_salesperson foreign key (ManufacturerID, ShowRoomNo) 
         references ShowRoom (ManufacturerID, ShowRoomNo) 
; 

-- 
-- keys for Sale table 
-- 
alter table Sale 
    add constraint PK_sale primary key (SaleID) 

, add constraint FK1_sale foreign key (BuyerID) 
        references Person (PersonID) 

, add constraint FK2_sale foreign key (ManufacturerID, ModelName, ShowRoomNo) 
       references CarDisplay (ManufacturerID, ModelName, ShowRoomNo) 

, add constraint FK3_sale foreign key (ManufacturerID, ShowRoomNo, SalesPersonID) 
       references SalesPerson (ManufacturerID, ShowRoomNo, PersonID) 
; 

Answer 2

il modo per garantire che il "fondo" del diamante non può fare riferimento "lati" del diamante che hanno generato un diverso " top" del diamante, è quello di utilizzare identificazione rapporti e il conseguente 'chiavi naturale grassi', in modo che possano essere fuse in basso:

(Solo per i campi PK visualizzati, per brevità. Sarà quasi certamente desidera un numero di telaio come chiave si alternano in Car ecc ...)

Il ManufacturerId è stato migrato su entrambi i lati di diamanti e, infine, fusa in fondo in un unico campo. Il fatto stesso che sia il singolo archiviato assicura che non ci possono essere due produttori che portano alla stessa auto.

BTW, questo ancora non si impedisce l'utilizzo di chiavi surrogate (in aggiunta a queste naturali), assumendo DBMS supporta FKS ai tasti alternativi:

Surrogates sono ridondanti in questo modello preso da solo , ma potresti avere altre entità lì che non ci hai mostrato, che potrebbero trarre vantaggio dall'uso di FK più sottili.

---

Quanto sopra è la conversione più diretta del diagramma, in cui un'automobile esiste solo come un'auto venduta.Tuttavia, ho il sospetto che ci si vuole essere in grado di memorizzare le auto che non sono ancora stati venduti, e quando sono venduti memorizzare l'acquirente di macchina ecc ...

Quindi, un modello più completo sarebbe qualcosa di simile questo:

Abbiamo appena risciacquo-e-ripetere la relazioni identificare trucco, quindi una macchina non può essere visualizzato in uno showroom di un altro produttore e non può essere venduto da un venditore da uno showroom diversa.

Una macchina è invenduto quando c'è solo una riga in Car. Un'auto viene venduta quando c'è una riga in Care una riga corrispondente in Sale. Sia lo Car sia lo Sale condividono lo stesso PK e questa è una relazione da 1 a 0..1, che potrebbe anche essere modellata unendo Car e Sale e rendendo i campi di vendita NULL-in grado, con il CONTROLLO appropriato per garantire che non possano essere "parzialmente NULL".

BTW, ogni volta che si sta vendendo qualcosa, è necessario assicurarsi che la vendita è "congelato nel tempo". Ad esempio, il prezzo effettivamente pagato da un acquirente non dovrebbe cambiare solo perché il prezzo dell'auto è stato cambiato dopo la vendita dello. Dai un'occhiata a here per maggiori informazioni.