Data management e analytics: come gestire i dati in modo efficace

I dati vengono raccolti e conservati, ma non sempre sono disponibili nel formato e nei tempi necessari per utilizzarli. Per un’azienda questo può rendere più difficile prendere decisioni, migliorare un servizio o individuare un problema prima che abbia conseguenze tangibili. Ecco perché il data management diventa fondamentale. Comprende infatti i processi e le tecnologie con cui un’azienda raccoglie, conserva, integra e rende disponibili le proprie informazioni.

In questa guida vediamo cos’è il data management, quale rapporto ha con la data analytics e come scegliere architetture e database in funzione del tipo di dati, dei volumi e dei tempi di risposta richiesti.

Cos’è il data management

Il data management è l’insieme di processi, regole e tecnologie con cui un’organizzazione gestisce i dati durante il loro ciclo di vita, con l’obiettivo di renderli affidabili e utilizzabili dalle persone e dalle applicazioni che ne hanno bisogno.

La gestione dei dati non riguarda quindi soltanto il luogo in cui vengono archiviati. Comprende diverse attività tra loro collegate:

• Raccolta: definire quali dati raccogliere e con quale struttura.
• Conservazione: scegliere le tecnologie più adatte per archiviarli e renderli disponibili.
• Integrazione: collegare le informazioni provenienti da sistemi diversi.
• Qualità: individuare duplicati, dati incompleti o informazioni non aggiornate.
• Accesso: stabilire chi può utilizzare i dati, attraverso quali strumenti e con quali tempi di risposta.

Queste attività determinano la differenza tra possedere le informazioni e riuscire a utilizzarle nel momento in cui servono. Un’azienda può raccogliere grandi quantità di dati senza avere necessariamente la possibilità di interrogarli in modo semplice e tempestivo.

Data analytics e data management: qual è il rapporto

La data analytics utilizza i dati per rispondere a domande di business, individuare tendenze e supportare le decisioni. Il data management crea invece le condizioni perché queste analisi possano essere eseguite su informazioni affidabili, aggiornate e accessibili. Se i dati sono distribuiti tra più sistemi, duplicati o aggiornati con frequenze diverse, anche gli strumenti di business intelligence e analytics possono produrre risultati incompleti o renderli disponibili troppo tardi.

Non tutte le analisi, inoltre, hanno gli stessi requisiti. Ad esempio, i report mensili sulle vendite o i confronti tra periodi si basano su dati consolidati in un data warehouse o in un data lake e aggiornati a intervalli regolari. Altri casi richiedono invece di utilizzare le informazioni mentre vengono prodotte. È quello che accade, quando bisogna individuare un pagamento sospetto prima che venga autorizzato, proporre un contenuto durante la navigazione di un cliente o monitorare in tempo reale il funzionamento di un impianto. Nel primo caso l’analisi avviene prevalentemente a posteriori. Nel secondo, tempi di accesso e architettura dei dati diventano parte integrante del servizio applicativo.

Data platform e data architecture

Per rendere disponibili i dati è necessario definire sia il modo in cui vengono organizzati sia le tecnologie che li gestiscono.

La data architecture descrive come i dati vengono generati, trasferiti, conservati e messi a disposizione. La data platform comprende invece gli strumenti utilizzati per realizzare questa architettura.

Una data architecture può essere osservata attraverso quattro elementi principali:

1. Le sorgenti, come applicazioni, gestionali, siti web, dispositivi connessi e servizi esterni.
2. I meccanismi di trasferimento, che possono comprendere caricamenti periodici, integrazioni tra applicazioni e flussi continui di eventi, abilitati da piattaforme basate su Apache Kafka.
3. I sistemi di conservazione, come i database operativi o gli archivi destinati all’analisi dello storico.
4. Le modalità di accesso, come API, query, strumenti di analytics e applicazioni basate sull’intelligenza artificiale.

