Tips for en vellykket implementering av LuckyTemplates

Vi fortsetter serien vår om LuckyTemplates prosjektplanlegging og implementering. Denne gangen skal vi diskutere datasettdesign , profilering og moduser . Sjekk ut den første delen av vår prosjektplanleggingsserie som omhandler , og den andre delen som snakker om .

Innholdsfortegnelse

• Datasettdesign for LuckyTemplates-prosjektimplementering
  • 4 trinn til datasettdesign
  • Velg forretningsprosessen.
    • Anti-mønsteret å unngå i LuckyTemplates-implementering
  • Erklær kornet.
  • Identifiser dimensjonene.
  • Definer fakta.
• Databussmatrise for LuckyTemplates-prosjektimplementering
• Dataprofilering for LuckyTemplates-implementering
  • SQL Server-integrasjonstjenester
  • DAX Studio
  • LuckyTemplates Desktop
• Datasettplanlegging for LuckyTemplates-implementering
  • Velge en datasettmodus
  • Noen spørsmål å stille når du velger datasettmoduser
• Konklusjon

Datasettdesign for LuckyTemplates-prosjektimplementering

La oss snakke om datasettdesignprosessen og diskutere datavarehusbussmatrisen , som er et verktøy som har eksistert en stund.

Å designe power BI-datasett ligner på å designe datavarehus. Så både datasett og datavarehus har lignende konsepter som fakta- og dimensjonstabeller, stjerneskjemaer, sakte skiftende dimensjoner, faktatabellgranularitet og lokale informerte nøkler for å bygge relasjoner mellom tabeller.

4 trinn til datasettdesign

Det er fire trinn i datasettdesignprosessen: velg forretningsprosessen , erklær detaljene i faktatabellene dine, identifiser dimensjonene og definer deretter fakta .

Velg forretningsprosessen.

For det første trinnet er hver forretningsprosess representert av en faktatabell med et stjerneskjema for dimensjonene.

Under en oppdagelses- eller kravinnsamlingsprosess er det vanskelig å fokusere på en enkelt forretningsprosess isolert, siden brukere jevnlig analyserer flere forretningsprosesser samtidig.

Anti-mønsteret å unngå i LuckyTemplates-implementering

Det vanlige antimønsteret (som er et svar på et tilbakevendende problem som generelt er ineffektivt og potensielt kontraproduktivt) som du ønsker å unngå i LuckyTemplates-prosjekter, er utviklingen av datasett for spesifikke prosjekter eller team i stedet for for forretningsprosessene .

For eksempel å utvikle et datasett eksklusivt for markedsføringsteamet og et annet datasett for salgsorganisasjonen. Denne tilnærmingen fører naturligvis til bortkastede ressurser fordi de samme salgsdataene søkes og oppdateres to ganger i begge datasettene. Disse vil også forbruke lagringsressurser i LuckyTemplates-tjenesten.

dette er noen av grunnene til at du ønsker å gå gjennom en god prosess for datasettdesign. En isolert tilnærming fører til problemer med administrasjon og versjonskontroll fordi datasettene kan inneholde variasjoner og transformasjoner.

Selv om de analytiske behovene til brukerne eller teamene er prioritet for LuckyTemplates-prosjekter, er det også viktig å planlegge for bærekraftige løsninger som til slutt kan deles på tvers av team.

Erklær kornet.

Faktatabellene dekker til syvende og sist detaljnivået som er tilgjengelig for analytiske spørringer, så vel som mengden data som er tilgjengelig.

Så høyere korn betyr flere detaljer mens lavere korn betyr mindre detaljer. Et eksempel på dette er når du ønsker å få salgsordrelinjenivået, eller hvis du vil at prosjektet kun skal inneholde oppsummeringsnivået for hver salgsordre og ikke komme ned til de spesifikke produktene som ble bestilt som en del av det salget.

Noen ganger kan dette kornet variere avhengig av tidsrammen din. Jeg har kommet over en rekke kunder som ønsker svært finmaskede faktatabeller for inneværende kvartal, men for tidligere kvartaler trengte de bare å vite hva det totale salget for kvartalet var.

I løpet av dette trinnet vil du finne ut hva hver rad av de forskjellige forretningsprosessene representerer . For eksempel representerer hver rad i salgsfaktatabellen fra vårt datavarehus linjen i en salgsordre fra en kunde.

Omvendt vil radene i en salgs- og marginplan bli aggregert i en kalendermåned, produktunderkategori og salgsområderegion. så i dette tilfellet har du to forskjellige faktatabeller og to forskjellige korn. hvis du vil sammenligne de to, vil det være noe datamodelleringsarbeid involvert.

