Per eliminare una relazione in Access apri Strumenti database > Relazioni, seleziona la linea che collega le due tabelle e premi Canc oppure usa il comando Elimina. Eliminare la relazione non cancella automaticamente i record delle tabelle, ma rimuove il vincolo che protegge quel collegamento. Se era attiva l’integrità referenziale, dopo la rimozione Access non impedirà più la creazione di record orfani per quella relazione. Per questo è importante capire perché stai eliminando il collegamento e quali conseguenze avrà sul database.
Indice
- Cosa succede eliminando una relazione
- Procedura passo passo
- Quando può essere corretto farlo
- Quando non conviene
- Integrità referenziale
- Query di controllo
- Relazioni e join
- Database multiutente
- FAQ
Cosa significa eliminare una relazione
Una relazione in Access descrive come due campi di tabelle diverse corrispondono tra loro. Nel caso Clienti.IDCliente → Ordini.IDCliente, il record cliente è il padre e gli ordini sono figli. Se elimini la relazione, Clienti e Ordini restano nel database con tutti i loro record, ma Access non considera più quel collegamento una regola strutturale persistente.
Questo significa che eventuali query esistenti possono continuare a contenere join tra le tabelle, ma la protezione dell’integrità referenziale viene meno. È fondamentale distinguere quindi tra relazione salvata e join usato da una singola query.
Procedura passo passo
- Crea un backup del file ACCDB.
- Chiudi tabelle, query, maschere e report che usano gli oggetti interessati.
- Apri Strumenti database > Relazioni.
- Usa Tutte le relazioni se non vedi il collegamento.
- Fai clic sulla linea tra le tabelle finché appare selezionata.
- Premi Canc/Delete oppure usa il menu contestuale Elimina.
- Conferma la rimozione quando Access lo richiede.
- Salva il layout della finestra Relazioni.
- Testa query, maschere e report dipendenti.
Quando può essere corretto eliminare una relazione
Può essere necessario quando la relazione è stata creata tra campi sbagliati, quando stai sostituendo una vecchia chiave naturale con un nuovo ID tecnico, quando il modello dati viene ridisegnato oppure quando una tabella viene dismessa. In questi casi la rimozione è parte di una modifica strutturale pianificata, non un espediente per aggirare un errore.
Per esempio, se Ordini.CodiceCliente è collegato a Clienti.CodiceCliente e hai introdotto IDCliente Autonumerazione, potresti dover eliminare la vecchia relazione dopo aver popolato Ordini.IDCliente e verificato tutti i record. Subito dopo creerai il nuovo collegamento IDCliente → IDCliente con integrità referenziale.
Quando non conviene
Non eliminare una relazione soltanto perché Access impedisce di cancellare un record padre. Quel blocco spesso indica che esistono figli collegati e che la protezione sta funzionando. Rimuovere il vincolo per cancellare il padre può lasciare record orfani e generare errori più difficili da individuare.
Se vuoi eliminare un cliente ma esistono ordini storici, valuta uno stato Inattivo. Se vuoi eliminare anche i figli perché la regola aziendale lo prevede, considera con prudenza l’eliminazione a catena. Se i dati sono incoerenti, correggili prima di toccare la relazione.
Effetto sull’integrità referenziale
Microsoft spiega che rimuovendo una relazione elimini anche il supporto dell’integrità referenziale per quel collegamento. Da quel momento Access non impedisce più di inserire nella tabella figlia una chiave che non esiste nel padre. Inoltre può diventare possibile eliminare il padre lasciando figli con riferimenti non validi.
Per un database operativo questo è un cambiamento significativo. Dopo aver eliminato la relazione, documenta il motivo e indica se il vincolo sarà ricreato in un’altra forma.
Controllare i record orfani
Prima e dopo la modifica puoi usare una query di non corrispondenza:
SELECT Ordini.IDOrdine, Ordini.IDCliente FROM Ordini LEFT JOIN Clienti ON Ordini.IDCliente = Clienti.IDCliente WHERE Clienti.IDCliente IS NULL;Se ottieni risultati prima della rimozione, il database ha già incoerenze o la relazione non applica integrità. Se compaiono dopo, significa che qualche processo ha creato riferimenti invalidi.
Controllare duplicati sul lato uno
Se stai eliminando una relazione perché Access non la considera uno-a-molti, controlla l’unicità:
SELECT CodiceCliente, Count(*) AS Quanti FROM Clienti GROUP BY CodiceCliente HAVING Count(*) > 1;Duplicati sul lato che dovrebbe essere uno indicano un problema di chiave. Potresti non aver bisogno di eliminare definitivamente la relazione: potrebbe bastare correggere i dati e scegliere una chiave più adatta.
Eliminare una relazione non elimina un join di query
Una query può contenere un INNER JOIN o LEFT JOIN tra le stesse tabelle. La rimozione della relazione salvata non necessariamente cancella il join già memorizzato nella query. Per questo devi testare gli oggetti dipendenti e verificare il comportamento uno per uno.
Access usa spesso le relazioni salvate per proporre automaticamente join nelle nuove query. Dopo la rimozione, le nuove query potrebbero non aggiungere automaticamente il collegamento.
Esempio: relazione errata tra clienti e ordini
Supponi che Ordini.IDCliente sia stato collegato per errore a Clienti.IDAgente. I tipi dati sono compatibili, quindi la linea esiste, ma il significato è sbagliato. Prima di eliminare il collegamento, controlla i dati e le query che lo usano. Poi rimuovi la relazione errata e crea Clienti.IDCliente → Ordini.IDCliente.
Attiva integrità referenziale solo dopo aver verificato che tutti gli ID presenti negli ordini abbiano un cliente valido. Questo esempio mostra che eliminare una relazione può essere corretto quando fa parte di una correzione immediata del modello.
Esempio: sostituzione di una chiave naturale
Un database usa Email come chiave primaria dei clienti. Dopo alcuni anni l’azienda capisce che le email cambiano e introduce IDCliente Autonumerazione. Il percorso corretto è aggiungere il nuovo ID, popolare le chiavi esterne nelle tabelle figlie, testare, eliminare la vecchia relazione basata su Email e creare quella nuova basata su IDCliente.
Non eliminare la vecchia relazione all’inizio della migrazione, altrimenti perdi la protezione prima che i nuovi dati siano pronti. Procedi per fasi e conserva un backup.
Relazione, cardinalità e modello dati
Prima di rimuovere un collegamento chiediti quale cardinalità rappresentava. Uno-a-uno, uno-a-molti e molti-a-molti hanno significati diversi. In un molti-a-molti, la relazione diretta di solito non dovrebbe esistere: serve una tabella ponte con due relazioni uno-a-molti.
Se trovi una relazione diretta Ordini → Prodotti che tenta di rappresentare più prodotti per ordine, potrebbe essere un segnale che il modello va normalizzato con DettagliOrdine.
Finestra Relazioni: evitare errori di clic
La linea può essere sottile e difficile da selezionare. Fai clic finché viene evidenziata, poi verifica che sia il collegamento corretto. Se il database è grande, usa Relazioni dirette o riorganizza il layout prima di cancellare qualcosa.
Ricorda che nascondere una tabella dal layout è diverso da eliminare la relazione. Se vuoi soltanto una vista più pulita, non cancellare il vincolo.
Database multiutente e split
In una soluzione front-end/back-end le tabelle condivise risiedono nel back-end. Le relazioni con integrità tra tabelle Access devono essere gestite nel file che contiene fisicamente i dati. Esegui le modifiche quando gli utenti non stanno lavorando e crea backup del back-end.
Il front-end locale può contenere query e maschere che dipendono dalla relazione. Testa una copia del front-end dopo la modifica e distribuiscila solo quando hai verificato tutto.
Access Microsoft 365, Access 2024 e Runtime
La documentazione Microsoft corrente indica la gestione delle relazioni nell’app desktop Access per Microsoft 365 e Access 2024, oltre alle versioni precedenti supportate nelle pagine di riferimento. La scelta 32/64 bit non cambia la logica relazionale. Access Runtime è destinato agli utenti finali e non è l’ambiente completo per progettare la struttura.
Le procedure descritte sono per Windows. Access non dispone di un’app desktop nativa su macOS.
Controllare le dipendenze
Usa il riquadro Dipendenze oggetti per capire quali query, maschere e report usano le tabelle o le query collegate. Rimuovere una relazione non cancella quei riferimenti, ma può cambiare il comportamento delle nuove query e permettere dati che gli oggetti non sono progettati per gestire.
Documenta l’impatto prima della manutenzione, soprattutto se esiste codice VBA che assume l’esistenza di una determinata relazione.
Alternative all’eliminazione
Se vuoi impedire l’integrità solo temporaneamente per una migrazione, valuta un processo controllato su una copia del database. Se il problema è l’eliminazione del padre, considera archiviazione o soft delete. Se il problema sono i tipi dati, correggi i campi. Se esistono record orfani, pulisci i dati.
La rimozione definitiva della relazione dovrebbe essere l’ultima fase di un ridisegno oppure la conseguenza di una regola che non rappresenta più il modello.
Test dopo la rimozione
Prova a inserire un record figlio, crea una query tra le tabelle, apri le maschere principali e genera i report. Se la relazione verrà ricreata, esegui subito i controlli e riattiva l’integrità prima che gli utenti tornino a lavorare.
Verifica inoltre che nessuna procedura VBA o macro dipenda dalla vecchia struttura. Una migrazione di chiavi richiede test end-to-end.
Prestazioni e indici
Eliminare una relazione non elimina necessariamente gli indici dei campi. Tuttavia non usare questo intervento come tecnica di ottimizzazione delle prestazioni. La progettazione relazionale e l’indicizzazione sono aspetti distinti.
Le chiavi esterne usate spesso nei join possono continuare a beneficiare di indici anche se il vincolo cambia. Valuta gli indici in base a query e carichi reali.
Importazioni e migrazioni
Durante una migrazione da Excel o da un vecchio MDB, potresti dover ricostruire le relazioni. Non cancellare i collegamenti esistenti senza una mappa. Esporta o stampa il Relationship Report e annota cardinalità e opzioni a catena.
Dopo l’importazione, cerca duplicati e orfani prima di applicare i nuovi vincoli. La migrazione è un’occasione per correggere il modello, non per perdere le regole che proteggevano i dati.
Errori comuni
Il più grave è eliminare la relazione per “sbloccare” una cancellazione. Altri errori: non fare backup, confondere nascondere la tabella con rimuovere il vincolo, non testare le query, dimenticare tabelle collegate e non documentare la ragione della modifica.
Un database può continuare a funzionare apparentemente bene anche senza integrità, mentre accumula lentamente dati incoerenti. Il problema emerge spesso mesi dopo.
Troubleshooting
Se non riesci a selezionare la relazione, ingrandisci e riordina il layout. Se Access segnala che le tabelle sono in uso, chiudi gli oggetti e assicurati che altri utenti siano disconnessi. Se la relazione ricompare in una query, ricorda che quel join può essere salvato indipendentemente.
Se devi ricreare il vincolo e Access lo rifiuta, controlla tipi dati, indice univoco e record orfani.
FAQ
Eliminare una relazione cancella le tabelle?
No.
Cancella i record?
No. Rimuove il collegamento e le relative regole di integrità.
Posso ricrearla dopo?
Sì, se i campi sono compatibili e i dati permettono di applicare il vincolo.
Le query smettono di funzionare?
Non necessariamente. I join salvati nelle query possono restare; devi testarli.
È meglio disattivare l’integrità o eliminare la relazione?
Dipende dall’obiettivo, ma nessuna delle due opzioni dovrebbe essere usata per nascondere dati incoerenti.
Link utili
Consulta la categoria Guide Access e le guide su creare relazioni, integrità referenziale e vedere tutte le relazioni.
Fonte ufficiale: Microsoft Support: creare, modificare o eliminare una relazione.
Conclusione
Eliminare una relazione in Access rimuove il vincolo, non i dati. Fallo solo quando il modello richiede davvero la rimozione o sostituzione del collegamento. Se l’obiettivo è aggirare un errore di integrità, fermati e correggi la causa. Backup, analisi dei record e test degli oggetti dipendenti sono essenziali per evitare un database apparentemente funzionante ma strutturalmente incoerente.