Consumo energetico degli Edifici: Il database come strumento di raccolta strutturata dei dati

In informatica con i termini database, base di dati o banca dati, ci si riferisce tipicamente a quello che potremmo rappresentare come un archivio strutturato, ovvero un sistema che permette la memorizzazione, gestione ed accesso a dati precedentemente archiviati.
In informatica spesso tale termine si utilizza impropriamente come sinonimo di DBMS (database Management System), che sono in realtà dei software creati per la gestione delle basi di dati, e non le basi di dati stesse.
L’utilità dei database è correlata alla possibilità, che di fatto è spesso anche la motivazione per cui si fa ricorso ad essi, di correlare ai puri dati tutta una serie di informazioni aggiuntive inerenti le caratteristiche strutturali dei dati stessi e anche le relazioni che spesso intercorrono tra di loro.
Dal punto di vista operativo, possiamo riassumere una base di dati come un insieme di dati, raccolti in elementi principali detti record, a loro volta suddivisi in campi (di fatto l’elemento base).

Le basi di dati possono essere suddivise in diverse tipologie a seconda della loro organizzazione interna dei dati:

• Proto-database: si tratta della forma più semplice di organizzazione dei dati: essi vengono inseriti in un singolo file sotto forma di informazioni testuali separate da virgola, con il criterio di usare una singola riga per singolo record. I file vengono convenzionalmente codificati ed indicati con l’estensione .csv (Comma Separated Values) e sono in pratica dei semplici file di testo formattati rispettando delle specifiche regole. Per la loro facilità di gestione ed implementazione sono spesso utilizzati come formato di interscambio di informazioni, ed anche il sistema oggetto di questa tesi li utilizza come formato di importazione ed esportazione dati. La modalità tipica di rappresentazione di tali dati è la tabella bidimensionale costituita dallo schema logico righe-colonne.

• Database gerarchici: sono stati sviluppati dai precedenti, con una suddivisione del materiale tra più file, introducendo una relazione gerarchica tra gli stessi. Un esempio di implementazione di tale tipologia di database era IMS di IBM, ma attualmente non sono più utilizzati, nonostante sia stato di fatto il primo modello ad affermarsi sul mercato. Al suo interno le relazioni possono essere rappresentate solo con la tipologia 1:N (uno a molti), un esempio ancora oggi utilizzato è l’organizzazione dei file system, mentre come modello per basi di dati sono ormai superati. La modalità tipica di rappresentazione di tali strutture era il diagramma ad albero.

• Database reticolari: con questa tipologia si è cercato di superare il principale limite del modello gerarchico, ovvero la complessità della rappresentazione della relazione N:N (Molti a Molti), superandola con una rappresentazione che permettesse il raggiungimento di un nodo da percorsi differenti, reticolare appunto. Anche questa tipologia, con l’aumentare della complessità delle realtà che si intende rappresentare però entra in crisi e pertanto anche tale modello è stato abbandonato. La rappresentazione migliore di questo schema è quella di un grafo.

• Database distribuito: non è una vera e propria tipologia di database, quanto piuttosto un modello di localizzazione e stoccaggio dei dati, che non risultato fisicamente nel medesimo posto, ma suddivisi in più posizioni, anche distinte geograficamente, per facilitare l’accesso e la consultazione, oltre che per preservare l’integrità del sistema in caso di guasti ad uno o più nodi. Un esempio tipico di tale sistema sono i server DNS che sovraintendono alla risoluzione dei nomi nel mondo internet. Non ha una modalità di rappresentazione specifica.

• Database relazionale: è di fatto la tipologia con cui sono realizzati la quasi totalità dei database esistenti: si basa sulla possibilità di memorizzare i dati in diversi file correlando i record tramite appositi campi chiave, attraverso i quali è possibile ottenere comunque tutte le informazioni ricavandole da tutte le tabelle in cui sono memorizzate tramite interrogazioni (query) al database che sfruttano le relazioni di correlazione tra i dati per ottenere i risultati voluti. L’elemento distintivo rispetto al modello reticolare, da cui deriva, è il suo livello di astrazione, che permette di scollegare la rappresentazione logica delle informazioni dalla modalità di memorizzazione delle informazioni stesse, introducendo quindi un livello di flessibilità e un livello di prestazioni nella ricerca dei dati che i modelli precedenti non erano in grado di garantire.

