​Vi skal se på de grunnleggende forskjellene mellom et datavarehus og databasene for virksomhetens operasjonelle systemer, for å vise hvorfor datavarehuset må modelleres med helt andre prinsipper enn transaksjonsbaserte systemer. Vi skal se på hva som skiller relasjonsdatabaser fra dimensjonsdatabaser og forklare hvorfor dimensjonsdatabaser er et naturlig valg for BI løsninger.

​Operative systemer og datavarehus har fundamentalt forskjellige formål. Operative systemer støtte gjennomføringen av forretningsprosesser, mens datavarehus støtter evaluering av disse forretningsprosessene. For å kjøre effektivt må operative systemer optimaliseres for online transaksjonsbehandling (OLTP), i motsetning til datavarehus som må optimaliseres for behandling av spørringen og brukervennlighet. Tabellen under oppsummerer disse forskjellene.

​ER-modellering er en standard tilnærming for design av OLAP databaser. Den klassifiserer alle data som en av tre ting; en entitet, en relasjon, eller et attributt. Diagrammet under viser et eksempel hvor entiteter vises som bokser og relasjoner vises som linjer som kobler boksene sammen. Kardinaliteten for hver relasjon - antall mulige kombinasjoner av verdier på hver side av relasjonen - vises som ved hjelp av kråkeføtter for mange, | for en og 0 for null (også kjent som valgfritt).

​Dimensjonale modeller definere forretningsprosesser og deres enkelthendelser i form av målinger (fakta) og beskrivelser (dimensjoner) som kan brukes til å filtrere, gruppere og aggregere målingene. Datakuber blir ofte brukt til å visualisere enkle dimensjonale modeller.

​Dimensjonale modeller i den virkelige verden brukes til å måle langt mer komplekse forretningsprosesser (med flere dimensjoner) og med mange flere detaljer enn det man enkelt vil kunne se for seg kuber med mer enn tre dimensjoner, men de kan lett representeres ved hjelp av stjerneskjema diagrammer. Diagrammet under viser et klassisk stjerneskjema for detaljomsetningen som inneholder en fjerde dimensjon PROMOTION.

​Et stjernediagram består av en sentral fakatabell omgitt av en rekke dimensjonstabeller. Faktatabellen inneholder fakta; de numeriske (kvantitative) målingene av en forretningsprosess. Dimensjonstabeller inneholder hovedsakelig tekstlige (kvalitative) beskrivelser av hendelsen og gir kontekst til faktaene.

Før man setter igang med å modellering og gjennomføring en BI løsning kan det være nyttig å se litt på de grunnleggende målene for datavarehuset.

Behovet for et datavarehus kan plukkes opp ved å gå gjennom korridorene i en hvilken som helst organisasjon og lytter til bedriftens ledere og fagpersoner. Følgende problemstillinger er noe man typisk kan overhøre at det klages over:

• Vi har et fjell av data i dette selskapet, men vi får ikke tilgang til det!
• Vi har behov for å slice & dice data på alle mulige måter!
• Du er nødt til å gjøre det enkelt for forretningsfolk å få direkte tilgang til data'ene!
• Bare vise meg hva som er viktig!
• Jeg blir gal av at to personer presentere de samme forretningsberegningene på et møte men med forskjellige tall!
• Vi vil at folk skal bruke informasjonen for å støtte en mer faktabasert beslutningsprosess!

Basert på vår erfaring er disse bekymringene så universell at de styrer de grunnleggende kravene til datavarehuset. La oss omforme disse sitater til datavarehuskrav.

Tilgjengelighet av informasjon
Innholdet i datavarehuset må være forståelig. Dataene må være intuitivt og åpenbart for forretningsbrukeren og ikke bare for utviklerne. Forståelighet innebærer lesbarhet; innholdet i datavarehuset må ha en meningsfull navngivning. Forretningsbrukere ønsker å splitte opp og kombinere dataene i utallige kombinasjoner i en prosess ofte referert til som "slicing og dicing". Verktøyene som gir tilgang til datavarehuset må være enkele og lette å bruke. De må også returnere søkeresultatene til brukeren med minimal ventetid.

