Progettazione di un database

Transcript

1 Progettazione di un database

2 Progettazione di un database In questo modulo vengono brevemente introdotti alcuni concetti di base riguardanti la strutturazione logica e la normalizzazione dei database. A supporto delle descrizioni vengono utilizzati degli esempi: in particolare viene descritto il database Azienda che verrà creato nei moduli successivi. Infine vengono descritti gli oggetti presenti in Access e le diverse modalità di creazione delle tabelle. Progettazione di un database... 3 Normalizzazione... 9 Il database Azienda Oggetti di Microsoft Access Finestra Database Creazione di tabelle Dati esterni Progettazione di un database

3 Prima di avviare Access è opportuno chiarire in sintesi alcuni concetti elementari sulla creazione di database. Lo scopo di questo modulo introduttivo è quello di fornire delle indicazioni di massima da tenere presenti in fase di progettazione di un database. Verranno fornite delle indicazioni generali, presentando i problemi più comuni con le relative soluzioni. Progettazione di un database Col termine database (o base di dati), nel corso delle lezioni che seguiranno, si identificherà un insieme organizzato di informazioni. Un database è ad esempio l'insieme delle informazioni gestite dall'ufficio anagrafico di una città, oppure l'insieme dei dati relativi alle situazioni cliniche dei pazienti di un ospedale. Nel descrivere la prima fase di creazione di un database si supponga di dover archiviare informazioni relative ai reclami che un ufficio preposto di una certa azienda deve gestire. Come prima operazione si può pensare di creare una tabella contenente le seguenti informazioni: Tabella: Reclami Codice Reclamo Data Reclamo Cliente Prodotto Motivo Reclamo 1 14 Settembre 2009 Rossi SpA M-XP Coperchio deformato 1 14 Settembre 2009 Rossi SpA SENDIMAR-20 Etichetta rovesciata 1 14 Settembre 2009 Rossi SpA MEBV-10 Gusto amaro 2 15 Settembre 2009 Bianchi Srl M-XP Coperchio difettoso 2 15 Settembre 2009 Bianchi Srl KL-50 Gusto amarognolo 3 18 Settembre 2009 Rossi SpA SENDIMAR-20 Etichetta rovesciata 3 18 Settembre 2009 Rossi SpA MEBV-10 Etichetta rovesciata 4 19 Settembre 2009 Neri Srl M-XP Coperchio danneggiato In questa tabella si sono inserite cinque colonne (denominate campi) che contengono le informazioni essenziali del raclamo. Ogni riga (denominata record), infatti, contiene le informazioni relative a un prodotto con il motivo del reclamo (oltre alle informazioni generali del reclamo stesso come il codice attribuito, la data del reclamo e il nominativo del cliente che ha inoltrato il reclamo). Apparentemente si tratta di una corretta impostazione del database. In realtà questa tabella presenta diversi problemi di impostazione con successiva difficile gestione dei dati. Si può notare, infatti, che le informazioni Data Reclamo e Cliente vengono ripetute inutilmente per ogni reclamo. Ad esempio i dati della prima riga 14 Settembre 2009 e Rossi SpA sono ripetuti anche Progettazione di un database 3

4 sulle due righe sottostanti (sempre appartenenti al reclamo numero 1). Questo comporta i seguenti problemi: Possibilità di commettere errori nella digitazione dei dati (ad esempio il cliente Rossi SpA si può scrivere Rossi S.p.A. oppure Rossi oppure ancora Rosssi SpA ). Ovviamente al momento di estrarre i reclami del cliente Rossi SpA si avranno risultati errati. In caso di correzioni si devono modificare diverse righe. Ad esempio se la data del reclamo numero 1 dovesse essere modificata in 09 Settembre 2009 si dovrebbero effettuare modifiche sulle prime tre righe della tabella. Per ovviare a questi problemi si deve fare in modo che la data del reclamo e il cliente siano presenti nel database una sola volta. In questo modo si evitano errori per inserimenti multipli e si facilita la gestione successiva dei dati. Per fare ciò si deve separare la tabella in due tabelle come illustrato nella figura della pagina successiva. Come si può constatare, con questa soluzione la data del reclamo e il cliente vengono inseriti una sola volta nella tabella principale Reclami, mentre nella tabella secondaria Dettagli viene riportato il codice del reclamo e inseriti i diversi prodotti facenti parte dei diversi reclami. 4 Progettazione di un database

