Snøflakmodell

En snøflakmodell,^[2] også kalt snøflakskjema^[3][4][5][6] eller snøfnuggdiagram,^[7] er en logisk datamodell av tabeller i en flerdimensjonal database slik at entitet–relasjonsmodellen ligner på et snøfnugg. Snøflakmodellen kjennetegnes av sentraliserte faktatabeller som er koblet til flere dimensjonstabeller. Såkalt snowflaking er en metode for å normalisere dimensjonstabellene i en stjernemodell. Når det som var en stjernemodell har blitt helt normalisert langs alle dimensjonstabellene vil den resulterende strukturen ligne på et snøfnugg med en faktatabell i midten. Prinsippet bak snowflaking er normalisering av dimensjonstabellene ved å fjerne attributter med lav kardinalitet og flytte disse til separate tabeller.^[8]

Snøflakmodellen ligner på stjernemodellen, men dimensjonene i snøflakmodellen er normaliserte til flere relaterte tabeller, mens stjernemodellen sine dimensjoner er denormaliserte med alle dimensjonene representert i én enkelt tabell. Formen til en snøflakmodell kan minne om et komplekst snøfnugg når man får omstendige dimensjoner med flere nivåer av relasjoner, og barnetabeller med flere foreldretabeller.

Vanlige bruksområder

Stjerne- og snøflakmodeller finnes oftest i dimensjonale datavarehus og datatorg hvor hastigheten på datauthenting er viktigere enn effektiviteten til datamanipulasjoner. Som sådan er tabellene i disse modellene ikke mye normaliserte, og er ofte dersignet med et normaliseringsnivå under tredje normalform.^[9]

Datanormalisering og lagring

Normalisering handler om å dele opp data for å unngå redundans (duplisering) ved å flytte ofte gjentatte grupper av data til nye tabeller. Normalisering har derfor en tendens til å øke antall tabeller som må slås sammen for å utføre en gitt spørring, men reduserer plassen som kreves for å holde på dataene og antall steder de må oppdateres dersom dataene endres.

Fra et lagringsperspektiv er dimensjonstabeller vanligvis små sammenlignet med faktatabeller. Dette negerer ofte stjernemodellen sin potensielle fordel når det gjelder lagringsplass sammenlignet med en snøflakmodell. For eksempel: Anta at en million salgstransaksjoner i 300 butikker fordelt på 220 land vil resultere i 1 000 300 oppføringer i en stjernemodell (1 000 000 oppføringer i faktatabellen og 300 oppføringer i dimensjonstabellen hvor hvert land vil bli oppført eksplisitt for hver butikk i det landet). En mer normalisert snøflakmodell med landsnøkler som refererer til et landstabell vil bestå av det samme antall faktaoppføringer med 1 000 000 fakta, og en butikktabell med 300 oppføringer med referanser til et landtabell med 220 oppføringer. I dette tilfellet vil stjernemodellen, selv om den er mer denormalisert, bare redusere antallet oppføringer med en (ubetydelig) faktor på ~0.9998 (=[1 000 000 + 300] delt på [1 000 000 + 300 + 220])

Noen databaseutviklere lager en kompromissløsning hvor man lager en underliggende struktur basert på en snøflakmodell med visninger oppå der igjen som utfører mange av de nødvendige skjøter for å simulere en stjernemodell. Dette gjør at man både får lagringsfordelene gjennom normalisering av dimensjonene, samtidig som man får de enklere spørringene som en stjernemodell gir. Ulempen er at man da pålegger tjeneren å utførede underliggende skjøtene automatisk, hvilket kan føre til dårligere ytelse under spørringer, samt at de ekstra skjøtene kan være overflødige for å utføre en del spørringer.^{[trenger referanse]}

Fordeler

Snøflakmodellen og stjernemodellen er nært beslektet som logiske modeller. Noen anser faktisk en stjernemodell som et spesielt tilfelle av en snøflakmodell. Snøflakmodellen har noen fordeler fremfor stjernemodellen i visse situasjoner, inkludert:

• Noen flerdimensjonale databasemodelleringsverktøy for OLAP er optimaliserte for snøflakmodeller.^[10]
• Normalisering av attributter resulterer i mer kompakt lagring, på bekostning av ekstra kompleksitet når man skal spørre om skjøter (joins).

Ulemper

Hovedulempen med snøflakmodellen er at de ekstra nivåene med attributt-normalisering gir økt kompleksitet sammenlignet med stjernemodellen når man skal spørre om skjøter.

I motsetning til flate dimensjoner med en enkelt tabell har snøflakmodellen blitt sterkt kritisert. Formålet deres^[klargjør] antas å være effektiv og kompakt lagring av normaliserte data, men dette kommer på bekostning av dårlig ytelse skal surfer gjennom skjøtene som trengs i den gitte dimensjonen.^[11] Denne ulempen kan imidlertid ha blitt redusert i løpet av årene etter at problemet ble anerkjent grunnet bedre ytelse på spørringer i surfeverktøyene.

Sammenlignet med en svært normalisert transaksjonslogikk vil denormalisering av en snøflakmodell fjerne forsikringer om dataintegritet gitt av de normaliserte modellene.^{[trenger referanse]} Data som lastes inn i snøflakmodellen må være svært godt kontrollerte for å unngå anomalier ved oppdatering og innsetting av data.

Eksempler

Modellen vist til høyre er en snowflaked versjon av eksemplet som er gitt i stjernemodell-artikkelen.

Følgende eksempelspørring for en snøflakmodell returnerer totalt antall TV-er solgt i 1997 etter merke og land. (Eksempelkode for en lignende spørring kan også sees i stjernemodell-artikkelen). Merk til at spørringen i snøflakmodellen krever mange flere skjøter (joins) enn stjernemodell-versjonen for å utføre en relativt enkel spørring. Fordelen med å bruke snøflakmodellen i dette eksemplet er slakkere lagringskrav ettersom snøflakmodellen på egenhånd eliminerer mange dupliserte verdier fra dimensjonene.

SELECT
	B.Brand,
	G.Country,
	SUM(F.Units_Sold)
FROM Fact_Sales F
INNER JOIN Dim_Date D             ON F.Date_Id = D.Id
INNER JOIN Dim_Store S            ON F.Store_Id = S.Id
INNER JOIN Dim_Geography G        ON S.Geography_Id = G.Id
INNER JOIN Dim_Product P          ON F.Product_Id = P.Id
INNER JOIN Dim_Brand B            ON P.Brand_Id = B.Id
INNER JOIN Dim_Product_Category C ON P.Product_Category_Id = C.Id
WHERE
	D.Year = 1997 AND
	C.Product_Category = 'tv'
GROUP BY
	B.Brand,
	G.Country

Se også

• Stjernemodell
• Datavarehus
• Online analytisk prosessering (OLAP)

Referanser