Overenstemt presentasjon av informasjon
Dataene i datavarehuset må være troverdig. Data må nøye settes sammen fra en rekke kilder rundt om i organisasjonen, renses, kvalitetssikres og gjøres tilgjengelig først når informasjonen er klar for bruk. Informasjon fra en forretningsprosess skal samsvare med informasjon fra de andre forretningsprosessene. Hvis to målinger har samme navn så må de bety det samme. Hvis to målinger derimot ikke betyr det samme så må de navngis forskjellig. Overenstemt informasjon betyr informasjon av høy kvalitet. Det betyr at alle dataene er regnskapsført og komplett. Overenstemt innebærer også at felles definisjoner for innholdet i datavarehuset er tilgjengelige for brukerne.

Tilpasningsdyktige i forhold til endringer
Vi kan simpelthen ikke unngå forandring. Brukernes behov, forretningsmessige forhold, data og teknologi er alle underlagt endringer i tiden. Datavarehuset må være utformet slik at den klarer å håndtere disse uunngåelig endringene. Endringer i datavarehuset skal være grasiøse i den forstand at noe som betyr at de ivaretar eksisterende data og ikke får eksisterende applikasjoner til å feile. Eksisterende data og programmer bør ikke måtte endres eller avbrytes når forretningsbrukere stiller nye spørsmål eller nye data legges til datavarehuset. Hvis beskrivelsen av data i datavarehuset blir endret må vi ta hensyn til endringene på riktig måte.

Sikker bastion som beskytter informasjonsaktiva
Organisasjonens informasjonskronjuveler blir lagret i datavarehuset. I det minste vil datavarehuset sannsynlig inneholder informasjon om hva vi selger, til hvem og til hvilken pris. Noe som potensielt er skadelige detaljer i hendene på feil person. Datavarehuset må effektivt kontrollere tilgangen til organisasjonens konfidensielle informasjon.

Et grunnlag for bedre beslutninger
Datavarehuset må ha de riktige dataene for å kunne støtte beslutningsprosesser. Det er bare ett riktig svar fra et datavarehus. Beslutninger gjøres på bakgrunn av bevis presentert av datavarehuset. Disse beslutningene levere den mest presserende verdien knyttet til datavarehuset. Den opprinnelige navnet som forut for datavarehuset er fortsatt den beste beskrivelsen av hva vi utarbeider; et beslutningsstøttesystem.

Forretningsbrukerne må akseptere datavarehuset for at det skal bli vellykket
Det spiller ingen rolle om vi har bygget en elegant løsning med de beste produktene på den beste plattformen. Hvis forretningsbrukerne ikke omfavner datavarehus og fortsatte å bruke det aktivt seks måneder etter opplæring, da feiler vi akseptansetesten. I motsetning til vedereutvikling av et operativt system, hvor forretningsbrukerne ikke har annet valg enn å bruke det nye systemet, er bruk av datavarehuset noen ganger valgfritt. Aksept fra forretningsbrukerne har mer å gjøre med enkelhet enn noe annet.
​
Disse punktene viser at et vellykkede datavarehus krever mye mer av oss enn å være en fantastisk database administrator eller systemutvikler. Med et datavarehus initiativ har vi en fot i vår informasjonsteknologi komfortsone, mens vår andre foten er på ukjente grunn hos forretningsbrukere. Vi må skreve over de to og endre noen av våre utprøvde ferdigheter for å tilpasse oss til de unike kravene til datavarehuset. Åpenbart må vi ta med oss alle våre ferdigheter når vi prøver å oppføre oss som om vi er en hybrid DBA/MBA.

Hele hensikten med en selvbetjening BI løsning er at forretningsbrukere får tilgang til å utforske og analysere bedriftens informasjon uten å være avhengig av IT-avdelingen. Prosjekter som innfører selvbetjent BI sliter imidlertid med å skalere løsninger utviklet for de enkelte avdelingene opp til en felles løsning for hele bedriften. Mange opplever at ulike rapporter ikke stemmer overens grunnet dårlig kvalitet på kildedata og at den behandles ulikt fra avdeling til avdeling. Vi skal her se på hvilken rolle Master Data Management spiller ved innføring av selvbetjening BI.

