Issuu on Google+

Progettazione di un database


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 .............................................................................................................................. 13 Oggetti di Microsoft Access ................................................................................................................. 18 Finestra Database ................................................................................................................................. 20 Creazione di tabelle .............................................................................................................................. 22

2

Progettazione di un database


Progettazione di un database 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 2003

Rossi SpA

M-XP-12-1500

Coperchio deformato

1

14 Settembre 2003

Rossi SpA

SENDIMAR-20

Etichetta rovesciata

1

14 Settembre 2003

Rossi SpA

MEBV-10

Gusto amaro

2

15 Settembre 2003

Bianchi Srl

M-XP-12-1500

Coperchio difettoso

2

15 Settembre 2003

Bianchi Srl

KL-50

Gusto amarognolo

3

18 Settembre 2003

Rossi SpA

SENDIMAR-20

Etichetta rovesciata

3

18 Settembre 2003

Rossi SpA

MEBV-10

Etichetta rovesciata

4

19 Settembre 2003

Neri Srl

M-XP-12-1500

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 2003” e “Rossi SpA” sono ripetuti anche Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

3


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 2003” 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. Tabella: Reclami Codice Reclamo

Data Reclamo

Cliente

1

14 settembre 2003

Rossi SpA

2

15 settembre 2003

Bianchi Srl

3

18 settembre 2003

Rossi SpA

4

19 settembre 2003

Neri Srl

1 

Tabella: Dettagli

Codice Reclamo

4

Progettazione di un database

Prodotto

Motivo Reclamo

1

M-XP-12-1500

Coperchio deformato

1

SENDIMAR-20

Etichetta rovesciata

1

MEBV-10

Gusto amaro

2

M-XP-12-1500

Coperchio difettoso

2

KL-50

Gusto amarognolo

3

SENDIMAR-20

Etichetta rovesciata

3

MEBV-10

Etichetta rovesciata

4

M-XP-12-1500

Coperchio danneggiato

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


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:

Tabella: Fatture Codice Fattura

Data Fattura

Cliente

1 

Tabella: Dettagli

Codice Fattura

Prodotto / Servizio

Quantità

Prezzo

Tabella: Corsi Codice Corso

Data Corso

Docente

Aula

1 

Tabella: Dettagli

Codice Corso

Partecipante

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.

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

5


Tabella: Reclami Codice Reclamo

Data Reclamo

Cliente

1

14 settembre 2003

Rossi SpA

2

15 settembre 2003

Bianchi Srl

3

18 settembre 2003

Rossi S.p.A.

4

19 settembre 2003

Neri Srl

1 

Tabella: Dettagli

Codice Reclamo

Prodotto

Motivo Reclamo

1

M XP 12 1500

Coperchio deformato

1

SENDIMAR-20

Etichetta rovesciata

1

MEBV-10

Gusto amaro

2

M / XP / 12 / 1500

Coperchio difettoso

2

KL-50

Gusto amarognolo

3

SENDIMAR-20

Etichetta rovesciata

3

MEBV.10

Etichetta rovesciata

4

M-XP-12-1500

Coperchio danneggiato

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

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


Tabella: Reclami Codice Reclamo

Data Reclamo

Cliente

Tabella: Clienti

1

14 settembre 2003

S10

Cliente

2

15 settembre 2003

S11

S10

Rossi SpA

...

...

3

18 settembre 2003

S10

S11

Bianchi Srl

...

...

4

19 settembre 2003

N10

N10

Neri Srl

...

...

1

Nome

Tabella: Dettagli

Codice Reclamo

Descriz.

Prodotto

Motivo Reclamo

1

A1

1

1

B3

2

...

1

A2

3

Tabella: Prodotti

A1

M-XP-12-1500

...

2

A1

1

B3

SENDIMAR-20

...

2

C1

3

A2

MEBV-10

...

3

B3

2

C1

KL 50

...

3

A2

2

4

A1

1

1

...

1

Prodotto

Città

Tabella: Motivi reclamo

Soltanto modificando la descrizione del Motivo Reclamo codificato con la chiave n° 1 in “Chiusura non ermetica”, automaticamente si avrà il conseguente significato della chiave esterna n° 1 nella tabella Dettagli.

Reclamo

Descrizione

1

Coperchio difettoso

2

Etichetta rovesciata

3

Gusto amarognolo 1

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

7


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: Query: Elenco reclami Codice Reclamo

Data Reclamo

Nome

Città

Telefono

...

....

1

14 settembre 2003

Rossi SpA

Verona

045 / 9866550

...

....

2

15 settembre 2003

Bianchi Srl

Milano

02 / 778811

...

....

3

18 settembre 2003

Rossi SpA

Verona

045 / 9866550

...

....

4

19 settembre 2003

Neri Srl

Roma

06 / 121234

...

....

Campi prelevati dalla tabella Reclami

Campi prelevati dalla tabella Clienti

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

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


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.

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

9


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

6

1234

L02

Rossi Alberto

7

1235

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

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


Per rendere il nostro database 2NF dovremo scomporlo in due tabelle: Codice Studente

Codice Esame

Voto Esame

1234

M01

6

1234

L02

7

1235

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:

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

11


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

Codice Corso

RSSBLN79Y12T344A

BB01

CRLBNCT84A11L611B

BB01

RSSMNN79E64A112A

BB01

FRNTMT59U66P109B

AE02

e Codice Corso

Insegnante

BB01

De Rossi

AE02

Sandri

Il nostro database è ora in terza forma normale.

12

Progettazione di un database

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


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, 5 – 36100 Verona

P.Iva 03453452450

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.

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

13


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

Dettagli ordine Agente

14

Progettazione di un database

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


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

Data Evasione

1

21-gen-04

2

6

2

26-gen-04

