La guida completa

GEORGE KOCH, KEVIN LONEY

LA GUIDA COMPLETAORACLE8

McGraw-Hill

Milano New York San Francisco Washington, D.C. Auckland BogotLisbon London Madrid Mexico City Montreal New Delhi San Juan

Singapore Sydney Tokyo Toronto

EDITOR: Paola Rossi

REDAZIONE: Valeria Camatta

PRODUZIONE: Gino La Rosa

REALIZZAZIONE EDITORIALE: Infostudio Monza

GRAFICA DI COPERTINA: progetto di Achilli e Ghizzardi& Associati Milano

STAMPA: Arti Grafiche Murelli Fizzonasco di Pieve Emanuele (MI)

I diritti di traduzione, di riproduzione, di memorizzazione elettronica e di adattamentototale o parziale con qualsiasi mezzo (compresi i microfilm e le copie fotostatiche) sonoriservati per tutti i paesi.

Ogni cura posta nella creazione, realizzazione, verifica e documentazione dei programmicontenuti in questo libro, tuttavia n lAutore n la McGraw-Hill Libri Italia possonoassumersi alcuna responsabilit derivante dallimplementazione dei programmi stessi, npossono fornire alcuna garanzia sulle prestazioni o sui risultati ottenibili dallutilizzo deiprogrammi. Lo stesso dicasi per ogni persona o societ coinvolta nella creazione, nellaproduzione e nella distribuzione di questo libro.

Nomi e marchi citati sono generalmente depositati o registrati dalle rispettive caseproduttrici.

Printed in Italy1234567890AGMLLC921098ISBN 88 386 048351a edizione luglio 1998

Titolo originale: Oracle8 The Complete ReferenceEdizione originale: Osborne/McGraw-HillCopyright 1997 by The McGraw-Hill Companies

Copyright 1998 McGraw-Hill Libri Italia srlPiazza Emilia 5, 20129 Milano

Indice

Introduzione XIII

PARTE PRIMA CONCETTI FONDAMENTALIDEI DATABASE 1

Capitolo 1 Condividere conoscenze e successo 31.1 Lapproccio cooperativo 51.2 Tutti hanno dei dati 61.3 Il linguaggio familiare di ORACLE 71.4 Alcuni esempi comuni 131.5 Un esempio vecchio di 100 anni 15

Capitolo 2 I pericoli di un database relazionale 172.1 davvero facile come sembra? 172.2 Quali sono i rischi? 182.3 Limportanza della nuova visione 192.4 Codici, abbreviazioni e standard

di denominazione 202.5 Perch vengono utilizzati i codici

e non la lingua corrente? 222.6 Come arginare la confusione 232.7 Maiuscole e minuscole nei nomi e nei dati 352.8 Normalizzazione dei nomi 352.9 Cogliere lopportunit 36

VI I N D I C E

PARTE SECONDA SQL: DA PRINCIPIANTI A ESPERTI 37

Capitolo 3 Le parti fondamentali del discorso in SQL 393.1 Stile 413.2 Utilizzo di SQL per selezionare dati da tabelle 423.3 I comandi select, from, where e order by 453.4 Logica e valore 473.5 LIKE 513.6 Un altro impiego delle sottoquery con where 583.7 Come combinare le tabelle 623.8 Creazione di una vista 64

Capitolo 4 Elementi di base dei database relazionalia oggetti 694.1 obbligatorio utilizzare gli oggetti? 694.2 Perch utilizzare gli oggetti? 704.3 Tutti possiedono degli oggetti 714.4 Un esempio di oggetto comune 774.5 Analisi e progettazione orientata agli oggetti 844.6 I prossimi capitoli 85

Capitolo 5 Report e comandi fondamentali di SQLPLUS 875.1 Creazione di un report semplice 905.2 Altre caratteristiche 1015.3 Controllo dellambiente SQLPLUS 1085.4 I fondamenti 110

Capitolo 6 Ottenere e modificare informazioni di testo 1136.1 I tipi di dati 1146.2 Che cos una stringa? 1146.3 Notazione 1156.4 Concatenazione (||) 1176.5 Come tagliare e incollare le stringhe 1186.6 Le funzioni stringa order by e where with 1346.7 Riepilogo 138

Capitolo 7 Giocare con i numeri 1397.1 Le tre classi delle funzioni numeriche 1397.2 Notazione 1417.3 Funzioni a valori singoli 1427.4 Funzioni di gruppo 1507.5 Funzioni di elenco 1577.6 Ricerca di righe con MAX o MIN 1587.7 Precedenza e parentesi 1597.8 Riepilogo 161

I N D I C E VII

Capitolo 8 Le date 1638.1 Aritmetica delle date 1638.2 ROUND e TRUNC in calcoli di date 1728.3 Formattazione di TO_DATE e TO_CHAR 1738.4 Date nelle clausole where 1828.5 Lanno 2000 184

Capitolo 9 Funzioni di conversione e trasformazione 1879.1 Funzioni elementari di conversione 1899.2 Funzioni di conversione specializzate 1959.3 Funzioni di trasformazione 1959.4 Riepilogo 198

Capitolo 10 Raggruppamento di righe 19910.1 Utilizzo di group by e having 20110.2 Viste di gruppi 20510.3 La potenza delle viste di gruppi 20910.4 where, having, group by e order by 213

Capitolo 11 Una query dipendente da unaltra 21511.1 Sottoquery avanzate 21511.2 UNION, INTERSECT e MINUS 228

Capitolo 12 Alcune possibilit complesse 24112.1 Creazione di una vista complessa 24112.2 Alberi genealogici e connect by 24612.3 Utilizzo di viste nella clausola from 255

Capitolo 13 Creazione di un report in SQLPLUS 25713.1 Formattazione avanzata 25713.2 set termout off e set termout on 27213.3 Variabili in SQLPLUS 27213.4 Formattazione di numeri 27513.5 Utilizzo di mask.sql 27813.6 Utilizzo di buffer per salvare comandi

SQLPLUS 27813.7 show all e spool 28113.8 Aggiunta di righe vuote 28113.9 Ulteriori controlli per la realizzazione

di report 283

Capitolo 14 Modifica dei dati: insert, update e delete 28514.1 insert 28514.2 rollback, commit e autocommit 28814.3 delete 29114.4 update 292

Capitolo 15 Utilizzo avanzato di funzioni e variabili 29715.1 Funzioni in order by 29715.2 Diagrammi a barre e grafici 29815.3 Utilizzo di TRANSLATE 30015.4 Copia e incollamento complessi 30415.5 Conteggio delle ricorrenze di stringhe

in stringhe pi lunghe 30815.6 Variabili e sostituzioni registrate 309

Capitolo 16 La funzione DECODE 31516.1 if, then, else 31516.2 Esempio: datazione di fatture 31616.3 Trasposizione di una tabella 32116.4 Utilizzo di MOD in DECODE 32316.5 order by e RowNum 32516.6 Colonne e calcoli in then ed else 32716.7 Maggiore, minore e uguale in DECODE 329

Capitolo 17 Creazione, scaricamento e modificadi tabelle e viste 33117.1 Creazione di una tabella 33117.2 Scaricamento di tabelle 33917.3 Modifica di tabelle 33917.4 Creazione di una vista 34117.5 Creazione di una tabella a partire da unaltra 34517.6 Creazione di una tabella di solo indice 34617.7 Utilizzo di tabelle partizionate 347

Capitolo 18 ORACLE e lautorit 35318.1 Utenti, ruoli e privilegi 35318.2 Che cosa possono concedere gli utenti 35718.3 Concessione di risorse limitate 370

Capitolo 19 Modifica dellambiente di ORACLE 37119.1 Indici 37119.2 Tablespace e struttura del database 38019.3 Cluster 38519.4 Sequenze 386

Capitolo 20 SQLPLUS 38920.1 Generazione di codice per una query 38920.2 Caricamento di variabili 39520.3 Creazione e annidamento di file di avvio

e comandi 39720.4 Riepilogo 401

VIII I N D I C E

Capitolo 21 Accesso a dati remoti 40321.1 Link di database 40321.2 Utilizzo di sinonimi per la trasparenza

di locazione 41021.3 Utilizzo della pseudocolonna User nelle viste 41121.4 Collegamenti dinamici: utilizzo

del comando copy di SQLPLUS 41321.5 Connessione a un database remoto 41521.6 Strumenti di gestione: Oracle*Names 416

Capitolo 22 Introduzione a PL/SQL 41922.1 PL/SQL: nozioni di base 41922.2 La sezione delle dichiarazioni 42022.3 La sezione dei comandi eseguibili 42322.4 La sezione per la gestione delle eccezioni 434

Capitolo 23 I trigger 43723.1 Privilegi di sistema necessari 43723.2 Privilegi di tabella richiesti 43823.3 Tipi di trigger 43823.4 Sintassi dei trigger 44023.5 Attivazione e disattivazione dei trigger 44723.6 Sostituzione di trigger 44923.7 Scaricamento di trigger 449

Capitolo 24 Le procedure 45124.1 Privilegi di sistema necessari 45224.2 Privilegi di tabella necessari 45424.3 Procedure e funzioni 45424.4 Procedure e package 45424.5 Sintassi del comando create procedure 45524.6 Sintassi del comando create function 45624.7 Sintassi per il comando create package 46324.8 Visualizzazione del codice sorgente

di oggetti procedurali esistenti 46724.9 Compilazione di procedure, funzioni

e package 46724.10 Sostituzione di procedure, funzioni

e package 46824.11 Scaricamento di procedure, funzioni

e package 469

Capitolo 25 Implementazione di tipi, viste oggettoe metodi 47125.1 Nuova analisi dei tipi di dati astratti 47125.2 Implementazione di viste oggetto 47625.3 Metodi 483

I N D I C E IX

Capitolo 26 Tabelle annidate e array variabili 48926.1 Array variabili 48926.2 Tabelle annidate 49626.3 Problemi nella gestione di tabelle annidate

e array variabili 503

Capitolo 27 Utilizzo di LOB in ORACLE8 50727.1 Tipi di dati disponibili 50727.2 Definizione dei parametri di memorizzazione

per i dati LOB 50927.3 Gestione e selezione dei valori LOB 511

Capitolo 28 Gli snapshot 53128.1 Che cosa sono gli snapshot? 53228.2 Privilegi di sistema richiesti 53228.3 Privilegi richiesti per la tabella 53328.4 Snapshot semplici e snapshot complessi 53328.5 Snapshot di sola lettura e snapshot

aggiornabili 53428.6 Sintassi del comando create snapshot 53528.7 Aggiornamento degli snapshot 54128.8 Snapshot e trigger 54728.9 Sintassi per il comando create snapshot log 54828.10 Visualizzazione di informazioni su snapshot

esistenti 54928.11 Modifica di snapshot e log di snapshot 55128.12 Scaricamento di snapshot e log di snapshot 552

Capitolo 29 Utilizzo di ConText per ricerche di testo 55529.1 Aggiunta di testo al database 55529.2 Query di testo dal database 55729.3 Impostazione dellopzione ConText 570

Capitolo 30 Impostazione dellopzione ConText 57130.1 Impostazione del database per le ricerche

