In het vorige artikel heb ik gesproken over de basisprincipes van DATA VAULT, de belangrijkste elementen van DATA VAULT en hun doel beschreven. Dit kan niet worden beschouwd als het onderwerp van DATA VAULT als uitgeput; het is noodzakelijk om te praten over de volgende stappen in de evolutie van DATA VAULT.
En in dit artikel zal ik me concentreren op de ontwikkeling van DATA VAULT en de overgang naar BUSINESS DATA VAULT of simpelweg BUSINESS VAULT.
Redenen voor het verschijnen van BUSINESS DATA VAULT
Opgemerkt moet worden dat DATA VAULT, hoewel het bepaalde sterke punten heeft, niet zonder nadelen is. Een van deze nadelen is de moeilijkheid bij het schrijven van analytische vragen. Query's hebben een aanzienlijk aantal JOIN's, de code is lang en omslachtig. Bovendien ondergaan de gegevens die DATA VAULT binnenkomen geen enkele transformatie. Vanuit zakelijk oogpunt heeft DATA VAULT in zijn pure vorm dan ook geen absolute waarde.
Om deze tekortkomingen te elimineren werd de DATA VAULT-methodologie uitgebreid met elementen als:
- PIT-tabellen (punt in de tijd);
- BRIDGE-tafels;
- VOORGEDEFINIEERDE AFLEIDINGEN.
Laten we het doel van deze elementen eens nader bekijken.
PIT-tafels
Doorgaans kan één bedrijfsentiteit (HUB) gegevens bevatten met verschillende updatefrequenties. Als we het bijvoorbeeld hebben over gegevens die een persoon karakteriseren, kunnen we zeggen dat informatie over een telefoonnummer, adres of e-mailadres een hogere updatesnelheid heeft dan bijvoorbeeld: volledige naam, paspoortgegevens, burgerlijke staat of geslacht.
Daarom moet u bij het bepalen van satellieten rekening houden met hun updatefrequentie. Waarom is het belangrijk?
Als u attributen met verschillende updatesnelheden in dezelfde tabel opslaat, moet u elke keer dat het meest gewijzigde attribuut wordt bijgewerkt een rij aan de tabel toevoegen. Het resultaat is een toename van de schijfruimte en een toename van de uitvoeringstijd van query's.
Nu we de satellieten hebben onderverdeeld op updatefrequentie en er onafhankelijk gegevens in kunnen laden, moeten we ervoor zorgen dat we actuele gegevens kunnen ontvangen. Beter, zonder onnodige JOINs te gebruiken.
Laat me bijvoorbeeld uitleggen dat je actuele informatie (volgens de datum van de laatste update) moet verkrijgen van satellieten met verschillende updatesnelheden. Om dit te doen, moet u niet alleen een JOIN maken, maar ook verschillende geneste zoekopdrachten maken (voor elke satelliet die informatie bevat) met de selectie van de maximale updatedatum MAX (Update Date). Met elke nieuwe JOIN groeit deze code en wordt deze al snel moeilijk te begrijpen.
De PIT-tabel is ontworpen om dergelijke zoekopdrachten te vereenvoudigen; PIT-tabellen worden gelijktijdig gevuld met het schrijven van nieuwe gegevens naar de DATA VAULT. PIT-tabel:
We hebben dus informatie over de relevantie van gegevens voor alle satellieten op elk tijdstip. Door JOINs aan de PIT-tabel te gebruiken, kunnen we geneste queries volledig elimineren, uiteraard op voorwaarde dat de PIT elke dag en zonder gaten wordt gevuld. Zelfs als er gaten in de PIT zitten, kunt u de meest recente gegevens verkrijgen door slechts één geneste query naar de PIT zelf te gebruiken. Eén geneste zoekopdracht wordt sneller verwerkt dan geneste zoekopdrachten naar elke satelliet.
BRUG
BRIDGE-tabellen worden ook gebruikt om analytische query's te vereenvoudigen. Wat echter verschilt van PIT is een manier om verzoeken tussen verschillende hubs, verbindingen en hun satellieten te vereenvoudigen en te versnellen.
De tabel bevat alle benodigde sleutels voor alle satellieten, die vaak worden gebruikt bij zoekopdrachten. Daarnaast kunnen gehashte bedrijfssleutels indien nodig worden aangevuld met sleutels in tekstvorm als de namen van de sleutels nodig zijn voor analyse.
Feit is dat zonder BRIDGE te gebruiken, het tijdens het ontvangen van gegevens die zich bevinden in satellieten die tot verschillende hubs behoren, noodzakelijk zal zijn om niet alleen een JOIN te maken van de satellieten zelf, maar ook van de verbindingen die de hubs verbinden.
De aanwezigheid of afwezigheid van BRIDGE wordt bepaald door de opslagconfiguratie en de noodzaak om de snelheid van de uitvoering van query's te optimaliseren. Het is moeilijk om een universeel voorbeeld van BRIGE te bedenken.
VOORGEDEFINIEERDE AFLEIDINGEN
Een ander type object dat ons dichter bij de BUSINESS DATA VAULT brengt, zijn tabellen met vooraf berekende indicatoren. Dergelijke tabellen zijn erg belangrijk voor het bedrijfsleven; ze bevatten informatie die is samengevoegd volgens bepaalde regels en maken deze relatief gemakkelijk toegankelijk.
Architectonisch gezien zijn VOORGEDEFINIEERDE AFLEIDINGEN niets meer dan een andere satelliet van een bepaalde hub. Het bevat, net als een gewone satelliet, een bedrijfssleutel en de datum van creatie van het record in de satelliet. Dit is echter waar de overeenkomsten eindigen. De verdere samenstelling van de attributen van zo’n “gespecialiseerde” satelliet wordt bepaald door zakelijke gebruikers op basis van de meest populaire, vooraf berekende indicatoren.
Een hub met informatie over een werknemer kan bijvoorbeeld een satelliet bevatten met indicatoren zoals:
- Minimumloon;
- Maximaal salaris;
- Gemiddeld salaris;
- Cumulatief totaal van opgebouwde lonen etc.
Het is logisch om VOORGEDEFINIEERDE AFLEIDINGEN op te nemen in de PIT-tabel van dezelfde hub, zodat u eenvoudig dataplakken kunt verkrijgen voor een medewerker op een specifiek geselecteerde datum.
Conclusies
Zoals de praktijk laat zien, is het gebruik van DATA VAULT door zakelijke gebruikers om verschillende redenen enigszins lastig:
- De querycode is complex en omslachtig;
- De overvloed aan JOIN's beïnvloedt de prestaties van query's;
- Het schrijven van analytische queries vereist uitstekende kennis van opslagontwerp.
Om de toegang tot gegevens te vereenvoudigen, is DATA VAULT uitgebreid met extra objecten:
- PIT-tabellen (punt in de tijd);
- BRIDGE-tafels;
- VOORGEDEFINIEERDE AFLEIDINGEN.
Volgende Ik ben van plan om naar mijn mening het meest interessante te vertellen voor degenen die met BI werken. Ik zal manieren presenteren om feitentabellen en dimensietabellen te maken op basis van DATA VAULT.
De materialen van het artikel zijn gebaseerd op:
- Op Kenta Graziano, dat naast een gedetailleerde beschrijving ook modeldiagrammen bevat;
- Boek: “Bouw een schaalbaar datawarehouse met DATA VAULT 2.0”;
- artikel .
Bron: www.habr.com