Stjernemodell

Innen databehandling er en **stjernemodell**,  også kalt et **stjerneskjema** eller **stjernediagram**, en enkel modell for flerdimensjonal dataanalyse, og er kanskje den vanligste tilnærmingen for å utvikle datavarehus og dimensjonale datatorg. Stjernemodellen består av en eller flere faktatabeller som refererer til et hvilket som helst antall dimensjonstabeller. Retningen til kardinalitetspilene vil ofte peke i retning av faktatabellen i en relasjon, hvilket vil være mot midten i en stjernemodell. Stjernemodellen er et viktig spesialtilfelle av snøflakmodellen, og er mer effektiv i å håndtere enkle spørringer.

Stjernemodellen har fått sitt navn av at den fysiske datamodellen minner om formen til et stjernepolygon med faktatabellen i midten og dimensjonstabellene rundt.

## Modell
Stjernemodeller deler data fra forretningsprosesser inn i:

* Fakta som inneholder de målbare, kvantitative dataene om en virksomhet, og
* Dimensjoner som er deskriptive attributter som er relatert til fakta-dataene

Eksempler på faktadata er salgspris, salgmengde og tid, avstand-, hastighet- og vektmålinger. Eksempler på relaterte dimensjonsattributter inkluderer produktmodeller, produktfarger, produktstørrelser, geografiske lokasjoner og navn på selgere. (Selv om det finnes «typiske» fakta- og dimensjonstabeller, er det også eksempler på at det som tradisjonelt betraktes som en faktatabell i noen tilfeller tas i bruk som en dimensjonstabell. Imidlertid tillater ikke alle systemer dette.)

En stjernemodell som har mange dimensjoner har av noen blitt kalt en "tusenbeinmodell" (*centipede schema*). Å ha dimensjoner med bare noen få attributter gjør modellen enklere å vedlikeholde, men resulterer i spørringer med mange tabellskjøter og gjør en stjernemodell mindre lett å bruke.

### Faktatabeller
I faktatabeller registreres målinger eller beregninger for en bestemt hendelse. Faktatabeller består vanligvis av numeriske verdier, samt fremmednøkler til dimensjonale data hvor deskriptiv informasjon er lagret. Faktatabeller er laget for å ha uniforme detaljer på et veldig lavt nivå (høy granularitet), hvilket betyr hendelser kan registreres på et svært atomisk nivå. Dette kan medføre at det akkumuleres et stort antall oppføringer i en faktatabell over tid.Faktatabeller kan deles inn i tre typer:

* Transaksjon-faktatabeller: Fører opp fakta om en bestemt hendelse (for eksempel salgshendelser)
* Snapshot-faktatabeller: Fører opp fakta på et gitt tidspunkt (for eksempel kontodetaljer ved slutten av måneden)
* Akkumulerende snapshot-faktatabeller: Fører opp aggregerte fakta på et gitt tidspunkt (for eksempel samlede salg måned-til-dato for et produkt)

Faktatabeller tildeles vanligvis en surrogatnøkkel for å sikre at hver rad kan bli unikt identifisert. Denne nøkkelen er en enkel primærnøkkel.

### Dimensjonstabeller
Dimensjonstabller har vanligvis et relativt lite antall oppføringer (*records*) sammenlignet med faktatabeller, men hver oppføring kan ha et veldig stort antall attributter for å beskrive faktadataene. Dimensjoner kan definere et bredt utvalg av egenskaper, men noen av de mest vanlige attributtene som er definert av dimensjonstabeller inkluderer:

* Tabeller for tiddimensjon: Beskriver tiden med det laveste nivået av granularitet for hendelser som skal registreres i stjernemodellen.
* Tabeller for geografidimensjon: Beskriver lokasjonsdata, for eksempel land, fylke eller by.
* Tabeller for produktdimensjon: Beskriver produkter.
* Tabeller for ansattdimensjon: Beskriver ansatte, for eksempel selgere.
* Tabeller som beskriver intervaller eller spenn av tid, pengeverdier eller andre målbare mengder som kan forenkle rapportering

Dimensjonstabeller blir vanligvis tildelt en surrogat-primærnøkkel, som typisk er av datatypen heltall og i en enkelt kolonne. Den avbildes til kombinasjonen av dimensjonsattributter som danner den naturlige nøkkelen.

