Benutzer mit den meisten Antworten
SSAS - "Attributschlüssel wurde bei der Verarbeitung nicht gefunden" bei Datums-Attribut

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].ydaIch 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
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
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Administrator Montag, 18. April 2016 07:20
- Als Antwort markiert Aleksander Chalabashiev Montag, 25. April 2016 13:42
-
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- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Administrator Montag, 18. April 2016 07:19
- Als Antwort markiert Aleksander Chalabashiev Montag, 25. April 2016 13:42
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
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Administrator Montag, 18. April 2016 07:20
- Als Antwort markiert Aleksander Chalabashiev Montag, 25. April 2016 13:42
-
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
-
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- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Administrator Montag, 18. April 2016 07:19
- Als Antwort markiert Aleksander Chalabashiev Montag, 25. April 2016 13:42