1.1 A definição prática

Business Intelligence é o conjunto de processos e ferramentas que transformam dados operacionais em informação organizada, confiável e acessível para apoiar decisões recorrentes do negócio. A palavra-chave é recorrente: BI serve as perguntas que se repetem toda semana ("como estão as vendas por região?", "qual a taxa de churn deste mês?") com um número em que todos confiam.

Os três se alimentam: um dashboard de BI levanta uma pergunta → análise ad-hoc investiga → vira um modelo de DS → cujo resultado volta a um dashboard de BI. Boa parte do trabalho de BI corporativo é, na verdade, a fronteira entre BI e analytics engineering (modelagem e métricas).

1.2 O stack de uma solução de BI

  FONTES            INTEGRAÇÃO         MODELO             SEMÂNTICA          APRESENTAÇÃO      DISTRIBUIÇÃO
  ┌───────────┐    ┌────────────┐    ┌────────────┐    ┌─────────────┐    ┌────────────┐   ┌──────────────┐
  ERP, CRM     ──▶  ETL/ELT      ──▶  star schema  ──▶  medidas /     ──▶ dashboards  ──▶  workspaces,
  planilhas         (ver apost.       (fato +           métricas          e relatórios     apps, e-mail,
  banco de prod.    Eng. de Dados)    dimensões)        centralizadas                      Slack/Teams,
  APIs SaaS                                             (DAX / LookML)                     embedded
  warehouse/lake                                        + RLS
  └───────────┘    └────────────┘    └────────────┘    └─────────────┘    └────────────┘   └──────────────┘

• Você pode pular etapas (conectar o Power BI direto numa planilha), mas soluções corporativas sérias têm todas — é o que dá confiabilidade e escala.
• A tendência moderna é empurrar a integração e a modelagem para o warehouse/lakehouse (ELT + dbt) e deixar a ferramenta de BI cuidar de semântica e apresentação. Ver apostila de Engenharia de Dados.

1.3 Self-service × BI governado

O equilíbrio maduro: datasets/modelos governados e certificados pelo time central, sobre os quais as áreas fazem self-service de visualização. As métricas são únicas; a exploração é livre.

1.4 Os papéis

• BI Analyst: traduz perguntas de negócio em dashboards; conhece o domínio e a ferramenta.
• BI Developer: constrói e mantém os modelos, medidas, RLS, performance, deployment.
• Analytics Engineer: modela os dados no warehouse (dbt) que alimentam o BI.
• BI/Data Platform Admin: tenant, capacidade, licenças, gateways, políticas.
• Data Steward / dono de métrica: responde pela definição de cada KPI.

2.1 Comparativo

2.2 Como escolher

• Já é casa Microsoft / orçamento apertado / precisa de modelagem forte: Power BI.
• Análise visual exploratória é o coração do trabalho / cultura de "data viz": Tableau.
• Quer a métrica definida uma vez, versionada, consumida por vários BIs e apps: Looker ou uma camada semântica headless (Módulo 8).
• Time pequeno, perguntas diretas, quer algo de pé amanhã: Metabase.
• Já tem warehouse forte: qualquer uma em modo "live/DirectQuery" + modelagem no warehouse.

3.1 Por que não uma tabela gigante achatada

A tentação do iniciante: trazer uma única tabela enorme com tudo (a "flat table" / "big table") e arrastar campos. Problemas: explode em tamanho (repetição de todos os atributos em cada linha), filtros e totais ficam ambíguos, medidas de contagem distinta quebram, e a manutenção vira um inferno. A resposta é a modelagem dimensional (Kimball) — a mesma da apostila de Engenharia de Dados, aqui do ponto de vista do BI.

3.2 Star schema

• Tabela fato: os eventos mensuráveis (vendas, pedidos, tickets). Cada linha é uma ocorrência no grão definido. Colunas = chaves para as dimensões + métricas numéricas. Longa e estreita; cresce sem parar.
• Tabelas dimensão: o contexto descritivo pelo qual se fatia — dCliente, dProduto, dCalendario, dLoja. Curtas e largas; mudam devagar; contêm os atributos textuais para filtrar e agrupar.
• Relacionamentos: 1 (dimensão) para muitos (fato), com a dimensão "filtrando" o fato. Em Power BI, filtro flui do lado "1" para o lado "*" por padrão (single direction) — mantenha assim salvo necessidade real.

                 ┌──────────────┐
                 │ dCalendario  │
                 └──────┬───────┘
  ┌────────────┐   ┌────┴─────────┐   ┌──────────────┐
  │  dCliente  ├───┤   fVendas    ├───┤  dProduto    │
  └────────────┘   │ grão: 1 linha│   └──────────────┘
                   │ por item de  │
                   │ nota fiscal  │
                   └────┬─────────┘
                 ┌──────┴───────┐
                 │   dLoja      │
                 └──────────────┘

