Tips voor een succesvolle LuckyTemplates-implementatie

We gaan door met onze serie over LuckyTemplates-projectplanning en -implementatie. Deze keer zullen we het hebben over het ontwerpen van datasets , profilering en modi . Bekijk het eerste deel van onze serie projectplanning dat gaat over implementatiemodi en het tweede deel over ontdekking en opname .

Inhoudsopgave

• Datasetontwerp voor implementatie van LuckyTemplates-projecten
  • 4 stappen naar datasetontwerp
  • Selecteer het bedrijfsproces.
    • Het te vermijden antipatroon bij de implementatie van LuckyTemplates
  • Verklaar het graan.
  • Identificeer de afmetingen.
  • Definieer de feiten.
• Databusmatrix voor implementatie van LuckyTemplates-projecten
• Gegevensprofilering voor LuckyTemplates-implementatie
  • SQL Server-integratieservices
  • DAX-studio
  • LuckyTemplates Desktop
• Datasetplanning voor LuckyTemplates-implementatie
  • Een gegevenssetmodus kiezen
  • Enkele vragen die u moet stellen bij het kiezen van gegevenssetmodi
• Conclusie

Datasetontwerp voor implementatie van LuckyTemplates-projecten

Laten we het hebben over het ontwerpproces van de dataset en de busmatrix van het datawarehouse bespreken , een tool die al een tijdje bestaat.

Het ontwerpen van LuckyTemplates-datasets is vergelijkbaar met het ontwerpen van datawarehouses. Zowel datasets als datawarehouses hebben dus vergelijkbare concepten, zoals feiten- en dimensietabellen, sterschema's, langzaam veranderende dimensies, granulariteit van feitentabellen en lokaal geïnformeerde sleutels voor het bouwen van relaties tussen tabellen.

4 stappen naar datasetontwerp

Er zijn vier stappen in het ontwerpproces van de dataset: selecteer het bedrijfsproces , definieer de kern van uw feitentabellen, identificeer de dimensies en definieer vervolgens de feiten .

Selecteer het bedrijfsproces.

Voor de eerste stap wordt elk bedrijfsproces weergegeven door een feitentabel met een sterschema van veel-op-één-relaties met de dimensies.

Tijdens een ontdekkings- of vereistenverzamelingsproces is het moeilijk om zich te concentreren op een enkel bedrijfsproces afzonderlijk, aangezien gebruikers regelmatig meerdere bedrijfsprocessen tegelijkertijd analyseren.

Het te vermijden antipatroon bij de implementatie van LuckyTemplates

Het algemene antipatroon (dat een reactie is op een terugkerend probleem dat over het algemeen ineffectief en potentieel contraproductief is) dat u in LuckyTemplates-projecten wilt vermijden, is de ontwikkeling van datasets voor specifieke projecten of teams in plaats van voor de bedrijfsprocessen .

Bijvoorbeeld het ontwikkelen van een dataset exclusief voor het marketingteam en een andere dataset voor de verkooporganisatie. Deze aanpak leidt natuurlijk tot verspilling van middelen omdat dezelfde verkoopgegevens tweemaal worden opgevraagd en vernieuwd in beide datasets. Deze verbruiken ook opslagresources in de LuckyTemplates-service.

dit zijn enkele van de redenen waarom u een goed proces voor het ontwerpen van datasets wilt doorlopen. Een geïsoleerde benadering leidt tot problemen met beheersbaarheid en versiebeheer omdat de datasets variaties en transformaties kunnen bevatten.

Hoewel de analytische behoeften van de gebruikers of teams de prioriteit zijn van LuckyTemplates-projecten, is het ook belangrijk om te plannen voor duurzame oplossingen die uiteindelijk door teams kunnen worden gedeeld.

Verklaar het graan.

De feitentabellen hebben uiteindelijk betrekking op het detailniveau dat beschikbaar is voor analytische query's, evenals de hoeveelheid gegevens waartoe toegang kan worden verkregen.

Dus hogere korrel betekent meer detail, terwijl lagere korrel minder detail betekent. Een voorbeeld hiervan is wanneer u het niveau van de verkooporderregel wilt hebben, of als u wilt dat het project alleen het samenvattingsniveau van elke verkooporder bevat en niet naar de specifieke producten gaat die als onderdeel van die verkoop zijn besteld.

Soms kan deze korrel variëren, afhankelijk van uw tijdsbestek. Ik ben een aantal klanten tegengekomen die heel fijnmazige feitentabellen willen voor het huidige kwartaal, maar voor voorgaande kwartalen moesten ze gewoon weten wat de totale omzet voor het kwartaal was.

Tijdens deze stap wilt u bepalen wat elke rij van de verschillende bedrijfsprocessen vertegenwoordigt . Elke rij van de verkoopfeitentabel uit ons datawarehouse vertegenwoordigt bijvoorbeeld de regel van een verkooporder van een klant.

Omgekeerd worden de rijen van een verkoop- en margeplan geaggregeerd in een kalendermaand, productsubcategorie en verkoopregio. dus in dit geval heb je twee verschillende feitentabellen en twee verschillende korrels. als je de twee wilt vergelijken, komt er wat datamodelleringswerk bij kijken.

