Capitolo 9

VIEW e INDICI

Le view e gli indici sono oggetti abbastanza diversi tra di loro; le view esistono in RAM, gli indici vengono memorizzati su disco. Malgrado questa sostanziale differenza, i due oggetti, hanno in comune il fatto di essere associati a una o più tabelle e di mostrarci i dati in un ordine o formato diverso da quello originale. Cerchiamo di capire meglio di cosa si tratta.

VIEW

Fino a questo punto del corso abbiamo utilizzato oggetti (database, tabelle e campi) che avevano la caratteristica di esistere fisicamente su disco. In questo paragrafo invece andremo a considerare qualcosa che non esiste fisicamente su disco. Questo particolare oggetto è ogni volta ricostruito in RAM, ma è come se esistesse fisicamente su disco. Infatti può essere trattato, a parte qualche piccola limitazione, come se fosse una tabella vera e propria.

Le VIEW vengono create mediante l’istruzione CREATE VIEW associandogli un nome ed una lista di attributi. I valori presenti nelle VIEW possono essere modificati o estrapolati da i comuni comandi applicabili alle tabelle. Vediamo quali sono questi comandi:

• SELECT
• INSERT
• INPUT
• UPDATE
• DELETE
• DROP

Le VIEW possono anche essere usate per creare query complesse; una volta creata la VIEW su di essa è possibile eseguire query. Le modifiche dei dati su una VIEW si ripercuotono su tutte le tabelle da cui sono state create e viceversa.
Per creare le VIEW useremo la seguente sintassi:

CREATE VIEW nomeView [(colonna1, colonna2, . . . )] AS
SELECT nomi_delle_colonne
FROM . . .
. . . ;

questo comando indica a SQL di creare una VIEW, di nome nomeView, strutturata con le colonne specificate. La select che segue serve per estrapolare i dati da una o più tabelle e inserirli nella VIEW. Vediamo un altro esempio:

CREATE VIEW pagamenti (nome, cognome, indirizzo, città, totale) AS
SELECT clienti.nome, clienti.cognome, clienti.indirizzo, clienti.città, fatture.totale
FROM clienti, fatture
WHERE clienti.id_cliente = fatture.riferimentoCliente
AND fattuare.saldata = ‘no’;

lanciando questa CREATE si genera una VIEW con i campi nome, cognome, indirizzo, città, totale in cui avremo tutti i dati dei clienti che hanno pagamenti di fatture in sospeso. I dati della select vengono ricavati dal join di due tabelle: clienti e fatture.
Una VIEW di questo tipo è particolarmente utile, basta pensare che si aggiorna in tempo reale man mano che vengono inseriti o modificati i dati nelle tabelle clienti e fatture.

Modificare i dati di una VIEW

Abbiamo già detto che le VIEW possono essere considerate come qualsiasi tabelle, quindi possiamo cancellare, modificare, ecc. usando i comandi e le sintassi già viste precedentemente per le semplici tabelle. Quando però, la VIEW è il risultato di join tra più tabelle le cose potrebbero complicarsi un po. Si consiglia di essere cauti, magari facendo varie prove, o di consultare il manuale del DBMS che si sta utilizzando.

Perché si utilizzano le VIEW

Vediamo alcune tipiche applicazioni delle VIEW

• Proteggere i dati:
  Uno dei grossi problemi dei database è la sicurezza e la riservatezza dei dati. Le viste ci aiutano ad ottenere questo scopo: si immagini di avere una certa tabella a cui non vogliamo che un certo tipo di utenza possa accedere a tutti i campi indistintamente.
  Per questo tipo di utenza creeremo una vista in cui appariranno soltanto alcuni dei campi, della tabella in questione.
• Convertire le unità di misura:
  Ad esempio se il campo IMPORTO contenente valori espressi in sterline e vogliamo visualizzarli in lire l’uso di una VIEW risulta essere particolarmente utile. Vediamo un esempio:
     CREATE VIEW fattureRegnoUnito (azienda, lire) AS
     SELECT nomeDitta, importo * 3000
     FROM fattureRegnoUnito;
