relazione A-B-C vs A-B, B-C, relazioni A-C

Penso che i due modelli che proponi rappresentano cose molto diverse.

Una singola tabella digitata su (A, B, C) rappresenta che questa combinazione unica è valida / contiene dati ad essa associati. Cercare una riga e interpretare solo i dati basati su A e B sarebbe un errore. Se puoi prevedere i valori validi di C basati su A e B, allora non fa parte della chiave; se c'è una sola C valida per ogni A e B, è solo una colonna di dati.

Tre tabelle (A, B), (A, C) e (B, C) modellano un insieme di relazioni separate. Cercare solo una riga basata su A e B è possibile e pienamente supportato. Inoltre, le regole di normalizzazione dicono che queste relazioni dovrebbero essere indipendenti - l'esistenza di righe in (A, B) e (A, C) non dovrebbe prevedere una riga in (B, C), altrimenti quella riga è dati duplicati.

Sono possibili altre variazioni, come una tabella di mappatura da A a B, con la chiave surrogata AB e una tabella dipendente che elenca la relazione di tali coppie con C (AB, C); o anche una tabella che associa le coppie AB alle coppie BC.

Ci saranno diversi scenari in cui cose diverse hanno senso. Può mai esserci una A con una B e non una C? La stessa A avrebbe sempre la stessa B ma C diverse? La relazione tra B e C ha un significato al di fuori della relazione tra loro e A?

Dalle informazioni aggiuntive modificate nella domanda, potresti modellare le seguenti relazioni:

• cosa-A ha la caratteristica-B, che dà la cosa-funzione-AB (chiavi esterne A, B; chiave primaria AB)
• la caratteristica-B ha l'opzione-C, che fornisce l'opzione-opzione-BC (chiavi esterne B, C; la chiave primaria BC)
• cosa-caratteristica-AB ha caratteristica-opzione-BC, dando prezzo X (chiavi esterne AB, BC)

Si noti che qui abbiamo creato entità aggiuntive, che potrebbero avere le proprie informazioni: ho elencato il prezzo come probabile output della terza tabella, ma una cosa-funzione-AB potrebbe avere delle restrizioni su quando questa funzionalità è disponibile ; una caratteristica-opzione-BC potrebbe avere una descrizione aggiuntiva su come l'opzione si applica in quel contesto; ecc. Queste sarebbero o colonne o ulteriori tabelle con chiavi esterne, come le restrizioni delle caratteristiche delle cose con la chiave esterna AB.

Per essere onesti, i tuoi esempi sono un po 'astratti per me. Quello che deduco è che hai le caratteristiche B che possono avere le opzioni C. Quindi quello che penserei sarebbe che le relazioni sarebbero: tu crei una tabella D: B- > C e poi hai la relazione D nella tua tabella A o una tabella: A- > D

Immagino qualcosa del genere: hai una macchina, che può avere cerchi diversi, e ogni tipo di cerchio è disponibile in più colori, ma non tutti i cerchi possono essere in ogni colore.

Quindi quello che vorrei fare è avere il mio tavolo Car, Rim Table e Color Table. Ora crea un tavolo incrociato con i diversi cerchi e le loro opzioni di colore e nel tavolo della tua auto puoi fare un riferimento in un campo alla registrazione della tavola incrociata dei cerchi e dei loro colori in modo da ottenere un bordo specifico con un colore.

Se hai un maggior numero di cerchi sulla tua auto, puoi creare un tavolo incrociato di auto e il tavolo dei colori dei cerchi.

Se è davvero una relazione formata dalla tripla, allora dovresti avere una tabella che è la tripla, altrimenti ti stai aprendo a dati privi di senso quando le cose vengono aggiornate / cancellate.

per es.

Diciamo che hai A1, A2, B1, C1, C2 e il seguente:

A1, B1, C1        A1, B1 | A1, C1 | B1, C1
A2, B1, C2        A2, B1 | A2, C2 | B1, C2

Cosa succede quando elimini una delle A, ad esempio A1? Ora hai il seguente:

                         |        | B1, C1 <- Dangling relation?
A2, B1, C2        A2, B1 | A2, C2 | B1, C2