Identificeer de afmetingen.

Afmetingen zijn slechts het natuurlijke bijproduct van de korrel die in de vorige ontwerpstap is gekozen.

Een enkele voorbeeldrij uit de feitentabel moet dus duidelijk de dimensies van de bedrijfseenheid aangeven die verband houden met het gegeven proces, zoals de klant die een individueel project heeft gekocht, het product op een bepaalde datum en op een bepaald tijdstip. Feitentabellen die lagere korrels vertegenwoordigen, hebben minder dimensies.

Een feitentabel die het koptekstniveau van een inkooporder vertegenwoordigt, kan bijvoorbeeld de leverancier identificeren, maar niet de individuele productaankoop van de leverancier. in dat geval hoeft u dus geen productcategorie- of productsubcategoriedimensie op te nemen.

Definieer de feiten.

De feiten vertegenwoordigen de numerieke kolommen in de feitentabellen. Dus terwijl de dimensiekolommen uit stap 3 worden gebruikt voor relaties, worden de feitkolommen gebruikt in meetwaarden die aggregatielogica bevatten, zoals de som van een hoeveelheidskolom of het gemiddelde van een prijskolom.

Databusmatrix voor implementatie van LuckyTemplates-projecten

De datawarehouse-busmatrix is ​​een hoofdbestanddeel van de Ralph Kimball-datawarehouse-architectuur, die een incrementele en geïntegreerde benadering van het ontwerp van datawarehouses biedt.

De architectuur die u hier ziet, is afkomstig uit The Data Warehouse Toolkit , 3e editie door Ralph Kimball. Het maakt schaalbare gegevensmodellen mogelijk die meerdere bedrijfsteams of -functies vaak nodig hebben om toegang te krijgen tot dezelfde bedrijfsprocessen en dimensies.

Het is handig om een ​​datawarehouse-busmatrix bij de hand te hebben. wanneer u het invult, weet u of er andere datasets zijn die vergelijkbare feitentabellen en dimensietabellen op internet bevatten. dit bevordert de herbruikbaarheid van het project en verbetert de projectcommunicatie.

Elke rij weerspiegelt dus een belangrijk en terugkerend bedrijfsproces, zoals de maandelijkse afsluiting van het grootboek. elke kolom vertegenwoordigt een bedrijfsentiteit, die betrekking kan hebben op een of meer van de bedrijfsprocessen, terwijl de gearceerde rijen het bedrijfsproces vertegenwoordigen dat binnen het project wordt opgenomen.

Gegevensprofilering voor LuckyTemplates-implementatie

zodra u de korrel hebt geïdentificeerd en het ontwerpproces van de dataset in vier stappen is voltooid, moet dit onmiddellijk worden gevolgd door een technische analyse van de brongegevens van de feiten- en dimensietabellen .

Technische metadata, inclusief databasediagrammen en dataprofileringsresultaten, zijn essentieel voor de projectplanningsfase.

Deze informatie wordt gebruikt om ervoor te zorgen dat de LuckyTemplates-dataset de beoogde bedrijfsdefinities weerspiegelt en is gebaseerd op een degelijke en betrouwbare bron.

Dus drie zijn drie verschillende manieren om die profileringsinformatie te verzamelen, wat de allereerste stap zou moeten zijn die mensen zullen doen als ze eenmaal uit het ontwerpproces komen.

SQL Server-integratieservices

Er zijn een aantal manieren om dit aan te pakken. Eén methode is het gebruik van een gegevensprofileringstaak binnen een SQL Server Integration Services (SSIS)-pakket.

De gegevensprofileringstaak vereist een ADO.NET-verbinding en kan de uitvoer naar een XML-bestand of een SSIS-variabele schrijven.

In dit voorbeeld zijn de ADO.NET-brongegevens een AdventureWorks-datawarehouse, -database en -SQL-server en is de bestemming een XML-bestand.

Dus zodra de taak is uitgevoerd, kan het XML-bestand worden gelezen via een SQL Server-gegevensprofielviewer. U kunt de resultaten zien in termen van null count en null count percentages.

DAX-studio

Een andere manier van dataprofilering is via DAX Studio. u moet de gegevens daadwerkelijk opnemen in een LuckyTemplates-gegevensset door naar DAX Studio te gaan, naar het tabblad Geavanceerd te gaan en VertiPaq Analyzer uit te voeren .

Het toont u dezelfde soort informatie over de kardinaliteit van uw kolommen, zodat u weet welke de meeste ruimte innemen in uw gegevensmodel. het bevat alle verschillende statistieken rond de gegevens.

LuckyTemplates Desktop

gegevensprofilering is ook beschikbaar in Power Query binnen LuckyTemplates-desktop. als u naar het tabblad Weergave gaat , kunt u zaken als kolomkwaliteit, kolomdistributie en kolomprofiel inschakelen. Voor ten minste de eerste duizend rijen kunt u de informatie zien, zoals fouten, nulwaarden, gemiddelden en standaarddeviaties.

Datasetplanning voor LuckyTemplates-implementatie

Nadat de brongegevens zijn geprofileerd en geëvalueerd aan de hand van de vereisten die zijn vastgesteld in het ontwerpproces van vier stappen voor de dataset, kan het BI-team de implementatieopties voor de dataset verder analyseren.

In bijna alle LuckyTemplates-projecten, zelfs projecten met aanzienlijke investeringen in bedrijfsgegevens, magazijnen, architectuur en ETL-tools en -processen, is een zekere mate van aanvullende logica, integratie of transformatie nodig om de kwaliteit en waarde van de brongegevens te verbeteren.

De planningsfase van de dataset bepaalt hoe de geïdentificeerde problemen met datatransformatie worden aangepakt om de dataset te ondersteunen. Bovendien moet het projectteam bepalen of er een dataset in importmodus , een directe query-dataset of een samengestelde dataset moet worden ontwikkeld .

Om het planningsproces van de dataset te verduidelijken, identificeert dit diagram de verschillende lagen van het datawarehouse en de LuckyTemplates-dataset waar transformatie en bedrijfslogica kunnen worden geïmplementeerd.

in sommige projecten is minimale transformatie nodig en kan deze eenvoudig worden opgenomen in de power BI-dataset. Als er bijvoorbeeld maar een paar extra kolommen nodig zijn voor een dimensietabel en er duidelijke richtlijnen zijn voor hoe deze kolommen worden berekend, kan de IT-organisatie ervoor kiezen om deze transformaties te implementeren in M ​​Power Query's in plaats van het datawarehouse te herzien.

Als de substantiële kloof tussen de BI-behoeften en het datawarehouse van het bedrijf blijft bestaan, worden de LuckyTemplates-datasets complexer om te bouwen en te onderhouden.

Ontwerpers van datasets moeten regelmatig de implicaties van datasets analyseren en communiceren als er sprake is van grotere complexiteit.

Als de vereiste transformatielogica echter complex of omvangrijk is met meerdere gezamenlijke bewerkingen, rijfilters en wijzigingen in het gegevenstype, kan de IT-organisatie ervoor kiezen om essentiële wijzigingen in het datawarehouse door te voeren ter ondersteuning van de nieuwe dataset en toekomstige BI-projecten.

Er kunnen bijvoorbeeld een verzameltabel en een SQL-opslagprocedure nodig zijn om het proces te ondersteunen, te herzien en bij te werken, of het maken van een index kan nodig zijn om de queryprestaties voor DirectQuery-datasets te verbeteren.

Een gegevenssetmodus kiezen

Een volgende maar nauw verwante stap bij het plannen van datasets is kiezen tussen de standaard importmodus, DirectQuery/live-modus of samengestelde modus.

In sommige projecten is dit een eenvoudige beslissing waarbij slechts één optie haalbaar of realistisch is gezien de bekende vereisten, terwijl andere projecten een grondige analyse van de voor- en nadelen van elk ontwerp met zich meebrengen.

Dus als een gegevensbron als traag wordt beschouwd of slecht is toegerust om een ​​groot aantal analytische zoekopdrachten te verwerken, dan is een gegevensset in de importmodus zeer waarschijnlijk de voorkeursoptie.

Evenzo, als bijna realtime zichtbaarheid van een gegevensbron essentieel is, dan is DirectQuery of live-modus de enige optie om dat te bereiken. de DirectQuery- en live-modi lijken erg op elkaar. Beide methoden slaan geen gegevens op in de dataset zelf, en beide bevragen de bronsystemen rechtstreeks om gegevens op te halen op basis van gebruikersactie. We hebben nu DirectQuery voor LuckyTemplates-datasets en DirectQuery voor Analysis Services.

Enkele vragen die u moet stellen bij het kiezen van gegevenssetmodi

Hier zijn enkele vragen die u kunt stellen wanneer u beslist welke modus u wilt gebruiken. is er één bron voor onze dataset? Als er geen enkele bron is, kon u in het verleden geen DirectQuery/Live-bron gebruiken.

Ook al hebben we nu datasets in de samengestelde modus, het is nog steeds een goede vraag om aan het begin te stellen, want als er geen enkele bron is, is het ofwel import ofwel samengesteld.

Als DirectQuery/Live-bron een optie is, kan de bron dan analytische vragen ondersteunen? Als u met miljarden of biljoenen rijen werkt, is een gegevensset in importmodus misschien niet haalbaar en moet u de DirectQuery- of samengestelde modus gebruiken om er zeker van te zijn dat de gegevensset bruikbaar is.

Als de DirectQuery/Live-bron de werklast kan ondersteunen, is de DirectQuery/Live-verbinding dan waardevoller dan de prestaties en flexibiliteit van een importmodel?

Conclusie

Dit bericht rondt deze serie over het plannen van LuckyTemplates-projecten af. dit zijn volgens mij de essentiële stappen voor elk LuckyTemplates-project waaraan u werkt. Deze stappen zijn belangrijk bij het uitvoeren van de due diligence, vooral in een enterprise business intelligence-omgeving.

Al het beste,

Greg Decker