Texte

Es ist schon einige Jahre her, da wurde uns hier bei Bissantz ein künstlerisches Video gezeigt. Zu sehen war, wenn ich mich richtig erinnere, eine Autofahrt durch die Häuserschluchten einer Großstadt. Das besondere war allerdings, dass alle Objekte in diesem Video nicht durch die Objekte selbst dargestellt wurden, sondern durch den entsprechenden Schriftzug. D. h. anstatt eines Autos fuhr, z. B. das Wort „Auto“‘ durch die Stadt. Das sollte uns die Macht und Möglichkeiten von Text vor Augen führen. Leider flossen diese Erkenntnisse zum Thema Text kaum in den DeltaMaster ein. Zumindest bis es die Möglichkeit gab, SQL-Durchgriffe als HTML formatiert zurückzugeben. Das fand ich sehr interessant, da HTML ein recht gutes Instrument ist, um Texte darzustellen. weiterlesen…

Inkrementelles Laden mit relationaler Partitionierung

Ab einer bestimmten Größe wird es sehr unhandlich, eine Faktentabelle bei jeder Aktualisierung komplett zu laden. In diesem Fall muss der Aktualisierungsprozess so verändert werden, dass möglichst nur neue oder geänderte Datensätze geladen werden. Das nennen wir „Inkrementelles Laden“. Solch ein Laden stellt neue Anforderungen an den verwendeten SQL-Code und die Performance-Optimierungen. War es z. B. beim Komplettladen möglich, die Faktentabelle mit dem sehr schnellen TRUNCATE-Befehl zu löschen, ist das jetzt nicht mehr möglich, da nur noch die Daten gelöscht werden dürfen, die sich geändert haben. Ein entsprechender DELETE-Befehl kann aber viele Ressourcen und viel Zeit kosten.

Ein weiteres Problem ist, dass die Zeilen, die sich geändert haben und diejenigen, die hinzukommen, nicht immer einwandfrei identifizierbar sind. Deshalb wird es in der Praxis meistens auf einen Kompromiss hinauslaufen. Ein Kompromiss könnte z. B. so aussehen: Für FIBU-Daten ist nicht erkennbar, welche Datenzeilen geändert und welche hinzugefügt werden müssen. Was aber bekannt ist: Es können sich nur Datenzeilen im aktuellen Geschäftsjahr ändern. Also werden die Datenzeilen des aktuellen Geschäftsjahres komplett gelöscht (auch die, die sich gar nicht geändert haben) und das Geschäftsjahr wird komplett neu geladen, die alten Geschäftsjahre bleiben aber unberührt.

Das bei uns am häufigsten eingesetzte Verfahren für inkrementelles Laden, möchte ich hier ‚Meh-rere-Faktentabellen-Verfahren“ nennen. Dabei wird, um auf das gerade angesprochene Beispiel zurückzukommen, für jedes Geschäftsjahr eine Faktentabelle angelegt und in der multidimensionalen Datenbank kann dann für jede einzelne relationale Faktentabelle eine Partition angelegt werden. Das Verfahren wird auch wunderbar durch DeltaMaster Modeler unterstützt, der durch die Einstellung „PartitionPerSourceTable“ solch ein Modell schnell aufbaut. Für einen Nachteil dieses Verfahrens halte ich, dass sobald z. B. ein neues Geschäftsjahr hinzukommt, eine neue Faktentabelle und der ganze zugehörige „Rattenschwanz“ neu angelegt werden muss. Das Modell muss also periodisch erweitert werden.

Ich möchte in diesem Beitrag noch ein anderes Verfahren vorstellen, dass einerseits etwas flexibler an die Anforderungen des jeweiligen Modells angepasst werden kann, andererseits aber auch das periodische Erweitern des Modells überflüssig macht. All das erfordert jedoch deutlich mehr Komplexität, wie noch ersichtlich sein wird.
weiterlesen…

Überwachungen (SQL-Server-Audit)

Die Log- oder Trace-Möglichkeiten von Microsoft SQL Server sind vielfältig. Dieser Beitrag gibt eine kleine Einführung in eine Trace-Möglichkeit, die nicht allzu bekannt zu sein scheint: dem SQL-Server-Audit. Auditing ist dann sinnvoll, wenn man wissen will, was sich auf einem SQL Server oder in einer SQL-Server-Datenbank so ereignet. Beim Audit können die Informationen entweder in ein Log der Windows-Ereignisanzeige oder in eine gesonderte Datei geschrieben werden. Bei beiden ist jedoch darauf zu achten, dass sowohl der Service-Account des SQL Servers als auch der Nutzer entsprechende Rechte besitzt. In dieser kleinen Einführung liegt der Fokus darauf, die Audit-Informationen in einem separaten File abzulegen. weiterlesen…

