Kitabı oku: «Praxishandbuch SAP Business Warehouse mit BW/4HANA», sayfa 2

1.2.3 Die Referenzarchitektur LSA

Parallel zur Entwicklung der ersten Data Warehouses wuchsen, bedingt durch den Aufstieg von SAP R/3 zum Werkzeug für die unternehmensweite Ressourcenplanung, die Anforderungen an das unternehmensinterne Berichtswesen. Mithilfe des herkömmlichen ERP-Systems waren diese Anforderungen nur noch schwer zu erfüllen.

In der ersten Hälfte des Jahres 1997 ging SAP Business Information Warehouse 1.2A für wenige ausgewählte Kunden an den Start. Bill Inmon hatte dazu mit seiner CIF-Idee architektonisch die Vorarbeit geleistet. Die SAP griff seine Idee auf und nutzte sie für die generelle Strukturierung und Modellierung des eigenen Business Warehouse. Architektonisch war das SAP Business Warehouse bis zur Version 7.5 in die Infrastruktur von SAP NetWeaver integriert. Im Laufe der Zeit entwickelte sich SAP Business Warehouse durch den sogenannten Business Content kontinuierlich weiter, mit dem schnell und einfach betriebliche Prozesse verschiedener Branchen abgebildet werden konnten. Mit der zunehmenden Anzahl an Funktionalitäten und neuen Einsatzgebieten stieg jedoch auch die Komplexität und warf bei den Anwendern Fragen bezüglich der Data-Warehouse-Architektur auf. Die klassische Schichtenarchitektur erwies sich in vielen Belangen als zu starr und wenig flexibel bezüglich Anpassungen und Erweiterungen. Den Fachabteilungen dauerte es oft zu lange, bis eine angeforderte Änderung produktiv gehen konnte.

Mit den Jahren und mit zunehmender Erfahrung im dauerhaften Betrieb eines Warehouse setzte sich die Erkenntnis durch, dass ein Business Warehouse eine zukunftsfähige Architektur benötigt, die mit dem Unternehmen mitwachsen kann. 2009 entwarf SAP eine skalierbare Architektur unter dem Namen Layered Scalable Architecture (LSA), also skalierbare Schichtenarchitektur.

Zentraler Ansatzpunkt war, dass man auch zukünftig in der Lage sein wollte, schnell sowie mit nur wenigen Eingriffen in die existierenden Datenmodelle und Applikationen auf geänderte Anforderungen reagieren zu können.

Abbildung 1.3 stellt die Referenzarchitektur der LSA von SAP in der Übersicht dar.

Abbildung 1.3: LSA-Blöcke (eigene Darstellung)

Die einzelnen Blöcke werden nacheinander durchlaufen, und im Zuge dessen werden die einzelnen Bausteine an den Bedürfnissen und Prozessen des Kunden ausgerichtet. Mit dem Kunden werden innerhalb des Blocks »Bausteine« beispielsweise die Granularität der Schichten definiert und Vorgaben für Datenmodelle sowie Entwicklungsrichtlinien festgelegt. Damit entsteht eine kundenindividuelle LSA, die die Prozesse und die Umgebung des Kunden exakt widerspiegelt. Die LSA bietet somit weit mehr als die reine Schichtenarchitektur des bisherigen Data Warehouse, indem sie alle Prozesse beschreibt, die für den Aufbau sowie für den reibungslosen Betrieb eines Business Warehouse erforderlich sind. Für die Gliederung in einzelne Schichten findet sich in der Referenzarchitektur ein Vorschlag (siehe Abbildung 1.4).

Abbildung 1.4: LSA-Schichtenmodell