di testo 57130.2 Impostazione della tabella per query ConText 57530.3 Ottimizzazione degli indici testuali 58330.4 Query in due passaggi 58430.5 Utilizzo dei servizi linguistici 586

Capitolo 31 Concetti orientati agli oggetti avanzatiin ORACLE8 58931.1 Oggetti riga e oggetti colonna 58931.2 Tabelle oggetto e OID 59031.3 Viste oggetto con REF 59831.4 PL/SQL a oggetti 60331.5 Oggetti nel database 605

X I N D I C E

PARTE TERZA IL DIZIONARIO DI DATI DI ORACLE8 607

Capitolo 32 Guida al dizionario di dati di ORACLE8 60932.1 Nota sulla nomenclatura 61032.2 Le carte stradali: DICTIONARY (DICT)

e DICT_COLUMNS 61032.3 Oggetti da cui possibile selezionare:

tabelle (e colonne), viste, sinonimi e sequenze 61232.4 Vincoli e commenti 62232.5 Indici e cluster 62732.6 Oggetti specifici di ORACLE8 63132.7 Link di database e snapshot 63532.8 Trigger, procedure, funzioni e package 63932.9 Allocazione e utilizzo dello spazio,

compreso il partizionamento 64232.10 Utenti e privilegi 64832.11 Ruoli 65132.12 Revisioni 65232.13 Monitoraggio: le tabelle V$ o tabelle

di prestazioni dinamiche 65432.14 Varie 655

PARTE QUARTA OTTIMIZZAZIONE DEL PROGETTO 659

Capitolo 33 Limportanza del fattore umano 66133.1 Comprensione dei compiti dellapplicazione 66233.2 Comprensione dei dati 66733.3 Il modello commerciale 67033.4 Inserimento dei dati 67033.5 Query e report 67133.6 Conclusioni 671

Capitolo 34 Prestazioni e progettazione 67334.1 Denormalizzazione e integrit dei dati 67434.2 La tabella dei calcoli 68234.3 Riepilogo 682

Capitolo 35 I dieci comandamenti della progettazione 68335.1 Verso la normalizzazione dei nomi

degli oggetti 68335.2 Sinonimi di nomi di oggetti 69035.3 Chiavi intelligenti e valori di colonna 69035.4 Comandamenti 691

I N D I C E XI

Capitolo 36 Guida allottimizzatore di ORACLE 69336.1 Quale ottimizzatore? 69336.2 Operazioni di accesso alle tabelle 69436.3 Operazioni che utilizzano indici 69636.4 Operazioni che gestiscono insiemi di dati 70636.5 Operazioni di unione 72036.6 Visualizzazione del percorso di esecuzione 73236.7 Operazioni varie 73836.8 Riepilogo 744

PARTE QUINTA RIFERIMENTO ALFABETICO 745

Capitolo 37 Guida di riferimento in ordine alfabetico 74737.1 Contenuti della guida di riferimento 74737.2 Che cosa non contiene la guida di riferimento 74737.3 Formato generale delle voci 74837.4 Ordine dellelenco 750

PARTE SESTA APPENDICI 1031

Appendice A Le tabelle utilizzate nel libro 1033A.1 Utilizzo delle tabelle 1033

Indice analitico 1071

XII I N D I C E

Introduzione

ORACLE il database pi diffuso del mondo. Fun-ziona su praticamente tutti i tipi di computer, da PC e Macintosh fino aiminicomputer e ai mainframe. In tutte queste macchine il funzionamento vir-tualmente identico, perci basta imparare a utilizzarlo su una piattaforma per po-ter passare alle altre senza problemi. Per questo utenti e sviluppatori diORACLE sono molto richiesti dalle aziende e risulta facile trasportare le proprieconoscenze e capacit in ambienti diversi.

La documentazione di ORACLE completa e assai voluminosa, infatti com-prende oltre cinquanta volumi. La guida completa ORACLE8 il primo libro cheraccoglie tutte le principali definizioni, i comandi, le funzioni, le funzionalit e iprodotti legati a ORACLE in un unico volume, una guida di riferimento che tuttigli utenti e gli sviluppatori dovrebbero tenere a portata di mano.

Le persone a cui si rivolge questo libro possono essere distinte in tre categorie,descritte di seguito.

Utenti finali di ORACLE. possibile utilizzare ORACLE per operazioni estre-mamente semplici come inserire dati ed eseguire report standard, ma in questomodo non se ne sfruttano le potenzialit. come acquistare una potente mac-china sportiva e poi trainarla con un cavallo. Con il materiale introduttivo for-nito nelle prime due parti di questo libro, anche un utente finale quasi del tuttoprivo di esperienza nellelaborazione dei dati pu divenire un piccolo esperto,in grado di generare report con indicazioni in italiano, guidare gli sviluppatorinella creazione di nuove funzionalit e migliorare la velocit e la precisione inunattivit. Il linguaggio di questo libro semplice e chiaro, privo di terminigergali. Le conoscenze di computer o database richieste come presupposto allettore sono assai poche. Il libro guida i principianti a diventare degli esperticon una struttura semplice da seguire e numerosi esempi concreti.

Sviluppatori che si avvicinano a ORACLE per la prima volta. Con tutti i volu-mi di cui dotata la documentazione di ORACLE, trovare un comando o unconcetto importante pu rivelarsi unoperazione molto lunga.

Questo libro cerca di fornire un metodo meglio organizzato e pi efficiente diapprendere i fondamenti del prodotto. Lo sviluppatore che non conosceORACLE viene condotto in una rapida panoramica sui concetti di base, ac-compagnato nelle aree pi complesse, informato di possibili incomprensionicirca il prodotto e lo sviluppo di database relazionali, guidato con principi chiariper lo sviluppo di applicazioni.

Sviluppatori esperti in ORACLE. Come per tutti i prodotti di ampio respiro emolto sofisticati, esistono importanti aspetti riguardo ai quali vi poca o nessu-na documentazione. La conoscenza giunge con lesperienza, ma spesso non vie-ne trasferita agli altri. Questo libro approfondisce molti di questi argomenti,come la precedenza negli operatori UNION, INTERSECTION e MINUS, lutilizzodi SQLPLUS come generatore di codice, lereditariet e CONNECT BY, lelimi-nazione di NOT IN con un join esterno, lutilizzo di ConText, limplementa-zione delle opzioni relazionali a oggetti e molti altri. Nel testo sono inoltre chia-riti molti aspetti che spesso sono oggetto di confusione e suggeriti rigorosi prin-cipi guida per convenzioni di denominazione, tecniche di sviluppo delle applica-zioni, progettazione e prestazioni.

Per qualsiasi utente e sviluppatore, oltre duecento pagine del libro sono dedi-cate a una completa guida di riferimento alfabetica che contiene tutti i principaliaspetti, comandi, funzioni e caratteristiche di ORACLE, con sintassi, riferimentiincrociati ed esempi. Si tratta della pi ampia guida di riferimento pubblicata suquesto argomento.

Struttura del libro

Il libro suddiviso in sei parti e contiene un CD-ROM allegato.La Parte prima unintroduzione ai concetti fondamentali dei database. Si

tratta di argomenti indispensabili per qualsiasi utente di ORACLE, principiante oesperto, dai semplici addetti allinserimento di dati ai DBA. Viene descritta la ter-minologia di base che utenti e sviluppatori possono utilizzare per condividereconcetti in modo coerente e intelligente, al fine di garantire il successo di qualsiasilavoro di sviluppo. Questa parte introduttiva si rivolge a sviluppatori e utenti fina-li di ORACLE, esamina i concetti di base e la terminologia dei databaserelazionali ed evidenzia i pericoli, gli errori classici e le opportunit offerte dalleapplicazioni di database relazionali.

La Parte seconda spiega la teoria e le tecniche dei sistemi di databaserelazionali con le relative applicazioni, tra cui SQL (Structured Query Language)e SQLPLUS. Questa parte inizia con un numero relativamente limitato di presup-posti circa la conoscenza delle tecniche di elaborazione dei dati da parte del letto-re e prosegue passo per passo fino a raggiungere argomenti molto avanzati etecniche complesse. Il testo scritto ponendo molta attenzione alluso di un italia-no chiaro e scorrevole, con esempi unici e interessanti, ed evitando luso di termi-ni gergali o indefiniti.

XIV I N T R O D U Z I O N E

Questa parte dedicata principalmente a sviluppatori e utenti finali che si ac-costano a ORACLE per la prima volta, o che necessitano di un rapido ripasso dialcune caratteristiche di base. Vengono esaminate passo per passo le funzionalitdi base di SQL e dello strumento per query interattive di ORACLE, SQLPLUS.Una volta completata questa parte, il lettore avr una completa conoscenza ditutte le parole chiave, le funzioni e gli operatori di SQL e sar in grado di produr-re report complessi, creare tabelle, inserire, aggiornare ed eliminare dati da undatabase di ORACLE.

Negli ultimi capitoli della Parte seconda sono presentati alcuni metodi avanza-ti per luso di SQLPLUS, linterfaccia a riga di comando di ORACLE, e descrizio-ni approfondite delle nuove e potenti caratteristiche di ORACLE stesso. Questiargomenti sono utili per sviluppatori che hanno una certa familiarit conORACLE, soprattutto coloro che hanno utilizzato le versioni precedenti ma sisono resi conto di avere delle lacune. In alcuni casi si tratta di tecniche mai docu-mentate o addirittura ritenute impossibili da realizzare.

I suggerimenti e le tecniche avanzate trattate in questa parte mostrano comeutilizzare ORACLE in modi potenti e creativi; tra gli altri argomenti sono trattatila generazione di codice, il caricamento di variabili e lannidamento di file di av-vio e processi host in SQLPLUS, oltre ai modi per sfruttare le caratteristiche deidatabase distribuiti, trigger e procedure memorizzate, e le altre funzionalit diORACLE8.

Sono inoltre trattate funzionalit orientate agli oggetti come i tipi di datiastratti, i metodi, le viste oggetto, le tabelle oggetto, le tabelle annidate, gli arrayvariabili e i LOB (Large OBject).

La Parte terza fornisce una guida orientata allutente per il dizionario di datidi ORACLE8, lequivalente delle Pagine Gialle nel mondo dei database. Invecedi elencare in ordine alfabetico le viste del dizionario di dati, queste vengono rag-gruppate per argomento, in modo da abbreviare i tempi richiesti per scoprire qua-le vista fa al caso proprio. Diversi esempi concreti illustrano luso appropriato diqueste viste.

Nella Parte quarta sono trattati argomenti vitali nella progettazione di appli-cazioni utili e ben accolte. Gli strumenti di ORACLE offrono una notevole op-portunit di creare applicazioni efficaci e apprezzate dagli utenti, ma moltisviluppatori non conoscono alcune delle metodiche utilizzabili.

Questa parte si rivolge specificamente agli sviluppatori, le persone che hannola responsabilit di comprendere unattivit e progettare un programmaORACLE in grado di soddisfarla. Gli argomenti non dovrebbero risultare deltutto incomprensibili per gli utenti finali, ma si presuppone che il lettore dispongadi nozioni tecniche riguardo lelaborazione di dati ed esperienza nello sviluppo diapplicazioni per computer.