Quando le informazioni devono essere trasferite tra sistemi nel momento stesso in cui vengono generate, è possibile utilizzare architetture di data streaming ed event-driven.

Un altro elemento centrale riguarda invece il sistema in cui i dati vengono conservati. La scelta del database dipende dalla loro struttura, dai volumi e dal modo in cui devono essere interrogati.

Database relazionale e NoSQL: come scegliere

I database relazionali organizzano le informazioni in tabelle con una struttura definita e relazioni espresse attraverso chiavi. Sono particolarmente adatti quando i dati hanno uno schema stabile e le transazioni devono garantire un elevato livello di consistenza, come nei sistemi contabili o nella gestione degli ordini.

I database NoSQL rispondono invece a esigenze differenti. Il termine comprende più modelli progettati per gestire dati con strutture variabili, grandi volumi distribuiti o interrogazioni in cui assumono particolare importanza le relazioni.

Tra i principali modelli rientrano:

• i database a documenti, adatti a informazioni con strutture variabili;
• i database distribuiti a colonne, utilizzati per gestire grandi volumi e carichi elevati;
• i database a grafi, progettati per interrogare le connessioni tra entità.

Dati con strutture variabili: MongoDB

MongoDB è un database NoSQL a documenti. Ogni record viene memorizzato come documento e può avere una struttura differente dagli altri, senza richiedere necessariamente la modifica dello schema dell’intero database. Questa caratteristica lo rende adatto a contesti in cui le informazioni cambiano frequentemente o non condividono sempre gli stessi attributi, come cataloghi, profili cliente, contenuti, log di sistema e dati provenienti da sensori.

MongoDB mette inoltre a disposizione funzionalità per la replica dei dati e la distribuzione del carico su più server, così da supportare esigenze di disponibilità e crescita dei volumi.

Sourcesense è partner di MongoDB. Nell’articolo dedicato a Codemotion e MongoDB Day 2025 puoi approfondire il rapporto tra piattaforme dati e applicazioni di intelligenza artificiale

Grandi volumi e disponibilità: Apache Cassandra e DataStax

Apache Cassandra è un database distribuito open source progettato per gestire grandi quantità di dati e mantenere il servizio disponibile anche in presenza di guasti.

I nodi possono gestire letture e scritture e i dati possono essere replicati tra più macchine e data center. La capacità del sistema può essere aumentata aggiungendo nuovi nodi, senza dover concentrare il carico su un singolo server.

DataStax mette a disposizione tecnologie basate sull’ecosistema Cassandra, tra cui soluzioni enterprise e servizi gestiti in cloud come Astra DB. Con IBM DataStax, Sourcesense lavora su architetture in cui disponibilità, distribuzione dei dati e gestione di carichi variabili rappresentano requisiti centrali.

MongoDB e DataStax rispondono quindi a esigenze differenti e possono anche convivere nella stessa architettura insieme ai database relazionali. La tecnologia viene scelta in funzione del singolo carico di lavoro, anziché applicare lo stesso modello a tutti i dati aziendali.

Analytics sui dati operativi

Il modello tradizionale di analytics prevede spesso che i dati vengano trasferiti periodicamente in un data warehouse, dove possono essere consolidati e analizzati. Questo approccio è quello più utilizzato per la reportistica e le analisi storiche.

In altri casi, però, la risposta deve arrivare mentre l’evento è ancora in corso. Un sistema antifrode deve poter valutare una transazione prima che venga completata; una piattaforma di e-commerce può utilizzare le informazioni sulla navigazione per proporre un contenuto durante la stessa sessione; un impianto può richiedere un intervento sulla base dei dati raccolti in quel momento.

In questi scenari, l’analisi può essere eseguita direttamente sui dati operativi, senza la necessità di trasferirli prima in un altro sistema. DataStax Enterprise integra funzionalità di ricerca e analisi sui dati gestiti da Cassandra. MongoDB permette invece di aggregare e interrogare nel database informazioni come log, dati provenienti da sensori e contenuti con strutture differenti.

