Nell'articolo precedente ho parlato delle basi di DATA VAULT, ho descritto gli elementi principali di DATA VAULT e il loro scopo. L'argomento DATA VAULT non può considerarsi esaurito; è necessario parlare dei prossimi passi nell'evoluzione di DATA VAULT.
E in questo articolo mi concentrerò sullo sviluppo di DATA VAULT e sul passaggio a BUSINESS DATA VAULT o semplicemente BUSINESS VAULT.
Motivi per la comparsa di BUSINESS DATA VAULT
Va notato che DATA VAULT, pur avendo alcuni punti di forza, non è privo di inconvenienti. Uno di questi svantaggi è la difficoltà nello scrivere query analitiche. Le query hanno un numero significativo di JOIN, il codice è lungo e macchinoso. Inoltre, i dati che entrano in DATA VAULT non subiscono alcuna trasformazione, quindi, da un punto di vista aziendale, DATA VAULT nella sua forma pura non ha valore assoluto.
È stato per eliminare queste carenze che la metodologia DATA VAULT è stata ampliata con elementi quali:
- Tabelle PIT (point in time);
- Tavoli PONTE;
- DERIVAZIONI PREDEFINITE.
Diamo uno sguardo più da vicino allo scopo di questi elementi.
Tabelle PIT
In genere, un'entità aziendale (HUB) può contenere dati con velocità di aggiornamento diverse, ad esempio, se parliamo di dati che caratterizzano una persona, possiamo dire che le informazioni su un numero di telefono, indirizzo o e-mail hanno una velocità di aggiornamento più elevata rispetto ad esempio, nome completo, dettagli del passaporto, stato civile o sesso.
Pertanto, quando si determinano i satelliti, è necessario tenere presente la loro frequenza di aggiornamento. Perché è importante?
Se memorizzi attributi con frequenze di aggiornamento diverse nella stessa tabella, dovrai aggiungere una riga alla tabella ogni volta che viene aggiornato l'attributo modificato più frequentemente. Il risultato è un aumento dello spazio su disco e un aumento del tempo di esecuzione delle query.
Ora che abbiamo diviso i satelliti in base alla frequenza di aggiornamento e possiamo caricare i dati al loro interno in modo indipendente, dovremmo assicurarci di poter ricevere dati aggiornati. Meglio, senza utilizzare JOIN inutili.
Mi spiego, ad esempio, è necessario ottenere informazioni attuali (in base alla data dell'ultimo aggiornamento) da satelliti che hanno velocità di aggiornamento diverse. Per fare ciò sarà necessario non solo effettuare un JOIN, ma anche creare diverse query nidificate (per ogni satellite contenente informazioni) con la selezione della data massima di aggiornamento MAX (Update Date). Con ogni nuovo JOIN, tale codice cresce e diventa molto rapidamente difficile da comprendere.
La tabella PIT è progettata per semplificare tali query; le tabelle PIT vengono riempite contemporaneamente alla scrittura di nuovi dati nel DATA VAULT. Tabella PIT:
Pertanto, disponiamo di informazioni sulla rilevanza dei dati per tutti i satelliti in ogni momento. Utilizzando i JOIN alla tabella PIT possiamo eliminare completamente le query nidificate, naturalmente a condizione che il PIT venga riempito ogni giorno e senza interruzioni. Anche se ci sono lacune nel PIT, puoi ottenere i dati più recenti utilizzando solo una query nidificata nel PIT stesso. Una query nidificata verrà elaborata più velocemente delle query nidificate su ciascun satellite.
BRIDGE
Le tabelle BRIDGE vengono utilizzate anche per semplificare le query analitiche. Tuttavia, ciò che differisce dal PIT è un mezzo per semplificare e accelerare le richieste tra i vari hub, collegamenti e i loro satelliti.
La tabella contiene tutte le chiavi necessarie per tutti i satelliti, che vengono spesso utilizzate nelle query. Inoltre, se necessario, le chiavi aziendali con hash possono essere integrate con chiavi in forma di testo se i nomi delle chiavi sono necessari per l'analisi.
Il fatto è che senza utilizzare BRIDGE, nel processo di ricezione dei dati situati in satelliti appartenenti a hub diversi, sarà necessario effettuare un JOIN non solo dei satelliti stessi, ma anche dei collegamenti che collegano gli hub.
La presenza o l'assenza di BRIDGE è determinata dalla configurazione dello storage e dalla necessità di ottimizzare la velocità di esecuzione delle query. È difficile trovare un esempio universale di BRIGE.
DERIVAZIONI PREDEFINITE
Un'altra tipologia di oggetti che ci avvicina al BUSINESS DATA VAULT sono le tabelle contenenti indicatori precalcolati. Tali tabelle sono molto importanti per le aziende; contengono informazioni aggregate secondo determinate regole e ne rendono relativamente facile l'accesso.
Architettonicamente le DERIVAZIONI PREDEFINITE non sono altro che un altro satellite di un certo hub. Come un normale satellite, contiene una chiave aziendale e la data di creazione del record nel satellite. Qui però finiscono le somiglianze. L'ulteriore composizione degli attributi di un satellite così “specializzato” è determinata dagli utenti aziendali sulla base degli indicatori più popolari e precalcolati.
Ad esempio, un hub contenente informazioni su un dipendente può includere un satellite con indicatori quali:
- Salario minimo;
- Salario massimo;
- Stipendio medio;
- Totale cumulativo dei salari maturati, ecc.
È logico includere DERIVAZIONI PREDEFINITE nella tabella PIT dello stesso hub, quindi è possibile ottenere facilmente porzioni di dati per un dipendente in una data specificatamente selezionata.
CONCLUSIONI
Come dimostra la pratica, l'utilizzo di DATA VAULT da parte degli utenti aziendali è alquanto difficile per diversi motivi:
- Il codice della query è complesso e macchinoso;
- L'abbondanza di JOIN influisce sulle prestazioni delle query;
- La scrittura di query analitiche richiede una conoscenza eccezionale della progettazione dello storage.
Per semplificare l'accesso ai dati, DATA VAULT viene esteso con oggetti aggiuntivi:
- Tabelle PIT (point in time);
- Tavoli PONTE;
- DERIVAZIONI PREDEFINITE.
Prossimo Ho intenzione di raccontare, secondo me, la cosa più interessante per chi lavora con la BI. Presenterò modi per creare tabelle dei fatti e tabelle delle dimensioni basate su DATA VAULT.
I materiali dell'articolo si basano su:
- Su Kenta Graziano, che, oltre ad una descrizione dettagliata, contiene schemi di modelli;
- Libro: "Creazione di un data warehouse scalabile con DATA VAULT 2.0";
- Статья .
Fonte: habr.com