Star - Schema. AnPr. Name Klasse Datum. ANPR_StarSchema_v03.docx Seite 1

Transkript

1 Name Klasse Datum 1 OLAP vs. OLTP In den RDBMS Konfigurationen unterscheidet man zwei verschiedene Grundtypen: OLTP: OnLine Transactional Processing ist für die Transaktionsprozesse und somit zur funktionalen Abbildung bzw. Unterstützung der eigentlichen Geschäftsprozesse gedacht. Hier finden wir folgende grundlegende Eigenschaften wieder: Redundanzfreie Abbildung aller Daten im Datenmodell Sehr hohe Ausfallsicherheit (meistens durch gespiegelte Systeme) Viele User und Transaktionen werden unterstützt OLAP: OnLine Analytical Processing ist für die Gewinnung von Erkenntnissen aus den Daten konzipiert. Es greifen im Regelfall keine direkten Interfaces auf die OLAP Datenbanken zu, welche direkt wieder den Geschäftsprozess beeinflussen. Wir finden bei OLAP folgende Eigenschaften: Unterstützung von Entscheidungen (mittels Analysetools, Dashboards etc.) Abfrageoptimierte Abbildung relevanter Daten Sehr hoher Speicherbedarf Wenige User und Transaktionen OLAP Datenbanken finden wir im Regelfall in sogenannten Datamarts, in denen große Mengen an Informationen für Analysezwecke bereitgehalten werden. Das Hauptproblem der OLTP Architekturen ist die Vermeidung von Redundanzen und die damit einhergehende Notwendigkeit von Joins für fachlich relevante Abfragen. Diese Joins können bei intensiveren Datenanalysen zu erheblichen Performanceeinbußen führen, wodurch die OLTP Datenbanken mitunter für schnelle Datenanalysen nicht mehr zu gebrauchen sind. 2 Der Weg der Daten Die Datenwahrheit bleibt in dem OLTP Datenbanken, da hier die Geschäftsprozesse laufen. Von dort aus werden sie mittels eines ETL Prozesses (Extract Transfer Load) in die gewünschte Form gebracht. Hierbei werden die ursprünglichen Daten nicht verändert, sondern in eine neue Datenbank kopiert. Mitunter werden in den Analysedatenbanken historische Informationen benötigt, welche zeitlich weiter zurückgreifen, als es die OLTP Datenbanken ermöglichen. Hierbei werden teilweise auch Zwischenschritte eingebaut, um eine saubere Historie zu ermöglichen. Meist wird bereits eine Veränderung der Daten in Richtung ANPR_StarSchema_v03.docx Seite 1

