DOAG SID Data Warehouse Star Schema Design

Was kostet ein Join? Einen zusätzlichen DB Block Read für den Index Driving Table Row 1 Row 2 Row 3 Row 4 Row 5 Row 6 Row 7 Row 8 … ... 032-040 030-031 07-16 03-06 00-02 041-069 rowid Index 0-1 Einen zusätzlichen DB Block Read für den Index Durchlaufen des B*Tree Baums Einen DB Block für die Daten Driven Table Row 1 Row 2 Row 3 ...

Was kostet ein Join… Es müssen zwei DB Blöcke gelesen werden Diese werden (hoffentlich) im Cache gehalten Speziell wenn die Driven Table klein ist liegt sie komplett im Cache Kein sequentielles Lesen möglich da Index und Tabelle getrennt voneinander liegen Aber selbst wenn alles im Cache liegt, ein Join kostet etwas (wenn auch nicht sooo viel) aber: wenn er nur 1ms pro Zeile kostet sind das 1,6 Minuten für 100 000 rows!

Ein Beispiel: Index plus Tabelle

Normalisiertes Datenmodell Account ID Name Customer ID ... Account ID Branch ID Date Revenue ... Customer ID Name Office ID ... Branch ID Name ... Office ID Name ... Reports benötigen viele Joins Updates und inserts sind schnell Eingabemasken können leicht gebaut werden Datenmodell ist komplex (viele Tabellen, weite Wege)

Abschätzungen Wie schätzt man die Effektivität eines Datenmodells? Über die Anzahl MByte die zu lesen sind Diese geben einen guten Anhaltspunkt, denn I/O ist für die Datenbank am teuersten Vernachlässigt dabei viele Faktoren, etwa Sequentielles lesen vs. Random Access oder Caching ja/nein, aber es ist Aufgabe der Datenbank die MByte möglichst effektiv zu lesen

Normalisiertes Datenmodell select the sum(Revenue) per Office Name and Branch Name Account ID Name Customer ID ... Customer ID Name Office ID ... Account ID Branch ID Date Revenue ... (10+190) Bytes * 1*106rows = 200*106 Bytes (7+293) Bytes * 100’000rows = 30*106 Bytes (10+4+7+69) Bytes *10*106rows = 900*106 Bytes Office ID Name ... Branch ID Name ... (2+38) Bytes * 100rows = 0.004*106 Bytes (4+116) Bytes * 8000rows = 0.96*106 Bytes

Normalisiertes Datenmodell select the sum(Revenue) per Office Name and Customer Name Account ID Name Customer ID ... Customer ID Name Office ID ... Account ID Branch ID Date Revenue ... Office ID Name ... 200*106 Bytes 30*106 Bytes Branch ID Name ... 0.004*106 Bytes 900*106 Bytes 0.96*106 Bytes Offices +0.004 * 106 Branches +0.960 * 106 Customers +30.000 * 106 Accounts +200.000 * 106 Orders +900.000 * 106 Offices Index 0MB Branches Index 0MB Customers Index 2MB Accounts Index 30MB + 1162MB to read =

Eine große Tabelle Wenn joins so teuer sind, legen wir doch alles in eine Tabelle Die Datenbank muss immer den kompletten Satz lesen Account ID Account Name ... Branch ID Branch Name Office Name Office ID Customer Name Customer ID Date Revenue +(4+10+7+69) for the Fact Data +190 for the Accounts Data +293 for the Customer Data +38 for the Office Data +116 for the Branch Data =727 Bytes 727 Bytes *10*106rows = 7270*106 Bytes 7 GByte müssen gelesen werden!!!

Star Schema Branch ID Branch Name Account ID Account Name Branch ID Account ID Customer ID Office ID Date Revenue Office ID Branch Name Customer ID Customer Name Ein geänderter Satz in der Quelle kann mehrere Sätze beeinflussen Nicht Sinnvoll für Eingabemasken Für Reports werden weniger Joins benötigt Datemodell ist einfacher zu verstehen Die zu lesende Datenmenge ist geringer Dafür werden zusätzliche Schlüssel in der großen Fact Tabelle benötigt