3.3 O grão é a decisão nº 1

3.4 Star × snowflake, e a dimensão calendário

• Star (dimensões achatadas) > snowflake (dimensões normalizadas em sub-tabelas) para BI: menos relacionamentos, motor mais feliz, DAX mais simples. Normalize só se houver motivo forte.
• Sempre tenha uma tabela calendário dedicada (dCalendario), contínua, marcada como tabela de datas, com colunas de ano, trimestre, mês, semana, dia útil, feriado. É o que faz "time intelligence" (YoY, MTD, YTD) funcionar. Nunca dependa da data solta na tabela fato.
• Slowly Changing Dimensions (SCD): Tipo 1 sobrescreve (perde histórico); Tipo 2 cria linha nova com validade (preserva histórico — a venda de janeiro fica ligada ao vendedor/território de janeiro). Ver apostila de Engenharia de Dados.

3.5 Import × DirectQuery / Live

4.1 Medida × coluna calculada

4.2 Contexto: o coração do DAX

• Contexto de linha (row context): "qual linha estou avaliando agora" — existe dentro de colunas calculadas e de iteradores (SUMX, FILTER).
• Contexto de filtro (filter context): "quais filtros estão ativos" — vem dos visuais, slicers, linhas/colunas da matriz, e de CALCULATE. É o que faz a mesma medida [Total Vendas] mostrar um número por região numa tabela e outro no total.
• CALCULATE é a função central: modifica o contexto de filtro. CALCULATE([Total Vendas], dProduto[Categoria] = "Bebidas") ignora o filtro de categoria do visual e força "Bebidas".

// Medidas típicas de um modelo de vendas
Total Vendas = SUMX(fVendas, fVendas[Qtd] * fVendas[PrecoUnit])

Vendas Ano Anterior =
    CALCULATE([Total Vendas], SAMEPERIODLASTYEAR(dCalendario[Data]))

Crescimento YoY % =
    DIVIDE([Total Vendas] - [Vendas Ano Anterior], [Vendas Ano Anterior])

Vendas YTD =
    TOTALYTD([Total Vendas], dCalendario[Data])

% do Total (Categoria) =
    DIVIDE([Total Vendas],
           CALCULATE([Total Vendas], ALL(dProduto[Categoria])))

Funções essenciais para conhecer: CALCULATE, FILTER, ALL/ALLEXCEPT/REMOVEFILTERS, SUMX/AVERAGEX (iteradores), DIVIDE, VAR (variáveis para legibilidade e performance), e a família de time intelligence (SAMEPERIODLASTYEAR, DATEADD, TOTALYTD, DATESINPERIOD).

4.3 O equivalente no Tableau

• Campos calculados simples (aritmética, lógica) ~ colunas/medidas básicas.
• Table calculations (running total, percent of total, rank, moving average) operam sobre o resultado já agregado no visual — dependem do "endereçamento e partição".
• LOD expressions ({ FIXED [Cliente] : SUM([Vendas]) }, INCLUDE, EXCLUDE) controlam em que granularidade a agregação acontece, independente do nível do visual — é o mecanismo que resolve os casos que em DAX você faria com CALCULATE/ALLEXCEPT.
• Parâmetros e sets para interatividade e segmentação.

4.4 A camada semântica: métrica definida uma vez

O problema corporativo clássico: "receita" calculada de formas ligeiramente diferentes em 12 dashboards, e nas reuniões ninguém sabe qual número está certo. A solução é centralizar a definição das métricas:

• Power BI: um dataset compartilhado e certificado com as medidas oficiais; os relatórios se conectam a ele (thin reports), não recriam as medidas.
• Tableau: published data sources e Tableau Metrics; a definição vive no data source, não em cada pasta.
• Looker: LookML — as medidas são código versionado, reusadas por tudo.
• Headless (Módulo 8): dbt Semantic Layer / MetricFlow, Cube — a métrica definida uma vez e servida a qualquer ferramenta.

5.1 Escolha do gráfico pela pergunta

5.2 Princípios (o essencial de Tufte / Few)

