Snöflinga schema
Vid beräkning är ett snöflingaschema ett logiskt arrangemang av tabeller i en flerdimensionell databas så att entitetsrelationsdiagrammet liknar en snöflingaform . Snöflingeschemat representeras av centraliserade faktatabeller som är kopplade till flera dimensioner . "Snowflaking" är en metod för att normalisera dimensionstabellerna i ett stjärnschema . När den är helt normaliserad längs alla dimensionstabeller, liknar den resulterande strukturen en snöflinga med faktatabellen i mitten. Principen bakom snöflingning är normalisering av dimensionstabellerna genom att ta bort lågkardinalitetsattribut och bilda separata tabeller.
Snöflingaschemat liknar stjärnschemat. Men i snöflingeschemat normaliseras dimensioner till flera relaterade tabeller, medan stjärnschemats dimensioner denormaliseras med varje dimension representerad av en enda tabell. En komplex snöflingeform uppstår när dimensionerna för ett snöflingaschema är utarbetade, har flera nivåer av relationer, och de underordnade tabellerna har flera överordnade tabeller ("gafflar i vägen").
Vanliga användningsområden
Stjärn- och snöflingascheman finns oftast i dimensionella datalager och datamars där hastigheten för datahämtning är viktigare än effektiviteten av datamanipulationer. Som sådan är tabellerna i dessa scheman inte normaliserade mycket, och är ofta utformade på en normaliseringsnivå som är mindre än tredje normalformen .
Datanormalisering och lagring
Normalisering delar upp data för att undvika redundans (duplicering) genom att flytta vanliga grupper av data till nya tabeller. Normalisering tenderar därför att öka antalet tabeller som behöver sammanfogas för att utföra en given fråga, men minskar utrymmet som krävs för att lagra data och antalet platser där det behöver uppdateras om data ändras.
Ur utrymmeslagringssynpunkt är dimensionstabeller vanligtvis små jämfört med faktatabeller. Detta förnekar ofta de potentiella lagringsutrymmesfördelarna med stjärnschemat jämfört med snöflingeschemat. Exempel: En miljon försäljningstransaktioner i 300 butiker i 220 länder skulle resultera i 1 000 300 poster i ett stjärnschema (1 000 000 poster i faktatabellen och 300 poster i dimensionstabellen där varje land skulle anges explicit för varje butik i det landet). Ett mer normaliserat snöflingaschema med landsnycklar som hänvisar till en landstabell skulle bestå av samma faktatabell med 1 000 000 poster, en 300 skivbutikstabell med referenser till en landstabell med 220 poster. I det här fallet skulle stjärnschemat, även om det är ytterligare denormaliserat, endast minska antalet eller posterna med (försumbart) ~0,02 % (=[1 000 000+300] istället för [1 000 000+300+220])
Vissa databasutvecklare kompromissar genom att skapa ett underliggande snöflingaschema med vyer byggda ovanpå det som utför många av de nödvändiga kopplingarna för att simulera ett stjärnschema. Detta ger lagringsfördelarna som uppnås genom normalisering av dimensioner med den enkla fråga som stjärnschemat ger. Avvägningen är att att kräva att servern ska utföra de underliggande kopplingarna automatiskt kan resultera i en prestandaträff vid fråga samt extra kopplingar till tabeller som kanske inte är nödvändiga för att uppfylla vissa frågor. [ citat behövs ]
Fördelar
Snöflingeschemat är i samma familj som stjärnschemats logiska modell. Faktum stjärnschemat anses vara ett specialfall av snöflingeschemat. Snöflingaschemat ger vissa fördelar jämfört med stjärnschemat i vissa situationer, inklusive:
- Vissa OLAP multidimensionella databasmodelleringsverktyg är optimerade för snöflingscheman.
- Normalisering av attribut resulterar i lagringsbesparingar, avvägningen är ytterligare komplexitet i källfrågaanslutningar.
Nackdelar
Den primära nackdelen med snöflingeschemat är att de ytterligare nivåerna av attributnormalisering ökar komplexiteten i källförfrågekopplingar, jämfört med stjärnschemat .
Snowflake-scheman har, i motsats till platta enkelbordsdimensioner, kritiserats hårt. Deras mål antas vara en effektiv och kompakt lagring av normaliserad data, men detta är till den betydande kostnaden för dålig prestanda när man bläddrar i kopplingarna som krävs i denna dimension. Denna nackdel kan ha minskat under åren sedan den först upptäcktes, på grund av bättre frågeprestanda i webbläsarverktygen.
Jämfört med ett mycket normaliserat transaktionsschema tar snöflingeschemats denormalisering bort dataintegritetsgarantierna från normaliserade scheman. [ citat behövs ] Dataladdningar i snowflake-schemat måste vara mycket kontrollerade och hanterade för att undvika uppdatering och infoga anomalier.
Exempel
Exempelschemat som visas till höger är en snöflingad version av stjärnschemaexemplet som tillhandahålls i stjärnschemaartikeln .
Följande exempelfråga är snöflingaschemats motsvarighet till exempelkoden för stjärnschemat, som returnerar det totala antalet sålda TV-enheter per märke och land för 1997. Observera att frågan om snöflingaschema kräver många fler kopplingar än stjärnschemaversionen för att uppfylla även en enkel fråga. Fördelen med att använda snöflingeschemat i det här exemplet är att lagringskraven är lägre eftersom snöflingschemat eliminerar många dubbletter av värden från själva dimensionerna.
VÄLJ B . Brand , G . Land , SUMMA ( F. Units_Sold ) FROM Fact_Sales F INNER JOIN Dim_Date D ON F . _ Datum_Id = D . ID INNER JOIN Dim_Store S ON F . Store_Id = S . ID INNER JOIN Dim_Geography G ON S . Geografi_Id = G . ID INNER JOIN Dim_Product P ON F . Product_Id = P . ID INNER JOIN Dim_Brand B PÅ P . Brand_Id = B . Id INNER JOIN Dim_Product_Category C PÅ P . Product_Category_Id = C . ID VAR D . År = 1997 OCH C . Product_Category = 'tv' GRUPPER AV B . Brand , G . Land
Se även
Bibliografi
- Anahory, S.; D. Murray. Data Warehousing in the Real World: A Practical Guide for Building Decision Support Systems . Addison Wesley Professional.
- Kimball, Ralph (1996). Data Warehousing Toolkit . John Wiley.
externa länkar
- " Varför är Snowflake Schema en bra datalagerdesign?" av Mark Levene och George Loizou
- Omvänd Snowflake Joins