Classi IV e V SIA: Nozioni fondamentali sulla progettazione di database con Access per Office 365 Access 2019 Access 2016 Access 2013 Access 2010 Access 2007
Un database progettato correttamente consente l'accesso a informazioni aggiornate e accurate. Dal momento che una progettazione corretta è essenziale per raggiungere gli obiettivi per cui si usa un database, può essere utile investire il tempo necessario per apprendere i principi di una buona progettazione. In definitiva, sarà molto più probabile ottenere un database che soddisfi esigenze specifiche e che supporti facilmente le modifiche.
Questo articolo contiene le linee guida per la pianificazione di un database desktop. Verrà anche illustrato come identificare le informazioni necessarie e come suddividerle in tabelle e colonne appropriate, nonché come si imposta una correlazione tra di esse. Prima di procedere alla creazione del primo database desktop, è consigliabile leggere il presente articolo.
Importante: Access offre modalità di progettazione innovative che consentono di creare applicazioni di database per il Web. Quando si progetta per il Web è necessario prendere in considerazione diversi aspetti. Questo articolo non descrive la progettazione di applicazioni di database Web. Per altre informazioni, vedere l'articolo Creare un database da condividere sul Web.
Terminologia di database che è utile conoscere
Access organizza le informazioni in tabelle, ovvero elenchi di righe e colonne che ricordano gli antichi fogli di calcolo o registri contabili. In un semplice database può essere presente una sola tabella, ma per la maggior parte dei database ne sono necessarie più d'una. In una tabella è possibile, ad esempio, archiviare informazioni sui prodotti, in un'altra tabella le informazioni sugli ordini e in un'altra ancora le informazioni sui clienti.
Ogni riga viene più correttamente definita record e ogni colonna è detta campo. Un record costituisce un modo significativo e coerente di combinare informazioni su vari elementi. Un campo è un singolo elemento di informazioni, ovvero un tipo di elemento che viene visualizzato in ogni record. Nella tabella Prodotti, ad esempio, ogni riga o record contiene informazioni su un prodotto. Ogni colonna o campo contiene un tipo di informazioni sul prodotto, ad esempio il nome o il prezzo.
Quando una progettazione di database è appropriata?
Il processo di progettazione di un database si basa su determinati principi, il primo dei quali è che la presenza di informazioni duplicate, dette anche dati ridondanti, costituisce un aspetto negativo, perché si spreca spazio e si aumenta la probabilità di introdurre errori e incoerenze. Il secondo principio è che la correttezza e la completezza delle informazioni sono elementi importanti. Se il database contiene informazioni non corrette, anche tutti i report che recuperano informazioni da tale database conterranno informazioni non corrette. Di conseguenza, qualsiasi decisione assunta in base a tali report sarà fondata su informazioni errate.
Una progettazione di database corretta consentirà quindi di:
Dividere le informazioni in tabelle basate su un argomento per ridurre i dati ridondanti.
Immettere in Access le informazioni necessarie per unire le informazioni nelle tabelle secondo le esigenze.
Supportare e assicurare l'accuratezza e l'integrità delle informazioni.
Soddisfare le esigenze di elaborazione dei dati e di creazione di report.
Processo di progettazione
Il processo di progettazione è costituito dai passaggi seguenti:
Determinare lo scopo del database
È utile per prepararsi ai passaggi rimanenti.
Trovare e organizzare le informazioni necessarie
Raccogliere tutti i tipi di informazioni che si potrebbe voler registrare nel database, come nomi di prodotto e numeri di ordine.
Suddividere le informazioni in tabelle
Suddividere le informazioni in entità o argomenti principali, come prodotti o ordini. Ogni argomento diventa quindi una tabella.
Trasformare le informazioni in colonne
Stabilire quali informazioni si vogliono archiviare in ogni tabella. Ogni elemento diventa un campo e viene visualizzato sotto forma di colonna nella tabella. Ad esempio, una tabella Dipendenti può includere campi come Cognome e Data assunzione.
Specificare le chiavi primarie
Scegliere la chiave primaria di ogni tabella. La chiave primaria è una colonna usata per identificare in modo univoco ogni riga, ad esempio ID prodotto o ID ordine.
Impostare le relazioni tra tabelle
Esaminare ogni tabella e decidere in che modo i dati presenti in una tabella sono correlati ai dati in altre tabelle. Aggiungere campi alle tabelle o creare nuove tabelle per chiarire le relazioni, se necessario.
Ottimizzare la progettazione
Analizzare la progettazione per verificare se sono presenti errori. Creare le tabelle e aggiungere alcuni record di dati di esempio. Controllare se è possibile ottenere i risultati desiderati da tali tabelle. Apportare modifiche alla progettazione, se necessario.
Applicare le regole di normalizzazione
Applicare le regole di normalizzazione dei dati per verificare se le tabelle sono strutturate correttamente. Apportare modifiche alle tabelle, se necessario
Questo articolo contiene le linee guida per la pianificazione di un database desktop. Verrà anche illustrato come identificare le informazioni necessarie e come suddividerle in tabelle e colonne appropriate, nonché come si imposta una correlazione tra di esse. Prima di procedere alla creazione del primo database desktop, è consigliabile leggere il presente articolo.
Importante: Access offre modalità di progettazione innovative che consentono di creare applicazioni di database per il Web. Quando si progetta per il Web è necessario prendere in considerazione diversi aspetti. Questo articolo non descrive la progettazione di applicazioni di database Web. Per altre informazioni, vedere l'articolo Creare un database da condividere sul Web.
Terminologia di database che è utile conoscere
Access organizza le informazioni in tabelle, ovvero elenchi di righe e colonne che ricordano gli antichi fogli di calcolo o registri contabili. In un semplice database può essere presente una sola tabella, ma per la maggior parte dei database ne sono necessarie più d'una. In una tabella è possibile, ad esempio, archiviare informazioni sui prodotti, in un'altra tabella le informazioni sugli ordini e in un'altra ancora le informazioni sui clienti.
Ogni riga viene più correttamente definita record e ogni colonna è detta campo. Un record costituisce un modo significativo e coerente di combinare informazioni su vari elementi. Un campo è un singolo elemento di informazioni, ovvero un tipo di elemento che viene visualizzato in ogni record. Nella tabella Prodotti, ad esempio, ogni riga o record contiene informazioni su un prodotto. Ogni colonna o campo contiene un tipo di informazioni sul prodotto, ad esempio il nome o il prezzo.
Quando una progettazione di database è appropriata?
Il processo di progettazione di un database si basa su determinati principi, il primo dei quali è che la presenza di informazioni duplicate, dette anche dati ridondanti, costituisce un aspetto negativo, perché si spreca spazio e si aumenta la probabilità di introdurre errori e incoerenze. Il secondo principio è che la correttezza e la completezza delle informazioni sono elementi importanti. Se il database contiene informazioni non corrette, anche tutti i report che recuperano informazioni da tale database conterranno informazioni non corrette. Di conseguenza, qualsiasi decisione assunta in base a tali report sarà fondata su informazioni errate.
Una progettazione di database corretta consentirà quindi di:
Dividere le informazioni in tabelle basate su un argomento per ridurre i dati ridondanti.
Immettere in Access le informazioni necessarie per unire le informazioni nelle tabelle secondo le esigenze.
Supportare e assicurare l'accuratezza e l'integrità delle informazioni.
Soddisfare le esigenze di elaborazione dei dati e di creazione di report.
Processo di progettazione
Il processo di progettazione è costituito dai passaggi seguenti:
Determinare lo scopo del database
È utile per prepararsi ai passaggi rimanenti.
Trovare e organizzare le informazioni necessarie
Raccogliere tutti i tipi di informazioni che si potrebbe voler registrare nel database, come nomi di prodotto e numeri di ordine.
Suddividere le informazioni in tabelle
Suddividere le informazioni in entità o argomenti principali, come prodotti o ordini. Ogni argomento diventa quindi una tabella.
Trasformare le informazioni in colonne
Stabilire quali informazioni si vogliono archiviare in ogni tabella. Ogni elemento diventa un campo e viene visualizzato sotto forma di colonna nella tabella. Ad esempio, una tabella Dipendenti può includere campi come Cognome e Data assunzione.
Specificare le chiavi primarie
Scegliere la chiave primaria di ogni tabella. La chiave primaria è una colonna usata per identificare in modo univoco ogni riga, ad esempio ID prodotto o ID ordine.
Impostare le relazioni tra tabelle
Esaminare ogni tabella e decidere in che modo i dati presenti in una tabella sono correlati ai dati in altre tabelle. Aggiungere campi alle tabelle o creare nuove tabelle per chiarire le relazioni, se necessario.
Ottimizzare la progettazione
Analizzare la progettazione per verificare se sono presenti errori. Creare le tabelle e aggiungere alcuni record di dati di esempio. Controllare se è possibile ottenere i risultati desiderati da tali tabelle. Apportare modifiche alla progettazione, se necessario.
Applicare le regole di normalizzazione
Applicare le regole di normalizzazione dei dati per verificare se le tabelle sono strutturate correttamente. Apportare modifiche alle tabelle, se necessario
Identificazione dello scopo del database
È consigliabile annotare su carta lo scopo del database, ovvero qual è lo scopo, come si prevede di usarlo e chi lo userà. Per un piccolo database per un'azienda a conduzione familiare, ad esempio, si potrebbe scrivere qualcosa di semplice come "Il database dei clienti mantiene un elenco di informazioni sui clienti allo scopo di produrre la corrispondenza e i report". Se il database è più complesso o viene usato da molte persone, come accade spesso in una configurazione aziendale, lo scopo può facilmente richiedere uno o più paragrafi e dovrebbe includere l'indicazione su quando o come ogni persona userà il database. L'idea è di avere una dichiarazione di intenti ben sviluppata a cui sia possibile fare riferimento durante tutto il processo di progettazione. La presenza di tale dichiarazione consente di concentrarsi sugli obiettivi quando si assumono decisioni.
È consigliabile annotare su carta lo scopo del database, ovvero qual è lo scopo, come si prevede di usarlo e chi lo userà. Per un piccolo database per un'azienda a conduzione familiare, ad esempio, si potrebbe scrivere qualcosa di semplice come "Il database dei clienti mantiene un elenco di informazioni sui clienti allo scopo di produrre la corrispondenza e i report". Se il database è più complesso o viene usato da molte persone, come accade spesso in una configurazione aziendale, lo scopo può facilmente richiedere uno o più paragrafi e dovrebbe includere l'indicazione su quando o come ogni persona userà il database. L'idea è di avere una dichiarazione di intenti ben sviluppata a cui sia possibile fare riferimento durante tutto il processo di progettazione. La presenza di tale dichiarazione consente di concentrarsi sugli obiettivi quando si assumono decisioni.
Individuazione e organizzazione delle informazioni necessarie
Per trovare e organizzare le informazioni necessarie, iniziare da quelle esistenti. È possibile, ad esempio, che gli ordini di acquisto vengano registrati in un libro mastro o che le informazioni relative ai clienti siano annotate su moduli cartacei conservati in uno schedario. Raccogliere tali documenti ed elencare ogni tipo di informazioni rilevate, ad esempio tutte le caselle che vengono compilate in un modulo. Se non sono disponibili moduli esistenti, si supponga invece di dover progettare un modulo per la registrazione delle informazioni relative ai clienti, cercando di immaginare quali informazioni verrebbero inserite nel modulo, quali caselle compilabili sarebbe opportuno creare, identificando ognuno di questi elementi e creandone un elenco. Si supponga anche, ad esempio, che attualmente per l'elenco dei clienti vengano usate schede. L'esame di tali schede potrebbe rivelare che su ogni scheda sono indicati il nome del cliente, l'indirizzo, la città, lo stato il codice postale e il numero di telefono. Ognuno di questi elementi rappresenta una potenziale colonna di una tabella.
Non è necessario che questo elenco risulti perfetto durante la preparazione iniziale. È invece consigliabile includere nell'elenco tutti gli elementi possibili e chiedere suggerimenti a eventuali altre persone che useranno il database. L'elenco potrà essere ottimizzato in un momento successivo.
È quindi opportuno considerare i tipi di report o lettere che si vogliono generare dal database. Ad esempio, potrebbe essere utile creare un report sulle vendite di prodotti in cui sono visualizzate le vendite per zona oppure un report di inventario riepilogativo con i livelli di scorte dei prodotti. Potrebbe anche essere utile generare lettere tipo da inviare ai clienti per annunciare una vendita speciale o per offrire un bonus. Progettare il report mentalmente, immaginando quale aspetto avrà. Stabilire quali informazioni si vogliono inserire nel report e aggiungerle all'elenco. Procedere allo stesso modo per la lettera tipo e per qualsiasi altro report che si prevede di creare.
Pensare ai report e alle lettere che potrebbero voler creare consente di identificare più facilmente gli elementi richiesti nel database. Si supponga, ad esempio, di voler offrire ai clienti l'opportunità di accettare o rifiutare esplicitamente aggiornamenti periodici via posta elettronica e di voler stampare un elenco dei clienti che hanno accettato. Per registrare tali informazioni, aggiungere una colonna “Invio messaggio di posta elettronica” alla tabella dei clienti e impostare il campo su Sì o No per ogni cliente.
Il requisito di inviare messaggi di posta elettronica ai clienti suggerisce un altro elemento da registrare. Dopo avere ricevuto la conferma che un cliente vuole ricevere messaggi di posta elettronica, si dovrà conoscere l'indirizzo di posta elettronica a cui inviarli. È quindi necessario registrare un indirizzo di posta elettronica per ogni cliente.
È consigliabile creare un prototipo di ogni report o elenco di output e considerare quali elementi saranno necessari per generare il report. Ad esempio, esaminando una lettera tipo si potrebbe pensare ad alcuni particolari. Se si vuole includere una vera e propria formula di apertura, ad esempio una stringa "Sig.", "Sig.ra" o "Sig.na" iniziale, si dovrà creare un elemento per la formula di apertura. È anche possibile che si voglia iniziare solitamente una lettera con la formula "Egr. Sig. Trentini", anziché "Egr. Sig. Mattia Trentini". Ciò suggerisce che è in genere consigliabile archiviare il cognome separatamente dal nome.
Un punto chiave da ricordare è la necessità di suddividere ogni informazione nelle relative parti utili più piccole. Nel caso di un nome, per render immediatamente disponibile il cognome, è opportuno dividere il nome in due parti, Nome e Cognome. Per ordinare un report in base al cognome, ad esempio, è utile archiviare separatamente il cognome del cliente. È in genere consigliabile inserire in un campo separato le informazioni in base alle quali si vogliono applicare criteri di ordinamento, ricerca e calcolo oppure creare un report.
Pensare alle domande alle quali il database dovrebbe rispondere. Ad esempio, la quantità di vendite chiuse per il prodotto in primo piano durante il mese precedente, dove risiedono i clienti migliori, chi è il fornitore del prodotto più venduto. La capacità di prevedere queste domande consente di focalizzare l'attenzione su altri elementi da registrare.
Dopo avere raccolto queste informazioni, è possibile procedere al passaggio successivo.
Suddivisione delle informazioni in tabelle
Per suddividere le informazioni in tabelle, scegliere le entità o gli argomenti principali. Dopo avere trovato e organizzato le informazioni, ad esempio, per un database relativo alle vendite di prodotti, l'elenco preliminare potrebbe avere l'aspetto seguente:
Le principali entità qui illustrate sono i prodotti, i fornitori, i clienti e gli ordini. È quindi consigliabile iniziare con queste quattro tabelle: una per le informazioni sui prodotti, una per le informazioni sui fornitori, una per le informazioni sui clienti e una per le informazioni sugli ordini. Anche se l'elenco non è completo, è un buon punto di partenza. È possibile continuare a ottimizzare questo elenco finché non si ottiene una progettazione appropriata.
Quando inizialmente si esamina l'elenco di elementi preliminare, si potrebbe essere tentati di inserirli tutti in un'unica tabella, anziché le quattro illustrate nella figura precedente. Di seguito viene spiegato perché non è opportuno procedere in questo modo. Si consideri per un momento la tabella illustrata di seguito:
In questo caso, ogni riga contiene informazioni sul prodotto e sul suo fornitore. Dal momento che possono essere presenti molti prodotti dello stesso fornitore, le informazioni su nome e indirizzo del fornitore devono essere ripetute molte volte. Questo provoca uno spreco dello spazio su disco. In alternativa, è possibile registrare le informazioni sul fornitore una sola volta in una tabella Fornitori separata e quindi collegare questa tabella alla tabella Prodotti.
Un secondo problema in questa progettazione si presenta quando si devono modificare le informazioni sul fornitore. Si supponga di dover modificare l'indirizzo di un fornitore. Dal momento che è visualizzato in molti punti, si potrebbe accidentalmente modificare l'indirizzo in un punto dimenticando di modificarlo negli altri. La registrazione dell'indirizzo del fornitore in un'unica posizione risolve il problema.
Quando si progetta un database, è sempre opportuno cercare di registrare ogni dato una sola volta. Se si rileva che la stessa informazione viene ripetuta in più posizioni, ad esempio l'indirizzo di un particolare fornitore, inserire tale informazione in una tabella distinta.
Si supponga infine che Coho Winery fornisca un solo prodotto e che si voglia eliminare tale prodotto mantenendo il nome del fornitore e le informazioni sull'indirizzo. Non è possibile eliminare il record del prodotto senza perdere le informazioni sul fornitore. Infatti, dal momento che ogni record contiene dati su un prodotto, nonché dati relativi a un fornitore, non è possibile eliminarne uno senza eliminare l'altro. Per mantenere separati questi dati, è necessario dividere una tabella in due: una per le informazioni sul prodotto e un'altra per le informazioni sul fornitore. In questo modo l'eliminazione di un record relativo al prodotto cancellerà solo i dati relativi a tale prodotto, non quelli relativi al fornitore.
Dopo avere scelto l'argomento rappresentato da una tabella, nelle relative colonne dovranno essere archiviati solo dati su tale argomento. La tabella di prodotti, ad esempio, deve archiviare solo dati sui prodotti. Dal momento che l'indirizzo del fornitore è un dato relativo al fornitore e non al prodotto, appartiene alla tabella dei fornitori.
Trasformazione di informazioni in colonne
Per determinare le colonne di una tabella, è opportuno stabilire quali sono le informazioni relative all'argomento registrato nella tabella di cui è necessario tenere traccia. Per la tabella Clienti, ad esempio, Nome, Indirizzo, Città-Stato-CAP, Invio messaggio di posta elettronica, Formula di apertura e Posta elettronica sono un buon elenco di colonne da cui iniziare. Ogni record nella tabella contiene lo stesso set di colonne, quindi è possibile archiviare informazioni relative a Nome, Indirizzo, Città-Stato-CAP, Invio messaggio di posta elettronica, Formula di apertura e Posta elettronica per ogni record. La colonna Indirizzo, ad esempio, contiene l'indirizzo per quel cliente. Ogni record contiene dati relativi a un cliente e il campo indirizzo contiene l'indirizzo per quel cliente specifico.
Dopo avere determinato il set iniziale di colonne per ogni tabella, è possibile definire le colonne con precisione ancora maggiore. È consigliabile, ad esempio, archiviare il nome del cliente in due colonne distinte, nome e cognome, per poter eseguire operazioni di ordinamento, ricerca e indicizzazione solo su tali colonne. In modo analogo, l'indirizzo è in effetti composto da cinque componenti distinti, ovvero indirizzo, città, provincia, CAP e paese, e anche in questo caso è consigliabile archiviarli in colonne distinte. Se si vuole eseguire un'operazione di ricerca o di ordinamento oppure applicare un filtro in base, ad esempio, alla provincia, è necessario archiviare le informazioni corrispondenti in una colonna distinta.
È opportuno considerare anche se il database conterrà informazioni solo di origine nazionale o anche internazionale. Se si prevede, ad esempio, di archiviare indirizzi internazionali, è preferibile creare una colonna Paese anziché provincia, per potervi inserire sia la provincie nazionali sia le aree di altri paese. Una colonna CAP sarà invece appropriata anche per archiviare indirizzi internazionali.
L'elenco seguente contiene alcuni suggerimenti utili per determinare quali colonne creare.
Non includere dati calcolati
Nella maggior parte dei casi, è consigliabile non archiviare risultati di calcoli nelle tabelle. Al contrario, è possibile fare in modo che i calcoli vengano eseguiti da Access quando si vuole visualizzare il risultato. Si supponga, ad esempio, di avere un report Prodotti ordinati in cui viene visualizzato il subtotale delle unità ordinate per ogni categoria di prodotto nel database. Non è tuttavia presente una colonna di subtotale Unità ordinate in alcuna tabella. La tabella Prodotti include invece una colonna Unità ordinate in cui sono archiviate le unità ordinate per ogni prodotto. Usando questi dati, Access calcola il subtotale ogni volta che si stampa il report. È consigliabile non archiviare il subtotale stesso in una tabella.
Archiviare le informazioni nelle relative parti logiche più piccole
Si potrebbe essere tentati di creare un singolo campo per nomi e cognomi o per nomi di prodotti e relative descrizioni. Se si combina più di un tipo di informazioni in un campo, sarà difficile recuperare i dati in seguito. Cercare di scomporre le informazioni in parti logiche. Ad esempio, creare campi distinti per nome e per cognome o per nome di prodotto, categoria e descrizione.
Dopo avere ottimizzato le colonne dati in ogni tabella, è possibile scegliere la relativa chiave primaria.
Specifica di chiavi primarie
Ogni tabella deve includere una colonna (o set di colonne) che identifichi in modo univoco ogni riga archiviata nella tabella. Si tratta spesso di un numero di identificazione univoco, ad esempio il numero ID di un dipendente o un numero di serie. Nella terminologia di database queste informazioni sono definite chiave primaria della tabella. Access usa i campi di chiavi primarie per associare rapidamente dati di più tabelle e unire i dati automaticamente.
Se si ha già un identificatore univoco per una tabella, ad esempio un numero di prodotto che identifica in modo univoco ogni prodotto nel catalogo, è possibile usarlo come chiave primaria della tabella, ma solo se i valori in questa colonna saranno sempre diversi per ogni record. Non è possibile usare valori duplicati in una chiave primaria. Non usare, ad esempio, nomi di persone come chiave primaria, perché i nomi non sono univoci. È molto facile che due persone abbiano lo stesso nome nella stessa tabella.
Una chiave primaria deve avere sempre un valore. Se il valore di una colonna può diventare a un certo punto non assegnato o sconosciuto (valore mancante), non può essere usato come componente di una chiave primaria.
È consigliabile scegliere sempre una chiave primaria il cui valore non venga modificato. In un database che usa più di una tabella, è possibile usare la chiave primaria di una tabella come riferimento in altre tabelle. Se la chiave primaria viene modificata, tale modifica dovrà essere applicata anche a qualsiasi altro elemento in cui viene fatto riferimento a tale chiave. L'uso di una chiave primaria non soggetta a modifiche riduce la possibilità che non sia più sincronizzata con altre tabelle che vi fanno riferimento.
Spesso come chiave primaria viene usato un numero univoco arbitrario. È possibile, ad esempio, assegnare a ogni ordine un numero d'ordine univoco. Dal momento che il solo scopo di un numero d'ordine è quello di identificare un ordine, dopo essere stato assegnato non viene mai modificato.
Se non si ha una colonna o un set di colonne adatte a costituire la chiave primaria, è possibile usare una colonna con tipo di dati Numerazione automatica. Quando si usa questo tipo di dati, viene assegnato automaticamente un valore. Tale identificatore non rappresenta un dato effettivo, ovvero non contiene alcuna informazione effettiva che descriva la riga a cui è associato. L'uso di questo tipo di identificatori come chiave primaria è ideale perché non vengono modificati. Una chiave primaria che contiene dati relativi a una riga, ad esempio un numero di telefono o il nome di un cliente, è più facilmente soggetta a modifiche, perché i dati stessi che contiene potrebbero variare nel tempo.
1. Una colonna impostata sul tipo di dati Numerazione automatica rappresenta spesso una chiave primaria appropriata perché garantisce l'univocità di tutti gli ID prodotto.
In alcuni casi è possibile usare due o più campi che insieme costituiscono la chiave primaria di una tabella. Una tabella Dettagli sugli ordini che memorizza le voci d'ordine potrebbe, ad esempio, usare come chiave primaria due colonne, ovvero ID ordine e ID prodotto. Le chiavi primarie costituite da più colonne vengono anche definite chiavi composte.
Per il database relativo alle vendite di prodotti è possibile creare una colonna Numerazione automatica per ognuna delle tabelle usate come chiave primaria: IDProdotto per la tabella Prodotti, IDOrdine per la tabella Ordini, IDCliente per la tabella Clienti e IDFornitore per la tabella Fornitori.
Creazione di relazioni tra tabelle
Dopo avere suddiviso le informazioni in tabelle, è necessario riunire di nuovo tali informazioni nei modi appropriati. La maschera seguente, ad esempio, include informazioni recuperate da diverse tabelle.
1. Le informazioni nella maschera provengono dalla tabella Clienti...
2. ...dalla tabella Dipendenti...
3. ...dalla tabella Ordini...
4. ...dalla tabella Prodotti...
5. ...e dalla tabella Dettagli sugli ordini.
Access è un sistema di gestione di database relazionali. In un database relazionale le informazioni vengono suddivise in tabelle distinte in base all'argomento. Le relazioni tra tabelle vengono quindi usate per riunire le informazioni secondo le esigenze.
Creazione di una relazione uno-a-molti
Si consideri l'esempio seguente, in cui il database relativo ai prodotti ordinati include le tabelle Fornitori e Prodotti. Un fornitore può fornire una quantità qualsiasi di prodotti. Di conseguenza, per qualsiasi fornitore rappresentato nella tabella Fornitori possono essere rappresentati molti prodotti nella tabella Prodotti. Tra la tabella Fornitori e la tabella Prodotti esiste quindi una relazione uno-a-molti.
Per rappresentare una relazione uno-a-molti nella progettazione del database, aggiungere la chiave primaria del lato "uno" della relazione come colonna o colonne aggiuntive alla tabella sul lato "molti" della relazione. In questo caso, ad esempio, si aggiunge la colonna ID fornitore dalla tabella fornitori alla tabella Prodotti. Il numero di ID fornitore potrà quindi essere usato da Access nella tabella Prodotti per trovare il fornitore corretto per ogni prodotto.
La colonna ID fornitore nella tabella Prodotti è detta chiave esterna. Una chiave esterna è un'altra chiave primaria della tabella. La colonna ID fornitore nella tabella Prodotti è una chiave esterna, perché è anche la chiave primaria della tabella Fornitori.
Per creare le basi per unire in join tabelle correlate, è necessario definire coppie di chiavi primarie e chiavi esterne. Se non si è certi delle tabelle che dovrebbero condividere una colonna comune, identificare una relazione uno-a-molti per assicurare che le due tabelle interessate richiedano in effetti una colonna condivisa.
Creazione di una relazione molti-a-molti
Si consideri la relazione tra una tabella Prodotti e una tabella Ordini.
Un singolo ordine può includere più prodotti, mentre un singolo prodotto può essere incluso in molti ordini. A ogni record della tabella Ordini possono quindi corrispondere molti record della tabella Prodotti e a ogni record della tabella Prodotti possono corrispondere molti record della tabella Ordini. Questo è un tipo di relazione molti-a-molti, perché a qualsiasi prodotto possono corrispondere molti ordini e a qualsiasi ordine possono corrispondere molti prodotti. Per rilevare le relazioni molti-a-molti tra le tabelle, è importante considerare entrambi i lati della relazione.
Gli argomenti delle due tabelle, Ordini e Prodotti, sono collegati da una relazione molti-a-molti e ciò rappresenta un problema. Per comprendere il problema, si immagini cosa accadrebbe se si provasse a creare la relazione tra le due tabelle aggiungendo il campo ID prodotto alla tabella Ordini. Per inserire più prodotti per ogni ordine, nella tabella Ordini deve essere presente più di un record per ordine. Si dovrebbero ripetere le informazioni relative agli ordini per ogni riga correlata a un singolo ordine, ottenendo una progettazione inefficiente che potrebbe generare dati non corretti. Lo stesso problema si verifica se si inserisce il campo ID ordine nella tabella Prodotti, perché nella tabella Prodotti sarebbe presente più di un record per ogni prodotto. Di seguito viene descritto come risolvere il problema.
Creare una terza tabella, in genere denominata tabella di collegamento, che consente di suddividere la relazione molti-a-molti in due relazioni uno-a-molti. Nella terza tabella viene inserita la chiave primaria di ognuna delle due tabelle, registrando così ogni occorrenza o istanza della relazione.
Ogni record nella tabella Dettagli sugli ordini rappresenta una voce in un ordine. La chiave primaria della tabella Dettagli sugli ordini è costituita da due campi, le chiavi esterne delle tabelle Ordini e Prodotti. Non è possibile usare il campo ID ordine da solo come chiave primaria per questa tabella, perché a un ordine possono corrispondere più voci. L'ID ordine viene ripetuto per ogni voce di un ordine, di conseguenza il campo non contiene valori univoci. Non è possibile usare nemmeno il campo ID prodotto da solo, perché un prodotto può essere presente in molti ordini diversi. Usati insieme, tuttavia, i due campi generano sempre un valore univoco per ogni record.
Nel database relativo alle vendite di prodotti la tabella Ordini e la tabella Prodotti non sono correlate direttamente, ma lo sono indirettamente attraverso la tabella Dettagli sugli ordini. La relazione molti-a-molti tra ordini e prodotti è rappresentata nel database usando due relazioni uno-a-molti:
Tra la tabella Ordini e la tabella Dettagli sugli ordini è presente una relazione uno-a-molti. A ogni ordine può corrispondere più di una voce, ma ognuna è collegata a un solo ordine.
Tra la tabella Prodotti e la tabella Dettagli sugli ordini è presente una relazione uno-a-molti. A ogni prodotto possono essere associate molte voci, ma ogni voce si riferisce a un solo prodotto.
Dalla tabella Dettagli sugli ordini è possibile determinare tutti i prodotti inclusi in un ordine particolare e determinare anche tutti gli ordini per un particolare prodotto.
Dopo avere incorporato la tabella Dettagli sugli ordini, l'elenco delle tabelle e dei campi potrebbe avere un aspetto analogo al seguente:
Creazione di una relazione uno-a-uno
Un altro tipo di relazione disponibile è la relazione uno-a-uno. Si supponga, ad esempio, di avere l'esigenza di registrare speciali informazioni supplementari sui prodotti, che saranno usate raramente o applicabili solo a pochi prodotti. Dal momento che tali informazioni sono raramente necessarie e che la loro archiviazione nella tabella Prodotti comporterebbe la presenta di spazio vuoto per ogni prodotto a cui tali informazioni non sono applicabili, si userà una tabella distinta. In modo analogo alla tabella Prodotti, verrà usato IDProdotto come chiave primaria. La relazione tra questa tabella supplementare e la tabella Prodotto costituisce una relazione uno-a-uno. Per ogni record nella tabella Prodotto è presente un unico record corrispondente nella tabella supplementare. Quando si identifica tale relazione, entrambe le tabelle devono condividere un campo comune.
Quando si rileva l'esigenza di impostare una relazione uno-a-uno nel database, verificare che sia possibile inserire le informazioni dalle due tabelle in una sola. Se non si vuole effettuare questa operazione per qualsiasi motivo, ad esempio perché rimarrebbe parecchio spazio vuoto, nell'elenco seguente è illustrato come verrebbe rappresentata la relazione nella progettazione:
Se le due tabelle condividono lo stesso argomento, è probabilmente possibile impostare la relazione usando la stessa chiave primaria in entrambe le tabelle.
Se le due tabelle includono argomenti diversi con chiavi primarie diverse, scegliere una delle due tabelle (una qualsiasi) e inserire la relativa chiave primaria nell'altra tabella come chiave esterna.
La capacità di determinare le relazioni tra tabelle assicura che vengano usata le tabelle e le colonne corrette. Quando è presente una relazione uno-a-uno o uno-a-molti, le tabelle interessate devono condividere una colonna o più colonne comuni. Quando è presente una relazione molti-a-molti, per rappresentare la relazione è necessaria una terza tabella.
Ottimizzazione della progettazione
Dopo avere definito le tabelle, i campi e le relazioni necessari, è consigliabile creare e popolare le tabelle con dati di esempio e provare a usare tali informazioni, creando query, aggiungendo nuovi record e così via. In questo modo è possibile evidenziare i potenziali problemi, ad esempio, potrebbe essere necessario aggiungere una colonna che si è dimenticato di inserire durante la fase di progettazione oppure dividere una tabella per rimuovere la duplicazione.
Verificare se è possibile usare il database per ottenere le risposte desiderate. Creare bozze di maschere e report e verificare se vengono visualizzati i dati previsti. Cercare le eventuali inutili duplicazioni dei dati e, se vengono trovate, modificare la progettazione per eliminarle.
Mentre si prova a usare il database iniziale, si scopriranno con tutta probabilità aree soggette a miglioramento. Di seguito sono elencati alcuni aspetti da verificare:
Verificare se sono state dimenticate colonne. In tal caso controllare se le informazioni sono presenti nelle tabelle esistenti. Se si tratta di informazioni relative ad altri argomenti, potrebbe essere necessario creare un'altra tabella. Creare una colonna per ogni informazione di cui è necessario tenere traccia. Se non è possibile calcolare le informazioni da altre colonne, è probabile che sia necessario creare una nuova colonna a tale scopo.
Stabilire se sono presenti colonne non necessarie, perché possono essere calcolate da campi esistenti. Se un'informazione può essere calcolata da altre colonne esistenti, ad esempio un prezzo scontato calcolato dal prezzo al dettaglio, è in genere preferibile procedere in tal modo, evitando di creare nuove colonne.
Verificare se vengono immesse ripetutamente informazioni duplicate in una delle tabelle. In tal caso è probabilmente necessario dividere la tabella in due tabelle con una relazione uno-a-molti.
Verificare se nelle tabelle sono presenti molti campi, un numero limitato di record e molti campi vuoti nei singoli record. In tal caso, considerare la possibilità di riprogettare la tabella in modo che contenga meno campi e record.
Verificare se ogni informazione è stata suddivisa in parti utili più piccole. Se è necessario creare report oppure applicare criteri di ordinamento o eseguire ricerche o calcoli su un elemento di informazioni, inserire tale elemento in una colonna corrispondente.
Verificare se ogni colonna contiene dati relativi all'argomento della tabella. Se una colonna non contiene informazioni sull'argomento di una tabella, appartiene a una tabella diversa.
Verificare che tutte le relazioni tra tabelle siano rappresentate da campi comuni o da una terza tabella. Le relazioni uno-a-uno e uno-a-molti- richiedono colonne comuni. Le relazioni molti a molti richiedono una terza tabella.
Ottimizzazione della tabella Prodotti
Si supponga che ogni prodotto nel database relativo alle vendite di prodotti rientri in una categoria generale, ad esempio Bevande, Condimenti o Pesce. La tabella Prodotti può includere un campo che visualizza la categoria per ogni prodotto.
Si supponga che dopo avere esaminato e ottimizzato la progettazione del database si decida di archiviare una descrizione della categoria insieme al relativo nome. Se si aggiunge un campo Descrizione categoria alla tabella Prodotti, sarà necessario ripetere ogni descrizione di categoria per ogni prodotto che rientra in tale categoria, una soluzione non certo ottimale.
Una soluzione migliore consiste nell'impostare Categorie come nuovo argomento di cui tenere traccia nel database, con una tabella e una chiave primaria personalizzate. Sarà quindi possibile aggiungere la chiave primaria dalla tabella Categorie alla tabella Prodotti come chiave esterna.
Le tabelle Categorie e Prodotti sono collegate con una relazione uno-a-molti, infatti una categoria può includere più prodotti, ma un prodotto può appartenere a una sola categoria.
Quando si esaminano le strutture delle tabelle, prestare attenzione agli eventuali gruppi ripetuti. Si consideri ad esempio una tabella contenente le colonne seguenti:
ID prodotto
Nome
ID Prodotto1
Nome1
ID Prodotto2
Nome2
ID Prodotto3
Nome3
Ogni prodotto è un gruppo ripetuto di colonne che differiscono dalle altre solo aggiungendo un numero alla fine del nome della colonna. Se si osservano colonne con questa numerazione, è consigliabile rivedere la progettazione.
Tale progettazione presenta diversi difetti. Prima di tutto, impone la definizione di un limite massimo al numero di prodotti e, quando si supera tale limite, diventa necessario aggiungere un nuovo gruppo di colonne alla struttura della tabella e ciò implica un'attività amministrativa importante.
Un altro problema è dovuto allo spreco di spazio per i fornitori con un una quantità di prodotti inferiore al numero massimo, perché le colonne aggiuntive saranno vuote. Il difetto più grave di tale progettazione è che rende difficile l'esecuzione di molte attività, ad esempio l'ordinamento o l'indicizzazione della tabella per ID prodotto o per nome.
Ogni volta che si rilevano gruppi ripetuti, è consigliabile rivedere attentamente la progettazione considerando la possibilità di dividere la tabella in due. Nell'esempio precedente è preferibile usare due tabelle, una per i fornitori e una per i prodotti, collegate con l'ID fornitore.
Applicazione delle regole di normalizzazione
Come passaggio successivo del processo di progettazione, è possibile applicare regole di normalizzazione dei dati, dette a volte semplicemente regole di normalizzazione, che consentono di verificare se le tabelle sono strutturate correttamente. Il processo di applicazione delle regole alla progettazione del database è detto normalizzazione del database o solo normalizzazione.
La normalizzazione risulta utile soprattutto dopo che sono stati rappresentati tutte le informazioni e avere creato la progettazione preliminare. Consente di verificare che gli elementi di informazioni siano stati suddivisi nelle tabelle appropriate, ma non può invece assicurare che siano stati inseriti tutti gli elementi di dati corretti con cui iniziare.
Applicare le regole in successione, verificando a ogni passaggio che la progettazione raggiunga una di quelle che vengono definite "forme normali". In genere vengono ampiamente accettate cinque forme normali, dalla prima alla quinta. Questo articolo considera solo le prime tre, perché rappresentano i requisiti necessari per la maggior parte delle progettazioni di database.
Seconda forma normale
La seconda forma normale richiede che ogni colonna non chiave sia completamente dipendente dall'intera chiave primaria e non solo da una parte di tale chiave. Questa regola viene applicata in presenza di una chiave primaria composta da più colonne. Si supponga ad esempio di avere una tabella contenente le colonne seguenti, dove ID ordine o ID prodotto costituisce la chiave primaria:
ID ordine (chiave primaria)
ID prodotto (chiave primaria)
Nome prodotto
Questa progettazione viola la seconda forma normale, perché Nome prodotto è dipendente da ID prodotto ma non da ID ordine, quindi non è dipendente dall'intera chiave primaria. È necessario rimuovere Nome prodotto dalla tabella, perché appartiene a un'altra tabella (Prodotti).
Terza forma normale
La terza forma normale richiede non solo che ogni colonna non chiave sia dipendente dall'intera chiave primaria, ma che le colonne non chiave siano indipendenti le une dalle altre.
In altre parole, ogni colonna non chiave deve essere dipendente dalla chiave primaria ed esclusivamente dalla chiave primaria. Si supponga ad esempio di avere una tabella che contiene le colonne seguenti:
ID prodotto (chiave primaria)
Nome
PDC
Sconto
Si supponga che la colonna Sconto dipenda dal prezzo al dettaglio consigliato (PDC). Questa tabella viola la terza forma normale perché una colonna non chiave, Sconto, dipende da un'altra colonna non chiave, PDC. Indipendenza delle colonne significa che deve essere possibile modificare qualsiasi colonna non chiave senza influire su qualsiasi altra colonna. Se si modifica un valore nel campo PDC, il valore di Sconto verrebbe modificato di conseguenza, violando in tal modo la regola. In questo caso è necessario spostare la colonna Sconto in un'altra tabella la cui chiave primaria è basata sulla colonna PDC.
fonte: https://support.office.com/it-it/article/nozioni-fondamentali-sulla-progettazione-di-database-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5#bmdesignprocess
Per trovare e organizzare le informazioni necessarie, iniziare da quelle esistenti. È possibile, ad esempio, che gli ordini di acquisto vengano registrati in un libro mastro o che le informazioni relative ai clienti siano annotate su moduli cartacei conservati in uno schedario. Raccogliere tali documenti ed elencare ogni tipo di informazioni rilevate, ad esempio tutte le caselle che vengono compilate in un modulo. Se non sono disponibili moduli esistenti, si supponga invece di dover progettare un modulo per la registrazione delle informazioni relative ai clienti, cercando di immaginare quali informazioni verrebbero inserite nel modulo, quali caselle compilabili sarebbe opportuno creare, identificando ognuno di questi elementi e creandone un elenco. Si supponga anche, ad esempio, che attualmente per l'elenco dei clienti vengano usate schede. L'esame di tali schede potrebbe rivelare che su ogni scheda sono indicati il nome del cliente, l'indirizzo, la città, lo stato il codice postale e il numero di telefono. Ognuno di questi elementi rappresenta una potenziale colonna di una tabella.
Non è necessario che questo elenco risulti perfetto durante la preparazione iniziale. È invece consigliabile includere nell'elenco tutti gli elementi possibili e chiedere suggerimenti a eventuali altre persone che useranno il database. L'elenco potrà essere ottimizzato in un momento successivo.
È quindi opportuno considerare i tipi di report o lettere che si vogliono generare dal database. Ad esempio, potrebbe essere utile creare un report sulle vendite di prodotti in cui sono visualizzate le vendite per zona oppure un report di inventario riepilogativo con i livelli di scorte dei prodotti. Potrebbe anche essere utile generare lettere tipo da inviare ai clienti per annunciare una vendita speciale o per offrire un bonus. Progettare il report mentalmente, immaginando quale aspetto avrà. Stabilire quali informazioni si vogliono inserire nel report e aggiungerle all'elenco. Procedere allo stesso modo per la lettera tipo e per qualsiasi altro report che si prevede di creare.
Pensare ai report e alle lettere che potrebbero voler creare consente di identificare più facilmente gli elementi richiesti nel database. Si supponga, ad esempio, di voler offrire ai clienti l'opportunità di accettare o rifiutare esplicitamente aggiornamenti periodici via posta elettronica e di voler stampare un elenco dei clienti che hanno accettato. Per registrare tali informazioni, aggiungere una colonna “Invio messaggio di posta elettronica” alla tabella dei clienti e impostare il campo su Sì o No per ogni cliente.
Il requisito di inviare messaggi di posta elettronica ai clienti suggerisce un altro elemento da registrare. Dopo avere ricevuto la conferma che un cliente vuole ricevere messaggi di posta elettronica, si dovrà conoscere l'indirizzo di posta elettronica a cui inviarli. È quindi necessario registrare un indirizzo di posta elettronica per ogni cliente.
È consigliabile creare un prototipo di ogni report o elenco di output e considerare quali elementi saranno necessari per generare il report. Ad esempio, esaminando una lettera tipo si potrebbe pensare ad alcuni particolari. Se si vuole includere una vera e propria formula di apertura, ad esempio una stringa "Sig.", "Sig.ra" o "Sig.na" iniziale, si dovrà creare un elemento per la formula di apertura. È anche possibile che si voglia iniziare solitamente una lettera con la formula "Egr. Sig. Trentini", anziché "Egr. Sig. Mattia Trentini". Ciò suggerisce che è in genere consigliabile archiviare il cognome separatamente dal nome.
Un punto chiave da ricordare è la necessità di suddividere ogni informazione nelle relative parti utili più piccole. Nel caso di un nome, per render immediatamente disponibile il cognome, è opportuno dividere il nome in due parti, Nome e Cognome. Per ordinare un report in base al cognome, ad esempio, è utile archiviare separatamente il cognome del cliente. È in genere consigliabile inserire in un campo separato le informazioni in base alle quali si vogliono applicare criteri di ordinamento, ricerca e calcolo oppure creare un report.
Pensare alle domande alle quali il database dovrebbe rispondere. Ad esempio, la quantità di vendite chiuse per il prodotto in primo piano durante il mese precedente, dove risiedono i clienti migliori, chi è il fornitore del prodotto più venduto. La capacità di prevedere queste domande consente di focalizzare l'attenzione su altri elementi da registrare.
Dopo avere raccolto queste informazioni, è possibile procedere al passaggio successivo.
Suddivisione delle informazioni in tabelle
Per suddividere le informazioni in tabelle, scegliere le entità o gli argomenti principali. Dopo avere trovato e organizzato le informazioni, ad esempio, per un database relativo alle vendite di prodotti, l'elenco preliminare potrebbe avere l'aspetto seguente:
Le principali entità qui illustrate sono i prodotti, i fornitori, i clienti e gli ordini. È quindi consigliabile iniziare con queste quattro tabelle: una per le informazioni sui prodotti, una per le informazioni sui fornitori, una per le informazioni sui clienti e una per le informazioni sugli ordini. Anche se l'elenco non è completo, è un buon punto di partenza. È possibile continuare a ottimizzare questo elenco finché non si ottiene una progettazione appropriata.
Quando inizialmente si esamina l'elenco di elementi preliminare, si potrebbe essere tentati di inserirli tutti in un'unica tabella, anziché le quattro illustrate nella figura precedente. Di seguito viene spiegato perché non è opportuno procedere in questo modo. Si consideri per un momento la tabella illustrata di seguito:
In questo caso, ogni riga contiene informazioni sul prodotto e sul suo fornitore. Dal momento che possono essere presenti molti prodotti dello stesso fornitore, le informazioni su nome e indirizzo del fornitore devono essere ripetute molte volte. Questo provoca uno spreco dello spazio su disco. In alternativa, è possibile registrare le informazioni sul fornitore una sola volta in una tabella Fornitori separata e quindi collegare questa tabella alla tabella Prodotti.
Un secondo problema in questa progettazione si presenta quando si devono modificare le informazioni sul fornitore. Si supponga di dover modificare l'indirizzo di un fornitore. Dal momento che è visualizzato in molti punti, si potrebbe accidentalmente modificare l'indirizzo in un punto dimenticando di modificarlo negli altri. La registrazione dell'indirizzo del fornitore in un'unica posizione risolve il problema.
Quando si progetta un database, è sempre opportuno cercare di registrare ogni dato una sola volta. Se si rileva che la stessa informazione viene ripetuta in più posizioni, ad esempio l'indirizzo di un particolare fornitore, inserire tale informazione in una tabella distinta.
Si supponga infine che Coho Winery fornisca un solo prodotto e che si voglia eliminare tale prodotto mantenendo il nome del fornitore e le informazioni sull'indirizzo. Non è possibile eliminare il record del prodotto senza perdere le informazioni sul fornitore. Infatti, dal momento che ogni record contiene dati su un prodotto, nonché dati relativi a un fornitore, non è possibile eliminarne uno senza eliminare l'altro. Per mantenere separati questi dati, è necessario dividere una tabella in due: una per le informazioni sul prodotto e un'altra per le informazioni sul fornitore. In questo modo l'eliminazione di un record relativo al prodotto cancellerà solo i dati relativi a tale prodotto, non quelli relativi al fornitore.
Dopo avere scelto l'argomento rappresentato da una tabella, nelle relative colonne dovranno essere archiviati solo dati su tale argomento. La tabella di prodotti, ad esempio, deve archiviare solo dati sui prodotti. Dal momento che l'indirizzo del fornitore è un dato relativo al fornitore e non al prodotto, appartiene alla tabella dei fornitori.
Trasformazione di informazioni in colonne
Per determinare le colonne di una tabella, è opportuno stabilire quali sono le informazioni relative all'argomento registrato nella tabella di cui è necessario tenere traccia. Per la tabella Clienti, ad esempio, Nome, Indirizzo, Città-Stato-CAP, Invio messaggio di posta elettronica, Formula di apertura e Posta elettronica sono un buon elenco di colonne da cui iniziare. Ogni record nella tabella contiene lo stesso set di colonne, quindi è possibile archiviare informazioni relative a Nome, Indirizzo, Città-Stato-CAP, Invio messaggio di posta elettronica, Formula di apertura e Posta elettronica per ogni record. La colonna Indirizzo, ad esempio, contiene l'indirizzo per quel cliente. Ogni record contiene dati relativi a un cliente e il campo indirizzo contiene l'indirizzo per quel cliente specifico.
Dopo avere determinato il set iniziale di colonne per ogni tabella, è possibile definire le colonne con precisione ancora maggiore. È consigliabile, ad esempio, archiviare il nome del cliente in due colonne distinte, nome e cognome, per poter eseguire operazioni di ordinamento, ricerca e indicizzazione solo su tali colonne. In modo analogo, l'indirizzo è in effetti composto da cinque componenti distinti, ovvero indirizzo, città, provincia, CAP e paese, e anche in questo caso è consigliabile archiviarli in colonne distinte. Se si vuole eseguire un'operazione di ricerca o di ordinamento oppure applicare un filtro in base, ad esempio, alla provincia, è necessario archiviare le informazioni corrispondenti in una colonna distinta.
È opportuno considerare anche se il database conterrà informazioni solo di origine nazionale o anche internazionale. Se si prevede, ad esempio, di archiviare indirizzi internazionali, è preferibile creare una colonna Paese anziché provincia, per potervi inserire sia la provincie nazionali sia le aree di altri paese. Una colonna CAP sarà invece appropriata anche per archiviare indirizzi internazionali.
L'elenco seguente contiene alcuni suggerimenti utili per determinare quali colonne creare.
Non includere dati calcolati
Nella maggior parte dei casi, è consigliabile non archiviare risultati di calcoli nelle tabelle. Al contrario, è possibile fare in modo che i calcoli vengano eseguiti da Access quando si vuole visualizzare il risultato. Si supponga, ad esempio, di avere un report Prodotti ordinati in cui viene visualizzato il subtotale delle unità ordinate per ogni categoria di prodotto nel database. Non è tuttavia presente una colonna di subtotale Unità ordinate in alcuna tabella. La tabella Prodotti include invece una colonna Unità ordinate in cui sono archiviate le unità ordinate per ogni prodotto. Usando questi dati, Access calcola il subtotale ogni volta che si stampa il report. È consigliabile non archiviare il subtotale stesso in una tabella.
Archiviare le informazioni nelle relative parti logiche più piccole
Si potrebbe essere tentati di creare un singolo campo per nomi e cognomi o per nomi di prodotti e relative descrizioni. Se si combina più di un tipo di informazioni in un campo, sarà difficile recuperare i dati in seguito. Cercare di scomporre le informazioni in parti logiche. Ad esempio, creare campi distinti per nome e per cognome o per nome di prodotto, categoria e descrizione.
Dopo avere ottimizzato le colonne dati in ogni tabella, è possibile scegliere la relativa chiave primaria.
Specifica di chiavi primarie
Ogni tabella deve includere una colonna (o set di colonne) che identifichi in modo univoco ogni riga archiviata nella tabella. Si tratta spesso di un numero di identificazione univoco, ad esempio il numero ID di un dipendente o un numero di serie. Nella terminologia di database queste informazioni sono definite chiave primaria della tabella. Access usa i campi di chiavi primarie per associare rapidamente dati di più tabelle e unire i dati automaticamente.
Se si ha già un identificatore univoco per una tabella, ad esempio un numero di prodotto che identifica in modo univoco ogni prodotto nel catalogo, è possibile usarlo come chiave primaria della tabella, ma solo se i valori in questa colonna saranno sempre diversi per ogni record. Non è possibile usare valori duplicati in una chiave primaria. Non usare, ad esempio, nomi di persone come chiave primaria, perché i nomi non sono univoci. È molto facile che due persone abbiano lo stesso nome nella stessa tabella.
Una chiave primaria deve avere sempre un valore. Se il valore di una colonna può diventare a un certo punto non assegnato o sconosciuto (valore mancante), non può essere usato come componente di una chiave primaria.
È consigliabile scegliere sempre una chiave primaria il cui valore non venga modificato. In un database che usa più di una tabella, è possibile usare la chiave primaria di una tabella come riferimento in altre tabelle. Se la chiave primaria viene modificata, tale modifica dovrà essere applicata anche a qualsiasi altro elemento in cui viene fatto riferimento a tale chiave. L'uso di una chiave primaria non soggetta a modifiche riduce la possibilità che non sia più sincronizzata con altre tabelle che vi fanno riferimento.
Spesso come chiave primaria viene usato un numero univoco arbitrario. È possibile, ad esempio, assegnare a ogni ordine un numero d'ordine univoco. Dal momento che il solo scopo di un numero d'ordine è quello di identificare un ordine, dopo essere stato assegnato non viene mai modificato.
Se non si ha una colonna o un set di colonne adatte a costituire la chiave primaria, è possibile usare una colonna con tipo di dati Numerazione automatica. Quando si usa questo tipo di dati, viene assegnato automaticamente un valore. Tale identificatore non rappresenta un dato effettivo, ovvero non contiene alcuna informazione effettiva che descriva la riga a cui è associato. L'uso di questo tipo di identificatori come chiave primaria è ideale perché non vengono modificati. Una chiave primaria che contiene dati relativi a una riga, ad esempio un numero di telefono o il nome di un cliente, è più facilmente soggetta a modifiche, perché i dati stessi che contiene potrebbero variare nel tempo.
1. Una colonna impostata sul tipo di dati Numerazione automatica rappresenta spesso una chiave primaria appropriata perché garantisce l'univocità di tutti gli ID prodotto.
In alcuni casi è possibile usare due o più campi che insieme costituiscono la chiave primaria di una tabella. Una tabella Dettagli sugli ordini che memorizza le voci d'ordine potrebbe, ad esempio, usare come chiave primaria due colonne, ovvero ID ordine e ID prodotto. Le chiavi primarie costituite da più colonne vengono anche definite chiavi composte.
Per il database relativo alle vendite di prodotti è possibile creare una colonna Numerazione automatica per ognuna delle tabelle usate come chiave primaria: IDProdotto per la tabella Prodotti, IDOrdine per la tabella Ordini, IDCliente per la tabella Clienti e IDFornitore per la tabella Fornitori.
Creazione di relazioni tra tabelle
Dopo avere suddiviso le informazioni in tabelle, è necessario riunire di nuovo tali informazioni nei modi appropriati. La maschera seguente, ad esempio, include informazioni recuperate da diverse tabelle.
1. Le informazioni nella maschera provengono dalla tabella Clienti...
2. ...dalla tabella Dipendenti...
3. ...dalla tabella Ordini...
4. ...dalla tabella Prodotti...
5. ...e dalla tabella Dettagli sugli ordini.
Access è un sistema di gestione di database relazionali. In un database relazionale le informazioni vengono suddivise in tabelle distinte in base all'argomento. Le relazioni tra tabelle vengono quindi usate per riunire le informazioni secondo le esigenze.
Creazione di una relazione uno-a-molti
Si consideri l'esempio seguente, in cui il database relativo ai prodotti ordinati include le tabelle Fornitori e Prodotti. Un fornitore può fornire una quantità qualsiasi di prodotti. Di conseguenza, per qualsiasi fornitore rappresentato nella tabella Fornitori possono essere rappresentati molti prodotti nella tabella Prodotti. Tra la tabella Fornitori e la tabella Prodotti esiste quindi una relazione uno-a-molti.
Per rappresentare una relazione uno-a-molti nella progettazione del database, aggiungere la chiave primaria del lato "uno" della relazione come colonna o colonne aggiuntive alla tabella sul lato "molti" della relazione. In questo caso, ad esempio, si aggiunge la colonna ID fornitore dalla tabella fornitori alla tabella Prodotti. Il numero di ID fornitore potrà quindi essere usato da Access nella tabella Prodotti per trovare il fornitore corretto per ogni prodotto.
La colonna ID fornitore nella tabella Prodotti è detta chiave esterna. Una chiave esterna è un'altra chiave primaria della tabella. La colonna ID fornitore nella tabella Prodotti è una chiave esterna, perché è anche la chiave primaria della tabella Fornitori.
Per creare le basi per unire in join tabelle correlate, è necessario definire coppie di chiavi primarie e chiavi esterne. Se non si è certi delle tabelle che dovrebbero condividere una colonna comune, identificare una relazione uno-a-molti per assicurare che le due tabelle interessate richiedano in effetti una colonna condivisa.
Creazione di una relazione molti-a-molti
Si consideri la relazione tra una tabella Prodotti e una tabella Ordini.
Un singolo ordine può includere più prodotti, mentre un singolo prodotto può essere incluso in molti ordini. A ogni record della tabella Ordini possono quindi corrispondere molti record della tabella Prodotti e a ogni record della tabella Prodotti possono corrispondere molti record della tabella Ordini. Questo è un tipo di relazione molti-a-molti, perché a qualsiasi prodotto possono corrispondere molti ordini e a qualsiasi ordine possono corrispondere molti prodotti. Per rilevare le relazioni molti-a-molti tra le tabelle, è importante considerare entrambi i lati della relazione.
Gli argomenti delle due tabelle, Ordini e Prodotti, sono collegati da una relazione molti-a-molti e ciò rappresenta un problema. Per comprendere il problema, si immagini cosa accadrebbe se si provasse a creare la relazione tra le due tabelle aggiungendo il campo ID prodotto alla tabella Ordini. Per inserire più prodotti per ogni ordine, nella tabella Ordini deve essere presente più di un record per ordine. Si dovrebbero ripetere le informazioni relative agli ordini per ogni riga correlata a un singolo ordine, ottenendo una progettazione inefficiente che potrebbe generare dati non corretti. Lo stesso problema si verifica se si inserisce il campo ID ordine nella tabella Prodotti, perché nella tabella Prodotti sarebbe presente più di un record per ogni prodotto. Di seguito viene descritto come risolvere il problema.
Creare una terza tabella, in genere denominata tabella di collegamento, che consente di suddividere la relazione molti-a-molti in due relazioni uno-a-molti. Nella terza tabella viene inserita la chiave primaria di ognuna delle due tabelle, registrando così ogni occorrenza o istanza della relazione.
Ogni record nella tabella Dettagli sugli ordini rappresenta una voce in un ordine. La chiave primaria della tabella Dettagli sugli ordini è costituita da due campi, le chiavi esterne delle tabelle Ordini e Prodotti. Non è possibile usare il campo ID ordine da solo come chiave primaria per questa tabella, perché a un ordine possono corrispondere più voci. L'ID ordine viene ripetuto per ogni voce di un ordine, di conseguenza il campo non contiene valori univoci. Non è possibile usare nemmeno il campo ID prodotto da solo, perché un prodotto può essere presente in molti ordini diversi. Usati insieme, tuttavia, i due campi generano sempre un valore univoco per ogni record.
Nel database relativo alle vendite di prodotti la tabella Ordini e la tabella Prodotti non sono correlate direttamente, ma lo sono indirettamente attraverso la tabella Dettagli sugli ordini. La relazione molti-a-molti tra ordini e prodotti è rappresentata nel database usando due relazioni uno-a-molti:
Tra la tabella Ordini e la tabella Dettagli sugli ordini è presente una relazione uno-a-molti. A ogni ordine può corrispondere più di una voce, ma ognuna è collegata a un solo ordine.
Tra la tabella Prodotti e la tabella Dettagli sugli ordini è presente una relazione uno-a-molti. A ogni prodotto possono essere associate molte voci, ma ogni voce si riferisce a un solo prodotto.
Dalla tabella Dettagli sugli ordini è possibile determinare tutti i prodotti inclusi in un ordine particolare e determinare anche tutti gli ordini per un particolare prodotto.
Dopo avere incorporato la tabella Dettagli sugli ordini, l'elenco delle tabelle e dei campi potrebbe avere un aspetto analogo al seguente:
Creazione di una relazione uno-a-uno
Un altro tipo di relazione disponibile è la relazione uno-a-uno. Si supponga, ad esempio, di avere l'esigenza di registrare speciali informazioni supplementari sui prodotti, che saranno usate raramente o applicabili solo a pochi prodotti. Dal momento che tali informazioni sono raramente necessarie e che la loro archiviazione nella tabella Prodotti comporterebbe la presenta di spazio vuoto per ogni prodotto a cui tali informazioni non sono applicabili, si userà una tabella distinta. In modo analogo alla tabella Prodotti, verrà usato IDProdotto come chiave primaria. La relazione tra questa tabella supplementare e la tabella Prodotto costituisce una relazione uno-a-uno. Per ogni record nella tabella Prodotto è presente un unico record corrispondente nella tabella supplementare. Quando si identifica tale relazione, entrambe le tabelle devono condividere un campo comune.
Quando si rileva l'esigenza di impostare una relazione uno-a-uno nel database, verificare che sia possibile inserire le informazioni dalle due tabelle in una sola. Se non si vuole effettuare questa operazione per qualsiasi motivo, ad esempio perché rimarrebbe parecchio spazio vuoto, nell'elenco seguente è illustrato come verrebbe rappresentata la relazione nella progettazione:
Se le due tabelle condividono lo stesso argomento, è probabilmente possibile impostare la relazione usando la stessa chiave primaria in entrambe le tabelle.
Se le due tabelle includono argomenti diversi con chiavi primarie diverse, scegliere una delle due tabelle (una qualsiasi) e inserire la relativa chiave primaria nell'altra tabella come chiave esterna.
La capacità di determinare le relazioni tra tabelle assicura che vengano usata le tabelle e le colonne corrette. Quando è presente una relazione uno-a-uno o uno-a-molti, le tabelle interessate devono condividere una colonna o più colonne comuni. Quando è presente una relazione molti-a-molti, per rappresentare la relazione è necessaria una terza tabella.
Ottimizzazione della progettazione
Dopo avere definito le tabelle, i campi e le relazioni necessari, è consigliabile creare e popolare le tabelle con dati di esempio e provare a usare tali informazioni, creando query, aggiungendo nuovi record e così via. In questo modo è possibile evidenziare i potenziali problemi, ad esempio, potrebbe essere necessario aggiungere una colonna che si è dimenticato di inserire durante la fase di progettazione oppure dividere una tabella per rimuovere la duplicazione.
Verificare se è possibile usare il database per ottenere le risposte desiderate. Creare bozze di maschere e report e verificare se vengono visualizzati i dati previsti. Cercare le eventuali inutili duplicazioni dei dati e, se vengono trovate, modificare la progettazione per eliminarle.
Mentre si prova a usare il database iniziale, si scopriranno con tutta probabilità aree soggette a miglioramento. Di seguito sono elencati alcuni aspetti da verificare:
Verificare se sono state dimenticate colonne. In tal caso controllare se le informazioni sono presenti nelle tabelle esistenti. Se si tratta di informazioni relative ad altri argomenti, potrebbe essere necessario creare un'altra tabella. Creare una colonna per ogni informazione di cui è necessario tenere traccia. Se non è possibile calcolare le informazioni da altre colonne, è probabile che sia necessario creare una nuova colonna a tale scopo.
Stabilire se sono presenti colonne non necessarie, perché possono essere calcolate da campi esistenti. Se un'informazione può essere calcolata da altre colonne esistenti, ad esempio un prezzo scontato calcolato dal prezzo al dettaglio, è in genere preferibile procedere in tal modo, evitando di creare nuove colonne.
Verificare se vengono immesse ripetutamente informazioni duplicate in una delle tabelle. In tal caso è probabilmente necessario dividere la tabella in due tabelle con una relazione uno-a-molti.
Verificare se nelle tabelle sono presenti molti campi, un numero limitato di record e molti campi vuoti nei singoli record. In tal caso, considerare la possibilità di riprogettare la tabella in modo che contenga meno campi e record.
Verificare se ogni informazione è stata suddivisa in parti utili più piccole. Se è necessario creare report oppure applicare criteri di ordinamento o eseguire ricerche o calcoli su un elemento di informazioni, inserire tale elemento in una colonna corrispondente.
Verificare se ogni colonna contiene dati relativi all'argomento della tabella. Se una colonna non contiene informazioni sull'argomento di una tabella, appartiene a una tabella diversa.
Verificare che tutte le relazioni tra tabelle siano rappresentate da campi comuni o da una terza tabella. Le relazioni uno-a-uno e uno-a-molti- richiedono colonne comuni. Le relazioni molti a molti richiedono una terza tabella.
Ottimizzazione della tabella Prodotti
Si supponga che ogni prodotto nel database relativo alle vendite di prodotti rientri in una categoria generale, ad esempio Bevande, Condimenti o Pesce. La tabella Prodotti può includere un campo che visualizza la categoria per ogni prodotto.
Si supponga che dopo avere esaminato e ottimizzato la progettazione del database si decida di archiviare una descrizione della categoria insieme al relativo nome. Se si aggiunge un campo Descrizione categoria alla tabella Prodotti, sarà necessario ripetere ogni descrizione di categoria per ogni prodotto che rientra in tale categoria, una soluzione non certo ottimale.
Una soluzione migliore consiste nell'impostare Categorie come nuovo argomento di cui tenere traccia nel database, con una tabella e una chiave primaria personalizzate. Sarà quindi possibile aggiungere la chiave primaria dalla tabella Categorie alla tabella Prodotti come chiave esterna.
Le tabelle Categorie e Prodotti sono collegate con una relazione uno-a-molti, infatti una categoria può includere più prodotti, ma un prodotto può appartenere a una sola categoria.
Quando si esaminano le strutture delle tabelle, prestare attenzione agli eventuali gruppi ripetuti. Si consideri ad esempio una tabella contenente le colonne seguenti:
ID prodotto
Nome
ID Prodotto1
Nome1
ID Prodotto2
Nome2
ID Prodotto3
Nome3
Ogni prodotto è un gruppo ripetuto di colonne che differiscono dalle altre solo aggiungendo un numero alla fine del nome della colonna. Se si osservano colonne con questa numerazione, è consigliabile rivedere la progettazione.
Tale progettazione presenta diversi difetti. Prima di tutto, impone la definizione di un limite massimo al numero di prodotti e, quando si supera tale limite, diventa necessario aggiungere un nuovo gruppo di colonne alla struttura della tabella e ciò implica un'attività amministrativa importante.
Un altro problema è dovuto allo spreco di spazio per i fornitori con un una quantità di prodotti inferiore al numero massimo, perché le colonne aggiuntive saranno vuote. Il difetto più grave di tale progettazione è che rende difficile l'esecuzione di molte attività, ad esempio l'ordinamento o l'indicizzazione della tabella per ID prodotto o per nome.
Ogni volta che si rilevano gruppi ripetuti, è consigliabile rivedere attentamente la progettazione considerando la possibilità di dividere la tabella in due. Nell'esempio precedente è preferibile usare due tabelle, una per i fornitori e una per i prodotti, collegate con l'ID fornitore.
Applicazione delle regole di normalizzazione
Come passaggio successivo del processo di progettazione, è possibile applicare regole di normalizzazione dei dati, dette a volte semplicemente regole di normalizzazione, che consentono di verificare se le tabelle sono strutturate correttamente. Il processo di applicazione delle regole alla progettazione del database è detto normalizzazione del database o solo normalizzazione.
La normalizzazione risulta utile soprattutto dopo che sono stati rappresentati tutte le informazioni e avere creato la progettazione preliminare. Consente di verificare che gli elementi di informazioni siano stati suddivisi nelle tabelle appropriate, ma non può invece assicurare che siano stati inseriti tutti gli elementi di dati corretti con cui iniziare.
Applicare le regole in successione, verificando a ogni passaggio che la progettazione raggiunga una di quelle che vengono definite "forme normali". In genere vengono ampiamente accettate cinque forme normali, dalla prima alla quinta. Questo articolo considera solo le prime tre, perché rappresentano i requisiti necessari per la maggior parte delle progettazioni di database.
Prima forma normale
La prima forma normale specifica che a ogni intersezione di riga e colonna nella tabelle è presente un singolo valore e mai un elenco di valori. Ad esempio non è possibile avere un campo denominato Prezzo con cui siano presenti più prezzi. Se si considera ogni intersezione di riga e colonna come una cella, ogni cella può contenere un solo valore.
La prima forma normale specifica che a ogni intersezione di riga e colonna nella tabelle è presente un singolo valore e mai un elenco di valori. Ad esempio non è possibile avere un campo denominato Prezzo con cui siano presenti più prezzi. Se si considera ogni intersezione di riga e colonna come una cella, ogni cella può contenere un solo valore.
Seconda forma normale
La seconda forma normale richiede che ogni colonna non chiave sia completamente dipendente dall'intera chiave primaria e non solo da una parte di tale chiave. Questa regola viene applicata in presenza di una chiave primaria composta da più colonne. Si supponga ad esempio di avere una tabella contenente le colonne seguenti, dove ID ordine o ID prodotto costituisce la chiave primaria:
ID ordine (chiave primaria)
ID prodotto (chiave primaria)
Nome prodotto
Questa progettazione viola la seconda forma normale, perché Nome prodotto è dipendente da ID prodotto ma non da ID ordine, quindi non è dipendente dall'intera chiave primaria. È necessario rimuovere Nome prodotto dalla tabella, perché appartiene a un'altra tabella (Prodotti).
Terza forma normale
La terza forma normale richiede non solo che ogni colonna non chiave sia dipendente dall'intera chiave primaria, ma che le colonne non chiave siano indipendenti le une dalle altre.
In altre parole, ogni colonna non chiave deve essere dipendente dalla chiave primaria ed esclusivamente dalla chiave primaria. Si supponga ad esempio di avere una tabella che contiene le colonne seguenti:
ID prodotto (chiave primaria)
Nome
PDC
Sconto
Si supponga che la colonna Sconto dipenda dal prezzo al dettaglio consigliato (PDC). Questa tabella viola la terza forma normale perché una colonna non chiave, Sconto, dipende da un'altra colonna non chiave, PDC. Indipendenza delle colonne significa che deve essere possibile modificare qualsiasi colonna non chiave senza influire su qualsiasi altra colonna. Se si modifica un valore nel campo PDC, il valore di Sconto verrebbe modificato di conseguenza, violando in tal modo la regola. In questo caso è necessario spostare la colonna Sconto in un'altra tabella la cui chiave primaria è basata sulla colonna PDC.
fonte: https://support.office.com/it-it/article/nozioni-fondamentali-sulla-progettazione-di-database-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5#bmdesignprocess
Commenti
Posta un commento