Selv om selvbetjent BI innføres for å styrke brukerne kan det være vanskelig å overbevise dem om å basere virksomhetskritiske beslutninger på løsningen uten noen form for Master Data Management. Med en gang beslutningstakeren oppdager at salgstallene for en kunde fremdeles tilhører et salgsdistrikt som kunden ikke lenger tilhører vil tillitten til resultatene fra BI løsningen bli svekket. Uten skikkelig administrasjon av dataene så vil bruken av løsningen raskt avta etter hvert som flere brukere opplever inkonsekvente resultater.

Ofte vil ansatte spørre en venn på IT-avdelingen om uttrekk fra produksjonsdatabaser eller analytikere vil opprette en egne datamodell i Access for et gitt forretningsområde. Slike datauttrekk som ikke er underlagt sentral administrasjon vil være som regel være inkonsistente og dårlige kilder for forretningsanalyse.
Vi skal her se på hvorfor du bør vurdere Master Data Management som et viktig element i implementeringen av selvbetjent BI.

Selvstendighet til brukere og fageksperter
En god implementering av Master Data Management oppfordrer til løsrivelse fra avhengigheten til IT-avdelingen for utforskning, analyse og forvaltning av felles data. Ikke bare vil brukere og fageksperter føle seg mer frigjort, men dette vil også gi IT-avdelingen mulighet til å fokusere på andre viktige oppgaver som applikasjonsutvikling, infrastruktur og sikkerhet. Eksperter i de enkelte forretningsområdene vil ta eierskap til dataene ved håndtering av forretningsregler og forretningshierarkier helt uten kjennskap til den underliggende databasestrukturen. Dette kan utføres ved riktig bruk av Excel med Microsoft Master Data Services (MDS) plugin installert. Det er flere nøkler til denne selvstendighet:

• Brukere kan administrere og vedlikeholde data
• Brukere kan definere og håndheve forretningsregler
• Brukere kan optimalisere arbeidsflyt for godkjenning
• Brukere kan iterere trygt gjennom den innebygde versjonskontrollen

Konsolidert og troverdig data
Problemstillinger relatert til dårlig datakvalitet er kostbar og truer organisasjoner som ikke har implementert standardisert praksis for administrasjon av data. En av de grunnleggende årsakene til problemer med troverdighet er mangel på fagkunnskap. Som oftest er det sluttbrukere med fagkompetanse som best vil kunne vurdere troverdigheten til kildedata og definere forretningsreglene som styrer disse dataene og ikke utviklerne på IT-avdelingen.

Håndheving av valideringsregler og arbeidsflyt for godkjenning av data som strømmer inn i Master Data Management system vil sikre nøyaktighet og kvalitetsstandarder for masterdata. For eksempel når du arbeider med kundedata vil felt for by og kommune ofte ikke fylles ut eller bli feilstavet. Ved å opprette en regel som fyller ut disse attributtene basert på postnummeret vil sikre at dataene ikke bare er mer nøyaktig men også at de kan brukes på riktig måte når man kartlegger geografiske data i rapporter. Når reglene er satt i MDS vil alle adressedataene som er trukket inn anta regelen naturlig. Anvende av slike regler vil øke sluttbrukers tillit til at de konsumerer rene, nøyaktige og troverdige data.

Integrasjon av ulike systemer
Det er veldig vanlig at organisasjoner vil ha flere ulike systemer innen områder som kundestøtte, ordrebehandling, lagerstyring og regnskap. Det er en god sjanse for at disse systemene har overlappende data som ofte ikke er lagret på samme måte som igjen kan gjøre det vanskelig å holde dataene synkronisert. For eksempel kan ordrebehandlingssystem lagre valuta i et forkortet format (NOK) mens kundestøttesystemet lagre dem som sitt fulle navn (norske kroner). Uten tilstrekkelig Master Data Management kan forvaltningen av mappingen mellom disse systemene bli en tidskrevende oppgave. Med Master Data Management verktøy som MDS for Excel kan dataene fra de ulike kildesystemer bli konsolidert og forbli i synk slik at de kan brukes av sluttbruker av bedriftens rapporteringssystem.

Positive endringer i forretningsprosesser
Avdelinger i en organisasjon med lite eller ingen Master Data Management vil typisk administrere sine egne data og kan være tilbakeholdne med å gi tilgang direkte til andre forretningsenheter. Denne formen for administrasjon av data vil skape informasjonssiloer som avskrekker samarbeid, informasjonsdeling og datautforskning.

