Sterrenschema versus sneeuwvlokschema

In de vorige twee artikelen hebben we gekeken naar de twee meest voorkomende datawarehouse-modellen:het sterschema en het sneeuwvlokschema. Vandaag onderzoeken we de verschillen tussen deze twee schema's en leggen we uit wanneer het beter is om het een of het ander te gebruiken.

Het sterschema en het sneeuwvlokschema zijn manieren om datamarts of hele datawarehouses te organiseren met behulp van relationele databases. Beiden gebruiken dimensietabellen om gegevens te beschrijven die zijn verzameld in een feitentabel .

Iedereen verkoopt iets, of het nu kennis, een product of een dienst is. Ook het opslaan van deze informatie, in een operationeel systeem of in een rapportagesysteem, is een noodzaak. We kunnen dus een soort verkoopmodel verwachten in het datawarehouse van bijna elk bedrijf.

Laten we nog een keer kijken naar het verkoopmodel in zowel het ster- als het sneeuwvlokschema.

Het sterrenschema

Het meest voor de hand liggende kenmerk van het sterschema is dat dimensietabellen niet zijn genormaliseerd. In het bovenstaande model is de roze fact_sales tabel slaat geaggregeerde gegevens op die zijn gemaakt op basis van onze operationele database(s). De lichtblauwe tafels zijn maattabellen. We hebben besloten deze vijf dimensies te gebruiken omdat we rapporten moeten maken met deze als parameters. De granulatie binnen elke dimensie wordt ook bepaald door onze rapportagebehoeften.

Uit dit model kunnen we gemakkelijk zien waarom dit schema het 'sterrenschema' wordt genoemd:het ziet eruit als een ster, met de dimensietabellen rond de centrale feitentabel.

Het sneeuwvlokschema

Dit sneeuwvlokschema slaat exact dezelfde gegevens op als het sterschema. De feitentabel heeft dezelfde afmetingen als in het voorbeeld van het sterschema. Het belangrijkste verschil is dat de dimensietabellen in het sneeuwvlokschema zijn genormaliseerd. Interessant is dat het proces van het normaliseren van dimensietabellen sneeuwvlokken wordt genoemd.

Nogmaals, visueel herinnert het sneeuwvlokschema ons aan zijn naamgenoot, met verschillende lagen dimensietabellen die een onregelmatige sneeuwvlokachtige vorm creëren.

Het eerste verschil:normalisatie

Zoals eerder vermeld, is normalisatie een belangrijk verschil tussen ster- en sneeuwvlokschema's. Hierover zijn er een paar dingen die u moet weten:

• Sneeuwvlokschema's nemen minder ruimte in beslag om dimensietabellen op te slaan. Dit komt omdat in de regel elke genormaliseerde database veel minder overbodige records produceert.
• Gedenormaliseerde gegevensmodellen vergroten de kans op problemen met gegevensintegriteit. Deze problemen zullen toekomstige aanpassingen en onderhoud ook bemoeilijken.
• Voor ervaren datamodelleurs lijkt het sneeuwvlokschema logischer georganiseerd dan het sterrenschema. (Dit is mijn persoonlijke mening, geen hard feit. :) )

Laten we verder gaan met het tweede grote verschil tussen deze twee schema's.

Het tweede verschil:complexiteit van zoekopdrachten

In onze eerste twee artikelen hebben we een zoekopdracht gedemonstreerd die op het verkoopmodel kan worden gebruikt om de hoeveelheid van alle telefoonachtige producten te krijgen die in 2016 in Berlijnse winkels zijn verkocht.

De zoekopdracht voor het sterschema ziet er als volgt uit:

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

Om hetzelfde resultaat van het sneeuwvlokschema te krijgen, moeten we deze query gebruiken:

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

Het is duidelijk dat de query voor het sneeuwvlokschema complexer is. Omdat de dimensietabellen zijn genormaliseerd, moeten we dieper graven om de naam van het producttype en de stad te krijgen. We moeten nog een JOIN toevoegen voor elk nieuw niveau binnen dezelfde dimensie.

In het sterrenschema voegen we de feitentabel alleen samen met die dimensietabellen die we nodig hebben. We hebben maximaal één JOIN per dimensietabel. En als we geen dimensietabel gebruiken, hoeven we ons er niet eens mee bezig te houden. In de sneeuwvlokschema-query weten we niet hoe diep we moeten gaan om het juiste dimensieniveau te krijgen, dus dat bemoeilijkt het proces van het schrijven van query's.