Il data warehouse mantiene quindi il proprio ruolo per l’analisi dello storico, mentre i sistemi operativi possono supportare le elaborazioni che richiedono tempi di risposta più rapidi.

Dati connessi: graph database e knowledge graph

In alcune applicazioni, il valore dell’informazione dipende soprattutto dalle relazioni tra i dati.

Un graph database rappresenta le informazioni attraverso nodi e relazioni. I collegamenti vengono quindi memorizzati direttamente nel modello invece di essere ricostruiti a ogni interrogazione attraverso operazioni tra tabelle.

Un esempio può essere la ricerca dei fornitori che lavorano anche per determinate aziende concorrenti. In un database relazionale questa interrogazione può richiedere una successione di JOIN. In un database a grafi è invece possibile attraversare direttamente le relazioni tra le entità coinvolte. Neo4j è un database a grafi nativo che utilizza Cypher come linguaggio di query. AuraDB è la relativa versione gestita disponibile sui principali cloud provider.

I grafi possono essere utilizzati anche per costruire un knowledge graph, cioè una rappresentazione di entità e relazioni appartenenti a uno specifico dominio: clienti, prodotti, contratti, persone, sedi e altri elementi possono essere collegati in base al loro significato. Un esempio di utilizzo è descritto nell’articolo su knowledge graph e software intelligence, dove le relazioni presenti nel codice vengono utilizzate per fornire maggiore contesto a un sistema di AI.

Fraud detection e sistemi di raccomandazione

Fraud detection e sistemi di raccomandazione sono due applicazioni in cui l’analisi delle relazioni può assumere particolare importanza.

Nel primo caso una singola transazione può non presentare anomalie evidenti. Il rischio emerge però quando il conto, il dispositivo, l’indirizzo o altre entità risultano collegati a elementi già associati a comportamenti sospetti. Per intercettare queste dinamiche prima che l'operazione vada a buon fine, piattaforme di data streaming come Confluent consentono di raccogliere, archiviare ed elaborare i flussi informativi in tempo reale. Ciò permette di ricostruire il contesto relazionale all'istante e bloccare i comportamenti anomali sul nascere.

Nei sistemi di raccomandazione, invece, le connessioni tra utenti, prodotti e comportamenti possono essere utilizzate per individuare contenuti o articoli potenzialmente rilevanti per una persona sulla base di interazioni simili.

Dati e intelligenza artificiale: vector search e GraphRAG

Le applicazioni basate su modelli linguistici possono utilizzare informazioni aziendali esterne al modello attraverso tecniche di retrieval-augmented generation, o RAG. In questo approccio, il sistema recupera i contenuti rilevanti da una fonte dati e li fornisce al modello come contesto per generare la risposta. La vector search permette di cercare contenuti sulla base della loro similarità semantica. Testi, immagini o altri elementi vengono rappresentati attraverso vettori numerici, così che una ricerca possa individuare concetti correlati anche quando non vengono utilizzate le stesse parole.

Abbiamo approfondito il funzionamento di questo modello nell’articolo dedicato ai database vettoriali.

MongoDB, DataStax e Neo4j integrano funzionalità di ricerca vettoriale accanto agli altri modelli di gestione dei dati. Questo permette, in diversi scenari, di utilizzare le informazioni già presenti nella piattaforma senza introdurre necessariamente un archivio separato da mantenere sincronizzato.

Quando oltre alla similarità semantica assumono importanza anche le relazioni tra entità, è possibile utilizzare approcci di GraphRAG. Il recupero delle informazioni può così includere anche il contesto rappresentato nel grafo, come il rapporto tra un cliente e i suoi contratti o tra un prodotto e le sue alternative.

RAG e GraphRAG rientrano nelle tecnologie che possono collegare le applicazioni di intelligenza artificiale al patrimonio informativo dell’organizzazione.

