none
SSAS - "Attributschlüssel wurde bei der Verarbeitung nicht gefunden" bei Datums-Attribut RRS feed

  • Frage

  • Hallo *.*,

    ich erhalte in meinem Test-Projekt aktuell immer diese Meldungen:

    Fehler im OLAP-Speichermodul: Der Attributschlüssel wurde bei der Verarbeitung nicht gefunden: Tabelle: dbo_Vorgang_x0024_Projektkopf, Spalte: ProjektDatumA, Wert: 00:00:00. Das Attribut ist 'Datum'. Fehler im OLAP-Speichermodul: Der Datensatz wurde ausgelassen, da der Attributschlüssel nicht gefunden wurde. Attribut: Datum der Dimension: Datum - A aus Datenbank: Test2016, Cube: Vorgangsverwaltung, Measuregruppe: Vorgangskopf, Partition: Vorgangskopf, Datensatz: 677.

    Bei der Spalte "ProjektDatumA" handelt es sich SQL-seitig um eine Datetime-Spalte, die jedoch nur mit Datum gefüllt ist. Die Uhrzeit wird also automatisch auf 00:00:00 gesetzt. Es sind auch NULL-Werte enthalten.  Führe ich direkt im SSMS eine einfache JOIN-Abfrage durch, erhalte ich die erwartete Anzahl an Ergebnissen:

    SELECT [Vorgang$Projektkopf].nummer, [Vorgang$Projektkopf].yda, [dimZeit].PS_Datum
      FROM [Datenbank].[dbo].[Vorgang$Projektkopf]
      JOIN [dimZeit] ON [dimZeit].PS_Datum = [Vorgang$Projektkopf].yda

    Ich könnte jetzt in der DSV einen CAST auf Date durchführen, aber die Ergebnisse werden dann immer noch mit Uhrzeit angezeigt. Ein CONVERT müsste in VARCHAR(10) stattfinden, aber dann ist es kein Datum mehr, was andere Probleme nach sich zieht.

    Hat hier jemand eine Idee, was mein Problem sein könnte und was ich da am besten machen (oder auch nur probieren) kann?

    VS2015, SQL Server 2012


    MCTS (70-642), MCP

    Dienstag, 12. April 2016 09:59

Antworten

  • Hallo Markus,

    was ich tun würde:

    1.) In der Dimension Zeit eine Spalte Zeit_ID einführen, Typ Integer. Diese Spalte ist die numerische Repräsentation des Datum, also z. B. 20160413. Diese Spalte wird Primary Key und verknüpft mit der Faktentabelle, wo auch die Daten als Integerwert abgelegt sind, was die Füllung der Faktentabelle vereinfacht, da Du nicht erst die ID aus der Tabelle Zeit ermitteln musst.

    Select cast(convert(varchar(10), GETDATE(), 112) as int);

    Die weiteren Spalten in der Dimension Zeit sind dann das Datum als Date, Jahr, Woche, Monat, Quartal, usw.

    2.) Vermeide NULL-Werte. Ich habe anstelle von Null z. B. den 01.01.1800 verwendet.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Mittwoch, 13. April 2016 06:53
  • Noch einfacher:

    da Uhrzeit ja nicht verwendet wird, auf den date-Datentyp wechseln

    • spart 1 byte
    • erlaubt Datumsfunktionen
    • und natürlich auch Join etc

    Dummy-Werte sind ein in Datawarehouses übliches Konstrukt. Andernfalls muss man den Datensatz komplett verwerfen, da er ja nicht logisch eingebunden werden kann.

    Also: Daten vorab bereinigen, ggfl löschen, oder eben doch "aufheben" und sich dafür ein Date-bucket überlegen


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Donnerstag, 14. April 2016 11:17

Alle Antworten

  • Hallo Markus,

    was ich tun würde:

    1.) In der Dimension Zeit eine Spalte Zeit_ID einführen, Typ Integer. Diese Spalte ist die numerische Repräsentation des Datum, also z. B. 20160413. Diese Spalte wird Primary Key und verknüpft mit der Faktentabelle, wo auch die Daten als Integerwert abgelegt sind, was die Füllung der Faktentabelle vereinfacht, da Du nicht erst die ID aus der Tabelle Zeit ermitteln musst.

    Select cast(convert(varchar(10), GETDATE(), 112) as int);

    Die weiteren Spalten in der Dimension Zeit sind dann das Datum als Date, Jahr, Woche, Monat, Quartal, usw.

    2.) Vermeide NULL-Werte. Ich habe anstelle von Null z. B. den 01.01.1800 verwendet.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Mittwoch, 13. April 2016 06:53
  • Hallo Christoph,

    den ersten Teil hatte ich bereits so umgesetzt, aber schön zu sehen, dass das wohl richtig war :)

    Das zweite hatte ich schon selbst überlegt, aber eigentlich möchte ich genau das vermeiden. Wenn die Daten dann im nächsten Schritt in einem Bericht aufbereitet werden, erscheint dieses Datum - sofern ich es nicht wieder rausfiltere - ebenfalls.


    MCTS (70-642), MCP

    Donnerstag, 14. April 2016 09:38
  • Noch einfacher:

    da Uhrzeit ja nicht verwendet wird, auf den date-Datentyp wechseln

    • spart 1 byte
    • erlaubt Datumsfunktionen
    • und natürlich auch Join etc

    Dummy-Werte sind ein in Datawarehouses übliches Konstrukt. Andernfalls muss man den Datensatz komplett verwerfen, da er ja nicht logisch eingebunden werden kann.

    Also: Daten vorab bereinigen, ggfl löschen, oder eben doch "aufheben" und sich dafür ein Date-bucket überlegen


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Donnerstag, 14. April 2016 11:17