Tips för en framgångsrik implementering av LuckyTemplates

Vi kommer att fortsätta vår serie om LuckyTemplates projektplanering och implementering. Den här gången kommer vi att diskutera datauppsättningsdesign , profilering och lägen . Kolla in den första delen av vår projektplaneringsserie som handlar om , och den andra delen som handlar om .

Innehållsförteckning

• Datasetdesign för projektimplementering av LuckyTemplates
  • 4 steg till datauppsättningsdesign
  • Välj affärsprocess.
    • Anti-mönstret att undvika i LuckyTemplates-implementering
  • Deklarera säden.
  • Identifiera måtten.
  • Definiera fakta.
• Databussmatris för projektimplementering av LuckyTemplates
• Dataprofilering för LuckyTemplates-implementering
  • SQL Server Integration Services
  • DAX Studio
  • LuckyTemplates Desktop
• Datauppsättningsplanering för LuckyTemplates-implementering
  • Att välja ett datauppsättningsläge
  • Några frågor att ställa när du väljer datauppsättningslägen
• Slutsats

Datasetdesign för projektimplementering av LuckyTemplates

Låt oss prata om datauppsättningsdesignprocessen och diskutera datalagerbussmatrisen , som är ett verktyg som har funnits ett tag.

Att designa power BI-datauppsättningar liknar att designa datalager. Så både datauppsättningar och datalager har liknande koncept som fakta- och dimensionstabeller, stjärnscheman, långsamt föränderliga dimensioner, faktatabellgranularitet och lokalt informerade nycklar för att bygga relationer mellan tabeller.

4 steg till datauppsättningsdesign

Det finns fyra steg i datauppsättningsprocessen: välj affärsprocess , deklarera detaljerna i dina faktatabeller, identifiera dimensionerna och definiera sedan fakta .

Välj affärsprocess.

För det första steget representeras varje affärsprocess av en faktatabell med ett stjärnschema för dimensionerna.

Under en upptäckts- eller kravinsamlingsprocess är det svårt att fokusera på en enda affärsprocess isolerat, eftersom användare regelbundet analyserar flera affärsprocesser samtidigt.

Anti-mönstret att undvika i LuckyTemplates-implementering

Det vanliga antimönster (som är ett svar på ett återkommande problem som generellt är ineffektivt och potentiellt kontraproduktivt) som du vill undvika i LuckyTemplates-projekt är utvecklingen av datauppsättningar för specifika projekt eller team snarare än för affärsprocesserna .

Till exempel utveckla en datauppsättning exklusivt för marknadsföringsteamet och en annan datauppsättning för säljorganisationen. Detta tillvägagångssätt leder naturligtvis till slöseri med resurser eftersom samma försäljningsdata efterfrågas och uppdateras två gånger i båda datamängderna. Dessa kommer också att förbruka lagringsresurser i tjänsten LuckyTemplates.

det här är några av anledningarna till att du vill gå igenom en bra process för datauppsättningsdesign. Ett isolerat tillvägagångssätt leder till hanterbarhet och versionskontrollproblem eftersom datamängderna kan innehålla variationer och transformationer.

Även om användarnas eller teams analytiska behov är prioritet för LuckyTemplates-projekt, är det också viktigt att planera för hållbara lösningar som i slutändan kan delas mellan team.

Deklarera säden.

Faktatabellerna täcker i slutändan detaljnivån som är tillgänglig för analytiska frågor, såväl som mängden data som kan nås.

Så högre ådring betyder mer detaljer medan lägre ådring betyder mindre detaljer. Ett exempel på detta är när du vill få säljorderradsnivån, eller om du vill att projektet endast ska innehålla sammanfattningsnivån för varje säljorder och inte komma ner till de specifika produkterna som beställdes som en del av den försäljningen.

Ibland kan detta spannmål variera beroende på din tidsram. Jag har stött på ett antal kunder som vill ha mycket finkorniga faktatabeller för innevarande kvartal, men för tidigare kvartal behövde de bara veta vad den totala försäljningen för kvartalet var.

Under det här steget vill du bestämma vad varje rad av de olika affärsprocesserna representerar . Till exempel representerar varje rad i försäljningsfaktatabellen från vårt datalager raden för en försäljningsorder från en kund.

