Stjerneskjema og utforming av datavarehus
Fakta- og dimensjonstabeller, avveininger ved denormalisering og OLAP-modellering.
Stjerneskjema og utforming av datavarehus er en gratis leksjon i Forberedelse til SQL-intervju på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Forberedelse til SQL-intervju, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Forberedelse til SQL-intervju inneholder totalt 4 leksjoner.
OLTP versus OLAP
Spørsmål om datavarehus begynner med ett skille som intervjuere forventer at De har full kontroll på: OLTP versus OLAP.
- OLTP (transaksjonelt): mange små lese- og skriveoperasjoner, sterkt normalisert for å sikre integritet. Driver appen.
- OLAP (analytisk): noen få store leseoperasjoner med aggregering over historikk, bevisst denormalisert for høy hastighet. Driver rapporter og dashbord.
Stjerneskjemaer er et OLAP-design. Hensikten er raske analytiske spørringer, der man aksepterer redundans som motytelse.
Fakta og dimensjoner
Et stjerneskjema deler data inn i to typer tabeller:
- Faktatabell: de målbare hendelsene eller transaksjonene (et salg, et klikk). Inneholder numeriske måltall og fremmednøkler til dimensjoner.
- Dimensjonstabeller: den beskrivende konteksten som brukes til filtrering og gruppering (dato, produkt, kunde, butikk).
Faktatabellen står i sentrum, mens dimensjonene omgir den som punktene i en stjerne. Derfor heter det et stjerneskjema.
En faktatabells anatomi
En faktatabell består hovedsakelig av fremmednøkler pluss numeriske måltall. Den er lang og smal og vokser kontinuerlig.
Måltall er summerbare tall som De aggregerer: antall, inntekt, kostnad. Granulariteten (én rad = én ?) må angis tydelig; her er én rad én produktlinje i ett salg.
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
);En dimensjonstabells anatomi
Dimensjoner er korte og brede: mange beskrivende kolonner som De filtrerer og grupperer etter. De er bevisst denormalisert slik at en spørring bare trenger én kobling per dimensjon.
Legg merke til at dim_product har kategori og merkevare på samme rad, i stedet for i separate tabeller. Denne redundansen er selve poenget: Den unngår ekstra koblinger når spørringen kjøres.
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 spørring mot et stjerneskjema
Dette er gevinsten ved designet. En typisk analysespørring kobler faktatabellen til noen få dimensjoner, filtrerer og aggregerer. Én kobling per dimensjon, uten dype kjeder.
Intervjuere ber Dem ofte skrive akkurat denne typen spørring mot et stjerneskjema.
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;Surrogatnøkler
Dimensjoner bruker en surrogatnøkkel: en meningsløs heltallsbasert primærnøkkel (som product_key) som genereres av datavarehuset og er adskilt fra kildesystemets naturlige nøkkel.
Derfor er dette viktig for intervjuere:
- Det frikobler datavarehuset fra forretningsnøkler som endres.
- Det holder faktatabellene smale (koblinger på heltall er raske).
- Det er nødvendig for å spore historikk med dimensjoner som endres over tid (neste scene).
Dimensjoner som endres over tid
Et populært tema i datavarehusintervjuer er hvordan De håndterer at et dimensjonsattributt endres, for eksempel når en kunde flytter til en annen by. Dette kalles dimensjoner som endres over tid (SCD):
- Type 1: overskriv den gamle verdien. Ingen historikk.
- Type 2: legg til en ny rad med gyldighetsdatoer og et flagg for gjeldende verdi. Full historikk; dette krever surrogatnøkler.
- Type 3: behold en kolonne for «forrige verdi». Begrenset historikk.
Type 2 er det vanligste forventede svaret når endringer over tid skal spores.
-- 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
);Stjerne- versus snøfnuggskjema
Forvent et sammenligningsspørsmål. Et snøfnuggskjema normaliserer dimensjoner til undertabeller (product -> category -> department), mens et stjerneskjema holder dem flate.
- Stjerne: færre koblinger, raskere lesing og noe redundans. Foretrukket for spørringsytelse.
- Snøfnugg: mindre lagringsbehov og enklere vedlikehold av dimensjoner, men flere koblinger per spørring.
Si: «Velg som standard stjerne for høy spørringshastighet; bruk bare snøfnugg når dimensjonene er store og gjenbrukes.»
Datodimensjonen
Nesten alle stjerneskjemaer har en egen datodimensjon i stedet for en rå datokolonne. Den beregner år, kvartal, måned, ukedag, helligdagsflagg og regnskapsperioder på forhånd.
Dermed kan analytikere gruppere etter «regnskapskvartal» eller «is_weekend» med en enkel kobling i stedet for spredte datofunksjoner. At De nevner en datodimensjon uten å bli spurt, er et sterkt signal om at De har bygget datavarehus.
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)
);Velge granularitet
Den viktigste beslutningen for en faktatabell er granulariteten: hva én rad representerer. Fastslå dette før alt annet.
- For grovt (én rad per dag per butikk), og De mister detaljer.
- For fint (én rad per skannet vare), og tabellen eksploderer i størrelse.
En tydelig granularitetsbeskrivelse, som «én rad per produkt per ordrelinje», avgjør hvilke dimensjoner og måltall som hører hjemme der. Intervjuere legger merke til denne disiplinen.
Når bør man denormalisere
Knytt dette tilbake til normalisering. OLTP-systemer normaliseres til 3NF for å sikre integritet, mens datavarehus bevisst denormaliserer dimensjoner for raskere lesing.
Avveiningen De må kunne forklare:
- Redundante dimensjonsdata er akseptable fordi datavarehuset lastes gjennom kontrollert ETL, ikke gjennom tilfeldige skrivinger fra appen.
- Færre koblinger gir raskere aggregeringer over milliarder av faktarader.
Det er vurderingsevnen, ikke regelen i seg selv, som skiller svar på seniornivå fra andre svar.
Hurtigsjekk
De designer et datavarehus for salg og må bevare full historikk over hvilken by en kunde bodde i da kunden flyttet.
Oppsummering: Stjerneskjema og datavarehusdesign
De kan nå svare på spørsmål om modellering av datavarehus:
- OLTP normaliserer for å sikre integritet; OLAP denormaliserer for raskere lesing.
- Et stjerneskjema har en sentral faktatabell (FK-er + numeriske måltall), omgitt av flate dimensjoner.
- Bruk surrogatnøkler og en egen datodimensjon.
- Spor endringer med SCD Type 2, og fastslå faktatabellens granularitet først.
- Foretrekk stjerne fremfor snøfnugg for best spørringsytelse.
Lær deg SQL med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 30
- Leksjoner
- 120
Ofte stilte spørsmål
Er leksjonen «Stjerneskjema og utforming av datavarehus» gratis?
Ja – hele teksten i «Stjerneskjema og utforming av datavarehus» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Forberedelse til SQL-intervju-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Forberedelse til SQL-intervju inneholder totalt 4 leksjoner.
Hva lærer jeg i «Stjerneskjema og utforming av datavarehus»?
Fakta- og dimensjonstabeller, avveininger ved denormalisering og OLAP-modellering. Du øver på Forberedelse til SQL-intervju med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Forberedelse til SQL-intervju?
Ingen tidligere erfaring er nødvendig. Forberedelse til SQL-intervju på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.
Hvor lang tid tar leksjonen «Stjerneskjema og utforming av datavarehus»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Forberedelse til SQL-intervju-leksjonen?
Ja. Alle Forberedelse til SQL-intervju-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Normalisering til 3NF
- ER-modellering og kardinalitet i relasjoner
- Stjerneskjema og utforming av datavarehus
- Komplett sett med prøveoppgaver til intervju