5 Come si può notare dalla figura è presente un legame tra i campi Codice Reclamo presenti nelle due tabelle. Infatti è questo campo che determina il collegamento tra dati della tabella principale (dati generali del reclamo) con quelli della tabella secondaria (dati di dettaglio del reclamo). Questa situazione ricorre molte volte nella progettazione di un database: quando si hanno diversi dati secondari collegati a un solo dato principale, la soluzione migliore è quella di separare le due serie di dati in due tabelle collegate tra di loro. Si riportano di seguito alcuni esempi: In conclusione la separazione dei dati in due tabelle relazionate tra di loro (database relazionale) determina la non ridondanza dei dati e una maggiore facilità di gestione degli stessi. Rimangono, tuttavia, ancora dei problemi da risolvere. Si faccia riferimento alla figura seguente, nella quale viene riportato lo stato attuale delle tabelle con inseriti alcuni dati di prova. Progettazione di un database 5

6 Si noti che il cliente dei reclami 1 e 3, pur essendo sempre lo stesso, è stato scritto in due modi differenti; così come il nome di alcuni prodotti. Al contrario può succedere che esistano due clienti omonimi (cioè con la stessa denominazione): in questo caso si renderebbe impossibile la loro univoca identificazione. La questione, in questo caso, è, quindi, quella di evitare di scrivere il nome del cliente o del prodotto ma un suo codice univoco che faccia riferimento alle tabelle Clienti e Prodotti. Ragionando per codici univoci si permette anche una facile gestione dei dati. Ad esempio se il cliente Rossi SpA cambiasse denominazione in Rossi & Bianchi SpA basterà modificare in una sola riga della tabella Clienti la sua denominazione: il codice univoco rimarrà, invece, lo stesso e quindi anche il riferimento nella tabella Reclami. Un problema analogo si pone per il motivo del reclamo: come si può notare si possono commettere errori di battitura ( Etichettta... ) oppure scrivere descrizione di motivi in modo diverso ma con lo stesso significato ( Gusto amaro e Gusto amarognolo oppure Coperchio difettoso, Coperchio rotto e Coperchio errato ). Anche in questo caso si rende necessaria una tabella contenente l elenco di tutti i motivi di reclamo, opportunamente codificati. A seguito di queste considerazioni la struttura del database (a questo punto veramente relazionale ) si presenta nella configurazione seguente: 6 Progettazione di un database

7 Progettazione di un database 7

8 A fronte di una certa complessità della struttura del database fa riscontro una più semplice manutenzione dei dati: infatti basterà cambiare le informazioni nelle tabelle Clienti ; Prodotti e Motivi reclamo perché queste vengano automaticamente collegate con i dati delle altre tabelle. Nelle tabelle di anagrafica (come sono le tabelle Clienti, Prodotti e Motivi reclamo ) deve essere sempre presente un codice di identificazione univoco del record. Tale campo viene detto campo chiave, ed è per mezzo di questo campo che si rende sempre possibile identificare il record in modo preciso e sicuro. Generalmente si tratta di un valore numerico progressivo aggiornato automaticamente da Access. Può trattarsi, però, anche di un qualunque codice alfanumerico personalizzabile. In questo caso deve essere inserito manualmente nel campo: essendo associato a chiave non sarà possibile attribuire lo stesso valore a due record diversi è sarà un campo a compilazione obbligatoria. Le relazioni presenti tra le tabelle comportano l integrazione dei dati presenti: ad esempio il legame tra i campi Cliente delle tabelle Reclami e Clienti determina che nel valore presente nella prima tabella comprenda tutto il record correlato presente nella seconda tabella. Sarà così possibile, per mezzo delle interrogazioni al database (query) sapere il nominativo del cliente che ha effettuato il reclamo assieme a tutti gli altri dati del cliente stesso come illustrato con la query seguente: Access offre, inoltre, strumenti di controllo e di congruenza dei dati: ad esempio se si tenta di cancellare il cliente Rossi SpA dalla tabella Clienti, il sistema stesso, se opportunamente impostato, impedisce di farlo essendo quel cliente collegato a una o più righe della tabella Reclami. Analogamente se si tenta di inserire nella tabella Reclami come codice del cliente la sigla S15, il sistema lo impedisce non essendo presente nessun cliente con quella sigla nella tabella Clienti. 8 Progettazione di un database

