„Hybride“ Performancemessung

Der folgende Beitrag beschreibt, wie mit der dargestellten Anwendung schnell und flexibel die Ausführungszeiten von Berichten mit Hilfe von DeltaMaster erfasst und analysiert werden können. Im Fokus steht hier, die oft durch Anwender als „gefühlte Verschlechterung der Performance“ beschriebene subjektive Einschätzung anhand von manuellen Messungen mit Daten zu unterfüttern. Es werden allgemeine Einflussfaktoren, das Messverfahren und die Ergebnisdarstellung beschrieben.

Zum Ende wird ein Ausblick über den weiteren Ausbau der Anwendung und neue Anforderungen hinsichtlich der Automatisierung dieses manuellen Ansatzes dargestellt. weiterlesen…

Disziplin – aber bitte automatisch

Wie kann unter Verwendung des Microsoft SQL-Servers ein kundenspezifisches Regelwerk zur Datenbankentwicklung eingeführt und automatisiert durchgesetzt werden? Dieser Beitrag zeigt einen Lösungsansatz mit Hilfe von SQL Server DDL-Triggern, deren Funktionsweise und technische Umsetzung anhand eines konkreten Praxisbeispiels. Es werden die Technik, der Nutzen und ein Codebeispiel dargestellt. Das dargestellte Codebeispiel ist ein allgemeingültiger Vorschlag, basierend auf der bisher im Bissantz Consulting gelebten Namensgebung im Entwicklungsprozess von Kundenprojekten. weiterlesen…

Repräsentative Daten

Die meisten Anwendungssysteme – und somit auch unsere DeltaMaster-Welt – werden in einer Mehrsystemlandschaft betrieben. Typisch in aktuellen IT-Infrastrukturen sind 2- oder 3-Systemlandschaften. In einer 2-Systemlandschaft sprechen wir von einem Entwicklungssystem (DEV) und einem Produktivsystem (PROD). In einer 3-Systemlandschaft wird zusätzlich noch ein Testsystem (QS) für unterschiedliche Benutzergruppen und Testszenarien zwischengeschaltet. Grundsätzlich ist die Verwendung von solchen Mehrsystemlandschaften dringend zu empfehlen. Nur so können notwendige und gewünschte Änderungen separat vom produktiven System entwickelt, getestet und vom Kunden fachlich abgenommen werden.

Eine Mehrsystemlandschaft bedeutet aber auch einen Mehraufwand während der Entwicklungszyklen. Es muss ein Prozess definiert sein wie die Entwicklungen von DEV zu PROD möglichst automatisiert übertragen werden können. Außerdem müssen in geeigneten Intervallen die produktiven Daten vom PROD auf das DEV zurückgespielt werden, um möglichst repräsentative Testergebnisse bereits während der Entwicklung gewährleisten zu können. weiterlesen…

Back(upp)en mit Rezept

Ein regelmäßiges Backup der von uns bearbeiteten Systeme lässt einen meist ruhig schlafen, korrekt? – Stimmt, wenn es denn ein Backup gibt und man darauf vertrauen kann!

In den meisten Projekten obliegt die Betriebsbereitschaft von Serversystemen der Verantwortung der IT-Abteilungen und das ist gut so. Es gibt regelmäßige Wartungspläne, ganze 19“-Racks voll mit Hardware sowie unterschiedliche Softwaretools, um automatisiert und möglichst effizient die wichtigen und sensiblen Daten zu kopieren, auf Medien auszulagern und damit vor Verlust zu schützen.
Die verschiedenen Verfahren sind nicht Bestandteil dieses Beitrags, es sei nur so viel gesagt: Je nach Schutzbedarf und Datenmenge kann es kompliziert werden. Weiterführende Details und Hintergründe finden sich zum Beispiel beim Bundesamt für Sicherheit in der Informationstechnik (kurz: BSI) unter Abschnitt B1.4 des IT-Grundschutzkatalogs.

Was tun wir aber, wenn unser Business Intelligence Projekt von der Fachabteilung an der IT vorbei begonnen und eingeführt wird und unsere Server eben nicht dem Luxus einer geregelten Datensicherung unterliegen? Ein allgemeines Rezept als Trumpf im Ärmel zu haben; das zeige ich auf den folgenden Seiten. weiterlesen…

Sehen und gesehen werden

In diesem Beitrag möchte ich mich einem Detail des oft behandelten Themas der OLAP-Berechtigungen widmen, der Berechtigung von Kennzahlen.
Wir alle haben uns sicherlich schon mit der Frage beschäftigt, was sieht ein Benutzer tatsächlich, nachdem man sich bei der Rechtevergabe auf der OLAP-Datenbank ausgetobt hat. Dazu stelle ich einen kleinen, aber feinen Trick vor.

Spricht man mit IT-Administratoren, weise ich immer auf einen grundlegenden Unterschied zwischen Berechtigungen von Microsoft Analysis Services (kurz: SSAS) und z. B. dem Dateisystem einer Microsoft Windows Systemumgebung hin: die Berechtigungen auf OLAP-Datenbanken sind additiv, nicht restriktiv!

Von Dateien oder Verzeichnissen ist man gewöhnt, dass wenn einmal einem Benutzer ein beliebiges Recht entzogen wurde, dann bleibt diese Restriktion erhalten, egal worüber sonst einem vielleicht ein höheres Recht eingeräumt wird. Dieser Grundgedanke bietet einen recht guten Schutz gegen Fehlkonfiguration und damit unerwünschte Zugriffsrechte.