Identifiser dimensjonene.

Dimensjoner er bare det naturlige biproduktet av kornet som ble valgt i forrige designtrinn.

Så en enkelt prøverad fra faktatabellen bør tydelig indikere det som er knyttet til den gitte prosessen, for eksempel kunden som kjøpte et individuelt prosjekt, produktet på en bestemt dato og på et bestemt tidspunkt. Faktatabeller som representerer lavere korn har færre dimensjoner.

For eksempel kan en faktatabell som representerer overskriftsnivået til en innkjøpsordre identifisere leverandøren, men ikke det individuelle produktkjøpet fra leverandøren. så i så fall trenger du ikke en produktkategori eller en produktunderkategoridimensjon inkludert.

Definer fakta.

Fakta representerer de numeriske kolonnene som er inkludert i faktatabellene. Så mens dimensjonskolonnene fra trinn 3 brukes for relasjoner, brukes faktakolonnene i mål som inneholder aggregeringslogikk, for eksempel summen av en mengdekolonne eller gjennomsnittet av en priskolonne.

Databussmatrise for LuckyTemplates-prosjektimplementering

Datavarehusbussmatrisen er en stift i Ralph Kimballs datavarehusarkitektur, som gir en inkrementell og integrert tilnærming til datavarehusdesign.

Arkitekturen du ser her er fra The Data Warehouse Toolkit , 3. utgave av Ralph Kimball. Det gir mulighet for skalerbare datamodeller som flere forretningsteam eller funksjoner ofte krever for å få tilgang til de samme forretningsprosessene og dimensjonene.

Det er nyttig å ha en bussmatrise for datavarehus. når du fyller det ut, vil du vite om det er andre datasett som inneholder lignende internettfaktatabeller og dimensjonstabeller. dette fremmer gjenbrukbarheten til prosjektet og forbedrer prosjektkommunikasjonen.

Så hver rad gjenspeiler en viktig og tilbakevendende forretningsprosess som den månedlige avslutningen av hovedboken. hver kolonne representerer en forretningsenhet, som kan relateres til én eller flere av forretningsprosessene, mens de skyggelagte radene representerer forretningsprosessen som inkluderes i prosjektet.

Dataprofilering for LuckyTemplates-implementering

når du har identifisert kornet og fire-trinns datasettdesignprosessen er fullført, bør den umiddelbart etterfølges av en teknisk analyse av kildedataene til fakta- og dimensjonstabellene .

Tekniske metadata, inkludert databasediagrammer og dataprofileringsresultater, er avgjørende for prosjektplanleggingsstadiet.

Denne informasjonen brukes for å sikre at power BI-datasettet gjenspeiler de tiltenkte forretningsdefinisjonene og er bygget på en solid og pålitelig kilde.

Så tre er tre forskjellige måter å samle den profileringsinformasjonen på, som bør være det aller første trinnet folk vil gjøre når de kommer ut av designprosessen.

SQL Server-integrasjonstjenester

Det er et par måter å gå om dette på. En metode er å bruke en dataprofileringsoppgave i en SQL Server Integration Services (SSIS)-pakke.

Dataprofileringsoppgaven krever en ADO.NET-tilkobling og kan skrive utdataene til en XML-fil eller en SSIS-variabel.

I dette eksemplet er ADO.NET-kildedataene et AdventureWorks-datavarehus, database og SQL-server, og målet er en XML-fil.

Så når oppgaven er utført, kan XML-filen leses via en SQL-serverdataprofilviser. Du kan se resultatene i form av nullantall og nulltellingsprosent.

DAX Studio

En annen måte for dataprofilering er via DAX Studio. du må faktisk innta dataene i et LuckyTemplates-datasett ved å gå til DAX Studio, gå til avansert-fanen og kjøre .

Den vil vise deg den samme typen informasjon rundt kardinaliteten til kolonnene dine, slik at du vet hvilke som tar mest plass i datamodellen din. den inkluderer alle de ulike statistikkene rundt dataene.

LuckyTemplates Desktop

dataprofilering er også tilgjengelig i power-query i LuckyTemplates skrivebord. hvis du går til Vis-fanen , kan du slå på ting som kolonnekvalitet, kolonnefordeling og kolonneprofil. For minst de første tusen radene eller så kan du se informasjonen som feil, nullverdier, gjennomsnitt og standardavvik.

Datasettplanlegging for LuckyTemplates-implementering

Etter at kildedataene er profilert og evaluert mot kravene identifisert i fire-trinns datasettdesignprosessen, kan BI-teamet analysere implementeringsalternativene for datasettet videre.

