C'è una matrice di risposta che posso usare per decidere se ho bisogno di una chiave esterna o no?
-
22-09-2019 - |
Domanda
Per esempio, ho una tabella che memorizza le classi, e una tabella che memorizza class_attributes. class_attributes ha un class_attribute_id e un class_id, mentre le classi ha un class_id.
Mi piacerebbe che se un set di dati è "un bambino esclusivamente di" o "appartiene esclusivamente a" o "è di proprietà esclusiva", quindi ho bisogno di un FK per identificare il genitore. Senza class_id nella tabella class_attributes non avrei mai potuto scoprire a quale classe questo attributo appartiene.
Forse c'è una matrice di risposta utile per questo?
Soluzione
Wikipedia è utile.
Nel contesto relazionale banche dati, una chiave esterna è un vincolo referenziale tra due Tabelle. 1 I identifica chiave esterna una colonna o un insieme di colonne in una (Riferimento) tabella che si riferisce ad un Colonna o set di colonne in un'altra (Riferimento) tavolo. Le colonne nella tabella di riferimento deve essere il primario chiave o le altre chiave candidata nella tabella di riferimento.
(e si va avanti nella sempre più dettagli)
Se si desidera applicare il vincolo che ogni riga in class_attributes applica a esattamente una fila di classi, è necessario una chiave esterna. Se non si cura di far rispettare questo (cioè, siete bene avere gli attributi per le classi inesistenti), non è necessario un FK.
Altri suggerimenti
Non ho una matrice risposta, ma solo per motivi di chiarezza, stiamo parlando di di normalizzazione di database :
http://en.wikipedia.org/wiki/Database_normalization
E in una certa misura Denormalizzazione :
direi, è il contrario. In primo luogo, si progetta che tipo di oggetti è necessario avere. Per coloro che creerà una tabella.
Una parte di questa fase è la progettazione delle chiavi, cioè le combinazioni di attributi (colonne) che identificano in modo univoco l'oggetto. Si può o non può aggiungere un tasto chiave o surrogata artificiale per motivi di convenienza o di prestazioni. Da questi tasti, in genere si sceglie una chiave canonica, la chiave primaria, che si tenta di utilizzare in modo coerente per identificare gli oggetti in tale tabella (a mantenere gli altri tasti troppo, servono per garantire unicità come una regola di business, non tanto per identificattion Ai fini).
Quindi, si pensa ciò che esistono relazioni tra gli oggetti. Un oggetto che è 'posseduto' da un altro oggetto, o un oggetto che fa riferimento a un altro oggetto ha bisogno di qualche modo per identificare suo oggetto correlato. Nella tabella corrispondente (tabella figlio) si aggiungono le colonne di fare una chiave esterna per puntare alla chiave primaria della tabella di riferimento.
Questo si prende cura di tutto uno a molti rapporti.
A volte, un oggetto può essere correlato più volte ad un altro oggetto. Ad esempio, un ordine può essere utilizzata per ordinare più prodotti, ma un prodotto può apparire su più ordini pure. Per questi rapporti, si progetta una tabella (tabella di intersezione - in questo esempio, order_items) separata. Questa tabella avrà una chiave univoca creata da due chiavi esterne: uno che punta a quella controllanti (ordini), uno per l'altro genitore (prodotti). E ancora, si aggiungono le colonne alla tabella incrocio che è necessario creare queste chiavi esterne.
Così, in breve, è innanzitutto chiavi di progettazione e chiavi esterne, solo allora si inizia ad aggiungere colonne per la loro attuazione.
Non essere interessato al tipo di rapporto -. Ha più a che fare con la cardinalità del rapporto
Se si dispone di una relazione uno-a-molti, allora che ci si vuole assegnare una chiave primaria per il più piccolo dei tavoli, e conservarla come chiave esterna nella tabella più grande.
Si potrebbe anche fare con relazioni uno-a-uno, ma alcune persone sostengono che si dovrebbe evitare.
Nel caso di una relazione molti-a-molti, che ci si vuole fare una tabella unirsi, e poi ognuna delle tabelle originali hanno una chiave esterna alla tabella unirsi.