Stjerneskema vs. snefnugskema

I de foregående to artikler har vi overvejet de to mest almindelige datavarehusmodeller:stjerneskemaet og snefnugskemaet. I dag vil vi undersøge forskellene mellem disse to skemaer, og vi vil forklare, hvornår det er bedre at bruge det ene eller det andet.

Stjerneskemaet og snefnugskemaet er måder at organisere data marts eller hele datavarehuse ved hjælp af relationelle databaser. Begge bruger dimensionstabeller at beskrive data samlet i en fakta-tabel .

Alle sælger noget, det være sig viden, et produkt eller en service. Lagring af disse oplysninger, enten i et operationelt system eller i et rapporteringssystem, er også et behov. Så vi kan forvente at finde en eller anden form for salgsmodel inde i næsten alle virksomheders datavarehus.

Lad os tage endnu et kig på salgsmodellen i både stjerne- og snefnugskemaerne.

Stjerneskemaet

Det mest åbenlyse kendetegn ved stjerneskemaet er, at dimensionstabeller ikke er normaliserede. I modellen ovenfor er den lyserøde fact_sales tabel gemmer aggregerede data oprettet fra vores operationelle database(r). De lyseblå borde er dimensionstabeller. Vi besluttede at bruge disse fem dimensioner, fordi vi skal oprette rapporter ved at bruge dem som parametre. Granuleringen i hver dimension bestemmes også af vores rapporteringsbehov.

Fra denne model kan vi nemt se, hvorfor dette skema kaldes 'stjerneskemaet':det ligner en stjerne med dimensionstabellerne omkring den centrale faktatabel.

Snefnugskemaet

Dette snefnugskema gemmer nøjagtig de samme data som stjerneskemaet. Faktatabellen har de samme dimensioner som i eksemplet med stjerneskemaet. Den vigtigste forskel er, at dimensionstabellerne i snefnugskemaet er normaliserede. Interessant nok kaldes processen med at normalisere dimensionstabeller snefnug.

Endnu en gang minder snefnugskemaet os visuelt om dets navnebror, med flere lag af dimensionstabeller, der skaber en uregelmæssig snefnuglignende form.

Den første forskel:Normalisering

Som nævnt er normalisering en nøgleforskel mellem stjerne- og snefnugskemaer. Med hensyn til dette er der et par ting at vide:

• Snefnugskemaer vil bruge mindre plads til at gemme dimensionstabeller. Dette skyldes, at enhver normaliseret database som regel producerer langt færre overflødige poster .
• Denormaliserede datamodeller øger chancerne for dataintegritetsproblemer. Disse problemer vil også komplicere fremtidige ændringer og vedligeholdelse.
• For erfarne datamodellerere virker snefnugskemaet mere logisk organiseret end stjerneskemaet. (Dette er min personlige mening, ikke en hård kendsgerning. :) )

Lad os gå videre til den anden store forskel mellem disse to skemaer.

Den anden forskel:Forespørgselskompleksitet

I vores første to artikler demonstrerede vi en forespørgsel, der kunne bruges på salgsmodellen for at få oplyst mængden af ​​alle telefonlignende produkter solgt i Berlin-butikker i 2016.

Stjerneskemaforespørgslen ser sådan ud:

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

For at få det samme resultat fra snefnugskemaet skal vi bruge denne forespørgsel:

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

Selvfølgelig er snefnugskemaforespørgslen mere kompleks. Fordi dimensionstabellerne er normaliserede, er vi nødt til at grave dybere for at få navnet på produkttypen og byen. Vi er nødt til at tilføje endnu et JOIN for hvert nyt niveau inden for samme dimension.

I stjerneskemaet forbinder vi kun faktatabellen med de dimensionstabeller, vi har brug for. Vi har højst kun én JOIN pr. dimensionstabel. Og hvis vi ikke bruger en dimensionstabel, behøver vi ikke engang at bøvle med den. I snefnugskemaforespørgslen ved vi ikke, hvor dybt vi skal gå for at få det rigtige dimensionsniveau, så det komplicerer processen med at skrive forespørgsler.