I nesten alle power BI-prosjekter, selv de med betydelige investeringer i bedriftsdata, lager, arkitektur og ETL-verktøy og prosesser, er det nødvendig med et visst nivå av ekstra logikk, integrasjon eller transformasjon for å forbedre kvaliteten og verdien av kildedataene.

Datasettplanleggingsstadiet bestemmer hvordan de identifiserte datatransformasjonsproblemene håndteres for å støtte datasettet. I tillegg må prosjektteamet bestemme om det skal utvikles et importmodusdatasett , et direkte spørringsdatasett eller et sammensatt datasett .

For å tydeliggjøre datasettplanleggingsprosessen identifiserer dette diagrammet de forskjellige lagene i datavarehuset og LuckyTemplates-datasettet der transformasjon og forretningslogikk kan implementeres.

i noen prosjekter er minimal transformasjon nødvendig, og den kan enkelt inkluderes i power BI-datasettet. For eksempel, hvis bare noen få ekstra kolonner er nødvendig for en dimensjonstabell og det er enkel veiledning om hvordan disse kolonnene skal beregnes, kan IT-organisasjonen velge å implementere disse transformasjonene innenfor M strømforespørsler i stedet for å revidere datavarehuset.

Hvis det betydelige gapet mellom BI-behovene og bedriftens datavarehus tillates å vedvare, blir LuckyTemplates-datasettene mer komplekse å bygge og vedlikeholde.

Datasettdesignere bør jevnlig analysere og kommunisere implikasjonene av datasett hvis det er større nivåer av kompleksitet.

Men hvis den nødvendige transformasjonslogikken er kompleks eller omfattende med flere felles operasjoner, radfiltre og datatypeendringer, kan IT-organisasjonen velge å implementere vesentlige endringer i datavarehuset for å støtte det nye datasettet og fremtidige BI-prosjekter.

For eksempel kan det være nødvendig med en oppsamlingstabell og en SQL-lagerprosedyre for å støtte, revidere og oppdatere prosessen, eller det kan være nødvendig å opprette en indeks for å forbedre spørringsytelsen for DirectQuery-datasett.

Velge en datasettmodus

Et påfølgende, men nært beslektet trinn til datasettplanlegging, er å velge mellom standard importmodus, DirectQuery/live-modus eller sammensatt modus.

I noen prosjekter er dette en enkel beslutning hvor kun ett alternativ er gjennomførbart eller realistisk gitt de kjente kravene, mens andre prosjekter vil innebære betydelig analyse av fordeler og ulemper ved hvert design.

Så hvis en datakilde anses som treg eller dårlig utstyrt til å håndtere et stort volum av analytiske søk, er et datasett i importmodus høyst sannsynlig det foretrukne alternativet.

På samme måte, hvis synlighet i nær sanntid av en datakilde er viktig, er DirectQuery eller live-modus det eneste alternativet for å oppnå det. DirectQuery- og live-modusene ligner veldig på hverandre. Begge metodene lagrer ikke data i selve datasettet, og begge spør kildesystemene direkte for å hente data basert på brukerhandling. Vi har nå DirectQuery for LuckyTemplates-datasett og DirectQuery for Analysis Services.

Noen spørsmål å stille når du velger datasettmoduser

Her er noen spørsmål du bør stille når du bestemmer deg for hvilken modus du skal bruke. er det én enkelt kilde for datasettet vårt? Hvis det ikke er en enkelt kilde, kunne du ikke bruke DirectQuery/Live-kilde tidligere.

Selv om vi nå har komposittmodusdatasett, er det fortsatt et godt spørsmål å stille i begynnelsen, for hvis det ikke er en enkelt kilde, vil den enten være import eller sammensatt.

Hvis DirectQuery/Live-kilde er et alternativ, er kilden i stand til å støtte analytiske søk? Hvis du jobber med milliarder eller billioner av rader, kan det hende at et datasett for importmodus ikke er mulig, og du må gå ned i DirectQuery eller sammensatt modus for å sikre at datasettet er brukbart.

Hvis DirectQuery/Live-kilden er i stand til å støtte arbeidsbelastningen, er DirectQuery/Live-tilkoblingen mer verdifull enn ytelsen og fleksibiliteten som tilbys av en importmodell?

Konklusjon

Dette innlegget avslutter denne serien om planlegging av LuckyTemplates-prosjekter. disse, tror jeg, er de essensielle trinnene for alle power BI-prosjekter du jobber med. Disse trinnene er viktige når du utfører due diligence, spesielt i en bedrifts-business intelligence-setting.

Beste ønsker,

Greg Deckler