• Maximize a razão dado/tinta: remova bordas, sombras, grades pesadas, fundos, gradientes, ícones decorativos. Cada pixel deve informar.
• Cor com propósito: uma paleta neutra + uma cor de destaque para o que importa. Nunca "arco-íris". Garanta contraste e não dependa só de cor (daltonismo) — use rótulo, posição, forma.
• Ordene com significado: barras por valor (não alfabético), a menos que a categoria tenha ordem natural (meses, faixas).
• Contexto em todo número: um KPI sozinho não diz nada — mostre vs meta, vs período anterior, ou a tendência (sparkline).
• Rótulos diretos > legenda distante; títulos que afirmam a conclusão ("Vendas caíram 8% no Sul") > títulos genéricos ("Vendas por região").
• Alinhe numa grade; agrupe o relacionado; deixe respiro (whitespace).

5.3 Dashboard × relatório

O anti-padrão mais comum: espremer 25 visuais numa página, cada um pedindo interpretação, e chamar de dashboard. Se o usuário precisa "estudar" a tela, não é dashboard. Separe: uma página-resumo enxuta + páginas de detalhe acessíveis por drill-through.

5.4 Interatividade e narrativa

• Filtros/slicers visíveis e poucos; estado inicial sensato (mês atual, todas as regiões).
• Drill-down (ano → trimestre → mês) e drill-through (clicar numa região abre a página de detalhe daquela região).
• Tooltips ricos (um mini-gráfico no hover) para não poluir a tela principal.
• Ordem de leitura: topo-esquerda = mais importante (KPIs), desça para o detalhe. Conte uma história.
• Mobile: se será visto no celular, faça um layout mobile dedicado, não confie no redimensionamento.

6.1 Como o motor em memória funciona

Power BI (VertiPaq) e Tableau (Hyper) usam armazenamento colunar comprimido em memória. A performance depende de quão bem cada coluna comprime, e isso depende principalmente da cardinalidade (nº de valores distintos): colunas com poucos valores distintos comprimem muito; colunas de altíssima cardinalidade (IDs únicos, timestamps ao segundo, texto livre) comprimem mal e dominam o tamanho e a lentidão do modelo.

6.2 Alavancas no modelo

• Star schema não é só organização — é performance: o motor é otimizado para fato + dimensões com relações 1:*. Modelos "espaguete" (muitas tabelas, relações bidirecionais, many-to-many) são lentos.
• Reduza cardinalidade: separe DateTime em Date + Time; não importe colunas que ninguém usa; arredonde decimais desnecessários; troque chaves textuais longas por inteiras (surrogate keys).
• Traga só o necessário: filtre linhas na origem (só os últimos N anos), remova colunas no Power Query/prep, não a página inteira do ERP.
• Evite relações bidirecionais e many-to-many salvo necessidade real e consciente.
• Desabilite auto date/time (Power BI cria uma tabela de datas escondida por coluna de data — use a sua dCalendario).

6.3 Alavancas nas medidas (DAX)

• Use variáveis (VAR): calcule uma vez, reutilize; melhora legibilidade e evita recomputar.
• Evite iterar sobre a tabela fato inteira quando uma agregação simples resolve; cuidado com FILTER(tabela inteira, ...) — filtre colunas, não tabelas.
• Prefira DIVIDE a / (trata divisão por zero sem erro/branch).
• Meça com o Performance Analyzer (Power BI) e o DAX Studio (server timings, storage engine vs formula engine) para achar a medida/visual culpado.

6.4 Agregações e refresh incremental

• Tabelas de agregação: pré-somar a fato num grão mais alto (por dia/loja/categoria) e deixar o motor usar a agregação para as consultas de alto nível, caindo para o detalhe só quando necessário. Ganho enorme em modelos grandes.
• Incremental refresh: em vez de recarregar 5 anos toda noite, recarregar só a janela recente (últimos X dias) e manter o histórico particionado. Refresh de minutos em vez de horas.
• Composite models / DirectQuery híbrido: histórico frio em DirectQuery, quente em Import.

6.5 Alavancas na página

• Menos visuais por página (cada visual é uma ou mais queries). 6–8 é saudável; 20 é lento por construção.
• Evite tabelas/matrizes com dezenas de milhares de linhas renderizadas.
• Slicers pesados (muitos itens, "select all") custam; considere listas suspensas e menos slicers.
• Cuidado com medidas complексas em cada célula de uma matriz grande (é a medida × nº de células).

7.1 Ambientes e deployment

