Jürgen Noe - Praxishandbuch SAP Business Warehouse mit BW/4HANA

Ich möchte die einzelnen Kostenkomponenten kurz näher erläutern und die notwendigen Beziehungen zwischen den benötigten ene’t-Tabellen darstellen, um die entsprechenden Teilkomponenten der Kosten zu erhalten.

Die Ermittlung der Kosten möchte ich Ihnen anhand eines Netzbetreibers in 66111 Saarbrücken exemplarisch zeigen. Öffnen Sie die CSV-Datei für PLZ_Netzbetreiber in Excel. Filtern Sie auf die Postleitzahl 66111 . Als Netznummer finden Sie im Feld Netz-Nr. den Wert 66117001 .

Für das Netznutzungsentgelt öffnen Sie die zugehörige CSV-Datei Netznutzungsentgelt.csv. Sie stellen fest, dass die Datei aus sehr vielen Spalten mit unterschiedlichen Werten besteht. Diese Datei liegt im Kennzahlenformat vor. Für die Lösung wird nur ein Teilausschnitt benötigt. Das Netznutzungsentgelt soll für Single-Privathaushalte mit einem Eintarif-Drehstromzähler ermittelt werden. Folgende Spalten werden benötigt:

Netz_Nr

ID

GUELTIG_SEIT

GUELTIG_BIS

Ms_o_LM_HH_GP

MS_o_LM_HH_AP

Filtern Sie in der Spalte Netz_Nr wieder auf den Wert 66117001 , in der Spalte Status_ID auf 1 und im Feld GUELTIG_BIS auf 31.12.2999 . Der Grundpreis ist in der Spalte MS_o_LM_HH_GP, der Arbeitspreis pro kWh in der Spalte MS_o_LM_HH_AP gespeichert. Die Formel zur Berechnung lautet folgendermaßen:

Berechnung Netznutzungsentgelt

Generelle Formel:

»Grundpreis« [€/Jahr] + Verbrauch [kWh/Jahr] * »Arbeitspreis« [Cent/(kWh)] / 100 [Cent/€]

Für die Netznummer 66117001 ermittelt sich demnach das Netznutzungsentgelt wie folgt:

35 [€] + 2500 [kWh] * 5,12 [Cent/kWh] / 100 [Cent/€] = 163,00 €.

Mit diesem Wissen kann prinzipiell ein erster Datenfluss gebaut werden. Für die weitere Modellierung ist noch ein Punkt wichtig: Soll ein rein feldbasierter, ein rein InfoObject-basierter Ansatz oder ein Mixed-Modeling-Ansatz verfolgt werden?

Mit SAP BW/4HANA ist ein rein feldbasiertes Modellieren prinzipiell möglich. Beim feldbasierten Modellieren verzichten Sie auf das Anlegen von InfoObjects und nutzen ausschließlich die Felder aus den Tabellen der angeschlossenen Systeme. Dies hat den Vorteil, dass Sie schnell einen Prototypen entwickeln können, um dem Fachbereich die ersten Ergebnisse zu präsentieren. Dies ermöglicht Ihnen auch ein operatives Reporting auf den nahezu unveränderten Quelldaten. Ebenfalls damit verbunden sind Möglichkeiten zum schnellen Verifizieren der Datenqualität durch einen Abgleich mit dem Quellsystem. Das ist wichtig, denn ein häufiger Kritikpunkt an Data-Warehouse-Systemen ist mangelnde oder unzureichende Datenqualität. Insbesondere wenn Sie SAP S/4HANA im Einsatz haben, können Sie sehr schnell Abfragen gegen SAP BW/4HANA und SAP S/4HANA durchführen und die Datenqualität beurteilen. Im einfachsten Beispiel nutzen Sie dazu die SQL-Konsole in Eclipse, führen dort für das jeweilige System die SELECT-Abfrage aus und vergleichen die Ergebnisse.

