Starschema vs. snowflakeschema: verschillen en use cases

Wat is een snowflakeschema?

Een snowflakeschema is een andere manier om data te organiseren. In dit schema worden dimensietabellen opgesplitst in kleinere subdimensies om data geordender en gedetailleerder te houden — net als sneeuwvlokken in een groot meer. 

Indeling van een snowflakeschema. Afbeelding door de auteur.

Dit zijn de belangrijkste kenmerken van het snowflakeschema die het onderscheiden van andere schema’s:

• Meerlagige dimensietabellen: We kunnen onze dimensietabellen opsplitsen in kleinere, specifiekere tabellen. Als ik bijvoorbeeld winkellocaties wil volgen, kan ik in plaats van alle locatiedetails in één grote tabel te stoppen, ze splitsen in aparte tabellen voor landen, staten/provincies en steden. Zo bevat elke tabel alleen de informatie die nodig is, wat redundantie vermindert en de organisatie verbetert.
• Normalisatie voor opslagefficiëntie: In tegenstelling tot het starschema volgt het snowflakeschema een genormaliseerd ontwerp, waardoor dataduplicatie wordt vermeden. In plaats van bijvoorbeeld de productcategorie Electronics voor elk product te herhalen, kan ik de categorie in een aparte tabel opslaan en die koppelen aan afzonderlijke producten.
• Geschikt voor complexe data-omgevingen: Het snowflakeschema werkt het best voor complexe data-omgevingen omdat het met meerlagige tabellen ingewikkelde relaties en hiërarchische datastructuren kan afhandelen.

Laten we dit begrijpen met een eenvoudig diagram van een snowflakeschema. In het midden staat de feittabel met meetbare data. Deze is verbonden met dimensietabellen die de feiten beschrijven, en die dimensietabellen vertakken verder in subdimensietabellen, wat samen een sneeuwvlokachtige structuur vormt. 

Zo heb ik hier de tabel Product opgesplitst in tabellen Manufacturer en Category en de tabel Customer in tabellen Transaction en Location opgesplitst:

Voorbeeld van een snowflakeschema. Afbeelding door de auteur.

Hier is een SQL-voorbeeld van een snowflakeschema waarin de tabel Product verder is genormaliseerd naar de tabellen Category en Manufacturer:

-- Fact table remains the same
CREATE TABLE Sales (
    Sales_ID INT PRIMARY KEY,
    Product_ID INT,
    Customer_ID INT,
    Date_ID INT,
    Sales_Amount DECIMAL(10, 2),
    FOREIGN KEY (Product_ID) REFERENCES Products(Product_ID),
    FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID),
    FOREIGN KEY (Date_ID) REFERENCES Dates(Date_ID)
);

-- Dimension table: Product
CREATE TABLE Product (
    Product_ID INT PRIMARY KEY,
    Product_Name VARCHAR(100),
    Category_ID INT,
    Manufacturer_ID INT,
    FOREIGN KEY (Category_ID) REFERENCES Category(Category_ID),
    FOREIGN KEY (Manufacturer_ID) REFERENCES Manufacturer(Manufacturer_ID)
);

-- Sub-dimension table: Category
CREATE TABLE Category (
    Category_ID INT PRIMARY KEY,
    Category_Name VARCHAR(50)
);

-- Sub-dimension table: Manufacturer
CREATE TABLE Manufacturer (
    Manufacturer_ID INT PRIMARY KEY,
    Manufacturer_Name VARCHAR(100)
);

De volgende query berekent de totale verkoop per productcategorie. Hoewel deze meer joins bevat dan het starschema, is het opslagzuiniger:

SELECT cat.Category_Name, SUM(s.Sales_Amount) AS TotalSales
FROM Sales s
JOIN Product p ON s.Product_ID = p.Product_ID
JOIN Category cat ON p.Category_ID = cat.Category_ID
GROUP BY cat.Category_Name;

Voordelen en beperkingen van een snowflakeschema

Net als het starschema heeft het snowflakeschema zijn eigen voordelen. Dit zijn ze:

• Minder dataduplicatie: Normalisatie zorgt ervoor dat dezelfde data niet meerdere keren wordt opgeslagen, wat duplicatie vermindert.
• Efficiënte opslag voor grote datasets: Dit schema bespaart opslagruimte door herhaling te vermijden, waardoor het ideaal is voor het beheren van grote datasets.

Toch zijn er, ondanks de voordelen, ook enkele beperkingen. Zo kunnen queries langzamer zijn omdat er meer joins tussen tabellen nodig zijn. Daarnaast is de meerlagige structuur lastiger te ontwerpen en te onderhouden dan eenvoudigere schema’s zoals het starschema. Kies hiervoor dus alleen als je een ervaren DBA-team hebt.

Ik raad je aan om de Database Design-cursus te bekijken als je meer wilt leren over het efficiënt structureren van data voor analyse. 

Een hybride aanpak gebruiken

In echte projecten is het gebruikelijk om beide patronen op verschillende lagen te combineren om de sterke punten van beide benaderingen te benutten:

• Houd meer genormaliseerde (gesnowflakete) structuren in de warehouselaag voor consistentie en eenvoudiger onderhoud
• Publiceer starvormige marts of gedenormaliseerde views voor BI en rapportage

Zo kunnen teams dataintegriteit en governance in balans brengen met snelle, eenvoudige analytics-consumptie.

Starschema vs. snowflakeschema

Zowel star- als snowflakeschema’s worden veel gebruikt in datawarehousing, maar hun unieke eigenschappen maken ze geschikt voor verschillende behoeften. Laten we kijken hoe deze schema’s verschillen qua structuur, performance, opslagvereisten en use cases.

Structuur

In een starschema zijn alle dimensietabellen direct verbonden met één centrale feittabel. Dit betekent dat al je referentiedata één stap verwijderd is van je hoofddata, wat het begrijpen en werken ermee eenvoudig maakt.

Ter vergelijking: een snowflakeschema splitst dimensietabellen op in kleinere, specifiekere subdimensietabellen. Je kunt bijvoorbeeld aparte tabellen hebben voor landen, staten/provincies en steden in plaats van één locatietabel. Hoewel dit een geordendere en gedetailleerdere structuur oplevert, zijn er ook meer verbindingen (of joins) nodig om je data te benaderen — een belangrijke reden waarom het snowflakeschema complexer is dan het starschema.

Performance

Als het om snelheid gaat, zijn starschema’s vaak beter. Omdat alle dimensietabellen direct met de feittabel zijn verbonden, vereisen queries meestal minder joins, wat zorgt voor snellere prestaties. Stel dat je verkoop per regio wilt analyseren — dan kun je met het starschema de data met minimale verwerking ophalen.

Snowflakeschema’s zijn daarentegen vaak langzamer, omdat je door meerdere tabellen heen moet koppelen om de data op te halen. Elke join voegt verwerkingstijd toe, waardoor snowflakeschema’s minder efficiënt zijn voor taken die snelle queryresultaten vereisen.

De cursus Joining Data in SQL is een uitstekende inleiding om te leren hoe je tabellen samenvoegt, relationele verzamelingenleer toepast en met subqueries werkt.

Opslagvereisten

Starschema’s nemen meer opslagruimte in beslag omdat ze redundante informatie in dimensietabellen opslaan. Als meerdere producten bijvoorbeeld tot dezelfde categorie behoren, wordt de categorienaam voor elk product herhaald, wat de opslagbehoefte vergroot.

Snowflakeschema’s normaliseren data zodat alle informatie slechts één keer wordt opgeslagen. In plaats van categorienamen te herhalen, worden die in een aparte tabel opgeslagen en met de producttabel verbonden via foreign keys. Dit ontwerp bespaart opslagruimte en is ideaal voor grote datasets.

Use cases

Starschema’s zijn ideaal voor online analytical processing (OLAP)-systemen, rapportage en business intelligence-taken. Hun eenvoud maakt ze perfect voor scenario’s waar snelheid en gebruiksgemak belangrijk zijn, zoals het genereren van snelle dashboards of verkooprapporten.