• Workspaces por ambiente: Dev → Test → Prod (Power BI Deployment Pipelines; no Tableau, projetos/sites e migração via API/Content Migration Tool).
• Regras de parametrização: a conexão troca de banco automaticamente ao promover de Test para Prod.
• Versionamento: Power BI Project (.pbip, formato de pasta com TMDL) e Tableau (.tds/.twb XML) vão para o git — revisão de PR, histórico, rollback. "BI como código" está deixando de ser exceção.
• CI/CD: validar o modelo (Tabular Editor + regras de "best practice analyzer"), rodar testes de dados, e publicar via API/Fabric no merge.

7.2 Segurança de dados

7.3 Datasets certificados e catálogo de métricas

• Endorsement: marcar datasets/data sources como Certified (revisado, oficial) ou Promoted. Usuários filtram por confiável.
• Thin reports: relatórios que se conectam ao dataset certificado em vez de importar dados de novo — a métrica é uma só.
• Catálogo de métricas / data dictionary: para cada KPI — definição em linguagem de negócio, fórmula, fonte, dono, frequência de atualização, ressalvas. Vive num lugar acessível (wiki, catálogo de dados, ou o próprio tooltip da medida).
• Lineage: ver de qual fonte → dataflow → dataset → relatório cada número vem (Power BI lineage view; catálogos como Purview/DataHub).

7.4 Operação

• Monitoramento de refresh: alarme quando uma atualização falha ou atrasa; histórico de duração.
• Métricas de uso: quais relatórios são vistos, por quem, com que frequência — para aposentar os mortos (Módulo 9).
• Ciclo de vida: revisão periódica; conteúdo sem uso vai para arquivo/lixeira; dono responsável por cada workspace.
• Capacidade/custo: em Power BI Premium/Fabric e Tableau Server, monitorar consumo de capacidade e planejar (ver apostila de FinOps).

8.1 A camada semântica headless

Em vez de definir as métricas dentro de uma ferramenta de BI (e re-defini-las na próxima), define-se uma vez numa camada independente que serve qualquer consumidor:

• dbt Semantic Layer / MetricFlow, Cube, o LookML do Looker: a métrica "receita líquida" mora aqui, versionada, testada, com governança.
• Power BI, Tableau, um notebook, uma planilha, um app, um agente de IA — todos consultam a mesma definição via API/SQL.
• Acaba a divergência de métricas entre ferramentas; a definição fica no controle de versão junto do pipeline de dados.

8.2 BI como código

• Modelo, medidas e relatórios em arquivos de texto (TMDL/`.pbip`, LookML, código do Superset) no git; PR review; CI que valida e publica.
• Best practice analyzer (Tabular Editor) roda no CI como um linter de modelo.
• Ambientes reproduzíveis, rollback, e a possibilidade de gerar relatórios programaticamente.

8.3 Integração com warehouse / lakehouse

• A modelagem (bronze/silver/gold, star schema) acontece no warehouse com ELT + dbt; o BI consome a camada gold.
• DirectQuery/Live sobre o warehouse quando ele é rápido o bastante (ClickHouse, BigQuery BI Engine, Snowflake) — evita duplicar o dado e mantém frescor.
• Formatos abertos (Iceberg/Delta) e "one copy" — o BI lê a mesma tabela que o ML e o ad-hoc.

8.4 Distribuição além do dashboard

• Alertas data-driven: "avise no Teams se a margem cair abaixo de X" — o insight vai ao usuário, o usuário não precisa ir ao dashboard.
• Subscriptions: o relatório por e-mail no horário certo.
• Embedded analytics: dashboards embutidos no produto/portal da empresa ou entregues a clientes (Power BI Embedded, Tableau Embedding, Looker, Sigma).
• Data apps / write-back: o usuário não só vê, mas insere dados de volta (previsões, aprovações).

8.5 IA no BI: o que muda e o que não

• Pergunta em linguagem natural (Copilot no Power BI, Tableau Pulse/Agent, "Explore" do Looker): o usuário pergunta "vendas por região no último trimestre" e a ferramenta gera o visual. Útil para exploração e para quem não domina a ferramenta.
• Resumos e explicações automáticas: "por que este KPI mudou" com decomposição automática dos drivers.
• Geração assistida de DAX/medidas e de relatórios.
• Os limites: a IA responde bem quando o modelo semântico é bom — métricas certificadas, nomes claros, relacionamentos corretos. Sobre um modelo bagunçado, ela alucina números plausíveis e errados. A IA amplifica a qualidade da modelagem e da governança; não a substitui. Continua valendo tudo dos Módulos 3, 4 e 7.

9.1 KPI acionável × métrica de vaidade

