Stjärnschema och design av datalager
Fakta- och dimensionstabeller, avvägningar kring denormalisering och OLAP-modellering.
Stjärnschema och design av datalager är en gratis lektion i Förberedelser inför SQL-intervjun på CoddyKit. Detta är lektion 3 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Förberedelser inför SQL-intervjun, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Förberedelser inför SQL-intervjun innehåller totalt 4 lektioner.
OLTP kontra OLAP
Frågor om datalager börjar med en skillnad som intervjuare förväntar sig att ni har full koll på: OLTP kontra OLAP.
- OLTP (transaktionsbaserat): många små läsningar och skrivningar, kraftigt normaliserat för dataintegritet. Driver applikationen.
- OLAP (analytiskt): ett fåtal stora, aggregerande läsningar över historik, medvetet denormaliserat för hög hastighet. Driver rapporter och dashboards.
Stjärnscheman är en OLAP-design. Hela poängen är snabba analytiska frågor, där man accepterar redundans i utbyte mot hastighet.
Fakta och dimensioner
Ett stjärnschema delar upp data i två slags tabeller:
- Faktatabell: de mätbara händelserna eller transaktionerna (en försäljning, ett klick). Innehåller numeriska mått och främmande nycklar till dimensionerna.
- Dimensionstabeller: det beskrivande sammanhang som ni analyserar utifrån (datum, produkt, kund, butik).
Faktatabellen ligger i mitten och dimensionerna omger den som stjärnans uddar, därav namnet.
Faktatabellens uppbyggnad
En faktatabell består huvudsakligen av främmande nycklar och numeriska mått. Den är lång och smal och växer kontinuerligt.
Mått är additiva tal som ni aggregerar: antal, intäkt, kostnad. Granulariteten (en rad = en ?) måste anges tydligt; här representerar en rad en produktrad i en försäljning.
CREATE TABLE fact_sales (
sale_id BIGINT PRIMARY KEY,
date_key INT NOT NULL, -- FK to dim_date
product_key INT NOT NULL, -- FK to dim_product
customer_key INT NOT NULL, -- FK to dim_customer
store_key INT NOT NULL, -- FK to dim_store
quantity INT, -- measure
revenue DECIMAL(12,2), -- measure
cost DECIMAL(12,2) -- measure
);Dimensionstabellens uppbyggnad
Dimensioner är korta och breda: de har många beskrivande kolumner som ni filtrerar och grupperar efter. De är avsiktligt denormaliserade så att en fråga bara behöver en join per dimension.
Observera att dim_product lagrar kategori och varumärke på samma rad i stället för i separata tabeller. Den redundansen är själva poängen: den undviker extra joins när frågan körs.
CREATE TABLE dim_product (
product_key INT PRIMARY KEY, -- surrogate key
product_id INT, -- natural/business key
product_name VARCHAR(100),
category VARCHAR(50), -- denormalized
brand VARCHAR(50), -- denormalized
unit_price DECIMAL(10,2)
);En fråga mot ett stjärnschema
Det är detta som designen möjliggör. En typisk analysfråga joinar faktatabellen med några få dimensioner, filtrerar och aggregerar. En join per dimension, inga djupa kedjor.
Intervjuare ber er ofta skriva exakt den här typen av fråga mot ett stjärnschema.
SELECT d.category,
t.year,
SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product d ON d.product_key = f.product_key
JOIN dim_date t ON t.date_key = f.date_key
WHERE t.year = 2025
GROUP BY d.category, t.year
ORDER BY total_revenue DESC;Surrogatnycklar
Dimensioner använder en surrogatnyckel: en meningslös heltalsbaserad primärnyckel (som product_key) som genereras av datalagret och är fristående från källsystemets naturliga nyckel.
Varför intervjuare bryr sig:
- Den frikopplar datalagret från affärsnycklar som förändras.
- Den håller faktatabellerna smala (joins på heltal är snabba).
- Den krävs för att spåra historik med långsamt föränderliga dimensioner (nästa avsnitt).
Långsamt föränderliga dimensioner
Det här är ett vanligt ämne i intervjuer om datalager: hur hanterar ni att ett dimensionsattribut ändras (till exempel att en kund flyttar till en annan stad)? Det kallas långsamt föränderliga dimensioner (SCD):
- Type 1: skriv över det gamla värdet. Ingen historik.
- Type 2: lägg till en ny rad med giltighetsdatum och en flagga som anger om raden är aktuell. Full historik; detta kräver surrogatnycklar.
- Type 3: behåll en kolumn för "föregående värde". Begränsad historik.
Type 2 är det vanligaste förväntade svaret när förändringar över tid ska spåras.
-- SCD Type 2 dimension
CREATE TABLE dim_customer (
customer_key INT PRIMARY KEY, -- surrogate
customer_id INT, -- natural key
city VARCHAR(50),
valid_from DATE,
valid_to DATE,
is_current BOOLEAN
);Stjärna kontra snöflinga
Räkna med en jämförelsefråga. Ett snöflingeschema normaliserar dimensioner till undertabeller (produkt -> kategori -> avdelning), medan ett stjärnschema håller dem platta.
- Stjärnschema: färre joins, snabbare läsningar, viss redundans. Föredras för frågeprestanda.
- Snöflingeschema: mindre lagringsutrymme och enklare underhåll av dimensioner, men fler joins per fråga.
Säg: "Välj som standard ett stjärnschema för frågehastighet; använd snöflingeschema endast när dimensionerna är stora och återanvänds."
Datumdimensionen
Nästan alla stjärnscheman har en särskild datumdimension i stället för en rå datumkolumn. Den beräknar i förväg år, kvartal, månad, veckodag, helgdagar och räkenskapsperioder.
Det gör att analytiker kan gruppera efter "räkenskapskvartal" eller "is_weekend" med en enkel join i stället för spridda datumfunktioner. Att nämna en datumdimension utan att bli tillfrågad är en stark signal om att ni har byggt datalager.
CREATE TABLE dim_date (
date_key INT PRIMARY KEY, -- e.g. 20250131
full_date DATE,
year INT,
quarter INT,
month INT,
day_of_week VARCHAR(10),
is_weekend BOOLEAN,
fiscal_qtr VARCHAR(6)
);Välja granularitet
Det viktigaste beslutet för en faktatabell är granulariteten: vad en rad representerar. Ange den innan något annat.
- För grov granularitet (en rad per dag och butik) gör att ni förlorar detaljer.
- För fin granularitet (en rad per skannad artikel) gör att tabellen exploderar i storlek.
Ett tydligt granularitetsuttalande, som "en rad per produkt och orderrad," styr vilka dimensioner och mått som hör hemma där. Intervjuare lyssnar efter den här disciplinen.
När denormalisering bör användas
Knyt det till normalisering. OLTP-system normaliseras till 3NF för dataintegritet; datalager denormaliserar medvetet dimensioner för snabbare läsningar.
Avvägningen ni måste kunna formulera:
- Redundanta dimensionsdata är acceptabla eftersom datalagret fylls med kontrollerad ETL, inte genom godtyckliga skrivningar från applikationen.
- Färre joins innebär snabbare aggregeringar över miljarder faktarader.
Det är omdömet, inte regeln, som skiljer seniora svar från andra här.
Snabb kontroll
Ni designar ett datalager för försäljning och behöver bevara full historik över en kunds stad när kunden flyttar.
Återblick: stjärnschema och datalagerdesign
Ni kan nu besvara frågor om datalagerdesign:
- OLTP normaliserar för dataintegritet; OLAP denormaliserar för snabbare läsningar.
- Ett stjärnschema har en central faktatabell (främmande nycklar + numeriska mått) omgiven av platta dimensioner.
- Använd surrogatnycklar och en särskild datumdimension.
- Spåra förändringar med SCD Type 2; ange faktatabellens granularitet först.
- Föredra stjärnschema framför snöflingeschema för bättre frågeprestanda.
Lär dig SQL med en AI-lärare – gratis
Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.
- Kurser
- 30
- Lektioner
- 120
Vanliga frågor
Är lektionen ”Stjärnschema och design av datalager” gratis?
Ja – hela texten till ”Stjärnschema och design av datalager” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Förberedelser inför SQL-intervjun, kan Ni uppgradera till CoddyKit PRO. Kursen i Förberedelser inför SQL-intervjun innehåller totalt 4 lektioner.
Vad lär jag mig i ”Stjärnschema och design av datalager”?
Fakta- och dimensionstabeller, avvägningar kring denormalisering och OLAP-modellering. Ni övar på Förberedelser inför SQL-intervjun med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.
Behöver jag någon erfarenhet för att börja lära mig Förberedelser inför SQL-intervjun?
Du behöver inga förkunskaper. Utbildningen i Förberedelser inför SQL-intervjun på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.
Hur lång tid tar lektionen ”Stjärnschema och design av datalager”?
De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.
Kan jag skriva och köra kod i den här Förberedelser inför SQL-intervjun-lektionen?
Ja. Varje Förberedelser inför SQL-intervjun-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.
Alla lektioner i den här kursen
- Normalisering till 3NF
- ER-modellering och relationskardinalitet
- Stjärnschema och design av datalager
- Komplett uppsättning övningsintervjuer