En vellykket strategi for Master Data Management vil bryte ned organisatoriske og avdelingsmessige grensene ved å definere et rammeverk for de prosesser og personer som er involvert. Roller som data administrator vil bli definert og tildelt Tiltak vil også innføres for å håndtere forslag-, kontroll- og godkjenningsprosess for opprettelse av ny eller endring av eksisterende data. Å muliggjøre dette nivået av samarbeidet vil gi grunnlag for en skalerbar BI løsning for bedriften som er i stand til å møte virksomhetens økende behov for analyse og rapportering.

Ralph Kimball er en av de ledende visjonærene innen business intelligence og grunnlegger av dimensjonal modellering av datavarehus. Hans metodikk har blitt en de facto standard innen beslutningsstøtte.

Kimball startet sin karriere hos Xerox Palo Alto Research Center (PARC) som en av de ledende designerne av arbeidsstasjonen Xerox Star, det første kommersielle produkt til å bruke mus, ikoner og vinduer.

Han ble deretter visepresident for applikasjoner hos Metaphor Computer Systems hvor han i 1982 utviklet The Capsule Facility. Dette var en grafisk programmeringsteknikk som lot ikke-programmerere visuelt utvikle applikasjoner for rapportering og analyse ved å koblet ikoner sammen i en logisk flyt.

Kimball stiftet i 1986 Red Brick Systems hvor han fungerte som konsernsjef frem til 1992. Red Brick Systems ble kjøpt opp av Informix som nå eies av IBM. Red Brick ble kjent for sin relasjonsdatabase optimalisert for datavarehus. Med bruk av indeksering klarte de å oppnå en ytelse på nesten 10 ganger mer enn andre konkurrerende databaseleverandører.

Ralph Kimball Associates innlemmet i 1992 for å gi datavarehus rådgivning og utdanning. The Kimball Gruppen formalisert eksisterende langsiktige relasjoner mellom Ralph Kimball Associates, DecisionWorks Consulting, og InfoDynamics LLC.

Kimball er nok mest kjent som en forfatter på temaet datavarehus og business intelligence. Han er ansett som en av de opprinnelige arkitektene datavarehus og er kjent for langsiktig overbevisning at datavarehus må være utformet for å være forståelig og rask. Hans metode, også kjent som tredimensjonal modellering eller Kimball metodikk, har blitt de facto standard i området av beslutningsstøtte.

Han er hovedforfatter av de bestselgende bøkene Datavarehus Toolkit, Datavarehuslifecycle Toolkit, Datavarehus ETL Toolkit og The Kimball Gruppe Reader, utgitt av Wiley and Sons.

Kimbal har etablert en beste praksis innen dimensjonale modelering av et datevarehus som er fritt tilgjengelig her.

​Disse teknikkene er også tilgjengelig som et PDF dokument.

Ralph Kimball og Margy Ross utgir sin tredje utgave av Kimballs klassiske veiledning til dimensjonal modellering. Denne boken inneholder en komplett samling av modelleringsteknikker fra helt grunnleggende konsepter til håndtering av stadig mer komplekse problemstillinger, hele tiden med referanser til eksempler fra den virkelige verden.

Boken gir vesentlig bedre og utvider på begreper og eksempler presentert i tidligere utgaver av Datavarehus verktøykassen:

• Nytt kapittel med den "offisielle " bibliotek av Kimball dimensjonale modelleringsteknikker
• Utvidet dekning av avanserte dimensjonale modellerings mønstre for mer komplekse scenarier fra virkeligheten, inkludert bridgebord for fillete variable dybde hierarkier og flerverdiattributter
• Sample datavarehus buss matriser for 12 case-studier
• Forbedrede langsomt skiftende dimensjon teknikker skriver 0 til 7
• Anbefalingene for store dataanalyse
• Veiledning om samarbeid , interaktive tredimensjonale modellering motiv økter med forretnings interessenter
• Oppdatert oversikt over Kimball DW/BI prosjektets livssyklus metodikk
• Omfattende gjennomgang av ekstrakt , transformasjon , og last (ETL ) systemer og design hensyn , inkludert 34 delsystemer og teknikker for å fylle dimensjonale modeller

Kimbal har etablert en beste praksis innen dimensjonale modelering av et datevarehus som er fritt tilgjengelig her.

