Jeder, der sich mit BI auseinandersetzt – womöglich auseinandersetzen muss – kennt das Problem: praxisnahe Demodaten, die man auch öffentlich verwenden darf! Zugegeben, Microsoft hat die AdventureWorks-Beispieldatenbanken und –cubes, die eine Art “lingua franca” der BI-Jünger sind. Kein Bug wird ernstgenommen, den man nicht auf AdventureWorks nachvollziehen kann, und überraschend oft gelingt dies auch! Aber AdventureWorks ist lächerlich klein, und dafür ist das relationale und das Cube-Schema unnötig komplex; eben dafür gemacht, jedes Feature der Analysis Services irgendwo einmal vorführen zu können, ob sein Einsatz dort Sinn macht oder nicht.
Weitaus realistischer, vor allem in der Größe, ist der “Microsoft Contoso BI-Demodatensatz für die Einzelhandelsbranche”, der im Microsoft Download Center steht. 1,5 GB relationale Daten, und 500 MB Cube, das ist auch sehr spannend für Vergleiche zwischen PowerPivot und Analysis Services im Tabellenmodus oder im multidimensionalen Modus.
Öffnet man nun den dort mitgelieferten Analysis Services Cube in Excel, so erscheint seit dem Jahreswechsel eine hässliche Fehlermeldung, bevor man zugreifen kann: “Das &[2012]-Element wurde beim Analysieren der Zeichenfolge “[Date].[Calendar YQMD].[Calendar Year].&[2012]” nicht im Cube gefunden”.
Das bringt uns schon auf die richtige Spur: Der Cube “Operations” enthält im MDX Skript benannte Mengen der Datumsdimension wie etwa [This Year], die beispielsweise so definiert ist:
StrToMember(„[Date].[Calendar YQMD].[Calendar Year].&[„+ CSTR(YEAR([Measures].[Now])) + „]“)
…und das klappt natürlich nicht, wenn es in der Datumsdimension das Jahr 2012 noch nicht gibt! Es muss also dort hinein, und mit einigem Minuten SQL-Gefummel auf der Tabelle DimDate ist das leicht gelöst. Damit der Rest des Internets diese Abfrage nicht noch einmal schreiben muss, hier der SQL-Code, fertig zum guttenbergen:
SETLANGUAGEus_english
INSERTINTODimDate
SELECT DATEADD(year, 1,[Datekey])ASDatekey
,CONVERT(nvarchar(4),‚2012‘)+RIGHT([FullDateLabel], 6)ASFullDateLabel
,CONVERT(nvarchar(4),‚2012‘)+RIGHT([DateDescription], 6)AS[DateDescription]
,[CalendarYear]+ 1 ASCalendarYear
,LEFT(CalendarYearLabel, 8)+‚2‘AS[CalendarYearLabel]
,[CalendarHalfYear]+ 10 ASCalendarHalfYear
,[CalendarHalfYearLabel]
,[CalendarQuarter]+ 10 ASCalendarQuarter
,[CalendarQuarterLabel]
,[CalendarMonth]+ 100 ASCalendarMonth
,[CalendarMonthLabel]
,[CalendarWeek]+ 100 ASCalendarWeek
,[CalendarWeekLabel]
,[CalendarDayOfWeek]+ 1000 ASCalendarDayOfWeek
,DATENAME(weekday,DateKey)AS[CalendarDayOfWeekLabel]
,FiscalYear+ 1 ASFiscalYear
,LEFT([FiscalYearLabel], 14)+‚2‘AS[FiscalYearLabel]
,[FiscalHalfYear]+ 10 ASFiscalHalfYear
,[FiscalHalfYearLabel]
,[FiscalQuarter]+ 10 ASFiscalQuarter
,[FiscalQuarterLabel]
,[FiscalMonth]+ 100 ASFiscalMonth
,[FiscalMonthLabel]
,CASEDATEPART(weekday,DateKey)
WHEN 1 THEN‚WeekEnd‘
WHEN 7 THEN‚WeekEnd‘
ELSE‚WorkDay‘ENDAS[IsWorkDay]
,[IsHoliday]
,[HolidayName]
,[EuropeSeason]
,[NorthAmericaSeason]
,[AsiaSeason]
FROM[ContosoRetailDW].[dbo].[DimDate]
WHERECalendarYear= 2011
Danach die Datumsdimension UPDATE-verarbeiten, und wir können auch wieder mit Excel rauf. Mal sehen, wie lange es dauert, bis Microsoft diesen Lapsus im Download bemerkt und selber löst!
P.S. Eleganter wäre natürlich ein Skript, das die Faktendaten auch alle ein Jahr weiter nach vorne verschiebt… Wenn mir das einer schickt, veröffentliche ich das auch.