Als je de LIKE operator wilt gebruiker in bijvoorbeeld de TABLIX ga je naar Tablix properties, Filter:

Bij Expression vul je in op welke kolom in je dataset je wilt filteren.  Daarna kies je bij Operator de LIKE. Bij de expressie (klik op het knopje Fx) ga je de volgende expressie invoeren

= “*” & “tekst” & “*”

Alle records met het woord “tekst” worden nu gefilterd.

Alles is zo eenvoudig als je het weet

Dit boek is een zelfstudie voor Pentaho Data Integratie en geeft praktijkervaring in het samenstellen van een datavault architectuur. De opdrachten resulteren in een werkende oplossing die als basis kan worden gebruikt voor een BI oplossing in uw eigen omgeving. Het boek is te koop via: http://bit.ly/datavaultimplementeren U kunt dit boek gratis ontvangen als hardcopy en als PDF. Vul het onderstaande formulier in en u ontvangt het boek tijdens een persoonlijk gesprek gratis.

Klik hier voor de website.

The SQL Server 2012 Developer Training Kit includes technical content including labs, demos and presentations designed to help you learn how to develop SQL Server 2012 database and BI solutions. New and updated content will be released periodically and can be downloaded on-demand using the Web Installer Preview.

Deze plugin ondersteunt Google+, Twitter, Facebook Like/Share en ook de layout is prima. Je kunt de plugin bovenaan berichten en onderaan berichten plaatsen. Daarnaast kun je hem ook op de frontpage toevoegen.

Inleiding

Bij stermodellen is het gebruikelijk dat de mate van detaillering, ook wel bekend als “Grain”, binnen een feit/fact is vastgelegd op datum, het laagste level binnen de tijd dat opgeslagen wordt (tijd kan ook nog maar is nu niet relevant). Stel dat een fact een grain heeft op weekniveau. Je zult dan gaan proberen een koppeling te krijgen met de datumdimensie. Dit kun je doen door het weeknummer om te zetten naar een DatumID (SELECT 201001 * 100 + 01). Dit werkt veruit het eenvoudigst. Bij het rapporteren van managementinformatie werkt dit prima voor transactiefeiten die aggregeerbaar zijn. De som van de omzet van alles bestellingen over de dagen binnen een maand is immers de omzet van een maand. Maar wat te doen als je feiten moet rapporteren die je niet makkelijk kunt optellen? Met andere woorden, de totalen van maand 1 + 2 + 3 zijn niet de totalen van kwartaal 1. Denk hierbij aan “Aantal werkende mensen per week”. Dit is een feit dat niet op te tellen is. Toch wil je deze informatie in rapportages kunnen tonen op kwartaal, maand, jaar, week, etc. en bij voorkeur ook nog in een trendrapportage. De oplossing is een periode dimensie maken in combinatie met een snapshotfeit. Dit artikel geeft de voordelen, de werking en een AdventureWorks voorbeeld. Als bijlage van dit artikel zijn de scripts te vinden om een Periode-dimensie te bouwen.

Opbouw Periode-dimensie

Een Periode-dimensie bevat voor iedere periode een record. Ieder periode maakt deel uit van een periode-grootheid. Een periodegrootheid kan een maand of een week zijn. De periode-dimensie bevat in mijn geval 102 records voor het jaar 2010. Voor weken zijn er 52 records, voor jaar een record, voor maand 12 records, etc.

Verder zijn de volgende kolommen belangrijk:

PeriodeID: unieke sleutel
Jaar: het jaar waar de periode in valt
PeriodeNummer: jaar + periodenummer
BeginDatumID: eerste dag van de periode
EindDatumID: laatste dag van de periode
PeriodeGrootheidID: grootheid van de periode
VorigJaar1PeriodeID, PeriodeID van de periode een jaar terug
VorigePeriode01PeriodeID: PeriodeID van de vorige periode
VorigePeriode02PeriodeID: PeriodeID van twee periodes terug
VorigePeriode03PeriodeID: PeriodeID van drie periodes terug
VorigePeriode04PeriodeID: PeriodeID van vier periodes terug
VorigePeriode05PeriodeID: PeriodeID van vijf periodes terug
VorigePeriode06PeriodeID: PeriodeID van zes periodes terug

PeriodeNummer is handig om later het resultaat van een periode-feit aan een ander feit te koppelen die bijvoorbeeld op week is geaggregeerd omdat PeriodeNummer hetzelfde is als WeekNummer. De Vorige ID’s zijn uitermate handig om later vergelijkingen te doen ten opzichte van de vorige periode. Dit kun je uitbreiden met meer velden (functie bijgesloten) met bijvoorbeeld deze SQL:

UPDATE DimPeriode SET VorigePeriode01PeriodeID = dbo.GetParallelPeriodID(PeriodeID, -1) , VorigePeriode02PeriodeID = dbo.GetParallelPeriodID(PeriodeID, -2) , VorigePeriode03PeriodeID = dbo.GetParallelPeriodID(PeriodeID, -3) , VorigePeriode04PeriodeID = dbo.GetParallelPeriodID(PeriodeID, -4) , VorigePeriode05PeriodeID = dbo.GetParallelPeriodID(PeriodeID, -5) , VorigePeriode06PeriodeID = dbo.GetParallelPeriodID(PeriodeID, -6)

Sleutelopbouw

De primaire sleutel van de tabel is PeriodeID. Deze is uniek. De sleutel is opgebouwd met bepaalde logica: Jaar + PeriodeGrootheid + PeriodeNummer.

Voorbeeld Week 12-2010: 2010112
Voorbeeld Maand 8-2010: 2010208

Voor iedere periodegrootheid en iedere periode is er een record aanwezig. De periodegrootheden die onderkent zijn:

• Week
• Maand obv. Kalender
• Kwartaal obv. Kalender
• Periode obv. 444 Weekverdeling
• Maand obv. 445 Weekverdeling
• Kwartaal obv. 445 Weekverdeling
• Jaar obv. Kalender
• Jaar obv. Weekverdeling
• Dag

Gebruiksvoorbeelden

De periode-dimensie kun je combineren met een organisatiestructuur. Zo krijg je combinatie van alle periodes en alle organisatie-eenheden. Vervolgens kun je aan deze combinaties waarden hangen, bijvoorbeeld KPI’s. Het plaatje ziet er ongeveer zo uit:

Business-vraagstukken die je kunt beantwoorden:

• Aantal medewerkers die bij ons bedrijf werken. De gebruiker moet met behulp van een parameter kunnen aanpassen hoe hij de data wilt bekijken. Hij moet dit per week, per maand, per kwartaal en per jaar kunnen bekijken. Je zult nu de meetwaarde “aantal medewerkers” moeten gaan bepalen op iedere periodegrootheid die men wenst. 
• Ranking; hoe verhoud mijn afdeling zicht ten opzichte van andere afdelingen (omzet kpi delen door aantal fte)
• Omzetgegevens afzetten tegen een periode een jaar terug: je hoeft geen grote tabellen meer door te worstelen en SUM functies te gebruiken, je slaat de omzetgegevens in alle mogelijke combinaties op in een KPI tabel die gebruik maakt van DimPeriode
• Trendlijnen laten zien: trendlijnen performen vaak slecht in combinatie met SQL (zonder OLAP). Verschillende Group By en SUM functies verstoren de performance. Met een KPI tabel in combinatie met DimPeriode heb je dit probleem minder.

Voorwaarde voor een juiste werking van dit mechanisme is dat je redelijk complexe SQL nodig hebt om de nieuwe feiten te gaan vullen. Dit hoeft niet altijd zo te zijn. Om de werking en de kracht van de tabel te demonstreren geef ik enkele voorbeelden van SQL op AdventureWorksDWH.

Vraagstuk: aantal klanten die een internetsale hebben geplaatst, opgesplitst in weken, maanden en jaar.

– Ik doe er even 6 jaar bij optellen omdat in DimPeriode niet alle jaren

– aanwezig zijn.

SELECT DP.PeriodeID

,SUM(FIS.IsOrder) AS AantalBestellingen

FROM (

SELECT CONVERT(VARCHAR, DT.FULLDATEALTERNATEKEY, 112) + 60000 AS OrderDatumID

,1 AS IsOrder

FROM FACTINTERNETSALES AS FIS

INNER JOIN DIMTIME AS DT ON FIS.ORDERDATEKEY = DT.TIMEKEY

WHERE CONVERT(VARCHAR, DT.FULLDATEALTERNATEKEY, 112) > 20040000

) AS FIS –Hier is de truuk, bepaal in welke periodes een bestelling valt!

INNER JOIN DimPeriode AS DP ON FIS.OrderDatumID BETWEEN DP.BeginDatumID

AND DP.EindDatumID

