|
Home
|
Appunti di storia dei database relazioniali |
|
|
|
|
|
Written by Administrator
|
|
Monday, 31 March 2008 |
L'alba dei database relazionali è collegata al famoso articolo di Edgar
F. Codd "A relational model of Data for Large Shared Data Banks" del
1970. Questi appunti partono dal primo capitolo del libro "Oracle
Insights.Tales of the Oak Table".
Il primo
progetto significativo che ha cercato di mettere in pratica il modello
descritto da Codd nel suddetto articolo si chiama "System R", iniziato
nel 1973 nel labotorio di ricerca dell'IBM a San Jose. La storia è
riassunta in questo breve articolo scritto per commemorare la morte di Codd il 18 aprile del 2003.
Il progetto System R aveva implementato il linguaggio SQL per
interrogazioni, in senso stretto, in quanto inteso solo come linguaggio
per reperire i dati e non come DDL. Il sistema necessitava di una
precompilazione delle query, ma offriva anche la possibilità di usare
query particolari per lo sviluppo rapido e il test che non
necessitavano di tale precompilazione. Inoltre, cosa significativa,
System R permetteva la ridefinizione o modifica della struttura dei dati "online", ovvero senza dover interrompere il servizio. Codd lavorò poi con Ray Boyce alla definizione della forma normale definita Boyce-Codd (BCNF) che era un ulteriore miglioramento rispetto alla terza forma normale (3NF). Da
System R, la cui documentazione era pubblica, Larry Ellison prese
l'idea di fondare una società che producesse un RDBMS (da qualche parte
ho letto che al tempo Larry Ellison lavorava all'IBM e stava
fotocopiando suddetta documentazione); lo fece con l'aiuto di Bob Miner
e Ed Oates. In questo modo nel 1979 Ellison battè sul tempo IBM
rilasciando la prima versione commerciale di un sistema di database
relazionale, che pare sia uscito gia come versione 2 per farlo apparire
un prodotto più maturo di quanto non fosse. L'IBM annunciò
il suo primo prodotto, SQL/DS nel 1981 e riuscì effettivamente a
rilasciarlo però nel 1983. Poco dopo IBM annunciò quello che diventerà
un po' la bandiera di IBM, DB2 Un serio avversario di Oracle negli anni '80 pare essere stato Ingres, di Michael Stonebraker. Un'altro documento che vale la pena di leggere è questo.
Le dodici regole di CoddNel
1985, pare per limitare la confusione dovuta al fatto che molti
vendevano dei prodotti come database relazionali che in realtà erano
vecchi prodotti mascherati, Ted Codd pubblicò (non ho un riferimento
serio,in alternativa c'è wikipedia, Ohio State University o PSOUG o questo) un
elenco di 12 regole a cui un database relazionale doveva obbedire per
poter essere chiamato tale. In realtà le regole sono tredici perchè c'è
anche una regola zero.
Regola 0: "Foundation Rule"A relational database management system must manage its stored data using
only its relational capabilities.
Regola 1: "The Information Rule"Tutti
i dati devono essere presentati agli utenti in tabelle, chiamate da
Codd "relazioni". Le tabella contengono righe (o tuple) ma non
c'è alcun ordine su queste righe, ne in memorizzazione ne in
estrazione. Tutte le righe di una tabella hanno esattamente le stesse
colonne ed ogni colonna ha tre caratteristiche. Primo, ogni colonna
deve contenere un tipo dato "scalare", cioè un solo valore alla volta;
questo esclude gli "oggetti". Secondo una colonna non può avere
sottocampi e infine il nome di una colonna deve essere univoco per una
tabella.
Regola 2: "Guaranteed Access Rule"Ogni
elemento dei dati deve essere accessibile senza ambiguità. Questo
significa, in un database relazionale puro, dare il nome della tabella, il valore della chiave primaria e il nome della colonna.
Regola 3: "Systematic Treatment of Null Values"Una
novità introdotta dai database relazionali è proprio il concetto di
Null, ovvero di assenza di valore. Oracle ha la grave pecca di trattare in modo equivalente la stringa vuota e il null.
Regola 4: "Dynamic On-Line Catalog"in questo Oracle non segue lo standard SQL, però è conforme, anzi atraverso le viste V$ va ben oltre
Regola 5: "Comprehensive Data Sublanguage"Il database deve supportare almene un linguaggio chiaramente definito. SQL è uno di questi
Regola 6: "View Updating Rule"siccome
ogni query può essere classificata come vista (view) e quindi dovrebbe
essere intercambiabile con una tabella, Codd stabilì che ogni
operazione di manipolazione dei dati che può essere eseguita su una
tabella deve essere eseguibile anche su una vista (o su una query).
Questa regola può creare dei problemi, ad esempio su alcune join.
Oracle ha introdotto i trigger "INSTEAD OF" per completare la
conformità a questa regola.
Regola 7: "High-level Insert, Update, and Delete"questa
regola deriva dalle regole 5 e 6 e stabilisce che le operazioni INSERT,
UPDATE e DELETE dovrebbero (should) essere supportate per qualunque
insieme estraibile di righe. Oracle rispetta questa regola solo per
operazioni su tabelle o viste aggiornabili come in :
UPDATE emps SET JOB='Data Executive' where JOB='DBA' and sal>1000; INSERT INTO EXEC SELECT * FROM EMP WHERE LOWER(JOB) LIKE '%executive%'; DELETE FROM EMPS WHERE LOWER(JOB) LIKE '%executive%'; Regola 8: "Physical Data Independence"Questa
regola stabilisce che l'utente (chi scrive l'SQL) non deve aver bisogno
di conoscere nulla riguardo i meccanismi fisici usati per immagazzinare
ed estrarre i dati. Nelle DDL questo non è proprio soddisfatto.
Regola 9: "Logical Data Independence"Questa regola stabilisce che l'utente (sempre chi scrive SQL) deve avere sempre la stessa vista dei dati anche se viene cambiata
la struttura logica del database (la definizione delle tabelle). In
qualche modo questo si può ottenere con delle viste, ma non pare
proprio ideale.
Regola 10: "Integrity Independence"DDL
e quindi il dizionario dati, deve supportare la dichiarazione di
vincoli che mantengono l'integrità del database durante gli
aggiornamenti. In sostanza parliamo dei vincoli di integrità sui dati
che controllano i dati immessi dagli utenti. Ad oggi Oracle soddisfa
questa regola
Regola 11: "Distribution Independence"Questa
regola aggiunge una dimensione alla regola 8, stabilendo che per
l'utente non deve dover sapere dove stanno effettivamente i dati, si
tratta qualcosa di più di quello che già Oracle implementa attravarso i
database link ed il meccanismo del "Two Phase Commit" (2PC), perchè qui
si intende che anche una stessa tabella può avere dati distribuiti.
Questo pone problemi nelmantenimento dell'integrità dei dati.
Regola 12: "Nonsubversion Rule"Non
ci devono essere metodi alternativi alla modifica della struttura del
database attraverso il linguaggio insiemistico del database. Questo
rende più facile il controllo delle regole sui dati. Un esempio di
meccanismo che in Oracle non soddisfa questa regola è il "direct path"
che permette di caricare dati senza far rispettare i vincoli di
integrità. |
|
|
|
|
|
|
Who's Online |
|
We have 8 guests online |
|
|