Datenbanken Unit 9: OLAP, OLTP und objektrelationale ...institute.unileoben.ac.at/infotech/lehre/db/SS2017/Unit9.pdfOrganisatorischesSQL OLTP, OLAP, SAP, and Data Warehouse Objekt-relationale

Organisatorisches SQL OLTP, OLAP, SAP, and Data Warehouse Objekt-relationale Datenbanken

DatenbankenUnit 9: OLAP, OLTP und objektrelationale

Datenbanken

Ronald Ortner

17. V. 2017

Ronald Ortner


Outline

1 Organisatorisches

2 SQL

3 OLTP, OLAP, SAP, and Data WarehouseOLTP and OLAPSAPData Warehouse & OLAP

4 Objekt-relationale DatenbankenBeispielObjekt-relationale Datenbanken

Ronald Ortner


Organisatorisches

Nächste Woche entfallen VO und UE

Aktuelle ÜBeispiele bis in zwei Wochen

Noch drei Wissensüberprüfungen am 17.5., 31.5. und 7.6.

UE-Abschlusstest am 14. Juni(Gruppe 1: 14:45–16:00, Gruppe 2: 16:00–17:15 )

Am 21. Juni finden beide Übungsgruppen gleichzeitig statt(16–17:30 Uhr im RWZ HS).

Ronald Ortner


SQL

Heute:Nachbetrachtung WissensüberprüfungenDatentyp Date und Regular Expressions

Ronald Ortner


Nachbetrachtung Zwischentest

HAVING für Bedingungen an Aggregatfunktionen(Korrelierte Subqueries sind aufwendig, sollten also nurverwendet werden, wenn es wirklich notwendig ist!)COUNT 6= SUM

Kein GROUP BY ohne Aggregatfunktion!!!Eine Subtilität:Oft sollte im GROUP BY nicht der Ausdruck im SELECT sondernentsprechende id verwendet werden.

Ronald Ortner


OLTP and OLAP

Outline

1 Organisatorisches

2 SQL



Ronald Ortner


OLTP and OLAP

OLTP vs. OLAP

OLTP: online transaction processingOnline-DatenbankanwendungenBeispiele: Bestellungen, Buchungen, etc.wichtig ist die Verarbeitung aktuell anfallender Daten→ viele Updates und neue Einträge in der Datenbank

OLAP: online analytical processingDatenbankanwendungen für Analyse und Decision SupportBeispiele: Trendanalyse, Big Datahistorische Daten sind wichtig→ viele Daten, die meist in aggregierter Form benötigt werden

Ronald Ortner


OLTP and OLAP

OLTP vs. OLAP

OLTP: online transaction processingOnline-DatenbankanwendungenBeispiele: Bestellungen, Buchungen, etc.wichtig ist die Verarbeitung aktuell anfallender Daten→ viele Updates und neue Einträge in der Datenbank


Ronald Ortner


SAP

Outline

1 Organisatorisches

2 SQL



Ronald Ortner


SAP

SAP

SAP: Softwaresystem, hauptsächlich für OLTP

SAP hat drei Ebenen:großes relationales Datenbanksystem im HintergrundApplikationen, die auf Datenbank aufsetzenGUI

Zugriff auf dahinterliegende Datenbanken:Auf einige Tabellen kann normal via SQL zugegriffen werden.Dabei ist meist nur lesender Zugriff sinnvoll.Auf andere Tabellen kann nur via SAP zugegriffen werden.

Ronald Ortner


SAP

SAP


SAP hat drei Ebenen:großes relationales Datenbanksystem im HintergrundApplikationen, die auf Datenbank aufsetzenGUI

Zugriff auf dahinterliegende Datenbanken:Auf einige Tabellen kann normal via SQL zugegriffen werden.Dabei ist meist nur lesender Zugriff sinnvoll.Auf andere Tabellen kann nur via SAP zugegriffen werden.

Ronald Ortner


SAP

SAP


