Lade Inhalt...

Datenverarbeitung mit der SAP HANA In-Memory-Plattform der SAP

Überblick und technische Grundlagen

Projektarbeit 2017 49 Seiten

Informatik - Programmierung

Leseprobe

Gliederung

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

ABKÜRZUNGEN

1 EINFÜHRUNG
1.1 PROBLEMSTELLUNG
1.2 ZIELSETZUNG
1.3 VORGEHENSWEISE

2 GRUNDLAGEN
2.1 UNTERNEHMENSGESCHICHTE
2.2 GESCHICHTE DES SAP ERP-SYSTEMS

3 DATENBANKMODELLE
3.1 RELATIONALE DATENBANKEN
3.1.1 GESCHICHTE
3.1.2 BEGRIFFSDEFINITION
3.1.3 TECHNISCHES FUNKTIONSPRINZIP VON RELATIONALEN DATENBANKEN
3.1.4 GRENZEN VON RELATIONALEN DATENBANKEN
3.2 NOSQL-DATENBANKEN
3.2.1 GESCHICHTE
3.2.2 BEGRIFFSDEFINITION
3.2.3 TECHNISCHES FUNKTIONSPRINZIP VON NOSQL-DATENBANKEN
3.2.4 SPALTENORIENTIERTE DATENBANKEN
3.3 KONSISTENZMODELLE
3.3.1 GRUNDLAGEN DER KONSISTENZMODELLE
3.3.2 DAS CAP-THEOREM
3.3.3 STARKES KONSISTENZMODELL
3.3.4 SCHWACHES KONSISTENZMODELL
3.3.5 MULTI VERSION CONCURRENCY CONTROL
3.4 SAP HANA IST EINE NEWSQL

4 IN-MEMORY DATENBANK
4.1 WEGBEREITER FÜR IN-MEMORY-DATENBANKEN
4.1.1 ZUGRIFFSZEITEN
4.1.2 MULTI-CORE-ARCHITEKTUR
4.1.3 64-BIT-ARCHITEKTUR UND HAUPTSPEICHERKOSTEN
4.2 FUNKTIONSWEISE EINER IN-MEMORY-DATENBANK AM BEISPIEL SANSSOUCIDB
4.2.1 DATENORGANISATION UND -ZUGRIFF
4.2.2 AKTIVE UND NICHT AKTIVE DATEN
4.2.3 FEHLERTOLERANZ UND VERHALTEN IM FEHLERFALL
4.2.4 ARCHITEKTURSCHEMA SANSSOUCIDB

5 SAP HANA
5.1 EINFÜHRUNG IN DIE HANA DATENBANK
5.2 SAP HANA DATENBANKARCHITEKTUR
5.3 TECHNISCHE VORAUSSETZUNGEN FÜR SAP HANA

6 FAZIT

LITERATURVERZEICHNIS

GEDRUCKTE QUELLEN

INTERNETQUELLEN

Abbildungsverzeichnis

Abbildung 1: Zeitliche Entwicklung des SAP ERP-Systems

Abbildung 2: Zeitliche Entwicklung der SAP HANA Technologie

Abbildung 3: Ein Beispiel für eine relationalen Datenbank

Abbildung 4: Meilensteine in der Big-Data-Entwicklung

Abbildung 5: Das CAP-Theorem

Abbildung 6: ACID pessimistisches Konkurrenzverfahren mittels Sperren

Abbildung 7: MVCC optimistisches Konkurrenzverfahren mittels Versionen

Abbildung 8: Speicherkostenverlauf

Abbildung 9: Architekturschema der SanssouciDB

Abbildung 10: SAP HANA Datenbank Architektur

Tabellenverzeichnis

Tabelle 1: Datenorganisation in relationalen Datenbanken

Tabelle 2: Datenorganisation in spaltenorientierten Datenbanken

Tabelle 3: Aufrufzeiten

Abkürzungen

Abbildung in dieser Leseprobe nicht enthalten

1 Einführung

1.1 Problemstellung

