Data Platform & Data Management

Immer neue Datenquellen und Anwendungsgebiete sorgen auch weiterhin für den stetigen Ausbau von Datenhaltungssystemen, wie DWH, Data Lake oder Analytics Platform. Mit den erweiterten Anforderungen müssen auch die Datenbewirtschaftungsprozesse Schritt halten. Nicht selten wachsen kleine BI-Anwendungen zu großen Initiativen, an denen mehrere Entwicklerteams beteiligt sind. In vielen Branchen müssen Anpassungen schneller vorgenommen werden als jemals zuvor, was die Lage zusätzlich verschärft. Den Teams wird dadurch eine kurze Reaktionszeit sowie eine hohe Flexibilität abverlangt, die jedoch nicht zuletzt von der Infrastruktur getragen werden muss.

Bei Business Intelligence steht das Thema „Qualität“ immer wieder an zentraler Stelle, wird dabei aber auf die unterschiedlichsten Weisen behandelt. Das liegt daran, dass es bisher kein einheitliches Verständnis und damit auch kein standardisiertes Vorgehen zur BI-Qualität gibt.

Dass dies mehr und mehr zum Problem wird, verdeutlicht auch die Umbenennung des aktuellen Gartner Quadrant. Statt Data Quality „Tools“ heißt dieser nun Data Quality „Solutions“. Denn: Während sich viele Hersteller mittlerweile „was mit Qualität“ auf die Fahne schreiben, eint sie meist lediglich ein verschwindend kleiner gemeinsamer Nenner: Probleme zu finden, zu verstehen und zu lösen. Zwar ist dies, das muss man ihnen zugutehalten, nach dem Philosophen Karl Popper immerhin die Quelle allen technischen Fortschritts. Mit Datenqualität per se hat das aber noch nicht zwingend etwas zu tun. In diesem Beitrag werde ich deshalb das Thema BI-Qualität etwas ordnen und strukturieren und nenne das Ganze deshalb „BI Quality Management“. So bleibt noch eine Menge Luft zum „Total BI Quality Management“, wie es schon seit geraumer Zeit in den Ingenieursdisziplinen angewendet und gelehrt wird

‍

Mit SAP BW on HANA kommt das ADSO mit neuen Tabellenstrukturen und Funktionen. Im Vergleich zu den InfoProvidern, die auf nicht auf HANA basierenden SAP BW-Systemen genutzt werden, besitzen ADSOs die Fähigkeit, ihre Funktion ohne Verlust der abgelegten Daten zu ändern. Dies schließt auch eine Änderung der Inhalte von Tabellen mit ein, wenn der Typ verändert wird.

Ein ADSO besteht dabei immer aus drei Tabellen, die je nach ADSO-Typ gefüllt und verarbeitet werden. Nicht genutzte Tabellen werden vom System trotzdem angelegt. Somit ist die Nutzung in Routinen, HANA-Experten-Skripten etc. möglich, aber generell nicht immer richtig.

Vielleicht bist Du auch schon über folgendes Problem gestolpert? Du hast eine versionierte Tabelle in Deiner Datenbank und bemerkst, dass sich von Version zu Version gar nichts Relevantes ändert und Du einfach viel zu viele Zeilen hast? Wir zeigen Dir, wir Du das Problem lösen kannst!

Der Teufel steckt im Detail - welche Kleinigkeiten über die Effektivität von Partition Pruning entscheiden

In dem vorhergehenden Artikel dieser Serie wurde ein praxisnaher und effektiver Ansatz zur Nutzung von Partition Pruning eingehend erläutert. Mit Hilfe dieser einfach umzusetzenden Methode können die Abfragezeiten deutlich optimiert werden. Um jedoch die effiziente und effektive Nutzung der vorgestellten Methode zu gewährleisten, müssen, wie so häufig, einige Details beachtet werden. In diesem Aspekt halten wir es mit Theodor Fontane, der schon im 19. Jahrhundert festgehalten hat, dass der Zauber immer im Detail steckt.

Nachdem im ersten Beitrag dieser Blogreihe die herkömmlichen Wege zur Aufbewahrung historischer Daten dargestellt wurden, möchte ich in diesem zweiten Teil eine weitere, effektivere Möglichkeit zur Partitionierung einer historischen Tabelle vorstellen.

Data Warehouses nehmen im Zuge der digitalen Transformation von Unternehmen eine immer zentralere Rolle ein. Denn im Zuge der Entscheidungsfindung hält ein gutes Data Warehouse für jegliche Fragestellung entscheidungsrelevante Informationen bereit. Ein DWH kann also als ein strategisches Management-Instrument gesehen werden, dessen reibungslose Funktionsweise essentiell für den zukünftigen Unternehmenserfolg ist. In diesem Blogbeitrag wird auf eines der wichtigsten Performancefeatures eingegangen, das Partition Pruning.

Mehr als ein Jahr nach der Einführung der Datenschutz-Grundverordnung (DSGVO) fällt es vielen Unternehmen noch immer schwer, die Themen Data Warehouse (DWH) und Datenschutz unter einen Hut zu bringen. Die in den Unternehmen vorherrschende kundenzentrierte Datenmodellierung ist hierbei eine besondere Herausforderung. Sie führt bei vielen Anforderungen der DSGVO zu großen Problemen in nahezu allen datengetriebenen Prozessen. Doch warum ist es so schwer, die beiden Themen miteinander zu vereinen?

Ausgangssituation

Um ein wirksames Customer Relationship Management einsetzen zu können, ist es, besonders im Bereich des Kampagnenmanagements, von großer Bedeutung,  aussagekräftiges Wissen über die eigenen Kunden und Kundenstrukturen zu haben. Persönliche Informationen über Kunden, Ereignisse und Veränderungen in Kundensituation und -verhalten in einem CRM-System können als Anlass für eine auftretende Kommunikation genutzt werden. Mit Hilfe dieser vorhandenen Daten wird eine personalisierte Interaktion mit dem Kunden, wie Angebote und Services, ermöglicht.

Viele Unternehmen beginnen derzeit, erste Erfahrungen mit dem Einsatz von Big-Data-Methoden zu machen. Diese Methoden versprechen, aus großen Mengen an meist unstrukturierten Daten in kürzester Zeit mittels statistischer Methoden zusätzliches Wissen über die Kunden zu generieren. Häufig werden dazu automatisch generierte Daten eingesetzt, wie zum Beispiel Logfiles oder auch Clickstreams, die aus der Nutzung der Webseite, eines Webshops oder den Daten aus sozialen Netzen erhoben werden. Dieses Wissen kann wertvoll für CRM-Aktivitäten eingesetzt werden. Dabei stellt sich die Frage der Bedeutung von Datenqualität bei Einsatz von Big-Data-Methoden. Denn: Die Analyse und damit das generierte Wissen kann nur so gut sein wie die Qualität der dazu verwendeten Daten.