35,99 €
Mastering Microsoft Power BI, Second Edition, provides an advanced understanding of Power BI to get the most out of your data and maximize business intelligence. This updated edition walks through each essential phase and component of Power BI, and explores the latest, most impactful Power BI features.
Using best practices and working code examples, you will connect to data sources, shape and enhance source data, and develop analytical data models. You will also learn how to apply custom visuals, implement new DAX commands and paginated SSRS-style reports, manage application workspaces and metadata, and understand how content can be staged and securely distributed via Power BI apps. Furthermore, you will explore top report and interactive dashboard design practices using features such as bookmarks and the Power KPI visual, alongside the latest capabilities of Power BI mobile applications and self-service BI techniques. Additionally, important management and administration topics are covered, including application lifecycle management via Power BI pipelines, the on-premises data gateway, and Power BI Premium capacity.
By the end of this Power BI book, you will be confident in creating sustainable and impactful charts, tables, reports, and dashboards with any kind of data using Microsoft Power BI.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 909
Veröffentlichungsjahr: 2022
Mastering Microsoft Power BI
Second Edition
Expert techniques to create interactive insights for effective data analytics and business intelligence
Greg Deckler
Brett Powell
BIRMINGHAM—MUMBAI
Mastering Microsoft Power BI
Second Edition
Copyright © 2022 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Senior Publishing Product Manager: Devika Battike
Acquisition Editor – Peer Reviews: Saby Dsilva
Project Editor: Amisha Vathare
Content Development Editor: Rebecca Robinson
Copy Editor: Safis Editing
Technical Editor: Aditya Sawant
Proofreader: Safis Editing
Indexer: Rekha Nair
Presentation Designer: Ganesh Bhadwalkar
First published: March 2018
Second edition: June 2022
Production reference: 3141022
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
ISBN 978-1-80181-148-4
www.packt.com
Microsoft Power BI is the best analytics platform that empowers every employee to ask and explore questions, uncover insights, and gain intelligence through modern business intelligence tools. Power BI consists of cloud services, mobile applications, a data modeling and report authoring application, and other utilities, including the on-premises data gateway. Additionally, organizations can deploy Power BI reports on-premise via the Power BI Report Server and scale their deployments with Power BI Premium capacity.
This book provides an end-to-end analysis of Power BI tools and features, from planning a Power BI project to distributing Power BI apps to large groups of users. You will be familiarized with all the fundamental concepts and see how Power BI datasets, reports, and dashboards can be designed to deliver insights and rich, interactive experiences.
You'll also become knowledgeable about management and administration topics, such as the allocation of Power BI Premium capacities, Azure Active Directory security groups, conditional access policies, and staged deployments of Power BI content.
This book will inspire you to take advantage of these powerful features and follow consistent practices in deploying Power BI for your organization. I highly recommend this book to any new or existing Power BI users who want to learn what features and functionalities Power BI provides, as well as how they can quickly take advantage of their data.
- Leon Gordon, Thought Leader at Forbes Technical Council, Microsoft Data Platform MVP and Partner at Pomerol Partners
Greg Deckler is a Vice President at Fusion Alliance and has been a consulting services professional for over 27 years. Recognized as an expert in Power BI, Greg is a six-time Microsoft MVP for the Data Platform and an active member of the Power BI Community site with over 5,000 solutions authored and hundreds of Quick Measures Gallery submissions. Greg founded the Columbus Azure ML and Power BI User Group in Columbus, OH in 2016 and holds regular monthly meetings. Greg is also the author of numerous external tools for Power BI available for free on his gdeckler GitHub repository.
I would like to deeply thank my family, son Rocket, my extended Fusion Alliance family, the dynamic and vibrant Power BI community as a whole and especially all of the Super Users as well as my user group members. A special thanks to Brett Powell for all of his support and guidance on this book as well as Power BI Cookbook, 2nd Edition.
Brett Powell is a Microsoft business intelligence consultant and author. Brett has over 12 years of business intelligence experience across many industries as a developer, architect, and administrator. Although most known for his Insights Quest blog and the first editions of the Microsoft Power BI Cookbook and Mastering Microsoft Power BI, Brett primarily focuses on the needs of clients and project engagements though Frontline Analytics LLC, a Microsoft BI consultancy and Power BI partner.
I give all glory and praise to my Lord and Savior Jesus Christ. I was alone and lost in sin, but Christ has forgiven me and granted me a new peace and purpose for my life.
Eugene Meidinger has been working in business intelligence for over 8 years now, focusing heavily on business reporting. He speaks regularly at technical conferences, including Pass Summit and SQLBits. Eugene started his own company in 2018, SQLGene Training, and now produces training videos for Pluralsight and consults on Power BI.
I would like to thank my husband Miles for supporting me during the nights and weekends I worked on reviewing this book.
Join our community’s Discord space for discussions with the author and other readers: https://discord.gg/q6BPbHEPXp
Preface
Who this book is for
What this book covers
To get the most out of this book
Get in touch
Planning Power BI Projects
Power BI deployment modes
Corporate BI
Self-Service Visualization
Self-Service BI
Choosing a deployment mode
Project discovery and ingestion
Sample Power BI project template
Sample template – Adventure Works BI
Power BI project roles
Dataset designer
Report authors
Power BI administrator
Project role collaboration
Power BI licenses
Shared capacity
Free
Pro
Dedicated capacity
Premium
Premium Per User
Embedded
Power BI license scenarios
Dataset design
Data warehouse bus matrix
Dataset design process
Select the business process
Declare the grain
Identify the dimensions
Define the facts
Data profiling
Data profiling with Power BI Desktop
Dataset planning
Data transformations
Import, DirectQuery, Live, and Composite datasets
Import mode
DirectQuery/Live mode
Composite mode
Sample project analysis
Summary
Preparing Data Sources
Query folding
Partial query folding
Query design per dataset mode
Import mode dataset queries
DirectQuery dataset queries
DirectQuery report execution
Composite datasets
Table storage modes
Data sources
Authentication
Data source settings
Privacy levels
Power BI as a data source
Power BI Desktop options
Global options
CURRENT FILE options
SQL views
SQL views versus M queries
SQL view examples
Date dimension view
Mark as date table
Product dimension view
Slowly changing dimensions
Summary
Connecting to Sources and Transforming Data with M
Types of Power Query M queries
Organizing queries
Data source parameters
Staging queries
DirectQuery staging
Fact and dimension queries
Source reference only
Excel workbook – Annual Sales Plan
Parameter tables queries
Security table queries
Custom function queries
Creating Power Query M queries
Numeric data types
Item access in M
Power Query M query examples
Trailing three years filter
Combining queries
Incremental refresh for fact tables
Customer history column
Product dimension integration
R and Python script transformation
Dataflows
Power BI Premium dataflow features
Power Query M editing tools
Advanced Editor
Visual Studio Code
Visual Studio
Summary
Designing Import, DirectQuery, and Composite Data Models
Dataset layers
Power BI as a superset of Azure Analysis Services
Dataset objectives
Competing objectives
External factors
The Data Model
The Model view
The Data view
The Report view
Fact tables
Fact table columns
Fact column data types
Fact-to-dimension relationships
Dimension tables
Hierarchies
Custom sort
Parameter tables
Measure groups
Last refreshed date
Measure support logic
Display folders
Relationships
Uniqueness
Ambiguity
Single-direction relationships
Direct flights only
Bidirectional relationships
Shared dimensions
Date dimensions
The CROSSFILTER function
Model metadata
Visibility
Column and measure metadata
Default summarization
Data format
Data category
Description
Optimizing data model performance
Import
Query caching
Columnar compression
Memory analysis via DMVs and the VertiPaq Analyzer
DirectQuery
Columnstore and HTAP
Automatic aggregations
Composite
Aggregation tables
Summary
Developing DAX Measures and Security Roles
DAX measure basics
Filter context
SQL equivalent
Measure evaluation process
Row context
Scalar and table functions
Related tables
The CALCULATE() function
The FILTER() function
DAX variables
Base measures
Measure support expressions
KPI targets
Current and prior periods
Date intelligence metrics
Current versus prior and growth rates
Rolling periods
Calculation groups
Dimension metrics
Missing dimensions
Ranking metrics
Dynamic ranking measures
Security roles
Dynamic row-level security
Performance testing
Performance analyzer
DAX Studio
Summary
Planning Power BI Reports
Report planning process
Identify the audience
Define the business questions to answer
Confirm that the dataset supports the business questions
Determine interactivity
Define access and distribution
Sketch the report layout
Report architecture diagram
Visualization best practices
Choosing the right visual
Tables and matrices versus charts
Chart selection
Visualization anti-patterns
Visual interactions
Editing interactions
Drillthrough report pages
Custom labels and the back button
Multi-column drillthrough
Report filter scopes
Report filter conditions
Report and page filters
Relative date filtering
Visual-level filtering
Top N visual-level filters
Bookmarks
Selection pane and the Spotlight property
Custom report navigation
View mode
Live connections to Power BI datasets
Customizing Live connection reports
Switching Live source datasets
Switching between import mode and Live mode datasets
Report design summary
Summary
Creating and Formatting Visualizations
The Visualizations pane
Slicers
Slicer synchronization
Custom slicer parameters
What-if parameters
Page filter or slicer?
Single-value visuals
The Card visual
The KPI visual
Gauge visual
Map visuals
Bubble map
Filled map
Waterfall chart
Power Platform visuals
Power Apps for Power BI
Power Automate for Power BI
Premium visuals
Scorecard
Paginated reports
Elements
Formatting visualizations
Tooltips
Report page tooltips
Column and line charts
Column and line chart conditional formatting
Table and matrix visuals
Custom format strings
Table and matrix conditional formatting
Sparklines
Values as rows
Scatter charts
Summary
Applying Advanced Analytics
AI visuals
Key influencers
Decomposition tree
Q&A
Smart narrative
R and Python visuals
R visual
Python visual
ArcGIS Maps for Power BI
Custom visuals
Adding a custom visual
Animation and data storytelling
Play axis for Scatter charts
Pulse chart
Analytics pane
Trend line
Forecasting
Quick insights/Analyze
Explain the increase/decrease
Mobile-optimized report pages
Summary
Designing Dashboards
Dashboards versus reports
Dashboard design
Visual selection
Layout
Navigation pane
Fullscreen mode
Supporting tiles
Dashboard architectures
Single-dashboard architecture
Multiple-dashboard architecture
Organizational dashboard architecture
Multiple datasets
Dashboard tiles
Tile details and custom links
Real-time data tiles
Dashboard themes
Paginated reports
Excel workbooks
Live report pages
Mobile-optimized dashboards
Summary
Managing Workspaces and Content
Workspaces
Workspace roles and rights
Viewer role
Contributor role
Member role
Admin role
Datasets across workspaces
My workspace
Staged deployments
Workspace datasets
Power BI REST API and PowerShell module
Power BI REST API
Power BI PowerShell module
Workspace and content identifiers
PowerShell sample scripts
Power BI deployment pipelines
Content sensitivity and protection
Information protection
Data loss prevention
Version control
OneDrive for Business
Source control for M and DAX code
MSHGQM
Metadata management
Field descriptions
Creating descriptions
View field descriptions
Metadata Mechanic
Metadata reporting
Standard metadata reports
Server and database parameters
Querying the DMVs from Power BI
Integrating and enhancing DMV data
Metadata report pages
Summary
Managing the On-Premises Data Gateway
On-premises data gateway planning
Top gateway planning tasks
Determining whether a gateway is needed
Identifying where the gateway should be installed
Defining the gateway infrastructure and hardware requirements
Defining gateway roles and permissions
Planning for recovery keys
Standard versus personal mode
Gateway concepts
Gateway clusters
Gateway architectures
Gateway security
Gateway installation and configuration
The gateway service account
TCP versus HTTPS mode
Connectors
Recovery Keys
Managing gateway clusters
Gateway administrators
Gateway data sources and users
PowerShell support for gateway clusters
Troubleshooting and monitoring gateways
Restoring, migrating, and taking over a gateway
Gateway diagnostics
Gateway monitoring reports
Data refresh
Scheduled data refresh
DirectQuery datasets
Live connections to Analysis Services models
Dashboard cache refresh
Summary
Deploying Paginated Reports
Paginated reports in the Power BI service
Planning paginated reports
Building and publishing paginated reports
Identifying and interacting with paginated reports
Printing, exporting, subscribing, and sharing
Migrating reports to the Power BI service
Inventory
Assess
Plan
Migrate
User Acceptance Testing and final deployment
Planning the Power BI Report Server (PBRS)
Feature differences with the Power BI service
Parity with SQL Server Reporting Services
Data sources and connectivity options
Hardware and user licensing
Pro licenses for report authors
Alternative and hybrid deployment models
PBRS reference topology
Scale PBRS
Installing and upgrading PBRS
Retrieve the PBRS product key
Upgrade cycles
PBRS client applications
Running desktop versions side by side
Power BI mobile applications
Summary
Creating Power BI Apps and Content Distribution
Content distribution methods
Power BI apps
Licensing apps
App deployment process
User permissions and security
Publishing apps
Installing apps
App updates
Apps on Power BI mobile
Sharing content
Sharing scopes
Sharing versus Power BI apps
Embedding
Licensing embedding
Publish to web
Secure URL embedding
Microsoft 365 apps
Teams
SharePoint Online
Custom applications
Data alerts
Power Automate integration
Email subscriptions
Analyze in Excel
Self-service BI workspaces
Self-service content distribution
Risks of self-service BI
Summary
Administering Power BI for an Organization
Power BI administrator role
Data governance for Power BI
Implementing data governance
Azure Active Directory
AAD B2B collaboration
Licensing external users
Conditional access policies
Power BI admin portal
Tenant settings
Usage metrics
Users and Audit logs
Premium Per User
Capacity settings
Embed codes
Organizational visuals
Azure connections
Workspaces
Custom branding
Protection metrics
Featured content
Usage metrics reports
Audit logs
Audit log monitoring solution
The Power BI REST API for admins
Summary
Building Enterprise BI with Power BI Premium
Power BI Premium
Power BI Premium capabilities
Premium capacity nodes
Frontend versus backend resources
Premium capacity estimations
Premium capacity administration and allocation
Capacity allocation
Corporate and Self-Service BI capacity
Create, size, and monitor capacities
Changing capacity size
Monitoring Premium capacities
Workspace assignment
Premium capacity resource optimization
Data model optimizations
Report and visualization optimizations
Workloads
Life cycle management with Premium
ALM Toolkit deployment
Dataset management with SSMS
Backing up Premium capacities
Summary
Other Books You May Enjoy
Index
Cover
Index
Once you’ve read Mastering Microsoft Power BI, Second Edition, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.
Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.
Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere? Is your eBook purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily
Follow these simple steps to get the benefits:
Scan the QR code or visit the link belowhttps://packt.link/free-ebook/9781801811484
Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directlyPower BI is a robust, flexible business intelligence platform enabling organizations to deploy data analysis and reporting solutions according to their individual policies and use cases. Organizations can utilize Power BI to enable self-service data analytics and visualization for business analysts, as well as deploying enterprise-grade solutions involving technical expertise and advanced security and scalability features. Likewise, Power BI fully supports both cloud and on-premises data sources as well as all primary types of reports, ranging from interactive visualizations to pixel-perfect paginated reports to Excel-based reports.
While specific organizational goals, the data landscape, and specific resource responsibilities can vary greatly, the underlying concepts, deployment choices, roles, and planning processes for business intelligence projects remain the same. The long-term success or failure of most Power BI projects is most highly correlated to the planning, organization, and effective collaboration of the different stakeholders. Solutions that deliver the most value to the business over time are the result of thoughtful decisions around the people and processes involved in data governance, data quality, data modeling, and finally data visualization and distribution.
This chapter explores the various project planning decision topics, roles, and processes critical to the success of all Power BI projects.
In this chapter, we review the following topics:
Power BI deployment modesProject discovery and ingestionPower BI project rolesPower BI licensesDataset designData profilingDataset planningTo begin, we first explore the different deployment modes for Power BI.
Prior to the existence and adoption of BI tools capable of supporting self-service scenarios, business analysts were effectively relegated to the role of “end user” of solutions developed and maintained from end to end by their information technology department. While this top-down approach helped ensure that the solution would be secure, accurate, and resource-efficient, it was also relatively slow and inflexible to adjust to changing requirements.
As a consequence, business analysts commonly utilized the IT-owned solutions as merely a starting point or data source to their own MS Office-based solutions that business analysts could maintain. The perceived lack of flexibility and extended timelines sometimes associated with IT-owned solutions often frustrated business teams, resulting in a lack of adoption and “shadow IT” scenarios in which business users created their own solutions via Excel and other tools.
Modern business intelligence platforms such as Power BI provide increased opportunities for the business to participate in the creation and deployment of data assets for the organization. Organizations can deliver Power BI solutions that require the resources and technical expertise of a Corporate BI approach, as well as empowering business teams to leverage the self-service capabilities of the platform. This “self-service” can range widely from enabling teams to access and analyze certain certified Power BI datasets to empowering business analysts to create their own end-to-end solutions including their own data transformation workflows and semantic models.
In many scenarios, a combination of corporate IT resources, such as the on-premises data gateway and Power BI Premium capacity, can be combined with the business users’ knowledge of requirements and familiarity with data analysis and visualization in order to increase the velocity of data asset development. More experienced organizations may even utilize multiple deployment modes depending on the distinct requirements and use cases for Power BI across different teams and projects.
For example, solutions involving highly sensitive data or targeted at executive leadership are generally owned from end to end by Corporate BI/IT personnel. However, in scenarios involving rapidly changing requirements where deep business knowledge is essential, business analysts familiar with the data are often empowered with sufficient Power BI licenses and resources to develop their own datasets and reports.
We refer to standard deployment mode as Corporate BI, a deployment mode where the IT department controls all aspects of the business intelligence platform. Alternative approaches are called self-service, where the business controls some or all aspects of the business intelligence platform.
Self-service approaches can benefit both IT and business teams, as self-service can reduce IT resource constraints and project timelines, and provide the business with greater flexibility and control as analytical needs change. Additionally, Power BI projects can be migrated across deployment modes over time as required skills and resources change. However, greater levels of self-service and shared ownership structures generally increase the risk of miscommunication and introduce issues of version control, quality, and consistency.
These deployment modes are summarized in Figure 1.1:
Figure 1.1: Power BI deployment modes
A Power BI dataset is a semantic data model primarily comprised of data source queries, relationships between fact and dimension tables, and measure calculations. A semantic data model adds meaning to the physical, underlying data by adding relationships between data entities, allowing organizations to extract truth and understanding from their data.
Datasets often contain hierarchies, row-level security roles, and often other metadata such as calculation groups, detailed row expressions, and other metadata that supports usability and analysis. Power BI datasets share the heritage and concepts of Analysis Services tabular mode models and are generally developed using Power BI Desktop, a Windows application.
Microsoft has now positioned Power BI Premium-hosted datasets as their flagship semantic modeling tool and a “superset” of Analysis Services models. As the “superset” term implies, Power BI Premium-hosted datasets now support all of the enterprise-grade modeling features of Analysis Services and there are a number of powerful modeling features, such as composite models and incremental refresh policies, that are only available via Power BI datasets. Chapter 15, Building Enterprise BI with Power BI Premium, covers Power BI Premium in more detail.
Now that deployment modes are understood at a high level, let’s take a look at each of the three deployment modes in greater detail.
The Corporate BI delivery approach in which the BI team develops and maintains both the Power BI dataset (sometimes called a data model) and the required report visualizations is a common deployment option, particularly for large-scale projects and projects with executive-level sponsors or stakeholders. This is the approach followed in this chapter and throughout this book, as it offers maximum control over top BI objectives, such as version control, scalability, usability, and performance.
Corporate BI can be visualized as shown in Figure 1.2:
Figure 1.2: Corporate BI
As shown in Figure 1.2, all data and Power BI assets are owned by corporate IT and business users simply consume reports and dashboards published by corporate IT to the Power BI service.
Again, with the Corporate BI approach, business users are solely consumers of corporate business intelligence assets. Next, we compare this approach with self-service approaches where business users are more engaged with the creation and deployment of business intelligence assets.
In the Self-Service Visualization approach, the dataset is created and maintained by the IT organization’s BI team, but certain business users with Power BI Pro licenses create reports and dashboards for consumption by other users. In many scenarios, business analysts are already comfortable with authoring reports in Power BI Desktop (or, optionally, Excel) and can leverage their business knowledge to rapidly develop useful visualizations and insights.
With ownership of the dataset, the BI team can be confident that only curated data sources and standard metric definitions are used in reports and can ensure that the dataset remains available, performant, and updated or refreshed as per business requirements.
Self-Service Visualization is shown in Figure 1.3:
Figure 1.3: Self-Service Visualization
As shown in Figure 1.3, dataset designers within corporate IT still create and manage the Power BI datasets but business users author and publish reports and dashboards to the Power BI service. In the next section, we explore the Self-Service BI approach driven entirely by the business.
In the Self-Service BI approach, the BI organization only contributes essential infrastructure and monitoring, such as the use of an on-premises data gateway and possibly Power BI Premium capacity to support the solution. Since the business team maintains control of both the datasets and the visualization layer, the business team has maximum flexibility to tailor its own solutions including data source retrieval, transformation, and modeling.
This flexibility, however, can be negated by a lack of technical coding skills and a lack of technical knowledge such as the relationships between tables in a database. Additionally, business-controlled datasets can introduce version conflicts with corporate semantic models and generally lack the resilience, performance, and scalability of IT-owned datasets. Self-Service BI can be visualized as shown in Figure 1.4:
Figure 1.4: Self-Service Visualization
As shown in Figure 1.4, with a completely self-service approach to business intelligence with Power BI, the business, and not IT, performs all of the functions of dataset design and report authoring. Now that the three different deployment modes are understood in greater detail, next we cover choosing between them.
Organizations generally choose a standard deployment mode used throughout the business or choose a particular deployment mode based upon the unique requirements and goals of each individual Power BI project.
It’s usually necessary or at least beneficial for Corporate BI organizations to own the Power BI datasets or at least the datasets that support important, widely distributed reports and dashboards. This is primarily due to the value of providing a single source of truth built on top of a curated data source such as a data warehouse as well as the technical skills involved in developing and managing large or complex datasets.
Additionally, BI organizations require control of datasets to implement security and to maintain version control. Security and version control often factor into corporate governance policies or are necessary to maintain compliance with regulations imposed by government agencies. Therefore, small datasets initially created by business teams are often migrated to the BI team and either integrated into larger models or rationalized given the equivalent functionality from an existing dataset.
Larger organizations with experience in deploying and managing Power BI often utilize a mix of deployment modes depending on the needs of the project and available resources. For example, a Corporate BI solution with a set of standard IT-developed reports and dashboards distributed via a Power BI app may be extended by assigning Power BI Pro licenses to certain business users who have experience or training in Power BI report design. These users could then leverage the existing data model and business definitions maintained by IT to create new reports and dashboards and distribute this content in a separate Power BI workspace and/or app.
A workspace is simply a container of datasets, reports, and dashboards in the Power BI cloud service that can be distributed to large groups of users. A Power BI app represents the published version of a workspace in the Power BI service and workspace. Members can choose which items in the workspace are included in the published Power BI app. See Chapter 10, Managing Application Workspaces and Content, and Chapter 13, Creating Apps and Content Distribution, for greater detail on app workspaces and apps, respectively.
Another common scenario is a Proof of Concept (POC). A POC is a small-scale self-service solution developed by a business user or a team designed to be transitioned to a formal, IT-owned, and managed solution. Power BI Desktop’s rich graphical interfaces at each layer of the application (query editor, data model, and report canvas) make it possible and often easy for users to create useful models and reports with minimal experience and little to no code.
It’s much more difficult, of course, to deliver consistent insights across business functions (that is, finance, sales, and marketing) and at scale in a secure, governed environment. The IT organization can enhance the quality and analytical value of these assets, as well as providing robust governance and administrative controls to ensure that the right data is being accessed by the right people.
The following list of fundamental questions help guide a deployment mode decision:
Who will own the data model?Experienced dataset designers and other IT professionals are usually required to support complex data transformations, analytical data modeling, large data sizes, and security rules, such as RLS roles, as described in Chapter 5, Developing DAX Measures and Security Roles.
If the required data model is relatively small and simple, or if the requirements are unclear, the business team may be best positioned to create at least the initial iterations of the model.
The data model could be created with Analysis Services or Power BI Desktop.
Who will own the reports and dashboards?Experienced Power BI report developers with an understanding of corporate standards and data visualization best practices can deliver a consistent user experience.
Business users can be trained on report design and development practices and are well positioned to manage the visualization layer, given their knowledge of business needs and questions.
How will the Power BI content be managed and distributed?A staged deployment across development, test, and production environments, as described in Chapter 8, Managing Application Workspaces and Content, helps to ensure that quality, validated content is published. This approach is generally exclusive to Corporate BI projects.
Sufficient Power BI Premium capacity is required to support distribution to Power BI free users and either large datasets or demanding query workloads.
Self-Service BI content can be assigned to Premium capacity, but organizations may wish to limit the scale or scope of these projects to ensure that provisioned capacity is being used efficiently.
As covered in this section, deployment modes represent the overall manner in which Power BI is used within an organization. Now that the different deployment modes for Power BI are fully understood, we next move on to covering the processes and roles for implementing individual Power BI projects.
An organization’s business intelligence assets are the result of individual projects designed to accomplish a specific set of goals or answer a specific set of business questions. Thus, the successful initiation and execution of business intelligence projects is vital to all organizations.
Power BI projects often begin with answering a set of standard questions within a project template form. Business guidance on these questions informs the BI team of the high-level technical needs of the project and helps to promote a productive project kickoff. By reviewing the project template, the BI team can ask the project sponsor or relevant Subject Matter Experts (SMEs) targeted questions to better understand the current state and the goals of the project.
A sample Power BI project template is provided in the following section.
The primary focus of the project planning template and the overall project planning stage is on the data sources and the scale and structure of the Power BI dataset required. The project sponsor or business users may only have an idea of several reports, dashboards, or metrics needed but, as a Corporate BI project, it’s essential to focus on where the project fits within an overall BI architecture and the long-term Return on Investment (ROI) of the solution. For example, BI teams would look to leverage any existing Power BI datasets or Analysis Services tabular models applicable to the project and would be sensitive to version control issues.
The following section provides a completed template for a Power BI project.
The template is comprised of two tables. The first table, Table 1.1, answers the essential who and when questions so that the project can be added to the BI team’s backlog. The BI team can use this information to plan their engagements across multiple ongoing and requested Power BI projects and to respond to project stakeholders, such as Vickie Jacobs, VP of Group Sales, in this example:
Date of Submission
6/6/2022
Project Sponsor
Vickie Jacobs, VP of Group Sales
Primary Stakeholders
Adventure Works Sales
Adventure Works Corp
Power BI Author(s)
Mark Langford, Sales Analytics Manager
Table 1.1: Project sponsors, stakeholders, and participantsIdentifying stakeholders is critical to the success of business intelligence projects. Stakeholders define the goals and requirements of the business intelligence project and ultimately determine success or failure in meeting identified goals. There are often multiple stakeholders for business intelligence projects and these stakeholders may even span multiple business domains. Start by identifying the business domains as stakeholders for the business intelligence project and then identify specific individuals within those domains who can provide the goals and requirements for the project.
It is always advantageous to identify a single individual as a special kind of stakeholder, a project sponsor. Project sponsors secure the funding and assist in the prioritization of resources for business intelligence projects.
The following table, Table 1.2, is a list of questions that describe the project’s requirements and scope. It is critical to discover and answer as many of these questions as possible early on in a business intelligence project in order to set expectations in terms of the cost and duration of the project. For example, the number of users who are read-only consumers of Power BI reports and dashboards and the number of self-service users who need Power BI Pro licenses to create Power BI content largely impact the total cost of the project. Likewise, the amount of historical data to include in the dataset (2 years, 5 years?) can significantly impact performance scalability:
Topic
#
Question
Business Input
Data sources
1
Can you describe the required data? (For example, sales, inventory, shipping)
Internet Sales, Reseller Sales, and the Sales and Margin Plan. We need to analyze total corporate sales, online and reseller sales, and compare these results to our plan.
Data sources
2
Is all of the data required for your project available in the data warehouse (SQL Server)?
No.
Data sources
3
What other data sources (if any) contain all or part of the required data (for example, Web, Oracle, Excel)?
The Sales and Margin Plan is maintained in Excel.
Security
4
Should certain users be prevented from viewing some or all of the data?
Yes, sales managers and associates should only see data for their sales territory group. VPs of sales, however, should have global access.
Security
5
Does the data contain any PCII, HIPAA, GDPR, or other sensitive data?
No, not that I’m aware of.
Scale
6
Approximately, how many years of historical data are needed?
3-4.
Scale
7
Is it necessary to track the history of certain dimensions such as customers or products? For example, if a customer’s address changes, is it necessary to store and report on both the prior address and the new address?
Yes, it would be helpful to track product history.
Data refresh
8
How often does the data need to be refreshed?
Daily.
Data refresh
9
Is there a need to view data in real time (as it changes)?
No.
Distribution
10
Approximately, how many users will need to view reports and dashboards?
200.
Distribution
11
Approximately, how many users will need to create reports and dashboards?
3-4.
Distribution
12
Will the users be viewing the reports and dashboards on mobile devices such as phones or tablets?
Yes, users need the ability to access the information on their phones.
Version control
13
Are there existing reports on the same data? If so, please describe.
Yes, there are daily and weekly sales snapshot reports available on the portal. Additionally, our team builds reports in Excel that compare actuals to the plan.
Version Control
14
Is the Power BI solution expected to replace these existing reports?
Yes, we would like to exclusively use Power BI going forward.
Version Control
15
Is there an existing Power BI dataset that targets the same business processes (fact tables)?
Not to our knowledge.
Table 1.2: Project questions regarding project’s scopeA business analyst inside the IT organization often partners with the business on completing the project ingestion template and reviews the current state in order to give greater context to the template. Prior to the project kickoff meeting, the business analyst usually meets with the BI team members to review the template and any additional findings or considerations.
Many questions with greater levels of detail are required as the project moves forward and therefore the template shouldn’t attempt to be comprehensive or overwhelm business teams. The specific questions to include should use business-friendly language and serve to call out the top drivers of project resources and Corporate BI priorities, such as security and version control.
Now that you understand the process and requirements that drive project discovery and ingestion, we next cover the different roles involved in Power BI projects.
Following the review of the project template and input from the business analyst, members of the Power BI team directly engage the project sponsor and other key stakeholders to officially engage in the project. These stakeholders include SMEs on the data source systems, business team members knowledgeable about the current state of reporting and analytics, and administrative or governance personnel with knowledge of organizational policies, available licenses, and current usage.
New Power BI projects of any significant scale and long-term adoption of Power BI within organizations require Dataset Designers, Report Authors, and Power BI Admin(s), as illustrated in the following diagram:
Figure 1.5: Power BI team roles
Each of the three Power BI project roles and perhaps longer-term roles as part of a business intelligence team entail a distinct set of skills and responsibilities. It can be advantageous in a short-term or POC scenario for a single user to serve as both a dataset designer and a report author. However, the Power BI platform and the multi-faceted nature of Corporate BI deployments are too broad and dynamic for a single BI professional to adequately fulfill both roles.
It’s recommended that team members either self-select or are assigned distinct roles based on their existing skills and experience and that each member develops advanced and current knowledge relevant to their role. For example, individuals with a user experience and user interface (UX/UI) background are generally best suited to fulfill the Report Author role. Conversely, more technical developers with a background in coding and data modeling often fulfill the Dataset Designer role. A BI manager and/or a project manager can help facilitate effective communication across roles and between the BI team and other stakeholders, such as project sponsors.
Let’s now take a closer look at each of the three roles involved in Power BI projects.
The dataset designer is responsible for the data access layer of the Power BI dataset, including the authentication to data sources and the M queries used to define the tables of the data model. Additionally, the dataset designer defines the relationships of the model and any required row-level security roles and develops the DAX measure expressions for use in reports, such as year-to-date (YTD) sales.
A Power BI dataset designer often has experience in developing Analysis Services models, particularly Analysis Services models in tabular mode, as this aligns with the semantic modeling engine used in Power BI. For organizations utilizing both Analysis Services and Power BI Desktop, this could be the same individual. Alternatively, business analysts experienced with Power Pivot for Excel or with the modeling features of Power BI Desktop may also prove to have the skills required of Power BI dataset designers for self-service scenarios.
Datasets (semantic models) have always been the heart of Power BI solutions as they serve as the data source responsible for rapidly resolving the report queries generated by reports and analysis sessions. Power BI datasets can be designed to import copies of data from multiple data sources into a compressed, in-memory cache, as well as merely passing report queries back to a data source system such as Azure Synapse Analytics. Additionally, Power BI dataset designers can mix both import (in-memory) and DirectQuery storage modes across different tables of a dataset thus balancing the tradeoffs between the two storage modes.
In addition to providing a performant and scalable data source that efficiently utilizes resources (CPU, RAM), datasets must provide a user-friendly interface for report authors and analysts to quickly produce effective content. Moreover, datasets also typically contain Row-Level Security (RLS) roles that limit what certain users or groups of users can see and can also contain complex logic to support certain business rules or report requirements. Datasets are therefore a critical component of Power BI projects and their design has tremendous implications regarding user experience, query performance, source system and Power BI resource utilization, and more.
Given the importance of Power BI datasets and the implications of dataset design decisions for entire environments, many organizations choose to dedicate one or multiple developer roles to Power BI datasets. These individuals are expected to have advanced- to expert-level knowledge of Data Analysis eXpressions (DAX) as well as experience with enterprise features such as aggregation tables, partitions and incremental refresh, and other supporting third-party tools such as ALM Toolkit. All of these topics are explained in later chapters.
Business analysts or “power users” can often independently learn or receive essential training to build basic Power BI datasets that meet the needs of their department. However, business analysts can also struggle to learn coding languages like M and DAX and can fail to appreciate other goals of a dataset such as resource usage. For this reason, organizations are well advised to regularly monitor the datasets developed by business teams/analysts and consider adopting a process for migrating ownership of these datasets from a business team to a Corporate BI team.
It can’t be emphasized strongly enough that Power BI project teams should carefully distinguish between datasets and reports and maintain a goal of supporting many related reports and dashboards via high-quality, well-tested or certified datasets. This can be challenging as teams are generally tasked with developing reports regardless of the source dataset, thus creating a temptation to simply create a dataset dedicated to the needs of a single report. Over the long term this “report factory” approach results in both inefficient use of resources (CPU) as well as confusion and manageability issues with many datasets having slightly different logic and all needing to be maintained.
Dataset designers should regularly communicate with data source owners or SMEs, as well as report authors. For example, the dataset designer needs to be aware of changes to data sources so that data access queries can be revised accordingly, and report authors can advise of any additional measures or columns necessary to create new reports. Furthermore, the dataset designer should be aware of the performance and resource utilization of deployed datasets and should work with the Power BI admin on issues such as Power BI Premium capacity.
As per Figure 1.5, there are usually relatively few dataset designers in a team compared with the number of report authors. This is largely due to the organizational objectives of version control and reusability, which leads to a small number of large datasets. Additionally, robust dataset development requires knowledge of the M and DAX functional programming languages, dimensional modeling practices, and business intelligence. Database experience is also very helpful. If multiple dataset designers are on a team, they should look to standardize their development practices so that they can more easily learn and support each other’s solutions.
With the crucial role of the dataset designer understood, we next explore the report author role.
Report authors interface directly with the consumers of reports and dashboards or a representative of this group. In a self-service deployment mode or a hybrid project (business and IT), a small number of report authors may themselves work within the business.
Above all else, report authors must have a clear understanding of the business questions to be answered and the measures and attributes (columns) needed to visually analyze and answer these questions. The report author should also be knowledgeable of visualization best practices, such as symmetry and minimalism, in addition to any corporate standards for report formatting and layout.
Power BI Desktop provides a rich set of formatting properties and analytical features, giving report authors granular control over the appearance and behavior of visualizations. Report authors should be very familiar with all standard capabilities, such as conditional formatting, drilldown, drillthrough, and cross-highlighting, as they often lead demonstrations or training sessions.
It’s important for report authors to understand the use cases and essential features of the two alternative report types available in Power BI – paginated reports and Excel reports. For example, given the requirements to export or print detail-level data, a report author should be comfortable in building a paginated report via the Power BI Report Builder. Additionally, report authors should understand the organization’s policies on custom visuals available in the MS Office store and the specific use cases for top or popular custom visuals.
It should be clear now that report authors have distinct responsibilities and skillsets compared to dataset designers. The ability to design intuitive reports and dashboards that are easily understood by the business is also of critical importance to the success of every Power BI project. Next, we look at the last critical role, the Power BI administrator.
As Power BI has grown its capabilities and become a mission-critical tool for organizations, the role of a Power BI administrator (admin) has become increasingly common. Power BI administrators are responsible for ensuring Power BI is utilized effectively and according to the organization’s policies. For example, Power BI administrators monitor and troubleshoot dataset refresh failures, performance issues, user access requests and issues, and the overall health of an organization’s Premium capacities.
A Power BI administrator is assigned the Power BI administrator role in Azure Active Directory, the identity and access control service at the heart of Microsoft’s cloud-based Software as a Service (SaaS) products. Assignment of the Power BI administrator role is done in the Microsoft 365 admin center and only Global administrators of Office 365 can assign users to the role.
Users assigned to the Power BI administrator role obtain access to the Power BI admin portal and the rights to configure Power BI tenant settings. The Power BI admin portal and tenant settings are used to enable or disable features, such as exporting data and printing reports and dashboards. BI and IT managers that oversee Power BI deployments are often assigned to this role, as the role also provides the ability to manage Power BI Premium capacities and access to standard monitoring and usage reporting.
The Power BI admin should have a clear understanding of the organizational policy on the various tenant settings, such as whether content can be shared with external users. For most tenant settings, the Power BI administrator can define rules in the Power BI admin portal to include or exclude specific security groups. For example, external sharing can be disabled for the entire organization except for a specific security group of users.
Power BI admins must also have a thorough knowledge of permissions, roles, sharing, and licensing of Power BI in order to resolve common issues related to access. For example, a Power BI admin would know that build permission to a dataset could be granted to a business analyst as a less permissive alternative to membership in the workspace of the source dataset.
Most organizations should assign two or more users to the Power BI administrator role and ensure these users are trained on the administration features specific to this role. Chapter 14, Administering Power BI for an Organization, contains details on the Power BI admin portal and other administrative topics.
While Power BI admins are not involved in the day-to-day activities of specific projects, the role is ultimately critical to the success of all projects, as is the overall collaboration between all project roles, which we cover in the next section.
Communicating and documenting project role assignments during the planning stage promotes the efficient use of time during the development and operations phases. For organizations committed to the Power BI platform and perhaps migrating away from a legacy or different BI platform, project roles may become full-time positions.
For example, BI developers with experience in DAX and Analysis Services tabular models may transition to permanent dataset designer roles while BI developers experienced in data visualization and report development may become report authors:
Name
Project role
Brett Powell
Dataset Designer
Jennifer Lawrence
Report Author
Anna Sanders
Power BI Administrator
Mark Langford
Report Author
Stacy Loeb
QA Tester
Table 1.3: Project role assignmentsIt is important for the individuals within all of the various roles to work together and communicate effectively in order to deliver a successful project outcome. Proper communication and collaboration are important to all projects but are perhaps even more crucial within the realm of business intelligence given the distinct nature of the roles involved and the criticality of accurate, effective reporting to the success of organizations.
With project roles and responsibilities now understood, we next cover the various forms of licensing for Power BI deployments.
Power BI provides a number of different licensing options that provide flexible and affordable pricing for individuals and organizations. These licensing options come in two primary categories:
Shared capacityDedicated capacityLet us first have a look at shared capacity.
Shared capacity is like an apartment building. While each tenant in the building has their own personal living quarters accessible to only themselves, certain infrastructures such as plumbing, electrical wiring, and stairways are common to everyone in the building. Shared capacity for Power BI is similar. Each tenant within the Power BI service has its own area for publishing data and reporting assets but infrastructure such as memory and processing capacity are shared among the tenants. Thus, just like a noisy neighbor in an apartment building can affect other tenants, so too can tenants within shared capacity in the Power BI service impact the performance for other tenants.
Tausende von E-Books und Hörbücher
Ihre Zahl wächst ständig und Sie haben eine Fixpreisgarantie.
Sie haben über uns geschrieben: