Database management system

Da Wikipedia, l'enciclopedia libera.

In informatica, un Database Management System, abbreviato in DBMS o Sistema di gestione di basi di dati è un sistema software progettato per consentire la creazione e la manipolazione (da parte di un amministratore) e l'interrogazione efficiente (da parte di uno o più utenti) di database (ovvero di collezioni di dati strutturati), per questo detto anche "gestore o motore del database", e ospitato su architettura hardware dedicata oppure su semplice computer. I DBMS svolgono un ruolo fondamentale in numerose applicazioni informatiche, dalla contabilità, alla gestione delle risorse umane e alla 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 sulle banche dati, 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[modifica | modifica wikitesto]

Un DBMS può essere costituito da un insieme complesso di programmi software che controllano 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.

Autorizzazioni[modifica | modifica wikitesto]

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 a 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.

Integrità[modifica | modifica wikitesto]

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à "ACID".

Interrogazioni e modifiche[modifica | modifica wikitesto]

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 e 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.

DBMS e sistemi informativi[modifica | modifica wikitesto]

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.

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.

Architettura e organizzazione[modifica | modifica wikitesto]

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 reticolare e il modello relazionale. Il modello dominante oggi è quello relazionale, normalmente utilizzato con il linguaggio di interrogazione SQL. Molti DBMS supportano le API (Application programming 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 a 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 e affidabile dei dati che garantisca la continuità del servizio anche in caso di guasto a un componente (sistemi fault tolerant o ad alta affidabilità e disponibilità). 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 a uno o più server attraverso canali preferenziali ad alta velocità di trasmissione.

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 giornali 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, a una "vista" concettuale del futuro sito web esiste un linguaggio specifico chiamato WebML.

Storia[modifica | modifica wikitesto]

I database sono stati utilizzati fin dall'inizio della storia dell'informatica, ma la grande maggioranza di questi erano programmi specializzati per l'accesso a 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[modifica | modifica wikitesto]

Con la crescita della capacità elaborativa dei calcolatori questo contrasto con la flessibilità andò attenuandosi, con la creazione negli anni sessanta di una serie di database utilizzabili per diverse applicazioni. L'interesse nel fissare uno standard crebbe, e Charles W. Bachman, creatore di uno di questi prodotti, (IDS), fondò il Database Task Group, all'interno del gruppo Codasyl, ossia il team 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'intero 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 (o reticolari).

Database Relazionali[modifica | modifica wikitesto]

Exquisite-kfind.png Per approfondire, vedi 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 tupla. 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 (ad 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"), o una combinazione di più campi (chiave composta).

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. Tale linguaggio, più tardi, si è sviluppato nella codifica che oggi è universalmente adottata e che è il mattone fondamentale 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 settanta, 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 passò 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 Eugene Wong e Michael Stonebraker. Il loro progetto, chiamato INGRES e finanziato con 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 fondarono imprese per entrare nel mercato con questo prodotto. Sybase, Informix, NonStop SQL e alla fine Ingres stessa nacquero quali "spin-off" per la diffusione di INGRES all'inizio degli anni ottanta. 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 nell'introduzione del concetto di transazione, successivamente importata in quasi tutti i DBMS.

Database multidimensionali[modifica | modifica wikitesto]

I database multidimensionali sono un paradigma definito ancora una volta da Codd per sopperire alle scarse performance offerte dai database relazionali nel caso di utilizzo delle basi di dati stesse per processi di analisi (on line analitical process, OLAP). Tali sistemi consentono di effettuare analisi su enormi quantità di dati con efficenza, cosa non possibile su database relazionali più adatti a gestire transazioni (on line transaction process, OLTP).

Da fine anni '90 pressoché ogni database relazionale commerciale ha al suo interno un motore multidimensionale per effettuare analisi.

DBMS a oggetti[modifica | modifica wikitesto]

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 a 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 a 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 a 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 a 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).

Architettura di un DBMS[modifica | modifica wikitesto]

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 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:

  1. Dischi e file
  2. Storage manager
  3. Buffer manager
  4. Index/file/record manager
  5. Execution engine
  6. Query compiler
  7. Concurrency control
  8. Logging/recovery
  9. Transaction manager

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

  1. Gestore delle interrogazioni
  2. Gestore dei metodi di accesso
  3. Gestore del buffer (Buffer manager)

Il gestore delle interrogazioni[modifica | modifica wikitesto]

Si occupa di 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 funzione principale del gestore delle interrogazioni è quella di scegliere fra le varie alternative quella migliore, quella cioè che richiede un minor tempo di elaborazione e una minore occupazione di memoria. Ad esempio, un'ottimizzazione consiste nell'anticipare sempre le operazioni di selezione, in modo da diminuire fin dall'inizio 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[modifica | modifica wikitesto]

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

Un utente con privilegi di amministratore dichiara al sistema come gestire gli accessi, tramite una tavola CRUD.

Il DBMS dovrebbe consentire l'accesso in scrittura a una generica risorsa informatica, a un solo utente alla volta. Se due utenze accedono alla stessa risorsa, apportando modifiche, si hanno due casi:

  1. se salvano contemporaneamente il loro lavoro, sorge un conflitto di edizione;
  2. se salvano le modifiche in momenti diversi, chi pubblica per ultimo sovrascrive il lavoro dell'utente precedente.

Il DBMS può includere delle utility per fare dei merge fra versioni differenti della stessa risorsa.

Il gestore del buffer[modifica | modifica wikitesto]

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 al salvataggio e il caricamento dei blocchi. In effetti, le operazioni che mette a disposizione il gestore del buffer sono queste:

  • FIX: con questo comando si 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 due 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 a effettuare la scrittura in modo sincrono con la conclusione (commit) della transazione
  • FLUSH: Con questo comando si forza il gestore del buffer a eseguire il salvataggio, quando ci si trova in modalità NOT FORCE.

Lista di DBMS comuni[modifica | modifica wikitesto]

Voci correlate[modifica | modifica wikitesto]

Altri progetti[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]