StarView: mit statischem SQL dynamische Abfragen auf StarSchema

Transkript

1 StarView: mit statischem SQL dynamische Abfragen auf StarSchema DOAG Konferenz 2013 Nürnberg, November 2013 Slavomir Nagy metafinanz Informationssysteme GmbH

2 Wir fokussieren mit unseren Services die Herausforderungen des Marktes und verbinden Mensch und IT. Business Intelligence Themenbereiche Über metafinanz Enterprise DWH Data Modeling & Integration & ETL Architecture: DWH & Data Marts Hadoop & Columnar DBs Data Quality & Data Masking Insurance Reporting Standard & Adhoc Reporting Dashboarding BI Office Integration Mobile BI & InMemory SAS Trainings for Business Analysts BI & Risk Customer Intelligence Customer based Analytics & Processes Churn Prediction and Management Insurance Analytics Segmentation and Clustering Predictive Models, Data Mining & Statistics Scorecarding Social Media Analytics Fraud & AML Risk Solvency II (Standard & internal Model) Regulatory Reporting Compliance Risk Management metafinanz gehört seit 23 Jahren zu den erfahrensten Software- und Beratungshäusern mit Fokus auf die Versicherungsbranche. Mit einem Jahresumsatz von 250 Mio. EUR und über Mitarbeitern entwickeln wir für unsere Kunden intelligente zukunftsorientierte Lösungen für komplexe Herausforderungen Slavomir Nagy Ihr Ansprechpartner Principal Consultant Mehr als 16 Jahre Oracle-Erfahrung Oracle DWH Certified Specialist CFA Zertifizierung mail: phone: <Titel der Präsentation> Seite 2

3 StarView: mit statischem SQL dynamische Abfragen auf StarSchema 1 Motivation 2 Einfache Abfrage 3 Abfrage mit Partition Pruning 4 Abfrage mit Query Rewrite 5 Abfrage mit Row-Level Security 6 Fazit StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 3

4 1 Motivation

5 Am Ende des Datenflusses sind nicht nur Endbenutzer mit BI Tools, sondern auch? Business Intelligence Umgebung Data Mart (StarSchema) Endanwender BI Tools Dimension A Dimension B 34 Umsatz Plan Ist Nach Regionen Asien Europa Sonstige Anzahl Mitarbeiter Monatsumsatz 2013 Fakten Plan Wirklichkeit Mil. EUR Jan Febr Mar Apr May Jun Jul Aug Sept Oct Nov Dec Dimension C Dimension D StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 5

6 Die Daten aus dem Data Mart werden in einer flachen Tabelle gespeichert, damit sie auch anderen Abnehmer zur Verfügung stehen können. Nicht BI-Tool basierte Datenabnehmer Die Daten aus dem Data Mart werden auch für folgende Abnehmer benötigt Datenexports Folgesysteme mit Einschränkungen beim Metadatenmodell Endbenutzer ohne oder nur mit minimalem SQL Knowhow Poweruser mit exzellenten SQL Kenntnissen Lösung: flache Tabelle StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 6

7 Speicherung der gesamten Daten aus dem Starschema in einer flachen Tabelle hat mehrere Nachteile. Flache Tabelle ist einfach zu verstehen (keine Joins notwendig) aber braucht extra Umsetzung braucht extra Speicherplatz für die Daten benötigt dabei normalerweise mehr Platz als Starschema braucht extra Zeit für den Aufbau Unterschiede bei den Datenständen zwischen Starschema und Tabelle sind möglich (zeitlich und inhaltlich) Lösung: StarView benötigt erneutes physisches Design (Partitionierung, Indizierung) StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 7

8 Bis auf die Notwendigkeit der zusätzlichen Aufwände für die Umsetzung ist ein View im Vorteil im Vergleich zu einer flachen Tabelle View auf dem StarSchema -> StarView Daten immer konsistent mit dem Starschema (ist nur ein Datenbank-View, kein MView) keine extra Laufzeit notwendig - kein extra Speicherplatz notwendig Umsetzung notwendig (aber durch Generierung sehr effizient möglich) leicht verständlich (für SQL Abfragen identisch mit einer flachen Tabelle) kein erneutes physisches Design notwendig StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 8

9 Datenmodell des Beispielschemas SH mit der Faktentabelle SALES und fünf Dimensionstabellen SH.CHANNELS 5 Zeilen 64 KB 4 Blocks AVG_ROW_LEN 41 SH.TIMES 1,826 Zeilen 512 KB 198 Blocks AVG_ROW_LEN 59 SH.PROMOTIONS 503 Zeilen 512 KB 57 Blocks AVG_ROW_LEN 98 SH.PRODUCTS SH.SALES 72 Zeilen 918,843 Zeilen 64 KB 128 MB 5 Blocks 1,907 Blocks AVG_ROW_LEN 173 AVG_ROW_LEN Partitionen je 8 MB SH.CUSTOMERS 1995 und 1996 jährlich 1997 halbjährlich 55,500 Zeilen 1998 bis 2003 quartalsweise 5 Dimensionstabellen FKs 12 MB 2 Kennzahlen 1,486 Blocks AVG_ROW_LEN 181 (QUANTITY_SOLD und AMOUNT_SOLD) StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 9

10 2 Einfache Abfrage

11 So sieht eine typische fachliche Abfrage aus einem Data Mart aus Einfache Abfrage Wie waren die monatlichen Umsätze nach Produkt-Kategorien und Subkategorien über die gesamte Historie? StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 11

12 Das dynamische SQL hat durch die Verwendung von Metadaten und durch das Generieren der SQL Abfragen große Vorteile im Vergleich zum statischen SQL Einfache Abfrage: Ideale SQL Abfrage SQL Abfrage kann dynamisch erstellt werden nur die relevanten Tabellen werden abgefragt SELECT calendar_year, calendar_month_name, prod_category, prod_subcategory, SUM(amount_sold) as amount_sold FROM sales s JOIN times t ON t.time_id=s.time_id JOIN products p ON p.prod_id=s.prod_id GROUP BY calendar_year, calendar_month_name, prod_category, prod_subcategory ORDER BY calendar_year, calendar_month_name, prod_category, prod_subcategory Id Operation Name SELECT STATEMENT 1 SORT ORDER BY 2 HASH GROUP BY * 3 HASH JOIN 4 TABLE ACCESS FULL PRODUCTS 5 VIEW VW_GBC_9 6 HASH GROUP BY * 7 HASH JOIN 8 PART JOIN FILTER CREATE :BF TABLE ACCESS FULL TIMES 10 PARTITION RANGE JOIN-FILTER 11 TABLE ACCESS FULL SALES StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 12

