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