Bei Microsoft Analysis Services Datenbanken gilt dieser Grundsatz leider nicht, weder für „normale“ Dimensionselemente noch für die Berechtigung von Kennzahlen. Einmal erlaubt = immer erlaubt; das ist die Devise!

Was es bei dem Einsatz von Berechtigungen auf Kennzahlen gesondert zu beachten gilt, schauen wir uns in der Demonstrationsdatenbank „Chair“ an. weiterlesen…

Transparente Verschlüsselung

Als im Juni 2013 die amerikanische Washington Post und der britische Guardian damit begannen, geheime Dokumente eines ehemaligen Mitarbeiters des amerikanischen Auslandsgeheimdienstes NSA zu veröffentlichen, wurde der Weltöffentlichkeit klar, wie transparent scheinbar jegliche Kommunikation und damit auch die dadurch erhobenen Daten eines jeden von uns sind. Die dadurch neuentfachte Debatte um den Datenschutz schafft immer mehr Sensibilität im Umgang mit unseren privaten Daten. Auch Unternehmen, allen voran das Finanz- und Bankenwesen, haben in den meisten Fällen festgeschriebene Regeln, wie mit allgemeinen Geschäftsdaten umzugehen ist. In Deutschland werden diese Regeln vom Bundesamt für Sicherheit in der Informationstechnologie (kurz: BSI) definiert und als sogenannter IT-Grundschutz veröffentlicht. Kernziele sind dabei Vertraulichkeit, Verfügbarkeit, Integrität und Identität sicherzustellen, um dadurch Gefahren und Risiken zu minimieren. Was bedeutet dies nun aber in Business-Intelligence-Projekten? Der folgende Artikel soll die potenziellen Gefahrenquellen hinsichtlich der Vertraulichkeit aufzeigen und im Detail die Möglichkeit zur Verschlüsselung der relationalen Datenquelle mit Hilfe der sogenannten transparenten Datenverschlüsselung (kurz: TDE) des Microsoft SQL Servers aufzeigen. weiterlesen…

Hochrechnung²

Das Thema Hochrechnungen, gerne auch als Prognose bezeichnet, ist eine häufig gestellte Anforde-rung an Unternehmensberichte. Dabei ist die Definition der Prognose meist individuell und stets den jeweiligen Gegebenheiten und Geschäftsmodellen unterworfen. Reicht es beispielsweise aus, für den Rest des laufenden Geschäftsjahres vorhandene Planwerte als Ziel anzunehmen? Oder ist für die Betrachtung eher der entsprechende Vorjahreswert von Interesse und aussagekräftiger? Unterliegt die Entwicklung wiederkehrenden Saisonalitäten? Das sind nur einige Fragestellungen, die es bei der kundenindividuellen Entwicklung einer Hochrechnung zu diskutieren und beachten gilt. Ein weiteres wichtiges Detail ist die Festlegung, ab wann sich der Berichtsempfänger datentechnisch in der Vergangenheit und wann in der Zukunft befindet?

Einen ersten Ansatz liefern wir mit DeltaMaster ab Version 5.5.8 bereits aus, den Standardbericht „Way to Go“. Dieser kann vollständig automatisiert mit Hilfe des Startassistenten auf (fast) jedem Datenmodell erstellt werden, vorhandene Planwerte vorausgesetzt. Allerdings basiert diese Form der Prognose auf der Fragestellung, was das Unternehmen im Verlauf des Jahres erreichen muss, um am Ende den Plan zu erfüllen.

Ich möchte heute einige Lösungsansätze mit Hilfe von DeltaMaster und ein wenig MDX zeigen, die es jedem Interessierten ermöglichen, die Aussage der Hochrechnung durch ein paar „Stellschrauben“ zu individualisieren. Am Ende soll eine Hochrechnung entstehen, die den Entscheidern zu jeder Zeit sagt, wo das Unternehmen am Jahresende stehen wird. Viel Spaß beim Weiterlesen.
weiterlesen…

Hash & Co.

Heute möchte ich mich einmal mit einer sehr nützlichen T-SQL-Funktion namens CHECKSUM() beschäftigen. An einem Beispiel aus dem Datenladeprozess soll gezeigt werden, wie dieser durch die Verwendung von CHECKSUM() schneller und eleganter gestaltet werden kann.
Wir Modellierer kennen aus unserer täglichen Praxis eine häufig mangelhafte Datenqualität, egal in welcher Form die notwendigen Daten bereitgestellt werden. Gerade in Workshop-Situationen, in denen sehr schnell eine Vielzahl an Kundenwünschen implementiert werden muss, können wir nicht immer einen perfekten ETL-Prozess erwarten. Geht es dann auch noch um Themen wie eine inkrementelle Datenlade-Logik bei großen Datenvolumina, bei der die Rohdaten aber nicht per eindeutigem Schlüssel gefunden werden können, hilft man sich oft mit einer differenzierten JOIN-Bedingung (X=X AND Y=Y AND Z=Z etc.). Das funktioniert grundsätzlich auch sehr gut. Allerdings kann dies die Abfrageperformance negativ beeinflussen, und das gilt es zu vermeiden. weiterlesen…