Per modellare un database relazionale in Access devi partire dai processi e dalle entità, non dalle maschere. Identifica quali informazioni devono essere memorizzate, separale in tabelle coerenti, scegli chiavi primarie stabili, definisci foreign key e cardinalità, applica l’integrità referenziale e soltanto dopo costruisci query, maschere e report.
Indice
- Raccogliere i requisiti
- Identificare entità e attributi
- Normalizzare
- Scegliere le chiavi
- Definire cardinalità
- Creare foreign key
- Gestire molti-a-molti
- Applicare integrità referenziale
- Progettare query
- Creare maschere
- Testare e documentare
- FAQ
Partire dai requisiti, non dall’interfaccia
Un errore frequente è aprire Access e iniziare subito a creare maschere. La maschera è soltanto l’interfaccia. Prima devi capire quali fatti devono essere memorizzati e quali relazioni esistono fra essi.
Scrivi le domande che il database dovrà poter rispondere: quali clienti hanno effettuato ordini? quali prodotti sono stati venduti? quali ordini sono ancora aperti? quali pagamenti appartengono a una fattura? Le domande aiutano a identificare entità e collegamenti.
Identificare le entità
Per un sistema vendite potresti individuare Clienti, Ordini, Prodotti, DettagliOrdine, Pagamenti e Agenti. Ogni entità rappresenta qualcosa che ha una propria identità e un proprio ciclo di vita.
Evita una tabella gigantesca che ripete nome cliente, indirizzo e descrizione prodotto in ogni riga ordine. La ridondanza aumenta il rischio di incoerenze.
Separare entità e attributi
RagioneSociale è un attributo di Cliente. DataOrdine è un attributo di Ordine. Quantità, in un sistema Ordini-Prodotti, è un attributo della relazione fra l’ordine e il prodotto e appartiene quindi alla tabella DettagliOrdine.
Chiederti “a chi appartiene questo dato?” è uno dei modi più efficaci per capire dove collocare un campo.
Normalizzazione
La normalizzazione riduce ripetizioni e dipendenze improprie. Non serve trasformare ogni progetto in un esercizio accademico, ma almeno devi evitare gruppi ripetuti, valori duplicati inutilmente e colonne numerate come Prodotto1, Prodotto2, Prodotto3.
Prima forma normale
Ogni campo dovrebbe contenere un valore coerente con il proprio significato e non una lista di elementi. Se un cliente ha molti telefoni, valuta una tabella TelefoniCliente invece di salvare una stringa con numeri separati da virgole quando il processo richiede ricerca o gestione individuale.
Seconda e terza forma normale
In termini pratici, gli attributi dovrebbero dipendere dalla chiave della propria entità e non da altri attributi non chiave. Se in Ordini salvi RagioneSociale e CittaCliente oltre a IDCliente, rischi di dover aggiornare le stesse informazioni in più punti.
Scegliere la chiave primaria
Ogni tabella dovrebbe avere una chiave primaria stabile. Un campo Autonumerazione è spesso una buona scelta tecnica in Access. Se esiste una chiave naturale veramente stabile e univoca, puoi usarla consapevolmente, ma devi documentarne la regola.
Chiave tecnica e codice commerciale
Separare ID interno e codice di business offre flessibilità. IDCliente può essere Autonumerazione; CodiceCliente può essere un codice leggibile dall’azienda e avere un indice univoco. Se il codice commerciale cambia formato, le relazioni interne non devono essere riscritte.
Definire la cardinalità
Scrivi le regole in linguaggio naturale. “Un cliente può avere zero o molti ordini; ogni ordine appartiene a un solo cliente.” “Un ordine contiene molti prodotti; un prodotto può comparire in molti ordini.” Queste frasi guidano il modello.
Uno-a-molti
È la relazione più comune. Clienti 1→∞ Ordini. Il lato uno ha una chiave univoca; il lato molti contiene una foreign key che può ripetersi.
Uno-a-uno
Entrambi i lati sono univoci. Usala quando la separazione in due tabelle ha una ragione reale, per esempio dati opzionali molto specifici o esigenze di sicurezza/segmentazione.
Molti-a-molti
Richiede una tabella ponte. Ordini e Prodotti vengono collegati da DettagliOrdine. La tabella ponte contiene IDOrdine, IDProdotto e gli attributi del legame, come Quantita e PrezzoUnitario.
Creare le foreign key
Nel lato molti aggiungi il campo che punta alla primaria del padre. Se la primaria è Autonumerazione, usa normalmente Numero/Intero lungo nella foreign key. Non creare una nuova Autonumerazione al posto del riferimento.
Progettare Clienti
Campi possibili: IDCliente, CodiceCliente, RagioneSociale, Email, Telefono, Citta, Attivo. Non inserire nella tabella Cliente una lista di ordini. Sarà Ordini a contenere IDCliente.
Progettare Ordini
Campi possibili: IDOrdine, IDCliente, DataOrdine, Stato, Note. Evita di copiare RagioneSociale se puoi ricavarla con un join. Se devi congelare dati storici per esigenze documentali, distinguine chiaramente il motivo dal semplice duplicato.
Progettare Prodotti
Campi possibili: IDProdotto, CodiceProdotto, Descrizione, Categoria, PrezzoListino, Attivo. Il prezzo effettivo applicato a un ordine può essere memorizzato in DettagliOrdine perché può differire dal listino corrente.
Progettare DettagliOrdine
Campi: IDDettaglio opzionale, IDOrdine, IDProdotto, Quantita, PrezzoUnitario, Sconto. Le due foreign key trasformano la molti-a-molti in due uno-a-molti.
Creare le relazioni in Access
- Apri Strumenti database > Relazioni.
- Aggiungi le tabelle.
- Trascina primaria su foreign key.
- Controlla i tipi.
- Applica integrità referenziale.
- Valuta cascata.
- Salva.
Integrità referenziale
Impedisce che una foreign key non Null punti a un padre inesistente. È una protezione fondamentale. Se il database contiene già dati, cerca orfani prima di attivare il vincolo.
Eliminazione a catena
Non abilitarla automaticamente. Per DettagliOrdine può avere senso cancellare i dettagli quando si elimina un ordine in un sistema non storico; per Clienti-Ordini spesso è meglio impedire la cancellazione del cliente e archiviare l’anagrafica.
Aggiornamento a catena
Con chiavi Autonumerazione normalmente non serve. Con chiavi naturali modificabili può essere utile, ma una chiave tecnica stabile riduce questa necessità.
Progettare pensando alle query
Prima di costruire le maschere, prova a rispondere alle domande iniziali con query. Se il modello è corretto, una query Clienti-Ordini-DettagliOrdine-Prodotti dovrebbe essere naturale.
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;Se una query semplice diventa troppo complicata
Potrebbe esserci un problema di modellazione. Se devi confrontare nomi in più colonne o usare molti OR per capire quale campo contiene il prodotto, torna alla struttura e verifica la normalizzazione.
Query di controllo 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;Con integrità corretta dovrebbe restituire zero righe inattese.
Query per duplicati
Se un codice deve essere univoco, usa GROUP BY e HAVING Count(*) > 1 prima di creare un indice univoco. Non assumere l’unicità senza verificarla.
Maschere
Costruisci maschere sopra il modello. Una combo può mostrare RagioneSociale e salvare IDCliente. Una sottomaschera DettagliOrdine può essere collegata a Ordini tramite IDOrdine.
Non far digitare gli ID
Gli utenti devono lavorare con nomi e descrizioni. L’ID è un dettaglio tecnico. Nascondilo nelle combo e salva comunque il valore corretto nella foreign key.
Report
Usa query per combinare i dati e report per presentarli. Se il modello è normalizzato, non devi duplicare descrizioni nelle tabelle per poterle stampare.
Campi calcolati
Evita di memorizzare valori facilmente derivabili se non esiste una motivazione. Il totale riga può essere calcolato da Quantita e PrezzoUnitario. Tuttavia in sistemi commerciali può essere necessario congelare determinati valori storici: documenta la scelta.
Indici
Le primarie sono indicizzate. Le foreign key usate spesso nei join possono beneficiare di un indice con duplicati ammessi. Non creare indici a caso: troppi indici rallentano scritture.
Importazioni da Excel
Usa staging. Importa i dati grezzi, pulisci codici e tipi, crea mapping verso gli ID interni e soltanto dopo accoda nelle tabelle definitive. Questo impedisce di contaminare la struttura con dati esterni non validati.
Database front-end/back-end
In multiutente separa dati e applicazione. Le tabelle stanno nel back-end condiviso; query, maschere, report e VBA nel front-end locale. Le relazioni Access devono essere definite nel back-end che contiene fisicamente i dati.
SQL Server
Quando crescono utenti, volume, disponibilità o accesso remoto, puoi mantenere Access come front-end e spostare le tabelle su SQL Server. Le foreign key autorevoli vengono definite sul server. Un buon modello relazionale rende la migrazione molto più semplice.
Access Microsoft 365 e Access 2024
I concetti valgono per Access desktop su Windows, inclusi Microsoft 365 e Access 2024. 32/64 bit non cambia la logica relazionale. Runtime esegue applicazioni già progettate.
Access non dispone di una versione desktop nativa equivalente per macOS.
Backup prima delle modifiche
Prima di cambiare chiavi, tipi o relazioni crea una copia. In un ambiente multiutente fai uscire gli utenti. Dopo le modifiche testa query, maschere, report e codice VBA.
Test di inserimento
Prova un padre valido e un figlio valido, poi prova una foreign key inesistente. Se l’integrità è attiva, Access deve bloccare il secondo caso.
Test di cancellazione
Prova cosa accade quando elimini un padre con figli. Il comportamento deve corrispondere alla regola aziendale: blocco o cascata. Documentalo.
Test dei Null
Se una relazione è opzionale, prova un figlio senza padre. Se è obbligatoria, imposta anche Required e verifica che la maschera non consenta salvataggi incompleti.
Documentazione
Genera un Relationship Report e un dizionario dati. Per ogni relazione scrivi una frase che ne spiega il significato. Mantieni un changelog delle modifiche strutturali.
Segnali di un modello da rivedere
- Dati descrittivi copiati in molte tabelle.
- Colonne numerate.
- Join sui nomi.
- Molti campi che possono essere Null senza motivo.
- Foreign key senza indice né vincolo.
- Righe orfane.
- Relazioni duplicate obsolete.
- Query semplici eccessivamente complesse.
Errori comuni
Progettare a partire da Excel copiando fogli uno a uno; confondere tabella con report; usare un’unica tabella per tutto; inserire più valori nello stesso campo; non creare primarie; usare descrizioni come foreign key; attivare cascata senza analisi.
Troubleshooting: non so dove mettere un campo
Chiediti quale entità lo possiede e da quale chiave dipende. Se descrive la relazione fra due entità, probabilmente appartiene a una tabella ponte.
Troubleshooting: la query produce duplicati
Verifica la cardinalità. Potrebbero essere righe corrette di una uno-a-molti oppure un molti-a-molti non modellato adeguatamente.
Troubleshooting: Access rifiuta la relazione
Controlla primaria, tipi dati, dimensioni, orfani e duplicati. Con Autonumerazione usa normalmente Numero/Intero lungo nel figlio.
Checklist
- Requisiti scritti.
- Entità identificate.
- Campi assegnati correttamente.
- Primarie stabili.
- Foreign key compatibili.
- Cardinalità definite.
- Tabelle ponte dove servono.
- Integrità applicata.
- Query di verifica create.
- Maschere progettate sugli ID.
- Backup e documentazione presenti.
FAQ
Devo normalizzare sempre al massimo?
Devi almeno evitare ridondanze e gruppi ripetuti che compromettono integrità e manutenzione. La denormalizzazione va fatta solo con motivazioni precise.
Access è davvero relazionale?
Sì, supporta tabelle, chiavi, relazioni e integrità referenziale.
Posso usare Access con SQL Server?
Sì, Access può essere front-end di tabelle collegate su SQL Server.
32/64 bit cambia il modello?
No.
Runtime serve per progettare?
No, è destinato principalmente all’esecuzione.
Link utili
Consulta la categoria Guide Access, normalizzazione, relazioni, tabella ponte e integrità referenziale.
Fonte Microsoft: Guide to table relationships e Learn the structure of an Access database.
Conclusione
Modellare un database relazionale in Access significa trasformare i processi reali in una struttura coerente di entità, chiavi e relazioni. Se il modello è corretto, query, maschere e report diventano più semplici; se il modello è confuso, ogni funzione successiva richiede workaround. Investire tempo nella progettazione è quindi uno dei modi migliori per rendere Access affidabile e manutenibile.