Database

ARCHIVI DI DATI E DATABASE

Una Base di dati (o Database) è un insieme integrato di archivi che possono costruire una base comune di lavoro per utenti diversi con applicazioni diverse.

Un archivio è a sua volta un insieme organizzato di informazioni legate da un nesso logico e registrate su un supporto fisico, cartaceo o digitale che sia, sul quale è possibile scrivere e leggere le informazioni.

Le informazioni conservate in un archivio e rappresentate secondo una struttura organizzata che ne rende veloce il reperimento si chiamano dati.

Per esempio, un archivio di dati anagrafici contiene le informazioni sulle persone, con Cognome, Nome, Data di nascita, Città, Telefono.

Ognuno di questi dati si chiama campo e l’insieme dei campi di una stessa riga forma il record, che si riferisce ad una singola persona. L’archivio è quindi un insieme di record.

Le principali operazioni che si possono effettuare sul database sono:

• creazione dell’archivio sul supporto
• manipolazione delle informazioni contenute (inserimento, variazione, cancellazione)
• consultazione e interrogazione dell’archivio fornendo i risultati con visualizzazioni o stampe

Normalmente in un’azienda gli archivi necessari alla gestione sono molteplici e vengono utilizzati da più persone contemporaneamente.

Condividere gli stessi archivi tra persone diverse all’interno di un’azienda, significa creare una base di dati comune che disponga di dati sempre aggiornati su cui operare, perché le variazioni apportate da un utente sono visibili immediatamente anche dall’altro.

 

PROGETTAZIONE DEL DATABASE

La costruzione di una base di dati deve essere preceduta da una fase di progettazione per definire le caratteristiche fondamentali della realtà che si vuole automatizzare e gli obiettivi che si vogliono raggiungere. Viene dunque adottato il modello dei dati con cui procedere alla rappresentazione.

Il modello è un insieme di concetti che rappresenta formalmente la realtà da rappresentare attraverso una codifica interpretabile in modo automatizzato da un elaboratore. Il suo scopo è quello di rendere efficiente la fase progettuale, per cui i modelli utilizzati dovranno essere standardizzati e condivisibili (uniformati) e saranno accompagnati da un protocollo di progettazione che ottimizzi la creazione e l’aggiornamento del progetto.

Ci concentreremo in questa fase sui modelli

• Concettuale
• Logico
• Fisico

 

MODELLO CONCETTUALE

Osservando una realtà possiamo coglierne le entità utili per rappresentarne la gestione automatizzata. Ciò si ottiene individuando gli elementi che la caratterizzano: ad esempio in una scuola gli studenti, i docenti, le materie, le prove degli studenti, ecc.

Ciascun’entità possiede degli attributi, ovvero le proprietà che la identificano e la caratterizzano.

Per esempio, le proprietà (o attributi) dell’entità Studente sono la matricola, il cognome, il nome, la data di nascita, la classe.

L’entità Prova ha come attributi il voto, la data di svolgimento, la materia a cui si riferisce.

Tra le entità si stabiliscono inoltre delle relazioni o associazioni, cioè dei collegamenti.

Per conoscere a quale studente si riferiscono le prove fissiamo un collegamento tra l’entità Prova e l’entità Studente.

Definendo le entità, gli attributi e le relazioni si costruisce il modello concettuale della realtà osservata.

LINK ESTERNO al modello E-R

 

MODELLO LOGICO

Dal modello precedente si derivano le strutture dati adatte a contenere le informazioni relative alle entità. Viene definito così il modello logico (o relazionale), cioè l’organizzazione dell’insieme dei dati attraverso le tabelle.

Ogni entità del modello concettuale diventa una tabella. Gli attributi diventano i titoli delle colonne e andranno a formare il tracciato record, cioè l’insieme di tutti gli identificatori dei campi della tabella.

Le righe (o record) contengono i dati che si riferiscono a uno specifico esemplare (o istanza) dell’entità. Ad esempio, la prima riga della tabella Studenti rappresenta lo studente Laura Rossi.

MODELLO FISICO
Infine, il modello fisico individua il supporto fisico di memorizzazione da utilizzare per l’archiviazione dei dati (cd-rom, hard-disk,…).

La progettazione fisica coincide con l’associazione della struttura logica ad una struttura fisica per la memorizzazione di massa.

