I en tidigare artikel diskuterade vi stjärnschemamodellen. Snöflingeschemat ligger bredvid stjärnschemat när det gäller dess betydelse i datalagermodellering. Det utvecklades utifrån stjärnschemat, och det erbjuder vissa fördelar jämfört med sin föregångare. Men dessa fördelar har en kostnad. I den här artikeln kommer vi att diskutera när och hur man använder snöflingaschemat.
The Snowflake Schema
Snöflingeschemats namn kommer från det faktum att dimensionstabeller förgrenar sig och ser ut ungefär som en snöflinga. När vi tittar på modellen ovan kommer vi att märka att det är en faktatabell omgiven av några dimensionstabeller, av vilka några gör den ovan nämnda förgreningen. Till skillnad från stjärnschemat kan dimensionstabeller i snöflingaschemat ha sina egna kategorier.
Den härskande tanken bakom snöflingaschemat är att dimensionstabeller är helt normaliserade. Varje dimensionstabell kan beskrivas av en eller flera uppslagstabeller. Varje uppslagstabell kan beskrivas av en eller flera ytterligare uppslagstabeller. Detta upprepas tills modellen är helt normaliserad. Processen att normalisera dimensionstabeller för stjärnscheman kallas snöflingning.
Du kommer att höra mycket om normalisering i den här artikeln. Vad är normalisering? I grund och botten är det att organisera en databas på ett sätt som minimerar redundanser och skyddar dataintegriteten. Kolla in det här inlägget för att lära dig mer om normalisering och denormalisering.
Snowflake Schema Exempel:Försäljningsmodell
Tidigare använde vi ett stjärnschema för att modellera en fiktiv försäljningsavdelning – detta skulle vara besläktat med en datamarknad som används för att spåra försäljningsaktiviteter och resultat. Modellen har fem dimensioner:produkt , tid , butik , försäljning typ och anställd . I fact_sales tabell, pris och kvantitet lagras och grupperas baserat på värden i dimensionstabeller. För en uppfräschning, ta en titt på stjärnschemaförsäljningsmodellen nedan:
Här är samma modell organiserad som ett snöflingaschema:
dim_employee och dim_sales_type dimensionstabeller är exakt samma som i stjärnschemamodellen eftersom de redan är normaliserade.
Å andra sidan tillämpade vi normaliseringsregler på resten av dimensionstabellerna.
dim_product dimensionstabellen från stjärnschemat är uppdelad i två tabeller i snöflingamodellen. dim_product_type tabell lades till för att referera till matchningstypen i dim_product tabell. Genom att använda detta undvek vi vissa dataintegritetsproblem.
Det är logiskt att anta att vi redan kommer att ha alla produktnamn och deras relaterade typer infogade som en del av ETL-processen, men anta att vi behöver lägga till fler produktnamn och typer. I ett stjärnschema kan vi av misstag skriva in fel produkttyp i tabellen. I snöflingans schema:
- Om vi stöter på ett nytt produkttypsnamn kan vi lägga till en ny produkttyp och sedan relatera den typen till en nyligen tillagd post. Detta kan dock leda till att användaren anger felaktig information, precis som i stjärnschemat.
- Vi kan kontrollera om produktnamnet som vi vill lägga till redan finns. Om så är fallet kan vi få dess ID; om inte, kommer en varning att komma upp som frågar oss om vi vill lägga till en ny produkt och en relaterad typ.
dim_store dimensionstabell från stjärnschemat representeras av 5 tabeller i snöflingaschemat. Dessa delar upp attributen stad, region, stat och land som lagrades i dim_store tabell. Genom att normalisera den här tabellen undvek inte bara risken för dataintegritet, det sparade också en del diskutrymme.
dim_time dimensionen representeras med fem tabeller. Vi kan tänka oss dim_week , dim_month , dim_year och dim_weekday tabeller som ordböcker som beskriver dim_time tabell.
dim_week , dim_month , dim_year och dim_weekday tabeller är fyra olika hierarkier som används för att beskriva vår tidsdimension. Vi kunde lägga till fler dimensioner som kvarter eller andra relaterade tabeller om vi behövde dem. I det här exemplet, dim_month är en ordbok som innehåller 12 månader; bara från denna dimension har vi inget sätt att veta vilket år den månaden tillhör; det är funktionen för dim_year tabell.
Snowflake Schema Exempel:Supply Order Model
Den andra datamarknaden vi diskuterade var för leveransordrar. Tanken är att lagra och aggregera all leveransorderdata för följande fyra dimensioner:produkt , tid , leverantör och anställd . Återigen ska vi ta en titt på det relevanta stjärnschemat:
Om vi konverterar detta till snöflingaschemat får vi följande modell:
Samma normaliseringsregler som de som beskrivs för försäljningsmodellen användes på dim_product , dim_time och dim_supplier dimensionstabeller.
Fördelar och nackdelar med Snowflake Schema
Det finns två huvudsakliga fördelar till snöflingans schema:
- Bättre datakvalitet (data är mer strukturerad, så dataintegritetsproblem minskar)
- Mindre diskutrymme används sedan i en denormaliserad modell
Den mest anmärkningsvärda nackdelen för snöflingamodellen är att den kräver mer komplexa frågor. Dessa frågor, med sitt ökade antal anslutningar, kan minska prestandan avsevärt.
Vi kommer att skriva om samma fråga som används i stjärnschemaartikeln för försäljningsmodellen för snöflingaschema. Här är frågan som behövs för att returnera mängden av alla telefontyper som såldes i butiker i Berlin 2016:
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
The Starflake Schema
Ett sjöflingaschema är en kombination av snöflinga- och stjärnscheman. Vi kan se det som ett snöflingaschema som har några dimensionstabeller denormaliserade. När det används på rätt sätt kan starflake-schemat ge det bästa av båda världarna. Uppenbarligen bör snöflingadelen av modellen spara diskutrymme, medan stjärndelen ska förbättra prestandan.
Modellen ovan är i grunden en snöflingamodell med en denormaliserad dim_time tabell. Eftersom det här schemat minskar antalet frågekopplingar som behövs kan det förbättra prestandan. Å andra sidan kommer vi inte att förlora en anmärkningsvärd mängd av diskutrymmet, eftersom de flesta av tabellattributen och främmande nyckelattribut delar int typ.
Galaxyschemat
I datalager är ett galaxschema när två eller flera faktatabeller delar en eller flera dimensionstabeller. En anledning att använda detta schema är att spara diskutrymme. Vi har skapat ett exempel på ett galaxschema nedan:
Här har vi två faktatabeller, fact_sales och fact_supply_order , som direkt delar tredimensionella tabeller:dim_product , dim_employee och dim_time . Lägg märke till att även dim_store och dim_supplier dela samma uppslagstabell, dim_city .
Vi kommer att spara utrymme på det här sättet, men vi måste ha några saker i åtanke innan vi sammanfogar två datamarts (i det här fallet försäljnings- och leveransordrar) till ett galaxschema:
- Finns det någon logik bakom att gå med dem? T.ex. Skulle båda datamarterna användas av samma avdelning?
- Är vi säkra på att vi behöver precis samma dimension och granulering för båda datamarts?
Snöflingeschemat används ofta i datamodellering. Det kan vara rätt val i situationer där diskutrymme är viktigare än prestanda. Om vi vill ha en balans mellan utrymmesbesparing och prestanda kan vi använda starflake-schemat. Ändå beror rätt passform för ett specifikt problem på många parametrar. Det här är ett av de områden inom IT där vi kan "leka" med faktorer för att komma fram till den bästa lösningen.