Nel contesto informatico un archivio di dati, inteso come collezione omogenea di elementi atti a contenere informazione, è noto con il termine database, letteralmente base di dati.

Un classico e semplice esempio può essere rappresentato da un’agenda telefonica nella quale disponiamo di una serie di righe in cui inseriamo in una posizione un nominativo e nella posizione successiva il corrispondente numero telefonico:

L’intera organizzazione è nota come tabella, le singole righe vengono normalmente chiamate record mentre le singole caselle sono note come campi. In generale le tabelle posseggono una intestazione per ogni colonna che serve ad identificare i valori in essa inseriti. Nell’esempio proposto le intestazioni sono “nominativo” e “telefono”. Tali etichette sono anche note come “nome del campo”. Una o più tabelle sono sufficienti per la definizione di un database.

Spesso si confonde un database, che è “semplicemente” l’organizzazione dei dati, con l’intera applicazione predisposta a gestire gli archivi e i loro contenuti. Tale applicazione è, più propriamente, denominata con il termine DBMS (Database Management System) ovvero sistema per la gestione di database. Per intenderci, per chi conosce l’applicativo Microsoft Access, Access stesso è un DBMS mentre i file da esso prodotti (tipicamente con estensione .mdb) sono i veri e propri database.

Incidentalmente riportiamo il nome di una figura professionale di grande importanza connessa con i DB (abbreviazione per database) e i DBMS: il DBA ovvero Database Administrator. Il DBA è colui che si occupa della gestione e manutenzione di un database e ovviamente conosce le modalità operative del DBMS. Da notare che i DBMS, anche se in determinati contesti posseggono caratteristiche organizzative e di manutenzione simili, possono essere anche molto diversi tra loro.

Sono oggi disponibili vari applicativi DBMS (Microsoft SQL Server, Oracle, MySQL, PostgreSQL, …) e in generale un DBA è costretto a specializzarsi su di uno specifico prodotto. Tuttavia, voglio sottolineare come i concetti teorici siano sempre gli stessi ed è proprio a questi che bisogna concedere i massimi sforzi di comprensione al fine di poter, in caso di necessità, “migrare” ad una nuova soluzione software con il minimo sforzo.

E’ intuitivo pensare che, come quasi ogni oggetto che conosciamo, anche i DB prevedono una fase preliminare di creazione (a noi informatici piace molto questo aspetto “divino”) e una successiva fase operativa, di vera e propria gestione nella quale, ad esempio, preleviamo e modifichiamo specifici dati presenti nel nostro archivio.

Per ognuna di queste due fasi distinte esistono uno specifico linguaggio adatto allo scopo: DDL, ovvero Data Definition Language, con il quale costruiamo il nostro database e DML, Data Manipulation Language, con il quale gestiamo il database.

Entità, Attributi e Chiavi

Uno dei passi chiave per modellare in maniera corretta in un archivio una certa realtà è di individuare con precisione gli oggetti caratterizzanti la realtà stessa. Pensiamo, ad esempio, di dover costruire un archivio per la gestione degli ordini per un certo negozio, piuttosto che l’elenco dei dipendenti di una data azienda per la gestione di stipendi e altro ad essi attinente. E’ evidente la necessità di individuare con precisione tali oggetti e le loro singole caratteristiche. Per la gestione degli ordini ci saranno sicuramente clienti e fornitori così come per la gestione degli stipendi individuiamo immediatamente almeno l’insieme dei dipendenti. Tali oggetti prendono il nome di entità.

Come detto queste entità hanno delle proprie caratteristiche. Nel caso dei fornitori si può pensare, a titolo di esempio, al loro numero telefonico (dovessimo contattarli per qualche reclamo), il loro recapito postale e così via. Tali caratteristiche prendono il nome di attributi. La scelta degli attributi rilevanti è un altro passo critico nella creazione di un modello efficiente della realtà che vogliamo “codificare”.

Tra tutti gli attributi di un certa entità è necessario individuarne uno (o in alcuni casi più di uno) che sia in grado di caratterizzare l’entità in modo da renderla distinguibile, senza ambiguità, dalle altre entità. Mi spiego meglio: è necessario individuare una caratteristica unica dell’entità stessa in modo che tramite questa caratteristica sia possibile riferirsi all’entità in oggetto in modo univoco. Esempio: il codice fiscale è una caratteristica che identifica in modo univoco una data persona nel senso che, banalmente, non possono esistere due persone diverse aventi lo stesso codice fiscale. Queste particolari caratteristiche prendono il nome di chiavi primarie. A tali speciali attributi ci si riferisce spesso anche con la sigla PK, acronimo appunto di Primary Key.

In linea del tutto generale, gli attributi posseggono le seguenti caratteristiche:

• formato
• dimensione
• opzionalità

