Meny

Schematyper i datalagermodellering - Star & SnowFlake Schema

  • Huvud
  • Övrig
  • Schematyper i datalagermodellering - Star & SnowFlake Schema

schema types data warehouse modeling star snowflake schema

Prova Vårt Instrument För Att Eliminera Problem

Denna handledning förklarar olika typer av scheman för datalager. Lär dig vad som är Star Schema & Snowflake Schema och skillnaden mellan Star Schema Vs Snowflake Schema:

I denna Tutorials för datalager för nybörjare , vi hade en djupgående titt på Dimensionell datamodell i datalager i vår tidigare handledning.

I den här självstudien lär vi oss allt om Data Warehouse Schemas som används för att strukturera datamärken (eller) datalagertabeller.

bästa gratis pc renare windows 7

Låt oss börja!!

Datalagringsscheman

Målgrupp

  • Datalager / ETL-utvecklare och testare.
  • Databasproffs med grundläggande kunskap om databaskoncept.
  • Databasadministratörer / big data-experter som vill förstå datalager / ETL-områden.
  • Högskoleexamen / nybörjare som letar efter datalagerjobb.

Vad du kommer att lära dig:

Schema för datalager

I ett datalager används ett schema för att definiera sättet att organisera systemet med alla databasenheter (faktatabeller, dimensionstabeller) och deras logiska koppling.

Här är de olika typerna av scheman i DW:

  1. Stjärnschema
  2. SnowFlake Schema
  3. Galaxdiagram
  4. Star Cluster Schema

# 1) Stjärnschema

Detta är det enklaste och mest effektiva schemat i ett datalager. En faktatabell i mitten omgiven av flera dimensionstabeller liknar en stjärna i Star Schema-modellen.

Faktatabellen upprätthåller en-till-många-relationer med alla dimensionstabellerna. Varje rad i en faktatabell är associerad med dess dimensionstabellrader med en referens för främmande nycklar.

På grund av ovanstående anledning är navigering mellan tabellerna i den här modellen lätt för att fråga aggregerade data. En slutanvändare kan lätt förstå denna struktur. Därför stöder alla Business Intelligence (BI) -verktygen starkt Star-schemamodellen.

När du utformar stjärnscheman normaliseras dimensionstabellerna medvetet. De är breda med många attribut för att lagra kontextuppgifterna för bättre analys och rapportering.

Fördelar med stjärnschema

  • Frågor använder mycket enkla sammanfogningar medan data hämtas och därigenom ökas frågan.
  • Det är enkelt att hämta data för rapportering, när som helst under vilken period som helst.

Nackdelar med stjärnschema

  • Om det finns många förändringar i kraven rekommenderas inte det befintliga stjärnschemat att ändra och återanvända på lång sikt.
  • Dataredundans är mer eftersom tabeller inte är hierarkiskt uppdelade.

Ett exempel på ett stjärnschema ges nedan.

Star Schema - Exempel

Fråga efter ett stjärnschema

En slutanvändare kan begära en rapport med hjälp av Business Intelligence-verktyg. Alla sådana förfrågningar kommer att behandlas genom att skapa en kedja med 'SELECT-frågor' internt. Utförandet av dessa frågor kommer att påverka rapportens exekveringstid.

Från ovanstående stjärnschemaexempel, om en företagsanvändare vill veta hur många romaner och DVD-skivor som har sålts i delstaten Kerala i januari 2018, kan du tillämpa frågan på följande sätt i stjärnscheman:

SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Product pdim, Sales sfact, Store sdim, Date ddim WHERE sfact.product_id = pdim.product_id AND sfact.store_id = sdim.store_id AND sfact.date_id = ddim.date_id AND sdim.state = 'Kerala' AND ddim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name

Resultat:

Produktnamn Kvantitet_Säljs
7Vem som helst kan lätt förstå och utforma schemat.Det är svårt att förstå och utforma schemat.
Romaner12,702
DVD-skivor32,919

Hoppas att du förstod hur lätt det är att fråga efter ett Star Schema.

# 2) SnowFlake Schema

Stjärnschema fungerar som en input för att utforma ett SnowFlake-schema. Snöflingning är en process som helt normaliserar alla dimensionstabeller från ett stjärnschema.

Arrangemanget av en faktatabell i mitten omgiven av flera hierarkier av dimensionstabeller ser ut som en SnowFlake i SnowFlake-schemamodellen. Varje faktatabellrad är associerad med dess dimensionstabellrader med en referens för främmande nycklar.

