Fondamenti di Basi di Dati 88-08-07003-4 [PDF]

Zitiervorschau

Clean by Ripper_92 2013

ONDAMENTI DI BASI DI DATI ANTONIO ALBANO· GIORGIO GHELLI RENZO ORSINI

ZANICHELLI

INDICE Clean by Ripper_92 2013

Prefazione l

Sistemi per basi di dati 1.1 Sistemi informativi e informatici 1.2 1.3

1.4

-> Q})

1.6 1.7

2

Evoluzione dei sistemi informatici Tipi di sistemi informat ici . . . . . 1.3. 1 Sistemi informatici operativi 1.3.2 Sistemi informatici direzionali I sistemi per basi di dati . . . . . . . . Funzionalità dei DBMS . . . . . . . . 1.5. 1 Definizione della base di dati . 1.5.2 Uso della base di dati . . . . . 1.5.3 Controll o della base di dati . . 1.5.4 Distribuzione della base di dati . 1.5 .5 Ammi ni strazione dell a base di dati . Vantaggi e problemi nell ' uso dei DBMS Conc lusioni . . . . Esercizi . . . . . . Note bibliografiche

xi l l 3 5 6 7 8 12 12 16 18 22 22 23 24 25 25

I modelli dei dati

27

2. 1 2.2

27 28 28 36 36 36 37

2.3

Progettazione e modellazione . . . . . . . . . Considerazioni preliminari all a modellazione 2.2. l Aspetto antologico . . . . . 2.2.2 Aspetto lingui stico astratto . 2.2.3 Aspetto linguistico concreto 2.2.4 Aspetto pragmatico . . . . . Il modello dei dati ad oggetti . . . . 2.3. 1 Rappresentazione della struttura della conoscenza concreta . . . 2.3.2 Rappresentazione degli altri aspetti della conoscenza astratta . . . . . . 2.3.3 Rappresentazione della conoscenza procedurale .

38 49 50

vi

© 88-08-07003-4

Indice

2.3.4 2.4

2.5

• 3

La progettazione di basi di dati

3.1 3.2

3.3 3.4

3.5

3.6 3.7

• 4

Rappresentazione della comunicazione Alt1i modelli dei dati 2.4. 1 Il modello entità-relaz ione 2.4.2 TI mode ll o retico lare 2.4.3 li mode ll o gerarchico . 2.4.4 Il modello relazionale Conclusioni Esercizi Note bibliografiche

Introdu zione . Le metodologie di progettazione 3.2. 1 Il ruolo delle metodologie 3.2.2 Le metodologie con più fasi 3.2.3 Le metodologie con prototipazione Gli strumenti formali 3.3.1 I diagrammi di flu sso dati 3.3.2 I diagrammi di stato L' ana li si dei requi siti 3.4.1 Scopo dell ' anali si dei requisiti 3.4.2 Come procedere 3.4.3 Un esempio di analisi dei req uisiti La progettazione concettual e 3.5. 1 Scopo della progettazione co ncettuale 3.5.2 Come procedere 3.5.3 I passi della progettazione co ncettuale Riepilogo della metodologia di progettazione Conclusioni Esercizi Note bibliografi che

Il modello relazionale

4.1

4.2

4.3

Il modello dei dati . 4.1. 1 La relazione . 4. 1.2 I vi ncoli d'integrità 4.1.3 Una rappresentazione grafi ca di schemi relazionali 4.1.4 Operatori Progettazione log ica rel azionale 4.2. 1 Rappresentazion e delle associazioni binarie uno a molti e uno ad un o 4.2.2 Rappresentazione di associazioni molti a molti 4.2.3 Rapprese ntazione dell e gerarchie fra classi 4.2.4 Defi nizione dell e chiavi primarie . 4.2.5 Rappresentazione de lle proprietà multi valore 4.2.6 Appiattimento degli attributi composti Algebra relazionale 4.3.1 Gli operatori primitivi

50 51 51 53 53 54 55 55 56 57 57 58 59 60 62 63 64 67 69 69 70 71 78 78

79 80 88 88 89 93 95 95 95 97 99 100 101 102 103 105 108 109 l IO III III

© 88-08-07003-4

Indice

" ,., 4.4 ~ 4.5 4.6

vii

4.3.2 Operatori derivati .. .. .. .. . . . . . .. . 4.3.3 Proprietà algebriche degli operatori relazionali 4.3.4 Altri operatori . . . . . Calcolo relazionale su ennupl e I linguaggi logici Conclusioni . . . . Esercizi . . . . . . Note bibliografiche

5

Normalizzazione di schemi relazionali 5.1 Le anomalie· . . . . . . 5.2 Dipendenze funzionali . . . 5.2. 1 Definizione . . . . . 5.2.2 Dipende nze deri vate 5.2.3 Chiusura di un insieme di dipendenze funzionali 5.2.4 Chiavi . . . . . . .. . .. . .. . .. . 5.2.5 Copertura di un insieme di dipendenze . 5.3 Decomposizione di schemi .. . . . . . . . . . 5.3. 1 Decomposizioni che preservano i dati . 5.3.2 Decomposizioni che preservano le dipendenze 5.4 Forme normali . . . . . . . . . . . . . . . . 5.4. 1 Forma Normale di Boyce-Codd .. . 5.4.2 Normalizzazione di schemi in BCNF 5.4.3 Terza forma normale . . .. .. . . 5.4.4 Norm alizzazione di schemj in 3NF. ( 5.5 Dipendenze multivalore . .. . .. . . ~ 5.6 La denormalizzazione . . . . . . . . . 5.7 Uso della teori a della norm ali zzazione 5.8 Conclusioni .. . . Esercizi . . . . . . Note bibliografiche 6

SQL per l'uso interattivo di basi di dati 6.1 Operatori per la ricerca di dati 6.1.1 La clausola SELECT 6.1.2 La clausola FROM . . . 6. 1.3 La clausola WHERE . . 6.1 .4 Operatore di ordinamento 6.1 .5 Funzioni di aggregazione . 6.1.6 Operatore di raggruppamento 6.1.7 Operatori insierrustici . . . . . 6.1.8 Sintassi completa del SELECT 6.2 Operatori per la modifica dei dati .. . 6.3 Il potere espressivo di SQL . . . . . . 6.4 QBE: un esempio di linguaggio basato sulla grafica 6.5 Conclusioni . . . . Esercizi . . . . . . Note bibliografiche

115 117 120 123 124 126 126 127

129 129 133 133 134 137 139 141 143 144 146 149 150 151 153 154 158 159 160 161 161 164 165 166 168 169 170 176 176 177 178 179 180 181 182 183 183 185

viii

Indice

© 88-08-07003-4

7

SQL per definire e amministrare basi di dati 7.1 Defi ni zione della struttura di una base di dati 7.1.1 Base di dati .. 7 . l .2 Tabelle . . 7.1.3 Tabelle virtuali 7.2 Vincoli d' integrità . 7.3 Aspetti procedurali 7.3.1 Procedure memorizzate. 7.3.2 Trigger 7.4 Progettazione fisièa . . 7.4.1 Definizione di indici 7.5 Evoluzione dello schema 7.6 Utenti e Autorizzazioni 7.7 Schemj esterni .. . 7.8 Cataloghi . . 7.9 Strumenti per l'amministrazione di basi di dati . .. 7.10 Conclusioni Esercizi .. Note bibliografiche

187 187 188 189 190 192 195 195 196 201 202 203 204 205 206 206 207 207 208

8

SQL per programmare le applicazioni 8. 1 Linguaggi che ospitano l' SQL 8.1. 1 Connessione all a base di dati 8.1.2 Comandi SQL 8.1.3 I cursori . . . . . 8.1.4 Transazioni . . . 8.2 Linguaggi con interfaccia API 8.2.1 L'API ODBC 8.2.2 L' API JDBC . . . . 8.3 Linguaggi integrati 8.4 La programmazione di transazioni 8.4.1 Ripetizione esplicita delle transazioni 8.4.2 Transazioni con li velli diversi di isolamento 8.5 Conclusioni .. Esercizi Note bibliografiche

209 2 10 211 2 12 212 2 13 216 2 17 2 18 221 223 226 227 228 229 230

Realizzazione dei DBMS 9 .l Architettura dei sistemi relazionali 9.2 Gestore della memoria permanente . 9.3 Gestore del buffer . . . . . 9.4 Gestore delle strutture di memorizzazione 9.5 Gestore dei metodi di accesso . 9.6 Gestore delle interrogazioni . 9.6. 1 Riscrittura algebrica 9.6.2 Ottirnizzazione fi sica . 9.6.3 Esecuzione di un piano di accesso 9.7 Gestore della concorrenza . . . . . . .

231 23 1 231 232 233 236 236 237 239 249 250

' () 9

© 88-08-07003-4

Indice

9.8 9.9

ix

Gestore dell ' affidabi lità Conclusioni . .. . Esercizi . . . . . . Note bibliografiche

251 253 253 255

Bibliografia

257

Indice analitico

261

PREFAZIONE

Otto anni dopo la pubblicazione del volume Basi di dati re/a zionali e a oggetti, la nuova organizzazione della didattica uni versi taria suggerisce una sostanziale revi sione del materiale per renderlo adatto ad un corso semestrale di basi di dati, fo ndamentale dell a laurea in Informati ca delle faco ltà di Scienze e di Ingegneria. Il materiale è stato organizzato in due parti: i concetti fondamentali sono nel vo lume stampato, gli approfondimenti e i complementi sono di sponibili gratuitamente sul sito web del libro (http: l l f o ndamentidibasididati . i t). Questa organizzazione del materiale ha il vantaggio di ridurre la parte stampata agli argomenti ormai consolidati , e all o stesso tempo di poter proporre frequenti aggiornamenti quando nuovi ri sultati diventano importanti per la teoria e le applicazioni . La prima parte tratta gli argomenti considerati fo ndamentali nel campo delle basi di dati per la formazione degli informatici: i modelli dei dati, i linguaggi , i sistemi e le metodologie di progettazione di applicazioni che usano basi di dati. Questi argomenti sono trattati dal punto di vista de l progettista di applicazioni e del responsabile di basi di dati , con cenni ag li aspetti reali zzativi dei sistemi. L' approccio segu ito nel presentare questi argomenti si basa sulla presentazione rigorosa di concetti e princìpi fo ndamentali , costantemente corredata da esemplificazioni tratte da app li cazioni e sistemi reali. Sul sito co ll egato al libro è disponibile invece la trattazione di argomenti che non si riescono ad affrontare in un corso semestrale, che richiedono un continuo aggiornamento allo stato dell ' arte e che si ritiene util e rendere disponibili per le persone interessate ad approfondire la loro formazione. Il sito conti ene inoltre altro materiale utile per lo studi o, come eserci zi con le relative soluzioni , esempi di prove d' esame e appunti delle lezioni.

Organizzazione del testo Il libro inizia presentando le ragioni che motivano la tec nologia delle basi di dati , ed i concetti principali che caratterizzano le basi di dati ed i sistemi per la loro gestione. In maggior dettaglio, il Capitolo 2 si sofferma sulle nozioni fondamentali

xii

Prefazione

© 88-08-07003-4

di modell o inform ati co fi nali zzato al trattamento dell e info rmazioni d i interesse de i sistemi in fo rmati vi delle organi zzazioni e sui meccani smi d'astrazione per costruire mode lli info rmati ci. Il modell o d i ri ferimento è il modell o ad oggetti , moti vato non so lo dall a sua naturalezza per la progettazione di bas i di dati , ma anche per essere il modell o dei dati dell 'attu ale tecno log ia relazio nale ad oggetti per bas i d i dati . Il fo rm ali smo grafico adottato si ispira all ' Unified Modeling Language, UML, ormai uno standard dell ' in gegneria del software. Il Capito lo 3 presenta una panorami ca del problema dell a progettaz ione di bas i di dati , si sofferm a sull e fas i dell 'anali si de i requi siti e dell a progettazione co ncettua le usando il modell o ad oggetti e il fo rmalismo grafi co proposto nel Capito lo 2, e descrive un metodo di lavoro per queste fas i. l Capitoli 4 e 5 sono dedicati all a presentazione ri gorosa del modell o rei azionale dei dati e ad un ' introdu zione all a teori a dell a norm ali zzazio ne. La scelta di dedicare questo spazio all ' argo mento è giustifi cata dal ruo lo fo ndamentale che svo lge il modell o re lazi onale per la comprensione dell a tecnolog ia delle basi di dati e per la fo rmaz ione degli addetti . l Capito li 6, 7 e 8 trattano il linguaggio relazionale SQL da tre punti di vista, che corri spondo no ad altrettante categori e di utenti : (l ) gli utenti interessati ad usare interatti vamente bas i di dati relazio nali , (2) i res ponsabili di bas i di dati interessati a definire e gestire basi di dati , (3) i programm atori dell e applicazio ni . Il Capitolo 9 presenta una panoramica de ll e princ ipali tecni che per la reali zzazione dei sistemi relazionali . Vengono presentate in particolare la gestion e dell e interrogazioni e dei metodi di accesso e la gesti one dell 'ato mi c ità e dell a co ncorrenza in sistemi centrali zzati.

Ringraziamenti L'organi zzazione del mate1i ale di questo testo è il ri sultato di mo lti anni d i in egnamento nei corsi di bas i di dati per i corsi di laurea in scienze dell ' informazione e in info rmati ca. Molte persone hanno contribuito con i loro suggerimenti e criti che costruttive a mi gli orare la qu alità del materi ale. In partico lare si rin graziano i numerosi studenti che nel passato hanno usato le precedenti versioni del testo e G ualti ero Leoni per la sua coll aborazione. A. A. G. G .

R. O.

Capitolo 1

SISTEMI PER BASI DI DATI

Spesso interagiamo con basi di dati senza saperlo: quando facciamo un prelievo dal conto coiTente con il bancomat, quando facciamo un acquisto con la carta di credito, quando acquistiamo un biglietto ferroviario o prenotiamo un viaggio presso un'agenzia, quando usiamo il sito web di un dipartimento universitario per iscriversi ad un esame ecc. In tutte queste situazioni è richiesto l'accesso a certe raccolte di dati o la loro modifica per registrare l'effetto dell'operazione compi uta. In generale queste raccolte di dati sono gestite da organizzazioni che dedicano molte attività e risorse alla raccolta, archiviazione ed elaborazione di informazioni per fornire opportuni servizi. Negli ultimi anni , per l'evoluzione della tecnologia elettronica e la conseguente rid uzione dei costi , si è assistito ad una crescente diffusione degli elaboratori e lettronici per agevolare e potenziare le possibilità di trattamento delle informazioni. Questo fenomeno ha interessato organizzazioni di ogni tipo e dimensioni ed ha portato ad una richiesta sempre più ampia di sistemi dedicati a questo scopo. In seguito, dopo una precisazione sul ruolo del sistema informativo e del sistema informatico all ' interno di un'organizzazione, vengo no definite le nozioni di base di dati e di sistema per la gestione di basi di dati e vengono presentati i concetti fondamentali che verranno sviluppati nei capitoli successivi.

1.1

Sistemi informativi e informatici Ogni organizzazione, per il proprio funzionamento , ha bisogno di disporre di informazioni che costituiscono una risorsa gestita da un proprio sistema informativo, del quale si propone la seguente definizione.

Definizione 1.1 Il sistema informativo di un 'organizzazione è una combinazione di risorse.,-u.r.nane e materiali. e di procedure organizzate per la raccolta, l'archiviazione, l' elaborazione e lo scambio delle informazioni necessarie alle attività operative (informa zioni di servizio), alle attività di programmazione e controllo (informazioni di gestione), e alle attività di pianificazione strategica (informazioni di governo) .

2

Capitolo 1 .

© 88-08-07003-4

Sistemi per basi di dati

Con il termine sistema si evidenzia il fatto che esiste un insieme organizzato di e lementi, di natura diversa, che interagiscono in modo coordinato, mentre con informativo si precisa che tutto ciò è finalizzato alla gestione delle informazioni e quindi le interazioni che preme evidenziare sono quelle dovute a scambi di informazioni (flussi informativi). Per esempio, un ' industria manifatturiera gesti sce informazioni per svolgere attività che includono: l. 2. 3. 4. 5. 6.

Gestione degli ordini e dei pagamenti dei prodotti venduti ; Gestione degli ordini e dei pagamenti ai fornitori di materiali ; gestione del magazzino; Programmazione della produzione; Controllo di gestione; Pianificazione di nuovi prodotti .

Le informazioni di un ' organizzazione, un a volta ridotte a dati mediante un processo di interpretazione, quantificazione e formalizzazione, possono essere trattate automaticamente con gli elaboratori elettronjci. La riduzione dei costi della tecnologia informatica ha diffuso largamente questa possibilità, rendendo più accurate e rapide le procedure e potenziando i modi di elaborazione delle informazioni . Con il termi ne sistema informativo automatizzato si indica la parte del si.; stema mformati vo realizzata im ie ando strumenti informatici e della comuni cazione. In generale, raramente il sistema informativo di un ' organi zzazione viene completamente automatizzato sia a causa di problemi tecnici che per motivi di convenienza economica. Spesso nella letteratura si parla di sistemi informativi pensando al la parte automatizzata. Per brevità e per ev itare confusione useremo il termine sistema informatico per riferirei m sistemi mformativi automatizzati . Un sistema informatico, per fornire i servizi attesi dagli utenti , prevede i seguenti componenti principali (Figura 1.1): Utenti

t

Servizi

Comunicazione

Prog ramm i '--a-p-pl-ic_a_ t iv_i_,

~~

L::J L:_j

Software e hardware di base

Sistema informatico

Figura 1.1. Componenti del sistema informatico.

© 88-08-07003-4

1.2.

Evoluzione dei sistemi informatici

3

- il software e l'hardware di base; - una base di dati, che contiene una rappresentazione del patrimonio informativo dell 'organizzazione; - uno schema, che descrive la struttura della base di dati , le operazioni per agire su di essa e le restrizioni sui valori memorizzabili nella base di dati e sui modi in cui essi possono evolvere nel tempo (vincoli di integrità). Lo schema viene usato dal sistema per garantire un uso corretto della base di dati; - i programmi applicativi, che forniscono i servizi agli utenti eseguendo un certo insieme di operazioni sulla base di dati. - la comunicazione, che perf!l.ette l'accesso ai servizi del sistema informatico ad utenti e programmi . In questo testo vengono prese in considerazione, tra le informazioni trattate da un 'organizzazione, solo quelle strutturate, con un formato predeterminato, e di carattere prevalentemente globale, cioè utili a più reparti.

1.2

Evoluzione dei sistemi informatici L'architettura dei sistemi informatici per la gestione di informazioni strutturate è cambiata molto negli ultimi quarant'anni con l'evolvere della tecnologia degli elaboratori elettronici e degli strumenti per la gestione di dati permanenti. Vediamo i passaggi più significativi.

Primo stadio: applicazioni operative Agli inizi degli anni '60, le applicazioni riguardavano le attività delle funzioni amministrative che richiedevano l'elaborazione sistematica e ripetitiva di grandi quantità di dati, come il calcolo delle paghe e degli stipendi o l'emissione delle fatture . Successivamente, a questo primo nucleo di applicazioni, si sono aggiunte altre più complesse, come la gestione del magazzino e la contabi lità dei clienti, che ancora oggi costituiscono il nucleo essenziale di ogni sistema informatico nelle aziende. Secondo stadio: servizi informatici di funzione Dalla fine degli anni '60, l'interesse si è spostato anche sull 'elaborazione delle informazioni di supporto ai responsabili delle varie funzioni aziendali, con lo sviluppo di applicazioni per la contabilità generale, per il controllo di gestione e per la valutazione del funzionamento d eli' azienda. Questi tipi di sistemi informatici ri spondevano quindi a due precise esigenze: - rendere più efficienti le attività ripetiti ve dei Livelli esecutivi dell 'azienda; - permettere una migliore gestione dell 'azienda fornendo ai responsabili le informazioni sintetiche sull 'andamento delle attività controllate.

Terzo stadio: servizi informatici per l'organizzazione La realizzazione di servizi informatici per le funzioni aziendali non presupponeva l' integrazione dei dati in comune alle diverse funzioni e quindi comportava sia la duplicazione di dati, con il ri schio di copie incoerenti, sia una lirnitata possibilità di correlare dati settoriali per generare informazioni di interesse globale per l'organizzazione.

4

Capitolo 1.

Sistemi per basi di dati

© 88-08-07003-4

A partire dag li anni ' 70, il progresso de ll a tecnol ogia ha reso di sQonibili nuovi strumenti infor matici, i sistemi per la gestione di basi di dati Data Base Management System, DBMS) , che, rendendo poss ibile una gest ione integrata dei dati, interessavano ogni li vello delle organizzazioni: i dati trattati automaticamente non erano suddi visi per interessi settoriali , ma veni vano trattati globalmente, in modo che ciascuna informazione, benché rappresentata una sola volta, era utilizzabile per attività diverse del sistema informativo. Si è passati quindi da sistemi informatici settoriali a sistemi informatici per l 'organizzazione, co n notevoli rifless i sulla struttura dell ' organi zzazione stessa, in quanto un impiego razionale della tecnologia informatica comporta necessariamente una rev isione del modo di fu nzionare della struttura organizzati va che deve utili zzar!a. ~ I vantaggi più evidenti di questa so lu zione sono: l. Integrazione dei dati. Invece di avere per ogni applicazione un a coppia (daI , programmi , con dati in generale non compl etamente di stinti da quelli usati da un ' altra applicazione, si vuo le prevedere un ' unica racco lta di dati com uni , che costituiscono le info rmazioni di base, e tanti programmi che reali zzano le applicazioni operando solo sui dati di loro interesse. Questo obiettivo comporta i seguenti vantaggi:

Disponibilità dei dati. Quando i dati non so no organizzati in funzione di u na specifica applicazione, è più semplice renderli di sponibili ad usi diversi. Limitazione delle ridondanze. L' esistenza di un ' unica raccolta di dati , accessibili co n modal ità diverse, elimina la necessità di dupli cazioni , che com portano maggiore occ upazio ne di memori a e possibilità di inconsistenze fra i dati. Efficienza. La gestione integrata dei dati si presta allo sviluppo di strume nti per ottimi zzare globalmente la loro organizzazione fisica e, quindi , l'efficienza complessiva del sistema. 2. Flessibilità della realizzazione. Le modifiche ad un sistem a informatico funzionante sono mev itabiTi e devono poter essere fatte senza dover intervenire sull a realizzazione in modo massiccio. Infatti , il progetto e la reali zzazione di un sistema informatico sono, in generale, dei compiti complessi: dal momento in cui si raccolgono le specifiche, al momento in cui si ha un a prima versione fun zionante dell a reali zzazione, può trascorrere un intervallo di tempo suffic ientemente lungo perché ci sia una modifica dei requisiti iniziali. Un'altra ragione, che richi ede un 'evolu zione della reali zzazio ne, è che un sistema informatico di supporto a sistemi informati vi si progetta in modo incrementale: si parte automatizzand o un nucleo di funzioni essenziali e, success ivamente, il sistem a si amplia inglobando nuovi dati e funzioni . Esi ste, infine, un 'altra ragione , meno prevedibil e, che può causare un 'evoluzione delle specifiche: quando il sistema funziona in modo soddi sfacente, gli utenti vengono stimolati nell a loro immaginazione e intravedono nuove possibilità d' impiego del sistema informatico, modificando così i requi siti ini ziali.

© 88-08-07003-4

1 .3.

Tipi di sistemi informatici

5

Tabella 1.1. Prospetto cronologico dell'evoluzione dei sistemi per basi di dati.

'60

Si stemi gerarchici (IMS e Sys te m 2000)

' 70

Sistemi reti colari secondo la proposta CODASYL (IDMS , IDS II, DM IV, DMS Il 00 ecc.) E.F. Codd propone il modell o relazio nale

'80

Si stemi re lazionaJi (System R, lngres, Orac le, SQL/DS, DB 2, Infonni x ecc .)

'90

Si stemi re lazionali di stribuiti Architetture cli ente/servente e parall e le Sistemi ad oggetti e re lazionali ad oggetti (GEMSTONE, ONTOS, Objectstore, 0 2 , Illustra, UniSQL ecc .)

1995

Integrazione co n Internet

lni z i a lm~nte

i sistemi per bas i di dati erano di tipo centrali zzato, ovvero la base di dati era geStita da un uni co e laboratore. Ag li ini zi degli anni ' 90, Invece, l'evoluzione dell a tecno log ia ha reso possibile anche la reali zzazione di siste mi per bas i di dati di stribuite, u rete locale o geografi ca, che consento no di avere una visione uni ca dei dati, indipendentemente da dove ess i siano fi sicamente memori zzati . - In Tabe ll a 1.1 sono riportati i passagg i più signifi cati vi d eli ' evo lu zione de ll a tecno log ia de ll e bas i di dati .

Quarto stadio: servizi informatici per la pianificazione strategica A partire dagli anni ' 80, infine, lo sviluppo dell a tec nolog ia ha permesso un a progress iva copertura dell e es igenze inform ati ve per le atti vità di programm azione e di pi anifi cazione strateg ica, all argando ulteriormente lo spettro dell e poss ibilità di applicazio ne dell a tec nol ogia informati ca ne ll e organi zzaz ioni per l' automaz ione dei sistemi info rm ati vi.

Quinto stadio: servizi informatici per la cooperazione fra organizzazioni A partire dall a fin e deg li anni '90 infine, co n la grande diffu sione di standard di comuni cazio ne dov uti all o sv iluppo dell a rete Internet e del Web, sono ini ziati a diffo ndersi protoco lli di cooperaz iOne fra sistemi inform ati ci diversi, e strumenti che semplifi cano lo sca mbi o di dati e le richieste di servizi fra di loro (Web services) . L' obietti vo è di facilitare lo sv iluppo di applicazio ni di comm ercio elettro nico che prevedano l' interaz10ne d i oroanizzazioni s~a­ rate, con sistemi inform atic ic tero eneì, co me le az iende produttric i, quell e di mtermedi azio ne, di logistica, pubbliche ammini strazioni ecc.

1.3 Tipi di sistemi informatici TIIustJiamo le differenze fra le fin alità di due ti ici sistemi informati ci dell e organi zzazioni , usando come esempi o il caso di un a catena di supermercati con negozi sul tenitorio naz io nale.

6

Capitolo 1.

1.3.1

© 88-08-07003-4

Sistemi per basi di dati

Sistemi informatici operativi

l

d pe.u.de....A,

Ogni negozio utilizza una base di dati operazionale (o transazionale) che raccoglie informazioni sugli effetti delle operazioni di routine necessarie quotidianamente per condurre le attività aziendali. Per esempio, per avere informazioni sui prodotti di cui dispone, per stabilire a quale prezzo vendere il prodotto quando viene fatto un acquisto, come stampare lo scontrino, come aggiornare il saldo del venduto ad ogni cassa e come aggiornare lo stato del magazzino. È faci le immaginare come le cose si complichino quando sia necessario tener conto anche del fatto ché i pagamenti possono essere fatti non solo in contanti , ma anche con bancomat o con carta di credito. Quando il cliente ha ricevuto lo scontrino, il sistema garantisce che la base di dati ha subito tutte le modifiche necessarie per tener conto di tutti gli effetti che ha prodotto l'evento che si è verificato alla cassa. U termine transazionalfl__ si usa per riferirsi al fatto che le interazioni con il sistema avvengono mediante transazioni un evento che innesca sull a base di dati una se uenza S di azioni che devono tutte andare a buon fine perché essa rimanga coerente, ovvero rifletta correttamente gli effetti e evento. In caso di un malfunzionamento che interrompa l'esecuzione di S, il meccanismo della transazione arantisce che la base di dati - si troverà nello stato- in cui si trovava prima che S iniziasse.

--

---

Le basi di dati operazionah sono gestite dalle appli cazioni che fanno parte dei cosiddetti sistemi infonnatici operativi o sistemi di elaborazione di transazioni (Transaction Processing Systems, TPS) . Le applicazioni assistono i dipendenti allivell o operativo nello svolgimento delle attività di loro competen:i.a -(Figura r:2). Un esempio di questo tipo di soluzione sono i sistemi ERP, Enterprise Resource Planning, acron imo che non spiega la finalità di questi sistemi, che non è la pianificazione delle risorse aziendali , ma l'integrazione dei processi aziendali in un unico sistema software che possa soddisfare tutti i requisiti informativi dell'azienda usando una base di dati centralizzata.

Logistica interna ed esterna Produzione Vendita e marketing Contabilità

Finanza

Risorse umane APPLICAZIONI

Figura 1.2. Sistemi informatici operativi.

© 88-08-07003-4

1.3.

7

Tipi di sistemi informatici ..._..,.,

1.3.2

Sistemi informatici direzionali

(

c.

C.e(r" dt ,~:"e.,

, ,,-r'!J. r··e.v.o'....r.

ci{_~, ""'"""' )

Le direzioni intermedia e operativa della catena di supermercati hanno bi sogno di analizzare i dati di ogni negozio per produrre rapporti di riepilogo sul l'andamento delle vendite e sul funzionamento del supermercato per prendere decisioni che riguardano tutta l' azienda allivello nazionale. Assumiamo che i rapporti da produrre riguardino (a) l' andamento delle operazioni di base dell ' azienda nel breve periodo (settimanale, men sile e annuale), (b) siano standard e ripetiti vi, (c) siano relativamente poco complessi, (d) siano produci bili a partire dalle basi di dati operazionali. Per esempio, conoscere .le vendite del supermercato con sede a Pisa nelle ultime quattro settimane. Le informazioni sono ricavate dalle basi di dati operazionali usando applicazioni specializzate per assistere le direzioni intermedia e operativa dell ' az ienda nelle funzioni di programmazione e controllo. Per prendere decisioni , le direzioni intermedia ed alta della catena di supermercati hanno invece bi sogno di analisi storiche dell 'andamento degli affari che comportano la produzione interattiva di rapporti di sintesi non programmati, più complessi e da punti di vista diversi, per scoprire situazioni anomali o tendenze interessanti, che non possono essere prodotti a partire dalle basi di dati operazionali perché esse di solito rendono disponibili solo i dati più recenti oppure perché le operazioni necessarie per produrre i rapporti sono complesse e rallenterebbero le operazioni di cassa oltre il tollerabile. Per soddisfare queste esigenze, i dati storici ven ono inteorati con dati rovenienti da fonti esterne e organizzati opportunamente in un altro ti o di baseaì ati , detta data warehouse, gestita separatamente con un opportuno sistema che metta a di sposizione strumenti adatti per fare faci lmente a lisi interattive dei dati . Mentre una base di dati o erazionale è a iornata tempestivamente d o ni verificarsi di un evento aziendale, il data warehouse VIene aggiornato periodicamente con nuovi dati storici, oesterni , perché a1 t1nì e e analisi di supporto alle deci sioni non è necessario di s arre di dati accurati al %. -Mentre nel caso precedente le esigenze sono soddi sfacibili con richieste specifiche (''Trovare i possessori di carta di credito che hanno speso più di 50 euro in alcolici nel mese di gennaio"), un ' altra es igenza dell'alta dirigenza è di scoprire automaticamente qualche aspetto interessante di un insieme di dati con tecniche di data mining (''Qual è il profilo generale dei possessori di carta di credito che traggono profitto dalle promozioni?"). Il data mining è una fase di un rocesso interattivo e iterativo che cerca di estrarre modelli da un insieme di dati uti ·i m dirigenti per prendere deci sioni. Un modello, in questo contesto, è una rappresentazione concettuale che evidenzia in una forma opportuna certe caratteristiche di informazioni implicite, sconosciute a priori e potenzialmente utili , presenti nei dati. I dati per produrre le informazio ni che aiutino i diri oenti a prendere deci sioni sonogestiti dai cosiaCieffi sistemi cf .up.p.o.t:. e decisioni Decision Sup ort Systems, DSS) (Figura 1.3).

8

Capitolo 1.

© 88-08-07003-4

Sistemi per basi di dati

Analisi multidimensionale

Base di dati operazionale

Estrazione Trasformazione Caricamento

f+---'~

Sistema di Supporto alle Decisioni

Data Mining

Data Warehouse Generazione di rapporti Dati esterni

Figura 1.3. Sistemi informatici direzionali.

1.4

l sistemi per basi di dati Il termine base di dati viene spesso usato per riferirsi ad un qualsiasi insieme di dati permanenti trattati con un elaboratore elettronico, ma qui verrà usato con il seguente significato.

Definizione 1.2 Una base di dati è una raccolta di dati permanenti, gestiti da un elaboratore elettronico, suddiVISIIndue categorie: ---

1. I metadati, ovvero lo schema della base di dati (database schema), una raccolta di definiziom c e escrivono la struttura dei dati , le restrizioni sui valori ammissibili dei dati vincolld'integrità) , le relazioni esistenti fra gli inslemf, e a volte anche alcune operazioni eseguibili sui dati. Lo schema va definito prima di creare i dati ed è indipendente dalle app li cazion i che usano la base di dati; 2. I dati, le rappresentazioni di certi fatti conformi alle definizioni dello sche~on le seguenti caratteristiche: (a) sono organizzati in insiemi omogenei, fra i quali sono definite delle relazioni. La struttura dei dati e le relazioni sono descritte nello schema con opportuni meccanismi di astrazione dipendenti dal modello dei dati (data mode/) utilizzato, che prevede anche operatori per estrarre elementi da un insieme e per conoscere quelli che, in altri insiemi, sono in relazione con loro; (b) sono molti , in assoluto e rispetto ai metadati , e non posso no essere gestiti tutti contemporaneamente in memoria temporanea; (c) sono permanenti , cioè, una volta creati, continuano ad esistere finché non so no esplicitamente rimossi; la loro vita quindi non dipende dalla durata delle applicazioni che ne fanno uso; (d) sono accessibili mediante transazioni (transactions), unità di lavoro atomiche che non possono avere effetti parziali ; (e) sono protetti sia dall 'accesso di utenti non autorizzati, sia da corruzione dovuta a malfunzionamenti hardware e software ; (f) sono utilizzabili contemporaneamente da utenti diversi. 1

l. Il termine " ute nte" viene usato sia con il sig nifi cato di persona che accede ai dati da un tenninaie in modo interattivo usando un opportuno lin guagg io, sia con il significato di programma

© 88-08-07003-4

1.4.

9

l sistemi per basi di dati

Esempio 1.1 Per chi arire i concetti esposti , si mostra un sempli ce esempi o di base di dati che memori zzi info rmazioni relative a studenti ed esami di un ' uni versità. Ogni insieme è visto come un a tabell a con tante colonne qu anti sono i campi d' interesse. Questo tipo di base di dati è detto relazionale e sarà di sc usso in modo approfo ndito nel Capitolo 4. Studenti

ProveEsami

Nome

Matricola

Città

AnnoNascita

Isaia Rossi Bianchi Bonini

71523 67459 79856 75649

Pisa Lucca Livorno Pisa

1980 1981 1980 1981

Materia

Matricola

Data

Voto

Basi di dati Basi di dati Linguaggi Basi di dati Compilatori

71523 67459 79856 75649 71523

12/01 /01 15/09/02 25/10/03 27/06/01 10/10/02

28 30 30 25 18

l metadati riguardano le seguenti info rmazioni :

----

l. Il fa tto che esistono due coll ezio ni di interesse Studenti e ProveEsami ; 2. La struttura degli elementi di queste due coll ezioni (intestazione dell e tabelle): ogni studente ha una matricola, di tipo intero, che lo contraddi stingue, un nome, di tipo stringa, un anno di nascita, una città di res idenza; ogni esame ha un a materia, la matri cola dello studente, la data dell 'esame e il voto ottenuto; 3. Il fa tto che ad ogni esame (inteso come l'evento in cui un o studente viene esamin ato) corri sponde uno studente con la matri cola spec ificata, e ad ogni studente corri spondono uno, ness uno, o più esarni ; 4 . Alcuni vincoli sui valori ammi ss ibili , qu ali il fatto che il valore della matricola identi fica una ri ga della tabell a Studenti e i valori della matri cola e dell a materia identifi cano una ri ga dell a tabell a ProveEsami, oppure che il voto deve essere un numero intero co mpreso fra 18 e 30.

I dati invece sono le ri ghe dell e tabelle che co ntengono le informazioni .relative ai singoli studentì ed esami.

Le caratteri stiche delle bas i di dati sono aranti te da un sistema er la estione di basi di dati (Data Base Management System, DBMS , che ha il controll o dei dati e li rende accessibili agli utenti autorizzati . -- -

Definizione 1.3 Un DBMS è un sistema centrali zzato o di -stribuito - - che

'-"'-'=~'-"":.....:::..:==-==~=ti , (b) di scegli ere le strutture datLr_er_!a memori zzazione e l'accesso ai dati , (c) di memori zzai~, rec uperare

app licativo che conti ene istruzioni per l' accesso ai dati.

10

Capitolo 1.

© 88-08-07003-4

Sistemi per basi di dati

e modificare i dati, interattivamente o da gro rammi ad utenti autorizz ti_e_ rispettando i vincoli definiti nello schema.

Utente

Utente

l

l

Sistema informatico

l

Programmi app licativi

DBMS

l

j/ Gestore schemi, autorizzazioni e operazioni

t l BO

Gestore dati permanenti -?1

l

~ [ Metadati]

l

l J

~

\

.:!

~

·~

Figura 1.4. Il sistema informatico e il sistema per la gestione di basi di dati.

In Figura 1.4 è mostrata una versione semplificata della struttura di un DBMS. È interessante ricorrere ad un'analogia con concetti dei linguaggi di programmazione per chiarire alcuni dei concetti finora introdotti: modello dei dati, linguaggio per basi di dati , base di dati e schema, sistema per la gestione di basi di dati.

Modello dei dati Un modello dei dati è un insieme di meccanismi di astrazione per definire una base di dat1 , con assoCiato un ms1eme predefimto di operatori e di vincoli d'integrità. I modelli dei dati adottati dai moderni sistemi commerciali sono il relazionale e quello ad oggetti. Le loro caratteristiche verranno presentate nelprossimo capitolo. I meccanismi di astrazione di un modello dei dati corrispondono ai meccani smi di astrazione per rappresentare i dati in un linguaggio di programmazione e vanno tenuti distinti dal modo in cui sono trattati in un particolare linguaggio per basi di dati, nello stesso modo in cui nei linguaggi di programmazione si parla, per esempio, del meccanismo di astrazione del reco rd e delfile, prescindendo dalla forma sintattica che prende in un particolare linguaggio. Un buon modello dei dati dovrebbe essere caratterizzato da: espressività: il modello dovrebbe permettere di rappresentare in modo naturale e diretto il significato di ciò che si sta modellando; - semplicità d' uso: il modello dovrebbe essere basato su di un numero minimo di meccanismi semplici da utilizzare e da comprendere;

© 88-08-07003-4

1 .4.

l sistemi per basi di dati

11

- realizzabili tà: i meccani smi del modell o di astrazio ne, e i relativi operatori per la manipo laz io ne dei dati , devono essere reali zzabili in modo effic iente su di un elaboratore elettroni co.

Linguaggio per basi di dati Quando si pensa ad un linguaggio di programmaz ione si pensa ad un linguaggio che prevede un sistema di tipi co n opportuni operatori e una struttura del contro ll o. Quando si pensa ad un linguaggio per base di dati , invece, per moti vi stori ci, si usa di stinguere ra:

l. Il lin guagg io per la defini zione dell o schema, ovvero de ll a struttura dell e co lezio nidei dati (Data definition language, DDL); 2. Il linguaggio degli operatori del modell o dei dati , che permette di accedere ai dati e di modifi ca r! i, ma è in genere pri vo dei costrutti tipi ci dei linguaggi di programm azione (fun zioni , struttura de l contro ll o, vari abili ecc.) (Data manipulation language, DML); -3. Il linguagg io per la codifi ca dell e appli cazio ni che richiedono lo sv ilu o 1 programmi c e usano la ase di dati . Si tratta di solito di un linguagg io tradi zionale, tipo C o Java, esteso agg iungendov i gli operatori de l DML (host language); 4. Il linguaggio di interrogazione (query language) per il recu ero e la modica 1 a 1 1n eratt.I vamente, ma non per o sviluppo di applicazioni . Sono stati proposti sia lingu agg i che offrono alcune dell e funzionalità sopra elencate, come il linguaggio SQL che verrà descritto nei Capitoli 6-8, sia linguaggi di programm azione co mpl eti per bas i di dati che offrono tutte le funzionalità sopra descritte: defini zione de ll o chema, interrogazione e modifi ca dei dati , reali zzazione di applicazioni co mplete. Questi linguaggi possono essere visti come de i linguaggi di programmazione arri cchiti co n la possibilità di definire alcuni dati come persistenti e la di sponibilità di operatori e tipi di dati adatti a manipol are collezioni di dati omogenei. Un esempio di questi linguagg i verrà presentato nel Capitolo 8.

Base di dati e schema Secondo la visio ne tradi zionale, i dati di un a base di dati ed il relati vo schema corri spondono ri spettivam ente ad un insieme di variabili (che denotano insiemi modificabili di valori permanenti ) che più applicazio ni posso no leggere e modifi care in mani era concorrente, ed all a defi ni zione del tipo di tali variabili , che tuttavia in questo caso è anch'essa perm anente e in generale utili zzabile dall e applicazio ni . Gli orientame nti più recenti , invece, prevedono di trattare ne ll o sche ma sia dati sia procedure. In questa visione, un o schema è analogo ad un insie me di defini zioni non so lo di tipi e variabili , ma anche di procedure scritte nel linguagg io del DBMS , access ibili da tutte le applicazioni che fa nno ri fe rimento a tale schema. Esempi verranno mostrati nel Capito lo 7.

12

Capitolo 1.

Sistemi per basi di dati

© 88-08-07003-4

Sistema per la gestione di basi di dati È il sistema, hardware e software, che consente la definizione e l' uso di basi di dati in un opportuno linguaggio. In altre parole, è la macchina astratta il cui linguaggio è il linguaggio per basi di dati. Esso, quindi , è analogo al compilatore, o all ' interprete, di un certo linguaggio, più l' insieme dei moduli attivi durante l' esecuzione dei programmi (run time system). L'architettura e le tecniche di realizzazione dei DBMS saranno discusse nel Capitolo 9. Si passa ora ad esaminare le funzionalità che caratterizzano un DBMS. Non tutti i sistemi o rond 'tutte le funzionalità che s1 pren eranno in considerazTOne,Tnparticolare i DB S previsti per calcolatori personaìi ne sacrificano alcun~er raowm 1 costo 1p1camen e a gestione delle transazioni e l'accesso concorrente ai dati), ma l'elenco che seoue include uell e funzionalità da considerarsi irrinunciabi 1 per prodotti da usare nella gestione delle informazioni ne-ti

1.5

Funzionalità dei DBMS Si analizzano le principali funzionalità che un DBMS mette a disposizione per i seguenti scopi: l. 2. 3. 4. 5.

Definizione della base di dati ; Uso della base di dati; Controllo della base di dati; Distribuzione della base di dati ; Amministrazione della base di dati.

1.5.1

Definizione della base di dati

Nei DBMS la base di dati è descritta separatamente dai programmi applicativi che ne fanno uso ed è utile distinguere tre diversi li velli di descrizione dei dati: il livello fisico, il livello logico e il livello di vista logica. Al livello fisico viene descritto il modo in cui vanno organizzati fisicamente i dati nelle memorie permanenti e quali strutture dati ausiliarie definire per facilitarne l' uso. La descrizione di questi aspetti viene detta schema fisico o interno (physical o internai schema). Al livello logico viene descritta la struttura degli insiemi di dati e delle relazioni fra loro, secondo un certo modello dei dati , senza nessun riferimento alla loro organizzazione fisica nell a memoria permanente. La descrizione della struttura della base di dati viene detta schema logico (logica/ schema) . Al livello di vista logica viene definito come deve apparire la struttura della base di dati ad una certa applicazione. Questa descrizione viene anche detta schema esterno o vista (external schema o user view), per evidenziare il fatto che essa si riferisce a ciò che un utente immagina che sia la base di dati . Le differenze fra una vista e lo schema logico della base di dati riguardano sia gli insiemi di dati accessibili sia la struttura dei dati. Mentre lo schema

© 88-08-07003-4

1.5.

Funzionalità dei DBMS

13

logico è unico, es istono in genere più schemi esterni , uno per ogni applicazione (o gruppo d i applicazioni correlate), che permettono di vedere e modifi care sotto in siemi diversi, in generale non di sgiunti , de ll a base di dati (vedi Figura 1.5). Appl icazione 1 (AC-

c:.tl

/)'--0

us'~ o tJ. s "-"-"-'1té\c .,.\\ X

-

~

Appl icazione2

Applicazione m

>

W i:

~1V' v.\\u-..~ EcE:·, c:.~

s(R), è una relazione con attributi X- {A} U {B} definita come segue: oA--> B(R)

=

{t

l :Ju

E

R tale che t[B]

= u[A] 1\ t[C] = u[C] se C i=

B) }.

Unione R U S = {t

lt

E

R V t E S},

con R ed S relazioni dello stesso tipo. Restituisce la relazione ottenuta facendo l' unione delle ennuple di R con quelle di S. Per esempio, se R : {T}, e t : T un 'ennupl a non in R, R U {t} sta per la relazione ottenuta aggiungendo ad R l' ennupl a t.

112

Capitolo 4.

© 88 -08-07003-4

Il modello re/azionale

Differenza R-

s = {t I l

R

E

t

1\

rt S},

co n R ed S relazioni dell o stesso tipo. Restitui sce la re lazio ne conte ne nte le e nnupl e di R non presenti in S . Pe r esempi o, se R : {T} , e 1 : T un 'e nnupl a in R, R - {t} sta per la re lazione otte nuta elimina ndo l' e nnupl a 1 da R.

Proiezione

con A 1 • A 2 , . ... A 111 attributi di R. Restitui sce un a re lazione di tipo {A 1 : T1, A2 : T2 . .. . , A 111 : 7;11 } i c ui ele menti sono la copi a dell e e nnupl e di R pro iettate sugli attributi A 1• A 2 . .. . , A 111 • Po ic hé le relaz io ni sono in siemi , eventuali e nnupl e uguali dopo la pro iezio ne appaio no un a so la vo lta ne l ri sultato.

Restrizione CYif> ( R) ={l I l E R 1\ (/) }.

Restitui sce un a relazione de ll o stesso tipo diR i c ui ele menti so no la copi a de lle e nnupl e di R che soddi sfano la condi zio ne. La condizione

,

= , i= - :::.~ } ;