2

6

3

26-gen-04

1

11

4

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

15


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

1

1

500

1

6

10

1

15

20

2

1

300

2

2

200

2

3

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,03

5.000

2

Ab12

Busta portadocumenti

0,32

0,65

3.000

3

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

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


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.

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

17


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, caselle combinate, gruppi di opzione, pulsanti di comando ecc. abbinabili a campi di tabelle oppure a macro

18

Progettazione di un database

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


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. Pagine/ Pages Una pagina di accesso ai dati è un tipo speciale di pagina Web progettata per la visualizzazione e la gestione di dati provenienti da Internet o da una rete Intranet. Una pagina di accesso ai dati è direttamente connessa a un database. Quando gli utenti visualizzano la pagina di accesso ai dati in Microsoft Internet Explorer, visualizzano la propria copia della pagina. Tutte le modifiche apportate alla visualizzazione dei dati, quali le operazioni di filtraggio, di ordinamento e di altro genere, influiscono solo sulla propria copia della pagina di accesso ai dati. Le modifiche apportate ai dati veri e propri, ad esempio la modifica dei valori e l'aggiunta o l'eliminazione di dati, vengono memorizzate tuttavia nel database sottostante, diventando così disponibili a qualsiasi utente che visualizza la pagina di accesso ai dati. 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.

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

19


Finestra Database Creando un database, Access crea una finestra denominata “Finestra Database” e visibile nella figura seguente.

La finestra presenta la possibilità di accesso ai diversi oggetti elencati nel paragrafo precedente. Per ogni oggetto, nella parte in alto a sinistra della finestra, sono presenti tre pulsanti: Pulsante Apri / Open (Anteprima / Preview per i report; Esegui / Run per macro e moduli) Il pulsante Apri / Open permette di aprire la Tabella, la Query, la Maschera o la Pagina selezionata in modalità di visualizzazione dei dati. Il pulsante Anteprima / Preview apre il Report in modalità anteprima di stampa mentre il pulsante Esegui / Run manda in esecuzione la Macro o il Modulo selezionato. Per aprire un oggetto è sufficiente fare doppio clic sul nome dell’oggetto stesso all’interno della finestra Database. Pulsante Struttura / Design: apre l’oggetto selezionato in modalità di definizione e di modifica della sua struttura. Pulsante Nuovo / New: permette di creare un nuovo oggetto (Tabella, Query, Maschera, Report, Pagina, Macro o Modulo). Per gli oggetti Tabella, Query, Maschera e Report sono presenti strumenti di Autocomposizione che permettono di creare l’oggetto in modo guidato. Gli oggetti sono visibili all’interno della finestra Database in ordine alfabetico. Le seguenti voci, presenti nel menu Visualizza / View quando è visibile la finestra Database, permettono di visualizzare gli oggetti secondo quattro diverse modalità:

20

Progettazione di un database

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


A

B

C

D

A

visualizza l’elenco degli oggetti sotto forma di icone grandi;

B

visualizza l’elenco degli oggetti sotto forma di icone piccole;

C

visualizza l’elenco degli oggetti sotto forma di elenco (è l’impostazione di default);

D

visualizza l’elenco dei dettagli degli oggetti.

Se gli oggetti sono visibili sotto forma di icone (sia grandi che piccole) è possibile disporle a piacere all’interno della finestra Database. Se invece è visibile l’elenco dei dettagli è possibile ordinare gli oggetti anche per loro descrizione o per date (di creazione o di modifica) facendo clic sui pulsanti di intestazione dell’elenco. Al momento della creazione Access permette il salvataggio con nome dell’oggetto (è possibile assegnare un nome qualsiasi utilizzando anche gli spazi). Uscendo da Access non appare alcun messaggio di ulteriore salvataggio in quanto, appunto, l’oggetto viene salvato al momento della sua creazione. Tutto il database, quindi, con tutti gli oggetti e tutti i dati sono compresi in un unico file di estensione MDB (Microsoft DataBase).

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it

Progettazione di un database

21


Creazione di tabelle Premendo il pulsante Nuovo / New con la sezione Tabelle attiva appare la seguente finestra:

Le opzioni presenti hanno il seguente significato: Visualizzazione Foglio dati / Datasheet View Crea una nuova tabella visualizzando il foglio dati inserendo direttamente i dati. Il tipo di dati dei campi viene riconosciuto a seconda del dato inserito. Visualizzazione Struttura / Design View É l’opzione più comune: crea una nuova tabella visualizzandone la struttura. Con questa modalità è possibile definire e personalizzare il nome dei campi, i tipi di dati inseribili, il formato di visualizzazione dei dati ed effettuare il controllo dei dati inseriti (ad esempio il rispetto dell’obbligatorietà oppure di determinate regole di convalida). Crazioine guidata Tabella / Table Wizard Crea una nuova tabella in modo guidato utilizzando lo strumento dell’autocomposizione. Le tabelle presenti nell’autocomposizione sono di tipo standard: in un secondo momento è comunque possibile modificarne e personalizzarne la struttura. Importa Tabella / Import Table Crea una nuova tabella importandola da una fonte esterna. È possibile importare tabelle presenti in altri database di Access o database di altro tipo oppure importare dati in formato ASCII o in formato foglio di calcolo (ad esempio Microsoft Excel). Collegamento Tabella / Link Table Crea una nuova tabella collegandola da una fonte esterna. È possibile, ad esempio, collegare tabelle presenti in altri database di Access: in questo modo i dati presenti nella tabella sono visibili, modificabili e cancellabili sia dal database di origine, sia da quello in cui si è effettuato il collegamento.

22

Progettazione di un database

Copyright Telémaco - VERONA - www.telemaco.vr.it

info@telemaco.vr.it


Esempio Autodoc Database