Das Sternenschema

Berichte und Analysen sind heute fast so wichtig wie das Kerngeschäft. Berichte können aus Ihren Live-Daten erstellt werden; oft reicht dieser Ansatz für kleine und mittelständische Unternehmen ohne große Datenmengen aus. Aber wenn die Dinge größer werden – oder die Datenmenge dramatisch ansteigt – ist es an der Zeit, darüber nachzudenken, Ihre Betriebs- und Berichtssysteme zu trennen.

Bevor wir uns mit der grundlegenden Datenmodellierung befassen, benötigen wir einige Hintergrundinformationen zu den beteiligten Systemen. Wir können Systeme grob in zwei Kategorien einteilen:Betriebs- und Berichtssysteme. Betriebssysteme werden oft als Online Transaction Processing (OLTP) bezeichnet. Melde- und Analysesysteme werden als Online Analytical Processing (OLAP) bezeichnet. OLTP-Systeme unterstützen Geschäftsprozesse. Sie arbeiten mit „lebenden“ Betriebsdaten, sind stark normalisiert und reagieren sehr schnell auf Benutzeraktionen. Andererseits ist der Hauptzweck der OLAP-Systeme die Analyse. Diese Systeme verwenden zusammengefasste Daten, die normalerweise in einer denormalisierten Data-Warehousing-Struktur wie dem Sternschema platziert werden. (Was ist Denormalisierung? Einfach ausgedrückt:Redundante Datensätze für eine bessere Leistung. Lesen Sie mehr.)

Nachdem wir nun ein wenig über die Systeme wissen, beginnen wir mit der Untersuchung des Data Warehouse und seiner Teile und Prozesse.

Data Warehouses vs. Data Marts

Ein Data Warehouse (DWH) ist ein System zum Speichern von Informationen zur Verwendung bei der Datenanalyse und Berichterstellung. Datamarts sind Bereiche eines Data Warehouses, in denen Informationen gespeichert werden, die von einer einzelnen Abteilung oder sogar von einem einzelnen Benutzer benötigt werden. (Stellen Sie sich das DWH als Gebäude und Data Marts als Büros innerhalb des Gebäudes vor.)

Warum werden Data Marts benötigt? Alle relevanten Daten werden im Firmen-DWH gespeichert. Die meisten Benutzer müssen jedoch nur auf bestimmte Teilmengen von Daten zugreifen, beispielsweise zu Vertrieb, Produktion, Logistik oder Marketing. Data Marts sind sowohl aus Sicherheitssicht (Einschränkung unnötigen Zugriffs) als auch aus Benutzersicht wichtig (wir wollen sie nicht verwirren oder sie zwingen, sich durch irrelevante Daten zu wühlen).

Es gibt zwei verschiedene Ansätze für die Beziehung zwischen Data Warehouse und Data Mart:

• Von oben nach unten :Data Marts werden aus dem Data Warehouse erstellt. (Das ist etwas, dem Bill Inmon, der „Vater des Data Warehouse“, zustimmen würde, zusammen mit der Idee, dass Warehouses in 3NF enthalten sein sollten.)
• Bottom-Up :Data Marts werden zuerst erstellt und dann zu einem Data Warehouse kombiniert. (Dieser Ansatz kommt dem, was Ralph Kimball, ein Experte für Data Warehouses und dimensionale Modellierung, befürwortet, näher.)

Der ETL-Prozess wird verwendet, um dem OLAP-System regelmäßig „neue“ Daten hinzuzufügen. ETL ist die Abkürzung für Extrahieren, Transformieren und Laden. Wie der Name schon sagt, extrahieren wir Daten aus einer oder mehreren operativen Datenbanken, transformieren sie, um sie an unsere Warehouse-Struktur anzupassen, und laden die Daten in das DWH.

Dimensionsmodellierung , das Teil des Data-Warehouse-Designs ist, führt zur Erstellung des dimensionalen Modells. Es gibt zwei Arten von Tabellen:

• Maßtabellen werden verwendet, um die Daten zu beschreiben, die wir speichern möchten. Beispiel:Ein Einzelhändler möchte möglicherweise das Datum, das Geschäft und den an einem bestimmten Einkauf beteiligten Mitarbeiter speichern. Jede Dimensionstabelle ist eine eigene Kategorie (Datum, Mitarbeiter, Filiale) und kann ein oder mehrere Attribute haben . Für jedes Geschäft können wir seinen Standort auf Stadt-, Regions-, Bundesstaats- und Länderebene speichern. Für jedes Datum können wir das Jahr, den Monat, den Tag des Monats, den Wochentag usw. speichern. Dies hängt mit der Hierarchie zusammen von Attributen in der Dimensionstabelle.

  Im Star-Schema stellen wir normalerweise fest, dass einige Attribute eine Teilmenge anderer Attribute im selben Datensatz sind. Diese Redundanz ist beabsichtigt und erfolgt im Namen einer besseren Leistung. Wir könnten Datums-, Standort- und Vertriebsagentendimensionen verwenden, um Daten zu aggregieren (der Transformationsteil des ETL-Prozesses) und Daten in DWH zu speichern. Bei der Dimensionsmodellierung ist es sehr wichtig, die richtigen Abmessungen zu definieren und die richtige Körnung auszuwählen.

• Faktentabellen enthalten die Daten, die wir in Berichte aufnehmen möchten, aggregiert basierend auf Werten in den zugehörigen Dimensionstabellen. Eine Faktentabelle hat nur Spalten, die Werte und Fremdschlüssel speichern, die auf die Dimensionstabellen verweisen. Die Kombination aller Fremdschlüssel bildet den Primärschlüssel der Faktentabelle. Beispielsweise könnte eine Faktentabelle eine Anzahl von Kontakten und die Anzahl der aus diesen Kontakten resultierenden Verkäufe speichern.

Mit diesen Informationen können wir uns jetzt mit dem Star-Schema-Datenmodell befassen.

Das Sternenschema

Das Sternschema ist das einfachste Modell, das in DWH verwendet wird. Da sich die Faktentabelle in der Mitte des Schemas mit den Dimensionstabellen darum befindet, sieht sie ungefähr wie ein Stern aus. Dies wird besonders deutlich, wenn die Faktentabelle von fünf Dimensionstabellen umgeben ist. Eine Variante des Sternschemas, das Tausendfüßlerschema , wobei die Faktentabelle von einer großen Anzahl kleiner Dimensionstabellen umgeben ist.

Sternschemata werden sehr häufig in Data Marts verwendet. Wir können sie mit dem Top-Down-Datenmodellansatz in Beziehung setzen. Wir analysieren zwei Sternschemata (Data Marts) und kombinieren sie dann zu einem einzigen Modell.

Star-Schema-Beispiel:Verkäufe

Der Verkaufsbericht ist einer der heute am häufigsten verwendeten Berichte. Wie bereits erwähnt, konnten wir in den meisten Fällen Verkaufsberichte aus dem Live-System generieren. Aber wenn die Daten oder die Unternehmensgröße dies zu umständlich machen, müssen wir ein Data Warehouse oder einen Data Mart aufbauen, um den Prozess zu rationalisieren. Nach dem Entwerfen unseres Sternschemas wird eine ETL Der Prozess ruft die Daten aus den Betriebsdatenbanken ab, wandelt die Daten in das richtige Format für das DWH um und lädt die Daten in das Warehouse.

Das oben dargestellte Modell enthält eine Faktentabelle (hellrot gefärbt) und fünf Dimensionstabellen (hellblau gefärbt). Die Tabellen im Modell sind:

• fact_sales – Diese Tabelle enthält Verweise auf die Maßtabellen plus zwei Fakten (Preis und verkaufte Menge). Beachten Sie, dass alle fünf Fremdschlüssel zusammen den Primärschlüssel der Tabelle bilden.
• dim_sales_type – Dies ist eine Dimensionstabelle vom Verkaufstyp mit nur einem Attribut, „type_name “.
• dim_employee – Dies ist eine Mitarbeiterdimensionstabelle, die grundlegende Mitarbeiterattribute speichert:vollständiger Name und Geburtsjahr.
• dim_product – Dies ist eine Produktdimensionstabelle mit nur zwei Attributen (außer dem Primärschlüssel):Produktname und Produkttyp.
• dim_time – Diese Tabelle behandelt die Zeitdimension. Es enthält neben dem Primärschlüssel fünf Attribute. Die Daten der untersten Ebene sind Verkäufe nach Datum (action_date ). Die action_week Attribut ist die Nummer der Woche in diesem Jahr (d. h. die erste Woche im Januar würde die Nummer 1 erhalten; die letzte Woche im Dezember würde die Nummer 52 erhalten usw.) Der actual_month und actual_year Attribute speichern den Kalendermonat und das Kalenderjahr, in dem der Verkauf stattfand. Diese können aus dem action_date extrahiert werden Attribut. Der action_weekday -Attribut speichert den Namen des Tages, an dem der Verkauf stattfand.
• dim_store – Dies ist eine Filialdimension. Für jedes Geschäft speichern wir die Stadt, die Region, das Bundesland und das Land, in dem es sich befindet. Hier können wir deutlich erkennen, dass das Sternschema denormalisiert ist.