Mit der Einführung von Personal Computer ist das digitale Datenaufkommen rasant ge- stiegen. Seien es Unternehmensdaten oder Daten, die ihren Ursprung im Internet haben. Daher stehen die Unternehmen vor der großen Herausforderung die eintreffenden großen Datenmengen effizient zu verarbeiten. Für die die Bewältigung dieser Herausforderung steht der Begriff Big Data. Die klassischen rationalen Datenbanken sind nicht mehr in der Lage eine so große Datenmenge in Echtzeit zu verarbeiten. Daher müssen andere Ansätze für eine Datenverarbeitung erforscht werden. Durch den Preisverfall für Arbeitsspeicher wurde es für die Unternehmen finanziell möglich die Server mit einer großen Arbeits- speichergröße auszustatten, so dass der Datenzugriff auf die Daten nicht mehr über Festplatten stattfinden muss, sondern direkt aus dem Arbeitsspeicher gelesen werden kann. Diese Art der Datenhaltung wird auch In-Memory genannt. Diesen Trend hat auch der weltweit führende Anbieter für Standardsoftware, die SAP, erkannt und eine In-Me- mory-Datenbank namens SAP HANA entwickelt. Da es eine relativ neue Technologie ist, ist es nicht jedem bekannt, wie sie funktioniert und welche technischen Grundlagen hinter dieser Technologie verborgen sind.

1.2 Zielsetzung

Das Ziel der vorliegenden Projektarbeit ist es, dem Leser einen Überblick über die SAP HANA-Datenbank sowie die In-Memory-Plattform als Ganzes und deren wesentliche Merkmale, Bestandteile und Funktionen zu verschaffen. Dabei soll auch einem Leser, der keinen Bezug zu Datenbanktechnologien hat, anschaulich gemacht werden, wie eine SAP HANA-Datenbank funktioniert, welchem Datenbankmodell es zugrunde liegt und welche Voraussetzungen das System erfüllen muss, damit die SAP HANA-Datenbank in Betrieb genommen werden kann.

1.3 Vorgehensweise

Um den Überblick über SAP HANA In-Memory-Plattform besser darzustellen, ist der Aufbau dieser Projektarbeit in zwei große Teilbereiche aufgeteilt. Zum Verständnis dar- über, auf welchen allgemeinen Datenbankmodellen die In-Memory-Technologie und die SAP HANA-Datenbank aufbaut, wird in den ersten Kapiteln der Fokus auf allgemeine Datenbanktechnologien gelegt. Hier werden zum einen die technologischen Grundsätze, aber auch die Geschichte der SAP, das Wie und Warum dargelegt. Der zweite Teil der Arbeit beschreibt die In-Memory-Technologie, die technologischen Wegbereiter für diese sowie den Aufbau einer In-Memory-Datenbank. Im letzten Teil der Arbeit wird die SAP HANA-Datenbank, die auf der In-Memory-Technologie aufsetzt, die Architektur der Datenbank sowie die Voraussetzungen, die zur Implementierung der SAP HANADatenbank erfüllt sein müssen, beschrieben.

2 Grundlagen

Dieses Kapitel befasst sich mit der Geschichte von SAP als Unternehmen sowie mit dem Produkt SAP ERP-System und deren Entstehung und Evolution über die Jahre. Die Geschichte gibt einen Überblick wie SAP ERP-Systeme sich konzeptionell verändert haben und welche technischen Neuheiten über die Zeit hinzugekommen sind.

2.1 Unternehmensgeschichte

Im Jahr 1972 haben die fünf ehemaligen IBM Mitarbeiter Hasso Plattner, Dietmar Hopp, Klaus Tschira, Hans-Werner Hector und Claus Wellenreuther ein Software-Unternehmen namens ‚Systemanalyse und Programmentwicklung‘ in Weinheim gegründet. Ihr erster Auftrag war für eine deutsche Niederlassung von Imperial Chemical Industries (ICI) in Östringen. Sie entwickelten eine Software, die nicht wie für die damalige Zeit üblich, mit Hilfe von Lochkarten umgesetzt wurde, sondern auf eine neue revolutionäre Weise, in- dem die Daten über die Tastatur eingegeben und auf den Bildschirmen ausgegeben wurden. Die Software wurde für den Bereich Lohnabrechnung und Buchhaltung ge- schrieben und lief auf den IBM Großrechnern. Im Gründungsjahr des Unternehmens wurde das Personal bis auf 9 Mitarbeiter aufstockt und es wurde ein Umsatz von 640.000 Deutsche Mark (DM) erwirtschaftet.1

