Power BI Modeling Use Cases: Desktop to Enterprise

Editor's Notes

• #2: Welcome! Thanks for joining us in the latest installment of the Senturus business analytics education series. I’m Michael Weinhauer your host for today…give background…
• #3: Today’s agenda. After a brief introduction of the speakers, we’ll get right into the topic. Stay on after the presentation when we will We’ll then share useful links, provide a quick overview of Senturus and let you know of upcoming events. We’ll wrap with a live Q&A.
• #4: The first question we usually get is “Can I get a copy of the presentation?” Absolutely! It’s available on Senturus.com. Select the Resources tab and then Resources Library. Or you can click the link that was just posted in the GoToWebinar Control panel. Be sure to bookmark the resource library. It has tons of valuable content addressing a wide variety of business analytics topics.
• #7: I’m an eager analyst in a small company (business unit within a larger company). I have business data sitting in a bunch of flat files and I’m not going to bother IT with any of this yet (e.g. resources, politics, competence). I have a lot to figure out! How am I going to: Prepare, Store, Model, Visualize, and Share? On top of all that, how am I going to: Have this perform super fast (perhaps by storing data in-memory)? Do it myself (self-service)?? Can one tool do It all? This used to be a disjointed process, with upstream data prep and modeling handled by multiple people, often in IT.
• #9: Note iterative capability where historically ETL, Modeling, Reporting/Visualization and Deployment were separate and distinct roles, many often handled by IT. Power BI and modern tools allow for rapid iteration. Concepts can be prototypes, changes made quickly and incorporated at the report, then into the model layer, and ultimately deployed and/or pushed further upstream into EDW.
• #11: Cost vs Performance vs Governance Like an Orchestra Bulls eye? Why you should care? The true cost Transportation analogy RIGHT TOOL FOR THE JOB
• #12: Distinction between DirectQuery, In-Memory, Import etc for the SOURCE (i.e., SSAS, Dataset) vs Power Query usage. For purposes of this webinar, we generally are referring to the query as it is executed by Power BI desktop/report authoring environment Composite models currently combine import w DirectQuery, however MSFT is enhancing this capability to allow more than one DirectQuery connection in a model.
• #14: Direct connection to the transactional data​ not modeled for analysis​ not suggested/best practice​ will possibly affect the transactional system​ Upwards of 20-30 THOUSAND Tables,3NF, etc Ideal For: small organizations or teams, small data volumes, prototypes Method: DirectQuery, Import, or Dual DirectQuery ​ can be against transactional DB or against SSAS cube configured as DirectQuery against transactional DB​ Import ​ can be imported into Power BI model or SSAS model​ better use case than DirectQuery due to only hitting the transactional DB during refresh​ better use case due to typical import vs DirectQuery pros/cons (i.e. performance, modeling, etc.)​
• #15: Direct connection to the transactional data​ not suggested/best practice​ will possibly affect the transactional system​ typically not modeled for analysis​ can be DirectQuery or import​ DirectQuery ​ can be against transactional DB or against SSAS cube configured as DirectQuery against transactional DB​ Import ​ can be imported into Power BI model or SSAS model​ better use case than DirectQuery due to only hitting the transactional DB during refresh​ better use case due to typical import vs DirectQuery pros/cons (i.e. performance, modeling, etc.)​ Ideal For: smalerl organizations or teams, real-time/operational use cases, rapid prototypes Method: DirectQuery, Import, or Dual (Can also be “extract/export”, i.e., run a report from source system) Maturity Level? Beginner
• #16: Transactional data --> DW​ better practice​ Defined as anything other than txnl – actual EDW, snapshot, ODS, Data Lake – your mileage may vary! Doesn’t affect the transactional DB​ Modeled for analysis​ can be DirectQuery or import​ DirectQuery ​ can be against DW or against SSAS cube configured as DirectQuery against DW​ Import​ can be imported into Power BI model or SSAS model​ better use case than DirectQuery due to only hitting the DW during refresh​ better use case due to typical import vs DirectQuery pros/cons (i.e. performance, modeling, etc.)​ Ideal for: medium/large enterprise Methods: DirectQuery, Import, or Dual
• #17: Transactional data --> DW​ better practice​ Defined as anything other than txnl – actual EDW, snapshot, ODS, Data Lake – your mileage may vary! Doesn’t affect the transactional DB​ Modeled for analysis​ can be DirectQuery or import​ DirectQuery ​ can be against DW or against SSAS cube configured as DirectQuery against DW​ Import​ can be imported into Power BI model or SSAS model​ better use case than DirectQuery due to only hitting the DW during refresh​ better use case due to typical import vs DirectQuery pros/cons (i.e. performance, modeling, etc.)​ Ideal for: medium/large enterprise Methods: DirectQuery, Import, or Dual
• #18: Option #2 – Connect to EDW​ better practice​ will not affect the transactional DB​ typically modeled for analysis​ can be DirectQuery or import​ DirectQuery ​ can be against DW or against SSAS cube configured as DirectQuery against DW​ Import​ can be imported into Power BI model or SSAS model​ better use case than DirectQuery due to only hitting the DW during refresh​ better use case due to typical import vs DirectQuery pros/cons (i.e. performance, modeling, etc.)​ Ideal for: medium/large enterprise Methods: DirectQuery, Import, or Dual MENTION ITERATIVE PROCESS – feedback loop – bring in other data source, proving value, harden, pull upstream into flows, ETL etc.
• #20: Transactional data --> SSAS Live Query from PBI, i.e., zero modeling, only creation of measures using existing fields. However, Microsoft is working on composite models to allow DirectQuery against SSAS or Power BI service models + the ability to import and append to the model. SSAS DirectQuery ​ SSAS cube can be configured as DirectQuery from DW​ SSAS In-Memory better use case than DirectQuery due to only hitting the DW during refresh​ better use case due to typical import vs DirectQuery pros/cons (i.e. performance, modeling, etc.)​ Import into PBI Allows for additional modeling in PBI, but you are now pulling all the data over locally and it is very resource intensive. Ideal for: medium/large enterprise, governed reporting needs, ease of use Methods: DirectQuery or Import
• #21: Option #2 – Connect to EDW​ better practice​ will not affect the transactional DB​ typically modeled for analysis​ can be DirectQuery or import​ DirectQuery ​ can be against DW or against SSAS cube configured as DirectQuery against DW​ Import​ can be imported into Power BI model or SSAS model​ better use case than DirectQuery due to only hitting the DW during refresh​ better use case due to typical import vs DirectQuery pros/cons (i.e. performance, modeling, etc.)​ Ideal for: medium/large enterprise Methods: DirectQuery, Import, or Dual MENTION ITERATIVE PROCESS – feedback loop – bring in other data source, proving value, harden, pull upstream into flows, ETL etc.
• #22: Shared Dataset can be based on DirectQuery (to any data source - i.e. transactional, DW) can be based on import (Power BI or SSAS) can point to dataflows as a data source Ideal for: shared datasets across Power BI reports Methods: Datasets can be DirectQuery or Import, but from Power BI are Live only INTENT of data set is to provide clean data, BUT can be wild wild west Old way was top down, governed. These tools have turned upside down, so governance is critical!
• #23: Shared Dataset can be based on DirectQuery (to any data source - i.e. transactional, DW) can be based on import (Power BI or SSAS) can point to dataflows as a data source Can be promoted/certified Ideal for: shared datasets across Power BI reports Methods: Datasets can be DirectQuery or Import, but from Power BI are Live only INTENT of data set is to provide clean data, BUT can be wild wild west Old way was top down, governed. These tools have turned upside down, so governance is critical!
• #24: Shared Dataset can be based on DirectQuery (to any data source - i.e. transactional, DW) can be based on import (Power BI or SSAS) can point to dataflows as a data source Ideal for: shared datasets across Power BI reports Methods: Datasets can be DirectQuery or Import, but from Power BI are Live only INTENT of data set is to provide clean data, BUT can be wild wild west Old way was top down, governed. These tools have turned upside down, so governance is critical!
• #25: Dataflows​ - think “reusing data objects (one or more ENTITIES) across different reporting MODELS, i.e., TIME” Always imported into Azure Data Lake Gen2 (ADLG2)​ can reduce the number of data extracts from source systems​ can be configured as incremental refreshes​ can then be configured as DirectQuery from Power BI to the dataflow (coming soon) or import from Power BI to the dataflow​ can BYOS (bring your own storage) and point dataflows to your own Azure Data Lake Gen2​ that data in your own ADLSG2 storage can then be utilized by other downstream services​ that data can also be configured to utilize CDM​ Ideal for: shared data sources across Power BI datasets Methods: Import
• #26: Dataflows​ - think “reusing data objects (one or more ENTITIES) across different reporting MODELS, i.e., TIME” Always imported into Azure Data Lake Gen2 (ADLG2)​ can reduce the number of data extracts from source systems​ can be configured as incremental refreshes​ can then be configured as DirectQuery from Power BI to the dataflow (coming soon) or import from Power BI to the dataflow​ can BYOS (bring your own storage) and point dataflows to your own Azure Data Lake Gen2​ that data in your own ADLSG2 storage can then be utilized by other downstream services​ that data can also be configured to utilize CDM​ Ideal for: shared data sources across Power BI datasets Methods: Import
• #27: Dataflows​ are always import into Azure Data Lake Gen2 ​ can reduce the number of data extracts from source systems​ can be configured as incremental refreshes​ can then be configured as DirectQuery from Power BI to the dataflow (coming soon) or import from Power BI to the dataflow​ can BYOS (bring your own storage) and point dataflows to your own Azure Data Lake Gen2​ that data in your own ADLSG2 storage can then be utilized by other downstream services​ that data can also be configured to utilize CDM​ Ideal for: shared data sources across Power BI datasets Methods: DirectQuery Premium – 100TB limit, Pro 10GB limit
• #28: Assumes well-designed EDW or data model “Query Method” refers to query connection method used by Power BI Desktop
• #29: Assumes well-designed EDW or data model “Query Method” refers to query connection method used by Power BI Desktop
• #30: BI reports Methods: DirectQuery or Import Iterative process - Starts w desktop as prototype – suss out requirements, optimize, harden, deploy, iterate
• #32: Focus on the issues that have the biggest impact to your organization, including Speed up dashboard creation—reduce time spent gathering data Reuse data sets—eliminate repetitive work Share dashboards across departments Perform rapid, on-the-fly recalculations Reduce errors from manual data manipulation Restrict access to sensitive data
• #33: At Senturus we concentrate our expertise on business intelligence with a depth of knowledge across the entire BI stack.
• #34: At Senturus, our clients know us for providing clarity from the chaos of complex business requirements, disparate data sources and constantly moving targets. We have made a name for ourselves because of our strength at bridging the gap between IT and business users. We deliver solutions that give you access to reliable, analysis-ready data across the organization so you can quickly and easily get answers at the point of impact: the Decisions you Make and Actions you Take.
• #35: Our consultants are leading experts in the field of analytics, with years of pragmatic, real-world expertise and experience advancing the state-of-the-art. We’re so confident in our team and our methodology that we back our projects with a 100% money back guarantee that is unique in the industry.
• #36: We have been focused exclusively on business intelligence for 19 years. We work across the spectrum from Fortune 500 to mid market, We solve business problems across many industries and function areas including in the office of finance, sales and marketing, manufacturing, operations, HR and IT Our team is large enough to meet all your business analytics needs yet small enough to provide personal attention.
• #37: Senturus has 100s of free resources on our website, from webinars on all things BI, to our fabulous up-to-the-minute, easily consumable blogs.
• #39: We provide training in the three top BI platforms. We are ideal for organizations running multiple platforms or those moving from one to another. We can provide training in many modes and can mix and match to suit your user community.
• #40: Senturus provides 100s of free resources on our website. We have been committed to sharing our BI expertise for over a decade.