http://community.qlikview.com/blogs/theqlikviewblog/2010/08/16/qlikview-is-associative-to-its-very-core

Detta är ett exempel på ett QlikView dokument som tillämpar den associativa tekniken. Gönmarkerad värde är det valda värdet, vitmarkerad värde är det som associeras till det valda och dem gråmarkerade värdena är det som inte associeras med det valda värdet.

Datumdimensionen

Kanske är datumdimensionen den vanligast förekommande dimensionen i en stjärnmodell.  Till skillnad från de flesta övriga dimensioner härstammar inte dimensionsmedlemmarna från ett källsystem. Medlemmarna är givna utifrån den gregorianska tideräkning som används i vår del av världen. Följaktligen är dimensionens utseende snarlikt mellan olika stjärnmodeller. Många BI-utvecklare anser därför att det smidigaste sättet att skapa datumdimensionstabellen är att kopiera den från en annan, redan existerande, stjärnmodell. Nedan tittar vi på ett alternativ till kopierametoden, en metod där datumdimensionen genereras i T-SQL kod.

CTE

Införandet av CTE´s i 2005 versionen av SQL server innebar att vi slapp ofoget med subselects och att vi fick bättre strukturerad och mer lättläst kod. Med CTE´s kom också möjligheten att skriva rekursiva uttryck.  Med rekursiva CTE uttryck är det möjligt att generera rader utan att referera till en tabell.

Följande enkla kodsnutt använder ett rekursivt CTE uttryck för att skapa en datumdimensionstabell.

DECLARE @tDateDay AS DATE = > ’1990-01-01′;

WITH dimDate_CTE AS (
SELECT dateDay = @tDateDay

UNION ALL

SELECT  dateDay = DATEADD(d,1,dateDay)
FROM dimDate_CTE
WHERE dateDay<= ’2019-12-31′)

SELECT
dimDateKey = ROW_NUMBER() OVER(ORDER BY dateDay),
dateID =CONVERT(INT,CONVERT(NVARCHAR(8),dateDay,112)),
dateDay = dateDay,
dateDayOfWeek = CONVERT(SMALLDATETIME,DATEPART(DW,dateDay)),
dateWeekNo = CONVERT(SMALLINT,DATEPART(WK,dateDay)),
dateMonthNo = CONVERT(SMALLINT,DATEPART(M,dateDay)),
dateQuarter = CONVERT(SMALLINT,DATEPART(Q,dateDay)),
dateYear = CONVERT(INT,DATEPART(YY,dateday))
INTO dimDate
FROM dimDate_CTE
OPTION (MAXRECURSION 11000)

Vi vill börja generera medlemmar från 1990-01-01. Första raden kod tilldelar detta värde till en lokal variabel. Notera att första raden kod endast fungerar i 2008 versionen eller senare av SQL server. I tidigare versioner existerar inte DATE datatypen. Det går inte heller, i tidigare versioner, att tilldela en lokal variabel ett värde på samma rad som den deklareras.

CTE uttrycket görs rekursivt genom att den andra SELECT frågan i en UNION ALL refererar till den första. Med andra ord, CTE uttrycket anropar sig själv. För varje anrop adderar vi en dag till startdatumet.

WHERE satsen i den andra SELECT frågan är vårt terminerings villkor. Vi vill fortsätta att addera en dag till startdatumet till det når 2019-12-31.

I den nedre SELECT frågan, som refererar till CTE uttrycket, skapar vi de dimensions attribut som vi finner relevanta. Alla attributen baseras på datum. Genererade rader lagras i tabellen dimDate.

Ett rekursivt CTE uttryck får som default endast anropa sig själv 100 gånger, detta för att man inte av misstag skriver uttryck som anropar sig själv i oändlighet. Sista raden kod är en query hint som tillåter rekursiva CTE uttryck, tillhörande denna SELECT sats, att anropa sig själva som mest 11000 gånger. Eftersom vi vet att det är 10958 dagar mellan vårt startdatum och vårt slutdatum känns 11000 som en bra siffra.

In MDX a query scoped member or calculated measure totaling the sales amount for male customers would look like this:

sum([DimCustomer].[Gender].&[M],[Measures].[Sales Amount])

Translated into a Qlikview set analysis expression we end up with the following:

=sum({$<Customer.Gender = {'M'}>} OrderDetails.[Sales Amount])

An MDX scoped member or calculated measure totaling the sales for all male customers in Germany and France would be defined using a crossjoin (note the * operator):

sum({[DimSalesTerritory].[SalesTerritoryCountry].&[France],
[DimSalesTerritory].[SalesTerritoryCountry].&[Germany]} *
[DimCustomer].[Gender].&[M], [Measures].[Sales Amount])

