In fin dei conti, i problemi di analisi sono riconducibili ai dati sottostanti. Record di clienti duplicati, cifre dei ricavi che non corrispondono nei vari report e dashboard che si contraddicono a vicenda non sono problemi di visualizzazione o di query, bensì problemi di schema; la normalizzazione dei dati è il modo in cui i team li risolvono alla fonte.

Di seguito, discuteremo di come funziona la normalizzazione dei dati, dell'aspetto di uno schema normalizzato nella pratica e del punto in cui i team di analisi e data warehouse riscontrano compromessi concreti.

In evidenza

• La normalizzazione dei dati struttura un database relazionale in modo che ogni informazione si trovi in un'unica posizione. Ciò elimina i valori duplicati e in conflitto.

• I team di analisi possono applicare la normalizzazione in una pipeline creando prima tabelle di entità core normalizzate e poi sovrapponendovi reportistica denormalizzata.

• Un moderno fornitore di servizi di pagamento è in grado di sincronizzare i dati dei pagamenti direttamente nel warehouse di un'attività. In tal modo, si fornisce agli schemi normalizzati una base di partenza completa e aggiornata da cui partire senza dover far passare dati finanziari sensibili attraverso connettori di terze parti.

Cos'è la normalizzazione dei dati?

La normalizzazione dei dati è la procedura di organizzazione di un database relazionale in modo che ogni informazione si trovi in un'unica posizione. Per farlo, si suddividono i dati in tabelle correlate e li si collega tramite chiavi anziché ripetere gli stessi valori tra le righe.

L'obiettivo è la coerenza. Con la crescita del volume dei dati, questa disciplina strutturale è ciò che separa un warehouse di cui ci si può fidare da uno che richiede un auditing costante.

Perché la normalizzazione dei dati è importante per la precisione e la governance dell'analisi?

I dati non normalizzati possono creare categorie di problemi che si accumulano man mano che il volume dei dati aumenta.

Ognuno dei seguenti punti costituisce un difetto strutturale nello schema stesso:

• Anomalie di aggiornamento: si verificano quando lo stesso dato appare in più righe. Se il nome di un piano di abbonamento è memorizzato direttamente in ogni riga della fattura, rinominare il piano significa aggiornare migliaia di record, e tralasciarne anche solo uno genera una discrepanza. In uno schema normalizzato, il nome del piano si trova in una tabella di piani, mentre la fattura contiene solo l'ID del piano, ovvero plan_id.

• Anomalie di inserimento: si verificano quando non è possibile registrare un elemento senza registrarne un altro non correlato. In una tabella piana che memorizza i dati del cliente e dell'ordine insieme, non è possibile aggiungere un nuovo cliente finché questo non effettua un ordine, il che significa che la tabella si rompe nel momento in cui il team di vendita inizia a caricare i potenziali clienti nel warehouse.

• Anomalie di eliminazione: si verificano quando l'eliminazione di un record specifico comporta la rimozione involontaria di dati importanti e non correlati. Se si elimina l'ultimo ordine per un cliente da una tabella piana, si perdono anche le sue informazioni di contatto, in quanto non disponevano di un alloggiamento indipendente.

Quali sono le principali forme normali?

Le forme normali sono una sequenza di regole sempre più rigorose su come strutturare i dati.

I team che utilizzano la normalizzazione dei dati devono comprendere le forme fino alla terza forma normale (3NF) compresa, al fine di prendere decisioni corrette in merito allo schema. Un database viene spesso definito "normalizzato" se soddisfa la 3NF.

• Prima forma normale (1NF): richiede che ogni colonna contenga valori atomici, ovvero niente elenchi, stringhe separate da virgole e array raggruppati in un unico campo. Una colonna di prodotti contenente "camicia, pantaloni, giacca" non supera la 1NF. Tre righe contenenti ciascuna product_id e product_name la superano.

• Seconda forma normale (2NF): si basa sulla 1NF, ma richiede che ogni colonna non chiave dipenda dall'intera chiave primaria e non solo da una sua parte. Se una tabella delle voci usa "(order_id, product_id)" come chiave, ma memorizza anche la città del cliente, la quale dipende solo da order_id, si tratta di una dipendenza parziale che costituisce una violazione della 2NF. La città del cliente deve invece essere inserita nella tabella degli ordini.

• Terza forma normale (3NF): elimina le dipendenze transitive, ovvero le colonne non chiave che dipendono da altre colonne non chiave anziché dalla chiave stessa. Se una tabella degli ordini memorizza sia zip_code sia city e la città è determinata dal CAP anziché dall'ordine, questi campi vanno inseriti in una tabella geografica separata.

• Forma normale di Boyce-Codd (BCNF): si tratta di una versione più rigorosa della 3NF che gestisce casi limite che coinvolgono la sovrapposizione di chiavi candidate. Per gli schemi di analisi, raggiungere la 3NF è sufficiente.

Come funziona nella pratica la normalizzazione dei dati?

Il modo più chiaro per vedere cosa fa effettivamente la normalizzazione è iniziare con una tabella difettosa e correggerla. Ecco un esempio di tabella degli ordini non normalizzata e una spiegazione di cosa le succede dopo la normalizzazione.

Tabella degli ordini non normalizzata

