SQL (Structured Query Language)

Un corso completo sul linguaggio SQL (Structured Query Language): definizioni, esempi ed esercizi

View e Indici

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) ASSELECT nomeDitta, importo * 3000FROM 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.

Autore: Art Net

Condividi questo articolo su

12 Commenti

  1. Ho imparato alcune cose buone qui. Certamente merita il bookmarking per la rivisitazione.

    Mi chiedo quanti sforzi hai impostato per creare questo tipo di fantastico sito informativo.

    Rispondi al Commento
  2. guida molto interessante grazie se ci fossero anche le istruzioni per creare la tabella sarebbe completa secondo me

    Rispondi al Commento
  3. Grazie per la guida. Semplice, interessante ed utile.
    Vorremmo segnalare due cose. Un errore ed un dubbio.
    Errore:
    SELECT DIVISIONE, AVG(STIPENDIO)
    FROM DIPENDENTI
    HAVING AVG(STIPENDIO) > 2200000;

    manca la “group by DIVISIONE” prima della HAVING.

    Di conseguenza il dubbio sul punto 6.
    HAVING non è necessario che venga posta dopo la clausola GROUP BY.
    Sicuri?

    Rispondi al Commento
  4. Guida Molto utile, segnalo un errore nella query 9, capitolo 2, delle soluzioni:
    PrezzoIngrosso è moltiplicato * 1,5 ma si chiedeva un aumento del 15%, ciò significa moltiplicare * 1,15

    Rispondi al Commento
  5. Veramente complimenti, una guida dettagliata, semplice e adatta a tutti 🙂

    FortyZone

    Rispondi al Commento
  6. Davvero complimenti ragazzi. La prima guida che per chi parte da zero è manna dal cielo…PERFETTA!!

    Rispondi al Commento
  7. nel punto 8 la soluzione non dovrebbe essere con HAVING MIN(IMPORTO) > 400 000; cioè: SELECT BENEFICIARI FROM ASSEGNI GROUP BY BENEFICIARIO HAVING MIN(IMPORTO) > 400 000;

    Rispondi al Commento
  8. un ottimo Manuale unico errore (se vogliamo chiamarlo cosi) i tipi di dati Char(5) number(5,2) cosa sono e come si usano

    Rispondi al Commento
  9. Complimenti ottimo sito! fatto davvero bene. Grazie!

    Rispondi al Commento

Invia commento

Il tuo indirizzo email non sarà pubblicato.