9 Normalizzazione Vediamo quindi di capire cosa s'intende per forme normali e normalizzazione dei database. Prima forma normale (1NF) La prima forma normale definita per un database esprime un concetto semplice ma fondamentale: ogni riga di ciascuna tabella deve poter essere identificata in modo univoco tramite un gruppo di dati in essa contenuti. In altre parole, in una tabella del tipo: Nominativo Età Professione Rossini 30 Impiegato Carli 24 Studente Rossini 30 Impiegato Franchi 50 Insegnante non è possibile distinguere il dato inserito nella prima riga da quello inserito nella terza: le due righe sono infatti identiche. Il Rossini della prima riga, di 30 anni impiegato, non è infatti distiunguibile dal Rossini, 30 anni, impiegato, della terza riga. Il problema potrebbe essere risolto inserendo un altro campo nella tabella, con valore diverso per ogni riga, ad esempio il codice fiscale. A questo punto il database sarebbe in prima forma normale. Il campo o l'insieme di campi diversi per ciascuna riga e sufficienti ad identificarla sono detti chiave primaria della tabella (in questo caso il codice fiscale). Codice Fiscale Nominativo Età Professione RSSBLN79Y12T344A Rossini 30 Impiegato CRLBNCT84A11L611B Carli 24 Studente RSSMNN79E64A112A Rossini 30 Impiegato FRNTMT59U66P109B Franchi 50 Insegnante Il miglioramento delle prestazioni in questo caso è piuttosto evidente: la presenza di righe uguali all'interno di una tabella è infatti un evidente sintomo di inefficienza, che viene così eliminato. Progettazione di un database 9

10 Si noti che la presenza di una chiave primaria è requisito indispensabile ma non sufficiente affinchè una base dati sia in prima forma normale; infatti è altresì necessario che non vi siano gruppi di attributi che si ripetono (ossia ciascun attributo deve essere definito su un dominio con valori atomici). La tabella vista poco sopra è in 1NF; per chiarezza facciamo un esempio di una tabella che, seppur munita di una chiave primaria, non può essere considerata in forma normale: Codice Fiscale Nominativo Altri dati RSSBLN79Y12T344A Rossini Età: 30; Professione: Impiegato CRLBNCT84A11L611B Carli Età: 24; Professione: Studente RSSMNN79E64A112A Rossini Età: 30; Professione: Impiegato FRNTMT59U66P109B Franchi Età: 50; Professione: Insegnante La tabella qui sopra NON è in 1NF in quanto, pur avendo una chiave primaria, presenta un campo (dettagli) che non contiene dati in forma atomica. Seconda forma normale (2NF) Un ulteriore miglioramento è possibile passando alla seconda forma normale. Perchè una base dati possa essere in 2NF è necessario che: si trovi già in 1NF tutti i campi non chiave dipendano dall'intera chiave primaria (e non solo da una parte di essa). Per fare un esempio si supponga di avere a che fare con il database di una scuola con una chiave primaria composta dai campi "Codice Studente" e "Codice Esame": Codice Studente Codice Esame Nominativo Studente Voto Esame 1234 M01 Rossi Alberto L02 Rossi Alberto L02 Verdi Mario 8 Il database qui sopra si trova in 1NF ma non in 2NF in quanto il campo "Nominativo Studente" non dipende dall'intera chiave ma solo da una parte di essa ("Codice Studente"). 10 Progettazione di un database

