Informationslogistik Unit 10: OLTP, OLAP, SAP, Data Warehouse, and Object-relational Databases

Transcription

1 Informationslogistik Unit 10: OLTP, OLAP, SAP, Data Warehouse, and Object-relational Databases 19. V. 2015

2 Outline 1 Organization 2 Normalization: Another Example 3 OLTP, OLAP, SAP, and Data Warehouse OLTP and OLAP SAP 4 SQL: Subtleties for COUNT and JOINs

3 Organization Results for second intermediate test. Common errors: - see common errors sheet - when to use a correlated subquery No lectures next Tuesday, exercises due till June 2nd. Additional material for normalization: Chapter 2 of Andreas Meier: Relationale und postrelationale Datenbanken, Springer (available online within MUL)

4 Normalization: Another Example Design a database for storing information of a ticket agency for pop/rock concerts. Store for each concert the band(s) playing at the concert, date, country, town, and venue when/where the concert takes place, the time when the concert starts, and the ticket price. (You may assume that for a given concert all tickets are the same price.) Store also for each customer buying tickets his/her name, address, and thenumber of tickets purchased for which concert(s).

5 OLTP and OLAP Outline 1 Organization 2 Normalization: Another Example 3 OLTP, OLAP, SAP, and Data Warehouse OLTP and OLAP SAP 4 SQL: Subtleties for COUNT and JOINs

6 OLTP and OLAP OLTP vs. OLAP OLTP: online transaction processing Database applications for ongoing work Examples: orders, bookings, etc. current data is important many updates and changes in database

7 OLTP and OLAP OLTP vs. OLAP OLTP: online transaction processing Database applications for ongoing work Examples: orders, bookings, etc. current data is important many updates and changes in database OLAP: online analytical processing Database applications for analysis and decision support Example: analysis of trends historical data is important lots of data, need information in aggregated form

8 SAP Outline 1 Organization 2 Normalization: Another Example 3 OLTP, OLAP, SAP, and Data Warehouse OLTP and OLAP SAP 4 SQL: Subtleties for COUNT and JOINs

9 SAP SAP SAP: software system, mainly for OLTP SAP has three levels: big relational database system in the background applications that work on the database system graphical user interface

10 SAP SAP SAP: software system, mainly for OLTP SAP has three levels: big relational database system in the background applications that work on the database system graphical user interface Access to underlying database system: Some tables can be accessed also outside SAP (using SQL). Usually only read access is sensible. Some other tables can be accessed only via SAP.

11 SAP SAP SAP: software system, mainly for OLTP SAP has three levels: big relational database system in the background applications that work on the database system graphical user interface Writing applications with ABAP/4 access to databases with Native SQL (using special interface) Open SQL (direct access to databases)

12 Outline 1 Organization 2 Normalization: Another Example 3 OLTP, OLAP, SAP, and Data Warehouse OLTP and OLAP SAP 4 SQL: Subtleties for COUNT and JOINs

13 OLTP vs. OLAP OLTP: online transaction processing Database applications for ongoing work Examples: orders, bookings, etc. current data is important many updates and changes in database OLAP: online analytical processing Database applications for analysis and decision support Example: analysis of trends historical data is important lots of data, need information in aggregated form

14 OLTP vs. OLAP OLTP: online transaction processing Database applications for ongoing work Examples: orders, bookings, etc. current data is important many updates and changes in database OLAP: online analytical processing Database applications for analysis and decision support Example: analysis of trends historical data is important lots of data, need information in aggregated form no good idea to do OLTP and OLAP on the same database system

15 Data Warehouse Idea of Data Warehouse: Do OLTP on operational databases Store information from operational databases regularly (but not online!) in data warehouse

16 Data Warehouse Idea of Data Warehouse: Do OLTP on operational databases Store information from operational databases regularly (but not online!) in data warehouse Database Scheme for Data Warehouse: Star Scheme: Central fact table other tables not normalized

17 Data Warehouse Idea of Data Warehouse: Do OLTP on operational databases Store information from operational databases regularly (but not online!) in data warehouse Database Scheme for Data Warehouse: Star Scheme: Central fact table other tables not normalized Snowflake Scheme: Central fact table other tables normalized ( more joins necessary)

18 Roll Up and Drill Down Queries on Data Warehouse for analysis usually aggregate data ( GROUP BY) Drill down: more attributes in GROUP BY Roll up: fewer attributes in GROUP BY Data can be summarized in a cross table (data cube)

19 Relations for Aggregation & the Cube Operator Creating the data cube: expensive to execute all queries for creating cube

20 Relations for Aggregation & the Cube Operator Creating the data cube: expensive to execute all queries for creating cube can store relation for data cube (using NULL values where aggregated)

21 Relations for Aggregation & the Cube Operator Creating the data cube: expensive to execute all queries for creating cube can store relation for data cube (using NULL values where aggregated) still elaborate and uncomfortable

22 Relations for Aggregation & the Cube Operator Creating the data cube: expensive to execute all queries for creating cube can store relation for data cube (using NULL values where aggregated) still elaborate and uncomfortable idea: new SQL operator CUBE Usage: GROUP BY CUBE( attr1, attr2,... )

23 Relations for Aggregation & the Cube Operator Creating the data cube: expensive to execute all queries for creating cube can store relation for data cube (using NULL values where aggregated) still elaborate and uncomfortable idea: new SQL operator CUBE Usage: GROUP BY CUBE( attr1, attr2,... ) Other possibility: storing maximally drilled-down table aggregate this table (cheaper than doing each aggregation from scratch)

24 Row Store vs. Column Store Usually, tables are stored row-wise.

25 Row Store vs. Column Store Usually, tables are stored row-wise. When there are many columns, it may be better to store column-wise:

26 Row Store vs. Column Store Usually, tables are stored row-wise. When there are many columns, it may be better to store column-wise: Most queries consider only few columns.

27 Row Store vs. Column Store Usually, tables are stored row-wise. When there are many columns, it may be better to store column-wise: Most queries consider only few columns. Column values can be better compressed.

28 Row Store vs. Column Store Usually, tables are stored row-wise. When there are many columns, it may be better to store column-wise: Most queries consider only few columns. Column values can be better compressed. Use e.g. dictionary table.

29 SQL-Lesson Today: Extensions I: counting with 0 Extensions II: when to put conditions in the ON / WHERE part