2 Zwischenstatus durchgeführt man geht von den quellsystemgetriebenen Datenmodell hin zu einem fachlich getriebenen Datenmodell ( Corporate Data Model ) hin, welches auch historisch vorliegt. Man bezeichnet diese Datenhaltung meist als Datawarehouse, kurz DWH. Von dort werden die Daten in die analyseoptimierte Struktur, dem Datamart weitergeleitet. Ziel ist es am Ende aber immer, die Daten derart bereitzustellen, dass Analysen möglichst einfach und vor allem schnell zu ermöglichen. 3 Das Star Schema Üblicherweise werden in Schemabilder die Analyseplattformen als Würfel ( Cubes ) dargestellt. Dies soll das Grundkonzept der Analysen verdeutlichen. Im Regelfall ist man an Geschäftszahlen interessiert(wie bspw. Sales ). Diese müssen nun nach gewissen Gesichtspunkten zusammengefasst werden. Diese Gesichtspunkte können bspw. die Zeit sein also Wie viel Sales wurde im ersten Quartal 2014 gemacht?. Eine andere benötigte Information ist Welcher Betreuer hat am meisten verkauft?. Diese Sichtweisen kann man sich als Dimensionen vorstellen. Wenn man sich nun die Informationen in drei Dimensionen aufteilt sagen wir Betreuer, Kunde und Datum, dann würde dies wie ein Würfel aussehen, der aus vielen kleinen Einzelwürfeln besteht. Jeder Einzelwürfel trägt die Information des Salesbetrages zu der zugehörigen Zeit, dem Betreuer und dem Kunden. Nun kann man in den drei verschiedenen Dimensionen Summen bilden und könnte somit verschiedene Aspekte des Sales analysieren. In der Realität gibt es natürlich mehr als nur drei Dimensionen, da wir auch nach Branchen, Personen usw. gruppieren möchten. Da dies aber grafisch nicht darstellbar ist, beschränkt man sich bei Erklärungen meist auf drei Dimensionen. Die tatsächliche Abbildung auf der Datenbank erfolgt im sogenannten Star Schema, in dem die Faktentabelle im Zentrum steht und die Dimensionstabellen wie Sternenarme außen herum geordnet sind. Die Schlüssel der Dimensionen bilden wiederum den kombinierten Schlüssel der Faktentabelle. In den Dimensionstabellen stehen Werte und Eigenschaften, welche für die Spätere Auswertung und Einschätzung interessant sind, wie bspw. Kundennamen oder Rechtsformen. Die Faktentabelle trägt (neben den Schlüsseln) lediglich die Betragsfelder, welche den eigentlichen Kern der Analyse darstellen. Wie man bereits sieht, ist das Star Schema immer auf einen bestimmten Analysebereich ausgerichtet. Die Anforderungen für ein solches Datenmodell kommen also von den Personen, welche Auswertungen durchführen müssen, nicht von den Systemen, welche die Daten bereitstellen. Eine leicht veränderte Version des Star Schemas ist das sogenannte Snowflake Schema. Dieses berücksichtigt, dass es Dimensionen gibt, die direkt voneinander abhängen. So würde man im Snowflake Schema die Branche nicht am Fakt Sales hängen, sondern an die Dimensionstabelle der Firma, da eine Firma in unserem Quelldatenmodell immer einer bestimmten Branche zugeordnet ist. Dies hat den Vorteil, dass weniger Redundanzen entstehen, allerdings den Nachteil, dass wieder mehr Joins notwendig werden. In der Praxis gilt es noch zusätzliche Probleme zu meistern. Ein Beispiel wären die Slowly Changing Dimensions. Dies sind Änderungen in den Dimensionen wenn bspw. für einen Kunden der Betreuer wechselt. Hier müssen die Änderungen dergestalt in den Datenhaushalt eingebaut werden, dass der Auswertende sinnvolle Ergebnisse erhält. Dies bedeutet, dass es für einen Betreuerwechsel je nach Auswertungsnotwendigkeit unterschiedliche Lösungsansätze gibt. Da dies jedoch den Inhalt sprengen würde, sei hier auf das Internet verwiesen. Seite 2

3 Star - Schema 4 Aufgabenstellung Um das Ganze praktisch zu untermauern, soll nun ein Star Schema erstellt und bewirtschaftet werden. Als Datenbasis für das im vorausgegangenen Kapitel bereits vorgestellte Schema die nebenstehenden Tabellen. Wie wir schon erahnen können, wird das Umstellen auf ein Star Schema nicht sehr viel bringen, da die Datenbasis vergleichsweise einfach aufgebaut ist. Trotzdem wird ein Performancegewinn bei den Abfragen zu erwarten sein. 4.1 Die Dimensionstabellen Da die Faktentabelle die Schlüssel aus den Dimensionstabellen bezieht, beginnen wir mit den Dimensionstabellen. Tabelle DimPartner: PartnerID INT (Primary 1:1 aus Partner. PrimAnsprechpersonName VARCHAR(60) Nachname + Vorname aus Tabelle Person. Bei Firmen: erste. auffindbare Person der Firma (also Primärer Ansprechpartner). Bei Privatkunden: Person. PrimGeschl CHAR(1) Aus Person (Datensatzauswahl siehe oben) Tabelle DimBetreuer: BetreuerID INT (Primary 1:1 aus Partner.BetreuerID. Name VARCHAR(60) Nachname + Vorname aus Tabelle Person Geschl CHAR(1) Aus Person (Datensatzauswahl siehe oben) Tabelle DimFirma: FirmaID INT (Primary Bei Firmen 1:1 aus Firma. Bei Privatkunden Wert -1 Name VARCHAR(100) Bei Firmen 1:1 aus Firma. Bei Privatkunden Wert Privatkunde RechtsForm CHAR(5) Bei Firmen 1:1 aus Firma. Bei Privatkunden Wert PRV Tabelle DimBranche: BrancheID INT (Primary Bei Firmen 1:1 aus Branche. Bei Privatkunden Wert - 1 Bezeichnung VARCHAR(100) Bei Firmen 1:1 aus Branche. Bei Privatkunden Wert Privatkunden Seite 3

4 Tabelle DimDatum: Die Datumstabelle ist eine besondere Tabelle, da die Daten für die Auswertungszwecke speziell aus dem Datumswert erzeugt werden. Auch werden die Keys eigens für das Star Schema erstellt: DatumID INT (Primary AUTO INCREMENT Datum DATE 1:1 aus Bestellung Tag TINYINT Errechnet aus Datum Wochentag TINYINT Errechnet aus Datum Monat TINYINT Errechnet aus Datum Quartal TINYINT Errechnet aus Datum Jahr SMALLINT Errechnet aus Datum 4.2 Die Faktentabelle Basierend auf den Dimensionkeys kann nun die Faktentabelle definiert werden: Tabelle FctSales: DatumID INT (Primary DimDatum PartnerID INT (Primary DimPartner BetreuerID INT (Primary DimBetreuer BrancheID INT (Primary DimBrache FirmaID INT (Primary DimFirma Porto DECIMAL(7,2) Summe aus Bestellung BestBetrag DECIMAL(10,2) Summe Betrag aus Bestellung 4.3 Die Skripte Erstellen Sie nun ein Skript, welches die Datenbankstruktur bereitstellt. Anschließend ein Skript, welches die Daten aus dem existierenden HardWhere Datenmodell in das Star Datenmodell migriert. Hierzu reichen in unserem Fall normale SQL Mittel. Empfehlung: Bewirtschaften Sie zuerst die Dimensionstabellen, anschließend lediglich die Keys der Faktentabelle. Erst zum Schluss werden über ein Updatestatement die Faktenbeträge übernommen. Hilfestellung für Update aus einem Select: UPDATE Zieltabelle, ( SELECT z.keyfeld, q.wertefeld FROM Quelltabelle q, Zieltabelle z WHERE z.keyfeld = q.keyfeld) Quelle SET Zieltabelle.WerteFeld = Quelle.WerteFeld WHERE Zieltabelle.KeyFeld = Quelle.KeyFeld; Hier wird die Zieltabelle mittels SET geupdated. Die Daten kommen aus einer Quelltabelle und werden mittels einem Subselect ermittelt (dieses müssen Sie natürlich auf die Problemstellung anpassen). Seite 4

5 Star - Schema 5 Die Abfragen Für folgende Abfragen sollen Sie einmal über das Star Schema gehen und einmal die Informationen direkt aus dem Quelldatenmodell beziehen und jeweils die Performance notieren. Aufgabenstellung: Ergebnis: Zeit OLAP: Zeit OLTP: Quartal mit den meisten Umsätzen 4/2012 Betreuer mit den meisten Umsätzen Branche mit den meisten Umsätzen Der Betreuer, welcher in der Branche 132 im ersten Quartal 2009 den meisten Umsatz gemacht hat. Der Kunde, welcher den meisten Umsatz gemacht hat Der Kunde (Ansprechpartner), welcher im zweiten Quartal 2012 den meisten Umsatz gemacht hat. Becker Petra Gastronomie, Restaurants Becker Petra Riemer Josef Schneider Hildegard Seite 5

6 6 Lizenz Diese(s) Werk bzw. Inhalt von Maik Aicher ( steht unter einer Creative Commons Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz. Seite 6