Database: a cosa servono e quali tipi ci sono

Un database raccoglie dati e li collega in un’unità logica. I singoli dati sono forniti con metadescrizioni e le informazioni necessarie per la loro elaborazione. I database sono estremamente utili per la gestione dei dati e semplificare la ricerca di informazioni specifiche. Inoltre in molti database si possono stabilire tramite i diritti di accesso quali persone o programmi possano accedere a quali dati. Si occupano anche di rappresentare i contenuti in modo chiaro e consono ai bisogni.

I sistemi di database differiscono tra loro a livello concettuale e hanno di conseguenza pregi e difetti peculiari. Tutti si basano però su una suddivisione in database e sistema di gestione del database. Il database indica l’insieme di tutti i dati che devono essere ordinati (insieme indicato anche come “base di dati”). Il sistema di gestione del database è responsabile appunto per la gestione e stabilisce la struttura, l’ordine, i diritti di accesso, le dipendenze etc. Per fare questo spesso utilizza una lingua di database appositamente definita e un appropriato modello di database che specifica l’architettura del sistema di database.

Già negli anni 60 era stato elaborato il concetto di database elettronico come livello separato di software tra il sistema operativo e il programma dell’applicazione, in grado di strutturare l’elaborazione dei dati elettronici in modo efficiente. Del resto si è trattato di uno sviluppo naturale: il lavoro manuale file per file, la supervisione e la suddivisione dei diritti di accesso rendevano il lavoro troppo macchinoso, rendendo l’elaborazione elettronica dei dati un alleggerimento concreto del lavoro. L’idea dei sistemi di database elettronici è stata una delle innovazioni più importanti nello sviluppo del computer.

Inizialmente sono stati sviluppati modelli di database gerarchici e di rete, che però presto si sono dimostrati troppo semplici e tecnicamente limitati. Negli anni 70 grazie a IBM ci fu un notevole passo avanti con lo sviluppo del modello di database relazionale, che si diffuse rapidamente nel mondo del lavoro. I prodotti di maggior successo di questo periodo erano il linguaggio di database SQL di Oracle e i prodotti successivi di IBM, SQL/DS e DB2.

Fino agli anni 2000 nel mercato dei software per i database dominavano principalmente i fornitori di grande fama, fino a quando alcuni progetti open source portarono una ventata di aria fresca. I più popolari sistemi liberamente accessibili sono MySQL e PostgreSQL. La tendenza verso i sistemi NoSQL dal 2001 ha continuato a sfidare la tradizione dei sistemi di database relazionali dei produttori.

Oggi i sistemi di database sono diventati irrinunciabili per molti ambiti di applicazioni. Ogni software  aziendale si basa su database potenti che rendono disponibili una vasta gamma di opzioni e strumenti per gli amministratori di sistema. Inoltre il tema della sicurezza dei dati nei sistemi di database è diventato sempre più importante: infatti nei database elettronici vengono archiviate e crittografate password, informazioni personali, nonché valute elettroniche.

Il moderno sistema finanziario si può ad esempio immaginare come un grande network di database. La maggior parte delle somme in denaro esistono come unità di informazione elettroniche e la tutela di queste informazioni grazie a database sicuri è un compito essenziale degli istituti finanziari. Un ulteriore motivo che ci fa comprendere l’importanza dei database per la nostra civiltà.

Un termine ampiamente utilizzato che descrive le funzioni e i requisiti per le transazioni del sistema di gestione dei database è ACID (conosciuto anche come AKID), un acronimo per atomicity, consistency, isolation e durability (atomicità, coerenza, isolamento e durabilità). Le sottosezioni di ACID a loro volta coprono i requisiti più importanti per un DBMS:

• L’atomicità indica la proprietà “tutto o niente” del DBMS, nel senso che solo le richieste valide vengono eseguite nell’ordine stabilito, garantendo la correttezza dell’intera transazione.
• La coerenza richiede che le transazioni riuscite lascino un database stabile, che a sua volta richiede una revisione costante di tutte le transazioni.
• Per isolamento si indica il requisito che le transazioni non si ostacolino l’un l’altra, il che è garantito da specifiche funzioni di blocco.
• Per durabilità si intende che tutti i dati sono memorizzati in modo permanente nel DBMS, anche dopo aver completato una transazione corretta. Questo vale anche o soprattutto in caso di errori di sistema o guasti del DBMS. Per garantire la durabilità sono essenziali ad esempio i registri delle transazioni, che archiviano tutti i processi del DBMS.

Di seguito trovate un breve prospetto delle funzioni e dei requisiti di un sistema di gestione di database che superano il modello ACID.

La differenziazione tra i comuni modelli di database è anche il risultato degli sviluppi tecnici della trasmissione dei dati in forma elettronica. Si trattava soprattutto di efficienza e di usabilità, ma anche di una corsa agli armamenti di noti produttori in concorrenza tra loro.

Il modello che per primo si è affermato è quello gerarchico, che però nel frattempo è stato ampiamente sostituito dai database relazionali e da altri modelli. Tuttavia recentemente il modello gerarchico è utilizzato abbastanza spesso: XML utilizza questo semplice sistema per l’archiviazione dei dati. Alcune banche e assicurazioni utilizzano ancora database gerarchici, soprattutto quando si usano applicazioni database datate. Il sistema di database gerarchico più conosciuto in assoluto è IMS/DB di IBM.

Nei database gerarchici ci sono dipendenze molto nette. In questo modo ogni record di dati ha un precedente in una relazione “padre-figlio” (parent-child relationship, PCR) ad eccezione del root del database. Ciò porta alla struttura ad albero riportata nella figura sopra. In realtà ogni “figlio” può avere soltanto un “padre”, viceversa ogni “padre” può avere un numero a piacere di “figli”. A causa di questo rigoroso ordine gerarchico, i livelli che non sono direttamente adiacenti non hanno la possibilità di interagire tra loro. Inoltre non si può stabilire facilmente una connessione tra due diversi alberi. Le strutture gerarchiche del database sono perciò estremamente rigide, anche se molto chiare.

I dati che hanno “figli” vengono indicati come “record”, mentre quelli che non ne hanno “fogli”, perché generalmente in un database gerarchico contengono documenti. I record servono principalmente ad ordinare i “fogli”. Ciascuna query rivolta ad un database gerarchico accede in questo modo ad un foglio, raggiunto a partire dal root attraverso i record.

Il record al centro dell’immagine sopra può teoricamente essere raggiunto da cinque altri record. Allo stesso tempo l’accesso al record centrale consente il percorso verso altri cinque record. Nei modelli di database reticolare si possono stabilire delle dipendenze: il record più in alto non dispone di collegamenti immediati con quello all’estrema destra, ma deve passare attraverso quello in mezzo (che può acconsentire o negare l’accesso). Tuttavia può raggiungere direttamente il record in alto a sinistra. In un modello reticolare si possono inserire e rimuovere record in modo fluido senza interferire con la struttura generale.

Oggi il modello di database reticolare è utilizzato soprattutto sui grandi calcolatori. In altri ambiti ci si affida o ancora al modello gerarchico (particolarmente amato dai clienti IBM) o al modello relazionale, più flessibile e semplice da utilizzare. I modelli di database reticolare più noti sono, accanto a USD della Siemens, DMS di Sperry Univac. Entrambi i marchi nel corso degli anni hanno sviluppato forme ibride interessanti che si situano tra il modello reticolare e quello relazionale, senza però riuscire a dare una vera svolta. I risultati di questo tentativo si possono tuttavia vedere ancora oggi in Siemens SQL. Il database grafico, con la sua struttura a rete, è uno sviluppo moderno del modello reticolare.

In questo video potete trovare una breve introduzione ai database e un confronto tra i database gerarchici e quelli reticolari:

Il modello di database relazionale lavora con singole tabelle che stabiliscono la localizzazione delle informazioni e i suoi collegamenti. Queste informazioni vanno a formare un record (nell’immagine sopra una riga, row in inglese, o “tupla”). Le singole informazioni vengono raggruppate nelle colonne come attributi (nella figura A1 fino An). La relazione generale (“relation” è una parola spesso utilizzata come sinonimo di “tabella”) risulta perciò dagli attributi connessi. Per la chiara identificazione di un record è necessario la chiave primaria che generalmente è definita dal primo attributo (A1) e che non può mai cambiare. In altre parole la cosiddetta chiave primaria (anche detta “ID”) definisce la precisa posizione del record con tutti gli attributi.

Nei modelli di database orientati agli oggetti i dati vengono archiviati in un oggetto insieme alle loro funzioni o metodi. Gli oggetti includono anche termini con attributi associati che descrivono il rispettivo oggetto in modo dettagliato. L’accesso a questi oggetti viene definito nel sistema di gestione del database a oggetto utilizzando i “metodi” che sono memorizzati insieme ai dati nell’oggetto.

Gli oggetti inoltre possono essere complessi ed essere costituiti da un numero qualsiasi di tipi di dati. Inoltre gli oggetti all’interno del sistema di database sono unici e sono identificati da un numero univoco (Object ID, OID). Come si può vedere nell’immagine sopra, i singoli oggetti vengono raggruppati in classi di oggetti, configurando una gerarchia di classi. In questo modo il modello parrebbe simile a quello del database gerarchico, ma qui non ci sono delle relazioni fisse sul modello parent-child. Tuttavia attraverso si possono specificare i metodi di accesso utilizzando le classi di oggetti.

I database a oggetto sono vantaggiosi quando si tratta di problemi complessi che coinvolgono la profondità degli oggetti corrispondenti. Normalmente il database a oggetto lavora in modo autonomo senza grandi interventi nella normalizzazione e nella referenziazione degli ID, consentendo quindi un feed-in relativamente semplice e lineare di nuovi oggetti complessi. Le query semplici sono invece molto più veloci in un sistema di database relazionale. La scarsa popolarità dei database orientati agli oggetti porta anche ad una inadeguata compatibilità con molte delle applicazioni comuni per i database.

In questo video potrete vedere un confronto tra i database relazionali e quelli a oggetto:

I documenti costituiscono in questo modello l’unità di base per l’archiviazione dei dati. Essi strutturano i dati e non vanno confusi con i documenti che conosciamo ad esempio dai programmi di modifica del testo. I dati vengono archiviati nelle cosiddette coppie key/value e perciò constano di una “chiave” e di un “valore”. Poiché non è stabilito un numero o una struttura precisa per queste coppie, i documenti singoli all’interno di un database possono apparire molto diversi. Ogni documento è un’unità autonoma. Non è semplice stabilire relazioni tra i documenti, ma in questo modello non sono nemmeno necessarie. 

Nel modello relazionale (rappresentato nella figura con le tabelle) vengono stabilite diverse relazioni per leggere un record di dati comune. Nel modello orientato al documento, è sufficiente un singolo documento per memorizzare tutte le informazioni. Lo schema è inoltre liberamente selezionabile: il modello di database orientato al documento è concettualmente schematico, purché il linguaggio del database utilizzato rimanga lo stesso.

Per i database orientati al documento è fondamentale l’idea che i dati correlati siano sempre memorizzati insieme in un unico luogo (nel documento). Mentre i database relazionali normalmente visualizzano e producono informazioni prevalentemente collegando più tabelle, qui è sufficiente una query indirizzata ad un documento. In questo modo si riduce evidentemente il numero di operazioni necessarie al database.

I sistemi di database orientati ai documenti sono interessanti soprattutto per le applicazioni web, perché possono essere utilizzati per alimentare moduli HTML completi. I database orientati ai documenti sono diventati sempre più popolari soprattutto in seguito allo sviluppo del web 2.0. Tuttavia tra i diversi sistemi di database orientati ai documenti ci sono differenze significative dalla sintassi fino alla struttura interna. Pertanto non tutti i database orientati ai documenti sono adatti per ogni applicazione. Soprattutto a causa di queste diverse interazioni esistono oggi alcuni ben noti sistemi di database orientati ai documenti: Lotus Notes, Amazon SimpleDB, MongoDB, CouchDB, Riak, ThruDB, OrientDB e molti altri.