• Semplificare la costruzione di query complesse:
  In alcuni casi quando si devono estrapolare dati da più tabelle, può essere conveniente per una maggiore semplicità, creare una VIEW ed a questa applicare una select. Questo tipo di uso delle VIEW può sembrare poco ortodosso, ma è sicuramente un modo veloce e relativamente semplice per venire a capo a problemi di interrogazione apparentemente insolubili con le normali sintassi che seguono la parola chiave SELEC.

Access non implementa le VIEW.

INDICI

Provate ad immaginare un biblioteca dove esistono lunghe cassettiere contenenti migliaia di schede ordinate alfabeticamente per titolo, con i dati di ogni singolo libro. Supponete che il bibliotecario in un attimo di follia le lanci tutte in aria e poi le riponga a caso nelle cassettiere. Ora per ritrovare la scheda di un qualsiasi libro dovremo sfogliare le schede una per una fino a trovare il titolo che ci interessava. Mediamente, se le schede sono 1.000.000 dovremmo sfogliare e leggere l’intestazione (titolo del libro) di 500.000 schede prima di trovare quella giusta. Ciò che è stato descritto è quello che accade quando un qualsiasi DBMS cerca un record in una tabella senza usare gli indici; infatti i record all’interno di una tabella rispettano l’ordine di inserimento e non quello alfabetico. Immaginate ora che il bibliotecario non voglia più riordinare le schede, ma comunque decida di creare un indice ordinato alfabeticamente in cui ad ogni titolo corrisponde la posizione esatta della scheda. Il bibliotecario costatando che il metodo adottato è funzionale decide di creare un altro indice ordinato alfabeticamente per gli autori, in cui per ogni autore si ha la posizione delle schede contenenti i dati dei libri scritti da quell’autore. Dunque, con il metodo degli indici, il bibliotecario effettuerà le ricerche in maniera particolarmente veloce e mirata. Questo è quello che fanno i DBMS, quando utilizzano gli indici.

In altre parole gli indici sono delle tabelle speciali associate alle tabelle dati, che vengono poi utilizzate durante le operazioni che agiscono su queste ultime.
Contrariamente a molti linguaggi gestionali mirati al trattamento dei file, SQL permette di creare più indici su una stessa tabella. Tuttavia quando si crea un indice, SQL memorizza, oltre ai dati della tabella, anche quelli dell’indice. Quindi ogni variazione alla tabella comporta una variazione agli opportuni puntatori alle righe della tabella e non è detto che ciò sia sempre conveniente. Ad esempio se una tabella cambia spesso dati, allora la presenza di molti indici rallenta il lavoro di aggiornamento. Riportiamo una lista che ci aiuta a valutare quando è opportuno usare gli indici:

• Gli indici occupano spazio su disco.
• Possiamo ottimizzare le query, tramite l’uso di indici, se queste forniscono modeste quantità di dati (non più del 23%). In caso contrario, allora gli indici non migliorano la velocità di lettura delle query.
• Gli indici di piccole tabelle non migliorano le prestazioni.
• I migliori risultati si ottengono quando le colonne su cui sono stati costruiti gli indici contengono grandi quantità di dati o tanti valori NULL.
• Gli indici rallentano le operazioni di modifica dei dati. Di questo bisogna tenerne conto quando si effettuano molti aggiornamenti. Infatti prima di un massiccio aggiornamento del database sarebbe meglio distruggere tutti gli indici e poi ricrearli.
• Se la condizione delle query riguarda un solo campo allora è opportuno usare un indice composto da quella sola colonna. Se la condizione delle query riguardano la combinazione di più campi allora è opportuno creare un indice contenente quei campi.

Vediamo la sintassi per creare un indice:

CREATE INDEX nomeIndice
ON nomeTabella (nomeColonna1, [nomeColonna2], . . . );

inutile dirlo, la sintassi del comando CREATE INDEX varia da DBMS a DBMS. Questa specifica sintassi è stata testata su Personal Oracle 8 e su Access.