Utveckling av DATA VAULT och övergång till BUSINESS DATA VAULT

I den tidigare artikeln pratade jag om grunderna i DATA VAULT, beskrev de viktigaste delarna av DATA VAULT och deras syfte. Detta kan inte betraktas som ämnet för DATA VAULT som uttömt; det är nödvändigt att prata om nästa steg i utvecklingen av DATA VAULT.

Och i den här artikeln kommer jag att fokusera på utvecklingen av DATA VAULT och övergången till BUSINESS DATA VAULT eller helt enkelt BUSINESS VAULT.

Orsaker till uppkomsten av BUSINESS DATA VAULT

Det bör noteras att DATA VAULT, även om det har vissa styrkor, inte är utan sina nackdelar. En av dessa nackdelar är svårigheten att skriva analytiska frågor. Frågor har ett betydande antal JOINs, koden är lång och krånglig. Dessutom genomgår inte data som matas in i DATA VAULT några omvandlingar, därför har DATA VAULT ur affärssynpunkt inget absolut värde i sin rena form.

Det var för att eliminera dessa brister som DATA VAULT-metoden utökades med sådana element som:

• PIT-tabeller (tidpunkt);
• BRIDGE tabeller;
• FÖRDEFINIERADE DERIVATIONER.

Låt oss ta en närmare titt på syftet med dessa element.

PIT-bord

Vanligtvis kan en affärsenhet (HUB) innehålla data med olika uppdateringshastigheter, om vi till exempel talar om data som kännetecknar en person kan vi säga att information om ett telefonnummer, adress eller e-post har en högre uppdateringshastighet än säg, fullständigt namn, passuppgifter, civilstånd eller kön.

Därför bör du komma ihåg deras uppdateringsfrekvens när du bestämmer satelliter. Varför är det viktigt?

Om du lagrar attribut med olika uppdateringshastigheter i samma tabell, måste du lägga till en rad i tabellen varje gång det mest ändrade attributet uppdateras. Resultatet är en ökning av diskutrymmet och en ökning av exekveringstiden för frågor.

Nu när vi har delat upp satelliterna efter uppdateringsfrekvens och kan ladda data till dem oberoende, bör vi se till att vi kan ta emot uppdaterad data. Bättre, utan att använda onödiga JOINs.

Låt mig förklara, till exempel, du behöver få aktuell (enligt datum för den senaste uppdateringen) information från satelliter som har olika uppdateringshastigheter. För att göra detta behöver du inte bara göra en JOIN, utan också skapa flera kapslade frågor (för varje satellit som innehåller information) med val av maximalt uppdateringsdatum MAX (Update Date). Med varje ny JOIN växer sådan kod och blir väldigt snabbt svår att förstå.

PIT-tabellen är utformad för att förenkla sådana frågor; PIT-tabeller fylls samtidigt med att nya data skrivs till DATA VAULT. PIT-tabell:

Således har vi information om relevansen av data för alla satelliter vid varje tidpunkt. Genom att använda JOINs till PIT-tabellen kan vi helt eliminera kapslade frågor, naturligtvis med villkoret att PIT fylls varje dag och utan luckor. Även om det finns luckor i PIT, kan du få den senaste informationen endast genom att använda en kapslad fråga till själva PIT. En kapslad fråga kommer att bearbetas snabbare än kapslade frågor till varje satellit.

BRO

BRIDGE-tabeller används också för att förenkla analytiska frågor. Det som dock skiljer sig från PIT är ett sätt att förenkla och påskynda förfrågningar mellan olika nav, länkar och deras satelliter.

Tabellen innehåller alla nödvändiga nycklar för alla satelliter, som ofta används i frågor. Dessutom kan hashade affärsnycklar vid behov kompletteras med nycklar i textform om nycklarnas namn behövs för analys.

Faktum är att utan att använda BRIDGE, i processen för att ta emot data som finns i satelliter som tillhör olika nav, kommer det att vara nödvändigt att göra en JOIN inte bara av satelliterna själva utan också av länkarna som förbinder naven.

Närvaron eller frånvaron av BRIDGE bestäms av lagringskonfigurationen och behovet av att optimera hastigheten för exekveringen av en fråga. Det är svårt att komma på ett universellt exempel på BRIGE.

FÖRDEFINIERADE DERIVATIONER

En annan typ av objekt som för oss närmare BUSINESS DATA VALV är tabeller som innehåller förberäknade indikatorer. Sådana tabeller är verkligen viktiga för företag, de innehåller information som är aggregerad enligt givna regler och gör den relativt lättillgänglig.

Arkitektoniskt är FÖRDEFINIERADE DERIVATIONER inget annat än en annan satellit för ett visst nav. Den, som en vanlig satellit, innehåller en affärsnyckel och datumet för skapandet av posten i satelliten. Det är här dock likheterna slutar. Den ytterligare sammansättningen av attributen för en sådan "specialiserad" satellit bestäms av affärsanvändare baserat på de mest populära, förberäknade indikatorerna.

Till exempel kan ett nav som innehåller information om en anställd inkludera en satellit med indikatorer som:

• Minimilön;
• Maximal lön;
• Genomsnittslön;
• Sammanlagd summa av upplupna löner m.m.

Det är logiskt att inkludera FÖRDEFINIERADE DERIVATIONER i PIT-tabellen för samma nav, då kan du enkelt få datasnitt för en anställd på ett specifikt valt datum.

SLUTSATSER

Som praxis visar är användningen av DATA VAULT av företagsanvändare något svårt av flera skäl:

• Frågekoden är komplex och besvärlig;
• Överflödet av JOINs påverkar prestandan för frågor;
• Att skriva analytiska frågor kräver enastående kunskap om lagringsdesign.

För att förenkla dataåtkomst utökas DATA VAULT med ytterligare objekt:

• PIT-tabeller (tidpunkt);
• BRIDGE tabeller;
• FÖRDEFINIERADE DERIVATIONER.

Nästa artikeln Jag tänker berätta, enligt mig, det mest intressanta för de som jobbar med BI. Jag kommer att presentera sätt att skapa faktatabeller och dimensionstabeller baserade på DATA VALV.

Materialet i artikeln är baserat på:

• På Publikation Kenta Graziano, som förutom en detaljerad beskrivning innehåller modelldiagram;
• Bok: "Bygga ett skalbart datalager med DATA VAULT 2.0";
• Artikel Grundläggande om datavalv.

Källa: will.com