Di seguito sono rappresentati i passaggi, dall’applicazione del primo modello fino alla realizzazione del modello fisico, che caratterizzano la fase di progettazione del database.

Dal momento che la possibilità di reperire efficientemente i dati collezionati costituisce un’esigenza primaria, la struttura fisica può includere, oltre ai dati, anche gli indici.

Gli indici sono strutture costruite sui dati, in grado di ottimizzare i processi di accesso, modifica e cancellazione dei dati stessi. Risultano particolarmente utili per le tipologie di dati letti più frequentemente dagli utenti.

 

CHIAVI E INTEGRITÀ REFERENZIALE

Tutte le tabelle hanno un campo chiave primaria, costituito da un codice alfanumerico o da un numero identificativo (ID) per distinguere ciascuna riga all’interno della tabella.

La chiave primaria di una tabella è un campo del tracciato record i cui valori identificano univocamente ciascun singolo record della tabella, in modo che non possano esistere due o più record della tabella con la stessa chiave primaria.

Per stabilire poi i collegamenti tra le tabelle occorre aggiungere le chiavi esterne: La chiave esterna di una tabella è un campo del tracciato record che può ammettere valori duplicati, ma che invece è chiave primaria di un’altra tabella alla quale ci si vuole relazionare logicamente.

Nel database seguente, la tabella dei Prodotti deve contenere due campi aggiuntivi che rappresentano i collegamenti al codice della categoria e al codice del fornitore.

I record di due tabelle si mettono in relazione attraverso la coppia di campi chiave primaria/chiave esterna.

Riportiamo in basso le tabelle

• Categorie
• Prodotti
• Fornitori

sono anche esplicitati, in rosso, i collegamenti tra le tabelle, attraverso l’associazione chiave esterna-chiave primaria

Possiamo quindi definire il modello logico del database con le seguenti tabelle:

Categorie: (ID, NomeCategoria, Descrizione)

Fornitori: (CodForn, NomeSocietà, Città, Telefono)

Prodotti: (CodProdotto, NomeProdotto, Prezzo, CodFornitore, IDCategoria)

dove le chiavi primarie vengono sottolineate e le chiavi esterne sono indicate in corsivo.

Quando si mettono in relazione le tabelle, è possibile applicare all’associazione una particolare proprietà detta integrità referenziale che permette di rendere più forte il legame tra i record delle tabelle collegate.

L’integrità referenziale è una regola applicata ai valori che può assumere la chiave esterna, in modo da assicurare che i valori che questa assumerà siano sempre riferiti a quelli del campo chiave primaria in relazione. In altre parole, l’integrità referenziale impone che ogni inserimento di un valore della chiave esterna debba avere un valore corrispondente della chiave primaria associata nella relazione.

Tornando all’esempio sulle Valutazioni, ogni record della tabella Valutazioni avrà un valore del campo Matricola (chiave esterna -c.e.) in corrispondenza con un valore del campo Matricola (chiave primaria – c.p.) della tabella Studenti, in modo che non si possano avere valutazioni associate a studenti inesistenti – situazione quest’ultima inaccettabile in quanto errata.

Per questo motivo, sarà impossibile modificare il valore della c.p. della tabella Studenti (tabella primaria), o allo stesso modo eliminare un record di tale tabella, se nella tabella collegata Valutazioni (tabella secondaria) esistono righe aventi come chiave esterna valori che corrispondono a quella specifica chiave primaria.

 

RELAZIONI TRA TABELLE

Le relazioni tra tabelle, possono essere di tre tipi:

• uno a uno (o biunivoca)
• uno a molti
• molti a molti

La relazione uno a uno è detta anche biunivoca perché ad ogni elemento della prima categoria, fa corrispondere un solo, specifico, elemento della categoria collegata.

Ad esempio: a ciascun marito, corrisponde una sola e specifica moglie.

La relazione uno a molti è quella su cui ci focalizzeremo maggiormente: fa corrispondere a ciascun elemento della prima categoria, uno o più elementi della seconda categoria. Ma se osservo la relazione a partire dalla seconda categoria invece, avrò che ad ogni elemento di quest’ultima, corrisponderà un solo e specifico elemento della categoria precedente.

Ad esempio: per ogni studente possiamo avere più valutazioni (voto di Storia di novembre; voto di Matematica di ottobre; voto di Italiano di gennaio; voto di Italiano di febbraio…), mentre a ciascuna valutazione (personale), corrisponde il solo e specifico Studente che l’ha presa.