SAP hat drei Ebenen:große relationales Datenbanksystem im HintergrundApplikationen, die auf Datenbank aufsetzenGUI

Eigene Applikationen könne mit ABAP/4 geschrieben werden –Datenbankzugriff mit

Native SQL (mit speziellem User Interface)Open SQL (direkter Zugriff auf Datenbanken)

Ronald Ortner


Data Warehouse & OLAP

Outline

1 Organisatorisches

2 SQL



Ronald Ortner



OLTP vs. OLAP

OLTP: online transaction processingOnline-DatenbankanwendungenBeispiele: Bestellungen, Buchungen, etc.wichtig ist de Verarbeitung aktuell anfallender Daten→ viele Updates und neue Einträge in der Datenbank


→ Es ist keine gute Idee, OLTP und OLAP auf derselben Datenbankauszuführen.

Ronald Ortner



OLTP vs. OLAP

OLTP: online transaction processingOnline-DatenbankanwendungenBeispiele: Bestellungen, Buchungen, etc.wichtig ist de Verarbeitung aktuell anfallender Daten→ viele Updates und neue Einträge in der Datenbank


→ Es ist keine gute Idee, OLTP und OLAP auf derselben Datenbankauszuführen.

Ronald Ortner



Data Warehouse

Grundidee von Data Warehouse:Operationale Datenbank für OLTPSpeichere regelmäßig (aber nicht online!) Daten von operationalerDatenbank in Data Warehouse

Datenbankschemata für Data Warehouse:Sternschema:

eine zentrale Faktentabelleandere Tabellen nicht normalisiert

Schneeflockenschema:eine zentrale Faktentabelleandere Tabellen normalisiert (→ benötigt mehr Joins)

Ronald Ortner



Data Warehouse





Ronald Ortner



Data Warehouse





Ronald Ortner



Roll Up und Drill Down

Abfragen auf Data Warehouse typischerweise in aggregierter Form(→ GROUP BY)

Drill down: mehr Attribute im GROUP BY

Roll up: weniger Attribute im GROUP BY

Daten können in einer Tabelle bzw. allgemein im “Data cube”dargestellt werden.

Ronald Ortner



Cube Operator

Data cube:

Ausführung aller nötigen Abfragen aufwendig

können Tabelle für Data cube speichern(mit NULL Werten, wo aggregiert wird)immer noch recht aufwendig und unpraktisch→ Idee: neuer SQL Operator CUBEVerwendung: GROUP BY CUBE( attr1, attr2, . . .)Weitere Möglichkeit:

speichern Tabelle, die maximal “drilled-down” istaggregieren diese Tabelle(weniger aufwendig als Aggregation jedesmal neu zu machen)

Ronald Ortner



Cube Operator

Data cube:

Ausführung aller nötigen Abfragen aufwendigkönnen Tabelle für Data cube speichern(mit NULL Werten, wo aggregiert wird)

immer noch recht aufwendig und unpraktisch→ Idee: neuer SQL Operator CUBEVerwendung: GROUP BY CUBE( attr1, attr2, . . .)Weitere Möglichkeit:


Ronald Ortner



Cube Operator

Data cube:

Ausführung aller nötigen Abfragen aufwendigkönnen Tabelle für Data cube speichern(mit NULL Werten, wo aggregiert wird)immer noch recht aufwendig und unpraktisch

→ Idee: neuer SQL Operator CUBEVerwendung: GROUP BY CUBE( attr1, attr2, . . .)Weitere Möglichkeit:


Ronald Ortner



Cube Operator

Data cube:

Ausführung aller nötigen Abfragen aufwendigkönnen Tabelle für Data cube speichern(mit NULL Werten, wo aggregiert wird)immer noch recht aufwendig und unpraktisch→ Idee: neuer SQL Operator CUBEVerwendung: GROUP BY CUBE( attr1, attr2, . . .)

Weitere Möglichkeit:speichern Tabelle, die maximal “drilled-down” istaggregieren diese Tabelle(weniger aufwendig als Aggregation jedesmal neu zu machen)

