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: Fase 2: Fase 3: Fase 4: Fase 5: Definizione dello scopo. - Determinare quali informazioni dovranno essere memorizzate nel Database Definizione delle tabelle. - Suddividere le informazioni in argomenti distinti; ciascun argomento deve costituire una tabella del database. Definizione dei campi. - 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 Matricola Esame Data_esame Voto Esami Codice_esame Descrizione 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.