Menü

Schematypen in der Data Warehouse-Modellierung - Star & SnowFlake-Schema

  • Haupt
  • Andere
  • Schematypen in der Data Warehouse-Modellierung - Star & SnowFlake-Schema

schema types data warehouse modeling star snowflake schema

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

In diesem Lernprogramm werden verschiedene Data Warehouse-Schematypen erläutert. Erfahren Sie, was Sternschema und Schneeflockenschema sind und was der Unterschied zwischen Sternschema und Schneeflockenschema ist:

In diesem Date Warehouse Tutorials für Anfänger Wir haben uns das genauer angesehen Dimensionsdatenmodell im Data Warehouse in unserem vorherigen Tutorial.

In diesem Tutorial erfahren Sie alles über Data Warehouse-Schemas, die zum Strukturieren von Data Marts (oder) Data Warehouse-Tabellen verwendet werden.

c ++ char * in int konvertieren

Lasst uns beginnen!!

Data Warehouse-Schemata

Zielgruppe

  • Entwickler und Tester von Data Warehouse / ETL.
  • Datenbankprofis mit Grundkenntnissen in Datenbankkonzepten.
  • Datenbankadministratoren / Big-Data-Experten, die Data Warehouse- / ETL-Bereiche verstehen möchten.
  • Hochschulabsolventen / Studienanfänger, die nach Data Warehouse-Jobs suchen.

Was du lernen wirst:

Data Warehouse-Schema

In einem Data Warehouse wird ein Schema verwendet, um die Art und Weise der Organisation des Systems mit allen Datenbankentitäten (Faktentabellen, Dimensionstabellen) und deren logische Zuordnung zu definieren.

Hier sind die verschiedenen Arten von Schemata in DW:

  1. Stern Zeitplan
  2. SnowFlake-Schema
  3. Galaxiediagramm
  4. Sternhaufenschema

# 1) Star Schedule

Dies ist das einfachste und effektivste Schema in einem Data Warehouse. Eine Faktentabelle in der Mitte, die von Tabellen mit mehreren Dimensionen umgeben ist, ähnelt einem Stern im Sternschemamodell.

Die Faktentabelle unterhält Eins-zu-Viele-Beziehungen zu allen Dimensionstabellen. Jede Zeile in einer Faktentabelle ist ihren Dimensionstabellenzeilen mit einer Fremdschlüsselreferenz zugeordnet.

Aus dem oben genannten Grund ist die Navigation zwischen den Tabellen in diesem Modell zum Abfragen aggregierter Daten einfach. Ein Endbenutzer kann diese Struktur leicht verstehen. Daher unterstützen alle Business Intelligence (BI) -Tools das Star-Schemamodell erheblich.

Beim Entwerfen von Sternschemata werden die Dimensionstabellen absichtlich de-normalisiert. Sie sind breit und enthalten viele Attribute zum Speichern der Kontextdaten für eine bessere Analyse und Berichterstellung.

Vorteile des Sternschemas

  • Abfragen verwenden beim Abrufen der Daten sehr einfache Verknüpfungen, wodurch die Abfrageleistung erhöht wird.
  • Es ist einfach, Daten für die Berichterstellung zu jedem Zeitpunkt und für jeden Zeitraum abzurufen.

Nachteile des Sternschemas

  • Wenn sich die Anforderungen häufig ändern, wird nicht empfohlen, das vorhandene Sternschema zu ändern und langfristig wiederzuverwenden.
  • Datenredundanz ist mehr, da Tabellen nicht hierarchisch unterteilt sind.

Ein Beispiel für ein Sternschema ist unten angegeben.

Sternschema - Beispiel

Abfragen eines Sternschemas

Ein Endbenutzer kann mithilfe von Business Intelligence-Tools einen Bericht anfordern. Alle diese Anforderungen werden verarbeitet, indem intern eine Kette von 'SELECT-Abfragen' erstellt wird. Die Leistung dieser Abfragen wirkt sich auf die Ausführungszeit des Berichts aus.