Lo scopo quello di discutere le tecniche di sviluppo con ORACLE che sisono dimostrate efficaci e utili per gli utenti finali, oltre che di proporre alcuninuovi approcci alla progettazione in aree finora ignorate. Questa parte compren-de I dieci comandamenti della progettazione, un elenco di tutte le regole vitaliper il processo di sviluppo, e si conclude con una guida orientata allutente perlottimizzatore di ORACLE.

I N T R O D U Z I O N E XVI N T R O D U Z I O N E XV

La Parte quinta contiene il riferimento completo per il server ORACLE. Lepagine introduttive sono molto utili per comprendere meglio il testo. Questa par-te contiene riferimenti per la maggior parte dei comandi, delle parole chiavi, deiprodotti, delle caratteristiche e delle funzionalit di ORACLE, con molti rimandiai vari argomenti. La guida si rivolge sia agli sviluppatori sia agli utenti diORACLE, ma presuppone una certa familiarit con il prodotto. Per sfruttare almeglio la guida consigliabile leggere le prime pagine introduttive, che spieganoin dettaglio gli argomenti trattati e mostrano come leggere il testo.

La Parte sesta contiene le istruzioni per la creazione delle tabelle utilizzate nellibro, insieme con quelle per linserimento dei dati. Per chiunque stia imparandoORACLE, la disponibilit di queste tabelle nel proprio ID, o in uno di esercizio,facilita notevolmente la comprensione degli esempi.

Il CD allegato al libro contiene il testo in versione elettronica, in modo che illettore possa portarlo con s sul proprio computer, mentre la versione cartacea ri-mane nel proprio ufficio oppure a casa.

Breve panoramica sui capitoli

Il Capitolo 1 spiega i concetti di base del modello relazionali e le opportunit disviluppare applicazioni di successo condividendo le responsabilit della progetta-zione con utenti finali dotati di buone capacit.

Nel Capitolo 2 sono descritti alcuni dei rischi inerenti lo sviluppo in un am-biente relazionale con tempi rapidi e sono discussi molti degli errori classici com-messi nel passato. In questo capitolo sono inoltre presentati i metodi di controllodei rischi.

Il Capitolo 3 unintroduzione al linguaggio SQL, con lo stile utilizzato inquesto libro, logica e valore, sottoquery, unione di tabelle e creazione di viste.

Nel Capitolo 4 presentato il concetto di tipo di dati astratto, il fondamentodei database relazionali a oggetti.

Il Capitolo 5 mostra come creare un semplice report in SQLPLUS, come uti-lizzare un editor, servirsi dei comandi di SQLPLUS e capire le differenze traSQLPLUS e SQL.

Nel Capitolo 6 viene introdotto il concetto di stringa di caratteri, sono esami-nate le funzioni sui caratteri e descritte le differenze tra caratteri, numeri e datein ORACLE.

Nel Capitolo 7 si esplorano i numeri e le relative funzioni, tra cui quelle a va-lore singolo, di gruppo e di elenco.

Il Capitolo 8 mostra come utilizzare le eccezionali funzioni per la manipola-zione delle date di ORACLE, come calcolare le differenze tra le date e comeformattare le date per la visualizzazione.

Nel Capitolo 9 sono trattate le funzioni di conversione da un tipo di dati in unaltro, o che trasformano i dati in una forma diversa da quella in cui appaiononormalmente.

Il Capitolo 10 mostra come raggruppare e riepilogare le informazioni inORACLE e come creare viste di dati riepilogati.

XVI I N T R O D U Z I O N E

Nel Capitolo 11 sono trattate le sottoquery avanzate, le sottoquerycorrelate, la tecnica del join esterno e luso degli operatori UNION, INTERSECT eMINUS per combinare tabelle di ORACLE. Questo capitolo contiene inoltre unatrattazione avanzata della precedenza e la spiegazione di come utilizzare i joinesterni e NOT EXISTS per sostituire loperatore NOT IN.

Il Capitolo 12 mostra come creare viste molto complesse e contiene un estesoesame dellereditariet e di CONNECT BY.

Nel Capitolo 13 sono trattate tecniche avanzate per la creazione di report e laformattazione in SQLPLUS, per calcolare medie pesate, per utilizzare variabilinei titoli, per formattare i numeri e per utilizzare varie istruzioni SQL nei report.

Il Capitolo 14 discute il modo in cui si modificano i dati nelle tabelle diORACLE e limportanza dei processi di commit e rollback.

Il Capitolo 15 introduce i metodi per creare grafici e diagrammi a barre, perinserire virgole nei numeri, per eseguire complesse funzioni di taglia e incolla eper caricare dinamicamente le variabili.

Nel Capitolo 16 si approfondisce luso della potente funzione DECODE inORACLE, spiegando come effettuare la trasposizione di una tabella, come data-re le fatture, come controllare il movimento della carta nelle stampanti e come re-golare i commit per ampi gruppi di record.

Il Capitolo 17 tratta in dettaglio le basi della manipolazione di tabelle, spie-gando come specificare vincoli e partizioni e descrivendo le viste di sistema checontengono informazioni sulle tabelle.

Nel Capitolo 18 sono trattate le funzioni di sicurezza di ORACLE, tra cui lau-torit dei DBA e i privilegi di accesso che possono essere concessi a ogni utente, oche gli utenti possono concedere ad altri. Viene inoltre spiegato come le modifi-che nellautorit influenzino gli utenti che dipendono da altri e luso dei ruoli nel-le applicazioni e nellamministrazione dei database.

Nel Capitolo 19 sono trattati gli indici, luso dello spazio, la struttura deldatabase, le tecniche per la gestione delle tabelle mediante i cluster, le sequenze ei termini tecnici di base per ORACLE.

Il Capitolo 20 tratta materiale avanzato per sviluppatori e utenti esperti. Mo-stra metodi per lutilizzo di SQLPLUS al fine di generare codice, caricare variabi-li, creare viste con numero di tabelle variabile e utilizzare processi host in modointerattivo.

Il Capitolo 21 descrive i metodi utilizzati per accedere a dati che si trovano indatabase remoti e mostra come creare e mantenere link di database.

Nel Capitolo 22 vengono presentate le strutture e le caratteristiche delleestensioni al linguaggio SQL di ORACLE. Comprendere PL/SQL fondamenta-le per sfruttare caratteristiche come package, procedure e metodi.

Il Capitolo 23 descrive i tipi di trigger disponibili in ORACLE, con esempi deitrigger utilizzati pi comunemente.

Nel Capitolo 24 viene mostrato come utilizzare procedure, package e funzioniin ORACLE e comre creare, compilare, eseguire il debugging e manipolare talioggetti.

Il Capitolo 25 mostra i passaggi necessari per implementare i concettirelazionali a oggetti descritti per la prima volta nel Capitolo 4. Gli esempi illustra-no come sovrapporre strutture relazionali a oggetti alle tabelle relazionali esi-stenti.

I N T R O D U Z I O N E XVII

Il Capitolo 26 mostra come implementare tabelle annidate e array variabilinelle applicazioni e descrive i problemi di gestione relativi.

Nel Capitolo 27 viene mostrato come utilizzare i tipi di dati LOB disponibili apartire da ORACLE8 e come manipolare i valori memorizzati nelle colonne ditipo LOB.

Il Capitolo 28 mostra come utilizzare gli oggetti snapshot di ORACLE per ge-stire la replicazione di dati remoti. Spiega inoltre come funzionano gli snapshot,gli oggetti creati nei database locali e ramoti, e come gestire la programmazionedella replicazione.

Il Capitolo 29 mostra come eseguire ricerche di testo (come le espansioni del-la radice, le corrispondenze fuzzy e la ricerca di frasi).

Nel Capitolo 30 viene spiegato come configurare le tabelle in modo da poterutilizzare i metodi di ricerca descritti nel Capitolo 29. Questo capitolo si rivolgeagli amministratori delle applicazioni che necessitano di configurare e gestire in-dici di testo.

Il Capitolo 31 descrive oggetti riga e riferimenti, oltre alle estensioni a oggettiper PL/SQL. I concetti presentati in questo capitolo sono utili per gli sviluppatoriavanzati che desiderano implementare caratteristiche orientate agli oggetti in undatabase di ORACLE.

Nel Capitolo 32 sono mostrate le viste del dizionario di dati utilizzate conmaggiore frequenza, in maniera orientata allutente: le viste sono organizzate perfunzionalit in modo da facilitarne la localizzazione.

Il Capitolo 33 offre una guida sicura alla creazione di applicazioni che abbianoun chiaro significato per lutente e svolgano bene il compito a cui sono dedicate.Questo approccio fondamentale per avere un buon successo nello sviluppo diapplicazioni.

Nel Capitolo 34 sono esaminati alcuni dei problemi e delle lacune circa lanormalizzazione e i metodi di progettazione; sono inoltre forniti suggerimenti permigliorare le prestazioni e la progettazione di applicazioni ORACLE.

Il Capitolo 35 presenta alcuni concetti nuovi per la comunit relazionale, conlo scopo di portare un passo oltre la metodologia di progettazione; si tratta di in-tegrit dei nomi, normalizzazione dei nomi di oggetti e singolarit. Vengono inol-tre trattate aree che per tradizione risultano irte di difficolt e si conclude con ledieci regole di base per la progettazione.

Il Capitolo 36 spiega il modo in cui ORACLE accede ai dati e sceglie il per-corso da utilizzare per laccesso. Vengono inoltre mostrate le conseguenze di que-ste scelte e i comandi che consentono di prevedere e influenzare la scelta delpercorso.

Il Capitolo 37 una guida di riferimento completa, in ordine alfabetico, di co-mandi, parole chiave, funzioni e altri elementi di ORACLE.

NellAppendice A sono inclusi i listati completi per tutte le tabelle utilizzatenel libro.

XVIII I N T R O D U Z I O N E

Convenzioni di stile

Fatta eccezione per i controlli di uguaglianza (come Citta=CHICAGO),ORACLE ignora la distinzione tra lettere maiuscole e minuscole. Nei listati di co-mandi, funzioni e della loro sintassi forniti nella guida di riferimento alfabeticodel Capitolo 37 questo libro segue lo stile della documentazione di ORACLE, se-condo il quale tutti i comandi SQL sono posti in maiuscolo e tutte le variabili inminuscolo corsivo.

Tuttavia, la maggior parte degli utenti e degli sviluppatori di ORACLE nonutilizza le lettere maiuscole per i comandi SQL, perch troppo faticoso e co-munque per ORACLE non conta nulla. Per questo motivo, nel libro si sceltouno stile leggermente diverso per quanto riguarda gli esempi (e non nei comandiformali e nelle sintassi, come si detto in precedenza), principalmente per miglio-rare la leggibilit. Le convenzioni di stile adottate sono descritte di seguito.

Il grassetto non viene utilizzato nei listati di esempio.

select, from, where, order by, having e group by sono riportati in un tipo di caratte-re diverso da quello del corpo del testo.

I comandi di SQLPLUS sono riportati in minuscolo e con un tipo di caratterediverso da quello del corpo del testo; questo vale ad esempio per column, set,save, ttitle e cos via.

Operatori e funzioni SQL, come IN, BETWEEN, UPPER, SOUNDEX e cos viasono riportati in maiuscolo e con un tipo di carattere diverso da quello del cor-po del testo.

