Modellazione del data vault

Modello semplice di data vault con due hub (blu), un link (verde) e quattro satelliti (giallo)

Il data vault cerca di risolvere il problema di gestire i cambiamenti nell’ambiente separando le chiavi aziendali (che non mutano così spesso, perché identificano univocamente un’entità aziendale) e le associazioni tra queste chiavi aziendali, dagli attributi descrittivi di queste chiavi.

Le chiavi aziendali e le loro associazioni sono attributi strutturali, che formano lo scheletro del modello di dati. Il metodo del data vault ha come uno dei suoi assiomi principali che le chiavi aziendali reali cambiano solo quando il business cambia e sono quindi gli elementi più stabili da cui derivare la struttura di un database storico. Se si utilizzano queste chiavi come spina dorsale di un data warehouse, è possibile organizzare il resto dei dati intorno ad esse. Ciò significa che la scelta delle chiavi corrette per gli hub è di primaria importanza per la stabilità del tuo modello. Le chiavi sono memorizzate in tabelle con alcuni vincoli sulla struttura. Queste tabelle-chiave sono chiamate hub.

HubsEdit

Hubs contengono una lista di chiavi commerciali uniche con bassa propensione al cambiamento. Gli hub contengono anche una chiave surrogata per ogni elemento Hub e metadati che descrivono l’origine della chiave aziendale. Gli attributi descrittivi per le informazioni sull’Hub (come la descrizione della chiave, possibilmente in più lingue) sono memorizzati in strutture chiamate tabelle Satellite che saranno discusse più avanti.

L’Hub contiene almeno i seguenti campi:

• una chiave surrogata, usata per collegare le altre strutture a questa tabella.
• una business key, il driver per questo hub. La business key può essere composta da più campi.
• la fonte del record, che può essere usata per vedere quale sistema ha caricato per primo ogni business key.
• opzionalmente, si possono anche avere campi di metadati con informazioni sugli aggiornamenti manuali (utente/tempo) e la data di estrazione.

Un hub non può contenere chiavi commerciali multiple, eccetto quando due sistemi forniscono la stessa chiave commerciale ma con collisioni che hanno significati diversi.

Gli hub dovrebbero normalmente avere almeno un satellite.

Esempio di hubModifica

Questo è un esempio per un hub-table contenente auto, chiamato “Car” (H_CAR). La chiave di guida è il numero di identificazione del veicolo.

LinksEdit

Le associazioni o le transazioni tra chiavi aziendali (che mettono in relazione per esempio gli hub per il cliente e il prodotto tra loro attraverso la transazione di acquisto) sono modellate usando tabelle di collegamento. Queste tabelle sono fondamentalmente tabelle di unione molti-a-molti, con alcuni metadati.

I collegamenti possono collegarsi ad altri collegamenti, per gestire i cambiamenti di granularità (per esempio, l’aggiunta di una nuova chiave a una tabella di database cambierebbe la grana della tabella di database). Per esempio, se avete un’associazione tra il cliente e l’indirizzo, potreste aggiungere un riferimento a un collegamento tra gli hub per il prodotto e la società di trasporto. Questo potrebbe essere un collegamento chiamato “Consegna”. Fare riferimento a un link in un altro link è considerata una cattiva pratica, perché introduce dipendenze tra i link che rendono più difficile il caricamento parallelo. Poiché un collegamento ad un altro collegamento è lo stesso di un nuovo collegamento con gli hub dell’altro collegamento, in questi casi creare i collegamenti senza referenziare altri collegamenti è la soluzione preferita (vedere la sezione sulle pratiche di caricamento per maggiori informazioni).

I collegamenti a volte collegano gli hub ad informazioni che non sono di per sé sufficienti per costruire un hub. Questo accade quando una delle chiavi commerciali associate dal link non è una vera chiave commerciale. Come esempio, prendiamo un modulo d’ordine con “numero d’ordine” come chiave, e linee d’ordine che sono codificate con un numero semi-casuale per renderle uniche. Diciamo “numero unico”. Quest’ultima chiave non è una vera chiave aziendale, quindi non è un hub. Tuttavia, abbiamo bisogno di usarla per garantire la corretta granularità del collegamento. In questo caso, non usiamo un hub con chiave surrogata, ma aggiungiamo la chiave aziendale “numero unico” stessa al collegamento. Questo viene fatto solo quando non c’è la possibilità di usare la business key per un altro link o come chiave per gli attributi in un satellite. Questo costrutto è stato chiamato “peg-legged link” da Dan Linstedt sul suo forum (ora defunto).

