Sie möchten erfahren, wie ABAP Core Data Services (CDS) in Kombination mit dem virtuellen Datenmodell (VDM) Ihr Datenmanagement grundlegend optimieren können?
Sie wissen, dass Ihre Unternehmensdaten wertvolle Informationen enthalten und möchten diese nutzen, um erfolgsversprechende Entscheidungen zu treffen?
Nehmen Sie sich ein paar Minuten Zeit und lernen Sie in diesem Blogbeitrag den Aufbau und die Vorteile des virtuellen Datenmodells sowie die Verwendung von ABAP Core Data Services kennen.
Stamm- und Bewegungsdaten im CDS-Kontext?
Daten enthalten wertvolle Erkenntnisse über Ihr Geschäftsgeschehen. Um konkrete Schlüsse aus Ihren Daten ziehen zu können, ist das richtige Verständnis der Daten von großer Bedeutung.
Lassen Sie uns gemeinsam tiefer in diese Welt eintauchen und einen Blick auf die Grundlagen der Berichterstattung und Geschäftsanalysen werfen.
Dimension View
Dimensionen sind Stammdaten, die nicht aggregiert werden, sondern oftmals Textinformationen wie Produktkategorien, Zeiträume, geografische Standorte, Kunden oder Verkäufer enthalten. ABAP Core Data Services sind Ihre Werkzeuge, um diese Daten zu durchforsten und deren Geschichte zu verstehen. Sie bieten Ihnen die Möglichkeit, die Daten zu kategorisieren, zu filtern und zu gruppieren.
Fact View
Fakten sind die Zahlen, die Ihre Geschichte vervollständigen. Dabei sprechen wir von Bewegungsdaten, die durch Messungen oder Kennzahlen quantifizieren, wie viel von einer bestimmten Aktivität stattgefunden hat. Beispiele hierzu sind Verkaufsmengen, Umsatz, Kosten oder Gewinn.
Virtuelles Datenmodell (VDM)
Das virtuelle Datenmodell (VDM) revolutioniert den Umgang mit Ihren Daten.
Durch die betriebswirtschaftliche Semantik werden diese für Sie verständlich und leicht nutzbar aufbereitet, sodass technische Bezeichnungen oder die Struktur der Daten keine Herausforderung mehr für Sie darstellen.
Klare Trennung, mehr Effizienz
Das Fundament für eine reibungslose Datenverarbeitung bilden dabei eine klare Definition des Datenmodells sowie die Nutzung aussagekräftiger Namenskonventionen. Sie gewährleisten die klare Trennung von Datenzugriff, Geschäftslogik und Benutzeroberfläche. Auch Wartung, Skalierbarkeit und Weiterentwicklung Ihres virtuellen Datenmodells werden dadurch erheblich vereinfacht.
Ein VDM besteht im Wesentlichen aus drei Schichten, die im Folgenden dargestellt sind:
Basic-Interface-Views
Mit Views dieser Schicht greifen Sie direkt auf Tabellen der Datenbank zu. Die darin liegenden Inhalte stehen Ihnen ungefiltert zur Verfügung. Technische Namen, Eigenschaften und Struktur der Daten können Sie bereits hier in betriebswirtschaftliche Entitäten umwandeln.
Views dieser Schicht ermöglichen einen effizienten, direkten Datenzugriff auf Datenbanktabellen und verfügen über eine große Wiederverwendbarkeit für unterschiedlichste Anwendungen.
Composite-Interface-Views
Mit Views dieser Schicht bilden Sie neue, eigenständige, betriebswirtschaftliche Entitäten ab. Die Daten dieser Entitäten stammen oftmals aus unterschiedlichen Datenbanktabellen und werden je nach Bedarf zu einer neuen betriebswirtschaftlichen Entität kombiniert.
Views dieser Schicht setzen sich aus Basic-Interface-Views zusammen oder bauen auf einem anderen Composite-Interface-View auf.
Consumption-Views
Mit Views dieser Schicht bilden Sie die oberste Schicht eines Virtuellen Datenmodells ab. Sie bauen auf einem Composite-Interface-View auf und orientieren sich inhaltlich an Ihren betriebswirtschaftlichen Anforderungen. Sie stellen die Grundlage für Ihr spezifisches Reporting dar und verfolgen nicht das Ziel einer großen Wiederverwendbarkeit.
Zusammenführung und Verknüpfung von Daten
Sie haben den Anspruch wertvolle Erkenntnisse aus Ihren Daten zu gewinnen und bestmögliche Entscheidungen für Ihr Unternehmen zu treffen. Um derartige erfolgversprechende Auswertungen durchführen zu können, benötigen Sie häufig eine Kombination von Daten aus unterschiedlichen Datenbanktabellen.
Nachfolgend möchten wir Ihnen anhand von Beispielen aufzeigen, weshalb sich das virtuelle Datenmodell in diesem Fall besonders gut eignet. Dabei gehen wir näher auf die Nutzung von Zwischenschichten und die Kombination von Daten über Joins, Unions und Assoziationen ein.
Zusammenführung von Daten aus unterschiedlichen Datenbanktabellen
In diesem Beispiel möchten wir Ihnen den Aufbau eines Stammdaten-Reportings aufzeigen. Hierfür werden unterschiedliche Felder aus den nachfolgenden Tabellen benötigt:
Tabelle COBK – CO-Objekt: Belegkopf
Benötigte Felder:
Technischer Name | Beschreibung |
KOKRS | Kostenrechnungskreis |
BELNR | Belegnummer |
Tabelle COEP – CO-Objekt: Einzelposten periodenbezogen
Benötigte Felder:
Technischer Name | Beschreibung |
SGTXT | Segmenttext |
KSTAR | Kostenart |
Datenzugriff
Im ersten Schritt greifen wir auf die unformatierten Daten aus den Tabellen COBK und COEP zu. Hierzu werden zwei eigene Basic-Interface-Views im Datenmodell erstellt. Für die technischen Namen nutzen wir direkt die betriebswirtschaftliche Semantik und versehen diese mit sprechenden Bezeichnungen.
Basic-Interface-View ZPK_BASIC_VIEW_COBK:
Dieser Basic-Interface-View zeigt in der Datenvorschau folgende Ausgabe mit entsprechenden Daten aus der Tabelle COBK:
Data Preview Basic-Interface-View ZPK_BASIC_VIEW_COBK:
Basic-Interface-View ZPK_BASIC_VIEW_COEP:
Dieser Basic-Interface-View zeigt in der Datenvorschau folgende Ausgabe mit entsprechenden Daten aus der Tabelle COEP.
Data Preview Basic-Interface-View ZPK_BASIC_VIEW_COEP:
Kombination der Basic-Interface-Views und Zusammenführung von Daten
Wie in den obigen Grafiken dargestellt, stehen zwei Basic-Interface-Views mit den benötigten Feldern zur Verfügung. Für die weitere Verarbeitung der Daten werden diese Felder in einer eigenen, gemeinsamen View benötigt.
Im virtuellen Datenmodell wird hierzu eine Zwischenschicht erstellt.
Dabei handelt es sich um einen weiteren, eigenen Basic-Interface-View, der mit Hilfe eines Joins, die Daten aus den beiden bereits erstellten Basic-Interface-Views miteinander verknüpft.
Neben einem Join können Sie im virtuellen Datenmodell auch Assoziationen und Union Anweisungen verwenden. Wozu diese sich besonders gut eignen, wird im weiteren Verlauf aufgezeigt.
In unserem Beispiel werden die erstellten Basic-Interface-Views mit Hilfe eines Joins verbunden. Dabei erfolgt die Verbindung der Daten über die Schlüsselfelder Belegnummer (Document Number) und Kostenkreis (Controlling Area).
Basic-Interface-View ZPK_BASIC_VIEW_JOIN:
Dieser Basic-Interface-View zeigt in der Datenvorschau folgende Ausgabe mit entsprechenden Daten aus den beiden vorherigen Views, die auf die Inhalte der Tabellen COBK und COEP zugreifen:
Data Preview Basic-Interface-View ZPK_BASIC_VIEW_JOIN:
Erweiterung des Datenmodells mittels Assoziation
Im nächsten Schritt wird ein Composite-Interface-View erstellt.
Dieser basiert auf der Grundlage des zusammengeführten Basic-Interface-Views und enthält somit alle benötigten Felder für das spätere Stammdaten-Reporting.
Oftmals kommt es vor, dass während der Erstellung des Datenmodells oder im Nachgang weitere Felder aus bisher nicht verwendeten Datenbanktabellen für das Reporting benötigt werden.
Ein großer Vorteil der Composite-Interface-View besteht darin, dass derartige Felder einfach mittels Assoziationen zum Datenmodell hinzugefügt werden können.
Assoziationen verhalten sich aus technischer Sicht sehr ähnlich zu einem Join, jedoch sind diese wesentlich performanter, da sie nur dann ausgeführt werden, wenn die Felder tatsächlich abgerufen werden.
In unserem Beispiel soll dem Composite-Interface-View das Feld Country und die zugehörigen Texte hinzugefügt werden. Die benötigten Daten stammen aus einem eigenen Basic-Interface-View, welcher auf die Tabelle BWV_T005T zugreift.
Hierfür wird eine Assoziation verwendet, die in dem Composite-Interface-View eingebaut wird.
Composite-Interface-View ZPK_BASIC_VIEW_JOIN mit Assoziation:
Dieser Composite-Interface-View zeigt in der Datenvorschau folgende Ausgabe:
Data Preview Composite-Interface-View ZPK_BASIC_VIEW_JOIN mit Assoziation:
Nachdem nun alle benötigten Felder mittels Join- und Assoziations-Anweisung im Composite-Interface-View enthalten sind, kann mit der Erstellung des Consumption-Interface-Views begonnen werden.
Bei diesem View handelt es sich um den eigentlichen Stammdaten-Report, der dem Unternehmen für Auswertungen zur Verfügung steht.
Annotationen
Mittels Annotationen können Sie im virtuellen Datenmodell unterschiedlichste Einstellungen vornehmen. Beispielsweise können Felder standardmäßig als Zeilen oder Spalten im Aufriss deklariert sowie Feldbezeichnungen und Feldeigenschaften vergeben werden.
Feldbezeichnungen können über die Annotation @EndUserText.label: definiert werden während die Annotation @AnalyticsDetails.query.axis: steuert, ob Daten im Aufriss als Zeile oder Spalte verwendet werden.
Consumption View: ZPK_CONSUMPTION_VIEW
Dieser Basic-Interface-View zeigt in der Datenvorschau folgende Ausgabe:
Consumption View: ZPK_CONSUMPTION_VIEW in Analysis for Office (AfO):
Die Ausgabe des Consumption View zeigt, dass dem Feld Country neben dem Schlüssel „DE“ nun auch Texte „Germany“ zugeordnet werden. Diese Zuordnung erfolgte mittels Assoziation des Feldes Country und unter Anwendung von Annotationen um die zugehörigen Texte darzustellen.
Zusammenführung von Daten aus gleichartigen Datenbanktabellen
Im obigen Beispiel wurde ein Join und im weiteren Verlauf eine Assoziation verwendet, um die benötigten Daten für das Stammdaten-Reporting im Datenmodell zu kombinieren. Diese beiden Arten eignen sich besonders gut, wenn Daten aus Tabellen mit unterschiedlichen Strukturen bzw. unterschiedlichen Feldern kombiniert werden sollen.
Ein Union hingegen eignet sich besonders gut für die Kombination von Daten, die aus zwei Tabellen mit der gleichen Struktur bzw. den gleichen Feldern in einer Basic-Interface-View vereinigt werden.
Zusammenführung der Daten mittels Union
Anhand eines weiteren Beispiels wird die Funktionalität des Unions gezeigt. Es sollen zwei unterschiedliche Basic-Interface-Views zu einem gemeinsamen Basic-Interface View zusammengeführt werden.
Hierfür werden zwei Basic-Interface-Views verwendet, die auf die Datenbanktabelle ACDOCA zugreifen und dabei identische Felder auslesen. Sie unterscheiden sich in deren Filterung. Ein View liest Daten für das Geschäftsjahr 2021, der zweite View für das Geschäftsjahr 2022 aus.
Basic-Interface-View ZPK_SELECTION_1:
Dieser Basic-Interface-View zeigt in der Datenvorschau folgende Ausgabe:
Data Preview Basic-Interface-View ZPK_SELECTION_1:
Dieser Basic-Interface-View zeigt nun in einer Tabelle alle entsprechenden Daten aus dem Jahr 2021.
Basic-Interface-View ZPK_SELECTION_2:
Dieser Basic-Interface-View zeigt in der Datenvorschau folgende Ausgabe:
Data Preview Basic-Interface-View ZPK_SELECTION_2:
Dieser Basic-Interface-View zeigt nun in einer Tabelle alle entsprechenden Daten aus dem Jahr 2022.
Basic-Interface-View ZPK_UNION_EXAMPLE:
Dieser Basic-Interface-View zeigt in der Datenvorschau folgende Ausgabe:
Data Preview Basic-Interface-View ZPK_UNION_EXAMPLE:
Der zusammengeführte Basic-Interface-View zeigt nun in einer Tabelle alle entsprechenden Daten aus den Jahren 2021 und 2022.
Ihr Datenmanagement, Ihre Regeln
Mit dem virtuellen Datenmodell schaffen Sie die Grundlage für ein einfaches und transparentes Datenmanagement. Die Verwendung einer leicht verständlichen betriebswirtschaftlichen Semantik vereinfacht den Aufbau und die Weiterentwicklung des Virtuellen Datenmodells. Weiterhin wird Ihnen ein performanter Datenzugriff, eine hohe Wiederverwendbarkeit und eine einfache Wartung geboten.
Nutzen Sie die Flexibilität des virtuellen Datenmodell um genau die Daten bereitzustellen, die Sie für Ihr Reporting benötigen.
Webinare zu Embedded Analytics
Success Story: Finanzreporting mit Echtzeit-Berichterstattung direkt aus SAP S/4HANA bei Munich Re
Die Munich Re ist ein global führender Anbieter von Rückversicherung, Erstversicherung und versicherungsnahen Risikolösungen. Um den Abschlussprozess bei Finanz- und Buchhaltungsprozessen zu optimieren, wurde die Einführung eines Finanzreportings direkt aus SAP S/4HANA beschlossen.
Wie dies genau realisiert wurde und welche Vorteile sich für die Munich Re ergeben, erfahren Sie in der Success Story.
