Eigenschaften von Unternehmensanwendungen - Dr. Matthias Uflacker, Stefan Halfpap, Dr. Werner Sinzig 17. April 2019 - Hasso-Plattner-Institut
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Eigenschaften von Unternehmensanwendungen
Dr. Matthias Uflacker, Stefan Halfpap, Dr. Werner Sinzig
17. April 2019
Vorlesungsinhalte/-aufbau
■ Einführung zu Unternehmensanwendungen (2 Vorlesungen)
■ Einführung zu relationalen Datenbanken und Anfrageverarbeitung (2 Vorlesungen)
■ Grundlagen des IT-gestützten Rechnungswesens und der Planung (3 Vorlesungen)
■ Grundlagen von (spaltenorientierten) Hauptspeicherdatenbanken (5 Vorlesungen)
■ Trends in Hauptspeicherdatenbanken (4 Vorlesungen)
■ Klausur
2Überblick
■ Unternehmensanwendungen
■ Beispiele für Unternehmensanwendungen
■ Datenbankanfrageeigenschaften von Unternehmensanwendungen
□ OLTP vs. OLAP
□ Trennung in eigenständige Systeme
□ Optimierung eines Systems für beide Anfragearten
■ Eigenschaften von Unternehmensdaten
■ Zusammenfassung
■ Übungsblatt 1
3Unternehmensanwendungen
■ „Enterprise applications are about the display, manipulation, and storage of large
amounts of often complex data and the support or automation of business
processes with that data.“ Martin Fowler „Patterns of Enterprise Application Architecture Patterns“ (2002)
□ Große komplexe Datenmengen, die in der realen Welt existierende Entitäten abbilden
□ Unterstützung/Automatisierung von Geschäftsprozessen auf Basis dieser Daten
□ Nutzen üblicherweise (relationale) Datenbanken
4Beispiele für Unternehmensanwendungen
■ Klassische Domäne
□ ERP, SCM, CRM (siehe 01_Unternehmensanwendungen)
■ Erweiterte Domäne
Neue Technologien haben Einfluss auf Unternehmensanwendungen.
Informationsintegration aus unterschiedlichen Quellen bietet neue Möglichkeiten zur
Anreicherung und dadurch Optimierung der klassischen Unternehmensprozesse.
□ Sensordaten in Produktionsüberwachung
□ Unstrukturierte Daten wie medizinische Behandlungsberichte und Röntgenbilder
□ Posts im Web und auf sozialen Netzwerken zum Einfluss von Produkten
5Beispiele für Unternehmensanwendungen
Klassische Domäne: Abwicklung eines Kaufauftrags
Basierend auf Frank Körsgen „SAP R/3 Arbeitsbuch“ (2005)
■ Prozesse im Vertrieb werden durch Vertriebs-/Verkaufsbelege abgebildet
□ Kundenanfrage
□ Angebot
□ Auftrag
□ Lieferung
□ Warenausgang + Buchhaltungsbeleg
□ Ausgangsrechnung + Buchhaltungsbeleg
□ Bezahlung + Buchhaltungsbeleg
■ (Details in der Vorlesung zum Rechnungswesen)
6Beispiele für Unternehmensanwendungen
Klassische Domäne: Abwicklung eines Kaufauftrags
■ Vorkommende teils aufwändige Prozesse
□ Preisfindung
□ Verfügbarkeitsprüfung
□ Bedarfsübergabe (an Einkauf und/oder Fertigung)
□ Versandterminierung
□ Versandstellen- und Routenermittlung
□ Kreditlimitprüfung
7Beispiele für Unternehmensanwendungen
Klassische Domäne: Abwicklung eines Kaufauftrags
■ Verfügbarkeitsprüfung
Zugänge zum Wunschliefertermin Abgänge zum Wunschliefertermin
Lieferungen
Fertigungsaufträge
Bestellungen Aufträge
Bestand verfügbare Menge
Basiered auf Frank Körsgen „SAP R/3 Arbeitsbuch“ (2005) 8Unternehmensanwendungen
Datenbankanfrageeigenschaften
Clark D. French „’One Size Fits All’ Database Architectures Do Not Work for DDS“ (1995)
■ Online Transaction Processing (OLTP) ■ Online Analytical Processing (OLAP)
□ Beispiele: Auftrag anlegen/suchen, □ Beispiele: Mahnlauf,
Rechnung erstellen, Kontenbuchung, Verfügbarkeitsprüfung, Cross-Selling,
Anlegen und Anzeigen von Stammdaten Operationales Reporting (Auflistung
offenen Rechnungen)
□ Einfache Anfragen □ Komplexe Anfragen
□ Oft festgelegte Anfragen □ Ad-hoc-Anfragen
à Index-Unterstützung □ „Decision Support“
□ Geringe Datengrundlage □ Große Datengrundlage
(stark-selektive Anfragen) (schwach-selektive Anfragen)
□ Daten(tupel)eingabe und –abruf □ Analyseanfragen (Aggregation und
Gruppierung weniger Attribute) 9Unternehmensanwendungen
Historischer Hintergrund
Michael Stonebraker „One Size Fits All: An Idea Whose Time Has Come and Gone“ (2005)
■ Relationale DBMSs entstanden in den 1970er Jahren als Forschungs-Prototypen
□ System R
Genealogy der relationalen Datenbanken
□ INGRES https://hpi.de/fileadmin/user_upload/fachgebiete/naumann/projekte/RDBMSGenealogy/RDBMS_Genealogy_V6.pdf
■ Beide Systeme wurden für die Verarbeitung von Unternehmensdaten (OLTP) geschaffen
■ Seit Anfang der 1980er: „one size fits all“ Strategie
Gründe: Kosten, Kompatibilität, Verkauf, Marketing
■ In der 1990er Jahren: Unternehmen wollen Daten aus verschiedenen operationalen DBs in
ein Data-Warehouse für Business Intelligence vereinen
“Although most warehouse projects were dramatically over budget and ended up delivering only a subset
of promised functionality, they still delivered a reasonable return on investment. In fact, it is widely
acknowledged that historical warehouses of retail transactions pay for themselves within a year […].”
10Unternehmensanwendungen
Typische Systemlandschaft
11Unternehmensanwendungen
Data-Warehouse und OLAP Technologien
S. Chaudhuri et U. Dayal „An Overview of Data Warehousing and OLAP Technology “ (1997)
■ Gründe für Entstehung: Performanz und Datenintegration
□ Relationale Datenbanken waren historisch für OLTP optimiert: Angst vor
Performanzeinbruch für Transaktionen durch komplexe Ad-hoc-Anfragen
□ Ältere Daten für historische Tendenzen + zusätzliche Informationen z.B. Aktienpreise
■ Aufbau eines Data-Warehouses für Unternehmen ist langwieriger und komplexer Prozess
■ Erfordert umfangreiche Geschäftsprozessmodellierung
(Abdeckung des gesamten Unternehmens)
■ Data-Marts: integrieren Datenuntermenge, die sich auf einen einzelnen Organisationsbereich
fokussieren z.B. Marketing Data-Mart
12ed for OLTP. It is for all these Section 8 with a brief mention of these issues.
ses Unternehmensanwendungen
are implemented separately
Data-Warehouse Architektur
2. Architecture and End-to-End Process
S. Chaudhuri et U. Dayal „An Overview of Data Warehousing and OLAP Technology “ (1997)
Figure 1 shows a typical data warehousing architecture.
e implemented on standard or
Ss, called Relational OLAP
■ Datenintegration Monitoring & Admnistration
rvers assume that data is stored in
ey support extensions to SQL and Metadata
Repository
mentation methods to efficiently
■ Datenmodellierung OLAP
Servers Analysis
ional data model and operations. Data Warehouse
nal OLAP (MOLAP) servers are External Extract
■ Operationen sources Transform Query/Reporting
multidimensional data in special Load
Operational Refresh Serve
ys) and implement the OLAP dbs Data Mining
l data■ structures.
Datenspeicherung
nd maintaining a data warehouse Data sources
Hilfsstrukturen
rver ■and defining a schema and Data Marts Tools
for the warehouse. Different Figure 1. Data Warehousing Architecture
13
xist. Many organizations want touse inconsistent representations, codes and formats, which is the Data Warehousing Information Center4.
have to be reconciled. Finally, supporting the
Unternehmensanwendungen
multidimensional data models and operations typical of Research in data warehousing is fairly recent, and has focused
Data-Warehouse: Datenintegration
OLAP requires special data organization, access methods,
and implementation methods, not generally provided by
primarily on query processing and view maintenance issues.
There still are many open research problems. We conclude in
S. Chaudhuri et U. Dayal „An Overview of Data Warehousing and OLAP Technology “ (1997)
commercial DBMSs targeted for OLTP. It is for all these Section 8 with a brief mention of these issues.
Aufwendiger
■reasons ETL-Prozess
that data warehouses are implemented separately
from operational databases. 2. Architecture and End-to-End Process
□ Extraktion der relevanten Daten aus operationalen DBs und externen Quellen
Figure 1 shows a typical data warehousing architecture.
Data warehouses might be implemented on
□ Transformation der Daten in das Warehouse-Schema standard or
extended relational DBMSs, called Relational OLAP Monitoring & Admnistration
□ Laden der Daten in das Warehouse
(ROLAP) servers. These servers assume that data is stored in
relational databases, and they support extensions to SQL and Metadata
Repository
special access and implementation methods to efficiently OLAP
Servers Analysis
implement the multidimensional data model and operations. Data Warehouse
In contrast, multidimensional OLAP (MOLAP) servers are External Extract
sources Transform
Metadatenmanagement
■servers that directly store multidimensional data in special Load
Query/Reporting
Operational Refresh Serve
data structures (e.g., arrays) and implement the OLAP
□ Beschreibung
operations der data
over these special Datenquellen
structures.
dbs Data Mining
□ Beschreibung des Warehouse-Schemas
There is more to building and maintaining a data warehouse Data sources
than (siehe
selectingFolgefolien)
an OLAP server and defining a schema and Data Marts Tools
some complex queries
□ Beschreibung derfor the warehouse. Different
Datenextraktions- Figure 1. Data Warehousing Architecture
und Datentransformationsregeln
architectural alternatives exist. Many organizations want to
14
implement an integrated enterprise warehouse that collects It includes tools for extracting data from multiple operational
information about all subjects (e.g., customers, products, databases and external sources; for cleaning, transforminguse inconsistent representations, codes and formats, which is the Data Warehousing Information Center .
have to be reconciled. Finally, supporting the
Unternehmensanwendungen
multidimensional data models and operations typical of Research in data warehousing is fairly recent, and has focused
OLAP requires special data organization, access methods, primarily on query processing and view maintenance issues.
Data-Warehouse: Datenmodellierung
and implementation methods, not generally provided by
commercial DBMSs targeted for OLTP. It is for all these
There still are many open research problems. We conclude in
Section 8 with a brief mention of these issues.
S. Chaudhuri
reasonsetthat
U. Dayal „An Overview
data warehouses of Data Warehousing
are implemented separately and OLAP Technology “ (1997)
from operational databases. 2. Architecture and End-to-End Process
■ OLTP Schema-Design basiert auf Normalisierung (redundanzfreie Speicherung)
Figure 1 shows a typical data warehousing architecture.
■ Für OLAP sindData warehouses might be implemented on standard or
effiziente Anfragen und effizientes Laden wichtig
extended relational DBMSs, called Relational OLAP Monitoring & Admnistration
(ROLAP) servers. These servers assume that data is stored in
relational databases, and they support extensions to SQL and Metadata
Repository
■ Mehrdimensionale
special Datensicht
access and implementation methods to efficiently OLAP
Servers Analysis
implement the multidimensional data model and operations.
Stadt
Data Warehouse
Datenwürfel (OLAP-Würfel)
In contrast, multidimensional OLAP (MOLAP) servers are External Extract
Transform
sources Query/Reporting
servers that directly store multidimensional data in special Load
□ Numerische data
Kennzahlen
structures (e.g., arrays) and implement the OLAP Operational Refresh Serve
Produkt
dbs Data Mining
werden analysiert z.B.
operations over these special data structures.
Umsätze oder Bestände
There is more to building and maintaining a data warehouse Data sources
Data Marts Tools
than selecting an OLAP server and defining a schema and
□ Jede Kennzahl somehängt
complexvon einer
queries forMenge an Dimensionen
the warehouse. Different ab Figure 1. Data Warehousing Architecture
architectural alternatives exist. Many organizations want to
□ Dimensionenimplement
sind oft hierarchisch
an integrated enterprise warehouse that collects It includes tools for extracting data from multiple operational
information about
– Tag - Monat - Quartal – Jahr all subjects (e.g., customers, products, databases and external sources; for cleaning, transforming
sales, assets, personnel) spanning the whole organization. and integrating this data; for loading data into the data
– Produkt - Kategorie – Industrie
However, building an enterprise warehouse is a long and warehouse; and for periodically refreshing the warehouse to
complex
– Stadt - Bezirk - Land process, requiring extensive business modeling, and reflect updates at the sources and to purge data from15 the
may take many years to succeed. Some organizations are warehouse, perhaps onto slower archival storage. In addition
settling for data marts instead, which are departmentalUnternehmensanwendungen
Data-Warehouse: Operationen
S. Chaudhuri et U. Dayal „An Overview of Data Warehousing and OLAP Technology “ (1997)
■ Slicing und Dicing: Selektion/Auswahl bestimmter Informationen
■ Drill-Down: zunehmende Datendetails
Stadt
■ Drill-Up/Roll-Up: zunehmende Aggregation/Verdichtung der Daten Produkt
■ Pivoting/Rotation: Umorganisation der Datenansicht
16Let there Entity Relationship diagrams and normalization techniques
umn that are popularly used for database design in OLTP
pivoting
regate aUnternehmensanwendungen
environments. However, the database designs recommended
by ER diagrams are inappropriate for decision support
gregated
ue in theData-Warehouse: Datenspeicherung - ROLAP
systems where efficiency in querying and in loading data
(including incremental loads) are important.
e of the S. Chaudhuri et U. Dayal „An Overview of Data Warehousing and OLAP Technology “ (1997)
Most data warehouses use a star schema to represent the
and the
mple, if■ R(elational)OLAP
multidimensional data model. The database consists of a
single fact table and a single table for each dimension. Each
axis may
tuple in the fact table consists of a pointer (foreign key - often
sent the Daten
□ uses sind
a generated in efficiency)
key for Tabellen (relational)
to each of the dimensions gespeichert
sales for
that provide its multidimensional coordinates, and stores the
original
aders in
Umsetzung
□ numeric measures forim Sternschema
those mit Denormalisierungen aus Performanzgründen:
coordinates. Each dimension
table consists of columns that correspond to attributes of the
eine Faktentabellen
dimension. Figure 3 shows an example +ofeine Tabelle pro Dimension
a star schema.
ll-down.
ect and
hus, it is Order ProdNo
gregated OrderNo ProdName
OrderDate ProdDescr
ration is Fact table Category
onds to CategoryDescr
Customer OrderNo
aking a UnitPrice
CustomerNo SalespersonID
selected CustomerNo QOH
CustomerName
we can ProdNo Date
CustomerAddress
create a City DateKey DateKey
of sale. CityName Date
sorting), Salesperson Quantity Month
TotalPrice Year
SalespersonID
City
SalespesonName
City CityName
ted a lot State
business
Quota
Country 17
ans of a Figure 3. A Star Schema.
e storedLet there Entity Relationship diagrams and normalization techniques
umn that are popularly used for database design in OLTP
pivoting
regate aUnternehmensanwendungen
environments. However, the database designs recommended
by ER diagrams are inappropriate for decision support
schemas where the dimensional hierarchy is explicitly
gregated
ue in theData-Warehouse: Datenspeicherung - ROLAP
systems where efficiency in querying and in loading data
(including incremental loads) are important.
represented by normalizing the dimension tables, as shown in
Figure 4. This leads to advantages in maintaining the
Data w
answer
e of the S. Chaudhuri et U. Dayal „An Overview of Data Warehousing and However,
dimension tables. OLAP Technology “ (1997)structure of the
the denormalized
and the
Most data warehouses use a star schema to represent the access
mple, if■ R(elational)OLAP
multidimensional data model. The database consists of a dimensional tables in star schemas may be more appropriate issues a
single fact table and a single table for each dimension. Each for browsing the dimensions.
axis may
tuple in the fact table consists of a pointer (foreign key - often such as
sent the Schneeflockenschema
□ uses als Alternative:
a generated key for efficiency) to each of the dimensions Dimensionshierarchie wird explizit durch indices
sales for
original Normalisierung dargestellt
that provide its multidimensional coordinates, and stores the
numeric measures for those coordinates. Each dimension
Fact constellations are examples of more complex structures importa
aders in in which multiple fact tables share dimensional tables. For effectiv
table consists of columns that correspond to attributes of the
Sternschema
dimension. Figure 3 shows an example of a star schema. vs. Schneeflockenschema
example, projected expense and the actual expense may form answer
a fact constellation since they share many dimensions. importa
ll-down. Einfacheres Schema (Anfragen) vs. Weniger Redundanz efficien
ect and
hus, it is Order ProdNo Order Category
queries
OrderNo ProdNo efficien
gregated ProdName OrderNo CategoryName
OrderDate ProdName
ProdDescr OrderDate CategoryDescr
ration is Fact table Category
ProdDescr be expl
Fact table
onds to CategoryDescr
Category paper, i
Customer OrderNo Customer OrderNo
aking a UnitPrice
UnitPrice
selected CustomerNo SalespersonID
CustomerNo SalespersonID QOH Therefo
CustomerNo QOH
CustomerName CustomerName CustomerNo
we can ProdNo Date
create a
CustomerAddress
City DateKey DateKey vs. CustomerAddress DateKey
CityName
Date Month Year
Index S
Date City DateKey
of sale. CityName ProdNo Month
Quantity Month Date Year A numb
sorting), Salesperson Salesperson Quantity
TotalPrice Year Month
SalespersonID TotalPrice are use
City SalespersonID
SalespesonName City State
City CityName
SalespesonName
CityName
conditio
ted a lot City
Quota State
Quota State useful
18
business Country
operatio
ans of a Figure 3. A Star Schema. Figure 4. A Snowflake Schema.
e stored cases elUnternehmensanwendungen
Data-Warehouse: Datenspeicherung - MOLAP
S. Chaudhuri et U. Dayal „An Overview of Data Warehousing and OLAP Technology “ (1997)
■ M(ultidimensional)OLAP
□ Mehrdimensionale Daten sind in speziellen Datenstrukturen gespeichert
z.B. mehrdimensionale Arrays
□ Nutzen meist zwei Dimensionen (+ Kompressionsverfahren) um dünn
besetze Datenwürfel („sparse data“) effizient zu unterstützen
19Unternehmensanwendungen
Data-Warehouse: Datenspeicherung - Hilfsstrukturen
S. Chaudhuri et U. Dayal „An Overview of Data Warehousing and OLAP Technology “ (1997)
■ ROLAP- und MOLAP-Systeme nutzen Hilfsstrukturen für effiziente Anfragebearbeitung
□ Voraggregierte Daten (nach verschiedenen Dimensionen)
□ Materialisierte Sichten
□ Indexstrukturen
– Bit-Map-Index als Alternative zu Pointer/ID-Listen
à Effiziente Operationen: Index-Intersection, Index-Union
– Join-Indizes: Dimensionstabelle à Faktentabelle
– Indizes für Textsuche
■ Weitere Effizienzsteigerung durch Partitionierung/Sortierung möglich
20Unternehmensanwendungen Systemtrennung ■ Unternehmensanwendungen beinhalten sowohl transaktionale als auch analytische Anfragen ■ Aber: Anforderungen an OLAP- und OLTP-Datenbanksysteme sind widersprüchlich (historischer) Ansatz 1: Trennung in eigenständige Systeme (Tuning der Datenspeicherung und des Schemas) ■ Data Warehouse: separate optimierte OLAP-Datenbank □ Effizientere Bearbeitung komplexer analytischer Anfragen □ Daten vieler Datenbanken können integriert werden (moderner) Ansatz 2: Optimierung eines Systems für beide Anfragearten (mit Kompromissen) 21
Unternehmensanwendungen
Nachteile der Systemtrennung
■ Datenredundanz
■ Synchronisierung der Systeme durch Extract, Transform, Load (ETL)
□ Kostenintensiver Prozess
□ ETL verursacht eine Zeitverzögerung
■ Unterschiedliche Datenschemas erzeugen eine höhere Komplexität für Anwendungen,
die beide Systeme nutzen
22Unternehmensanwendungen
Kombination von OLTP und OLAP in einem System
■ Eine Datenbasis als „Wahrheitsquelle“ („Single source of truth“)
■ Ziel sind ad-hoc-Analysen auf dem transaktionalen Schema ohne materialisierte Sichten
(z.B. vorberechnete Aggregate) – „Mixed Workloads“ auf einem System
à Vereinfachte Anwendungen (nur eine DB mit allen Datenpunkten anfragen) und
Datenbankstrukturen (weniger Indizes, keine materialisierte Sichten)
■ Ermöglicht durch modernere/schnellere Hardware
■ Dennoch: für spezielle Charakteristiken optimierte Datenbanksysteme sind „One size fits all“
Systemen überlegen
Michael Stonebraker „One Size Fits All: An Idea Whose Time Has Come and Gone“ (2005)
23Unternehmensanwendungen
Vielseitige Anfrageeigenschaften („Mixed Workloads”)
■ Auch Hybrid Transactional/Analytical Processing (HTAP) oder OLxP
■ Vereinen Eigenschaften von OLTP und OLAP
□ Einfache und komplexe Abfragen
□ Vordefinierte und ad-hoc-Abfragen
□ „Zeilenoperationen“ und Analysen (Aggregationen, Gruppierungen, Joins)
über komplette Spalten
□ INSERTS, UPDATES und viele SELECTS
24Unternehmensanwendungen
Anfrageeigenschaften: OLTP Datenzugriffsmythos
Hasso Plattner „The Impact of Columnar In-Memory Databases on Enterprise Systems“ (2014)
■ Workload Analysen von Unternehmensanwendungen zeigen: OLTP und OLAP Workloads
unterscheiden sich NICHT wesentlich bezüglich ihres Schreibanteil
100% 100% 100%
90 % 90 % 90 % Delete
Delete Delete
80 % Modification 80 % Modification 80 % Modification
70 % Insert 70 % Insert 70 % Insert
Workload
Workload
60 % Workload 60 % 60 %
50 % Read 50 % 50 %
Read Read
40 % 40 % 40 %
30 % 30 % 30 %
20 % 20 % 20 %
10 % 10 % 10 %
0 % 0 % 0 %
TPC-C OLTP OLAP Classic Simplified*
SAP Financials
(a) TPC-C Benchmark (b) Workload Analysis (c) SAP Financials
Krueger et al. VLDB’11 Workload Analysis
*Without Transaction-Maintained Aggregates 25Unternehmensanwendungen
Eigenschaften von Unternehmensdaten
■ Viele Tabellen haben hunderte von Attributen
■ Viele Attribute werden in der Regel NICHT benutzt
■ Für viele Attribute dominieren NULL oder DEFAULT-Werte
■ Viele Attribute haben eine geringe Kardinalität (Anzahl verschiedener Attributwerte)
■ Tabellen sind breit und spärlich gefüllt à erlaubt effiziente Komprimierung
■ Detaillierte Informationen in
Jens Krüger „Fast Updates on Read-Optimized Databases Using Multi-Core CPUs“ (2011)
http://www.vldb.org/pvldb/vol5/p061_jenskrueger_vldb2012.pdf
26Unternehmensanwendungen
Zusammenfassung
■ Unternehmensanwendungen beinhalten sowohl transaktionale als auch analytische Anfragen;
Insbesondere analytische Anforderungen sind mit der Zeit gewachsen
■ Tabellen von Unternehmensanwendungen sind breit und spärlich gefüllt
■ Zwei Ansätze: Separat optimierte Systeme vs. Vereinigung in einem System
□ Vereinigung überwindet viele Nachteile der Systemtrennung
□ Entsprechende Datenbankarchitekturen beinhalten viele Optimierungen, die den Anfrage-
und Datencharakteristiken gerecht werden (kommende Vorlesungen)
27Unternehmensanwendungen
Übungsblatt 1
Unternehmensanwendungen
Sommersemester 2019: Übung 1
Aufgabe 1
Lesen Sie Ausschnitte aus Hasso Plattners Veröffentlichungen
• „A Common Database Approach for OLTP and OLAP
Using an In-Memory Column Database“
Abschnitt 1 – 3
http://www.sigmod09.org/images/sigmod1ktp-plattner.pdf
• „The Impact of Columnar In-Memory Databases on Enterprise Systems“
Abschnitt 1 – 5.2
http://www.vldb.org/pvldb/vol7/p1722-plattner.pdf
und fassen Sie die Inhalte unter Beantwortung folgender Fragen zusammen.
a) Nennen Sie Gründe für die historische Trennung von OLTP und OLAP in ver-
schiedene Systeme.
b) Warum und wie ist es heutzutage möglich OLTP- und OLAP-Anfragen in einem
System effizient zu bearbeiten?
c) Warum werden Inserts in Unternehmensanwendungen durch den Umstieg auf
spaltenbasierte Hauptspeicherdatenbanken nicht unbedingt langsamer als in ei-
ner Zeilendatenbank?
d) Erklären Sie warum die Vereinigung von OLTP und OLAP die Entwicklung neuer
Unternehmensanwendungen vereinfacht.
e) Welche Vorteile haben spaltenorientierte gegenüber zeilenorientierte Datenban-
ken?
f) Was ist der TPC-C Benchmark?
g) Welche Fragen haben Sie zu den gelesenen Abschnitten? (optional)
Aufgabe 2
Für die Bearbeitung der zweiten Übung benötigen Sie Zugang zu folgendem SAP HANA-
Datenbanksystem: 28
Host Name: syene.eaalab.hpi.uni-potsdam.de (192.168.31.39)
Instance Nummer: 02
User Name: STUDENTS
Password: Students17Sie können auch lesen