INNER JOIN DimPeriodeGrootheid AS DPG ON DP.PeriodeGrootheidID = DPG.PeriodeGrootheidID

GROUP BY DP.PeriodeID

ORDER BY PeriodeID

Wat je in de afbeeldingen ziet zijn alle periodes in 2010 met het aantal klanten die een internetsale hebben geplaatst. Zo heb ik er twee uitgepikt om toe te lichten hoe het werkt.

De uitkomst van deze SQL kun je in een nieuwe tabel stoppen, bijvoorbeeld FactPeriodeKPI. Een Measure binnen FactPeriodeKPI wordt dan AantalInternetBestellingen. Op deze manier kun je diverse KPI’s / Measures opslaan.

Vraagstuk: aantal unieke klanten per sales territory, afgezet over de tijd

Dit is een leuke een. Dit is een typische KPI die niet aggregeerbaar is. Het aantal klanten binnen een week kun je niet optellen om ze op maand te zien. Je moet deze waarden dus per periode uitrekenen. De truuk is om te kijken welke klanten een bestelling hebben per datum. Als een klant op een dag twee bestellingen heeft is dit niet relevant voor de telling, het gaat immers om het aantal unieke klanten per dag. Vervolgens ga je dit koppelen aan de periodes door te bepalen of een datum in een periode valt. Daar overheen doe je een COUNT DISTINCT om het aantal unieke klanten te bepalen. Het wordt helemaal een feest als een klantstructuur ook hierarchieen bevat. Een klant is alleen een klant op het hoogste niveau (bijv concern), alle onderliggende nummers moeten niet als uniek worden geteld. Dit laat ik even buiten de scope. Op naar de SQL:

SELECT DP.PeriodeID

,DPG.Naam

,DP.PeriodeNummer

,COUNT(DISTINCT FIS.CUSTOMERKEY) AS AantalUniekeKlanten

FROM (

– Aantal Unieke klanten per orderdatum

SELECT DISTINCT

CONVERT(VARCHAR, DT.FULLDATEALTERNATEKEY, 112) + 60000 AS OrderDatumID

,DC.CUSTOMERKEY

FROM FACTINTERNETSALES AS FIS

INNER JOIN DIMTIME AS DT ON FIS.ORDERDATEKEY = DT.TIMEKEY

INNER JOIN DIMCUSTOMER AS DC ON FIS.CUSTOMERKEY = DC.CUSTOMERKEY

WHERE CONVERT(VARCHAR, DT.FULLDATEALTERNATEKEY, 112) > 20040000

) AS FIS –Hier is de truuk, bepaal in welke periodes een bestelling valt!

INNER JOIN DimPeriode AS DP ON FIS.OrderDatumID BETWEEN DP.BeginDatumID

AND DP.EindDatumID

INNER JOIN DimPeriodeGrootheid AS DPG ON DP.PeriodeGrootheidID = DPG.PeriodeGrootheidID

GROUP BY DP.PeriodeID,DP.PeriodeNummer, DPG.Naam

ORDER BY PeriodeID

Bovenstaand resultaat laat de kracht van DimPeriode zien. Zoals je ziet zijn er in de eerste drie maanden een aantal unieke klanten. Daaronder zie je het kwartaalresultaat. Het kwartaalresultaat zijn het aantal unieke klanten in het eerste kwartaal. Dit is geen som van de eerste drie waarden want dan zou je op 5392 klanten uitkomen.

De laatste die ik behandel is het aantal verloren klanten T.O.V. Periode -1, -2, -4, -4. Dit doe ik binnenkort in dit artikel als ik meer tijd heb.

{attachments}

Voor het genereren van de DDL (tabellen) en ETL (laadprocessen) heb ik gebruik gemaakt van de (open-source) tool Quipu welke sinds 1 juli gratis te downloaden is. Deze tool neemt veel werk uit handen door de zaken die normaal veel tijd kosten te automatiseren. Quipu genereert het datamodel voor je (data vault) en de sql om te laden (ETL). Ook kun je views laten genereren die de inhoud van de Data Vault laten zien op een bepaald moment. Het mooie van Data Vault is dat alle ETL stappen uit substappen bestaan die allemaal los zijn op te starten. Quipu genereert alle SQL-statements voor je. Deze SQL wordt opgeslagen in de database van Quipu. Standaard slaat Quipu alles op in zijn Jetty Database. Je kunt dit veranderen zodat hij het in SQL Server opslaat. Dit heb ik zelf ook gedaan zodat ik in de tabellen kon kijken wat er gebeurde. Dit kun je voor elkaar krijgen door een lokale systeemvariabele aan te maken en deze te laten verwijzen naar een properties bestand op de schijf. In deze file staat een verwijzing naar de SQL database (zie documentatie). Zodra de ETL is gegenereerd moet je zelf creatief zijn om hier iets van te bakken. De ETL zijn eigenlijk gewoon SQL-statements die data verplaatsen. Je kunt hier een stored procedure van maken of een SSIS (SQL Server Integration Services) package. Het genereren van deze zaken zit (nog) niet in de versie die ik getest heb (1.03). Alles wat Quipu genereert is volgens de Datavault standaard in ANSI92 SQL. Dit werkt ook onder Sql Server 2005+.

