Snowflake Schema vs Star Schema

Når du velger et databaseskjema for et datalager, snøfnugg og stjerneskjemaer pleier å være populære valg. Denne sammenligningen diskuterer egnethet til stjerne mot snøflakskjemaer i forskjellige scenarier og deres egenskaper.

Sammenligningstabell

Snowflake Schema versus Star Schema sammenligning diagram

Snowflake Schema	Star Schema
Enkel vedlikehold / endring	Ingen redundans, så snowflake skjemaer er enklere å vedlikeholde og endre.	Har overflødige data og dermed mindre lett å vedlikeholde / endre
Brukervennlighet	Mer komplekse søk og dermed mindre lett å forstå	Lavere spørrekompleksitet og lett å forstå
Søkeytelse	Flere utenlandske nøkler og dermed lengre forespørsel om utføringstid (langsommere)	Mindre antall utenlandske nøkler og dermed kortere forespørsel om utføringstid (raskere)
Type Datawarehouse	God å bruke for datakjerne kjerne for å forenkle komplekse relasjoner (mange: mange)	Bra for datamaskiner med enkle relasjoner (1: 1 eller 1: mange)
tiltrer	Høyere antall tilkoblinger	Færre tilkoblinger
Dimensjonstabell	Et snøflakskjema kan ha mer enn en dimensjonstabell for hver dimensjon.	Et stjerneskjema inneholder bare en dimensjonstabell for hver dimensjon.
Når skal du bruke	Når dimensjonstabell er relativt stor i størrelse, er snøflakking bedre da det reduserer plass.	Når dimensjonstabellen inneholder færre antall rader, kan vi velge Star-skjema.
Normalisering / de-normalisering	Dimensjonstabeller er i normalisert form, men faktabord er i de-normalisert form	Både dimensjon og faktabord er i de-normalisert form
Datamodell	Bottom up tilnærming	Topp ned tilnærming

Innhold: Snowflake Schema vs Star Schema

• 1 Eksempler
  • 1.1 Star Schema Eksempel
  • 1.2 Snowflake Schema Eksempel
• 2 referanser

eksempler

Tenk på en database for en forhandler som har mange butikker, hvor hver butikk selger mange produkter i mange produktkategorier og forskjellige merker. Et datalager eller data mart for en slik forhandler vil måtte gi analytikere muligheten til å kjøre salgsrapporter gruppert etter butikk, dato (eller måned, kvartal eller år), eller produktkategori eller merkevare.

Star Schema Eksempel

Hvis denne data mart bruker et stjerneskjema, ser det ut som følger:

Eksempel på et stjerneskjema

Faktabordet vil være en oversikt over salgstransaksjoner, mens det er dimensjonstabeller for dato, butikk og produkt. Dimensjonstabeller er hver koblet til faktabordet via deres primærnøkkel, som er en fremmednøkkel for faktabordet. For eksempel, i stedet for å lagre den faktiske transaksjonsdatoen i en rekke av faktatabellen, lagres datoen_id. Denne date_id tilsvarer en unik rad i Dim_Date-tabellen, og den raden lagrer også andre attributter av datoen som kreves for gruppering i rapporter. for eksempel ukedag, måned, kvartår og så videre. Dataene er denormalisert for enklere rapportering.

Her er hvordan man vil få en rapport om antall fjernsyn som selges etter merke og land ved hjelp av indre sammenhenger.

Snowflake Schema Eksempel

Det samme scenariet kan også bruke et snøflakskjema, i så fall vil det bli strukturert som følger:

Snowflake skjema eksempel (klikk for å forstørre)

Hovedforskjellen, sammenlignet med stjerneskjemaet, er at data i dimensjonstabeller er mer normalisert. For eksempel, i stedet for å lagre måned, kvart og ukedag i hver rad i Dim_Date-tabellen, blir disse videre brutt ut i sine egne dimensjonstabeller. På samme måte for Dim_Store-tabellen er staten og landet geografiske attributter som er ett trinn fjernet - i stedet for å bli lagret i Dim_Store-tabellen, lagres de nå i et eget Dim_Geography-tabell.

Den samme rapporten - antall fjernsyn som selges etter land og etter merke - er nå litt mer komplisert enn i et stjerneskjema:

SQL-spørring for å få antall produkter solgt etter land og merke, når databasen bruker et snøflakskjema.

referanser

• wikipedia: Snowflake_schema
• wikipedia: Star_schema