Ich hatte ja gestern in meinem Blog geschrieben, wie man die deutsche KW im SQL Server berechnen kann. Wenn man darauf basierend eine Datumsdimension aufbaut, bieten sich natürlich zwei kanonische Hierarchien an:

• Jahr > Quartal > Monat > Tag
• Jahr > KW > Tag

Allerdings muss man dabei beachten, dass nur die erste eine echte Hierarchie ist. Die KW-Hierarchie ist nicht echt, da zwei Tage aus der selben KW in unterschiedlichen Jahren liegen können (z.B. 31.12.2008 und 1.1.2009 liegen beide in der KW 2009/01).

Deswegen darf man nicht einstellen, dass eine direkte Beziehung zwischen KW und Jahr besteht:

Also statt

muss es so aussehen (man beachte die Attributbeziehungen der KW):

Deswegen kann man natürlich trotzdem beide Hierarchien angeben:

(Das gelbe Dreieck gibt an, dass die Hierarchie nicht echt ist und deshalb nicht für Aggregationen verwendet werden kann)

Eine andere Alternative wäre, dass man unterschiedliche IDs und Namen für die KWs spendiert, die in einem anderen Jahr liegen, also beispielsweise:

• 31.12.2008 liegt in der KW 2009 / 01 (in 2008)
• 1.1.2009 liegt in der KW 2009 / 01

Damit wäre die KW-Hierarchie auch eine echte Hierarchie. Allerdings kann man dann die KW 2009 / 01 nicht mehr (so einfach) über Jahresgrenzen hinweg auswerten.

Bei mir kam es bei mehreren Installationen vor, dass die Entwicklung eines Cubes im Business Intelligence Development Studio (Visual Studio mit BI-Projektvorlagen) nicht vollständig funktionierte. Beim Klick auf den Tab zur Erstellung der berechneten Measures, stürzte entweder das Visual Studio komplett ab oder brachte eine Fehlermeldung.

Ein Forum-Eintrag in der MSDN besagt, dass die Dateien msmdlocal.dll und msmgdsrv.dll in den Verzeichnissen „%ProgramFiles%Microsoft Visual Studio 8Common7IDEPrivateAssemblies“ und „%ProgramFiles%Gemeinsame DateienSystemOle DB“ bzw. „%ProgramFiles%Common FilesSystemOle DB“ in unterschiedlichen Versionen vorliegen. Ich löschte (mit Backup 🙂 ) die Dateien in „%ProgramFiles%Gemeinsame DateienSystemOle DB“ und überschrieb sie mit den anderen Dateien. Dann funktionierte es wieder.

Bei mir trat das Problem reproduzierbar auf, als ich auf einem Rechner Excel 2003, Excel 2007 und SQL Server installierte. Die Reihenfolge der Installation spielte dabei keine Rolle.