Introduzione ai DBMS

Un Database Management System (abbreviato con DBMS) è un particolare software in grado di gestire in maniera efficace grandi collezioni di dati, sui quali vengono stabilite delle politiche di sicurezza e di persistenza.

Ogni organizzazione, dalla più semplice alla più complessa, ha la necessità di elaborare alcune informazioni. Ogni organizzazione è quindi dotata di un sistema informativo, che in alcuni casi può essere automatizzato attraverso i calcolatori.

I DBMS rappresentano la scelta migliore per gestire grandi quantità di informazioni, che devono essere subito accessibili.

Normalmente la gestione dei dati verrebbe affidata ai linguaggi di programmazione di alto livello (come il C, C++, Java, ecc.), che non avrebbero altra scelta se non utilizzare file e archivi, eventualmente crittografati, memorizzati su disco. In molti casi il sistema informativo è costituito da tanti computer che devono poter aggiornare, inserire o modificare le informazioni. Tale approccio comporterebbe la duplicazione dei dati di interesse per il numero di pc che li utilizzano, con evidente ridondanza e incoerenza.

Le basi di dati ci consentono di superare questi inconvenienti, infatti possiamo gestire collezioni di dati che sono:

• grandi: gestiscono un elevato numero di record e sono limitati solo dalla capacità dell’hard disk.
• condivise: riducono la ridondanza ed eliminano l’inconsistenza
• persistenti: i dati vengono mantenuti anche al termine dell’applicazione che li ha generati
• affidabili: questa non è proprio una caratteristica dei dbms, ma una precauzione che in ambito aziendale viene presa dagli amministratori, ovvero vengono periodicamente effettuate delle copie di backup che consentono in caso di guasti di ripristinare il tutto
• riservati: vengono stabilite delle politiche di accesso e modifica ai dati, attraverso i cosiddetti account utente
• i dati vengono gestiti in modo efficiente, ridotti tempi di elaborazione e memoria occupata
• i dati sono gestibili in maniera efficace, rendendo conveniente e semplice il loro utilizzo

Modelli dei dati

Servono ad organizzare i dati di interesse in modo da renderli comprensibili in un certo contesto. Da un lato i modelli concettuali, quelli utilizzati dai progettisti di database per descrivere i concetti fondamentali mediante formalismi maggiormente comprensibili all’uomo e non direttamente elaborabili da un calcolatore, dall’altro i modelli logici che indicano la particolare organizzazione dei dati (che può essere gerarchica, reticolare o relazionale).

I database più diffusi sono appunto quelli relazionali. Da Wikipedia riporto la storia della loro evoluzione:

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 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 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 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 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 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 nella introduzione del concetto di transazione, successivamente importata in quasi tutti i DBMS.

I DMBS più diffusi

Ne esistono molti, ma quelli più diffusi ed utilizzati sono:
MySQL (Open Source), Microsoft SQL Server, Microsoft Access (incluso nel pacchetto Microsoft Office), Oracle, PostgreSQL (Open Source), SQLite (Open Source).

MySQL vs Access

Nella mia esperienza ho avuto modo di provare sia MySQL che Microsoft Access; entrambi offrono grandi potenzialità, ma nettamente è un confronto che non regge: il primo destinato a siti web e portali anche molto trafficati, il secondo va bene per piccole applicazioni che non hanno grosse necessità di accesso multiutenza o da remoto.

MySQL richiede un po’ più di manutenzione e di esperienza per l’installazione e l’utilizzo, ma gli strumenti a disposizione sono ottimi e le guide si trovano facilmente su internet. E’ un prodotto Open Source, quindi molto seguito ed aggiornato. Recentemente è stato acquisito da Sun, quindi un buon bigliettino da visita. Nativamente non presenta interfaccia grafica (tutto a linea di comando) ma ovviamente sono stati sviluppati alcuni frontend, il più diffuso dei quali è PHPMyAdmin.

Access non ha troppe pretese. Buona l’interfaccia grafica, più intuitiva del suo rivale, anche se molte funzionalità per la creazione/modifica del database relazionale sono nascoste o più complesse da attivare. Anch’esso consente di gestire la multiutenza o l’accesso da remoto, ma non è decisamente il caso di utilizzarlo in ambito professionale.

In definitiva il primo ottimo prodotto per siti web e portali privati o aziendali che gestiscono grandi quantità di dati che devono essere accessibili da molti utenti anche contemporaneamente.
Il secondo può limitarsi all’utilizzo di un solo utente che vuole in pochi passaggi e con estrema facilità realizzare un database e richiamarlo attraverso comodi bottoni grafici da inserire nelle cosiddette maschere (ovvero le finestre a schermo).

Attendiamo il vostro parere su altri DBMS.