Progettazione di un Database Per comprendere il processo di

Progettazione di un Database
Per comprendere il processo di progettazione di un Database deve essere chiaro il modo con cui vengono
organizzati e quindi memorizzati i dati in un sistema di gestione di Database Relazionale, ad es.: MS-Access, File
Maker, Paradox., e conoscere quali sono gli elementi che si possono trovare all’interno della struttura di un
database.
In genere, a prescindere dal programma utilizzato per la progettazione, gli elementi di un Database sono:
- tabelle
-
maschere
query (interrogazioni)
report
macro e moduli.
Tabelle.
Alla base della struttura di un DATABASE vi sono le tabelle, formate da righe e colonne, dove vengono inseriti i
dati organizzati secondo schemi logici; la prima riga di ogni tabella contiene l’intestazione dei campi (o attributi).
Le informazioni relative ad argomenti diversi devono essere memorizzati in tabelle distinte, in tal modo è possibile
accedere più rapidamente e direttamente a tali informazioni. Per esempio, è conveniente creare una tabella per
memorizzare le informazioni relative agli studenti e una relativa agli esami sostenuti. L'
attenzione va posta, quindi,
sulla relazione che deve intercorrere fra le due tabelle (ad es.: il campo matricola che deve essere comune ad
entrambe le tabelle).
Maschere.
La funzione delle maschere (ad es. in MS-Access) è quella di visualizzare i dati e/o modificare gruppi di record, o
visualizzare tutti i campi di un singolo record all’interno di una maschera, o i dati provenienti dall’esecuzione di una
query. Una maschera può essere definita come la rappresentazione a video di un modulo su carta.
Il vantaggio della visualizzazione dei dati mediante maschera, è che non bisogna rispettare rigorosamente la
struttura righe/colonne.
Query.
Una query consente la ricerca dei dati in una o più tabelle. Sono utilizzate per filtrare i dati delle tabelle in base a
“criteri” assegnati dall’utente. Le query possono, anzi sono spesso, utilizzate come base per creare maschere e
report. Consentono di definire quali record e quali campi visualizzare.
Report.
Un report consente di stampare su supporto cartaceo i dati delle tabelle, o dei risultati delle query. La realizzazione
di un report è simile all’impostazione di una maschera: è possibile scegliere in che modo raggruppare i record e
determinare la posizione dei campi nel report.
Macro e moduli.
Sono, in pratica, gli strumenti di programmazione dei database. Consistono in azioni e istruzioni, scritte in un
opportuno linguaggio di programmazione (in Access è il Visual Basic), che è possibile fare eseguire all’interno di
un database. Strutturalmente la macro è un insieme di istruzioni, ognuno delle quali viene chiamata azione. Le
azioni eseguibili, in Access, sono fornite in un elenco all’interno del programma.
6 Struttura di un database
La struttura di un Database è un elemento sostanziale che va esaminato prima ancora di creare le tabelle,
evidenziando l'
obiettivo che si intende raggiungere e indicando le relazioni che devono intercorrere fra le
informazioni in esso contenute.
7 Fasi di progettazione di un Database
Fase 1:
Definizione dello scopo.
- Determinare quali informazioni dovranno essere memorizzate nel Database
Fase 2:
Definizione delle tabelle.
- Suddividere le informazioni in argomenti distinti; ciascun argomento deve costituire una tabella del
database.
Definizione dei campi.
Fase 3:
Fase 4:
Fase 5:
Determinare le informazioni che devono essere contenuti in ciascuna tabella, ovvero i campi (o
categorie) della tabella; definire una eventuale chiave primaria.
Definizione delle relazioni.
- Stabilire le relazioni che intercorrono fra i dati delle tabelle. Se necessario aggiungere dei campi alle
tabelle.
Ritocchi finali alla struttura.
- Analizzare la struttura per la ricerca di eventuali errori, creando le tabelle e aggiungendo dati di
esempio.
Fase 1. - Definizione dello scopo.
Definire lo scopo e la modalità di utilizzo del DATABASE equivale a stabilire il tipo di informazioni che dovranno
essere gestite dal DATABASE stesso. Quindi bisogna fissare gli argomenti nei quali scomporre le informazioni (le
tabelle) e le categorie in cui suddividere ogni argomento (i campi delle tabelle).
Esempio.
Creare un database che contenga informazioni relative agli studenti iscritti ad una facoltà all’interno dell’Università,
agli esami che andranno a sostenere e ai vari corsi di laurea cui appartengono.
La prima cosa che si andrà a fare è quella di determinare una serie di domande alle quali il Database dovrà poter
rispondere. Come per esempio: "Quanti esami sono stati sostenuti da uno studente?", "Chi ha sostenuto più esami?",
"Qual è l’esame più sostenuto?".
A queste domande il Database dovrà rispondere elaborando le informazioni disponibili e visualizzarle mediante
maschere o sotto forma di report, o stampare, eventualmente, delle etichette postali relative agli studenti.
Fase 2. - Definizione delle tabelle.
Le tabelle sono la struttura portante di un database, la loro definizione determina la fase più complessa nella
progettazione di un Database.
Attraverso le tabelle vengono fornite al Database le categorie di base alle quali sono riconducibili i dati che si
intendono inserire. Inizialmente tutte le informazioni che il DATABASE deve gestire non sono organizzate in
maniera logica, quindi bisogna creare dei raggruppamenti che evitino di ripetere informazioni nel Database
causando inutili sprechi di memoria del supporto utilizzato, o che evitino di eliminare informazioni valide se
vengono cancellati i record di una tabella.
Es.: “Annullare le date degli esami sostenuti da uno studente perché inizia un nuovo anno”. Se le informazioni
relative allo studente (i dati anagrafici) e agli esami sono contenute in un’unica tabella, allora eliminando i record
relativi agli esami verranno eliminati anche i dati anagrafici del dipendente, mentre questi devono rimanere; allora, è
necessario raggruppare tutte le informazioni relative allo studente in una tabella distinta denominata “Studenti” e
tutte le informazioni relative agli esami dello studente in un’altra tabella denominata “Esami_sostenuti”.
Quindi, si devono esaminare le informazioni che il Database deve gestire e suddividerle in argomenti logici, quali
studenti, esami, struttura e così via. Ciascun argomento costituirà una tabella distinta.
A questo punto è possibile ottenere una bozza delle tabelle del Database:
Esami_sostenuti
…………
……………..
…………………
Studenti
…………
……………..
…………………
Esami
…………
……………..
…………………
Osservazioni:
•
Una tabella contiene molti campi con informazioni relative a diversi argomenti. (Es.: la tabella contiene campi
relativi agli studenti e campi relativi agli esami oppure ai corsi di laurea: conviene creare più tabelle).
•
•
Alcuni record di una tabella contengono dei campi vuoti perché appartengono ad un'
altra tabella.
Sono state create varie tabelle, molte delle quali contengono gli stessi campi. (Es.: una tabella relativa agli esami
sostenuti a gennaio, una con quelli sostenuti a febbraio e così via; basta creare un'
unica tabella con il campo
“data”).
Fase 3. - Definizione dei campi.
Ogni categoria di informazioni contenuta in una tabella determina un campo, che corrisponde ad una colonna di
essa. Esempio di campo è il Cognome della tabella Studenti; questo conterrà il cognome dello studente.
Nota per la definizione dei campi:
Ogni campo di una tabella deve riferirsi univocamente all’argomento della tabella. Se il campo contiene
informazioni relative all’argomento di un’altra tabella vuol dire che è stato incluso nella tabella sbagliata.
(Parleremo più avanti di relazioni).
Non includere campi derivati o risultati calcolati. Non è conveniente memorizzare nei campi delle tabelle il
risultato di calcoli. Questo può essere eseguito solo quando si vuole visualizzare il risultato. Es. nei report per
visualizzare i totali di alcune quantità di dati; “il numero di esami sostenuti da uno studente”, verrà calcolato
il totale degli studenti nella relativa tabella solo quando si vuole visualizzare o stampare il risultato, non deve
mai essere memorizzato il totale in un campo della tabella.
Includere tutte le informazioni necessarie. Può darsi che durante la fase di progettazione non vengano inserite
delle informazioni necessarie. In tal caso bisogna ritornare alla prima fase del processo e inserirle.
Immettere in campi distinti informazioni raggruppate. È conveniente, per esempio creare un campo per il
Nome e uno per il Cognome e non un unico campo che li contiene entrambi; se infatti si vuole fare la ricerca
per cognome risulterà complicato poterlo considerare singolarmente.
Campi chiave.
Un sistema di gestione di database relazionale è molto più potente quanto maggiore è la sua capacità, in termine
di velocità, di raggruppare e ricercare le informazioni contenute nelle tabelle. Per questo motivo ogni tabella del
Database dovrebbe contenere un campo che identifichi in modo univoco ciascun record memorizzato (vedi
paragrafo 3). Tale campo viene chiamato Chiave primaria della tabella. Per esempio, un campo chiave potrebbe
essere la matricola per gli studenti. Se una tabella non contiene un proprio identificatore vedremo, più avanti,
come sarà possibile utilizzare un campo che assegni a ciascun record un numero progressivo, quindi univoco, e
definire questo campo come chiave primaria.
Nella definizione dei campi “chiave primaria” bisogna tenere presente che:
non possono essere immessi valori duplicati o nulli.
non deve contenere valori troppo lunghi da ricordare o da digitare, soprattutto quando questo viene
utilizzato per ricercare un record.
la sua dimensione incide sulla velocità delle operazioni di un Database, quindi utilizzare le più piccole
dimensioni di campo adatte ai valori da memorizzare nel campo stesso. Es. numerico tipo byte o sigla
alfanumerica.
Esempio:
Completiamo lo schema precedente delle tabelle considerando anche i campi:
Studenti
Matricola
Cognome
Nome
Data_nasc
Luogo
Corso_laurea
Esami_sostenuti
Esami
Matricola
Codice_esame
Esame
Descrizione
Data_esame
Voto
Fase 4. - Definizione delle relazioni.
Come detto precedentemente una relazione consente di “correlare” o “legare” due o più tabelle. In particolare
esistono diverse tipologie di relazioni che possono essere definite tra due tabelle:
•
Relazione uno a molti
•
Relazione molti a molti
•
Relazione uno a uno
La relazione uno a molti è il tipo di relazione più frequente in un Database relazionale: in questo tipo di relazione
ad un record di una tabella A possono corrispondere più record di una tabella B, mentre ad un record di una tabella
B corrisponde un solo record della tabella A. Un esempio di relazione uno a molti è quello visto precedentemente
tra clienti ed ordini: ad un record della tabella clienti corrispondono più record della tabella ordini, mentre ad un
record della tabella ordini corrisponde un solo record della tabella cliente (l’associazione in oggetto può essere letta
come: un cliente può effettuare più ordini - più ordini sono effettuati dallo stesso cliente).
In una relazione molti a molti ad un record della tabella A possono corrispondere più record della tabella B e
viceversa ad un record della tabella B possono corrispondere più record della tabella A. Questo tipo di relazione è
possibile solo definendo una terza tabella, chiamata tabella di congiunzione, che dispone di due chiavi esterne: una
è collegata alla chiave primaria della tabella A, l’altra invece alla chiave primaria della tabella B. Una relazione
molti a molti è pertanto composta da due relazioni uno a molti con una terza tabella; quest’ultima può anche essere
composta da due soli campi (le due chiavi esterne). Un esempio è rappresentato nella figura seguente, in cui esiste
una relazione molti a molti tra la tabella studenti e quella esami (più studenti possono sostenere più esami e
viceversa), e viene realizzata inserendo una terza tabella (esami_sostenuti) che contiene le due chiavi esterne
collegate alle tabelle principali.
In una relazione uno a uno, ad un record della tabella A può corrispondere un solo record della tabella B, e
viceversa. Si tratta di relazioni poco usate nella pratica, poiché generalmente le informazioni che risiedono nelle due
tabelle possono essere fuse in un’unica tabella. Un tipico esempio di tale relazione è quella tra la “tabella marito” e
la “tabella moglie”: un “marito” può avere una sola “moglie” e viceversa (almeno per la legge italiana!), in questo
caso è possibile creare una relazione tra i campi “codice_fiscale” delle due tabelle, che saranno due chiavi primarie
all’interno delle rispettive tabelle, come mostrato in figura:
N.B. Una relazione può essere creata soltanto tra campi dello stesso tipo, non può esistere ad esempio una relazione
tra un campo di testo ed un altro di tipo numerico;
Osservazione – l’ integrità referenziale.
Quando si crea una relazione tra due tabelle può essere utile impostare l’integrità referenziale. L’integrità
referenziale, come detto precedentemente è un insieme predefinito di regole che il programma, nel nostro caso
Access, utilizza per accettarsi che la relazione sia valida e prevenire modifiche o cancellazioni accidentali dei
dati. Si ricorda che, affinché sia possibile applicare l’integrità referenziale devono essere verificate alcune
condizioni, e cioè: il campo correlato nella tabella primaria deve essere chiave primaria, i campi correlati
devono avere lo stesso tipo di dati, le tabelle devono appartenere allo stesso database.