Reach for the Star – DeltaMaster ETL auf Star-Schema umbauen

Ob man ein OLAP-Modell auf einem Snowflake- oder Star-Schema aufsetzt, ist fast schon eine philosophische Frage, auf die es keine eindeutige Antwort gibt. Es gibt Argumente für das eine wie für das andere Modell. Kürzlich gab es im Rahmen einer Performanceoptimierung in einem Hybridplanungssystem ein schlagendes Argument für ein Star-Schema – die SQL-Server-interne Star-Join-Optimization. Scheinbar setzt Microsoft wieder öfter auf Star-Schemas und hat deren Verwendung intern für Abfragen optimiert. Die Auswirkungen (unter anderem auf die RealTimeOlap-Abfragen) sind deutlich spürbar. Bleibt die Frage wie man mit DeltaMaster ETL zu einem Star-Schema kommt? Schließlich wird hier immer ein Snowflake-Schema erstellt. Überraschenderweise ist der Weg dahin gar nicht so weit – zumindest wenn man auf Hybridplanung setzt. Glaubt Ihr nicht? Dann lest und staunt. weiterlesen…

CSI Nürnberg – Data Profiling im Einsatz

Unsere Beratungsmannschaft ist schnell – sehr schnell. In unseren 2-Tages-Workshops beweisen wir das regelmäßig und begeistern Interessenten und Kunden gleichermaßen. Mit unserer DeltaMaster Suite sind wir sowohl schnell beim Modellbau als auch beim späteren Berichtsbau.

Dennoch treibt mich schon seit langer Zeit die Frage um, wie wir hier noch besser und schneller werden können. Vor allem wie wir nerviges Try-and-Error auf fremden Datenbeständen loswerden. Intensive Diskussionen mit Dr. Nicolas Bissantz und diverse Webrecherchen haben mich schließlich auf die Idee des Data Profiling gebracht. Wie genial wäre es, wenn wir unsere DeltaMaster-Visualisierungstechnik bereits beim Beurteilen der Quelldaten nutzen könnten. Damit würden wir viele Schleifen beim Modellbau vermeiden und könnten bereits vorher Fehler identifizieren und Klippen umschiffen.

Ein paar Tage später war der Data Profiler geboren und die Ergebnisse begeistern mich noch immer. Da das Werkzeug aktuell erstmal als Stand-alone-Lösung existiert, sind ein paar manuelle Schritte für den Einsatz notwendig. Diese werden im vorliegenden Beitrag erläutert und ein paar Beispiele für die Erkenntnisse aus den Daten geliefert. Lieutenant Caine – let’s go profiling… weiterlesen…

Inkrementelles Löschen – Vanilla Style

Wie schon im Beitrag „Inkrementelles Laden – Vanilla Style“ angekündigt, hat der DeltaMaster Modeler 213 noch weitere Unterstützung für inkrementelle Befüllungsszenarien an Bord. Neben der im Beitrag erwähnten Möglichkeit das Snowflake-Schema inkrementell zu erzeugen, ist noch ein weiteres wertvolles Feature hinzugekommen, was eine Lücke in dem skizzierten Ladeprozess schließt: das inkrementelle Löschen von Daten. Wie diese neue Funktion konfiguriert wird, ist Thema dieses Beitrags. weiterlesen…

Snow ohne Flake – Einsatzmöglichkeiten der inkrementellen Snowflake-Erzeugung mit Modeler 213

Seit der Version 213 unterstützt DeltaMaster Modeler die Teilerzeugung des relationalen Snowflake-Schemas. Dies war eine der größten Änderungen in der Version und dient primär der Unterstützung von großen Projektumgebungen. Dabei werden in den neuen inkrementellen Modi nur die Objekte neu erzeugt, die von den letzten Änderungen betroffen sind.

Damit wir möglichst flexibel in der Projektarbeit bleiben und auch verschiedene Alltagssituationen (z. B. im Support) unterstützen, gibt es mehr als einen inkrementellen Modus. Die Unterscheidung der verschiedenen Option und deren Einsatzmöglichkeiten bilden das Thema dieses Beitrags. weiterlesen…

Inkrementelles Laden – Vanilla Style

Nachdem mein Kollege Jan Mo…, nein Fuchs, am 30.01.2015 bereits einen großartigen Non-Vanilla-Weg zum inkrementellen Laden von Daten aufgezeigt hat („Inkrementelles Laden mit relationaler Partitionierung“), trete ich heute nochmal einen Schritt zurück und zeige die Grundzüge eines einfachen inkrementellen Szenarios und erläutere ausführlich die notwendigen Kniffe im Modeler. Aufgrund der zahlreichen Fragen in jüngster Vergangenheit, scheint mir hier noch etwas Grundlagenarbeit nötig zu sein – also ab in die Vanilla-Welt! weiterlesen…

Sni Sna Snapshot – Snappi Snappi Snap

Seitdem ich die eleganten Möglichkeiten von Datenbank-Snapshots im Microsoft SQL Server kennengelernt habe, habe ich mal die Augen offen gehalten, wie oft diese Funktion im Feld draußen verwendet wird. Die Erkenntnis war ernüchternd – ungefähr so oft wie der Chartbreaker „Schni Schna Schnappi“ bei Rock am Ring läuft – nämlich gar nicht. Das ist sehr schade, da es einige Vorteile gegenüber herkömmlichen Backups gibt. Welche das sind und wie man die Schnappschüsse zum Einsatz bringt, schauen wir uns in diesem Beitrag an. Und danach widmen wir uns den unhaltbaren Zuständen bei Rock am Ring. weiterlesen…

Gigantomanisch dynamischer Versionsvergleich

Ich bin mir nicht sicher, ob ich schon mal erwähnt habe, dass DeltaMaster ein sensationelles Pla-nungswerkzeug ist. Aber selbst wenn man aus einem mir unergründlichen Grund nicht damit planen sollte, so kann man DeltaMaster dennoch hervorragend zur Daten- und Abweichungsanalyse verwenden. Standard ist die herkömmliche Plan-Ist-Analyse. Jetzt soll es da draußen aber Planer geben, die nicht auf Anhieb wissen, was genau sie in 5 Jahren an Kunden XY verkaufen. Aus dem Grund wird in Planungssystem häufig mit Planversionen gearbeitet, um verschiedene Szenarien durchspielen zu können. Oft kommen dabei Best-Case- oder Worst-Case-Annahmen zum Einsatz. Ebenso denkbar ist eine Gegenstromplanung, in der die Geschäftsführung und die Unternehmensbasis parallel plant und die Planungen anschließend ver- und angeglichen werden. Auch hier kommen Planversionen zum Einsatz. Wie so oft sind aber selten die absoluten Zahlen das spannende sondern der Vergleich zwischen einzelnen Versionen. Da es hier aber sehr viele geben kann, stellt sich die Frage, wie wir die Abweichungen möglichst elegant berechnen. Eine statische Berechnung ist zwar auch möglich, aber hierfür müsste man sehr viele Abweichungselemente anlegen, was sehr „uncool“ wäre. Wie man die Anforderung „cool“ löst zeigt dieser Beitrag. weiterlesen…

„Double-OLAP-Planning“

DeltaMaster ist ein sensationelles Planungswerkzeug. Dies hat uns kürzlich wieder ein Partnerunternehmen bestätigt, welches schon mit vielen anderen Frontends gearbeitet hat. Die Schwachstelle in SQL-Server-basierten Planungssystemen ist aktuell eher im Backend zu finden. Die Analysis Services sind zwar großartig im Verdichten, Verteilen und Vorhalten der Daten. Im Gegensatz zu dem relationalen Teil des SQL-Servers mag es die OLAP-Komponente allerdings überhaupt nicht, wenn Anwender gleichzeitig lesend und schreibend auf sie zugreifen. Unter gewissen Umständen kommt es dabei zu ernsthaften Zugriffsproblemen, bei denen der OLAP-Server in der Folge jegliche Kommunikationsversuche beharrlich verweigert. Wie es zu dieser Situation kommt und wie man sie umgeht, lesen Sie im nachfolgenden Artikel. weiterlesen…

Extreme Jahreswerterfassung – wie man die Zukunft ändert ohne die Vergangenheit zu berühren

Die Zeit kann man ja bekanntlich nicht zurückdrehen und somit die Vergangenheit auch nicht verändern. Dies erscheint jedem Erdenbürger einigermaßen logisch – zumindest wenn er nicht Dr. Emmett Brown heißt. Leider gilt das nicht für OLAP-Server. Diese engstirnigen Lebensformen lassen Änderungen in jedem zeitlichen Kontext zu, zumindest sofern wir sie nicht vom Gegenteil überzeugen. In einer monatsbasierten Planung ist das noch relativ einfach. Die zukünftigen Monate dürfen verändert werden, die vergangenen nicht. Selbst im aktuellen Jahr ist die Abgrenzung noch relativ einfach. Meist werden alle noch nicht vollständig abgeschlossenen Monate geplant, sprich der aktuelle Monat bleibt außen vor. Soweit so gut, wäre da nicht das schon oft erwähnte, unberechenbare Moment der Anwender. Diese wollen auch gern mal den Jahresendwert in Summe eingeben. Liegen im aktuellen Jahr dann schon Ist-Monate hinter uns, dürfen diese natürlich nicht verändert werden. Ein Splashing-Problem der besonderen Art. Ob und wie man diese Herausforderung löst, ganz ohne Flux-Kompensator, wird Thema des nachfolgenden Artikels sein. weiterlesen…

Der Maniac-OLAP-Ansatz – eindimensionale Datenmodellierung für Listen-Junkies

Als Berater-Frischling konnte ich mir nie vorstellen, wie mehr als drei Dimensionen in einen Würfel reinpassen sollten. Ich habe immer versucht mir das bildlich vorzustellen, was mir natürlich nicht gelungen ist. Falls es dem/der ein oder anderen genauso gehen sollte habe ich vielleicht eine Lösung parat. Hierzu stelle ich heute mutig den multidimensionalen Modellierungsansatz in Frage und behaupte, dass wir eindimensional auch nicht so schlecht fahren würden!
Jüngst wurde ich mit einem Hilferuf von einem Kollegen konfrontiert, der gern auf einem Bericht die Zeilenachse dynamisch tauschen würde und das am liebsten ohne Flexreport. Als Lösung fiel mir ein eindimensionaler Modellierungsansatz ein, den ich einmal in einem Konzeptionspapier eines Kunden gelesen hatte. Damals hielt ich diese Idee noch für vollkommen abwegig und habe sie großspurig vom Tisch gewischt – ich weiß ja schließlich wie man „richtig“ OLAP modelliert. In dem oben genannten Beispiel ist dieser Ansatz aber genau die Lösung für das Problem. Und als netten Nebeneffekt erreicht man auch noch eine immense Performancesteigerung für alle Listen- und Tapeten-Junkies. Also unter dem Strich durchaus vielversprechend. Heute würde ich ernsthaft über den Ansatz nachdenken. Und obendrein kann ich mir das in meinem kleinen Hirn auch wirklich bildlich vorstellen… ;o) weiterlesen…