e c,

ce

e

- A; oppure A ;, co n un ope ratore di co nfronto e dom (A;); - se

SA I ···· · AII-> SAII ( S ).

2. Sia T= CTR A 1=s A 1/\ ···A RA =S A ( R' x S ' ) . 3. La g iun zione naturale di R ed S è la relazione 11

8 R A 1->A l····· R A 11 -> A 11

11

(:n: R A l··· ·· R A

11 •

YZ

(T ))·

S i otti ene così una relaz ione che ha co me attributi l'uni one di quelli degli operandi , con le ennupl e formate concatenando quell e di R ed S con valori uguali per gli attributi in comune (e togliendo naturalmente le coppie ridondanti ). La giunzione naturale, qu indi , è una comoda abbreviazione dell ' equijoin applicato a relazio ni in cui l'associazio ne fra le ennuple è descritta con la chi ave estern a e la chi ave primaria costituite da attributi uguali. Si noti che:

=

- se R ed S non hanno attributi comuni , R l>< S ={t E R l t [X ] E :n:x (S)},

dove X sono gli attributi co muni tra R ed S. Restitui sce le ennupl e di R che partec ipano all a giun zione natu rale di R ed S. Vale l'equi valenza R C>< S :n:hh- .. A ( R l>< T=

A

8

c

D

a1 a1 a2 a3

b1 b1 b1 b1

c1 c2 c1 c1

d1 d1 d2

A

8

c

a1 a1 a2

b1 b1 b1

c1 c2 c1

null

Proprietà algebriche degli operatori relazionali

Un'espressione dell 'algebra relazionale può essere trasformata in un 'altra equivalente sfruttando alcune proprietà degli operatori. Queste trasformazioni sono utili perché possono ridurre di ordini di grandezza il costo di esecuzione delle espressioni (riscrittura algebrica). Si consideri la rappresentazione di un 'es pressione algebrica come un albero le cui foglie siano le rel az ioni e i nodi interni sono gli operatori dell 'algebra; i fi gli di un nodo interno N sono gli operandi dell 'operatore associato al nodo N (si veda la Figura 4.1 0).

118

Capitolo 4.

© 88-08-07003-4

Il modello re/azionale

rr Nome

l t>=

Un ' espress ione Espr è definita dall a seguente grammatica: Espr ::= [ lde.]Attributo 1 Costante 1 ·'(" Espr ")" 1 [- ] Espr [ p Espr] l ( SUM l COUNT l AVG l MAX l MIN) " (" [ OISTINCT] [ lde.]Attributo " )" l COUNT " (" * " )" p ::= ( + l - l * l /)

Infine, un a tabella è data dall a seguente gramm atica:

180

Capitolo 6.

SOL per l'uso interattivo di basi di dati

© 88-08-07003-4

Tabella ::= /de l Tabella Giunzione Tabella [ USING " (" Attributo{, Attributo l ")" 1ON Condizione] Giunzione: := [ ( CROSS l NATURAL)) [ ( LEFT l RIGHT l FULL )] JOIN Operatorelnsiemistico ::= ( UNION [ALL) I INTERSECT [ALL) I EXCEPT [ALL))

Si noti che la sintassi permette di scrivere delle SELECT che non sono ammesse nel linguaggio. Un'interrogazione valida deve infatti soddisfare almeno i seguenti vincoli : le funzioni di aggregazione non possono essere usate nei predicati della clauso la WHERE ; - in un ' inten·ogazione senza GROUP BY, tutti gli attributi ne ll a clausola SELECT sono argomento di un a funzione di aggregazione oppure nessuna funzione di aggregazione può apparire nella clausola; - ricordiamo infine che in un ' interrogazione con GROUP BY, tutti gli attributi che appaiono nelle clausole HAVING e SELECT, non come argomento di una funzione di aggregazione, sono attributi di raggruppamento.

6.2

Operatori per la modifica dei dati I comandi per modificare i dati sono i seguenti: INSERT INTO Tabella [ " (" Attributo {, Attributo l ")" ] VALUES " (" Valore {, Valore }")"

per effettuare l'inserzione di un ' enn upla in una tabella. La lista valori deve ri spettare l' ord ine degli attributi o, in loro assenza, l'ordine specificato nella definizione della tabella. Per esempio, per inserire un nuovo cliente: INSERT INTO Clienti VALUES ('A03', 'Rossi Mario', 'Roma', 10);

La modifica si effettua con il co mando UPDATE : Tabella UPDATE SET Attributo = Espr {, Attributo WHERE Condizione

= Espr)

Con un solo comando UPDATE si possono modificare uno o più attributi di un insieme di ennuple che soddi sfano una condizione. Si noti che l' ennupla è la più piccola unità di inserzione e l'attributo la più piccola unità di aggiornamento. Per esempio, se vogliamo assegnare a tutti gli agenti con supervi sore 's1 ' il nuovo supervisore 's2', possiamo scrivere: UPDATE Agenti SET Supervisore = 's2' WHERE Supervisore = 's1 ';

© 88-08-07003-4

6.3.

Il potere espressivo di SQL

181

Infine, il comando di cancellazio ne è il seguente: DELETE FROM Tabella WHERE Condizione Co me UPDATE, il co mando DELETE può coinvo lgere un a o più ennuple della tabell a come determinato dall a clausola WHERE. Per esempio, se vogli amo cancell are tutti gli ord ini precedenti al 2004, per cui l'agente corrispondente non esiste più nella relati va tabe lla, possiamo scrivere: DELETE FROM Ordini WHERE Data < '01012004';· .

6.3

Il potere espressivo di SQL Co me g ià accennato, il linguaggio SQL non ha la potenza co mputazionale delle Macchine di Turing, e quindi non permette di scrivere espress ioni equivalenti a tutte le fun zioni calcolabili . Un a tale limitazione non è un grosso problema prati co perché le interrogaz ioni che non si possono esprimere non sono molto co muni . Quando si presentano occorre usare l' SQL all'interno di un linguaggio di programmazione "Turing-equi valente" . La lj sta che segue mostra alcuni esempi di interrogazioni non esprirrubili in SQL.

l. Le funzioni di aggregaz ione di solito di sponibili non sono tutte quelle interessanti: se si vuole calcolare per esempio la moda, o la varianza, di una colonna di valori , come altre importanti fun zioni di tipo stati sti co, siamo imposs ibilitati a farl o. Infatti , se queste operazioni non sono fornite co me primiti ve (né potrebbero esserlo tutte), non è possi bile esprimerle come semplici espressioni sugli attributi (richiedono infatti uno o più "cicli" di calco lo sui va lori di un a colonna). 2. Le fun zioni di aggregazione no n si possono applicare ad altre fun zio ni . Per esempi o, no n si può calcolare il totale di tutte le medi e de ll 'ammontare deg li ordini degli agenti , o il mass imo di tutti i loro totali di vendita.4 3. La possibilità di creare " re port" con la clausola GROUP BY è molto limitata ri spetto a quelle offerte da un linguaggio di tipo general e. Per esempi o, non possiamo creare una tabell a che contenga per certi intervalli di ammontare di ordini il totale delle vendite relati ve ad ogni intervall o . 4. Le condizioni permesse impedi scono alcuni tipi di interrogazioni. Per esempio, supponi am o di avere le seguenti tabelle per trattare documenti e le parole chiavi che ne descri vono il contenuto: Documenti(CodiceDocumento, TitoloDocumento, Autore) ParoleChiave(CodiceDocumento, ParolaChiave)

4. Per ri solvere questi problemi si può ri con ere all ' espedi ente di defi nire tabelle deri vate, come sa rà mostrato nel prossimo capitolo.

182

Capitolo 6.

© 88-08-07003-4

SOL per l'uso interattivo di basi di dati

È semplice trovare i titoli dei documenti con una certa parola chiave oppure che contengono tutte le parole chiave di un certo insieme K , ma non è possibile scrivere un 'i nterrogazione per trovare tutti i documenti che contengono almeno k delle chiavi di K (problema tipico di information retrieval) . Per esempio, per trovare i documenti che contengono quattro chiavi di un insieme di sei chiavi occorre invece formulare (6 x 5) / 2 = 15 interrogazioni. 5. La chiusura transitiva di una relazione binaria rappresentata in forma di tabella non può essere calcolata (ma alcune varianti di SQL prevedono un operatore apposito). Per esempio, supponiamo che non solo gli agenti ma anche i loro supervisori possano avere un supervisore. Con gli operatori visti non è possibile trovare tutti_! supervisori, di qualsiasi livello, di un agente. Come si vede da questi esempi, quindi, il linguaggio SQL non è sufficiente per esprimere interrogazioni di qualsiasi natura, ma è stato definito prevedendo gli operatori più utili per le interrogazioni più comuni. Diverso è il caso del suo uso in un linguaggio di programmazione, come vedremo nel capitolo sullo sviluppo di applicazioni: lì è usato come un ' insieme di operatori "primitivi" (anche se non certo elementari) per operare sulla base di dati, mentre il linguaggio di programmazione utilizza i risultati delle interrogazioni per esprimere computazioni qual siasi.

6.4

QBE: un esempio di linguaggio basato sulla grafica Il linguaggio QBE (Query by Example), sviluppato alla IBM negli anni ' 70, è un esempio di linguaggio per il calcolo relazionale di domini, basato su un ' interfaccia grafica. Le interrogazioni sono formulate usando rappresentazioni grafiche delle tabelle come mostrato in figura: Clienti

Ordini

NumOrdine

CodiceCiiente

CodiceCiiente

Nome

CodiceAgente

Città

Sconto

Prodotto

Data

Ammontare

Questo modo di visualizzare le tabelle è quello originariamente previsto per i terminali a caratteri. Con i moderni sistemi provvisti di interfacce grafiche le cose cambiano molto e un esempio molto noto è Microsoft Access. Per formulare un'interrogazione, l'utente riempie le righe con esempi di valori che desidera nel risultato e con variabili che assumono valori nei domini di certe colonne. Per distinguere costanti da variabili , queste ultime iniziano con il carattere"_" . I campi che si vogliono vedere nel risultato sono quelli in cui si pongono i caratteri " P .". Un valore può essere preceduto da un operatore di confronto. Tutte le condizioni espresse nella stessa riga sono in ANO e quelle su righe diverse sono in OR. Per esempio, per trovare il codice e la commissione degli agenti di Pisa, lo scheletro della tabella si riempie nel modo seguente

© 88-08-07003-4

6.5.

183

Conclusioni

Agenti

CodiceAgente P ._x

Nome

Zona Pisa

Supervisore

Commissione P._y

A di fferenza dell ' SQL, QBE restituisce se mpre insiemi , mentre per mantenere nel ri sultato ennupl e uguali si usa " P. all". Condi zioni più co mplesse si danno separatamente in una condition box, senza usare l' operatore di negazione "..,", che va eliminato quindi usando le class iche equi valenze: ..,.., c l = c1 .., cc 1 1\ C2) = .., c 1 v .., c 2 .., cc 1 v C2) =.., c l 1\ ..,C2