Man erkennt hier eine Fünf-Schichten-Architektur. Die Eingangsschicht entspricht dem Staging-Bereich in Bill Inmons CIF (vgl. Abschnitt 1.2.2). Die Ebenen Datenqualitäts- und Harmonisierungsschicht, Datenverteilungsschicht sowie Schicht zu Umwandlung in Fachbereichsdaten entsprechen zusammengenommen grob der ETL aus Bill Inmons CIF. Die oberste Schicht, die Berichtsebene mit den Data Marts der Fachabteilungen, entspricht dem Enterprise Data Warehouse. Das Corporate Memory hält die Daten der Eingangsschicht harmonisiert und in Unternehmensbegrifflichkeiten übersetzt zum Wiederaufbau der Applikationen vor, falls die Daten nicht mehr aus dem Quellsystem geladen werden können. Dies kann der Fall sein, wenn die Daten im Quellsystem aus Datenschutz- oder Archivierungsgründen gelöscht werden mussten.

1.3 Grundlegende Architektur von SAP BW/4HANA

Schon seit Mitte der Siebzigerjahre war das Konzept der spaltenbasierten Datenbanken bekannt, in denen die Daten nicht wie bei herkömmlichen relationalen Datenbanken in Zeilen, sondern in Spalten abgelegt sind. Diese Form der Speicherung eignet sich besonders für Data Warehouses und OLAP-Systeme. Erweitert wurde das Konzept durch sogenannte In-Memory-Datenbanken, wie beispielsweise 1997 durch QlikView.

2007 stellte die SAP ihre erste In-Memory-Lösung unter dem Namen SAP Business Warehouse Accelerator vor. Dabei handelte es sich um zusätzliche Hardware, in der die Daten nicht mehr Zeile für Zeile, sondern in Spalten abgelegt wurden. Mit einem an das BW angeschlossenen Business Warehouse Accelerator konnte die Abfrageperformance deutlich erhöht werden.

In den folgenden Jahren wurde diese Technologie ständig weiterentwickelt. 2010 präsentierte das Hasso-Plattner-Institut in Berlin die neue Lösung SAP HANA. Bei SAP HANA handelt es sich nicht nur um eine reine In-Memory-Datenbank, die in sehr kurzer Zeit auf sehr große Datenmengen zugreifen kann. Es ist vielmehr eine komplette Plattform. Zu dieser gehören neben der SAP HANA Appliance und SAP HANA In-Memory Appliance auch die SAP In-Memory Computing Engine. Die SAP-HANA-Datenbank speichert sowohl Daten aus OLTP- als auch aus OLAP-Systemen.

SAP BW und SAP HANA

SAP HANA wird erst mit SAP BW 7.3 als Datenbank unterstützt. Frühere Releases von SAP BW können nicht mit dieser Technologie genutzt werden.

Mit dem Einsatz der SAP-HANA-Plattform ergeben sich Änderungen an der Layered Scalable Architecture. 2012 veröffentlichte die SAP Anpassungen an der LSA unter der Bezeichnung LSA++. Abbildung 1.5 stellt die Architektur zusammenfassend dar.

Abbildung 1.5: Architektur von LSA++

Ein Bestandteil der Architektur ist u.a. eine virtuelle Data-Marts-Schicht in BW, in der sich die Daten aus den vorhergehenden Schichten als sogenannte externe View in SAP HANA ablegen lassen. Dadurch können Queries mit optimalen Zugriffszeiten auf operationale Daten gebaut werden. Während die LSA noch – überwiegend aus Performancegründen – eine Trennung zwischen Berichtsebene und den operationalen Daten vollzog, entfällt diese Trennung durch den Einsatz von SAP HANA. Mit dieser neuen Datenbanktechnologie von SAP kann auf alle Schichten der LSA++-Architektur gleichermaßen leistungsfähig zugegriffen werden, was letztlich ein operatives und taktisches Berichtswesen zulässt. Die großen Vorteile liegen hier in einer Auflösung des starren Schichtenmodells, das mehrfach redundante Speicherung erzwang, und einem flexibleren Aufbau der Unternehmensberichte auf operationalen und taktischen Daten.

Migration auf SAP BW/4HANA

Eine Darstellung aller Funktionalitäten sowie Migrationsmöglichkeiten von einem Business Warehouse on any DB oder SAP BW on HANA auf SAP BW/4HANA sprengt den Rahmen dieses Buches. Als weiterführende Lektüre verweise ich auf das Buch »SAP BW/4HANA und BW auf HANA«, 2., erweiterte Auflage (Sauer/Riesner, Espresso Tutorials, 2017)