Wenn ein Geschäftsbenutzer anhand des obigen Star-Schema-Beispiels wissen möchte, wie viele Romane und DVDs im Januar 2018 im Bundesstaat Kerala verkauft wurden, können Sie die Abfrage wie folgt auf Star-Schematabellen anwenden:

SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Product pdim, Sales sfact, Store sdim, Date ddim WHERE sfact.product_id = pdim.product_id AND sfact.store_id = sdim.store_id AND sfact.date_id = ddim.date_id AND sdim.state = 'Kerala' AND ddim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name

Ergebnisse:

Produktname Menge_Verkauft
7Jeder kann das Schema leicht verstehen und entwerfen.Es ist schwierig, das Schema zu verstehen und zu entwerfen.
Romane12.702
DVDs32.919

Ich hoffe, Sie haben verstanden, wie einfach es ist, ein Sternschema abzufragen.

# 2) SnowFlake-Schema

Das Sternschema dient als Eingabe zum Entwerfen eines SnowFlake-Schemas. Schneeflocken sind ein Prozess, bei dem alle Dimensionstabellen eines Sternschemas vollständig normalisiert werden.

Die Anordnung einer Faktentabelle in der Mitte, die von mehreren Hierarchien von Dimensionstabellen umgeben ist, ähnelt einer SnowFlake im SnowFlake-Schemamodell. Jede Faktentabellenzeile ist ihren Dimensionstabellenzeilen mit einer Fremdschlüsselreferenz zugeordnet.

Beim Entwerfen von SnowFlake-Schemas werden die Dimensionstabellen gezielt normalisiert. Zu jeder Ebene der Dimensionstabellen werden Fremdschlüssel hinzugefügt, um eine Verknüpfung mit dem übergeordneten Attribut herzustellen. Die Komplexität des SnowFlake-Schemas ist direkt proportional zu den Hierarchieebenen der Dimensionstabellen.

Vorteile des SnowFlake-Schemas:

  • Datenredundanz wird vollständig entfernt, indem neue Dimensionstabellen erstellt werden.
  • Im Vergleich zum Sternschema wird in den Dimensionstabellen für Schneeflocken weniger Speicherplatz verwendet.
  • Es ist einfach, die Snow Flaking-Tabellen zu aktualisieren (oder zu pflegen).

Nachteile des SnowFlake-Schemas:

  • Aufgrund normalisierter Dimensionstabellen muss das ETL-System die Anzahl der Tabellen laden.
  • Aufgrund der Anzahl der hinzugefügten Tabellen benötigen Sie möglicherweise komplexe Verknüpfungen, um eine Abfrage durchzuführen. Daher wird die Abfrageleistung beeinträchtigt.

Ein Beispiel für ein SnowFlake-Schema finden Sie unten.

Schneeflockenschema

Die Dimensionstabellen im obigen SnowFlake-Diagramm werden wie folgt erläutert normalisiert:

  • Die Datumsdimension wird in vierteljährliche, monatliche und wöchentliche Tabellen normalisiert, indem Fremdschlüssel-IDs in der Datumstabelle belassen werden.
  • Die Speicherdimension wird so normalisiert, dass sie die Tabelle für den Status enthält.
  • Die Produktdimension wird in Brand normalisiert.
  • In der Kundendimension werden die mit der Stadt verbundenen Attribute in die neue Stadttabelle verschoben, indem eine Fremdschlüssel-ID in der Kundentabelle belassen wird.

Auf die gleiche Weise kann eine einzelne Dimension mehrere Hierarchieebenen beibehalten.

Verschiedene Hierarchieebenen aus dem obigen Diagramm können wie folgt bezeichnet werden:

  • Vierteljährliche ID, monatliche ID und wöchentliche IDs sind die neuen Ersatzschlüssel, die für Datumsdimensionshierarchien erstellt werden und die als Fremdschlüssel in der Datumsdimensionstabelle hinzugefügt wurden.
  • Die Status-ID ist der neue Ersatzschlüssel, der für die Hierarchie der Geschäftsdimensionen erstellt wurde, und wurde als Fremdschlüssel in der Dimension der Geschäftsdimensionen hinzugefügt.
  • Die Marken-ID ist der neue Ersatzschlüssel, der für die Produktdimensionshierarchie erstellt wurde und als Fremdschlüssel in der Produktdimensionstabelle hinzugefügt wurde.
  • Die Stadt-ID ist der neue Ersatzschlüssel, der für die Kundendimensionshierarchie erstellt wurde und als Fremdschlüssel in der Kundendimensionstabelle hinzugefügt wurde.

Abfragen eines Schneeflockenschemas

Mit SnowFlake-Schemas können wir für Endbenutzer die gleichen Berichte erstellen wie für Sternschemastrukturen. Aber die Abfragen sind hier etwas kompliziert.

Aus dem obigen SnowFlake-Schemabeispiel werden wir dieselbe Abfrage generieren, die wir während des Star-Schemaabfragebeispiels entworfen haben.

Wenn ein Geschäftsbenutzer wissen möchte, wie viele Romane und DVDs im Januar 2018 im Bundesstaat Kerala verkauft wurden, können Sie die Abfrage wie folgt auf SnowFlake-Schematabellen anwenden.

SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Sales sfact INNER JOIN Product pdim ON sfact.product_id = pdim.product_id INNER JOIN Store sdim ON sfact.store_id = sdim.store_id INNER JOIN State stdim ON sdim.state_id = stdim.state_id INNER JOIN Date ddim ON sfact.date_id = ddim.date_id INNER JOIN Month mdim ON ddim.month_id = mdim.month_id WHERE stdim.state = 'Kerala' AND mdim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name

Ergebnisse:

Produktname Menge_Verkauft
Romane12.702
DVDs32.919

Wichtige Punkte beim Abfragen von Star (oder) SnowFlake-Schematabellen

Jede Abfrage kann mit der folgenden Struktur entworfen werden:

SELECT-Klausel:

  • Die in der select-Klausel angegebenen Attribute werden in den Abfrageergebnissen angezeigt.
  • Die Select-Anweisung verwendet auch Gruppen, um die aggregierten Werte zu finden. Daher müssen wir die group by-Klausel in der where-Bedingung verwenden.

FROM-Klausel:

  • Alle wesentlichen Faktentabellen und Dimensionstabellen müssen kontextabhängig ausgewählt werden.

WHERE-Klausel:

  • Geeignete Dimensionsattribute werden in der where-Klausel durch Verknüpfen mit den Faktentabellenattributen erwähnt. Ersatzschlüssel aus den Dimensionstabellen werden mit den jeweiligen Fremdschlüsseln aus den Faktentabellen verknüpft, um den abzufragenden Datenbereich festzulegen. Weitere Informationen hierzu finden Sie im oben beschriebenen Beispiel für eine Sternschema-Abfrage. Sie können Daten auch in der from-Klausel selbst filtern, wenn Sie dort innere / äußere Verknüpfungen verwenden, wie im Beispiel für das SnowFlake-Schema beschrieben.
  • Dimensionsattribute werden in der where-Klausel auch als Einschränkungen für Daten erwähnt.
  • Durch Filtern der Daten mit allen oben genannten Schritten werden die entsprechenden Daten für die Berichte zurückgegeben.

Gemäß den Geschäftsanforderungen können Sie die Fakten, Dimensionen, Attribute und Einschränkungen zu einer Sternschema- (oder) SnowFlake-Schemaabfrage hinzufügen (oder entfernen), indem Sie der obigen Struktur folgen. Sie können auch Unterabfragen hinzufügen (oder verschiedene Abfrageergebnisse zusammenführen), um Daten für komplexe Berichte zu generieren.

# 3) Galaxiediagramm

Ein Galaxienschema wird auch als Fact Constellation Schema bezeichnet. In diesem Schema verwenden mehrere Faktentabellen dieselben Dimensionstabellen. Die Anordnung von Faktentabellen und Dimensionstabellen sieht aus wie eine Sammlung von Sternen im Galaxy-Schemamodell.

Die gemeinsamen Abmessungen in diesem Modell werden als konforme Abmessungen bezeichnet.

