BanVic Analytics — Como foi feito (explicado fácil)
Imagina que você cozinhava direto no saco do mercado: dava certo, mas era caos. Aqui foi a mesma coisa: a versão original do BanVic plugava Power BI direto no CSV — funcionava, mas escondia problemas. Refiz a "cozinha": PostgreSQL + ETL + IPCA externo.
O que é isso, em uma frase?
É a versão revisada de um desafio de Banking analytics. A primeira entrega era um Power BI lendo CSV. Funciona. Mas é frágil: tipos errados passam despercebidos, sem integridade referencial, sem como crescer.
Esta versão refatora pra arquitetura "de gente grande": PostgreSQL como camada de staging, schema stg_banvic com PK/FK, ETL em SQL versionado, e dado externo de IPCA (IBGE/Sidra) entrando pra dar contexto macroeconômico.
Por que importa? Porque é a diferença entre "deu certo no demo" e "rodando em produção sem dor". Quem contrata analista vê isso na hora.
Do CSV ao staging tipado
1 · Criar o schema com PK/FK. Defino as 7 tabelas (agências, clientes, colaboradores, contas, propostas, transações, IPCA) com chaves primárias e foreign keys. Banco recusa dado inconsistente — bug fica preso ali, não chega no relatório.
CREATE TABLE stg_banvic.contas (
num_conta VARCHAR(20) PRIMARY KEY,
cod_cliente INTEGER REFERENCES stg_banvic.clientes(cod_cliente),
cod_agencia INTEGER REFERENCES stg_banvic.agencias(cod_agencia),
tipo_conta VARCHAR(40),
saldo_total NUMERIC(14,2)
);
2 · Carregar os CSVs com \copy. Comando do psql que importa CSV direto pra tabela. Rápido (centenas de mil linhas em segundos) e não exige permissão de servidor.
\copy stg_banvic.transacoes FROM '/tmp/banvic/transacoes.csv' DELIMITER ',' CSV HEADER;
3 · Validar pós-carga. Conto linhas por tabela. Se algo diverge do esperado, sei na hora.
SELECT 'clientes', COUNT(*) FROM stg_banvic.clientes UNION ALL SELECT 'transacoes', COUNT(*) FROM stg_banvic.transacoes UNION ALL SELECT 'propostas_credito', COUNT(*) FROM stg_banvic.propostas_credito;
4 · Trazer o IPCA de fora. Baixo o IPCA mensal do IBGE (API Sidra), salvo em CSV e carrego na tabela ipca_mensal. Agora dá pra cruzar comportamento do cliente com inflação — algo que a versão original não fazia.
5 · Conectar Power BI no PostgreSQL. O BI lê views e tabelas tipadas. Refresh automático, sem mexer em CSV. Se um dia trocar de BI (Metabase, Looker), o staging continua igual.
6 · 4 sub-análises temáticas. Cada uma com seu arquivo .sql independente: clientes (perfil), crédito (taxas), IPCA (macro × micro) e transações (sazonalidade + YoY com LAG()).
A arquitetura completa
\copy → staging tipada → Power BI. Tudo versionado em SQL.Em uma linha: o que esse projeto ensina
Que refazer com arquitetura certa vale ouro. A versão original "funcionava" — mas a refatoração revela bugs escondidos, libera análises novas (IPCA) e abre caminho pra crescimento. É o tipo de trabalho que separa analista júnior de pleno.
Coisas técnicas que apareceram aqui: modelagem relacional (PK/FK), ETL com \copy do psql, CTEs encadeadas, window functions (LAG, SUM OVER), FILTER (WHERE ...), função corr() nativa, integração de dado externo (IPCA Sidra).