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

Чтение книги онлайн.

СКАЧАТЬ 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?

2.4 Ansatz mit InfoObjects

      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?

2.5 Mixed-Modeling-Ansatz

      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.

       Vereinfachungen im Betrieb und in der Entwicklung: Die Vielzahl an Ladevorgängen kann deutlich reduziert werden, wenn nur noch starke Objekte verwendet werden und keine Vielzahl an sogenannten Stammdatenprozessketten täglich eingeplant ist. Dies führt insgesamt zu einer Reduktion im Support sowie einer Senkung des TCO. Auch für die Entwicklung bedeutet es eine Vereinfachung, da bei sehr großen DataSources mit mehreren Hundert Datenfeldern nicht mehr zwingend jedes Feld mit einem InfoObject modelliert werden muss.

      Eine Einschränkung birgt dieser Ansatz allerdings: Es können in Feldern keine Variablen im Query Designer angelegt werden und die Felder müssen BW-kompatible Datentypen besitzen, um auch in Queries benutzt werden zu können. Dies trifft ebenso auf eingeschränkte Merkmale und Kennzahlen, Filter und Strukturen zu, was dazu führt, dass im Reporting doch sehr häufig InfoObjects genutzt werden müssen.

      Dieser Ansatz kann auch bei der Lösung des Fallbeispiels verwendet werden. In Abbildung 2.3 sehen Sie eine grobe Architektur als mögliche Lösung.

      Abbildung 2.3: Lösungsskizze

      Zum Einbinden der verschiedenen Datenquellen aus CSV-Dateien nutzen Sie eine DataSource. Über die DataSource wird eine sogenannte Shielding InfoSource modelliert, die das Anbinden gleichartig strukturierter Daten aus verschiedenen Quellen ermöglicht. Die InfoSource besteht aus den Feldern der jeweiligen Quelltabelle. Für die Quelltabellen Netzbetreiber, Netze, PLZ Netze und Netznutzungsentgelt wird eine InfoSource angelegt. Aus den beiden erstgenannten InfoSources wird direkt in das jeweils zugehörige, gleichnamige Merkmal Netzbetreiber und Netze fortgeschrieben. Die Modellierung als InfoObject ermöglicht im CompositeProvider Stromkosten einen einfachen Zugriff auf die Attribute und Texte des Netzbetreibers. Über der InfoSource PLZ-Netze liegt ein aDSO vom Typ »schreiboptimiert« nach dem Mixed-Modeling-Ansatz in der Struktur der Quelltabelle. Über der InfoSource NNE liegt aus technischen Gründen ein Standard-aDSO. Die Felder aus dem aDSO PLZ-Netze werden schließlich in ein aDSO Stromkosten vom Typ Standard-aDSO fortgeschrieben. In der Transformation zwischen dem aDSO PLZ Netze und dem aDSO Stromkosten werden aus dem aDSO Netznutzungsentgelt per Regeltyp Nachlesen aus aDSO die Kennzahlen für den Grund- und Arbeitspreis zur Netznummer nachgelesen. Zusätzlich wird aus den Stammdaten des InfoObjects Netze der Netzbetreiber per Regeltyp Stammdaten lesen nachgelesen. Das aDSO Stromkosten enthält dabei alle für das Reporting benötigten Merkmale und Kennzahlen. Es wird dann per Union als PartProvider in den CompositeProvider eingebunden. Über das Mapping können die Felder für den Ergebnisbericht genutzt werden.

      Doch bevor es an die konkrete Modellierung geht, folgt im nächsten Kapitel ein Kurzüberblick über Eclipse und die BW Modeling Tools in Eclipse.

      3 Arbeiten mit Eclipse

      In diesem Kapitel stelle ich Ihnen die Modeling СКАЧАТЬ