Per le colonne si utilizzano nomi in maiuscolo e minuscolo, come per Caratteri-stica, EstOvest, Longitudine e cos via.

I nomi delle tabelle, come GIORNALE, CLIMA, LOCAZIONE e cos via,sono riportati in maiuscolo.

Nel Capitolo 3 fornita unintroduzione allo stile utilizzato per i capitoli del li-bro fino al Capitolo 36. Il Capitolo 37 contiene unimportante testo introduttivoche descrive le convenzioni di stile adottate e andrebbe letto con cura prima diutilizzare gli elenchi alfabetici.

I N T R O D U Z I O N E XIX

Parte prima

Concetti fondamentalidei database

Capitolo 1

Condividere conoscenzee successo

1.1 Lapproccio cooperativo

1.2 Tutti hanno dei dati

1.3 Il linguaggio familiare di ORACLE

1.4 Alcuni esempi comuni

1.5 Un esempio vecchio di 100 anni

Per poter creare e utilizzare rapidamente ed efficace-mente unapplicazione ORACLE8, gli utenti e gli sviluppatori devono condividereun linguaggio comune e avere una conoscenza approfondita sia del compito specifi-co per cui viene utilizzata lapplicazione, sia degli strumenti di ORACLE.

Si tratta di un nuovo approccio allo sviluppo dei programmi software. In passato,gli analisti di sistemi studiavano le esigenze del mondo del lavoro e progettavano unapplicazione che soddisfacesse tali esigenze. Lutente veniva coinvolto solo nellafase di descrizione del lavoro e, talvolta, nella revisione della funzionalit dellappli-cazione progettata.

Con i nuovi strumenti e le varie modalit di approccio disponibili, e soprattuttocon ORACLE, possono essere sviluppate applicazioni pi adeguate alle aspettativee alle abitudini del mondo del lavoro; a condizione per che si instauri un linguag-gio comune.

Lo scopo specifico di questo libro promuovere questa condivisione di cono-scenze e fornire agli utenti e agli sviluppatori i mezzi per sviluppare appieno le po-tenzialit di ORACLE. Lutente finale conoscer dettagli del lavoro che lo svilup-patore non in grado di comprendere.

Lo sviluppatore apprender funzioni e caratteristiche interne di ORACLE e del-lambiente informatico che sarebbero tecnicamente troppo complesse per lutentefinale.

Tuttavia, questi ambiti di conoscenza esclusiva hanno portata minore rispetto atutto ci che utenti e sviluppatori possono condividere utilizzando ORACLE; sitratta di unopportunit davvero interessante.

Non un segreto che il mondo del lavoro e il mondo degli informatici sonostati in conflitto per molti anni. Differenze culturali e ambiti di conoscenza diversi,interessi e obiettivi professionali diversi, oltre al senso di estraneit che la sempliceseparazione fisica talvolta produce, sono alcuni dei motivi alla base di questa situa-zione.

4 C A P I T O L O 1

Per essere giusti, questa sorta di sindrome non tipica dellinformatizzazione; lastessa situazione si verifica anche tra persone che si occupano di contabilit, gestio-ne del personale o direzione generale, poich i componenti di ogni gruppo tendonoa raggrupparsi e a separarsi dagli altri gruppi collocandosi fisicamente su un piano,un edificio o una citt diversa.

Le relazioni tra individui di gruppi differenti diventano formali, tese e abnormi.Si instaurano le barriere e le procedure artificiali che prendono le mosse da questoisolazionismo, contribuendo ad aggravare la sindrome.

Va bene, penser il lettore, tutto questo pu essere interessante per i sociologi,ma che cosa ha a che fare con ORACLE?

Il fatto che ORACLE non si fonda su un linguaggio arcano comprensibile sol-tanto per gli specialisti, ma modifica la natura del rapporto tra utenti e sviluppatori.Chiunque pu comprenderlo, chiunque pu utilizzarlo. Le informazioni che primaerano intrappolate nei sistemi informatici finch qualcuno non creava un report dipresentazione sono ora accessibili, istantaneamente, da chiunque, semplicemente in-serendo una query in lingua inglese. In questo modo cambiano le regole del gioco.

Utilizzando ORACLE, la comprensione tra i due campi migliorata radicalmen-te, aumentata la conoscenza reciproca e anche le relazioni tra i due gruppi hannocominciato a normalizzarsi. Di conseguenza, sono state ottenute applicazioni e risul-tati finali di qualit superiore.

Fin dalla prima versione, ORACLE stato impostato sul modello relazionale difacile comprensione (spiegato tra breve); in questo modo i non esperti comprende-vano prontamente che cosa faceva ORACLE e come lo faceva. Ci lo rese di facileapproccio.

Inoltre ORACLE venne progettato per essere eseguito virtualmente nello stessomodo su qualsiasi tipo di computer. Qualunque fosse il produttore dellattrezzaturautilizzata dallutente, ORACLE funzionava. Tutte queste caratteristiche contribui-rono direttamente al grande successo del prodotto e della societ.

In un mercato popolato da societ che producevano hardware proprietario, si-stemi operativi proprietari, database proprietari e applicazioni proprietarie,ORACLE consentiva agli utenti che lo utilizzavano per lavoro e ai settori di svilup-po dei sistemi un nuovo controllo sulle loro vite e sul loro futuro, senza legami conil database di un unico venditore di hardware. ORACLE poteva essere eseguito suqualsiasi tipo di computer posseduto dallazienda. Si tratta di una rivoluzione fon-damentale per il mondo del lavoro e per lo sviluppo di applicazioni, con conseguen-ze che si proietteranno molto lontano nel futuro.

Alcuni individui non lo hanno ancora accettato o compreso, n hanno capitolimportanza vitale del fatto che le vecchie e artificiali barriere tra utenti e siste-mi continuino a crollare, ma lavvento dello sviluppo cooperativo avr influenzaprofonda sulle applicazioni e sulla loro utilit.

Tuttavia, molti sviluppatori di applicazioni sono caduti in una trappola: prosegui-re con metodi inutili ereditati dalla progettazione di sistemi della generazione pre-cedente. C molto da disimparare. Molte delle tecniche (e dei limiti) che eranoindispensabili in precedenza non sono soltanto inutili nella progettazione conORACLE, ma del tutto controproducenti. Nellaffrontare lapprendimento diORACLE ci si deve liberare dal peso di queste abitudini e di questi approcci datati:ora sono disponibili nuove e stimolanti possibilit.

C O N D I V I D E R E C O N O S C E N Z E E S U C C E S S O 5

Lintento fondamentale di questo testo spiegare ORACLE in maniera sempli-ce e chiara, in termini comprensibili e condivisibili sia dagli utenti, sia dai tecnici.Riguardo le modalit di progettazione e gestione datate o inadeguate, verr propo-sto il modo migliore per sostituirle.

1.1 Lapproccio cooperativo

ORACLE un database relazionale a oggetti. Un database relazionale un sistemaestremamente semplice per considerare e gestire i dati utilizzati in un lavoro. Non niente di pi di un insieme di tabelle di dati. Le tabelle sono molto presenti nellavita quotidiana: condizioni climatiche, grafici sullandamento della borsa, risultati diavvenimenti sportivi sono tutte tabelle, dotate di intestazioni di colonna e righe conle informazioni presentate in maniera semplice. Lapproccio relazionale pu esseresofisticato e sufficientemente espressivo anche per il lavoro pi complesso. Un data-base relazionale a oggetti presenta tutte le caratteristiche di un database relaziona-le, ma consente anche di sviluppare concetti e funzioni orientati agli oggetti.

Purtroppo, proprio le persone che possono trarre pi utilit da un database rela-zionale, ovvero gli utenti che se ne servono per lavoro, in genere ne sanno di meno.Gli sviluppatori di applicazioni, che costruiscono i sistemi che questi utenti utilizza-no nella loro attivit, spesso pensano che i concetti che stanno alla base del softwarerelazionale siano troppo difficili per poter essere spiegati in termini semplici. ne-cessario un linguaggio comune perch lapproccio cooperativo funzioni.

Nelle prime due parti di questo testo viene illustrato, con termini di comprensi-bilit immediata, che cos esattamente un database relazionale e come utilizzarloefficacemente nella propria attivit. Potrebbe sembrare che questa trattazione siaesclusivamente a beneficio degli utenti e un tecnico esperto di applicazioni rela-zionali potrebbe avere la tendenza a saltare questi primi capitoli per utilizzare il li-bro semplicemente come testo elementare di consultazione su ORACLE. Meglioresistere a questa tentazione! Anche se molto del materiale pu apparire come unapanoramica di base, per i progettisti di applicazioni si tratta di unopportunit peracquisire un terminologia chiara, coerente e gestibile di cui servirsi per conversarecon gli utenti riguardo alle loro esigenze e alle modalit per soddisfarle velocemen-te. Per i lettori di questo tipo, questa trattazione pu anche essere utile per abban-donare alcune abitudini inutili e probabilmente inconsce tipiche dei tecnici. Moltedi queste vengono svelate durante la presentazione dellapproccio relazionale. im-portante comprendere che persino il potenziale di ORACLE pu essere limitatoconsiderevolmente da metodi di progettazione adatti soltanto allo sviluppo di sof-tware non relazionale.

Per gli utenti finali, comprendere i concetti fondamentali dei database relaziona-li a oggetti consente di esprimere meglio le proprie esigenze agli sviluppatori di ap-plicazioni e di capire come possano essere soddisfatte. Mediamente un operatorepu passare da principiante a esperto in breve tempo. Con ORACLE, si ottiene lacapacit di raccogliere e utilizzare informazioni, di avere il controllo immediato deireport e dei dati e una visione chiara di come funziona lapplicazione.

6 C A P I T O L O 1

Lutente di ORACLE pu gestire unapplicazione o una query in maniera avan-zata e sapere se non sta utilizzando tutta la flessibilit e il potenziale disponibile.

Lutente finale ha anche la possibilit di liberare i programmatori dal loro com-pito meno gradevole: compilare nuovi report. Nelle grandi aziende, ben il 95 percento di tutto il cumulo di lavoro arretrato composto da richieste di nuovi report.Poich lutente in grado di compilarli autonomamente, in termini di minuti e nondi mesi, sar gratificante averne la responsabilit.

1.2 Tutti hanno dei dati

In una biblioteca vengono conservati elenchi di iscritti, libri e registrazioni di presti-ti. Il proprietario di una collezione di figurine di calcio registra nomi, date, mediedei giocatori e valore delle figurine. In qualsiasi attivit devono essere conservatealcune informazioni specifiche su clienti, prodotti, prezzi. Tutte queste informazionisono definite dati.

I filosofi dellinformazione amano dire che i dati rimangono semplici dati finchnon vengono organizzati in maniera significativa, diventando solo a quel punto in-formazioni. Se questa tesi corretta, ORACLE anche un mezzo per trasformarefacilmente i dati in informazioni. Con ORACLE vengono selezionati e manipolati idati per rivelare le conoscenze che nascondono, come totali, tendenze di mercato oaltre relazioni, che fino a quel momento non sono palesi. I lettori imparerannocome fare queste scoperte. Il concetto fondamentale in questo contesto rappresen-tato dai dati e dalle tre operazioni che possono essere effettuate con essi: acquisirli,memorizzarli e richiamarli.

