Tempo fa mi è capitato di leggere dal Web una notizia davvero eccitante: un top manager proclamava [1]: “Se la cosa più importante che offrite sono i dati vi troverete in difficoltà. (….) In verità il valore reale risiede negli algoritmi: sono loro che definiscono le azioni “
Ma che novità! Pensate, sembra suggerire che nessuno, neanche gli informatici e in particolare le persone che si occupano di database, si sia mai reso conto che “solo i dati” non sono sufficienti e che sono gli algoritmi a dettare come elaborarli? Beh, meno male che finalmente siamo stati informati!
In verità, invece, questo è stato sempre l’obiettivo generale della comunità di ricerca sulla Basi di Dati: trovare il modo migliore di memorizzare ed elaborare i dati in maniera efficiente, rappresentandoli nel modo “più vicino possibile” a quel che costituisce informazione per l’essere umano. Basta vedere [2] e l’enorme quantità di articoli tecnici e divulgativi che sono stati scritti fino ad oggi.
Nel fermento suscitato dal fenomeno dei Big Data si parla tanto delle “quattro V”, i quattro principali problemi da affrontare: Volume: non solo ogni sorgente dati contiene una grande quantità di dati, ma anche il numero stesso delle sorgenti di dati è dell’ordine dei milioni. Velocità: come diretta conseguenza della velocità con la quale i dati sono raccolti e continuamente messi a disposizione, molte delle fonti di dati sono molto dinamiche, sia nel senso che ne vengono fuori sempre di nuove, sia rispetto alla loro velocità di aggiornamento. Varietà: le sorgenti di dati (anche nello stesso dominio applicativo) sono molto eterogenee sia a livello di schema, per quanto riguarda la struttura dei loro dati, sia a livello di istanza, per quanto riguarda come descrivono la stessa entità del mondo reale. Veracità: le sorgenti di dati sono di qualità molto diverse, con significative differenze in quanto a copertura, accuratezza e tempestività dei dati forniti. In inglese la saggezza si chiama Wisdom. Ecco perché propongo, oltre alle classiche Quattro V, di prendere in considerazione un’altra V, stavolta doppia, per “saggezza”: non solo vogliamo dare un senso dei dati, siano essi grandi o no, ma dovremmo avere la possibilità di estrarre da loro una conoscenza che ci renda più sapienti, più saggi, raddoppiandone il Valore. Per fare ciò, l’approccio all’analisi dei dati che è stato “venduto” fino a oggi non è affatto sufficiente.
Il blog [3] recita
“Qual è la differenza tra Business Analytics e Business Intelligence (BI)? La risposta corretta è: ognuno ha un parere e nessuno lo sa, e non dobbiamo preoccuparcene”
Una risposta più misurata potrebbe essere che “Business Intelligence” è un termine ampiamente abusato, spesso adottato per indicare attività molto semplicistiche per trarre conoscenza dai dati, ma che in realtà questa attività dovrebbe coinvolgere qualcosa di più dell’analisi, cioè un mix delle due attività di induzione e deduzione che in ultima analisi sono i fondamenti del ragionamento umano e costituiscono da sempre la duplice base dell’Intelligenza Artificiale. Così la mia prima tesi è: derivare saggezza dai dati significa impegnarsi in una ricerca che mantiene la mente aperta a entrambe le attività. Il collega Oren Etzioni ha detto [4]: “per migliorare in maniera veramente significativa la precisione delle predizioni sono necessari, insieme, conoscenza di base, ragionamento deduttivo, e modelli semantici più sofisticati “.
Si noti che i cosiddetti Database Induttivi [5], e la Programmazione Logica Induttiva, o Inductive Logic Programming (ILP) [6,7], perseguono la formalizzazione di questa idea sin dagli anni ’90. I Database Induttivi integrano i dati con i risultati del data mining, in modo tale che i modelli individuati diventino quel che si dice “cittadini di prima classe” e possano quindi essere manipolati insieme con i dati stessi; ILP invece integra l’apprendimento induttivo con la Programmazione Logica, con l’obiettivo di costruire teorie logiche a partire da esempi positivi e negativi e quindi di acquisire nuova conoscenza “basata sull’esperienza”.
Oggi la comunità di ricerca delle Basi di Dati può dare un contributo molto prezioso: i dati disponibili per indurre conoscenza sono così abbondanti che – a condizione che le fonti e le tecniche di estrazione siano affidabili – la conoscenza ottenuta può essere basata su una grande “quantità di prove”. Per questo motivo, siamo chiamati a ideare i mezzi di calcolo e di memorizzazione opportuni affinché queste tecniche ambiziose possano essere applicate, in modo affidabile, alla grande quantità di informazioni a disposizione oggi, quantità che rende diversa la situazione attuale da quella di alcuni anni fa.
Il secondo (ma non meno importante) punto che vorrei sollevare è legato alla fruibilità da parte degli utenti finali. Già nel 2007, nella sua relazione invitata al SIGMOD (una delle due conferenze sulle Basi di Dati più importanti del mondo) [8], il ricercatore Jag Jagadish ha sottolineato le carenze dei sistemi di Basi di Dati dal punto di vista dell’usabilità, non solo per un utente finale, ma talvolta anche per un programmatore esperto. Jagadish ha suggerito soluzioni a problemi come il fatto che l’utente non conosca bene il linguaggio di interrogazione oppure lo schema del database, o non sappia in base a quali valori dei dati formulare l’interrogazione, o non conosca la provenienza dei dati, o debba affrontare schemi molto complessi.
Ulteriori aspetti riguardano la necessità di fornire agli utenti spiegazioni sui risultati ottenuti, o supportarli nella comprensione dei risultati intermedi, o la possibilità di modificare la struttura dei dati durante la vita del database. Io credo che gli utenti che si accingono a prendere decisioni dovrebbero essere aiutati allo stesso modo, mettendo loro direttamente a disposizione tecniche e strumenti nuovi che permettano di affrontare la sfida posta dall’abbondanza, spesso l’eccesso, di informazioni.
Come ricercatrice sono sempre stata affascinata da questi problemi: dopo i miei primi lavori di ricerca sui database deduttivi, molti dei metodi e dei sistemi proposti dal mio gruppo di ricerca adottano insieme tecniche di induzione e deduzione per supportare gli utenti, e in particolare gli utenti finali, nell’accedere con facilità ai dati e dar loro un senso. Ad esempio, negli ultimi dieci anni il mio gruppo ha lavorato su sistemi che affrontano il problema del sovraccarico informativo [9] proponendo un modello e una metodologia per progettare database sensibili al contesto: mediante la context-awareness, a ogni utente si forniscono, in ogni situazione (contesto) d’uso, le informazioni più appropriate, evitando quindi di disorientarlo con troppi dati allo stesso tempo. Nei primi anni di questa ricerca avevamo adottato un approccio “topdown”, completamente basato sul fatto che il designer potesse immaginare “a priori” quali informazioni fossero utili a ciascun utente in ogni contesto considerato (la cosiddetta vista contestuale); recentemente invece lavoriamo a un approccio che induce le informazioni relative a ciascun contesto a partire dai dati stessi: analizziamo i dati precedentemente scelti dall’utente quando si trovava in un determinato contesto, e li associamo a quel contesto magari anche ordinati in base alla preferenza.
L’informazione estratta viene poi ulteriormente manipolata per produrre la definizione dei dati contestuale espressa sinteticamente, in maniera “intensionale”, come una view, in modo che quando lo stesso contesto si incontra nuovamente si possa tener conto di eventuali aggiornamenti del database. Inoltre, per associare dei dati anche ai contesti nei quali l’utente non si è ancora trovato si usano delle tecniche deduttive. In questa ricerca si trovano quindi entrambi gli aspetti di cui si parlava in precedenza: da una parte l’associazione del ragionamento induttivo a quello deduttivo, e dall’altra l’obiettivo di facilitare l’utente finale. Di recente sono stata attratta dalla ricchezza delle sfide poste dalla cosiddetta“Database Exploration” [10, 11], un paradigma che prende forme diverse, tra cui la più correlata all’analisi dei dati è quella motivata dalla visione dell’ ”Exploratory Computing (EC)” [12]. In EC, le due discipline Basi di Dati e Human-Computer Interaction (HCI) concorrono insieme alla produzione di sistemi che supportano in modo adeguato gli utenti finali nel prendere decisioni, indagare e cercare ispirazione, confrontare i dati, verificare un’ipotesi di ricerca, o semplicemente cercare e leggere documenti per imparare qualcosa di nuovo. Oggi, in entrambe le aree di ricerca esistono sistemi che si prefiggono simili scopi: in HCI l’approccio più simile a questo è la cosiddetta “faceted search”, una strategia per l’accesso a dataset sulla base di un sistema di classificazione [13]: i dati sono classificati in base a una serie di “sfaccettature” (facet), o punti di vista (grosso modo corrispondenti agli attributi in una base di dati), eventualmente organizzati in gerarchie, che permettono all’utente di esaminare i dati da molteplici punti di vista fornendone visualizzazioni e descrizioni sintetiche. La faceted search è stata già realizzata in molti sistemi, ma in genere questi sistemi gestiscono quantità di dati relativamente piccole e adottano tecniche di analisi poco sofisticate per estrarre le informazioni sintetiche. Estendere il paradigma verso la gestione efficiente di grandi quantità di dati, anche arricchendo le possibilità di esplorazione, sembra molto promettente, soprattutto per la possibilità di guidare gli utenti verso la comprensione mediante una specie di conversazione con il sistema, che presenti loro i dati da diversi punti di vista.
D’altra parte, nella comunità di ricerca di BD la maggioranza dei sistemi di analisi è progettata per avere come utenti dei professionisti dell’informatica o degli statistici, i quali, oltre ad avere conoscenza del dominio di interesse, devono padroneggiare la matematica, la statistica e l’informatica. Inoltre normalmente l’analista si concentra su un metodo di analisi per volta, adottando una specifica tecnica statistica o di data mining per risolvere un problema dato, mentre l’esplorazione dovrebbe consentire di applicare, a ogni step della conversazione col sistema, le tecniche più appropriate per mostrare all’utente gli aspetti rilevanti del dataset a disposizione.
L’obiettivo dell’Exploratory Computing è assistere soprattutto gli utenti occasionali, eventualmente inesperti, i cosiddetti “data enthusiast” [14] che hanno bisogno del sostegno di un sofisticato sistema che li guidi nell’ispezione del dataset, magari a partire da una semplicissima interrogazione, ed eventualmente presenti loro suggerimenti lungo il cammino esplorativo. Il risultato è un percorso di ricognizione in cui, ad ogni passo, il sistema presenta all’utente dei fatti rilevanti e concisi sui dati, in modo che questi possa comprendere meglio e passare al prossimo passo di esplorazione. Consideriamo per esempio l’esplorazione di un dataset di dati medici.
Un fatto iniziale significativo potrebbe essere che il sistema rilevi, nel risultato di una semplice query iniziale Q1: “trovare i pazienti i cui test di funzionalità tiroidea sono alterati”, una particolare distribuzione dei valori di età. Questo è un fatto rilevante, che potrebbe permettere al ricercatore di individuare una qualche relazione tra l’età e i disturbi della tiroide. Questa prima informazione sintetica potrebbe suggerire all’utente un’altra domanda, ad esempio Q2 “trova tutti i pazienti i cui test di funzionalità tiroidea sono alterati e che hanno più di 60 anni”, per vedere se i pazienti di quel gruppo di età mostrano qualche caratteristica speciale.
Si noti quindi come sia di fondamentale importanza, in questo tipo di esplorazione, una qualche nozione di rilevanza: il compito principale del sistema è infatti richiamare l’attenzione dell’utente su differenze o somiglianze significative (o addirittura sorprendenti) tra i vari insiemi di dati che incontra lungo il suo percorso esplorativo. L’uso di sintesi statistiche, come abbiamo visto prima per le distribuzioni, può mettere in evidenza aspetti rilevanti a colpo d’occhio, permettendo di vedere i dati a un livello di astrazione superiore e decidere quindi di continuare con una o più ulteriori azioni. In effetti, una distribuzione può descrivere un insieme di dati in modo sintetico e approssimato, presentandone le proprietà invece che i dati stessi.
Il calcolo della distribuzione dei dati è solo uno dei tanti modi per valutare la rilevanza partendo da descrizioni concise: possiamo pensare anche ad altre misure, come l’entropia, che stabilisce il “livello di varietà” di un insieme di valori, o descrivere i dati mediante modelli come le regole di associazione [15], utilizzate per scoprire le relazioni tra i valori degli attributi, etc. Ad esempio, il sistema potrebbe scoprire che (i) “80% dei pazienti presenti nel risultato della query Q2, e provenienti dalla Lombardia, hanno vissuto in Valtellina tra la seconda guerra mondiale e gli anni sessanta”, e che (ii) “70% dei pazienti presenti nel risultato della query Q2 e provenienti dal Sud Italia vivono in località di mare “.
Allo stesso modo che nelle Basi di Dati Induttive, queste descrizioni succinte possono essere memorizzate per essere interrogate quando necessario, o calcolate al volo per ottenere risposte che sono veloci e concise, anche se potenzialmente parziali e approssimative. Naturalmente, il calcolo in tempo reale comporta la necessità di tecniche di elaborazione veloce, che costituisce una delle grandi sfide per i ricercatori di Database.
Un’altra caratteristica fondamentale per un sistema di database exploration è la capacità di fornire spiegazioni (explanation) [16], il cui scopo è sostanzialmente comprendere le ragioni dei risultati di una query. Immaginate che l’utente voglia capire “perché c’è una grande differenza tra i pazienti della Valtellina e quelli provenienti dal resto della Lombardia”: unendo l’insieme di dati originale con uno contenente i dati relativi alle regioni italiane, un sistema di explanation potrebbe scoprire che la Valtellina è molto povera di iodio (** ). L’utente capirà quindi che lo iodio è strettamente correlato ai disturbi della tiroide, ed eventualmente potrà chiedere un’altra spiegazione per vedere il motivo per cui tali disturbi si trovano anche nelle località di mare (regola di associazione (ii) estratta dal risultato di Q2). Le spiegazioni sono dunque un altro formidabile pilastro per supportare un utente che tenta di estrarre dai dati qualcosa che sia più simile alla “conoscenza” di una sequenza piatta di elementi. Anche per ottenere spiegazioni vengono impiegate insieme tecniche di tipo deduttivo e di tipo induttivo, come si diceva in precedenza.
In effetti, esistono infiniti modi e sfumature per combinare gli approcci induttivo e deduttivo e permettere agli utenti finali di arrivare a una maggiore coscienza del contenuto dei dataset (più “saggezza”). Pensiamo ad esempio al “cooperative queryanswering” [17], dove il sistema aiuta gli utenti a formulare le query in modo da ottenere risposte “più utili” dal database; o al “query relaxation” [18], in cui, quando una query restituisce una risposta vuota, il sistema suggerisce all’utente delle interrogazioni alternative, meno restrittive, che potrebbero fornire una risposta non vuota ma comunque interessante; o ancora al sistema Watson [19], sviluppato nel progetto DeepQA di IBM, che raccoglie e analizza le risorse del Web per rispondere a domande poste in linguaggio naturale.
In conclusione, avere costantemente in mente l’utente finale – o, se si vuole, l’appassionato di dati – ci aiuterà ad essere più vicini al modo di ragionare delle persone e quindi ad affinare gli strumenti che producono “Wisdom”. Tuttavia, mentre diverse delle sfide interessanti discusse sono in realtà comuni ad altre aree di ricerca, il vero salto di qualità deve essere compiuto dalla comunità dei Database, che in ultima analisi è quella chiamata a fornirne i tre principali pilastri: l’efficacia per gli utenti finali, i sistemi di storage efficienti e i sistemi di elaborazione di dati ad alte prestazioni.
(*) L’articolo è stato pubblicato in inglese nel Gennaio 2016 sul Blog del SIGMOD (Special Interest Group for the Management of Data — ACM) http://wp.sigmod.org/?cat=11
(**) In realtà, al giorno d’oggi la gente della Valtellina cucina utilizzando sale iodato.
Bibiografia
[1] https://www.laserfiche.com/simplicity/gartner-forget-big-data-the-future-isalgorithms/
[2] http://wp.sigmod.org/?cat=11
[3] http://timoelliott.com/blog/2011/03/business-analytics-vs-businessintelligence.html
[4] http://wp.sigmod.org/?p=1519
[5] Luc De Raedt: A Perspective on Inductive Databases. SIGKDD Explorations 4(2):69-77 (2002)
[6] Ehud Y. Shapiro: Inductive Inference of Theories from Facts. Computational Logic- Essays in Honor of Alan Robinson 1991: 199-254
[7] Stephen Muggleton, Luc De Raedt: Inductive Logic Programming: Theory and Methods. J. Log. Program. 19/20: 629-679 (1994)
[8] H.V. Jagadish, Adriane Chapman, Aaron Elkiss, Magesh Jayapandian, Yunyao Li, Arnab Nandi, and Cong Yu: Making Database Systems Usable. In SIGMOD, 2007.
[9] https://en.wikipedia.org/wiki/Information_overload
[10] Magdalini Eirinaki, Suju Abraham, Neoklis Polyzotis, Naushin Shaikh: QueRIE: Collaborative Database Exploration. IEEE Trans. Knowl. Data Eng. 26(7):1778-1790 (2014)
[11] M. Buoncristiano, G. Mecca, E. Quintarelli, M. Roveri, D. Santoro, and L. Tanca, “Database challenges for exploratory computing,” SIGMOD Record, vol. 44, no. 2, pp. 17–22, 2015. [Online]. Available:
[12] Paolo Paolini, Nicoletta Di Blas: Exploratory portals: The need for a new generation. DSAA 2014: 581-586
[13] D. Tunkelang. Faceted Search (Synthesis Lectures on Information Concepts, Retrieval, and Services). Morgan and Claypool Publishers, 2009.
[14] K. Morton, M. Balazinska, D. Grossman, and J. D. Mackinlay. Support the data enthusiast: Challenges for next-generation data-analysis systems. PVLDB, 7(6):453–456, 2014.
[15] Mirjana Mazuran, Elisa Quintarelli, Letizia Tanca: Data Mining for XML Query- Answering Support. TKDE 24(8): 1393-1407 (2012).
[16] A. Meliou, S. Roy, and D. Suciu. Causality and explanations in databases (tutorial). PVLDB,7(13):1715{1716, 2014, available at
[17] Chu, W.W., Chen, Q.: A structured approach for cooperative query answering. IEEE Transactions on Knowledge and Data Engineering 6(5), 738–749 (1994)
[18] Davide Mottin, Alice Marascu, Senjuti Basu Roy, Gautam Das, Themis Palpanas and Yannis Velegrakis: Query relaxation: A Probabilistic Optimization Framework for the Empty-Answer Problem, PVLDB 2013, Vol.6, No.14, available at http://www.vldb.org/pvldb/vol6/p1762-mottin.pdf
[19] https://www.youtube.com/watch?v=WIKM732oEek
