INTRODUZIONE

L'argomento trattato in questa tesi è scaturito da una esperienza personale di stage svolta presso il Consultorio Familiare della U.L.S.S. N°5 "OVEST VICENTINO" di Arzignano che ha avuto come scopo lo svolgimento di un lavoro proposto dal Dott. Mauro Gonzo, psicologo presso il suddetto Consultorio  (1).

In particolare l'obbiettivo dello stage è stata la progettazione e realizzazione di una base di dati per l'immissione e la visualizzazione dei dati raccolti tramite un questionario/intervista preparato dal dott. M. Gonzo nell'ambito del "Progetto Benessere Donna Straniera" e proposto a tutte le donne extracomunitarie che si rivolgono al Consultorio Familiare con la richiesta di interruzione volontaria di gravidanza.

Una descrizione più particolareggiata del problema e di come esso sia stato trattato è presentata nella seconda parte di questo elaborato.La prima parte illustra invece quelli che sono, più in generale, gli obbiettivi, le caratteristiche e le metodologie di progettazione di una base di dati.Nella terza ed ultima parte è presentato, con l'aiuto di alcune schermate di esempio, il software realizzato per lo scopo e le operazioni da esso svolte.

CAPITOLO 1

1. SISTEMI PER LA GESTIONE DI BASI DI DATI

Le basi di dati sono sorte verso la fine degli anni sessanta per far fronte ad una esigenza concreta: prima dell'avvento dei DBMS (Data Base Management System) infatti, i sistemi informativi (insiemi di risorse di uomini e strumenti per la raccolta, la memorizzazione, l'elaborazione e lo scambio di informazioni, nonché di regole organizzative per la gestione delle informazioni stesse) erano basati sull'uso di file separati (fig.1), una situazione in cui ciascun programma opera su file diversi e che può provocare i seguenti problemi:

• Inconsistenza e ridondanza dei dati: situazione in cui ogni programmatore definisce autonomamente i file di cui ha bisogno creando così una fonte potenziale di ridondanza (stessa informazione appartenente a più files) e di inconsistenza (la stessa informazione è aggiornata in un file ma non negli altri che la contengono), e comunque uno spreco di memoria.
• Problemi di privatezza: in una applicazione gestionale è necessario proteggere ciascun campo in modo differenziato: ad esempio, considerando la gestione dei conti correnti di una banca, vi saranno programmi abilitati a fare variazioni anagrafiche, altri ad aggiornare l'ammontare dei risparmi sul conto.
• Problemi di integrità: l'integrità di un insieme di dati può essere specificata tramite un opportuno insieme di regole, dette vincoli di consistenza. Verificare questi vincoli separatamente su ciascun file è possibile ma è reso molto difficile dalla replicazione dell'informazione e l'assenza di un meccanismo globale di controllo.
• Problemi di concorrenza: in uno stesso istante possono essere attivi vari programmi che operano su uno stesso file accedendo ai suoi dati. Se due programmi leggono uno stesso valore iniziale e lo modificano contemporaneamente, solo l'ultima operazione di modifica sarà registrata, con il risultato che un'operazione di scrittura sarà andata persa. Programmi ad accesso concorrente devono operare sotto vincoli di mutua esclusione.

I DBMS nascono per ovviare alle difficoltà esposte in precedenza, in maniera tale che tutte le azioni siano svolte sotto il controllo di un programma specificatamente progettato per gestire dati (fig.2).

Un DBMS ha infatti il controllo sull'intero insieme di dati che caratterizzano un particolare ambiente applicativo evitando così la ridondanza e l'inconsistenza, disciplina l'accesso alla base di dati con modalità di utilizzo definite per ciascun utente, dà la possibilità di definire regole per la correttezza verificate automaticamente ed esegue operazioni che permettono la mutua esclusione dei programmi contemporaneamente attivi.

1. LIVELLI DI ASTRAZIONE IN UNA BASI DI DATI

Un DBMS fornisce ai suoi utilizzatori una visione astratta della base di dati. In particolare si possono distinguere tre livelli di astrazione:

• Livello fisico: considera la base di dati come un insieme di registrazioni in memoria di massa, in particolare descrive la distribuzione dei dati sui vari supporti e le modalità di memorizzazione dei dati.
• Livello logico: presenta i dati i modo da evidenziare la loro struttura logica, cioè l'informazione posseduta da ciascun dato e come i dati si collegano tra di loro. E' detto anche livello globale perché vi vengono descritti tutti i dati della base di dati.
• Livello esterno: è il livello di massima astrazione, presenta i dati così come vogliono (o possono) essere visti da una particolare classe di utenti. Vi sono tante diverse rappresentazioni, ciascuna associata ad un particolare utilizzatore.

I tre livelli di rappresentazione consentono di introdurre i concetti di indipendenza fisica e logica dei dati:

• Indipendenza fisica: consiste nella possibilità di ridefinire il livello fisico senza modificare il livello logico, e quindi senza alterare i programmi degli utenti.
• Indipendenza logica: consiste nella possibilità di definire nuovi schemi esterni o estendere lo schema logico senza alterare gli schemi esterni preesistenti.

1. LINGUAGGI IN UNA BASE DI DATI

I linguaggi messi a disposizione da un DBMS servono essenzialmente a due scopi distinti: definire la base di dati e manipolarla per ottenere informazioni da essa, pertanto prendono il nome di Data Definition Language (DDL) e Data Manipulation Language (DML).

• DDL: è utilizzato dal gestore della base di dati per la definizione centralizzata della stessa. Le definizioni dello schema sono memorizzate in una base di dati speciale detta Dizionario dei dati. Opera su ciascuno dei tre i livelli.
• DML: è utilizzato dagli altri utenti della base di dati per estrarre informazioni da questa o modificarne il contenuto tramite inserimento di nuovi dati, cancellazione o modifica di dati preesistenti.

1. AMMINISTRATORE DI UNA BASE DI DATI

E' una figura particolare che ha il compito di determinare quella struttura che consente di svolgere tutte le operazioni sui dati con prestazioni adeguate. In particolare l'amministratore deve:

• definire la struttura logica dei dati: cioè determinare i dati che devono far parte dello schema logico, e le loro interrelazioni.
• definire la struttura fisica dei dati: determinare il modo migliore di disporre i dati in memoria.
• definire i diritti di accesso: cioè decidere chi può accedere alla base di dati e con quali modalità.
• specificare i vincoli di integrità che distinguono una base di dati corretta da una scorretta.
• gestire l'affidabilità del sistema: una base di dati deve garantire la correttezza anche a fronte di malfunzionamenti possibili come la caduta di corrente o la distruzione di un dispositivo, ecc.

1. UTENTI DI UNA BASE DI DATI

Vi sono diversi tipi di utenti di una base di dati, ciò che li distingue è il diverso modo di interagire con essa. In particolare abbiamo le seguenti classi di utenza:

• utente non programmatore: è colui che interagisce con la base di dati nel modo più semplice possibile.
• terminalista: non interagisce con un linguaggio di programmazione, ma con un insieme di procedure predisposte per lui. Un esempio di utente terminalista può essere un funzionario addetto alla gestione dei clienti allo sportello della banca.
• programmatore applicativo: è colui che scrive le transazioni e le rende disponibili agli utenti, ma non può cambiare la struttura dei dati.
• utente avanzato: accede direttamente alla base di dati utilizzando il DML per svolgere interrogazioni non preventivate ed estemporanee.

1. STRUTTURA SOFTWARE DI UNA BASE DI DATI

E' possibile ora individuare le componenti software che compongono il DBMS.

I dati memorizzati in memoria di massa sono di tre tipi:

• dati veri e propri.
• dati che memorizzano informazioni sulle modalità di accesso ai dati veri e propri.
• il Dizionario dei dati che descrive l'organizzazione della base di dati.

Le componenti funzionali che si trovano all'interno del DBMS sono:

• gestore della memoria fisica: per l'allocazione dei dati nella memoria di massa e la definizione delle modalità di acesso.
• gestore degli accessi: traduce le operazioni elementari di accesso ai dati in chiamate alle procedure del gestore della memoria fisica.
• processore di interrogazioni: traduce istruzioni del DML in operazioni elementari sui dati.
• pre-compilatore del linguaggio ospite: analizza un modulo di programma applicativo per estrarre le istruzioni DML.
• gestore di transazioni: riceve dai terminalisti richieste di attivazione di transazioni, e le attiva in conseguenza.
• compilatore delle definizioni dei dati: riceve istruzioni in DDL e genera il Dizionario dei dati.
• interfaccia utenti: consente ad un utente casuale di sottoporre interrogazioni, scritte in un opportuno linguaggio DML.

2. MODELLI PER LA GESTIONE DEI DATI

2.1 TIPI DI MODELLI DEI DATI

Un modello dei dati è definito come una collezione di concetti atti a rappresentare la realtà. Si distinguono due categorie di modelli di dati:

• modelli concettuali: sono modelli di dati dotati di un gran numero di costrutti, che mettono in evidenza i concetti presenti in una base di dati, piuttosto che la struttura con cui tali concetti possono essere rappresentati nella memoria del calcolatore. Il loro utilizzo avviene per questo motivo durante la fase di progettazione della base di dati. Il più famoso modello concettuale dei dati è il modello entità-relazione.
• modelli logici: i principali modelli logici sono:

1) modello relazionale: inventato da Codd nel 1970, è basato sul concetto di insieme e gran parte dei DBMS di nuova concezione sono di questo tipo.

2) modello gerarchico: è basato sulle strutture ad albero, ovvero sulle strutture dati gerarchiche ed ha caratterizzato i primi DBMS sviluppati verso la metà degli anni sessanta.

3) modello reticolare: è detto anche modello a rete o modello Codasyl, ideato nel 1973 e perfezionato nel 1978 il modello reticolare è basato sulle strutture dati a reticolo.

2.2 MODELLO CONCETTUALE

Un modello concettuale utilizza costrutti astratti per rappresentare una particolare realtà di interesse la cui descrizione prende il nome di schema concettuale.

Per ciò che riguarda i dati, nello schema vengono solitamente rappresentate le classi di dati di interesse dell'applicazione che sono descritte con un ricco insieme di strutture di rappresentazione, cioè un insieme di strutture linguistiche tramite le quali si descrive il frammento di realtà che si desidera gestire tramite la base di dati.

Accanto alle classi di dati devono essere rappresentate nello schema anche le proprietà (vincoli di integrità) che devono sempre essere valide per tali classi.

Una caratteristica comune dei modelli concettuali è la presenza nelle strutture di rappresentazione di meccanismi linguistici per descrivere astrazioni, cioè procedimenti mentali che permettono di evidenziare alcune proprietà significative degli oggetti osservati, escludendone altre non rilevanti.

Comuni esempi di astrazione sono:

• astrazione di classificazione: è il procedimento mentale mediante il quale a partire, ad esempio, dalle singole persone e considerando le proprietà che le accomunano si giunge al concetto di persona, quindi in generale si definisce una classe che rappresenta un insieme di altri oggetti.
• astrazione di aggregazione: mediante questo procedimento si può giungere alla definizione di una classe come astrazione di un insieme di parti componenti o proprietà, ad esempio aggregando le classi nome, cognome, sesso, età posso giungere alla definizione della classe persona.
• astrazione di generalizzazione: definisce una classe come unione di due o più insiemi, ognuno dei quali è una sottoclasse della classe data, ad esempio, le classi uomo e donna possono essere generalizzate tramite la definizione della classe persona.

Un modello concettuale, in quanto rappresentazione astratta e di facile comprensione della realtà dei dati di interesse, può essere utilizzato come linguaggio comune comprensibile sia dal progettista della base di dati che dall'utente, creando così la possibilità di una migliore collaborazione.

L'utilità dei modelli concettuali è data anche dalla possibilità di rappresentare, in maniera indipendente dai diversi linguaggi utilizzati per la realizzazione della base di dati, il contenuto informativo della stessa, e dalla maggiore facilità di modificare l'applicazione, nel caso le esigenze dei suoi utilizzatori cambiassero, o eventualmente anche il linguaggio di programmazione.

2.2.1 Il modello concettuale ENTITA'-RELAZIONE