Als Folge der Einführung von SAP HANA als grundlegende Plattform war es nur logisch, SAP Business Warehouse ebenfalls technologisch auf neue Füße zu stellen. Mit der Version 7.5 des SAP Business Warehouse liefert SAP die letzte Version eines auf SAP NetWeaver basierten Warehouse. Weiterentwicklungen oder neue Funktionalitäten sind aktuell für SAP BW 7.5 nicht geplant. Da die neue technologische Basis für SAP Business Warehouse die Datenbank SAP HANA ist, erhielt das neue Produkt auch einen entsprechenden Namen: »SAP BW/4HANA«. SAP HANA dient dabei sowohl zur Speicherung der Daten als auch zur Abwicklung von Logiken im Bereich des ETL oder zur Umwandlung der Fachbereichsdaten. Für die Beschreibung Letzterer stellt SAP HANA beispielweise spezielle mathematische, statistische oder auch String-Verarbeitungsfunktionen zur Verfügung. Aus Gründen der Abwärtskompatibilität verfügt SAP BW/4HANA über einen kleinen ABAP Stack, mit dem der Entwickler Business-Logik in ABAP hinterlegen kann.

1.3.1 Elemente und Struktur von SAP BW/4HANA

Wie in Abbildung 1.5 ersichtlich, können Sie an SAP BW/4HANA verschiedene Quellsysteme anschließen. Dies können andere SAP-Systeme, Dateien, relationale Datenbanken, aber auch Webservices sein.

Die Anbindung der verschiedenen Quellsysteme erfolgt über sogenannte DataSources, die ein Eins-zu-eins-Abbild der Quelldaten darstellen.

Die Eingangsebene der Daten kann in SAP BW/4HANA mit sogenannten Advanced DataStore Objects (aDSO) in der Ausprägung eines schreiboptimierten DSO modelliert werden. Dies sind flache Tabellen, in denen die Daten aus dem Vorsystem unverändert abgelegt, historisiert und im nächsten Schritt über ETL-Methoden an das SAP Business Warehouse übertragen werden können.

Das kleinste Element der Modellierung in SAP BW/4HANA stellt das sogenannte InfoObject dar. InfoObjects lassen sich wiederum nach Merkmalen und Kennzahlen unterscheiden.

Methoden der Datenverarbeitung stehen in SAP BW/4HANA ausschließlich in Form von Transformationen zur Verfügung. Als Lademethode dient der Datentransferprozess. Datenziele einer Transformation heißen in SAP BW/4HANA allgemein InfoProvider. Die beiden wichtigsten Typen der InfoProvider sind das bereits erwähnte aDSO sowie der CompositeProvider. CompositeProvider bieten eine für die mehrdimensionale Analyse optimierte Sicht auf die Daten. Der CompositeProvider vereint technisch die Möglichkeiten einer SQL-UNION und eines SQL-JOIN aus den verschiedenen beteiligten InfoProvidern.

SQL-JOIN

Ein SQL-JOIN liefert aus den Datensätzen zweier oder mehrerer Tabellen einer relationalen Datenbank eine Ergebnistabelle, deren Datensätze Felder der verwendeten Tabellen anhand einer Verbundoperation (JOIN) enthalten.

Beispielabfrage: Liefere mir alle Rechnungen eines Kunden mit Kundennamen, Rechnungsdatum und Rechnungsbetrag.

Das zugehörige SQL zeigt Listing 1.1.

SELECT Kunde.Vorname, Kunde.Nachname, Rechnung.Rechnungsdatum, Sum(Rechnung.Nettobetrag) AS Summe_Netto FROM Rechnung INNER JOIN (Kunde INNER JOIN Kundenrechnung ON (Kunde.Kdnr = Kundenrechnung.Kdnr) AND (Kunde.Kdnr = Kundenrechnung.Kdnr)) ON (Kundenrechnung.Rechnungsnr = Rechnung.Rechnungsnr) AND (Rechnung.Rechnungsnr = Kundenrechnung.Rechnungsnr) GROUP BY Kunde.Vorname, Kunde.Nachname

