data warehouse

Vi er Microsoft Gold Partner. Som nogle af landets førende inden for feltet, har vores specialister 100 % fokus på Microsoft SQL og opbygning af Data Warehouse

Scroll
Anders Strube Anders Strube Key Account Manager
Kontakt Anders
eller bliv ringet op når det passer dig
0

kunder

0

brugere

0

medarbejdere

Se vores kurser om Data Warehouse

Microsoft SQL Data Warehouse med SSIS, SSRS

Hvad er et Data Warehouse?

Et Data Warehouse er kort fortalt en samling af data, hvor vi har data liggende vi gerne vil kunne måle på.  Data Warehouse er ikke et stykke software, men nærme sammenspillet mellem flere forskellige typer af software. I unit IT bygger vi f.eks. Data Warehouses med Microsoft SQL Server som database, og så benytter vi typisk Microsoft Power BI til at bygge rapporter.

Et Data Warehouse er ikke en database, men et Data Warehouse ligger fysisk i en eller flere databaser alt efter hvordan det er sat op.

Referencer

gf-forsikring.jpg
universal-robots.jpg
odense-kommune.jpg
sdk_rgb.jpg
krifa.jpg
rema-1000.jpg
system-frugt.jpg
DK Company.jpg
Københavns Kommune
wuerth
Sydbank
Kolding_Kommune.png
abena logo.png

Processen fra kilder til Data Warehouse

Det er vigtigt at have et sted hvor forretningen er enige om at dette er sandheden om vores data. Hvad er en kunde i vores virksomhed?, hvornår er et salg et salg?; Er det når ordren er afgivet eller når varen er leveret?. Det er vigtigt at træffe nogle beslutninger om data inden de transformeres og loades ind i et Data Warehouse. Dette starter typisk med at identificere en forretnings proces hvor der skabes nogle facts og dimensions tabeller. Disse loades via ETL proces i SSIS (Extract, Transform Load).

Når det er identificeret hvad det er der skal måles på (facts) så bygges processen, der integrerer data fra kilder til Data Warehouse.  Data hentes fra kilder (NAV, AX, CRM osv.) og transformeres og loades ind i Data Warehouse. Denne proces kaldes ETL, som står for Extract, Transform, load. Processen er ikke software afhængig, det kan gøres på mange måder, i Unit IT bruger vi SQL Server Integration Service (SSIS) samt T-SQL til denne proces når det er on-prem. I Azure er der yderligere mulighed for at bruge Data factory (SSIS i skyen), Data Lake, Azure automation, Data Bricks osv. Typisk styres ETL flowet af et SQL job, som så afvikler SSIS pakkerne og opdaterer Data Warehouse data.

Data Warehouse koncept:
Konceptuelt findes der 2 anerkendte metoder at ”bygge” et Data Warehouse på. Inmon og Kimball. De har en meget forskellig tilgang til opbygningen af et Data Warehouse. Inmon benytter normaliseret data model hvor Kimball er bygget over et star schema. Kimball er bl.a. også hurtigere og billigere at komme i gang med end inmons metode. I unit IT benytter vi Kimballs model for opbygning af et Data Warehouse, baseret på en Microsoft SQL Server. Valget af software er ikke afhængigt af metoden man vælger, og man kan sagtens bygge efter Kimballs metode på postgres, mysql, oracle osv. I Unit IT har vi rigtig mange års erfaring med Microsoft SQL Server og opsætning, performance og vedligehold heraf, så derfor er vores software base til et Data Warehouse en Microsoft SQL Server, det kan både være on-prem og i Azure.

 

Download Power BI

Har din virksomhed også et ønske om, at du og resten af it-afdelingen fokuserer mere direkte på forretningen fremfor på teknikken?

 

Download gratis Power BI

Data Warehouse ”lag”
I vores Data Warehouse framework arbejder vi med lag til at styre processen. Extract, Archive, staging, Dimension og fact. (Disse er implementeret som SQL Schemas)

Extract:
Her hentes data direkte fra kilderne. Vi henter altid 1:1, det vil sige alle kolonner og alle rækker fra kilderne.
Første gang hentes alt fra kilden herefter læses der kun ændret data ud, dette giver et minimalt performance hit på kilderne, og er samtidig også en af de store gevinster ved et Data Warehouse.

Archive:
Her ligger data også 1:1. Arkivlaget opdateres fra extract laget. Fordelen er at der kan skabes en historik som ikke nødvendigvis er på kilderne. Vi benytter en type 2 historik, som betyder at vi gemmer rækken som den så ud når den opdateres og indsætter en ny gældende række i arkivet. Fordelen er at arkivlaget altid afspejler hvordan data så ud i et givent tidsrum. F.eks. en vare, der er på kampagne; her er gemt både prisen før, under og efter kampagnen så når der kigges i data, vil det altid afspejle den rigtige pris for denne vare på det pågældende tidspunkt.

