Immer diese Stammdaten, Teil 2

Willkommen zu dem zweiten Teil meines Beitrags über Änderungen von Stammdaten. Wie ich bereits im ersten Teil angekündigt habe, werde ich mich heute der Erweiterung der bisher bereits erstellten Transformation widmen. Zunächst ein kleiner Rückblick, was haben wir schon gemacht.
In Teil I haben wir im BI-Development Studio (kurz: BIDS) ein Paket mit einem integrierten Lookup-Task (deutsch: Suche) erstellt. Der Task verglich die Quelldaten bereits mit den vorhandenen Datensätzen in der Zieltabelle auf unserem SQL-Server und mit Hilfe eines kleinen Scripts am Ende des Datenflusses konnten wir neue Datensätze in die Tabelle mit aufnehmen. Darüber hinaus hatten wir den Lookup-Task bereits so konfiguriert, dass die Spalten „Position“ und „Gewicht“ bereits in einer Art „Überwachung“ (im BIDS sprechen wir hier von der Ausgabe für Suchübereinstimmungen) vorgehalten wurden. Zusätzlich hat das SQL-Script dann noch in die Zieltabelle das Importdatum eingetragen bzw. aktualisiert. Das war schon sehr schön, aber wir wollen noch mehr, oder?
Typische Fragen wie: „Wann wurde der Wert denn geändert?“ oder meist noch wichtiger „Was hat sich geändert?“ können wir unseren Kunden so leider noch nicht beantworten. Mit nur ein paar kleinen Änderungen an unserem Importprozess bringen wir auch hier Licht ins Dunkel. Und wie genau? Einfach weiterlesen und mitmachen, es lohnt sich. weiterlesen…

Immer diese Stammdaten

In unserer schnelllebigen Welt ändern sich die Daten (Werte) so schnell, dass die große Herausforderung in der Aktualität dieser Daten liegt. Nun kennen wir dies Thema praktisch in jedem Projekt und wie so oft gibt es diverse Lösungswege, die mehr oder weniger aufwändig und komplex zu implementieren sind. Eine Möglichkeit sich dem Problem zu nähern ist der Einsatz einer Transformation im BI Development Studio (kurz: BIDS), dem Lookup-Task (Achtung: erst ab SQL-Server 2008 einsetzbar). Vereinfacht dargestellt bietet der Lookup-Task eine Art Veränderungslogik, sprich: was ändert sich wann, wie und wo. Da dieser Schritt, je nach Konfiguration, unterschiedlichste Komplexitäten annehmen kann, beginne ich zunächst mit der einfachsten, trotzdem schon sehr nützlichen Variante. In einem zweiten Beitrag werden wir dann dieses Projekt um weitere Funktionalitäten erweitern. weiterlesen…

Historische Betrachtung von Stammdaten im Data Warehouse (DWH)

Der OLAP-Ansatz ist für die Entscheidungsunterstützung ausgelegt. Dabei sind historische, aggregierte und konsolidierte Daten viel wichtiger als die einzelnen detaillierten Datensätze. Meist sind diese Daten über verschieden lange historische Zeiträume vorhanden. Da also in einem Data-Warehouse (DWH) üblicherweise historische Daten verwaltet werden, sind beispielsweise bei Änderungen der Zuordnung von Kunden zu Kundengruppen in den Datenquellen in Form von periodischen “Snapshots” im DWH zu speichern. In anderen Beiträgen konnten Sie schon erfahren, wie etwa die historische Betrachtung von Bestandswerten, die als Bewegungsdaten gelten, implementiert werden kann. In diesem Beitrag stellen wir Ihnen Methoden zur Historisierung von Stammdaten vor. weiterlesen…