Snowflake Schema vs Star Schema

När du väljer ett databasschema för ett datalager, snöflinga och stjärnscheman tenderar att vara populära val. Denna jämförelse diskuterar lämplighet av stjärna vs snöflingaskeman i olika scenarier och deras egenskaper.

Jämförelsediagram

Snowflake Schema vs. Star Schema jämförelse diagram

Snowflake Schema	Star Schema
Lätt underhåll / förändring	Ingen redundans, så snöflingaskeman är enklare att behålla och förändra.	Har överflödiga data och därmed mindre lätt att underhålla / ändra
Enkel användning	Mer komplexa frågor och därmed mindre lätt att förstå	Lägre frågekomplexitet och lätt att förstå
Query Performance	Fler främmande nycklar och följaktligen längre utfrågningstid (långsammare)	Mindre antal främmande nycklar och följaktligen kortare utföra körningstid (snabbare)
Typ av Datawarehouse	Bra att använda för datawarehouse kärna för att förenkla komplexa relationer (många: många)	Bra för datorer med enkla relationer (1: 1 eller 1: många)
Fogar	Högre antal anslutningar	Färre anslutningar
Dimensionstabell	Ett snöflingaskjema kan ha mer än en dimensionstabell för varje dimension.	Ett stjärnschema innehåller bara en dimensionstabell för varje dimension.
När ska man använda	När dimensionstabellen är relativt stor i storlek, är snöflingan bättre eftersom det minskar rymden.	När dimensionstabellen innehåller mindre antal rader kan vi välja Star schema.
Normalisering / de-normalisering	Dimensionstabellerna är i normaliserad form men faktabordet är i de-normaliserad form	Både dimension och fakta tabeller är i normaliserad form
Datamodell	Bottom up approach	Top down approach

Innehåll: Snowflake Schema vs Star Schema

• 1 exempel
  • 1.1 Star Schema Exempel
  • 1.2 Snowflake Schema Exempel
• 2 referenser

exempel

Tänk på en databas för en återförsäljare som har många butiker, där varje butik säljer många produkter i många produktkategorier och olika varumärken. Ett datalager eller data mart för en sådan återförsäljare skulle kunna ge analytiker möjlighet att köra försäljningsrapporter grupperade efter butik, datum (eller månad, kvart eller år) eller produktkategori eller varumärke.

Star Schema Exempel

Om denna data mart använde ett stjärnschema skulle det se ut som följer:

Exempel på ett Star-schema

Fakta tabellen skulle vara en rekord av försäljningsaffärer, medan det finns dimensionstabeller för datum, butik och produkt. Dimensionstabellerna är alla anslutna till faktabordet via sin primära nyckel, vilket är en främmande nyckel för faktabordet. Till exempel, istället för att lagra det faktiska transaktionsdatumet i en rad i faktatabellen, sparas datum_id. Detta datum_id motsvarar en unik rad i tabellen Dim_Date, och den raden lagrar också andra attribut av det datum som krävs för att gruppera i rapporter. t ex dag i veckan, månad, kvartalet och så vidare. Uppgifterna är denormaliserade för enklare rapportering.

Här är hur man skulle få en rapport om antalet tv-apparater som säljs efter varumärke och land med hjälp av inre föreningar.

Snowflake Schema Exempel

Samma scenario kan också använda ett snöflingaskjema, i vilket fall det skulle vara strukturerat enligt följande:

Snowflake schema exempel (klicka för att förstora)

Huvudskillnaden jämfört med stjärnschemat är att data i dimensionstabeller normaliseras. Till exempel, i stället för att lagra månad, kvart och veckodag i varje rad i Dim_Date-tabellen bryts dessa vidare i sina egna dimensionstabeller. På samma sätt för Dim_Store-tabellen är staten och landet geografiska attribut som är ett steg borttaget - i stället för att lagras i Dim_Store-tabellen, lagras de nu i en separat Dim_Geography-tabell.

Samma rapport - antalet tv-säljare som säljs av land och varumärke - är nu lite mer komplicerat än i ett stjärnschema:

SQL-fråga för att få antal produkter som säljs efter land och varumärke, när databasen använder ett snöflingaskjema.

referenser

• wikipedia: Snowflake_schema
• wikipedia: Star_schema