Using Qlikview set analysis the above would look like this:

=sum({$ < Customer.Gender = {'M'},
SalesTerritory.SalesTerritoryCountry =
{'Germany','France'}>} OrderDetails.SalesAmount)

A total excluding France and Germany would look like this in MDX:

sum(except([DimSalesTerritory].[SalesTerritoryCountry].children,
{[DimSalesTerritory].[SalesTerritoryCountry].&[France],
[DimSalesTerritory].[SalesTerritoryCountry].&[Germany]},
[Measures].[Sales Amount])

using Qlikview set analysis we get this:

=sum({$ <SalesTerritory.SalesTerritoryCountry =
-{'Germany','France'} >} } OrderDetails.SalesAmount)

An mdx query calculating the two years with the highest sales from the AdventureWorks cube would look like this:

SELECT
sum(TOPCOUNT([DimDate].[CalendarYear].[CalendarYear], 2,
[Measures].[Sales Amount]),[Measures].[Sales Amount])
ON 0
from [AWModel]

In Qlikview you would create a chart displaying Sales Amount by Calendar Year and then select Properties–>Dimension Limits and check the ”Select which values are displayed” check box so you can set the chart to display only the two largest values.

Or you can create a list box for Calendar Year next to your chart and type the following set analysis expression into the search box:

=rank(sum(OrderDetails.SalesAmount))<=2

and press enter. The two years with the largest sales are now selected by the expression you just created.

I think it is quite safe to assume that one of the reasons it is quite time consuming to replace an OLAP-cube with a Qlikview document or vice versa, are the syntactical differences.

Notes: I have used the sum function on the MDX-statements for the sake of clarity. It is actually not needed since the property of the measure itself is set to sum in the SSAS cube definition. If we substitute the ”$” for ’1′, our selections will be independent of any selections in the Qlikview document.

I MDX så ser en frågesammanhangsberoende medlem eller ett kalkylerat mått som räknar ut totalen för alla manliga kunder ut på följande vis:

sum([DimCustomer].[Gender].&[M],[Measures].[Sales Amount])

Översatt till ett set analys-uttryck så får vi följande:

=sum({$<Customer.Gender = {'M'}>} OrderDetails.[Sales Amount])

I MDX så skulle en frågesammanhangsberoende medlem eller ett kalkylerat mått som räknar ut totalen för alla manliga kunder i Tyskland och Frankrike använda sig av en crossjoin och se ut på följande vis:

sum({[DimSalesTerritory].[SalesTerritoryCountry].&[France],
[DimSalesTerritory].[SalesTerritoryCountry].&[Germany]}
* [DimCustomer].[Gender].&[M],
[Measures].[Sales Amount])

Ovanstående uttryck omvandlat till ett Qlikview set analys-uttryck ser ut så här:

=sum({$ < Customer.Gender = {'M'},
SalesTerritory.SalesTerritoryCountry
= {'Germany','France'}>} OrderDetails.SalesAmount)

En total som utesluter Tyskland och Frankrike ser ut så här om man använder sig av MDX:

sum(except([DimSalesTerritory].[SalesTerritoryCountry].children,

{[DimSalesTerritory].[SalesTerritoryCountry].&[France],
[DimSalesTerritory].[SalesTerritoryCountry].&[Germany]}, [Measures].[Sales Amount])

Ovanstående uttryck omvandlat till ett Qlikview set analys-uttryck ser ut så här:

=sum({$ <SalesTerritory.SalesTerritoryCountry = 
-{'Germany','France'} >} }
OrderDetails.SalesAmount)

En MDX-fråga som räknar ut de två åren med störst försäljning från AdventureWorks-kuben skulle se ut så här:

SELECT
sum(TOPCOUNT([DimDate].[CalendarYear].[CalendarYear], 2,
[Measures].[Sales Amount]),[Measures].[Sales Amount])
ON 0
from [AWModel]

I Qlikview skulle man lösa ovanstående med att skapa ett diagram som visar Sales Amount över Calender Year–>Dimension Limits och välj ”Select which values are displayed” check box så du kan ställa diagrammet till att visa endast de två största värdena.

En annan möjlig lösning är att skapa en list box och skriva följande set analys-uttryck i sökrutan:

=rank(sum(OrderDetails.SalesAmount))<=2

och trycka enter.

P.g.a. skillnaderna i syntax så är det ett rimligt antagande att det krävs en del jobb att ersätta en SSAS-kub med ett Qlikview-dokument eller vice versa.

Noteringar: Jag har använt sum-funktionen på MDX-uttrycken för att öka tydligheten. Uttrycket behövs egentligen inte då måttet är satt till att vara en sum i själva kubdefinitionen. Det är också värt att notera att vi kan byta ’$’ mot ’1’ i set analys-uttrycken om vi vill göra dem oberoende av gjorda val i Qlikview-dokumentet.

