In diesem Kapitel wird die Selektion einer Datenbank und Plattform für den Prototypen diskutiert. Im ersten Unterkapitel wird erläutert, warum sich die SAP HANA-Datenbank für die Implementierung des Prototyps eignet. Im zweiten Kapitel wird erläutert, warum sich Node.js für die Implementierung des Prototyps eignet.
SAP HANA
Im Rahmen der technischen Implementierung des Prototyps musste zunächst entschie-den werden, welche Datenbank und welche Anwendungsplattform genutzt werden sol-len. Im ersten Unterkapitel wird die SAP HANA-Datenbank vorgestellt und erläutert, warum sie sich für die Implementierung eignet. Im zweiten Unterkapitel wird diskutiert, welches Programmiermodell für den Prototyp genutzt werden soll.
SAP HANA-Datenbank
Bei der HANA-Datenbank handelt es sich um eine sogenannte In-Memory-Datenbank (Silvia et al. 2017, S. 19). Der Begriff In-Memory-Datenbank bedeutet, dass eine große Menge von Daten im Random-Access Memory (kurz: RAM) eines Computer gehalten werden können, womit eine hohe Performanz erreicht wird (Silvia et al. 2017, S. 20). Auf die Daten im Hauptspeicher (RAM) kann ca. 100.000-mal schneller zugegeriffen werden als auf die Daten einer Festplatte (Silvia et al. 2017, S. 23). Für die Haltung der Daten im Hauptspeicher gelten, wie bei herkömmlichen Datenbanken, die ACID-Regeln (Silvia et al. 2017, S. 24f). Um dem Aspekt der Dauerhaftigkeit (engl.: persistency) der ACID-Regeln Rechnung zu tragen, werden die auf der In-Memory-Datenbank ausgeführten Transaktionen auf einer Festplatte vermerkt (Silvia et al. 2017, S. 25). Diese Sicherung ist nötig, da es sich bei RAM um einen flüchtigen Speicher handelt, der verloren ginge, wenn beispielsweise ein Stromausfall stattfindet (Silvia et al. 2017, S. 25). Durch die Protokollierung der Transaktionen kann die In-Memory-Datenbank wiederhergestellt werden (Silvia et al. 2017, S. 25).
Das zweite zentrale Feature der HANA-Datenbank ist die Fähigkeit, die Datensätze in der Datenbank in Spalten statt in Zeilen zu organisieren (Silvia et al. 2017, S. 32). Im Folgenden wird erläutert, warum die Organisation in Spalten für Analysen besser geeignet ist. Die spaltenbasierte Speicherung unterscheidet sich von der zeilenbasierten Speicherung in der Art, wie die Datenbanktabellen gespeichert und gelesen werden (Silvia et al. 2017, S. 34).
Während bei der zeilenbasierten Speicherung bei Tabellenzugriff alle Daten gelesen werden müssen, ist es bei der spaltenbasierten Speicherung möglich, nur die für eine Abfrage relevanten Spalten zu lesen, wobei jede Spalte zudem als Schlüssel oder Index der Abfrage genutzt werden kann (Silvia et al. 2017, S. 35). Ist die Spalte des Kundennamens beispielsweise nicht Teil einer Abfrage, wird diese Spalte nicht gelesen, womit die Abfrage schneller wird (Silvia et al. 2017, S. 34f). Beim zeilenbasierten Zugriff müssen hingegen alle Daten gelesen werden (Silvia et al. 2017, S. 35). Allerdings ist die spaltenbasierte Speicherung bezüglich der Aktualisierung und dem Einfügen von Daten weniger effizient als die zeilenbasierte Methode (Silvia et al. 2017, S. 35). Dieser Nachteil kann allerdings dadurch umgangen werden, dass die Aktualisierung der Datenbank außerhalb der Geschäftszeiten abgewickelt wird, sodass innerhab der Geschäftszeiten nur die performanten Lesezugriffe genutzt werden, was in Kapitel 4.5.1 näher erläutert wird. Die Entwickler können sich im Rahmen von SAP HANA zwischen dem zeilenbasierten und spaltenbasierten Ansatz bei der Erstellung einer Datenbanktabelle entscheiden, wobei SAP HANA allerdings insbesondere für den spaltenbasierten Ansatz optimiert ist (Kühnlein und Seubert 2016, S. 28 bis 30).
Durch die hohe Performanz der HANA-Datenbank und die damit verbundene Möglichkeit von Echtzeitanalysen, bietet sie sich für das Ziel eines automatisierten Preismanagements im Lebensmitteleinzelhandel an. Ein weiteres Argument für Nutzung der HANA-Datenbank ist, dass die SAP-Einzelhandelslösung SAP Retail, die u. a. von EDEKA, REWE, Aldi-Nord und Aldi-Süd genutzt wird (SAP SE 2007; REWE Systems o. J.; ALDI-Nord 2015; ALDI-Süd 2019), auf der HANA-Datenbank läuft (Anderer 2016, S. 21). Die HANA-Datenbank hat folglich im Rahmen der IT-Lösungen des Lebensmitteleinzelhandels bereits eine zentrale Bedeutung und es kann davon ausgegangen werden, dass bei den Einzelhändlern bereits Experise in diesem Breich vorhanden ist. Aus den genannten Gründen wurde sich für die Nutzung von SAP HANA entschieden.
Anwendungsplattformen und Programmiermodelle der HANA
Im Folgenden wird diskutiert, welche Plattform und welches Programmiermodell im Kontext der HANA-Datenbank gewählt werden soll. SAP HANA ist nicht nur eine Datenbank, sondern bietet auch eine Anwendungsplattform an (Silvia et al. 2017, S. 107). Diese Anwendungsplattform, die als XS Engine oder SAP HANA XS Classic bezeichnet wird, umfasst einen Web-Server und einen leichtgewichtigen Anwendungs-server, mit denen leichtgewichtige Web-Anwendungen entwickelt werden können (Silvia et al. 2017, S. 107 und S. 172). Als Programmiersprachen werden HTML5 und das sogenannte XS JavaScript genutzt, das einige auf die XS Engine zugeschnittene Sprachelemente von serverseitigem JavaScript umfasst (Kühnlein und Seubert 2016, S. 37).
Entwickler können sich entscheiden, ob sie dieses Programmiermodell des integrierten Anwendungsservers der HANA nutzen, was auch als native Entwicklung bezeichnet wird, oder ob sie die HANA lediglich als Datenbank nutzen, auf die mit einem externen An-wendungsserver zugegriffen wird (Kühnlein und Seubert 2016, S. 40). Im letzteren Fall wird der größte Teil der Anwendungslogik auf dem externen Anwendungsserver abgewickelt und nur datenintensive Operationen an die HANA-Datenbank delegiert (Kühnlein und Seubert 2016, S. 41). Die beiden Programmiermodelle werden in der folgenden Abbildung dargestellt.
(Kühnlein und Seubert 2016, S. 40)
Die verschiedenen Arten von externen Anwendungsservern können mit bestimmten Protokollen bzw. Treibern auf die SQL-Funktionen der HANA zugreifen (Kühnlein und Seubert 2016, S. 41). Da im Rahmen der nativen Entwicklung für den Zugriff kein zusätzliches Protokoll benötigt wird, und somit die Anzahl von Architekturschichten minimiert wird, ist der Performanz des nativen Programmiermodells höher, was von hoher Relevanz für Echtzeitanwendungen sein kann (Kühnlein und Seubert 2016, S. 62). Dieser Aspekt spricht dafür, den nativen Ansatz für den Prototyp zu nutzen.
Im Rahmen des Masterprojekts von Mansel et al. (2018) wurde allerdings herausgefun-den, dass der in der HANA integrierte leichtgewichtige Anwendungsserver nicht für die Umsetzung eines Web-Scrapings genutzt werden kann. Das liegt zum einen daran, dass im Rahmen der für den HANA-Anwendungsserver verfügbaren Sprache XS JavaScript nur bestimmte Sprachelemente der Gesamtsprache JavaScript vorhanden sind und zum anderen daran, dass es nicht möglich ist, beliebige externe Bibliotheken zu importieren, die beispielsweise das Parsen von HTML-Dokumenten stark vereinfachen (Mansel et al. 2018, S. 33f). Aus diesem Grund muss der Prototyp mit einem externen Anwendungs-servers umgesetzt werden. Im folgenden Unterkapitel wird Node.js vorgestellt und er-läutert, warum es sich zur Implementierung des externen Anwendungsservers in dieser Arbeit eignet.
Recent Comments