Eprogram informatica
V anno
Basi di dati
Il sistema EDP
In un’azienda il sistema informativo viene gestito utilizzando strumenti
informatici.
Questo sistema prende il nome di EDP (Electronic Data Processing) e
può essere visto come un insieme di dati memorizzati su supporti
elettronici e di applicazioni informatiche utilizzate per agevolare il
raggiungimento degli obiettivi di un’azienda.
Applicazione informatica
Per applicazione informatica si intende una componente del sistema
informativo (SI) che utilizza dati in esso immagazzinati per compiere una
funzione specifica all’interno dell’organizzazione a cui il SI appartiene.
OGNI applicazione del SI opera su un insieme di dati memorizzati
secondo una struttura definita all’interno dell’applicazione stessa
dall’analista.
L’analista ha il compito di realizzare l’applicazione in modo da rendere
massima la sua efficienza, indipendentemente dalle altre applicazioni.
In un sistema EDP ogni applicazione opera in modo del tutto
indipendente (o quasi) dalle altre applicazioni, facendo uso dei propri
dati e dei propri programmi.
File system
Lo strumento utilizzato per la gestione e la memorizzazione dei dati è
il file system.
Il file system è la parte del sistema operativo che si occupa della
definizione e gestione dei file immagazzinati sulla memoria di massa.
Problematiche legate alle applicazioni
Le applicazioni nel sistema EDP presentano alcune problematiche:
- risultano isolate dalle altre dello stesso sistema informativo, un
problema quando è necessaria la condivisione di dati.
- i dati vengono ripetuti tante volte quante sono le applicazioni che
devono usarli, con conseguente spreco di memoria e con il rischio di
introdurre inconsistenze ed errori.
- l’accesso ai dati può avvenire solo tramite le applicazioni. Se c’è
necessità di ottenere risultati diversi da quelli previsti dall’applicazione,
occorre realizzare i programmi specifici.
- stretto legame tra livello logico (cosa si vuole fare in un’applicazione)
e fisico (come sono memorizzati e gestiti i dati) con conseguenti
difficoltà, lunghezza e costo nella modifica delle applicazioni anche a
fronte di variazioni lievi.
Contenitore di dati unico, le basi di dati
Da questi problemi nasce l’idea di un unico contenitore di dati, che
garantisca:
- accessi multipli
- diversità di linguaggi
- privatezza
- integrità
- consistenza
- accessibilità
- modificabilità
- correttezza
Questi obiettivi non possono essere raggiunti tramite gli strumenti
convenzionali: nasce quindi l’esigenza di nuovi strumenti, quali le
basi di dati.
Basi di dati
Una base di dati può essere definita come una collezione di dati
strutturati, progettati per essere usati in applicazioni differenti e da
differenti utenti.
In particolare, è un insieme di dati memorizzati senza ridondanze inutili
per servire più di un’applicazione in contemporanea e organizzati in
modo da essere indipendenti dai programmi che li usano.
Basi di dati e DBMS
Per la gestione delle basi di dati sono necessari particolari sistemi
software, chiamati DBMS (Data Base Management System).
I DMBS si occupano della memorizzazione, dell’organizzazione e della
gestione dei dati.
Un DBMS si colloca tra i programmi
applicativi e i file dove sono
memorizzati i dati e si occupa di gestirli
su richiesta dei programmi.
Come opera un DBMS
In figura viene evidenziato il
modello di funzionamento
di un sistema con DMBS.
Gli utenti accedono ai
programmi tramite
interfacce.
I programmi che hanno
bisogno di dati li richiedono
al DBMS che li preleva dalla
base di dati tramite file
system del S.O. restituendoli
ai programmi richiedenti.
Ridondanze
Per ridondanza si intende sia la duplicazione del dato, sia la
memorizzazione di un dato che deriva dall’elaborazione di altri.
Tuttavia, se la richiesta su un dato che risulta ridondante viene fatta
spesso, può essere conveniente memorizzare questo dato (ridondanza
utile).
Una ridondanza utile comporta un costo maggiore, sia per l’occupazione
di memoria sia per la sua gestione, ma vengono velocizzate le richieste.
È il responsabile della base di dati (DBA, DataBase Administrator) che
deve decidere se inserire o no le ridondanze utili per garantire la
massima efficienza della base di dati.
Inconsistenze
Si parla di inconsistenza quando due dati che rappresentano la stessa
informazione assumono valori diversi.
Se una dato è memorizzato in due file differenti può capitare che
un’eventuale modifica sia apportata a un solo file, in questo caso si ha
un’inconsistenza perchè si hanno due valori diversi per lo stesso dato.
Dal momento che la base di dati riduce le ridondanze, il cambiamento
del valore di un dato viene immediatamente reso disponibile a tutti gli
utenti, cioè non possono esistere dati uguali con differenti valori.
Integrità dei dati
Il DBMS si occupa di controllare che l’inserimento di nuovi dati o la
cancellazione di quelli già esistenti non alteri la congruenza della base di
dati.
Si parla cioè di integrità dei dati che vengono protetti da accidentali o
voluti cambiamenti che risultino non corretti o non autorizzati.
I livelli dei dati
In un DBMS i dati si possono descrivere a livelli diversi.
Questa possibilità permette di liberare il progettista della base di dati e il
programmatore delle applicazioni dalla preoccupazione di come i dati sono
fisicamente organizzati in memoria, concentrandosi sul loro significato
piuttosto che sulla loro organizzazione fisica.
Nell’organizzazione delle basi di dati si evidenziano tre livelli di astrazione:
- esterno
- logico
- interno
Attraverso questi livelli il DBMS può nascondere la reale organizzazione dei
dati nei supporti di memorizzazione.
Il modello ANSI/SPARC
Tutto ciò è ottenuto grazie a una particolare architettura che è stata
formalizzata da un organismo di standardizzazione (ANSI/SPARC).
Ai tre livelli di astrazione corrispondono altrettanti schemi di
rappresentazione dei dati:
- Sottoschemi o viste: livello esterno in cui differenti utenti possono avere
differenti visioni degli stessi dati a seconda dell’uso che devono farne.
- Schema logico: rappresenta la visione complessiva del database.
- Schema fisico: si pone al livello interno e descrive come sono organizzati
fisicamente i dati sui supporti di memoria di massa.
Indipendenza logica
Per indipendenza logica si intende la possibilità di modificare lo schema
logico senza dover modificare i programmi che usano le singole applicazioni.
Tale indipendenza viene realizzata tramite il concetto di sottoschema o
vista (view).
Indipendenza fisica
Per indipendenza fisica si intende la possibilità di modificare
l’organizzazione fisica dei dati senza dover modificare l’organizzazione
logico-concettuale.
L’indipendenza fisica si basa sul concetto che né lo schema né il
sottoschema rispecchiano il modo in cui i dati sono effettivamente
memorizzati nella memoria secondaria del sistema.
Indipendenza logica e fisica
Come opera il DBMS
Il DBMS gestisce i passaggi tra i vari modi di vedere i dati appoggiandosi sul SO.
Cosa succede quando un’applicazione necessita di un dato memorizzato nella
base di dati?
1. Un’applicazione richiede un’entità al DBMS definendone alcune caratteristiche.
2. Utilizzando il sottoschema corrispondente all’applicazione in questione (modello
esterno) il DBMS individua la corrispondenza tra l’entità richiesta e quella definita
nello schema logico (corrispondenza esterno/logica).
3. Il DBMS, tramite lo schema fisico individua dove il dato è fisicamente
memorizzato (file) e i metodi per accedervi (corrispondenza logica/interna).
4. Il DBMS richiede al SO di prelevare il dato in questione dal file (o dai files).
5. Il SO restituisce, in un’apposita area, il record prelevato dal DBMS.
6. Il DBMS effettua le opportune trasformazioni del record reperito per renderlo
compatibile con il modello esterno.
7. Il DBMS restituisce il record all’applicazione richiedente.
Rappresentazione operazioni DBMS
Linguaggi e utenti
Per poter gestire le basi di dati tramite il DBMS sono stati introdotti alcuni
linguaggi specifici:
- DDL (Oracle, DB2, MySQL, Access)
- DML (SQL)
Data Definition Language
Per la definizione dello schema logico si usano i linguaggi DDL (Data
Definition Language), che consentono di definire i tipi di entità presenti
nello schema concettuale e le loro relazioni.
Un DDL è in genere un linguaggio a se stante con sintassi e semantica
proprie, ed è indipendente dalle applicazioni.
Il DDL serve anche a definire le viste e alcuni parametri qualitativi e
quantità delle strutture fisiche di memorizzazione della base di dati.
Ecco un esempio di come si
può creare una tabella
usando DDL:
Interfaccia grafica DDL
I principali DBMS (Oracle, DB2, MySQL, Access) forniscono anche
ambienti grafici per amministrazione di sistema e definizione tabelle:
QuickTime™ e un
decompressore
sono necessari per visualizzare quest'immagine.
Data Manipulation Language
Per la modifica, il reperimento, l’inserimento e la cancellazione dei dati si
usano i linguaggi di manipolazione dei dati (DML, Data Manipulation
Language).
I DML hanno lo scopo di fornire all’utente uno strumento per interrogare e
modificare le informazioni contenute nella base di dati.
Un DML può essere un linguaggio a se stante o un’estensione del
linguaggio ospite.
Nel primo caso siamo di fronte a un vero e proprio linguaggio di
programmazione.
DML procedurali e non
I DML, vengono distinti in:
• procedurali (o navigazionali) quando hanno gli operatori per trattare i
singoli record;
• non procedurali (o dichiarativi) quando gli operatori sono indipendenti
dal concetto di posizione, cioè considerano i dati collettivamente. Non si
deve indicare la procedura da seguire (algoritmo) ma l’obiettivo da
raggiungere.
Query language
Un particolare tipo di linguaggio di manipolazione è il query language.
Si tratta di un linguaggio di tipo interattivo per l’interrogazione e la
modifica della base di dati.
È stato ideato principalmente per risolvere il problema degli utenti
occasionali che, pur non avendo conoscenze di programmazione,
possono così interrogare la base di dati senza dover scrivere programmi
in un linguaggio complesso.
I sistemi attuali vanno sempre più nella direzione di dotarsi di strumenti
grafici per agevolare l’attività di interfacciamento con l’utente.
Query language testuale e grafico
Di seguito è mostrato un esempio in cui si richiede di reperire alcune
informazioni della tabella Prodotti
utilizzando uno di questi linguaggi (SQL):
e come la stessa richiesta
(query) possa venire
formulata tramite un query
language grafico:
QuickTime™ e un
decompressore
sono necessari per visualizzare quest'immagine.
Gli utenti
In base alle modalità di uso della base di dati possiamo individuare
alcune categorie di utenti:
- DBA (Data Base Administrator)
- programmatori
- utenti finali
Data Base Administrator
Il DBA (Data Base Administrator) è il responsabile del sistema per quanto
riguarda la gestione dello schema e dei sottoschemi e per
l’organizzazione fisica dei dati.
Ha il compito di:
• creare inizialmente e mantenere lo schema logico;
• definire e mantenere lo schema interno;
• definire e aggiornare i diritti di accesso;
• ripristinare la base di dati in caso di malfunzionamento.
I programmatori
I programmatori sono coloro che realizzano le applicazioni utilizzando
un DML o particolari linguaggi di programmazione.
Utenti finali
Gli utenti finali possono essere di tre tipi:
- occasionali, accedono alla base di dati occasionalmente e, non avendo
conoscenze informatiche, hanno bisogno di interfacce amichevoli per
interrogare la base di dati. Usano generalmente i query language.
- frequenti, pur non avendo conoscenze informatiche, accedono alla
base di dati spesso e quindi hanno dimestichezza con un particolare
sistema.
- inconsapevoli, sono coloro che utilizzano una particolare applicazione
senza necessariamente sapere che questa è basata su una base di dati.
Rappresentare la realtà
La necessità che porta alla costruzione delle basi di dati è quella di
rappresentare la realtà attraverso un insieme di entità e di relazioni
esistenti tra di loro.
Tutta la gestione delle basi di dati dipende da come queste sono
rappresentate: gli stessi linguaggi dipendono in modo strettissimo dallo
schema su cui devono operare.
Archi delle associazioni
I modelli dei dati utilizzati per descrivere lo schema possono essere
classificati in base al modo in cui vengono rappresentate e trattate le
associazioni, in particolare nel modo diverso in cui vengono gestiti gli
archi delle associazioni nella rappresentazione grafica dello schema.
L’arco si dice informativo se senza la sua presenza fisica non è
possibile collegare le due entità.
Si parla invece di archi non informativi se il collegamento è di tipo
logico, e quindi anche senza la sua presenza fisica è possibile collegare
le due entità (tramite l’uguaglianza di due attributi).
Arco informativo e non informativo
Classificazione dei modelli
I modelli che utilizzano archi informativi sono detti modelli a grafo, e
possono essere a loro volta suddivisi in modello gerarchico e modello
reticolare.
L’uso di archi non informativi è caratteristico invece del modello
relazionale.
Un discorso a parte va invece fatto per il modello Object-Oriented.
Modelli a grafo
Nei modelli a grafo le relazioni sono implementate tramite puntatori
(indirizzi fisici) che indicano quale istanza di entità è connessa a quella
considerata. Nella relazione è individuato SEMPRE un proprietario
(padre, owner) e un posseduto (figlio, member).
Modello gerarchico
Nei modelli gerarchici lo schema è rappresentato da una struttura ad
albero, cioè da un grafo privo di cicli.
L’albero, detto albero di definizione, ha un’organizzazione tipicamente
gerarchica: ciascun nodo rappresenta una classe di entità e ciascun
arco una relazione che può essere di tipo uno a molti (1:N) o uno a uno
(1:1).
Ogni nodo ha un solo genitore
mentre un padre può avere
più figli.
Ogni entità figlio può essere
collegata a elementi di un’altra
entità figlio solo passando dall’entità
superiore.
Modello gerarchico
Una base di dati gerarchica è costituita da un insieme di alberi, uno per
ogni occorrenza del nodo radice.
NON si possono rappresentare relazioni N:N a meno di spreco di spazio
e costruzione di strutture pesanti.
Per reperire informazioni è necessario percorrere l’albero dalla radice.
Linguaggi procedurali dei DBMS gerarchici
I DBMS gerarchici sono dotati di linguaggi procedurali e la sintassi
dei comandi è strettamente dipendente dal tipo di spostamenti che si
vuole richiedere dal momento che si può navigare nello schema solo
gerarchicamente.
Ricordiamo che per linguaggio procedurale si intende un linguaggio in
cui è necessario descrivere tutti i passi necessari per poter reperire
l’informazione desiderata.
Modello reticolare
Quando non è richiesto che lo schema sia un albero, ma ogni tipo di
entità può avere nello schema un numero qualsiasi di tipi di entità
connessi a esso siamo in presenza di schema reticolare.
In questo modello possibile l’esistenza di più di una relazione tra due
entità ed è per questo che le relazioni DEVONO avere un nome.
Sono permesse anche relazioni di tipo N:N e relazioni unarie.
Nello schema sono descritti i record-type (le entità), i data-items (gli
attributi) e i set (le associazioni tra entità) in cui c’è una gerarchia tra un
owner e un member.
Tramite il set si effettua la navigazione perchè un record-type può
appartenere a più set.
Rappresentazione modello reticolare
Navigazione
Nei modelli reticolare e gerarchico è molto importante il concetto di
navigazione.
Per accedere alle occorrenze delle entità è necessario muoversi tra di
esse utilizzando come mezzo di trasporto le associazioni.
Si parte da un’occorrenza, o un insieme di occorrenze, ci si sposta
fisicamente da un insieme di occorrenze a un altro: le informazioni si
possono reperire solo allora.
Si tratta del tipico approccio procedurale e il modo di lavorare è simile
a quello che si usa con un normale linguaggio di programmazione che
usufruisce di file.
Modello relazionale
Nel modello relazionale i dati vengono rappresentati in formato tabellare.
Le tabelle sono formate da colonne per gli attributi e da righe per i record.
Il legame esistente tra due tabelle è di tipo logico ed è realizzato
tramite un attributo in comune, che nell’esempio della figura è
rappresentato dal campo CodEd della tabella Editori e dal campo CodEd
della tabella Libri.
Modello Object-oriented
Recentemente si stanno diffondendo dei sistemi basati sul modello
Object-Oriented.
Tale modello utilizza oggetti indipendenti che permettono di modellizzare in
modo naturale la realtà, e non un modello della realtà, natural modelling.
Modello Object-oriented
Il concetto base della tecnologia Object-oriented è l’inscindibilità della
struttura dei dati e delle operazioni che li manipolano: un oggetto (in
figura) è formato da un insieme di dati, detti proprietà, e da un insieme di
operazioni, dette metodi.
Le proprietà (o attributi) sono dati privati di un oggetto e non possono
essere raggiunte esplicitamente dall’esterno se non applicando le
operazioni (o metodi) associate.
Encapsulation
Il principio della encapsulation afferma che l’unico modo per accedere ai
dati dell’oggetto è l’invocazione dei metodi: non è quindi possibile usare la
struttura in modo differente da quello per cui è stata prevista.
L’encapsulation può essere vista come un’estensione del concetto di
modularità.
Dal momento che le interazioni tra gli oggetti possono avvenire solamente
tramite i metodi, risulta facilitata la costruzione incrementale di sistemi di
dimensioni ragguardevoli, nonché la localizzazione di eventuali
malfunzionamenti.
Ereditarietà
Un’altra caratteristica importante che differenzia i sistemi Object-Oriented
da quelli tradizionali è l’ereditarietà.
L’ereditarietà (inheritance) consente la definizione di un nuovo oggetto
mediante il raffinamento.
Con l’ereditarietà diventa possibile riutilizzare il software prodotto senza
duplicazioni e senza conoscere i dettagli di implementazione, con evidenti
vantaggi in termini di produttività.