Sternschema

Das Sternschema ist keine Erfindung von SAP und kann auch über eine relationale Datenbank realisiert werden. Ich lese grade William H. Inmon / Building the Data Warehouse, fourth Edition. Der Stoff ist zwar schon über drei Jahrzehnte alt, ist aber auch heute noch Basis für das Verständnis eines Data Warehouses.

Fragestellungen, wie sie bei einem transaktionalen System eine zentrale Rolle spielen, haben auf einem Data Warehouse nur eine untergeordnete Priorität. Hierzu gehört unter anderen die redundanzfreie Speicherung der Daten, die auf einem OLTP die Grundlage für die Konsistenz ist und erst eine transaktionale Datenänderung ermöglicht.

Ziel des Sternschemas ist es, das Datenvolumen während einer Abfrage zu verringern und damit die Abfrage zu beschleunigen.


Das Problem

Es gibt da den Begriff der normalisierten Datenbank. Normalisierung ist ein Prozess beim Design von Datenbanken, bei dem Redundanzen minimiert werden und eine hohe Integrität der Daten gewährleistet werden soll. Bedeutet im Normalfall: Alle zusammengehörenden Informationen stehen in einem Datensatz innerhalb einer Tabelle. Die Normalisierung ermöglicht eine transaktionale Änderung der Daten, egal ob Einfügen neuer, das Ändern bestehender oder das Löschen nicht mehr benötigter Informationen. Die Normalisierung ist Grundlage für ACID (Atomicity, Consistency, Isolation und Durability). Das ist die Welt des OLTP (Online Transaction Processing).

Im Bereich OLAP, zu dem ein Data Warehousing gehört, entsteht durch die Normalisierung ein Laufzeitproblem. Wie der Begriff OLAP (Online Analytical Processing) schon sagt, geht es um Analyse, praktisch ausgedrückt das Durchsuchen der Daten. Hierbei spielt

Auf einer Datenbank bestimmen Teilmengen der Daten eine Zentrale Rolle, Datensätze auf die ein oder eine Reihe von Kriterien passt. Auf einer normalen SQL-Datenbank werden zusammenhängende Daten innerhalb einer Tabelle und innerhalb dieser Tabelle als Datensatz gespeicher. Innerhalb eines Datensatzes sind die Informationen als sequentielle Folge von Zeichen gespeichert, die über ein Schema interpretiert werden müssen. Um auf ein Feld innerhalb eines Datensatzes zugreifen zu können, muss auf er untersten Ebene die gesamte Zeichenfolge eines Datensatzes zunächst gelesen werden. Bei einer Speicherung auf Festplatten bedeutet dieses jede Menge mechanischer Arbeit.

Wo liegt nun die Relevanz: Diese kommt aus der WHERE-Klausel einer SELECT Anweisung über die eine Teilmenge bestimmt wird. Im einfachsten Fall lautet diese:

WHERE feldname operator wert.

no images were found

Um diejenigen Datensätze herauszusuchen, welche die Bedinung erfüllen, muss auf der Datenbank innerhalb der Tabelle jeder Datensatz in seiner vollen Länge durchsucht werden, um den Wert des Feldes mit dem Namen feldname auf die Erfüllung des Kriteriums hin abzugleichen. Bereits in diesem einfachen Fall sehr viel Traffic auf den Festplatten.

Zum echte Problem kann dieses werden, wenn verkettete Bedingungen notwendig sind oder z. B. ein JOIN Statement existiert, wo für jeden Datensatz der Tabelle aus einer weiteren ein Datensatz bedingt hinzugelesen werden muss.

Entscheidend für die Zeit für einen SELECT ist entspechend neben der Anzahl die Breite des Datensatzes, also wieviele Zeichen und damit Felder er beinhaltet. Um das zu erreichen können verschiedene Maßnahmen getroffen werden:

  • Nicht für die WHERE – Klausel benötigte Spalten müssen auch nicht durchsucht werden.
  • Die Anzahl der Felder kann auf mehrere Tabellen aufgeteilt werden.

Sternschema

Um ein Resultat zu erhalten, muss nicht der gesamte Datenbestand in einer Abfrage durchsucht werden

Ich halte diese Erkenntniss, so trivial sie auch erscheint, für den Kern einer beschleunigten Abfrage. Je schneller eine kleinere Teilmenge bestimmt werden kann, desto weniger Zeit benötige ich. Grade bei dem Hintergrund, das in der Zeit, in der Datenzugriff auch mechanische Arbeit auf den Drehorgeln des Speichers bedeutete, war diese Erkenntniss fundamental.

Unterscheidung zwischen beschreibenden und quantifizierenden Daten

Ist die Grundlage für die Trennung im SAP – Raum nach Merkmalen und Fakten. Im SQL ist diese Trennung nicht vorhanden, hier besteht ein Datensatz aus Feldern. Fakten als rein quantitative Werte müssen nicht durchsucht werden.

Bildung von Dimensionen

Die Idee zu den Dimensionen basisert auf der Annahme / Vermutung / Erkenntnis, dass nicht jeder Datennutzer interesse an allen Daten hat, sondern eine fachspezifische Sicht auf sie hat. Viele Werte interessieren ihn nicht. Das lässt zu, dass die Menge der beschreibenden Werte in Benutzerspezifische Segmente unterteilt werden kann.

Trennung von Bewegungs- und Stammdaten

Bestimmung von Data Marts


Erweitertet Sternschema (Snowflakes)

Indizierung

Gehört jetzt nicht mehr zum Kern des allgemeinen Sternschemas (?). Texte sind nur zeitaufwendig zu Vergleichen. Eine Möglichkeit, diesen Vorgang zu beschleunigen ist es, anstatt des Textes direkt auf eine Tabelle mit eindeutigen Textwerten zu referenzieren, bei der Abfrage wird nicht nach dem Text direkt gefragt, sondern es wird lediglich der Indexwert als Surrogat numerisch verglichen

Close Menu
error: Content is protected !!