11 Per rendere il nostro database 2NF dovremo scomporlo in due tabelle: Codice Studente Codice Esame Voto Esame 1234 M L L02 8 e Codice Studente Nominativo Studente 1234 Rossi Alberto 1235 Verdi Mario Nella prima tabella il campo "Voto" dipende correttamente dalla chiave primaria composta da "Codice Studente" e "Codice Esame", nella seconda tabella il campo "Nominativo Studentea" dipende correttamente dalla sola chiave primaria presente ("Codice Studente"). Ora il nostro database è normalizzato in seconda forma normale. Terza forma normale (3NF) Anche la terza forma normale, che definisce in modo ancora più puntuale ed efficiente la struttura delle tabelle di un database, si basa sul concetto di dipendenza funzionale già esposto. Un database è in 3NF se: è già in 2NF (e quindi, necessariamente, anche 1NF) tutti gli attributi non chiave dipendono direttamente dalla chiave (quindi non ci sono attributi "non chiave" che dipendono da altri attributi "non chiave"). Per fare un esempio torniamo all'ipotetico database degli esami; supponiamo di avere una base dati che associ il codice fiscale dell'iscritto al corso frequentato ed all'insegnante di riferimento. Si supponga che il nostro database abbia un'unica chiave primaria ("Codice Fiscale") e sia così strutturato: Progettazione di un database 11

12 Codice Fiscale Codice Corso Insegnante RSSBLN79Y12T344A BB01 De Rossi CRLBNCT84A11L611B BB01 De Rossi RSSMNN79E64A112A BB01 De Rossi FRNTMT59U66P109B AE02 Sandri Il nostro database non è certamente 3NF in quanto il campo "insegnante" non dipende dalla chiave primaria ma dal campo "Codice Corso" (che non è chiave). Per normalizzare il nostro database in 3NF dovremo scomporlo in due tabelle: Codice Fiscale RSSBLN79Y12T344A CRLBNCT84A11L611B RSSMNN79E64A112A FRNTMT59U66P109B Codice Corso BB01 BB01 BB01 AE02 e Codice Corso BB01 AE02 Insegnante De Rossi Sandri Il nostro database è ora in terza forma normale. 12 Progettazione di un database

13 Il database Azienda Il database che durante lo sviluppo delle prossime lezioni verrà utilizzato è l'insieme delle informazioni relative ai Clienti, agli Agenti, ai Fornitori, al Magazzino e agli Ordini dei clienti di una ipotetica azienda di distribuzione. Lo schema del database Azienda è descritto nelle pagine seguenti. Il database Azienda è formato dai seguenti gruppi di informazioni: Clienti (denominazione, recapito, dati fiscali) Agenti (denominazione, recapito, dati fiscali) Fornitori (denominazione, recapito, dati fiscali) Articoli a magazzino (descrizione, fornitore, costo di acquisto dal fornitore, prezzo di vendita al cliente, quantità presente a magazzino) Ordini dei clienti (date di effettuazione e di evasione dell ordine, agente e cliente che effettuano l ordine, articoli ordinati con la relativa quantità ordinata) Ciascuno di questi gruppi di informazioni può essere rappresentato in forma di tabella. Nella tabella Clienti, ad esempio, ciascuna riga conterrà la descrizione dei dati relativi ad un singolo cliente. A titolo di esempio si veda la figura seguente. Codice Dati anagrafici Dati Fiscali AC157 Mi.C. Srl Via Roma, Verona P.Iva Si può quindi ribadire che un database è un insieme di tabelle contenenti informazioni strutturate e logicamente coerenti. Come già ricordato ad ogni riga di una tabella di database si dà il nome di record. Nella figura precedente è evidenziato il record del cliente Mi.C. s.r.l. Dall'esame della tabella presentata in figura emerge che le informazioni relative ad un cliente sono ulteriormente suddivise in unità base di informazione (Codice, Dati anagrafici, Dati fiscali). A ciascuna di queste unità elementari di informazione si dà il nome di campo del record. In definitiva un database è un insieme di tabelle, composte da uno o più record, suddivisi in uno o più campi. Progettazione di un database 13