Doch hat der feldbasierte Ansatz auch ein paar Nachteile, wie z.B. beim Erstellen von Unternehmensberichten. Im Query Designer, dem Tool zur Erzeugung von Queries für InfoProvider, können für Felder keine Variablen angelegt werden und die Felder müssen BW-kompatible Datentypen aufweisen. So scheiden Felder mit datenbankspezifischen Datentypen (z.B. String) als Feld in der Query aus. Diese Felder müssen nach wie vor InfoObjects zugeordnet werden. Für Felder, in denen Variablen zur Selektion der Datenmenge benötigt werden, müssen ebenfalls InfoObjects zugeordnet werden. Der nächste Nachteil liegt in der fehlenden bzw. erschwerten Harmonisierung der Quelldaten. Nur zu oft werden Felder in mehreren Tabellen wiederverwendet und erhalten unterschiedliche Bedeutungen. Oder andersherum: Es werden verschiedene Feldnamen in den Tabellen genutzt, die aber fachlich dasselbe meinen. Harmonisierungen auf Feldebene sind prinzipiell möglich, aber aufwendig. Für Datenharmonisierungen empfehlen sich InfoObjects. Ein weiterer Nachteil von Feldern sind fehlende Stammdaten. Im klassischen Business Warehouse können über InfoObjects zusätzliche Attribute (z.B. zugehörige Adressfelder des Kunden) und Texte (z.B. der volle Name des Kunden) als Stammdaten einfach im Bericht hinzugefügt werden. Dies ist bei Feldern nicht möglich, per se beinhalten Felder diese Information nicht. Für ein Berichtswesen, in dem diese zusätzlichen Stammdaten-Informationen gewünscht werden, müssten die Tabellen immer über einen SQL-JOIN mit den entsprechenden Text- oder Attributtabellen verknüpft werden. Das macht Datenmodelle mit der Zeit sehr unübersichtlich. Welche Vor- und Nachteile bietet im Gegensatz dazu der rein InfoObject-basierte Ansatz?

Wie eben gezeigt, birgt der Ansatz mit InfoObjects einige Vorteile, wie etwa bei der Harmonisierung der Quelldaten sowie für zusätzliche Informationen wie Attribute und Texte zu einem Objekt, wie der Kunde. InfoObjects dienten ursprünglich zur Modellierung von betriebswirtschaftlichen Objekten, wie Kunde, Material oder Buchungskreis. Mit früheren Versionen des Business Warehouse stellte das InfoObject zugleich die kleinste Modellierungseinheit dar. Bei der Übernahme einer Tabelle über einen Extraktor bzw. DataSource musste für jedes Feld ein InfoObject angelegt werden. Bei der Vielzahl an Projekten und Datenmodellen, die in einem Business Warehouse genutzt werden, stieg die Anzahl der InfoObjects schnell auf mehrere Tausend an. Gerade bei DataSources mit mehreren Hundert Feldern war es sehr müßig, für jedes Feld ein neues InfoObject anzulegen. Zudem ist der technische Name des InfoObjects auf 9 Zeichen beschränkt, sodass sehr schnell wenig sprechende technische Namen für InfoObjects angelegt wurden. InfoObjects wurden außerdem gerade in der Eingangsschicht mehrfach redundant angelegt, um spätestens bei den Business Transformations einheitlichen InfoObjects zugeordnet zu werden. Bei der Erstellung musste jedes Mal geprüft werden, ob das InfoObject Stammdaten und Texte oder keines von beiden besitzen sollte. InfoObjects mussten in jeder Schicht der inzwischen klassischen LSA-Architektur zwingend genutzt werden, was einen schnellen und effizienten Aufbau eines Datenmodells oft unmöglich machte. Die nicht eindeutige Verwendung von InfoObjects führte auf Fachseite zu Diskussionen hinsichtlich des passenden InfoObject. Zusätzlich mussten die Attribute und Texte vieler InfoObjects durch regelmäßige Ladeprozesse auf einem aktuellen Stand gehalten werden. Im täglichen Betrieb kam es hin und wieder zu Fehlbeladungen und es wurden Stammdaten erzeugt, die auf Fehler im Quellsystem zurückzuführen waren. Eine Bereinigung von stammdatentragenden InfoObjects ist eine sehr aufwendige Angelegenheit.

Sowohl der rein feldbasierte als auch der InfoObject-basierte Ansatz bergen gravierende Nachteile. Welchen Kompromiss kann es hier geben?

Eine weitere Option ist der sogenannte Mixed-Modeling-Ansatz . Dabei bestehen Felder und InfoObjects gleichberechtigt nebeneinander. Über sogenannte starke betriebswirtschaftliche Objekte, wie Kunde, Material oder Buchungskreis, und die notwendigen Attribute werden InfoObjects angelegt. Die Vielzahl von beschreibenden Feldern wird jedoch als Feld ins Business Warehouse übernommen und nicht durch ein InfoObject modelliert. Dieser Ansatz bietet mehrere Vorteile:

Schnelles Prototyping: Es kann auf Feldebene ein schneller Prototyp für den Fachbereich erzeugt und z.B. über agile Methoden des Projektmanagements im Nachgang weiter verfeinert werden.

Stammdatentragende InfoObjects: An der Stelle, an der stammdatentragende oder starke betriebswirtschaftliche Objekte im Datenmodell zwingend erforderlich sind, können InfoObjects genutzt werden.