Newsgroup: it.comp.software.database
Titolo: Access - Integrità referenziale su chiave parziale

In un database, ho una tabella di questo genere (facciamo conto che si
tratti di rilievi effettuati su alberi):
Tabella:         [Rilievi]
Elenco campi:    Codice albero
                 Numero rilievo
                 Altri dati
                 ....
La chiave è [Codice albero]+[Numero rilievo]. E' ovvio che nel modello del
sistema esistono concettualmente oggetti "Albero", identificati da [Codice
albero], in relazione uno a molti con la tabella rilievi. Per vari motivi
però io non ho interesse ad avere una tabella [Alberi]: è ben vero che
alcuni attributi appartengono teoricamente all'albero e non al rilievo, ma
in pratica questa distinzione non è conveniente, e finirei per avere una
tabella assai poco interessante, con un unico campo (l'identificativo
[Codice albero], appunto). Lo stesso per quasi tutte le altre tabelle del
database, che si possono convenientemente considerare riferite agli oggetti
Rilievi.
Se non che, ho una (e una sola) altra tabella (facciamo conto che si tratti
di spese di manutenzione) chiaramente riferita agli oggetti Alberi, e non
ai Rilievi:
Tabella:         [Spese]
Elenco campi:    Codice albero
                 Anno
                 Altri dati
                 ....
Ora, io vorrei imporre un controllo di integrità referenziale sul campo
[Codice albero] della tabella [Spese], nel senso che questo deve riferirsi
ad un [Codice albero] presente nella tabella [Rilievi]. Access non me lo
consente (e probabilmente ha ragione lui), perché nella tabella [Rilievi]
non esiste (né potrebbe esistere) un indice univoco sul campo [Codice
albero]. Né posso evidentemente rendere univoco il campo [Spese].[Codice
albero], potendo esistere più spese riferite ad uno stesso albero.
La domanda, per chi ha avuto la pazienza di leggere fin qui, è: qual è il
modo più conveniente e corretto per garantire l'integrità referenziale fra
la tabella [Rilievi] e la tabella [Spese]? devo proprio necessariamente
introdurre la tabella [Alberi], che non avrebbe nessun'altra
giustificazione pratica?
Se impongo, nelle proprietà del campo [Spese].[Codice albero], una funzione
di ricerca, che peschi in [Rilievi].[Codice albero], con opzione "Solo in
elenco", questa può essere considerata una condizione sufficiente a
garantire l'integrità referenziale (considerato anche che accederò al
database con un programma esterno, non direttamente con l'interfaccia di
Access)? Quale altra strada potrei legittimamente prendere?
Ciao.

 tratti di rilievi effettuati su alberi):
In Oracle potresti anche creare una materialized view, fast refresh on
commit, con un campo = substr(chiave,1,<parte che ti interessa>) e
mettere la PK sulla materialized view
L'unica controindicazione e' che la chiave viene verificata sul
commit, e che se non e' verificata viene fatto il rollback di tutta la
transazione

transazione
Chiedo scusa, è passato diverso tempo e non mi ero reso conto che
qualcuno mi aveva risposto.
Ringrazio per l'interessamento. Un controllo è sempre meglio che
nessun controllo, e potrei anche accettare le limitazioni che dici.
Purtroppo però sono vincolato all'uso di Access, in cui non c'è nulla
di quello di cui parli.
Ciao.