Listing 1.1: Alle Rechnungen eines Kunden mit Kundendaten

SQL-UNION

Bei einer SQL-UNION werden die Ergebniszeilen von zwei oder mehr Tabellen verkettet.

Beispielabfrage: Liefere mir die Vornamen und Nachnamen aller Kunden und Lieferanten.

Das zugehörige SQL lautet:

SELECT Vorname, Nachname from Kunde UNION Select Vorname, Nachname from Lieferant;

Der CompositeProvider ist somit eine Weiterentwicklung und Vereinheitlichung der aus den SAP-NetWeaver-basierten Versionen des Business Warehouse bekannten InfoProvider-Typen »MultiProvider« und »InfoSet«. Mit der Option, Daten über eine externe View direkt als SAP-HANA-Tabelle bereitstellen zu lassen, können externe Tools ebenfalls auf die Daten in der SAP-HANA-Datenbank zugreifen. Benötigt wird hierfür lediglich ein passender SAP-HANA-ODBC- oder -JDBC-Treiber für die Zieldatenbank.

Der Query Designer dient auch unter SAP BW/4HANA als das Tool, um Daten in aggregierter oder angereicherter Form für ein Reporting zur Verfügung zu stellen. Unter SAP BW/4HANA und SAP BW on HANA hat der Query Designer ein Facelifting erfahren und wird als Eclipse-Plug-in innerhalb der BW Modeling Tools angeboten. Das Anlegen und Ausführen von Queries sprengt allerdings den Rahmen des Buches. Daher empfehle ich für das Arbeiten mit dem Query Designer in Eclipse mein Buch »Schnelleinstieg in den SAP Query Designer mit Eclipse« (Espresso Tutorials, 2017).

1.3.2 Kurzübersicht SAP BW/4HANA

SAP BW/4HANA ermöglicht eine sehr effiziente Integration verschiedenster SAP-Systeme über vorgefertigte Extraktoren, die der Kunde bei Bedarf anpassen kann. Die Architektur von SAP BW/4HANA zeigt Abbildung 1.6.

Abbildung 1.6: SAP-BW/4HANA-Architektur (eigene Darstellung)

Wie in der Abbildung unter zu sehen, ermöglicht SAP BW/4HANA das Einbinden verschiedener externer Quellen (Sources). Dies sind z.B. andere Datenbanken wie Microsoft SQL Server oder Oracle-Datenbanken. Über die Schnittstelle mit SAP Vora kann auch Hadoop, eine Lösung für Data Lakes, angeschlossen werden. Die Operational-Data-Provisioning(ODP-)Schnittstelle überträgt die Daten aus SAP-Quellsystemen per standardisiertem Delta-Handling an das BW-System. Bei ODP handelt es sich um einen Provider-Consumer-Ansatz. Das Quellsystem bietet über die ODP-API die Möglichkeit, dass Daten, wie beispielsweise die Kundenstammdaten, von beliebigen an das Quellsystem angeschlossenen Systemen konsumiert werden können. Die einzige Voraussetzung ist, dass das angeschlossene System die ODP-Schnittstellen-API ebenfalls implementiert hat. Sobald in SAP BW/4HANA ein Datentransferprozess zum Extrahieren der Kundendaten angestoßen wird, registriert sich das BW-System als Consumer beim Kundenstammdaten-Provider im Quellsystem. Über Zeitstempel und Datensatzzeiger kann daher ein sicherer, standardisierter Delta-Mechanismus zur Verfügung gestellt werden. Die ODP-Schnittstelle ersetzt die BICS-Schnittstelle, die aus den SAP-NetWeaver-basierten BW-Systemen bekannt ist, zum Datentransfer zwischen SAP-Systemen. Mit der ODP-Schnittstelle einher geht ein geändertes Verfahren, wie Datensätze im Delta-Init-Verfahren an SAP BW/4HANA übertragen werden. Dies ist eine wesentliche Neuerung in SAP BW/4HANA. Eine detaillierte Betrachtung der ODP-Schnittstelle sprengt jedoch den Rahmen dieses Buches.

