Power BI Fundamentals

Olá, daqui é o Alex do DEV STORIES DOT EU. Fundamentos de Power BI, episódio 1 de 14. A maioria das empresas está a nadar em dados, mas sedenta por verdadeiros insights. Tens bases de dados, folhas de cálculo e cloud storage cheios de números, mas quando a direção pergunta como foi o desempenho de um produto no último trimestre, toda a gente fica perdida. A solução para preencher esta lacuna entre números dispersos e informação coerente é o ecossistema Power BI. O Power BI não é um único software. É uma coleção de serviços, apps e conectores desenhados para funcionar em conjunto. A sua principal função é pegar em fontes de dados não relacionadas e transformá-las em relatórios interativos e visualmente imersivos. Uma armadilha frequente para novos utilizadores é confundir as diferentes partes deste ecossistema, especificamente a aplicação desktop e o web service. São ferramentas completamente diferentes, criadas para diferentes fases do ciclo de vida de reporting. Para não as confundires, lembra-te apenas que uma é a fábrica e a outra é o showroom. A fábrica é o Power BI Desktop. Esta é uma aplicação gratuita que instalas numa máquina Windows local. O Power BI Desktop é a tua principal ferramenta de autoria e criação. É aqui que o trabalho pesado acontece. É aqui que te ligas aos teus dados brutos, os limpas e desenhas o layout visual do teu relatório. Imagina um gestor de vendas que recebe um ficheiro Excel enorme, um flat file cheio de registos de transações em bruto. Olhar para um milhão de linhas de texto não o ajuda a tomar uma decisão. Ele abre o Power BI Desktop no seu laptop e liga-se diretamente a esse ficheiro Excel. Ele usa a desktop app para construir um relatório, adicionando um mapa para mostrar as vendas por região e um gráfico de barras para a receita mensal. Toda esta criação acontece localmente no seu próprio hardware. Assim que o relatório estiver terminado, o gestor precisa que o resto da equipa o veja. Enviar um ficheiro enorme por email é ineficiente e leva a pesadelos de version control. É aqui que a coisa fica interessante. Em vez de enviar o ficheiro, o gestor publica-o no Power BI service. O Power BI service é o showroom. É uma plataforma Software-as-a-Service baseada na cloud, acedida através de um web browser. Quando o gestor clica em publish na desktop app, é feito o upload do relatório para a cloud. Agora, o resto da equipa de vendas pode fazer login no web service. Eles podem ver os dashboards, filtrar os gráficos e interagir com os dados. Não precisam de instalar o Power BI Desktop, e não precisam de saber como o relatório foi construído. Eles apenas consomem os insights. Há também uma terceira peça para completar o cenário, que são as apps Power BI Mobile. Estas permitem que os utilizadores em telemóveis e tablets acedam com segurança aos mesmos exatos relatórios alojados no cloud service, enquanto estão longe das suas secretárias. O workflow típico move-se numa só direção. Ligas-te aos dados e constróis um relatório no Power BI Desktop. Publicas esse relatório no Power BI service. Depois, tu e a tua equipa veem e interagem com esses relatórios no service ou em mobile. A aplicação desktop é para o criador, e o web service é para o consumidor. Constróis localmente, mas distribuis globalmente. Se quiseres ajudar a apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 2 de 14. Fazes login numa nova plataforma de business intelligence no teu primeiro dia, e a sensação é como entrar no cockpit de um avião. Há dezenas de menus, listas e itens com nomes semelhantes, mas tu só precisas de encontrar as principais métricas da tua equipa sem partir nada. A solução é perceber a arquitetura do Power BI Service. O Power BI Service é o portal web acedido em app.powerbi.com. Quando fazes login, vais parar ao ecrã Home. Esta página funciona como um ponto de partida personalizado, que mostra os teus itens mais usados e acedidos recentemente. Mas, para navegares a sério pelo sistema, usas o painel do lado esquerdo do ecrã. O conceito mais crítico nesse painel de navegação é o workspace. Um workspace é um container. Ele guarda o teu conteúdo. Tens um container pessoal chamado My Workspace, que serve estritamente para os teus rascunhos e experiências privadas. Não o uses para métricas da empresa. Para colaboração, recorres a shared workspaces. Pensa num shared workspace como uma pasta de projeto segura onde uma equipa específica guarda os seus data assets unificados. Dentro de um workspace, vais encontrar vários tipos distintos de itens, e saber como eles se encaixam é a forma de entenderes a plataforma. A base de tudo é o semantic model. Tu não olhas para um semantic model para veres gráficos. É a estrutura de dados subjacente, que contém as tabelas, os relacionamentos e os cálculos. É o motor. Cada número que vês num ecrã está a ser queried a partir de um semantic model. Assente em cima desse motor está a camada visual, que geralmente assume a forma de um report. Aqui está a ideia principal. As pessoas usam constantemente as palavras report e dashboard como se significassem exatamente a mesma coisa. No Power BI, são objetos completamente diferentes, com comportamentos diferentes. Um report é um documento de várias páginas e altamente interativo. Está ligado a exatamente um semantic model. Quando abres um report, podes clicar em gráficos para fazer cross-filter a outros gráficos, usar menus dropdown para fazer slice aos dados, e navegar por diferentes separadores na parte inferior do ecrã. Os reports são construídos para uma exploração profunda e análise detalhada. Um dashboard é sempre uma única página. É um canvas personalizado onde fazes pin de elementos visuais individuais, conhecidos como tiles, retirados de vários reports. Como podes fazer pin de tiles de qualquer lado, um único dashboard pode combinar dados de vários semantic models diferentes numa visão geral de alto nível. Não podes filtrar ou fazer slice de dados diretamente num dashboard. Se clicares numa tile, ela funciona como um atalho, levando-te instantaneamente para o report subjacente onde aquele gráfico específico teve origem. Os dashboards servem para uma monitorização rápida e de relance. Os reports servem para explorar os detalhes. Quando uma equipa termina de construir os seus semantic models, reports e dashboards num workspace, geralmente não convida a empresa toda para esse workspace para dar uma vista de olhos. Em vez disso, empacotam os itens finalizados numa app. No Power BI Service, uma app é uma coleção compilada e read-only de conteúdo do workspace. Quando um novo funcionário precisa de encontrar os key performance indicators da sua divisão, geralmente basta clicar no ícone Apps no painel de navegação esquerdo. As apps oferecem uma estrutura de menu limpa e personalizada, sem expor os ficheiros raw do workspace a edições acidentais. Compreender o ecossistema significa compreender esta hierarquia. Se quiseres saber como uma métrica específica chegou ao teu ecrã, segue a chain de trás para a frente. A app distribui o dashboard, o dashboard extrai os visuais do report, o report visualiza o semantic model, e o semantic model vive num shared workspace. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 3 de 14. O maior erro que os novos utilizadores de Power BI cometem é criar um report crítico na sua conta pessoal, ir de férias e deixar toda a equipa completamente sem acesso aos dados. A solução para isto é perceber como estruturar corretamente os Workspaces e a colaboração. No Power BI, tens dois tipos distintos de ambientes para o teu conteúdo. Primeiro, tens o My Workspace. Esta é a tua sandbox pessoal. Cada utilizador de Power BI recebe um automaticamente. É completamente privado. Usas isto para te ligares a sample data, testar uma nova fórmula ou fazer o draft de um layout antes que qualquer outra pessoa o veja. Não uses o My Workspace para o reporting oficial da empresa. Se criares o dashboard principal de vendas aqui e depois saíres da empresa, a tua equipa vai ter dificuldades em aceder ou atualizar esse conteúdo. A solução é o Workspace standard. Este é um ambiente partilhado onde as equipas colaboram em semantic models, reports e dashboards. Um workspace funciona como um container seguro para um projeto ou departamento específico. Quando crias um workspace, defines exatamente quem pode entrar nesse container e que ações podem executar. Imagina uma equipa financeira a criar um report financeiro do Q3. Precisas de várias pessoas a contribuir para os dados, mas precisas de um controlo rigoroso sobre quem pode alterar os números finais. Garantes isto usando quatro roles distintos no workspace. O primeiro é o role de Admin. O Admin do workspace tem controlo total sobre o ambiente. Pode apagar todo o workspace e decide quem tem acesso. O administrador de sistemas ou o chefe da equipa de dados financeiros assume este role. A seguir, temos o role de Member. Os Members gerem o conteúdo e o fluxo do workspace. Podem adicionar colegas com permissões inferiores, atualizar semantic models e partilhar os itens do workspace. Um analista financeiro sénior que gere o processo de reporting do Q3 precisa deste role. Isto permite-lhe manter o projeto a andar e gerir o acesso da equipa sem precisar de chatear o Admin por cada pequena alteração. Depois, tens o Contributor. Este é o role principal para os criadores de conteúdo. Os Contributors podem criar, editar e apagar reports e dashboards dentro do workspace. Não podem gerir permissões, nem podem adicionar novos utilizadores. Os analistas que criam os gráficos e tabelas para o report do Q3 recebem acesso de Contributor. Eles constroem o conteúdo, mas não controlam os limites de segurança. Finalmente, existe o role de Viewer. Os Viewers podem ver reports, fazer cross-highlight em gráficos e filtrar os dados, mas não podem alterar o conteúdo ou a estrutura subjacente. Atribuis este role aos diretores financeiros que precisam de rever o report do Q3 e interagir com os dados antes de ser lançado para o resto da empresa. Aqui está o ponto-chave. As permissões num workspace aplicam-se a todo o container. Não podes dar a alguém acesso de Contributor a um workspace e impedi-lo de ver um report específico lá dentro. O workspace é um único limite de segurança. Se alguém tiver acesso ao workspace, pode ver todo o conteúdo lá dentro, restrito apenas pelo role específico que lhe atribuíste. A estrutura do workspace obriga-te a tratar o reporting como um processo de equipa resiliente. Ao manteres os drafts pessoais isolados no My Workspace e moveres os projetos de equipa para Workspaces partilhados com roles explícitos, a tua arquitetura de dados mantém-se estável e acessível, independentemente de quem estiver no escritório. Por agora é tudo. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Fundamentos do Power BI, episódio 4 de 14. O segredo para um report incrivelmente rápido e altamente preciso não tem, na verdade, nada a ver com os gráficos no ecrã. Quando os números não batem certo entre departamentos, o problema raramente está na interface visual. Está na arquitetura de dados subjacente. Hoje, vamos olhar para o modelo semântico. Um modelo semântico, que o Power BI antes chamava de dataset, é o cérebro invisível por trás dos teus reports. É um erro comum ver o Power BI apenas como uma ferramenta que puxa uma tabela simples de uma base de dados ou uma folha de Excel e desenha um gráfico por cima. Não é esse o caso. Um modelo semântico é uma rede relacional robusta. Armazena as tabelas, mas também encapsula as relações entre essas tabelas, os metadados de formatação e a business logic predefinida. Fica exatamente entre as tuas fontes de dados brutas e dispersas e os teus reports visuais, atuando como uma middle layer organizada. Podes trazer dados de uma base de dados na cloud, de um ficheiro local e de uma web API, e juntar tudo numa única estrutura coesa. Esta é a parte que importa. Não precisas de todo de um novo modelo para cada report. Um modelo semântico bem desenhado separa a core data logic da apresentação visual. Pensa num cenário em que a tua empresa precisa de um único modelo Customer Truth. A equipa de marketing quer acompanhar a performance das campanhas, enquanto a equipa de vendas precisa de monitorizar o seu pipeline diário. Num sistema mal desenhado, ambas as equipas extraem os seus próprios dados, escrevem as suas próprias business rules e, inevitavelmente, criam versões concorrentes da realidade. Numa arquitetura madura, ambas as equipas ligam os seus reports individuais exatamente ao mesmo modelo semântico. Constróis a lógica complexa apenas uma vez. Esse modelo único Customer Truth pode alimentar com segurança dez reports completamente diferentes em toda a organização. Se a definição de um cliente ativo mudar no próximo ano, atualizas o modelo central. Todos os dez reports herdam a nova regra automaticamente. A forma como este modelo lida realmente com os teus dados depende inteiramente do storage mode que selecionas durante a criação. Os dois principais paradigmas são Import e DirectQuery. O modo Import puxa os dados da tua fonte original, comprime-os e carrega-os diretamente para o motor in-memory do Power BI. Esta é a escolha por defeito para a maioria dos projetos. Como os dados residem inteiramente em memória, cálculos complexos e filtragens interativas acontecem quase instantaneamente. Os teus reports parecem excecionalmente rápidos para o end user. A limitação é que estás a fazer cache de um snapshot dos dados. Tens de agendar refreshes periódicos para puxar os updates, e há limites físicos para a quantidade de dados que podes empurrar para a memória. O DirectQuery adota a abordagem oposta. Nenhum dado bruto é alguma vez importado. O modelo semântico armazena apenas os metadados estruturais, como nomes de tabelas, tipos de colunas e relações. Quando um utilizador clica num filtro no seu report, o modelo traduz esse clique numa live query e envia-a diretamente de volta para a base de dados subjacente. Usas o DirectQuery quando o teu dataset é simplesmente demasiado massivo para importar, ou quando o negócio exige visibilidade quase em tempo real do source system. O trade-off óbvio é a performance. Um report a correr em modo DirectQuery só é tão rápido quanto a base de dados que responde às perguntas, e cada interação coloca um compute load diretamente nos teus source systems. Os visuais no teu workspace são apenas janelas leves a olhar para os dados. O modelo semântico guarda a verdade, e acertar no modelo significa que os reports praticamente se constroem sozinhos. Obrigado por passares uns minutos comigo. Até à próxima, e fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 5 de 14. O teu dashboard pode ser lindo, mas é completamente inútil se os números tiverem uma semana. O verdadeiro desafio é levar dados frescos para a cloud quando a tua base de dados real está trancada atrás de uma firewall corporativa rigorosa. Resolver essa tensão é exatamente o que os Data Connectors e a On-Premises Data Gateway fazem. O Power BI é um recipiente vazio até o alimentares com informação. Para puxar essa informação, usas data connectors. A Microsoft fornece centenas deles out of the box para praticamente qualquer sistema que possas imaginar. Pensa num connector como um tradutor especializado e pré-construído. Quer os teus dados vivam numa base de dados Oracle, num warehouse Snowflake ou num serviço cloud como o Salesforce, o connector trata do trabalho pesado. Ele gere as API calls específicas, os métodos de autenticação e as estruturas de query nativas necessárias para falar com esse sistema de destino. Tu só tens de fornecer as credenciais e selecionar as tabelas que queres. O connector traduz o teu request para a linguagem exata que o sistema de origem entende, o que significa que nunca tens de escrever scripts de extração custom. Quando a tua data source já está na cloud, este processo é fluido. O Power BI vai à internet, autentica-se e puxa os dados. Mas a realidade para muitas organizações é muito mais complicada. O que acontece quando os teus dados vivem num servidor físico na cave do teu escritório? Não podes simplesmente pedir ao Power BI na cloud para aceder à tua rede local privada. Fazer isso exigiria que a tua equipa de IT abrisse inbound ports na firewall, expondo a tua base de dados interna à internet pública. Aqui está a ideia chave. Não precisas de expor a tua rede interna ao mundo exterior para deixar o Power BI ler os teus dados. Em vez disso, usas uma On-Premises Data Gateway. A gateway é um pequeno pedaço de software que instalas numa máquina dentro da tua rede local. Fica atrás da tua firewall, perto das tuas data sources internas. Atua como uma ponte outbound segura. Em vez de o Power BI forçar a entrada na tua rede, a comunicação acontece de forma inteiramente inversa. A gateway verifica constantemente uma queue segura na cloud usando uma ligação de internet outbound standard. Simplesmente pergunta à cloud se há requests de dados pendentes. Como a ligação é iniciada de dentro da tua rede para fora, as firewalls standard deixam passar o tráfego sem qualquer configuração especial. Vamos ver um cenário prático. Tens um report de vendas de segunda-feira de manhã que tem de fazer refresh automático às seis da manhã. A raw data de vendas vive naquele servidor com firewall na cave. Às seis em ponto, o serviço cloud do Power BI regista um request de refresh agendado. Momentos depois, a tua gateway local faz poll à queue na cloud e apanha este request. A gateway faz download das instruções da query, liga-se diretamente à tua base de dados local usando as tuas credenciais da rede interna, e executa a query localmente. Assim que o servidor da cave termina de processar o request, devolve a raw data ao software da gateway. A gateway comprime e encripta estes dados, e depois faz push para o serviço cloud do Power BI. A cloud recebe o pacote encriptado, desencripta-o e atualiza o teu dashboard de vendas. Ao usar este método de outbound polling, a gateway dá-te todo o poder analítico da cloud sem exigir que movas a tua base de dados real para fora da cave. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui fala o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 6 de 14. Se um stakeholder precisar de mais de cinco segundos para perceber o que o teu dashboard lhe está a dizer, perdeste a sua atenção. Colocar dez gráficos circulares sem relação entre si num único ecrã não é análise, é apenas ruído visual. Criar uma data story guiada requer um design deliberado, e isso leva-nos à Arte do Report Canvas. Um report de Power BI é uma visão multiperspetiva do teu semantic model subjacente. O report canvas é o workspace em branco onde constróis essa visão. Não se limita a um único ecrã. Podes adicionar várias páginas a um report, tal como numa apresentação. Isto permite-te dividir questões de negócio complexas numa sequência lógica, dedicando páginas diferentes a diferentes aspetos dos dados. Tu preenches o canvas com visuals. Estes são os teus gráficos, tabelas e mapas. Escolher o visual certo é apenas o primeiro passo. O layout dita como o teu utilizador lê a informação. Um canvas bem desenhado guia o olhar naturalmente desde as métricas de topo até aos detalhes mais granulares. Para gerir layouts complexos, usas o grouping. O grouping permite-te juntar vários visuals, shapes e text boxes. Quando agrupas itens, eles escalam e movem-se como uma única unidade. Isto mantém o teu layout preciso e evita que gráficos cuidadosamente alinhados saiam do sítio quando ajustas a página. Para manter um aspeto profissional em todas essas páginas, usas themes. Um theme é um conjunto de cores, fonts e regras de formatação predefinidas. Aplicas um theme ao report, e cada visual atualiza-se instantaneamente para corresponder. Isto força a consistência e evita que tenhas de digitar manualmente códigos de cores em dezenas de gráficos separados. Aqui está o insight principal. O verdadeiro poder do canvas não está no aspeto dos visuals, mas sim em como eles se comportam. Em muitas ferramentas de reporting, os gráficos são imagens isoladas. No Power BI, os visuals na mesma página estão profundamente ligados por default. Eles fazem cross-filter entre si naturalmente, com base nos relacionamentos do teu semantic model. Pensa num report de performance regional. Colocas um gráfico de barras a mostrar as vendas por categoria de produto à esquerda, e um mapa geográfico a mostrar a localização das lojas à direita. Se um utilizador clicar na barra da categoria de eletrónica, a página inteira reage. O mapa destaca instantaneamente as regiões específicas que venderam eletrónica, desvanecendo o resto do mapa. O utilizador não pesquisou nada, e tu não escreveste nenhuma routing logic para fazer a interação acontecer. O canvas sabe que estes visuals partilham os mesmos dados subjacentes, por isso, tocar num deles altera automaticamente o contexto dos outros. Este comportamento transforma uma página estática numa ferramenta de exploração interativa. A arte do report canvas é aprender a não interferir. Ao combinar layouts limpos, themes consistentes e cross-filtering nativo, permites que o utilizador faça as suas próprias perguntas simplesmente ao clicar nos dados à sua frente. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Power BI Fundamentals, episódio 7 de 14. Os melhores relatórios não apresentam apenas números; permitem que o utilizador final converse com os dados. Se construíres um dashboard estático que obriga cada stakeholder a olhar exatamente para os mesmos totais agregados, os teus utilizadores vão acabar por exportar esses números para uma folha de cálculo para encontrarem o que realmente lhes interessa. Evitas isso ao tornares os dados interativos. Existem duas formas principais de passar o controlo dos dados para os teus utilizadores no Power BI. As pessoas costumam usar a terminologia de forma intercambiável porque ambos os métodos atingem um resultado final semelhante, mas a user experience é fundamentalmente diferente. Estamos a falar de slicers e do Filters pane. Um slicer é um tipo de visual que largas diretamente no canvas do teu relatório. Fica ali mesmo ao lado dos teus gráficos de barras e gráficos de linhas. Por ser um visual on-page, tem muito destaque. Usas um slicer quando queres convidar explicitamente o utilizador a alterar a view. Pensa num relatório nacional de vendas. Um gestor regional abre-o, mas na verdade só quer olhar para o seu próprio território. Se adicionares um slicer ao canvas e o configurares como um simples dropdown, esse gestor pode selecionar a sua região específica. No momento em que faz essa seleção, todos os outros visuais na página atualizam imediatamente para refletir apenas essa região. Os slicers dão poder ao utilizador para fazer drill down exatamente para o que lhe interessa naquele momento. Podes formatá-los como listas, dropdowns, ou até mesmo sliders de intervalo de datas, mas o seu propósito principal é sempre a interação imediata e visível. Agora, a segunda parte disto é o Filters pane. Ao contrário de um slicer, um filtro não é colocado no próprio canvas. Vive num painel lateral dedicado, anexado à borda da janela do relatório. O Filters pane é onde controlas o scope subjacente dos teus dados. Opera a múltiplos níveis. Podes arrastar um campo de dados para o painel para filtrar apenas um gráfico específico, uma página inteira, ou de forma uniforme em todas as páginas do teu relatório. Aqui está o insight principal. A maior diferença entre um slicer e um filtro é a visibilidade e o controlo. Os slicers estão sempre visíveis para o utilizador. Os filtros não têm de estar. Como criador do relatório, podes fazer lock a um filtro para que o utilizador não o consiga alterar, ou podes escondê-lo completamente. Se quiseres construir uma versão do teu relatório que mostre sempre apenas dados do ano fiscal atual, aplicarias um page-level filter oculto para o ano. O utilizador final nunca vê um botão ou um dropdown. Simplesmente interage com um relatório que está delimitado de forma segura ao período de tempo certo. Vais usar frequentemente ambas as ferramentas exatamente na mesma página. Estabeleces as regras de base dos teus dados usando o Filters pane, desenhando efetivamente uma caixa à volta daquilo que o utilizador tem permissão para ver. Depois, colocas alguns slicers estratégicos dentro do canvas para que o utilizador possa explorar livremente dentro dessa caixa. Esta abordagem mantém o teu canvas limpo. Se tentasses transformar todas as variáveis possíveis num slicer, o teu relatório ficaria ilegível. O Filters pane oculta as configurações secundárias, mantendo as escolhas mais críticas no centro das atenções. Dá aos teus utilizadores slicers no canvas para as perguntas que precisam de fazer todos os dias, e usa os filtros do painel lateral para impor as regras que eles nunca devem quebrar. É tudo por este episódio. Obrigado por ouvires, e keep building!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 8 de 14. A parte mais difícil do design de reports é a tensão entre clareza e profundidade. Tu queres uma página principal com um aspeto limpo e que conte instantaneamente a história de alto nível, mas os teus power users exigem cada data point granular. Se puseres tudo numa só página, ela torna-se ilegível. A forma de resolver isto é esconder a complexidade a apenas uma interação de distância, usando deep dives contextuais. Primeiro, considera as tooltips personalizadas de páginas de report. Por default, quando um utilizador faz hover sobre um data point num visual, o Power BI mostra uma caixa de texto simples com o valor exato desse ponto. Isso dá-te um número, mas não te dá contexto. Uma tooltip de página de report permite-te substituir essa caixa default por um canvas totalmente personalizado. Constróis uma pequena página de report escondida e configura-la para aparecer quando um utilizador faz hover sobre um visual. Em vez de um número simples, podes mostrar uma pequena linha de tendência ou um gauge chart logo dentro da janela de hover. Pega num visual de mapa que mostre o total de vendas por cidade. Quando um utilizador faz hover com o cursor sobre a bolha de dados de Seattle, aparece uma tooltip personalizada. Dentro desse pop-up está um bar chart em miniatura a detalhar as vendas de Seattle nos últimos doze meses. O utilizador absorve esta camada extra de informação instantaneamente, e nunca sai da página principal do mapa. Às vezes, um hover rápido não é suficiente. Quando um utilizador precisa de fazer uma auditoria completa a um data point específico, usas uma página de drillthrough. O drillthrough é construído para investigação profunda. Crias uma página de report detalhada e completamente separada, e atribuis-lhe um campo específico, como uma localização geográfica ou uma categoria de produto. Isto diz ao Power BI que esta página é um destino para ações de drillthrough. Volta a esse mesmo mapa. O utilizador faz hover sobre Seattle, vê a tendência mensal, mas decide que os números exigem um olhar mais atento. Clica com o botão direito do rato na bolha de Seattle e seleciona drillthrough. O Power BI tira-o do mapa e leva-o para a tua página de detalhes. Crucialmente, passa a sua seleção. A nova página é filtrada automaticamente para mostrar apenas dados de Seattle. Agora, está a olhar para uma tabela abrangente de transações brutas de faturas. É fácil esbater as linhas entre estas duas features. As tooltips são hover-boxes personalizadas que mostram mini-visuais sem sair da página atual. São feitas para um olhar rápido. O drillthrough leva o utilizador para uma página de detalhes inteiramente nova, filtrada precisamente para a sua seleção. Requer um clique explícito e é feito para análise pesada. Aqui está o insight principal. Não precisas de enfiar tabelas de transações densas ao lado dos teus resumos executivos de alto nível. Usa as tooltips para responder à pergunta de follow-up imediata, e confia nas páginas de drillthrough para lidar com as auditorias pesadas. O teu dashboard principal mantém-se rápido e limpo, enquanto os teus utilizadores continuam a aceder exatamente aos dados de que precisam. Se quiseres ajudar a apoiar o show, podes procurar por DevStoriesEU no Patreon — isso ajuda-nos genuinamente. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 9 de 14. Só consegues ir até certo ponto ao arrastar e largar campos num canvas. Mais cedo ou mais tarde, precisas que o teu relatório responda a perguntas complexas que não estão explicitamente escritas na tua base de dados. É aí que entram as Data Analysis Expressions, ou DAX. É tentador pensar no DAX apenas como fórmulas avançadas de Excel. Parecem semelhantes, e muitos nomes de funções são idênticos. Mas o Excel opera numa grelha de células individuais e estáticas. O DAX opera inteiramente sobre colunas e tabelas inteiras. Nunca apontas o DAX para a linha três, coluna C. Apontas para a coluna do valor de vendas e deixas o engine descobrir o resto. Para desmistificar o DAX, só precisas de dominar dois conceitos estruturais principais. São eles as calculated columns e as measures. Uma calculated column é avaliada linha a linha. Se precisares de uma coluna que multiplique o preço unitário pela quantidade vendida para cada transação individual, usas uma calculated column. O engine calcula o resultado uma vez quando os dados são carregados ou atualizados, e guarda-o em memória. Torna-se uma parte física do teu dataset, o que a torna útil para categorizar dados ou construir eixos num gráfico. Aqui está o ponto chave. As calculated columns são estáticas. Não mudam quando o utilizador interage com o teu dashboard. As measures, por outro lado, são totalmente dinâmicas. Uma measure não calcula linha a linha, e não guarda valores pré-computados em memória. Em vez disso, calcula um aggregate on the fly, guiado por algo chamado filter context. O filter context significa simplesmente a combinação de filtros atualmente ativos no teu relatório num determinado momento. Esta é a parte que interessa. Quando um utilizador clica num ano específico numa timeline, ou seleciona uma região específica num drop-down, está a alterar o filter context. A measure DAX ouve esses cliques, restringe as tabelas subjacentes em memória para corresponder à seleção, e recalcula instantaneamente a resposta final. Considera um cenário em que escreves uma única measure DAX para o crescimento Year over Year. Por ser uma measure, não fica presa a uma view específica. Se o teu utilizador olhar para um summary card de alto nível, essa mesma measure calcula o crescimento global para toda a empresa. Se clicar na região europeia num mapa, a measure recalcula instantaneamente para mostrar apenas o crescimento europeu. Se fizer um slice ainda mais específico por uma linha de produtos em novembro, a mesma measure devolve o crescimento apenas para esse produto nesse mês. Escreves a matemática subjacente uma vez, e o filter context faz o trabalho pesado de a aplicar ao que o utilizador quiser ver. As calculated columns constroem a estrutura pela qual fazes slice. As measures executam a matemática dinamicamente com base nesses slices. Compreender esta distinção evita bottlenecks de performance massivos, como tentar forçar um cálculo de linha pesado em memória a fazer o trabalho de um aggregate dinâmico. O verdadeiro poder do DAX não está em memorizar centenas de funções distintas, mas em compreender que cada cálculo acontece dentro de um limite invisível e em constante mudança, definido pelo utilizador. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 10 de 14. Os executivos não têm tempo para clicar em cinco documentos diferentes com várias páginas só para descobrir se a empresa está saudável. Eles querem o resultado final, num único ecrã, agora mesmo. A funcionalidade criada especificamente para resolver este problema é o dashboard de Power BI. As pessoas costumam usar as palavras report e dashboard como sinónimos. No ecossistema de Power BI, tens de os tratar como conceitos totalmente diferentes. Um report é uma ferramenta interativa com várias páginas, desenhada para análises aprofundadas, e está quase sempre ligado a um único dataset subjacente. Um dashboard é estritamente um canvas de página única. É um resumo executivo. Além disso, não crias dashboards no Power BI Desktop. São um artefacto exclusivo do Power BI service. Crias os teus reports primeiro, fazes publish, e depois constróis o dashboard inteiramente no browser. Imagina um CEO que quer verificar três métricas específicas no seu telemóvel todas as manhãs. Ele precisa de ver a receita diária, o uptime do servidor e o score atual de satisfação do cliente. Estas métricas originam-se naturalmente de áreas completamente desconectadas da empresa. A métrica de receita reside num report financeiro complexo. O uptime do servidor é monitorizado num report dedicado de infraestrutura de TI. O score de satisfação está na página três de um report de marketing. Não consegues fundir facilmente estes três datasets distintos num único report standard. Em vez disso, crias um dashboard usando um mecanismo chamado pinning. Navegas até ao report financeiro publicado no teu browser, selecionas o card visual de receita total e fazes pin para um novo dashboard. A seguir, abres o report de TI, pegas no gauge de uptime do servidor e fazes pin para o mesmo dashboard. Finalmente, fazes o mesmo para o score de satisfação no report de marketing. Uma vez feito o pin para o canvas do dashboard, estes visuais individuais são conhecidos como tiles. O teu dashboard de página única é agora uma coleção curada de tiles a extrair dados em tempo real de vários reports diferentes, o que significa que está a ligar vários datasets subjacentes diferentes. Esta agregação cross-report é a razão exata pela qual os dashboards existem. Eles quebram as fronteiras dos datasets individuais para criar uma visão unificada. Quando um executivo abre este dashboard, recebe um status update imediato, num relance. Não interage com os dados aqui da mesma forma que faria num report. Em vez disso, as tiles funcionam como entry points. Se a tile de receita diária mostrar uma queda repentina, o executivo simplesmente clica nessa tile específica. Essa ação tira imediatamente o utilizador do dashboard e leva-o diretamente para o report financeiro subjacente de onde esse visual teve origem. Aqui está o insight principal. O dashboard não é um substituto para a tua camada de reporting detalhada. É uma camada de curadoria que fica por cima. Um dashboard bem desenhado não tenta responder a todas as perguntas analíticas possíveis; simplesmente aponta o utilizador para o report subjacente exato que contém as respostas de que precisa agora mesmo. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 11 de 14. Se estás a partilhar um workspace com quinhentas pessoas que só precisam de ver dados, estás a cometer um erro. Estás a mostrar-lhes a desarrumação da cozinha quando elas só vieram para uma refeição. A forma certa de entregar conteúdo finalizado é empacotar a experiência, e isso significa usar uma App de Power BI. Uma App de Power BI não é um programa de software standalone que descarregas de uma loja de telemóveis. Neste contexto, uma App é uma coleção agrupada de dashboards e reports apresentada como um pacote único e unificado. É o método oficial de distribuição do teu conteúdo finalizado de Power BI. Vamos esclarecer a principal confusão logo à partida, que é a diferença entre um workspace e uma App. Um workspace é a tua cozinha. É onde os criadores de reports se ligam aos dados, constroem modelos e testam diferentes layouts de gráficos. É uma área colaborativa destinada a quem constrói, e pode ficar desorganizada com rascunhos de reports e datasets brutos. A App é a sala de jantar. É limpa, organizada e desenhada estritamente para consumo. Quando publicas uma App, estás a tirar os pratos prontos da cozinha e a apresentá-los aos teus convidados. Pensa em lançar as Métricas Oficiais da Empresa de 2026 para quinhentos colaboradores de diferentes departamentos. Não queres que eles andem à procura num workspace para descobrir qual é a versão final do report. Também não lhes queres enviar cinco web links diferentes. Em vez disso, crias uma App. Quando constróis uma App, selecionas exatamente quais os dashboards e reports do teu workspace a incluir. Deixas os rascunhos para trás. Depois, desenhas um menu de navegação personalizado. É aqui que a coisa fica interessante. Em vez de uma lista plana de ficheiros, podes agrupar reports relacionados debaixo de cabeçalhos colapsáveis. Podes ordenar as páginas para que a história flua logicamente, desde resumos de alto nível até detalhes granulares. Podes até aplicar uma cor de tema específica e adicionar o logótipo da tua empresa. Para o end-user, a experiência é fluida. Eles instalam a App uma vez a partir do diretório da organização. Quando a abrem, têm uma interface com a marca, em modo read-only. Não há botões de edição para os distrair. Eles não conseguem apagar acidentalmente um visual ou alterar o dataset. Eles simplesmente usam o menu lateral para navegar pelos reports. Se abrirem a aplicação mobile do Power BI, a App e a sua estrutura de navegação personalizada também funcionam perfeitamente lá. Aqui está o insight principal para manter este conteúdo. Como o workspace e a App estão separados, podes atualizar os reports sem quebrar a user experience. Se uma métrica precisar de um ajuste, fazes essa alteração na cozinha do workspace. Os teus quinhentos users não veem os teus visuals partidos ou gráficos a meio enquanto trabalhas. A App deles fica exatamente igual até estares totalmente pronto. Assim que terminares, clicas em update na App, e a nova versão fica live para todos ao mesmo tempo. Quando precisares de entregar um conjunto de reports coeso e fácil de navegar a um grande público, constrói o workspace para os teus autores, mas empacota a App para os teus consumidores. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 12 de 14. A maneira mais rápida de garantires que ninguém olha para o teu dashboard é obrigá-los a abrir um novo separador no browser, encontrar um bookmark e fazer login num portal separado. O context switching mata a adoção. Se queres que as pessoas usem os dados, tens de os colocar exatamente onde elas já estão a falar. Essa é a ideia central por trás de ir ter com os utilizadores onde eles trabalham. Para a maioria das organizações, esse lugar é o Microsoft Teams. O Power BI integra-se profundamente no Teams para remover a fricção do context switching. Em vez de enviares um link para um dashboard num chat, trazes o dashboard para o workspace. Imagina uma equipa de armazém que precisa de verificar os níveis de stock todas as manhãs. Podes fixar um report de inventário live diretamente como um separador no seu canal dedicado do Teams. Eles clicam no separador, e os dados estão simplesmente lá, mesmo ao lado das suas mensagens matinais. Há um mal-entendido frequente sobre como isto funciona. Fazer push de um report para o Teams não envia apenas um screenshot estático ou um PDF desligado. Faz embed do report completo, live e interativo do Power BI de forma segura dentro do cliente Teams. Os utilizadores podem fazer slice, filter e drill down nos dados dentro do canal. As permissões de segurança continuam a ser estritamente aplicadas. Se um utilizador não tiver permissão para ver os dados no serviço do Power BI, também não os consegue ver no Teams. Também podes iniciar uma thread de conversação diretamente ligada a um visual específico do report, mantendo a discussão e os dados exatamente no mesmo contexto. Isto cobre a comunicação diária. Agora, considera as reuniões de executivos. As apresentações são tipicamente onde os dados vão para morrer. Alguém tira um screenshot de um gráfico, cola-o num slide e, cinco minutos depois, a base de dados subjacente atualiza-se. O slide fica instantaneamente desatualizado. O Power BI resolve isto ao permitir-te fazer embed de páginas de reports live diretamente nos slides do PowerPoint. Quando abres a apresentação, o gráfico vai buscar os números mais recentes. Aqui está o insight principal. Como o report com embed é completamente interativo, muda a forma como as reuniões decorrem. Quando um stakeholder faz uma pergunta específica sobre um pico nas vendas, não tens de a anotar e prometer fazer follow-up mais tarde. Podes clicar nesse data point diretamente no slide da apresentação, fazer cross-filter aos visuais, e responder à pergunta live. Finalmente, temos o Excel. Nunca vais conseguir impedir os business users de quererem dados numa folha de cálculo. Em vez de lutares contra este comportamento e veres as pessoas a exportar ficheiros CSV estáticos e sem controlo, podes integrar o Power BI perfeitamente com o Excel. Os utilizadores podem ligar PivotTables, gráficos e fórmulas standard do Excel diretamente a um dataset publicado do Power BI. Os dados mantêm-se geridos centralmente, seguros e precisos no servidor. Entretanto, os utilizadores podem analisar essa single source of truth usando a interface de grid que já conhecem. Não constróis uma cultura data-driven ao forçar toda a gente a aprender uma nova aplicação standalone. Fazes isso ao injetar dados live e fiáveis diretamente nas ferramentas de comunicação que eles já abrem todas as manhãs. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 13 de 14. Provavelmente estás a perder demasiado tempo a fazer refresh aos dashboards só para verificar se tudo está a correr bem. Os teus utilizadores fazem exatamente a mesma coisa, a fazer login todas as manhãs apenas para confirmar se os números estão normais. Para de depender de humanos para verificar problemas de rotina. Deixa que os dados te digam quando algo corre mal. Essa é a ideia central por trás do BI proativo, alcançado através da combinação de data alerts do Power BI com o Power Automate. Tradicionalmente, o business intelligence é reativo. Crias um report, publicas e esperas que alguém o abra. O BI proativo inverte este modelo. O sistema monitoriza-se a si próprio e faz push de informação para ti apenas quando a tua atenção é realmente necessária. Quando uma métrica específica ultrapassa um threshold predefinido, o sistema age imediatamente. Antes de configurar isto, precisamos de esclarecer um mal-entendido comum. Não podes associar estes alertas automáticos a um visual qualquer, perdido no meio de uma página complexa de um report. Os data alerts no Power BI estão estritamente ligados a tipos de visuais específicos num dashboard. Só os podes configurar em tiles de valor único, especificamente gauges, KPIs e cards. Se tiveres uma métrica crítica que queiras monitorizar num report detalhado, primeiro tens de fazer pin desse visual específico a um dashboard para desbloquear a funcionalidade de alertas. Vamos analisar um cenário concreto. Imagina que acompanhas as vendas diárias de uma grande loja de retalho. A expectativa base é de dez mil dólares por dia. Se as vendas caírem abaixo desse valor, esperar que um gestor verifique o dashboard na sexta-feira é tarde demais. Precisas de uma resposta imediata. Primeiro, configuras um data alert no card do dashboard que mostra as vendas diárias. Defines uma regra a dizer ao Power BI para disparar um alerta se o valor cair abaixo dos dez mil. Presta atenção a esta parte. O Power BI não monitoriza a base de dados de origem em tempo real. Em vez disso, sempre que o dataset subjacente do Power BI faz refresh, o sistema avalia o novo número nesse card. Se a condição for cumprida, o alerta dispara. Por defeito, um alerta disparado gera simplesmente uma notificação dentro do serviço do Power BI ou envia um email básico à pessoa que criou a regra. Para tornar isto realmente útil em toda a empresa, integras com o Power Automate. O Power Automate fica silenciosamente à escuta desse data alert específico do Power BI. Quando o alerta dispara, o Power BI passa um payload de dados para o Power Automate. Este payload contém o título do alerta, o threshold que definiste e o valor real que quebrou a regra. Usas estes valores dinâmicos para construir um workflow downstream. Podes configurar o flow para que, no momento em que a métrica de vendas cai, duas coisas aconteçam automaticamente. Primeiro, o flow extrai o valor real das vendas e faz push de uma notificação imediata diretamente para o telemóvel do gestor da loja. Segundo, envia um email automático para a equipa regional com os números exatos e um link direto de volta para o dashboard para investigação adicional. Ninguém teve de abrir o Power BI manualmente para descobrir o problema. Ao integrar os alertas do dashboard com automação downstream, removes o bottleneck humano da resposta a incidentes. O verdadeiro valor de um sistema de monitorização não se mede por quantas pessoas olham para ele todos os dias, mas pela rapidez com que força uma ação no momento em que um limite crítico é ultrapassado. Por agora é tudo. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Power BI, episódio 14 de 14. Estás a olhar para uma tela em branco, a precisar de um relatório de vendas completo até ao fim do dia. Em vez de passares horas a fazer drag and drop de campos, simplesmente fazes uma pergunta em plain text, e o layout constrói-se sozinho. O futuro do business intelligence é conversacional, impulsionado pelo Copilot no Power BI. Existe um receio persistente de que a inteligência artificial está aqui para substituir o data analyst. Não é o caso. O Copilot é um assistente poderoso desenhado especificamente para acelerar o teu primeiro rascunho. Ele trata do setup inicial aborrecido, libertando-te para te focares em refinar os insights reais. Ele faz a ponte entre os dados brutos e um relatório finalizado usando linguagem natural, tornando a fase inicial de criação muito mais rápida. Quando abres o report builder, podes interagir diretamente com o painel do Copilot. Digitas um prompt, como pedir para criar um resumo do desempenho de vendas. O Copilot analisa imediatamente o teu modelo semântico subjacente. Ele determina quais as métricas que importam com base no teu pedido, seleciona os tipos de visuais apropriados e gera automaticamente uma página de relatório completa. Não precisas de colocar gráficos de barras manualmente nem de configurar eixos para começar. Declaras a tua intenção, e o sistema traduz essa intenção num layout concreto. Isto muda fundamentalmente a forma como abordas a criação de relatórios, passando da construção manual para uma orientação de alto nível. Aqui está o insight principal. O Copilot não constrói apenas gráficos; ele escreve a história dos teus dados. Juntamente com os visuais, ele gera uma caixa de texto narrativa que resume os principais drivers e tendências em linguagem simples. Isto não é texto estático. Como está ligado diretamente ao modelo semântico, a narrativa é totalmente dinâmica. Se os dados subjacentes mudarem durante a noite, ou se um utilizador clicar numa região específica num visual de mapa, o texto reescreve-se instantaneamente para refletir esse novo contexto. O resumo fica sempre sincronizado com a vista atual dos dados, sem exigir quaisquer atualizações manuais. Esta interface conversacional reduz drasticamente a barreira de entrada para gerar insights. Não precisas de conhecimento técnico profundo da ferramenta para extrair valor dos dados. No entanto, manténs o controlo absoluto. Assim que a IA gera esse layout e narrativa iniciais, tu voltas a intervir. Podes redimensionar os visuais, ajustar a formatação ou modificar a narrativa para se adequar às tuas especificações exatas. É um workflow colaborativo. O Copilot constrói a base pesada, e tu aplicas os retoques finais para garantir que o produto final cumpre os padrões da tua organização. O verdadeiro poder da linguagem natural no business intelligence não é apenas poupar alguns cliques do rato; é sobre remover completamente a fricção entre ter uma pergunta de negócio e ver a resposta no ecrã. Como este é o episódio final da nossa série de fundamentos, recomendo vivamente que explores a documentação oficial da Microsoft e experimentes estas features hands-on com os teus próprios modelos semânticos. Se tiveres ideias sobre o que devemos abordar a seguir, visita devstories dot eu para sugerir tópicos para séries futuras. É tudo por este episódio. Obrigado por ouvires, e continua a construir!