Ronald Ortner



Cube Operator

Data cube:

Ausführung aller nötigen Abfragen aufwendigkönnen Tabelle für Data cube speichern(mit NULL Werten, wo aggregiert wird)immer noch recht aufwendig und unpraktisch→ Idee: neuer SQL Operator CUBEVerwendung: GROUP BY CUBE( attr1, attr2, . . .)Weitere Möglichkeit:


Ronald Ortner



Row Store vs. Column Store

Typischerweise werden Tabellen zeilenweise gespeichert.

Bei vielen Spalten, kann es aus Performancegründen u.U. auchbesser sein, spaltenweise zu speichern:

Die meisten Abfragen betreffen nur wenige Spalten.Spaltenwerte sind ähnlicher und können leichter komprimiertwerden. Verwendung von Wörterbuch-Tabelle

Ronald Ortner




Typischerweise werden Tabellen zeilenweise gespeichert.Bei vielen Spalten, kann es aus Performancegründen u.U. auchbesser sein, spaltenweise zu speichern:


Ronald Ortner





Die meisten Abfragen betreffen nur wenige Spalten.

Spaltenwerte sind ähnlicher und können leichter komprimiertwerden. Verwendung von Wörterbuch-Tabelle

Ronald Ortner





Die meisten Abfragen betreffen nur wenige Spalten.Spaltenwerte sind ähnlicher und können leichter komprimiertwerden.

Verwendung von Wörterbuch-Tabelle

Ronald Ortner






Ronald Ortner


Beispiel

Outline

1 Organisatorisches

2 SQL



Ronald Ortner


Beispiel

Beispiel: Bücherdatenbank

Ronald Ortner


Beispiel


Wir führen IDs für Autoren, Bücher und Keywords ein.

Dann:eine Tabelle für jeden Entitätstyp (mit den IDs alsPrimärschlüssel):Autoren: {[a_id, Name]}Bücher: {[b_id, Titel, Verlag]}Keywords: {[k_id, Keyword]}eine Tabelle für jede Relation:schreibt: {[a_id, b_id]}hat_Keyword: {[b_id, k_id, Gewicht]}

→ brauchen fünf (!) Tabellen für einen Entitätstyp

Ronald Ortner


Beispiel


Wir führen IDs für Autoren, Bücher und Keywords ein.

Dann:eine Tabelle für jeden Entitätstyp (mit den IDs alsPrimärschlüssel):Autoren: {[a_id, Name]}Bücher: {[b_id, Titel, Verlag]}Keywords: {[k_id, Keyword]}eine Tabelle für jede Relation:schreibt: {[a_id, b_id]}hat_Keyword: {[b_id, k_id, Gewicht]}

→ brauchen fünf (!) Tabellen für einen Entitätstyp

Ronald Ortner


Objekt-relationale Datenbanken

Outline

1 Organisatorisches

2 SQL



Ronald Ortner



Objektorientierte Erweiterungen

→ erweitern relationale Datenbanktheorie mit objektorientierten Ideen:

Mögliche Ansätze:

zusätzliche Struktur in Datenbanken:→ implizite Joins (keine Join-Bedingung nötig)

geben 1.NF auf und erlauben strukturierte Informationen:→ können z.B. mehrere Autoren oder Keywords speichern

Ronald Ortner





Mögliche Ansätze:



Ronald Ortner





Mögliche Ansätze:



Ronald Ortner




In objekt-relationaler Datenbank gibt es weiters:

Möglichkeit, Objekte mithilfe anderer Objekte zu definierenVererbungObjektmethoden

→ objekt-orientierte Programmiersprachen wie etwa Java

Ronald Ortner

Documents

Datenbanken Unit 9: OLAP, OLTP und objektrelationale ...institute.unileoben.ac.at/infotech/lehre/db/SS2017/Unit9.pdfOrganisatorischesSQL OLTP, OLAP, SAP, and Data Warehouse Objekt-relationale