Wikipedia

Database management system

tipo di software
Versione del 10 mag 2005 alle 17:47 di 82.112.217.1 (discussione) (→Descrizione)

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

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à refenziale. A tale proposito si vedano le cosidette "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 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) 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.

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

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.

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 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 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, 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 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 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 scaso successo, anche se molti concetti sono stati ripresi dai database ad oggetti.

DBMS ad oggetti

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 medesime tecnologia stanno avendo un periodo di forte sviluppo di questi tempi.

Lista di DBMS comuni

Voci correlate

Collegamenti esterni

Estratto da "https://it.wikipedia.org/w/index.php?title=Database_management_system&oldid=589084"