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. I denna jämförelse diskuteras lämpligheten hos stjärna kontra snöflingascheman i olika scenarier och deras egenskaper.

Jämförelsediagram

Snowflake Schema kontra Star Schema jämförelse diagram
Snowflake Schema Star Schema
Enkel underhåll / förändringIngen redundans, så snöflingascheman är lättare att underhålla och ändra.Har redundanta data och därmed mindre lätt att underhålla / ändra
Enkel användningMer komplexa frågor och därmed mindre lätt att förståLägre frågeställningskomplexitet och lätt att förstå
FrågoresultatMer utländska nycklar och därmed längre körningstid för frågan (långsammare)Mindre antal utländska nycklar och därmed kortare körningstid för frågan (snabbare)
Typ av datawarehouseBra att använda för datawarehouse-kärna för att förenkla komplexa relationer (många: många)Bra för datamart med enkla relationer (1: 1 eller 1: många)
FogarHögre antal JoinsFärre anslutningar
DimensionstabellEtt snöflingaschema kan ha mer än en dimensionstabell för varje dimension.Ett stjärnschema innehåller endast enstaka dimensionstabell för varje dimension.
När du ska använda denNär dimensionstabellen är relativt stor i storlek är snöflinga bättre eftersom det minskar utrymmet.När dimensionstabellen innehåller mindre antal rader kan vi välja Stjärnskema.
Normalisering / De-NormaliseringDimensionstabeller är i normaliserad form men fakta tabell är i de-normaliserad formBåde dimensioner och fakta tabeller är i de-normaliserad form
DatamodellUnderifrån uppåtUppifrån och ner

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 av olika märken. Ett datalager eller datamart för en sådan återförsäljare skulle behöva ge analytiker möjligheten att köra försäljningsrapporter grupperade efter butik, datum (eller månad, kvartal eller år) eller produktkategori eller märke.

Exempel på stjärnschema

Om denna datamart använde ett stjärnschema skulle det se ut enligt följande:

Exempel på ett stjärnskema

Faktabellen skulle vara en post av försäljningstransaktioner, medan det finns dimensionstabeller för datum, butik och produkt. Dimensionstabeller är anslutna till faktabellen via sin primära nyckel, som är en främmande nyckel för faktabellen. I stället för att lagra det faktiska transaktionsdatumet i en rad i faktabellen lagras till exempel date_id. Detta datum_id motsvarar en unik rad i tabellen Dim_Date, och den raden lagrar också andra attribut för det datum som krävs för gruppering i rapporter. t.ex. veckodag, månad, kvartal av året och så vidare. Uppgifterna är normaliserade för enklare rapportering.

Så här kan man få en rapport om antalet TV-apparater som säljs efter märke och land med hjälp av inre kopplingar.

Snowflake Schema Exempel

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

Exempel på snöflinga schema (klicka för att förstora)

Den största skillnaden, jämfört med stjärnschemat, är att data i dimensionstabeller är mer normaliserade. I stället för att lagra månad, kvartal och veckodag i varje rad i Dim_Date-tabellen, delas de till exempel upp i sina egna dimensionstabeller. På liknande sätt för Dim_Store-tabellen är staten och landet geografiska attribut som är ett steg bort - istället för att lagras i Dim_Store-tabellen, lagras de nu i en separat Dim_Geography-tabell.

Samma rapport - antalet TV-apparater som säljs per land och efter 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 märke när databasen använder ett snöflingaschema.

Relaterade Artiklar