Alle DDL en ETL kun je downloaden onderaan dit artikel.

Staging Area Adventureworks
Alvorens het Data Vault model geladen wordt dient de data in een Staging Area aanwezig te zijn. Bovenstaande tool genereert staging area tabellen voor je en ook de ETL, dit scheelt weer een berg werk. Nadat ik het schema van AdventureWorks heb geselecteerd stel ik wat opties in:

Ik heb ingesteld dat ik de staging area tabellen wil leeggooien voordat de data wordt geladen en dat ik een full load wil. De eerste zorgt voor extra truncate commando’s tussen de laadstatements in. De tweede laadt altijd alle records vanuit de bron. Als Delta Load wordt aangevinkt worden alleen wijzigingen in de bron geladen. Vervolgens kan ik de staging area DDL genereren. Maak eerst een database aan, bijvoorbeeld “Adventureworks_stg”. Let op de collation (de collation moet hetzelfde zijn als de brondatabase van Adventureworks).

Voer nu dit script uit: 1.0_Create_Staging_Area.sql

Let op: maak eerst de user defined datatypen en schema’s aan, deze zitten ook standaard in Adventureworks. Als je deze niet aanmaakt krijg je foutmeldingen.

CREATE TYPE [dbo].[NAME] FROM [nvarchar](50) NULL
CREATE TYPE [dbo].[FLAG] FROM [bit] NOT NULL
CREATE SCHEMA Production

Vervolgens genereren we de ETL om de Staging Area op te vullen.

Voer dit script uit: 2.0_Populate_Staging_Area.sql

Voer de scripts om de beurt uit. Als het goed is worden er tabellen aangemaakt in AdventureWorks_stg en daarna gevuld met het ETL script. We hebben nu een staging area en ETL.

Data Vault AdventureWorks
We willen nu een datamodel genereren en laadprocessen om een Data Vault te laden. Ik ga niet teveel in op de stappen die ik heb doorlopen om tot het model te komen. Ik heb het model laten genereren door bovengenoemde tool. De meeste settings heb ik standaard gelaten. Het voordeel van AdventureWorks is dat het een vrij “mooie bron” is. Relaties zijn aanwezig, tabelnamen zijn duidelijk. Normaal is dit natuurlijk niet zo. Daarnaast heb ik wat naming conventions mbt tabelnamen. De sleutels heten bijna altijd hetzelfde als de tabel met een suffix.

Hub: NaamTabel_h
Link: TableA_TableB_l  <- volgorde van naamgeving belangrijk, zo wordt de naam van de link tussen productmodel en product: Product_ProductModel_l
Satelite op hub: NaamTabel_s
Satelite op link: NaamTabel_l_s
Surrogatkey hub:Hubnaam_hid
Surrogatkey link: Linknaam_lid

Ik heb gemerkt dat dit prettig leest. Je mag volgens de theorie ook de suffix als prefix toevoegen, alleen vind ik dit beter werken. Hieronder zie je een screenshot van mijn instellingen op het schema “Production”. Zoals je ziet gebruik ik maar een paar tabellen in dit voorbeeld.

Vervolgens laat ik de tool het Data Vault model aanmaken. Als target schema stel ik in “dbo”. Zo worden alle tabellen netjes dbo.tabelnaam genoemd. Daarna rename ik de tabellen en veldnamen naar de standaarden die hierboven staan voor betere leesbaarheid.

Notitie:
De link tussen product en Bill of Materials komt twee keer voor:
BillOfMaterials_Product_Component_l
BillOfMaterials_Product_ProductAssembly_l

Dit zijn twee aparte links. In het bronmodel zie je ook dat dit twee relaties zijn. Ik weet niet precies hoe Data Vault naming convention toepast bij links tussen dezelfde tabellen maar met een nadere rol.

