Tips til en vellykket implementering af LuckyTemplates

Vi fortsætter vores serie om LuckyTemplates projektplanlægning og implementering. Denne gang vil vi diskutere datasætdesign , profilering og tilstande . Se den første del af vores projektplanlægningsserie, der omhandler , og den anden del, som handler om .

Indholdsfortegnelse

• Datasætdesign til LuckyTemplates-projektimplementering
  • 4 trin til datasætdesign
  • Vælg forretningsproces.
    • Anti-mønsteret, der skal undgås i LuckyTemplates-implementering
  • Erklære kornet.
  • Identificer dimensionerne.
  • Definer fakta.
• Databusmatrix til LuckyTemplates-projektimplementering
• Dataprofilering til LuckyTemplates-implementering
  • SQL Server Integration Services
  • DAX Studio
  • LuckyTemplates Desktop
• Datasætplanlægning til LuckyTemplates-implementering
  • Valg af en datasættilstand
  • Nogle spørgsmål at stille, når du vælger datasættilstande
• Konklusion

Datasætdesign til LuckyTemplates-projektimplementering

Lad os tale om datasætdesignprocessen og diskutere datavarehusbusmatrixen , som er et værktøj, der har eksisteret i et stykke tid.

Design af power BI-datasæt svarer til at designe datavarehuse. Så både datasæt og datavarehuse har lignende koncepter såsom fakta- og dimensionstabeller, stjerneskemaer, langsomt skiftende dimensioner, faktatabelgranularitet og lokale informerede nøgler til opbygning af relationer mellem tabeller.

4 trin til datasætdesign

Der er fire trin til datasætdesignprocessen: vælg forretningsprocessen , erklær kernen i dine faktatabeller, identificer dimensionerne og definer derefter fakta .

Vælg forretningsproces.

For det første trin er hver forretningsproces repræsenteret af en faktatabel med et stjerneskema for dimensionerne.

Under en opdagelses- eller kravindsamlingsproces er det vanskeligt at fokusere på en enkelt forretningsproces isoleret, da brugere regelmæssigt analyserer flere forretningsprocesser samtidigt.

Anti-mønsteret, der skal undgås i LuckyTemplates-implementering

Det almindelige antimønster (som er et svar på et tilbagevendende problem, der generelt er ineffektivt og potentielt kontraproduktivt), som du ønsker at undgå i LuckyTemplates-projekter, er udviklingen af ​​datasæt til specifikke projekter eller teams snarere end til forretningsprocesserne .

For eksempel udvikling af et datasæt udelukkende til marketingteamet og et andet datasæt til salgsorganisationen. Denne tilgang fører naturligvis til spildte ressourcer, fordi de samme salgsdata forespørges og opdateres to gange i begge datasæt. Disse vil også forbruge lagerressourcer i LuckyTemplates-tjenesten.

dette er nogle af grundene til, at du ønsker at gennemgå en god proces for datasætdesign. En isoleret tilgang fører til problemer med administration og versionskontrol, fordi datasættene kan indeholde variationer og transformationer.

Selvom brugernes eller teams analytiske behov er prioriteret i LuckyTemplates-projekter, er det også vigtigt at planlægge bæredygtige løsninger, der i sidste ende kan deles på tværs af teams.

Erklære kornet.

Faktatabellerne dækker i sidste ende det detaljeringsniveau, der er tilgængeligt for analytiske forespørgsler, såvel som mængden af ​​data, der kan tilgås.

Så højere korn betyder flere detaljer, mens lavere korn betyder færre detaljer. Et eksempel på dette er, når du ønsker at få salgsordrelinjeniveauet, eller hvis du ønsker, at projektet kun skal indeholde oversigtsniveauet for hver salgsordre og ikke komme ned til de specifikke produkter, der blev bestilt som en del af det pågældende salg.

Nogle gange kan dette korn variere afhængigt af din tidsramme. Jeg er stødt på en række kunder, der gerne vil have meget finmaskede faktatabeller for indeværende kvartal, men for tidligere kvartaler skulle de bare vide, hvad det samlede salg for kvartalet var.

I løbet af dette trin vil du bestemme, hvad hver række af de forskellige forretningsprocesser repræsenterer . For eksempel repræsenterer hver række i salgsfaktatabellen fra vores datavarehus linjen i en salgsordre fra en kunde.

Omvendt vil rækkerne i en salgs- og marginplan blive aggregeret i en kalendermåned, produktunderkategori og salgsområderegion. så i dette tilfælde har du to forskellige faktatabeller og to forskellige korn. hvis du vil sammenligne de to, vil der være noget datamodelleringsarbejde involveret.