13 Die Performanz des StarViews soll vergleichbar mit der Performanz der optimalen Abfrage sein Einfache Abfrage mit View SQL Abfrage soll möglichst einfach sein SELECT calendar_year, calendar_month_name, prod_category, prod_subcategory, SUM(amount_sold) as amount_sold FROM sales s JOIN times t ON t.time_id=s.time_id JOIN products p ON p.prod_id=s.prod_id GROUP BY calendar_year, calendar_month_name, prod_category, prod_subcategory ORDER BY calendar_year, calendar_month_name, prod_category, prod_subcategory dabei soll aber die Performanz vergleichbar mit der idealen Abfrage sein SELECT calendar_year, calendar_month_name, prod_category, prod_subcategory, SUM(amount_sold) as amount_sold FROM <view> GROUP BY calendar_year, calendar_month_name, prod_category, prod_subcategory ORDER BY calendar_year, calendar_month_name, prod_category, prod_subcategory StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 13

14 Das erste View kann ohne Auswirkungen auf die Performanz in zwei Versionen umgesetzt werden View INNER: Alle Dimensionstabellen mit INNER JOIN entweder mit der Oracle-Syntax (Joins in WHERE-Bedingung definiert) oder mit der ANSI-Syntax (INNER JOIN ON ) CREATE OR REPLACE FORCE VIEW v_sales_inner AS SELECT t.time_id,day_name,day_number_in_week, p.prod_id,prod_name,prod_desc,prod_subcategory, c.cust_id,cust_first_name,cust_last_name, x.channel_id,channel_desc,channel_class, r.promo_id,promo_name,promo_subcategory, s.amount_sold, s.quantity_sold FROM sales s,times t,products p,channels x,customers c,promotions r WHERE t.time_id=s.time_id AND p.prod_id=s.prod_id AND x.channel_id=s.channel_id AND c.cust_id=s.cust_id AND r.promo_id=s.promo_id CREATE OR REPLACE FORCE VIEW v_sales_inner_ansi AS SELECT t.time_id,day_name,day_number_in_week, p.prod_id,prod_name,prod_desc,prod_subcategory, c.cust_id,cust_first_name,cust_last_name, x.channel_id,channel_desc,channel_class, r.promo_id,promo_name,promo_subcategory, s.amount_sold, s.quantity_sold FROM sales s INNER JOIN times t ON t.time_id=s.time_id INNER JOIN products p ON p.prod_id=s.prod_id INNER JOIN channels x ON x.channel_id=s.channel_id INNER JOIN customers c ON c.cust_id=s.cust_id INNER JOIN promotions r ON r.promo_id=s.promo_id StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 14

15 Bei View mit INNER JOIN wird im Ausführungsplan der eindeutige Index über Primärschlüssel der in der Abfrage nicht verwendeten Dimensionstabellen benutzt View INNER: Ausführungsplan Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 649 (100) 1 SORT ORDER BY K 649 (12) 00:00:08 2 HASH GROUP BY K 649 (12) 00:00:08 * 3 HASH JOIN K 647 (11) 00:00:08 4 TABLE ACCESS FULL PRODUCTS (0) 00:00:01 5 VIEW VW_GBC_ (11) 00:00:08 6 HASH GROUP BY K 643 (11) 00:00:08 * 7 HASH JOIN 918K 53M 602 (5) 00:00:08 8 INDEX FAST FULL SCAN CUSTOMERS_PK K 33 (0) 00:00:01 * 9 HASH JOIN 918K 49M 563 (5) 00:00:07 10 PART JOIN FILTER CREATE :BF (0) 00:00:01 11 TABLE ACCESS FULL TIMES (0) 00:00:01 * 12 HASH JOIN 918K 31M 540 (4) 00:00:07 13 MERGE JOIN CARTESIAN (0) 00:00:01 14 INDEX FULL SCAN CHANNELS_PK (0) 00:00:01 15 BUFFER SORT (0) 00:00:01 16 INDEX FAST FULL SCAN PROMO_PK (0) 00:00:01 17 PARTITION RANGE JOIN-FILTER 918K 25M 531 (3) 00:00:07 :BF0000 :BF TABLE ACCESS FULL SALES 918K 25M 531 (3) 00:00:07 :BF0000 :BF Primärschlüssel der nicht abgefragten Dimensionstabellen wird gelesen StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 15

16 Beim zweiten View wird jede Spalte der Dimensionstabelle über eine Unterabfrage abgefragt View SUBSELECT: Unterabfrage pro Spalte CREATE OR REPLACE FORCE VIEW v_sales_subselect AS SELECT (select t.time_id from TIMES t where t.time_id=s.time_id) as TIME_ID, (select t.day_name from TIMES t where t.time_id=s.time_id) as DAY_NAME, (select t.prod_id from PRODUCTS t where t.prod_id=s.prod_id) as PROD_ID, (select t.prod_name from PRODUCTS t where t.prod_id=s.prod_id) as PROD_NAME, (select t.prod_desc from PRODUCTS t where t.prod_id=s.prod_id) as PROD_DESC, (select t.cust_id from CUSTOMERS t where t.cust_id=s.cust_id) as CUST_ID, (select t.cust_first_name from CUSTOMERS t where t.cust_id=s.cust_id) as CUST_FIRST_NAME, (select t.cust_last_name from CUSTOMERS t where t.cust_id=s.cust_id) as CUST_LAST_NAME, (select t.promo_name from PROMOTIONS t where t.promo_id=s.promo_id) as PROMO_NAME, (select t.channel_class from CHANNELS t where t.channel_id=s.channel_id) as CHANNEL_CLASS, s.amount_sold, s.quantity_sold FROM sales s StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 16

