Do Excel ao SQL Server: quando a planilha não dá conta

No fim do meu primeiro ano, os relatórios já tinham cara de novos. Tudo tinha ido para o Power BI, os clientes abriam os resultados numa área própria e o BI tinha virado produto da consultoria. Por baixo, porém, os dados continuavam onde sempre estiveram: em arquivos de Excel.

Este texto trata do segundo e do terceiro anos montando uma área de BI numa consultoria que atende escolas particulares no Brasil. A linha do tempo completa está em seis anos montando uma área de BI, e o primeiro ano, em o Power BI como produto.

O preço de viver no Excel

Quase todo trabalho com dados começa no Excel, e por bons motivos: qualquer pessoa abre uma planilha, qualquer pessoa corrige uma célula. O problema aparece depois. A planilha tem limite de tamanho e é difícil de compartilhar com segurança. O arquivo é copiado, vai por e-mail, ganha outro nome, e logo ninguém sabe qual versão vale.

O custo maior estava no cruzamento. Cada pergunta que pedia duas fontes ao mesmo tempo obrigava alguém a costurar arquivos à mão: procura entre pastas de trabalho, colunas coladas na ordem certa, um filtro esquecido no caminho. Era lento para nós e mais lento ainda para quem esperava a resposta.

E quem espera a resposta é o que importa. Em BI, tudo se resume à experiência de quem usa o relatório. Um dashboard maravilhoso que leva minutos para renderizar não funciona. A pessoa precisa da informação correta, disponível na hora, sem atraso e sem bug. Um modelo alimentado por uma pilha de planilhas nunca ia entregar isso com regularidade.

A mudança para o SQL Server

Por isso o segundo ano foi de estrutura. Migrei para o SQL Server as bases que estavam em arquivos de Excel, e duas coisas melhoraram de imediato. A manutenção ficou mais simples, porque o dado passou a ter um lugar só e um jeito só de ser alterado. A segurança subiu bastante, porque em vez de arquivos circulando havia um servidor com acesso controlado.

Olhando para trás, foi um divisor de águas. A facilidade de manipular os dados e a segurança a mais sustentaram o crescimento sem que o trabalho desabasse sob o próprio peso.

O nome de manual para o que estávamos construindo é data warehouse: um repositório central que consolida várias fontes e é otimizado para leitura e análise, ao contrário dos sistemas transacionais, feitos para gravar rápido. O caminho até ele é o velho ETL:

1. Extrair o dado bruto de onde ele estiver: arquivos, sistemas, exportações.
2. Transformar, o que quer dizer padronizar formatos, tirar duplicatas, corrigir inconsistências e aplicar as regras do negócio.
3. Carregar no repositório, por inteiro ou de forma incremental, só com o que é novo.

Nada disso é teoria nova. O que muda quando se faz de verdade é que as regras de transformação deixam de morar na cabeça de alguém ou numa aba escondida da planilha. Viram algo que dá para ler, revisar e rodar de novo.

A pergunta que só uma base única responde

Com os dados num lugar só, deu para cruzar fontes que nunca tinham se encontrado. Um exemplo virou referência para mim.

Toda escola quer saber se a mensalidade está certa. Não certa em tese, mas certa para as famílias que moram em volta dela. Com a base no SQL Server, passamos a responder isso com dados. Traçamos a área de influência da escola em dois raios, de 2 km e de 4 km, e cruzamos dados demográficos de quem mora ali com dados econômicos da cidade. O resultado era uma estimativa do valor médio gasto com mensalidade escolar na região, que comparávamos com a mensalidade do cliente.

O raciocínio cabe numa frase: se as famílias do entorno costumam gastar muito menos, ou muito mais, do que a escola cobra, essa diferença é um fato estratégico, não uma impressão. Com planilhas, chegar lá exigiria juntar tudo à mão para cada escola. Com um banco de verdade, virou uma análise que dava para repetir.

Esse é o argumento real para sair do Excel. Não que SQL seja mais sofisticado, mas que algumas perguntas só passam a ter resposta quando qualquer fonte pode ser ligada a qualquer outra.

Terceiro ano: todos os relatórios refeitos em cima da base

No terceiro ano, todos os relatórios foram refeitos no Power BI, agora ligados à nova base no SQL Server. Quem usava sentiu a diferença, e os modelos semânticos por trás dos relatórios passaram a render muito mais, o que deu análises mais rápidas e mais precisas.

Algumas ideias de modelagem pesam nessa fase, e valem para quase qualquer ferramenta de BI:

• Modele antes de construir. Comece pelas entidades e pelas relações entre elas, detalhe isso em tabelas e chaves, e só então pense em índice e tipo de dado.
• Normalize onde se grava, desnormalize onde se lê. A normalização mantém a origem consistente e sem redundância. O modelo de relatório costuma abrir mão de parte disso em troca de consultas mais simples e rápidas.
• Pense em dimensões. A maior parte das perguntas de negócio é uma medida recortada por tempo, lugar e categoria, que é a ideia por trás do OLAP e da análise multidimensional. Um modelo desenhado em torno dessas dimensões responde perguntas novas sem ser refeito.
• Automatize a atualização. Relatório que depende de alguém lembrar de atualizar vai, cedo ou tarde, mostrar número velho.

No mesmo ano contratamos um assistente. Com mais um par de mãos, seguimos atendendo os pedidos dos clientes e, ao mesmo tempo, desenvolvemos áreas específicas e soluções sob medida para quem precisava de algo além dos relatórios padrão.

O que eu faria de novo

Se fosse montar outra área de BI amanhã, ainda começaria pelos relatórios, porque é o que o cliente vê e paga. Mas não esperaria um ano inteiro para arrumar a fundação. Estas são as lições que levo dessa fase:

• Velocidade é recurso. Um dashboard lento perde a confiança de quem usa mais rápido do que um dashboard feio.
• O banco se paga no cruzamento. A comparação de mensalidade, sozinha, justificou a migração.
• Escreva as regras de transformação em código ou SQL. É isso que torna o trabalho repetível, e foi o que abriu caminho para o passo seguinte, a automação.
• Refaça quando a base muda. Apontar relatórios antigos para um banco novo não é o mesmo que redesenhá-los para ele.

O gargalo seguinte foi o volume, e ele marcou o quarto ano: automatizar o tratamento de dados com Python.

Se os seus dados ainda estão espalhados em planilhas e você quer ver como fica o cruzamento na prática, a plataforma de BI da bi19 conecta planilhas, bancos SQL, Google Sheets e APIs num lugar só.