När du utformar SnowFlake-scheman normaliseras dimensionstabellerna medvetet. Utländska nycklar läggs till på varje nivå i dimensionstabellerna för att länka till dess överordnade attribut. Komplexiteten i SnowFlake-schemat är direkt proportionell mot hierarkinivåerna i dimensionstabellerna.

Fördelar med SnowFlake Schema:

  • Dataredundans tas bort helt genom att skapa nya dimensionstabeller.
  • Jämfört med stjärnschema används mindre lagringsutrymme i dimensionstabellerna Snow Flaking.
  • Det är lätt att uppdatera (eller) underhålla Snow Flaking-tabellerna.

Nackdelar med SnowFlake Schema:

  • På grund av normaliserade dimensionstabeller måste ETL-systemet ladda antalet tabeller.
  • Du kan behöva komplexa sammanfogningar för att utföra en fråga på grund av antalet tillagda tabeller. Därför försämras sökprestanda.

Ett exempel på ett SnowFlake-schema ges nedan.

Snöflingaschema

Dimensionstabellerna i SnowFlake-diagrammet ovan normaliseras enligt nedan:

  • Datumdimension normaliseras till kvartals-, månads- och veckotabeller genom att lämna utländska nyckel-id i datumtabellen.
  • Butiksdimensionen normaliseras till att omfatta tabellen för stat.
  • Produktdimensionen normaliseras till varumärke.
  • I kunddimensionen flyttas attributen som är kopplade till staden till den nya stadstabellen genom att lämna ett främmande nyckel-id i kundtabellen.

På samma sätt kan en enda dimension upprätthålla flera hierarkinivåer.

Olika nivåer av hierarkier från ovanstående diagram kan hänvisas till enligt följande:

  • Kvartals-id, månads-id och vecko-id är de nya surrogatnycklarna som skapas för datumdimensionshierarkier och de har lagts till som främmande nycklar i datumdimensionstabellen.
  • Tillstånds-id är den nya surrogatnyckeln som skapats för butiksdimensionshierarkin och den har lagts till som främmande nyckel i butikens dimensionstabell.
  • Varumärkes-id är den nya surrogatnyckeln som skapats för produktdimensionshierarkin och den har lagts till som främmande nyckel i tabellen Produktdimension.
  • Stad-id är den nya surrogatnyckeln som skapats för kunddimensionshierarkin och den har lagts till som främmande nyckel i kunddimensionstabellen.

Fråga efter ett snöflingaschema

Vi kan generera samma typ av rapporter för slutanvändare som för stjärnskemastrukturer med SnowFlake-scheman också. Men frågorna är lite komplicerade här.

Från ovanstående SnowFlake-schemaexempel kommer vi att generera samma fråga som vi har utformat under exemplet Star-schemafråga.

Det är om en företagsanvändare vill veta hur många romaner och DVD-skivor som har sålts i delstaten Kerala i januari 2018, kan du tillämpa frågan enligt följande på SnowFlake-schematabeller.

SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Sales sfact INNER JOIN Product pdim ON sfact.product_id = pdim.product_id INNER JOIN Store sdim ON sfact.store_id = sdim.store_id INNER JOIN State stdim ON sdim.state_id = stdim.state_id INNER JOIN Date ddim ON sfact.date_id = ddim.date_id INNER JOIN Month mdim ON ddim.month_id = mdim.month_id WHERE stdim.state = 'Kerala' AND mdim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name

Resultat:

Produktnamn Kvantitet_Säljs
Romaner12,702
DVD-skivor32,919

Poäng att komma ihåg när du frågar efter Star (eller) SnowFlake Schema Tabeller

Varje fråga kan utformas med nedanstående struktur:

VÄLJ Klausul:

  • Attributen som anges i select-satsen visas i frågeresultaten.
  • Select-uttalandet använder också grupper för att hitta de aggregerade värdena och därför måste vi använda grupp för paragraf i var-tillståndet.

FRÅN Klausul:

  • Alla väsentliga faktatabeller och dimensionstabeller måste väljas enligt sammanhanget.

