In die vorige artikel het ek oor die basiese beginsels van DATA VAULT gepraat, die hoofelemente van DATA VAULT en hul doel beskryf. Op hierdie stadium kan die onderwerp van DATA VAULT nie as uitgeput beskou word nie, dit is nodig om te praat oor die volgende stappe in die evolusie van DATA VAULT.
En in hierdie artikel sal ek fokus op die ontwikkeling van DATA VAULT en die oorgang na BUSINESS DATA VAULT of bloot BUSINESS VULT.
Redes vir die ontstaan van BUSINESS DATA VULT
Daar moet kennis geneem word dat DATA VAULT, wat sekere sterk punte het, nie sonder sy tekortkominge is nie. Een van hierdie nadele is die moeilikheid om analitiese navrae te skryf. Navrae het 'n aansienlike aantal JOINs, die kode is lank en omslagtig. Die data wat die DATA VAULT binnekom is ook nie onderhewig aan enige transformasies nie, daarom het DATA VAULT uit 'n besigheidsoogpunt in sy suiwer vorm geen onvoorwaardelike waarde nie.
Dit is om hierdie tekortkominge uit te skakel dat die DATA VAULT-metodologie uitgebrei is met sulke elemente soos:
- PIT (punt in tyd) tabelle;
- BRUG tafels;
- VOORAFGEDEFINEERDE AFLEIDINGS.
Kom ons kyk noukeuriger na die doel van hierdie elemente.
PIT-tabelle
As 'n reël kan een besigheidsobjek (HUB) data met verskillende opdateringstempo's bevat, byvoorbeeld, as ons praat oor data wat 'n persoon kenmerk, kan ons sê dat inligting oor 'n telefoonnommer, adres of e-pos 'n hoër opdateringstempo het as sê, volle naam, paspoortbesonderhede, huwelikstatus of geslag.
Daarom, wanneer satelliete bepaal word, moet 'n mens die frekwensie van hul hernuwing in gedagte hou. Hoekom is dit belangrik?
As jy eienskappe met verskillende opdateringskoerse in dieselfde tabel stoor, sal jy elke keer 'n ry by die tabel moet voeg wanneer die kenmerk wat die meeste verander word, opgedateer word. As gevolg hiervan is daar 'n toename in die hoeveelheid skyfspasie, 'n toename in die uitvoeringstyd van navrae.
Noudat ons die satelliete volgens opdateringstempo geskei het, en ons data onafhanklik in hulle kan laai, moet ons verseker dat ons bygewerkte data kan kry. Beter sonder om onnodige JOINs te gebruik.
Kom ek verduidelik, byvoorbeeld, jy moet bygewerkte (teen die datum van die laaste opdatering) inligting van satelliete met verskillende opdateringskoerse kry. Om dit te doen, sal jy nie net 'n JOIN moet maak nie, maar ook verskeie geneste navrae moet skep (vir elke satelliet wat inligting bevat) met 'n keuse van die maksimum opdateringsdatum MAX (Opdateringsdatum). Met elke nuwe JOIN groei sulke kode en word dit baie vinnig moeilik om te verstaan.
Die PIT-tabel is ontwerp om sulke navrae te vereenvoudig, PIT-tabelle word gevul op dieselfde tyd as wat nuwe data na die DATA VULT geskryf word. PIT tabel:
Ons het dus inligting oor die relevansie van data vir alle satelliete op elke tydstip. Deur JOINs op die PIT-tabel te gebruik, kan ons geneste navrae heeltemal uitskakel, natuurlik met die voorwaarde dat die PIT elke dag gevul word en sonder gapings. Selfs al is daar leemtes in die PIT, kan jy slegs bygewerkte data kry deur een geneste navraag na die PIT self te gebruik. Een geneste navraag sal vinniger werk as geneste navrae vir elke satelliet.
BRIDGE
BRIDGE-tabelle word ook gebruik om analitiese navrae te vereenvoudig. Die verskil van PIT is egter 'n manier om versoeke tussen verskeie spilpunte, skakels en hul satelliete te vereenvoudig en te bespoedig.
Die tabel bevat al die nodige sleutels vir alle satelliete wat dikwels in navrae gebruik word. Daarbenewens, indien nodig, kan hashed besigheidssleutels aangevul word met sleutels in teksvorm, indien die name van die sleutels nodig is vir ontleding.
Die feit is dat sonder om BRIDGE te gebruik, in die proses om data te verkry wat geleë is in satelliete wat aan verskillende spilpunte behoort, sal dit nodig wees om nie net by die satelliete self aan te sluit nie, maar ook die skakels wat die spilpunte verbind.
Die teenwoordigheid of afwesigheid van BRIDGE word bepaal deur die bergingkonfigurasie, die behoefte om die spoed van navraaguitvoering te optimaliseer. Dit is moeilik om met 'n universele voorbeeld van BRIGE vorendag te kom.
VOORAFGEDEFINEERDE AFLEIDINGS
Nog 'n tipe voorwerpe wat ons nader bring aan BESIGHEIDSDATA VAULT is tabelle wat vooraf berekende aanwysers bevat. Sulke tabelle is regtig belangrik vir besigheid, dit bevat inligting wat volgens gegewe reëls saamgevoeg is en maak dit relatief maklik om toegang te verkry.
Argitektonies is VOORAFGEDEFINEERDE AFLEIDINGS niks meer as nog 'n satelliet van 'n sekere spilpunt nie. Dit, soos 'n gewone satelliet, bevat 'n besigheidsleutel en die datum waarop die rekord in die satelliet geskep is. Dit is egter waar die ooreenkomste eindig. Die verdere samestelling van die eienskappe van so 'n "gespesialiseerde" satelliet word deur sakegebruikers bepaal op grond van die gewildste, vooraf berekende aanwysers.
Byvoorbeeld, 'n spilpunt wat inligting oor 'n werknemer bevat, kan 'n satelliet insluit met aanwysers soos:
- Minimumloon;
- Maksimum salaris;
- Gemiddelde salaris;
- Kumulatiewe totaal van opgelope lone, ens.
Dit is logies om VOORAFGEDEFINEERDE AFLEIDINGS in die PIT-tabel van dieselfde spilpunt in te sluit, dan kan jy maklik werknemerdataskywe vir 'n spesifieke datum kry.
GEVOLGTREKKINGS
Soos die praktyk toon, is die gebruik van DATA VAULT deur sakegebruikers om verskeie redes ietwat moeilik:
- Die navraagkode is kompleks en omslagtig;
- Die oorvloed van JOINs beïnvloed navraagprestasie;
- Die skryf van analitiese navrae vereis 'n uitstekende kennis van die pakhuisstruktuur.
Om datatoegang te vereenvoudig, word DATA VAULT uitgebrei met bykomende voorwerpe:
- PIT (punt in tyd) tabelle;
- BRUG tafels;
- VOORAFGEDEFINEERDE AFLEIDINGS.
Volgende Ek beplan om na my mening die interessantste te vertel vir diegene wat met BI werk. Ek sal maniere aanbied om tabelle te skep - feite en tabelle - dimensies gebaseer op DATA VULT.
Die materiaal van die artikel is gebaseer op:
- Op Kenta Graziano, wat, benewens 'n gedetailleerde beskrywing, modeldiagramme bevat;
- Boek: "Bou 'n skaalbare datapakhuis met DATA VAULT 2.0";
- artikel .
Bron: will.com