Database
 sql >> Datenbank >  >> RDS >> Database

Sternschema vs. Schneeflockenschema

In den beiden vorangegangenen Artikeln haben wir die beiden gängigsten Data-Warehouse-Modelle betrachtet:das Sternschema und das Schneeflockenschema. Heute untersuchen wir die Unterschiede zwischen diesen beiden Schemas und erklären, wann es besser ist, das eine oder das andere zu verwenden.

Das Sternschema und das Schneeflockenschema sind Möglichkeiten, Data Marts oder ganze Data Warehouses mithilfe relationaler Datenbanken zu organisieren. Beide verwenden Maßtabellen um Daten aggregiert in einer Faktentabelle zu beschreiben .

Jeder verkauft etwas, sei es Wissen, ein Produkt oder eine Dienstleistung. Das Speichern dieser Informationen, entweder in einem operativen System oder in einem Berichtssystem, ist ebenfalls erforderlich. Wir können also damit rechnen, im Data Warehouse fast jedes Unternehmens eine Art Verkaufsmodell zu finden.

Werfen wir einen weiteren Blick auf das Verkaufsmodell sowohl im Stern- als auch im Schneeflockenschema.

Das Sternenschema



Das offensichtlichste Merkmal des Sternschemas ist, dass Dimensionstabellen nicht normalisiert sind. Im obigen Modell der rosafarbene fact_sales Tabelle speichert aggregierte Daten, die aus unseren operativen Datenbanken erstellt wurden. Die hellblauen Tabellen sind Maßtabellen. Wir haben uns für diese fünf Dimensionen entschieden, weil wir Berichte erstellen müssen, die sie als Parameter verwenden. Die Granulierung innerhalb jeder Dimension wird auch durch unsere Berichtsanforderungen bestimmt.

Anhand dieses Modells können wir leicht erkennen, warum dieses Schema „Sternschema“ genannt wird:Es sieht aus wie ein Stern, mit den Dimensionstabellen, die die zentrale Faktentabelle umgeben.

Das Schneeflockenschema



Dieses Schneeflockenschema speichert genau die gleichen Daten wie das Sternschema. Die Faktentabelle hat die gleichen Dimensionen wie im Beispiel des Sternschemas. Der wichtigste Unterschied besteht darin, dass die Dimensionstabellen im Schneeflockenschema normalisiert sind. Interessanterweise wird der Prozess der Normalisierung von Dimensionstabellen als Snowflaking bezeichnet.

Wieder einmal erinnert uns das Schneeflockenschema visuell an seinen Namensvetter, wobei mehrere Ebenen von Dimensionstabellen eine unregelmäßige schneeflockenähnliche Form erzeugen.

Der erste Unterschied:Normalisierung

Wie bereits erwähnt, ist die Normalisierung ein wesentlicher Unterschied zwischen Stern- und Schneeflockenschemata. Diesbezüglich gibt es ein paar Dinge zu wissen:

  • Snowflake-Schemata benötigen weniger Speicherplatz zum Speichern von Dimensionstabellen. Denn in der Regel produziert jede normalisierte Datenbank weit weniger redundante Datensätze .
  • Denormalisierte Datenmodelle erhöhen die Wahrscheinlichkeit von Datenintegritätsproblemen. Diese Probleme erschweren auch zukünftige Modifikationen und Wartungsarbeiten.
  • Für erfahrene Datenmodellierer erscheint das Schneeflockenschema logischer organisiert als das Sternschema. (Das ist meine persönliche Meinung, keine harte Tatsache. :) )

Kommen wir zum zweiten großen Unterschied zwischen diesen beiden Schemas.

Der zweite Unterschied:Komplexität der Abfragen

In unseren ersten beiden Artikeln haben wir eine Abfrage demonstriert, die für das Verkaufsmodell verwendet werden kann, um die Menge aller 2016 in Berliner Geschäften verkauften Telefonprodukte abzurufen.

Die Star-Schema-Abfrage sieht folgendermaßen aus:

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

Um dasselbe Ergebnis aus dem Schneeflockenschema zu erhalten, müssen wir diese Abfrage verwenden:

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_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Offensichtlich ist die Abfrage des Schneeflockenschemas komplexer. Da die Dimensionstabellen normalisiert sind, müssen wir tiefer graben, um den Namen des Produkttyps und der Stadt zu erhalten. Wir müssen für jede neue Ebene innerhalb derselben Dimension einen weiteren JOIN hinzufügen.

Im Sternschema verbinden wir die Faktentabelle nur mit den Dimensionstabellen, die wir brauchen. Wir haben höchstens einen JOIN pro Dimensionstabelle. Und wenn wir keine Maßtabelle verwenden, brauchen wir uns nicht einmal darum zu kümmern. Bei der Schneeflockenschema-Abfrage wissen wir nicht, wie tief wir gehen müssen, um die richtige Dimensionsebene zu erhalten, was den Prozess des Schreibens von Abfragen erschwert.