Staging:
Dette Data Warehouse lag benyttes til at forberede data på vej mod dimension og fact tabellerne. Her begynder der at komme forretningslogik ind i processen, hvor extract og archive lagene er en kopi af kilderne 1:1 (med historik) så tages der stilling til hvilke kolonner og rækker der skal med samt fra hvilke tabeller.

Dimension:
Dimensions tabeller er tabeller som fortæller noget om det vi vil måle på f.eks. en kunde. I tabellen ligger der informationer om navn, adresse, mail osv. Hver kunde får et unikt ID i Data Warehouse, dette ID skal bruges når der refereres til kunden i fact tabellen. Dimensionstabellen kan også have historik, typiske benyttes Type-2 historik.

Fact:
I disse tabeller ligger det data der kan måles på, f.eks. prisen for en varer, et samlet salg. Ud over det der kan måles på (altså tal der kan lægges sammen) så er der også referencer til det som fortæller noget om hvad der måles på, der er en ID fra den/de dimensionstabeller.

Skab en datadreven kultur med et optimeret data warehouse

Find klarhed i data, når du har mest brug for det

Giv teammedlemmer mulighed for at opdage indsigter, der er skjult i dine data.

Annette Jelle
CIO, Verdo

”Folkene hos Unit IT er fagligt yderst kompetente, og for mig er der ingen tvivl om, hvad de står for: professionalisme og skarphed. De er dygtige mennesker, der kan sætte det rigtige hold til den opgave, de står overfor.”

Læs hele casen
VERDO_02102017_Overvaagning.jpg

Hvordan arbejder du med et data warehouse?

Der kan arbejdes med Data Warehouse lag på forskellige måder. Vi benytter typisk SQL schemas til det men hvis det er et meget stort setup så kan det sagtens være at lagene er delt i flere forskellige databaser.

Kimballs Data Warehouse metode introducerer også to typer af schemas: Star- og Snowflake schema.

Et star schema hedder det fordi der er relation mellem en fact og flere dimensionstabeller, hvilket visuelt kan illustreres som en stjerne:

Da det typisk ikke er normaliseret data i et Data Warehouse bygget på kimballs metode der kan dog nogle gange være behov for at referere mellem 2 eller flere dimensionstabeller, når man har denne struktur, kaldes det et snowflake schema.

Data Warehouse bygget på kimballs metode

Gør det til en fordel at benytte star schema

SQL Serveren kan genkende star schema strukturen og kan derved optimere sine forespørgsler, hvilket gør det til en fordel at benytte star schema i sin Data Warehouse arkitektur. Dette vil være med til at øge performance.

 

Hvorfor Power BI

Kom i gang allerede i dag

 

Download gratis Power BI
  • Power BI er en nem og hurtig måde at komme i gang med at visualisere data på.
  • Traf beslutninger ud fra data og ikke mavefornemmelse.
  • Data understøtter beslutninger på strategisk-, taktisk- og operationelniveau.

Certificeringer

Microsoft Gold Partner

Som et af de få konsulenthuse i Danmark har Unit IT opnået status som: Microsoft Gold Partner på Data Platform. For at opnå titlen er der krav til et højt kompetenceniveau, høj kundetilfredshed og gennemarbejdet dokumentation for veludført arbejde.

Danish Cloud Community

Vi er certificeret medlem af Danish Cloud Community i perioden 16.03.18 – 15.03.19, som dokumenterer at Unit IT efterlever krav om høj kvalitet og sikkerhed inden for kommerciel drift af forretningskritiske it-ydelser samt skaber øget gennemsigtighed for købere af disse ydelser.

Data Warehouse arkitektur

Konceptuelt kan et Data Warehouse, ikke en database, have forskellig arkitektur. Der kan være et centraliseret Data Warehouse hvor alle rapporter og ad-hoc forespørgsler trækker på en og samme database. Denne arkitektur er meget almindelig at benytte som opstart. Det er også muligt at bygge et Data Warehouse med flere ”Data Marts” – f.eks. lavet til forskellige afdelinger, eller dele af firmaet – Et Data Mart er flere databaser som hver indeholder en lille del af Data Warehouse. Endelig kan der også være et centraliseret Data Warehouse hvor der hentes data fra til Data Marts det kaldes hub-and-spoke arkitektur. Illustreret her i dette Data Warehouse arkitektur diagram:

Data Warehouse i Azure

 

Data Warehouse er ikke et stykke software men et koncept. Så om det ligger i Azure eller på egne servere er underordnet. Laves et Data Warehouse i Azure så er der også her flere forskellige løsningsmuligheder for at implementere det. I Azure er der nogle tools som kan gøre det lettere at samle data fra forskellige devices f.eks. ved brug at data lakes eller data factory. Microsoft Azure har også en komplet løsning; Azure Synapse som er ideelt til big data. Vi vejleder meget gerne om det helt rigtige løsning baseret på dit behov og datamængde.

Partnere

citrix_grey.png (1)
microsoft_grey.png (1)
csis_grey.png (1)
topdesk_grey.png (1)
lenovo_grey.png (1)

