In vielen meiner Projekte besteht die Notwendigkeit, Stammdaten nicht nur zu importieren, sondern auch die Eingabe und Änderung von Stammdaten zu ermöglichen. Dazu habe ich bisher verschiedene Möglichkeiten genutzt:
-
Sharepoint-Listen und deren Import
-
Stammdaten-Tabellen im SQL-Server und Zugriff auf diese Tabellen über SSMS, über Microsoft Access und ODBC, über Web-Anwendungen, über speziell programmierte Frontends zur Eingabe der Daten
In diesem Beitrag möchte ich die Verwendung separater Stammdaten-Tabellen näher beschreiben.
Sehr einfach ist es, eine separate Datenbank nur für die Stammdaten zu erstellen. Die Tabellen können untereinander mit Fremdschlüsseln verknüpft werden, die Fremdschlüssel sorgen für konsistente Daten, Delete Rules und Update Rules können verwendet werden. Seit SQL Server 2016 bietet die Verwendung temporaler Tabellen auch eine eingebaute Historisierung der Daten. Diese Tabellen lassen sich inklusive benötigter Fremdschlüssel sehr einfach ohne den AnalyticsCreator erstellen.
Der AnalyticsCreator kann dann diese Datenbank als Connector verwenden: entweder als SQL Server Connector, wobei die Daten in das Haupt-DWH importiert werden (dann kann sich die Datenbank auch auf einer anderen Instanz befinden) oder als "Direct Connector", bei dem sich die zu verbindende Datenbank auf der gleichen Instanz, wie die Hauptdatenbank befindet. Die Verbindung erfolgt dabei über Sichten, so dass keine separaten Import-Prozesse und Import-Tabellen nötig sind.
Doch was mache ich, wenn ich die Stammdaten nicht in einer separaten Datenbank pflegen will, sondern im Haupt-DWH?
Mögliche Gründe dafür gibt es mehrere:
-
man möchte nur eine Datenbank
-
die Fremdschlüssel beziehen sich auf andere Stammdaten, die in das Haupt-DWH aus anderen Quellen importiert werden.
-
…
Wie erstellt man mit dem AnalyticsCreator echte Fremdschlüssel? Ein Feature-Request dazu habe ich bereits angelegt:
0000490: Erstellung echter physischer Fremdschlüssel im Ziel-DWH
Ein Vorschlag vom AC-Chef-Entwickler:
Das einfachste ist — erstelle ein Post-Deployment Script mit ALTER TABLE ADD CONSTRAINT
Die ALTER TABLE Kommandos kannst du entweder manuell oder aus dem Repository mit einem SQL Script erstellen.
Das ist eine pragmatische Lösung und zeigt wieder einmal, dass man mit dem AnalyticsCreator auch Dinge umsetzen kann, die noch nicht implementiert wurden.
Meine Lösung:
-
ich verwende "Add externally filled table", um eine neue Tabelle hinzuzufügen
-
auf physische Fremdschlüssel werde ich wahrscheinlich verzichten, stattdessen verwende ich im AnalyticsCreator zumindest logische Referenzen, weil ich diese immer und überall verwende
-
Allerdings soll beim Verzicht auf physische Fremdschlüssel das Frontend Nachschlage-Listen für die möglichen Einträge anbieten, um dem Anwender die Eingabe konsistenter Daten zu vereinfachen.
Microsoft Access mit ODBC-Verbindungen zu den Tabellen bietet sich dafür an. -
auf die Tabelle folgt eine Transformation, welche prüft, ob die eingetragenen Inhalte zu den anderen Stammdaten passen
-
nur konsistente Einträge werden historisiert
-
für nicht konsistente Einträge gibt es eine optionale Sicht, die dem Anwender, der die Tabelle befüllt, nicht-konsistente Einträge anzeigen kann
Auf dem folgenden Bild sieht man in der untersten Zeile von Links nach rechts:
-
die Tabelle für die Eingabe der Daten
-
eine Transformation, die mit allen Nachschlage-Tabellen verbunden ist
-
eine weitere Transformation mit einer WHERE Bedingung, in welcher geprüft wird, ob es einen match mit den Nachschlage-Tabellen gibt:
NOT Assetmanager_match IS NULL
AND NOT AusrichtungAT_match IS NULL
AND NOT Disponibilität_match IS NULL
AND NOT Eingriff_match IS NULL
/*Länderzone ist kein Pflichtfeld*/
--AND NOT Länderzone_match IS NULL
AND NOT Mehrhalterfonds_code_match IS NULL
AND NOT PortfolioType_PerformanceType_match IS NULL
AND NOT Steuerung_M_MM_match IS NULL
AND NOT Mandant_or_MetaMandant_match IS NULLdiese Transformation ist die Quelle der Historisierung
in der zweiten Zeile von unten gibt es über der Quell-Transformation für die Historisierung eine Transformation, die alle Datensätze liefert, die nicht matchen. Der Filter lautet:
NOT EXISTS
(SELECT f.File_BaseName
FROM mdt.Steuerung f
WHERE T1.File_BaseName = f.File_BaseName
)
Über mich
Mein Name ist Germo Görtz. Und ich bin darauf spezialisiert, analytische Informations-Systeme und Berichts-Systeme technisch zu konzipieren und zu implementieren, damit sie fachlich funktionieren.
Meine Kunden erwarten von mir keine strategische Beratung, denn sie sind Profis, kennen ihr Fach und ihre Ziele.
Ich bin der Weihnachtsmann des kompetenten Controllers.
Je kniffliger die Aufgabe, desto größer mein Mehrwert.
Ihr Kittel brennt? Ich bin Ihr Feuerlöscher!
Sie wissen, wo Sie hinwollen. Ich analysiere und verstehe Ihre Ziele, dann werde ich Ihr Pfadfinder und führe oder fahre oder fliege Sie zu Ihren Zielen.
Meine technische und konzeptionelle Erfahrung ergänzt Ihre fachliche Erfahrung
⇒ für Ihre Karriere und Ihren Erfolg!
Folgende Faktoren machen unser gemeinsames Projekt besonders fruchtbar:
-
Exzellenz durch Kompetenz
-
Handwerk statt Fließband
-
Vertrauen in Experten (Technokratie statt Demokratie[1])
Für die Umsetzung nutze ich primär meine in Jahrzehnten erworbenen Kenntnisse und Erfahrungen mit der Microsoft BI Plattform: SQL Server, Power BI, relationale und analytische Datenbanken, maschinelles Lernen. Meine besondere Stärke ist die Erstellung von Datenmodellen.
Vergütung:
-
Besonders motivierend ist eine Zusammenarbeit, bei der ich Expertise und Zeit investieren kann, um am messbaren Erfolg beteiligt zu werden.
-
Gewerke und Festpreise sind möglich.
-
Ansonsten tausche ich Zeit gegen Geld und werde nach Stunden bezahlt.
Am Ende meines IT-Profils finden Sie Referenzen zufriedener Kunden.
Lernen Sie mich kennen, bewerben Sie sich mit Ihren Ideen und Projekten, investieren Sie in die Zusammenarbeit mit mir:
⇒ für Ihren Erfolg!
Schreiben Sie mir, rufen Sie mich an, buchen Sie einen Termin!