Star-Schema-Beispiel:Lieferaufträge

Es gibt viele Ähnlichkeiten zwischen diesem unten gezeigten Modell und dem Verkaufsmodell.

Dieses Modell soll die Historie der aufgegebenen Bestellungen speichern. Wir haben eine Faktentabelle und vier Dimensionstabellen. Die Dimensionstabellen dim_employee , dim_product und dim_time sind genau die gleichen wie im Verkaufsmodell. Die folgenden Tabellen sind jedoch unterschiedlich:

• fact_supply_order – enthält aggregierte Daten über die getätigten Bestellungen.
• dim_supplier – ist eine Dimensionstabelle, die Lieferantendaten auf die gleiche Weise speichert wie dim_store Speicherdaten im Verkaufsmodell beibehalten.

Vor- und Nachteile des Star-Schemas

Die Verwendung des Sternschemas bietet viele Vorteile. Die Faktentabelle ist mit jeder Dimensionstabelle durch genau eine Beziehung verbunden, und wir benötigen keine zusätzlichen Wörterbücher, um Dimensionstabellen zu beschreiben. Das vereinfacht Abfragen und verringert die Abfrageausführungszeit. Wir könnten den gleichen Bericht direkt aus unserem OLTP-System erstellen, aber die Abfrage wäre viel komplexer und könnte die Gesamtleistung des Systems beeinträchtigen. Die folgende Beispielabfrage für das Verkaufsmodell gibt die Menge aller telefonartigen Produkttypen zurück, die 2016 in Berliner Geschäften verkauft wurden:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Der größte Nachteil des Sternschemas ist die Redundanz. Jede Dimension wird in einer separaten Dimensionstabelle gespeichert, was zu einer Denormalisierung führt. In unserem Beispiel gehört die Stadt zu einer Region oder einem Staat, der wiederum zu einem Land gehört; wir speichern diesen Zusammenhang in der Regel nicht in unserer Datenbank, wiederholen ihn aber ständig. Das bedeutet, dass wir mehr Speicherplatz verbrauchen und ein Datenintegritätsrisiko eingehen.

Das Galaxieschema

Wir können die beiden Vorgängermodelle als zwei Data Marts betrachten, einen für die Verkaufsabteilung und den anderen für die Beschaffungsabteilung. Jede von ihnen besteht nur aus einer Faktentabelle und einigen Maßtabellen. Wenn wir wollten, könnten wir diese beiden Data Marts zu einem Modell kombinieren. Dieser Schematyp, der mehrere Faktentabellen enthält und einige Dimensionstabellen gemeinsam nutzt, wird als Galaxieschema bezeichnet . Die gemeinsame Nutzung von Dimensionstabellen kann die Datenbankgröße reduzieren, insbesondere wenn gemeinsame Dimensionen viele mögliche Werte haben. Idealerweise sind die Dimensionen in beiden Data Marts gleich definiert. Wenn dies nicht der Fall ist, müssen wir die Abmessungen anpassen, um beide Anforderungen zu erfüllen.

Unten sehen Sie ein Galaxienschema, das aus unseren beiden Beispiel-Datamarts aufgebaut ist:

Das Star-Schema ist ein Ansatz zur Organisation eines Data Warehouse. Es ist sehr einfach und wird am häufigsten in Data Marts verwendet. Wenn wir uns keine Sorgen um den Speicherplatz machen müssen und uns um die Datenintegrität kümmern, dann ist das Star-Schema eine praktikable erste und beste Wahl. Wenn nicht, sollten wir uns einen anderen Ansatz überlegen. Eines davon ist das Snowflake-Schema, das wir in einem der nächsten Artikel besprechen werden.