1976 wurde die Firma in ‚Systeme, Anwendungen, Produkte in der Datenverarbeitung GmbH‘ (kurz SAP) umbenannt. Ein Jahr später wurde der Firmensitz nach Walldorf ver- legt. Seitdem ist Walldorf der Hauptsitz für die zukünftige SAP AG.2 Durch eine hohe Anzahl von eintreffenden Aufträgen war das Unternehmen gezwungen mehr Mitarbeiter einzustellen. Außerdem wurden einige eigene Firmengebäude gebaut. Die SAP hat zu- dem eigene Rechenzentren aufgebaut, damit die Software auch im Haus, und nicht beim Kunden entwickelt werden musste. Durch das starke Wachstum entschloss sich das Un- ternehmen ins Ausland zu expandieren. Dafür wurden Büros in der Schweiz eröffnet. Im Jahr 1988 ist die SAP an die Börse gegangen.3

Durch die Etablierung von Personal Computer (PC) Anfang der 90er Jahren wurde die Nachfrage nach Großrechnern geschwächt. Neue Konzepte, wie zum Beispiel die ClienServer-Architektur, wurden notwendig. Die SAP hat diesen Trend schnell erkannt und im Jahr 1992 die ersten Module der neuen SAP R/3 vorgestellt. Das Unternehmen feierte einen Erfolg nach dem Anderen. Viele große und namhafte Unternehmen setzten SAP als Standardsoftware ein. Um den Wachstum beizubehalten übernahm das SAP in folgenden Jahr mehrere Unternehmen, um sein Portfolio zu erweitern.4

Im Laufe der Jahre wurde der Vorstand des Unternehmens immer wieder ausgetauscht. Der letzte Unternehmensgründer Hasso Plattner zog sich im Jahr 2003 aus dem operati- ven Geschäft zurück und nahm einen Platz im Aufsichtsrat ein. Jahre später folgten neue Akquisen, um die Unternehmenskompetenzen zu erweitern. Vor allem durch den Erwerb des französischen Unternehmens Business Objects konnte die SAP das Portfolio im Be- reich Data Warehouse und Business Intelligence erweitern und entwickelte sich so zu einem der führenden Anbieter im Bereich Unternehmenssoftware, Enterprise Perfor- mance Management und Business Intelligence. Im Jahr 2009 durchlebte das Unternehmen aufgrund der Wirtschaftskrise schwere Zeiten. Um das Unternehmen wei- ter gesund und profitabel zu halten, musste die Unternehmensleitung eine Sanierung der Organisation durchführen. Ein Teil dieses Sanierungskonzepts sah Entlassungen von einigen Mitarbeitern vor.5

Nach der Wirtschaftskrise wuchs das Geschäft wieder. SAP brachte neue Technologien auf den Markt, wie z.B. SAP HANA, In-Memory-Technologie und Cloud-Lösungen. Das Unternehmen wurde 2014 in eine europäische Aktiengesellschaft umformiert und trägt seitdem die Bezeichnung SAP SE. Mittlerweile beschäftigt SAP SE über 80.000 Mitarbeiter und macht mehr als 20 Milliarden Euro Jahresumsatz.6

2.2 Geschichte des SAP ERP-Systems

Die Geschichte und die zeitliche Reihenfolge der Entwicklung des SAP ERP-Systems lässt sich am besten anhand einer Zeitlinie visuell darstellen. Wie aus der folgenden Ab- bildung ersichtlich ist, kam die erste Version von SAP ERP im Jahr 1972. Damals bestand das ERP-System aus einem Lohnabrechnungs- und Buchhaltungsmodul. Der Buchstabe R steht für ‚Realtime‘.7 Die Zweite Generation der SAP ERP-Systeme trug die Bezeich- nung SAP R/2 und lief nicht nur auf teuren IBM Großrechnern, sondern auch auf kompatiblen Siemens Großrechnern. Die Auslöser waren die geänderten Datenbank- und Dialogsteuerungssysteme der IBM.8

