Introduzione
Oggi, l’argomento più comune tra i manager di data warehouse è determinare quale schema è più orientato alla performance. Tuttavia, è fondamentale sapere che nessuno dei due approcci di normalizzazione o denormalizzazione può essere scartato, poiché entrambi hanno pro e contro.
Pertanto, prima di dettagliare le loro differenze attraverso i casi d’uso, diamo uno sguardo alla normalizzazione e alla denormalizzazione.
Normalizzazione
La normalizzazione è l’atto di riorganizzazione dei dati in un data warehouse per soddisfare due requisiti fondamentali:
- Rimuovere la ridondanza dei dati memorizzando tutti i dati rigorosamente in un unico posto
- Assicurare la dipendenza dei dati, cioè tutti gli elementi di dati corrispondenti sono conservati in un unico posto
.Cioè tutti i dati corrispondenti sono immagazzinati insieme
La normalizzazione è fondamentale per diverse ragioni, ma soprattutto perché permette ai data warehouse di occupare il minor spazio possibile su disco. Questo si traduce in un miglioramento delle prestazioni.
Denormalizzazione
Questa strategia di data warehousing è usata per migliorare la funzionalità di un’infrastruttura di database. La denormalizzazione richiama i dati ridondanti in un data warehouse normalizzato per minimizzare il tempo di esecuzione di specifiche query di database che uniscono i dati di molte tabelle in una sola.
In effetti, l’interpretazione della denormalizzazione dipende dalla normalizzazione, che è caratterizzata come l’atto di organizzare un database in tabelle rimuovendo le ripetizioni per implementare un determinato caso d’uso. Ricorda, un database denormalizzato non dovrebbe mai essere confuso con un database che non è mai stato normalizzato.
Normalizzazione e Denormalizzazione – Casi d’uso
Amazon DynamoDB
L’opzione di uno schema normalizzato o denormalizzato in un database NoSQL, come DynamoDB, dipende dal tuo caso d’uso. Tuttavia, i professionisti raccomandano di progettare le tabelle DynamoDB con uno schema denormalizzato per i seguenti due motivi:
- DynamoDB di Amazon è senza schema, e quando una tabella viene creata in questo database, è necessario specificare solo gli attributi della chiave primaria, come la chiave di ordinamento e la chiave di partizione, o solo la chiave di partizione. Inoltre, non è necessario definire altri attributi in anticipo.
- DynamoDB non approva le operazioni di join attraverso le tabelle.
Nonostante, ci sono alcune situazioni in cui è invece possibile utilizzare uno schema normalizzato.
Lo schema normalizzato può essere considerato quando:
- È necessario memorizzare elementi con dimensioni maggiori di 400 KB. Tuttavia, la dimensione massima degli elementi consentita in DynamoDB è di 400 KB. Pertanto, gli attributi più grandi possono essere memorizzati in Amazon S3 o su una singola tabella DynamoDB.
- Si prevedono vari modelli di accesso. Per esempio, prendete una tabella degli ordini dei prodotti, a cui si accede ogni volta che un cliente ordina un prodotto. Ora prendete una tabella di disponibilità dei prodotti, a cui si accede solo occasionalmente. Entrambe le tabelle hanno diversi prerequisiti di capacità di lettura & scrittura.
- Le vostre applicazioni eseguono diversi aggiornamenti. In Amazon DynamoDB, una WCU (unità di capacità di scrittura) è delineata come una scrittura/secondo, per un elemento di 1 KB di dimensione. Inoltre, numerose scritture di elementi di dati superiori a 1 KB influiranno sul numero di WCU esaurite per scrittura. Inoltre, anche se si sta aggiornando un solo attributo, il calcolo delle WCU dipende dalla dimensione dell’elemento completo.
Lo schema denormalizzato può essere considerato quando:
- Sono necessari piccoli elementi con pochi attributi da memorizzare. Inoltre, la dimensione dell’elemento non dovrebbe superare i 4 KB per la lettura. Ricordate, un RCU (unità di capacità di lettura) è specificato come una lettura/secondo per un elemento di dimensioni inferiori a 4 KB. In alternativa, per le scritture, la dimensione dell’elemento non dovrebbe superare 1 KB.
Le vostre applicazioni devono leggere e scrivere dati in un ambiente ad alto traffico, senza considerare la sincronizzazione e la coerenza dei dati su varie tabelle.
Caso d’uso della normalizzazione nell’Healthcare Data Warehousing
Oggi la normalizzazione dei dati ha un ruolo più ampio in una serie di impostazioni sanitarie, in quanto offre una struttura per interpretare i dati per facilitare diversi casi d’uso.
Per semplificare le cose, quella che segue è un’area comune che impiega la normalizzazione dei dati:
Rendere i dati utili all’interno del data warehouse
Un tipico data warehouse recupera i dati dei pazienti da una serie di sistemi informatici e clinici. Questo perché le organizzazioni vogliono centralizzare i loro progetti di reporting, i programmi di qualità, utilizzare i dati per progettare modelli predittivi e utilizzare i dati clinici e dei sinistri per supervisionare il processo di cura.
Quindi, quali sono le applicazioni dei dati normalizzati nella sanità?
Supponiamo che un ospedale abbia l’intenzione di stabilire un trend dei livelli di emoglobina A1C per un gruppo demografico di pazienti diabetici. Tuttavia, è comune per i sistemi di laboratorio mettere i loro codici di laboratorio proprietari personali che non sono standardizzati su LOINC. Il data warehouse dell’ospedale potrebbe possedere i risultati del laboratorio A codificati come 4321/Hgb A1c sangue. Nello stesso repository, l’ospedale potrebbe avere i risultati del LAB B già standardizzati come codice 17855-8 su LOINC.
Entrambi rappresentano i risultati di laboratorio A1C, ma i dati dovrebbero essere normalizzati a uno standard come LOINC affinché il sistema sanitario possa interpretare e analizzare correttamente entrambi i risultati di laboratorio.
Caso d’uso della normalizzazione
Considera una piattaforma di blogging dove si memorizzano i post e gli utenti. I post fanno riferimento ai loro autori attraverso un campo Author_ID. Dovreste memorizzare queste due entità in collezioni separate. Questo perché i post conterranno visualizzazioni, like, commenti e altre statistiche, e quindi, avranno bisogno di una maggiore capacità di scrittura rispetto agli utenti.
Ora, si dovrebbe forse registrare un feed dei post più recenti e il feed aggregherà direttamente gli autori in ogni post. Nel data warehousing, questo viene realizzato impostando Author_ID dei post come chiave esterna, seguito da una query su entrambe le tabelle degli utenti e dei post con una trasformazione Join per costruire il feed in tempo reale.
Tuttavia, questa opzione non è disponibile qui; invece, dovrete denormalizzare i vostri dati conservando il feed in un contenitore individuale che aspetta di essere interrogato. Questo contenitore porterà una copia dei dati memorizzati nei contenitori degli utenti e dei post, con gli autori consolidati nei post.
Conclusione
Lo schema che scegliete per il vostro data warehouse dipende principalmente dai modelli di accesso delle applicazioni e dalle dimensioni dei vostri dati. Potete consultare i nostri architetti di soluzioni per assicurare l’uso di tecniche di automazione avanzate quando normalizzate o denormalizzate il vostro data warehouse.
