Meny

Skjematyper i datalagermodellering - Star & SnowFlake Schema

  • Hoved
  • Annen
  • Skjematyper i datalagermodellering - Star & SnowFlake Schema

schema types data warehouse modeling star snowflake schema

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne opplæringen forklarer forskjellige typer datalager. Lær hva som er stjerneskjema og snøfnuggskjema og forskjellen mellom stjerneskjema mot snøfnuggskjema:

I dette Date Warehouse Tutorials For Beginners , vi hadde en grundig titt på Dimensjonal datamodell i datavarehus i vår forrige opplæring.

I denne opplæringen vil vi lære alt om datavarehusskjemaer som brukes til å strukturere datamarkeder (eller) datalagertabeller.

beste gratis pc renere windows 7

La oss begynne!!

Datalagerskjemaer

Målgruppe

  • Datalager / ETL-utviklere og testere.
  • Database fagpersoner med grunnleggende kunnskap om databasekonsepter.
  • Databaseadministratorer / big data-eksperter som ønsker å forstå Data warehouse / ETL-områder.
  • Høgskoleutdannede / Freshers som leter etter jobber med datalager.

Hva du vil lære:

Data Warehouse Schema

I et datalager brukes et skjema for å definere måten å organisere systemet på med alle databaseenhetene (faktatabeller, dimensjonstabeller) og deres logiske tilknytning.

Her er de forskjellige typene skjemaer i DW:

  1. Stjerneplan
  2. SnowFlake-skjema
  3. Galaxy Diagram
  4. Stjerneklyngeskjema

# 1) Stjerneplan

Dette er det enkleste og mest effektive skjemaet i et datalager. Et faktatabell i midten omgitt av flere dimensjonstabeller ligner en stjerne i stjerneskjema-modellen.

Faktatabellen opprettholder en-til-mange-relasjoner med alle dimensjonstabellene. Hver rad i en faktatabell er knyttet til dimensjonstabellrader med en fremmednøkkelreferanse.

På grunn av ovennevnte grunn er navigering mellom tabellene i denne modellen lett for å spørre aggregerte data. En sluttbruker kan enkelt forstå denne strukturen. Derfor støtter alle Business Intelligence (BI) -verktøyene sterkt skjemamodellen.

Mens du designer stjerneskjemaer, dimensjoneres tabellene målrettet. De er brede med mange attributter for å lagre kontekstuelle data for bedre analyse og rapportering.

Fordeler med stjerneskjema

  • Spørringer bruker veldig enkle sammenføyninger mens data hentes, og dermed økes spørringsytelsen.
  • Det er enkelt å hente data for rapportering, når som helst i en hvilken som helst periode.

Ulemper ved stjerneskjema

  • Hvis det er mange endringer i kravene, anbefales ikke det eksisterende stjerneskjemaet å modifisere og gjenbruke i det lange løp.
  • Dataredundans er mer ettersom tabeller ikke er hierarkisk delt.

Et eksempel på et stjerneskjema er gitt nedenfor.

Stjerneskjema - Eksempel

Spørring om et stjerneskjema

En sluttbruker kan be om en rapport ved hjelp av Business Intelligence-verktøy. Alle slike forespørsler vil bli behandlet ved å opprette en kjede av 'SELECT queries' internt. Utførelsen av disse spørsmålene vil ha en innvirkning på gjennomføringstiden for rapporten.

Fra stjerneskjemaeksemplet ovenfor, hvis en bedriftsbruker vil vite hvor mange romaner og DVDer som er solgt i delstaten Kerala i januar i 2018, kan du bruke spørringen som følger på stjerneskjema tabeller:

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

Resultater:

Produktnavn Mengde_Solgt
7Alle kan enkelt forstå og utforme skjemaet.Det er vanskelig å forstå og utforme skjemaet.
Romaner12.702
DVDer32,919

Håper du forsto hvor enkelt det er å spørre etter et stjerneskjema.

# 2) SnowFlake-skjema

Stjerneskjema fungerer som innspill for å designe et SnowFlake-skjema. Snøflak er en prosess som normaliserer alle dimensjonstabellene fra et stjerneskjema.

Arrangementet av en faktatabell i midten omgitt av flere hierarkier av dimensjonstabeller ser ut som en SnowFlake i SnowFlake-skjemamodellen. Hver faktatabellrad er assosiert med dimensjonstabellrader med en fremmednøkkelreferanse.

Mens du designer SnowFlake-skjemaer, er dimensjonstabellene målrettet normalisert. Utenlandske nøkler blir lagt til hvert nivå i dimensjonstabellene for å koble til det overordnede attributtet. Kompleksiteten i SnowFlake-skjemaet er direkte proporsjonal med hierarkinivåene i dimensjonstabellene.

Fordeler med SnowFlake-skjema:

  • Dataredundans fjernes fullstendig ved å opprette nye dimensjonstabeller.
  • Sammenlignet med stjerneskjema brukes mindre lagringsplass i dimensjonstabellene Snow Flaking.
  • Det er enkelt å oppdatere (eller) vedlikeholde Snow Flaking-tabellene.

Ulemper med SnowFlake Schema:

  • På grunn av normaliserte dimensjonstabeller, må ETL-systemet laste inn antall bord.
  • Det kan hende du trenger kompliserte sammenføyninger for å utføre et spørsmål på grunn av antall tabeller som er lagt til. Derfor vil spørringsytelsen bli redusert.

Et eksempel på et SnowFlake-skjema er gitt nedenfor.

Snøfnuggskjema

Dimensjonstabellene i ovenstående SnowFlake-diagram er normalisert som forklart nedenfor:

  • Datodimensjon normaliseres i kvartalsvise, månedlige og ukentlige tabeller ved å legge utenlandske nøkkel-ID-er i datatabellen.
  • Butikkdimensjonen er normalisert til å omfatte tabellen for staten.
  • Produktdimensjonen normaliseres til merkevare.
  • I kundedimensjonen flyttes attributtene knyttet til byen til den nye bytabellen ved å legge igjen en utenlandsk nøkkel-id i kundetabellen.

På samme måte kan en enkelt dimensjon opprettholde flere nivåer av hierarki.

Ulike nivåer av hierarkier fra diagrammet ovenfor kan refereres til som følger:

  • Kvartals-ID, Månedlig ID og Ukentlig ID er de nye surrogatnøklene som er opprettet for dato-dimensjonshierarkier, og de er lagt til som fremmede nøkler i tabellen dato-dimensjon.
  • State id er den nye surrogatnøkkelen som er opprettet for Store dimensjonshierarki, og den er lagt til som den fremmede nøkkelen i Store dimensjonstabellen.
  • Merke-id er den nye surrogatnøkkelen som er opprettet for produktdimensjonshierarkiet, og den er lagt til som den fremmede nøkkelen i tabellen Produktdimensjon.
  • By-id er den nye surrogatnøkkelen som er opprettet for kundedimensjonshierarki, og den er lagt til som den fremmede nøkkelen i kundedimensjonstabellen.

Spørring av et snøfnuggskjema

Vi kan generere samme type rapporter for sluttbrukere som for stjerneskjema-strukturer med SnowFlake-skjemaer også. Men spørsmålene er litt kompliserte her.

Fra ovenstående SnowFlake-skjemaeksempel skal vi generere den samme spørringen som vi har designet under eksemplet på Star-skjema-spørring.

Det er hvis en bedriftsbruker vil vite hvor mange romaner og DVDer som er solgt i delstaten Kerala i januar i 2018, kan du bruke spørringen som følger på SnowFlake-skjemaetabeller.

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

Resultater:

Produktnavn Mengde_Solgt
Romaner12.702
DVDer32,919

Poeng å huske når du spør etter Star (eller) SnowFlake Schema Tabeller

Ethvert spørsmål kan utformes med strukturen nedenfor:

VELG Klausul:

  • Attributtene som er spesifisert i select-setningen vises i søkeresultatene.
  • Select-setningen bruker også grupper for å finne de aggregerte verdiene, og derfor må vi bruke group by clause i where-tilstanden.

FRA Klausul:

  • Alle viktige faktatabeller og dimensjonstabeller må velges i henhold til konteksten.

HVOR Klausul:

  • Egnede dimensjonsattributter er nevnt i hvor-setningen ved å slutte seg til faktatabellattributtene. Surrogatnøkler fra dimensjonstabellene er forbundet med de respektive utenlandske nøklene fra faktatabellene for å fikse rekkevidden av data som skal spørres. Se eksemplet på det ovennevnte stjerneskjemaet for å forstå dette. Du kan også filtrere data i selve fra-setningen hvis du bruker indre / ytre sammenføyninger der, som skrevet i eksempelet på SnowFlake-skjemaet.
  • Dimensjonsattributter er også nevnt som begrensninger for data i hvor-setningen.
  • Ved å filtrere dataene med alle trinnene ovenfor, returneres passende data for rapportene.