​Disse teknikkene er også tilgjengelig som et PDF dokument.

Har du i dag et datavarehus som brukerene ønsker at oppfrisket seg oftere, men ser at ETL prosessen tar for lang tid? Da kan det være lurt å se nærmere på hva du kan oppnå med parallprosessering av dine data.
​
Microsoft har leget en 3 minutters video som på en fin måte beskriver det overordnede konseptet med sin nye paralelle datavarehus løsning. Du finner videoen her.

Microsoft har annonsert Cloud Data Warehousing med slagordet The Fastest Time To Value. Det vil nå være mulig å opprette en ferdig konfigurert SQL Server Enterprise som er optimalisert for å kjøre et datavarehus i skyen på Windows Azure.

Problemet med implementasjon av datavarehus er at dette ofte er lange og kostbare prosjekter. Det kreves store invisteringer i infrastruktur med kraftige servere hvor programvaren er optimalisert for ytelse (CPU, mine og I/O). Dette tar tid og man er langt uti prosjektet før man kan begynne med å laste inn data. Et datavarehus krever også betydelig vedlikeholde for å holde ytelsen på topp når datamengden øker.

Med den nye løsningen til Microsoft vil bedrifter kunne anskaffe seg et optimalisert datavarehus innen minutter uten kunnskap om Azure konfigurasjon eller erfaring på optimalisering av SQL Server for datavarehus. En ideell løsning for kunder som ønsker et datavarehus raskt uten å måtte drifte infrastrukturen selv?

​Les mer om annonseringen her.

Microsoft annonserer roadmap for SQL Server 2014 med In-Memory OLTP teknologi. Dette produktet passer inn i selskapets overordnete strategi om å tilby raskere innsikt i data med BI verktøy og skalerbare skybaserte tjenester.

Den store nyheten her er en betydelig forbedring i ytelse. Fra pilotprosjekter med kunder rapporteres det om 7 til 10 ganger raskere prosessering med in-memory OLTP i SQL Server 2014.

I tillegg til bedre ytelse vil lese og skrive operasjoner nå kunne kjøres simultant uten å låse databasen.

Dette er gode nyheter for bedrifter med datavarehus som i fremtiden slipper å vente timer på tilrettelegging av data for analyse og rapportering. Brukerne vil oppleve nær santidsoppdatering av informasjonen som er så viktig for bedre innsikt og sunne beslutninger.

​Microsoft har publisert et Internals Overview dokument med mer detaljer om den nye teknologien med SQL Server 2014.

Et datavarehus samler inn, kvalitetssikrer og konsoliderer kildedata fra bedriftens ulike operative systemer. Dette gir et helhetlig og pålitelig grunnlag for videre analyse og rapportering, som igjen sikrer god og konsistent informasjon til beslutningstakere.

Datavarehuset er en sentral database som lagrer den overordnete sannheter om rikets tilstand basert på konsolidering av kildedata hentet fra alle de operative datasystemene som bedriften benytter.

Bill Inmon er en amerikansk informatikeren som har fått æren for å oppfinne datavarehuset. På begynnelsen av 1980-tallet skrev han boken “Building the Data Warehouse” hvor han definerte begrepet som følgende:

"A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management's decision making process."

​De fleste bedrifter i dag har et antall forskjellige systemer og applikasjoner som benyttes som verktøy i forskjellige områdene av forretningen. Salg har sitt salgsstøttesystem med kunder, produkter og markedskampanjer. Økonomi har sitt regnskapssystem med budsjett, prognoser, lønn og resultater. Personal har sitt HR-system med ansatte og faktureringsgrad. De enkelte ansatte forholder seg til timeregistreringssystemet, MS Office og ulike produksjonsapplikasjoner. De fleste av disse løsningene vil ha sin egen dedikerte database som lagrer all informasjonen som mates inn. Når man implementerer en buisness intelligens løsning står man da overfor utfordringen når man skal innhente alle disse dataene, samordne informasjonen og konsolidere dette til en felles sannhet. I større prosjekter vil det være hensiktsmessig å opprette et datavarehus som inneholder resultatet av denne prosessen. Da vil alle datamodellene som lages basere seg på en felles datakilde slik at analyser og rapporter blir konsistente.