Una relazione Access è probabilmente progettata male quando collega campi instabili o non univoci, produce duplicati inattesi, non consente l’integrità referenziale, costringe a ripetere dati oppure tenta di rappresentare un molti-a-molti senza tabella ponte. Il modo migliore per valutarla è controllare cardinalità, chiavi, tipi dati e dati reali, non soltanto osservare se una query restituisce risultati.
Indice
- Segnali di una relazione sbagliata
- Cardinalità
- Chiavi
- Duplicati
- Record orfani
- Molti-a-molti
- Join
- Correzione passo passo
- FAQ
Segnale 1: il campo usato come chiave può cambiare
Se Clienti e Ordini sono collegati tramite NomeCliente o Email, la relazione è fragile. Nomi possono duplicarsi; email possono cambiare. Una chiave tecnica come IDCliente Autonumerazione è più stabile. La descrizione rimane visibile all’utente tramite query e combo box, mentre il collegamento usa l’ID.
Una relazione ben progettata deve sopravvivere alle normali modifiche dei dati descrittivi.
Segnale 2: il lato uno contiene duplicati
In una relazione uno-a-molti il lato uno deve essere univoco. Se pensi che CodiceCliente rappresenti un cliente ma trovi duplicati, non hai un vero lato uno. Controlla con:
SELECT CodiceCliente, Count(*) AS Quanti FROM Clienti GROUP BY CodiceCliente HAVING Count(*) > 1;Se la query restituisce righe, correggi i duplicati o scegli una chiave diversa.
Segnale 3: Access non applica l’integrità referenziale
Se i tipi sono compatibili e le tabelle sono nello stesso back-end, l’impossibilità di applicare l’integrità spesso segnala record orfani o assenza di unicità sul padre. Non risolvere disattivando il vincolo: trova la causa.
Microsoft indica che l’integrità richiede una primaria o indice univoco sul lato uno e campi compatibili.
Segnale 4: esistono record orfani
Un ordine con IDCliente inesistente è un segnale che il modello o il processo di inserimento non protegge i dati. Trova gli orfani:
SELECT Ordini.IDOrdine, Ordini.IDCliente FROM Ordini LEFT JOIN Clienti ON Ordini.IDCliente = Clienti.IDCliente WHERE Clienti.IDCliente IS NULL;Se sono numerosi, indaga importazioni, cancellazioni e maschere che permettono valori non validi.
Segnale 5: hai colonne Prodotto1, Prodotto2, Prodotto3
Questo schema tenta di rappresentare un elenco variabile dentro una singola riga. È un classico errore di normalizzazione. Crea una tabella DettagliOrdine con IDOrdine e IDProdotto e due relazioni uno-a-molti.
Il database diventa più flessibile perché un ordine può avere qualunque numero di prodotti senza cambiare struttura.
Segnale 6: duplicati inattesi nelle query
Una query che restituisce più righe del previsto può indicare una cardinalità diversa da quella immaginata. Se un cliente ha cinque ordini e ogni ordine ha tre dettagli, una query che include DettagliOrdine può mostrare fino a quindici righe: non sono necessariamente duplicati errati, ma il risultato ha granularità più fine.
Se invece il lato uno contiene duplicati reali, ogni join moltiplicherà le righe. Controlla il modello prima di usare DISTINCT.
Segnale 7: devi usare DISTINCT ovunque
DISTINCT è utile in query specifiche, ma se diventa un cerotto sistematico per rimuovere righe duplicate, il modello o i join potrebbero essere sbagliati. Analizza chiavi e cardinalità. Una query corretta dovrebbe produrre la granularità attesa senza nascondere problemi.
Chiediti quale entità rappresenta ogni riga del risultato.
Segnale 8: la chiave esterna è Autonumerazione
Se il padre usa Autonumerazione, il figlio deve normalmente usare Numero/Intero lungo per memorizzare l’ID del padre. Una chiave esterna Autonumerazione genera valori propri e non rappresenta correttamente il collegamento.
Questo errore è frequente nei database creati senza distinguere primaria ed esterna.
Segnale 9: colleghi campi solo perché hanno lo stesso tipo
IDOrdine e IDCliente possono essere entrambi numerici ma rappresentano entità diverse. Il tipo compatibile è necessario ma non sufficiente. Verifica sempre il significato. I nomi dei campi dovrebbero aiutare a evitare collegamenti semanticamente sbagliati.
Una relazione corretta collega lo stesso identificatore in due contesti diversi.
Segnale 10: cancelli una relazione per aggirare un errore
Se Access blocca una cancellazione del padre, probabilmente esistono figli. Eliminare il vincolo per poter cancellare il record può creare orfani. Decidi se i figli devono restare, essere archiviati o essere eliminati con una regola a catena consapevole.
Il messaggio di integrità è un’informazione sul modello, non un ostacolo da rimuovere.
Controllare la cardinalità reale
Uno-a-molti: un cliente ha molti ordini. Uno-a-uno: un record padre corrisponde al massimo a un figlio. Molti-a-molti: molti ordini contengono molti prodotti e serve una tabella ponte. La cardinalità deriva dalle regole aziendali, non dalla disposizione grafica delle tabelle.
Intervista chi usa il processo: può un cliente avere più ordini? Può un ordine avere più prodotti? Può un prodotto essere in più ordini? Le risposte definiscono il modello.
Controllare gli indici
La chiave primaria è indicizzata e univoca. La chiave esterna di una relazione uno-a-molti deve normalmente consentire duplicati. Se imposti Ordini.IDCliente come indice univoco, ogni cliente potrà avere un solo ordine, trasformando di fatto il modello.
Gli indici devono riflettere cardinalità e requisiti di ricerca.
Controllare i tipi dati
Autonumerazione padre ↔ Numero/Intero lungo figlio è una coppia comune. Testo breve deve collegarsi a testo compatibile. Se importi da Excel, verifica che i codici numerici non siano stati letti come testo e che non esistano valori misti.
Prima di convertire, crea backup e query di controllo.
Controllare i Null
Un Null nella chiave esterna può essere valido se la relazione è opzionale. Se ogni Ordine deve avere un Cliente, però, rendi IDCliente obbligatorio. L’integrità da sola non significa necessariamente che il campo non possa essere Null.
La regola di obbligatorietà appartiene al dominio e va impostata esplicitamente.
Relazione e join non sono la stessa cosa
La relazione salvata descrive il modello e può applicare integrità. Un join in una query decide come combinare i record. Una relazione corretta può essere usata con INNER JOIN o LEFT JOIN a seconda dell’analisi.
Se una query non restituisce ciò che vuoi, controlla sia il modello sia il tipo di join.
Esempio di relazione male progettata
Ordini.NomeCliente è collegato a Clienti.NomeCliente. Due clienti possono chiamarsi “Mario Rossi”; inoltre il nome può essere corretto. Le query possono associare un ordine a più anagrafiche. La soluzione è introdurre IDCliente Autonumerazione e memorizzarlo in Ordini come Numero/Intero lungo.
Popola il nuovo ID tramite una fase di migrazione controllata e poi applica integrità.
Esempio molti-a-molti sbagliato
Ordini contiene IDProdotto e Prodotti contiene IDOrdine. Questo crea ambiguità e limita il numero di collegamenti. La soluzione è DettagliOrdine: IDOrdine, IDProdotto, Quantità, PrezzoUnitario. Due relazioni uno-a-molti rappresentano correttamente il molti-a-molti.
La tabella ponte conserva anche gli attributi della relazione.
Esempio uno-a-uno sospetto
Se Clienti e DatiCliente sono uno-a-uno senza una ragione specifica, valuta se i campi potrebbero stare nella stessa tabella. Una separazione uno-a-uno può essere giustificata da sicurezza, modularità o dati opzionali molto estesi, ma non dovrebbe essere automatica.
Ogni tabella aggiuntiva aumenta la complessità delle query.
Procedura per correggere una relazione
- Crea backup.
- Documenta la relazione attuale.
- Verifica cardinalità reale.
- Controlla chiavi e tipi.
- Cerca duplicati.
- Cerca record orfani.
- Progetta la nuova struttura.
- Popola eventuali nuovi ID.
- Rimuovi la relazione errata.
- Crea quella corretta.
- Attiva integrità.
- Testa query, maschere e report.
Non cambiare tutto in una volta
Se devi introdurre una nuova chiave, mantieni temporaneamente il vecchio campo, popola il nuovo e confronta i risultati. Solo dopo che tutte le query funzionano con il nuovo ID puoi dismettere la vecchia relazione. Questo riduce il rischio di perdere il mapping.
Le migrazioni strutturali devono essere reversibili almeno fino al completamento dei test.
Controllare Dipendenze oggetti
Una relazione può essere usata indirettamente da query, maschere e report. Prima di rinominare campi o eliminare colonne usa Dipendenze oggetti. Cerca anche riferimenti nel VBA e nelle macro.
Un modello corretto non serve se l’interfaccia continua a scrivere nel vecchio campo.
Maschere e combo box
Le combo devono mostrare descrizioni ma salvare ID. Se una combo salva NomeCliente, stai reintroducendo una chiave instabile a livello di interfaccia. Imposta Bound Column sull’ID e nascondi la colonna tecnica se necessario.
Testa l’inserimento di nuovi record e verifica il valore effettivamente memorizzato nella tabella.
Aggiornamento a catena come segnale
Se devi rinumerare continuamente la primaria, chiediti se è la chiave giusta. Aggiorna campi correlati a catena è utile per chiavi realmente modificabili, ma una chiave tecnica stabile riduce la necessità della funzione.
Non modificare Autonumerazioni per ragioni estetiche.
Eliminazione a catena come segnale
Se cancellare un padre elimina grandi quantità di dati storici, la relazione o la politica di cancellazione potrebbe essere sbagliata. Per clienti, prodotti e fornitori usa spesso uno stato inattivo. La cascata è più adatta a dati figli che non hanno senso senza il padre.
Documenta ogni cascata e testala su copia.
Database multiutente
In un database split definisci i vincoli nel back-end che contiene le tabelle. Esegui modifiche strutturali senza utenti connessi. Ogni utente dovrebbe avere un front-end locale.
Se il back-end è SQL Server, definisci foreign key e vincoli nel server.
Access Microsoft 365, Access 2024 e Runtime
La finestra Relazioni e l’integrità sono funzioni dell’app desktop Access per Windows, inclusi Microsoft 365 e Access 2024. 32/64 bit non cambia cardinalità e chiavi. Runtime è per eseguire applicazioni e non per progettare il modello.
Access desktop non è disponibile nativamente per macOS.
Prestazioni
Relazioni corrette e indici appropriati migliorano anche la prevedibilità delle query. Una chiave esterna indicizzata può accelerare join. Ma la prestazione non giustifica un modello concettualmente sbagliato: prima la correttezza, poi l’ottimizzazione.
Su volumi elevati valuta un back-end server mantenendo lo stesso schema logico.
Documentazione
Genera un Relationship Report e annota per ogni linea: padre, figlio, campi, cardinalità, integrità, cascata e motivazione. Questa documentazione aiuta a individuare rapidamente relazioni anomale e facilita il passaggio di consegne.
Il Database Documenter può integrare le informazioni sugli oggetti.
Test di qualità del modello
Prova a modificare un nome cliente: gli ordini restano collegati? Prova due clienti omonimi: vengono distinti? Prova più ordini per cliente: il modello lo consente? Prova più prodotti per ordine: puoi inserirli senza aggiungere colonne? Prova un ID inesistente: l’integrità lo blocca?
Questi test pratici rivelano rapidamente errori progettuali.
FAQ
Una query che funziona dimostra che la relazione è corretta?
No.
Devo sempre vedere 1 e ∞?
Quando l’integrità è applicata a una vera relazione uno-a-molti, normalmente sì.
Perché vedo duplicati?
Potrebbero essere righe legittime del lato molti oppure un problema di chiavi/join.
Posso usare Email come primaria?
Tecnicamente sì se univoca, ma spesso è meglio un ID stabile perché l’email può cambiare.
Come correggo molti-a-molti?
Con una tabella ponte.
Link utili
Consulta la categoria Guide Access, creare relazioni, integrità referenziale, tabella ponte e chiavi primarie ed esterne.
Fonti Microsoft: guida alle relazioni e creare e modificare relazioni.
Conclusione
Una relazione è progettata bene quando le chiavi sono stabili, la cardinalità riflette il processo reale, l’integrità può essere applicata e le query producono risultati coerenti senza trucchi. Se trovi duplicati, orfani, campi ripetuti o chiavi descrittive fragili, correggi il modello prima che il database cresca.