Per creare relazioni tra tre o più tabelle in Access devi costruire una rete di relazioni coerenti tra coppie di tabelle. Ogni singola relazione collega due origini, ma più collegamenti possono formare un percorso completo, per esempio Clienti → Ordini → DettagliOrdine ← Prodotti. Il punto essenziale è definire prima le regole del processo, scegliere chiavi primarie stabili, creare foreign key compatibili e applicare l’integrità referenziale dove appropriato.
Indice
- Come funziona una rete di relazioni
- Esempio con Clienti, Ordini, DettagliOrdine e Prodotti
- Preparare chiavi e tipi dati
- Creare le relazioni passo passo
- Gestire uno-a-molti, uno-a-uno e molti-a-molti
- Usare tabelle ponte
- Applicare integrità referenziale
- Creare query con più join
- Evitare percorsi ridondanti
- Maschere e sottomaschere
- Database diviso e SQL Server
- Troubleshooting, FAQ e checklist
Una relazione collega sempre due tabelle
Quando si parla di relazioni tra tre o più tabelle, non esiste un unico vincolo “a tre tabelle”. Access crea relazioni fra coppie di tabelle. Il modello complessivo nasce dalla combinazione di queste relazioni. Per esempio Clienti si collega a Ordini, Ordini a DettagliOrdine e Prodotti a DettagliOrdine. La rete permette poi di interrogare i dati attraversando più passaggi.
Questo principio è importante anche nel troubleshooting. Se una query multi-tabella produce risultati sbagliati, analizza prima ogni singolo collegamento. Verifica Clienti-Ordini, poi Ordini-DettagliOrdine e infine Prodotti-DettagliOrdine. È molto più semplice che cercare di interpretare l’intero diagramma contemporaneamente.
Esempio pratico con quattro tabelle
Considera un piccolo gestionale. La tabella Clienti contiene IDCliente, RagioneSociale, Email e Citta. Ordini contiene IDOrdine, IDCliente, DataOrdine e Stato. Prodotti contiene IDProdotto, CodiceProdotto, Descrizione e PrezzoListino. DettagliOrdine contiene IDOrdine, IDProdotto, Quantita, PrezzoUnitario ed eventuale Sconto.
Le relazioni sono Clienti.IDCliente → Ordini.IDCliente, Ordini.IDOrdine → DettagliOrdine.IDOrdine e Prodotti.IDProdotto → DettagliOrdine.IDProdotto. In questo modo puoi sapere quali ordini appartengono a un cliente e quali prodotti compongono ogni ordine senza duplicare descrizioni e dati anagrafici.
Prima fase: identificare le entità
Non iniziare trascinando linee nella finestra Relazioni. Scrivi prima quali entità esistono e che ruolo hanno. Cliente è un’entità, Ordine è un’entità, Prodotto è un’entità. DettagliOrdine rappresenta invece la relazione tra Ordine e Prodotto e contiene dati che appartengono a quella specifica combinazione, come quantità e prezzo applicato.
Se non riesci a spiegare in una frase che cosa rappresenta una tabella, la struttura potrebbe essere troppo confusa. Una buona progettazione rende chiaro lo scopo di ogni oggetto.
Seconda fase: scegliere chiavi primarie stabili
Ogni tabella principale dovrebbe avere una chiave primaria. In Access un campo Autonumerazione è spesso una soluzione pratica. IDCliente, IDOrdine e IDProdotto possono essere Autonumerazione. La chiave identifica la riga e non deve avere necessariamente un significato commerciale.
Evita di usare il nome cliente o la descrizione prodotto come chiave. Possono cambiare, duplicarsi o essere scritti in modo diverso. Un ID tecnico separa l’identità del record dai valori descrittivi.
Terza fase: creare foreign key compatibili
Nelle tabelle figlie crea campi che memorizzano la chiave del padre. Se la primaria è una normale Autonumerazione, la foreign key è generalmente Numero con Dimensione campo Intero lungo. Ordini.IDCliente deve quindi poter contenere l’ID generato in Clienti.
Non impostare la foreign key come nuova Autonumerazione. Genererebbe un valore indipendente e non collegherebbe correttamente il figlio al padre. Questo è uno degli errori più comuni nei primi database Access.
Creare le relazioni nella finestra Relazioni
- Apri il database e vai su Strumenti database > Relazioni.
- Aggiungi Clienti, Ordini, DettagliOrdine e Prodotti.
- Trascina Clienti.IDCliente su Ordini.IDCliente.
- Seleziona Applica integrità referenziale quando i dati lo consentono.
- Trascina Ordini.IDOrdine su DettagliOrdine.IDOrdine.
- Applica l’integrità referenziale.
- Trascina Prodotti.IDProdotto su DettagliOrdine.IDProdotto.
- Controlla cardinalità e tipi.
- Salva il layout.
Con integrità attiva, le relazioni uno-a-molti mostrano normalmente 1 sul lato padre e ∞ sul lato figlio.
Capire la relazione uno-a-molti
Clienti-Ordini è un tipico uno-a-molti. Un cliente può avere zero, uno o molti ordini; ogni ordine appartiene a un solo cliente. IDCliente è univoco in Clienti ma può ripetersi molte volte in Ordini.
Se Ordini.IDCliente ha un indice univoco, potresti impedire per errore la creazione del secondo ordine dello stesso cliente. Sul lato molti i duplicati della foreign key sono normalmente necessari.
Capire il molti-a-molti
Ordini e Prodotti sono molti-a-molti: ogni ordine può contenere molti prodotti e ogni prodotto può apparire in molti ordini. Questo rapporto non va rappresentato con colonne Prodotto1, Prodotto2, Prodotto3. Usa una tabella ponte come DettagliOrdine.
La tabella ponte trasforma il molti-a-molti in due uno-a-molti: Ordini 1→∞ DettagliOrdine e Prodotti 1→∞ DettagliOrdine. È il modello relazionale corretto e rende semplici query, totali e report.
Quando serve una relazione uno-a-uno
Una uno-a-uno è meno comune. Può essere utile se dividi un’entità in due tabelle per esigenze specifiche, per esempio campi opzionali molto particolari o una separazione applicativa. Entrambi i campi collegati devono essere univoci. Non creare una uno-a-uno soltanto perché al momento ogni padre ha un solo figlio: la cardinalità deve riflettere la regola del processo, non il campione di dati corrente.
Integrità referenziale
L’integrità referenziale impedisce che una foreign key non Null punti a un record padre inesistente. È particolarmente importante quando il database cresce e quando più maschere, query o utenti inseriscono dati.
Se Access rifiuta il vincolo, controlla prima record orfani, duplicati sul lato uno, tipi incompatibili e Dimensione campo. Con dati già popolati, il rifiuto è spesso un segnale utile di incoerenza da correggere.
Come trovare record orfani
SELECT Ordini.IDOrdine, Ordini.IDCliente FROM Ordini LEFT JOIN Clienti ON Ordini.IDCliente = Clienti.IDCliente WHERE Clienti.IDCliente IS NULL AND Ordini.IDCliente IS NOT NULL;Ogni riga restituita indica un ordine che contiene un riferimento senza cliente corrispondente. Non eliminare automaticamente: verifica se il valore è errato, se il cliente è stato cancellato o se la migrazione è incompleta.
Controllare ogni tratto della rete
Ripeti lo stesso principio per DettagliOrdine→Ordini e DettagliOrdine→Prodotti. In una rete di relazioni, l’integrità complessiva dipende dalla correttezza di ogni singolo collegamento. Una sola foreign key incoerente può far sparire righe dalle query con INNER JOIN.
Eliminazione a catena
Non attivarla automaticamente. Se elimini un ordine, in alcuni sistemi può avere senso eliminare i dettagli perché non hanno significato autonomo. Se elimini un cliente, invece, cancellare automaticamente lo storico ordini potrebbe essere inaccettabile. Spesso è meglio impedire la cancellazione e usare un campo Attivo o Archiviato.
Aggiornamento a catena
Con chiavi Autonumerazione normalmente non serve perché la primaria non cambia. Se usi una chiave naturale modificabile può essere utile, ma la necessità frequente di rinumerare chiavi è spesso un segnale che conviene introdurre un ID tecnico stabile.
Creare una query che attraversa quattro tabelle
SELECT Clienti.RagioneSociale, Ordini.IDOrdine, Prodotti.Descrizione, DettagliOrdine.Quantita FROM ((Clienti INNER JOIN Ordini ON Clienti.IDCliente = Ordini.IDCliente) INNER JOIN DettagliOrdine ON Ordini.IDOrdine = DettagliOrdine.IDOrdine) INNER JOIN Prodotti ON DettagliOrdine.IDProdotto = Prodotti.IDProdotto;La query segue il percorso relazionale. Access usa spesso parentesi quando combina più join; non rimuoverle arbitrariamente nella Visualizzazione SQL.
Relazione e join non sono la stessa cosa
La relazione è una regola strutturale del database e può applicare integrità. Il join appartiene alla query e decide come combinare i record. Quando aggiungi tabelle già correlate a una query, Access può creare automaticamente i join, ma puoi modificarli per ottenere il risultato desiderato.
INNER JOIN e LEFT JOIN
INNER JOIN mostra soltanto righe con corrispondenza. LEFT JOIN mantiene tutti i record del lato sinistro anche senza match. Se vuoi elencare tutti i clienti, compresi quelli senza ordini, usa un LEFT JOIN da Clienti verso Ordini.
La scelta del join non modifica la cardinalità strutturale. La relazione può restare Clienti 1:N Ordini mentre query diverse usano join diversi.
Evitare relazioni ridondanti
Se DettagliOrdine è già collegata a Ordini e Ordini a Clienti, evita di aggiungere anche IDCliente in DettagliOrdine soltanto per accorciare una query. Avresti due percorsi per determinare il cliente e potresti creare incoerenza se i valori non coincidono.
La ridondanza va introdotta solo con una motivazione precisa e documentata, non per comodità momentanea.
Più ruoli verso la stessa tabella
È possibile che una tabella contenga più foreign key verso la stessa tabella padre. Ordini potrebbe avere IDAgente e IDResponsabile entrambi verso Utenti, oppure IDClienteFatturazione e IDClienteSpedizione entrambi verso Clienti.
Queste non sono relazioni duplicate se hanno significati diversi. Usa nomi chiari e documenta i ruoli.
Relazioni fra cinque o più tabelle
Il principio non cambia. Aggiungi ogni entità necessaria e collega le coppie secondo le regole reali. In un gestionale completo potresti avere Clienti→Ordini→DettagliOrdine←Prodotti→Categorie e Ordini→Pagamenti. Ogni linea deve avere una motivazione precisa.
Non collegare tutto a tutto
Una rete più fitta non è necessariamente migliore. Se due tabelle sono già collegate logicamente attraverso un’altra entità, una relazione diretta aggiuntiva può essere ridondante. Preferisci un modello che rappresenti i fatti senza percorsi ambigui.
Progettare le tabelle prima delle maschere
Le maschere devono poggiare su un modello già deciso. Se inizi dall’interfaccia, rischi di inserire campi duplicati soltanto perché vuoi mostrarli nella stessa schermata. Access permette di usare query e combo per visualizzare dati provenienti da tabelle correlate senza copiarli.
Combo box e ID
Una combo in Ordini può mostrare RagioneSociale ma salvare IDCliente. La colonna associata contiene la foreign key; le colonne visibili possono contenere informazioni comprensibili per l’utente. Questo separa correttamente interfaccia e struttura.
Maschera principale e sottomaschera
Per Ordini e DettagliOrdine usa una maschera principale Ordini e una sottomaschera DettagliOrdine. Imposta Link Master Fields e Link Child Fields su IDOrdine. Access può così assegnare automaticamente la foreign key ai nuovi dettagli.
Prodotto nella sottomaschera
Usa una combo che mostra CodiceProdotto e Descrizione ma salva IDProdotto. L’utente non deve digitare l’ID. Questo riduce errori e rende più naturale l’inserimento.
Importazioni da Excel
Se importi dati esterni, non accodarli subito alle tabelle operative. Usa tabelle di staging, pulisci codici, tipi e spazi, mappa gli identificatori esterni verso gli ID interni e controlla i record senza corrispondenza.
Una rete di relazioni con integrità può bloccare importazioni non valide, ma è meglio intercettare gli errori prima che arrivino alle tabelle definitive.
Migrare una vecchia struttura
Se un database usa nomi o codici instabili per collegare le tabelle, crea nuovi campi ID, popola le foreign key tramite query di mapping e mantieni temporaneamente i vecchi campi. Verifica query, maschere, report e VBA prima di eliminare la struttura precedente.
Backup prima di cambiare relazioni
Prima di rinominare campi, cambiare tipi o rimuovere relazioni crea un backup completo. In multiutente pianifica la manutenzione con utenti disconnessi dal back-end. Una modifica strutturale può influenzare molti oggetti anche senza cancellare dati.
Contare i record prima e dopo
SELECT Count(*) AS NumeroOrdini FROM Ordini;Confronta i conteggi prima e dopo migrazioni o query di aggiornamento. Aggiungi controlli per anno, stato o altra dimensione significativa quando il semplice totale non è sufficiente.
Controllare duplicati
SELECT CodiceCliente, Count(*) AS Quanti FROM Clienti GROUP BY CodiceCliente HAVING Count(*) > 1;Se CodiceCliente deve essere univoco, la query deve restituire zero righe. Se restituisce duplicati, correggili prima di creare un indice univoco o usarlo come chiave.
Indici sulle foreign key
Le chiavi primarie sono indicizzate. Sulle foreign key usate frequentemente nei join può essere utile un indice che consenta duplicati. Non creare un indice univoco sul lato molti se più figli devono poter puntare allo stesso padre.
Prestazioni nelle query multi-tabella
Seleziona solo i campi necessari, usa criteri selettivi e controlla che i campi di join siano indicizzati in modo ragionevole. Una struttura corretta viene prima delle micro-ottimizzazioni. Query lente possono dipendere da tabelle molto grandi, origini remote o funzioni non indicizzabili.
Database front-end/back-end
In un database Access multiutente è buona pratica dividere dati e applicazione. Le tabelle risiedono nel back-end condiviso; ogni utente usa un front-end locale con query, maschere, report e VBA.
Le relazioni che devono applicare integrità fra tabelle Access vanno definite nel back-end che contiene fisicamente i dati, non soltanto nel front-end.
Quando il back-end è SQL Server
Se le tabelle sono collegate a SQL Server, primary key, foreign key e vincoli autorevoli devono essere definiti sul server. Access può continuare a usare le tabelle collegate e creare query, ma non deve essere l’unico punto di protezione.
Access Microsoft 365 e Access 2024
La procedura riguarda Access desktop per Windows, incluso Access per Microsoft 365 e Access 2024. La scelta 32/64 bit non cambia la logica delle relazioni; riguarda soprattutto compatibilità con driver, componenti e codice VBA esterno.
Access Runtime è pensato per l’esecuzione di applicazioni già progettate, non per la manutenzione completa dello schema. Access non dispone di una versione desktop nativa equivalente per macOS e non va descritto come una soluzione Web/browser.
Documentare una rete di relazioni
Organizza la finestra Relazioni in modo leggibile e genera un Relationship Report quando serve. Affianca al diagramma un dizionario dati con tabelle, primarie, foreign key, tipi, indici e note.
Per ogni relazione scrivi una frase: “Un cliente può avere molti ordini; ogni ordine appartiene a un cliente; l’eliminazione del cliente è bloccata se esistono ordini”. Le frasi rendono esplicite cardinalità, obbligatorietà e politica di cancellazione.
Versionare le modifiche
Conserva un changelog con data, motivo, campi aggiunti, relazioni modificate e oggetti aggiornati. Se il database viene manutenuto da più persone, la documentazione riduce il rischio di ripristinare involontariamente un vecchio modello.
Test end-to-end
Inserisci un nuovo cliente e un ordine valido. Prova un ordine con IDCliente inesistente: con integrità attiva deve essere bloccato. Inserisci dettagli con prodotti validi e prova un IDProdotto inesistente. Verifica infine query e report.
Test delle cancellazioni
Prova su una copia cosa accade eliminando un padre con figli. Il comportamento deve corrispondere alla regola aziendale. Non scoprire in produzione che la cascata cancella più dati di quanto immaginato.
Test dei Null
Se un collegamento è opzionale, una foreign key Null può essere corretta. Se è obbligatorio, imposta Required e guida l’utente tramite la maschera. L’integrità referenziale da sola non trasforma necessariamente un campo opzionale in obbligatorio.
Troubleshooting: Access non crea una relazione
Controlla chiave primaria o indice univoco sul lato uno, tipi dati, Dimensione campo e record orfani. Con Autonumerazione usa normalmente Numero/Intero lungo nel figlio.
Troubleshooting: vedo uno-a-uno invece di uno-a-molti
Controlla l’indice della foreign key. Se è impostato su Duplicati non ammessi, il campo non può ripetersi. In una vera relazione uno-a-molti il lato molti deve accettare lo stesso ID padre più volte.
Troubleshooting: la query restituisce troppe righe
Verifica se stai attraversando una relazione molti-a-molti e se la tabella ponte è corretta. Controlla che ogni coppia di tabelle abbia il join necessario. Due tabelle aggiunte senza join possono creare un prodotto cartesiano.
Troubleshooting: la query perde righe
Un INNER JOIN elimina i record senza corrispondenza. Se vuoi mantenerli usa un LEFT JOIN appropriato. Controlla anche criteri applicati ai campi della tabella esterna, perché possono escludere i Null.
Troubleshooting: la maschera salva l’ID sbagliato
Controlla Origine riga, Colonna associata e Numero colonne della combo. La descrizione mostrata non deve essere necessariamente il valore salvato.
Errori comuni
- Collegare nomi invece di ID.
- Creare foreign key Autonumerazione.
- Mettere più prodotti in colonne ripetute.
- Aggiungere relazioni dirette ridondanti.
- Attivare cascata senza test.
- Ignorare record orfani preesistenti.
- Progettare le maschere prima dello schema.
- Modificare il front-end quando il vincolo deve stare nel back-end.
Checklist finale
- Ogni tabella ha uno scopo chiaro.
- Le entità hanno primarie stabili.
- Le foreign key sono compatibili.
- Ogni relazione ha una cardinalità motivata.
- I molti-a-molti usano tabelle ponte.
- L’integrità referenziale è applicata dove appropriato.
- Le cascata sono documentate.
- Non esistono orfani inattesi.
- Le query multi-tabella sono testate.
- Maschere e combo salvano gli ID corretti.
- Il diagramma è documentato.
- Esiste un backup prima delle modifiche.
FAQ
Posso collegare tre tabelle con una sola relazione?
No. Crei più relazioni fra coppie di tabelle, che insieme formano la rete.
Devo collegare direttamente tutte le tabelle?
No. Crea soltanto i collegamenti che rappresentano fatti reali e non sono ridondanti.
Posso usare query con più di tre tabelle?
Sì. Access può creare query con più join, purché la struttura sia coerente.
32 o 64 bit cambia le relazioni?
No, non cambia la logica del modello.
Access Runtime permette di progettare la rete?
Runtime è destinato all’esecuzione; per progettazione usa Access completo.
Posso usare Access con SQL Server?
Sì. Access può essere front-end, mentre le foreign key autorevoli risiedono sul server.
Link utili
Consulta la categoria Guide Access, come creare relazioni tra tabelle, integrità referenziale, tabella ponte e creare join tra tabelle.
Fonti Microsoft: Guide to table relationships, Create, edit or delete a relationship e Create a query based on multiple tables.
Conclusione
Creare relazioni tra tre o più tabelle in Access significa progettare correttamente una rete di collegamenti semplici. Se ogni tabella ha una responsabilità chiara, ogni chiave è stabile e ogni foreign key è protetta, anche un modello con molte entità rimane comprensibile. La qualità della rete relazionale determina quanto saranno semplici query, maschere, report e future migrazioni.