Abbildung 1: Zeitliche Entwicklung des SAP ERP-Systems

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Durch die starke Verbreitung von Personal Computern entwickelte das Unternehmen ein neues ERP-System, das auf einer Client-Server-Architektur aufsetzte. Das war zum damaligen Zeitpunkt revolutionär. Mit Beginn des Internet-Booms musste das Unternehmen sich neu ausrichten und entwickelte eine Unternehmenslösung für den E-Commerce Bereich. Sie wurde mySAP genannt. MySAP verbindet E-Commerce-Systeme mit bestehenden ERP-Systemen mithilfe von Webtechnologie.9

Damit die SAP R/3 mit anderen Softwareprodukten kommunizieren konnte, stellte das Unternehmen im Jahr 2004 die Integrationsplattform namens Netweaver zur Verfügung. In Zukunft setzt SAP auf Serviceorientierte Architektur (SOA), um mit anderen Anwen- dung zu interagieren. Der Name des ERP-Systems wurde in SAP ERP umbenannt.10

Abbildung 2: Zeitliche Entwicklung der SAP HANA Technologie

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Seit 2011 bietet SAP eine neue Datenbanklösung namens SAP HANA an. Diese Daten- bank hält die Daten im Arbeitsspeicher und speichert die Daten in Spalten und in Zeilen. Die Einführung der SAP HANA Datenbank erfolgte dabei in zwei Stufen. Zuerst wurde die SAP HANA-Datenbank nur als Sekundär-Datenbank betrieben. Das ERP-System lief wie bisher, nur die Finanzdaten wurden gespiegelt und in spaltenorientierte Datenstruktur gespeichert. So konnten die Abfragen von größeren Datenmengen und die Analysen der Daten schneller durchgeführt werden. Beim Ausfall der SAP HANA-Datenbank wurde die Datenverarbeitung wieder in der primären Datenbank durchgeführt.11

Die Zweite Stufe erfolgte im Jahr 2012. Die SAP HANA wurde als Primärdatenbank freigegeben. Das neue Gesamtprodukt heißt SAP Business Suite. Mit der Einführung die- ses Produktes waren alle Anwendungen mit der SAP HANA-Datenbank möglich.12 Mit der Zeit integriert die SAP weitere Inhouse-Produkte auf SAP HANA. Eines davon ist das Data Warehouse bzw. die interne Bezeichnung SAP BW. Seit 2015 wird die kom- plette ERP und Data Warehouse Lösung als SAP S/4 HANA bezeichnet.13

3 Datenbankmodelle

Diese Kapitel vergleicht relationale und NoSQL-Datenbanken. Sie erklärt, wie die Datenbankmodelle definiert sind, wie sie funktionieren und was ihre Merkmale sind. Zum Schluss wird versucht die SAP HANA-Datenbank einem konkreten Datenbankmodell, anhand ihrer wesentlichen Eigenschaften, zuzuordnen.

3.1 Relationale Datenbanken

3.1.1 Geschichte

Das relationale Datenmodell wurde von Ted Codd im Jahre 1970 bei IBM Research ent- wickelt. Das Konzept basierte auf mathematischen Relationen in der Mengentheorie. Dieses Relationsmodell war sehr einfach, wofür das Modell mehr Aufmerksamkeit und Popularität bekommen hat. Als Grundlage wurden hierarchische und Netzwerkmodelle genommen, welche in den 60-er Jahren zum ersten Mal veröffentlicht wurden.14

Relationale Datenbanken benutzen eine Abfragesprache für verschiedene Operationen. So zum Beispiel Datenbank anlegen, Tabellen erstellen, Daten in die Tabelle schreiben, ändern und löschen usw. Hier hat sich ein Standard namens Sequel Structured Language (SQL) durchgesetzt. SQL ist in relationalen Datenbankmanagementsystemen (RDBMS)

weitverbreitet und standardisiert.15 Einige RDBMS-Anbieter weichen von diesem Stan- dard ab und entwickeln ihre eigenen SQL-Dialekte. So z. B. wurde für Microsoft SQL Server Transact SQL definiert, welcher nicht unbedingt in anderen RDBMS kompatibel ist. Die meisten RDBMS-Anbieter haben erst nach SQL-92 Standard ihre Abweichungen eingebaut.16

3.1.2 Begriffsdefinition

