Boas Práticas em Dashboards, Power BI, Tableau e SQL

Boas Práticas em Dashboards e Tableau (Viz)

Aproveitando o ponto mais visualizado (hot spot)

A maioria dos usuários analisa o dashboard começando pelo canto superior esquerdo da página.

Eu sempre posiciono a visualização mais importante no canto superior esquerdo.

Outro aspecto importante é a capacidade de controlar o fluxo do usuário em um dashboard.

O usuário não deve sentir que está "preso" ao usar o dashboard.

Você pode criar drill down, permitindo que o usuário expanda os dados, e criar um botão de início para retornar à página inicial, entre outros recursos.

Gosto de conhecer meu público. Escolho as visualizações corretas, utilizo filtros e interatividade, defino objetivos claros e mantenho um design consistente. Design claro e intuitivo.

Use cores estrategicamente.

Forneça contexto: inclua títulos, descrições e anotações para ajudar o usuário a entender os dados e suas implicações.

Clareza e propósito: as visualizações devem responder a uma pergunta de negócio.

Levantamento de Requisitos com Stakeholders de Negócio

1️⃣ Entenda o contexto de negócio

Ao levantar requisitos com stakeholders de negócio, começo entendendo o contexto de negócio: qual problema eles querem resolver e quais decisões desejam tomar.

2️⃣ Identifique os principais stakeholders e objetivos

Reúno-me com os principais stakeholders para discutir seus objetivos, KPIs e os pontos de dor do processo ou relatório atual.

3️⃣ Faça as perguntas certas e valide os requisitos

Utilizo perguntas abertas, como "Quais decisões você precisa tomar a partir deste dashboard?" ou "Quais métricas melhor representam o sucesso para você?". Isso ajuda a descobrir não apenas o que eles querem ver, mas por que precisam disso.

4️⃣ Documente e confirme o alinhamento

Por fim, valido os requisitos compartilhando um resumo ou protótipo e confirmando que capturei corretamente suas expectativas antes do início do desenvolvimento.

Mantenha ciclos contínuos de feedback durante a entrega...

Integração de Dados

(Origem) API, SAP, CRM etc. > Data Factory > Data Lake > Synapse/Databricks > Power BI

(Origem) API, SAP, CRM etc. > Fivetran > DW (BigQuery, Snowflake) > DBT (Transformação) > Power BI/Tableau (Airflow por fora coordenando tudo)

Antigamente, quando tudo era on-premises, salvávamos no SQL relacional local e usávamos Pentaho ou Talend. Hoje, tudo está em nuvem, então as ferramentas mudaram.

Power BI

Coluna calculada vs Medida

Coluna: calculada no refresh e armazenada
Medida: calculada em tempo de execução, depende dos filtros

O que é Gateway?

Permite atualizar dados on-premises no Power BI Service.

O que é RLS (Row-Level Security)?

Controle de acesso aos dados por usuário usando filtros DAX.

SUM vs SUMX (Iterative DAX)

SUM: soma direta
SUMX: soma com lógica linha a linha

CALCULATE

É a função mais importante do DAX, pois modifica o contexto de filtro em que uma expressão é avaliada. Ela permite adicionar filtros, remover filtros ou alterar o contexto atual.

Import vs DirectQuery vs Live Connection

Import: mais rápido, dados na memória
DirectQuery: consulta na fonte, mais lento
Live: usa modelo externo (SSAS/Fabric)

Boas práticas

Star schema, baixa cardinalidade, documentação, naming padrão, usar apenas visuais validados pela Microsoft.

Como tornar o relatório mais dinâmico?

Usando bookmarks, ações e slicers

Query Folding

É uma técnica de otimização no Power BI que traduz as etapas de transformação do Power Query (linguagem M) em uma única consulta nativa (como SQL) e a executa diretamente na fonte de dados.

Append x Merge

Join = Merge | Append = Union

Many-to-Many

Ocorre quando não há unicidade em nenhuma das tabelas relacionadas.

Para resolver: use uma tabela ponte (bridge table) ou um modelo com granularidade correta.

Por que evitar relacionamento bidirecional

Resposta ideal:

Relacionamentos bidirecionais podem causar: ambiguidade de filtros, problemas de performance e resultados incorretos.

SQL

Inner x Left Join

Inner retorna somente o que corresponde nas duas tabelas; Left retorna tudo e coloca NULL no que não corresponder.

WHERE x HAVING

WHERE: filtra antes da agregação (linhas individuais).
HAVING: filtra depois da agregação (grupos).

CTE

Melhora a legibilidade: transforma subconsultas aninhadas e difíceis de ler em blocos lógicos estruturados.
Reutilização de código: permite referenciar o mesmo conjunto de dados várias vezes na mesma consulta, evitando a repetição de lógica.

UNION x UNION ALL

UNION: elimina duplicatas.
UNION ALL: mantém duplicatas.

Window Function

Window functions em SQL realizam cálculos analíticos sobre um grupo de linhas relacionadas à linha atual (uma "janela"), sem colapsar o resultado em uma única linha, ao contrário do GROUP BY.

Subquery x Join

JOIN → geralmente melhor para performance e leitura.

Subquery → útil para lógica isolada ou filtros.

Normalização

Organiza os dados para evitar redundância.

Ex.: separar cliente e pedido.

Otimizar performance SQL: "Como você otimiza uma query?"

Usar índices, evitar SELECT *, evitar funções em colunas filtradas e filtrar cedo (WHERE).

PK x FK

PRIMARY KEY → única, não nula

FOREIGN KEY → relacionamento entre tabelas

Performance no Tableau e Power BI (boas práticas para evitar relatórios lentos)

Power BI

Modelo: uso star schema, reduzo cardinalidade e removo colunas desnecessárias.

DAX: evito iteradores pesados, uso variáveis e simplifico cálculos.

Visual: reduzo o número de visuais, evito tabelas grandes e uso agregações.

👉 Sempre analiso com Performance Analyzer e DAX Studio.

Tableau

- Use data extracts | Incremental refresh only.

- Reduce the number of fields e reduce the scope of data para diminuir o número de campos de dados.

- Delete unused worksheets e unnecessary calculated fields.

- Use context filters.