Star Schema vs Snowflake Schema

I de två föregående artiklarna har vi övervägt de två vanligaste datalagermodellerna:stjärnschemat och snöflingaschemat. Idag ska vi undersöka skillnaderna mellan dessa två scheman och vi kommer att förklara när det är bättre att använda det ena eller det andra.

Stjärnschemat och snöflingaschemat är sätt att organisera datamarts eller hela datalager med hjälp av relationsdatabaser. Båda använder dimensionstabeller för att beskriva data som samlats i en faktatabell .

Alla säljer något, vare sig det är kunskap, en produkt eller en tjänst. Att lagra denna information, antingen i ett operativt system eller i ett rapporteringssystem, är också ett behov. Så vi kan förvänta oss att hitta någon typ av försäljningsmodell i nästan alla företags datalager.

Låt oss ta en titt på försäljningsmodellen i både stjärn- och snöflingschemat.

Stjärnschemat

Det mest uppenbara kännetecknet för stjärnschemat är att dimensionstabeller inte är normaliserade. I modellen ovan, den rosa fact_sales Tabell lagrar aggregerad data skapad från vår(a) operativa databas(er). De ljusblå borden är dimensionstabeller. Vi bestämde oss för att använda dessa fem dimensioner eftersom vi måste skapa rapporter med dem som parametrar. Granuleringen inuti varje dimension bestäms också av våra rapporteringsbehov.

Från den här modellen kan vi enkelt se varför det här schemat kallas "stjärnschemat":det ser ut som en stjärna, med dimensionstabellerna som omger den centrala faktatabellen.

The Snowflake Schema

Detta snöflingaschema lagrar exakt samma data som stjärnschemat. Faktatabellen har samma dimensioner som i exemplet med stjärnschemat. Den viktigaste skillnaden är att dimensionstabellerna i snöflingeschemat är normaliserade. Intressant nog kallas processen att normalisera dimensionstabeller för snöflingning.

Återigen, visuellt påminner snöflingeschemat oss om dess namne, med flera lager av dimensionstabeller som skapar en oregelbunden snöflingaliknande form.

Den första skillnaden:Normalisering

Som nämnts är normalisering en nyckelskillnad mellan stjärn- och snöflingsscheman. Angående detta finns det ett par saker att veta:

• Snöflingascheman kommer att använda mindre utrymme för att lagra dimensionstabeller. Detta beror på att som regel varje normaliserad databas producerar mycket färre redundanta poster .
• Denormaliserade datamodeller ökar chanserna för dataintegritetsproblem. Dessa problem kommer också att komplicera framtida ändringar och underhåll.
• För erfarna datamodellerare verkar snöflingeschemat mer logiskt organiserat än stjärnschemat. (Detta är min personliga åsikt, inget svårt faktum. :) )

Låt oss gå vidare till den andra stora skillnaden mellan dessa två scheman.

Den andra skillnaden:Frågekomplexitet

I våra två första artiklar demonstrerade vi en fråga som kunde användas på försäljningsmodellen för att få fram mängden av alla produkter av telefontyp som såldes i Berlins butiker under 2016.

Stjärnschemafrågan ser ut så här:

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_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

För att få samma resultat från snöflingaschemat måste vi använda den här frågan:

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

Snöflingaschemafrågan är naturligtvis mer komplex. Eftersom dimensionstabellerna är normaliserade måste vi gräva djupare för att få fram namnet på produkttypen och staden. Vi måste lägga till ytterligare en JOIN för varje ny nivå inom samma dimension.

I stjärnschemat sammanfogar vi bara faktatabellen med de dimensionstabeller vi behöver. Som mest har vi bara en JOIN per dimensionstabell. Och om vi inte använder en dimensionstabell behöver vi inte ens bry oss om det. I snöflingaschemafrågan vet vi inte hur djupt vi måste gå för att få rätt dimensionsnivå, så det komplicerar processen att skriva frågor.

Att slå samman två tabeller tar tid eftersom DMBS tar längre tid att behandla begäran. dim_store och dim_city bord är placerade nära varandra i vår modell, men de kanske inte finns någonstans nära varandra på skivan. Det finns en bättre möjlighet att data kommer fysiskt närmare på disken om den finns i samma bord.

I grund och botten kommer en fråga som körs mot ett snöflingaschema att köras långsammare. Men i de flesta fall kommer detta inte att utgöra ett problem:det spelar ingen större roll om vi får resultatet på en millisekund eller en sekund.

För snabbare saker och ting

För att påskynda rapporteringen kan vi:

• Aggregera data till den nivå vi behöver i rapporter. Detta kommer att komprimera data avsevärt. Vi måste skapa procedurer som omvandlar vår livedata så att den passar in i rapporteringsschemastrukturen (ETL-processen).
• Bygg ett centralt lagringsområde för alla företagets samlade data, inte bara försäljningsdata.
• Ge bara användarna den data de behöver för analys och rapporter.

Snöflinga vs. stjärnscheman:Vilket ska du använda?

Nu när vi har tittat på teori och frågehastigheter, låt oss gå rakt in i kärnan av saken:hur vet du vilket schema du ska använda i ett givet projekt?

Överväg att använda snöflingaschemat :

• I datalager. Eftersom lagret är Data Central för företaget kan vi spara mycket utrymme på detta sätt.
• När dimensionstabeller kräver en betydande mängd lagringsutrymme. I de flesta fall kommer faktatabellerna att vara de som tar det mesta av utrymmet. De kommer förmodligen också att växa mycket snabbare än dimensionstabeller. Men det finns vissa situationer där det inte gäller. Till exempel kan dimensionstabellerna innehålla många överflödiga men nödvändiga attribut. I vårt exempel använde vi stad attribut för att beskriva staden där butiken ligger. Tänk om vi ville ha en mycket mer detaljerad beskrivning av staden, inklusive befolkning, postnummer, demografiska data etc.? Beskriva andra underdimensioner – till exempel butik , region , delstat och land – med fler attribut skulle förvandla dim_store dimensionstabell till ett stort bord med mycket redundans.
• Om du använder verktyg som kräver ett snöflingaschema i bakgrunden. (Lyckligtvis stöder de flesta moderna verktyg både scheman och till och med galaxschemat.)

Överväg att använda stjärnschemat :

• I datamarts. Data marts är delmängder av data som tas ut från det centrala datalagret. De skapas vanligtvis för olika avdelningar och innehåller inte ens all historikdata. I den här inställningen är det inte en prioritet att spara lagringsutrymme.

  Å andra sidan förenklar stjärnschemat analys. Det handlar inte bara om frågeeffektivitet utan också om att förenkla framtida åtgärder för företagsanvändare. De kanske förstår databaser och vet hur man skriver frågor, men varför komplicera saker och ting och inkludera fler kopplingar om vi kan undvika det? En företagsanvändare kan ha en mallfråga som förenar faktatabellen med alla dimensionstabeller. Sedan behöver de bara lägga till lämpliga urval och grupperingar. (Detta tillvägagångssätt ligger nära Excels pivottabeller.)

• Om du använder verktyg som kräver ett stjärnschema i bakgrunden. (Återigen, detta brukar inte vara ett problem.)

Både stjärnschemat och snöflingaschemat är relationsmodeller som används för att organisera datalager och/eller datamarts. Oavsett hur lika de är, visar de två olika tillvägagångssätt och har sina egna fördelar och nackdelar. Personligen skulle jag gå med snöflingaschemat när jag implementerade ett datalager (för att spara lagringsutrymme) och med stjärnschemat för datamarts (för att göra livet enklare för företagsanvändare).