Si "spinge" poi la negazione verso l' interno di qualunque condi zione, fin o ad accostarl a alle condi zioni atomi che, che a loro vo lta sono in grado di assorbirl a, grazie alle eq ui valenze:

=y ..,x i- y -,x < y

..,x

=x i- y =x

=x

= y ~

y ecc.

Per esempi o, per trovare il nome dei clienti che hanno fatto ordini con ammontare superi ore a l O000 euro, si pone: Clienti

Ordini

NumOrdine

CodiceCiiente _x

CodiceCiiente

-Y

6.5

Nome P.

CodiceAgente

Città

Sconto

Prodotto

Data

Ammontare ;:: 10000

Conclusioni Sono state presentate le caratteri stiche del linguaggio SQL per il recupero dei dati . SQL è ormai uno standard ed è offerto da tutti i sistemi , anche se continu ano ad esistere differenze fra le versioni dei sistemi commerciali più diffu si. Molti sistemi prevedono interfacce grafiche per facilitarne l'uso interatti vo, ne ll o stil e di Access, un prodotto de ll a Microsoft molto popolare in ambi ente Windows. Nel prossimo capitolo si vedranno gli altri comandi deii ' SQL per definire e amministrare basi di dati e poi come si possa usare in un linguaggio di programmazione per sviluppare applicazioni. Per fare pratica con l' SQL, dal sito del libro si può scaricare il sistema JRS , sviluppato in Java per scopi didattici presso il Dipartimento di Informati ca de ll ' Università di Pi sa, che funziona con ogni sistema operativo dotato di un a macchin a virtuale Java e supporta un 'ampia versione deii'SQL.

184

Capitolo 6.

SOL per l'uso interattivo di basi di dati

© 88-08-07003-4

Esercizi 1. Dare un 'espress ione SELE CT per stabi li re se i valori di A in un a relaz ione con schema R(A, B, C) siano tutti di versi. L'espress ione deve essere diversa da SELECT A FROM R. 2. Si rico rd a che il predicato IN è equi valente a =ANY. Sp iegare perché il predicato NOT IN non è equival ente a ANY ma a ALL.

3. È importante sapere quando un a SELECT ritorn a una tabell a con ri ghe di verse per ev itare di usare inutilmente la cl auso la DISTINCT, che comporta un cos to addi zionale per l' esecuzione dell ' interrogazione (perch é?). (a) è vero che co n una SELECT con una tabell a nell a parte FROM , e senza GROUP BY, non vi saranno ri ghe duplicate nel ri sultato se gli attributi dell a parte SELECT sono una superch iave dell a tabell a? (b) è vero che con una SELECT con piLI tabell e nell a parte FROM , e senza GROUP BY, non vi saranno ri ghe dupli cate nel risultato se gli attributi dell a parte SELECT sono un a superchi ave di ogni tabell a? (c) è vero che nessun a interrogazione con un GROUP BY può avere duplica ti nel ri sultato? Per og ni caso dare un esempi o di inteiTogazione che ritorn a duplicati se la condi zione non è verifi cata. 4. Si consideri lo schema relazionale Studenti(Matricola, Nome, Provincia, AnnoNascita) Esami (Materia, MatricolaStudente, Voto, NumAppello, Anno) Formul ar e in SQL le seguenti interrogazioni : (a) trovare il nome deg li studenti di Pi sa che hanno superato l 'esame di Progr ammazione con 30. (b) trova re il nome deg li studenti che hanno superato cinque esa mi . (c) trovare per ogni studente di Pi sa i l numero degli esami superati , il voto mass imo, minimo e medi o. (d) trovare per ogni materi a il numero degli esami fatti al pri mo appell o, i l voto mass imo, minimo e medi o.

5. Usando la base di dati relazionale ottenuta dali ' Esercizio 2.9, fo rmul are in SQL le seguenti interrogazi oni : (a) trovare il nome e l 'anno di nascita dei fi gli dell ' impiegato con codice 350. (b) trovare il nome e codice degli impiegati e il nome del dipartimento dove lavorano. (c) trovare il nome degli impi egati , il nome e l 'anno di nascita dei fi gli maschi a carico. (d) trovare, per ogni progetto in corso a Pi sa, il numero e il nome del progetto, il nome del dipartim ento dove si svo lge, il cognome del direttore del dipartimento. (e) trovare il nome dei dipartimenti con almeno un impi egato con persone a carico. (f) trovare il numero degli impi egati del dipartim ento di Inform ati ca. (g) trovare, per ogni progetto al quale l avorano più di due impi egati , il nome, il numero e il numero degli impi egati che vi lavorano. (h) trovare per ogni dipartim ento il nome, il numero degli impi egati e la medi a del loro anno di na cita.

© 88-08-07003-4

6.5.

(i) (j) (k) (l) (m) (n) (o) (p)

Conclusioni

185

trovare i nomi dei supervisori e dei loro dipendenti. trovare il nome degli impiegati e il nome del dipartimento in cui lavorano. trovare il nome degli impiegati senza fami liari a carico. trovare i progetti cui partecipa il sig. Ross i come impiegato o co me direttore del dipartimento che gesti sce il progetto. trovare il nome degli impiegati che hanno i fa mili ari a carico dello stesso sesso. trovare il nome degli impiegati che hanno tutti i fam iliari a ca rico de l proprio stesso sesso. trovare il nome degli impiegati che lavora no almeno a tutti i progetti dell"impiegato con codi ce 300. trovare il nome de l dipartimento e il numero di impiegati nati dopo il 1950. per i dipartime nti co n più di due impi egati.

Note bibliografiche Il lin guaggio SQL è trattato in ogni libro sull e basi di dati. Per un 'anali si più approfo ndita es istono numerosi testi spec ifi ci come [vdLO l], che viene venduto insieme ad un CD-ROM con una versione di un sistema relazionale. Per lo standard SQL-92, e per un ' introdu zione aii 'SQL:2003. si veda [KBLOS].

Capitolo 7

SQL PER DEFINIRE E AMMINISTRARE BASI DI DATI

In questo capitolo vengon o presentati i comandi SQL-92 per definire e ammini strare basi di dati. Il materiale è organizzato presentando nell 'ordine i comand i per: - definire una base di dati e la struttura logica delle sue tabelle, memorizzate o calcolate; definire i vincoli d' integrità sui valori ammissibili degli attributi di un 'ennupla, di ennuple diverse dell a stessa tabell a (vinco li intrarela zionali ) o di tabelle diverse (vincoli interrelazionali); - definire aspetti procedurali ne ll o schema de lla base di dati , sia sotto forma di procedure memorizzate sia di trigger; - definire aspetti fisici riguardanti criteri di memorizzazione dei dati e tipi di strutture di accesso per rendere più rapide certe operazioni su tabe ll e di grand i dimen sioni . Mentre gli aspetti precedenti fanno parte de l cosiddetto schema logico, gli aspetti fisici fanno parte del cosiddetto schema .fisico; - adeguare la base di dati a nuove esigenze che si manifestano durante il funzionamento a regime (evo luzione dello schema); - limitare i dati accessibili e le modalità d' uso agli utenti autorizzati. Poiché non tutti q uesti aspetti sono trattati dallo standard SQL-92, per alcuni di essi si presenteranno le soluzioni presenti in alcuni sistemi commercia li.

7.1

Definizione della struttura di una base di dati Un DBMS permette la creazione di più sc hemi all'interno di un ' unica base di dati. Uno schema, in questa terminologi a, corrisponde ad un insieme di tabelle, memorizzate e calcolate, proced ure, trigger, e agli altri "oggetti " che possono

188

Capitolo 7.

© 88-08-07003-4

SOL per definire e amministrare basi di dati

essere presenti in un a base di dati, ed è assoc iato ad un utente proprietario, c he stabilisce la la di sponibilità deg li oggetti in esso conte nuti ad altri ute nti . Negli esemp i che seguono si useran no i comandi SQL-92 nell a forma testuale, ma si tenga presente che di so lito i siste mi commerciali prevedono anche strumenti di tipo grafico interattivi, faci li da usare ma no n sta nd ard . Questi strumenti generano poi i comandi SQL che verran no eseguiti dal sistema. Come base di dati di riferimento si userà quella vista ne l capito lo precede nte, che per comodità si ri p011a in Figura 7. l .

Cod iceCiiente: Nome: Città: Sconto:

Clienti string stri ng string in t ~

Codice Cliente

NumOrdine: CodiceCiiente: CodiceAgente: Prodotto: Data: Ammontare:

CodiceAge nte: Nome: Zona : Superviso re: Commissione :

Codic~

Agente

i

Agenti string« PK>> string st ring string in t

l

l

Supervis ore

Ordini stri ng string«FK(Ciienti)» string«FK(Agenti)» string string in t

Figura 7.1. Rappresentazione grafica dello schema esempio.

Premetti amo, infine, un a caratteristi ca importa nte de i siste mi relaz ion ali : lo sche ma di una base di dati si costrui sce increme ntalmente con opportuni comandi (per esemp io CREATE TABLE) dati interattivamente, o attraverso uno strumento grafico, e tutte le definizioni so no me mori zzate ne ll a " metabase di dati", o catalogo del sistem a, la c ui struttura verrà di scussa piì:1 avanti . Non es iste, quindi, in gene rale, un "testo" me morizzato da qu alche parte con tutte le definizioni c he costitui scono lo sche ma; è però poss ibile usa re opportuni programmi SQL che producono din a mica mente un testo di questo tipo interrogando il catalogo e sta mpando i ri sultati.

7.1.1

Base di dati

Lo sc hema di una base di dati viene c reata co n il comando: CREATE SCHEMA Nome AUTHORIZATION Utente Definizioni

dov'e Nome è il no me dello sche ma della base di dati c he viene c reata, Utente è il nome dell'utente proprietario, e Definizioni sono i co mandi per la creazione degli elementi della base di dati (tabelle, viste, indici ecc.). Come detto precedentemente, questi ele menti possono essere creati o modificati in un qualunque momento success ivo, durante un a sessione d ' uso dell o schema de ll a base di dati, co n gli opportuni comandi . Uno schema di base d i dati può essere rimosso con il comando: DROP SCHEMA Nome [ RESTR ICT l CASCADE ]

© 88-08-07003-4

7.1 .

Definizione della struttura di una base di dati

189

Con la form a RESTRICT l' operazione fallisce se vi sono ancora dati , mentre con la forma CASCADE si rimuovono automaticamente tutti i dati in essa presenti. 1

7 .1.2

Tabelle