Una volta chiarite le nozioni di base, si pu procedere effettuando conteggi, spo-stando i dati da una collocazione allaltra e modificandoli. Ci viene definito comeelaborazione e, fondamentalmente, coinvolge le tre fasi con cui vengono organizzatele informazioni.

Tutte queste operazioni potrebbero essere effettuate con una scatola di sigari,carta e matita, ma con laumentare del volume dei dati, tendenzialmente cambianoanche gli strumenti. Si possono utilizzare un archivio, calcolatori, matite e carta. Aun certo punto diventa sensato passare ai computer, anche se i compiti da eseguirerimangono gli stessi.

Un sistema di gestione di database relazionale (o RDBMS) come ORACLEconsente di eseguire questi compiti in maniera comprensibile e ragionevolmentesemplice. In pratica con ORACLE possibile eseguire tre compiti:

inserire dati;

mantenere i dati in memoria;

reperire i dati e gestirli.

Nella Figura 1.1 viene illustrata questa semplicit dazione.ORACLE supporta questo approccio in tre fasi e fornisce strumenti intelligenti

che consentono un notevole livello qualitativo nelle modalit con cui i dati vengono

C O N D I V I D E R E C O N O S C E N Z E E S U C C E S S O 7

reperiti, visualizzati, modificati e inseriti, mantenuti al sicuro ed estrapolati per ma-nipolarli e costruire report sulla base delle informazioni che contengono.

In un sistema di gestione di database relazionale a oggetti (ORDBMS) vengonoestese le possibilit di un RDBMS per supportare concetti orientati agli oggetti.ORACLE pu essere utilizzato come un RDBMS per trarre vantaggio delle sue ca-ratteristiche orientate agli oggetti.

1.3 Il linguaggio familiare di ORACLE

Le informazioni memorizzate in ORACLE vengono gestite in forma di tabelle ana-loghe a quelle delle previsioni meteorologiche dei quotidiani, come lesempio illu-strato nella Figura 1.2.

In questa tabella sono presenti quattro colonne verticali: Citta, Temperatura,Umidita e Condizione. C anche una riga orizzontale per ogni citt da Atene a Sid-ney. Infine, la tabella ha un nome: CLIMA.

Si tratta delle tre caratteristiche principali della maggior parte delle tabellestampate: colonne, righe e nome. Lo stesso accade per un database relazionale. I ter-mini e i concetti rappresentati sono comprensibili da tutti, perch le parole utilizza-te per descrivere i componenti di una tabella in un database di ORACLE sono lestesse utilizzate nelle conversazioni quotidiane. Non si tratta di termini dal significa-to particolare, insolito o esoterico: significano esattamente ci che sembrano.

Input Output

Archivio

Figura 1.1 Gestione dei dati in ORACLE.

8 C A P I T O L O 1

Tabelle di informazioni

Le informazioni in ORACLE sono memorizzate sotto forma di tabelle, come mo-strato nella Figura 1.3. In ciascuna di queste tabelle sono presenti una o pi colonne.Le intestazioni come Citta, Temperatura, Umidita e Condizione sono utilizzate perdescrivere il tipo di informazione contenuta nella colonna. Le informazioni vengonomemorizzate riga dopo riga, citt dopo citt. Ogni singolo insieme di dati, come latemperatura, lumidit e la condizione per la citt di Manchester, occupa la sua co-lonna specifica.

Con ORACLE viene evitata la terminologia specializzata, accademica, al fine direndere il prodotto di pi facile approccio. Nei documenti di ricerca sulla teoria re-lazionale, unintestazione di colonna pu essere definita attributo, una riga tu-pla e una tabella pu essere definita come entit. Per lutente finale, tuttavia,questi termini possono generare confusione. Inoltre, si tratta di una ridenominazio-ne non necessaria di elementi per i quali esistono gi termini generalmente compre-si nel linguaggio quotidiano. Con ORACLE si utilizza questo linguaggio quotidianoe anche i tecnici possono adeguarsi. indispensabile prendere coscienza del murodi sfiducia e incomprensione che viene prodotto dallutilizzo di gergo tecnico nonnecessario. Come ORACLE, anche questo testo si basa su tabelle, colonne erighe.

SQL

ORACLE stata la prima azienda a presentare un prodotto che utilizzava il lin-guaggio di interrogazione strutturato SQL (Structured Query Language), basato sul-la lingua inglese. Ci consent agli utenti finali di estrarre le informazioni in modoautonomo, senza rivolgersi ai sistemisti per ogni piccolo report.

Il linguaggio di interrogazione di ORACLE non privo di struttura, come non losono la lingua inglese o qualsiasi altra. Ci sono regole grammaticali e sintattiche, masono fondamentalmente le stesse di un discorso corretto e risultano quindi di imme-diata comprensione.

CLIMACitta Temperatura Umidita CondizioneATENE........ 36 89 SOLECHICAGO...... 19 88 PIOGGIALIMA......... 7 79 PIOGGIAMANCHESTER... 19 98 NEBBIAPARIGI....... 27 62 NUVOLOSOSPARTA....... 23 63 NUVOLOSOSYDNEY....... -5 12 NEVE

Figura 1.2 Una tabella di dati meteorologici tratta da un giornale.

C O N D I V I D E R E C O N O S C E N Z E E S U C C E S S O 9

Come verr illustrato tra breve, SQL uno strumento sorprendentemente po-tente, il cui utilizzo non richiede nessuna esperienza di programmazione. Ecco unesempio di possibile impiego: se qualcuno chiede di selezionare dalla tabella dellecondizioni climatiche la citt con umidit pari a 89, si pu facilmente rispondereAtene. Se venisse chiesto di selezionare le citt con temperatura pari a 19 gradi,la risposta sarebbe Chicago e Manchester.

Anche ORACLE in grado di rispondere alle stesse domande, quasi con lastessa facilit con cui lo fa un operatore e con una query semplice, molto simile alledomande poste pocanzi. Le parole chiave utilizzate in una query per ORACLEsono select, from, where e order by. Si tratta di spunti che consentono a ORACLE dicomprendere la domanda e presentare la risposta corretta.

Una semplice query di ORACLE

In ORACLE, con una tabella CLIMA, la prima query che si potrebbe impostare sa-rebbe semplicemente:

select Citta from CLIMA where Umidita = 89

La risposta sarebbe:

Citta----------Atene

La seconda query potrebbe essere:

select Citta from CLIMA where temperatura = 19

La risposta a questa query sarebbe:

Citta----------ManchesterChicago

CLIMACitta Temperatura Umidita Condizione---------- ----------- ------- ----------ATENE 36 89 SOLECHICAGO 19 88 PIOGGIALIMA 7 79 PIOGGIAMANCHESTER 19 98 NEBBIAPARIGI 27 62 NUVOLOSOSPARTA 23 63 NUVOLOSOSYDNEY -5 12 NEVE

Figura 1.3 Una tabella di dati meteorologici in ORACLE.

Nome tabella

Colonna

Riga

10 C A P I T O L O 1

E order by? Si supponga di voler visualizzare tutte le citt in ordine di temperatu-ra. Occorrerebbe semplicemente digitare:

select Citta, Temperatura from CLIMA order by Temperatura

In ORACLE appare immediatamente la risposta:

Citta Temperatura----------- -----------SYDNEY -5LIMA 7MANCHESTER 19CHICAGO 19SPARTA 23PARIGI 27ATENE 36

ORACLE ha rapidamente riordinato la tabella per temperatura (in questa ta-bella sono elencate per prime le temperature pi basse; in seguito viene spiegatocome specificare lordinamento).

Con gli strumenti di query di ORACLE si possono impostare molte altre do-mande, tuttavia gli esempi riportati dimostrano quanto sia facile ricavare informa-zioni da un database di ORACLE nella forma pi corrispondente alle esigenzedellutente. Si possono costruire richieste complesse partendo da elementi semplici,ma il metodo utilizzato rimane sempre facilmente comprensibile. Ad esempio, sipossono combinare i parametri where e order by, entrambi elementi semplici, perchiedere al programma di selezionare le citt in cui la temperatura superiore a 26gradi e di visualizzarle in ordine di temperatura crescente. In questo caso occorredigitare:

select Citta, Temperatura from CLIMA where Temperatura > 26 (> significa maggiore di) order by Temperatura

e la risposta immediata sarebbe:

Citta Temperatura----------- -----------PARIGI 27ATENE 36

Oppure, si pu impostare una richiesta ancora pi specifica, chiedendo qualisono le citt in cui la temperatura superiore a 26 gradi e lumidit inferiore a 70:

select Citta, Temperatura, Umidita from CLIMA where Temperatura > 26 and Umidita < 70 (< significa minore di) order by Temperatura

la risposta sarebbe:

Citta Temperatura Umidita----------- ----------- -------PARIGI 27 62

C O N D I V I D E R E C O N O S C E N Z E E S U C C E S S O 11

Che cosa significa relazionale

Si osservi che nella tabella CLIMA sono elencate citt di vari paesi e che per alcunipaesi sono presenti diverse citt. Si supponga di voler conoscere in quale paese collocata una data citt. Si potrebbe creare una tabella LOCAZIONE separata perle citt e i rispettivi paesi, come illustrato nella Figura 1.4.

Per ciascuna citt nella tabella CLIMA possibile semplicemente dare unoc-chiata alla tabella LOCAZIONE, trovare il nome nella colonna Citta, scorrere lacolonna Paese nella stessa riga e verificare il nome del paese.

Si tratta di due tabelle completamente separate e indipendenti; ciascuna contie-ne determinate informazioni suddivise in colonne e righe e hanno un elemento si-gnificativo in comune: la colonna Citta. A ogni nome di citt nella tabella CLIMAcorrisponde un nome identico nella tabella LOCAZIONE.

CLIMA

Citta Temperatura Umidita Condizione----------- ----------- ------- ----------ATENE 36 89 SOLECHICAGO 19 88 PIOGGIALIMA 7 79 PIOGGIAMANCHESTER 19 98 NEBBIAPARIGI 27 62 NUVOLOSOSPARTA 23 63 NUVOLOSOSYDNEY -5 12 NEVE

LOCAZIONE

Citta Paese ---------- ----- ATENE GRECIA CHICAGO STATI UNITI CONAKRY GUINEA LIMA PERU MADRAS INDIA MADRID SPAGNA MANCHESTER INGHILTERRA MOSCA RUSSIA PARIGI FRANCIA ROMA ITALIA SHENYANG CINA SPARTA GRECIA SYDNEY AUSTRALIA TOKIO GIAPPONE

Figura 1.4 Le tabelle CLIMA e LOCAZIONE.

12 C A P I T O L O 1

Ad esempio, si supponga di voler conoscere la temperatura, lumidit e le condi-zioni climatiche di una citt australiana. sufficiente osservare le due tabelle pergiungere alla risposta.

Come si risolve questo quesito? presente una sola voce AUSTRALIA, nellacolonna Paese, nella tabella LOCAZIONE. Vicino a questa, nella colonna Citta del-la stessa riga visualizzato il nome della citt, SYDNEY. Si cerca questo nome nellacolonna Citta della tabella CLIMA e, una volta individuato, ci si sposta lungo la rigaper trovare i valori di Temperatura, Umidita e Condizione: -5, 12 e NEVE.