Ci sono tre problemi immediati in questa tabella. L'email di Ana appare due volte: se la aggiorni in una riga, crei un conflitto. Il nome e la categoria del prodotto si ripetono in ogni riga dell'ordine, quindi modificare una categoria significa toccare ogni ordine storico che la includeva. E non c'è modo di aggiungere un nuovo cliente o prodotto senza allegargli un ordine.

Dopo la normalizzazione, avresti tre tabelle:

• Clienti: customer_id, name, email
  
• Prodotti: product_id, name, category
  
• Ordini: order_id, customer_id, product_id, qty, unit_price
  

L'email di Ana si trova in un'unica posizione. La categoria delle cuffie si trova in un'unica posizione. Gli ordini fanno riferimento a entrambe tramite ID. Un'istruzione SELECT con doppio JOIN di tipo Structured Query Language (SQL) può combinare dati da più tabelle in base a condizioni comuni: un costo minimo e permanente per uno schema che non accumula errori quando viene scalato.

Quali sono i compromessi comuni della normalizzazione dei dati?

Nonostante i notevoli vantaggi, la normalizzazione può anche comportare costi reali per i team.

I compromessi riguardano tre aree:

• Complessità delle query: ogni relazione normalizzata in una tabella a sé stante rappresenta un join che dovrà essere scritto in seguito. Un report che prima poteva essere letto da un'unica tabella piana ora richiede tre join, e il carico cognitivo si accumula per un team di analisti che lavora direttamente in SQL.

• Impegno preventivo di modellazione: la progettazione di uno schema normalizzato richiede una comprensione del dominio tale da identificare le entità, i loro attributi e le relazioni tra di essi. I team con la pressione di dover consegnare i risultati spesso saltano questo passaggio per creare strutture piane che al momento sembrano più semplici, ma che poi si rivelano costose in seguito.

• Prestazioni di lettura: in tabelle molto grandi, i join sono più lenti delle scansioni. I moderni data warehouse (ad esempio, BigQuery, Snowflake, Redshift) dispongono di ottimizzatori di query che gestiscono ragionevolmente bene i join, ma le strutture denormalizzate spesso vincono in termini di pura velocità delle query per carichi di lavoro analitici su miliardi di righe.

Come applicano la normalizzazione dei dati i team di analisi e dei warehouse nei propri flussi di lavoro?

Nella pratica, i team di analisi suddividono la normalizzazione su una pipeline. I diversi livelli di struttura sono adibiti a scopi e questioni distinte: l'integrità dei dati viene gestita nel livello core normalizzato, mentre le prestazioni delle query e l'ergonomia per gli analisti vengono gestite a livello di reportistica.

Ecco in che modo avviene:

• Livello di staging: i dati non elaborati arrivano qui quasi così come sono dalla fonte. In questa fase si verificano trasformazioni scarse o nulle. L'obiettivo è solo quello di inserire i dati intatti e interrogabili nel warehouse, non di modellarli.

• Livello core normalizzato: gli strumenti di trasformazione producono tabelle delle entità normalizzate a partire dal livello di staging, una per i clienti, una per gli abbonamenti e una per le transazioni. Queste tabelle corrispondono all'incirca alla 3NF e fungono da origine attendibile per qualsiasi modello a valle.

• Livello di reportistica: in cima al core normalizzato, i team creano tabelle ampie e denormalizzate progettate per garantire velocità e facilità d'uso in uno strumento di business intelligence (BI) come Tableau o Looker. Un modello di dashboard dei ricavi potrebbe unire cinque tabelle normalizzate in un'ampia tabella dei fatti, che viene poi letta direttamente dallo strumento di BI.

Come Stripe supporta dati più puliti e affidabili per la normalizzazione a valle

La qualità di qualsiasi schema normalizzato dipende interamente dalla qualità e dalla completezza dei dati che lo alimentano. Record di transazione obsoleti o incompleti possono creare lacune di riconciliazione che nessuna progettazione attenta dello schema può risolvere.

Ecco cosa può offrire un fornitore di servizi di pagamento:

• Sincronizzazione: Stripe Data Pipeline sposta i dati Stripe (ad es. addebiti, clienti, abbonamenti, rimborsi, contestazioni, bonifici) direttamente in un data warehouse o in una destinazione di archiviazione cloud, senza connettori di terze parti intermedi o limiti di frequenza per l'interfaccia di programmazione delle applicazioni (API).

• Completezza: Stripe garantisce la completezza dei dati sincronizzando tutti i dati Stripe, i report finanziari predefiniti e i set di dati curati.

• Sicurezza: quando i team instradano i dati Stripe tramite connettori di estrazione, trasformazione e caricamento (ETL) di terze parti, inviano dati finanziari sensibili all'infrastruttura di un ulteriore fornitore. Data Pipeline gestisce il trasporto direttamente, il che rimuove questo intermediario ed elimina un fornitore dall'elenco di quelli da esaminare per la sicurezza dei dati.

Data Pipeline non sostituisce una piattaforma ETL completa. Se stai combinando i dati Stripe con i dati provenienti da una dozzina di altre fonti, hai comunque bisogno di strumenti di trasformazione. Tuttavia, questa soluzione è progettata specificamente per sincronizzare i tuoi dati Stripe meglio di un connettore di terze parti per garantire che i tuoi dati finanziari vengano sincronizzati in modo affidabile, sicuro e accurato.