17 Im Ausführungsplan von View 2 wird die gleiche Dimensionstabelle mehrmals abgefragt, wenn mehrere Spalten aus der Dimension in der Abfrage benötigt werden View SUBSELECT: Ausführungsplan Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 613 (100) 1 TABLE ACCESS BY INDEX ROWID TIMES (0) 00:00:01 * 2 INDEX UNIQUE SCAN TIMES_PK 1 1 (0) 00:00:01 3 TABLE ACCESS BY INDEX ROWID TIMES (0) 00:00:01 * 4 INDEX UNIQUE SCAN TIMES_PK 1 1 (0) 00:00:01 5 TABLE ACCESS BY INDEX ROWID PRODUCTS (0) 00:00:01 * 6 INDEX UNIQUE SCAN PRODUCTS_PK 1 0 (0) 7 TABLE ACCESS BY INDEX ROWID PRODUCTS (0) 00:00:01 * 8 INDEX UNIQUE SCAN PRODUCTS_PK 1 0 (0) 9 SORT ORDER BY 918K 75M 613 (16) 00:00:08 10 HASH GROUP BY 918K 75M 613 (16) 00:00:08 11 PARTITION RANGE ALL 918K 75M 531 (3) 00:00: VIEW V_SALES_SUBSEL 918K 75M 531 (3) 00:00:07 13 TABLE ACCESS FULL SALES 918K 14M 531 (3) 00:00: Nicht benötigte Dimensionstabellen werden nicht abgefragt Bei mehreren abgefragten Spalten wird auf die gleiche Tabelle mehrmals zugegriffen StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 17

18 Das dritte View fragt die Dimensionstabelle nur einmal ab, verkettet zuerst die Spaltenwerte in eine Zeichenkette und zerlegt sie dann wieder zurück in Spaltenwerte View STRING: Unterabfrage pro Tabelle CREATE OR REPLACE FORCE VIEW v_sales_string AS SELECT substr(times_string,instr(times_string,' ',1,1)+1,instr(TIMES_string,' ',1,2)-1- instr(times_string,' ',1,1)) as TIME_ID, ' ', substr(times_string,instr(times_string,' ',1,2)+1,instr(TIMES_string,' ',1,3)-1- instr(times_string,' ',1,2)) as DAY_NAME, 'Thursday', '4', substr(products_string,instr(products_string,' ',1,1)+1,instr(PRODUCTS_string,' ',1,2)-1- instr(products_string,' ',1,1)) as PROD_ID, q.amount_sold, q.quantity_sold FROM (SELECT 'Cameras', (select ' ' TIME_ID ' ' DAY_NAME ' ' DAY_NUMBER_IN_WEEK ' ' from TIMES t where t.time_id=s.time_id) as TIMES_string, (select ' ' PROD_ID ' ' PROD_NAME ' ' PROD_DESC ' ' PROD_SUBCATEGORY ' ' from PRODUCTS t where t.prod_id=s.prod_id) as PRODUCTS_string, Thursday 4 '13', '5MP Telephoto Digital Camera' '5MP Telephoto Digital Camera', (select ' ' CUST_ID ' ' CUST_FIRST_NAME ' ' CUST_LAST_NAME ' ' from CUSTOMERS t where t.cust_id=s.cust_id) Friday 5 as CUSTOMERS_string, (select ' ' PROMO_ID ' ' Saturday 6 PROMO_NAME ' ' PROMO_SUBCATEGORY ' ' from PROMOTIONS t where t.promo_id=s.promo_id) as PROMOTIONS_string, (select ' ' CHANNEL_ID 13 5MP ' ' Telephoto CHANNEL_DESC Digital Camera 5MP ' ' CHANNEL_CLASS Telephoto Digital Camera Cameras ' ' from CHANNELS t where t.channel_id=s.channel_id) 14 17" LCD as w/built-in CHANNELS_string, HDTV Tuner 17" LCD w/built-in HDTV Tuner Monitors 15 Envoy 256MB - 40GB Envoy 256MB - 40Gb Desktop PCs s.amount_sold, s.quantity_sold FROM sales s ) q StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 18

19 Bereits bei der Ausführung merkt man Probleme mi der Performanz, das Problem des Views 2 wurde zwar gelöst, aber der Speicherbedarf steigt enorm (ca. 100-fach) View STRING: Ausführungsplan Durch die Verwendung von Verkettung steigen die Speicherplatzanforderungen Auch die Ausführung von Zeichenkettenfunktionen kostet Zeit Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 613 (100) 1 TABLE ACCESS BY INDEX ROWID TIMES (0) 00:00:01 * 2 INDEX UNIQUE SCAN TIMES_PK 1 1 (0) 00:00:01 3 TABLE ACCESS BY INDEX ROWID PRODUCTS (0) 00:00:01 * 4 INDEX UNIQUE SCAN PRODUCTS_PK 1 0 (0) 5 SORT ORDER BY 918K 7028M 613 (16) 00:00:08 6 HASH GROUP BY 918K 7028M 613 (16) 00:00:08 7 PARTITION RANGE ALL 918K 7028M 531 (3) 00:00: VIEW V_SALES_STRING 918K 7028M 531 (3) 00:00:07 9 TABLE ACCESS FULL SALES 918K 14M 531 (3) 00:00: Dimensionstabellen werden nur einmal gelesen Die Performanz ist durch Verwendung von String-Funktionen deutlich schlechter geworden StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 19

20 Um die Probleme mit den Zeichenketten zu vermeiden, werden die Spaltenwerte zwischen Unterabfrage und Hauptabfrage mit Hilfe von Datenbanktyp OBJECT weitergeleitet. Pro Dimensionstabelle ein OBJECT-Typ erstellen create type t_times_obj as object ( TIME_ID DATE,DAY_NAME VARCHAR2(9),DAY_NUMBER_IN_WEEK NUMBER(1,0) ) / create type t_products_obj as object ( PROD_ID NUMBER(6,0),PROD_NAME VARCHAR2(50),PROD_DESC VARCHAR2(4000),PROD_SUBCATEGORY VARCHAR2(50) ) / create type t_customers_obj as object ( CUST_ID NUMBER,CUST_FIRST_NAME VARCHAR2(20),CUST_LAST_NAME VARCHAR2(40),CUST_GENDER CHAR ) / create type t_promotions_obj as object ( PROMO_ID NUMBER(6,0),PROMO_NAME VARCHAR2(30),PROMO_SUBCATEGORY VARCHAR2(30) ) / create type t_channels_obj as object ( CHANNEL_ID NUMBER,CHANNEL_DESC VARCHAR2(20),CHANNEL_CLASS VARCHAR2(20),CHANNEL_CLASS_ID NUMBER,CHANNEL_TOTAL VARCHAR2(13),CHANNEL_TOTAL_ID NUMBER ) / StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 20