Anche se le tabelle sono indipendenti, si pu facilmente constatare che risultanocorrelate: in nome di citt in una tabella correlato a un nome di citt nellaltra. Iltermine database relazionale riferito a questo tipo di relazione. Si veda la Figura1.5. Questa la nozione fondamentale di database relazionale (talvolta definito mo-dello relazionale). I dati vengono organizzati in tabelle, composte da colonne, righee nomi. Le tabelle possono essere correlate tra di loro se hanno una colonna con untipo di informazione comune.

CLIMA

Citta Temperatura Umidita Condizione----------- ----------- ------- ----------ATENE 36 89 SOLECHICAGO 19 88 PIOGGIALIMA 7 79 PIOGGIAMANCHESTER 19 98 NEBBIAPARIGI 27 62 NUVOLOSOSPARTA 23 63 NUVOLOSOSYDNEY -5 12 NEVE

LOCAZIONE

Citta Paese---------- -----ATENE GRECIACHICAGO STATI UNITICONAKRY GUINEALIMA PERUMADRAS INDIAMADRID SPAGNAMANCHESTER INGHILTERRAMOSCA RUSSIAPARIGI FRANCIAROMA ITALIASHENYANG CINASPARTA GRECIASYDNEY AUSTRALIA

Figura 1.5 La relazione tra le tabelle CLIMA e LOCAZIONE.

Relazione

C O N D I V I D E R E C O N O S C E N Z E E S U C C E S S O 13

1.4 Alcuni esempi comuni

Una volta compreso il concetto fondamentale di database relazionale, si vedono ta-belle, righe e colonne ovunque. Naturalmente tabelle, righe e colonne erano presen-ti anche prima, ma cambia il modo di considerarle. Molte delle tabelle che siosservano pi comunemente potrebbero essere inserite in ORACLE, cos da poter-le utilizzare per rispondere velocemente a domande per le quali sarebbe necessariomolto tempo in qualsiasi altro modo.

Nella Figura 1.6 rappresentata una tipica tabella sullandamento della borsa. Sitratta di una piccola parte di un elenco alfabetico molto denso che comprende mol-te colonne ravvicinate distribuite su diverse pagine in un giornale. Per quale azienda stato scambiato il pi alto numero di azioni? Quale ha avuto la variazione percen-tuale pi elevata, in positivo o in negativo? Per ottenere queste risposte conORACLE sufficiente impostare delle semplici query; i tempi di risposta sono mol-to pi rapidi di quelli impiegati dovendo scorrere le colonne sulla pagina di un gior-nale. Nella Figura 1.7 sono riportati i risultati di alcune squadre di hockey. Qual laclassifica di tutte le squadre? Quali squadre hanno giocato pi partite? Ottenere lerisposte a queste domande con ORACLE facile: basta impostare delle sempliciquery.

Chiusura Chiusura AzioniAzienda ieri oggi scambiateAd Specialty 31.75 31.75 18,333,876Apple Cannery 33.75 36.50 25,787,229AT Space 46.75 48.00 11,398,323August Enterprises 15.00 15.00 12,221,711Brandon Ellipsis 32.75 33.50 25,789,769General Entropy 64.25 66.00 7,598,562Geneva Rocketry 22.75 27.25 22,533,944Hayward Antiseptic 104.25 106.00 3,358,561IDK 95.00 95.25 9,443,523India Cosmetics 30.75 30.75 8,134,878Isaiah James Storage 13.25 13.75 22,112,171KDK Airlines 80.00 85.25 7,481,566Kentgen Biophysics 18.25 19.50 6,636,863LaVay Cosmetics 21.50 22.00 3,341,542Local Development 26.75 27.25 2,596,934Maxtide 8.25 8.00 2,836,893MBK Communications 43.25 41.00 10,022,980Memory Graphics 15.50 14.25 4,557,992Micro Token 77.00 76.50 25,205,667Nancy Lee Features 13.50 14.25 14,222,692Northern Boreal 26.75 28.00 1,348,323Ockham Systems 21.50 22.00 7,052,990Oscar Coal Drayage 87.00 88.50 25,798,992Robert James Apparel 23.25 24.00 19,032,481Soup Sensations 16.25 16.75 22,574,879Wonder Labs 5.00 5.00 2,553,712

Figura 1.6 Una tabella di dati del mercato azionario.

14 C A P I T O L O 1

RISULTATI COMPLESSIVISquadra Vinte Perse PariBoston.................. 17 13 3Buffalo................. 21 9 4Calgary................. 14 11 9Chicago................. 19 13 2Detroit................. 10 18 5Edmonton................ 16 11 7Hartford................ 16 17 1Los Angeles............. 16 14 3Minnesota............... 17 15 2Montreal................ 20 13 4New Jersey.............. 15 15 3N.Y. Rangers............ 15 14 5N.Y. Islanders.......... 11 20 4Philadelphia............ 16 14 4Pittsburgh.............. 13 16 3Quebec.................. 6 23 4St Louis................ 14 12 6Toronto................. 16 18 0Vancouver............... 11 16 6Washington.............. 13 15 4Winnipeg................ 14 13 5

Argomento Sezione PaginaNascite F 7Bridge B 2Economia E 1Annunci F 8Fumetti C 4Salute F 6Editoriali A 12Vita moderna B 1Film B 4Notizie A 1Necrologi F 6Sport D 1Televisione B 7Meteo C 2

Figura 1.7 Una tabella di risultati di hockey.

Nella Figura 1.8 riprodotto un indice di giornale. Che cosa si trova nella sezio-ne F? Se si leggesse il giornale dallinizio alla fine, in che ordine apparirebbero gliarticoli? Anche in questo caso, per ottenere le risposte a queste domande conORACLE sufficiente impostare delle semplici query. In questo libro viene illu-strato come impostare tutte queste query e anche come costruire le tabelle in cuiconservare le informazioni.

Figura 1.8 Una tabella basata sulle sezioni di un giornale.

C O N D I V I D E R E C O N O S C E N Z E E S U C C E S S O 15

1.5 Un esempio vecchio di 100 anni

Un antico e deteriorato libro mastro, che porta la data iniziale del 1896, appartenutoa un tale G. B. Talbot, contiene le voci riportate nella Figura 1.9.

Le informazioni proseguono per diverse pagine, giorno dopo giorno, fino al 1905.Dora Talbot pagava i lavoratori un dollaro al giorno e George B. Talbot (presumibil-mente suo figlio) teneva le registrazioni. Alcuni lavoratori compaiono molte volte,altri soltanto una volta o due.

Figura 1.9 Il libro mastro di G.B. Talbot.

16 C A P I T O L O 1

Figura 1.10 Gli indirizzi dei lavoratori nel libro mastro di G.B. Talbot.

Qualche pagina dedicata anche allelenco di nomi e indirizzi dei lavoratori,come illustrato nella Figura 1.10. La relazione che collega le due tabelle il nomedei lavoratori. Se alla fine del mese George avesse voluto mandare un incaricato adistribuire le buste paga a ogni lavoratore, che cosa avrebbe dovuto fare? Innanzi-tutto avrebbe dovuto sommare le cifre spettanti per ciascun lavoratore, mettere ildenaro calcolato in ciascuna busta e scrivere il nome del lavoratore sulla stessa.Quindi avrebbe dovuto cercare ciascun indirizzo nella seconda parte del registro,scriverlo sulle buste e mandare lincaricato a consegnarle.

G. B. Talbot possedeva un vero database relazionale, anche se utilizzava carta einchiostro per raccogliere le informazioni, piuttosto che ununit a disco di un com-puter. Anche se le tabelle sono poste in relazione grazie alle dita, agli occhi e allamente di un uomo invece che con laiuto di una CPU, si tratta effettivamente di undatabase relazionale vero e proprio. anche abbastanza assimilabile a quello cheun progettista di applicazioni relazionali definirebbe normalizzato, termine che si-gnifica semplicemente che i dati sono raccolti in gruppi naturali: paga giornaliera eindirizzi non sono mescolati in ununica sezione del registro.

Le voci di questo libro mastro, sia quelle riportanti le somme sia quelle degli in-dirizzi, potrebbero facilmente essere impostate come tabelle di ORACLE. Le do-mande o i compiti che G. B. Talbot doveva affrontare avrebbero potuto esseredecisamente semplificati e nelle pagine seguenti viene spiegato come, utilizzando siaesempi moderni, sia le voci del vecchio registro di Talbot per scoprire le potenzialitdi ORACLE.

Capitolo 2

I pericoli di un databaserelazionale

2.1 davvero facile come sembra?

2.2 Quali sono i rischi?

2.3 Limportanza della nuova visione

2.4 Codici, abbreviazioni e standarddi denominazione

2.5 Perch vengono utilizzati i codicie non la lingua corrente?

2.6 Come arginare la confusione

2.7 Maiuscole e minuscole nei nomi e nei dati

2.8 Normalizzazione dei nomi

2.9 Cogliere lopportunit

Come accade per qualsiasi nuova tecnologia o per unnuovo avvenimento dallincerto profilo, importante considerare attentamente nonsolo i benefici e le opportunit che si presentano, ma anche i costi e i rischi. In unatecnologia relativamente nuova come quella dei database relazionali, non passatoabbastanza tempo per consentire alla maggior parte delle aziende di avere sufficien-te esperienza su che cosa evitare e come.

Se si aggiunge un database relazionale con una serie di strumenti potenti e facilida utilizzare, come ORACLE, la possibilit di essere guidati verso il disastro pro-prio a causa di questa semplicit diventa reale. Se si utilizzano anche funzioni orien-tate agli oggetti, il pericolo aumenta.

In questo capitolo vengono discussi alcuni dei pericoli che progettisti e utentidovrebbero considerare. Nella Parte quarta vengono trattati questi e altri argomenticon maggiore dettaglio, in particolare quelli che interessano i progettisti nel lorocompito di sviluppo di unapplicazione efficace e produttiva.

2.1 davvero facile come sembra?

Secondo i fornitori di database, sviluppare unapplicazione utilizzando un databaserelazionale e gli strumenti correlati di quarta generazione sar addirittura 20 vol-te pi rapido che utilizzare la progettazione di sistema tradizionale.

18 C A P I T O L O 2

molto facile: in ultima analisi, i programmatori e gli analisti di sistema non ri-sulteranno pi indispensabili poich gli utenti finali controlleranno appieno i lorodestini.

I critici dellapproccio relazionale tuttavia, ritengono che i sistemi relazionali sia-no per natura pi lenti degli altri, che gli utenti a cui viene dato il controllo sulla for-mulazione di query e report avranno la meglio sui computer e che le societperderanno il loro ruolo, anche economicamente, se non si adotter un approcciopi tradizionale. La stampa riporta resoconti su applicazioni di grande portata chenon hanno funzionato una volta messe in produzione.

Qual allora la verit? Che le regole del gioco sono cambiate. Lo sviluppo rela-zionale di quarta generazione presuppone richieste molto diverse nei confronti del-le societ e della gestione rispetto ai modelli di sviluppo tradizionale. Si tratta diesigenze e di rischi totalmente nuovi e niente affatto ovvi; una volta identificati ecompresi, il pericolo non superiore, ma anzi, probabilmente molto inferiore, ri-spetto allo sviluppo tradizionale.