La relazione molti a molti invece fa corrispondere ad un elemento della prima categoria, tanti elementi della seconda categoria; la stessa cosa avviene osservando la relazione a partire dalla seconda categoria: a ciascun elemento della seconda categoria, fanno capo tanti elementi della prima categoria.

Ad esempio: Ogni studente ha più Docenti e ogni Docente ha più Studenti.

Poiché la relazione di tipo molti a molti è riconducibile, attraverso un artificio, ad una combinazione di relazioni uno a molti, ci focalizzeremo inizialmente sulla rappresentazione delle relazioni di quest’ultimo tipo.

 

ESEMPIO COMPLETO DI PROGETTAZIONE

Tornando all’esempio sulle valutazioni, produciamo il modello concettuale rappresentando le entità, ciascuna con la sua molteplicità, in accordo con quanto visto nel paragrafo Relazioni tra Tabelle.

Attenzione, l’attribuzione della molteplicità è molto importante perché avrà un impatto rilevante per l’attribuzione della chiave esterna alla giusta tabella durante la fase di progettazione logica.

Partiamo dunque dal modello concettuale già imbastito all’inizio di questa trattazione:

Per ciascuna entità dovrò chiedermi ad ogni istanza della classe, quante istanze della classe collegata posso avere.

Esempio:

Per ogni specifico elemento della classe Studente (ovvero per ogni singolo studente), quante valutazioni posso avere?

La risposta sarà: “un numero generico” e lo indicheremo con la notazione “1..n” che si legge “da uno a n”. Scrivo questa molteplicità sul lato dell’entità Valutazione.

A questo punto, cambio prospettiva e mi chiedo: ad ogni Valutazione, quanti studenti fanno capo?

La risposta sarà “uno”: in quanto ogni valutazione appartiene ad uno specifico studente. Segno questa numerosità riportandolo un “1” sul lato Studente.

In questo modo abbiamo appena terminato la progettazione concettuale.

Passiamo ora alla modellazione logico-relazionale, ricordando che ciascuna tabella si ottiene dalla traduzione della singola entità, già esplicitata nel modello concettuale. L’entità diventa una tabella e gli attributi dell’entità diventano i campi del tracciato record della tabella.

Teniamo presente che l’entità del modello concettuale rappresenta la categoria degli elementi di un certo tipo, quindi è una classe astratta a cui non possiamo attribuire dei valori specifici per gli attributi elencati. Le Base di Dati hanno lo scopo di collezionare e gestire i dati di tutte le istanze che appartengono alle classi caratterizzanti (ad esempio i dati anagrafici dello studente Laura Rossi, dello studente Maria Verdi e così via). Il passaggio progettuale in cui trasformiamo le entità in tabelle, è dunque fondamentale per assolvere a questo compito, in quanto fornisce finalmente una struttura adeguata al mantenimento dei dati individuali. E’ questo il motivo per cui notiamo che la tabella, rispetto all’entità del modello concettuale, acquisisce il nome della categoria  al plurale.

Una particolare attenzione va prestata ai nomi dei campi del tracciato record (Matricola, Nome, Cognome, DataNascita…) che, se inizialmente composti da più parole, dovranno essere compattati in un’unica stringa, avendo cura di mantenere il maiuscoletto per le iniziali di parola.

Ad esempio:

“Data di Nascita” oltre a perdere la preposizione, ritenuta non indispensabile per mantenere il significato dell’espressione, diventa “DataNascita”.

Riprendo dunque la stessa struttura delle tabelle già presentate all’inizio della trattazione.

È necessario esplicitare il legame logico che intercorre tra le due tabelle.

Nel modello concettuale abbiamo manifestato tale legame attraverso la linea “relazione” che congiunge graficamente le due entità; mentre nel modello logico, la relazione va mediata attraverso l’utilizzo del campo chiave esterna descritta nel paragrafo Chiavi e Integrità.

A questo punto ci potrebbe sorgere un dubbio lecito: a quale tabella aggiungo il campo chiave esterna, indispensabile per il collegamento?

Aggiungo un campo IDStudenti alla tabella Valutazioni oppure aggiungo un campo IDValutazioni alla tabella Studenti?