21 Die vierte Lösung benutzt für die Weitergabe der Spaltenwerte zwischen dem inneren und äußeren SELECT den Datenbanktyp OBJECT View OBJECT: Unterabfrage mit Typ OBJECT CREATE OR REPLACE FORCE VIEW v_sales_object AS SELECT q.times_obj.time_id as TIME_ID, q.times_obj.day_name as DAY_NAME, DATE ' ', q.products_obj.prod_id as PROD_ID, 'Thursday', q.products_obj.prod_name as PROD_NAME, 4, q.products_obj.prod_desc as PROD_DESC, '13', q.amount_sold, q.quantity_sold '5MP Telephoto Digital Camera' FROM (SELECT '5MP Telephoto Digital Camera', (select t_times_obj(time_id,day_name, ) from TIMES 'Cameras', t where t.time_id=s.time_id) as TIMES_obj, (select t_products_obj(prod_id,prod_name,prod_desc,prod_subcategory, ) from PRODUCTS t where t.prod_id=s.prod_id) as PRODUCTS_obj, (select t_customers_obj(cust_id,cust_first_name,cust_last_name,cust_gender, ) from CUSTOMERS t where t.cust_id=s.cust_id) as CUSTOMERS_obj, t_times_obj( DATE ' ', 'Thursday', 4, ) (select t_promotions_obj(promo_id,promo_name,promo_subcategory, ) from PROMOTIONS t where t.promo_id=s.promo_id) ast_times_obj( PROMOTIONS_obj, DATE ' ', 'Friday', 5, ) (select t_channels_obj(channel_id,channel_desc,channel_class, ) t_times_obj( DATE ' ', 'Saturday', from CHANNELS t 6, where ) t.channel_id=s.channel_id) as CHANNELS_obj, s.amount_sold, s.quantity_sold FROM sales s ) q t_products_obj( 13, '5MP Telephoto Digital Camera', '5MP Telephoto Digital Camera', 'Cameras', ) t_products_obj( 14, '17" LCD w/built-in HDTV Tuner', '17" LCD w/built-in HDTV Tuner', 'Monitors', ) t_products_obj( 15, 'Envoy 256MB - 40GB', 'Envoy 256MB - 40Gb', 'Desktop PCs', ) StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 21

22 Der Ausführungsplan sieht in Ordnung aus, und die Laufzeit ist besser aber immer noch merkbar schlechter im Vergleich zur Abfrage aus dem BI Tool View OBJECT: Ausführungsplan Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 613 (100) 1 TABLE ACCESS BY INDEX ROWID TIMES (0) 00:00:01 * 2 INDEX UNIQUE SCAN TIMES_PK 1 1 (0) 00:00:01 3 TABLE ACCESS BY INDEX ROWID PRODUCTS (0) 00:00:01 * 4 INDEX UNIQUE SCAN PRODUCTS_PK 1 0 (0) 5 SORT ORDER BY 918K 75M 613 (16) 00:00:08 6 HASH GROUP BY 918K 75M 613 (16) 00:00:08 7 PARTITION RANGE ALL 918K 75M 531 (3) 00:00: VIEW V_SALES_OBJECT 918K 75M 531 (3) 00:00:07 9 TABLE ACCESS FULL SALES 918K 14M 531 (3) 00:00: Dimensionstabellen werden nur einmal gelesen, Speicherplatzanforderungen wieder normal Die Performanz ist wegen OBJECT-Typ immer noch nicht ideal StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 22

23 Das fünfte View kann ohne Auswirkungen auf die Performanz ebenfalls in zwei Versionen umgesetzt werden View OUTER: Alle Dimensionen mit OUTER JOIN entweder mit der Oracle-Syntax (Joins mit (+) in WHERE-Bedingung definiert) oder mit der ANSI-Syntax (LEFT OUTER JOIN ON ) CREATE OR REPLACE FORCE VIEW v_sales_outer AS SELECT t.time_id,day_name,day_number_in_week, p.prod_id,prod_name,prod_desc,prod_subcategory, c.cust_id,cust_first_name,cust_last_name, x.channel_id,channel_desc,channel_class, r.promo_id,promo_name,promo_subcategory, s.amount_sold, s.quantity_sold FROM sales s,times t,products p,channels x,customers c,promotions r WHERE t.time_id (+) = s.time_id AND p.prod_id (+) = s.prod_id AND x.channel_id (+) = s.channel_id AND c.cust_id (+) = s.cust_id AND r.promo_id (+) = s.promo_id CREATE OR REPLACE FORCE VIEW v_sales_outer_ansi AS SELECT t.time_id,day_name,day_number_in_week, p.prod_id,prod_name,prod_desc,prod_subcategory, c.cust_id,cust_first_name,cust_last_name, x.channel_id,channel_desc,channel_class, r.promo_id,promo_name,promo_subcategory, s.amount_sold, s.quantity_sold FROM sales s LEFT OUTER JOIN times t ON t.time_id=s.time_id LEFT OUTER JOIN products p ON p.prod_id=s.prod_id LEFT OUTER JOIN channels x ON x.channel_id=s.channel_id LEFT OUTER JOIN customers c ON c.cust_id=s.cust_id LEFT OUTER JOIN promotions r ON r.promo_id=s.promo_id StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 23

24 Bei View mit OUTER JOINs sieht der Ausführungsplan genauso aus wie bei der optimalen Abfrage View OUTER: Ausführungsplan Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 645 (100) 1 SORT ORDER BY K 645 (17) 00:00:08 2 HASH GROUP BY K 645 (17) 00:00:08 * 3 HASH JOIN RIGHT OUTER 918K 63M 562 (5) 00:00:07 4 TABLE ACCESS FULL TIMES (0) 00:00:01 * 5 HASH JOIN RIGHT OUTER 918K 45M 539 (4) 00:00:07 6 TABLE ACCESS FULL PRODUCTS (0) 00:00:01 7 PARTITION RANGE ALL 918K 14M 531 (3) 00:00: TABLE ACCESS FULL SALES 918K 14M 531 (3) 00:00: Mit OUTER JOINs erreichen wir den gewünschten Effekt StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 24

25 3 Abfrage mit Partition Pruning