## Fordeler
Stjernemodeller er denormaliserte, hvilket betyr at typiske regler for normalisering i transaksjonsbaserte relasjonsdatabaser ikke håndheves så sterkt når man designer og bygger basert på stjernemodellen. Fordeler med denormaliseringen i stjernemodellen er:

* Enklere søk: Stjernemodellens skjøtlogikk (*join logic*) er som regel enklere enn skjøtelogikken som kreves for å hente data fra en svært normalisert transaksjonslogikk.
* Forenklet logikk for forretningsrapportering: Sammenlignet med et svært normalisert modell forenkler stjernemodellen en virksomhets delte rapporteringslogikk, som tid over tid (eksempelvis år over år, måned over måned, osv.) eller øyeblikks-rapportering.
* Bedre ytelse: For rapporteringsapplikasjoner med *read-only*-tilgang kan stjernemodeller gi bedre ytelse for sammenlignet med svært normaliserte datamodeller.
* Rask aggregering: De enklere spørringene mot en stjernenmodell kan gi bedre ytelse for aggregeringsoperasjoner.
* Fôring av kuber: Stjernemodeller brukes i alle OLAP-systemer for å effektivt bygge proprietære OLAP-kuber. Faktisk har de fleste store OLAP-systemer en driftsmodus for relasjons-OLAP (ROLAP) hvor man kan bruke en stjernemodell direkte som en kilde uten å bygge en proprietær kubestruktur.

## Ulemper
Den største ulempen med stjernemodellen er at den ikke er like fleksibelt som en normalisert datamodell med tanke på analytiske behov. Normaliserte modeller tillater utføring av alle former for analytiske spørringer så lenge de følger forretningslogikken som er definert i modellen. Stjernemodeller har en tendens til å være mer spesialtilpassede for en bestemt visning av dataene, og tillater dermed egentlig ikke mer komplekse analyser. Stjernenmodellen støtter ikke med letthet mange-til-mange-relasjoner mellom entiteter i foretaket. Det er typisk at disse relasjonene har blitt forenklet i en stjernemodell for å samsvare med den enkle dimensjonale modellen.

En annen ulempe er at dataintegritet ikke håndheves godt på grunn av den denormaliserte tilstanden. Engangs-inserts og -updates kan føre til anomalier som normaliserte modeller er laget for å unngå. Generelt sett blir stjernemodeller lastet på en svært kontrollert måte via batch-prosessering eller i nær sanntids "*trickle-feeds*" for å kompensere for det manglende vernet man kunne fått av normalisering.

## Eksempel

Anta at man har en salgsdatabase for en butikkkjede klassifisert etter dato, butikk og produkt. Modellen til høyre er en stjernemodell-versjon av eksempelmodellen i artikkelen om snøflakmodell.

`Fact_Sales` er faktatabellen, og det er tre dimensjonstabeller kalt `Dim_Date`, `Dim_Store` og `Dim_Product`.

Hver dimensjonstabell har en primærnøkkel på sin `ID`-kolonne, som er knyttet til en av kolonnene (vist som rader i eksempelmodellen) i `Fact_Sales`-tabellen er trekolonnede (sammensatte) primærnøkkel (`Date_Id`, `Store_Id`, `Product_Id`). Ikke-primærnøkkel-kolonnen `Units_Sold` i faktatabellen i dette eksempelet representerer en måling eller beregning som kan brukes til beregninger og analyse. Ikke-primærnøkkel-kolonnene i dimensjonstabellene representerer flere attributter av dimensjonene (for eksempel `Year` (året) til `Dim_Date`-dimensjonen).

For eksempel vil den følgende spørringen svare på hvor mange TV-apparater har blitt solgt i 1997 for hvert merke og land:
```sql
SELECT
	P.Brand,
	S.Country AS Countries,
	SUM(F.Units_Sold)

FROM Fact_Sales F
INNER JOIN Dim_Date D    ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S   ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)

WHERE D.Year = 1997 AND  P.Product_Category = 'tv'

GROUP BY
	P.Brand,
	S.Country
```


## Se også
* Datavarehus
* Online analytisk prosessering
* Omvendt stjernemodell
* Snøflakmodell
* Faktasammenstilling

## Referanser