Nessun problema: se ho modellato correttamente le entità e le relazioni nel modello concettuale, applicherò la semplicissima regola che prevede che, nel caso di molteplicità uno a molti, il campo chiave esterna vada aggiunto alla tabella con molteplicità “a molti”, quindi all’entità del lato indicato con “1..n”, ovvero a Valutazione.

Se non mi ricordo la regola o non sono confidente di aver gestito correttamente le molteplicità, nessun problema, vado per tentativi e mi accorgerò ugualmente che l’inserimento è sostenibile in un solo caso.

Esempio:

Provo ad aggiungere la chiave esterna alla tabella Valutazioni e valuto cosa accade:

Suppongo che lo studente Laura Rossi abbia preso le valutazioni V001 e V003; che la V002 e la V004 appartengano rispettivamente agli studenti Giorgio Bianco e Luca Neri e che la studentessa Maria Verdi non abbia ancora ricevuto valutazioni.

Non mi resta che aggiungere la chiave primaria degli studenti citati a ciascuna riga della tabella Valutazioni per esplicitare il collegamento.

A questo punto il codice del singolo studente potrebbe comparire più volte nella tabella Valutazioni, pur essendo chiave, ma non è un problema perché l’identificativo dello studente risulta essere chiave primaria se presente nella tabella Studente (e quindi nella tabella Studente non può avere duplicati!), mentre è chiave esterna se presente in un’altra tabella  (ad es. nella tabella Valutazioni) e quindi può presentare lecitamente dei duplicati.

È il caso della studentessa Laura Rossi (codice 0001) che ha già conseguito due valutazioni (la V001 e la V003), per cui il suo codice comparirà correttamente in entrambe le righe della tabella Valutazioni.

A questo punto sembrerebbe corretto aggiungere la chiave esterna al fondo della tabella Valutazioni.

Ma vediamo comunque cosa sarebbe successo se avessimo tentato di aggiungere la chiave esterna alla tabella Studenti.

Proviamo!

Provo ad aggiungere la chiave esterna alla tabella Studenti e valuto cosa accade:

Ci rendiamo subito conto che esprimere eventuali molteplici voti di un singolo alunno risulterebbe quanto meno scomodo… Già solo con le prime due valutazioni conseguite durante l’anno, ci troveremmo a chiederci: “come separo le valutazioni tra di loro?” Non potrei che scegliere arbitrariamente un simbolo a caso tra la virgola, il punto e virgola, lo slash… (ma quale tra tutti?!?)

V001, V003 oppure V001; V003 oppure V001-V003 oppure V001/V003???

Niente panico! Ci viene in soccorso una regola fondamentale della progettazione dei database che ci dice che il modello relazionale ammette soltanto attributi atomici (ovvero unitari ed indivisibili), per cui non è possibile inserire i codici di più valutazioni nello stesso campo.

A questo punto posso definitivamente sancire il verdetto finale:

non è possibile aggiungere la chiave esterna alla tabella Studenti, ma va invece aggiunta alla tabella Valutazioni, come peraltro la molteplicità della relazione ci suggeriva sin dalla progettazione concettuale (essendo Valutazione l’entità sul lato “a molti”)!

Adesso abbiamo concluso anche la nostra progettazione logica, non ci resta che esplicitarla correttamente con lo schema logico e prendere il massimo punteggio nella verifica in classe.

Schema logico:

Valutazioni (ID, Voto, Data, Materia, Studente)

Studenti (Matricola, Cognome, Nome, DataNascita, Classe, Tel)

Attenzione: ricordate sempre che la chiave primaria va esplicitata, sottolineandola come nell’esempio, e che la chiave esterna, ove presente, va evidenziata con l’uso del corsivo.

Nel caso di un compito in classe su carta, l’uso del corsivo è sconsigliato, perché la scrittura manuale non permette una facile distinzione tra minuscoletto e minuscoletto corsivo per cui suggerisco agli alunni di indicare l’attributo chiave esterna con un asterisco o riportandovi accanto il semplice acronimo “c.e.”.

 

ACCESS

Adesso spostiamoci sul versante laboratoriale e proviamo ad implementare al computer una base dati funzionante sulla quale effettuare delle interrogazioni e dalla quale ricevere risposte.

A tale scopo utilizzeremo il DBMS di Microsoft Access.

 

IL DBMS

Il DBMS (DataBase Management System) è il software che consente di costruire e gestire una Base di Dati, realizzandola sulla memoria di massa, a partire dal modello logico dei dati.

