Bij het kiezen van een databaseschema voor een datawarehouse, sneeuwvlok en sterren schema's zijn meestal populaire keuzes. Deze vergelijking bespreekt de geschiktheid van ster- versus sneeuwvlokschema's in verschillende scenario's en hun kenmerken.
Sneeuwvlok schema | Star Schema | |
---|---|---|
Eenvoudig onderhoud / verandering | Geen redundantie, dus sneeuwvlokschema's zijn gemakkelijker te onderhouden en te veranderen. | Heeft overbodige gegevens en is daarom minder gemakkelijk te onderhouden / wijzigen |
Makkelijk te gebruiken | Complexere vragen en dus minder gemakkelijk te begrijpen | Lagere query-complexiteit en gemakkelijk te begrijpen |
Queryprestaties | Meer vreemde sleutels en dus langere uitvoeringstijd van de query (langzamer) | Minder aantal externe sleutels en dus kortere query-uitvoeringstijd (sneller) |
Type Datawarehouse | Goed te gebruiken voor de kern van datawarehouse om complexe relaties te vereenvoudigen (veel: veel) | Goed voor datamarts met eenvoudige relaties (1: 1 of 1: veel) |
Doet mee | Hoger aantal Joins | Minder Joins |
Afmetingstabel | Een sneeuwvlokschema kan voor elke dimensie meer dan één dimensietabel hebben. | Een ster schema bevat voor elke dimensie slechts één-dimensionale tabel. |
Wanneer te gebruiken | Wanneer de dimensietabel relatief groot is, is sneeuwklimmen beter omdat het de ruimte vermindert. | Wanneer de dimensietabel minder rijen bevat, kunnen we Star schema kiezen. |
Normalisatie / de-normalisatie | Dimentietabellen zijn in genormaliseerde vorm, maar feitentabel heeft de vorm van de genormaliseerde vorm | Zowel dimensie- als feitentabellen zijn in de vorm van de genormaliseerde vorm |
Gegevensmodel | Bottom-up benadering | Top-down benadering |
Overweeg een database voor een winkel die veel winkels heeft, waarbij elke winkel veel producten verkoopt in veel productcategorieën en van verschillende merken. Een datawarehouse of datamart voor een dergelijke retailer zou analisten de mogelijkheid moeten bieden verkooprapporten te groeperen op basis van winkel, datum (of maand, kwartaal of jaar) of productcategorie of merk.
Als deze datamart een sterrenschema zou gebruiken, zou het er als volgt uitzien:
Voorbeeld van een Star-schemaDe feitentabel zou een record van verkooptransacties zijn, terwijl er maatafmetingen zijn voor datum, winkel en product. Maattabellen zijn elk verbonden met de feitentabel via hun primaire sleutel, die een buitenlandse sleutel is voor de feitentabel. In plaats van de daadwerkelijke transactiedatum op te slaan in een rij van de feitentabel, wordt bijvoorbeeld de datum_id opgeslagen. Deze datum_id komt overeen met een unieke rij in de tabel Dim_Date en die rij slaat ook andere kenmerken van de datum op die vereist zijn voor groepering in rapporten. bijv. dag van de week, maand, kwartaal van het jaar enzovoort. De gegevens zijn gedenormaliseerd voor eenvoudiger rapportage.
Hier is hoe je een rapport krijgt over het aantal verkochte televisies per merk en per land met behulp van inner joins.
Hetzelfde scenario kan ook een sneeuwvlokschema gebruiken, in welk geval het als volgt gestructureerd zou zijn:
Sneeuwvlokschema voorbeeld (klik om te vergroten)Het belangrijkste verschil ten opzichte van het sterrenschema is dat gegevens in dimensietabellen meer genormaliseerd zijn. In plaats van bijvoorbeeld maand, kwartaal en dag van de week op te slaan in elke rij van de tabel Dim_Date, worden deze verder uitgebroken in hun eigen dimensietabellen. Evenzo zijn voor de tabel Dim_Store de staat en het land geografische kenmerken die één stap verwijderd zijn - in plaats van te worden opgeslagen in de tabel Dim_Store, worden ze nu opgeslagen in een afzonderlijke tabel Dim_Geography.
Hetzelfde rapport - het aantal verkochte televisies per land en per merk - is nu iets gecompliceerder dan in een sterrenschema:
SQL-query om het aantal verkochte producten per land en merk te krijgen, wanneer de database een sneeuwvlokschema gebruikt.