PENSIERO RELAZIONALE
Luglio 2004
NUOVA TEORIA DEL PENSIERO RELAZIONALE
Introduzione
La nostra presentazione rivolge la sua attenzione al mondo dei database, soffermandosi in
particolare sul concetto di db relazionale e i sui problemi che sta incontrando ormai da qualche
anno.
Analizzeremo anche i modi con i quali è stato possibile, fino ad oggi, non abbandonare l’idea che
sta alla base degli RDBMS, soffermandoci sul concetto di denormalizzazione, per poi arrivare ad
illustrare le vie alternative che si pensa porteranno ad una nuova generazione di database.
Situazione Attuale
Il database relazionale, vecchio cavallo da tiro del mondo IT sembra ormai un po’ affaticato.
Tuttavia non sembra ancora venuto il momento di mandarlo in pensione, in quanto rappresenta
una delle principali fonti di guadagno delle più grandi case dell’informatica.
Attorno al suo commercio ruota un mercato di circa 12 milioni di dollari cosi ripartiti:
Sybase
5%
Altri
15%
Oracle
40% ↓
Microsoft
10%
IBM
30% ↑
Come si può notare dal grafico Oracle detiene il primato col 40%(percentuale in diminuzione),
IBM il 30%(percentuale in aumento), Microsoft il 10%(percentuale in aumento).
La situazione dal lato produttori pertanto, di fronte alla necessita di un cambiamento, non si
può dire che sia felice.
Anche dal lato consumatori la situazione non è altrettanto rosea: infatti la maggior parte degli
utenti si lamentano della lentezza di calcolo degli RDB
Le Banche non hanno più il tempo necessario per effettuare i log delle transizioni durante la
notte prima della riapertura.
Gli operatori di borsa, che sono più sensibili ai lievi cambiamenti di mercato e devono poter
operare in tempo reale, si lamentano di questa lentezza così come i più grandi gestori di
telecomunicazioni come Vodafone che hanno a che fare con ingenti quantità di dati.
Le origini
Questa è una buona occasione per esaminare il ruolo del database relazionale e le possibili
alternative, dal momento che ci troviamo in una situazione intermedia tra due eventi
particolarmente significativi.
Nell’aprile del 2003 infatti, Edgar Codd, il creatore del db relazionale, è morto all’età di 79
anni. Quest’anno cade il 40°anniversario dell’invenzione del termine “database”.
Questo termine venne usato per la prima volta all’inizio degli anni sessanta per indicare alcune
applicazioni militari che producevano grandi quantità di dati.
Tuttavia prima di arrivare alla generazione di database relazionale, si è passati attraverso altre
tre generazione a partire dagli inizi degli anni ’60.
Ogni generazione cercava di risolvere i problemi di quella precedente cioè come sono organizzati
i dati e come viene implementata questa organizzazione.
Ogni generazione è stata etichettata in base al modo in cui organizza(o “vede”) i dati che deve
archiviare.
Le tre generazioni precedenti al database relazionale sono quelle dei database “flat file”,
gerarchici e di rete.
Modello Relazionale
Il modello relazionale di Codd si basa un una definizione matematica di relazione: "La relazione
è il prodotto cartesiano tra due o più insiemi".
Codd riprende questa definizione e formula la teoria del database relazionale basato su tabelle,
formate da tuple, che sono funzioni che associano dei valori agli attributi della tabella. Le
tabelle interagiscono tra loro su relazioni logiche determinate dal significato dei dati.
Il database relazionale si presenta come un modello puro, in quanto unicamente basato sui dati.
Al contrario dei modelli precedenti, che usavano puntatori per descrivere le relazioni tra le
entità, in questo modello tutte le relazioni sono basate sul confronto e significato dei dati
contenuti nelle tabelle.
E' un modello elegante poichè costruito su tabelle che descrivono chiaramente il significato e lo
scopo dei dati contenuti nel database.
Caratteristica fondamentale del database relazionale è che slega totalmente l'utente dal dover
conoscere come è implementato a livello fisico il database. Questo è stato ottenuto anche grazie
allo sviluppo di SQL, linguaggio dichiarativo che implementa ottimamente questa funzione.
Codd insieme alla definizione di database relazione, espone dei processi di normalizzazione, che
hanno lo scopo di portare il database ad assumere una forma corretta in base alla defizione da
lui data.
Un passaggio fondamentale si ha nella terza forma di normalizzazione, che ha come scopo
principale eliminare ogni tipo di ridondanza dei dati (poichè la ridondanza crea incongruenza tra
i dati).
Questo passaggio però porta il database a crescere in modo elevato poichè per eliminare
ridondanza si è quasi sempre costretti ad introdurre nuove tabelle. Un elevato numero di tabelle
causa notevoli problemi nell'efficienza delle interrogazioni che per forza di cose saranno
caratterizzate da un elevato numero di join (operato causa principale del rallentamento delle
prestazioni degli attuali DBMS).
Questo è un grosso problema sia per gli utenti e gestori della rete si per le aziende che devono
gestire enormi quantità di dati.
Per questo motivo in questi anni si è passati a una Denormalizzazione dei database che implica
l'inserimento di dati rindondanti per velocizzare l'interrogazione delle tabelle di dati. Questo
però ha portato ad una pardita di purezza ed eleganza dei database relazionali.
Soluzioni alternative
Esistono quindi due soluzioni alternative:
L’uso della forza bruta: SMP, GRID/UTILITY COMPUTING
L’uso dell’intelligenza: database XML
L’uso della forza bruta consiste nell’aumentare brutalmente l’hardware per sopperire alle
inefficienze del software.
SMP
Si tratta di piattaforme multiprocessore.
Sono ormai considerate un “vicolo cieco” in quanto possono andare bene per alcune applicazioni
di nicchia, ma non per la maggior parte degli utenti.
Ciò è dovuto al fatto che questo tipo di tecnologia, ad oggi, risulta di difficile sviluppo. Si
ottenuti buoni risultati con 8 processori ma già a 32 le difficoltà aumentano molto.
GRID/UTILITY COMPUTING
Grid: si intende la capacita di utilizzare “assieme” il power processing di molti piccoli processori
dislocati in luoghi diversi e connessi attraverso i protocolli internet.
Consente aumenti apparentemente infiniti a livello di capacità di storage
Utility: insieme di software messi a disposizione nella grid che permettono la gestione
automatica di complesse operazioni
Secondo IBM l’utility computing significa minimizzare l’intervento umano affidando ai software
l’automatica gestione delle operazioni più complesse, riducendo i costi
XML
Una nuova strada intrapresa nell'ultimo periodo è basata su una definizione data da Williams che
dice che è arrivato il momento di slegare l'utente anche dalla conoscenza della struttura logica
del database. Per raggiungere questo obbiettivo le grandi aziende prodruttrici di DBMS stanno
cercando un linguaggio adatto. Negli anni '90, anche sulla spinta data da java, si era pensato di
raggiungere questo obbiettivo con la programmazione ad oggetti, idea decaduta nel breve
periodo. In questo ultimo periodo si è avuta nuova spinta da XML, linguaggio inzialmente
comparso per la realizzazione di siti web altamente personalizzabili, ma che per le sue
caratteristiche si sta dimostrando adatto anche all'implementazione dei database.
XML è un linguaggio di tipo gerarchico, è possibile vederlo come un filesystem, cioè organizzato
ad albero.
Si stanno sviluppando linguaggi come XPath o XML-QL che hanno lo scopo di andare ad
interrogare questo codice XML come se fosse un filesystem. I dati sono contenuti all'interno dei
tag terminali (i file per i FS). Ogni tag intermedio identifica a che famiglia ci si sta riferendo.
Questa idea è portata pesantemente avanti da Oracle che in questo ultimo anno ha visto calare
la sua quota di mercato, e cerca in questa nuova filosofia nuova spinta per i suoi affari.
Questo linguaggio risolve decisamente bene il problema dell'alto numero di tabelle, senza
perdere in chiarazza e purezza.