SSIS 2012 erste Schritte

Letztens konnte ich bei einem unserer Kunden ein Upgrade eines SQL-Server 2005 auf die Version 2012 begleiten. Dabei war auch ein größeres, über Jahre ‚gewachsenes‘ SSIS-Paket enthalten. Jeder erfahrene BI-Consultant weiß, was das bedeutet: Das SSIS-Paket ist unübersichtlich:

Dies stellt nur einen Teil des SSIS-Paketes dar, das gesamte Paket ist noch größer.
Unübersichtlich ist es, ja, aber außerdem so groß, dass es mehrere Minuten dauert, diese Datei zu öffnen. Es gibt deaktivierte Tasks. Im BIDS-SSIS-Projekt (BIDS: Business Intelligence Development Studio, weil Version 2005; in Version 2012 heißt das SSDT: SQL Server Data Tools; bei beiden handelt es ich aber eigentlich um das VS: Visual Studio) befinden sich weitere Pakete, die aber mit dem eigentlichen Prozess nichts zu tun haben, die Tests darstellen oder anderweitig für den Produktivbetrieb irrelevant sind. Ich hatte mir schon häufig vorgenommen, hier ‚auszumisten‘, habe aber entweder selbst die Arbeit gescheut, oder konnte dem Kunden nicht wirklich einen Vorteil für ihn aufzeigen. Das Paket funktioniert ja tadellos, also warum da Arbeit reinstecken.
Im Zuge der Umstellung auf SQL Server 2012 habe ich einen Tag für das Upgraden des SSIS-Paketes eingeplant um genug Zeit zur Lösung für eventuelle Probleme zu haben.
weiterlesen…

Erstellen von Dimensionselementen im Planungsprozess

Der DeltaMaster ist ein großartiges Planungstool. Er bietet viele Möglichkeiten, die in Planungsszenarien viel Zeit und Energie sparen. Bei einigen Planungsszenarien kann es notwendig sein, neue Dimensionselemente anzulegen. Dies geschieht im DeltaMaster in sogenannten ‚Stammdaten‘-Sitzungen in denen Teile der relationalen Quelle der Dimensionsdaten gepflegt werden können. Leider ist im Standardmodell danach ein Verarbeiten notwendig, um die Änderungen im OLAP-Modell zur Verfügung zu haben. In Planungsphasen, die bei einigen unserer Kunden recht intensiv und kommunikativ sind, kann aber das Warten auf die nächste Verarbeitung (meist in der nächsten Nacht) keine Option sein. Deshalb stelle ich hier einen einfachen Weg vor, um Daten, die in der Stammdatenpflege eingeben werden, sofort im Modell verfügbar zu haben. weiterlesen…

Als Vorspeise bitte Multiplizieren und dann im Hauptgang Aggregieren. Und das bitte zackig!

Im Alltag eines BI-Consultants trifft man durchaus häufiger auf Anforderungen, die sich, stark vereinfacht, alle auf eine mathematische Formel reduzieren lassen: Eine Summe von Produkten. So sind z.B. alle Währungsumrechnungen mathematisch formulierbar: erst müssen alle Werte durch eine Multiplikation mit Währungsumrechnungen auf eine Währung umgerechnet werden, dann kann man diese Summieren.
In einem der Projekte, in denen ich z.Z. arbeite, gibt es ist noch einen anderen Fall von ‚Summen von Produkten‘: Das ERP-System des Kunden verwaltet die Geschäfte in einer Reihe von Gesellschaften. Die Auswertungen sollen aber häufig nicht für eine Gesellschaft vorgenommen werden, sondern für einen Fonds. Dabei haben Fonds bestimmte Anteile an den Gesellschaften. D.h. bevor die Aggregation der Werte erfolgen kann, muss der Anteil des Fonds an der entsprechenden Gesellschaft einfließen. weiterlesen…

Solve_Order in MDX

Manchmal kommt es vor, dass eine bestimmte Berechnung in MDX nicht genau das berechnet, was man erwartet hätte. Häufig hilft dann aber ein bisschen Spielen mit der Solve_Order und die Berechnung stimmt. Dadurch hängt der Solve_Order ein wenig der Spirit von Magie an. Dem möchte ich in diesem Beitrag entgegenwirken und die Solve_Order etwas entzaubern. weiterlesen…

SQL Server-Agent-Aufträge ereignisgesteuert ausführen

Kein Projekt, in das ich je Einblick hatte, kam ohne die Auftragssteuerung des SQL Server-Agent aus. Dabei wird für einen Auftrag immer genau angegeben was für eine Funktionalität wann auszuführen ist. Dabei wird das Was über einzelne Schritte des Auftrags eingestellt und das Wann über einen Zeitplan.
Es gibt aber auch die Möglichkeit, SQL-Server-Agent-Aufträge ereignisgesteuert auszuführen. Das soll hier kurz vorgestellt werden. Die Ereignissteuerung der SQL-Server-Agent-Aufträge basiert auf Warnungen und Fehlermeldungen. D.h. die Technik ist im SQL-Server implementiert, um auf bestimmte Fehler reagieren zu können. Fehlermeldungen in SQL-Server besitzen immer auch eine bestimmte Schwere. Es können also auch ‚Fehler‘ konfiguriert werden, die eher den Status eines Hinweises haben, als das sie tatsächliche Fehler sind. Diese Technik kann also auch in Fällen hilfreich sein, wo nicht unbedingt ein echter Fehlerfall auftritt. weiterlesen…

Einbinden von Assemblys in relationale Datenbanken

Für die meisten Anforderungen bietet der SQL Server genug Funktionalität um diese erfüllen zu können. Hin und wieder kann es aber notwendig sein, dem SQL Server durch eigene Programmierungen etwas unter die Arme zu greifen. Um dies tun zu können, bietet SQL Server eine Schnittstelle um selbst erstellte .NET-Funktionalitäten dem SQL Server zur Verfügung zu stellen. Man spricht hier von der CLR-Integration, wobei CLR ‚Common Language Runtime‘ bedeutet und einen bestimmten Layer in der .NET-Programmierung entspricht. CLR-Programme ersetzen in keinem Fall das SQL Server-interne T-SQL. Vielmehr werden die Programme integriert. So können folgende Bestandteile des T-SQL durch CLR-Programme erstellt werden:
 Stored procedures
 Trigger (DML und DDL)
 User defined functions
 Aggregate
Es soll in diesem Block gar nicht um die Erstellung solcher Assemblys gehen, sondern lediglich um die Integration dieser. weiterlesen…

Transferieren von Flex-Reports über XML-Dateien.

Die extrem hohe Vernetzung aller Bestandteile des DeltaMaster ist im Grunde ein großer Vorteil von DeltaMaster und OLAP-Datenbanken. Alle Beziehungen sind vordefiniert und der User kann sich sofort mit seinen Daten befassen, ohne vorher solche Beziehungen erst noch mühevoll definieren zu müssen.
Die Ebenen einer Hierarchie hängen voneinander ab. Attribute bilden Beziehungen in einer Dimension. Faktendaten sind mit bestimmten Attributen verbunden. MDX-Berechnungen benötigen die entsprechenden Measures der Faktentabellen. In einer DAS-Datei setzt sich diese hohe Vernetzung weiter fort: es sind neuen Analysewerte definiert und neue Dimensionselemente, die wiederum davon abhängig sind, dass die darunterliegenden Bestandteile alle genauso vorliegen, wie es zur Zeit der Definition der Fall war. Ein Bericht in einer DAS-Datei ist da nur das letzte Puzzlestück, die obere, sichtbare Sicht auf diese wohlgeformte aber eben auch recht komplexe Welt von Abhängigkeiten. Einen Bericht da herauszulösen und in eine andere Welt zu implementieren, würde erfordern, dass alle erforderlichen Bestandteile in der neuen Welt genauso vorhanden sind, wie in der alten.
Trotz all dieser Schwierigkeiten bietet der DeltaMaster ein Standard-Verfahren an, um Berichte von einer DAS-Datei in eine andere zu transferieren: die Seite ‚Import‘ im Modell-Browser. Da es ein automatisiertes Standard-Verfahren ist, muss man sich dabei an einige Regeln gewöhnen. Z.B. werden alle Bestandteile der DAS-Datei, von denen der zu überführende Bericht abhängig ist, ebenfalls mit kopiert. So wird sichergestellt, dass der Bericht in seiner neuen Umgebung auch funktioniert. Es wird sogar bei vorhandenen Elementen (z.B. einem benutzerdefinierten Analysewert, der in beiden DAS-Dateien unter gleichem Namen vorhanden ist), die Definition überschrieben. Das ist zwar gut für den importierten Bericht, kann aber in vorhandenen Berichten falsch sein, wenn das entsprechende Element (z.B. Analysewert) in der Ziel-DAS eine ganz andere Bedeutung hat.
Da solche Situationen durchaus häufig auftreten, gibt es zumindest für Flex-Reports eine alternative Variante des Berichtstransfers. Diese soll hier kurz vorgestellt werden. weiterlesen…