Det tager tid at forbinde to tabeller, fordi DMBS tager længere tid at behandle anmodningen. dim_store og dim_city borde er placeret i umiddelbar nærhed i vores model, men de er muligvis ikke placeret i nærheden af ​​hinanden på disken. Der er en bedre mulighed for, at data vil være fysisk tættere på disken, hvis den bor inde i samme bord.

Grundlæggende vil en forespørgsel, der kørte mod et snefnugskema, datamarked udføres langsommere. Men i de fleste tilfælde vil dette ikke udgøre et problem:det betyder ikke meget, om vi får resultatet på et millisekund eller et sekund.

Fremskynder tingene

For at fremskynde rapporteringen kan vi:

• Aggregér data til det niveau, vi har brug for i rapporter. Dette vil komprimere dataene betydeligt. Vi bliver nødt til at oprette procedurer, der vil transformere vores live-data, så de passer ind i rapporteringsskemastrukturen (ETL-processen).
• Byg et centralt lagerområde til alle virksomhedens aggregerede data, ikke kun salgsdata.
• Giv kun brugerne de data, de har brug for til analyser og rapporter.

Snefnug vs. stjerneskemaer:Hvilken skal du bruge?

Nu hvor vi har set på teori og forespørgselshastigheder, lad os komme helt ind i sagens kerne:hvordan ved du, hvilket skema du skal bruge på et givet projekt?

Overvej at bruge snefnugskemaet :

• I datavarehuse. Da lageret er Data Central for virksomheden, kunne vi spare meget plads på denne måde.
• Når dimensionstabeller kræver en betydelig mængde lagerplads. I de fleste tilfælde vil faktatabellerne være dem, der tager det meste af pladsen. De vil sandsynligvis også vokse meget hurtigere end dimensionstabeller. Men der er visse situationer, hvor det ikke gælder. For eksempel kunne dimensionstabellerne indeholde en masse overflødige, men nødvendige attributter. I vores eksempel brugte vi byen attribut for at beskrive den by, hvor butikken ligger. Hvad hvis vi ville have en meget mere detaljeret beskrivelse af byen, inklusive befolkning, postnummer, demografiske data osv.? Beskriver andre underdimensioner – for eksempel butik , region , stat og land – med flere attributter ville vende dim_store dimensionstabel til ét stort bord med meget redundans.
• Hvis du bruger værktøjer, der kræver et snefnugskema i baggrunden. (Heldigvis understøtter de fleste moderne værktøjer både skemaer og endda galakseskemaet.)

Overvej at bruge stjerneskemaet :

• I data marts. Data marts er delmængder af data taget ud af det centrale datavarehus. De er normalt oprettet til forskellige afdelinger og indeholder ikke engang alle historikdata. I denne indstilling er lagring af lagerplads ikke en prioritet.

  På den anden side forenkler stjerneskemaet analysen. Dette handler ikke kun om forespørgselseffektivitet, men også om at forenkle fremtidige handlinger for forretningsbrugere. De forstår måske databaser og ved, hvordan man skriver forespørgsler, men hvorfor komplicere tingene og inkludere flere joinforbindelser, hvis vi kan undgå det? En virksomhedsbruger kunne have en skabelonforespørgsel, der forbinder faktatabellen med alle dimensionstabellerne. Så behøver de kun at tilføje de relevante valg og grupperinger. (Denne tilgang er tæt på Excels pivottabeller.)

• Hvis du bruger værktøjer, der kræver et stjerneskema i baggrunden. (Igen, dette er normalt ikke et problem.)

Både stjerneskemaet og snefnugskemaet er relationelle modeller, der bruges til at organisere datavarehuse og/eller data marts. Uanset hvor ens de er, demonstrerer de to forskellige tilgange og har deres egne fordele og ulemper. Personligt ville jeg gå med snefnugskemaet, når jeg implementerer et datavarehus (for at spare lagerplads) og med stjerneskemaet for datamarts (for at gøre livet lettere for forretningsbrugere).