I Database rispondono all’esigenza aziendale fondamentale di collezionare e gestire in modo efficientemente organizzato una mole di dati grande, condivisa e persistente.

Fino a diversi decenni fa, gli archivi venivano gestiti su supporti cartacei. Si poteva dunque correttamente parlare di sistemi informativi cartacei.

Ma che differenza intercorre tra un sistema informativo e un sistema informatico?

Il sistema informativo aziendale comprende le informazioni utilizzate durante l’esecuzione dei processi aziendali.

All’interno del sistema informativo aziendale, il sistema informatico si fa carico dell’automazione dei processi aziendali.

Il DBMS è il sistema informatico che si occupa della gestione automatizzata dei dati.

Oltre a soddisfare la primaria esigenza di gestione efficiente di grandi quantità di dati, il DBMS risponde all’esigenza non trascurabile di condivisione dei dati, garantendo al contempo privacy e controllo dell’informazione.

I soggetti che operano nel medesimo contesto aziendale necessitano di dialogare tra loro e con soggetti di altre aziende; è pertanto logico pensare che essi abbiano bisogno, in qualche caso, di reperire informazioni dalla medesima collezione di dati. La privacy e il controllo garantiscono che la condivisione dei dati avvenga solo nei tempi e nelle modalità previste dai proprietari della base di dati.

Viste

Per garantire privacy ed efficienza, dallo schema logico dell’intera base di dati possono essere estrapolati dei sottoinsiemi, denominati Viste, che descrivono una parte della realtà del contesto analizzato e sono in grado di rispondere alle esigenze dei singoli utenti o gruppi di utenti.

Per esempio quando andiamo al cinema, sul tabellone dei film in proiezione, vengono mostrate solo alcune delle informazioni relative a ciascun film (ad esempio, non vediamo il produttore perché non è un dato ritenuto di interesse per il cliente, sebbene sia un’informazione presente sul database dell’azienda di proiezione).

Autorizzazioni

Nell’ambito del controllo delle informazioni, riveste particolare importanza la gestione delle autorizzazioni, che indica l’insieme di procedure che regolano la multi-utenza, assegnando a ciascun utente un profilo sul sistema, a cui loggarsi attraverso username e password.

La profilazione degli utenti è indispensabile per fornire a ciascun utente individualmente i relativi diritti di visualizzazione e di operazioni su porzioni specifiche della base di dati.

Indici

Per rispondere all’esigenza di efficienza nelle ricerche all’interno del DB, abbiamo precedentemente introdotto gli indici, che sono un utile strumento di diffusa applicazione all’interno delle basi di dati.

Ad esempio, un’applicazione degli indici potrebbe riguardare la ricerca dei dati anagrafici di uno specifico cliente. La ricerca risulterà più rapida usufruendo di una struttura fisica che tiene traccia della collocazione su disco dei dati sui clienti disposti in ordine alfabetico.

Maschere

Le maschere consentono di visualizzare i dati, in fase di archiviazione o di consultazione, secondo un’organizzazione sullo schermo basata su esigenze pratiche.

Query

Le query sono interrogazioni effettuate dall’utente del DBMS o da applicativi esterni, su una o più tabelle.

Report

è lo strumento che consente di visualizzare e stampare i dati dell’archivio con un’organizzazione predeterminata, ad esempio mediante raggruppamenti per categorie.

 

IL LINGUAGGIO SQL

Il DBMS supporta al suo interno una serie di linguaggi che permettono di interfacciarsi con la base di dati per manipolarne ed estrapolarne le informazioni di interesse per l’utente.

I linguaggi adottati sono di tipo dichiarativo perché consentono all’utente di comunicare al DBMS le operazioni che intende svolgere sulla base dati, non curandosi di come il DBMS sceglierà tecnicamente di andare ad operare tali interventi sul DB.

L’utente si focalizza sul risultato da richiedere e il DBMS si occuperà di applicare in autonomia le procedure adeguate per conseguirlo.

SQL (Structured Query Language) è il linguaggio dichiarativo che useremo per la creazione, modifica e interrogazione di dati e tabelle relazionali.

I principali comandi SQL si suddividono in due categorie:

• relativi alla manipolazione delle tabelle e dei loro contenuti
• relativi alle interrogazioni

Riportiamo di seguito la mappa concettuale dei comandi SQL che utilizzeremo:

Torna alla Home