• Database ad oggetti: nasce per superare alcuni limiti ancora presenti nei database relazionali, quali la gestione di alcune particolari tipologie di dati, indicate con il termine BLOB (Binary Large OBject), quali i file multimediali e le immagini. Infatti, i normali database sono progettati per gestire dati di ridotte dimensioni (tipicamente pochi KB, essendo i tipi di dati essenzialmente numerici e testuali), a differenza delle basi ad oggetti, che sono tipicamente ottimizzate per una particolare tipologia di dato: immagini, video, audio, GIS, ecc…

Quando si decide di utilizzare un database per la gestione di informazioni, la prima cosa da individuare sono quindi le entità, ovvero gli “oggetti” che costituiscono gli elementi fondamentali dell’organizzazione delle informazioni. Ogni entità sarà caratterizzata da proprietà, dette attributi (operativamente, campi).
A meno di particolari esigenze, come memorizzazione di grosse moli di dati, la tipologia normalmente scelta è quella relazionale, ed anche per la base di dati oggetto di questa tesi ci si è basati su tale modello.
La presenza all’interno dell’applicativo web realizzato nel corso di questa tesi di un repository documentale, che comporta di dover considerare come requisito del database la possibilità di gestire la memorizzazione di grosse moli di dati, e quindi la necessità teorica di dover ricorrere ad una tipologia di base di dati ad oggetti è stata risolta inserendo nella base di dati non il file stesso, ma solo alcuni dei suoi riferimenti fisici, quali la dimensione, la tipologia di file ed il nome, associati al riferimento sulla sua collocazione effettiva nel file system (il path).
In tale modo si è potuto realizzare il sistema utilizzando software di più ampia diffusione e su cui le competenze sono più facilmente reperibili sul mercato, nel caso di future implementazioni.

Questo ha permesso inoltre di mantenere le dimensioni teoriche del database a valori molto contenuti, in quanto il path, ovverosia l’attributo di localizzazione sul file system del documento stesso è una campo di tipo testuale con una lunghezza massima, derivante dalle limitazioni implicite dei file system di tipo ISO, pari a 255 caratteri, limite che comunque sarebbe superabile sui sistemi Unix, che accettano di default lunghezze di path fino a 4096 caratteri, ulteriormente incrementabile.
Da rapidi calcoli, infatti, l’occupazione massima teorica di un campo testuale in cui memorizzare il path sarebbe limitata a 255 Byte per record, tale valore comporterebbe una dimensione della base di dati di circa 250 Mbyte per ogni milione di documenti memorizzati, per quanto riguarda l’apporto derivante dalla memorizzazione dei dati di localizzazione del documento stesso, a fronte di un occupazione teorica, stimando una dimensione media di 1 MB, comunque molto ridotta se pensiamo ai file CAD o ai rilievi fotografici e video possibili, che facilmente arriverà, come occupazione di spazio disco, all’ordine di grandezza del TeraByte, ovvero delle migliaia di gigabyte, con un rapporto di oltre 1:4000. Si può quindi constatare, anche da questo rapido calcolo, come il principale problema di scalabilità dell’applicazione realizzata non risieda assolutamente nella modellizzazione della base di dati o nelle caratteristiche del DBMS scelto per la sua gestione, ma unicamente dalla complessità di memorizzazione in termini di spazio disco e garanzia di adeguate procedure di salvataggio dati e ripristino in caso di malfunzionamenti.

Tali problematiche sono però attualmente di più facile risoluzione basandosi su soluzioni di archiviazione basate su file system rispetto a soluzioni basate su memorizzazioni database.
Inoltre, la soluzione di utilizzare il database come archivio delle informazioni principali dei file depositati nel sistema, ha permesso di realizzare un efficace motore di ricerca interno a tale raccolta di dati, come d’altronde all’interno dei dati presenti nelle data collection con buone prestazioni complessive, senza dover ricorrere a strumenti di parsing ed analisi dei documenti stessi, a fronte della limitazione di non poter effettuare ricerche di tipo full text sul contenuto interno dei file.
Tale limitazione, però, vista la natura stessa della maggior parte dei file, ovvero contenuti multimediali (immagini, schizzi e rilievi fotografico e/o termografici) e disegni CAD non è parsa rilevante, ai fini dell’utilizzazione dello strumento, prevedendo comunque la possibilità da parte degli utenti di immettere alcune note descrittive a corredo del file stesso, su cui invece la ricerca è pienamente operativa.