Stjerneskemaet

I dag er rapporter og analyser næsten lige så vigtige som kerneforretningen. Rapporter kan bygges ud af dine live data; ofte vil denne tilgang gøre det trick for små og mellemstore virksomheder uden masser af data. Men når tingene bliver større - eller mængden af ​​data begynder at stige dramatisk - er det tid til at tænke på at adskille dine drifts- og rapporteringssystemer.

Før vi tackler grundlæggende datamodellering, har vi brug for lidt baggrund om de involverede systemer. Vi kan groft opdele systemer i to kategorier:drifts- og rapporteringssystemer. Operationelle systemer kaldes ofte Online Transaction Processing (OLTP). Rapporterings- og analysesystemer omtales som Online Analytical Processing (OLAP). OLTP-systemer understøtter forretningsprocesser. De arbejder med "live" driftsdata, er meget normaliserede og reagerer meget hurtigt på brugerhandlinger. På den anden side er det primære formål med OLAP-systemerne analyser. Disse systemer bruger opsummerede data, som normalt placeres i en denormaliseret datavarehusstruktur som stjerneskemaet. (Hvad er denormalisering? Kort sagt, det er at have overflødige dataregistreringer af hensyn til bedre ydeevne. Læs mere.)

Nu hvor vi ved lidt om systemerne, lad os begynde at undersøge datavarehuset og dets dele og processer.

Datavarehuse vs. Data Marts

Et datavarehus (DWH) er et system, der bruges til at lagre information til brug for dataanalyse og rapportering. Datamarts er områder af et datavarehus, der bruges til at gemme information, der er nødvendig af en enkelt afdeling eller endda af en individuel bruger. (Tænk på DWH som en bygning og data marts som kontorer inde i bygningen.)

Hvorfor er der brug for data marts? Alle relevante data opbevares i virksomheden DWH. De fleste brugere behøver dog kun at få adgang til visse delmængder af data, såsom dem, der vedrører salg, produktion, logistik eller marketing. Data marts er vigtige fra både et sikkerhedssynspunkt (begrænser unødvendig adgang) og fra et brugersynspunkt (vi ønsker ikke at forvirre dem eller tvinge dem til at vade gennem uvedkommende data).

Der er to forskellige tilgange til forholdet mellem datavarehus og datamarked:

• Top-down :Data marts oprettes fra datavarehuset. (Dette er noget, som Bill Inmon, "datavarehusets fader", ville være enig i, sammen med ideen om, at varehuse skulle være i 3NF.)
• Bund og op :Data marts oprettes først og kombineres derefter til et datavarehus. (Denne tilgang er tættere på, hvad Ralph Kimball, et datavarehus og ekspert i dimensionsmodellering, går ind for.)

ETL-processen bruges til at tilføje "nye" data til OLAP-systemet med jævne mellemrum. ETL er en forkortelse for Extract, Transform og Load. Som navnet antyder, udtrækker vi data fra en eller flere operationelle databaser, transformerer dem, så de passer til vores lagerstruktur, og indlæser dataene i DWH.

Dimensional modellering , som er en del af data warehouse design, resulterer i skabelsen af ​​den dimensionelle model. Der er to typer tabeller involveret:

• Dimensionstabeller bruges til at beskrive de data, vi ønsker at gemme. For eksempel:en forhandler ønsker måske at gemme datoen, butikken og medarbejder, der er involveret i et bestemt køb. Hver dimensionstabel er sin egen kategori (dato, medarbejder, butik) og kan have en eller flere attributter . For hver butik kan vi gemme dens placering på by-, regions-, stats- og landeniveau. For hver dato kan vi gemme år, måned, dag i måneden, ugedag osv. Dette er relateret til hierarkiet af attributter i dimensionstabellen.

  I stjerneskemaet vil vi normalt opdage, at nogle attributter er en delmængde af andre attributter i samme post. Denne redundans er bevidst og udført i navnet på bedre ydeevne. Vi kunne bruge dato-, lokations- og salgsagentdimensioner til at aggregere (transformationsdelen af ​​ETL-processen) og gemme data inde i DWH. I dimensionsmodellering er det meget vigtigt at definere de rigtige dimensioner og vælge korrekt granulering.

• Faktatabeller indeholde de data, vi ønsker at inkludere i rapporter, aggregeret baseret på værdier i de relaterede dimensionstabeller. En faktatabel har kun kolonner, der gemmer værdier og fremmednøgler, der refererer til dimensionstabellerne. Kombination af alle fremmednøgler danner den primære nøgle i faktatabellen. En faktatabel kan f.eks. gemme et antal kontakter og antallet af salg, der er resultatet af disse kontakter.

Med denne info på plads kan vi nu grave i stjerneskemadatamodellen.

Stjerneskemaet

Stjerneskemaet er den enkleste model, der bruges i DWH. Fordi faktatabellen er i midten af ​​skemaet med dimensionstabeller omkring den, ligner den nogenlunde en stjerne. Dette er især tydeligt, når faktatabellen er omgivet af femdimensionelle tabeller. En variant af stjerneskemaet centipede-skemaet , hvor faktatabellen er omgivet af en lang række små dimensionstabeller.

Stjerneskemaer er meget almindeligt brugt i data marts. Vi kan relatere dem til top-down datamodeltilgangen. Vi analyserer to stjerneskemaer (data marts) og kombinerer dem derefter til en enkelt model.

Stjerneskemaeksempel:Salg

Salgsrapporten er en af ​​dagens mest almindelige rapporter. Som vi nævnte før, kunne vi i de fleste tilfælde generere salgsrapporter fra live-systemet. Men når data eller virksomhedsstørrelse gør dette for besværligt, bliver vi nødt til at bygge et datavarehus eller et datamarked for at strømline processen. Efter at have designet vores stjerneskema, en ETL processen henter data fra operationelle database(r), transformerer dataene til det korrekte format for DWH og indlæser dataene i lageret.

Modellen præsenteret ovenfor indeholder en faktatabel (farvet lyserød) og fem dimensionstabeller (farvet lyseblå). Tabellerne i modellen er:

• fact_sales – Denne tabel indeholder referencer til dimensionstabellerne plus to fakta (pris og solgt mængde). Bemærk, at alle fem fremmednøgler tilsammen udgør den primære nøgle i tabellen.
• dim_sales_type – Dette er en dimensionstabel af salgstype med kun én attribut, "type_name ”.
• dim_employee – Dette er en medarbejderdimensionstabel, der gemmer grundlæggende medarbejderattributter:fulde navn og fødselsår.
• dim_product – Dette er en produktdimensionstabel med kun to attributter (ud over den primære nøgle):produktnavn og produkttype.
• dim_time – Denne tabel håndterer tidsdimensionen. Den indeholder fem attributter udover den primære nøgle. Dataene på det laveste niveau er salg efter dato (action_date ). action_week attribut er nummeret på ugen i det pågældende år (dvs. den første uge i januar vil få tallet 1; den sidste uge i december vil få tallet 52 osv.) actual_month og actual_year attributter gemmer den kalendermåned og -år, hvor salget fandt sted. Disse kan udtrækkes fra action_date attribut. action_weekday attribut gemmer navnet på den dag, hvor salget fandt sted.
• dim_store – Det er en butiksdimension. For hver butik gemmer vi den by, region, stat og land, hvor den er placeret. Her kan vi tydeligt bemærke, at stjerneskemaet er denormaliseret.

Eksempel på stjerneskema:Forsyningsordrer

Der er mange ligheder mellem denne model, vist nedenfor, og salgsmodellen.

Denne model er beregnet til at gemme historikken for afgivne ordrer. Vi har en faktatabel og fire dimensionstabeller. Dimensionstabellerne dim_employee , dim_product og dim_time er nøjagtig de samme som i salgsmodellen. Følgende tabeller er dog forskellige:

• fact_supply_order – indeholder aggregerede data om de afgivne ordrer.
• dim_supplier – er en dimensionstabel, der gemmer leverandørdata på samme måde som dim_store opbevarede butiksdata i salgsmodellen.

Fordele og ulemper ved stjerneskemaet

Der er masser af fordele ved at bruge stjerneskemaet. Faktatabellen er relateret til hver dimensionstabel med nøjagtig én relation, og vi har ikke brug for yderligere ordbøger for at beskrive dimensionstabeller. Det forenkler forespørgsler og reducerer udførelsestiden for forespørgsler. Vi kunne producere den samme rapport direkte fra vores OLTP-system, men forespørgslen ville være meget mere kompleks, og det kunne påvirke systemets overordnede ydeevne. Følgende eksempelforespørgsel for salgsmodellen returnerer mængden af ​​alle telefontyper, der sælges i Berlin-butikker i 2016:

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

Den største ulempe ved stjerneskemaet er redundans. Hver dimension er gemt i en separat dimensionstabel, og dette forårsager denormalisering. I vores eksempel hører by til en region eller stat, som tilhører et land; vi gemmer ikke denne relation som regel i vores database, men vi gentager den hele tiden. Det betyder, at vi bruger mere diskplads og har en risiko for dataintegritet.

Galaxy-skemaet

Vi kan se på de to tidligere modeller som to data marts, den ene til salgsafdelingen og den anden til forsyningsafdelingen. Hver af dem består kun af én faktatabel og nogle få dimensionelle tabeller. Hvis vi ville, kunne vi kombinere disse to data marts til én model. Denne type skema, der indeholder flere faktatabeller og deler nogle dimensionstabeller, kaldes et galakseskema . Deling af dimensionstabeller kan reducere databasestørrelsen, især hvor delte dimensioner har mange mulige værdier. Ideelt set er dimensionerne i begge data marts defineret på samme måde. Hvis det ikke er tilfældet, bliver vi nødt til at justere dimensionerne, så de passer til begge behov.

Et galakseskema, bygget ud af vores to eksempler på data marts, er vist nedenfor:

Stjerneskemaet er en tilgang til at organisere et datavarehus. Det er meget ligetil og bruges oftest i data marts. Hvis vi ikke behøver at bekymre os om diskplads, og vi passer godt på dataintegriteten, så er stjerneskemaet et levedygtigt første og bedste valg. Hvis ikke, bør vi overveje en anden tilgang. Det ene er snefnugskemaet, som vi vil diskutere i en kommende artikel.