Diese Art von Schema wird für anspruchsvolle Anforderungen und für aggregierte Faktentabellen verwendet, die komplexer sind und vom Star-Schema (oder SnowFlake-Schema) unterstützt werden. Dieses Schema ist aufgrund seiner Komplexität schwierig zu pflegen.

Ein Beispiel für das Galaxy-Schema finden Sie unten.

Galaxy Schema - Beispiel

# 4) Sternhaufenschema

Ein SnowFlake-Schema mit vielen Dimensionstabellen erfordert möglicherweise komplexere Verknüpfungen beim Abfragen. Ein Sternschema mit weniger Dimensionstabellen weist möglicherweise mehr Redundanz auf. Daher kam ein Sternhaufenschema ins Spiel, indem die Merkmale der beiden oben genannten Schemata kombiniert wurden.

Das Sternschema ist die Basis für das Entwerfen eines Sternhaufenschemas, und nur wenige wesentliche Dimensionstabellen aus dem Sternschema sind schneebedeckt, was wiederum eine stabilere Schemastruktur bildet.

Ein Beispiel für ein Sternhaufenschema ist unten angegeben.

Sternhaufenschema

Was ist ein besseres Schneeflockenschema oder Sternschema?

Die Data Warehouse-Plattform und die in Ihrem DW-System verwendeten BI-Tools spielen eine wichtige Rolle bei der Entscheidung über das geeignete zu entwerfende Schema. Star und SnowFlake sind die am häufigsten verwendeten Schemata in DW.

Das Sternschema wird bevorzugt, wenn BI-Tools es Geschäftsbenutzern ermöglichen, mit einfachen Abfragen problemlos mit den Tabellenstrukturen zu interagieren. Das SnowFlake-Schema wird bevorzugt, wenn BI-Tools für Geschäftsbenutzer aufgrund von mehr Verknüpfungen und komplexen Abfragen komplizierter sind, um direkt mit den Tabellenstrukturen zu interagieren.

Sie können mit dem SnowFlake-Schema fortfahren, entweder wenn Sie Speicherplatz sparen möchten oder wenn Ihr DW-System über optimierte Tools zum Entwerfen dieses Schemas verfügt.

Sternschema gegen Schneeflockenschema

Nachstehend sind die wichtigsten Unterschiede zwischen dem Star-Schema und dem SnowFlake-Schema aufgeführt.

S.No. Stern Zeitplan Schneeflockenschema
einDatenredundanz ist mehr.Datenredundanz ist geringer.
zweiDer Speicherplatz für Dimensionstabellen ist größer.Der Speicherplatz für Dimensionstabellen ist vergleichsweise geringer.
3Enthält de-normalisierte Dimensionstabellen.Enthält normalisierte Dimensionstabellen.
4Eine einzelne Faktentabelle ist von mehrdimensionalen Tabellen umgeben.Eine einzelne Faktentabelle ist von mehreren Hierarchien von Dimensionstabellen umgeben.
5Abfragen verwenden direkte Verknüpfungen zwischen Fakt und Dimensionen, um die Daten abzurufen.Abfragen verwenden komplexe Verknüpfungen zwischen Fakten und Dimensionen, um die Daten abzurufen.
6Die Ausführungszeit für Abfragen ist kürzer.Die Ausführungszeit für Abfragen ist länger.
8Verwendet den Top-Down-Ansatz.Verwendet den Bottom-Up-Ansatz.

Fazit

Wir hoffen, dass Sie ein gutes Verständnis der verschiedenen Arten von Data Warehouse-Schemata sowie ihrer Vor- und Nachteile aus diesem Lernprogramm erhalten haben.

Wir haben auch gelernt, wie Star Schema und SnowFlake Schema abgefragt werden können und welches Schema zwischen diesen beiden zusammen mit ihren Unterschieden zu wählen ist.

Besuchen Sie unser bevorstehendes Tutorial, um mehr über Data Mart in ETL zu erfahren!

=> Sehen Sie sich hier die einfache Data Warehousing-Schulungsreihe an.

Literatur-Empfehlungen

^