26 Die einfache Abfrage wird um eine WHERE-Bedingung erweitert, welche durch den Oracle Cost-Based Optimizer (CBO) für Partition Pruning verwendet wird Abfrage mit Partition Pruning SELECT calendar_year, calendar_month_name, prod_category, prod_subcategory, SUM(amount_sold) as amount_sold FROM sales s JOIN times t ON t.time_id=s.time_id JOIN products p ON p.prod_id=s.prod_id WHERE calendar_year = 2001 AND calendar_month_name = 'April' GROUP BY calendar_year, calendar_month_name, prod_category, prod_subcategory ORDER BY calendar_year, calendar_month_name, prod_category, prod_subcategory SELECT calendar_year, calendar_month_name, prod_category, prod_subcategory, SUM(amount_sold) as amount_sold FROM <view> WHERE calendar_year = 2001 AND calendar_month_name = 'April' GROUP BY calendar_year, calendar_month_name, prod_category, prod_subcategory ORDER BY calendar_year, calendar_month_name, prod_category, prod_subcategory StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 26

27 Bei Partition Pruning wird die Abfrage nur für die Partitionen, welche für die WHERE- Bedingung relevant sind, ausgeführt. Was ist Partition Pruning? Tabelle SH.SALES von bis Partition SALES_1995 MIN Partition SALES_ Partition SALES_H1_ Partition SALES_H2_ Partition SALES_Q1_ Partition SALES_Q2_ Partition SALES_Q4_ StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 27

28 Die Abfrage aus dem BI Tool profitiert vom Bitmap Index und von der Einschränkung auf die ausgewählte Partition Optimale Abfrage: Ausführungsplan Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 243 (100) 1 SORT ORDER BY (2) 00:00:03 2 HASH GROUP BY (2) 00:00:03 * 3 HASH JOIN K 240 (1) 00:00:03 4 TABLE ACCESS FULL PRODUCTS (0) 00:00:01 5 NESTED LOOPS 6 NESTED LOOPS K 236 (0) 00:00:03 * 7 TABLE ACCESS FULL TIMES (0) 00:00:01 8 PARTITION RANGE ITERATOR KEY KEY 9 BITMAP CONVERSION TO ROWIDS * 10 BITMAP INDEX SINGLE VALUE SALES_TIME_BIX KEY KEY 11 TABLE ACCESS BY LOCAL INDEX ROWID SALES (0) 00:00: Partition Pruning wird verwendet StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 28

29 Das erste View kann Bitmap Index verwenden und auch Partition Pruning funktioniert, die Schwächen dieses Ansatzes bleiben aber erhalten View INNER: Ausführungsplan mit Partition Pruning Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 245 (100) 1 SORT ORDER BY (3) 00:00:03 2 HASH GROUP BY (3) 00:00:03 3 NESTED LOOPS (3) 00:00:03 4 VIEW VW_GBC_ (3) 00:00:03 5 HASH GROUP BY (3) 00:00:03 6 NESTED LOOPS K 243 (2) 00:00:03 * 7 HASH JOIN K 241 (1) 00:00:03 8 TABLE ACCESS FULL PRODUCTS (0) 00:00:01 9 NESTED LOOPS K 237 (1) 00:00:03 10 NESTED LOOPS K 236 (0) 00:00:03 * 11 TABLE ACCESS FULL TIMES (0) 00:00:01 12 PARTITION RANGE ITERATOR (0) 00:00:03 KEY KEY 13 TABLE ACCESS BY LOCAL INDEX ROWID SALES (0) 00:00:03 KEY KEY 14 BITMAP CONVERSION TO ROWIDS * 15 BITMAP INDEX SINGLE VALUE SALES_TIME_BIX KEY KEY * 16 INDEX UNIQUE SCAN CHANNELS_PK (0) * 17 INDEX UNIQUE SCAN CUSTOMERS_PK (0) * 18 INDEX UNIQUE SCAN PROMO_PK (0) Partition Pruning wird verwendet StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 29

30 Die Views können weder von Bitmap Indizes noch von Partition Pruning profitieren View SUBSELECT: Ausführungsplan mit Partition Pruning Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 613 (100) 1 TABLE ACCESS BY INDEX ROWID TIMES (0) 00:00:01 * 2 INDEX UNIQUE SCAN TIMES_PK 1 1 (0) 00:00:01 3 TABLE ACCESS BY INDEX ROWID TIMES (0) 00:00:01 * 4 INDEX UNIQUE SCAN TIMES_PK 1 1 (0) 00:00:01 5 TABLE ACCESS BY INDEX ROWID PRODUCTS (0) 00:00:01 * 6 INDEX UNIQUE SCAN PRODUCTS_PK 1 0 (0) 7 TABLE ACCESS BY INDEX ROWID PRODUCTS (0) 00:00:01 * 8 INDEX UNIQUE SCAN PRODUCTS_PK 1 0 (0) 9 SORT ORDER BY 918K 75M 613 (16) 00:00:08 10 HASH GROUP BY 918K 75M 613 (16) 00:00:08 11 PARTITION RANGE ALL 918K 75M 531 (3) 00:00: * 12 VIEW V_SALES_SUBSEL 918K 75M 531 (3) 00:00:07 13 TABLE ACCESS FULL SALES 918K 14M 531 (3) 00:00: Das Gleiche gilt auch für andere Views mit Unterabfragen, die Weiterreichung der Einschränkungen aus der WHERE-Bedingung verhindert wird Kein Partition Pruning bei Unterabfragen StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 30

31 Das View mit OUTER JOINs kann Bitmap Index verwenden und auch Partition Pruning wird unterstützt View OUTER: Ausführungsplan mit Partition Pruning Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 243 (100) 1 SORT ORDER BY (2) 00:00:03 2 HASH GROUP BY (2) 00:00:03 * 3 HASH JOIN RIGHT OUTER K 240 (1) 00:00:03 4 TABLE ACCESS FULL PRODUCTS (0) 00:00:01 5 NESTED LOOPS 6 NESTED LOOPS K 236 (0) 00:00:03 * 7 TABLE ACCESS FULL TIMES (0) 00:00:01 8 PARTITION RANGE ITERATOR KEY KEY 9 BITMAP CONVERSION TO ROWIDS * 10 BITMAP INDEX SINGLE VALUE SALES_TIME_BIX KEY KEY 11 TABLE ACCESS BY LOCAL INDEX ROWID SALES (0) 00:00: Partition Pruning wird verwendet StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 31

32 4 Abfrage mit Query Rewrite