Das Zusammenführen von zwei Tischen nimmt Zeit in Anspruch, da das DMBS länger braucht, um die Anfrage zu verarbeiten. Der dim_store und dim_city Tabellen werden in unserem Modell in unmittelbarer Nähe platziert, aber sie dürfen sich auf der Festplatte nicht irgendwo nahe beieinander befinden. Es besteht eine bessere Möglichkeit, dass Daten physisch näher auf der Festplatte liegen, wenn sie sich in derselben Tabelle befinden.

Grundsätzlich wird eine Abfrage, die für einen Snowflake-Schema-Datamart ausgeführt wird, langsamer ausgeführt. Aber in den meisten Fällen stellt dies kein Problem dar:Es spielt keine große Rolle, ob wir das Ergebnis in einer Millisekunde oder einer Sekunde erhalten.

Dinge beschleunigen

Um die Berichterstellung zu beschleunigen, können wir:

  • Aggregieren Sie Daten auf die Ebene, die wir in Berichten benötigen. Dadurch werden die Daten erheblich komprimiert. Wir müssen Verfahren erstellen, die unsere Live-Daten so umwandeln, dass sie in die Berichtsschemastruktur (den ETL-Prozess) passen.
  • Errichten Sie einen zentralen Speicherbereich für alle die aggregierten Daten des Unternehmens, nicht nur die Verkaufsdaten.
  • Geben Sie Benutzern nur die Daten, die sie für Analysen und Berichte benötigen.

Snowflake vs. Star Schemas:Welche sollten Sie verwenden?

Nachdem wir uns nun mit der Theorie und den Abfragegeschwindigkeiten befasst haben, kommen wir direkt zum Kern der Sache:Woher wissen Sie, welches Schema Sie für ein bestimmtes Projekt verwenden sollen?

Erwägen Sie die Verwendung des Snowflake-Schemas :

  • In Data Warehouses. Da das Lager die Datenzentrale für das Unternehmen ist, konnten wir auf diese Weise viel Platz sparen.
  • Wenn Dimensionstabellen viel Speicherplatz benötigen. In den meisten Fällen nehmen die Faktentabellen den größten Platz ein. Sie werden wahrscheinlich auch viel schneller wachsen als Maßtabellen. Aber es gibt bestimmte Situationen, in denen das nicht gilt. Beispielsweise könnten die Dimensionstabellen viele redundante, aber benötigte Attribute enthalten. In unserem Beispiel haben wir die Stadt verwendet Attribut zur Beschreibung der Stadt, in der sich das Geschäft befindet. Was wäre, wenn wir eine viel detailliertere Beschreibung der Stadt wünschen, einschließlich Einwohnerzahl, Postleitzahl, demografische Daten usw.? Beschreiben anderer Unterdimensionen – zum Beispiel Geschäft , Region , Zustand und Land – mit mehr Attributen würde sich der dim_store Dimensionstabelle in eine große Tabelle mit viel Redundanz.
  • Wenn Sie Tools verwenden, die ein Schneeflockenschema im Hintergrund erfordern. (Glücklicherweise unterstützen die meisten modernen Tools beide Schemas und sogar das Galaxy-Schema.)

Erwägen Sie die Verwendung des Sternschemas :

  • In Datamarts. Data Marts sind Teilmengen von Daten, die aus dem zentralen Data Warehouse entnommen werden. Sie werden normalerweise für verschiedene Abteilungen erstellt und enthalten nicht einmal alle Verlaufsdaten. In dieser Einstellung hat das Sparen von Speicherplatz keine Priorität.

    Andererseits vereinfacht das Sternschema die Analyse. Dabei geht es nicht nur um die Abfrageeffizienz, sondern auch um die Vereinfachung zukünftiger Aktionen für Geschäftsanwender. Sie verstehen vielleicht Datenbanken und wissen, wie man Abfragen schreibt, aber warum die Dinge komplizieren und mehr Joins einbeziehen, wenn wir es vermeiden können? Ein Geschäftsbenutzer könnte eine Vorlagenabfrage haben, die die Faktentabelle mit allen Dimensionstabellen verknüpft. Dann müssen sie nur noch die entsprechenden Auswahlen und Gruppierungen hinzufügen. (Dieser Ansatz kommt den Pivot-Tabellen von Excel sehr nahe.)

  • Wenn Sie Tools verwenden, die ein Star-Schema im Hintergrund erfordern. (Auch dies ist normalerweise kein Problem.)

Sowohl das Sternschema als auch das Schneeflockenschema sind relationale Modelle, die zum Organisieren von Data Warehouses und/oder Data Marts verwendet werden. Egal wie ähnlich sie sind, sie demonstrieren zwei unterschiedliche Ansätze und haben ihre eigenen Vor- und Nachteile. Ich persönlich würde bei der Implementierung eines Data Warehouses (um Speicherplatz zu sparen) das Snowflake-Schema und bei Data Marts (um Business-Anwendern das Leben zu erleichtern) das Star-Schema wählen.