Het samenvoegen van twee tabellen kost tijd omdat de DMBS er langer over doet om het verzoek te verwerken. De dim_store en dim_city tabellen worden in ons model dicht bij elkaar geplaatst, maar ze mogen niet in de buurt van elkaar op de schijf staan. Er is een grotere kans dat gegevens fysiek dichter op de schijf staan ​​als deze zich in dezelfde tabel bevinden.

Kortom, een query die is uitgevoerd tegen een datamart met een sneeuwvlokschema, wordt langzamer uitgevoerd. Maar in de meeste gevallen zal dit geen probleem zijn:het maakt niet veel uit of we het resultaat in één milliseconde of één seconde krijgen.

Dingen versnellen

Om de rapportage te versnellen, kunnen we:

• Gegevens samenvoegen tot het niveau dat we nodig hebben in rapporten. Hierdoor worden de gegevens aanzienlijk gecomprimeerd. We moeten procedures creëren die onze live gegevens transformeren zodat ze passen in de rapportageschemastructuur (het ETL-proces).
• Bouw een centrale opslagruimte voor alle de geaggregeerde gegevens van het bedrijf, niet alleen de verkoopgegevens.
• Geef gebruikers alleen de gegevens die ze nodig hebben voor analyse en rapporten.

Sneeuwvlok versus sterschema's:welke moet je gebruiken?

Nu we de theorie en vraagsnelheden hebben bekeken, gaan we tot de kern van de zaak komen:hoe weet u welk schema u voor een bepaald project moet gebruiken?

Overweeg het gebruik van het sneeuwvlokschema :

• In datawarehouses. Omdat het magazijn Data Central is voor het bedrijf, kunnen we op deze manier veel ruimte besparen.
• Als maattabellen veel opslagruimte nodig hebben. In de meeste gevallen zullen de feitentabellen de meeste ruimte innemen. Ze zullen waarschijnlijk ook veel sneller groeien dan dimensietabellen. Maar er zijn bepaalde situaties waarin dat niet van toepassing is. De dimensietabellen kunnen bijvoorbeeld veel overbodige maar noodzakelijke attributen bevatten. In ons voorbeeld gebruikten we de stad attribuut om de stad te beschrijven waar de winkel zich bevindt. Wat als we een veel gedetailleerdere beschrijving van de stad willen, inclusief de bevolking, postcode, demografische gegevens, enz.? Andere subdimensies beschrijven – bijvoorbeeld winkel , regio , staat en land – met meer attributen zou de dim_store maattabel tot één grote tafel met veel redundantie.
• Als je tools gebruikt die een sneeuwvlokschema op de achtergrond vereisen. (Gelukkig ondersteunen de meeste moderne tools zowel schema's als zelfs het galaxy-schema.)

Overweeg het gebruik van het sterrenschema :

• In datamarts. Datamarts zijn subsets van gegevens die uit het centrale datawarehouse worden gehaald. Ze zijn meestal gemaakt voor verschillende afdelingen en bevatten niet eens alle historische gegevens. In deze instelling heeft het besparen van opslagruimte geen prioriteit.

  Aan de andere kant vereenvoudigt het sterschema de analyse. Het gaat niet alleen om de efficiëntie van zoekopdrachten, maar ook om het vereenvoudigen van toekomstige acties voor zakelijke gebruikers. Ze begrijpen misschien databases en weten hoe ze queries moeten schrijven, maar waarom zouden ze de zaken ingewikkelder maken en meer joins toevoegen als we dit kunnen vermijden? Een zakelijke gebruiker kan een sjabloonquery hebben die de feitentabel verbindt met alle dimensietabellen. Dan hoeven ze alleen nog de juiste selecties en groeperingen toe te voegen. (Deze benadering ligt dicht bij de draaitabellen van Excel.)

• Als je tools gebruikt die een sterschema op de achtergrond vereisen. (Nogmaals, dit is meestal geen probleem.)

Zowel het sterrenschema als het sneeuwvlokschema zijn relationele modellen die worden gebruikt om datawarehouses en/of datamarts te organiseren. Hoe vergelijkbaar ze ook zijn, ze demonstreren twee verschillende benaderingen en hebben hun eigen voor- en nadelen. Persoonlijk zou ik kiezen voor het sneeuwvlokschema bij het implementeren van een datawarehouse (om opslagruimte te besparen) en voor het sterrenschema voor datamarts (om het leven van zakelijke gebruikers gemakkelijker te maken).