14 L'organizzazione di una base di dati non si esaurisce però nella sola determinazione della struttura di ciascuna tabella a livello di record e campi. Infatti una riga della tabella Ordini conterrà dei riferimenti all agente che ha emesso l'ordine, al cliente che lo ha effettuato e agli articoli di magazzino richiesti. Inoltre, nella pianificazione stessa del database è conveniente procedere ad una codifica delle informazioni tale per cui possano essere evitate le ripetizioni superflue di informazioni e le possibilità di errore. Ad esempio nel momento della compilazione dell'ordine di un cliente per un particolare articolo di magazzino sarebbe decisamente poco efficiente dover riscrivere ogni volta i dati del cliente o le caratteristiche dell'articolo: i primi sono già disponibili nella tabella Clienti e le seconde nella tabella Magazzino. È necessario, in fase di progettazione del database effettuare una descrizione dettagliata di tutte le tabelle del database e dei collegamenti (in termine tecnico relazioni) che sussistono tra di esse. La gestione di una base di dati come quella proposta per il database Azienda non è immediata e richiede una attenta analisi delle operazioni da rendere disponibili e dei collegamenti da attivare. Per semplificarne la gestione si suddividerà in blocchi il database Azienda. Si creeranno in successione le tabelle Clienti, Agenti, Magazzino, Ordini, Dettagli ordini e Fornitori impostando le relazioni di collegamento. Ogni volta che all ufficio vendite viene presentato un ordine emesso da un agente, esso deve essere immesso nel registro ordini. Inoltre deve essere possibile identificare univocamente, l Agente che lo ha emesso, il Cliente che lo ha effettuato, gli articoli richiesti ed i loro quantitativi. Si tenga presente che: ciascun agente può emettere più ordini ciascuno di questi ordini può far riferimento ad uno stesso cliente o ad un altro cliente in ogni ordine possono essere richiesti uno o più articoli di magazzino. La situazione è rappresentata nella figura seguente Cliente Ordine Agente Dettagli ordine 14 Progettazione di un database

15 Essa suggerisce l organizzazione delle informazioni in sei tabelle: Agenti (Codice Agente, Dati anagrafici, Dati fiscali) Il Codice Agente si rende necessario per poter distinguere in modo inequivocabile gli agenti (si potrebbero presentare dei casi di omonimia): Codice Agente Agente Indirizzo CAP Località Prov Tel Fax Codice Fiscale 1 Bianchi Giampaolo 2 Rossini Emanuele 3 De Grandi Patrizia 4 Ferrari Francesco 5 Di Gennaro Giuseppe Clienti (Codice Cliente, Dati anagrafici, Dati fiscali) Il Codice Cliente identifica univocamente il cliente. Codice Cliente Cliente Indirizzo CAP Località Prov Tel Fax Partita IVA 1 Mi.C. Srl 2 De.Fra.L. Spa 3 Risparmio Snc 4 Ordini (Codice Ordine, Codice Agente, Codice Cliente, Date) Il Codice Ordine è progressivo e identifica univocamente l ordine; il Codice Agente identifica l agente che lo ha emesso; il Codice cliente identifica il cliente che lo ha effettuato. Sono inoltre presenti le date di emissione e di evasione dell ordine. Codice Ordine Data Ordine Codice Agente Codice Cliente 1 21-gen gen gen Data Evasione Progettazione di un database 15

16 Dettagli ordini (Codice Ordine, Codice Articolo, Quantità Ordinata) Il Codice Ordine identifica l ordine a cui appartiene la riga di dettaglio; il Codice Articolo identifica l articolo ordinato; la Quantità Ordinata indica il numero di pezzi ordinati. Codice Ordine Codice Articolo Quantita Ordinata La suddivisione del registro degli ordini ai clienti nelle due tabelle Ordini e Dettagli ordini trova la sua giustificazione nel fatto che bisogna ridurre al minimo la ripetizione delle informazioni superflue. In questo modo vengono immesse una sola volta le informazioni relative al Cliente, all Agente e alle date di emissione e di evasione mentre le informazioni relative agli articoli ordinati sono comunque collegate (tramite il numero d ordine) all ordine corrispondente. Questa struttura è del resto la più vicina al modo col quale normalmente viene compilato un ordine su un modulo cartaceo. Magazzino (Codice Articolo, Codice Fornitore, Descrizione, Costo, Prezzo, Quantità) Codice Articolo Codice Fornitore Descrizione Artticolo Costo Acquisto Prezzo Vendita Quantita Magazzino 1 Ab12 Cartellina portadocumenti 0,55 1, Ab12 Busta portadocumenti 0,32 0, Ab12 Portablocco 26,6x32,8 4 Il Codice Articolo identifica univocamente l articolo a magazzino; il Codice Fornitore identifica univocamente il fornitore dell articolo; il costo è quello di acquisto dal fornitore ed il prezzo è quello di vendita al cliente; la quantità indica il numero degli articoli di un dato tipo presenti a magazzino. 16 Progettazione di un database

17 Fornitori (Codice Fornitore, Dati anagrafici, Dati fiscali) Il Codice Fornitore identifica univocamente il fornitore. Codice Fornitore Ragione Sociale Indirizzo CAP Località Prov Tel Fax Ab12 Devon Srl Ab13 Plast Italia Ab14 Per concludere nell immagine seguente si riporta lo schema di relazioni presenti nel database Azienda. Tutte le relazioni presenti sono del tipo uno a molti. Questo significa che a un record della tabella principale (dalla parte uno del legame, rappresentata dal simbolo 1) possono corrispondere molti record nella tabella correlata (dalla parte molti del legame, rappresentata dal simbolo ). Ad esempio un certo cliente presente nella tabella Clienti potrà essere presente molte volte nella tabella Ordini se avrà eseguito diversi ordini. La modalità di creazione delle relazioni verrà illustrata nelle lezioni seguenti: si tenga comunque presente questo schema perché potrà essere di aiuto nella comprensione degli esercizi del manuale. Progettazione di un database 17

18 Oggetti di Microsoft Access Terminata questa breve trattazione teorica sulla progettazione di database (che verrà comunque ripresa al termine del presente modulo per introdurre il database oggetto del testo), si rende necessaria una descrizione delle principali funzionalità offerte da Access e dell interfaccia del programma. Gli oggetti presenti in un database di Access sono di seguito elencati: Tabelle / Tables Le tabelle costituiscono l archivio delle informazioni. Esempi di tabelle sono stati descritti nelle pagine precedenti. Si ricorda che la singola informazione comune a tutte le righe della tabella (cioè le colonne) si chiamano campi, mentre i dati presenti (cioè le righe) si chiamano record. Ad esempio, facendo riferimento alla tabella Clienti di cui si è parlato in precedenza sono campi le informazioni come Codice cliente, Nome. Città, Indirizzo, Telefono ecc., mentre record è la riga ad esempio del cliente codificato con la sigla S10. La caratteristica principale dei campi è il tipo di dato che può essere memorizzato. I tipi di dati più utilizzati sono: contatore (è un numero progressivo aggiornato in automatico da sistema; viene utilizzato di solito come chiave della tabella) testo (memorizza stringhe di testo alfanumeriche) numerico (memorizza valori numerici) data/ora (memorizza una data oppure un ora) sì/no (memorizza un valore binario come on/off oppure vero/falso) Le tabelle sono collegate tra di loro formando appunto il database relazionale. Query / Queries Le query sono lo strumento di interrogazione, di modifica, archiviazione o eliminazione dei dati presenti nel database. Le query si suddividono in due tipologie: query di estrazione dei dati da una o più tabelle corrispondenti a uno o più criteri di estrazione e di ordinamento; query di comando o di modifica automatica dei dati presenti, come aggiornamento di dati, eliminazione di record, accodamento a tabelle esistenti ecc. Una query di comando modifica sempre i dati presenti nelle tabelle è quindi la sua esecuzione deve essere sempre ponderata. Maschere / Forms Le maschere costituiscono l interfaccia utente del database. Esse, infatti, permettono l inserimento e la modifica dei dati utilizzando una visualizzazione più semplice e personalizzabile rispetto le tabelle. Con le maschere, inoltre, si possono creare pannelli per l esecuzione di comandi oppure delle finestre personalizzate di diverso tipo. Infatti nelle maschere è possibile inserire controlli come caselle di testo, 18 Progettazione di un database

19 caselle combinate, gruppi di opzione, pulsanti di comando ecc. abbinabili a campi di tabelle oppure a macro per l esecuzione in automatico di operazioni. È possibile altresì controllare e limitare l accesso ai dati mediante l impostazione di proprietà o l esecuzione di procedure automatizzate. Report / Reports Sia la tabelle come le query sono stampabili sotto forma di listato di dati. Con l oggetto Report è possibile generare delle stampe personalizzate sia per l aspetto sia per l inserimento di totali parziali o percentuali, non inseribili nelle query e tantomeno nelle tabelle. Di regola, quindi, le query permettono la semplice estrazione dei dati (comunque stampabili), mentre i report si appoggiano a tali query (o anche a tabelle) e ne rendono migliore la resa su stampa. Macro / Macros Le macro sono procedure che permettono di automatizzare operazioni che, se compiute manualmente, possono essere fonte di errori o comportare troppa laboriosità. Per realizzare tali procedure non occorre conoscere alcun linguaggio di programmazione, in quanto le singole azioni sono già codificate. Moduli / Modules I moduli sono procedure che permettono di automatizzare operazioni più complesse rispetto le macro. A differenza delle macro per realizzare tali procedure occorre conoscere il linguaggio di programmazione Visual Basic. Finestra Database Creando un database, Access crea una finestra denominata Finestra Database. Si tratta di una schermata complessiva composta da un pannello a sinistra in cui è visibile l elenco degli oggetti e da una parte destra in cui viene aperto l oggetto stesso. Nel pannello di sinistra, aprendo il menu, appare l elenco di comandi visibile nella figura seguente. Progettazione di un database 19

20 Con questo menu è possibile visualizzare gli oggetti in diverso modo. Il menu è diviso in due parti. La parte superiore, denominata Passa a categoria permette di visualizzare gli oggetti secondo un diverso ordine. Personalizzato Tipo di oggetto Tabelle e viste correlate Data creazione Data modifica Permette di creare un Gruppo personalizzato in cui spostare oggetti prelevati dall elenco Visualizza gli oggetti suddivisi per gruppo Per ogni tabella, visualizza gli oggetti (Query, Maschere, Report) correlati cioè dove quella tabella è utilizzata Visualizza gli oggetti ordinati per data di creazione Visualizza gli oggetti ordinati per data di modifica La sezione sottostante Filtra per gruppo permette di lasciare visibile solo un tipo di oggetto (Tabelle, Query, Maschere, Report) oppure di visualizzare tutti gli oggetti. 20 Progettazione di un database

21 Creazione di tabelle Attivando la barra strumenti Crea è possibile creare una nuova Tabella utilizzando i pulsanti posti a sinistra della barra stessa e visibili nella seguente finestra: Tali pulsanti permettono (nell ordine): Creare una tabella in modalità foglio dati. Appare un foglio dati in cui è possibile inserire direttamente i nuovi campi e i dati come visibile nella figura seguente: Creare una tabella utilizzando dei modelli predefiniti attraverso il menu visibile nella figura seguente: Creare una tabella utilizzando un elenco di SharePoint; Creare una tabella in modalità Struttura. Questo è sicuramente il metodo più usato perché permette di definire tipo e proprietà dei campi e successivamente di inserire i dati. Progettazione di un database 21

22 Dati esterni Con la barra strumenti Dati esterni è possibile importare dati da fonti esterne ed esportare dati. I pulsanti presenti hanno il seguente significato: Importazioni salvate Accedere alle importazioni salvate in modo da effettuare nuovamente una importazione simile ad una effettuata in precedenza. Infatti al termine di una importazione, tramite una procedura guidata, Access chiede se si desidera salvarne le caratteristiche. Sarà così possibile richiamarla in futuro ed eseguirla Ad esempio, in una specifica di importazione che esegue l importazione di dati da una cartella di lavoro di Microsoft Excel sono memorizzati il nome del file di Excel di origine, il nome del database di destinazione e altri dettagli, ad esempio se i dati sono stati accodati o se è stata creata una nuova tabella, le informazioni sulla chiave primaria, i nomi di campo e così via. Importa: Access, Excel, Elenco SharePoint, File di testo, File XML, Altro Con questi pulsanti si accede alle corrispondenti procedure di importazione dalle diverse tipologie di dati esterni. Le fonti più usate sono sicuramente Access, Excel e File di testo Esportazioni salvate Analogamente alle importazioni è possibile salvare le esportazioni in modo da richiamarle ed effettuarle velocemente in un momento successivo. Esporta: Excel, Elenco SharePoint, Word, File di testo, Altro Con questi pulsanti si accede alle corrispondenti procedure di esportazione. Molto utilizzata è l esportazione in Excel data la notevole diffusione di questo programma. Da segnalare l esportazione in File di testo (che occupa assai poco spazio anche su moli di dati notevoli). All interno della sezione Altro è possibile effettuare anche la Stampa Unione in Word. 22 Progettazione di un database