Construir um data warehouse do zero assusta. Parece um projeto gigante, técnico e cheio de decisões irreversíveis. Mas, olhando de perto, é sobretudo uma questão de organização por camadas — como construir uma casa: fundações primeiro, acabamentos por último. Vamos ver o percurso, camada a camada, sem jargão desnecessário.
Porque não basta ligar o Power BI à base de dados
A tentação é apontar a ferramenta de BI diretamente aos sistemas operacionais e começar a fazer relatórios. Funciona até deixar de funcionar: cada relatório reimplementa a sua lógica, os números não batem, as consultas pesam sobre os sistemas que gerem o negócio, e ninguém sabe qual é a versão certa. O data warehouse existe para resolver isto — dar um sítio único, organizado e fiável para a análise.
Camada 1: aterragem (staging)
A primeira camada recebe os dados em bruto das várias fontes, tal como vêm, sem os transformar. É uma zona de aterragem: copia-se para aqui e desacopla-se dos sistemas de origem, para não os sobrecarregar nem depender deles estarem disponíveis. Simples, mas essencial — é a rede de segurança onde tudo começa.
Camada 2: transformação e limpeza
Aqui os dados são limpos, normalizados e integrados: corrigem-se tipos, resolvem-se duplicados, juntam-se fontes, aplicam-se as regras de negócio. É a camada onde o caos vira ordem. Sai daqui uma versão fiável e coerente, pronta a ser modelada para análise. É também onde vive a maior parte do esforço de engenharia.
Camada 3: modelação dimensional
Os dados limpos são organizados no formato que o BI adora: tabelas de factos (as métricas — vendas, quantidades) rodeadas por dimensões (o contexto — cliente, produto, tempo). Este desenho em estrela é simples de entender e rápido de consultar. É a camada que faz a diferença entre um relatório ágil e um lento.
Camada 4: consumo e semântica
Por cima, define-se uma camada de consumo com as métricas de negócio calculadas uma única vez — "receita líquida", "margem", "cliente ativo" — para que toda a organização use as mesmas definições. É a ponte entre os dados técnicos e as pessoas que decidem, e o que garante que "receita" significa o mesmo em todo o lado.
Um exemplo de percurso
Uma empresa de distribuição com vendas em três sistemas diferentes começou por aterrar os três em staging todas as noites. Na camada de transformação, unificou os catálogos de produtos (que tinham códigos diferentes em cada sistema) e limpou moradas de clientes. Modelou depois um facto de vendas com dimensões de cliente, produto, loja e tempo. Por fim, definiu as métricas na camada semântica. O resultado: relatórios que antes demoravam dias a reconciliar à mão passaram a estar prontos todas as manhãs, com números em que todos confiam.
Comece pequeno, cresça por camadas
Não é preciso construir tudo de uma vez. Escolhe um domínio com valor claro — vendas, por exemplo — e leva-o do início ao fim pelas quatro camadas. Um data warehouse que serve bem uma área e cresce a partir daí bate um projeto monumental que tenta abraçar tudo e nunca termina.
Na prática
Se os teus relatórios correm direto sobre os sistemas operacionais e ninguém confia plenamente nos números, é sinal de que falta esta fundação. Desenhar por camadas torna o gigante gerível: uma de cada vez, com valor a aparecer cedo. Por que domínio de negócio começarias a construir a tua camada analítica?
