PDA

Visualizza versione completa : [SQL] Foreign Key


Dr_House
16-02-2007, 20.42.19
Salve a tutti,

ho un piccolo dubbio in merito alle foreign key, magari qualcuno può aiutarmi.

Vi spiegherò in breve la situazione:

Supponiamo di avere in uno schema ER la seguente situazione

Persona (1:1) --------- <Risiede> --------- (0:N)Città

Con persona avente primary key CF (codice Fiscale) e Città avente come primary key Nome

Andando a ristrutturare l'ER per avere uno schema logico avremo:


Persona (CF, ..... vari attributi)
Foreign key Persona[CF] <-- Risiede[persona]


Città (Nome, ..... altri attributi)

Risiede(persona, città)
Foreign Key Risiede[persona] <--- Persona[CF]
Foreign Key Risiede[città] <--- Città[nome]


Questo è lo schema che ne otterremmo andando a ristrutturare, non ci basta che creare le tabelle SQL ed il gioco parrebbe fatto ma non è così, infatti proprio per la foreign key, non posso creare Persona senza Risiede ne tanto mento Risiede senza persona!

Ed ecco qui le mie tre soluzioni:

1)

Creo persona semplicemente così:

Persona (CF, ..... vari attributi)

Senza alcuna foreign key, le altre tabelle non vengono toccate. Quando anche Risiede sarà creata, applico un alter table creando in Persona la Foreign Key su Risiede

2)

Applico il significato di Foreign Key e lascio inalterata la tabella Risiede, ma applico su “Persona” la clausola che serve a garantire l'inclusione in Risiede, dato che poi MySQL non supporta le check appropriatamente, creerò un trigger

3)

Applico un passo di ristrutturazione ulteriore con un accorpamento

Persona(CF, Città)
Foreign Key Persona[Città] <-- Città[nome]

Eliminando così Risiede ed il problema ad esso annesso.

Teniamo inoltre conto dei primi due metodi di risoluzione, ad ogni insert infatti, i vincoli di chiave esterna (soprattutto nel primo modo) impedirebbero di inserire una tupla all'interno di una tabella senza inserire parallelamente anche nell'altra, cosa che non è possibile.

Potrebbero essere usate transazioni, ma non sono a conoscenza di cose atte a questo scopo se non quello di settare a 0 i controlli della chiave esterna ovvero

set FOREIGN_KEY_CHECKS = 0

fare gli inserimenti

set FOREIGN_KEY_CHECKS = 1




Voi sapreste indicarmi modi alternativi ulteriori? Soprattutto se ci sono transazioni che permettano di inserire i valori senza ricorrere al set FOREIGN_KEY_CHECKS prima mostrato.

Grazie in anticipo

P8257 WebMaster
16-02-2007, 21.00.40
Dunque vediamo ...

se ho capito bene il tuo modello dati, direi che non stiamo parlando soltanto di foreign key ma anche di constraints, i "checks" innestano dei constraint e se tali devono essere non devono mai essere smantellati . .neanche per "comodità".. pena la perdita di coerenza della base dati...

Alla luce di questo direi che l'unico metodo applicabile (se di constraint attivi dobbiamo parlare), a mio avviso è il terzo... :

Semplificare le relazioni quando possible è sempre una buona regola, per cui se riesci a relazionare direttamente le "persone" alle città (tabella che probabilmente puoi prepopolare se non lo è già) risolvi il problema con meno fatica e con minore riscaldamento del cervello :)

Sharok
16-02-2007, 21.17.02
Ma il campo CF di Persona lo hai impostato tu come FK di Risiede.persona oppure è la specifica della base dati che te lo impone? Perchè quella FK sembra proprio di troppo :mm:

Per come la vedo io Risiede dovrebbe essere composto da CF,NomeCittà entrambi chiave Primaria, con CF Foreign per Persona.CF e e Nomecittà Foreign per Citta.Nomecittà. Mentre le altre due tabelle, Persona e Città, dovrebbero avere solo le due Primary key CF e NomeCittà.


:)

Dr_House
16-02-2007, 23.50.05
Allora, Persona è in (1:1) (0:N) con Città attravero la relazione Risiedi.

Nella ristrutturazione si ottiene il risultato che ho esposto prima...

La cardinalità minima (1 comporta un inclusione, mentre la cardinalità massima 1) solamente persona resta identificatore primario in "Risiede"

Questi son i passi della ristrutturazine, però appunto, il:

check ((cf) in (select persona from risiede))

che si avrebbe in una normale cardinalità (1:N) grazie alla restrizione dell' N=1 diventa una forein key (da qui l'idea della scomposizione)

Dato che, i check non vengono implementati correttamente e non sono ancora attendibili (anzi, se non erro MySQL quando incontr un Check lo salta, Oracle full e pochi altri eseguono soltanto queri più semplici) vanno implementati via Trigger..

Appunto mi son trovato di fronte al bivio e cercavo una soluzione con le transazioni per evitare di dover settare la chiave a 0 ogni qualvolta si vada ad inserire una tupla

Di fatto la scelta dell'accorpamento non è male, ma per il DBMS che realmente è in esame l'accorpamento non sarebbe la soluzione migliore, diciamola che se pur la più semplice è la via estrema...