I henhold til bedriftens behov kan du legge til (eller) fjerne fakta, dimensjoner, attributter og begrensninger i et stjerneskjema (eller) SnowFlake-skjema-spørring ved å følge strukturen ovenfor. Du kan også legge til underspørringer (eller) slå sammen forskjellige søkeresultater for å generere data for eventuelle komplekse rapporter.

# 3) Galaxy Diagram

Et galakseskjema er også kjent som faktakonstellasjonsskjema. I dette skjemaet deler flere faktatabeller samme dimensjonstabeller. Ordningen av faktabord og dimensjonstabeller ser ut som en samling stjerner i Galaxy-skjemamodellen.

De delte dimensjonene i denne modellen er kjent som Konformerte dimensjoner.

Denne typen skjema brukes til sofistikerte krav og til aggregerte faktatabeller som er mer komplekse for å bli støttet av stjerneskjemaet (eller) SnowFlake-skjemaet. Dette skjemaet er vanskelig å vedlikeholde på grunn av dets kompleksitet.

Et eksempel på Galaxy Schema er gitt nedenfor.

Galaxy Schema - Eksempel

# 4) Skjema for stjerneklynger

Et SnowFlake-skjema med mange dimensjonstabeller kan trenge mer komplekse sammenføyninger mens du spør. Et stjerneskjema med færre dimensjonstabeller kan ha mer redundans. Derfor kom et stjerneklyngeskjema inn i bildet ved å kombinere funksjonene i de to skjemaene ovenfor.

Stjerneskjema er basen for å utforme et stjerneklyngeskjema, og få viktige dimensjonstabeller fra stjerneskjemaet er snøflakket, og dette danner i sin tur en mer stabil skjemastruktur.

Et eksempel på et stjerneklyngeskjema er gitt nedenfor.

Stjerneklyngeskjema

Hva er bedre snøfnuggskjema eller stjerneskjema?

Datalagerplattformen og BI-verktøyene som brukes i DW-systemet ditt, vil spille en viktig rolle for å bestemme hvilket passende skjema som skal utformes. Star og SnowFlake er de mest brukte skjemaene i DW.

Stjerneskjema foretrekkes hvis BI-verktøy lar forretningsbrukere enkelt samhandle med tabellstrukturene med enkle spørsmål. SnowFlake-skjemaet foretrekkes hvis BI-verktøy er mer kompliserte for forretningsbrukerne å samhandle direkte med tabellstrukturene på grunn av flere sammenføyninger og komplekse spørsmål.

Du kan gå videre med SnowFlake-skjemaet enten hvis du vil spare litt lagringsplass eller hvis DW-systemet ditt har optimaliserte verktøy for å designe dette skjemaet.

Star Schema Vs Snowflake Schema

Nedenfor er de viktigste forskjellene mellom stjerneskjema og snøflakeskjema.

S. nr Stjerneplan Snow Flake Schema
1Dataredundans er mer.Dataredundans er mindre.
toLagringsplass for dimensjonstabeller er mer.Lagringsplass for dimensjonstabeller er relativt mindre.
3Inneholder avnormaliserte dimensjonstabeller.Inneholder normaliserte dimensjonstabeller.
4Enkelt faktabord er omgitt av flere dimensjonstabeller.Enkelt faktatabell er omgitt av flere hierarkier av dimensjonstabeller.
5Spørringer bruker direkte sammenkoblinger mellom fakta og dimensjoner for å hente dataene.Spørringer bruker komplekse sammenkoblinger mellom fakta og dimensjoner for å hente dataene.
6Spørringstid er mindre.Spørringstid er mer.
8Bruker tilnærming ovenfra og ned.Bruker nedenfra og opp tilnærming.

Konklusjon

Vi håper du har fått god forståelse av forskjellige typer datavarehusskjemaer, sammen med fordelene og ulempene fra denne opplæringen.

Vi lærte også hvordan Star Schema og SnowFlake Schema kan spørres, og hvilket skjema som er å velge mellom disse to sammen med forskjellene.

Følg med på vår kommende opplæring for å vite mer om Data Mart i ETL !!

=> Se opp den enkle opplæringsserien for datalagring her.

Anbefalt lesing

^