„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…

Die Lösung des gordischen Knotens: T-SQL objektorientiert UND schnell

Programmierern aus der Welt der objektorientierten oder prozeduralen Sprachen dürfte es beim Blick in so manche Microsoft-SQL-Datenbank die Haare zu Berge stehen lassen. Die gleiche Programmlogik wird häufig immer und immer wieder geschrieben und dies an verschiedensten Stellen in der Datenbank. Das ist umso erstaunlicher, weil es bereits seit der SQL-Server-Version 2005 sogenannte benutzerdefinierte Funktionen gibt, die genau dies verhindern sollen. Warum also werden diese nicht verwendet? Die Ursache ist ihre teilweise katastrophale Performance. Nutzt man diese Skalarwertfunktionen zur Zentralisierung des Quellcodes muss man wohl oder übel ein schlechtes Laufzeitverhalten in Kauf nehmen. Von daher hat man die Wahl zwischen Pest oder Cholera – saubere Architektur oder gute Performance.
Zum Glück ist aber auch die Datenbankwelt nicht ganz so schlecht wie es auf den ersten Blick scheint. Mit ein paar wenigen Handgriffen kann man tatsächlich den Quellcode zentralisieren und das bei sehr gutem Laufzeitverhalten. Wie das geht? Einfach weiterlesen… weiterlesen…

SUM-Where OVER the rainbow

Bereits 2007 haben wir uns in unserem Blog Gedanken gemacht, wie lange OLAP-Datenbanken wohl noch überleben werden. Im Zeitalter des DeltaMaster ImportWizzard kommt man auch tatsächlich ab und an ins Grübeln, wozu man diese Form der Datenbanken überhaupt noch benötigt? Bei genauer Betrachtung findet man aber schnell zahlreiche Gründe, warum wir immer noch lieber Würfel als Tabellen bauen. Neben dem deutlich schnelleren Aggregationsverhalten einer multidimensionalen Datenbank zählt auch die MDX-Zeitintelligenz nach wie vor zu den Pluspunkten. Relational Kumulieren beispielsweise erzeugt bei einem T-SQL-Programmierer nach wie vor ein flaues Gefühl in der Magengegend.
2012 ist jetzt auch Microsoft auf die Idee gekommen und sagt ihrer eigenen OLAP-Datenbank den Kampf an. Mit dem neuen „Tabular Mode“ und der Abfragesprache DAX des SQL Servers 2012 gibt Microsoft ein deutliches Statement für relationale Datenbanken ab. Im Zuge dessen wurden auch Implementierungslücken bereits existierender T-SQL-Befehle behoben, so dass künftig eine relationale Kumulation einem Programmierer nur noch ein müdes Lächeln ins Gesicht zaubern wird.
Wenn Sie wissen wollen wie, dann folgen Sie mir einfach auf dem Weg zum Ende des Regenbogens… weiterlesen…

NOT IN = NOT EXPECTED

Da programmiert man schon Jahrzehnte lang T-SQL und erlebt doch noch Überraschungen bei vermeintlich einfachen Befehlen. Jüngst haben wir in einer Kundenumgebung verschiedene Optimierungen durchgeführt und unter anderem NOT IN Befehle durch LEFT JOINs ausgetauscht. Erwartet haben wir ein identisches Abfrageergebnis bei deutlich besserer Performance. Aber weit gefehlt. Aus einem uns zu dem Zeitpunkt noch nicht bekannten Grund lieferte die „linke Verbindung“ ein vollkommen anderes Ergebnis als das zuvor verwendete IN-Kommando. Nach einer langwierigen Suche, mit wiederholten Zweifeln an der eigenen Fachkompetenz, haben wir den Grund schließlich gefunden. Und wie sich herausgestellt hat, ist dieser selbst für viele „alte Hasen“ überraschend. Also lassen auch Sie sich überraschen und nicht traurig sein – Sie sind in bester Gesellschaft… ;o) weiterlesen…

Partitionierte Tabellen – Faktenladen mit „Fast = TRUE“ (Teil 2)

Uuuund Action! Wie im ersten Teil dieses Beitragsthemas beschrieben, schauen wir uns heute die vorbereiteten partitionierten Tabellen in Aktion an. Im ersten Teil haben wir im SQL Server die notwendigen Partitionierungsobjekte angelegt und diese bereits auf eine Faktentabelle angewendet. Im zweiten Teil versuchen wir jetzt, neue Daten in die Faktentabelle zu importieren. Dies geschieht nicht wie sonst üblich per DELETE und INSERT, sondern mit einem sogenannten „Partition Swap“. Der vorliegende Artikel zeigt die notwendige Syntax, beleuchtet die Restriktionen und zeigt wie viel Optimierung die Partitionierung wirklich bringt. weiterlesen…

Partitionierte Tabellen – Faktenladen mit „Fast = TRUE“ (Teil 1)

Das sagenumwobene Flag „Fast = TRUE“ hat sich wohl jeder IT-ler in seinem Leben schon einmal gewünscht. Microsoft verspricht spätestens ab SQL-Server-Version 2005 eine Option, die diesem Flag schon ziemlich nahe kommt. Die Rede ist hier von der Möglichkeit, Tabellen zu partitionieren. Dies soll deutliche Performancegewinne insbesondere beim Laden und Verwalten von umfangreichen Faktendaten ermöglichen. Der Clou daran ist, dass einzelne Tabellenpartitionen einer Faktentabelle einfach gegen eine strukturidentische Deltatabelle ausgetauscht werden können. Bei dieser Operation werden lediglich Metadaten verändert, was nur einen Bruchteil der Zeit eines echten Datenimports benötigen soll.
Die Restriktionen, das allgemeine Vorgehen sowie die tatsächlichen Performancegewinne beim Partitionieren werden in Teil 1 und 2 des nachfolgenden Artikels betrachtet. weiterlesen…

Das kleine Wunder: Vorschlagswerte on Demand

Immer wieder werden wir bei Kunden mit dem Wunsch konfrontiert, dass in Ihrer Planungsanwendung zunächst die Daten auf Jahresebene erfasst und später auf die Monate heruntergebrochen wer-den sollen. Die Verteilungslogik soll natürlich online rechnen und die Ergebnisse unmittelbar sichtbar werden. Das große Ziel ist selbstverständlich, dass die Summe der Jahresplanung am Ende der Summe der Monatsplanung entspricht. Um dies zu erreichen muss für jeden Jahreswert ein korrekter Verteilungsschlüssel existieren.
Kein Problem, wäre da nicht ein unberechenbarer Faktor, der das System ins Wanken bringt: der Planer…
Wie wir es schaffen, mit fehlenden Verteilungsschlüsseln umzugehen, und dies ohne Batch-Verarbeitung schauen wir uns in nachfolgendem Artikel an. weiterlesen…

Den Modeler verstehen oder wie man nicht eindeutige Dimensionen mit dem DeltaMasterModeler aufbauen kann

Zum Aufbau von OLAP-Modellen in SQL-Server Analysis Services erzeugt der DeltaMasterModeler ein relationales Snowflake-Schema. Um Probleme bei der Aufbereitung des Würfels zu vermeiden, wird das Snowflake-Schema ordentlich mit Fremd- und Primärschlüsseln generiert. Die Sicherstellung der Datenintegrität ist für produktive Anwendungen auch unbedingt zu empfehlen. Leider erschwert einem häufig die strenge Logik das Leben beim Aufbau von Prototypen. Bekommt man beispielsweise Stammdaten mit nicht eindeutigen Bezeichnungen, kann daraus keine Dimension aufgebaut werden, weil die Primärschlüssel-Einschränkung verletzt wird. Im folgenden Artikel wird beschrieben, wie man die Dimension trotz allem aufbauen kann. weiterlesen…