Il formato specifica la tipologia dell’attributo. Ad esempio, se l’attributo è di tipo testuale, numerico, data-ora, ecc. In questo ambito mi sento di dover fare alcune precisazioni. Innanzitutto vi faccio notare che, sebbene determinati attributi abbiano una loro specifica natura, è sempre il progettista del database ad effettuare la scelta del tipo di formato.

Considerate, ad esempio, il caso di un numero telefonico. A prima vista si potrebbe pensare a tale attributo come avente un formato di tipo numerico. Ad una ulteriore analisi, un po’ più attenta, si potrebbe scoprire che se trattato in tale maniera sarebbe impossibile inserire numeri come il seguente: 0824/324343456. Ovvero, indicando nel numero il separatore “/” per la parte riguardante il prefisso. Infatti, tale separatore non è una cifra ed è quindi incompatibile con tale formato numerico.

Ma, sempre in relazione ai numeri telefonici, a volte questi sono espressi in una forma del tipo: +1-310-301-5800. Nello specifico questo è il numero dello IANA, l’organismo che ha responsabilità nell’assegnazione degli indirizzi IP nella rete Internet. Il simbolo + è il segnaposto per il codice per chiamate internazionali mentre il simbolo del trattino è un modo per rendere più leggibile il numero stesso. Vi renderete conto come un tale formato sia assolutamente incompatibile con quello di un normale numero che esprime delle quantità.

Vi faccio infine un ulteriore esempio: pensiamo al caso del CAP (il Codice di Avviamento Postale). Ebbene, anche in questa situazione si potrebbe effettivamente pensare ad un campo di formato numerico. Effettivamente la scelta potrebbe risultare opportuna in caso tale attributo sia riferito a CAP italiani. Tuttavia, se volessimo utilizzarlo per inserire CAP esteri in taluni casi, per quei codici che prevedono anche la presenza di lettere, tale scelta sarebbe assolutamente errata.

La dimensione di un attributo è un’altra caratteristica critica da valutare in fase di costruzione del nostro DB. Essa rappresenta, appunto, la dimensione da riservare per un dato attribuito.

Pensiamo, a titolo di esempio, all’attributo “cognome” nella definizione di una data entità “cliente”. In buona sostanza, dobbiamo decidere quanto potrà essere lungo al massimo un generico cognome, ovvero, quanti caratteri riservare per la sua memorizzazione. La prima cosa che potrebbe venirci in mente potrebbe essere quella di non voler correre rischi scegliendo così una dimensione sicuramente abbondante. Tuttavia, 255 caratteri, che in alcuni casi rappresenta la dimensione predefinita per i campi di tipo testuale, è sicuramente una scelta sproporzionata se riferita ad un cognome. Infatti, tale scelta, se da un lato ci consentirà di inserire cognomi di lunghezza qualsiasi, d’altra parte rappresenterà, in generale, un inutile spreco di spazio. Ma come dicevano i Latini “In medio stat virtus” ovvero “la virtù sta nel mezzo”. In altre parole è buona norma mediare tali situazioni scegliendo una dimensione che risulti comunque accettabile nei casi limite. A proposito di cognomi, ad esempio, può essere sorprendente scoprire quanto possa essere lungo un cognome di origine spagnola.

L’opzionalità si riferisce al fatto che un dato attributo possa avere o meno un certo valore. Più in generale, quindi, si considera la possibilità che un dato attributo possa avere un valore nullo. Pensiamo ad esempio all’attributo “codice fiscale”, oppure “data di nascita” di un certo individuo. Se la nostra progettazione prevedesse l’obbligatorietà di tali valori non sarebbe possibile inserire nessun dato relativo ad un certo individuo di cui non si conoscesse a priori la data di nascita.

Le precedenti, mi auguro semplici, considerazioni dovrebbero essere sufficienti per farvi intendere come la scelta di una serie di parametri sia a carico del progettista e di come tali scelte possano condizionare fortemente la struttura del nostro archivio di dati. Una buona e meditata progettazione renderà il nostro DB efficace ed efficiente consentendogli una certa flessibilità per eventuali future modifiche (si parla, in gergo tecnico, di scalabilità).

Associazioni e Relazioni

Di norma si è interessati non solo alle singole entità ma anche alle associazioni che esistono tra più entità. Un esempio servirà a chiarire meglio il concetto.

Se consideriamo l’archivio dei dipendenti è naturale immaginarsi un’associazione tra l’entità dipendente e l’entità stipendio. Tali associazioni prendono in generale anche il nome di relazioni. In tale contesto i termini associazione e relazione sono sinonimi.

Un aspetto di fondamentale importanza per quanto riguarda le relazioni tra entità è la loro classificazione. E’ possibile distinguere tre tipologie fondamentali:

• uno a uno (one – one)
• uno a molti (one – many )
• molti a molti (many – many)

Vediamole allora di seguito in dettaglio:

Relazione uno a uno

Tale forma di relazione è la più semplice e al contempo la più scarsamente utilizzata. Essa consiste sostanzialmente nel fatto che per ciascuna entità in entrambi gli insiemi esiste esclusivamente un altro termine associato nell’altro insieme.

Un esempio potrebbe essere rappresentato da una relazione tra docenti e corsi.

E’ ovvio, tuttavia, che l’assunzione che deve essere effettuata, per considerare la precedente come relazione uno ad uno, è che ogni docente possa tenere un solo corso e che un singolo corso sia tenuto da un solo docente. Come si po’ intuire, questo tipo di situazione non è di norma presente nella realtà a conferma della rarità di questa tipologia di relazione.

Relazione uno a molti

La relazione di tipo uno a molti è probabilmente la più comune. In sostanza per ogni elemento di un primo insieme esistono più elementi correlati nel secondo insieme; d’altra parte ad ogni elemento del secondo insieme può corrispondere al più un elemento del primo insieme. Un esempio classico e chiarificatore può essere quello relativo ai due insiemi, cliente e ordine, schematizzati in figura.

Un cliente può ovviamente effettuare vari e differenti ordini ma ogni singolo ordine corrisponde ad un unico cliente.

Relazione molti a molti

La relazione molti a molti prevede che ad ogni elemento di un primo insieme possano corrispondere più elementi di un secondo insieme e, viceversa, per ogni elemento del secondo insieme possono corrispondere più elementi del primo insieme.

Tale tipo di relazione, se non trattata in maniera corretta, può creare diversi problemi sia di ridondanza, ovvero inutile ripetizione, di dati che di gestione durante aggiunte ed eliminazioni di elementi.

Come esempio vi porto l’associazione, visibile in figura, tra docente e studente relativamente all’attività di insegnamento. La relazione è di tipo “molti a molti” in quanto un docente insegna a differenti studenti. Inoltre, ogni studente ha più docenti.

I modelli di dati

Nel corso degli anni si sono evoluti tutta una serie di differenti modalità di organizzazione dei dati noti con il termine generico di modelli di dati. Tra questi è utile innanzitutto ricordare, ma solo per un aspetto di tipo storico, il modello reticolare ed il modello gerarchico.

Tali modelli sono stati ad un certo punto completamente soppiantati da un nuovo sistema di organizzazione dei dati noto come modello relazionale. Per diversi anni il relazionale ha costituito il modello assoluto di riferimento  per la realizzazione di archivi di dati. Probabilmente, uno dei motivi dell’indiscusso successo di questo modello è stato il linguaggio che lo accompagna in maniera indissolubile noto come SQL (Structured Query Language) che vedremo nel prosieguo del nostro viaggio. Tuttavia, negli ultimi anni si è sviluppato un movimento che cerca di affiancare alle soluzioni proposte dal relazionale nuove metodologie di organizzazione dei dati motivate, tra le altre cose, dalla necessità di gestire mole di dati a dir poco enormi che oggi vengono veicolate, ad esempio, dai social network. Infatti, il modello relazionale, a causa di una serie di vincoli intrinseci mal si adatta a situazioni che prevedono la gestione di quantità di dati così grandi da essere definite cin uno specifico nome come big data. Questo movimento alternativo al relazionale prende il nome di NoSQL. Il riferimento al linguaggio SQL è dovuto, come si intuisce, al fatto che Structured Query Language è per certi apsetti considerabile quasi come se fosse un sinonimo di relazionale. Tuttavia il No si NoSQL non significa Non SQL ma più precisamente Not Only SQL, ovvero, non solo SQL a voler rimarcare il fatto che non si prevede una sostituzione assoluta del “vecchio” modello relazionale che rimane valido, se non l’unica alternativa, in diverse e differenti situazioni. Fondamentalmente, i modelli NoSQL possono essere divisi in quattro tipologie fondamentali. Una prima tipologia nota come modelli a grafo (Graph Database) e fondamentalmente altri tre  modelli identificati come basato su Documenti, di tipo chiave-valore ed orientati alle colonne. In realtà, questi ultime tre modelli hanno un approccio abbastanza simile tanto da essere individuati nella loro totalità dal termine Aggregate Oriented Database. Di seguito un piccolo schema riassuntivo con relativi esempi di DBMS reali che implementano lo specifico modello.

Tuttavia la precedente classificazione non è esaustiva. A solo titolo di esempio un ulteriore modello di dati è rappresentato da quello noto come Object-oriented o più semplicemente modello ad oggetti. La sua peculiarità consiste nel fatto che gli oggetti di cui è composto il database contengono sia i dati sia la logica operazionale (i metodi di gestione dei dati) così come avviene nei linguaggi di programmazione che seguono il paradigma ad oggetti come il C++ o Java.

Carlo A. Mazzone