Cosa sono i database relazionali?
In questo periodo sentiamo spesso parlare di Big Data, ovvero della enorme quantità di dati di ogni tipo che provengono dall’utilizzo delle varie risorse che Internet mette a disposizione. Ma quando si tratta di gestire dati strutturati, come è in qualsiasi software gestionale, in pratica si utilizza un solo metodo: il database relazionale.
Cerchiamo di capirne i presupposti, e anche l’uso dei gestionali sarà un po’ più chiaro.
Prima dei computer e degli archivi elettronici i dati venivano conservati in archivi di vario tipo e ovviamente ogni operazione era fatta a mano:
I calcoli venivano eseguiti a mano o con calcolatrici meccaniche e le varie pratiche erano sbrigate da molti impiegati, che seguivano l’iter e le procedure stabilite.
Sistemi meccanografici
Un metodo che ancora non si basava sulla digitalizzazione dei dati ma che rese molto più snella la gestione delle informazioni è stato quello delle schede perforate, che in seguito sono state anche usate come primo metodo per l’input dei programmi e dei dati nei calcolatori dell’epoca,
Nasce il Data Base
Nel 1964 viene coniato il termine Data Base, ovvero dati in formato elettronico resi disponibili a più utenti contemporaneamente dai terminali dei mainframe o a volte anche di singole macchine dedicate. Il tutto occupava parecchio spazio.
Database flat e reticolari sono stati i primi modelli che hanno consentito una prima manipolazione elettronica dei dati, ma all’uso pratico avevano forti limitazioni sia di ordine logico che di velocità di accesso ai dati.
Nel 1969 Edgar F. Codd presenta un nuovo modello per gestire dati che chiama relazionale; si basa sul concetto di entità/relazioni e su diversi presupposti formali, di cui eviterò la spiegazione tecnica ma cercherò di darne una intuitiva.
La prima società a sfruttarlo commercialmente fu Oracle nel 1977, tuttora punto di riferimento del settore.
Il modello relazionale
In cosa consiste il modello relazionale? senza entrare nei dettagli teorici e formali, immaginiamo di avere due gruppi di dati: quelli relativi all’anagrafica, suddivisi in schede relative ad ogni singolo soggetto, e quelli relativi alle fatture; anche qui abbiamo una scheda per fattura; entrambi i gruppi sono scritti in due tabelle separate, molto simili a quello che siamo abituati a vedere in excel, in cui ogni riga è una scheda; queste due tabelle sono apparentemente indipendenti.
Ovviamente nella pratica ogni cliente può avere un numero qualsiasi di fatture a lui riferite:
Chi usa il database, oltre a generare i documenti, deve anche poter facilmente vedere le fatture relative ad ogni cliente, raggrupparle, da ogni fattura risalire alla scheda del cliente e così via. Deve esserci una relazione logica precisa fra le diverse schede.
Un codice univoco (Chiave Primaria), presente in CLIENTI, viene impostato nella scheda FATTURA (Chiave Secondaria) creando così una relazione logica con la scheda CLIENTI da cui viene originato; nel gergo dei database relazionali questo tipo di relazione viene detto uno a molti: per ogni cliente possono esistere molte fatture, mentre per ogni fattura esiste un solo cliente. E’ così possibile richiamare in ogni nuova fattura, tramite il codice del cliente, le informazioni necessarie andando a prelevarle dalla relativa scheda. Da CLIENTI posso vedere tutte le fatture che hanno il codice uguale a quello impostato.
Stesso discorso si può fare per le righe della fattura: una fattura può avere una o più righe, righe legate alla testata della fattura da un codice univoco. Nella riga possiamo anche avere un altro codice/chiave secondaria relativa al prodotto e così via.
Come abbiamo visto nel gergo tecnico si chiama Chiave Primaria, deve essere univoca, dato che è quella che distingue ogni scheda dalle altre. La Chiave Secondaria è quella che viene utilizzata sulle schede ad essa relazionate per far capire che, ad esempio, la fattura 501 è relativa al cliente ABC, così come anche la fattura 504 è sempre legata al cliente ABC grazie alla Chiave Secondaria, in questo caso 1, uguale in entrambe le fatture.
In pratica le relazioni fra le Chiavi Primarie e le Chiavi Secondarie delle varie tabelle (clienti, fatture, righe fattura etc) formano la struttura logica del database. Le Chiavi Primarie vengono generate sulla tabella di origine. Vengono impostate come Chiavi Secondarie su altre tabelle ogni qual volta la logica dei dati lo richiede. Ad esempio non avrebbe senso riportare come Chiave Secondaria quella della fattura in clienti, dato che la logica ci dice che non ne abbiamo solo una ma potrebbero essere molte.
Ovviamente in un gestionale le chiavi vengono gestite in modo trasparente rispetto alle procedure che l’utente utilizza per le varie funzioni a sua disposizione. Ad esempio quando si genera una nuova fattura la procedura del gestionale come prima cosa prende la chiave del soggetto in clienti e la imposta sulla scheda della fattura appena generata, poi vi trasferisce i vari dati necessari per compilare l’intestazione della fattura, il tutto senza che l’utilizzatore non debba fare nulla.
Il linguaggio originariamente ideato per lavorare sui dati strutturati in questi termini nasce come SQL nel 1974 nei laboratori dell’IBM, ed è di una certa complessità. Col tempo si è notevolmente evoluto e permette una vasta serie di operazioni sulle tabelle e relativi dati.
La fortuna di Filemaker in effetti è stata che l’utente del tutto ignaro di database relazionali, SQL etc era ed è in grado di strutturarsi database anche abbastanza complessi, mentre con altri strumenti è praticamente impossibile utilizzarli senza uno studio delle basi della programmazione SQL. Ad esempio le ricerche con SQL sono abbastanza macchinose, mentre con Filemaker anche quelle complesse si riescono a fare seguendo semplicemente la logica che ci guida, senza la necessità di formalizzarle in un ulteriore linguaggio.
Tornando a concetti di base, uno dei presupposti dei database ben strutturati è di non avere ridondanza: esempio banale è il numero di telefono. Se per qualche motivo i dati del cliente ABC sono, quando necessario, ripetuti in più punti del database, il numero di telefono quando viene modificato deve cambiare in tutti i punti in cui si visualizza, altrimenti lo avremo un po’ aggiornato e un po’ no. Per questo se il dato si trova una sola volta in una sola scheda, accessibile grazie alle relazioni logiche da qualsiasi altra tabella, questo rischio non si corre.
Nell’utilizzare un database relazionale occorre avere in mente che i dati presenti originariamente su una tabella possono essere utilizzati su altre tabelle in due modi. Riprendendo l’esempio del numero di telefono e dell’indirizzo è ovvio che il dato è scritto solo nella tabella di anagrafica ma può essere mostrato ogni qual volta ve ne sia bisogno quando si richiamano i dati di quel soggetto, in modo da essere sicuri che sia aggiornato. Se invece siamo in una fattura, i dati saranno invece riscritti in modo da storicizzarli: se il soggetto cambia indirizzo le vecchie fatture dovranno continuare a riportare quelli che erano presenti all’epoca della generazione della fattura.
In pratica con le chiavi primarie e secondarie è possibile creare una struttura logica che collega fra di loro i dati presenti in ogni tabella, anche se sono “distanti” fra di loro. Questo con i database flat e reticolari è impossibile, mentre con i big data occorrono programmi che utilizzano reti neurali, intelligenza artificiale e simili, quindi anche con esigenze di hardware non indifferenti. Il database relazionale può invece tranquillamente essere utilizzato anche su PC economici.
La teoria dei database relazionali impone l’applicazione di requisiti formali ben precisi, chiamati le 13 regole di Codd o forme normali, oltre ovviamente alla tecnica di programmazione vera e propria che dipende dagli strumenti usati, ma che come abbiamo detto non è il caso di affrontare in questa sede. Ovviamente chi progetta e realizza database li deve conoscere approfonditamente.
