Vem ska använda QlikView?

I en artikel från fredag 25 april 2008 skrev jag vad jag tyckte att man skulle tänka på när man utvecklar applikationer i QlikView. Idag med ytterligare två års erfarenhet av QlikViewutveckling och analys så ska jag försöka beskriva vilken roll och kompetens man bör ha som QlikView-användare och vilket användningsområde i en BI-lösning QlikView bör ha.


Min erfarenhet när det gäller valet av QlikView som verktyg framför en traditionell OLAP-lösning baseras på det agila tankesättet att snabbt kunna leverera lösningar på nya krav från användarna. QlikView möjliggör detta genom att, med bibehållen prestanda, lagra stora mängder data på detaljnivå samt tillåta avancerade beräkningar i gränssnittet. Just möjligheten att göra avancerade beräkningar med kalkylerade dimensioner och hierarkier i gränssnittet gör att kravet på QlikView-användaren är högre än i en traditionell OLAP-lösning där nyckeltal, hierarkier m.m. görs av utvecklaren i kuberna. Arbetsuppgiften att beräkna nyckeltalen har delvis flyttats till slutanvändaren vilket ökar risken för att QlikView-användaren gör felaktiga beräkningar av bl.a. nyckeltal och hierarkier som kan leda till felaktiga beslut för företagets framtida satsningar. För att undvika detta så måste QlikViewanvändaren besitta rätt kompetens och bakgrund. En IT-ekonom med kompetens om datamodeller är som klippt och skuren för att ta rollen som QlikViewanvändare.


I vårt fall finns det stora behov av att kunna korsköra resultat ur olika stjärnmodeller. Ett exempel är att titta på alla kunder som har besökt vissa sidor i en webbapplikation (stjärnmodell 1) under en viss period och titta på hur mycket och vilka produkter de har köpt (stjärnmodell 2) före och efter besöken på sidorna. På detta sätt kan man dra vissa slutsatser om hur olika budskap på de besökta sidorna kan påverka inköpen. Dessa korskörningar kräver att användaren har förståelse för hur data hänger ihop så kunskap om datamodeller är av stor vikt för att lyckas med denna korskörning. I ovanstående fall så skulle en marknadsanalytiker på marknadsavdelningen för nya medier med kunskap om datamodeller kunna få fram intressanta resultat genom att använda QlikView som verktyg, och det genom att ad-hoc komma fram till på vilket sätt han/hon vill kategorisera data.

QlikView är ett utmärkt verktyg att använda i en förstudiefas hos marknadsavdelningen där exempelvis kunder ska kategoriseras i olika grupper för en CRM-lösning. Ett exempel kan vara analytisk CRM där QlikView är en del i arbete med att sätta kundgrupper som sedan kan existera över en viss tidsperiod i ett CRM-system. Mer statistisk rapportering bör ske på andra sätt än med QlikView där icke avancerade användare får information. En sådan lösning som inte kräver ständiga förändringar utan utgör en del i en rapporteringsplattform hanteras givetvis bäst av en traditionell OLAP-lösning.

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.

CDC - integrationshub och datalager

CDC eller Change Data Capture är en lyckad implementation i en integrationsarkitektur, framförallt i ett datalager med krav på uppdateringar nära realtid. Om många av källsystemen är databas Oracle så är det lätt att sätta upp en CDC på källsystemen från en integrationshub eller stagingdatabas. Oracle har fyra implementationer av CDC varav en heter Asynchronous Distributed Hotlog CDC. Källsystemets version måste vara Oracle 9 rel.2 eller högre och integrations- eller stagingdatabasen Oracle 10 rel.2 eller högre. Vid denna implementation kan den ansvariga för integrationshubben alternativt stagingdatabasen "lyssna" på förändringar i valda tabeller i källsystemet. Förändringarna propageras via streams AQ till förändringstabeller i hubben alternativt stagingdatabasen. Allt detta sätts upp automatiskt via DBMS_CDC-paket i Oracledatabasen. Förändringarna kan sedan bearbetas med exempelvis OWB var 5:e minut för inläsning i datalagret alternativt skapa xml-meddelanden som skickas ut på en integrationsbuss (ESB). Den stora fördelen med CDC är att utan applikationskod fånga förändringar i källsystemens tabeller och sedan bearbeta dessa.

Internetportal lanseras i början på september

Nu är sommarledigheten slut för den här gången och det är full fart igen. Sommarledigheten har inneburit en hel del arbete. Internetportalen för digital marknadsföring lanseras i början på september med direktreklam till nystartade företag i postnummerområde 74xxx-76xxx. Syftet med portalen är att i första hand ge nystartade företag möjlighet att marknadsföra sig gratis och på sikt även kunna få samma möjligheter som de stora företagen vad gäller kommunikation till sina kunder med kundklubbar osv.

SOA och Masterdata

Integration är just nu ett hett ämne och företag för flitiga diskussioner om målbilder för en principarkitektur. Målet är att all kommunikation ska ske via en ESB där alla förändringar i källsystemens data skickas i form av XML-meddelanden. Alla andra system som har ett intresse av förändringen prenumererar på meddelandet och tar del av förändringen. Tyvärr fokuserar företagen för mycket på tekniken med förkortningar som AQ, ESB, BPEL, BAM, SOAP, WS, XML, WSDL, XSD, JMS mm. Företagen borde i ett första skede fokusera mer på företagets data och organisation, allt handlar om data och hur data ska hanteras i företaget. Vi måste komma ihåg att tekniken bara är ett sätt att göra data tillgängligt. Det första steget enligt mig är att bestämma sig för vem som äger data och upprätta en organisation för Data Stewards som kontrollerar och övervakar attributen (definitioner, affärsregler, namn osv).

Införandet av en integrationshub (Enterprise MDM) med centraliserad data är ett första steg mot en lyckad integrationsarkitektur. I detta första steg finns mycket erfarenhet hos personer som har jobbat med datalager eftersom de stött på problemet med olika definitioner på samma begrepp i de källsystemen som integreras med datalagret.

Läs mer om masterdatahantering:
http://www.intelligententerprise.com/showArticle.jhtml?articleID=197004155&pgno=1

I nästa inlägg presenterar jag mina åsikter om datalagrets ETL-process och SOA.