In Quipu ziet mijn model er nu zo uit:

Voer nu dit script uit: 3.0_Create_Data_Vault_Data_Model.sql

Maak vervolgens de datatypen weer aan die ook in AdventureWorks worden gebruikt.

CREATE TYPE [dbo].[NAME] FROM [nvarchar](50) NULL
CREATE TYPE [dbo].[FLAG] FROM [bit] NOT NULL

Voer nu dit script uit: 4.0_Populate_Data_Vault_Model_Script.sql

Let op, ik gebruik geen constraints in de Data Vault.

Tot slot kun je met Quipu nog wat views aanmaken die de stand van de Data Vault weergeven. Dit zijn de actuele views, laatste stand en point in time. Deze vind je ook bij de scripts:

5.0_Views_Last.sql
6.0_Views_Actual.sql
7.0_Views_Point_In_Time.sql

Dat was een voorbeeld van het maken van een kleine Data Vault op AdventureWorks Database van Microsoft. Ik hoop dat dit voorbeeld duidelijk maakt hoe een Data Vault is opgebouwd qua structuur en hoe de laadprocessen eruit kunnen zien. Als je een opmerking of vraag hebt, post een bericht

Na de introductie werd er veel nadruk gelegd op diverse uitdagingen die men in de projecten tegenkwam. Opvallend was dat dit voornamelijk technische zaken waren. Bijvoorbeeld bij Vektis het onderkennen van goede bronsleutels wanneer er patiëntgegevens door verschillende partijen worden aangeleverd (hoe herken ik dan een unieke patiënt?). Bij Tele2 lag de uitdaging in het enorm aantal requirements, ruim 3000, en deze vertalen in een beknopt aantal functiegebieden.

Het leuke van dergelijke lezingen vind ik altijd dat het jezelf aan het denken zet. Zo kwam Dan Linstedt op een gegeven moment met de uitspraak “A single version of the truth doesn’t exist”. Maar wat doen wij dan alle jaren met onze Datawarehouses? Precies, het creëren van de waarheid. Maar wat is dan de waarheid, wie bepaald wat de waarheid is? Dan gaf een leuk voorbeeld dat ook goed blijft hangen. Hij had het over een lamp met een gele bol erin. Als er iemand anders een blauwe bol indraait krijg je een ander kleur licht. Vervolgens komt er weer iemand anders die er een groene bol indraait. De bol was dan de waarheid en het verwisselen van de bol waren de business rules. Wat hij hiermee probeerde te zeggen was dat de business bepaalt wat de waarheid is. Zodra de business verandert of zodra er nieuwe managers worden aangesteld die gebaat zijn bij een andere waarheid dan zal deze veranderen. Een waarheid binnen een datawarehouse zijn regels op een bepaald moment voor een bepaald persoon.

Data Vault speelt hier goed op in door ruwe data vast te houden. De data zoals het wordt opgeslagen in de diverse bronsystemen. De waarheid is zoals hij in de systemen was opgeslagen zonder dat er data wordt veranderd. Met veranderen bedoel ik opschonen en transformeren. Hierdoor is de data altijd 100% auditable/traceable. Daarbij was nog de vraag of je bijvoorbeeld een datumveld dat als tekst is opgeslagen mag omzetten naar een datumveld, het antwoord werd in het midden gelaten.

Om data vervolgens naar de waarheid “Version of the truth” om te zetten zegt Dan gebruik te maken van Business Vaults in het ruimste begrip des woords. Dit hoeft niet perse een fysieke datamart te zijn zoals een Kimball model, een olap kubus of een datavault met geschoonde data. Business Vault is een heel ruim begrip. Het omvat eigenlijk alles wat op de datavault is gebouwd en wat de data omzet in betekenisvolle businessdata. Dit kan ook een Excelsheet zijn met business rules (met bijvoorbeeld powerpivot) maar ook een fysieke database, gemodelleerd volgens de kimball methodiek.

Na wat research op internet wat een betere source is voor een Reporting Services Rapport zijn hieronder de voordelen beschreven voor het gebruik van Stored Procedures .

Kortom, gebruik Stored Procedures als bron voor je rapport. Leer jezelf aan bepaalde naming conventions te gebruiken voor deze procedures, bijvoorbeeld spcRptRapportOverVerzuim. Wanneer het aantal rapporten groeit en het aantal procedures staan deze dingen netjes onder elkaar op categorie.