Data governance: responsabilità, qualità e accesso

Accanto all’architettura tecnica è necessario stabilire le regole con cui i dati vengono gestiti.

La data governance comprende ruoli, processi e controlli utilizzati per definire chi è responsabile delle informazioni, quali livelli di qualità e sicurezza devono essere rispettati e quali persone o applicazioni possono accedervi. Nella pratica può comprendere, per esempio, l’assegnazione di responsabilità sui diversi domini informativi, controlli automatici sulla qualità e meccanismi che permettono di ricostruire la provenienza di un dato.

A questi aspetti si aggiunge quello della sovranità dei dati, che riguarda il luogo fisico in cui le informazioni vengono conservate e le regole a cui sono soggette.

Le tecnologie descritte finora possono essere utilizzate nei data center dell’organizzazione oppure attraverso servizi gestiti sui principali cloud. La scelta dipende dai requisiti dell’architettura, dalla governance e dai vincoli applicabili ai dati.

Abbiamo approfondito il tema nell’articolo dedicato alla governance dei dati negli ecosistemi cloud.

Da dove cominciare con il data management

Un progetto di data management può partire da un problema circoscritto e misurabile, anziché dalla scelta preventiva di una tecnologia.

Un primo step può articolarsi in tre passaggi che prevedono di

1. Individuare una domanda specifica, come, ad esempio, quali clienti hanno ridotto gli ordini dopo avere aperto un reclamo o identificare un evento che oggi viene rilevato troppo tardi.
2. Analizzare i dati necessari, verificare quindi dove si trovano, quale volume hanno, con quale frequenza cambiano e in quanto tempo deve essere disponibile la risposta.
3. Definire un primo perimetro, prendendo in considerazione un numero limitato di sistemi per verificare l’architettura e misurare i risultati prima di estendere il modello ad altri casi.

I dati raccolti in questa fase permettono di valutare con maggiore precisione quali database, integrazioni e modalità di accesso siano più adatti al contesto.

Per individuare il caso d’uso da cui partire e valutare l’architettura più adatta contattaci.

Domande frequenti sul data management

Che differenza c’è tra data management e data analytics?

Il data management riguarda i processi con cui i dati vengono raccolti, conservati, integrati e resi accessibili. La data analytics utilizza invece queste informazioni per rispondere a domande di business, individuare tendenze e supportare le decisioni. I due ambiti sono strettamente collegati: la qualità e la disponibilità dei dati condizionano direttamente la qualità delle analisi.

Quando conviene utilizzare un database NoSQL invece di uno relazionale?

Un database NoSQL può essere adatto quando i dati hanno una struttura che cambia frequentemente, quando devono essere distribuiti su più nodi o quando le interrogazioni dipendono soprattutto dalle relazioni tra le informazioni. I database relazionali continuano invece a essere indicati per molti sistemi caratterizzati da strutture stabili e requisiti transazionali rigorosi.

Serve un database diverso per ogni tipo di dato?

Non necessariamente. La scelta dipende soprattutto dai diversi carichi di lavoro. Nella stessa architettura possono convivere, per esempio, un database relazionale per le transazioni, un database a documenti per dati con strutture variabili e un database a grafo per applicazioni basate sulle relazioni. L’obiettivo è utilizzare ciascuna tecnologia dove offre un vantaggio tangibile, mantenendo allo stesso tempo l’architettura integrabile e governabile.

In che modo il data streaming e piattaforme basate su Apache Kafka supportano il Data Management?

Le piattaforme di data streaming basate su Apache Kafka applicano regole di governance direttamente ai flussi di dati in movimento tramite strumenti come lo Schema Registry. Questo garantisce che ogni evento rispetti una struttura predefinita prima ancora di raggiungere i database o gli strumenti di analytics, prevenendo errori a valle e assicurando tracciabilità (data lineage) e qualità costante lungo tutta l'architettura.