I link contengono le chiavi surrogate per gli hub che sono collegati, la propria chiave surrogata per il link e i metadati che descrivono l’origine dell’associazione. Gli attributi descrittivi per le informazioni sull’associazione (come il tempo, il prezzo o l’importo) sono memorizzati in strutture chiamate tabelle satellite che sono discusse più avanti.

Esempio di collegamentoModifica

Questo è un esempio per una tabella di collegamento tra due hub per auto (H_CAR) e persone (H_PERSON). Il collegamento si chiama “Autista” (L_DRIVER).

SatellitiEdit

Gli hub e i link formano la struttura del modello, ma non hanno attributi temporali e non hanno attributi descrittivi. Questi sono memorizzati in tabelle separate chiamate satelliti. Questi consistono in metadati che li collegano al loro hub o link padre, metadati che descrivono l’origine dell’associazione e degli attributi, così come una linea temporale con date di inizio e fine per l’attributo. Dove gli hub e i link forniscono la struttura del modello, i satelliti forniscono la “carne” del modello, il contesto per i processi di business che sono catturati negli hub e nei link. Questi attributi sono memorizzati sia per quanto riguarda i dettagli della materia che la linea temporale e possono variare da abbastanza complessi (tutti i campi che descrivono un profilo completo del cliente) a abbastanza semplici (un satellite su un link con solo un indicatore di validità e una linea temporale).

Di solito gli attributi sono raggruppati nei satelliti per sistema sorgente. Tuttavia, gli attributi descrittivi come la dimensione, il costo, la velocità, la quantità o il colore possono cambiare a tassi diversi, quindi puoi anche dividere questi attributi in diversi satelliti in base al loro tasso di cambiamento.

Tutte le tabelle contengono metadati, che descrivono minimamente almeno il sistema di origine e la data in cui questa voce è diventata valida, dando una visione storica completa dei dati mentre entrano nel data warehouse.

Esempio di satelliteModifica

Questo è un esempio per un satellite sul driver-link tra gli hub per auto e persone, chiamato “Driver insurance” (S_DRIVER_INSURANCE). Questo satellite contiene attributi che sono specifici per l’assicurazione della relazione tra l’auto e la persona che la guida, per esempio un indicatore se questo è il conducente principale, il nome della compagnia di assicurazione per questa auto e persona (potrebbe anche essere un hub separato) e un riassunto del numero di incidenti che coinvolgono questa combinazione di veicolo e conducente. È anche incluso un riferimento a una tabella di ricerca o di riferimento chiamata R_RISK_CATEGORY che contiene i codici per la categoria di rischio in cui si ritiene che questa relazione rientri.

(*) almeno un attributo è obbligatorio.(**) il numero di sequenza diventa obbligatorio se è necessario per far rispettare l’unicità per più satelliti validi sullo stesso hub o link.

Tabelle di riferimentoModifica

Le tabelle di riferimento sono una parte normale di un modello di data vault sano. Sono lì per prevenire la memorizzazione ridondante di semplici dati di riferimento che sono molto referenziati. Più formalmente, Dan Linstedt definisce i dati di riferimento come segue:

Tutte le informazioni ritenute necessarie per risolvere le descrizioni dai codici, o per tradurre le chiavi in (sic) un modo coerente. Molti di questi campi sono di natura “descrittiva” e descrivono uno stato specifico di altre informazioni più importanti. Come tali, i dati di riferimento vivono in tabelle separate dalle tabelle grezze del Data Vault.

Le tabelle di riferimento sono referenziate da Satelliti, ma mai legate con chiavi esterne fisiche. Non c’è una struttura prescritta per le tabelle di riferimento: usa ciò che funziona meglio nel tuo caso specifico, da semplici tabelle di lookup a piccoli data vault o persino stelle. Possono essere storiche o non avere storia, ma si raccomanda di attenersi alle chiavi naturali e non creare chiavi surrogate in questo caso. Normalmente, i data vault hanno molte tabelle di riferimento, proprio come qualsiasi altro Data Warehouse.

Esempio di riferimentoModifica

Questo è un esempio di tabella di riferimento con categorie di rischio per i conducenti di veicoli. Può essere referenziata da qualsiasi satellite nel data warehouse. Per ora facciamo riferimento dal satellite S_DRIVER_INSURANCE. La tabella di riferimento è R_RISK_CATEGORY.

(*) almeno un attributo è obbligatorio.