Omvänt kommer raderna i en försäljnings- och marginalplan att aggregeras i en kalendermånad, produktunderkategori och försäljningsområdesregion. så i det här fallet har du två olika faktatabeller och två olika korn. om du vill jämföra de två kommer det att finnas en del datamodelleringsarbete inblandat.

Identifiera måtten.

Dimensioner är bara den naturliga biprodukten av spannmålet som valdes i det föregående designsteget.

Så en enstaka exempelrad från faktatabellen bör tydligt ange det som är associerat med den givna processen, till exempel kunden som köpte ett enskilt projekt, produkten vid ett visst datum och vid en viss tid. Faktatabeller som representerar lägre korn har färre dimensioner.

Till exempel kan en faktatabell som representerar rubriknivån för en inköpsorder identifiera leverantören, men inte det enskilda produktköpet från leverantören. så i så fall skulle du inte behöva en produktkategori eller en produktunderkategoridimension inkluderad.

Definiera fakta.

Fakta representerar de numeriska kolumner som ingår i faktatabellerna. Så medan dimensionskolumnerna från steg 3 används för relationer, används faktakolumnerna i mått som innehåller aggregeringslogik, såsom summan av en kvantitetskolumn eller medelvärdet av en priskolumn.

Databussmatris för projektimplementering av LuckyTemplates

Datalagerbussmatrisen är en bas i Ralph Kimballs datalagerarkitektur, som ger en inkrementell och integrerad metod för design av datalager.

Arkitekturen som du ser här är från The Data Warehouse Toolkit , 3:e upplagan av Ralph Kimball. Det möjliggör skalbara datamodeller som flera affärsteam eller funktioner ofta kräver för att komma åt samma affärsprocesser och dimensioner.

Det är användbart att ha en bussmatris för datalager. när du fyller i det vet du om det finns andra datauppsättningar som innehåller liknande faktatabeller och dimensionstabeller på internet. detta främjar återanvändbarheten av projektet och förbättrar projektkommunikationen.

Så varje rad återspeglar en viktig och återkommande affärsprocess, såsom den månatliga avslutningen av huvudboken. varje kolumn representerar en affärsenhet, som kan relatera till en eller flera av affärsprocesserna, medan de skuggade raderna representerar den affärsprocess som ingår i projektet.

Dataprofilering för LuckyTemplates-implementering

när du har identifierat kornet och designprocessen i fyra steg har slutförts, bör den omedelbart följas av en teknisk analys av källdata för fakta- och dimensionstabellerna .

Teknisk metadata, inklusive databasdiagram och dataprofileringsresultat, är väsentliga för projektplaneringsstadiet.

Denna information används för att säkerställa att power BI-datauppsättningen återspeglar de avsedda affärsdefinitionerna och bygger på en sund och pålitlig källa.

Så tre är tre olika sätt att samla in den profileringsinformationen, vilket borde vara det allra första steget som människor kommer att göra när de kommer ut ur designprocessen.

SQL Server Integration Services

Det finns ett par sätt att gå tillväga. En metod är att använda en dataprofileringsuppgift inom ett SQL Server Integration Services ( SSIS)-paket.

Dataprofileringsuppgiften kräver en ADO.NET-anslutningar och kan skriva dess utdata till en XML-fil eller en SSIS-variabel.

I det här exemplet är ADO.NET-källdata ett AdventureWorks datalager, databas och SQL-server, och destinationen är en XML-fil.

Så när uppgiften är utförd kan XML-filen läsas via en SQL-serverdataprofilvisare. Du kan se resultaten i termer av null count och null count procent.

DAX Studio

Ett annat sätt att profilera data är via DAX Studio. du måste faktiskt mata in data i en LuckyTemplates-datauppsättning genom att gå till DAX Studio, gå till den avancerade fliken och köra .

Det kommer att visa dig samma typ av information kring kardinaliteten av dina kolumner så att du vet vilka som tar upp mest plats i din datamodell. den innehåller all olika statistik kring datan.

LuckyTemplates Desktop

dataprofilering är också tillgänglig i power query på LuckyTemplates skrivbord. om du går till fliken Visa kan du aktivera saker som kolumnkvalitet, kolumnfördelning och kolumnprofil. För åtminstone de första tusen raderna eller så kan du se information som fel, nollor, medelvärden och standardavvikelser.

Datauppsättningsplanering för LuckyTemplates-implementering

Efter att källdata har profilerats och utvärderats mot de krav som identifierats i den fyra-stegs datauppsättningsdesignprocessen, kan BI-teamet ytterligare analysera implementeringsalternativen för datamängden.

