Con la diffusione delle architetture basate su Microsoft, il modello di riferimento per la gestione delle informazioni diventa Sql. Per i responsabili dei sistemi informativi è, quindi, necessario comprendere esattamente cosa si pone alla base di questo standard di fatto.
Il mezzo principale per consultare, interrogare e aggiornare i database relazionali è, ormai da molti anni, il linguaggio Sql (Structured query language). Il fatto di avere uno standard definito ha aperto, in teoria, la strada all’intercomunicabilità fra tutti i prodotti che si basano su di esso. Dal punto di vista pratico, purtroppo però, le cose sono andate differentemente. In generale, infatti, ogni produttore ha adottato e implementato solo il cuore di Sql (il cosiddetto entry level o al massimo l’intermediate level), estendendolo in maniera proprietaria a seconda della propria visione del mondo dei database.
Tutte le applicazioni e i tool di sviluppo legati ai database relazionali, indipendentemente dall’interfaccia o dal loro approccio, traducono le query e altri comandi in linguaggio Sql. Anche gli strumenti di sviluppo più recenti, magari basati su concetti di programmazione visuale, effettuano tale conversione. Ciò semplifica l’integrazione dei sistemi di front end con quelli di back end, specialmente nelle architetture client-server a più livelli. La sola eccezione a questa regola riguarda i database object oriented, la cui struttura non è tipicamente relazionale.
Per comprendere la validità del modello di gestione dati implementato da Sql bisogna indagare sulle ragioni alla base della sua creazione. In origine, una delle principali spinte è stata quella di rendere tutti, o quasi, gli utenti aziendali autonomi dal punto di vista dell’estrazione dei dati, creazione dei report, elaborazioni statistiche e via dicendo. Infatti, data l’intrinseca semplicità del linguaggio (perlomeno delle sue istruzioni base), era opinione diffusa che, in breve tempo, anche il middle e il top management sarebbero stati in grado di creare le proprie query, senza che fossero necessari interventi di personale tecnico. In realtà, quanto inizialmente ipotizzato non si è verificato, se non in minima parte, data la storica ritrosia "di fondo" che gran parte del management aziendale tuttora nutre verso l’apprendimento di tecnologie informatiche.
Allo stato attuale è in corso un processo di revisione del linguaggio da parte dei comitati Ansi e Iso, che dovrebbe portare alla definizione di ciò che al momento è noto come Sql3. Le caratteristiche principali di questa nuova incarnazione di Sql dovrebbero essere la sua trasformazione in un linguaggio stand alone (mentre ora viene usato come linguaggio ospite) e l’introduzione di nuovi tipi di dati più complessi per permettere, ad esempio, il trattamento di quelli multimediali. Sono ormai lontani i tempi in cui, per database con più di 40mila o 50mila record i tempi di elaborazione delle query risultavano spesso inaccettabili. Con opportune indicizzazioni, detti limiti sono ora aumentati di almeno due ordini di grandezza, rendendo così fruibile questo linguaggio anche ad aziende con grosse basi dati (banche, assicurazioni) e per applicazioni Crm (notoriamente assetate di informazioni).
Il modello collaudato
I database relazionali (Rdbms) seguono il cosiddetto modello Entità-Relazioni (E-R) dove le entità sono date dagli elementi da memorizzare (per esempio il personale) le cui caratteristiche sono organizzate in tabelle che possono essere visualizzate con la classica struttura a righe e colonne. Tra le entità di un database si hanno diverse relazioni (ad esempio un dipendente è legato alle registrazioni delle proprie spese), che si traducono in collegamenti tra le corrispondenti tabelle (in questo caso tra la tabella "dipendenti" e quella "spese"). Tali link avvengono attraverso l’uso di parametri inseriti nelle tabelle stesse. Nell’esempio precedente, ogni spesa conterrà la matricola o qualsiasi altro identificatore univoco dell’impiegato.
Questo approccio permette di estrarre velocemente i dati da più tabelle e restituirli all’utente, o a un’applicazione, sotto forma di un’unica collezione di dati, ossia il risultato della query. L’utilizzo del modello E-R consente al database designer di descrivere in modo flessibile le relazioni fra i dati gestiti dai vari sistemi, anche se al crescere delle informazioni e delle relazioni aumenta la complessità della struttura. Per gli utenti, comunque, la tabella rappresenta la "visione" più intuitiva e chiara delle informazioni contenute nei database.
Attualmente, il linguaggio Sql costituisce lo strumento più utilizzato negli Rdbms per ricavare ed elaborare le informazioni contenute in un database: la sua storia si è, infatti, evoluta parallelamente al concetto stesso di struttura relazionale dei dati. L’organizzazione di questi tramite tabelle, adottata nel modello relazionale, e la creazione di query mediante comandi rimangono ancora oggi la combinazione di più semplice comprensione, pur garantendo grande libertà agli sviluppatori.
Entrando nel dettaglio, si può dire che, normalmente, l’interazione con un database relazionale avviene utilizzando istruzioni Sql mentre l’invio delle istruzioni al Dbms può avvenire per invocazione interattiva o tramite un programma applicativo. Nel primo caso si utilizza un programma il cui scopo è quello di ricevere in input le istruzioni Sql, trasmetterle al Dbms e visualizzare i risultati all’utente. Normalmente, tutti i Dbms mettono a disposizione un programma di tipo testuale che esegue le istruzioni Sql contenute in un file e termina immediatamente dopo. In questo modo è possibile automatizzare operazioni che devono essere ripetute di frequente o, comunque, composte da lunghe sequenze di comandi Sql, senza doverle digitare manualmente ogni volta.
Nel caso dell’invocazione delle istruzioni tramite un programma applicativo, i risultati sono utilizzati dal programma per produrre l’output. In questa situazione, l’utente non sottopone direttamente i comandi Sql e potrebbe anche non essere a conoscenza che il programma in uso sia in grado di accedere a un database relazionale: l’unica cosa rilevata è l’interfaccia messa a disposizione dall’applicazione.
Sostanzialmente, sono due i sistemi disponibili per scrivere applicazioni di questo tipo. È, infatti, possibile utilizzare l’Embedded Sql (Esql) oppure una libreria capace di gestire la comunicazione con il Dbms che trasmetta le istruzioni Sql e permetta di manipolare i risultati prodotti. Librerie di questo tipo sono, ad esempio, Jdbc e Odbc. Spesso i produttori dei Dbms forniscono librerie proprietarie, anche se in questo caso le applicazioni risultano molto specifiche e non trasportabili. Impiegando, al contrario, quelle "standard", come Jdbc o Odbc, le applicazioni funzioneranno con qualunque Dbms che esponga l’interfaccia richiesta dalla libreria (a meno di non utilizzare funzionalità specifiche del Dbms). Nel caso di Esql, invece, il codice Sql viene inglobato in quello di un linguaggio ospite, utilizzando i normali meccanismi per il passaggio dei parametri e dei risultati. Normalmente, il codice che si ottiene viene prima convertito da un pre-processore per passare, poi, al compilatore del linguaggio ospite. Uno dei vantaggi di Esql risiede nel fatto che uno standard Ansi ne descrive il funzionamento. In questo modo è possibile che un programma scritto per un determinato Dbms possa essere ricompilato e funzionare perfettamente anche per un altro.
Sql si è comunque via via ampliato per comprendere nuove funzionalità e alcune delle estensioni proprietarie sviluppate dai software vendor, e si prepara a "convivere" con i più recenti database a oggetti.
L’approccio object oriented
Lo svantaggio del modello relazionale dipende dal fatto che alcune realtà non possono essere facilmente "racchiuse" in tabella. Dalle esigenze di ambiti applicativi che richiedono la gestione di informazioni molto complesse, come i settori del Cad, sono quindi nati i database a oggetti. Gli Oodbms (Object oriented database management system) uniscono le caratteristiche dello sviluppo a oggetti con le tecnologie database, dando vita a un ambiente di programmazione integrato in cui le entità del modello relazionale diventano oggetti.
In quanto tali, le "vecchie" entità integrano le relazioni che le legano e che non vanno definite nelle applicazioni. Database relazionali e object oriented non sono (almeno oggi) in competizione, un pò per la posizione ormai dominante del modello relazionale ma soprattutto perché l’approccio a oggetti è inutile nelle applicazioni che gestiscono volumi di dati anche molto elevati ma non complessi.
Apertura all’esterno
Già da tempo sono state definite le specifiche Odbc (Open database connectivity) che forniscono un’interfaccia comune attraverso cui un’applicazione, anche Sql, può collegarsi con qualsiasi database, purché compatibile Odbc. Recentemente, specifiche simili (le Jdbc, Java data base connectivity) sono state introdotte per definire come i comandi Sql possano interfacciarsi con i programmi realizzati in linguaggio Java. Le specifiche di questo linguaggio sono state stabilite nel 1992, anche se, come già detto, un aggiornamento è in fase di studio.
L’obiettivo del possibile nuovo standard Sql3, quindi, vuole essere un ampliamento del linguaggio, in modo che possa essere utilizzato anche con i database a oggetti. Ciò implica che Sql3 debba includere, tra l’altro, gerarchie di specializzazione e di generalizzazione, dati definibili dall’utente ed espressioni di query ricorsive (che richiamano se stesse). Inoltre, una versione aggiornata di Sql dovrebbe supportare le caratteristiche associate alla programmazione a oggetti, quali i dati astratti, l’ereditarietà, il polimorfismo e l’incapsulamento.
In azienda, poi, capita spesso che l’esperto di marketing, piuttosto che quello di produzione, voglia prendere egli stesso decisioni rapide, legate ai dati aziendali ma, difficilmente sarà in grado di adoperare strumenti tecnici, anche se di alto livello come Sql. Ecco, quindi, la necessità di sviluppare e visualizzare le informazioni in un modo chiaro e sintetico: in molti pacchetti software si possono usare grafici a barre espandibili, menu top down associati a tecniche Olap di drill down e così via, in modo che anche un "non esperto di informatica" possa lavorare senza difficoltà. In sostanza, gli strumenti per il reporting permettono di formulare query senza che gli utenti conoscano il linguaggio Sql, avendo la possibilità di vedere il risultato in diversi formati, a seconda delle esigenze.
I limiti attuali
Nella versione interattiva attuale, Sql presenta, tuttavia, alcune carenze. Non è, infatti, consentito l’utilizzo del costrutto if-else per imporre delle condizioni all’esecuzione di comandi e non è possibile usare l’istruzione Select né per stampare il nome e la versione dell’Sql Server in uso, né per creare dei contatori di record per due diverse tabelle. I dati char, varchar, binary, varbinary hanno, poi, dei limiti di lunghezza alquanto ridotti e non sono gestibili procedure particolari per eseguire comandi da shell, come ad esempio visualizzare i file contenuti nel disco C. Queste sono solo alcune delle caratteristiche avanzate che alcuni dialetti di Sql, ad esempio T-Sql di Microsoft, già possiedono ma che saranno probabilmente disponibili in futuro anche con le nuove release standard di Sql.
