QlikView AGGR() vs SUM(TOTAL)

När man i QlikView vill ta fram andelar av en total brutet på en eller flera dimensioner så använder man ofta ett tillägg i en funktion som heter TOTAL. Detta tillägg fungerar inte i de fall man vill använda aggr() som en kalkylerad dimension. Nedan ska jag illustrera ett exempel på detta och vad man bör tänka på vid användandet av AGGR() och SUM(TOTAL).

I diagrammet nedan har vi två dimensioner: År och kundnummer.
Uttrycken i diagrammet visar följande:

1. sum(pris): en vanlig summering av pris på de varor som varje kund har köpt år 2001.
2. AGGR(NODISTINCT sum(pris),År): Summerar pris på de varor som alla 5 kunder har köpt år 2001.
3. sum(total <År> Pris): Summerar pris på de varor som alla 5 kunder har köpt år 2001, d.v.s samma som uttryck 2.

Vill man ha andelar så kan man således använda följande formel:
sum(pris)/sum(total <År> Pris)

Antag nu att man vill byta ut dimensionen kund i diagrammet ovan mot ett rankingnummer på varje kund istället för kundnummer. Dimensionen kund byts ut mot en kalkylerad dimension som beräknar varje kunds rank:

Aggr(rank(sum(pris)),År,kund): summera pris per år och kund och sätt ett rankingnummer.

I diagrammet nedan behåller vi uttryck 2 och 3 på samma sätt som i det tidigare diagrammet. Nu kan vi se att uttryck 3 sum(total <År> Pris) inte stämmer trots att vi har en rad för varje kund och år.

Slutsats: Om aggr() används som kalkylerad dimension använd aggr() i uttryck för postöverskridande beräkningar.

QlikView Set-analys är en kioskvältare!

I en tidigare artikel (Möte med QlikTech från 2008-02-28) har jag skrivit om för-och nackdelar med QlikView i förhållande till traditionell OLAP-teknik. Slutsatsen var att viktiga funktioner som mängder (union, intersektion, minus), jämförelse med tidigare år osv inte kunde hanteras på ett smidigt sätt i QlikView i förhållande till OLAP-kuber. I QlikView kunde man skapa flaggor för respektive nyckeltal man ville ha ut för jämförelser mellan veckor eller år för att ta ett exempel. I nya versionen av QlikView 8.5 finns det en ny hantering av denna problematik som kallas Set-analys.

Jag har testat denna set-analys och så här långt så fungerar det mycket bra och håller vad som lovas av leverantören. Ett exempel på hur jag har använt set-analysfunktionen är följande:

Exempel ur verkligheten
I ett och samma diagram ska jämförelser göras mellan olika försäljningsställen på olika nyckeltal. Ibland vill man jämföra en vecka mot en annan eller flera veckor mot varandra. Ibland vill man jämföra tre veckor mot tre andra. Veckorna ska vara valfria så att användaren kan jämföra exempelvis vecka 200915 mot 200913 och nästa gång 200915 och 200916 mot 200913 och 200914. I detta exempel så behöver man göra urval av två olika tider i ett och samma diagram, where-villkoren görs i uttrycken. Detta kan man lösa genom att lägga till en tabell som innehåller veckor och som endast fungerar som input i form av en variabel till urvalet i uttrycket. Ingen koppling av dessa veckor till någon annan tabell i QlikView, endast en fristående tabell som fungerar som en jämförelsetabell.

De två nyckeltalen som ska jämföras är försäljning och ställs upp enligt följande uttryck:

1. sum(försäljning): Uttrycket räknar ut försäljning per försäljningsställe för aktuella val. Detta är ett vanligt enkelt uttryck.
2. sum({$<Vecka={$(=(GetFieldSelections(Jämförelsetid.Vecka)))},Årtal=,Månad=>}[försäljning]): Uttryck med set-analys.

I uttryck nr.2 så nollställs urvalen Årtal och Månad. För att välja nya veckor för uttryck nr 2 så väljs Jämförelsetid.Vecka i en urvalslista som fungerar som ett nytt urval av veckor till fältet Vecka. Lägg märke till $ som betyder att det är en parameter innehållande värden som utgör ett nytt urval och funktionen GetFieldSelections som tar ut värdena från urvalet i den fristående tabellen Jämförelsetid.Vecka. Sedan kan uttryck nr 1 och 2 ingå i andra uttryck för att räkna på differenser, rankingar osv. På detta sätt får man en mycket flexibel hantering av olika jämförelser som inkluderar aktuell vecka i jämförelse med föregående vecka eller samma vecka föregående år osv.

Mycket imponerande prestanda i dessa funktioner som på flera hundra miljoner rader endast tar ett par sekunder att beräkna.

Slutsatsen är att Set-analys är en mycket bra funktion som gör att användaren själv kan skapa sina jämförelser och inte behöver involvera IT-avdelningen i speciellt stor utsträckning.

CDC eller Streams AQ

CDC är ett enkelt sätt att fånga förändringar i källsystemens tabeller och sedan propagera dessa till datalagret eller integrationshubben för bearbetning via förändringsvyer. DBMS_CDC-paketen är ett API ovanpå Streams AQ, dvs anrop till DBMS_CDC sätter upp köer, förändringstabeller osv (se tidigare inlägg om CDC). CDC är snabbt och relativt enkelt att sätta upp. CDC-paketen kom senare och frågan är om CDC alltid kan användas eller om det finns situationer när det är bättre att sätta upp Streams AQ direkt?

Enligt min mening så kan CDC användas i de fall när propagering av förändringar endast ska ske till ett ställe, s.k. punkt-till-punkt. Prenumeration på förändringar kan ske av flera användare på den mottagande sidan. Om data från källsystemen däremot ska propageras till flera ställen med många olika prenumeranter i flera databaser så är det bättre att sätta upp Streams AQ för att fånga förändringar och sedan propagera dessa till alla intressenter. Man kan med fördel använda Oracles egen Capture- och Applyprocess för att åstadkomma LCR (Logical Change Records) som skickas vidare till mottagande köer i olika databaser via meddelandetypen ANYDATA.

Fördelen med Streams i jämförelse med CDC är följande:

En utkö i källsystemet för vidare transport av förändringar istället för flera köer.
Propagering till flera olika databaser istället för punkt till punkt.
Kontroll på start av transaktioner att flytta över via SCN (System Change Number).
Skapa kanonisk xml direkt från LCR-meddelanden via paket.

Nackdelen med Streams i jämförelse med CDC:

- Tar längre tid att sätta upp
- Process för att ta hand om LCR-meddelanden på mottagande sida.