I nästan alla power BI-projekt, även de med betydande investeringar i företagsdata, lager, arkitektur och ETL-verktyg och -processer, behövs en viss nivå av ytterligare logik, integration eller transformation för att förbättra kvaliteten och värdet på källdata.

Datauppsättningsplaneringsstadiet avgör hur de identifierade datatransformationsproblemen åtgärdas för att stödja datamängden. Dessutom måste projektgruppen bestämma om det ska utvecklas en datauppsättning för importläge , en datauppsättning för direkta frågor eller en sammansatt datauppsättning .

För att förtydliga datauppsättningsplaneringsprocessen identifierar detta diagram de olika lagren i datalagret och LuckyTemplates datauppsättning där transformation och affärslogik kan implementeras.

i vissa projekt behövs minimal transformation och den kan enkelt inkluderas i power BI-dataset. Till exempel, om bara några ytterligare kolumner behövs för en dimensionstabell och det finns enkel vägledning om hur dessa kolumner kommer att beräknas, kan IT-organisationen välja att implementera dessa transformationer inom M power-frågor istället för att revidera datalagret.

Om det betydande gapet mellan BI-behoven och företagets datalager tillåts bestå, blir LuckyTemplates-datauppsättningarna mer komplexa att bygga och underhålla.

Dataset designers bör regelbundet analysera och kommunicera konsekvenserna av datamängder om det finns högre nivåer av komplexitet.

Men om den nödvändiga transformationslogiken är komplex eller omfattande med flera gemensamma operationer, radfilter och datatypändringar, kan IT-organisationen välja att implementera väsentliga förändringar i datalagret för att stödja den nya datamängden och framtida BI-projekt.

Till exempel kan en iscensättningstabell och en SQL-lagringsprocedur behövas för att stödja, revidera och uppdatera processer, eller så kan skapandet av ett index behövas för att förbättra frågeprestanda för DirectQuery-datauppsättningar.

Att välja ett datauppsättningsläge

Ett efterföljande men närbesläktat steg för datauppsättningsplanering är att välja mellan standardimportläge, DirectQuery/liveläge eller sammansatt läge.

I vissa projekt är detta ett enkelt beslut där endast ett alternativ är genomförbart eller realistiskt givet de kända kraven, medan andra projekt kommer att innebära betydande analys av för- och nackdelar med varje design.

Så om en datakälla anses vara långsam eller dåligt utrustad för att hantera en stor mängd analytiska frågor, är en datauppsättning av importläge mycket troligt det föredragna alternativet.

På samma sätt, om synlighet i nära realtid av en datakälla är väsentlig, är DirectQuery eller live-läge det enda alternativet för att uppnå det. DirectQuery och live-lägena är mycket lika varandra. Båda metoderna lagrar inte data i själva datasetet, och båda frågar källsystemen direkt för att hämta data baserat på användaråtgärder. Vi har nu DirectQuery för LuckyTemplates-datauppsättningar och DirectQuery för analystjänster.

Några frågor att ställa när du väljer datauppsättningslägen

Här är några frågor att ställa när du bestämmer vilket läge du ska använda. finns det en enda källa för vår datauppsättning? Om det inte finns en enda källa, kunde du inte använda DirectQuery/Live-källa tidigare.

Även om vi nu har sammansatta lägesdatauppsättningar, är det fortfarande en bra fråga att ställa till en början, för om det inte finns någon enskild källa kommer den antingen att vara importerad eller sammansatt.

Om DirectQuery/Live-källa är ett alternativ, kan källan stödja analytiska frågor? Om du arbetar med miljarder eller biljoner rader, kanske en datauppsättning för importläge inte är genomförbar och du måste gå ner i DirectQuery- eller sammansatt läge för att se till att datamängden är användbar.

Om DirectQuery/Live-källan kan stödja arbetsbelastningen, är DirectQuery/Live-anslutningen mer värdefull än den prestanda och flexibilitet som en importmodell ger?

Slutsats

Det här inlägget avslutar den här serien om att planera LuckyTemplates-projekt. dessa, tror jag, är de väsentliga stegen för alla power BI-projekt som du arbetar med. Dessa steg är viktiga när du gör due diligence, särskilt i ett företags Business Intelligence-miljö.

Med vänliga hälsningar,

Greg Deckler