VAR Klausul:

  • Lämpliga dimensionsattribut nämns i var-paragrafen genom att gå med faktatabellattributen. Surrogatnycklar från dimensionstabellerna är förenade med respektive främmande nycklar från faktatabellerna för att fixa det intervall av data som ska ifrågasättas. Vänligen hänvisa till ovanstående skriftliga frågeexempel på stjärnschema för att förstå detta. Du kan också filtrera data i själva från-klausulen om du använder inre / yttre kopplingar där, som skrivet i schemaexemplet SnowFlake.
  • Dimensionsattribut nämns också som begränsningar för data i var-klausulen.
  • Genom att filtrera data med alla ovanstående steg returneras lämplig data för rapporterna.

Enligt företagets behov kan du lägga till (eller) ta bort fakta, dimensioner, attribut och begränsningar i ett stjärnschema (eller) SnowFlake-schemafråga genom att följa ovanstående struktur. Du kan också lägga till underfrågor (eller) slå samman olika frågeresultat för att generera data för alla komplexa rapporter.

# 3) Galaxy Diagram

Ett galaxschema är också känt som Fact Constellation Schema. I detta schema delar flera faktatabeller samma dimensionstabeller. Arrangemanget av faktabord och dimensionstabeller ser ut som en samling stjärnor i Galaxy-schemamodellen.

De delade dimensionerna i denna modell kallas Conformed dimensions.

Den här typen av schema används för sofistikerade krav och för aggregerade faktatabeller som är mer komplexa för att stödjas av Star-schemat (eller) SnowFlake-schemat. Detta schema är svårt att upprätthålla på grund av dess komplexitet.

Ett exempel på Galaxy Schema ges nedan.

Galaxy Schema - Exempel

# 4) Star Cluster Schema

Ett SnowFlake-schema med många dimensionstabeller kan behöva mer komplexa sammanfogningar under frågan. Ett stjärnschema med färre dimensionstabeller kan ha mer redundans. Därför kom ett stjärnklusterschema in i bilden genom att kombinera funktionerna i ovanstående två scheman.

Stjärnschema är basen för att utforma ett stjärnklusterschema och få viktiga dimensionstabeller från stjärnschemat är snöflingor och detta bildar i sin tur en mer stabil schemastruktur.

Ett exempel på ett stjärnklusterschema ges nedan.

Star Cluster Schema

Vilket är bättre snöflingaschema eller stjärnschema?

Datalagerplattformen och BI-verktygen som används i ditt DW-system kommer att spela en viktig roll för att bestämma lämpligt schema som ska utformas. Star och SnowFlake är de mest använda scheman i DW.

Stjärnskema föredras om BI-verktyg gör det möjligt för företagsanvändare att enkelt interagera med tabellstrukturerna med enkla frågor. SnowFlake-schemat föredras om BI-verktyg är mer komplicerade för affärsanvändarna att interagera direkt med tabellstrukturerna på grund av fler sammanfogningar och komplexa frågor.

Du kan gå vidare med SnowFlake-schemat antingen om du vill spara lite lagringsutrymme eller om ditt DW-system har optimerade verktyg för att utforma detta schema.

Star Schema Vs Snowflake Schema

Nedan följer de viktigaste skillnaderna mellan Star schema och SnowFlake schema.

S. nr Stjärnschema Snow Flake Schema
ettDataredundans är mer.Dataredundans är mindre.
tvåLagringsutrymme för dimensionstabeller är mer.Förvaringsutrymme för dimensionstabeller är jämförelsevis mindre.
3Innehåller avnormaliserade dimensionstabeller.Innehåller normaliserade dimensionstabeller.
4Enkelt faktatabell omges av flera dimensionstabeller.Enstaka faktatabell omges av flera hierarkier av dimensionstabeller.
5Frågor använder direkt kopplingar mellan fakta och dimensioner för att hämta data.Frågor använder komplexa sammanfogningar mellan fakta och dimensioner för att hämta data.
6Frågekörningstiden är mindre.Frågan för körningstid är längre.
8Använder uppifrån och ner tillvägagångssätt.Använder bottom-up-tillvägagångssätt.

Slutsats

Vi hoppas att du har en god förståelse för olika typer av datalagringsscheman, tillsammans med deras fördelar och nackdelar från denna handledning.

Vi lärde oss också hur Star Schema och SnowFlake Schema kan ifrågasättas, och vilket schema som ska väljas mellan dessa två tillsammans med deras skillnader.

Håll koll på vår kommande handledning för att lära dig mer om Data Mart i ETL !!

=> Se upp den enkla utbildningsserien för datalagring här.

Rekommenderad läsning

^