Blog

Mit der Migration auf SAP BW/4 HANA oder der Aktivierung des BW/4-HANA-Modus, der hier beschrieben ist, können Legacy-Objekte nicht mehr genutzt werden. Darunter fallen auch die beliebten MultiProvider. Diese werden genutzt, um verschiedene InfoProvider zu kombinieren und eine Abstraktionsschicht zu einer BW-Query herzustellen. Dabei können Objekte der InfoProvider verbunden werden, auch wenn diese in einem der Provider nur als Navigationsattribut vorliegen, also nicht direkt in der Faktentabelle des InfoProviders. In diesem Beispiel wird das Land einmal direkt und einmal als Navigationsattribut vom Kunden zugeordnet.

SAP BW/4 HANA ist nun seit genau einem Jahr für Kunden verfügbar. Grund, einmal zurückzublicken und einen Vergleich mit SAP BW on HANA 7.5 anzustreben. Zudem werde ich von vielen Kunden gefragt, was genau der Unterschied zwischen SAP BW/4 HANA und SAP BW on HANA ist. Deshalb möchte ich dies einmal darstellen.

Nach jahrelanger Arbeit an der Entwicklung von ETL-Anwendungen kann ich sagen, dass sie üblicherweise schlechter als Transaktionssysteme geprüft werden.

Noch einmal möchte ich mich mit dem Thema Speichernutzung auseinandersetzen. In anderen Blogartikeln wie „SAP HANA – kein Speicher mehr? Bewusster Early Unload!“ ist bereits die Relevanz der korrekten Einstellung der SAP-BW-Objekte für die vorgesehene Nutzung aufgezeigt worden. Zusammengefasst: Immer alles frühzeitig aus dem Speicher schieben, was nicht immer und sofort für Abfragen benötigt wird. Gesteuert wird dies über die „Early Unload Priority“, die in der HANA-Datenbank auf Tabellenebene gesetzt wird. Da diese Einstellungen nicht im ABAP-Transportwesen (CTS) enthalten sind, muss der Entwickler oder der Betrieb sicherstellen, dass diese Einstellung immer korrekt gesetzt ist. Ansonsten liegen nur für das Staging benötigte Daten aus dem „Data Acquisition Layer“ sehr performant im RAM, was unnötig teuer ist und das System belastet.

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.

In Zeiten der Digitalisierung ist es besonders wichtig, auf verlässliche Datenbanken zurückgreifen zu können, um Fehlerquellen auszuschließen und zielstrebiges und exaktes Arbeiten zu ermöglichen. Die Staging-Area stellt für diese Art von Anforderungen in der heutigen Zeit eine Lösung bereit. Designer und Architekten unterschätzen häufig die Notwendigkeit einer Staging-Area in der Datenbanklandschaft, da sie dies für eine Verschwendung von Platz, Leistung und Entwicklungszeit halten. Sicher ist für den Aufbau von Staging Platz und Anstrengung erforderlich, doch diese zahlt sich über den gesamten Lebenszyklus der Datenbank aus.

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.

R ist eine der populärsten Open-Source-Programmiersprachen für Predictive Analytics. Ihr großer Vorteil ist das Comprehensive R Archive Network (CRAN) mit über 10.000 Paketen für verschiedenste Modelllösungen. Ein Hindernis ihrer Anwendung besteht jedoch in der häufig paketspezifischen Syntax (im Gegensatz zu z. B. Python). Das Paket Caret versucht, durch ein einheitliches Interface auf verschiedene Trainings- und Vorhersagefunktionen den Modellierungsprozess zu vereinfachen. Durch seine Datenvorbereitungs-, Merkmalsselektions- und Modell-Tuning-Funktionalität erleichtert Caret die Bildung und Evaluierung von prädiktiven Modellen. Dieser Blogeintrag zeigt auf, wie wir mit Caret verschiedenen Herausforderungen des Modellierungsprozesses begegnen können, insbesondere bei der Selektion und dem Tuning von Modellen.

Die Automatisierung von immer wiederkehrenden Aufgabenstellungen gehört zu den grundlegendsten Prinzipien der modernen Welt. Bereits Henry Ford erkannte daraus resultierende Vorteile, wie sinkende Fehleranfälligkeit, kürzere Fertigungszyklen und eine gleichbleibende, einheitliche Qualität. Eben diese Vorteile lassen sich bei Data-Warehouse-Initiativen anwenden.

Wir wissen jetzt, wie wir die Daten richtig selektieren, welche Tabellenart wir bei Lookups nutzen sollten und wie wir sicherstellen können, dass wir nur relevante Datensätze durchlesen.

In der Praxis ist es aber oft so, dass man erstmals eine größere und/oder nicht eindeutige Datenmenge von der Datenbank selektieren muss, die dann nach bestimmten Regeln fürs performante Nachlesen aggregiert werden sollte.

Part 1: Anpassung der Gültigkeit des Datensatzes

Der Oracle Data Integrator (ODI) bietet eine eingebaute Lösung, um Daten mit der SCD-Methodik (Slowly Changing Dimension) zu historisieren. Bei näherer Betrachtung und der praktischen Beladung einer Integrationsmenge in eine Zieltabelle mithilfe des Integration Knowledge Modules (IKM) SCD fällt auf, dass der ODI gewisse "Default Values" für das Gültigkeitsende des Datensatzes verwendet.

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.