Newsgroup: it.comp.appl.access
Titolo: chiave primaria multipla un po' particolare

ho una esigenza un po' particolare: in una tabella ho tre campi la cui
CONCATENAZIONE identifica univocamente i record contenuti nella
tabella. vorrei sfruttare la possibilità di una chiave multipla, per
non inserire una aggiuntiva campo di tipo contatore da utilizzare da
chiave (visto che è una fact table di un datawarehouse vorrei evitare
inutili sprechi).il problema è che i singoli campi che vorrei inserire
nella chiave multipla possono avere anche valore nullo, ma il record è
comunque identificato univocamente dalle restanti chiavi.  il valore
NULL significherebbe realmente che non è previsto un valore per tale
campo e mai lo sara'. non vorrei inserire un valore fittizio al posto
di NULL.
cerco di spiegarmi meglio con un esempio. Potrei avere le seguenti
chiavi:
key1 key2 key3 
1    NULL NULL
1    1    NULL
1    1    1
2    NULL NULL
...
1    2    NULL
1    3    NULL
...
1    1    2
1    1    3
...
1    2    1
1    2    2
...
esiste qualche soluzione per tale problema? faccio notare che per
questo progetto non sto utilizzando Access, ma Oracle. Mi sono
permesso di scrivere questo post su questo forum poichè ho sempre
trovato qui grande competenza e poichè credo che sia piu' un problema
che riguardi il mondo dei database che il DBMS specifico.
Grazie in anticipo
Buona giornata a tutti
Wild^_^

 questo progetto non sto utilizzando Access, ma Oracle.
Vedo due possibilità:
1) Individua un valore "impossibile" (0, -1, ecc.) e, tramite un trigger
Before Insert, metti questo valore nei campi della chiave che dovrebbero
essere null.
2) Individua un valore "impossibile" (0, -1, ecc.) e mettilo come valore di
default dei campi interessati; quindi omettili dall'istruzione INSERT quando
dovrebbero essere null.
HTH.
Alessandro

 questo progetto non sto utilizzando Access, ma Oracle. [CUT]
Ciao wild,
in qualsiasi database la caratteristica Primary Key esclude l'utilizzo dei
null nei campi che la compongono.
Potresti semplicemente usare un indice univoco ottenendo il risultato voluto
Creo la tabella
---------------
Create table Prova
(Campo1 int ,Campo2 int ,Campo3 int,
 CONSTRAINT IX_Prova UNIQUE (Campo1,Campo2,Campo3)
)
---------------
Inserisco alcuni dati
----------------
Insert Prova Values(1,NULL,NULL)
Insert Prova Values(1,1,NULL)
Insert Prova Values(1,1,1)
---------------
Ciao Giorgio

 di NULL.
Metti comunque un valore fittizio, poi quando devi interrogare i dati, se
c'è il valore fittizio, restituisci null o stringa vuota
Antonio

 ha scritto nel messaggio 
news:cucsb2$hc1$1...@newsread.albacom.net...

Creati un controllo "calcolato" dall'unione dei vari campi e usa quello come 
PK
Ora se un o più campi sono vuoti non te ne frega
MAssimiliano


Mannaggia, ero quasi convinto che con Access fosse possibile avere una PK
null, ma devo aver avuto le traveggole.
Inoltre mi era sfuggito che wild preferiva evitare valori fittizi: mi scuso
quindi con il NG e con l'interessato per il mio inutile post precedente.
Naturalmente la soluzione di Giorgio sembra la più appropriata, anche se un
indice Unique non è *esattamente* la stessa cosa di una Primary Key...
Alessandro

 Ora se un o pių campi sono vuoti non te ne frega
Per un DW non mi pare la soluzione ottimale...
Alessandro

 indice Unique non č *esattamente* la stessa cosa di una Primary Key...
no, non č la stessa cosa, la Primary Key ordina automaticamente le righe
della tabella, ma a parte questo non vedo altre differenze rispetto a un
indice univoco.
Ciao Giorgio

 news:dfaed9d8.05020...@posting.google.com...
umm... non so se Oracle ha gli indici Clustered,
In Ms Sql Server un indice Clustered ordina automaticamente le righe della
tabella proprio come farebbe la Primary Key
----------
Create table Prova
(Campo1 int ,Campo2 int ,Campo3 int,
 CONSTRAINT IX_Prova UNIQUE CLUSTERED (Campo1,Campo2,Campo3)
)
----------
Ciao Giorgio

 rispetto a un indice univoco.
Mi pare di ricordare ci fossero delle differenze nella dimensione
dell'indice (l'analyze riportava un'occupazione di spazio maggiore per gli
Unique). Poi, ma qui sono ancora meno sicuro, c'erano differenze nel
partitioning, ma stiamo andando un po' OT...
Alessandro

ringrazio tutti per la grande partecipazione al mio problema. Adoro
questo newsgroup proprio per questo. sto valutando bene le vostre
altrenative. anche se in prima analisi la soluzione che prevedeva
l'uso della UNIQUE mi era sembrata ottimale, ho ancora qualche dubbio
per il fatto della indicizzazione (che ovviamente essendo una fact
table è un problema non da poco). secondo il vostro parere è la stessa
cosa se creo un indice per ogni chiave utilizzando la UNIQUE al  posto
della PK? stavo, fra l'altro, anche pensando a chiavi a doppio
livello...
in uno dei primi post si è parlato di mettere la PK sul valore
"calcolato" che concatenava le tre chiavi...è stata una delle prime
cose che ho cercato di fare appena mi ero reso conto del problema che
non potevo avere valori Nulli nelle PK.
grazie ancora per la collaborazione
Wild^_^

 della tabella proprio come farebbe la Primary Key
Ora siamo decisamente fuori dalla mia (limitata) sfera di conoscenze, ma qui
credo proprio ci sia qualcosa di simile, se non uguale, ai Clustered
indexes:
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10743/schema.htm#sthref883
In particolare, credo che per un DW siano generalmente consigliati i Bitmap
indexes...
HTH.
Alessandro

 non potevo avere valori Nulli nelle PK.
si, ma ti devi inventare un sostitutivo al valore Null, se hai i campi
valorizzati in questo modo
---------
key1 key2 key3
1    NULL 1
1    1    NULL
NULL 1 1
---------
e concateni i valori ti ritroverai tre chiavi identiche
(ps non ricordavo che in Access non funziona un indice univoco composto da
piů campi i quali possono assumere valore NULL  )
Ciao Giorgio