Kræver det specialviden at administrere et Data Warehouse

Det kræver selvfølgelig viden om at udvikle i SQL hvis I selv vil rette i backend, eller viden om Power BI hvis der skal rettes i rapporten. Vi hjælper gerne med det og deler også meget gerne vores viden med jer så I er er så godt klædt på som muligt. Udviklingen af et Data Warehouse er et tæt samarbejde mellem Unit IT og forretningen, hvor viden forankres i forretningen også hvis det er ønsket. Unit IT kan også stå for det hele både udvikling og test og drift, det kommer helt an på hvad jeres behov er og hvilke kompetencer der er i virksomheden. Vi er gode til at dele vores viden og laver derfor gerne kurser eller sidemandsoplæring for at højne vidensniveauet i huset.

Det tager selvfølgelig tid at bygge et Data Warehouse, både at forstå forretningen og blive enige om en datamodel internt i virksomheden, der skal besluttes hvilken Data Warehouse arkitektur der skal benyttes, og besluttes om det skal bygges på virksomhedens servere, hos en host eller i Azure.

Ved at benytte Kimballs model kan et Data Warehouse bygges væsentligt hurtigere og til en noget lavere startomkostning end ved at bruge Inmons model. Kimballs model er også skalerbar så det giver god mening at starte småt med en proces, der skaber værdi for forretningen og som er relativt hurtig at implementere, dette giver værdi til brugerne og virksomheden begynder at få et fælles billede af data.

 

Tager det lang tid at bygge?

Hvordan bygges et Data Warehouse?

I unit IT har vi vores eget Data Warehouse framework, som er bygget efter mange års erfaring med SQL Server drift. Det er vigtigt at have et godt fundament når et Data Warehouse skal skabes. Desuden har vi udviklet vores egne værktøjer som bl.a benytter BIML express til hurtigt at trække data ud fra langt de fleste kildesystemer. Det vil sige, at vi altid bygger Data Warehouses på den samme måde, men er alligevel ret fleksible og tilpasser altid løsningen efter kundernes behov – vi vil ikke bygge en raket hvis behovet kan dækkes af en papirsflyver. Raketten kan altid komme og vores løsning er designet til at fungere både til mindre Data Warehouses og til de helt store.

Der bliver i de fleste virksomheder over tid trukket flere og flere rapporter på kilde systemerne, disse rapporter kunne være udstillet i Power BI, i Reporting Services (SSRS) eller direkte fra Excel. Ved øget rapportbrug belastes kildesystemerne mere og mere. Ved at bygge et Data Warehouse flyttes belastningen af rapportforespørgsler fra kildesystemerne over til Data Warehouse. En anden gevinst ved at bygge et Data Warehouse er at virksomheden bliver bevist om sine data, og får et fælles billede af f.eks. en kunde, et salg osv. I Data Warehouse forberedes data og kommer ind i en model, der er lavet til netop rapportering, vi benytter primært Power BI, men det kan udstilles i alt software lavet til at vise rapporter.

 

Hvorfor bygge et Data Warehouse?

Magien opstår, når vi arbejder helt tæt sammen.

LinkedIn

Linkedin.com
seneste linkedin opslag
linkedin
15. september 2021

Hvis du vil være en del af Danmarks Mest Anbefalede Virksomhed 2020, så er chancerne gode lige nu. Vi vækster, og søger derfor hele syv skarpe profiler indenfor det kommercielle.

Seneste artikel

Alle artikler
Webscrape -> SQL
24. juni 2021
Webscrape -> SQL

Der er mange forskellige metoder til at importere data i SQL Serveren, fra Excel, CSV, XML, txt osv.

Artikler relateret til SQL Unit

Webscrape -> SQL
24. juni 2021
Webscrape -> SQL

Der er mange forskellige metoder til at importere data i SQL Serveren, fra Excel, CSV, XML, txt osv.

SQL BI
PuTTY
10. november 2020
PuTTY

Jeg ved ikke hvorfor jeg ofte kommer til at kæmpe med SSIS, men denne gang var jeg virkelig tæt på at smide håndklædet i ringen.

06. oktober 2020
Parallelisering hvorfor ikke bare bruge alle CPU’er hver gang

Parallelisering er når SQL Serveren benytter mere end én CPU til at udføre sin forespørgsel. Det lyder jo teoretisk...

SQL BI
30. september 2020
SSIS: LocaleId 8192 is not installed

Problemet virkede underligt og løsningerne mange, som alle sammen alligevel ikke virkede.. før jeg kiggede på det åbenlyse.

25. september 2020
Extended Events

I min verden er Extended Events et must at kende til hvis du er DBA eller blot SQL nørd. Der er et væld af informationer vi kan få

26. august 2020
UNIQUEIDENTIFIER som clusterkey

Jeg havde fornøjelsen af at besøge en kunde, som virkelig har prioriteret at få tuned SQL Serveren og har allokeret ressourcer

Ring til Danmarks Mest Anbefalede Virksomhed 2020