Snowflakeschema’s worden vaak gebruikt voor financiële analyse of customer relationship management (CRM)-systemen. Het organiseren van gedetailleerde hiërarchieën en het besparen van opslagruimte is in zulke gevallen belangrijker dan querysnelheid.

Vergelijkingstabel

Hier is een snelle vergelijking van het star- en snowflakeschema om je te helpen bepalen welk schema het beste bij jouw databehoeften past. Ik heb de belangrijkste verschillen in deze tabel uitgelicht, met focus op structuur, performance, opslag en use cases:

Het juiste schema kiezen

Wanneer gebruik je een starschema

Als je je data vooral eenvoudig en snel wilt organiseren, is het starschema perfect. Dit zijn momenten waarop je het kunt gebruiken:

• Als je een semantisch model bouwt voor BI-tools (bijvoorbeeld Power BI) en je een laag aantal tabellen en relaties wilt. Het ondersteunt intuïtief filteren/groeperen en presteert vaak goed voor interactieve visuals.
• Als je eenvoudige queries wilt draaien, zoals totale verkoop per regio, gebruik dan een starschema. Omdat alle dimensietabellen direct met de feittabel zijn verbonden, vermijd je onnodige complexiteit en krijg je sneller antwoord.
• Je kunt ook een starschema gebruiken wanneer snelheid je prioriteit is. Het minimaliseert het aantal joins tussen tabellen, zodat je queries sneller draaien. Ik heb het eens gebruikt om meerdere verkooprapporten te genereren, wat me veel tijd bespaarde ten opzichte van andere ontwerpen.
• Als je dataset klein tot middelgroot is, zal de redundantie van het starschema geen probleem zijn. Zelfs met herhaalde data werkt het prima zonder je opslag te overbelasten.

Wanneer gebruik je een snowflakeschema

Het snowflakeschema is geschikter voor het weergeven van hiërarchieën en gedeelde referentiedata, vooral wanneer meerdere dimensiekenmerken zich over veel rijen herhalen. Dit zijn momenten waarop je het kunt gebruiken:

• Wanneer je dimensies duidelijke hiërarchieën hebben (bijvoorbeeld Land → Staat/Regio → Stad) en je die niveaus netjes als aparte tabellen wilt modelleren.​
• Als je sterkere controle wilt over gedeelde referentiedata (bijvoorbeeld standaardlijsten zoals categorieën, fabrikanten of geografische indelingen) om duplicatie te verminderen en definities eenvoudiger consistent te houden in het hele warehouse.
• Je kunt het snowflakeschema ook gebruiken als je data vaak verandert, zoals het updaten van regionamen. Het zorgt voor consistente updates in alle gerelateerde data om fouten en onderhoud te minimaliseren.
• Als je analyse meerdere dataniveaus omvat, helpt het snowflakeschema je om deze relaties overzichtelijk te organiseren en weer te geven.

Schema-selectie in clouddatawarehouses

In veel moderne clouddatawarehouses is opslag relatief goedkoop vergeleken met compute. Dat betekent dat de “extra opslag” door gedenormaliseerde dimensies vaak minder belangrijk is dan de compute-kosten van het scannen en joinen van data.

Kies je tussen star en snowflake, houd dan rekening met het prijsmodel van je platform (compute vs. storage), je queryconcurrentie en of je caching/materiële views kunt gebruiken om querykosten laag te houden.

Tot slot

In deze blog heb ik de verschillen tussen star- en snowflakeschema’s behandeld, hun sterke punten en wanneer je elk gebruikt. Hopelijk heb je nu een helder beeld en praktische tips voor je werk! Wil je meer leren, bekijk dan deze resources op DataCamp:

• De cursus Introduction to Data Modeling in Snowflake helpt je om je basis te leggen voor werken met Snowflake. 
• De cursus Data Modeling in Power BI voor het organiseren en beheren van data in Power BI.
• De skill track Associate Data Engineer in  SQL om je SQL-skills naar een hoger niveau te tillen.