2.2 Quali sono i rischi?

Il rischio principale rappresentato dal fatto che tutto davvero facile come sem-bra. Comprendere le tabelle, le colonne e le righe non difficile. La relazione tradue tabelle risulta concettualmente semplice. Anche la normalizzazione, il processodi analisi delle relazioni naturali o normali tra i vari elementi dei dati di una so-ciet, piuttosto semplice da apprendere.

Purtroppo, questa semplicit spesso produce esperti pieni di sicurezza e inge-nuit ma con poca esperienza nella creazione di applicazioni reali ed efficaci. Nelcaso di un piccolo database di marketing, o di unapplicazione per linventario dicasa, ci non ha molta importanza; gli errori commessi si rivelano con il tempo, le le-zioni vengono imparate e la volta successiva vengono evitati. In unapplicazione im-portante, tuttavia, questa la formula sicura per ottenere un disastro. Spesso proprio la mancanza di esperienza ci che sta dietro ai racconti riportati sulla stam-pa riguardo a fallimenti di grandi progetti.

I metodi di sviluppo pi vecchi sono generalmente pi lenti. Vengono imposticontrolli di progetto per assicurare una revisione generale e la qualit del prodotto,ma fondamentalmente i compiti dei metodi pi vecchi, codifica, compilazione,linking e collaudo, vengono effettuati con un ritmo pi lento. Il ciclo, soprattutto perun mainframe, spesso cos tedioso che i programmatori impiegano molto tempo acontrollare a tavolino il prodotto onde evitare il rallentamento prodotto da un al-tro ciclo completo nel caso si presenti un errore nel codice.

Gli strumenti di quarta generazione spingono i progettisti ad accelerare il pro-cesso produttivo. I cambiamenti possono essere apportati e implementati cos velo-cemente che rimane poco spazio per le verifiche. Leliminazione di tutti i controlli atavolino complica ulteriormente il problema.

Quando lincentivo negativo (il ciclo completo) che aveva promosso la prassi deicontrolli a tavolino scompare, scompaiono anche i controlli a tavolino. Linclinazio-ne di molte persone sembra essere quella per cui, se lapplicazione non perfetta,

I P E R I C O L I D I U N D A T A B A S E R E L A Z I O N A L E 19

possibile rimediare velocemente; se si verificano problemi con i dati, si possono ri-solvere con un veloce aggiornamento; se il prodotto non abbastanza veloce, si puaggiustare mentre si utilizza: limportante portarlo a compimento prima della sca-denza fissata e dimostrare di che cosa si capaci.

Questo problema viene peggiorato da un interessante fenomeno sociologico:molti degli sviluppatori di applicazioni relazionali sono neolaureati. Hanno impara-to la teoria e la progettazione relazionale od orientata agli oggetti a scuola e sonopronti a lasciare la loro impronta. Gli sviluppatori pi esperti, invece, non hanno im-parato la nuova tecnologia: sono occupati a supportare e migliorare le tecnologieche conoscono, che stanno alla base dei sistemi informativi correnti delle loro azien-de. Il risultato che gli sviluppatori inesperti tendono a porre laccento sui progettirelazionali, sono talvolta meno inclini a effettuare verifiche e sono meno sensibilialle conseguenze di un fallimento rispetto a coloro che hanno gi sperimentato varicicli completi di sviluppo di applicazioni.

Il ciclo di collaudo in un progetto importante di ORACLE dovrebbe essere pilungo e pi completo rispetto a quello di un progetto tradizionale. Ci vero anchequando vengono impostati controlli di progetto appropriati e anche se il progetto guidato da manager esperti, poich ci sono meno procedure di verifica a tavolino euna sopravvalutazione innata. Con questi collaudi deve essere controllata la corret-tezza delle schermate e dei report, del caricamento e dellaggiornamento, dellinte-grit e della coerenza dei dati e soprattutto dei volumi delle transazioni e dellamemorizzazione durante i periodi di massimo carico.

Proprio perch davvero facile come sembra, lo sviluppo di applicazioni con glistrumenti di ORACLE pu essere sorprendentemente rapido. Tuttavia, si riduce au-tomaticamente la quantit di collaudi svolti come normale procedura dello sviluppo,e collaudi e certificazioni di qualit pianificati devono essere volontariamente allun-gati per compensare questa mancanza. Ci non sempre previsto dai progettistipoco esperti di ORACLE o degli strumenti di quarta generazione, tuttavia oppor-tuno tenerne conto nella pianificazione del progetto.

2.3 Limportanza della nuova visione

Molte persone attendono con ansia il giorno in cui si potr dire semplicemente,come il Capitano Kirk Computer...; esporre domande in linguaggio corrente e ot-tenere la risposta, visualizzata sullo schermo del computer, in pochi secondi.

Siamo molto pi vicini a questi obiettivi di quanto pensi la maggior parte dellepersone. Il fattore limitativo non pi la tecnologia, ma la rigidit del pensiero nellaprogettazione di applicazioni. Con ORACLE possibile concepire facilmente siste-mi basati sulla lingua naturale che siano di comprensione e utilizzo immediato pergli utenti non esperti. Il potenziale questo, gi disponibile con il database e glistrumenti di ORACLE, ma soltanto poche persone lo hanno compreso e sono ingrado di sfruttarlo.

La chiarezza e la comprensibilit dovrebbero essere i tratti distintivi di qualsiasiapplicazione ORACLE. Si pu utilizzare la lingua corrente, gli utenti finali senzapreparazione specifica nella programmazione possono utilizzare facilmente le appli-cazioni e avere informazioni formulando una semplice query.

20 C A P I T O L O 2

E come si fa a ottenere tutto ci? Innanzitutto, uno degli obiettivi fondamentalidurante la programmazione deve essere quello di rendere lapplicazione facile dacapire e semplice da utilizzare. Anche se si sbaglia, questa la direzione da seguire,perfino se significa utilizzare pi tempo della CPU o spazio su disco. Il limite di que-sto tipo di approccio quello di creare programmi eccessivamente complessi che ri-sultino quasi impossibili da gestire e migliorare. Sarebbe un errore altrettanto grave.Tuttavia, a parit di condizioni, non dovrebbero mai essere sacrificate le esigenzedellutente finale a scapito di una programmazione troppo sofisticata.

Modificare gli ambienti

Nel 1969 il costo per tenere in attivit un computer con una velocit di elaborazionedi quattro milioni di istruzioni per secondo (MIPS) era di circa mille dollari lora.Per il 1989, il costo era sceso a 45 dollari lora e ha continuano a precipitare fino aoggi. I costi di lavorazione, daltro canto, hanno continuato a crescere, non solo acausa delle tendenze generali, ma anche perch i salari dei singoli addetti aumenta-no in proporzione al tempo trascorso nella stessa azienda e alla professionalit ac-quisita. Ci significa che qualsiasi lavoro che possa essere trasferito da operatoriumani alle macchine rappresenta un buon investimento.

Come stato applicato questo incredibile cambiamento nella progettazione diapplicazioni? Assolutamente non in maniera uniforme. Il vero progresso si verifi-cato negli ambienti, come accadde inizialmente con il lavoro visionario svolto daXerox, poi su Macintosh, ora con X-Windows, MS-Windows, Presentation Manager,New Wave, NeXT e altri sistemi di impostazione grafica, basati su icone. Questi am-bienti sono molto pi semplici da apprendere e comprendere rispetto a quelli prece-denti, basati su comandi scritti, e le persone che li utilizzano riescono a produrre inpochi minuti ci che prima richiedeva diversi giorni di lavoro. I progressi in alcunicasi sono stati cos rilevanti da far dimenticare quanto determinati compiti risultas-sero complessi in passato.

Purtroppo, questo concetto di ambiente semplice e agevole non stato afferratoda molti sviluppatori di applicazioni, che pur lavorando su questi ambienti, non ab-bandonano le vecchie abitudini ormai inadeguate.

2.4 Codici, abbreviazioni e standarddi denominazione

Questo problema si verifica soprattutto per i codici, le abbreviazioni e gli standarddi denominazione, che vengono completamente ignorati quando sono considerate leesigenze degli utenti finali. Quando questi argomenti vengono toccati, in generevengono esaminate soltanto le esigenze e le convenzioni dei gruppi di sistemi. Po-trebbe sembrare una questione sterile e poco interessante, tuttavia pu fare la diffe-renza tra un grande successo e un risultato a mala pena accettabile, tra un salto diproduttivit di prima grandezza e un guadagno marginale, tra utenti interessati edefficienti e utenti frettolosi che richiedono continuamente lausilio dei progettisti.

I P E R I C O L I D I U N D A T A B A S E R E L A Z I O N A L E 21

Una volta le registrazioni economiche venivano effettuate su libri mastri e gior-nali. Ciascun evento e transazione veniva trascritto, riga dopo riga, utilizzando lalingua corrente. Si osservi il registro di Talbot, nella Figura 2.1: ci sono forse dei co-dici? Assolutamente no. Delle abbreviazioni? S, qualcuna di uso comune, immedia-tamente comprensibile da qualsiasi lettore di lingua inglese. Quando Talbotvendette una corda di legna il 28 gennaio, annot: Jan 28 (1 Crd) Wood MethestChurch 2.00.

In molte applicazioni odierne, la stessa transazione sarebbe rappresentata neifile di un computer da un numero come 028 04 1 4 60227 3137; la data secondo ilcalendario giuliano per indicare il ventottesimo giorno dellanno, il codice di transa-zione 04 (una vendita) la quantit 1 del tipo di quantit 4 (una corda) dellarticolo

Figura 2.1 Una pagina del libro mastro di Talbot.

22 C A P I T O L O 2

60227 (60=legno, 22=non finito, 7=tagliato) al cliente 3137 (Chiesa Metodista). Gliaddetti allinserimento di questi dati dovrebbero in effetti conoscere o cercare lagran parte di questi codici e digitarli nel campo appropriato dello schermo. Si trattadi un esempio estremizzato, tuttavia centinaia di applicazioni operano esattamentecon questo approccio e ogni singola parte ugualmente complessa da imparare o dacapire.

Questo problema stato molto presente nello sviluppo dei grandi sistemi main-frame convenzionali. Quando si introducono i database relazionali in questi gruppi,essi vengono utilizzati semplicemente come parti sostitutive di vecchi metodi diinput/output tradizionali come VSAM e IMS. La potenzialit e le caratteristiche diun database relazionale sono virtualmente sprecate, quando vengono utilizzate inquesto modo.

2.5 Perch vengono utilizzati i codici e non la linguacorrente?

Perch utilizzare i codici? Sono due le giustificazioni che vengono generalmentepresentate:

una categoria comprende un numero di articoli cos elevato che non possono esse-re ragionevolmente rappresentati o ricordati utilizzando la lingua corrente;

per risparmiare spazio nel computer.

