← Curso IA na prática para Analistas de Dados: do pedido vago ao número que se sustenta 20 aulas
Onde a IA erra com dados (e por que ninguém percebe)

Laboratório: o dicionário de dados que você cola em toda conversa

Mão na massa 7 min de leitura 35 min de prática Você leva: Dicionário de dados do seu domínio

Montar o arquivo de contexto que elimina coluna inventada, junção duplicada e filtro esquecido.

Quase todo erro das três aulas anteriores vem da mesma origem: o assistente não sabe o que as suas colunas significam. Meia hora agora economiza isso todo dia.

Um dicionário de dados útil não é a documentação completa do banco. É o mínimo que alguém precisa saber para não errar: o que cada tabela representa, a cardinalidade entre elas, o significado dos códigos de status, onde há nulo e qual filtro é obrigatório.

O item mais valioso costuma ser o último: os filtros que todo mundo do time aplica sem pensar e que ninguém escreveu em lugar nenhum. É o conhecimento que sai da empresa quando alguém sai.

Você leva daquiDicionário de dados do seu domínio

Uma página por área de análise. Cole no começo de qualquer conversa sobre dados — ou aponte a ferramenta para ele.

# Dicionário — [área: vendas / produto / financeiro]
Banco: [MySQL 8 / BigQuery / Postgres] · Atualizado em [data]

## Tabelas e o que cada linha representa
| Tabela | Uma linha é | Volume | Chave |
|--------|-------------|--------|-------|
| pedidos | um pedido fechado | 3,4 mi | id |
| pedido_itens | um item dentro de um pedido | 11,8 mi | id (pedido_id → pedidos) |

## Cardinalidade (para não inflar agregação)
- 1 pedido : 1..40 itens  ← JOIN com pedido_itens MULTIPLICA linhas
- 1 cliente : 0..N pedidos

## Códigos que não são óbvios
| Coluna | Valor | Significa |
|--------|-------|-----------|
| pedidos.status | 1 | aguardando pagamento |
| pedidos.status | 2 | pago |
| pedidos.status | 3 | cancelado ← EXCLUIR de faturamento |
| pedidos.status | 7 | estornado ← valor entra NEGATIVO |

## Qualidade conhecida
- pedidos.valor: ~3% nulos (pedidos importados do sistema antigo, antes de 2023)
- clientes.uf: preenchida só a partir de 2024
- [outra armadilha real do seu dado]

## Fuso e datas
- criado_em gravado em [UTC]; o negócio opera em [America/Sao_Paulo]
- "dia" no relatório do time = dia civil em São Paulo

## Filtros que TODO relatório aplica (e ninguém escreve)
- status NOT IN (3, 7)
- cliente_id NOT IN (lista de contas internas de teste)
- [o filtro que só o veterano do time lembra]

## Números de referência (para conferir ordem de grandeza)
- Faturamento mês típico: ~R$ 2,1 mi
- Pedidos/mês: ~3.400 · Ticket mediano: ~R$ 340
- [outro número que você sabe de cor]

Onde guardar: Versionado no repositório de análises, ou fixado no canal do time. Não num documento pessoal.

Mão na massa35 min
Produzir o dicionário da sua área e provar que ele muda o resultado de uma consulta real.

Use o domínio em que você mais trabalha. A parte difícil não é escrever — é descobrir quantas regras você aplica no automático e nunca registrou.

  1. Copie o modelo e preencha as tabelas que você usa toda semana.
  2. Para a cardinalidade, rode a contagem antes/depois do JOIN da aula 1.2 e escreva o número real.
  3. Para os códigos de status, consulte o banco (SELECT status, COUNT(*) GROUP BY status), não a memória.
  4. Meça os nulos de verdade: SELECT COUNT(*) - COUNT(coluna) FROM tabela.
  5. Pergunte à pessoa mais antiga do time: "que filtro eu preciso aplicar e não está escrito em lugar nenhum?". Anote a resposta.
  6. Pegue uma pergunta real de negócio. Peça a consulta sem o dicionário e guarde.
  7. Em conversa nova, cole o dicionário e peça a mesma consulta. Compare as duas.
Deu certo quando
  • Toda cardinalidade foi medida, não estimada.
  • Os códigos de status vieram do banco.
  • A seção de filtros implícitos tem ao menos um item que você não sabia.
  • A segunda consulta aplica os filtros obrigatórios sem você pedir.

Se travar: Se a segunda consulta ficou igual à primeira, provavelmente faltou a seção de filtros implícitos e a de cardinalidade — são as duas que mais mudam o SQL gerado.

Efeito colateral que vale mais que o principal

Times que fazem esse exercício costumam descobrir divergências entre pessoas sobre o que conta como "pedido válido". Duas pessoas produzindo números diferentes há meses, sem saber.

O dicionário não resolve a divergência — mas faz ela aparecer, que é o passo que faltava.

Em uma frase
  • O filtro que todo mundo aplica e ninguém escreveu é a informação mais valiosa do dicionário.

Comentários e dúvidas

Inscreva-se grátis para comentar, tirar dúvidas, marcar seu progresso e emitir o certificado ao fim do curso.

Inscrever-se grátis com Google

Ainda não há comentários nesta aula.