Identificer dimensionerne.

Dimensioner er blot det naturlige biprodukt af kornet valgt i det foregående designtrin.

Så en enkelt prøverække fra faktatabellen bør tydeligt angive det, der er forbundet med den givne proces, såsom kunden, der har købt et individuelt projekt, produktet på en bestemt dato og på et bestemt tidspunkt. Faktatabeller, der repræsenterer lavere korn, har færre dimensioner.

For eksempel kan en faktatabel, der repræsenterer overskriftsniveauet for en indkøbsordre, identificere leverandøren, men ikke det individuelle produktkøb fra leverandøren. så i så fald behøver du ikke inkludere en produktkategori eller en produktunderkategoridimension.

Definer fakta.

Fakta repræsenterer de numeriske kolonner, der er inkluderet i faktatabellerne. Så mens dimensionskolonnerne fra trin 3 bruges til relationer, bruges faktakolonnerne i mål, der indeholder aggregeringslogik, såsom summen af ​​en mængdekolonne eller gennemsnittet af en priskolonne.

Databusmatrix til LuckyTemplates-projektimplementering

Datavarehusbusmatrixen er en fast bestanddel af Ralph Kimballs datavarehusarkitektur, som giver en trinvis og integreret tilgang til datavarehusdesign.

Arkitekturen, som du ser her, er fra The Data Warehouse Toolkit , 3. udgave af Ralph Kimball. Det giver mulighed for skalerbare datamodeller, som flere forretningsteams eller -funktioner ofte kræver for at få adgang til de samme forretningsprocesser og -dimensioner.

Det er nyttigt at holde en datavarehusbusmatrix omkring. når du udfylder det, vil du vide, om der er andre datasæt, der indeholder lignende internetfaktatabeller og dimensionstabeller. dette fremmer genanvendeligheden af ​​projektet og forbedrer projektkommunikationen.

Så hver række afspejler en vigtig og tilbagevendende forretningsproces, såsom den månedlige lukning af hovedbogen. hver kolonne repræsenterer en forretningsenhed, som kan relatere til en eller flere af forretningsprocesserne, mens de skraverede rækker repræsenterer den forretningsproces, der indgår i projektet.

Dataprofilering til LuckyTemplates-implementering

når du har identificeret kornet, og fire-trins datasætdesignprocessen er afsluttet, bør den straks efterfølges af en teknisk analyse af kildedataene for fakta- og dimensionstabellerne .

Tekniske metadata, herunder databasediagrammer og dataprofileringsresultater, er afgørende for projektplanlægningsfasen.

Disse oplysninger bruges til at sikre, at power BI-datasættet afspejler de tilsigtede forretningsdefinitioner og er bygget på en sund og pålidelig kilde.

Så tre er tre forskellige måder at indsamle den profileringsinformation på, hvilket burde være det allerførste skridt, som folk vil gøre, når de kommer ud af designprocessen.

SQL Server Integration Services

Der er et par måder at gøre dette på. En metode er at bruge en dataprofileringsopgave i en SQL Server Integration Services (SSIS)-pakke.

Dataprofileringsopgaven kræver en ADO.NET-forbindelse og kan skrive dens output til en XML-fil eller en SSIS-variabel.

I dette eksempel er ADO.NET-kildedataene et AdventureWorks-datavarehus, -database og SQL-server, og destinationen er en XML-fil.

Så når opgaven er udført, kan XML-filen læses via en SQL-serverdataprofilfremviser. Du kan se resultaterne i form af null count og null count procenter.

DAX Studio

En anden måde til dataprofilering er via DAX Studio. du skal faktisk indtage dataene i et LuckyTemplates-datasæt ved at gå til DAX Studio, gå til fanen avanceret og køre .

Det vil vise dig den samme slags information omkring kardinaliteten af ​​dine kolonner, så du ved, hvilke der optager mest plads i din datamodel. det inkluderer alle de forskellige statistikker omkring dataene.

LuckyTemplates Desktop

dataprofilering er også tilgængelig i power-forespørgsler på LuckyTemplates desktop. hvis du går til fanen Vis , kan du aktivere ting som kolonnekvalitet, kolonnefordeling og kolonneprofil. For mindst de første tusinde rækker eller deromkring kan du se oplysninger såsom fejl, nuller, gennemsnit og standardafvigelser.

Datasætplanlægning til LuckyTemplates-implementering

Efter at kildedataene er profileret og evalueret i forhold til kravene identificeret i fire-trins datasætdesignprocessen, kan BI-teamet yderligere analysere implementeringsmulighederne for datasættet.

