Aggregering (datavarehus)

Eksempel på en grunnleggende arkitektur til et datavarehus

En aggregering et en type sammendrag som brukes i dimensjonsmodellering innen datavarehus for å korte ned tiden det tar å gi svar på typiske spørringer av dataene. Grunnen til at aggregater kan gi en dramatisk bedring i ytelsen til et datavarehus er reduksjonen av antall rader som må gås gjennom når det skal svares på en spørring.

Bruk

I sin enkleste form er et aggregat en enkel sammendragstabell som kan utledes ved å utføre en group by SQL-spørring. Et mer vanlig eksempel på bruk av aggregater er å ta en dimensjon og endre granulariteten til denne dimensjonen. Når man endrer granulariteten til en dimensjon må faktatabellen delvis oppsummeres for å passe finheten til den nye dimensjonen slik at det skapes nye dimensjons- og faktatabeller som passer til den nye granulariteten.

Utforming

Aggregater blir noen ganger referert til som forhåndskalkulerte sammendragsdata siden aggregeringer vanligvis er forhåndsberegnede, delvis oppsummerte data som lagres i nye aggregerte tabeller. Når fakta aggregeres gjøres det enten ved å eliminere dimensjonalitet eller ved å knytte fakta til en sammenrullet dimensjon, hvor sammenrullede dimensjoner skal være krympede versjoner av dimensjonene knyttet til de granulære basisfaktaene. På denne måten bør de aggregerte dimensjonstabellene samsvare med basis-dimensjonstabellene.

Ytelse

Ralph Kimball anses som en av grunnleggerne av datavarehus. I 1996 uttalte han at aggregater er den teknikken som gav den mest dramatiske ytelsesgevinsten i store datavarehus, i noen tilfeller med en faktor på 100 til 1000, og at det var ingen andre midler eksisterer for å høste slike spektakulære gevinster.

Kompleksitet

Aggregeringer og atomiske data øker kompleksiteten til dimensjonsmodellen. Denne kompleksiteten skal være gjennomsiktig for brukerne av datalageret, og når en forespørsel sendes, skal datalageret returnere data fra den tabellen som har riktig finhet. Når forespørsler gjøres mot datavarehuset bør det være en navigasjonsfunksjonalitet for å assistere med å bestemme tabellen med den korrekte finheten.

Antallet mulige aggregeringer bestemmes av alle mulige kombinasjoner av dimensjonsgranulariteter. Siden det ville gi mye indirekte kostnader (overhead) å utforme og kalkulere alle mulige aggregeringer kan det være lurt å velge ut en delmengde av tabeller som det skal lages aggregeringer på. En metode for å velge ut en denne delmengden og bestemme hvilke aggregeringer som skal bygges er å overvåke spørringer og utforme aggregeringer for å matche vanlige spørringsmønstre.

Aggregat-navigasjon

Å ha aggregerte data i dimensjonsmodellen gjør miljøet mer komplekst. For å gjøre denne ekstra kompleksiteten gjennomsiktig for brukeren bør man ha en funksjonalitet for aggregat-navigasjon som brukes til å spørre dimensjons- og faktatabeller med riktig finhet. Aggregat-navigasjonenen undersøker i hovedsak om spørringen for å vurdere om den kan besvares ved å bruke en mindre og aggregert tabell.

Implementeringer av samlede aggregat-navigatører finnes for en rekke teknologier:

• OLAP-motorer
• Materialiserte visninger
• Relasjonelle OLAP-tjenester (ROLAP)
• Applikasjonstjenere og spørreverktøy for forretningsinnsikt

Det anbefales generelt å bruke en av de tre første teknologiene, siden fordelene i sistnevnte tilfelle er begrenset til et enkelt forsytems- (frontend) verktøy for forretningsinnsikt.

Avveininger rundt bruk av aggregater

• Siden dimensjonale modeller bare tjener på aggregater ved store datamengder vil det være en avveining når man bør begynne å bruke aggregater
• Man kan spørre seg om et datavarehus alltid håndterer datamengder som er for store for direkte spørringer, eller om det noen ganger kan være lurt å utelate de aggregerte tabellene når man starter et nytt datavarehusprosjekt
• Et åpent spørsmål er hvorvidt utelatelse av aggregater i første iterasjonen når man bygger et nytt datavarehus vil gjøre strukturen til dimensjonsmodellen enklere

Se også

• Aggregering i statistikk