Für den Begriff relationale Datenbanken existiert keine einheitliche und standardisierte Definition. In verschiedenen Quellen verwenden Autoren unterschiedliche Definitionen. So definieren z. B. Günter Matthiessen und Michael Unterstein eine relationale Daten- bank als Äeine Menge von Relationen [..], die jeweils durch das entsprechende Relationenschema bestimmt sind und welche die jeweiligen Integritätsregeln erfüllen“17. Edwin Schicker interpretiert eine Datenbank aus Benutzersicht als Äeine Datenbank, die der Benutzer ausschließlich als eine Ansammlung von zeitlich variierenden, normalisier- ten Relationen passender Grade erkennt“18. Durch die Kombinationen dieser Definitionen und der Beschreibungen von relationalen Datenbanken dieser Autoren, entsteht folgende Definition: Eine relationale Datenbank ist eine Sammlung von Tabellen, die auf einem Entity-Relationship-Modell basiert und dem Atomic, Consistency, Isolation, Durability (ACID)-Modell entspricht, wobei die Tabellen über einen Primär- und Sekundärschlüssel verknüpft werden und Daten nach Codd Regeln gespeichert werden.19

3.1.3 Technisches Funktionsprinzip von relationalen Datenbanken

Die Daten in einer relationalen Datenbank werden nach einem Entity-Relationship-Mo- dell in den Tabellen gespeichert. Das Schema einer Tabelle ist durch den Tabellennamen und die Anzahl von Attributen mit entsprechenden Datentypen definiert. Die Daten liegen in zeilenorientierten Format vor. Die Übersicht über die gespeicherten Daten bekommt man aus den Tabellen direkt bzw. bei komplexen Strukturen werden mehrere Tabellen kombiniert. Das hier zugrundeliegende Modell ist die relationale Algebra. Sie beschäftigt sich mit der Menge der Relationen in einem System. E. F. Codd hat in den 70-er Jahren einige Regeln für relationale Datenbanken festgelegt. Diese Regeln sind in der relationalen Welt als Normalisierung bekannt. Es existieren fünf Normalformen, nach der die Daten in den Tabellen strukturiert werden, damit eine möglichst redundanzfreie Datenspeicherung erfolgt. Am häufigsten werden nur die ersten drei benutzt.20

1 Normalform: Die erste Normalform Äbesagt, dass die Domäne eines Attributs nur ato- mare (einfache, unteilbare) Werte beinhalten darf und dass der Wert eines Attributs in einem Tupel ein Einzelwert aus der Domäne dieses Attributs sein muss“21.
2 Normalform: Eine Relation ist dann in zweiter Normalform, wenn sie die Bedingun- gen der ersten Normalform erfüllt und die Nichtschlüsselattribute von einem Teil des Primärschlüssels (bestehend aus mehreren Attributen) nicht funktional abhängig sind.22
3 Normalform: Eine Relation ist dann in dritter Normalform, wenn sie die Bedingungen der zweiten Normalform erfüllt und die Nichtschlüsselattribute nicht transitiv abhän- gig vom Primärschlüssel sind. D.h. Nichtschlüsselattribute dürfen nicht untereinander funktional abhängig sein.23

Ein Beispiel für eine relationale Datenbank, die in der dritten Normalform vorliegt, wird in der Abbildung 3 dargestellt. Die Daten sind in atomarer Form und werden nicht redun- dant abgespeichert. Die Beziehungen zwischen den Tabellen erfolgt über Primär- und Sekundärschlüssel.

Abbildung 3: Ein Beispiel für eine relationale Datenbank

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung

3.1.4 Grenzen von relationalen Datenbanken

Die relationalen Datenbanken haben sich im Laufe der Jahre auf dem Markt etabliert. Sie wurden standardisiert und haben eine weite Verbreitung in der Welt der Softwareentwicklung erlangt. Durch die weite Verbreitung und das mathematische Fundament sind die RDBMS leicht zu verstehen, bedienen, administrieren, erweitern und implementieren. Entwicklungen von RDBMS über viele Jahre haben Standards und Stabilität ins System gebracht. Es wurden zahlreiche Kommunikationsschnittstellen entwickelt und speziell für die Eigenschaften der RDMBS optimiert.24