33 Das Materialzed View unterstützt durch die Verwendung von ID-Spalten alle Abfragen mit Dimensionstabellen TIMES und CUSTOMERS Materialized View anlegen DROP MATERIALIZED VIEW mv_sales / CREATE MATERIALIZED VIEW mv_sales AS SELECT time_id, cust_id, sum(amount_sold) AS sum_amount_sold, count(amount_sold) AS c_amount_sold, count(*) FROM sales GROUP BY time_id, cust_id / ALTER MATERIALIZED VIEW mv_sales ENABLE QUERY REWRITE / SH.SALES 128 MB SH.MV_SALES 5 MB StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 33

34 Die Abfrage wird diesmal die Dimensionstabelle CUSTOMERS verwenden, für welche ein Materialized View angelegt wurde Abfrage mit Query Rewrite SELECT calendar_year, calendar_month_name, c.cust_city, SUM(amount_sold) as amount_sold FROM sales s JOIN times t ON t.time_id=s.time_id JOIN customers c ON c.cust_id = s.cust_id GROUP BY calendar_year, calendar_month_name, c.cust_city ORDER BY calendar_year, calendar_month_name, c.cust_city SELECT calendar_year, calendar_month_name, cust_city, SUM(amount_sold) as amount_sold FROM <view> GROUP BY calendar_year, calendar_month_name, cust_city ORDER BY calendar_year, calendar_month_name, cust_city SELECT calendar_year, calendar_month_name, cust_city, SUM(sum_amount_sold) as amount_sold FROM mv_sales s JOIN times t ON t.time_id=s.time_id JOIN customers c ON c.cust_id = s.cust_id GROUP BY calendar_year, calendar_month_name, cust_city ORDER BY calendar_year, calendar_month_name, cust_city StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 34

35 Dynamische SQL Abfrage unterstützt Query Rewrite. Abfrage: Ausführungsplan mit Query Rewrite Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT 228 (100) 1 SORT ORDER BY (5) 00:00:03 2 HASH GROUP BY (5) 00:00:03 3 NESTED LOOPS 4 NESTED LOOPS (4) 00:00:03 5 VIEW VW_GBC_ (5) 00:00:03 6 HASH GROUP BY (5) 00:00:03 * 7 HASH JOIN 145K 7822K 177 (2) 00:00:03 8 TABLE ACCESS FULL TIMES (0) 00:00:01 9 MAT_VIEW REWRITE ACCESS FULL MV_SALES 145K 4977K 158 (2) 00:00:02 * 10 INDEX UNIQUE SCAN CUSTOMERS_PK 1 0 (0) 11 TABLE ACCESS BY INDEX ROWID CUSTOMERS (0) 00:00: Query Rewrite funktioniert StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 35

36 Das View mit INNER JOINs unterstützt Query Rewrite nicht View INNER: Ausführungsplan mit Query Rewrite Id Operation Name Rows Bytes TempSpc Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 7098 (100) 1 SORT ORDER BY K 7098 (2) 00:01:26 2 HASH GROUP BY K 7098 (2) 00:01:26 * 3 HASH JOIN K 7092 (2) 00:01:26 4 INDEX FULL SCAN CHANNELS_PK (0) 00:00:01 5 VIEW VW_GBC_ K 7091 (2) 00:01:26 6 HASH GROUP BY K 70M 7091 (2) 00:01:26 * 7 HASH JOIN 918K 63M 977 (4) 00:00:12 8 TABLE ACCESS FULL CUSTOMERS K 405 (1) 00:00:05 * 9 HASH JOIN 918K 49M 566 (5) 00:00:07 10 PART JOIN FILTER CREATE :BF (0) 00:00:01 11 TABLE ACCESS FULL TIMES (0) 00:00:01 * 12 HASH JOIN 918K 32M 543 (5) 00:00:07 13 INDEX FULL SCAN PROMO_PK (0) 00:00:01 * 14 HASH JOIN 918K 28M 537 (4) 00:00:07 15 INDEX FULL SCAN PRODUCTS_PK (0) 00:00:01 16 PARTITION RANGE JOIN-FILTER 918K 25M 531 (3) 00:00:07 :BF0000 :BF TABLE ACCESS FULL SALES 918K 25M 531 (3) 00:00:07 :BF0000 :BF Weil alle Dimensionstabellen wegen INNER JOIN immer bei der Ausführung verwendet werden müssen, kann die Abfrage nicht auf MView umgeleitet werden Kein Query Rewrite mit INNER JOIN StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 36

37 View mit OUTER JOINs kann auch von Query Rewrite profitieren. View OUTER: Ausführungsplan mit Query Rewrite Id Operation Name Rows Bytes TempSpc Cost (%CPU) Time SELECT STATEMENT 2681 (100) 1 SORT ORDER BY K 11M 2681 (1) 00:00:33 2 HASH GROUP BY K 11M 2681 (1) 00:00:33 * 3 HASH JOIN RIGHT OUTER 145K 9955K 584 (2) 00:00:08 4 TABLE ACCESS FULL CUSTOMERS K 405 (1) 00:00:05 * 5 HASH JOIN RIGHT OUTER 145K 7822K 177 (2) 00:00:03 6 TABLE ACCESS FULL TIMES (0) 00:00:01 7 MAT_VIEW REWRITE ACCESS FULL MV_SALES 145K 4977K 158 (2) 00:00: Durch die Verwendung von OUTER JOIN ist auch Query Rewrite möglich Query Rewrite funktioniert mit OUTER JOIN StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 37

38 5 Abfrage mit Row-Level Security

39 Die Policy-Funktion erlaubt nur den Benutzern SH und SCOTT auf die Daten der Tabelle zuzugreifen. Benutzer SH hat Zugriff auf alle Zeilen, SCOTT nur auf Direct Channels. Row-Level Security Policy anlegen CREATE OR REPLACE FUNCTION f_channels_rls ( p_schema IN VARCHAR2, p_table_name IN VARCHAR2 ) RETURN varchar2 IS BEGIN IF user='sh' THEN RETURN NULL; ELSIF user='scott' THEN RETURN q'[channel_class='direct']'; ELSE RETURN '1=0'; END IF; END; / BEGIN DBMS_RLS.ADD_POLICY( object_schema => 'SH', object_name => 'CHANNELS', policy_name => 'RLS_CHANNELS_CLASS', function_schema => 'SH', policy_function => 'F_CHANNELS_RLS'); END; / StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 39