Il secondo punto un anacronismo, un prodotto dellepoca in cui quattro MIPScostavano 1 dollaro allora (o anche di pi). La memoria di sistema (un tempo ferri-te a forma di frittella montata su griglie metalliche) e la memoria permanente (na-stri o grossi piatti magnetici) erano talmente costose e le CPU talmente lente (conmeno potenza di una calcolatrice tascabile) che i programmatori dovevano conden-sare ogni informazione nel minor spazio possibile. I numeri, a parit di caratteri, oc-cupano la met dello spazio rispetto alle lettere, e i codici (come 3137 per Kentgen,Gerhardt) riducono ancora di pi le prestazioni richieste alla macchina.

Poich le macchine erano costose, i progettisti dovettero utilizzare codici per ot-tenere che ogni cosa funzionasse. Si trattava di una soluzione tecnica a un problemaeconomico. Per gli utenti, che dovettero imparare ogni genere di codici senza senso,la situazione era pressante. Le macchine erano troppo lente e troppo costose persoddisfare gli uomini, perci questi furono addestrati per adattarsi alle macchine. Fuun male necessario.

Questa giustificazione economica svan anni fa. I computer ora sono sufficiente-mente economici e veloci per adattarsi agli uomini e funzionare con il linguaggioumano con parole che gli umani comprendono. Era ora che accadesse! Eppure, sen-za porsi il problema consapevolmente, sviluppatori e progettisti continuano volentio nolenti a utilizzare i codici, come se fosse ancora il 1969.

Il primo punto, troppi articoli in ciascuna categoria, pi sostanziale, ma comun-que molto meno di quanto sembri a prima vista. Unidea proposta quella secondola quale necessario minore sforzo (e quindi meno costo) per digitare i numeri

I P E R I C O L I D I U N D A T A B A S E R E L A Z I O N A L E 23

3137 piuttosto che Kentgen, Gerhardt. Questa giustificazione non vera nelcaso di ORACLE. Non soltanto pi costoso addestrare le persone a conoscere ilcodice corretto per clienti, prodotti, transazioni e altro, oltre al costo degli errori(che sono molti nei sistemi basati su codici), utilizzare i codici significa anche nonutilizzare ORACLE in maniera completa; in ORACLE possibile digitare i primicaratteri di Kentgen, Gerhardt e ottenere che il resto del nome venga inserito au-tomaticamente. La stessa operazione possibile con nomi di prodotti, transazioni(una a pu diventare automaticamente acquisto e una v vendita) e cos via,per tutta lapplicazione. Tutto ci avviene grazie a sofisticate caratteristiche, virtual-mente inesplorate, di ricerca dellelemento appropriato.

Il vantaggio del riscontro dellutente

C anche un altro vantaggio: gli errori durante linserimento dei dati si riduconoquasi a zero, poich gli utenti hanno un riscontro immediato, in lingua corrente, del-le informazioni che vengono inserite. I caratteri digitati non vengono trasposti; i co-dici non vengono ricordati in maniera errata e nelle applicazioni di caratterefinanziario accade raramente che si perda del denaro in conti sospesi a causa di er-rori di digitazione, con un risparmio davvero significativo.

Anche le applicazioni diventano molto pi comprensibili. Le schermate e i re-port vengono trasformati da arcane serie di numeri e codici a un formato leggibile ecomprensibile. Il cambiamento della progettazione di applicazioni da un orienta-mento che punta sui codici allutilizzo della lingua naturale ha un effetto profondo erafforzativo sullazienda e i suoi impiegati. Per gli utenti che sono stati sommersi damanuali sui codici, lavorare con unapplicazione basata sulla lingua comune produ-ce un effetto altamente rilassante.

2.6 Come arginare la confusione

Unaltra versione della giustificazione troppi articoli per categoria quella secon-do cui il numero di prodotti, clienti o di tipi di transazione troppo elevato per riu-scire a differenziare ciascun elemento con una denominazione, oppure ci sonotroppi articoli allinterno di una categoria che si presentano come identici o moltosimili (clienti che si chiamano Mario Rossi, ad esempio).

Una categoria pu contenere troppe voci tali da rendere difficile lindividuazio-ne delle opzioni o la differenziazione, ma pi spesso questo il risultato di un lavo-ro incompleto di categorizzazione delle informazioni: troppe cose dissimili sonoraccolte in una categoria troppo ampia.

Per sviluppare unapplicazione con un forte orientamento alluso della linguaitaliana (o inglese, francese, tedesca e cos via), rispetto allutilizzo di codici, neces-sario avere tempo da impiegare con utenti e progettisti separando le informazionidal lavoro, comprendendone le relazioni e le categorie naturali, e quindi creandocon attenzione un database e uno schema di denominazione che rifletta in manierasemplice e accurata queste scoperte.

24 C A P I T O L O 2

Le fasi fondamentali di questo processo sono tre:

1. normalizzare i dati;

2. selezionare le denominazioni per le tabelle e le colonne;

3. selezionare le denominazioni per i dati.

Ciascuno di questi punti viene descritto seguendo lordine indicato. Lo scopo quello di sviluppare unapplicazione in cui i dati siano organizzati in tabelle e colon-ne con nomi familiari agli utenti e in cui i dati stessi siano denominati con terminifamiliari, non con codici.

Normalizzazione

Le relazioni tra paesi, o tra settori di una societ, o tra utenti e progettisti, sono soli-tamente il prodotto di particolari circostanze storiche, che possono definire le rela-zioni attuali anche se tali circostanze appartengono al passato remoto. Il risultatopu essere quello di relazioni anormali, oppure, secondo una definizione attuale, didisfunzioni. La storia e le circostanze spesso hanno lo stesso effetto sui dati (sullemodalit con cui vengono raccolti, organizzati e riportati). Anche i dati possono di-ventare anormali e presentare disfunzioni.

La normalizzazione il processo che serve per riportare le cose alla dimensionecorretta, rendendole normali. Lorigine del termine la parola latina norma, che in-dicava una squadra da carpentiere utilizzata per ottenere angoli retti. In geometria,quando una linea forma un angolo retto con unaltra, si definisce normale rispettoa questa. In un database relazionale il termine ha anche un preciso significato mate-matico, che riguarda il concetto di separazione di elementi dei dati (come nomi, in-dirizzi, o compiti) in gruppi di affinit e che definisce la relazione normale tra diessi.

I concetti di base della normalizzazione vengono presentati in questo contesto inmodo che gli utenti possano contribuire alla progettazione dellapplicazione che uti-lizzeranno, o comprendere meglio unapplicazione gi impostata. Tuttavia, sarebbeun errore pensare che questo processo sia veramente applicabile soltanto allo svi-luppo di un database o a unapplicazione per computer. I processi di normalizzazio-ne hanno per effetto una comprensione pi profonda delle informazioni utilizzatein una procedura e delle modalit di correlazione dei vari elementi che compongo-no quelle informazioni. Ci si dimostrer utile anche in aree diverse da quella deidatabase e dei computer.

Il modello logico Una delle fasi iniziali del processo di analisi la costruzionedi un modello logico, che semplicemente un diagramma normalizzato dei dati uti-lizzati nella procedura. Conoscere i motivi e le modalit per cui i dati vengono sud-divisi e separati essenziale per comprendere il modello, e questultimo essenzia-le per creare unapplicazione che supporti la procedura per un lungo periodo senzadover ricorrere a elementi aggiuntivi. Questo argomento viene trattato in manierapi completa nella Parte quarta, in particolare per quanto concerne gli sviluppatori.

I P E R I C O L I D I U N D A T A B A S E R E L A Z I O N A L E 25

In genere si parla di normalizzazione in termini di forma: la prima, la seconda ela terza forma normale sono le pi comuni, laddove la terza rappresenta lo statuspi altamente normalizzato. G.B. Talbot teneva traccia delle diverse persone che la-voravano per lui. La maggior parte svolgeva un lavoro occasionale e abitava in unodei molti alloggi della citt. Talbot studi una forma semplice per raccogliere questeinformazioni, come illustrato nella Figura 2.2.

Figura 2.2 Informazioni sul lavoratore.

Seguendo tecniche pi antiche, Talbot avrebbe potuto facilmente sviluppare undatabase che si adattasse alla disposizione fondamentale di questa forma. Sembraun approccio piuttosto rigido, che segue fondamentalmente il modello a schedariocartaceo. Molte applicazioni sono state progettate nella stessa maniera. I progettistiprendono le copie dei moduli esistenti (fatture, ricevute di vendita, domande di la-voro, dati di fatto, tabulati di informazioni sui lavoratori) e creano dei sistemi sullabase del loro contenuto e della loro forma.

Se ci si pensa bene, tuttavia, ci sono alcuni problemi nascosti. Si supponga che loschema di Talbot diventi la struttura di una tabella in ORACLE. La tabella potreb-be essere denominata LAVORATORE e le colonne potrebbero essere Nome, Al-loggio, Direttore, Indirizzo, Compito1, Compito2 e Compito3. Si osservi la Figura2.3. Gli utenti di questa tabella hanno gi un problema: sui fogli di carta Talbot po-teva elencare tutti i compiti desiderati, mentre nella tabella LAVORATORE gliutenti devono limitarsi a tre compiti.

Si supponga anche che, oltre al metodo dello schedario cartaceo, Talbot digiti glistessi elementi di informazione in ORACLE per verificare la sua tabella di databa-se LAVORATORE. Ogni scheda di carta diventa una riga di informazioni. Ma checosa accade quando Peletier (il direttore del registro di Talbot) si trasferisce nelNew Hampshire e un nuovo direttore prende il suo posto? Occorre scorrere il mo-dulo di ciascun lavoratore (nello schedario cartaceo, ovvero ogni riga della tabellaLAVORATORE) e correggere tutte le volte che compare il nome di Peletier.

26 C A P I T O L O 2

E quando Rose Hill (la residenza dove vive Pearson) viene acquistata da MajorResorts International, lindirizzo cambia in Residenza Major Resorts e di nuovotutte le registrazioni dei lavoratori devono essere modificate. Che cosa far Talbotquando John Pearson aggiunger un quarto compito allelenco? E buono o me-dio fanno effettivamente parte del compito, oppure rappresentano un livello di ca-pacit che forse dovrebbe costituire una colonna a parte?

I problemi appena elencati non sono questioni legate alluso del computer o tec-niche, anche se vengono evidenziate durante la progettazione di un database. Sitratta soprattutto di questioni di base sulle modalit di organizzare in modo sensi-bile e logico le informazioni relative a un dato compito, mediante procedimenti dinormalizzazione.

Occorre riorganizzare passo dopo passo gli elementi dei dati in gruppi di affinit,eliminando le relazioni non funzionali e stabilendo relazioni normali.

Prima forma normale Nella prima fase occorre impostare i dati nella primaforma normale. Si procede spostando i dati in tabelle separate, dove vengono rag-gruppati per tipo, e si assegna a ciascuna tabella una chiave primaria (unetichetta oun identificativo specifico). In questo modo viene eliminata la ripetizione di gruppidi dati, come accade per i compiti nel modulo cartaceo di Talbot (che viene ridottocon soltanto tre compiti nella prima elaborazione della tabella LAVORATORE).

Invece di mantenere tre compiti per lavoratore, i compiti di ciascuno sono collo-cati in una tabella separata, con una riga per nome, compito e descrizione di que-stultimo. In questo modo viene eliminata la necessit di un numero variabile dicompiti nella tabella LAVORATORE (in ogni c