Mit dem Internet-Boom stieg die Menge an Daten rasant an und die Anforderungen an das Datenbanksystem haben sich geändert. Das maximal zu verarbeitende Datenvolumen von herkömmlichen RDBMS war begrenzt und mit steigendem Datenvolumen hatten die RDBMS Leistungsverluste. Die RDBMS wurden ursprünglich für stand alone Server konzipiert, was bedeutet, dass nur eine vertikale Skalierung möglich ist. Zwar wurde die Leistung durch stärkere Hardware kompensiert, wobei auch Hardware an Grenzen stößt.

Auch mit steigender Komplexität des Datenaufbaus und von Tabellenbeziehungen wer- den die tabellenübergreifenden Abfragen mittels JOIN komplizierter und langsamer.25

Durch starre Tabellenstrukturen sind relationale Datenbanken nicht flexibel und können an ständig wachsende Anforderungen nicht agil angepasst werden. Dazu muss die Datenbank aus der Produktivumgebung getrennt werden, um Änderungen an den Tabellen vorzunehmen, z. B. um eine neue Spalte mittels ALTER TABLE einzufügen. Für ein Unternehmen bedeutet es den Ausfall des Systems, soweit keine Replikationsdatenbank vorhanden ist. Aber auch die Umstellung auf die Replikationsserver bedeutet einen kurzen Ausfall. Nichts desto trotz muss die Datenbankarchitektur vor dem produktiven Einsatz sorgfältig geplant und getestet werden.26

Die Replikationen in RDMBS sind kompliziert und umständlich. Verantwortlich dafür ist das starke Konsistenzmodell. Die Daten werden für den Replikationszeitraum gesperrt, um die Gefahr der Datenmanipulation auszuschließen. Hierzu kommt es zu Leistungsein- schränkungen der Operation auf die produktive Instanz. Ein starkes Konsistenzmodell bewirkt, dass die Datenbanken stets konsistent sein müssen. Darauf wird später in Kapitel 2.4.2 ausführlicher eingegangen.27

3.2 NoSQL-Datenbanken

3.2.1 Geschichte

Die erste NoSQL-Datenbank wurde 1979 von Ken Thompson entwickelt. Er nannte es DBM und sie arbeitete nach dem Key-Hash Prinzip. Später in den 80-er Jahren kamen noch bis heute bekannte Systeme wie Lotus Notes und BerkeleyDB auf Basis von NoSQL hinzu. Im Vergleich zu heute haben diese Datenbanksysteme mit geringen Datenbank- mengen zu kämpfen. Zum ersten Mal wurde der Begriff NoSQL im Jahr 1998 von Carlo Strozzi erwähnt. Er entwickelte eine Datenbank, die immer noch auf der Basis einer re- lationalen Datenbank aufbaute, aber kein SQL-API zur Verfügung gestellt hat.28

Mit dem Anbruch des Web 2.0 Zeitalters in den 2000-er Jahren war der Bedarf an der Verwendung von skalierbaren und hochverfügbaren Datenbanksystemen höher. Google zählt zu den Pionieren in der Entwicklung von NoSQL-Datenbanken. Googles erstes NoSQL-Datenbanksystem Namens 'BigTable' erschien im Jahr 2006.29 Ein Jahr später veröffentlichte auch Amazon sein erstes NoSQL-Datenbanksystem 'Dynamo' in einem seiner Paper.30 Später haben auch andere Internet-Unternehmen wie Yahoo sowie soziale Netzwerke wie Facebook und MySpace nachgezogen.31

Alle diese Datenbanken waren bis dahin noch nicht klassifiziert. Erst im Mai 2009 wurde der Begriff NoSQL auf einem Treffen in San Francisco von Johan Oskarsson genannt. Sein Vortrag beschäftigte sich mit dem Thema 'verteilte Datenspeicherung'. Seitdem wer- den nichtrelationale Datenbanksysteme als NoSQL-Datenbanksysteme bezeichnet.32

Jonas Freiknecht präsentiert in seinem Buch 'Big Data in der Praxis. Lösungen mit Hadoop, HBase und Hive. Daten speichern, aufbereiten, visualisieren' eine Zeitgrafik der Big-Data-Entwicklung. Dort sind die seiner Ansicht nach wichtigsten Meilensteine abgebildet (siehe Abbildung 4).33

Abbildung 4: Meilensteine in der Big-Data-Entwicklung

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Freiknecht, J., Big Data in der Praxis, 2014, S. XII.

[...]


1 Vgl. SAP, Der Anfang von SAP, o. J., o. S.

