Database management system

Da Wikipedia, l'enciclopedia libera.

In informatica, un Database Management System (abbreviato in DBMS) è un sistema software progettato per consentire la creazione e manipolazione efficiente di database (ovvero di collezioni di dati strutturati) solitamente da parte di più utenti. I DBMS svolgono un ruolo fondamentale in una grandissima quantità di applicazioni informatiche, dalla contabilità, la gestione delle risorse umane e la finanza fino a contesti tecnici come la gestione di rete o la telefonia. Se in passato i DBMS erano diffusi principalmente presso le grandi aziende e istituzioni (che potevano permettersi l'impegno economico derivante dall'acquisto delle grandi infrastrutture hardware necessarie per realizzare un sistema di database efficiente), oggi il loro utilizzo è diffuso praticamente in ogni contesto. L'espressione applicazione enterprise, che nel gergo informatico si riferisce ad applicazioni legate al business delle aziende che le utilizzano, implica quasi "per definizione" la presenza di una o più basi di dati amministrate da uno o più DBMS.

La teoria dei database, e dei DBMS, rappresenta da sempre uno dei filoni più solidi e importanti dell'informatica.

Un DBMS è differente 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.

[modifica] 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, record e archivi) in un database. Un DBMS 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 al cambiamento delle 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 password (parole d'ordine) agli utenti è permesso l'accesso all'intero database o ad un suo sottoinsieme: 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.

Il DBMS può mantenere l'integrità del database non consentendo a più utenti di modificare lo stesso record contemporaneamente (blocco del record). Il database può impedire l'immissione di due record duplicati; per esempio può essere impedita l'immissione nel database di due clienti con lo stesso numero identificativo (campi chiave). L'insieme di regole che determinano l'integrità e la consistenza di una base di dati prendono il nome di Vincoli di integrità referenziale. A tale proposito si vedano le cosiddette "proprietà ACIDE".

I linguaggi di interrogazione del database mediante query (interrogazioni) e i generatori di report permettono agli utenti di interrogare in maniera interattiva il database e di analizzarne i dati.

Se il DBMS fornisce un modo per aggiornare ed immettere nuovi dati nel database, oltre che per interrogarlo, questa capacità permette di gestire database personali. Comunque queste funzionalità non danno la possibilità di mantenere traccia delle revisioni e non forniscono gli strumenti necessari alla gestione di una organizzazione multi-utente. Questi controlli sono disponibili solamente quando un insieme di programmi applicativi sono appositamente costruiti per gestire e coordinare ciascuna funzione di immissione o modifica dei dati.

Un sistema informativo commerciale è costituito da soggetti (clienti, impiegati, venditori) e attività (ordini, pagamenti, acquisti, ecc.). La progettazione del database (database design) è il processo decisionale su come organizzare questi dati in tipi di record e su come ciascun tipo di record si relaziona con gli altri. Il DBMS dovrebbe rispecchiare la struttura dei dati dell'organizzazione e gestire in maniera efficiente le varie transazioni.

Le organizzazioni possono usare un DBMS per gestire il normale processo quotidiano delle transazioni e in un secondo tempo spostare il dettaglio in un altro computer che usa un altro DBMS più adatto per gestire interrogazioni casuali e l'attività di analisi. Le decisioni globali circa l'architettura dei sistemi informativi, sono gestite dagli analisti di sistema e dagli amministratori dei dati. La progettazione di dettaglio del database è demandata agli amministratori del database stesso.

I tre tipi di organizzazione più comuni sono il modello gerarchico, il modello a rete e il modello relazionale. Un sistema di gestione del database può fornire uno, due o anche tutti e tre questi metodi. Sono usate anche le liste invertite e altri metodi. La scelta delle struttura più adatta dipende dal tipo di applicazione, dalla frequenza delle transazioni e dal numero di interrogazioni che saranno effettuate.

Il modello dominante oggi è quello relazionale, normalmente utilizzato con il linguaggio di interrogazione SQL. Molti DBMS supportano le API (Application Program Interface) dell'Open Database Connectivity (ODBC) o Java Database Connectivity (JDBC, lo standard per Java), che forniscono ai programmatori strumenti standardizzati per l'accesso ai database.

I database server sono computer ottimizzati per ospitare i programmi che costituiscono il database reale e sui quali girano solo il DBMS e il software ad esso correlato (nelle situazioni reali spesso questi computer svolgono anche altre funzioni non correlate con la gestione del database). Di solito si tratta di macchine multiprocessore e con dischi fissi configurati in modalità RAID per una memorizzazione stabile ed affidabile dei dati che garantisca la continuità del servizio anche in caso di guasto ad un componente (sistemi fault tolerant). In ambienti dove vengono processate transazioni con moli di dati particolarmente elevate vengono utilizzati anche componenti hardware che hanno la funzione specifica di acceleratori di database e che sono collegati ad uno o più server attraverso canali preferenziali ad alta velocità.

Sempre più frequentemente si assiste alla integrazione delle basi di dati e di internet: una vasta classe di applicazioni della rete fa uso di informazioni presenti su basi di dati; esempi di questo tipo di applicazioni vanno dai cataloghi delle imprese, disponibili per il pubblico, alle edizioni on-line dei gionali e dei quotidiani. Per garantire un linguaggio di modellizzazione che consenta di passare dalla visualizzazione dei dati in un formato compatibile con le basi di dati, ad una "vista" concettuale del futuro sito web esiste un linguaggio specifico chiamato WebML.

[modifica] Storia

I database sono stati utilizzati fin dall'inizio della storia dell'informatica, ma la grande maggioranza 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à.

[modifica] 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, questo 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 e IDMS (ambedue database CODASYL), CINCOMs e TOTAL sono classificati come database a rete.

[modifica] Database Relazionali

Per approfondire, vedi la voce RDBMS.

I Dbms relazionali sono detti anche RDBMS (Relational DBMS).

Edgar F. 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 diverse "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 relazionale, le informazioni vengono divise, ad esempio, nelle tabelle "utente", "indirizzi", "numeri di telefono" e solo se i dati sono presenti viene creata, nella rispettiva tabella, una tupla.

Uno degli aspetti interessanti introdotti nei database relazionali 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 è universalmente adottata 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 operazioni 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, come 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 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: Sybase, 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.

[modifica] Database Multidimensionali

Presto alcuni DBMS pseudo-relazionali, come Oracle o Sybase, conquistarono grandissime 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", dopodiché 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 performance 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 chiave 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 scarso successo, anche se molti concetti sono stati ripresi dai database ad oggetti.

[modifica] DBMS ad oggetti

I Dbms a oggetti sono detti anche ODBMS (Object DBMS).

I database multidimensionali ebbero comunque un ruolo importante sul mercato: portarono alla creazione di basi di dati ad oggetti. Basata sugli stessi concetti generali, questa nuova tipologia di sistemi, consente 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 concetto 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 database che sfruttano la medesima tecnologia stanno avendo un periodo di forte sviluppo di questi tempi.

Oggi molti Dbms applicano in realtà un misto tra il modello relazionale e il modello a oggetti. Si parla quindi di ORDBMS (Object Relational DBMS).

[modifica] Architettura di un DBMS

Un DBMS è uno strumento per la creazione e la gestione efficiente di grandi quantità di dati che consente di conservarli in modo sicuro per lunghi periodi di tempo. Un DBMS fornisce agli utenti questi servizi:

Persistent storage: come un file system, un DBMS permette la memorizzazione di grandi quantità di dati, ma garantisce una flessibilità molto più elevata
Programming interface: permette agli utenti di accedere e modificare i dati attraverso un potente linguaggio di interrogazione
Transaction management: supporta l’accesso concorrente ai dati evitando conseguenze indesiderate dovute a crash del sistema e\o dell’applicazione

Si considerano due diversi tipi di utenti:

utenti convenzionali/applicazioni che modificano dati e formulano interrogazioni
l’amministratore della base di dati (database administrator – DBA) responsabile per la struttura, lo schema e la gestione della base di dati

Nell'architettura di un DBMS abbiamo le seguenti sezioni:

Dischi e file
Storage manager
Buffer manager
Index/file/record manager
Execution engine
Query compiler
Concurreny control
Logging/recovery
Transaction manager

Una suddivisione alternativa semplificata (ma parziale), utile a comprendere per linee generali il comportamento di un DMBS, potrebbe essere questa:

Gestore delle interrogazioni
Gestore dei metodi di accesso
Gestore del buffer (Buffer manager)

Il gestore delle interrogazioni

Si occupa elaborare le richieste dell'utente, di solito espresse in Sql, quindi in un linguaggio di tipo dichiarativo (un tipo di linguaggio in cui si descrivono i dati che si vogliono ottenere), e di tradurle in un insieme di operazioni (una procedura), che saranno poi effettivamente eseguite. Di solito vi sono più modi diversi di tradurre un'interrogazione e la funziona principale del gestore delle interrogazioni è quella di scegliere fra le varie alternative quella migliore, quella cioè che richiede un minor tempo di elaborazione ed una minore occupazione di memoria. Ad esempio un'ottimizzazione consiste nell'anticipare sempre le operazioni di selezione, in modo da diminuire da subito il numero di record da elaborare, con ovvi miglioramenti nell'occupazione di memoria e nella velocità. Altre ottimizzazioni sono fatte basandosi su criteri di tipo statistico: la grandezza di una tabella, come le tabelle sono fisicamente memorizzate, ecc. Alla fine dell'elaborazione il gestore delle interrogazioni darà delle direttive al gestore dei metodi di accesso per trovare le tuple.

Il gestore del metodo di accesso

Si occupa di individuare il blocco in cui è presente la tupla di interesse.

Il gestore del buffer

Un DBMS deve gestire una grossa mole di dati, e nel corso delle elaborazioni lo spazio richiesto per i blocchi di dati sarà spesso maggiore dello spazio di memoria disponibile. Per questo vi è la necessità di gestire un'area di memoria in cui caricare e scaricare i blocchi. Il gestore del buffer si occupa principalmente di gestire le operazioni inerenti il salvataggio e il caricamento dei blocchi. In effetti, le operazioni che mette a disposizione il gestore del buffer sono questi:

FIX: con questo comando di dice al gestore del buffer di caricare un blocco dal disco e restituire il puntatore all'area di memoria in cui lo si è caricato. Se il blocco era già in memoria, il gestore del buffer deve solo restituire il puntatore, altrimenti deve caricarlo dal disco e portarlo in memoria. Se il buffer in memoria è pieno però si possono avere 2 situazioni:
- esiste la possibilità di liberare una porzione di memoria perché occupata da transazioni già terminate. In questo caso prima di liberare l'area si scrive il contenuto sul disco se qualche blocco di quest'area era stato modificato.
- Non esiste la possibilità di liberare memoria perché occupata tutta da transizioni ancora in corso. In questo caso il gestore del buffer può lavorare in 2 modalità: nella prima modalità (STEAL) il gestore del buffer libera della memoria occupata da una transizione già attiva, salvando eventualmente le modifiche sul disco; nella seconda modalità (NOT STEAL) la transizione che ha richiesto il blocco viene fatta attendere finché non si libera memoria.
SET DIRTY: richiamando questo comando si contrassegna un blocco in memoria come modificato.

Prima di introdurre gli ultimi 2 comandi si deve anticipare che il DMBS può operare in 2 modalità: FORCE e NOT FORCE. Quando lavora in modalità FORCE, il salvataggio su disco avviene in modalità sincrona con il commit di una transazione. Quando lavora in modalità NOT FORCE il salvataggio viene effettuato di tanto in tanto in maniera asincrona. In genere i database commerciali operano in modalità NOT FORCE perché ciò consente un aumento delle prestazioni: il blocco può subire più modifiche in memoria prima di essere salvato, poi è possibile scegliere di effettuare i salvataggi quando il sistema è più scarico.

FORCE: Con questo comando si forza il gestore del buffer ad effettuare la scrittura in modo sincrono con il la conclusione (commit) della transazione
FLUSH: Con questo comando si forza il gestore del buffer ad eseguire il salvataggio, quando ci si trova in modalità NOT FORCE

[modifica] Lista di DBMS comuni

Software proprietario
- 4th Dimension
- ADABAS (Software AG)
- AskSam
- DB2 (IBM)
- Caché (InterSystems)
- FileMaker Pro (FileMaker, Inc., in precedenza Apple)
- FrontBase
- IMS/DB (IBM)
- Informix (IBM)
- Ingres (Computer Associates)
- InterBase (Borland)
- Microsoft SQL Server (Microsoft)
- Microsoft Access (Microsoft)
- Mimer SQL (Mimer AB)
- Oracle (Oracle Corporation)
- Ovrimos
- Progress RDBMS (Progress Software Corporation)
- SESAM
- SQL Anywhere Studio
- Sybase SQL Server
- Teradata (NCR Corporation)
- TimesTen (TimesTen, Inc.)
Open source o free software
- Berkeley DB (Sleepycat Software)
- Dataman
- DBM
- Emdros
- Firebird SQL (The FirebirdSQL Foundation; derivato da InterBase)
- GigaBASE
- HSQL Database Engine
- HyperNetDatabase
- MaxDB (prima SAP DB e Adabas)
- Metakit
- MySQL (MySQL AB)
- Ozone
- PicoSQL (un Dbms italiano)
- PostgreSQL (in precedenza Postgres) (PostgreSQL Global Development Group)
- SQLite (di pubblico dominio)
- tdbengine
- ZODB