Il modello entità-relazione adotta per i concetti la seguente rappresentazione grafica:

Una entità rappresenta una classe di oggetti del mondo reale (istanze) aventi proprietà omogenee ai fini dell'applicazione. Queste proprietà, nel caso non siano ulteriormente scomponibili in proprietà più atomiche, vengono chiamate attributi semplici dell'entità, e l'insieme dei valori assumibili da ogni attributo è detto dominio.

Un attributo può essere costituito da aggregazioni di attributi semplici, ed in questo caso prende il nome di attributo composto.

Le relazioni possono essere definite come classi di fatti significative ai fini dell'applicazione in quanto creano una corrispondenza tra istanze di due o più entità.

Una relazione può essere definita fra due o più entità (si pensi, ad esempio, alla relazione < risiede a > che lega le entità Persona e Città) o anche su una sola (come potrebbe essere la relazione < genitore di > che collega le istanze dell'entità Persona).

Una astrazione di generalizzazione che mette in relazione un insieme di entità (entità figlie) con una nuova entità (entità padre) è detta appunto generalizzazione. Ogni proprietà (attributi, relazioni e generalizzazioni) della entità padre è anche proprietà delle entità figlie.

Quando una generalizzazione avviene fra una entità padre ed una sola entità figlia siamo nell'ambito di una caso particolare che prende il nome di sottoinsieme.

L'insieme di regole che gli oggetti del modello concettuale devono rispettare per la correttezza della base di dati sono i vincolo di integrità: un tipo di vincolo è rappresentato dalle cardinalità massime e minime cioè il numero (rispettivamente massimo e minimo) di volte che ogni occorrenza (istanza) della entità può essere coinvolta in una occorrenza della relazione.

Un altro tipo di vincolo è l'identificabilità: un identificatore di una entità è definibile come l'insieme degli attributi ed entità di uno schema che identificano univocamente ogni occorrenza della entità stessa.

2.3 IL MODELLO LOGICO RELAZIONALE

Il modello relazionale ha fatto la sua comparsa nel mondo dei DBMS commerciali solo agli inizi degli anni ottanta, con lo scopo di affrontare e superare gli aspetti critici che avevano evidenziato i modelli gerarchico e reticolare, come la necessità di personale veramente esperto per progettare basi di dati efficienti, la rigidità del sistema informatico ed i conseguentemente elevati costi di modifica e la dipendenza delle applicazioni dai percorsi di accesso.

Un altro importante motivo che ha portato allo sviluppo del modello relazionale è la possibilità di descrivere i dati tramite una struttura semplice, raggiungendo un buon grado di indipendenza tra i programmi e la rappresentazione fisica.

Questo tipo di modello logico basa la sua forza sul fatto di muoversi in ambito prettamente matematico, svincolato da considerazioni di carattere fisico e senza alcuna gerarchia di partenza.

2.3.1 Il concetto di relazione

I concetti che stanno alla base del modello relazionale sono quelli di relazione e tabella; in particolare si definisce relazione R su una sequenza D1,D2,…,Dn di insiemi, un sottoinsieme finito del prodotto cartesiano D1xD2x…xDn.

In maniera più semplice si può identificare una relazione con una tabella bidimensionale, che può descrivere una entità, che ha come colonne i domini (D1,D2,…,Dn), a ciascuno dei quali è associato un attributo, cioè un nome, che lo identifica univocamente.

Il numero di domini definisce il grado della relazione e la relazione è caratterizzata da un nome e dall'elenco dei suoi attributi, che costituiscono lo schema della relazione.

Un esempio di rappresentazione di una relazione è il seguente:

La prima riga della tabella costituisce l'intensione o interpretazione, le rimanenti sono le estensioni o istanze della relazione.

 

2.3.2 Chiave della relazione

Quando un singolo attributo della relazione concorre alla determinazione univoca di una istanza della relazione stessa diremo che esso è chiave, mentre se lo stesso concorre solamente alla descrizione dell'entità di interesse diremo che è un attributo non chiave. Una chiave della relazione è quindi definita come un insieme non vuoto di attributi elementari che gode delle seguenti proprietà:

• univocità: per ogni valore della chiave si individua una sola istanza della relazione.
• non ridondanza: l'univocità non è più garantita se eliminiamo anche un solo elemento della chiave.

2.3.3 Relazioni in forma normale

• 1^A forma normale: una relazione si dice in prima forma normale quando tutti i suoi attributi sono elementari e sono tutti identificati dalla chiave.
• 2^A forma normale: una relazione è in seconda forma normale quando tutti gli attributi dipendono funzionalmente e in modo completo dalla chiave, cioè il valore di tutti gli attributi della chiave determina univocamente il valore di ogni attributo non chiave.
• 3^A forma normale: una relazione è in terza forma normale quando è in seconda forma normale e non esistono dipendenze transitive fra attributi chiave e non chiave, cioè ogni attributo non chiave dipende direttamente dalla chiave.
• 4^A forma normale: una relazione è in quarta forma normale se è in terza forma normale e nessun sottoinsieme della chiave ne multidetermina un altro; in altre parole non devono esistere uno o più attributi della chiave che per ogni valore assunto "vedano" tutte le possibili determinazioni di altri due o più attributi.

La normalizzazione delle relazioni viene fatta allo scopo di ottenere strutture dei dati che siano non ridondanti e non soggette ad anomalie conseguenti ad azioni sui dati. In particolare le anomalie si possono verificare:

3. PROGETTAZIONE DI UNA BASE DI DATI

3.1 DATI DI INGRESSO E PRODOTTI DI USCITA

Per poter svolgere l'attività di progettazione di una base di dati è necessario specificare i seguenti dati di ingresso:

• specifiche sui dati: è una descrizione della realtà di interesse che esprime gli aspetti di essa che vogliamo rappresentare nella applicazione.
• specifiche sulle operazioni: è una descrizione delle operazioni principali che si vorranno effettuare sulla base di dati.
• sistema di gestione di basi di dati scelto: caratteristiche del linguaggio per la descrizione dei dati e delle operazioni.
• previsioni sul carico applicativo: previsioni sulla quantità di dati che si vuole memorizzare nella base di dati e sulla frequenza delle varie operazioni.

Alla fine dell'attività di progettazione avremo i seguenti prodotti di uscita:

• descrizione dello schema logico e schema fisico nel linguaggio per la descrizione dei dati.
• descrizione delle operazioni nel linguaggio per la descrizione delle operazioni.

 3.2 FASI DELLA PROGETTAZIONE

Ciò che la progettazione della base di dati deve garantire è una rappresentazione completa e corretta della realtà di interesse ed una rappresentazione efficiente della base di dati stessa tramite le strutture del sistema di gestione scelto.

Una metodologia di progetto adatta allo scopo è suddivisa in tre fasi:

• Progettazione concettuale: lo scopo di questa prima fase è la traduzione delle specifiche della realtà di interesse in termini di una descrizione formale, completa, integrata e indipendente dalla rappresentazione scelta per il sistema di gestione della base di dati.
• Progettazione logica: in questa fase si traduce lo schema concettuale nei termini delle strutture di rappresentazione proprie del sistema di gestione scelto, cioè del modello logico. Lo schema logico deve assicurare la maggiore efficienza rispetto alla esecuzione delle operazioni di aggiornamento ed interrogazione.
• Progettazione fisica: lo schema logico viene completato con la specifica dei parametri fisici di memorizzazione e di ricerca dei dati. In questa fase si terrà conto dell'ambiente hardware e software in cui le applicazioni dovranno operare.

3.3 PROGETTAZIONE CONCETTUALE

3.3.1 Strategie di progettazione

Le strategie che si possono utilizzare per ottenere una rappresentazione di un insieme di specifiche di una applicazione tramite uno schema concettuale sono le seguenti:

• Strategia top-down: produce lo schema finale attraverso una serie di raffinamenti successivi, partendo da uno schema iniziale costituito da pochi concetti molto astratti, e raffinando via via lo schema con trasformazioni atte ad aumentare progressivamente il grado di dettaglio nella rappresentazione della realtà di interesse.
• Strategia bottom-up: la descrizione della realtà di interesse viene suddivisa in frammenti via via più piccoli, fin quando ogni frammento descrive una parte delle specifiche di dimensioni ridotte. A questo punto ogni parte delle specifiche è rappresentata per mezzo di un semplice schema concettuale e si procederà quindi a fondere questi schemi fino ad ottenere lo schema finale.

La strategia top-down ha il vantaggio di lavorare per raffinamenti sempre sull'insieme delle specifiche considerato nella sua globalità, ma è di difficile applicazione in molte situazioni reali. La strategia bottom-up è caratterizzata da una maggiore semplicità di applicazione ma necessita di possibili frequenti ristrutturazioni e revisioni di scelte fatte in precedenza.

Potrebbe di conseguenza essere spesso opportuna una metodologia mista di progetto che segua ove possibile un approccio di tipo top-down e che comunque, anche in caso di utilizzo di una strategia bottom-up, cerchi di mantenere una visione unitaria dello schema.

2. Le qualità di uno schema concettuale

Una metodologia di progettazione concettuale deve garantire il raggiungimento di uno schema di elevata qualità. In particolare le qualità di uno schema concettuale sono:

• Completezza: lo schema rappresenta tutte i dati della realtà di interesse, e tutte le operazioni descritte nei requisiti possono essere realizzate a partire dai dati presenti nello schema.
• Correttezza: lo schema utilizza in maniera propria i concetti del modello Entità-Relazione per rappresentare i requisiti.
• Leggibilità: lo schema rappresenta i requisiti in modo comprensibile e può essere quindi capito senza ulteriori spiegazioni.
• Minimalità: ogni aspetto dei requisiti appare una sola volta nello schema quindi nessun concetto può essere eliminato dallo schema senza alterarne il contenuto informativo.

2. Metodologia di progetto concettuale

Una metodologia complessiva per la progettazione concettuale può essere la seguente:

1. Analisi dei requisiti: gli scopi di questa prima fase sono eliminare le ambiguità presenti nei requisiti e dar loro una struttura, raccogliendoli in insiemi che fanno riferimento omogeneamente agli stessi concetti.
2. Progettazione iniziale: si crea un primo schema scheletro, cioè uno schema che contenga i concetti più importanti della applicazione.
3. Progettazione iterativa: si applicano allo schema tutte le trasformazioni utili per poter progredire nel lavoro di modellazione.
4. Analisi di qualità: si verifica periodicamente la bontà delle scelte fatte in precedenza, analizzando il grado di raggiungimento delle qualità descritte al punto 3.3.2.

3.4 PROGETTAZIONE LOGICA

Lo scopo della progettazione logica è quello di tradurre lo schema concettuale in uno schema che sia coerente con il modello logico adottato dal sistema di gestione di basi di dati scelto, in modo da ottimizzare quanto possibile gli indici di prestazione del progetto

Una metodologia generale di progettazione logica può essere suddivisa in due passi: il primo è la fase di ristrutturazione dello schema concettuale che da' luogo ad uno schema concettuale semplificato che utilizza solo concetti "vicini" ai modelli logici.

Il secondo passo produce una traduzione e una definitiva ottimizzazione nel modello logico scelto.

1. La fase di ristrutturazione

Questa fase avviene direttamente nel modello Entità-Relazione e si compone a sua volta di cinque fasi:

• analisi dei dati ridondanti e decisione sulla eventuale eliminazione.
• traduzione di generalizzazioni e sottoinsiemi in strutture più "vicine" ai modelli logici
• partizionamento delle entità in base a criteri basati sulla ottimizzazione degli accessi.
• aggregazione di entità e relazione sempre in base ai criteri di cui sopra.
• scelta degli identificatori principali.

1. La fase di traduzione e ottimizzazione

Considerando come modello logico scelto quello relazionale, una volta terminata la prima fase ciò che resta da fare è rappresentare le entità e le er-relazioni per mezzo dell'unico concetto di r-relazione, seguendo alcune regole generali che prevedono che ogni entità sia tradotta in r-relazione, mentre le er-relazioni che le collegano siano tradotte o meno in nuove r-relazioni a seconda delle circostanze.

4. PROGETTAZIONE FISICA