Newsgroup: it.comp.software.database
Titolo: Query browser, chiavi e indici univoci

Salve a tutti,
	mi fate capire una cosa che logicamente non comprendo?
Ho una tabella che chiamo tab1 sulla quale ho creato un campo "idtab1 
auto_incrementale e not null", un campo "codice not null" e un campo 
"num_parti not null". Sempre nel query browser volevo impostare come 
CHIAVE i campi "codice e num_parti" e quindi sull'edit della tabella ho 
messo la chiave. Dando conferma il database genera un errore perchè solo 
idtab1 può essere chiave. Al che ho tolto la chiave sui 2 campi e l'ho 
messa su idtab1 e per gli altri 2 ho creato un indice che li comprende 
con una clausola "UNIQUE". Questa va a buon fine.
Ma la logica non mi convince. Un campo autoincrementante è sempre 
univoco per definizione ed è inutile renderlo chiave. La chiave è per 
logica la somma di campi che "definisce" la chiave della tabella.
Mi spiegate perchè devo creare una chiave su un campo già univoco e un 
indice univoco sulla somma di 2 campi?
Grazie.
P.S. Conoscete un programma (meglio se free) che, collegandosi al DB, 
crea un disegno della struttura del database? Non serve poter editare e 
reimportare ma almeno vedere graficamente che tutte le chiavi siano 
state impostate bene senza andare tabella per tabella.
Grazie anche qui.

 indice univoco sulla somma di 2 campi?
Mi dispiace informarti che purtroppo sei stato ingannato dal dbms (del
quale ti sono grato che tu non abbia scritto il nome onde evitare
flames), e questo ti costringe a lavoro in piu` per sopperire alle
sue limitazioni. L'aspetto negativo e` che tale manchevolezza grava
su di te e non su chi l'ha causata; la soluzione probabilmente
implichera` la riscrittura di parte dello schema e dei programmi.
Una chiave e un indice univoco sono concetti differenti che
stanno su piani differenti; cio` che crea confusione e` nei novizi
il fatto che hanno entrambi l'effetto di rendere unici i valori su
cui sono applicati.
Nei primordi, il concetto di chiave primaria neppure esisteva:
i dati venivano manipolati usando numeri d'ordine che riflettevano
il supporto fisico su cui poggiavano; poteva trattarsi degli
arcaici perforatori di schede, in cui il numero rappresentava la
posizione della scheda nel contenitore, oppure era l'indice di
un array di una bobina a nastro (di carta o successivamente,
magnetico), in cui in effetti il numero rifletteva la sequenza in
cui i dati venivano aggiunti sul supporto.
Il programmatore si scriveva una routine con un ciclo in cui era
obbligato a leggersi tutto il contenitore o tutta la bobina, per
scartare quello che non interessava e processare una ad una le
righe rilevanti; questo era chiamato accesso (e programmazione)
sequenziale, ed oggi e` considerata pessima programmazione.
(Do' credito a Joe Celko per la sua incessante opera di erudizione
su questo aspetto).
I programmatori specialmente hanno doppia difficolta` ad
abbandonare tale pratica, perche' mentalmente la associano alla
scansione di un array, con l'ID che ne e` l'indice.
Poi venne la ricerca sulla programmazione ad alto livello (spec.
le operazioni set-oriented, che trattavano i dati tutti in una volta)
e gli hard disk con fulminei accessi non-sequenziali; tutto questo
rese obsoleta la programmazione sequenziale (benche' cio' non avvenne
subito, ne` in maniera netta).
Fu allora che Codd decise che in un modello di dati era assurdo usare
i valori posizionali (gli "ID") dello storage sottostante; va invece
usato uno dei valori della "realta`". E fu cosi` che apparve il
concetto di chiave primaria.
Il punto di tutto quanto (alla fine ci siamo arrivati!) e` che indici
e ID auto incrementanti sono concetti FISICI, mentre chiave primaria
e` concetto LOGICO.
I primi rdbms avevano uno scarso supporto al modello relazionale, e
spesso erano prodotti riciclati in fretta e furia dai dbms "vecchia
generazione".
Pertanto, una chiave primaria veniva implementata attraverso
l'apposizione di un indice univoco; il programmatore doveva ricordarsi
di non togliere mai quell'indice, dato che era "speciale" (che fosse
chiave primaria esisteva solo nella sua mente).
In altri casi, gli utenti continuavano a creare nelle tabelle ID
auto incrementanti per far funzionare i vecchi programmi (o
semplicemente perche` solo cosi` sapevano programmare...); il dbms
aggravava questa situazione rendendo automaticamente chiave primaria
la colonna auto incrementante, e costruendo lo storage in base ad
essa (solitamente un indice cluster).
Questo genero` nella mente dei dba l'errata convinzione che chiave
primaria = indice univoco; in questa stessa ambiguita` sei caduto
anche tu, complice un dbms in realta' non pienamente relazionale.
Concettualmente non c'e` motivo per cui uno debba essere obbligato
a rendere chiave primaria solo la colonna auto incrementante.
Rivedi il tuo schema: e` probabile che tu abbia una colonna in piu`
ed un indice in meno...
bye 

 ed un indice in meno...
Ti ringrazio innanzitutto per l'esaustiva descrizione che mi ha fatto 
capire meglio la funzione delle chiavi.
Io ho sempre usato la chiave primaria per definire campi univoci e 
pertanto sono d'accordo se il DB vedesse in un campo incrementale 
l'unica chiave possibile. Inoltre alla chiave primaria vengono associati 
in genere i trigger di duplicazione e spesso lì dove c'è la chiave 
univoca ci sono anche i collegamenti con altri campi di altre tabelle 
(FK). In questo caso però mi sono imbattuto proprio in un bel problema 
di significato attribuito alla chiave. Come dici tu il dbms che uso 
associa obbligatoriamente all'ID autoincrementante il valore LOGICO di 
chiave primaria quando nella mia tabella la chiave LOGICA è la somma di 
2 campi che ho dovuto rendere univoci creando un indice univoco. 
Purtroppo creare un ID numerico mi semplifica di molto la gestione delle 
FK associate alla tabella e integrarlo anche solo logicamente nella 
chiave per me sarebbe un errore logico perchè in realtà l'ID non è 
chiave. Ma non perchè univoco ma perchè la PK è unica nella tabella.
Tra l'altro manco ordino per ID ma ordino per l'indice univoco, percui 
proprio mi scoccia che ho un campo ID auto_incrementale che uso solo per 
semplificarmi la vita ma che nella realtà mi ostacola la logica. :(
Ma esistono anche altri DBMS che si comportano così? (Rispondi solo 
si/no così non si scopre il DB :) .
Grazie ancora.

 si/no così non si scopre il DB :) .
Chiaramente si`, qualcuno fa a modo suo.