SSAS: Default-Eigenschaften von Dimensionen führen zu Warnungen
Frage
Antworten
-
Ich finde es nur schräg, dass es jetzt von vornherein auf "benutzerdefiniert" steht, obwohl der Benutzer an dieser Stelle noch gar nichts definiert hat.
Die ganzen Objekte in einem SSAS Projekt sind XML Dateien, deren Schema (inkl. was ist Standard) über XSD definiert sind und wenn Du den "Code" ansiehst, wirst Du feststellen, das selbst für SSAS 2014 die XSD aus 2003 sind (http://schemas.microsoft.com/analysisservices/2003/engine) und es ist verständlich einfacher ist, im Designer einen Workaround einzubauen und vom "Standard" auf "costum" zu ändern, als ein neues Schema zu definieren und überall Programmanpassungen vornehmen zu müssen.
Wie gesagt, die BPA stammen aus dem Project REAL, wo Microsoft für eine Großkunden ein SSAS Projekt aufgesetzt hat und ein "kleines bisschen" Performanzprobleme hatte. Deswegen wurden die SSAS Entwickler hinzugezogen und aus der Zusammenarbeit sind dann die Project REAL: Business Intelligence ETL Design Practices entstanden. Rigid hat Performanzvorteil, die sich bei solchen Großprojekten auswirken, bei kleineren eher nicht. Es gibt Dimensionen, wo man Rigid problemlos verwenden kann, z.B. Datumsdimensionen, es wird nie vorkommen, das der 10.10.2014 aus Hierachieebene 2014 nach 2013 wandert. Bei Orten kann man es nicht ausschließen, das sie z.B. einer anderen Gemeinde zugeordnet, auch wenn so was selten vorkommt.
Siehe auch Project REAL: Technical Overview und Project REAL: Analysis Services Technical Drilldown
Ja, es ist ein Übersetzungsfehler, deswegen verwende ich bevorzugt die englischen Versionen von Programmen:
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Aleksander Chalabashiev Montag, 13. Oktober 2014 06:32
- Als Antwort markiert uwdn Montag, 13. Oktober 2014 11:35
Alle Antworten
-
Zu Punkt 4: Ich habe auch die Version 2012 und wie ich bereits schrieb, werden mit den Voreinstellungen (Standard-Einstellungen darf man hier ja nicht schreiben) keine Warnungen generiert. Ich finde es nur schräg, dass es jetzt von vornherein auf "benutzerdefiniert" steht, obwohl der Benutzer an dieser Stelle noch gar nichts definiert hat. Wäre es nicht richtiger unter "Standard" auf "ReportAndStop" zu stehen? So widerspricht es irgendwie der Definition von "Standard" und "Benutzerdefiniert".
Zu Punkt 3: Dann ist es aber meines Erachtens falsch, an dieser Stelle eine "Warnung" zu generieren. "Warnungen" sind für diesen Umstand zu heftig. Es müsste dafür noch etwas drittes wie "Hinweis" geben. Nach meiner Vorstellung sind Warnungen etwas, was man, wenn man sich viel Mühe gibt, in einem Projekt vollständig eliminieren können sollte. Und wenn man sie doch stehen lässt, ist man nur zu faul und man sollte sich dann bewusst sein, dass man etwas macht, was nicht der Norm entspricht.
Bei Punkt 6 bin ich mir auch noch nicht im klaren, wann der Fehler auftritt und wann nicht. Bei meinem geerbten SSAS-Projekt, den ich in meinem vorherigen Posting beschrieben habe, tritt er, wir mir bisher scheint, etwas chaotisch auf.
Vielleicht habe ich aber noch Wissenslücken, wie ich eine Dimension richtig aufbaue. Ich habe mir nur zum Testen eine kleine Dimension gebastelt. Die zugrunde liegende Tabelle sieht wie folgt aus:
Bei der Erstellung der Dimension bin ich wie folgt vorgegangen:
Wenn ich dann die Dimension verarbeite, erhalte ich erst zwei Warnungen ("Definieren Sie Attributbeziehungen ggf. als 'Fest'." und "Vermeiden Sie sichtbare Attributhierarchien für Attribute, die in benutzerdefinierten Hierarchien als Ebenen verwendet werden.") und dann und die Fehlermeldung "Fehler im OLAP-Speichermodul: Ein doppelter Attributschlüssel wurde bei der Verarbeitung gefunden: Tabelle: CITY_DIM, Spalte: CITY, Wert: Berlin. Das Attribut ist 'CITY'."
Das kann ich verhindern, indem ich der CITY-Spalte als KeyColumn die ID-Spalte zuordne und die CITY-Spalte als Name-Column verwende. Hätte ich beim Design der Dimension anders vorgehen müssen, um diesen Fehler zu verhindern?
Noch zwei Fragen:
Wenn ich im Dimension-Assistenten den Attributen einen Attributstypen aus der Gruppe "Geografie" zuordne, wird mit zwei mal der Typ "Bundesland/Kanton" angeboten (siehe rote Pfeile). Handelt es sich dabei um einen Übersetzungsfehler?
Wenn ich, wie in meinem Beispiel, den Attributen derartige Attributstypen zuordne, gibt es dann einen Möglichkeit, sich automatisch einen Vorschlag für eine Hierarchie erstellen zu lassen? So etwas wäre doch theoretisch möglich, oder?
-
Ich finde es nur schräg, dass es jetzt von vornherein auf "benutzerdefiniert" steht, obwohl der Benutzer an dieser Stelle noch gar nichts definiert hat.
Die ganzen Objekte in einem SSAS Projekt sind XML Dateien, deren Schema (inkl. was ist Standard) über XSD definiert sind und wenn Du den "Code" ansiehst, wirst Du feststellen, das selbst für SSAS 2014 die XSD aus 2003 sind (http://schemas.microsoft.com/analysisservices/2003/engine) und es ist verständlich einfacher ist, im Designer einen Workaround einzubauen und vom "Standard" auf "costum" zu ändern, als ein neues Schema zu definieren und überall Programmanpassungen vornehmen zu müssen.
Wie gesagt, die BPA stammen aus dem Project REAL, wo Microsoft für eine Großkunden ein SSAS Projekt aufgesetzt hat und ein "kleines bisschen" Performanzprobleme hatte. Deswegen wurden die SSAS Entwickler hinzugezogen und aus der Zusammenarbeit sind dann die Project REAL: Business Intelligence ETL Design Practices entstanden. Rigid hat Performanzvorteil, die sich bei solchen Großprojekten auswirken, bei kleineren eher nicht. Es gibt Dimensionen, wo man Rigid problemlos verwenden kann, z.B. Datumsdimensionen, es wird nie vorkommen, das der 10.10.2014 aus Hierachieebene 2014 nach 2013 wandert. Bei Orten kann man es nicht ausschließen, das sie z.B. einer anderen Gemeinde zugeordnet, auch wenn so was selten vorkommt.
Siehe auch Project REAL: Technical Overview und Project REAL: Analysis Services Technical Drilldown
Ja, es ist ein Übersetzungsfehler, deswegen verwende ich bevorzugt die englischen Versionen von Programmen:
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Aleksander Chalabashiev Montag, 13. Oktober 2014 06:32
- Als Antwort markiert uwdn Montag, 13. Oktober 2014 11:35
-
Und was Deine Geo Dimension betrifft: Ortsnamen sind nicht eindeutig, Frankfurt z.B. gibt es in DE 2 mal und noch ein paar mehr im Ausland. Hier musst Du in der Tat die KeyColumn ändern, entweder auf die ID oder Du erweiterst die KeyColumn um ein weiteres Feld. Im AdventureWorks Cube wurde es so gemacht, das StateProvince hinzu genommen wurde, weil man davon ausgehen kann, das es je Province ein Ortsname eindeutig ist.
Den AdventureWorks kann man gut als Vorlage nehmen, um zu sehen, wie dort was umgesetzt wurde; gibt es hier: http://msftdbprodsamples.codeplex.com/
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Aleksander Chalabashiev Montag, 13. Oktober 2014 06:32
-
Dadurch, das Du die ID als Key verwendest, wird man in einem BI Tool wie Excel 2x Frankfurt untereinander stehen sehen, und man weiß was welcher ist.
Das sollte wohl heißen, "... man weiß nicht, was welcher ist." oder? In manchen Fällen mag es gehen, die Attribute so zu unterscheiden, aber da wo sich die Attribute aus den Eingaben der Anwender generieren ist das sicher nicht immer möglich. Ich habe inzwischen herausgefunden, warum meine alten OLAP-Cubes so oft "A duplicate attribute key has been found" melden. Vielleicht interessiert es jemand, der beim "googeln" (oder muss man hier sagen beim "bingen") nach dieser Meldung auf diese Seite stößt. Es gibt zwei Ursachen:
Die wesentliche. In unserer Analysis-Services-Installation war das Häkchen bei "Unterscheidung nach Groß-/Kleinschreibung" nicht gesetzt:
und in der Datenbank hatten wir in vielen Feldern Fälle, wo sich zwei Inhalte nur in der Groß-/Kleinschreibung unterscheiden, z.B.: "68, rue de Lille" und "68, Rue de Lille". Ein SELECT DISTINCT bringt da natürlich zwei unterschiedliche Datensätze aber für Analysis Services waren es doppelte Datensätze.
Ich kann mich nicht entsinnen, dass wir den Haken "Groß-/Kleinschreibung" bei der Installation bewusst rausgenommen haben. Ist das bei der Installation "Default" oder haben wir das versehentlich gemacht?
Und dann hatten wir noch Fälle, wo in einer numerischen Spalte sowohl NULL also auch 0-Werte waren, die von den Analysis Services offensichtlich ebenfalls als identisch angesehen werden -
Ein SELECT DISTINCT bringt da natürlich zwei unterschiedliche Datensätze aber für Analysis Services waren es doppelte Datensätze.
Ja,das "nicht" fehlte, ist korrigiert.
Wenn die Datenquelle hier 2 Datensätze liefert, dann nur weil die bereits Case Sensitive ist, für Insensitive ist auch dort das nur ein Datensatz.
Ja, Case Insensitive ist bei der Installation der Standard, aber wenn man alle Optionen durchsieht, kann man schon im Klartext lesen, wie die Collation definiert ist.
Olaf Helper
[ Blog] [ Xing] [ MVP]- Bearbeitet Olaf HelperMVP Freitag, 10. Oktober 2014 16:32
- Als Antwort vorgeschlagen Aleksander Chalabashiev Montag, 13. Oktober 2014 06:33