I næsten alle power BI-projekter, selv dem med betydelige investeringer i virksomhedsdata, lager, arkitektur og ETL-værktøjer og -processer, er der behov for et vist niveau af yderligere logik, integration eller transformation for at forbedre kvaliteten og værdien af ​​kildedataene.

Datasætplanlægningsstadiet bestemmer, hvordan de identificerede datatransformationsproblemer løses for at understøtte datasættet. Derudover skal projektteamet afgøre, om der skal udvikles et datasæt i importtilstand , et direkte forespørgselsdatasæt eller et sammensat datasæt .

For at tydeliggøre datasætplanlægningsprocessen identificerer dette diagram de forskellige lag i datavarehuset og LuckyTemplates-datasættet, hvor transformation og forretningslogik kan implementeres.

i nogle projekter er minimal transformation nødvendig, og den kan nemt indgå i power BI-datasættet. For eksempel, hvis der kun er brug for et par ekstra kolonner til en dimensionstabel, og der er ligetil vejledning om, hvordan disse kolonner vil blive beregnet, kan it-organisationen vælge at implementere disse transformationer inden for M strømforespørgsler i stedet for at revidere datavarehuset.

Hvis den væsentlige kløft mellem BI-behovene og virksomhedens datavarehus får lov til at fortsætte, bliver LuckyTemplates-datasættene mere komplekse at bygge og vedligeholde.

Datasætdesignere bør regelmæssigt analysere og kommunikere implikationerne af datasæt, hvis der er større niveauer af kompleksitet.

Men hvis den nødvendige transformationslogik er kompleks eller omfattende med flere fælles operationer, rækkefiltre og datatypeændringer, kan it-organisationen vælge at implementere væsentlige ændringer i datavarehuset for at understøtte det nye datasæt og fremtidige BI-projekter.

For eksempel kan der være behov for en iscenesættelsestabel og en SQL-lagerprocedure for at understøtte, revidere og opdatere processen, eller det kan være nødvendigt at oprette et indeks for at forbedre forespørgselsydeevnen for DirectQuery-datasæt.

Valg af en datasættilstand

Et efterfølgende, men tæt beslægtet trin til datasætplanlægning, er at vælge mellem standardimporttilstand, DirectQuery/livetilstand eller sammensat tilstand.

I nogle projekter er dette en simpel beslutning, hvor kun én mulighed er gennemførlig eller realistisk givet de kendte krav, mens andre projekter vil medføre betydelige analyser af fordele og ulemper ved hvert design.

Så hvis en datakilde anses for langsom eller dårligt rustet til at håndtere en stor mængde analytiske forespørgsler, så er et importtilstandsdatasæt meget sandsynligt den foretrukne mulighed.

Ligeledes, hvis nær-realtidssynlighed af en datakilde er afgørende, så er DirectQuery eller live-tilstand den eneste mulighed for at opnå det. DirectQuery og live-tilstandene minder meget om hinanden. Begge metoder gemmer ikke data i selve datasættet, og begge forespørger kildesystemerne direkte for at hente data baseret på brugerhandling. Vi har nu DirectQuery til LuckyTemplates-datasæt og DirectQuery til Analysis Services.

Nogle spørgsmål at stille, når du vælger datasættilstande

Her er nogle spørgsmål, du skal stille, når du beslutter dig for, hvilken tilstand der skal bruges. er der en enkelt kilde til vores datasæt? Hvis der ikke er en enkelt kilde, så kunne du ikke bruge DirectQuery/Live-kilde tidligere.

Selvom vi nu har sammensatte tilstandsdatasæt, er det stadig et godt spørgsmål at stille i starten, for hvis der ikke er en enkelt kilde, så vil den enten være importeret eller sammensat.

Hvis DirectQuery/Live source er en mulighed, er kilden så i stand til at understøtte analytiske forespørgsler? Hvis du arbejder med milliarder eller billioner af rækker, er et datasæt i importtilstand måske ikke muligt, og du bliver nødt til at gå ned i DirectQuery eller sammensat tilstand for at sikre, at datasættet er brugbart.

Hvis DirectQuery/Live-kilden er i stand til at understøtte arbejdsbyrden, er DirectQuery/Live-forbindelsen så mere værdifuld end ydeevnen og fleksibiliteten fra en importmodel?

Konklusion

Dette indlæg afslutter denne serie om planlægning af LuckyTemplates-projekter. disse, tror jeg, er de væsentlige trin for alle power BI-projekter, du arbejder på. Disse trin er vigtige, når du udfører due diligence, især i en virksomheds business intelligence-indstilling.

Alt det bedste,

Greg Deckler