Um bom KPI: liga-se a um objetivo, é comparável (vs meta, período, benchmark), tem um dono que pode agir sobre ele, e leva a uma decisão. Se ninguém muda nada quando o número muda, não é KPI — é enfeite.

Frameworks úteis: North Star Metric (a métrica que melhor representa o valor entregue), OKRs (objetivos + resultados-chave mensuráveis), e a árvore de métricas (decompor o North Star em drivers acionáveis por time).

9.2 A proliferação de dashboards

Sintoma de BI doente: 400 dashboards, 30 usados, "receita" com 5 valores, ninguém confia em nada e todo mundo exporta para o Excel. Causas: self-service sem governança, cada pessoa recria em vez de reusar, nada é aposentado. Combate:

• Datasets certificados + thin reports (Módulo 7) — reusar, não recriar.
• Métricas de uso: aposentar o que ninguém abre há 90 dias.
• Um "produto" de BI por domínio, com dono, em vez de 40 relatórios soltos.
• Processo leve de request/revisão para conteúdo novo em áreas críticas.
• Catálogo pesquisável: a pessoa acha o dashboard certo em vez de fazer o 41º.

9.3 Medir a adoção

• Alcance: % dos usuários-alvo que abriram o conteúdo no mês.
• Frequência e recência: voltam? com que ritmo?
• Profundidade: usam filtros, drill, ou só olham a primeira tela?
• Decisões influenciadas: qualitativo — entrevistas, "que decisão você tomou com isto?".
• "Excel escape": quanto do consumo termina em exportação (sinal de que a ferramenta não atende).

9.4 Literacia de dados

• Treinar os consumidores a ler um gráfico, entender uma média vs mediana, desconfiar de amostra pequena, e a diferença entre correlação e causa.
• Glossário de métricas em linguagem de negócio, acessível no ponto de uso.
• "Office hours" do time de dados; campeões de dados em cada área.
• Cultura de decidir com o número, e de dizer "não sei ainda" quando o dado não suporta a conclusão.

9.5 Migração entre ferramentas e custo em escala

• Migração (ex.: Tableau → Power BI): não é "converter arquivos" — é reconstruir a modelagem e as métricas com a chance de limpar a bagunça. Priorizar pelo uso; rodar em paralelo; validar número a número; treinar os usuários.
• Licenciamento em escala: Power BI Pro por usuário vs Premium/Fabric por capacidade (o ponto de virada costuma ser por volta de algumas centenas de usuários); Tableau Creator/Explorer/Viewer. Modelar o custo antes de crescer (ver apostila de FinOps).

10.1 Perfis e certificações

10.2 Roadmap de estudo (8–10 semanas)

10.3 Banco de perguntas de entrevista (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Solução end-to-end (âncora): pegar um dataset público de negócio (varejo, e-commerce, saúde pública, transporte), modelar em estrela, escrever ~12 medidas (incluindo time intelligence), construir um dashboard executivo + páginas de detalhe com drill-through, implementar RLS, e documentar as decisões e um catálogo de métricas. Publicar (Power BI/Tableau Public + artigo).
2. "Antes/depois" de performance: um modelo propositalmente ruim (tabelona, timestamps, relações bidirecionais) e a versão otimizada, com números de Performance Analyzer e explicação.
3. Estudo de design: refazer um dashboard ruim (real ou inventado), lado a lado, explicando cada mudança pelos princípios do Módulo 5.
4. DAX/LOD em profundidade: um conjunto de padrões de medidas resolvidos e explicados (ranking dinâmico, % do total em vários níveis, comparação de períodos, cohort simples).
5. BI moderno: um projeto pequeno com dbt no warehouse + camada semântica + o BI conectado ao vivo, mostrando "uma verdade" entre duas ferramentas.

10.5 Fontes para continuar

• Modelagem: The Data Warehouse Toolkit (Kimball); Analyzing Data with Power BI and Power Pivot e The Definitive Guide to DAX (Russo & Ferrari / SQLBI).
• DAX: SQLBI (artigos, DAX Guide, patterns); DAX Studio e Tabular Editor (ferramentas).
• Visualização: The Visual Display of Quantitative Information (Tufte); Information Dashboard Design e Show Me the Numbers (Stephen Few); Storytelling with Data (Cole Nussbaumer Knaflic).
• Tableau: a documentação de LOD e table calculations; a comunidade "Makeover Monday" para praticar design.
• Moderno: docs do dbt Semantic Layer / MetricFlow e do Cube; material sobre "BI as code" e "headless BI".