Star Schema select the sum(Revenue) per Office Name and Branch Name Account ID Account Name Branch ID Branch Name Branch ID Account ID Customer ID Office ID Date Revenue (10+190) Bytes * 1*106rows = 200*106 Bytes (4+116) Bytes * 8000rows = 0.96*106 Bytes Office ID Office Name (4+10+7+7+2 + 69) Bytes * 10*106 rows = 990*106 Bytes Customer ID Customer Name (2+38) Bytes * 100rows = 0.004*106 Bytes (7+293) Bytes * 100’000rows = 30*106 Bytes

Star Schema select the sum(Revenue) per Office Name and Branch Name Branch ID Branch Name Branch ID Account ID Customer ID Office ID Date Revenue Account ID Account Name 0.96*106 Bytes 200*106 Bytes Office ID Office Name Customer ID Customer Name 0.004*106 Bytes 990*106 Bytes 30*106 Bytes Offices +0.004 * 106 Branches +0.960 * 106 Orders +990.000 * 106 Offices Index 0MB Branches Index 0MB + 990MB to read =

Star Schema select the sum(Revenue) per Office Name and Branch Name Branch ID Branch Name Branch ID Account ID Office ID Date Revenue Account ID Account Name 0.96*106 Bytes Customer ID Customer Name Office ID Office Name 493*106 Bytes 0.004*106 Bytes 920*106 Bytes Offices +0.004 * 106 Branches +0.960 * 106 Orders +920.000 * 106 Offices Index 0MB Branches Index 0MB + 920MB to read =

Star Schema Principles Joining ist teuer, also vermeiden Eine große Tabelle ist – wie gezeigt - nicht sinnvoll Joining mit kleinen Dimensionstabellen ist optimal da im Cache besonders wenn Einschränkungen auf der kleinen Dimensionstabelle liegen!!! Dimensionstabelle einschränken bedeutet einen Full Table Scan durchzuführen, aber auf den paar Sätzen…

Star Schema mit where clause select the sum(Revenue) per Office Name and Branch Name where Office Name = “SFO” Branch ID Branch Name Account ID Account Name Branch ID Account ID Customer ID Office ID Date Revenue 0.96*106 Bytes 200*106 Bytes Office ID Office Name Customer ID Customer Name 0.004*106 Bytes 30*106 Bytes 90*106 Bytes for SFO Offices +0.004 * 106 Branches +0.960 * 106 Orders +90.000 * 106 + Fact Office Index 3MB = 93MB to read

Normalisiertes Datenmodell mit where clause select the sum(Revenue) per Office Name and Branch Name where Office Name = “SFO” Account ID Name Customer ID ... Customer ID Name Office ID ... Account ID Branch ID Date Revenue ... Office ID Name ... 200*106 Bytes 30*106 Bytes Branch ID Name ... 0.004*106 Bytes 90*106 Bytes for SFO 0.96*106 Bytes Offices +0.004 * 106 Branches +0.960 * 106 Customers +30.000 * 106 Accounts +200.000 * 106 Orders +90.000 * 106 Offices Index 0MB Branches Index 0MB Customers Index 2MB Accounts Index 30MB + 352MB to read =

Ein typischer Anwendungsfall Eine Dimensionstablle mit Millionen von Sätzen und ein paar Feldern die häufig benutzt werden Join von großen Tabellen ist besonders teuer Where-Bedingungen sowieso Man könnte diese in zwei Dimensionstabellen aufspalten z.B. eine Tabelle mit Name, Anschrift und eine mit Geschlecht, Status, Altersgruppe

Ein typischer Anwendungsfall Customer Table Customer ID First Name Last Name Street State Martial Status Age Rich/Poor Indicator Diese Felder werden nur für einen Kunden gefragt Diese Felder werden ständig benötigt DIM Customers Customer ID First Name Last Name Street actual State actual Martial Status actual Age actual Rich/Poor Indicator actual Class ID e.g. 10*106 rows Fact Date Customer ID Class ID Revenue DIM Customer Class Class ID State Martial Status Age Rich/Poor Indicator 10*106 rows 10 000 rows only

Ein typischer Anwendungsfall Savings [Byte] = Source [Byte] - Fact Rows * Key Width [Bytes] - Class Rows * (Class Width + Key Width)

Summary Star Schema ist der Kompromiss zwischen möglichst wenig joins notwendig und nicht alles in eine Tabelle stellen (nur zus. FKs) Die Effektivität kommt dann besonders zu tragen wenn die Dimensionen klein sind und daher ein Full Table Scan keine Zeit benötigt und die Dimensionstabelle komplett im Cache liegt (wird sowieso ständig gelesen)