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…

Relationale Eingabeanwendung als Alternative zur Custom App

Häufig müssen Daten in bestehenden Modellen angepasst oder ergänzt werden. Um neue Daten relational zu übernehmen oder Hintergrundprozesse zu starten, kennen wir schon die Funktionalität der Custom App mit zusätzlichen Menüpunkten in DeltaMaster.

Eine weitere Möglichkeit, den DeltaMaster-Benutzern den manuellen Start von Prozeduren komfortabel über das FrontEnd einzurichten, bietet die relationale Eingabeanwendung. weiterlesen…

SSIS und das Excel-Problem

Mit dem ETL-Werkzeug SQL Server Integration Services (SSIS) des Microsoft SQL Servers können unterschiedlichste Datenladeprozesse umgesetzt werden. Dabei ist nicht nur die Zahl an anzubindenden Ziel- und Quellsystemen nahezu unerschöpflich, sondern auch die Datenmodifikations-, Datentransformations- und Datenvalidierungsmöglichkeiten, die zwischen der Anbindung der Quelle und des Ziels geschehen können. Und so ist es nicht verwunderlich, dass aus diesen vielen Modellierungsmöglichkeiten des Datenladeprozesses komplexe und verzahnte Pakete entstehen können, die anspruchsvolle Datenlogiken abbilden und beinhalten können. weiterlesen…

Aufbau einer Bestandslogik

Mein Lieblingspersonaldienstleister möchte seine Bewerber auswerten. Bewerber können sich auf eine offene Stelle oder initiativ in einem Portal registrieren, werden dann von den Niederlassungen überprüft – und bald mit DeltaMaster von Marketing, der Personalabteilung, dem Vertrieb und den Niederlassungsleitern ausgewertet. Allerdings liefert das Vorsystem täglich nur den heutigen Stand eines Bewerbers, ohne dass ersichtlich ist, ob gestern ein Wechsel seiner Eigenschaften stattgefunden hat. Um Zeitperiodenvergleiche oder einen historischen Bestand auswerten zu können, müssen die Daten also erstmal historisiert werden. Wie ich das gemacht habe, beschreibe ich in diesem Beitrag. 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…

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…

T-SQL schnelle Nachfolgersuche

In der Datenbankprogrammierung muss gelegentlich eine Tabelle mit sich selbst verbunden werden. Beispielsweise müssen Vorgänger- oder Nachfolger gefunden werden, um anschließend Berechnungen auf Grundlage dieser Informationen durchzuführen. Mit Hilfe eines so genannten Self Joins, der eine Datenbanktabelle mit sich selbst verbindet, kann eine Nachfolgersuche durchgeführt werden.

Dieser Beitrag zeigt am Beispiel der Nachfolgersuche wie ein Self Join grundsätzlich erstellt wird, anschließend wird eine leistungsfähige Variante mit Hilfe von Tabellenausdrücken (Common Table Expressions (CTE)), Partitionen und Rangfolgefunktionen gezeigt. Die Beispiele beziehen sich auf die Tabelle „promotion“ aus der Microsoft Beispiel Datenbank „Foodmart“. Die Tabelle enthält 1.864 Datensätze. weiterlesen…

Dynamische Ermittlung von Mitgliedern einer AD-Gruppe per SQL

Die Vergabe von Benutzerrechten in einer OLAP-Datenbank auf einem Microsoft Analysis Server (SSAS) kann auf unterschiedliche Weise gelöst werden. Es können Lese- oder Schreibberechtigungen auf die ganze Datenbank, auf einen oder mehrere Würfel und Measuresgroups vergeben, oder einzelne Elemente einer Dimension oder Measures für den Zugriff gesperrt werden. Diese Berechtigungen wer-den für Rollen definiert. In Rollen werden Benutzer mit gleichen Benutzerrechten zusammengefasst. Somit muss nicht für jeden einzelnen Anwender die Berechtigung separat gesetzt werden. Bei weniger komplexen Berechtigungsszenarien können so mit einigen Mausklicks die Berechtigungen erstellt und gepflegt werden. Sieht das Berechtigungsszenario jedoch vor, dass jeder Anwender separat berechtigt werden muss, weil jeder von ihnen z. B. nur seine Region oder seine Kostenstelle sehen darf, muss für jeden Anwender eine eigene Rolle mit den entsprechenden Berechtigungen erstellt werden. Wird beim Reporting der SQL-Durchgriff zur Analyse von Belegdaten genutzt, müssen diese Berechtigungen auch auf der relationalen Datenbank Berücksichtigung finden. Um sich dabei doppelten Pflegeaufwand bei der Vergabe der Berechtigungen zu ersparen, empfiehlt es sich die Berechtigung gleich auf der relationalen Schicht zu pflegen und diese anschließend automatisch an einen Berechtigungswürfel auf der OLAP-Datenbank zu übergeben (siehe Beitrag Rechteverwaltung in SSAS – Teil 2). Oft wird die Verantwortung für die Berechtigungspflege an die Fachabteilung delegiert. Die IT-Abteilung stellt eine speziell benannte Benutzergruppe im Active-Directory (AD) zur Verfügung, der alle Benutzer mit Zugriff auf die BI-Anwendung zugeordnet wurden. Die Vergabe der Berechtigungen der einzelnen Benutzer innerhalb dieser AD-Gruppe muss anschließend von der Fachabteilung vorgenommen werden. Hierfür werden oft Pflegeanwendungen in DeltaMaster genutzt, in denen man jedem einzelnen Benutzer z. B. seine berechtigte Kostenstelle zuweisen kann. Damit die Berechtigungen wirken, muss der korrekte Name der Kostenstelle und der korrekte Benutzername angegeben werden. Dies stellt aber oft ein Problem dar, da nicht immer bekannt ist, wie der genaue Benutzername im Active-Directory lautet. Um dem Pflegenden bei dieser Arbeit zu unterstützen, wäre es hilfreich, wenn alle in der AD-Gruppe befindlichen Benutzer in einer Pflegeanwendung angezeigt würden und anschließend „nur noch“ die berechtigten Kostenstellen zugeordnet werden müssten. Wie eine solche Liste mittels einer SQL-Abfrage ermittelt werden kann, soll dieser Beitrag verdeutlichen. weiterlesen…

CustomApp Teil2 – Anwendung im Web

In dem Artikel „CustomApp Teil1 – Anwendung im Client“ (im Folgenden Teil1 genannt) wurde bereits beschrieben, was mit einem benutzerdefinierten Menü im Client möglich ist, welche Voraussetzungen notwendig sind und wie mit den einzelnen Menüvarianten gearbeitet werden kann. In dem nun folgenden zweiten Teil soll erläutert werden, was mit der Variante der CustomApp als Webkomponente möglich ist und welche Unterschiede zu der Client-Variante bestehen. 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…