Documentação para um projeto de BI
- Amanda Nascimento
- 23 de jun.
- 3 min de leitura
Documentar um projeto de BI vai muito além de criar tabelas. É entender a necessidade, mapear corretamente os dados, prever o crescimento futuro e garantir que qualquer profissional consiga dar manutenção no futuro com segurança.
Um projeto bem documentado é sinônimo de transparência, controle e sucesso.
🗣️ Etapa 1: Entendimento do Projeto com a Área de Negócios
Perguntas para a área de negócio:
Qual é o objetivo principal do painel?
Quais decisões serão tomadas com base nesses dados?
Quais são os indicadores (KPIs) mais importantes?
Com que frequência os dados precisam ser atualizados?
Qual o nível de detalhe esperado? (por dia, por mês, por cliente, por produto, etc.)
Quais filtros são importantes para navegação no painel?
Há alguma fonte de dados já disponível? Qual o formato?
Quais são as dores com o processo atual (se houver)?
Quem são os usuários finais do painel?
Há necessidade de exportação dos dados ou integração com outros sistemas?
📌 Dica: Sempre valide com a área de negócio o que é considerado “correto” ou “esperado” para cada métrica.
📊 Etapa 2: Planejamento da Arquitetura e Documentação Técnica
Fonte dos dados
Nome da Fonte | Tipo | Origem | Formato | Acesso |
Planilha de Vendas | Arquivo | Enviado via e-mail | .xlsx | Pasta compartilhada / SharePoint |
Cadastro de Clientes | Banco | Sistema de CRM | Tabela SQL | Conexão ODBC: crm_db.clientes |
Cadastro de Produtos | Banco | ERP (Oracle) | Tabela SQL | Conexão Oracle: erp.produtos |
Calendário | Tabela Local | Tabela gerada em script | .csv | Local ou gerada por script de data |
Frequência da carga
Fonte | Frequência | Horário de Atualização | Observações |
Vendas (planilha) | Diária (manual) | Até 09h00 | E-mail automático do sistema de vendas |
Clientes (CRM) | Diário (automático) | 05h00 | Full Load |
Produtos (ERP) | Diário (automático) | 05h00 | Full Load |
Calendário | Única (estática) | - | Script Python para geração até 2030 |
Estrutura dos dados (camadas: stage, etc.)
🔹 Stage
Tabelas espelho da origem, sem transformação.
Tabelas: stage_vendas, stage_clientes, stage_produtos
🔹 Trusted
Dados tratados, padronizados, com chaves substituídas, enriquecimento com dimensões.
Tabelas: dim_cliente, dim_produto, dim_data, fato_vendas
🔹 Presentation
Visões otimizadas para Power BI, com joins e filtros aplicados.
Exemplo: vw_vendas_resumo, vw_vendas_detalhadas
Tabelas envolvidas
🔸 Camada Stage
Nome da Tabela | Fonte | Chaves | Comentário |
stage_vendas | Planilha Excel | id_venda | Ingestão bruta |
stage_clientes | CRM (SQL Server) | id_cliente | Importação direta |
stage_produtos | ERP (Oracle) | id_produto | Apenas produtos ativos |
🔸 Camada Trusted
Nome da Tabela | Tipo | Comentário |
dim_cliente | Dimensão | Contém cidade, estado, região |
dim_produto | Dimensão | Inclui categoria e preço atual |
dim_data | Dimensão | Criada com script Python |
fato_vendas | Fato | Agrega vendas por cliente e produto |
Regras de negócio e tratamentos necessários
Regra de Negócio | Aplicação |
Não considerar vendas com valor total = 0 | Filtro em stage_vendas |
Clientes com estado nulo serão marcados como 'IGNORAR' | Regra em dim_cliente |
Produto descontinuado será mantido para histórico | Nenhum filtro aplicado |
Datas devem ter FK válida na dim_data | Carga rejeita datas inválidas |
Vendas duplicadas (mesmo ID) são ignoradas | duplicação por id_venda |
Responsáveis por cada parte
Item | Responsável | Contato |
Ingestão de dados (ETL) | Amanda Nascimento | |
Modelagem dimensional | João BI | |
Validação com área comercial | Carla Comercial | |
Atualização do calendário | Script automatizado | Agendado via Python |
Publicação Power BI | Amanda Nascimento |
Caminho do dado
Planilha Excel (.xlsx)
↓
Carga manual via script Python (ETL)
↓
Tabela stage_vendas
↓
Transformações, deduplicações
↓
Tabela fato_vendas (com FKs)
↓
Power BI conectado ao DW
Organização da Documentação no Projeto
/documentacao_analise_vendas
├── briefing_negocio.md
├── arquitetura_dados.drawio
├── dicionario_dados.xlsx
├── scripts_sql/
│ ├── create_stage.sql
│ ├── create_trusted.sql
│ └── insert_dim_data.sql
├── processo_etl/
│ └── pipeline_ingestao.py
└── dashboard_powerbi/
└── painel_vendas.pbix
🛠️ Etapa 3: Exemplo Prático com Criação de Tabelas no SQL (Camada Stage)
🧩 Cenário:
Você precisa criar um painel que analisa as vendas de uma empresa de e-commerce.
Fontes:
Planilha mensal de vendas (Excel)
Cadastro de clientes (CSV)
Cadastro de produtos (MySQL)
Objetivo do Painel: Exibir total de vendas por período, produto, cliente e região.
Camada Stage
Para cada tabela de stage, documente:
Nome da tabela
Origem dos dados
Descrição de cada coluna
Tipo de dado
Observações (formato, nulos, padrões, etc.)
📄 Exemplo: Documentação Técnica da Camada Stage (faça isso para todas as tabelas)
Tabela: stage_vendas
Coluna | Tipo de dado | Descrição |
id_venda | INT | Identificador único da venda |
data_venda | DATE | Data em que a venda foi realizada |
id_produto | INT | Chave estrangeira para produto |
id_cliente | INT | Chave estrangeira para cliente |
valor_total | DECIMAL(10,2) | Valor total da venda |
🧮 Script SQL de Criação das Tabelas na Camada Stage
CREATE TABLE stage_vendas (
id_venda INT PRIMARY KEY,
data_venda DATE,
id_produto INT,
id_cliente INT,
valor_total DECIMAL(10,2)
);
CREATE TABLE stage_produtos (
id_produto INT PRIMARY KEY,
nome_produto VARCHAR(100),
categoria VARCHAR(50),
preco_unit DECIMAL(10,2)
);
CREATE TABLE stage_clientes (
id_cliente INT PRIMARY KEY,
nome_cliente VARCHAR(100),
estado VARCHAR(2),
cidade VARCHAR(50)
);
📌 Diagrama Relacional da Camada Stage
Algumas ferramentas para auxiliar:
