Menu

Skema typer i datalager modellering - Star & SnowFlake skema

  • Vigtigste
  • Andet
  • Skema typer i datalager modellering - Star & SnowFlake skema

schema types data warehouse modeling star snowflake schema

Prøv Vores Instrument Til At Fjerne Problemer

Denne vejledning forklarer forskellige typer af datalagerskemaer. Lær hvad der er stjerneskema og snefnugskema og forskellen mellem stjerneskema og snefnugskema:

I denne Datalagervejledninger til begyndere , vi havde et dybtgående kig på Dimensional datamodel i datalager i vores tidligere tutorial.

I denne vejledning lærer vi alt om Data Warehouse Schemas, der bruges til at strukturere data marts (eller) data warehouse-tabeller.

top 10 websteder at se anime

Lad os begynde!!

Datalagerskemaer

Målgruppe

  • Datalager / ETL-udviklere og testere.
  • Databaseprofessionelle med grundlæggende viden om databasekoncepter.
  • Databaseadministratorer / big data-eksperter, der ønsker at forstå Data warehouse / ETL-områder.
  • College kandidater / Freshers, der er på udkig efter datalagerjob.

Hvad du vil lære:

Data Warehouse Schema

I et datalager bruges et skema til at definere måden at organisere systemet på med alle databaseenheder (faktatabeller, dimensionstabeller) og deres logiske tilknytning.

Her er de forskellige typer skemaer i DW:

  1. Stjerneplan
  2. SnowFlake-skema
  3. Galaxy Diagram
  4. Star Cluster Schema

# 1) Stjerneplan

Dette er det enkleste og mest effektive skema i et datalager. En faktatabel i midten omgivet af flere dimensionstabeller ligner en stjerne i Star Schema-modellen.

Faktatabellen opretholder en-til-mange forhold med alle dimensionstabellerne. Hver række i en faktatabel er knyttet til dens dimensionstabelrækker med en fremmednøglehenvisning.

På grund af ovenstående er navigering mellem tabellerne i denne model let til forespørgsel på aggregerede data. En slutbruger kan let forstå denne struktur. Derfor understøtter alle Business Intelligence (BI) værktøjerne stærkt Star-skema-modellen.

Under udformningen af ​​stjerneskemaer er dimensionstabellerne målrettet de-normaliserede. De er brede med mange attributter til at gemme de kontekstuelle data til bedre analyse og rapportering.

Fordele ved stjerneskema

  • Forespørgsler bruger meget enkle sammenføjninger, mens data hentes, og dermed øges forespørgslens ydeevne.
  • Det er nemt at hente data til rapportering til enhver tid i enhver periode.

Ulemper ved stjerneskema

  • Hvis der er mange ændringer i kravene, anbefales det ikke, at det eksisterende stjerneskema ændres og genbruges i det lange løb.
  • Data redundans er mere, da tabeller ikke er hierarkisk opdelt.

Et eksempel på et stjerneskema er givet nedenfor.

Stjerneskema - Eksempel

Forespørgsel om et stjerneskema

En slutbruger kan anmode om en rapport ved hjælp af Business Intelligence-værktøjer. Alle sådanne anmodninger behandles ved at oprette en kæde af 'SELECT forespørgsler' internt. Udførelsen af ​​disse forespørgsler vil have en indvirkning på rapportens udførelsestid.

Fra ovenstående stjerneskemaeksempel, hvis en forretningsbruger vil vide, hvor mange romaner og dvd'er der er solgt i staten Kerala i januar i 2018, kan du anvende forespørgslen som følger på stjerneskema-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 Mængde_Solgt
7Alle kan let forstå og designe skemaet.Det er svært at forstå og designe skemaet.
Romaner12.702
DVD'er32.919

Håber du forstod, hvor let det er at forespørge om et stjerneskema.

# 2) SnowFlake-skema

Stjerneskema fungerer som et input til at designe et SnowFlake-skema. Sne flager er en proces, der fuldstændigt normaliserer alle dimensionstabellerne fra et stjerneskema.

Arrangementet af en faktatabel i midten omgivet af flere hierarkier af dimensionstabeller ligner en SnowFlake i SnowFlake-skemamodellen. Hver faktatabelrækker er knyttet til dens dimensionstabelrækker med en fremmednøglereference.

Mens du designer SnowFlake-skemaer, er dimensionstabellerne målrettet normaliseret. Udenlandske nøgler føjes til hvert niveau i dimensionstabellerne for at linke til dets overordnede attribut. Kompleksiteten i SnowFlake-skemaet er direkte proportional med hierarkiniveauerne i dimensionstabellerne.

Fordele ved SnowFlake-skema:

  • Dataredundans fjernes fuldstændigt ved at oprette nye dimensionstabeller.
  • Sammenlignet med stjerneskemaet bruges mindre lagerplads i dimensionerne i Snow Flaking.
  • Det er let at opdatere (eller) vedligeholde Snow Flaking-tabellerne.

Ulemper ved SnowFlake-skemaet:

  • På grund af normaliserede dimensionstabeller skal ETL-systemet indlæse antallet af tabeller.
  • Du har muligvis brug for komplekse sammenføjninger for at udføre en forespørgsel på grund af antallet af tilføjede tabeller. Derfor vil forespørgselens ydeevne blive forringet.

Et eksempel på et SnowFlake-skema er givet nedenfor.

Snowflake Schema

Dimensionstabellerne i ovenstående SnowFlake-diagram er normaliseret som forklaret nedenfor:

  • Datodimension normaliseres i kvartals-, måned- og ugentabeller ved at lade udenlandske nøgle-id'er i datatabellen.
  • Butiksdimensionen er normaliseret til at omfatte tabellen for tilstand.
  • Produktdimensionen normaliseres til Brand.
  • I kundedimensionen flyttes attributterne, der er knyttet til byen, ind i den nye bytabel ved at efterlade et fremmed nøgle-id i kundetabellen.

På samme måde kan en enkelt dimension opretholde flere niveauer af hierarki.

Forskellige niveauer af hierarkier fra ovenstående diagram kan henvises til som følger:

  • Kvartals-id, Månedlig id og Ugentlig id er de nye surrogatnøgler, der oprettes til dato-dimensionshierarkier, og de er tilføjet som fremmede nøgler i tabellen Dato-dimension.
  • Tilstands-id er den nye surrogatnøgle, der er oprettet til Store-dimensionshierarki, og den er blevet tilføjet som den fremmede nøgle i Store-dimensionstabellen.
  • Brand-id er den nye surrogatnøgle, der er oprettet til produktdimensionhierarkiet, og den er tilføjet som den fremmede nøgle i tabellen Produktdimension.
  • By-id er den nye surrogatnøgle oprettet til kundedimensionshierarki, og den er tilføjet som den fremmede nøgle i kundedimensionstabellen.

Forespørgsel på et snefnugskema

Vi kan generere den samme type rapporter for slutbrugere som for stjerneskemastrukturer med SnowFlake-skemaer. Men forespørgslerne er lidt komplicerede her.

Fra ovenstående eksempel på SnowFlake-skemaet genererer vi den samme forespørgsel, som vi har designet under eksemplet på stjerneskemaforespørgsel.

Det er, hvis en forretningsbruger vil vide, hvor mange romaner og dvd'er der er solgt i staten Kerala i januar i 2018, kan du anvende forespørgslen som følger på SnowFlake-skemaetabeller.

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 Mængde_Solgt
Romaner12.702
DVD'er32.919

Point, du skal huske, når du forespørger på stjerne- (eller) SnowFlake-skema-tabeller

Enhver forespørgsel kan designes med nedenstående struktur:

VÆLG Klausul:

  • De attributter, der er angivet i select-klausulen, vises i forespørgselsresultaterne.
  • Select-udsagnet bruger også grupper til at finde de aggregerede værdier, og derfor skal vi bruge group by clause i hvor-tilstanden.

FRA klausul:

  • Alle væsentlige faktatabeller og dimensionstabeller skal vælges i henhold til konteksten.

HVOR Klausul:

  • Passende dimensionsattributter er nævnt i hvor-klausulen ved at slutte sig til faktatabelattributterne. Surrogatnøgler fra dimensionstabellerne er forbundet med de respektive udenlandske nøgler fra faktatabellerne for at rette det dataområde, der skal forespørges. Se det ovennævnte eksempler på forespørgsel om stjerneskema for at forstå dette. Du kan også filtrere data i selve fra-klausulen, hvis du bruger indre / ydre sammenkædninger der, som skrevet i eksemplet på SnowFlake-skemaet.
  • Dimensionsattributter nævnes også som begrænsninger for data i hvor-klausulen.
  • Ved at filtrere dataene med alle ovenstående trin returneres passende data til rapporterne.