La forma base del comando di creazione di una tabella è la seguente: CREATE TABLE Nome " (" Attributo Tipo [Vincolo {, Vincolo l] {, Attributo Tipo [Vincolo {, Vincolo l] l [, VincoloDiTabella {, VincoloDiTabella l ] ")"

I vi ncoli saranno discussi in dettaglio nella sezione 7.2. I tipi più co muni per i valori degli attributi sono: - CHAR(n) per stringhe di caratteri di lunghezza fissa n; VARCHAR(n) per stringhe di caratteri di lunghezza variabile di al massimo n caratteri; INTEGER per interi con la dimensione uguale alla parola di memoria standard dell 'elaboratore; REAL per numeri reali con dimensione uguale alla parola di memoria standard d eli' elaboratore; NUMBER(p,s) per numeri con p cifre, di cui s decimali ; FLOAT(p) per numeri binari in virgola mobile, con almeno p cifre significative; DATE per va lori che rappresentano istanti di tempo (in alcuni sistemi, come Oracle), oppure solo date (e quindi insieme ad un tipo TIME per indicare ora, minuti e seco ndi ). Vediamo un esempio di definizione di una tabella, per ora senza vincoli: CREATE TABLE Clienti ( CodiceCiiente CHAR(3), CHAR(30) , Nome Città CHAR(30) , Sconto INTEGER ); Una tabella si può anche creare inserendovi immediatamente un insieme di en nupl e ottenute come risultato di un a espressione SQL: CREATE

TABLE Nome AS EspressioneSelect;

Per esempio, i seguenti comandi creano una tabella che rappresenta un archi vio storico contenente informazioni sugli ordini precedenti al 2003, togliendoli dall a tabella corrente: CREATE

TABLE ArchivioStoricoOrdini AS SELECT

l. Una regola generale del linguaggio è che per ogni comando CREATE Elemento vi è un COITispondente comando di cancellazione DROP Elemento.

190

Capitolo 7.

DELETE

SOL per definire e amministrare basi di dati

FROM WHERE

Ordini Data < '01 012003';

FROM WHERE

Ordin i Data < '01012003';

© 88-08-07003-4

Un a tabell a può essere eliminata con il co mando : DROP TABLE Nome

7.1.3

Tabelle virtuali

Oltre all a costruzione di tabelle normali , contenenti dati , (tabelle di base), si possono definire de ll e tabelle. ~irtuali con il comando: CREATE

VIEW Nome Vista [ " (" Attributo {, Attributo) " )" ] AS EspressioneSelect

Un a tabell a virtu ale, o vista (view) , è il ri ultato di un 'espress ione SQL a partire da altre tabe lle, ia base che virtuali . Il contenuto di una tabe lla virtu ale non è fis icamente memori zzato nell a base di dati , ma solo l'espressione SQL che la defini sce viene me mori zzata nel catalogo del sistema. In generale, il contenuto viene calco lato ogni vo lta che la tabell a virtu ale viene usata come se fo sse un a normale tabell a in un ' interrogazione, tranne in quei cas i in cui I' ottimi zzatore del sistema sia in grado di stabilire che l' interrogazione possa essere ''riscritta" combinando la con l'espress ione SQL che defi ni sce la tabell a virtuale. Per esempi o, la seguente vista: CREATE VIEW AS SELECT FROM GROUP BY

OrdiniPerAgente(CodiceAgente, TotaleOrdini) CodiceAgente , SUM(Ammontare) Ordini CodiceAgente;

descri ve un a tabella virtu ale formata, per ogni agente che ha fatto qualche ord ine, dal codice dell ' agente e da l total e dei suoi ordini. Un ' interrogazione come: SELECT FROM WHERE

a.Nome, TotaleOrdini Agenti a, OrdiniPerAgente o a.CodiceAgente = o.CodiceAgente ANO TotaleOrdini > 1000 ;

può essere ri sc ritta co me: SELECT FROM WHERE GROUP BY HAVING

a.Nome, SUM (Ammontare) AS TotaleOrdin i Agenti a, Ordi ni o a.CodiceAgente = o.CodiceAgente a.CodiceAgente, a.Nome SUM (Ammontare) > 1000;

Una tabell a virtu ale può co mparire in una espress io ne SELECT esattamente come un a tabell a base, mentre le operazio ni di modifi ca su una tabe ll a virtu ale sono soggette a restrizioni , perché non sempre sono riconduc ibili a modifi che sull e tabelle base usate per definirl a. In parti co lare, le modifi che so no ammesse

© 88-08-07003-4

7 .1. Definizione della struttura di una base di dati

191

solo quando la tabella virtuale è defi nita con un 'espressione che soddi sfa le seguenti condizioni:

-

la clausola SELECT non ha l' opzione DISTINCT e i valori degli attributi della tabell a virtuale non sono calcolati; la clauso la FROM riguarda una so la tabella base o virtuale, a sua volta modificabile, ovvero sono escl use tabelle vi rtu ali ottenute per giun zione; la clausola WHERE non conti ene SottoSelect; non sono presenti gli operatori GROUP BY e HAVING ; le colonne definite nelle tabelle di base con il vincolo NOT NULL devono far parte della tabell a virtu ale.

Per ese mpio, la vista precedente non può essere usata per modifi che, dato che conti ene un attributo calco lato (TotaleOrdini). Con l' introduzione delle tabell e virtuali occorre rivedere in genera le il comando di cancellazione delle tabelle, sia base che virtu ali. Infatti , se una tabella è utili zzata nella definizione di un 'altra virtuale, al momento dell a sua cancell azione si può specificare quale azio ne intraprendere: DROP ( Tabella l Vista) [ RESTRICT l CASCADE]

In entrambi i casi, se viene specificato RESTRICT, la tabella o la vista non ve ngono rimosse se sono utili zzate in altre viste, mentre CASCADE provoca la rimozione automatica di tutte le viste che utilizzano la tabe ll a o la vista cancellata.

Uso delle tabelle virtuali Le tabelle virtuali sono utili per diverse ragioni: l . Per semplificare certi tipi di interrogazioni comp lesse, o addirittura non esprimibili in SQL su tabelle base. Per esempio, come già discusso nel capitolo precedente, se vog li amo trovare il numero medio degli agenti per zona, sarebbe un eJTore scrivere qualcosa del genere: SELECT AVG (COUNT(*)) FROM Agenti GROUP BY Zona;

Poss iamo però form ul are l' interrogazione con l' aiuto di una tabell a virtuale: CREATE VIEW AgentiPerZona (Zona , NumeroAgenti) AS SELECT Zona, COUNT(*) FROM Agenti GROUP BY Zona; SELECT AVG (NumeroAgenti) FROM AgentiPerZona; DROP

AgentiPerZona ;

2. Per nascondere alle app licazioni alcune modifiche dell 'organizzazione logica dei dati (indipendenza logica). Per esempio, supponi amo che per ogni

192

Capitolo 7.

SOL per definire e amministrare basi di dati

© 88-08-07003-4

zona vi sia un supervisore, che sia egli stesso un agente, ma privo di supervisore. La memorizzazione dei dati potrebbero essere cambiata nel modo seguente: (a) aggiungere una tabella contenente le zone e i relativi supervisori: CREATE TABLE SupervisoriPerZone AS SELECT DISTINCT Zona, Supervisore FROM Agenti WHERE Supervisore IS NOT NULL;

(b) togliere l'attributo Supervisore dalla tabella degli agenti: CREATE TABLE NuoviAgenti AS SELECT CodiceAgente, Nome, Zona, Commissione FROM Agenti ;

(c) cancellare la "vecchia" tabella degli agenti: DROP

Agenti ;

(d) costruire una vista che ricostruisce la "vecchia" situazione di agenti con l'attributo Supervisore: Agenti(CodiceAgente , Nome, Zona, Supervisore, Commissione) AS SELECT CodiceAgente, Nome, z.Zona, Supervisore , Commissione) FROM NuoviAgenti a, SupervisoriPerZone z WHERE a.Zona = z.Zona ANO CodiceAgente Supervisore UNION ALL SELECT CodiceAgente, Nome, z.Zona , NULL AS Supervisore, Commissione FROM NuoviAgenti a, SupervisoriPerZone z WHERE a.Zona = z.Zona ANO CodiceAgente = Supervisore;

CREATE

VIEW

3. Possono essere usate per dare visioni diverse degli stessi dati (viste utente). Per esempio, se vogliamo aggregare gli ordini per agente, per applicazioni di tipo stati stico, possiamo fornire la tabella virtuale creata all ' inizio di questa sezione.

7.2

Vincoli d'integrità I vincoli che possono essere espressi in uno schem a relazionale riguardano i valori ammissibili degli attributi di un 'ennupla, o di ennuple diverse della stessa tabella (vincoli intrarelazionali) o di tabelle diverse (vincoli interrelazionali) . Per impedirne la violazione, i vincoli d' integrità vengono controllati dal sistema quando si effettua una modifica della base di dati (operazioni INSERT, DELETE e UPDATE) che li coinvolge. Nel caso di violazione di un vincolo, l'azione eseguita dal sistema dipende da come è stato dichi arato il vincolo. In assenza di direttive esplicite, il sistema interrompe l'operazione annullando la transazione corrente, e segnala il fatto, come accade per esempio quando si

© 88-08-07003-4

7 .2 .

Vincoli d'integrità

193

cerca di inserire una ennupla che viola il vincolo di chiave prim ari a. Nel caso invece che sia stata specificata un 'azione da co mpiere per portare la base di dati in uno stato corretto (come è possibile fare per esempio per il vinco lo di chi ave estern a), il sistema si comporta di conseguenza. l . Vinco li su attributi di un 'ennupl a. (a) si può specificare che un attributo non possa avere il va lore NULL co n il vinco lo NOT NULL. Questo vincolo è implicito se l' attributo fa parte della chi ave primari a. (b) con la sintassi CHECK Condizione è possibile specificare con una condi zione i valori ammi s ibili de)) 'attributo. Per esempio, se vog li amo ri chiedere che l' ammontare minimo di un ordine sia 100, si pone Ammontare INTEGER NOT NULL CHECK (Ammontare > = 100) oppure se vog liamo imporre che un attributo Sesso abbi a solo va lori M o F, si pone Sesso CHAR(1) NOT NULL CHECK (Sesso IN ('M', 'F')) (c) si pu ò fare in modo che il sistema as egni un valore di def ault all 'attributo quando v iene inserita una ennupla con DEFAULT (Costante 1 NULL ). (d) è possibile definire vinco li fra i valori di attributi di versi di una stessa ennupl a; nella condizione non possono essere co involte altre tabelle: CHECK Condizione 2. Vinco li intrarelazionali . (a) il vinco lo UNIOUE ri chiede che non vi siano duplicati nei va lori dell 'attributo (cioè l' attributo è una chi ave). Si noti che la chi ave primari a deve invece essere dichi arata con il seguente vincolo di PRIMARY KEY. (b) è poss ibil e definire una chi ave prim ari a, anche f orm ata da più attributi , e assegnarl e un nome: PRIMARY KEY [NomeChiave] " (" Attributo {, Attributo) " )" Gli attributi delle chiavi devono essere dichi arati NOT NULL, e non vi può essere più di un vincol o di tipo PR IMARY KEY in una tabella. Una chiave pri maria è obbli gatori a quando i devono introdurre vinco li d' integrità referenzial i . (c) è possibile definire chiavi form ate da più attributi : UNIOUE " (" Attributo {, Attributo ) ")" 3. Vincoli interrelazionali . È possibile definire il vincolo d' integrità referenzi ale su chi avi esterne, con la seguente sintassi : FOREIGN KEY [NomeChiaveEsterna] " (" Attributo {, Attributo ) ")" REFERENCES TabellaReferenziata [ ON DELETE ( NO ACTION l CASCADE l SET NULL ) ]

194

Capitolo 7. SQL per definire e amministrare basi di dati

©

88-08-07003-4

dove TabellaReferenziata è una tabella per la quale è stata defi nita una chiave primari a (con l ' opzione PRIMARY KEY) il cui tipo è ugual e a quello degli attr ibuti specificati . Gli attributi di una chi ave estern a, al contrari o di quelli di una chiave, possono avere il valore NULL. Il vincolo d' integrità referenzi ale su chiavi estern e ha i seguenti effetti : - se si cerca di inserire una ennupl a nell a tabella con il valore della chiave esterna che non corri sponde ad un valore dell a chi ave prim aria in TabellaReferenziata , il vincol o viene violato e l' operazione fallisce; se si cerca di can ce ll ar~ .una ennupl a di TabellaReferenziata la cui chjave primari a è il valore di qualche chiave esterna nell a tabella (viol ando il vinco lo), si opera in base alla specifica del vincolo: (a) ON DELETE NO ACTION ri chiede il rifiuto dell ' operazi one e il f allimento della transazione. L ' assenza della specifica ON DELETE è equivalente a questa opzi one; (b) ON DELETE CASCADE richjede la cancellazione delle ennuple che hanno il valore della chiave estern a ugual e a quello della chiave primari a delle ennuple cancellate; (c) ON DELETE SET NULL ri chiede di assegnare il valore nullo agli attributi della chi ave estern a. - se si cerca di modi ficare una ennupl a assegnando agli attributi dell a chiave esterna un va lore che non corri sponde ad un valore della chiave primari a in TabellaReferenziata , oppure se si modifica il valore di una chiave primari a in TabellaReferenziata , di solito nei si sterill commerciali l 'operazione viene ri fi utata, mentre nei sistemi che seguono il livello intermedio dell ' SQL-92, con l 'opzi one ON UPDATE è prevista la possibilità di scelta dell 'azione da intraprendere come nel caso delle cancellazioni .

Esempio 7.1 Diamo lo schema SQL completo per la base di dati di Figura 6. 1: CREATE TABLE Clienti ( CodiceCiiente CHAR(3) NOT NULL, Nome CHAR(30) NOT NULL, Città CHAR(30) NOT NULL, Sconto INTEGER NOT NULL DEFAULT O CHECK(Sconto> = OANO Sconto < 100) , PRIMARY KEY pk_Ciienti (CodiceCiiente) ); CREATE TABLE Agenti ( CodiceAgente Nome Zona Supervisore Commissione PRIMARY KEY FOREIGN KEY CHECK

CHAR(3) NOT NULL, CHAR(30) NOT NULL, CHAR(8) NOT NULL, CHAR(3), INTEGER, pk_Agenti (CodiceAgente), fk_SupervisoreAgente (Supervisore) REFERENCES Agenti ON DELETE SET NULL, (Supervisore CodiceAgente OR Supervisore IS NULL) );

© 88-08-07003-4

7.3.

Aspetti procedurali

195

CREATE TABLE Ordini ( NumOrdine CodiceCiiente CodiceAgente Data Prodotto Ammontare PRIMARY KEY FOREIGN KEY

CHAR (3) NOT NULL, NOT NULL, CHAR(3) NOT NULL, CHAR(3) CHAR(8) NOT NULL, NOT NULL, CHAR(3) INTEGER NOT NULL CHECK(Ammontare > 100) , pk_Ordini (NumOrdine), fk _CiienteOrdine (CodiceCiiente) REFERENCES Clienti ON DELETE NO ACTION , FOREIGN KEY fk...AgenteOrdine (CodiceAgente) REFERENCES Agenti ON DELETE NO ACTION );

CREATE VIEW AS SELECT FROM GROUP BY

OrdiniPerAgente(CodiceAgente, TotaleOrdini) CodiceAgente, SUM(Ammontare) Ordini CodiceAgente;

CREATE VIEW AS SELECT

AgentiConOrdini a.CodiceAgente AS CodiceAgente, Nome, Zona, Supervisore, Commissione, TotaleOrdini OrdiniPerAgente o, Agenti a a.CodiceAgente = o.CodiceAgente;

FROM WHERE

Si noti la definizione dei vincoli e delle tabelle virtuali. Nella seconda, AgentiConOrdini, si utilizza la prima (OrdiniPerAgente), e non si dichiarano gli attributi della tabella, perché vengono presi quelli specificati nel SELECT.

7.3

Aspetti procedurali Nei sistemi relazionali commerciali si possono trattare nello schema aspetti procedurali definendo procedure o frigger. Le procedure memorizzate nella base di dati sono programmi che vengono eseguiti dal DBMS su esplicita richiesta delle applicazioni o degli utenti . I frigger, invece, sono anch 'essi delle procedure memorizzate nella base di dati, che però vengono attivate automaticamente dal DBMS quando si fanno determinate operazioni su lle tabelle.

7.3.1

Procedure memorizzate

Le procedure memorizzate nella base di dati sono state previste dall ' SQL-92 come procedure con un nome, parametri e un corpo costituito da un unico comando SQL, raggruppabili attraverso un meccanismo di moduli. Normalmente, però, i sistemi commerciali prevedono un linguaggio più ricco per definirle, come il linguaggio PL!SQL del sistema Oracle, che verrà presentato nel prossimo capitolo, insieme a esempi di procedure, e il Transact/SQL del sistema Sybase. Le procedure memorizzate nella base di dati sono utili per diverse ragioru: l . Consentono di condividere fra le applicazioni del codice di interesse generale. In questo modo si semplificano le applicazioni e quindi la loro

196

Capitolo 7.

2. 3.

4.

5.

SOL per definire e amministrare basi di dati

© 88-08-07003-4

manutenzione. Inoltre, essendo le procedure gestite in modo centrali zzato, una loro modifica no n ri chiede di essere riportata in tutte le applicazionj che ne fa nno uso; Consentono di garantire che certe operazioni sull a base di dati abbi ano la stessa semantica per ogru applicazione che ne fa uso; Consentono di controll are in modo centrali zzato certi vincoli d' integrità non esprimibili nell a defini zione delle tabell e; Consentono di ridurre il traffico sulla rete dovuto ad applicazioni remote: il programma cliente, invece di interagire con il DBMS servente spedendo un ' interrogazione per volta, spedi sce semplicemente una chi amata di un a procedura memori zzata, che viene eseguita dal servente, e ri ceve all a fin e solo il ri sultato final e; - . Consentono di garantire la sicurezza dei dati perché a certi utenti si può permettere di usare solo certe procedure per ottenere dei dati , ma no n di accedere direttamente alle tabelle dalle qu ali le procedure estraggono i dati restituiti .

L' uso delle procedure memori zzate nella base di dati pone però nuovi problemi nell a progettazione di bas i di dati , e le metodologie di sponibili non aiutano in genere a definire ed organi zzare tali procedure. Il loro uso pone, inoltre, nuov i problemj di carattere organi zzativo poiché richiede un a nuova fi gura professionale, l' amministratore delle procedure, che può essere diverso dal tradi zionale amministratore dei dati .

7.3.2

Trigger

I trigger sono presenti in tutti i sistemj commerciali più sofi sti cati, sebbene no n siano stati previ sti dallo standard SQL-92. Un trigger specifica un 'azione da atti vare automati camente al verificarsi di un 'operazione di modifica su un a tabella ( INSERT, UPDATE, DELETE) . Come esempio, riporti amo la form a base del comando per creare trigger in PLISQL: CREATE

TRIGGER NomeTrigger Tipo Trigger ( TipoOperazione (OR TipoOperazione}) [OF Attributo] ON NomeTabel/a [FOR EACH ROW ] (WHEN "(" Condizione " )" ] Programma

TipoTrigger := ( BEFORE l AFTER ) TipoOperazione := ( SELECT l DELETE

l INSERT l UPDATE )

Nell a definizi one si specificano le seguenti informazioni: - il tipo essere il tipo mente

di trigger ( BEFORE, AFTER) per stabilire qu ando il trigger debba atti vato, se prima o dopo l' operazione; di operazione che attiva il trigger e su qu ale tabella (ed eventu alsu quale attributo) ;

© 88-08-07003-4

7 .3. Aspetti procedurali

197

- un 'eventual e clausola FOR EACH ROW per stabilire qu ante vo lte il frigger debba essere attivato, se una volta oppure tante vo lte quante sono l e righe della tabella interessate dall 'operazione; - un 'eventual e ulteriore condi zione che deve essere vera perché il codice del frigger venga eseguito;

- il codice da eseguire.

Esempio 7.2 Supponiamo che nella base di dati dell ' Esempio 7.1 gli ordini si ano fatture da pagare e che si voglia impotTe il vincol o che non si accettano nu ov i ordini da clienti con uno scoperto maggiore di l 0.000: CREATE TRIGGER ControlloFidÒ. BEFORE INSERT ON Ordini DECLARE DaPagare NUMBER; BEGIN SELECT SUM(Ammontare) INTO DaPagare FROM Ordini WHERE CodiceCiiente = :new.CodiceCiiente; IF DaPagare > = 10000 - :new.Ammontare THEN RAISE...APPLICATION_ERROR(-2061 , 'fido superato'); END IF; END; Nel corpo di un frigger, :new sta per il val ore della ennupl a da in serire o il va lore modifi cato, mentre :old per il val ore precedente. Quindi, in questo caso :new.CodiceCiiente è il val ore del campo CodiceCiiente dell 'ennupl a da in serire. Come ul teri ore esempio, mostri amo l ' uso di un fr igge r per mantenere una tabella memorizzata, ma aggiornata automaticam ente in f unzi one di un 'altra tabella, senza l ' uso di vi ste.

Esempio 7.3 Il seguente programma crea un a nuova tabella di coppie (agente, totale ordini effettuati ), e un frigger che automati camente, da questo momento in poi, manterrà aggiornata l a nuova tabella. CREATE TABLE Totali (CodiceAgente CHAR(3) , TotaleOrdini INTEGER); CREATE TRIGGER esempioTrig AFTER INSERT ON Ordini FOR EACH ROW DECLARE esiste NUMBER ; BEGIN /* Si controlla se l'agente dell'ordine e' gia' presente nella tabella dei totali */ SELECT COUNT(*) INTO esiste FROM Totali WHERE CodiceAgente = :new.CodiceAgente; IF esiste= O/* !.:agente non e' presente, deve essere inserita una nuova riga */ THEN INSERT INTO Totali VALUES (:new.CodiceAgente, :new.Ammontare); ELSE

198

Capitolo 7.

SOL per definire e amministrare basi di dati

© 88-08-07003-4

UPDATE Totali SET TotaleOrdini = TotaleOrdini + :new.Ammontare WHERE CodiceAgente = :new.CodiceAgente; END;

S i noti che :new.CodiceAgente rappresenta il va lore del campo CodiceAgente della riga di Ordini inserita. Se vog li amo anche cancell are la riga dell a tabell a Totali qu ando l'agente corri spondente viene cancell ato, è suffic iente il seguente frigger: CREATE TRIGGER esempio2Trig AFTER DELETE ON Agenti FOR EACH ROW BEGIN DELETE Totali WHERE CodiceAgente END;

= :old .CodiceAgente;

Uso dei trigger A seconda del loro uso, possiamo di videre i frigge r in passivi ed atti vi. Un frigger è passivo se serve a provocare un fallimento dell a transazione corrente sotto certe condi zioni , mentre un frigger è atti vo qu ando, in corri spondenza di certi eventi, modifi ca lo stato dell a base di dati (così, negli esempi precedenti , il primo è pass ivo mentre gli ultimi due sono atti vi). I frigger sono util i per di verse ragioni : l . Trigger pass ivi: (a) per definire vincoli d ' integrità non esprimibili nel modell o dei dati usati (per esempi o vincoli dinamic i); (b) per fare controlli sulle operazioni ammi ssibili degli utenti basati sui valo ri dei parametri di comandi SQL. Per esempi o, si possono inserire certi dati solo se il codi ce del dipartimento è quell o de ll ' utente che esegue l'operazione. 2. Trigger atti vi: (a) per definire le cos iddette regole deg l i affari (business rules), ovvero le azioni da eseguire per garantire la corretta evoluzione del sistema inform ati vo. Per esempio, le azioni per la manutenzione automati ca del magazzino, spedi zione automati ca di ordini e soll eciti , passaggio di documenti fra utenti di versi ecc.; (b) per memori zzare eventi sull a base di dati per rag ioni di controllo (a uditing and logg ing). Per ese mpi o, in un 'opportuna tabell a si registrano dati sull e operazio ni eseguite su tabe ll e riservate. In verità si memorizzano so lo gli effetti di transazioni terminate normalmente perché di so lito se un a transazione termina prematuramente anche gli effetti dei frigger vengono annull ati ; (c) per propagare su altre tabelle gli effetti di certe operazioni su tabe lle (base o calcolate); (d) per mantenere allineati eventuali dati dupli cati qu ando si modifica uno di essi;

© 88-08-07003-4

7 .3 . Aspetti procedurali

199

(e) per mantenere certi vincoli d ' integrità modificando la base di dati in modo opportuno; per esempio, quando una ennupla viene cancel lata, il vincolo referenziale può essere mantenuto in maniera attiva cancellando tutte le ennuple che fanno riferimento all a ennupla cancellata.

Vantaggi e problemi nell'uso dei trigger Poiché i trigger sono memorizzati nella base di dati e la loro atti vazione è sotto il controllo del DBMS , si hanno i seguenti vantaggi: l. Si semplifica la codifica delle applicazioni che non devono preocc uparsi dei contrali i effettuati dai frigger; 2. I trigger sono definiti e amministrati centralmente e quindi gli utenti che usano la base di dati , in modo interattivo o per mezzo di appli cazione, non possono evitare i controlli da essi garantiti. Un problema che si presenta nell ' uso dei frigger è che i sistemi commerciali adottano una diversa semantica per la loro atti vaz ione e prevedono una diversa modalità di interazione fra i meccanismi di atti vazione dei trigger e l' esecuzione della tran sazione che li attiva [Ff95]. In particolare, i punti principali che differenziano i vari sistemi sono: - Granularità. Se la modifica riguarda un insieme di ennuple (come è possibile per i comandi UPDATE , INSERT e DELETE), in alcuni sistemi il frigger viene eseguito una so la volta per il comando (trigger di comando), mentre in altri viene eseguito tante volte quante sono le ennuple modificate dal comando (trigger di riga). Per esempio, in Oracle è poss ibile scegli ere fra i due casi: con la specifica esplicita FOR EACH ROW si dichiara che il trigger deve essere attivato tante volte quante sono le righe modifi cate. Un approccio di verso è adottato da Sybase, dove un trigger è attivato una so la volta per comando. In questo caso si possono usare le tabelle speci ali inserted e deleted che contengono le righe inserite o cancellate dal comando (una modifica è considerata una cancell azione seguita da un ' inserzione). L'esempio precedente diventerebbe così: CREATE TRIGGER esempio3Trig AFTER DELETE ON Agenti BEGIN DELETE Totali WHERE CodiceAgente IN (S ELECT deleted.CodiceAgente FROM deleted) ; END; - Risoluzione dei conflitti. Se è possibile definire più trigger attivabili dallo stesso comando, in alcuni sistemi l'ordine di definizione dei trigge r stabilisce anche l'ordine in cui vengono attivati (Oracle), in altri sistemi si può specificare in quale ordine vanno attivati, in altri ancora l'ordine è stabilito dal sistema. - Trigger in cascata . Se un trigger T 1 provoca l'attivazione di un altro T2 (frigger in "cascata", cascade trigger, o annidati , nesfed trigger), s i possono creare dei cicli se T2 provoca l'atti vazione di T 1 (trigger ricorsivi). In

200

Capitolo 7.

SOL per definire e amministrare basi di dati

© 88-08-07003-4

Sybase è possibile scegliere se permettere o meno le attivazioni in cascata (e in questo caso se permettere attivazioni ricorsive), mentre in Oracle le attivazioni ricorsive sono proibite. Esecuzione dei trigger. Di so lito l' azione di un trigger viene eseguita immediatamente come parte della tran sazione che lo ha attivato. Un ' altra possibilità da prevedere sarebbe di poter specificare che l'azione di un frigger andrebbe eseguita solo alla fin e della tran sazione che lo attiva (esecuzione differita). Questa possibilità sarebbe utile nel seguente caso: l. Supponiamo che esista un trigger T che elimina un dipartimento quando questo non ha un direttore; 2. Viene eseguita una transazione che elimina un impiegato direttore di un dipartimento, al quale assegna poi un nuovo direttore. Con l'esecuzione immediata di T il dipartimento viene eliminato, mentre con l' esecuzione differita di T la transazione produce l' effetto voluto. - Interazione con l e transazioni. Un altro aspetto critico è l' interazione dell'esecuzione dell'azione di un trigger con l'esec uzione della tran sazione che lo attiva. Di solito l'azione diventa parte della transazione che viene eseguita globalmente in modo atomico: se l'azione abortisce, abortisce anche la transazione e viceversa. In generale questo modo di procedere è quello desiderato, ma es istono casi in cui non lo è. Un esempio è quando un trigger viene usato per memorizzare eventi sulla base per ragioni di controllo, visto in precedenza: se una transazione legge un dato questo evento va registrato in un 'opportuna tabell a, anche nel caso in cui la transazione fallisca. Un'altra poss ibilità sarebbe di poter specificare che l'azione di un frigger vada eseguita come una transazione indipendente da quella che lo attiva. Oltre a queste difficoltà semantiche, i trigger presentano problemi per ciò che riguarda la loro progettazione e la rea lizzazione di applicazioni in un ambiente in cui se ne faccia uso. Per ciò che riguarda la progettazione dei trigger, il problema ri siede nel fatto che molte metodologie, tra cui quella descritta nei primi capitoli di questo testo, non forniscono indicazioni riguardo all ' utili zzo dei frigger, analogamente a quanto è già stato osservato a proposito delle procedure memori zzate. Tuttavia, una corretta progettazione dei frigger è cruciale per evitare poi problemi nella fase di realizzazione delle applicazioni. Per ciò che riguarda la realizzazione delle applicazioni in un ambiente in cui sui dati siano definiti dei trigger, poss iamo citare in particolare due problemj: l. Complessità: chi realizza un 'applicazione, per conoscerne gli effetti, deve capire non so lo in che modo l' applicazione modifica la base di dati in modo diretto, ma anche qual è l'effetto dei frigger attivati da tale applicazione. Questo aumenta in generale la complessità della progettazione delle applicazioni. La situazione è ancora più complessa quando si utilizzano trigger attivi, poiché questi possono provocare l'attivazione indiretta di ulteriori frigger. In questa situazione, il comportamento del sistema tende a diventare imprevedibile, principalmente perché è difficile capire in che ordine

© 88-08-07003-4

7.4.

Progettazione fisica

201

e in che esatto momento i diversi trigger vengono effettivamente eseguiti. Trattandosi però di trigger che modificano lo stato , il tempo di esecuzione ne influenza in generale la semantica, che tende quindi ad uscire dal controllo del programmatore. A questo proposito, molti sistemj defini scono dei meccanismi automatici per impedire l' attivazione mutuamente ricorsiva di più frigger , a dimostrazione di quanto siano comuni situazioni in cui il co mportamento di un insieme di frigger travalica le intenzioni di chi li ha di segnati. 2. Rigidità: un frigge r , in genere, costringe al rispetto di un certo vincolo adottando una certa strategia; per esempio, potrebbe forzare il vincolo che ogni dipartimento ha un direttore cancellando i dipartimenti che ne sono privi. Se una specifica applicazione intende mantenere lo stesso vi ncolo con una strategia diversa, questa app licazione può finire in conflitto con il frigger, come esemplificato in precedenza nel caso di una app li cazione che vonebbe cancellare il vecchio direttore e fissarne uno nuovo. In questo caso l' applicazione è costretta a cercare un modo per convivere con il frigger, poiché non è poss ibile, in generale, evitarne l'attivazione. Concludiamo questa sezione accennando alle basi di dati attive: sono basi di dati in cui l'uso dei trigger è notevo lmente ampliato al fine di definire delle regole (dette regole ECA, evento-condizione-azione) , in cui gli eventi sono molto più ampi di quelli classici (per esempio eventi temporali , eventi su condizioni qualunque, eventi composti , eventi esterni ecc.), e i meccarusmi di valutazione delle regole sono più sofisticati . Queste regole vengono usate in maniera estensiva per arricchire gli aspetti funzionali delle basi di dati gestite, rendendole utili zzabili per lo sviluppo di applicazioni più sofi sticate di quelle normalmente di sponibili. Per approfondire l' argomento, e per esempi di DBMS attivi, si rinvi a ai riferimenti riportati nelle note bibliografiche.

7.4

Progettazione fisica La progettazione fisica di una base di dati è molto critica perché comporta numerose deci sioni che devono tener conto delle caratteristiche del DBMS e del tipo di uso che le applicazioni fanno della base di dati. Per il carattere non speciali stico del testo , ci limiteremo a ricordare che le principali informazioni che vanno fornite dalla progettazione fi sica di una base di dati relazionale sono: distribu zione delle tabelle sugli archivi del sistema operativo; è necessario stabilire quali arcruvi contengano le tabelle, fornendo in particolare la possibilità di spezzare una singola tabella su archivi di versi, e di mantenere più tabelle in un singolo archivio; - dimen sioni degli archivi e loro organizzazione; l'organizzazione di un archivio deterrillna, per esempio, se i record sono inseriti nella tabella in ordine di arrivo, oppure ordinati sul valore di un attributo, oppure in base al ri sultato dell 'applicazione di una funzione hash al valore di un attributo. Le organizzazioru dei dati verranno presentate nel Capitolo 9; presenza di indici ; un indice su di un attributo A di una tabella è una struttura dati che permette di trovare rapidamente una registrazione nella ta-

202

Capitolo 7.

SOL per definire e amministrare basi di dati

© 88-08-07003-4

bell a a partire dal suo valore per l' attributo A. L'importanza degli indici nell 'esecuzione delle interrogazioni verrà mostrato nel Capitolo 9. Come per gli aspetti procedurali, le modalità di definjzione degli aspetti fisici di una base di dati non sono standardizzate. Vedremo quindi , a titolo di esempio, quelle previ ste in Oracle per la definizione degli indici.

7.4.1

Definizione di indici

Un indice su un attributo A di una tabella R è un insieme ordinato di coppie (a; , {r 1 )) , con a; un valore di A presente in un 'ennupla di R, e {rJ } un insieme di ri ferimenti all e enn uple di ·R con il valore a; di A. Un indice può essere anche definito su un insieme di attributi, e in q uesto caso il primo elemento della coppia è formato da una combinazione dei valori relativi. Di solito una tabella è memorizzata in modo seriale, mentre un indice è memorizzato con un a struttura ad albero per trovare con pochi accessi, a partire da un valore v, le enn upl e di R in cui il valore di A è in una relazione specificata con v . L'esistenza degli indici non cambia il modo in cui si formulano le intenogazioni (indipendenza fisica), ma viene sfruttata dall'ottimizzatore de l sistema per stabilire le strategie di esecuzione delle interrogazioni, in particolare se e quali indici usare. La creazione e distruzione di indici può essere fatta in ogni momento su tabelle già es isten ti : questa operazione può invalidare i risultati di ottim izzazio ni precedenti. La forma base del comando per creare indici è: CREATE

[UNIOUE)INDEX Nomelndice ON Nome Tabella " (" Attributo [ASC l DESC) {. Attributo [ASC l DESC] [TABLESPACE NomeArchivio] [STORAGE ParametriDiMemoria]

l ")"

L'opzione UNIOUE è usata per specificare che l' indice riguarda un attributo chi ave, TABLESPACE richiede la memorizzazione dell'indice nell'archivio specificato, e STORAGE modifica i parametri di all ocazione fisica default dell'archi vio. Le opzion i ASC e DESC sono usate per scegliere l'ord inamento per valori crescenti o decrescenti di un attributo, per default crescente. Un indice può essere elimi nato con il comando DROP INDEX Nomelndice. I sistemi costruiscono automaticamente un indice sugli attributi delle chiavi , per controll are facilmente che i loro valori siano diversi nella tabella.

Come scegliere gli indici

In generale non è semplice stabilire quali indici creare su una base di dati per migliorare le prestazionj complessive delle applicazioni. Infatti , se è vero che gli indici favoriscono le operazioni di ricerca, è anche vero che occupano memoria (di solito si stima che un indice occupa il 20% della memoria occupata dalla relazione), e vanno aggiornati ad ogni operazione INSERT, UPDATE e DELETE, aumentando i loro tempi di esecuzione. Altro aspetto che compli ca il

© 88-08-07003-4

7 .5.

Evoluzione dello schema

203

problema è che g li indici vanno scelti conoscendo le strategie di ottimizzazione del sistema per evi tare di costruire indi ci che non verranno mai usati . Sono stati studi ati algoritmi opportuni per scegliere gli indici ed alcuni sistemi forniscono strumenti per aiutare i l progetti sta nel farlo [AlbO l]. Si tengano comunque presenti i seguenti suggerimenti almeno per evitare scelte errate: l . Non creare indici su tabelle piccole, ovvero che occupano meno di sei pagine. 2. Non creare indic i su attributi poco seletti vi, ovvero che hanno pochi va lori diversi co me il sesso o lo stato c ivil e. 3. Evitare indic i su attributi modificati frequentemente. 4 . Prevedere più di qu attro indi c i per re laz ione solo se le operazioni di modifica so no rare . 5. Creare indi ci sull e chi av i estern e per agevolare l'esecuzione delle operazioni d i g iun zio ne. 6. Sono util i indici ordinati su attributi usati frequentemente ne ll e opzioni ORDER BY, DISTINCT e GROUP BY. Infatti , l'esec uzione di interrogazioni con queste opzio ni , in assenza di indi ci, comporta la creazio ne di tabelle temporanee da ordinare. 7. Prevedere indi ci su attributi usati frequentemente nelle operazioni di restrizio ne con co ndizione di uguagli anza o comunque molto restrittive.

7.5

Evoluzione dello schema Una caratteristica dei s istemi rel azionali , assente nei sistemi che li hanno preced uti , è la possibilità di modificare la struttura delle tabelle anche dopo che vi sono stati inseriti dei dati. In particolare, una tabell a può essere modifi cata con il co mando ALTE R TABLE per: l. Aggi un gere un nuovo attributo: ALTER TABLE Nome ADO Attributo Tipo

l valori de ll a nuova colonna saranno tutti nulli (e non sarà poss ibile imporre il vincolo NOT NULL prima di assegnare nuovi valori a tutta la co lonna); 2. Eliminare un attributo: ALTER TABLE Nome DROP Attributo

3. Modificare la defi nizione di un attributo: ALTER TABLE Nome MODIFY Attributo Tipo

Le mod ifi che di tipo sono soggette a certe restrizioni di compatibilità. Per esemp io, è poss ibile passare da INTEGER a FLOAT, o da CHAR (4) a CHAR (6), ma non da CHAR (4) a INTEGER ; 4. Cambiare il nome di un attributo: ALTER TABLE Nome RENAME VecchioAttributo NuovoAttributo

204

Capitolo 7.

SOL per definire e amministrare basi di dati

© 88-08-07003-4

5. Aggiungere o eliminare un vincolo d' integrità: ALTER TABLE Nome Vincolo ALTER TABLE Nome DROP Vincolo

Per esempio, se dopo aver creato la tabell a Ordini si vuole aggiungere un a colonna che registra i pagamenti effettu ati, assumendo che gli ordini già fatti siano stati tutti pagati, si può scrivere: ALTER TABLE Ordini ADO Pagato INTEGER; UPDATE Ordini SET Pagato

7.6

= Ammontare

Utenti e Autorizzazioni Per garantire la protezione dei dati da accessi non desiderati , i DBMS forniscono normalmente un sistema di permessi basato sui concetti di utente, autorizzazione (o privilegio) e profilo. Gli utenti sono creati dall ' amministratore dell a base di dati , e da questi possono ricevere le autorizzazionj di base, che gli permettono di ini ziare a lavorare (collegarsi, creare sc hemi e tabelle, ecc.). Se un utente crea un oggetto, come una tabella, a sua volta può autorizzare altri utenti a lavorare su di esso. Un 'autorizzazione è il permesso di eseguire una o più operazioni, e si indica con il nome dell ' operazione o con un nome simbolico (per esempio SELECT o CONNECT) . Un utente ha associato un insieme di autorizzazioni, che delimitano le operazioni che può effettuare (e i dati su cui può effettuarle). Per semplificare la gestione dell ' assegnazione delle autorizzazioni, so no definiti i profili , cioè insiemi di autorizzazioni che possono essere assegnati ad un utente in maniera globale, e che defini scono le categorie tipiche di utenti di una certa base di dati . Un utente viene creato con il seguente comando: CREATE USER NomeUtente PROFILE NomeProfilo IDENTIFIED BY Password DEFAULT TABLESPACE NomeArchivio TEMPORARY TABLESPACE NomeArchivio ACCOUNT UNLOCK

che crea un utente assegnandogl i un profilo, una password e degli spazi di lavoro. Il profilo conterrà tipicamente almeno le autorizzazioni di base (per esempio CONNECT, per collegarsi alla base di dati , o RESOURCE per costruire tabel le e altri oggetti di base). Oltre alle autorizzazioni associate ad un profilo, il proprietario di una risorsa può assegnare e ritirare singole autorizzazioni sulla ri sorsa con i seguenti comandi, dei quali si mostrano solo alcune possibilità, riferite a tabelle base e tabelle virtuali: GRANT Autorizzazioni ON Tabella TO (PUBLIC l Utente{, Utente }) [WITH GRANT OPTION]

© 88-08-07003-4

7 .7.

Schemi esterni

205

REVOKE [GRANT OPTION FOR] Autorizzazioni ON Tabella FROM Utente {, Utente }

dove le autori zzazioni possibili sono le seguenti : - SELECT per consentire l'accesso a tutte le colonne dell a tabella. - INSERT per consentire l'inserzione di ennupl e nella tabella. - UPDATE per consentire la modifica dei campi dell e ennupl e dell a tabell a.

La fom1a ristretta UPDATE (Attributi) autorizza la modifica solo dei ca mpi specifi cati . - DELETE per consentire la ~~mcel l az i o n e di ennuple dall a tabella. - ALL PRIVILEGES per consentire tutte le operazioni. Con il comando GRANT si autori zza l'uso di un a tabella a tutti ( PUBLIC) o solo ad alc uni utenti . Se viene specifi cato WITH GRANT OPTION gli utenti hanno a loro volta il diritto di concedere le stesse autorizzazion i ad altri utenti ancora (di nuovo con la clausola WITH GRANT OPTION). Con il comando REVOKE si tolgono delle autori zzazioni a certi utenti, oppure, semplicemente, il diritto che hanno a trasferirle ad altri utenti . La rimozione di un ' autorizzazione (o del diritto a trasmetterl a) ad un certo utente provoca in mani era automati ca la rimozione della stessa autorizzazione a tutti gli altri uten ti che l' avevano ricevuta da questo. Il meccanismo delle autorizzazioni , insieme alle tabell e virtuali, offre una grande flessibilità ne l contro ll o dell'accesso e della modifi ca dei dati . Per esempio, per accedere ad un a tabella virtuale V che usa nell a propria definizione una tabella R è sufficiente avere i diritti relativi a V . In questo modo è possibi le fornire ad un utente la possibilità di vedere o modificare solo quell a parte di una tabella reale che è rifl essa nell a tabella virtuale, senza concedergli alcun diritto sull a tabella reale.

7.7

Schemi esterni Uno schema esterno, secondo la proposta ANSVX3/SPARC citata nel Capitolo l , è la definizione della struttura della base di dati per un a certa classe di utenti e della modalità d'uso dei dati ad ess i consentita. I DBMS relazionali offrono soluzioni diverse per defi nire schemi esterni. l. Una base di dati è descritta da un uni co schema S e co n il meccani smo delle autorizzazioni si dichiara chi può accedere alle tabelle base o virtuali presenti nell o schema e con quali modalità. Esiste, quindi, un comando CREATE SCHEMA, ma non un comando CREATE EXTERNAL SCHEMA. 2. Si possono definire più schemi S; che usano tabell e base o virtuali presenti nello schema S che descrive la base di dati . Per ogni schema S; si autori zzano gli utenti con le possibilità prev iste nel caso precedente. Con questa soluzione ogni schema S; ha il ruolo di schema esterno come previsto dalla proposta ANSVX3/S PARC.

206

Capitolo 7. SQL per definire e amministrare basi di dati

© 88-08-07003-4

In entrambi i casi, le tabelle virtuali sono il meccani smo fondamentale per modificare la visione della struttura dei dati memorizzati e per garantire l'i ndi pendenza logica delle appli cazioni.

7.8

Cataloghi I sistem i relazionali prevedono che le informazioni relative all o schema (tabelle, viste, vi ncoli , trigger, utenti , autorizzazioni , indici ecc.), i cos iddetti metadati, vengano me mori zzati in opportune tabelle interrogabili da utente, dette

catalogo del sistema. Vediamo alcuni attributi di uìi campi one di possibili tabelle de l catalogo pe r raccog li ere informazioni su ute nti , bas i di dati , tabelle, colonne e indi c i: PASSWORD(NomeUtente, Parola Chiave) SYSDB(NomeBaseDati, Proprietario, Cammino, Commenti) SYSTABLE(NomeTabella, Proprietario, BaseODerivata, NumeroColonne, NomeArchivioFisico, Commenti) SYSCOLS(NomeColonna, Tabella, Numero, Tipo, Lunghezza, Defau lt, Commenti) SYSINDEX(Nomelndice, Tabella , Proprietario, NumeroColonna, Commenti) Altre tabell e, un a decina, contengono informazioni sui vinco li , le tabelle virtuali , le a utorizzazioni ecc. Altre informazioni raccolte nei cataloghi di sistema riguardano aspetti quantitativi sui dati, le statistiche, e sono utili zzate dall ' ottimizzatore delle interrogazioni . Normalmente le tabelle del catalogo sono consultabili dall'utente, ma non modifi cabili per impedire interferenze co n il funzionamento del sistema. Spesso queste tabelle sono delle "viste" di tabelle più complesse o vengono ri copiate dal siste ma in strutture dati in me moria temporanea e ottimi zzate per la valutazione de ll e interrogazioni. Un utili zzo importante dei metadati è la loro consultazione interattiva da parte degli ute nti (o dell 'ammini stratore) usando 1'SQL. Pe r ragio ni di completezza i metadati sarann o autorefe re nziati: per esempio, la tabell a SYSTABLE co nte rrà anche un a riga re lativa a se stessa. Quindi la struttura dei metadati stess i può essere consu ltata (natura lme nte conoscendo precedentemente un insieme mjnimo di informazioni essenziali ).

7.9

Strumenti per l'amministrazione di basi di dati Oltre al catalogo dei dati , molti altri strumenti sono offerti dai produttori di DBMS o da ditte indipendenti per assistere l'ammini stratore di basi di dati nell e numerose attività di sua competenza. Vediamone alcu ni per le attività considerate più critiche: l . Progettazione concettuale di bas i di dati e generazio ne dei coma ndi per la defi ni zione dei rel ativi sche mi relazionali ; 2. De fini zione dell a memori a da assegnare all e tabelle e ag li indi ci e sua ri organi zzazione in caso di eccess iva fra mme ntazione;

© 88-08-07003-4

7.1O.

Conclusioni

207

3. Controllo dell 'esecuzione di comandi SQL per migli orare le prestazioni delle appli cazioni critiche; 4. Piani ficaz ione ed esecuzione delle procedure per la generaz ione di copie di sicurezza dell a base di dati ; 5. Controll o del f unzionamento del DBMS e generazione di opportune statisti che su utili zzazione dell a memori a permanente e del buffer, operazioni di I/0, blocchi dei dati e condi zioni di stall a delle tran sazioni attive ecc.

7.10

Conclusioni Sono state presentate le caratteri sti che de li ' SQL per la definizione e amministrazione di basi di dati . Il linguagg io messo a di sposizione a questo scopo dai vari sistemi è in realtà, in genere, molto più complesso del sottoin sieme qui illustrato, ed è ricco di opzioni che differi scono in modo sostanzial e da un si stema ad un altro. Questo non dipende tanto dall a povertà dello standard, qu anto dal fatto che le attività di cui si occupa l'ammini stratore della base di dati, ovvero la definizione dell o schema fi sico, la gestione deg li schemi, degli utenti , dell e autori zzazioni e dell 'affid abilità, coinvolgo no quegli aspetti fi sici sui quali i vari sistemi di fferiscono in modo molto sensibile.

Esercizi 1. Si defi ni sca uno schema relazionale con i comandi CREATE TABLE per trattare le inform azioni e i vincoli d' integri tà sui dipendenti di un ' azienda, con attributi CodiceFiscale, Nome, AnnoAssunzione e Salario, e sui loro famili ari a carico, con attri buti Nome, AnnoNascita e RelazioneDiParentela. 2. Si supponga che sia stato defini to uno schema relazionale con le istruzioni: CREATE TABLE R (K CHAR(8) NOT NULL, A CHAR(8) , B CHAR(8) ) PRIMARY KEY (K) GRANT SELECT ON R TO caio e siano stati immess i dei dati in R. Usando i comandi : DROP TABLE Nome CREATE TABLE Nome (Attributo Tipo, ... ) AS ExprSQL CREATE VIEW Nome (Attributo, ... ) AS ExprSQL GRANT SELECT ON Nome TO Utente mostrare come si possa modificare lo schema in modo che i dati di R vengano memorizzati escl usiva mente nell e tabelle: R 1( K char(8) not null, A char(8)) R2( K char(8) not null , B char{8)) e l' utente " caio" possa continuare a lavorare sull a base di dati come se esistesse la tabell a: R(K integer(8) not null , A integer(8) , B integer(8)) .

208

Capitolo 7.

SOL per definire e amministrare basi di dati

© 88-08-07003-4

3. Definire lo schema per la base di dati rei azionale ottenuta dali 'Eserci-

zio 5.3. 4. Si mostri come trattare il vincolo di chiave esterna con i trigger. 5. Si ricorda che date due sottoclass i C 1 e C 2 di una classe C, diciamo che: (a) C 1 e C2 soddisfano il vincolo di copertura di C se C 1 u C2 =C ; (b) C 1 e C 2 soddisfano il vincolo di di sg iunzione se non hanno ness un elemento in comune. In generale si possono quindi avere quattro tipi di situazioni: (a) copertura disgiunta o partizione (vincolo di copertura e di disgiunzione); (b) copertura non disgiunta (solo vincolo di copertura); (c) sottoinsiemi disgiunti (solo vincolo di di sgiunzione); (d) sottoinsiemi non disgiunti (nessun vincolo). Si supponga di rappresentare C 1, C2 e C con tre relazioni RC 1, RC2 ed RC , con RC 1 ed RC2 che contengono gli attributi propri di C 1 e C 2 e una chiave esterna per RC . Si supponga di poter dichiarare nello schema solo il vincolo di chiave primaria e di chiave esterna. Si mostri se è poss ibile rappresentare i vincoli dei quattro tipi di sottoclassi con il comando create table.

6. Si risolva l'esercizio precedente usando i trigger.

Note bibliografiche Per maggiori dettagli sui comandi SQL per definire e amministrare basi di dati si rimanda ai testi citati nel Capitolo l , mentre per le estension i previste dei vari sistemi commerciali è necessario consu ltare i relativi manuali. Un testo molto util e per la messa a punto delle basi di dati che ogn i DBA dovrebbe consultare è [SB02]. I trigger e le basi di dati attive, con esempi di sistemi e metodologie di progetto, sono discussi in [WC96], [ZCF+97].

Capitolo 8

SQLPERPROGRAMMARE LE APPLICAZIONI

Un o dei principali obie tti vi de i propone nti dell ' SQL fu c he il lin guaggio dovesse essere utili zzabile direttame nte da utenti occasiona ti per inte rrogare bas i di dati , senza dover ri correre a programmi sv iluppati da espe rti . Per questa rag ione fu sub ito proposta anche una version e grafi ca de l li nguagg io per nascondere la sintass i SQL, c hi a mata Que ry By Example (Q BE). L'obi etti vo però è stato raggiunto solo in parte, perché a nco ra ogg i l'uso interatti vo di bas i di dati con il lin guaggio SQL è limitato a pe rsone co n compete nze tec ni c he, nonostante i progressi fatti co n le inte rfacce grafi che di ambi enti interatti vi tipo Mi c rosoft Access per W indows, versione moderna del QBE. Nell a maggioranza dei cas i occorre invece sv iluppare applicazioni interatti ve in modo che gli ute nti de l siste ma informatico possano usare i servizi offerti senza nessun a compe tenza spec ifi ca. Pe r questo è necessari o di sporre di oppo rtuni lin guaggi di programmaz io ne c he consentano sia l' accesso a bas i d i dati che la reali zzazione dell e interfacce gra fi che per il d ia logo con gli utenti. U n altro moti vo pe r cui ta li linguagg i sono necessa ri è la necess ità di sc rivere appli cazioni c he usano bas i d i dati pe r una gra nde varietà di compiti divers i: applicazio ni gesti ona li , a nali si compl esse, appli caz ioni web ecc. In tutti questi cas i la te nden za attua le è di usare SQL come compone nte dedi cata ali ' accesso ai dati all ' inte rno di un linguaggio di programmazione adatto al co mpito spec ifi co. La diffe re nza fra le varie soluzioni è data soprattutto dall a modalità di integrazio ne fra SQL e il linguagg io di program mazio ne. In generale le so lu zioni più comuni pos ono essere ragg ruppate nell e segue nti categori e: l . Lin guaggi di program mazio ne gene rale, co me C, C++, Java, Vis ual Bas ic, la c ui sintas i viene es tesa con costrutti SQL per operare sull a base di dati (s i di ce anche che ospitano l' SQL). 2. Lin guagg i tradi zionali co n i qu ali l'u so de ll a base d i dati avv iene attraverso la chi a mata di fun zio ni di un a o pportun a li breri a (App lication Programming Interface, A PI ).

210

Capitolo 8.

SOL per programmare le applicazioni

© 88-08-07003-4

3. Linguaggi cosiddetti della quarta generazione (4' 17 Generation Languages, 4GL), come lnformix 4GL, Oracle PLISQL, e Sybase Tran sact/SQL. Questi sono linguaggi di programmazione di tipo generale costruiti "attorno" ad SQL, nel senso che lo estendono con costrutti di controllo ed altri tipi di dati , ma si basano sul modello dei dati relazionali.

8.1

Linguaggi che ospitano l'SOL Un approccio classico allo sviluppo di applicazioni per basi di dati relazionali prevede l'immersione dei costrutti di SQL in un linguaggio di programmazione tradizionale (come COBOL, C, Basic, Java, C++) con una sintassi "aggiuntiva", senza alterare nè la sintassi corrente nè il sistema dei tipi. 1 Poiché in questi lin guaggi non è previsto il tipo relazione e il tipo ennupla, vengono usati opportuni accorgimenti per scambiare dati fra la "parte" SQL e la parte tradizionale del lin guaggio. I vantaggi di questo approccio sono diversi: - il costo ridotto di addestramento dei programmatori, che continueranno ad usare un linguaggio già conosciuto per la parte di app licazione che non tratta direttamente la gestione dei dati persistenti; - la semplicità della sintassi di estensione, che rende i programmi più comprensibili rispetto ad approcci basati su chiamate di funzione ; - la possibilità di usare meccanismi di controllo dei tipi per validare durante la compilazione la correttezza dell ' uso dei comandi SQL; - la possibilità di ottimizzare le interrogazioni durante la compi lazione del programma; - la possibilità di attivare meccanismi di sicurezza basati sull'analisi del codice SQL. Lo svantaggio principale, invece, è il fenomeno detto di impedence mismatch: la differenza fra i tipi di dati del linguaggio e quelli relazionali obbliga a curare la conversione dei dati fra i due diversi modelli. Per esempio, per trattare il risultato di una interrogazione SQL (una relazione, cioè un insieme) occorre usare costrutti iterativi propri del linguaggio, operando su un solo elemento all a volta. In questa sezione, si mostra come vengono immersi i comandi SQL (Embedded SQL) nel linguaggio Java. Il linguaggio risultante, detto SQLJ, presenta una serie di vantaggi : - è un linguaggio standard, definito dall'organismo internazionale di standard ISO, quindi i programmi scritti con questo linguaggio sono utilizzabili su DBMS diversi , al contrario di altre soluzioni basate su linguaggio ospite; - il traduttore dal linguaggio esteso al linguaggio di base, Java, è a sua volta scritto in Java, così come il sistema di supporto per l'esecuzione (SQLJ

l . In inglese ve ngono detti SQL embedded languages, cioè linguaggi co n SQL immerso.

© 88-08-07003-4

8.1.

Linguaggi che ospitano l'SOL

211

runtime), quindi , sfruttando la portabilità di Java, questa è un a solu zione di sponibile su moltissimi sistemi operati vi; vengono usati gli aspetti "object-oriented" di Java per semplificare la comunicazione fra le due compo nenti del linguaggio. In ogni caso, q ualunque sia il lin guaggio osp ite che si utili zza, un ' approccio al problema dell ' uso di basi di dati relazionali all ' interno di un linguagg io di programmazione deve risolvere i seguenti aspetti fon damentali: l. come indicare la conness ione all a base di dati e fo rnire le credenziali di utente; 2. come specificare i co mandi SQL, associando ad eventuali loro parametri dei valori calcolati dal programma; 3. co me accedere ai risultati di un comando SQL, in parti colare ad un a re lazione res tituita da un ' interrogazione; 4. co me gestire le condizioni anormali di esec uzione di un comando, ed eventualmente come gestire questo aspetto in relazione alle proprietà di atomi c ità di una transazione. Questi punti verranno esami nati ne l seguito per il linguaggio SQLJ, ma si tenga presente che le soluzioni adottate sono simili a quelle offerte da altri lin guaggi.

8.1.1

Connessione alla base di dati

Il concetto di connessione, o contesto di connessione (connection context), indi ca in generale il co ntesto di lavoro a cui dei comandi SQL fa nno riferimento. Un contesto spec ifica la base di dati a cui si fa riferimento, con quale no me di utente si accede, e qual'è il tipo dei dati utili zzati . Un contesto è un oggetto di una classe (o tipo oggetto) Java particolare, detta classe di contesto, che viene dichi arata e istanziata come nel seguente esempio: 2 Class.forName (DatabaseDriver); #sql context ClasseContesto; ClasseContesto contesto= new ClasseContesto(url , utente, password) ;

La prima riga serve per caricare nel sistema il driver di accesso alla base di dati , cioè la li breri a specifica al DBMS che si vuole utili zzare. Per esempi o, se vo lessi mo accedere ad un sistema Oracle con il dri ver JDB C dell a stessa azienda, dovremmo dare come parametro "oracle .jdbc.driver.OracleDrive r". La seconda riga è scritta con la sintassi SQLJ estesa (ogni comando SQLJ deve ini ziare con il simbolo #sql), e indica che nel programm a viene defi nita un a nuova classe di contesto, con campi e metodi predefi niti , chj amata in q uesto esempi o ClasseContesto. Infine nell ' ultim a ri ga si crea un a nuova istanza di questa classe, un oggetto d i no me contesto , che veiTà usato in tutte le operazioni successive. Il costruttore prende come parametri tre strin ghe: la prima è il riferimento all a base di

2. Vi sono in realtà diversi modi per creare una classe di contesto e una sua istanza. Ne li ' esempio viene mostrato il modo più semp lice.

212

Capitolo 8.

SOL per programmare le applicazioni

© 88-08-07003-4

dati, la seconda è il nome dell ' utente e la terza è la parola chiave d eli' utente specifìcato. 3

8.1.2

Comandi SQL

Una volta aperta una connessione, è poss ibile usare i comandi SQL premettendovi il simbolo #sql e il nome del contesto all'interno del quale devono essere eseguiti. Per esempio, se nella base di dati esiste una tabella Province con attributi Nome, Sigla, stringhe di caratteri, e NumeroComuni un numero intero, potremmo creare una nuova Provincia con la riga seguente: #sql [contesto]INSERT INTO Province VALUES (''Milano", "MI", 166 );

Normalmente, però, i dati in un comando SQL non sono costanti, ma valori di variabili del programma che vanno usate aggiungendo il prefi sso ":". Se volessimo così effettuare un 'i nserzione usando dati letti da terminale, potremmo scnvere: String provincia, sigla; int numeroComuni; ... lettura dei valori corretti nelle tre variabili sopra definite .. . #sq l [contesto]INSERT INTO Province VALUES (:provincia, :sigla, : numeroComuni) ;

L' uso dell e variabili consente il passaggio di dati non solo dal programma alla base di dati , come nell 'esempio precedente, ma anche nella direzione opposta, dalla base di dati al programma, usando la versione del comando SELECT esteso con la clausola INTO per assegnare a delle variabi li il valore degli attributi deli' unica ennupla del risultato di un a SELECT, come nel seguente esempio: int numeroProvince; #sql [contesto] SELECT COUNT(*) INTO :numeroProvince FROM Province ; System.out.println("ln Italia ci sono " + numeroProvince + " province.");

con la clausola INTO: Questa forma del comando SELECT non si può usare se il ri sultato è un insieme di ennuple, ma per accedere ad esse una per volta si utilizza il meccani smo dei cursori (chiamati in SQLJ, iteratori, o result set iterators).

8.1.3

l cursori

Un cursore è un oggetto che rappresenta un insieme di ennuple, con metodi che permettono di estrarre dali ' insieme un elemento all a volta. Per esempio, se vogliamo stampare tutte le province con più di 60 comuni, potremmo scrivere:

3. Per esempio il riferimento all a base di dati Orac le di nome acmedb sul server db.acme.com sarà: "jdbc :oracle :thin :@ db.acme.com:1521 :acmedb".

© 88-08-07003-4

8.1.

Linguaggi che ospitano l'SOL

213

#sql iterator lteratoreProvince (String nome, int comuni) ; lteratore Province province; #sql [contesto] province= {SELECT Nome, NumeroComuni FROM Province WHERE NumeroComuni > 60}; while (province.next()) { System.out.println(province.nome() + " " + province.comuni()) ; }

province.close() ; La prima riga, analogamente alla dichiarazione di una classe di contesto, è una dichiarazione di un a classe di iteratore di nome lteratoreProvince. Gli oggetti istanza di questa classe verr~nno usati per scorre re insiemi di e nnuple con due campi, una stringa e un intero. La seco nda riga dichiara una variabile di tipo iteratore, che viene ini zializzata nella terza riga al ri sultato di un comando SELECT. U ri sultato del comando è quindi un oggetto iteratore che ha il tipo compatibile con lteratoreProvince: infatti la SELECT effettua la proiezione su due attributi , il primo stringa e il secondo intero. Un oggetto iteratore ha associato in ogni istante un 'ennupla del ri sultato, che chiameremo riga corrente, oppure un valore nullo (all' inizio e alla fine dopo la scansione di tutte le ennuple). Il metodo booleano next ha un duplice scopo: ritorna vero o falso per indicare se ci sono ancora ennuple da scorrere, e fa diventare corrente l' ennupla successiva (o la prima, quando viene chiamato la prima volta). Quindi è sufficiente usarlo all ' interno della condizione del comando while per scorrere in sequenza tutte le ennuple del risultato e terminare il ciclo quando non ce ne sono più . Il corpo del ciclo, invece, mostra come viene usata l'ennupla corrente: attraverso dei metodi , con i nomi uguali a quelli dati nella dichiarazione della classe di iteratore, si selezionano i campi associati. Così il metodo nome restitui sce il valore dell'attributo Nome dell 'e nnupla corrente, mentre il metodo comuni restituisce il valore dell'attributo NumeroComuni . Alla fine della scansione l' iteratore viene chiuso, rilasciando così le risorse impegnate per la gestione del risultato.

8.1.4

Transazioni

Come abbiamo già visto nel Capitolo l , una transazione è un programma che non può avere un effetto parziale: la tran sazio ne termina correttamente, oppure, se si verifica un errore, ne vengono disfatti tutti gli effetti ed è come se la transazione non fosse mai iniziata. Come si concretizza questo concetto all'interno di un programma per basi di dati ? I vari linguaggi ri spo ndono in mani era diversa a questa domanda. SQLJ, in particolare, stabilisce la seguente regola iniziale: ogni singolo comando SQL è considerato una transazione a sè stante (regola di autocommit on). Dato che non sempre questa regola è soddi sfacente, per esempio perchè vog liamo fare una serie di letture e scritture che potrebbero essere completamente annullate in seguito al verificarsi di qualche evento particolare, è possibile imporre la regola di autocommit off: una tran sazione inizia con il primo comando SQL, prosegue con i comandi successivi, e termina solo quando si dà un comando esplicito di terminazione (con successo COMMIT o con fallimento ROLLBACK).

214

Capitolo 8.

SOL per programmare le applicazioni

© 88-08-07003-4

Se non viene spec ificato altrimenti , viene seguita la regola autocommit on; si può specificare quale delle due rego le segui re con un quarto parametro al costruttore di contesto: se questo è true si vuole il comportamento standard, se invece è false si vuole disabilitare l' autocommit. In questo secondo caso, un a transazione inizia co n il primo comando SQL e viene terminata dando il comando SQLJ : #sq l [contesto] COMMIT;

se vogli amo far termin are la transazione con successo e quindi salvare le modifi che, oppure #sq l [contesto] ROLLBACK;

se vogli amo far fallire la transazione annull ando tutte le modi fic he effettu ate dall ' ini zio. Si noti che la gesti one del fa llimento delle transazioni è indipendente dal veri ficars i di eiTori SQL all ' interno del programma. Infatti , quando un comando SQL provoca un errore, questo viene rifl esso nel programm a Java sotto fo rma di una eccezio ne di classe SQLException . Sta al programm atore gestire l'eccezione e decidere come comportars i ri spetto all a transazione corrente (in caso di autocommit off, dato che nell 'altro caso la transazione consiste solo dell' operazio ne SQL che ha provocato errore e che quindi non viene eseguita). Spetta quindi al programmatore la decisio ne della regola da segui re: nei casi più sempli ci è suffic iente lasc iare quell a default (autocommit on), mentre nei casi più compl essi sarà necessari o impostare autocommit off e gestire esplicitamente l' i11izio e la fin e dell e transazioni . Alla fin e di questo capi tolo, nell a Sez ione 8.4, questo argomento verrà di sc usso in dettaglio e verranno mostrati deg li esempi .

Esempio 8.1 Usando la base di dati del capitolo precedente, si mostra un programm a per (a) la stampa dell 'ammo ntare di un certo ordine, (b) l' aggiorn amento de ll a zona di un agente e (c) la stampa delle coppie (c li enti , ammontare degli ordini ) ordin ate in modo decrescente secondo l' amm ontare . import java.sql. *; import sq lj.runtime.*; public class Esempio ( public static void main (String [] args) ( try (

Il Connessione alla base di dati Class.forName ("oracle.jdbc.driver.OracleDriver''); #sql context ClasseContesto; ClasseContesto contesto = new ClasseContesto("jdbc:oracle :thin :@ localhost:1521 :mydb", "utente 1", "password 1");

Il Ricerca dell'ammontare di un certo ordine Il Lettura dei parametri

© 88-08-07003-4

8 .1.

Linguaggi che ospitano l'SOL

215

String numeroAgente = leggi("Numero agente: "); String numeroCiiente = leggi("Numero cliente : "); String numeroOrdine = leggi("Numero ordine : "); int ammontare; #sql [contesto] SELECT Ammontare INTO :ammontare FROM Ordini WHERE CodiceAgente = :numeroAgente ANO CodiceCiiente = :numeroCiiente ANO NumOrdine = :numeroOrdine;

Il Stampa ri su ltato System.out.println("Lammontare e': " + ammontare) ; Il Aggiornamento della zona di un agente numeroAgente = leggi("Numero agente: "); String zona= leggi("Zona: "); #sq l [contesto] UPOATE Agenti SET Zona= :zona WHERE CodiceAgente = :numeroAgente;

Il Stampa le coppie (numero cliente, ammontare ordini) Il ordinate in modo decrescente secondo l'ammontare #sql iterator lteratoriCiientiOrdini(String codCiiente , int ammontare) ; lteratoriCiientiOrdini risultato; #sq l [contesto] risultato = SELECT CodiceCiiente, SUM (Ammontare) FROM Ordini GROUP BY CodiceCi iente OROER BY SUM(Ammontare) OESC; //Stampa intestazione tabella System.out.println("Ci iente Uscite"); whi le (risultato. next()) { System.out.println(risultato.codCiiente() + "" + risultato.ammontare()) ; }

risu ltato.close() ; } catch ( SQLException e ) { System.err.println("SQLException " +e) ; } finally { try { contesto.close() ; Il disconnessione dal OBMS } catch ( SQLException e ) { System.err.println("SQLException " +e) ;

static BufferedReader reader = new Buffered Reader(new lnputStreamReader(System .in)) ; static String leggi(String messaggio) throws IOException { System.out.println(messaggio); return reader.readline();

216

8.2

Capitolo 8.

SOL per programmare le applicazioni

© 88-08-07003-4

Linguaggi con interfaccia API L'uso della base di dati con i comandi SQL immersi nel linguaggio ospite richiede la presenza di un compilatore apposito, o, come avviene più frequentemente, di un precompilatore che trasforma il programma nel linguaggio esteso in un programma nel linguaggio base con opportune chiamate al sistema a run-time del DBMS. Ci sono tuttavia casi in cui non è disponibile il precompilatore, oppure, per motivi di efficienza e di flessibilità, ci si vuole interfacciare direttamente dal programma con il sistema di gestione di basi di dati. In tali casi viene fornita una libreria di funzioni API da richiamare nel linguaggio tradizionale utilizzato passando opportuni parametri, che possono essere, per esempio, comandi SQL sotto forma di stringhe di caratteri, oppure informazioni di controllo o per lo scambio dei dati . La possibilità di passare al DBMS i comandi SQL sotto forma di stringhe, se da un lato co mporta lo svantaggio che eventuali errori nei comandi possono essere individuati solo durante l' esecuzione del programma, e non durante la sua compilazione, dall'altro permette l'utilizzo del cosiddetto Dynamic SQL. Con questo termine si intendono programmi in cui i comandi SQL non sono noti durante la scrittura del programma, ma vengono calcolati durante la sua esecuzione, per esempio leggendo] i come stringhe da terminale, o generandoli con informazioni ricavate dall ' accesso al catalogo della base di dati. In Figura 8. l viene mostrata la differenza fra i due approcci: quello del linguaggio ospite (linee contin ue) e delle chi amate dirette delle librerie messe a disposizione dal DBMS, nel caso del linguaggio Java (linee tratteggiate) .

Programma SQLJ

Programma Java con chiamate a SQLJ runtime

Bytecode Java con chiamate a JDBC

Bytecode Java con chiamate a SQLJ runtime

DBMS Server

Figura 8.1. Sviluppo di applicazioni con linguaggio ospite e con chiamate ad API del DBMS.

© 88-08-07003-4

8.2.

217

Linguaggi con interfaccia API

Le principali solu zioni adottate, per mantenere la portabilità del codice, prevedono l' util izzo di libreri e che, sebbene siano di verse per i vari DBMS e ambienti di esecuzione, hanno un ' interfacc ia standard , che viene usata all ' interno dei programmi applicativi sempre nello stesso modo. H programma, una volta compil ato ri spetto all' interfacc ia, viene quindi eseguito insieme all a libreria opportuna per il suo ambi ente di esec uzio ne e per il DBMS a cui deve accedere. Un vantaggio ulteriore di questo approccio è che queste librerie prevedono in generale che il DBMS ri sieda su un elaboratore diverso da quello in cui si esegue il programma, e si occupano di gestire in maniera tras parente tutte le problemati che di comuni cazion e con un approccio client-server.

8.2.1

l'API ODBC

L' API ODBC (Open Data Base Con.nectivity) è, attualmente, uno standard molto diffuso per l' utilizzo di DBMS relazionali. ODBC è stato definito dalla Mi crosoft, e specifica un DDL ed un DML relazionali basati sullo standard SQL CLI (Ca li Leve/ In.terface) proposto dal comitato X/Open. Uno strumento che implementi l' API ODBC è composto principalmente da un insieme di driver o libreri e ODBC. Un driver ODBC per il DBMS X è un a libreria che traduce le chi amate generi che ODBC in chiamate allo specifico siste ma X e gliele invia, appogg iandos i ad un sistema di comunicazione (Figura 8.2). ODBC permette di accedere ad un sottoinsieme limitato di SQL, quello implementato da tutti i sistemi relaz ionali , ma permette anche di usare estensioni non standard presenti su di uno specifi co sistema, anche se questo riduce la portabilità dell 'applicazione. So no di sponibili anche d river ODBC per sistemi di archi viazi one; questi driver interpretano in proprio le istruzioni SQL.

API ODBC

DBMS 1

Ciente 1

Driver ODBC per DBMS 1

Figura 8.2. Uso dei driver ODBC.

218

Capitolo 8.

SQL per programmare le applicazioni

© 88-08-07003-4

Mentre ODBC è un 'A PI utili zzabile per lo sv iluppo di applicazioni in C o in altri lin guaggi di programm az ione, ne esistono anche dell e versio ni integrate in ambienti di sv iluppo di vario tipo, come Vi sua l B as ic di Mi crosoft, che ne permettono anche l'uso all ' interno di strumenti di produtti vità indi vidu a le. In parti colare, tutti g li strumenti più diffusi per l' implementaz ione di inte1facce hanno la capac ità di sfruttare driver ODBC. Il seguente ese mpi o mostra un se mpli ce programm a Vi sual Bas ic che pu ò essere ri chiamato all ' interno di un foglio e lettro nico Excel, per inserire i ri sultati di un a interrogazio ne SQL in una co lo nna del fog li o di ca lcolo con no me Risultato : Procedure TrovaNomiStudenti () ' Si apre la connessione alla base di dati connessione= SQLOpen ("DSN=M ioDatabase ;UID=ut1 ;PWD=pw1 ") ' Si esegue l'interrogazione (senza recuperare i dati) SQLExecQuery connessione ; "SELECT Nome FROM Studenti" ' Si dichiara che i risultati saranno restituiti a partire ' dalla prima cella del foglio di calcolo SQLBind connessione ; 1 FogliDilavoro("Risultati"). Celle(1; 1) ' Si recuperano effettivamente i dati SQLRetrieve connessione ' Si chiude la connessione SQLCiose connessione End Procedure

8.2.2

L'API JDBC

L'A PI JDB C (l ava Data Base Connecti vity) pu ò essere de finita come la versione Java di ODBC, e ha implementaz ioni analoghe a quell e di ODBC. L' interesse per questo tipo di API è duplice: grazie all a portabilità dei programmi Java, con JDB C si ha il va ntaggio di poter sv iluppare applicazioni indipendenti no n so lo dal tipo di siste ma che gesti sce la base di dati , ma anche dal tipo di pi attaforma su c ui l' applicazione vi ene eseguita; JDBC è un ' interfacc ia per un linguagg io ad oggetti , Java, progettato per ev itare quelle caratteri sti che de l C e C++ che rendono la programmazione ri schi osa. JDBC è lo strumento utili zzato per la reali zzazione del linguaggio SQLJ: tutti i comandi SQL di tale ling uagg io vengono trasformati dal preco mpil atore in chi amate all e primiti ve JDBC. In effetti , dato che i co mpil atori SQLJ sono ancora scarsa mente di ffusi, la programm az ione d i bas i dati re laz io nali dal linguagg io ] ava è fatta mo lto spesso con J DBC. La log ica con cui dal programm a si utili zza il DBMS è mo lto simile a quell a di SQLJ . Le differenze principali sono nel fatto che non è poss ibile nessun

© 88-08-07003-4

8.2.

Linguaggi con interfaccia API

219

controllo dei tipi, mentre altre differenze dipendono dalle classi di verse che sono usate per accedere ai dati : Connection, per stabilire il collegamento co n una base di dati : una co nnessi one è l ' equi val ente di un contesto in SQLJ ; - Statement per costruire il comando SQL da invi ar e al si stema tramite una

connection, e ResultSet per ricevere il 1isultato (equi val ente al result set iterator di SQLJ) . Vedi amo un sempli ce esempi o d ' uso di JDBC. import java.sql. *; class StampaNomiStudenti { public static void main(String argv[]) { try {

Il URL della base di dati da usare String uri = "jdbc:odbc:MioDatabase"; Il si apre la connessione con la base di dati Connection con= DriverManager.getConnection(url , "utente1 ", "password1 "); Il si esegue un comando SELECT Statement stmt = con .createStatement(); ResultSet risultato= stmt.executeQuery("SELECT Nome FROM Studenti"); Il scansione del risultato usando il metodo next System .out.println ("Nomi trovati :"); while (risultato.next()) { String nome = risultato.getString("Nome"); Il Stampa del nome trovato System.out.println (" Nome = " + nome) ; risultato.close() ; stmt.close() ; con.close() ;

Si noti l a di fferenza dell' uso del ResultSet ri spetto a SQLJ : dato che a tempo di compil azi one non si conosce l a struttura della base di dati , non si possono usare metodi specifici per accedere ai campi dell 'ennupl a corrente. Si usano invece metodi generici (getString, getlnteger ecc.) che prendono come parametro o il nome dell 'attributo, oppure il suo numero d ' ordine. La gesti one delle tran sazi oni è anal oga a quella di SQLJ, attraverso il meccani smo di autocommit (che può essere esplicitam ente m anipol ato con il metodo setAutocommit(Boolean) di una connessi one). Si può anche ri chi edere l'esecuzi one della transazi one con un certo li vello di i solamento con un opportuno val ore del parametro del metodo setTransactionlsolation.

220

Capitolo 8. SOL per programmare le applicazioni

© 88-08-07003-4

Per passare va lori dal programma ai comandi SQL, dato che sono solamente stri nghe, si può procedere in due modi diversi: usando la concatenazione di stringhe, come nell'esempio seguente, in cui viene usato il valore della variabil e matricola per indicare la matricola dello stude nte da ricercare: stmt.executeQuery("SELECT Nome FROM Studenti WHERE Matricola= "+ matricola); usando la classe PreparedStatement, che le c ui istanze corrispondono a comandi SQL all'interno dei quali vi sono dei parametri indi cati da "?" che si possono sostituire con valori qualunque, in mani era ord inata, come nel seguente frammento di progi·amma: PreparedStatement pstmt = con.prepareStatement("SELECT Nome FROM Studenti WHERE Matricola= ?"); pstmt.setlnt(1 , matricola); risultato = pstmt.executeOuery() ;

Si noti che il secondo metodo è preferibile per ev itare che caratteri particolari all'interno dei parametri, come le virgolette, interferiscano con le operazioni di concatenamento di stringhe o con la si ntassi del comando SQL. Infine, è importante sotto lineare come l'interfaccia JDBC permetta anche lo svi luppo di applicazioni con SQL dinamico (Dynam.ic SQL) , cioè in cui i comandi SQL che devono essere esegu iti sono calcolati a tempo di esecuzione.

Esempio 8.2 Si consideri per esempi o un programma che, consu ltando il catalogo, propone all ' utente la li sta delle tabelle della base di dati chiedendogli quale di queste vuole interrogare. Una volta che l' utente ha fatto la sua scelta, il programm a potrebbe proporre l'elenco degli attri buti , e permettere di all ' utente di dare i valori di alcuni attributi per restrin gere la ricerca, e di indicare gli attributi di cui vuole la visualizzazione. In base a queste informazioni il programma potrebbe sintetizzare la query sotto forma di stringa, con la sicurezza che sia comunque corretta perché generata utilizzando le informazioni del catalogo dei dati . Un program ma come quello descritto nell'esempio precedente può essere faci lmente scri tto con JDBC utili zzandone le funzionalità che permettono di interrogare, in maniera indipendente dal particolare DBMS usato, il catalogo dei dati (i metadati ). Esiste infatti il metodo getMetaData di un oggetto Connection che restituisce un oggetto istanza della classe predefinita DataBaseMetaData, con molti ss imi metodi per conoscere tutti gli elementi del catalogo dei dati (tabell e, attributi , chi avi, chi avi esterne, procedure memorizzate ecc.). Inoltre, per visuali zzare il risultato di una interrogazione espressa con una stringa calcolata a tempo di esec uzione, si può usare il metodo getMetaData d e li ' istanza di Result Set restituita. Questo metodo produce un oggetto di tipo ResultSetMetaData, che descrive completamente il risultato dell ' interrogazione (n umero di attri buti , loro tipo, lunghezza ecc.).

© 88-08-07003-4

8.3

8.3.

Linguaggi integrati

221

Linguaggi integrati Per ovviare al problema dell' impedence mismatch presente nell'uso di SQL con un linguaggio ospite, si integrano i costrutti di un linguaggio relazionale e di un linguaggio di programmazione in un unico linguaggio. Il primo esempio di linguaggio progettato con questo obiettivo è stato il Pascai/R, in cui il sistema dei tipi del Pasca! è esteso con un nuovo tipo di dato, la relazione, e di costrutti per agire su relazioni [Sch77]. Una direzione completamente diversa è stata invece presa da molti costruttori di sistemi relazionali commerciali , con i cosiddetti linguaggi della quarta generazione (4GL): l'idea è quella di costruire un linguaggio di programmazione estendendo l' SQL con costt'ùtti di controllo di tipo generale, spesso derivati da linguaggi tipo BASIC. L'esempio che presenteremo in questa sezione è il PL/SQL, linguaggio del sistema ORACLE. Le caratteristiche principali del PL/SQL sono le seguenti: - Si possono definire variabili o costanti dei tipi dei domini relazionali, sia espli citamente (come in DECLARE x CHAR(2); che dichiara x di tipo stringa di due caratteri), che uguali al tipo di una colonna (come in DECLARE x Clienti .CognomeENome%TYPE ; che dichiara x dello stesso tipo della colon na CognomeENome della tabella Clienti) . Si possono, inoltre, dichiarare variabi li di un tipo ennupla, come in DECLARE CodiceCiiente Clienti%ROWTYPE . - Si possono definire cursori , equivalenti agli iteratori SQLJ, per operare in maniera iterativa su un insieme di ennuple restituite da una SELECT. Un cursore è associato ad una espressione SQL, come per esempio in DECLARE CURSOR c1 IS SELECT Zona FROM Agenti , e quindi può essere usato in due modi: all'interno di un costrutto FOR, per scandire tutte le enn upl e del risultato dell ' espressione associata (come in FOR z IN c1 LOOP ... END) , oppure con dei comandi per eseguire il ciclo in maniera esplicita (OPEN , FETCH, CLOSE).

- I comandi possibili sono l'assegnamento, tutti comandi SQL (per cui il linguagg io è in effetti un soprainsieme deli'SQL), e i tradizionali costrutti di controllo (IF, WHILE, LOOP ecc.). - Esiste un meccanismo di gestione delle eccezioni, sia generate da operazioni illegali, che espli citamente dall'utente. Il verificarsi di un'eccezione provoca l'annull amento delle modifiche alla base di dati. - Si possono definire funzioni e procedure con parametri (PROCEDURE) in maniera usuale. - Si possono definire moduli (PACKAGES) che racchiudono procedure, funzioni, cursori e variabili collegate. Un modulo ha una parte pubblica, che elenca le entità esportabili dal modulo, ed una privata, che contiene la realizzazione delle procedure pubbliche ed eventuali variabili e procedure locali al modulo. - Sia le singole procedure e funzioni che i moduli possono essere memori:::.z.ati nella base di dati, assegnando loro un nome (C REATE PROCEDURE, CREATE PACKAGE). Il sistema memorizza procedure e moduli in forma compi lata, ma mantiene anche il codice sorgente e tiene traccia delle dipendenze in esso

222

Capitolo 8. SOL per programmare le applicazioni

© 88-08-07003-4

presenti , per ricompilarl o nel caso di modifi che dei dati usati (per esempio, se viene modi fica ta l a defini zione di una tabella) . - Si possono definire dei trigger (CREATE TRIGGER), co me di scu sso nel capitol o precedente. U n progr amma in PL/SQL viene scritto sotto form a di bl occo anonimo anonymous block, e può essere presentato, interatt ivamente oppure in un ar chi vi o di testo, ad uno dei vari tool di ORA CLE per l 'esecuzione. Usando i com andi CREATE PROCEDURE o CREATE PACKAGE si può memori zzare una procedura o un modul o nella base di dati . Procedure e componenti di m oduli m emori zzati possono quindi essere richi amate ed usate da altri programmi , anche remoti .

Esempio 8.3 Riferendoci all o schema g ià presentato dei clienti, agenti e venditori , si vuol e: (a) stampare l 'ammontare di un certo ordin e; (b) agg iornar e la zona di un agente e (c) stampare le coppi e (clienti , ammontare degli ordini ) ordin ate in modo decrescente secondo l 'ammontare. DECLARE NumCiiente Clienti.CodiceCiiente%TYPE; NumOrdine Ordini.NumFattura%TYPE; NumAgente Agenti.CodiceAgente%TYPE; NomeZona Agenti .Zona%TYPE; VAmmontare Ordini .Ammontare%TYPE ; TotaleAmmontare INTEGER ; BEGIN /* Ricerca dell'ammontare di un certo ordine */ PRINT "Scrivi CodiceAgente, CodiceCiiente, NumOrdine"; READ NumAgente, NumCiiente, NumOrdine; SELECT FROM WHERE AND

Ammontare INTO VAmmontare Ordini CodiceAgente=NumAgente AND CodiceCiiente=NumCiiente NumOrdine=NumOrdine;

PRINT VAmmontare; /* Aggiornamento della zona di un agente */ PRINT "Scrivi CodiceAgente, Zona"; READ NumAgente, NomeZona; UPDATE Agenti SET Zona = NomeZona WHERE CodiceAgente = NumAgente; /* Creazione di un cursore per i clienti e l'ammontare */ DECLARE c CURSOR IS SELECT CodiceCiiente, SUM(Ammontare) AS Totale FROM Ordini GROUP BY CodiceCiiente ORDER BY SUM(Ammontare) DESC; /* Uso del cursore; *l /* coppia e' implicitamente di tipo c%ROWTYPE */ FOR coppia IN c LOOP PRINT coppia.CodiceCiiente, coppia .Totale END LOOP; END

© 88-08-07003-4

8.4

8.4.

La programmazione di transazioni

223

La programmazione di transazioni Come specificato nel Capitolo l , una transazione è un programma che il DBMS esegue garantendone atomicità e serializzabilità. L'atomicità viene garantita (concettualmente) facendo sì che, quando una transazione fallisce , tutti i suoi effetti sulla base di dati siano disfatti. La serializzabilità è garantita in genere con il meccanismo del bloccaggio dei dati (record and table locking). Prima di leggere, o modificare, un dato una transazione lo deve bloccare in lettura o, rispettivamente, in scrittura. Quando una transazione T l cerca di ottenere un blocco in scrittura su di un dato già bloccato da T2 , T l viene messa in attesa, finché T2 non termina e quindi rilascia il blocco. Con questa tecnica si garantisce la serializzabilità delle transazioni ed il loro isolamento, ovvero il fatto che una transazione non veda mai le modifiche fatte da un ' altra transazione non ancora terminata. Le richieste di blocco sono fatte automaticamente dal sistema senza intervento del programmatore. Se si adotta l'approccio di considerare ogni comando SQL come una transazione (autocommit on) , possiamo non essere in grado di disfare un ' operazione che abbiamo già fatta e che ha portato la base di dati in uno stato non consistente. È quindi necessario, a vo lte, gestire esplicitamente le transazioni (autocommit off). La prima possibilità da con siderare in questi casi , è quella di far sì che l'intero programma diventi una tran sazione. Questo approccio, però, funziona bene in casi semplici, ma in generale è necessario poter prevedere altri comportamenti: Quando il programma scopre una condizione anomala, che impedisce il completamento di un suo compito, è spesso opportuno avere la possibilità di disfare solo una parte delle operazioni fatte, cercando di aggirare l'anomalia usando del codice alternativo. Quando un programma può richiedere un tempo lungo per terminare le proprie operazioni, per esempio perché interagisce con l' utente, può essere opportuno spezzare il programma in più transazioni , in modo da poter rilasciare i blocchi , per permettere l' esecuzione di altre transazioni che necessitano degli stessi dati. I comandi COMMIT e ROLLBACK. permettono di ottenere questi comportamenti, spezzando un programma in più transazioni. Vediamo come questo può essere ottenuto nel caso di SQLJ, assumendo di operare quindi attraverso un contesto con autocommit aff. Una transazione viene considerata iniziata dal sistema quando un programma esegue un ' operazione su una tabella (per esempio, SELECT, UPDATE, INSERT, DELETE). 4

La transazione quindi prosegue finché:

4. Di sol ito i comandi che modificano lo schem a (CREATE , DROP e ALTER) sono eseguiti in modo atomico e i loro effetti non possono essere annu ll ati.

224

Capitolo 8.

SOL per programmare le applicazioni

© 88-08-07003-4

l . Viene eseguito il comando #sql [contesto) COMMIT; che comporta la terminazione normale della transazione e quindi il rilascio dei blocchi sui dati usati , che diventano così disponibili ad altre transazioni ; 2. Viene eseguito il comando #sql [contesto] ROLLBACK; (abort transaction) che comporta la terminazione prematura della tran sazione, e quindi (a) il disfacimento di tutte le modifiche fatte dalla transazione (per garantire la proprietà dell' ato micità) e (b) il rilascio dei blocchi sui dati usati ; 3. Il programma termina senza errori e quindi la tran sazione tennina normalmente; 4. Il programma termina con fallimento e provoca la terminazione prematura della transazione. Nell'esempio precedente, quindi, il programma andrebbe riscritto per portare le parti di codice che interagi sco no con l' utente al di fuori della transazione. Per ottenere questo risultato è sufficiente organizzare il programma come due transazioni: la prima che comincia dopo la prima interazione con l' utente, consistente di un unico SELECT, e la seconda, che comprende il comando UPDATE, e la dichiarazione e l'u so del cursore. La modifica da fare al programma è quindi l'inserzione del comando: #sql [contesto] COMMIT;

dopo il primo SELECT, per forzare la terminazione della prima transazione, dato che la seconda termina con la fine del programma. In realtà, quando un programma esegue transazioni occorre cercare di renderle meno "estese" possibili , in modo da permettere il più alto grado di concorr·enza possibile fra programmi diversi . Così, nell 'esempio precedente, è preferibile suddividere ancora la seconda tran sazione in due, dato che si eseguono due operazioni non correlate (l ' aggiornamento della zona di un agente e la stampa delle coppie cliente, ammontare ordini). La struttura finale del programma diventa quindi: Class Esempio; Dichiarazioni e lnizializzazioni { Lettura dal terminale dei dati di un ordine l { Prima transazione: ricerca ordine l #sql [contesto] COMMIT; { Stampa risultato prima transazione l { Lettura dal terminale dei dati per la seconda transazione l { Seconda transazione: aggiornamento zona di un agente l #sql [contesto] COMMIT; { Terza transazione: recupero e stampa dei dati sui clienti e total i ordini } #sql [contesto] COMMIT; END programma.

Esempio 8.4 Supponiamo che nella base di dati esista anche la tabella: Magazzino(Prodotto, Quantità, Prezzo)

© 88-08-07003-4

8.4 .

La programmazione di transazioni

225

Si consideri il seguente frammento di programma, che potrebbe servire ad un venditore al mo mento dell a richi esta di un ordine da parte di un clie nte. Nel programm a si legge la quantità di prodotto di sponibil e in magazzino e il prezzo corrente. Quindi si legge la qu antità ordinata, e si crea i'ordine. import java.sql .*; import sqlj .runtime.*; public class Esempio2 { public static void main(String [] args) { try {

Il Connessione alla base di dati Class.forName( "oracle.jdbc .driver.OracleDriver"); #sq l context ClasseContesto; ClasseContesto contesto = new ClasseContesto("jdbc:oracle :thin :@ localhost:1521 :mydb", "utente1 ","password1 ");

Il Ricerca della quantita' di un certo prodotto Il Lettura dei parametri String numProdotto = leggi("Codice prodotto: ");

Il inizio della prima transazione int quantita, prezzo ; #sql [contesto) SELECT Quantita, Prezzo INTO :quantita, :prezzo FROM Magazzino WHERE Prodotto= :numProdotto; //si termina la transazione prima di interagire con l'utente #sql [contesto] COMMIT;

Il Stampa risultato System.out.println("La quantita e':" + quantita) ; System .out.println("ll prezzo e': " + prezzo) ; int quantitaRichiesta = new lnteger{leggi("Quantita ordinata : ")) .intValue() ; int prezzo Proposto = prezzo;

Il inizio della seconda transazione #sq l [contesto] SELECT Quantita , Prezzo INTO :quantita, :prezzo FRO M Magazzino WH ERE Prodotto= :numProdotto; if (quantita > = quantitaRichiesta && prezzo== prezzoProposto) { #sql [contesto] UPDATE Magazzino SET Quantita = :quantitaRichiesta WH ERE Prodotto= :numProdotto; ... soddisfacimento dell'ordine ... } else { // se la quantita' e' diventata insufficiente o il prezzo e' cambiato #sq l [contesto) ROLLBACK ; System.out.println {"Richiesta non evasa per cambiamento" + " quantita' oppure prezzo");

Questo esempio mostra come la necess ità di di videre un programma in più tran sazioni per aumentare il grado di concorrenza comporti alcune co mpli caZIOni.

226

Capitolo 8. SOL per programmare le applicazioni

© 88-08-07003-4

In fa tti la second a transazio ne, que ll a che effettu a l'ordine vero e propri o, invece di agg io rn are direttame nte il va lore de ll a qu antità del prodo tto, ri c hi ede un a nuova lettura per co ntro ll are l' effetti va di s po nibilità de ll a me rce e il suo prezzo . Il co ntroll o è dovuto al fatto c he fra la c hiu sura de ll a prim a transaz io ne e l' ini z io de ll a seconda, può essere stata eseguita un ' a ltra tra nsazio ne c he ha modifi cato la qu antità (per esempi o per fa re un a ltro o rdine), o il prezzo (pe r ese mpi o per agg io rnare i prezz i de i prodotti ). Il contro ll o quindi è indi spensabil e per ev itare di vendere la stessa me rce due volte o ad un prezzo di verso da qu e ll o stabilito. A second a de ll 'es ito de l co ntro ll o, pu ò essere necessari o provocare il fallim ento della transaz io ne.

8.4.1

Ripetizione esplièita delle transazioni

Un ' altra situ azio ne da prevede re ne ll a prog rammazione di transazioni è la ripeti zio ne de lla transaz io ne quando questa vie ne inte rrotta dal s istema per s bloccare una condi z io ne di sta/lo (deadlock), che si presenta qu ando due o più transaz io ni sono bl occate in attesa l' un a de i dati de ll' a ltra, e viceversa. In questo caso, il DBMS scopre lo stall o e inte rro mpe, seco ndo un a pro pria strategia, un a de ll e transazio ni in modo c he le a ltre possano proseguire . Il fatto c he un a transazio ne venga interro tta per sbloccare uno sta ilo vie ne seg na lato a l programm a co n (SQLCODE = DEADABORT), e quindi si può dec idere di far ripartire la tra nsazio ne.

Esempio 8.5 Suppo ni amo di dover fa re un aggio rn ame nto c he co invo lge mo lte e nnuple, come cambi are il s upervisore di tutti g li age nti di una certa zona. S i pu ò usare il seguente framme nto di codi ce, che prova ripetuta me nte , fin o ad un mass im o di qu attro volte, l'ope razio ne in caso di inte rru zio ne de lla transazio ne per uno sta ll a. int tentativi = O; boolean riuscito = false ; while ((tentativi < 4) && ! riuscito) { try { #sql [contesto] UPDATE Agenti SET Supervisore = :nuovoSupervisore WHERE Zona= :nomeZona; riuscito = true ; } catch (SQLException e) { #sql [contesto] ROLLBACK; tentativi = tentativi + 1; }

if (! riuscito) { System .out.println ("Aggiornamento non eseguito per troppi stalli!"); }

In gene ra le, se si decide di far ripartire una transazio ne inte rrotta da l sistema, bi sogna ri cordarsi c he me ntre i uo i effetti sull a base di dati vengo no di sfatti auto mati came nte, i valo ri di variabili de l progra mma, eve ntua lme nte sig nifi cati vi per la co rretta esecuz io ne de ll a tra nsazio ne, rim angono ina lterati pe rché no n sono ~otto il contro ll o de l siste ma e quindi vann o ini z ia lizzati dal progra mm a prim a di fa r ripartire la transaz ione .

© 88-08-07003-4

8.4.

La programmazione di transazioni

8.4.2

227

Transazioni con livelli diversi di isolamento

Con l'aumentare del numero di transazioni eseguite concorrentemente in modo seriali zzabile si può ridurre l'effettivo grado di conconenza del sistema a causa del fatto che aumenta la probabilità di avere transazioni in attesa di dati bloccati da altre o interrotte per il verificarsi di situazioni di stalla. Per questa ragione i sistemi commerciali prevedono la possibilità di programmare transazioni rinunciando alla proprietà della serializzabilità e quindi di isolamento delle tran sazioni . Nella proposta dell'SQL-92, con il comando SETTRANSACTION si può scegliere uno dei seguenti livelli di isolamento per consentire gradi di concorrenza decrescenti: SET TRANSACTION ISOLATION LEVEL [ READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE

l l l ]

Il primo li vello di isolamento, read uncommitted, detto anche dirty read o degree of isolation O, consente tran sazioni che fanno solo operazioni di lettura (quelle di modifica sono proibite) che vengono eseguite dal sistema senza bloccare in lettura i dati. La conseguenza di questo modo di operare è che una transazione può leggere dati modificati da un ' altra non ancora terminata, che vengono detti sporchi perché potrebbero non essere più nella base di dati se la transazione che li ha cambiati venisse abortita. Il secondo li vello di isolamento, read committed, detto anche cursor stability o degree of isolation l , prevede che i blocchj in lettura vengano rilasciati subito, mentre quelli in scrittura vengono rilasciati alla terminazione della transazione. In questo modo, quando una transazione T modifica un dato , quel dato non può essere letto da altri fino a che T non abbia effettuato un comm it o un rollback. La conseguenza di questo modo di operare è che un a transazione può fare letture non ripetibili, ovvero letture successive degli stessi dati possono dare risultati diversi perché i dati sono stati modificati da altre transazioni terminate nell'intervallo tra la prima e la seconda lettura. Il terzo li ve ll o di isolamento, repeatable read, detto anche degree of isolation 2, prevede che i blocchi in lettura e sc rittura siano assegnati solo su en nupl e di tabelle e vengano rilasciati all a terminazione della transazione. Questa soluzione evita il problema delle letture non ripetibili, ma non è ancora il tipo di isolamento che accane per avere transazioni serializzabili in quanto consente ad altre transazioni di fare inserzioni di ennuple nella stessa tabella, creando il fenomeno cosiddetto dei fantasmi (phan toms). Per esempio, supponiamo che esista una tabella di riepilogo sulle vendite dei prodotti: Vendite(Prodotto,TotaleAmmontare)

che venga mantenuta aggiornata dalla tran sazione che inserisce un nuovo ordine per un prodotto. Supponiamo che vengano eseguite due transazioni T 1 e T2 con il livello di isolamento repeatable read: T inserisce un ordine per il prodotto 200 e quindi 1

228

Capitolo 8.

© 88-08-07003-4

SOL per programmare le applicazioni

aggiorn a la riga corri spondente dell a tabell a Vendite ; T2 legge gli ordini del prodotto 200, calcola il totale e co ntroll a che sia quell o dell a tabell a Vendite . All ora può capitare che le due transazioni vengano eseguite come segue:

T,

Tz Legge gli ordini di un certo prodotto e calcola il totale

Inserisce un nuovo ordine per lo stesso prodotto e aggiorna la tabyll a vendite Controlla la so mma in cui T2 segnala che il valore dell a tabe ll a Vendite è scorretto, anche se non è vero (dato che è stato inserito un nuovo ordine e aggiornata la somma). Questo è poss ibile propri o perché T2 blocca solo le ri ghe degli o rdini che legge, e no n tutta la tabella, pertanto T 1 può effettu are l'inserzione e la modifi ca di Vendite . Per ev itare il problema occorre invece che l'insieme delle ri ghe di Ordini lette da T2 non venga modi ficato da T1, per esempi o bloccando tutta la tabell a, come fa nno quei sistemi che garanti scono il quarto li vello di iso lamento, serializable, detto anche deg ree of isolation 3 . In alcuni sistemi il blocco de ll a tabell a può essere anche ri chiesto esplic itamente dall a transazione con il comando: LOCK TABLE Tabella IN [ SHARE l EXCLUSIVE] MODE

per se mpli ficare la gesti one dei blocchi da parte del sistema o per operare correttamente anche co n un li vell o d i isolamento diverso da que ll o serializable. Il comando LOCK non è previsto da SQL-92. La programm azione di transazioni con i primi tre li velli di iso lamento richiede in generale un maggior impegno per garantire la cotTetta evo lu zione dell a base di dati , perché non è poss ibile astrarre dal fatto che la transazione è eseg uita insieme ad altre. ln tabell a sono ri ass unti i fen omeni che si possono presentare operando con i di versi live lli di iso lamento. Livello READ UNCOMM ITIED READ COMM ITIED REPEATABLE READ SER IALIZABLE

8.5

Letture sporche Possibile Non possibi le Non possibi le Non possibile

Letture non ripetibili Possibi le Possibile on possibi le No n possibile

Dati fan tasmi Possibile Possibile Possi bile No n poss ibile

Conclusioni Sono state presentate le caratteristi che d i tre tipi di strumenti per lo sv iluppo d i applicazioni che usano bas i di dati : lin guaggi che ospitano SQL, linguagg i che usano interfacce API e linguaggi integrati della quarta generazione. L'attenzione è stata posta su d ue aspetti principali : come scambi are info rm azion i con un a base di dati da un programma e come programmare le transazio-

© 88-08-07003-4

8.5.

Conclusioni

229

ni. C'è un altro aspetto importante che non è stato discusso per ragioni di spazio: come programmare la parte dell'applicazione dedicata alle interazioni con gli utenti con opportune interfacce grafiche. Ogni sistema offre linguaggi dotati dei meccanismi per farlo ed esistono anche strumenti di ditte indipendenti finalizzati a questo scopo.

Esercizi 1. Si consideri il seguente frammento di codice SQLJ: #sql [contesto] SELECT Ammontare INTO :ammontare FROM Ordini WHERE CodiceAgente = :numAgente

L'elaborazione del codice procede in tre fasi: (a) precompilazione dei frammenti SQL in Java, (b) compilazione del programma Java risultante, (c) esecuzione. Durante l'esecuzione, il controllo si alterna tra macchina astratta Java e il DBMS. Esemplifichiamo ora alcuni motivi per cui tale codice potrebbe essere scorretto. Immaginando che ogni enore sia scoperto prima possibile, specificare chi dei quattro attori (precompilatore, compilatore, macchina astratta Java e DBMS) segnala ciascun errore. (a) sintassi SQL: il programmatore potrebbe scrivere WEHRE anziché WHERE . (b) nomi: il programmatore potrebbe avere sbagliato a scrivere il nome della relazione, oppure quello dell'attributo Ammontare, oppure quello della variabile :ammontare. (c) tipi : il tipo di Ammontare e quello di :ammontare potrebbero essere incompatibili. (d) variazione dello schema: quando il programma viene eseguito la relazione Ordini potrebbe essere stata cancellata, oppure il tipo dell 'attributo Ammontare potrebbe essere cambiato. (e) univocità: il valore di :NumAgente potrebbe non essere associato ad alcun agente, oppure essere associato a più agenti.

2. Si consideri la versione API del frammento di codice dell'esempio precedente. PreparedStatement pstmt = con.prepareStatement( "SELECT Ammontare INTO :ammontare FROM Ordini WHERE CodiceAgente = ?") ; pstmt.setString(1 , codAgente) ; risultato = pstmt.executeQuery(); In questo caso l' elaborazione di tale frammento procede come segue: compilazione del programma Java, esecuzione da parte della macchina astratta Java che interagisce con il DBMS. Anche in questo caso si cerchi di individuare in quale momento verrebbe scoperto ciascuno degli errori sopra elencati. 3. Specificare vantaggi e svantaggi della programmazione di applicazioni usando un linguaggio integrato anziché un ' API. 4. Si considerino le seguenti applicazioni in ambito bancario. Indicare il livello di isolamento più opportuno per ciascuna di esse, spiegando la ri sposta.

230

Capitolo 8.

SQL per programmare le applicazioni

© 88-08-07003-4

(a) per ogni cli ente della banca, contare le operazioni effettuate negli ultimi 500 giorni , ed agg iungere il no me del cliente ad un elenco se le operazioni sono più di trecento. L' e lenco servirà a scopi di marketing. (b) effettuare un trasferimento fo ndi , sottraendo un ammontare da un conto per agg iungerl o ad un altro. (c) gestire un pre li evo allo sporte llo come segue: il cassiere legge sul termjnale il saldo corre nte del cliente; se questo supera la cifra richiesta dal clie nte, il cassiere comunica al sistema la cifra ed effettu a il pagamento (specificare quali di queste operazio ni sarebbero racchiuse nell a transazione).

Note bibliografiche Per approfondire il problema della programmazione delle appli cazioni in SQL si veda [vdLOl] e [KBLOS] . Molte informazioni su JDBC e SQLJ sono disponibili sulla rete, in particol are ai siti http ://java.sun .com/products/jdbc/ e http ://www.sqlj .org .

Capitolo 9

REALIZZAZIONE DEl DBMS

Si presentano l'architettura dei DBMS relazionali centralizzati e alcune delle tecniche utilizzate per realizzarne le funzionalità essenziali: la gestione dei dati , delle interrogazioni , della concorrenza e dell 'affidabilità. Una conoscenza, sia pure elementare, di tali tecni che è indispensabile per utilizzare questi sistemi in maniera efficace.

9.1

Architettura dei sistemi relazionali In Figura 9.1 so no mostrati i moduli principali di una poss ibile architettura di un sistema relazionale centralizzato. Un DBMS è organizzato su due livelli , che chiameremo la macchina logica e la macchina fisica. La macchina logica comprende i moduli che trattano i comandi del linguaggio SQL e stabiliscono come eseguirli usando gli operatori forniti dalla macchina fisica, che gestisce la memoria permanente e le strutture per la memorizzazione e recupero dei dati . Nei sistemi commerciali le funzionalità di questi moduli non sono nettamente separate come la fig•Jra potrebbe far pensare, ma questa schematizzazione consente di comprendere meglio gli scopi di ognuno. Nelle pross ime sezioni si esaminano brevemente i moduli dedicati alla gestione dei dati, delle interrogazioni , della concorrenza e dell 'affidabilità. Di ogni modulo viene descritto il livello di astrazione fornito e le funzionalità che rendono disponibili agli altri moduli. Per approfondire gli argomenti si veda [AlbO l].

9.2

Gestore della memoria permanente Il gestore della memoria permanente offre una visione di una basi di dati come un insieme di file di blocchi di caratteri (pagine fisiche) di grandezza prefì ssata, compresa generalmente fra l e 8 Kbyte, che sono l'unità minima di trasferimento fra la memoria permanente e quella temporanea. Esso consente agli

232

Capitolo 9.

© 88-08-07003-4

Realizzazione dei DBMS

COMANDI SOL

t

MACCHINA LOGICA: GESTORE SOL GESTORE AUTORIZZAZIONI

GESTORE CATALOGO

GESTORE INTERROGAZION I ESECUTORE PIANI D'ACCESSO

OTTIMIZZATORE

MACCHINA FISICA: GESTORE MEMORIA RELAZIONALE

GESTORE CONCORRENZA

·~

GESTORE METODI DI ACCESSO

~

GESTORE STRUTTURE DI MEMORIZZAZIONE

~

GESTORE BUFFER

~

GESTORE MEMORIA PERMANENTE

~

GESTORE AFFIDABILITÀ

~ MEMORIA PERMANENTE

BD DATI , INDICI CATALOGO , GIORNALE

Figura 9.1. Architettura di un DBMS relazionale.

altri livelli di usare la memoria permanente astraendo dalle diverse modalità di gestione dei file dei sistemi operativi. I dati memorizzati nella memoria permanente sono quelli descritti ne llo schema logico, le strutture ausi li arie per agevo lare g li accessi all a base di dati (indici ), e i dati di servizio necessari per il funzionamento del sistema.

9.3

Gestore del buffer Il gestore del buffer gesti sce uno spazio della memoria temporanea destinato a contenere un insieme di pagine fi siche trasferite dalla memoria permanente. Una pagina fisica è rappresentato in memoria temporanea come una struttura logica detta pagina e gli altri livelli del s istema hanno una visione della memoria permanente come un insieme di pagine utili zzabili in memoria te mpora nea astraendo da quando esse vengano trasferite fra i due tipi di memoria.

© 88-08-07003-4

9.4.

Gestore delle strutture di memorizzazione

233

Poiché il buffer può contenere molte pagine, quando si opera su dati usati di recente esiste una certa probabilità che tali dati siano ancora disponibili nel buffer, evitandone così la rilettura dal disco. Similmente, gli aggiornamenti ai dati vengono in realtà effettuati all'interno del buffer, e i dati sono riportati sul disco solo quando è necessario liberare il buffer o quando il protocollo per la gestione dell 'affidabilità lo richiede (si veda la Sezione 9.8). l record all'interno delle pagine sono memorizzati come stringhe di caratteri con un prefisso contenente informazioni di servizio seguito dai valori dei campi. Il prefisso può contenere, per esempio, una marca per la cancellazione logica, la lunghezza del record , il numero degli attributi, l'identificatore interno del record, unico all'interno. della base di dati e assegnato automaticamente dal sistema ad ogni nuovo record. Un record con una dimensione inferiore a quella di una pagina si memorizza tutto in una pagina. Quando un record viene inserito in una relazione, il sistema gli assegna un identificatore, chiamato TID (tuple identifier) , o RID (row identifier), che diventa il riferimento da usare nelle strutture dati. L'esatta natura del TID può variare da un sistema ad un altro, ma l'obiettivo comune a tutti è di garantire che un TID sia un'informazione che non cambia fintantoché il record esista nella base di dati. La soluzione più comune è la seguente: un TID è una coppia (P, j), dove P è il numero di pagina e j è la posizione relativa in un vettore memorizzato nella pagina, contenente il riferimento all'inizio del record (Figura 9.2). Se il record si sposta nella pagina, per esempio in seguito a modifiche che ne cambiano la lunghezza, basta aggiornare il contenuto del vettore, senza cambiare il TID. Nel caso in cui la modifica del record ne comporti uno spostamento in un 'altra pagina, il record viene sostituito con la coppia (P ' , j'), un altro TID, dove P ' è l'indirizzo della nuova pagina e j' è la posizione relativa in P' . Anche in questo caso, il TID originariamente assegnato al record non cambia. Se successivamente, nell 'accedere al record si scopre che nella pagina P esiste sufficiente spazio libero per contenerlo, allora questo può essere riportato nella pagina originaria.

Figura 9.2. Riferimenti ai record.

9.4

Gestore delle strutture di memorizzazione Il gestore delle strutture di memorizzazione offre ag li altri livelli del sistema una visione dei dati permanenti organizzati in collezioni di record e indici

234

Capitolo 9.

Realizzazione dei DBMS

© 88-08-07003-4

astraendo dalle strutture fisiche usate per la loro memorizzazione in memoria permanente. Avendo stabilito come si può memorizzare in modo persistente una col lezione di record dotati di un TID uni voco, resta ancora da stabi lire: come indi viduare la pagina in cu i inserire un nuovo record quando questo viene agg iunto all a co ll ezione; come gestire le situazioni in cui un a sequenza di cancellazioni o di inserìmenti rendono una pagina troppo vuota o troppo piena; quali strutture ausi li arie prevedere per faci litare l'esecuzione delle ricerche. Un'organizzazione dei dati è .un in sieme di algoritmi per gestire le operazioni su di una collezione di record che risponde a queste tre domande. In questa sezione presentiamo brevemente le organizzazioni più importanti.

Organizzazione seriale e sequenziale Il modo più sempli ce di organizzare i record di una collezione è di memorizzarli nell 'ordine in cui si prese ntano. Le pagine possono essere conti gue nell a memoria permanente oppure no, e in quest'ultimo caso sono collegate a li sta. Questa organ izzazione è la più sempli ce e la più efficiente per ciò che riguarda le inserzioni , ed è detta organizzazione seria/e (heap). Se invece i record sono tenuti ordinati sul va lore di un attributo A si parla di organ izzazione sequenziale su A. Questa organizzazione complica l'operazione di inserzione, ma permette di reperire in modo più efficiente i record che hanno un valore specificato dell'attributo A . Organizzazione procedurale L'organ izzazione procedurale, o hash, prevede l'esistenza di un opportuno algoritmo (trasformazione della chiave) che, applicato al valore della chiave, restituisce l' indirizzo della pagina in cui memorizzare, e successivamente cercare, il record ; in caso di insuccesso, esiste un criterio per proseguire la ricerca in modo da completare l'operazione con pochi access i suppl ementari. Se ben configurata, questa organizzazione permette in genere di ritrovare un record , a partire dal va lore dell a chi ave primaria, con un solo accesso all a memoria permanente. Organizzazione ad albero L' organizzazione ad albero di una collezio ne C su di un attributo A prevede l'utilizzo di una struttura dati in memoria permanente detta s +-albero che generali zza l'albero di ricerca bilanciato, con le seguenti caratteristiche: l . Permette di arrivare, con poch i accessi alla memoria permanente, al record con valore k per l'attributo A; 2. Mantiene la collezione C ordinata sull 'attributo A. Questa organizzazione è la più complessa tra quelle illustrate ed è li evemente meno efficiente della precedente quando si deve rispondere ad un ' interrogazione con condizione A = k. Tuttavia, la seco nda caratteristica sopra elencata la rende molto adatta a rispondere ad inteiTogazioni con condizioni tipo A :=: k , A::::: k,k, :SA :S k2.

© 88-08-07003-4

9.4 .

Gestore delle strutture di memorizzazione

235

Indici U n indi ce su un attribu to A di un a relazione R è un insieme ordinato di coppie (ki, {rj}i), dove ki è un valore di A presente in un record diR , ed {r j L è l' insieme dei riferimenti ai record di R in cui A vale ki. Di solito un indi ce è organi zzato a s+- albero per permettere di trovare con pochi access i, a partire da un va lore v, i record di R in cui il valore di A è in un a relazione specifi cata con v . Se interessano solo ricerche del tipo A = k l' indi ce può anche essere organi zzato in modo procedurale . Quando l'attributo A è un a chi ave per la relazione, allora l' insieme {rj L contiene in realtà un unico TID. Quando A non è una chiave l' indi ce viene detto indice a liste invertite. U n indi ce pu ò anche essere defi nito su di un insieme A 1 , ••• , A 11 di attributi . In questo caso , l' indi ce conti ei1e una lista di riferimenti per ogni combinaz ione di valori ass unti dagli attributi A 1, • • • , A 11 nell a relaz ione, e può essere utili zzato per ri spondere in modo effi ciente ad interrogazioni che spec ifi chino un valore per ciascuno di questi attributi . Organizzazioni statiche e dinamiche

In tutti i m etod i descritti , non abbi amo specificato come si gesti sco no le situ azio ni in cui un a pagina di venta troppo vuota o troppo piena. A seconda d i come si affronta questo problema, l' organi zzazione dei dati che ne scaturi sce può essere statica o dinamica. U n'organi zzazione è detta statica se, un a volta dimensionata per un a certa quantità di dati , non si ri confi gura automati camente in seguito ad un aumento de i dati memorizzati, il qu ale comporta, quindi , un degrado dell e prestazio ni , che si e limina con una riorganizzazione . Un'organi zzazione è detta invece dinamica se è in grado di adeguars i all a quantità d i dati memori zzati , preservando le prestazioni senza bisogno di ri organizzaz ioni . Tutte le organi zzaz ioni sopra descritte ammettono un a versione stati ca ed un a d in amica.

Scelta dell'organizzazione

La scelta dell' organi zzazio ne più opportun a per ogni relaz ione costitui sce il nocciol o de ll a progettaz ione fi sica, ed è un compito arduo che necess ita di esperien za e di strumenti di supporto. La scelta dell 'organi zzazione no n è mai definiti va, ma varia durante l' uso del sistema, e in parti co lare qu ando si osservano dell e prestazioni poco soddi sfacenti. La scelta dell 'organi zzazione per un a relazione è in genere guidata dall 'applicazione che la usa ed è la più importante da eseguire in modo efficiente. In estrema sintesi, se tale applicazione utili zza un ' alta percentu ale dei dati si sceglie un ' organi zzaz ione seri ale, se l' applicazione se leziona un pi cco lo insieme di record in base al valore di un attributo A si scegli e un ' organizzazio ne ad albero, mentre se seleziona un unico record sull a base del valore di un a chi ave si sceg li e un ' organizzazione procedurale. Per fac ilitare l' esecuzione di ogni altra applicazi one è possibile aggiungere indici sug li attributi coinvo lti , tenendo conto dell e indi cazioni date nel Capitolo 7.

Esempio 9.1 Il lin guaggio per la defini zio ne dell o schema dell a base d i dati prevede co mandi per scegli ere le strutture per memorizzare i dati. Vedi amo le solu zioni adottate da alcuni sistemi commerciali .

236

Capitolo 9.

Realizzazione dei DBMS

© 88-08-07003-4

Nel sistema INGRES una relazione R{ A 1 : T1, ••• , A 11 : T,, } è memori zzata ini zialmente con un 'organi zzazione seri ale, chi amata heap. Una vo lta caricati i dati, è poss ibile trasform are l'organizzazi one di una relaz ione in sequ enziale, hash stati ca, oppure ad albero statico (ISA M ), con uno dei seguenti comandi: MODIFY R TO HEAPSORT ON A; ASC MODIFY R TO HASH ON A; MODIFY R TO ISAM ON A;

Le d ichiaraz ioni dell e organi zzazio ni prevedono ino ltre la possibilità di imporre che i valori dell a chi ave siano uni ci (per esempi o, HAS UNIOUE ON A;) oppure che i valori siano memorizzati co mpress i, eliminando i caratteri bi anchi (per esempi o , CHEAPSORT). È possibile po i aggiungere indi ci con il comando CREATE IN DEX Nome ON R(A;)

che vengono trattati dal sistema come re lazioni binarie con attributi (A;, TID), dove i valori d i TID so no g li identificatori interni dell e ennupl e. Un attributo può essere sosti tuito da una co mbinazione di più attributi , fin o ad un mass imo di se i. Questi ind ici possono a loro volta essere organi zzati in modo sequenziaJe, hash o ISAM, come ogni altra relazione. In altri sistem i relazionali (co me DB 2, Oracle e Sybase) le ennupl e di un a relazione sono memorizzate con un 'organi zzazione seri ale e, per agevo lare le operazio ni , si utili zzano indi c i su alcuni attributi o su combinazioni di attributi. G li indici sono memori zzati ad albero dinamico. Gli indi ci si defini sco no con il comando: CREATE [UNIQUE]INDEX Nome ON R (A;)

L'opzione UNIQUE si usa per indici per chi av i.

9.5

Gestore dei metodi di accesso Il gestore dei metodi di accesso offre operatori per costruire, o elimin are, collezioni di record o indi ci e per recuperare i record uno dopo l ' altro nell ' ordine in cui sono memori zzati , oppure attraverso indi ci, astraendo dalla loro organizzazione fi sica. Gli access i all e relaz ioni e ag li indici avvengo no con modalità simili a quelle prev iste per i cursori descritte ne l Capito lo 8, qu ali apertura relazion e, avanzamento del cursore, pos izio namento del cursore sull a base del valore di un attributo, veri fica di fi ne relazione, chiu sura.

9.6

Gestore delle interrogazioni La macchin a log ica offre un a vis ione de i dati permanenti co me un insieme di tabe ll e relazionali sulle quali si opera con g li operatori deii ' SQL. Essa prevede i seguenti moduli : - il gestore delle autorizza::.ioni per contro ll are che so lo gli utenti autori zzati facc iano uso dei dati co n le modalità consentite; - il gestore del catalogo per trattare i metadati, ovvero le informazio ni sulle caratteristiche logiche e fi siche dei dati presenti ;

© 88-08-07003-4

9.6.

237

Gestore delle interrogazioni

il gestore delle interrogazioni per controllare la correttezza delle interrogazioni e stabilire la strategia migliore per eseguirle con un opportuno algoritmo detto piano di accesso. Nel seguito ci soffermiamo sulla gestione delle interrogazioni , compito fra i più importanti di un DBMS svolto con le seguenti fasi: l. Controllo lessicale, sintattico e semantico dell'interrogazione e sua rappresentazione in forma di albero logico; 2. Riscrittura algebrica dell' albero logico; 3. Ottirnizzazione fisica e generazione del piano di accesso; 4. Esec uzione del piano di acce~so . Una volta controll ata la correttezza dell ' interrogazione, essa viene rappresentata con un albero logico, usando gli operatori algebrici , sul quale si opera nelle fasi successive come segue.

9.6.1

Riscrittura algebrica

Durante la ri scrittura algebrica si applicano tecniche di trasformazione dell' interrogazione, basate su lle proprietà algebriche degli operatori relazionali, per trovarne una forma equivalente eseguibile con costi inferiori . Un possibile algoritmo di riscrittura algebrica è riportato nel Capitolo 4 . Vediamo alcuni esempi di ri scritture algebriche, con riferimento alle seguenti relazioni: Studenti (Matricola , Nome, Provincia, AnnoNascita) Esami (Codice, Materia, Candidato, Voto, Lode)

Esempio 9.2 Si consideri la seguente interrogazione: SELECT Nome FROM Studenti, Esami WHERE Matricola= Candidato ANO Provincia= 'PI ' ANO Voto > 25;

rappresentata con l'albero logi co iniziale': JT b

Nome

l

O" Pr ovincia=' P l '

1\

V otn=25

l

1> 200

l

A Ycou N T(•)

.su M ( B )

l O" A > 100

l

R Albero fisico

Project({A , COU NT (*)l)

l Filter(SU M(B) > 200)

l

GroupBy({A}, {COU NT (•) , SU M ( B) l)

l

Sort({A)) Filter(A

l

> 100)

l

TableScan (R) Si noti c he (a) le funzioni di aggregazio ne di y e GroupBy sono que ll e di verse dell a SELECT e deii ' HAVING , (b) la condi zio ne deli ' HAVING di venta un Filter sul GroupBy e (c) per produrre il ri sultato occorra un Project.

Unione, differenza e intersezione L' operazio ne d i uni o ne è sempli ce da rea li zzare se sono ammessi record duplicati nel risultato (operato re UNION ALL in SQL). Se i dupli cati vanno e liminati (operato re in sie mi sti co UNION in SQL), l' o perazio ne è ancora sempli ce da realizzare ne ll' ipotesi che i record de lle d ue re lazio ni sia no ordinati e privi di d upl icati. In modo ana logo si procede per la diffe re nza e l' intersezio ne in sie mistica d i d ue re lazioni. Altri modi di procedere sono possibili per eseguire q ueste operazioni che no n richiedono l'ordiname nto de i dati e 1' assenza di d uplicati, ma per e mplic ità non si pre ndo no in considerazio ne. Vediamo g li o peratori fis ici che reali zzano questi algoritmi : - Union (O E. Ot ), Except (OE , O, ), lntersect (OE , o ,) : per le operazio ni insie mistiche con i record degli opera ndi o rdinati e privi di duplicati ; - UnionAII (OE , 0 1 ): per l' uni o ne con duplicati .

© 88-08-07003-4

9.6.

Gestore delle interrogazioni

249

Esempio 9.7 Si consideri l'interrogazione: SELECT R.A FROM R WHERE R.A < 100 UNION SELECT S.C FROM S WHERE S.C > 200;

Albero logico

u

/~

rrs.c

7r R.A

l

l

CYR .A < IOO

CYs.c > 200

l

l

s

R Albero fisico Uni on

~~

Distinct

l

Project({R.A))

l

Filter(R .A < 100)

l

SortScan(R, {A))

9.6.3

Distinct

l

Project({S.C))

l

Filter(S.C > 200)

l

SortScan(S, {C))

Esecuzione di un piano di accesso

Come abbiamo visto all'inizio della sezione, un nodo del piano di accesso è un oggetto che ha quattro metodi, ed in particolare li ha la radice, quindi se si dà un nome al piano di accesso (ad es. AlberoFisico), il risultato dell ' interrogazione si ottiene eseguendo il seguente programma: AlberoFisico.open() ; while !AiberoFisico.isDone() print(AiberoFisico.next()); AlberoFisico.close();

//inizia le operazioni //finche' ci sono elementi //stampa prossimo record //termina le operazioni

Quando si esegue il metodo open() della radice dell' albero, esso inizializza lo stato dell'operatore ed eseg ue l'open() del figlio e così via fino ad arrivare al le foglie . Terminata la fase di inizializzazione, inizia la fase di generazione del ri sultato.

250

Capitolo 9.

Realizzazione dei DBMS

© 88-08-07003-4

Quando si esegue il metodo next() dell a radi ce dell ' albero , esso esegue il next() del figlio per ottenere il pross imo record del ri sultato, il figlio fa la stessa operazione sul figlio e così vìa fino ad arri vare all a foglia: i record ritornati dalla fog li a faran no la strada inversa. Ogni operatore quindi è pronto a restituire un record a ll a volta, ri sultato de ll 'elaboraz ione del record ottenuto dal figlio (o dai figli , nel caso di operatori binari) . TI Sort è l' unico operatore che si di scosta da questo schema: il metodo che compi e gran parte del lavoro è open() , che richiede tutti i record al nodo fi g lio, li me mori zza ordinati in una tabella temporanea per poi restituirli uno alla volta su richiesta del nodo padre.

9. 7

Gestore della concorrenza La tecni ca utilizzata più comunemente per reali zzare il controllo della concorrenza nei sistemi centrali zzati è la tec nica del blocco a due fasi (Two Phase Lock, 2PL). Utilizzando questa tecnica, si associa ad ogni dato usato da un ' operazione un blocco (lock) in lettura o in scrittura. Ogni transazione, prima di eseguire un 'azione su di un dato , richiede il blocco corri spondente di lettura o scrittura. Due transazioni non possono avere blocchi incompatibili sullo stesso dato , ovvero blocc hi con almeno uno dei due di scrittura. Pertanto in ogni momento, per ogni dato possono essere stati assegnati o più blocchi in lettura o, alternati vamente, un solo blocco in scrittura. La tran sazione che richiede un blocco incompatibile su un dato viene messa in attesa, e ri sveg liata so lo quando il dato diventa disponibile. Per garantire la seria li zzab ilità e l'isolamento, ogni tran sazione viene di solito eseguita con la tecnica del blocco a due fasi stretto, che prevede che i blocchi di una tran sazion e vengano rilasciati tutti assieme, so lo dopo che la transazione sia terminata. La tecnica del blocco prevede che una tran sazione venga posta in attesa quando richiede un blocco che non può ottenere. Può accadere che questa attesa diventi infinita: supponiamo che T 1 ottenga un blocco in scrittura su X 1 e T2 ottenga un blocco in scrittura su X 2 , e che successivamente T 1 richieda anch'essa un blocco in scrittura su X 2 : in questo caso T 1 viene messa in attesa del fatto che T2 rilasci il proprio blocco . Se a questo punto T2 richiede un blocco su X 1, anche T2 va in attesa del fatto che T 1 rilasci il proprio blocco, e si crea una situ azione di attesa "circolare", ovvero di stalla (deadlock) . I metodi comunemente usati per sbloccare una situazione di stalla sono i seguenti. Rilevazione tramite grafo delle attese: si costruisce un grafo avente come nodi le transazioni , agg iungendo un arco da T 1 a T2 ogni volta che T 1 va in attesa del rilasci o di un blocco da parte di T2 . Ogni volta che si crea un ciclo nel grafo, una delle tran sazioni coinvolta viene fatta abortire (tipicamente la più giovane, quella che ha meno risorse o quella il cui aborto ha il minor costo). Rilevazione per time-out: ogn i volta che un 'attesa si prolunga o ltre un certo limite, la transazione in attesa viene abortita, presupponendo l'esistenza di uno stalla.

© 88-08-07003-4

9.8.

Gestore dell'affidabilità

251

Il blocco a due fas i garantisce la serializzabil ità, ma limita la concorrenza possibile tra di verse transazioni. Per esempio, un ' apphcazione lu nga che legge una grande quantità di dati potrebbe non riuscire mai ad acqui sire tutti i blocchi necessari, oppure, quando li avesse acqu isiti tutti, potrebbe impedire ad ogni altra transazione che voglia effettuare modific he di partire. Per questo motivo, molti sistemi permettono al programm atore di lim itare la quantità di blocchi richiesti dalle applicazioni , anche se questo comporta la perdi ta dell a seri alizzabilità (si veda il Capitolo 8).

9.8

Gestore dell'affidabilità .. Co mpito del gestore dell' affidabilità è di eseguire le operazionj delle transazioni e la loro termjnazione garantendo che la base di dati contenga solo gli effetti delle transazioni terrrun ate normalmente e sia protetta da fa llimenti di transazione, di sistema e di sastri . Le operazioni delle transazioni possono essere eseguite con algori tmi diversi. Supponi amo che si adotti l' algoritmo disfare -rifare, come accade nei sistemi DB2 e Oracle: una modifi ca di un dato può essere riportata sull a base di dati prima che la transazione termini. Nel caso di fa llimento di transazione o di sistema occorre annull are le modific he fatte dall a transazione sull a base di dati (di sfare) ; - un a transazione T è co nsiderata term inata normalmente, e viene scritto nel giornale (descritto più avanti ) il record (T , commit) , senza che le sue modifi che vengano preventi vamente riportate nella base di dati ; questo co mpito viene svolto dal gestore del buffer quando lo ri ti ene opportuno. Nel caso di fallimento di sistema occon e ri fare le modific he fatte dalle transazioni terminate norm almente perché non si è certi che i loro effetti siano stati riportati sulla base di dati. La struttura dati che viene utili zzata in mani era cruciale tanto per disfare che per ri fare gli effetti delle transazioni è il giornale delle modifiche (log ). Questo è un archi vio gestito in maniera sicura (cioè mantenuto in due copie su dispositi vi con fallimento indipendente) che contiene, per ognj operazione effettu ata da una transazione sui dati, le seguenti informazioni : L' identifi catore dell a transazione che ha effettu ato l'operazio ne. L'operazione eseguita (inserzione, aggiorn amento, cancell azione, inj zio transazione, commit, abort). L' identifi catore del record modificato. Il vecchi o ed il nuovo valore del record. Poiché un malfunzionamento può anche intercorrere tra il momento in cui un ' operazione viene eseguita ed il momento in cui tale operazione viene registrata nel giornale, è essenziale registrare tutte le operazioni nel giornale pri ma che esse vengano esegui te. Pi ù precisamente, è necessario seguire le due regole seguenti :

252

Capitolo 9.

Realizzazione dei DBMS

© 88-08-07003-4

l. Regola per disfare (Write ahead log): prima di eseguire una modifica, occorre salvare il vecchio valore nel giornale, in modo che non vada perduto in caso di malfunzionamento. 2. Regola per rifare (Commit Rule): prima di considerare terminata una transazio ne, occon·e salvare nel giornale i nuovi valori dei dati modificati, in modo da poter rieseguire la transazione in caso di falljmento di sistema o di disastro.

Avendo a di sposizione il giornale, ed una vecchia copia della base di dati , la proced w-a di ripri stino in caso di malfunzionamento è la seguente: In caso di fallimento di transazione, si disfano gli effetti di tutte le operazioni della tran sazione, utilizzando le informazioni sul giornale, ed infine si memorizza una marca di abort sul giornale stesso. In caso di fallimento di sistema, prima di rendere operativa la base di dati , si esegue il comando restart che scandi sce il giornale per disfare gli effetti dell e tran sazioni attive al momento del fallimento e per rifare gli effetti delle transazioni terminate normalmente. Per limitare poi la porzione di giornale da scandire, i DBMS effettuano ad intervalli brevi e regolari un 'operazione di allineamento ( checkpoint) che consiste nel riportare in memoria permanente tutti gli aggiornamenti effettuati nei buffer, e nel memori zzare poi sul giornale una marca di checkpoint. In questo modo, in caso di fallimento di sistema, la procedura di ripristino può partire dallo stato del giornale e della base di dati in linea, avendo la certezza che non c'è bisogno di rifare nessun a delle operazioni eseguite prima del checkpoint. Si osservi tuttavia che è necessario disfare le operazioni eseguite prima e dopo il ch.eckpoint da transazioni non terminate normalmente. In caso di di sastro, si porta in linea la vecchia copia stabile dello stato della base di dati e si riapplicano ad essa tutte le operazioni reg istrate sul giornale da parte di transazioni che abbiano effettuato il comrn.it. Se la vecchia copia era stata presa in un momento di attività del sistema, è anche necessario di sfare gli effetti di tutte le tran sazioni che erano in corso al momento dell a copia e che non avevano ancora effettuato il commit al momento del malfunzionamento. Si osservi che la regola per di sfare garanti sce che il vecchio valore di un record modificato non vada mai perduto, ma implica che, in seguito ad un malfun zionamento avvenuto poco dopo la scrittura del record nel giornale, non sia possibile sapere se l'operazione fosse stata realmente effettuata sui dati. Si osservi inoltre che un malfunzionamento può avere luogo anche durante il ripri sti no. Per ambedue questi moti vi, è importante che le operazioni di "di sfacimento" e "rifacimento" che si effettuano durante il ripristino siano effettuate in maniera " idempotente", ovvero in modo da ottenere l' effetto voluto sia che si stia disfacendo un'operazione realmente effettuata, sia che si stia di sfacendo un ' operazione già di sfatta.

© 88-08-07003-4

9.9

9.9.

253

Conclusioni

Conclusioni Sono state presentate le principali tecniche utilizzate per realizzare le fu nzionalità fondamentali di un DBMS centralizzato: la gestione dei dati, delle interrogazioni, della concorrenza e dell'affidabilità. Per mostrare come venga eseguita un ' interrogazione SQL è stato introdotto il formalismo dei piani di accesso, una versione semplificata di quello usato dai sistemi commerciali per visualizzare il risultato dell' ottimizzazione fisica di un'interrogazione. Questa informazione è molto utile all'amministratore della base di dati per la messa a punto delle strutture di memorizzazione dei dati al fine di un 'esecuzione efficiente delle interrogazioni. Per fare pratica con i piani di accesso, dal sito del libro si può scaricare il sistema JRS , sviluppato in Java per scopi didattici presso il Dipartimento di Informatica dell'Università di Pisa, che funziona con ogni sistema operativo dotato di un a macchina virtua le Java, supporta un ' ampia versione dell' SQL e fornisce i piani di accesso delle interrogazioni con gli operatori descritti in questo capitolo. È interessante confrontare il piano di accesso immaginato per un ' interrogazione con quello prodotto da un sistema con un buon ottimizzatore.

Esercizi 1. Dire quali delle seguenti affermazioni è vera o falsa e giustificate la risposta: (a) i seguenti piani di accesso per l' interrogazione SELECT A FROM R ORDER BY A

non sono equivalenti : Sort({AJ)

l

Project({AJ)

Project({AJ)

l

SortScan(S, {A)}

l

TableScan(R} (b) (c) (d) (e) (f)

operatore logico e operatore fisico sono sinonimi. ad ogni interrogazione SQL corri spondono più alberi logici. ad ogni albero logico corrispondono più alberi fisici. la gestione della concorrenza con il blocco dei dati non crea cond izion i di stall o. con il metodo disfare-rifare, nessun dato modificato da una T può essere riportato nella BD prima che il corrispondente record del giornale sia scritto nell a memoria permanente. (g) con il metodo rifare, tutte le modifiche di una T devono essere riportate nella BD prima che il record di commit sia scritto nel giornale.

2. Si considerino due relazioni unarie R e S con i seguenti record : R(A) = {7 , 2, 8, 3, l , 3, 6} S(B) = {4, 2, l , 3, 2, 7, 3} Mostrare (a) il contenuto di un indice su ll 'attributo A diR e (b) il risultato prodotto C:B S usando il Nestedloop. dalla giunzione R A

254

Capitolo 9.

© 88-08-07003-4

Realizzazione dei DBMS

3. Si consideri l a relazione R(A, B, C) , con chiave primaria A, e l ' interrogazione: SELECT FROM WHERE GROUP BY

A, COUNT(*)

R A > 100

A;

Dare l'albero logico iniziale deli ' inten ogazione e un possibile piano di accesso. Come cambia l a solu zione se nella SELECT ci fosse DISTINCT A, COUNT(*)? 4. Si consideri la relaz ione Studenti(Matricola, Nome, AnnoNascita), ordin ata sull a chi ave primaria Matricola, e l 'interrogazione: SELECT FROM WHERE GROUP BY ORDER BY

DISTINCT Matricola, COUNT(*) Studenti Anno Nascita = 1974 Matricola Matricola;

D are l 'albero logico inizi ale dell'interrogazione e si dica se il seguente pi ano d' accesso produce il ri sultato cercato. Se non va bene, l o si modifichi in tre modi: (a) aggiungendo prima solo le parti mancanti (operatori e parametri), (b) semplificando poi il pi ano eliminando operatori inutili e (c) mod ificando infine il pi ano supponendo che es ita un indice su AnnoNascita: Sort({M al ri co/a l)

l

Distinct

l

Sort(( M al ri cola l)

l

Project( (M atri cola})

l

GroupBy((Malri co/a}, (})

l TableScan( S1uden1i)

5. Si consideri il seguente schema relazionale: Aule(CodiceA, Edificio, Capienza) Lezioni(CodiceA, CodiceC, Ora, GiornoSett, Semestre) Corsi (Cod iceC, Nomee, Docente) e l'interrogazione: SELECT FROM WHERE

A.Edificio, COUNT(*) Aule A, Lezioni L A.CodiceA = L.CodiceA ANO Semestre= 1 GROUP BY A.Edificio COUNT(*) > 2; HAVING Si di a l ' albero logico ini ziale dell ' interrogazione e un pi ano di accesso che utili z-

© 88-08-07003-4

9.9.

255

Conclusioni

zi indici (a) nel caso di giunzione con l 'operatore Nestedloop e (b) nel caso di giunzione con l 'operatore lndexNestedloop 6. Si con ideri la base di dati : Clienti(Codice, NomeCI , AnnoNascita) , con chiave primaria Codice Movimenti(CodiceCI , Ammontare, Tipo) , con chiave esterna CodiceCI e l' interrogazione: NomeCI , SUM(Ammontare) Clienti , Movimenti Codice = CodiceCI ANO AnnoNascita = 1974 GROUP BY Codice, NomeCI COUNT(*) > 5 ; HAVING

SELECT FROM WHERE

Dare l 'albero logico ini ziale dell'interrogazione e si di ca (a) se il seguente piano d'accesso è corretto, (b) se produce il ri sultato cercato. Se non va bene, lo si modifichi aggiungendo le parti mancanti (operatori e parametri): Project({ NomeC/, SU M ( Ammontar e) J)

l

GroupBy({ Codi ce, Nom eCL), {S U M (Ammon tare) J)

l

lndexNestedl oop( Codi ce

= Codi ceCI)

~~ SortScan( Cii en ti , {Cod ice })

TableScan( Movi m enti )

Note bibliografiche Per approfo ndire gli argo menti di questo capitolo si rin v ia al libro [A1b01], dedicato all e strutture e al goritmi per l a reali zzaz ione di DBMS . Il si stema JRS con l a rel ativa documentazione è di sponibile sul sito W eb del libro alla pagin a http ://www. di.unipi . it!~ albano/costruireDBMS.html.

BIBLIOGRAFIA

P. Atzeni and V De Antonellis. Relational Database Theory. Morgan Kaufmann Publishers, San Mateo, California, 1993. [AAGOO] A. Albano, G. Antognonj , and G. Ghelli. View operations on objects with roles for a statically typed database language. IEEE Transactions on Knowledge and Data Engineering, 12(4): 548-567 , 2000. S. Abiteboul and N. Bidoit. An algebra for non normalized rela[AB84] tion s. In Proceedings of the ACM SIGACT-SIGMOD Symposium on Principles of Database Systems ( PODS) , 1984. [ACPT02] P. Atzeni, S. Ceri, S. Paraboschi , and R. Torlone. Basi di dati. Modelli e linguaggi di interrogazione . McGraw-Hill, Milano, 2002. [AHV95] S. Abiteboul , R. Hull , and V Vianu. Database Foundations. Addison-Wesley, Reading, Massachusetts, 1995 . A. Albano. Costruire sistemi per basi di dati. Addison-Wesley, [AlbOl] Milano, 2001. [Arm74] W. W. Armstrong. Dependency structures of database relationships. In Proceedings ofthe IF/P Congress, pages 580-583 , 1974. C. Beeri and P.A. Bernstein. Computational problems related to [BB79] the design of normal form relational schemas. ACM Transactions on Database Systems, 4(1):30-59, 1979. [BCN92] C. Batini, S. Ceri , and S. Navathe. Conceptual Database Design. An Entity-Relationship Approach. The Benjamin/Cummjngs Publishing Company, Inc. , Redwood City, California, 1992. [Ber76] P.A. Bernstein. Synthesizing third norma) fonn relations from functional dependencies. ACM Transactions on Database Systems, 1(4):277-298, December 1976. [BLN87] C. Batini , M. Lenzerini , and S. Navathe. A comparative analysis of methodologies for database schema integration. ACM Computing Surveys, 18(4):2-18, 1987. [CBOO] T. Connolly and C. Begg. Database Solutions. A step-by-step guide to building databases. Addison-Wesley, Reading, Massachusetts, 2000.

[AA93]

258

Bibliografia

© 88-08-07003-4

S. Ceri , editor. Methodology and Tools for Database Design. North-Holland, Amsterdam, 1983. [CGT90] S. Ceri, G. Gottlob, and L. Tanca. Logic Programming and Data Bases. Springer-Verlag, Berli n, 1990. [Cod70] E.F. Codd. A relational mode! fo r large shared data banks. Communications of the ACM, 13(6):377- 387, 1970. [DM88] J. Diederich and J. Milton. New methods and fast algorithms for database normalization . ACM Transactions on Database Systems, 13(3):339-365, 1988. [ENOl] R. Elmasri and S.B . Navathe. Sistemi di basi di dati. Fondamenti. Prima edizione italiana. Addi son-Wesley, Milano, 200 1. [FT95] P. Fraternali and L. Tanca. A structured approach for the defìniti on of the semantics of active databases. ACM Transa ctions on Database Systems, 20 (4):41~71 , 1995. [Har87] D . Harel . Statecharts: a visual forma li sm for complex system s. Science ofComputer Programming , 8:23 1-274, 1987. [KBL05] M. Kifer, A. Bernstein, and P. M. Lewis. Database Systems. Addison-Wesley, Reading, Massachusetts, second edition , 2005. [L078] C.L. Lucchesi and S.L. Osborn. Candidate keys for relations. Journal of Computer and System Sciences , 17(2) :270-280, 1978 . [Mac02] L. A. Maciaszek. Sviluppo di sistemi informativi con UML. Addison-Wesley, Milano, 2002. [Mai83] D . Maier. The Theory of Relational Databases . Computer Science Press, Rockville, Maryland, 1983. [Mar79] T. De Marco . Structured Analysis and System Specification. Prentice Hall, Inc. , Englewood Cliffs, New Jersey, 1979. [MR92] H. Mannila and K.R. Raiha. The Design of Relational Databases . Addison-Wesley, Reading, Massachusetts, 1992. [RBP+9 1] J. Rumbaugh, M. Blaha, W. Premerl anj , F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall International , Inc., London, 1991 . R. Ramakrishnan and J. Gehrke. Sistemi di basi di dati. McGraw[RG03] Hill , Milano, 2003. [SB02] D.E. Shasha and P. Bonnet. Database Tuning : principles, experiments, and troubleshooting techniques. Morgan Kaufmann Publishers, San Mateo, California, 2002 . [Sch77] J.W. Schmidt. Some high levellanguage constructs for data of type relation. ACM Transactions on Database Systems, 2(3) :247-26 1, 1977. [SKS02] H. F. Si lberschatz, H . F. Korth , and S. Sudarshan. Database System Concepts. McGraw-Hill, New York, 4th edition , 2002. [Teo99] T. Teorey. Database Modeling and Design. The E-R Approach. Morgan Kaufmann Publishers, San Mateo, California, 1999. [TF82] D.M. Tsou and P.C. Fischer. Decomposition of a relation scheme into Boyce-Codd Normal Fonn. ACM SIGACT News, 14(3):23-29, 1982. [Ull 83] J.D. Ullman. Principles of Database Systems. Computer Science Press, Rockville, Maryland, second edition, 1983.

[Cer83]

© 88-08-07003-4

Bibliografia

[UWOl]

259

J. D. Ullman and J. Widom. A First Course in Database System. Prentice Hall, Inc. , Englewood Cliffs, New Jersey, second edition, 2001 . [vdLO l] R. van der La ns. Introduzione a SQL. Seconda edizione italiana. Addison-Wesley, Milano, 200 l . [WC96] J. Widom and S. Ceri, editors. Active Database Systems: Trigger and Rules for Advanced Database Programming . Morgan Kaufmann Publishers, San Mateo, California, 1996. [You89] E. Yourdon. Modern Structured Analysis. Yourdon Press, Englewood Cliffs, New Jersey, 1989. [ZCF+97] C. Zaniolo, S. Ceri , C. Faloutsos, R.T. Snodgrass, VS. Subrahmanian , and R. Zicari , editors. lntroduction to Advanced Database Systems. Morgan Kaufmann Publishers, San Mateo, California, 1997 .

INDICE ANALITICO

A

B

affidabilità, l 8 algebra relazionale - differenza, l l 2 - espressione, 113 - funzioni di aggregazione, 12 1 -giunzione, 115 -giunzione esterna, 117 - giunzione naturale, 116 - intersezione, 115 - prodotto, 112 - proiezione, l l 2 -proiezione generalizzata, 121 -raggruppamento, 121 - restrizione, l l 2 - ridenominazione, 111 -semi-giunzione, 116 -unione, l 11 analisi -dei dati, 70 - dei requisiti, 60 -funzionale, 65 , 70 anomalia, l 29 API, 216 applicazione, 57 assiomi di Armstrong, 135 associazione, 31, 41 -cardi nalità, 32 - molteplicità, 32 -proprietà strutturali , 32 - rappresentazione grafica, 41 attributo - di un oggetto, 39 -estraneo, 142 -primo, 98, 139

base di dati, 8 BCNF, 150 bloccaggio dei dati , 223 blocco a due fasi (2PL), 250 Boyce-Codd -forma normale di , 150

c calcolo re1azionale di ennuple, 123 CASE, 70, 89 catalogo, 23, 206 checkpoint, 252 chiave, 34, 54, 98, 139 - esterna, 54, 98 - calcolo, 139 -primaria, 54, 98 chiusura -di dipendenze funzionali , 137 -di un insieme di attributi , 135 classe, 41 -rappresentazione grafica, 41 collezione, 30 comunicazione, 35 conoscenza -astratta, 33 - concreta, 28 - rappresentazione, 38 -struttura, 33 - della comunicazione, 35 -procedurale, 34 -operazioni degli utenti , 35 -operazioni di base, 35 controllo - dell a concorrenza, 20, 250

262

Indice analitico

copertura, 141 copertura canonica, 142 D

data ftow diagram, 64 data store, 64 Datalog, 124 DBA (Data Base Administrator), 22 - strumenti per il, 206 DBMS , 9 -arch itettura dei sistemi relazionali , 23 1 - catalogo, 206 -funzionalità, 12 DDL (Data Definition Language), Il deadlock, 250 decomposizione, 143 -che preserva i dati , 144 -che preserva le dipendenze, 146 -con perdita di informazione, 131 definizione per ereditarietà, 45 denormalizzazione, 159 deposito dati, 64 derivazione di una dipendenza, 135 diagramma - di contesto, 65 -di flu sso dati, 64 - di stato, 64, 67 -per la descrizione dei dati , 64 dipendenze - anoma le, 150 -banali , L34 -copertura canonica, 142 - der iva te, 134 -derivazione di , 135 -elementari , 142 -fun zionali , 82, 133 -implicazione logica, 134 - multi va lore, 158 - proiezione, L46 -ridondanti , 142 di stribu zione della base di dati , 22 DML (Data Manipulation Language), l L E

ennupla, 54 entità, 29

© 88-08-07003-4

-debole, 52 - proprietà, 29 -tipo, 29 ereditarietà - singola, 45 - multipla, 45 - stretta, 45 F

forma normale - 3FN, 153 -4NF, 159 - BCNF, 150 - Boyce-Codd, 150 G

generatore -di applicazioni , 16 - di rapporti, 17 gerarchia -di inclusione, 46 -di inclusione multipla, 46 -di tipi , 45 gestione delle interrogazioni -albero fisico, vedi piano di accesso -operatori fisici , 239 - ottimizzazione fi sica, 239 - piano di accesso, 239 - riscrittura algebrica, 237 gestore - dei metodi di accesso, 236 - del buffer, 232 -dell 'affidabilità, 25 1 - della concorrenza, 250 -della memoria permanente, 23 L - delle interrogazioni , 236, 237 - delle strutture di memorizzazione,233 giornale, 251 giUnziOne - metodo index nested loop , 245 - metodo nested loop , 244 - metodo sort-merge, 245 H

identità degli oggetti, 38 indice, 235 indipendenza

© 88-08-07003-4

263

Indice analitico

-fisica, 14 -logica, 14 integrazione di schemi di settore, 84 integrità dei dati , 18 interfaccia, 64 -di un oggetto, 38 -di un tipo oggetto, 39 istanza - di associazione, 31 -valida, 97 -valida di una relazione, 133 J

JDBC (Java Data Base Connectivity), 218 L

linguaggio -di interrogazione, 11 -di quarta generazione (4GL), 17, 221 -per basi di dati , l l , 17 lock, 250 log, vedi giornale M

malfunzionamento, 19 -disastro, 20 -fallimento di sistema, 20 -fallimento di transazione, 19 metadati , 8 metodologia di modellazione, 36 modellazione, 27 -aspetto linguistico astratto, 36 -aspetto linguistico concreto, 36 - aspetto antologico, 28 - aspetto pragmatico, 36 modello dei dati , IO -ad oggetti, 37 -entità-relazione, 51 -gerarchico, 53 - relazionale, 54, 95 , 111 - reticolare, 53 N

normalizzazione, 132, 149 - in 3NF, 154 -in BCNF, 151 -algoritmo di sintesi, 154 -algoritmo di analisi , 152

o ODBC (Open Data Base Connectivity), 217 oggetto, 38 oggetto composto, 42 OID (Object Identifier), 38 operatore fi sico - per il raggruppamento, 247 -per l' intersezione, 248 -per l'ordinamento, 241 -per l' unione, 248 - per la differenza, 248 - per la giunzione, 244 - per la proiezione, 240 - per la restrizione, 241 - per la scansione, 240 organizzazione dei dati , 234 - ad albero, 234 - indice, 235 -procedurale (hash), 234 -scelta, 235 - seriale (heap) e sequenziaJe, 234 - statica o dinamica, 235 ottimizzazione fi sica, 239 p

piano di accesso - esecuzione, 249 PL/SQL, 221 procedure memori zzate, 195 processo, 64 progettazione -concettuale, 78 -fi sica relazionale, 201 - logica relazionale, l Ol progettazione di bas i di dati, 58 -analisi dei requisiti, 58, 69 -CASE, 89 -concettuale, 58, 60, 78 -fisica, 58 , 61 -logica, 58, 61 - metodologia, 58 -strumenti formali, 63 proiezione di dipendenze, 146 Q

QBE, 182 quarta forma normale (4FN), 159 query language, 11

264

© 88-08-07003-4

Indice analitico

R

relazione, 54 -universale, 132 report generator, 17 ripristino dopo fallimento , 252 riscrittura algebrica, 117

s schema - concettuale, 78 -della base di dati , 8 -di relazione, 95 -di relazio ne universale, 132 - esterno, 12, 205 -fi sico, 12 -logico, 12 - relazionale, 96 -scheletro, 75 sicurezza dei dati, 21 sistema -informatico , 2 -di supporto alle decisioni, 7 - direzionale, 7 - operativo, 6 -informativo, l -per basi di dati, vedi DBMS sottoclassi, 46 - copertura, 46 -disgiunte, 46 - partizione, 46 -rappresentazione grafica, 47 sottotipo, 45 SQL, 165 - ALTER TABLE , 203 -CHECK, 193 - COMMIT WORK, 224 - CREATE SCHEMA, 188 - CREATE INDEX, 202 - CREATE TABLE , 189 -CREATE TRIGGER , 196 -CREATE VIEW, 190 -CROSS JOIN, 170 - DELETE, 181 - DIRTY READ , 227 - DROP SCHEMA, 188 - DROP TABLE , 190, 191 - EXCEPT, 178 - FOREIGN KEY, 193

- GROUP BY, 177 - INSERT, 180 -INTERSECT, 178 - JOIN, 170 - LOCK TABLE, 228 - NATURAL JOIN, 170 - ORDER BY, 176 - PRIMARY KEY, 193 - READ COMMITTED, 227 - READ UNCOMMITTED, 227 - REPEATABLE READ , 227 - SELECT, 166, 179 - SERIALIZABLE, 228 - UNION , 178 - UNIOUE, 193 - UPDATE, 180

-4GL, 221 - API, 216 - cursor stability, 227 - dynamic, 216 - embedded, 210 - giu nzione esterna, 170 - nei linguaggi di programmazione,210 -potere espressivo, 181 -procedure memorizzate, 195 -tipi di gi unzione, 169 -transazio ne, 223 - vincoli - interrelazionali , 193 - intrarelazionali , 193 - su attributi , 193 SQL-89, 165 SQL-92, 165 SQL2, 165 SQL:2003 , 165 stalla, 250 state diagram, 64, 67 superchiave, 54, 98, 139 T

terza forma normale (3NF), 153 TID (Tup1e ldentifier), 233 tipo - ennupla, 54 - enumerazione, 40 - oggetto, 39 -record, 40

© 88-08-07003-4

Indice analitico

- seq uenza, 40 transazione, 19, 223 - li velli di isolamento, 227 -reali zzazione, 251 trigger, 196 Two Phase Lock (2PL), 250

u UML (Unifì ed Modeling Language), 93 universo del di scorso, 27

265

v valore null o, 97 vincolo -d' integrità, 18, 34 -d ' integrità din ami co, 34 -d ' integrità stati co, 34 - di copertura, 46 -di di sgiunzione, 46 - estensionale, 46 - strutturale, 46

ALBANO · GHELLI · ORSINI

FONDAMENTI DI BASI DI DATI

Gli autori Antonio Albano è professore ordinario di Basi di dati e sistemi informativi presso la facoltà di Scienze dell'Università di Pisa . È autore di Costruire sistemi per basi di dati (Addison-Wesley, 2001 ). Giorgio Ghelli è professore ordinario di Informatica presso la facoltà di Scienze dell'Università di Pisa . Renzo Orsini è professore associato di Basi di dati e sistemi informativi presso la facoltà di Scienze dell'Università «Ca' Foscari» di Venezia .

L'opera Le basi di dati sono comunemente usate per l'archiviazione, il recupero e l'elaborazione di informazioni. · Questo libro presenta i concetti fondamentali per progettare, realizzare e usare basi di dati in modo interattivo o a partire da programmi . Per affrontare la progettazione gli autori si awalgono di un formalismo grafico che descrive un modello ad oggetti e si ispira al linguaggio unificato UML, mentre la realizzazione è trattata considerando i sistemi relazionali e presentando le caratteristiche del modello dei dati, della teoria della normalizzazione, del linguaggio SOL e le principali funzionalità dei sistemi relazionali. Gli argomenti sono presentati con gradualità per aiutare il lettore a passare agevolmente dai concetti alloro impiego nella realizzazione di applicazioni. Argomenti più specialistici sono trattati separatamente e disponibili sul sito web collegato al libro (http://fondamentidibasididati.it) insieme ad altro materiale utile per lo studio.