Die SAP-HANA-Plattform wiederum besteht aus mehreren Komponenten; die wichtigsten im Zusammenhang mit BW sind die Datenbank (DB), die Calculation Engine (Calc. Eng.) sowie der SAP Smart Data Access (SDA) bzw. die SAP Smart Data Integration (SDI). Über SDA bzw. SDI können relationale Datenbanken angeschlossen und so gezielt einzelne relationale Tabellen oder Sichten auf eine Tabelle zeitgesteuert ins BW geladen werden.

In Abbildung 1.6 unter sind die geeigneten Tools aufgeführt. Aufgaben in der Datenbank sowie Arbeiten mit der Calculation Engine oder SDA erfolgen mit den SAP HANA Modeling Tools.

SAP BW/4HANA Application besteht aus dem eigentlichen Data Warehousing mit einer LSA++-Architektur und dem Analytical Manager für OLAP-Operationen bzw. mehrdimensionale Auswertungen. Daneben steht das Metadata Repository, das die gesamten Metadaten, also im Wesentlichen die Struktur der einzelnen Objekte, verwaltet. Als Schnittstellen zu anderen externen Systemen bietet SAP hier einerseits ODP und andererseits den Open Hub an. Für eine Zusammenarbeit im Team an einer gemeinsamen Aufgabe können Workspaces genutzt werden. Sie erlauben es dem Fachbereich und der IT, gemeinsam an einem Datenmodell zu arbeiten und dies grundsätzlich zu entwickeln, um es nach einer Abstimmung anschließend in das Data Warehousing zu übernehmen. Der Einsatz von Workspaces empfiehlt sich besonders für agile Projektmanagement-Methoden, wie etwa SCRUM.

Oberhalb von SAP BW/4HANA Application sind die Business User Tools angeschlossen. Dabei handelt es sich zum einen um SAP-Analytics-Lösungen, wie etwa SAP Analysis for Microsoft Office oder SAP Analytics Cloud. SAP Lumira wird nicht mehr weiterentwickelt, und der Support dafür wurde 2019 eingestellt. Zum anderen ist hier die Planungskomponente SAP Business Planning and Consolidation (BPC) zu nennen. Die SAP-BW/4HANA-Application-Schicht ist die Schnittstelle für weitere Tools von Drittanbietern für ein formatiertes Berichtswesen oder Management-Dashboards, wie etwa Qlik, Tableau und weitere.

Damit möchte ich den eher theoretischen Teil und die Einführung in SAP BW/4HANA beenden und mich im nächsten Kapitel dem Fallbeispiel zuwenden.

2 Fallbeispiel

In diesem Kapitel lernen Sie das Fallbeispiel mit Lösungsansatz kennen. Es werden kurz der rein feldbasierte, der InfoObject-basierte sowie der Hybrid- oder Mixed-Modeling-Ansatz zur Lösung vorgestellt.

2.1 Aufgabenstellung

Sie arbeiten in der IT-Abteilung eines Unternehmens aus der Energiewirtschaft. Ihre IT-Landschaft ist durch eine Vielzahl von verschiedenen Systemen und Anwendungen geprägt. Für die kritischen Prozesse ist SAP als führendes System gesetzt. Sie haben zahlreiche Kunden, jedoch ist der Markt durch Preiskämpfe geprägt. Über einschlägige Internetseiten kann sich der Verbraucher jederzeit über den günstigsten Stromtarif informieren. Davon ausgehend, dass alternative und erneuerbare Energien in nächster Zeit staatlich günstiger besteuert werden, entschließt sich Ihr Unternehmen, ein neues Stromprodukt speziell für Singles auf den Markt zu bringen. Der Marketing- und Produktabteilung fehlt jedoch eine verlässliche Aussage über einen konkurrenzfähigen Preis für das neue Stromprodukt.