I henhold til forretningsbehovet kan du tilføje (eller) fjerne fakta, dimensioner, attributter og begrænsninger til et stjerneskema (eller) SnowFlake-skemaforespørgsel ved at følge ovenstående struktur. Du kan også tilføje underforespørgsler (eller) flette forskellige forespørgselsresultater for at generere data til eventuelle komplekse rapporter.

# 3) Galaxy Diagram

Et galakse-skema er også kendt som Fact Constellation Schema. I dette skema deler flere faktatabeller de samme dimensionstabeller. Arrangementet af faktaborde og dimensionstabeller ligner en samling af stjerner i Galaxy-skema-modellen.

De delte dimensioner i denne model er kendt som konformerede dimensioner.

Denne type skema bruges til sofistikerede krav og til aggregerede faktatabeller, der er mere komplekse til at blive understøttet af stjerneskemaet (eller) SnowFlake-skemaet. Dette skema er vanskeligt at vedligeholde på grund af dets kompleksitet.

Et eksempel på Galaxy Schema er givet nedenfor.

Galaxy Schema - Eksempel

# 4) Stjerneklyngeskema

Et SnowFlake-skema med mange dimensionstabeller kan have brug for mere komplekse sammenføjninger under forespørgsel. Et stjerneskema med færre dimensionstabeller kan have mere redundans. Derfor kom et stjerneklyngeskema ind i billedet ved at kombinere funktionerne i ovenstående to skemaer.

Stjerneskema er basen til at designe et stjerneklyngeskema, og få vigtige dimensionstabeller fra stjerneskemaet er snefnug, og dette danner igen en mere stabil skemastruktur.

Et eksempel på et stjerneklyngeskema er givet nedenfor.

Star Cluster Schema

Hvilket er bedre snefnugskema eller stjerneskema?

Datalagerplatformen og BI-værktøjerne, der bruges i dit DW-system, spiller en vigtig rolle i beslutningen om det passende skema, der skal designes. Star og SnowFlake er de hyppigst anvendte skemaer i DW.

Stjerneskema foretrækkes, hvis BI-værktøjer giver forretningsbrugere mulighed for let at interagere med tabelstrukturer med enkle forespørgsler. SnowFlake-skemaet foretrækkes, hvis BI-værktøjer er mere komplicerede for forretningsbrugere at interagere direkte med tabelstrukturer på grund af flere sammenføjninger og komplekse forespørgsler.

Du kan gå videre med SnowFlake-skemaet, enten hvis du vil spare noget lagerplads, eller hvis dit DW-system har optimerede værktøjer til at designe dette skema.

Star Schema Vs Snowflake Schema

Nedenfor er de vigtigste forskelle mellem stjerneskema og SnowFlake-skema.

S. nr Stjerneplan Snow Flake Schema
1Data redundans er mere.Data redundans er mindre.
toOpbevaringsplads til dimensionstabeller er mere.Opbevaringsplads til dimensionstabeller er forholdsvis mindre.
3Indeholder de-normaliserede dimensionstabeller.Indeholder normaliserede dimensionstabeller.
4Enkelt faktabord er omgivet af flere dimensionstabeller.Enkelt faktatabel er omgivet af flere hierarkier af dimensionstabeller.
5Forespørgsler bruger direkte sammenkædninger mellem fakta og dimensioner for at hente dataene.Forespørgsler bruger komplekse sammenføjninger mellem fakta og dimensioner for at hente dataene.
6Forespørgselens udførelsestid er mindre.Forespørgselens udførelsestid er mere.
8Bruger top-down tilgang.Bruger bottom up tilgang.

Konklusion

Vi håber, at du har en god forståelse af forskellige typer datavarehusskemaer sammen med deres fordele og ulemper fra denne vejledning.

Vi lærte også, hvordan Star Schema og SnowFlake Schema kan forespørges, og hvilket skema der skal vælges mellem disse to sammen med deres forskelle.

Hold øje med vores kommende tutorial for at vide mere om Data Mart i ETL !!

=> Pas på den enkle træningsserie om datalagring her.

Anbefalet læsning

^