2 Vgl. SAP, Der Anfang von SAP, o. J., o. S.

3 Vgl. SAP, SAP R/2, o. J., o. S.

4 Vgl. SAP, SAP R/3, o. J., o. S.

5 Vgl. SAP, SAP und Echtzeitdaten, o. J. o. S.

6 Vgl. SAP, SAP und In-Memory-Technologie, o. J., o. S.

7 Vgl. SAP, Der Anfang von SAP, o. J., o. S.

8 Vgl. SAP, SAP R/2, o. J., o. S.

9 Vgl. SAP, SAP R/3, o. J., o. S.

10 Vgl. SAP, SAP und Echtzeitdaten, o. J. o. S.

11 Vgl. Salmon, J. et al., SAP S/4HANA, 2016, S. 30.

12 Vgl. Salmon, J. et al., SAP S/4HANA, 2016, S. 34.

13 Vgl. SAP, SAP und In-Memory-Technologie, o. J., o. S.

14 Vgl. Elmasri, R., Navathe, S. B., Datenbanksysteme, 2005, S. 133ff.

15 Vgl. Ernst, H., Schmidt, J., Beneken, G., Grundkurs Informatik, 2015, S. 340.

16 Vgl. Ernst, H., Schmidt, J., Beneken, G., Grundkurs Informatik, 2015, S. 347ff.

17 Matthiessen, G., Unterstein, M., Relationale Datenbanken, 2008, S. 40.

18 Schicker, E., Datenbanken und SQL, 2014, S. 27.

19 Vgl. Matthiessen, G., Unterstein, M., Relationale Datenbanken, 2008, S. 40, Schicker, E., Datenbanken und SQL, 2014, S. 27.

20 Vgl. Ernst, H., Schmidt, J., Beneken, G., Grundkurs Informatik, 2015, S. 340, Elmasri, R., Navathe, S. B., Datenbanksysteme, 2005, S. 134.

21 Elmasri, R., Navathe, S. B., Datenbanksysteme, 2005, S. 319.

22 Vgl. Elmasri, R., Navathe, S. B., Datenbanksysteme, 2005, S. 323.

23 Vgl. Elmasri, R., Navathe, S. B., Datenbanksysteme, 2005, S. 324ff.

24 Vgl. Schicker, E., Datenbanken und SQL, 2014, S. 27.

25 Vgl. Datenbanken Online Lexikon der FH Köln, RDBMS, 2012, o. S.

26 Vgl. ebd.

27 Vgl. ebd.

28 Vgl. Edlich, S. et al., NoSQL, 2011, S. 1.

29 Vgl. Freiknecht, J., Big Data in der Praxis, 2014, S. 189.

30 Vgl. Freiknecht, J., Big Data in der Praxis, 2014, S. XII.

31 Vgl. Edlich, S. et al., NoSQL, 2011, S. 1.

32 Vgl. Edlich, S. et al., NoSQL, 2011, S. 1; Freiknecht, J., Big Data in der Praxis, 2014, S. 190.

33 Vgl. Freiknecht, J., Big Data in der Praxis, 2014, S. XII.

Details

Seiten
49
Jahr
2017
ISBN (eBook)
9783668878556
ISBN (Buch)
9783668878563
Sprache
Deutsch
Katalognummer
v448968
Institution / Hochschule
FOM Hochschule für Oekonomie & Management gemeinnützige GmbH, Stuttgart
Note
1,7
Schlagworte
DATENBANKMODELLE RELATIONALE DATENBANKEN NOSQL-DATENBANKEN DAS CAP-THEOREM MULTI VERSION CONCURRENCY CONTROL NEWSQL IN-MEMORY DATENBANK ZUGRIFFSZEITEN MULTI-CORE-ARCHITEKTUR FUNKTIONSWEISE EINER IN-MEMORY-DATENBANK DATENORGANISATION UND -ZUGRIFF AKTIVE UND NICHT AKTIVE DATEN FEHLERTOLERANZ UND VERHALTEN IM FEHLERFALL SAP HANA SAP HANA DATENBANKARCHITEKTUR TECHNISCHE VORAUSSETZUNGEN FÜR SAP HANA

Autor

Zurück

Titel: Datenverarbeitung mit der SAP HANA In-Memory-Plattform der SAP