Database management system
Un Database Management System (abbr. DBMS) è un programma informatico (o, più frequentemente, un insieme di programmi) progettato per gestire un database, ovvero un insieme di numerosi dati strutturati. Le operazioni, normalmente, sono richieste da un gran numero di utenti. Esempi tipici dell'uso di DBMS possono essere riscontrati nella contabilità, e nella gestione delle risorse umane; i DBMS sono utilizzati frequentemente anche nei servizi di assistenza e nei call-centers. In passato i DBMS erano un'esclusività delle grandi aziende che potevano permettersi l'impegno economico derivante dall'acquisto o dal nolo delle grandi infrastrutture hardware richieste; oggi, con l'abbassamento dei costi, l'utilizzo dei DBMS è divenuto pressocchè uno standard nei "back offices" delle imprese.
Un DBMS è diferente dal concetto generale di applicazione sui database, in quanto è progettato per sistemi multi-utente. A tale scopo, i DBMS si appoggiano a kernel che supportano nativamente il multitasking e il collegamento in rete. Una tipica applicazione per la gestione dei database non includerebbe, infatti, tali funzionalità, ma si appoggerebbe al sistema operativo per consentire all'utente di fruirne dei vantaggi.
Descrizione
Un DBMS può essere costituito da un insieme assai complesso di programmi software che controlla l'organizzazione, la memorizzazione e il reperimento dei dati (campi, records e archivi) in un database. Esso controlla anche la sicurezza e l'integrità del database. Il DBMS accetta richieste di dati da parte del programma applicativo e istruisce il sistema operativo per il trasferimento dei dati appropriati.
Quando si usa un DBMS i sistemi informativi possono essere adeguati molto facilmente quando cambiano le richieste informative dell'organizzazione. Possono essere aggiunte al database nuove categorie di dati senza dover stravolgere il sistema esistente.
Il sistema di sicurezza dei dati impedisce agli utenti non autorizzati di visualizzare o aggiornare il database. Mediante l'uso di passwords (parole d'ordine) agli utenti è permesso l'accesso all'intero database o ad un suo sottoinsieme e in questo secondo caso si parla di subschema. Per esempio un database di impiegati può contenere tutti i dati riguardanti un singolo soggetto, ma un gruppo di utenti può essere autorizzato a vedere solamente i dati riguardanti lo stipendio, mentre altri utenti possono essere autorizzati a vedere solamente le informazioni che riguardano la sua storia lavorativa e la situazione sanitaria.
Storia
I database sono stati utilizzati fin dall'inizio della storia dell'informatica, ma la grande maggiornaza di questi erano programmi specializzati per l'accesso ad un singolo database. Oggi, invece, i moderni sistemi possono essere utilizzati per compiere operazioni su un gran numero di basi di dati differenti. Questa "specializzazione" era dovuta alla necessità di guadagnare in velocità di esecuzione pur perdendo in flessibilità.
Database Navigazionali
Con la crescita della capacità elaborativa dei calcolatori questo contrasto con la flessibilità si andò attenuandosi, con la creazione negli anni '60 di una serie di database utilizzabili per diverse applicazioni. L'interesse nel fissare uno standard crebbe, e Charles W. Bachman, creature di uno di questi prodotti, ("IDS"), fondò il "Database Task Group", all'interno del "Codasyl", il gruppo di lavoro dedicato alla creazione e standardizzazione del linguaggio di programmazione COBOL. Nel 1971 tale standard fu prodotto e prese il nome di "Approccio Codasyl"; presto furono disponibili sul mercato una serie di prodotti basati su tale approccio.
Questo approccio era basato sulla navigazione manuale in un insieme di dati disposti sotto forma di rete. Alla prima apertura del programma, il programma si apriva sul primo dato disponibile, contenente, tra le altre cose un puntatore ai dati successivi. Per trovare un dato il programma attraversava la serie di puntatori fino a trovare il dato corretto. Delle semplici '"query" come "Trova tutte le persone nate in Svezia" richiedevano l'attraversamento dell'interno set di dati. Non esisteva, dunque, alcuna funzione di ricerca; oggi, questio potrebbe sembrare una limitazione, ma all'epoca, essendo i dati archiviati su nastro magnetico, operazioni come quelle evidenziate sopra non erano particolarmente costose in termini di tempo.
nel 1968, la IBM sviluppò un proprio sistema DBMS, chiamato IMS. IMS era uno sviluppo di un programma utilizzato nelle missioni Apollo sui Sistemi /360 e utilizzava un sistema simile all'approccio Codasyl, con l'unica differenza di avere un sistema gerarchico anzichè a rete.
Ambedue le soluzioni presero poi il nome di "database navigazionali" a causa del metodo di consultazione che era stato previsto; inoltre, Charles Bachman, in occasione della premiazione nel 1973 in cui gli venne conferito il Premio Turing presentò un lavoro intitolato "Il programmatore come navigatore". IMS è abitualmente classificato come un database gerarchico mentre IDS and IDMS (ambedue database CODASYL) CINCOMs e TOTAL sono classificato come database a rete.
Database Relazionali
Edgar Codd lavorava alla sede californiana della IBM come ricercatore sulla nascente tecnologia degli hard disk quando osservò l'inefficienza dell'approccio Codasyl con la nuova modalità di memorizzazione dei dati, inefficienza principalmente dovuta all'assenza di una funzione di ricerca. Nel 1970 cominciò a produrre diversi documenti schematizzanti un nuovo approccio alla costruzione delle basi di dati, culminati nel "Modello relazionale per Basi di dati condivise" ("A Relational Model of Data for Large Shared Data Banks") In questo articolo, descrisse un nuovo sistema per archiviare e modificare grandi quantità di dati. Invece di utilizzare delle "righe" (in inglese, ma anche molto usato in italiano: "record" o anche "tuple") collegate tra di loro attraverso un qualche tipo di struttura "ad albero", come in Codasyl, ritenne di utilizzare una "tabella" di righe a lunghezza fissa. Questo sistema sarebbe stato molto inefficiente nell'archiviazione di dati "sparsi", in cui la tabella avrebbe potuto avere dierse "celle" vuote; tale errore di impostazione fu corretto dividendo i dati in diverse tabelle, in cui gli elementi opzionali venivano spostati, anzichè sprecare spazio nella tabella principale.
Ad esempio, un utilizzo comune delle basi di dati è quello di registrare delle informazioni sugli utenti: il loro nome, informazioni di accesso, indirizzo e numeri di telefono. In un database navigazionale tutti questi dati sarebbero stati memorizzati in un unico "record", e gli elementi non presenti (ad esempio un utente di cui non sia noto l'indirizzo) sarebbero stati semplicemente omessi. Al contrario, in un database relzionale, le informazioni sarebbe state divise, ad esempio, nelle tabelle "utente", "indirizzi", "numeri di telefono": solo se i dati sono presenti viene creata, nella rispettiva tabella, una tupla.
La chiave di volta del sistema sta nel collegamento delle tabelle: nel modello relazionale, per ogni record viene definita una "chiave", ovvero un identificatore univoco della riga. Nella ricostruzione delle relazioni, l'elemento di riferimento, che distingue una riga da un'altra è proprio questa "chiave" e viene richiamata nella definizione della relazione. La chiave può essere uno dei dati stessi che vengono memorizzati (as esempio, per la tabella utenti, il "Codice Fiscale" della persona), o un campo che viene aggiunto specificatamente per questo scopo (spesso chiamato "OID" - "Object IDentifier")
Questa operazione di "riunificazione" dei dati non è prevista nei linguaggi di programmazione tradizionali; mentre l'approccio navigazionale richiede semplicemente di "ciclare" per raccogliere i diversi record, l'approccio relazionale richiede al programma di "ciclare" per raccogliere le informazioni riguardanti ogni record. Codd, propose, come soluzione, la creazione di un linguaggio dedicato a questo problema, un linguaggio che, più tardi, si sarebbe sviluppato nella codifica che oggi è utilizzata universalmente e che è il mattone fondamentali delle basi di dati: SQL.
Utilizzando una branca della matematica chiamata "calcolo delle tuple", dimostrò che questo sistema era in grado di compiere tutte le normali operazione di amministrazione dei database (inserimento, cancellazione, etc.) e che inoltre consentiva di disporre di uno strumento semplice per trovare e visualizzare gruppi di dati tramite un'unica operazione.
LA IBM cominciò a implementare questa teoria in alcuni prototipi all'inizio degli Anni 70, com nel "System R". La prima versione fu realizzata nel 1974/75 con uno strumento "monotabella"; negli anni successivi furono studiati i primi sistemi che potessero supportare la suddivisione dei dati in tabelle separate, utile, come abbiamo visto, per la separazione dei dati opzionali in tabelle diverse da quella principale. Versioni "multiutente" furono realizzate nel 1978 e nel 1979; negli stessi anni fu standardizzato il linguaggio SQL. La superiorità di questo sistema rispetto a Codasyl fu quindi evidente e la IBM passo a sviluppare una versione commerciale di "System R", che prese il nome di "SQL/DS" prima e di "Database 2" (DB2) infine.
Il lavoro di Codd, venne proseguito presso l'università di Berkeley da parte di Euegene Wong e Michael Stonebraker. Il loro progetto, chiamato INGRES e finanziato tramite fondi destinati alla creazione di un database geografico, vide la luce nel 1973 e produsse i primi risultati nel 1974 anche grazie all'opera di numerosi studenti che si prestarono quali programmatori; quasi 30 persone lavorarono al progetto. INGRES era assai simile a "System R" e prevedeva un linguaggio alternativo a SQL, chiamato QUEL.
Molte delle persone coinvolte nel progetto si convinsero della fattibilità commerciale dello stesso e e fondarono imprese per entrare nel mercato con questo prodotto: ybase, Informix, NonStop SQL e alla fine Ingres stessa naquero quali "spin-off" per la diffusione di INGREs all'inizio degli Anni 80. Perfino Microsoft SQL Server è, per certi versi, una derivazione di "Sybase" e, quindi, di INGRES. Solamente la Oracle di Larry Ellison partì utilizzando un approccio diverso, basato sul "System R" della IBM, e alla fine prevalse sulle altre compagnie con il suo prodotto, lanciato nel 1978.
In Svezia il lavoro di Codd venne sviluppato nella Università di Uppsala che sviluppò un diverso prodotto, "Mimer SQL", commercializzato nel 1984: una particolarità di questa soluzione sta nella introduzione del concetto di transazione, successivamente importata in quasi tutti i DBMS.
Database Multidimensionali
Presto alcuni DBMS pseudo-relazionali, come Oracle o Sybase, conquistarono gradissime quote di mercato anche se non erano completamente aderenti al lavoro originale di Codd. Come risultato, l'implementazione di interrograzioni con questi sistemi su database perfettamente aderenti agli standard risulta essere assai poco efficiente. Ad esempio, in questi sistemi, per ricercare l'elenco degli utenti che hanno come cognome "Rossi", tali DBMS cercano le chiavi primarie nella tabella "Utenti" , e dopodichp cercano nella tabella "Indirizzi" le istanze con quella chiave nella colonna corrispondente. Anche se ciò è trasparente all'utente, che percepisce una singola operazione, il DBMS compie un lavoro computazionalmente assai oneroso.
Per risolvere questo problema i programmatori hanno adattato lo standard per migliorare le performances dei sistemi; tali adattamenti hanno però causato degli "extra-costi" in termini di ridondanza di dati e controlli per assicurare la consistenza delle basi di dati.
I database multidimensionali, ignorano la indipendenza tra gli aspetti fisici e logici della base di dati insita nel modello relazionale, e al contrario, lasciano la definizione dei puntatori ai programmatori. Invece di cercare l'indirizzo del Signor Rossi in diverse tabelle, il DBMS memorizza un puntatore al record "Indirizzo". In effetti, se il dato "appartiene" ad un certo record nella "tabella padre", questo può essere memorizzato nella stessa area di memoria del primo, ed in tal modo è possibile velocizzare l'accesso. Naturalmente il dato deve appartenere solamente ad una dato-padre.
Questo tipo di implementazione fisica dei dati può (e dovrebbe) essere fatta in questi database pseudo relazionali, pur lasciando una indipendenza logica: il programmatore dovrebbe vedere solamente la chioave primaria che poi andrebbe "tradotta" dal DBMS in un puntatore.
A causa degli scarsi risultati in termini di tempo di accesso ai dati, spesso dovute a cattive implementazioni di questi concetti, i database multidimensionali hanno avuto scaso successo, anche se molti concetti sono stati ripresi dai databse ad oggetti.
DBMS ad oggetti
I database multidimensionali ebbero comunque un ruolo importante sul mercato: portarono alla creazione di basi di dati ad oggetti. basati sugli stessi concetti generali, questa nuova tipologia di sistemi, consentono agli utenti di memorizzare direttamente "oggetti" all'interno delle basi di dati. Ovvero, gli stessi principi della programmazione ad oggetti, invece di dover effettuare un adattamento di metodi e variabili.
Questo può avvenire grazie al particolare conetto di proprietà dei database multidimensionali. nella programmazione ad oggetti, ognuno di questi "oggetti" tipicamente ne conterrà altri. Ad esempio, l'oggetto contenente il Signor Rossi, conterrà un riferimento all'oggetto "Indirizzo". Contenendo il supporto per molti linguaggi di programmazione ad oggetti, i dtabase che sfruttano la medesime tecnologia stanno avendo un periodo di forte sviluppo di questi tempi.
Da continuare la traduzione dalla wikipedia inglese