Snøflakmodell
![](http://upload.wikimedia.org/wikipedia/commons/thumb/b/b2/Snowflake-schema.png/350px-Snowflake-schema.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Snowflake_schema.png/250px-Snowflake_schema.png)
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
![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/73/Snowflake-schema-example.png/300px-Snowflake-schema-example.png)
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
- ^ Forstå stjerneskjema og viktigheten for Power BI - Power BI | Microsoft Learn
- ^ INF212 - Databaseteori
- ^ Sluttprøve 5602 Databaser, 4f) 2009-12-01
- ^ Databasesystemer 2. utgave, kap. 17. Datavarehus, 17.2.4 Stjerneskjema og snøflakskjema
- ^ Operativsystemer – Eksamensoppgave – Høst 98
- ^ FOVA 1-1 Utvikling av beslutningsstøttesystemer og persondatabaser - Informatiske emner. 5.4 Dataanlyse, s. 16
- ^ «Universitetet i Oslo - Institutt for informatikk - Implementasjon av datavarehus – et eksempel - Hovedoppgave av Anette Langmo Becker 22. oktober 2004» (PDF).
- ^ Paulraj Ponniah. Data Warehousing Fundamentals for IT Professionals. Wiley, 2010, pp. 29–32. ISBN 0470462078.
- ^ Han, Jiawei. Data Mining - Concepts and Techniques. Massachusettes, USA: Morgan Kauffmann Publishers. ISBN 9780123814791.
- ^ Wilkie, Michelle (2009). «Using SAS® OLAP Server for a ROLAP Scenario» (PDF). SAS Global Forum 2009.
- ^ Kimball, Ralph. «6: The Big Dimensions». The Data Warehouse Toolkit (1st utg.). Wiley. ISBN 0-471-15337-0. «Do not snowflake your dimensions, even if they are large»
- v
- d
- r
Konsepter |
|
---|---|
Varianter |
|
Elementer | |
Fakta | |
Dimensjon | |
Fylling |
Konsepter | |
---|---|
Språk | |
Verktøy |
Folk |
---|