Da der Energiemarkt stark staatlich kontrolliert ist, melden alle Energieunternehmen, im Weiteren »Netzbetreiber« genannt, die Strompreise einer zentralen Stelle, der Bundesnetzagentur. Die Bundesnetzagentur erlaubt verschiedenen Anbietern, diese Informationen zu verarbeiten, um sie öffentlich und auch für Privatverbraucher zur Verfügung zu stellen. Die gestellte Aufgabe von der Marketing- und Produktabteilung beinhaltet daher, eine Liste aller aktuellen Netzbetreiber mit dem aktuell gültigen Preis für einen Single-Privathaushalt mit ca. 2500 kWh Jahresverbrauch zu erstellen. Für unser Beispiel soll die Preisermittlung sehr stark vereinfacht werden. Der Preis soll in einem ersten Schritt nur anhand des Netznutzungsentgelts berechnet werden. Ein Netzbetreiber kann dabei den Strom an verschiedene postalische Orte in Deutschland liefern. Dies sind die sogenannten Liefergebiete. Die von der Marketingabteilung geforderte Liste soll folgende Felder enthalten:

 Postleitzahl Liefergebiet

 Ort Liefergebiet

 Netzbetreibername

 Sitz des Netzbetreibers (Ort)

 Postleitzahl des Netzbetreibers

 Höhe Netznutzungsentgelt (NNE)

2.2 Datengrundlage

Da der gesamte Energiemarkt reguliert ist, können Sie auf einen Anbieter zurückgreifen, der die zur Lösung des Fallbeispiels benötigten Informationen, wie Netzbetreiber auf PLZ-/Ort-Ebene und die zugehörigen Kosten, vorhält. Die Firma ene’t aus Hückelhoven stellt diese mit vielen weiteren zusätzlichen Informationen in Ihrem Downloadbereich zur Verfügung. Unter der URL https://download.enet.eu/uebersicht/datenbanken finden Sie eine Reihe von öffentlich zugänglichen Daten, wie Abbildung 2.1 zeigt.

Abbildung 2.1: Frei verfügbare ene’t-Datenbanken

Laden Sie sich von dieser Seite die ZIP-Datei für Netznutzung Strom als CSV und MSSQL herunter und speichern Sie beide Dateien lokal auf Ihrem PC. Anschließend entpacken Sie die Dateien in einen Ordner Ihrer Wahl. Schauen Sie sich den Ordner mit den entpackten CSV-Dateien kurz an und scrollen Sie etwas die Seite hinunter bis an die Stelle aus Abbildung 2.2.

Abbildung 2.2: Auszug aus ene’t-Dateien

Die vorliegenden Daten enthalten nur einen Ausschnitt der gesamten Datenmenge. Dieser reicht für unser Fallbeispiel jedoch aus. Anhand der Dateinamen sehen Sie, dass das Datenmodell von ene’t normalisiert vorliegt. Die Daten zur Lösung der Aufgabenstellung sind daher auf mehrere Dateien bzw. Tabellen aufgeteilt.

Die Lösung erfordert eine Tabelle, die Ihnen pro Postleitzahl und Ort den aktuellen Netzbetreiber liefert. Für den Sitz des Netzbetreibers und die Postleitzahl des Netzbetreibers benötigen Sie seine Stammdaten. Zum weiteren Verständnis hilft, dass das deutsche Stromnetz in viele kleinere Stromnetze aufgeteilt ist. Jedes dieser kleineren Stromnetze hat eine eindeutige Netznummer zur Identifikation erhalten. Jeder Netznummer ist dabei eindeutig ein Netzbetreiber zugeordnet. Die Preiskalkulation erfolgt über eine Tabelle mit dem Netznutzungsentgelt.

Konkret sind für das Fallbeispiel nur die in Tabelle 2.1 ausgewiesenen ene’t-Tabellen erforderlich:

ene’t-Tabelle	Beschreibung
Netzbetreiber	Stammdaten des Netzbetreibers, wie Adresse, Bundesland, Kontaktdaten, …
Netze	Stammdaten mit Zuordnung des Netzbetreibers zur Netznummer
PLZ_Netzbetreiber	Liste aller Postleitzahlen und Orte mit zugeordneter Netznummer
Netznutzungsentgelt	Netznutzungsentgelt pro Netznummer

Tabelle 2.1: enet’t-Tabellen für Fallbeispiel

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?