40 Nur Anwender SH und SCOTT haben Zugriff auf die Daten in der Tabelle SH.CHANNELS, wobei SH den Vollzugriff hat, SCOTT sieht nur eingeschränkte Daten Row-Level Security Policy prüfen CONNECT sh/***** select * from channels; CHANNEL_ID CHANNEL_DESC CHANNEL_CLASS CHANNEL_CLASS_ID CHANNEL_TOTAL CHANNEL_TOTAL_ID Direct Sales Direct 12 Channel total 1 9 Tele Sales Direct 12 Channel total 1 5 Catalog Indirect 13 Channel total 1 4 Internet Indirect 13 Channel total 1 2 Partners Others 14 Channel total 1 5 row(s) selected. CONNECT scott/***** select * from sh.channels; CHANNEL_ID CHANNEL_DESC CHANNEL_CLASS CHANNEL_CLASS_ID CHANNEL_TOTAL CHANNEL_TOTAL_ID Direct Sales Direct 12 Channel total 1 9 Tele Sales Direct 12 Channel total 1 2 row(s) selected. StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 40

41 Die Abfrage wird diesmal die Dimensionstabelle CHANNELS verwenden, für welche eine Row-Level Security Policy angelegt wurde Abfrage mit Row-Level Security SELECT calendar_year, calendar_month_name, x.channel_class, SUM(amount_sold) as amount_sold FROM sales s JOIN times t ON t.time_id=s.time_id JOIN channels x ON x.channel_id = s.channel_id GROUP BY calendar_year, calendar_month_name, x.channel_class ORDER BY calendar_year, calendar_month_name, x.channel_class SELECT calendar_year, calendar_month_name, channel_class, SUM(amount_sold) as amount_sold FROM <view> GROUP BY calendar_year, calendar_month_name, channel_class ORDER BY calendar_year, calendar_month_name, channel_class StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 41

42 SH kann alle Daten in der Dimensionstabelle CHANNELS sehen, deswegen liefert die Abfrage drei Zeilen pro Monat. SH: Ausführungsplan mit RLS Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 600 (100) 1 SORT ORDER BY (11) 00:00:08 2 HASH GROUP BY (11) 00:00:08 3 MERGE JOIN (11) 00:00:08 4 TABLE ACCESS BY INDEX ROWID CHANNELS (0) 00:00:01 5 INDEX FULL SCAN CHANNELS_PK 5 1 (0) 00:00:01 * 6 SORT JOIN (11) 00:00:08 7 VIEW VW_GBC_ (10) 00:00:08 8 HASH GROUP BY (10) 00:00:08 * 9 HASH JOIN 918K 31M 554 (4) 00:00:07 10 PART JOIN FILTER CREATE :BF (0) 00:00:01 11 TABLE ACCESS FULL TIMES (0) 00:00:01 12 PARTITION RANGE JOIN-FILTER 918K 14M 531 (3) 00:00:07 :BF0000 :BF TABLE ACCESS FULL SALES 918K 14M 531 (3) 00:00:07 :BF0000 :BF CALENDAR_YEAR CALENDAR_MONTH CHANNEL_CLASS AMOUNT_SOLD April Direct , April Indirect , April Others , August Direct , December Direct , February Direct StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 42

43 SCOTT kann nur eingeschränkte Daten aus der Dimensionstabelle CHANNELS lesen, deswegen liefert die Abfrage nur eine Zeilen pro Monat. SCOTT: Ausführungsplan mit RLS Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 576 (100) 1 SORT ORDER BY (7) 00:00:07 2 HASH GROUP BY (7) 00:00:07 * 3 HASH JOIN (7) 00:00:07 4 VIEW VW_GBC_ (7) 00:00:07 5 HASH GROUP BY (7) 00:00:07 * 6 HASH JOIN 382K 9M 539 (4) 00:00:07 * 7 TABLE ACCESS FULL CHANNELS (0) 00:00:01 8 PARTITION RANGE ALL 918K 14M 531 (3) 00:00: TABLE ACCESS FULL SALES 918K 14M 531 (3) 00:00: TABLE ACCESS FULL TIMES (0) 00:00: CALENDAR_YEAR CALENDAR_MONTH CHANNEL_CLASS AMOUNT_SOLD April Direct , August Direct , December Direct , February Direct StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 43

44 Das View mit INNER JOIN liefert die gleichen Ergebnisse, wie die optimale Abfrage. Die Nachteile bleiben. SCOTT und INNER: Ausführungsplan mit RLS Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 615 (100) 1 SORT ORDER BY (13) 00:00:08 2 HASH GROUP BY (13) 00:00:08 3 NESTED LOOPS (12) 00:00:08 4 VIEW VW_GBC_ (12) 00:00:08 5 HASH GROUP BY (12) 00:00:08 6 NESTED LOOPS 382K 25M 597 (10) 00:00:08 * 7 HASH JOIN 382K 23M 561 (4) 00:00:07 8 PART JOIN FILTER CREATE :BF (0) 00:00:01 9 TABLE ACCESS FULL TIMES (0) 00:00:01 * 10 HASH JOIN 382K 16M 541 (4) 00:00:07 11 MERGE JOIN CARTESIAN (0) 00:00:01 * 12 TABLE ACCESS FULL CHANNELS (0) 00:00:01 13 BUFFER SORT (0) 00:00:01 14 INDEX FAST FULL SCAN PRODUCTS_PK (0) 00:00:01 15 PARTITION RANGE JOIN-FILTER 918K 25M 531 (3) 00:00:07 :BF0000 :BF0000 CALENDAR_YEAR CALENDAR_MONTH CHANNEL_CLASS AMOUNT_SOLD 16 TABLE ACCESS FULL SALES 918K 25M 531 (3) 00:00:07 :BF0000 :BF * 17 INDEX UNIQUE SCAN CUSTOMERS_PK (0) 1998 April Direct ,93 * 18 INDEX UNIQUE SCAN PROMO_PK (0) 1998 August Direct , December Direct , February Direct StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 44

45 Das View mit OUTER liefert zu viele Datensätze zurück, oder? SCOTT und OUTER: Ausführungsplan mit RLS Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop SELECT STATEMENT 645 (100) 1 SORT ORDER BY (17) 00:00:08 2 HASH GROUP BY (17) 00:00:08 * 3 HASH JOIN RIGHT OUTER 918K 41M 562 (5) 00:00:07 4 TABLE ACCESS FULL TIMES (0) 00:00:01 * 5 HASH JOIN RIGHT OUTER 918K 23M 539 (4) 00:00:07 * 6 TABLE ACCESS FULL CHANNELS (0) 00:00:01 7 PARTITION RANGE ALL 918K 14M 531 (3) 00:00: TABLE ACCESS FULL SALES 918K 14M 531 (3) 00:00: CALENDAR_YEAR CALENDAR_MONTH CHANNEL_CLASS AMOUNT_SOLD April Direct , April (null) , August Direct , August (null) , December Direct , December (null) , February Direct February (null) ,87 StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 45

46 Bei OUTER JOIN werden alle Zeilen aus der Faktentabelle gelesen, und wenn durch RLS keine Zeilen in der Dimensionstabelle gefunden wird, werden NULL Werte benutzt. Was passiert bei OUTER JOIN und RLS? SH CALENDAR_YEAR CALENDAR_MONTH CHANNEL_CLASS AMOUNT_SOLD April Direct , April Indirect , April Others , August Direct , December Direct , February Direct , , , = ,37 SCOTT mit OUTER JOIN CALENDAR_YEAR CALENDAR_MONTH CHANNEL_CLASS AMOUNT_SOLD April Direct , April (null) , August Direct , August (null) , December Direct , December (null) , February Direct February (null) ,87 StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 46

47 Der INNER JOIN führt zu Einschränkungen in allen Auswertungen, beim OUTER JOIN wird immer die Gesamtsumme abgefragt RLS: Gesamtsumme oder Einschränkungen CONNECT scott/***** SELECT SUM(amount_sold) as amount_sold FROM sh.sales s ; AMOUNT_SOLD ,21 SELECT SUM(amount_sold) as amount_sold FROM sh.v_sales_inner ; AMOUNT_SOLD ,86 SELECT SUM(amount_sold) as amount_sold FROM sh.v_sales_outer ; AMOUNT_SOLD ,21 CONNECT scott/***** SELECT channel_class, SUM(amount_sold) as amount_sold FROM sh.sales s JOIN sh.channels x ON x.channel_id=s.channel_id GROUP BY channel_class ; CHANNEL_CLASS AMOUNT_SOLD Direct ,86 SELECT channel_class, SUM(amount_sold) as amount_sold FROM sh.v_sales_inner GROUP BY channel_class ; CHANNEL_CLASS AMOUNT_SOLD Direct ,86 SELECT SUM(amount_sold) as amount_sold FROM sh.v_sales_outer GROUP BY channel_class ; CHANNEL_CLASS AMOUNT_SOLD Direct ,86 (null) ,35 StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 47

48 BI Tools können das Problem mit Hilfe von SQL Generierung lösen, indem die geschützte Tabelle immer in der Abfrage benutzt wird BI Tool: Einschränkungen oder Gesamtsumme CONNECT scott/***** SELECT SUM(amount_sold) as amount_sold FROM sh.sales s JOIN sh.channels x ON x.channel_id=s.channel_id ; AMOUNT_SOLD ,86 SELECT channel_class, SUM(amount_sold) as amount_sold FROM sh.sales s JOIN sh.channels x ON x.channel_id=s.channel_id GROUP BY channel_class ; CHANNEL_CLASS AMOUNT_SOLD Direct ,86 CONNECT scott/***** SELECT SUM(amount_sold) as amount_sold FROM sh.sales s LEFT OUTER JOIN sh.channels x ON x.channel_id=s.channel_id ; AMOUNT_SOLD ,21 SELECT channel_class, SUM(amount_sold) as amount_sold FROM sh.sales s LEFT OUTER JOIN sh.channels x ON x.channel_id=s.channel_id GROUP BY channel_class ; CHANNEL_CLASS AMOUNT_SOLD Direct ,86 (null) ,35 StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 48

49 6 Fazit

50 Das View 5 scheint in den meisten Fällen die besten Ergebnisse zu liefern. Aber View 1 wird auch benötigt, wenn RLS im Starschema benutzt wurde. consectetur Auswertung adipisici View einfache Abfrage Partition Pruning Query Rewrite RLS View 1: INNER JOIN View 2: Unterabfrage pro Spalte - View 3: Unterabfrage pro Tabelle - View 4: Typ OBJECT - View 5: OUTER JOIN (*) (*) mit Einschränkungen Sollten wir immer im StarView die OUTER JOINs benutzen? StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 50

51 Mit folgenden Regeln lässt sich ein funktionierendes StarView über ein Starschema erstellen. Regelwerk für StarView Row-Level Security mit Einschränkung INNER JOIN Row-Level Security mit Gesamtsumme OUTER JOIN Fremdschlüssel der Dimensionstabelle ist Partitionsschlüssel OUTER JOIN (evtl. INNER JOIN) Dimension nicht in allen Materialized Views verwendet OUTER JOIN sonst OUTER JOIN oder INNER JOIN StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 51

52 Und so sieht unser StarView aus. Es unterstützt alle untersuchten Szenarien und liefert eine Performanz, welche mit dynamischen SQL vergleichbar ist. StarView CREATE OR REPLACE FORCE VIEW v_sales AS SELECT t.time_id,day_name,day_number_in_week, p.prod_id,prod_name,prod_desc,prod_subcategory, c.cust_id,cust_first_name,cust_last_name, x.channel_id,channel_desc,channel_class, r.promo_id,promo_name,promo_subcategory, s.amount_sold, s.quantity_sold FROM sales s INNER JOIN times t ON t.time_id=s.time_id LEFT OUTER JOIN products p ON p.prod_id=s.prod_id INNER JOIN channels x ON x.channel_id=s.channel_id LEFT OUTER JOIN customers c ON c.cust_id=s.cust_id LEFT OUTER JOIN promotions r ON r.promo_id=s.promo_id StarView: mit statischem SQL dynamische Abfragen auf StarSchema Seite 52

53 Interesse? Fragen? Austausch? Treffen Sie uns an unserem Stand und gewinnen Sie eine Hadoop-Schulung!

54 Vielen Dank für Ihre Aufmerksamkeit! metafinanz Informationssysteme GmbH Leopoldstraße 146 D München Phone: Fax: DWH & Hadoop Expertise Besuchen Sie uns auch auf: