Un database raccoglie dati e li collega in un’unità logica. I singoli dati sono forniti con me­ta­de­scri­zio­ni e le in­for­ma­zio­ni ne­ces­sa­rie per la loro ela­bo­ra­zio­ne. I database sono estre­ma­men­te utili per la gestione dei dati e sem­pli­fi­ca­re la ricerca di in­for­ma­zio­ni spe­ci­fi­che. 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 rap­pre­sen­ta­re i contenuti in modo chiaro e consono ai bisogni.

I sistemi di database dif­fe­ri­sco­no tra loro a livello con­cet­tua­le e hanno di con­se­guen­za pregi e difetti peculiari. Tutti si basano però su una sud­di­vi­sio­ne 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 è re­spon­sa­bi­le appunto per la gestione e sta­bi­li­sce la struttura, l’ordine, i diritti di accesso, le di­pen­den­ze etc. Per fare questo spesso utilizza una lingua di database ap­po­si­ta­men­te definita e un ap­pro­pria­to modello di database che specifica l’ar­chi­tet­tu­ra del sistema di database.

Già negli anni 60 era stato elaborato il concetto di database elet­tro­ni­co come livello separato di software tra il sistema operativo e il programma dell’ap­pli­ca­zio­ne, in grado di strut­tu­ra­re l’ela­bo­ra­zio­ne dei dati elet­tro­ni­ci in modo ef­fi­cien­te. Del resto si è trattato di uno sviluppo naturale: il lavoro manuale file per file, la su­per­vi­sio­ne e la sud­di­vi­sio­ne dei diritti di accesso rendevano il lavoro troppo mac­chi­no­so, rendendo l’ela­bo­ra­zio­ne elet­tro­ni­ca dei dati un al­leg­ge­ri­men­to concreto del lavoro. L’idea dei sistemi di database elet­tro­ni­ci è stata una delle in­no­va­zio­ni più im­por­tan­ti nello sviluppo del computer.

Ini­zial­men­te sono stati svi­lup­pa­ti modelli di database ge­rar­chi­ci e di rete, che però presto si sono di­mo­stra­ti troppo semplici e tec­ni­ca­men­te limitati. Negli anni 70 grazie a IBM ci fu un notevole passo avanti con lo sviluppo del modello di database re­la­zio­na­le, che si diffuse ra­pi­da­men­te nel mondo del lavoro. I prodotti di maggior successo di questo periodo erano il lin­guag­gio di database SQL di Oracle e i prodotti suc­ces­si­vi di IBM, SQL/DS e DB2.

Fino agli anni 2000 nel mercato dei software per i database do­mi­na­va­no prin­ci­pal­men­te i fornitori di grande fama, fino a quando alcuni progetti open source portarono una ventata di aria fresca. I più popolari sistemi li­be­ra­men­te ac­ces­si­bi­li sono MySQL e Post­gre­SQL. La tendenza verso i sistemi NoSQL dal 2001 ha con­ti­nua­to a sfidare la tra­di­zio­ne dei sistemi di database re­la­zio­na­li dei pro­dut­to­ri.

Oggi i sistemi di database sono diventati ir­ri­nun­cia­bi­li per molti ambiti di ap­pli­ca­zio­ni. Ogni software  aziendale si basa su database potenti che rendono di­spo­ni­bi­li una vasta gamma di opzioni e strumenti per gli am­mi­ni­stra­to­ri di sistema. Inoltre il tema della sicurezza dei dati nei sistemi di database è diventato sempre più im­por­tan­te: infatti nei database elet­tro­ni­ci vengono ar­chi­via­te e crit­to­gra­fa­te password, in­for­ma­zio­ni personali, nonché valute elet­tro­ni­che.

Il moderno sistema fi­nan­zia­rio si può ad esempio im­ma­gi­na­re come un grande network di database. La maggior parte delle somme in denaro esistono come unità di in­for­ma­zio­ne elet­tro­ni­che e la tutela di queste in­for­ma­zio­ni grazie a database sicuri è un compito es­sen­zia­le degli istituti fi­nan­zia­ri. Un ulteriore motivo che ci fa com­pren­de­re l’im­por­tan­za dei database per la nostra civiltà.

Un termine am­pia­men­te uti­liz­za­to che descrive le funzioni e i requisiti per le tran­sa­zio­ni del sistema di gestione dei database è ACID (co­no­sciu­to anche come AKID), un acronimo per atomicity, con­si­sten­cy, isolation e du­ra­bi­li­ty (atomicità, coerenza, iso­la­men­to e du­ra­bi­li­tà). Le sot­to­se­zio­ni di ACID a loro volta coprono i requisiti più im­por­tan­ti 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, ga­ran­ten­do la cor­ret­tez­za dell’intera tran­sa­zio­ne.
• La coerenza richiede che le tran­sa­zio­ni riuscite lascino un database stabile, che a sua volta richiede una revisione costante di tutte le tran­sa­zio­ni.
• Per iso­la­men­to si indica il requisito che le tran­sa­zio­ni non si osta­co­li­no l’un l’altra, il che è garantito da spe­ci­fi­che funzioni di blocco.
• Per du­ra­bi­li­tà si intende che tutti i dati sono me­mo­riz­za­ti in modo per­ma­nen­te nel DBMS, anche dopo aver com­ple­ta­to una tran­sa­zio­ne corretta. Questo vale anche o so­prat­tut­to in caso di errori di sistema o guasti del DBMS. Per garantire la du­ra­bi­li­tà sono es­sen­zia­li ad esempio i registri delle tran­sa­zio­ni, che ar­chi­via­no 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 dif­fe­ren­zia­zio­ne tra i comuni modelli di database è anche il risultato degli sviluppi tecnici della tra­smis­sio­ne dei dati in forma elet­tro­ni­ca. Si trattava so­prat­tut­to di ef­fi­cien­za e di usabilità, ma anche di una corsa agli armamenti di noti pro­dut­to­ri in con­cor­ren­za tra loro.

Il modello che per primo si è affermato è quello ge­rar­chi­co, che però nel frattempo è stato am­pia­men­te so­sti­tui­to dai database re­la­zio­na­li e da altri modelli. Tuttavia re­cen­te­men­te il modello ge­rar­chi­co è uti­liz­za­to ab­ba­stan­za spesso: XML utilizza questo semplice sistema per l’ar­chi­via­zio­ne dei dati. Alcune banche e as­si­cu­ra­zio­ni uti­liz­za­no ancora database ge­rar­chi­ci, so­prat­tut­to quando si usano ap­pli­ca­zio­ni database datate. Il sistema di database ge­rar­chi­co più co­no­sciu­to in assoluto è IMS/DB di IBM.

Nei database ge­rar­chi­ci ci sono di­pen­den­ze molto nette. In questo modo ogni record di dati ha un pre­ce­den­te in una relazione “padre-figlio” (parent-child re­la­tion­ship, 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 ge­rar­chi­co, i livelli che non sono di­ret­ta­men­te adiacenti non hanno la pos­si­bi­li­tà di in­te­ra­gi­re tra loro. Inoltre non si può stabilire fa­cil­men­te una con­nes­sio­ne tra due diversi alberi. Le strutture ge­rar­chi­che del database sono perciò estre­ma­men­te rigide, anche se molto chiare.

I dati che hanno “figli” vengono indicati come “record”, mentre quelli che non ne hanno “fogli”, perché ge­ne­ral­men­te in un database ge­rar­chi­co con­ten­go­no documenti. I record servono prin­ci­pal­men­te ad ordinare i “fogli”. Ciascuna query rivolta ad un database ge­rar­chi­co accede in questo modo ad un foglio, raggiunto a partire dal root at­tra­ver­so i record.

Il record al centro dell’immagine sopra può teo­ri­ca­men­te 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 re­ti­co­la­re si possono stabilire delle di­pen­den­ze: il record più in alto non dispone di col­le­ga­men­ti immediati con quello all’estrema destra, ma deve passare at­tra­ver­so quello in mezzo (che può ac­con­sen­ti­re o negare l’accesso). Tuttavia può rag­giun­ge­re di­ret­ta­men­te il record in alto a sinistra. In un modello re­ti­co­la­re si possono inserire e rimuovere record in modo fluido senza in­ter­fe­ri­re con la struttura generale.

Oggi il modello di database re­ti­co­la­re è uti­liz­za­to so­prat­tut­to sui grandi cal­co­la­to­ri. In altri ambiti ci si affida o ancora al modello ge­rar­chi­co (par­ti­co­lar­men­te amato dai clienti IBM) o al modello re­la­zio­na­le, più fles­si­bi­le e semplice da uti­liz­za­re. I modelli di database re­ti­co­la­re più noti sono, accanto a USD della Siemens, DMS di Sperry Univac. Entrambi i marchi nel corso degli anni hanno svi­lup­pa­to forme ibride in­te­res­san­ti che si situano tra il modello re­ti­co­la­re e quello re­la­zio­na­le, 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 re­ti­co­la­re.

In questo video potete trovare una breve in­tro­du­zio­ne ai database e un confronto tra i database ge­rar­chi­ci e quelli re­ti­co­la­ri:

Il modello di database re­la­zio­na­le lavora con singole tabelle che sta­bi­li­sco­no la lo­ca­liz­za­zio­ne delle in­for­ma­zio­ni e i suoi col­le­ga­men­ti. Queste in­for­ma­zio­ni vanno a formare un record (nell’immagine sopra una riga, row in inglese, o “tupla”). Le singole in­for­ma­zio­ni vengono rag­grup­pa­te nelle colonne come attributi (nella figura A1 fino An). La relazione generale (“relation” è una parola spesso uti­liz­za­ta come sinonimo di “tabella”) risulta perciò dagli attributi connessi. Per la chiara iden­ti­fi­ca­zio­ne di un record è ne­ces­sa­rio la chiave primaria che ge­ne­ral­men­te è definita dal primo attributo (A1) e che non può mai cambiare. In altre parole la co­sid­det­ta 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 ar­chi­via­ti in un oggetto insieme alle loro funzioni o metodi. Gli oggetti includono anche termini con attributi associati che de­scri­vo­no il ri­spet­ti­vo oggetto in modo det­ta­glia­to. L’accesso a questi oggetti viene definito nel sistema di gestione del database a oggetto uti­liz­zan­do i “metodi” che sono me­mo­riz­za­ti insieme ai dati nell’oggetto.

Gli oggetti inoltre possono essere complessi ed essere co­sti­tui­ti da un numero qualsiasi di tipi di dati. Inoltre gli oggetti all’interno del sistema di database sono unici e sono iden­ti­fi­ca­ti da un numero univoco (Object ID, OID). Come si può vedere nell’immagine sopra, i singoli oggetti vengono rag­grup­pa­ti in classi di oggetti, con­fi­gu­ran­do una gerarchia di classi. In questo modo il modello parrebbe simile a quello del database ge­rar­chi­co, ma qui non ci sono delle relazioni fisse sul modello parent-child. Tuttavia at­tra­ver­so si possono spe­ci­fi­ca­re i metodi di accesso uti­liz­zan­do le classi di oggetti.

I database a oggetto sono van­tag­gio­si quando si tratta di problemi complessi che coin­vol­go­no la pro­fon­di­tà degli oggetti cor­ri­spon­den­ti. Nor­mal­men­te il database a oggetto lavora in modo autonomo senza grandi in­ter­ven­ti nella nor­ma­liz­za­zio­ne e nella re­fe­ren­zia­zio­ne degli ID, con­sen­ten­do quindi un feed-in re­la­ti­va­men­te semplice e lineare di nuovi oggetti complessi. Le query semplici sono invece molto più veloci in un sistema di database re­la­zio­na­le. La scarsa po­po­la­ri­tà dei database orientati agli oggetti porta anche ad una ina­de­gua­ta com­pa­ti­bi­li­tà con molte delle ap­pli­ca­zio­ni comuni per i database.

In questo video potrete vedere un confronto tra i database re­la­zio­na­li e quelli a oggetto:

I documenti co­sti­tui­sco­no in questo modello l’unità di base per l’ar­chi­via­zio­ne dei dati. Essi strut­tu­ra­no i dati e non vanno confusi con i documenti che co­no­scia­mo ad esempio dai programmi di modifica del testo. I dati vengono ar­chi­via­ti nelle co­sid­det­te 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 ne­ces­sa­rie. 

Nel modello re­la­zio­na­le (rap­pre­sen­ta­to nella figura con le tabelle) vengono stabilite diverse relazioni per leggere un record di dati comune. Nel modello orientato al documento, è suf­fi­cien­te un singolo documento per me­mo­riz­za­re tutte le in­for­ma­zio­ni. Lo schema è inoltre li­be­ra­men­te se­le­zio­na­bi­le: il modello di database orientato al documento è con­cet­tual­men­te sche­ma­ti­co, purché il lin­guag­gio del database uti­liz­za­to rimanga lo stesso.

Per i database orientati al documento è fon­da­men­ta­le l’idea che i dati correlati siano sempre me­mo­riz­za­ti insieme in un unico luogo (nel documento). Mentre i database re­la­zio­na­li nor­mal­men­te vi­sua­liz­za­no e producono in­for­ma­zio­ni pre­va­len­te­men­te col­le­gan­do più tabelle, qui è suf­fi­cien­te una query in­di­riz­za­ta ad un documento. In questo modo si riduce evi­den­te­men­te il numero di ope­ra­zio­ni ne­ces­sa­rie al database.

I sistemi di database orientati ai documenti sono in­te­res­san­ti so­prat­tut­to per le ap­pli­ca­zio­ni web, perché possono essere uti­liz­za­ti per ali­men­ta­re moduli HTML completi. I database orientati ai documenti sono diventati sempre più popolari so­prat­tut­to in seguito allo sviluppo del web 2.0. Tuttavia tra i diversi sistemi di database orientati ai documenti ci sono dif­fe­ren­ze si­gni­fi­ca­ti­ve dalla sintassi fino alla struttura interna. Pertanto non tutti i database orientati ai documenti sono adatti per ogni ap­pli­ca­zio­ne. So­prat­tut­to a causa di queste diverse in­te­ra­zio­ni esistono oggi alcuni ben noti sistemi di database orientati ai documenti: Lotus Notes, Amazon SimpleDB, MongoDB, CouchDB, Riak, ThruDB, OrientDB e molti altri.