Den andra april bjuder SQLUG in till en heldag på Microsoft i Akalla där de går igenom SQL Server 2012 och Azure.

Detta får ni inte missa, speciellt med tanke på vem som är inbjuden talare!

Tidsschema:

08:30-09:00         Registrering, Kaffe
09.00-10.00         SQL Server 2012 Overview
10.00-10:45         T-SQL Deep-dive – What is new in SQL Server     2012 & SQL Azure
10:45-11:00         Paus
11:00-11:45         Making sense of your Unstructured data in SQL Server 2012
11:45-12:45         Lunch
12:45-13:45         Enterprise Information Management in SQL Server 2012, Keeping you data clean!
13:45-14:30         Developing Applications for SQL Azure
14:30-14:50         Paus
14:50-15:30         Performance tuning SQL Server 2012
15:30-16:00         Ask the experts

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032507143&culture=sv-SE

Vill påminna alla ni BI-fantaster att Microsoft har sin årliga Business Intelligence konferens i Stockholm den 27 Mars och den 28 Mars i Göteborg.

In och boka!

http://www.microsoft.com/sv-se/business/losningsomraden/business-intelligence-conference.aspx

Vi från Kentor kommer vara där hela dagen som åhörare, så är ni där är det bara att komma fram och säga hej.

I de två tidigare delarna har vi definierat BI som uppföljningen av en verksamhets affärsprocess. Samt identifierat de funktionella komponenter som krävs vid data-förberedelse i en enterprise BI miljö.

Vi kommer i detta inlägg identifiera resterande komponenter i vår enterprise BI-stack. Avslutningsvis använder vi den kompletta BI-stack modellen för att identifiera tre vanligt förekommande varianter av vår definition och vilka implikationer de tre varianterna har på en verksamhets BI-mognad.

Data användning

Återstående komponenter beskriver de verktyg som riktar sig till slutanvändaren.  Användare som genomför uppföljningen och har tillräcklig verksamhetskunskap för att dra slutsatser av den. Med ett samlingsnamn kallar vi dessa komponenter för data användnings komponenter.

Analys

Här placerar vi verktyg för den mer avancerade användaren. Användare med djup förståelse både för datamängden och verktyget. Utmärkande för analys verktyg är att de bara oftast är tillgängliga för ett begränsat antal användare som får möjlighet att fritt interagera med en avgränsad datamängd. Exempel på funktionalitet som analys verktyg stöder är datamining, statistisk analys och ad hoc querying.

Rapportering

Verktyg med ett stort antal mindre avancerade användare. Här krävs ingen djupare förståelse av vare sig verktyg eller datamängd. Användaren har begränsade möjligheter att interagera med datamängden. Exempel på rapporterings funktionalitet är statisk rapportering, scorecards och dashboards.

Hela BI stacken

Om vi samlar alla våra identifierade komponenter i samma stack modell ser den ut som nedan. Modellen är såklart väldigt översiktlig, men ger en bra introduktion till vad som krävs från en IT avdelning för att kunna erbjuda verksamheten en enterprise BI miljö.

BI mognad

Efter ganska många år som BI konsult och minst lika många olika kunduppdrag, har jag stött på en mängd olika sätt att implementera BI. Med hjälp av stack modell kan vi gruppera dem i tre dominerande definitioner. Min erfarenhet är att vilken av dessa tre definitioner en verksamhet ligger närmast, säger väldigt mycket om deras grad av BI mognad.

Skillnaden mellan de tre definitionerna ligger i vilken omfattning man valt att implementera komponenterna för data förberedelse. Ett arbete som de flesta verksamheter upplever som mycket svårt (det är inte lätt att komma överens om vad en kund är för något) och dyrt. Värdet som dataförberedelsen skapar ligger långt i framtiden och det är inte alla som har tålamodet och disciplinen som krävs.

Fristående datamarts.

Verksamheter som helt hoppar över data förberedelsen och kopplar sina dataanvändningsverktyg direkt mot källsystemen. Fördelen är att man uppnår resultat väldigt fort. Nackdelen är givetvis en väldigt splittrad bild av verksamheten. Detta angreppssätt, som funnits sen hålkortens tid, har fått ny vind i segeln i takt med att in memory tekniken utvecklats. Ur ett enterprise BI-perspektiv är fristående datamarts förkastligt, för varje nytt mart som byggs rör man sig längre och längre ifrån en helhetsbild av verksamheten.

Datawarehouse

Här har verksamheten insett nyttan av gemensam uppföljning av flera affärsprocesser. Man har byggt ett eller flera datawarehouse för detta ändamål. Varje datawarehouse har implementerat sina egna komponenter för dataintegration, datakvalité och masterdata management. Dessa warehouse drivs och förvaltas av för varandra fristående grupperingar inom verksamheten.

Enterprise BI

En verksamhet som implementerar all delar av BI-stacken som fristående komponenter och där även exekveringsdelen av IT-processen tar ett ansvar för att förbereda data för uppföljning. Alla viktiga affärsobjekt har minst en accepterad uppföljnings definition. Det går att följa upp hela verksamheten i ett verktyg. Man har skapat en ”single version of the truth”.

Jag har ännu inte sett en verksamhet som nått hela vägen. De flesta kämpar fortfarande med att röra sig från fristående datamarts mot datawarehouse.

Sist, men inte minst

BI är en process som bör drivas av affärsverksamheten och inte av IT, denna definition är kraftigt begränsad i att den endast beskriver vad som krävs av IT för att stödja verksamhetens BI-behov.

http://xkcd.com/936/

I del 1 påbörjade vi vårt mycket ambitiösa projekt med att definiera BI. Vi bestämde oss för att se BI som uppföljningen av en verksamhets affärsprocesser.

I detta andra inlägg ska vi påbörja arbetet med att skapa en modell som definiera de funktionella komponenter som bygger en värdeskapande enterprise BI miljö. En enterprise BI miljö syftar på en miljö som stöder en gemensam uppföljning av en verksamhets samtliga affärsprocesser, a single point of truth. BI´s heliga Graal. Modellen kommer att vara en komponent stack, där varje komponent placeras in efter sitt beroende förhållande till övriga komponenter.

Källsystem

Exekveringsprocessen matar uppföljningsprocessen med data. Utan exekvering ingen uppföljning. Därför placerar vi exekvering som grunden i vår komponent stack. Vi fortsätter vår trend av förenkling och definierar exekveringsprocessens funktionella komponenter som källsystem.

Data förberedelse

Affärsdata finns utspritt över en mängd olika källsystem runt om i verksamheten. Ofta finns det flera olika system som stöder samma del-affärsprocess.  För att skapa en samlad bild av verksamheten måste affärs data samlas in och göras enhetlig. Denna process kallar vi för data förberedelse (data preparation, ibland även kallat data management). Ansvaret för dataförberedelse delas mellan exekveringsprocessen och uppföljningsprocessen. Desto tidigare i exekveringsprocessen ett affärsobjekt anpassas till gemensamma definitioner desto enklare blir det att följa upp.

Vi delar in data förberedelse i fyra komponenter.

Data integration

Ansvarar för integrationen mellan exekvering och uppföljning. Oftast behöver en IT process två integrationskomponenter. En för integration mellan olika exekverings komponenter. Denna är meddelande orienterad och hanterar en transaktion eller ett affärsobjekt åt gången. Den andra integrationskomponenten stöder integrationen mellan exekvering och uppföljning. Denna är batch orienterad och hanterar stora mängder transaktioner eller affärsobjekt åt gången. Vår komponent syftar på den batch orienterade.

Data kvalité

Dålig data kvalité i källsystemen är oftast den största utmaningen i ett BI projekt. Dålig kvalité leder till att stora mängder affärsdata blir oanvändbar och att värdet av verksamhetens data historik minskar. Denna komponent ansvarar för att all affärsdata lever upp till de kvalitéts krav som ställs för en meningsfull uppföljning.

Master data management (MDM)

Samma affärsobjekt används ofta i en mängd olika källsystem. Oftast har dessa system lite olika definitioner på affärsobjekten. Ett klassiskt exempel är kund. Det är sällan som det finns en rådande definition av vad en kund är i alla källsystem. MDM komponenten har som uppgift att implementera en rådande definition av varje affärsobjekt och se till att all källdata anpassas till denna definition. I uppföljningssammanhang accepteras denna definition som den enda sanningen.

Datawarehouse

Modellerar data till att passa för de specifika krav som ställs på uppföljning. Modeller som är anpassade för analysera stora mängder data. I icke enterprise miljöer är ofta de underliggande komponenterna (Data integration, Data kvalité, Master Data Management) naturligt integrerade delar av ett datawarehouse. I icke enterprise miljöer existerar ofta flera datawarehouse som var för sig täcker olika delar av verksamhetens affärsdata.

BI stacken

Om vi placerar in ovan definierade komponenter i en och samma modell ser den ut som nedan. Vi kallar modellen för BI stacken.

I nästa inlägg…

Definierar vi de översta nivåerna i BI stacken, komponenter för data användning. Samt tittar på några andra, mindre omfattande men vanligt förekommande, definitioner av BI och vilka implikationer dessa varianter har på en verksamhets IT mognad.