Disciplina: Business Intelligence Professor: José Antonio de Paiva Júnior Tema do Projeto: Análise de Vendas do E-commerce Olist Fonte dos Dados: Kaggle – Brazilian E-commerce Public Dataset by Olist
O presente projeto teve como objetivo o desenvolvimento completo de uma solução de Business Intelligence utilizando PostgreSQL e Power BI, seguindo os requisitos definidos na disciplina.
O trabalho foi desenvolvido utilizando dados reais do marketplace brasileiro Olist, disponíveis publicamente no Kaggle. O dataset contém informações sobre pedidos, clientes, produtos, vendedores, pagamentos e entregas realizadas em um e-commerce brasileiro.
A proposta principal foi transformar dados brutos em informações analíticas organizadas, permitindo análises estratégicas e operacionais através de um Data Warehouse estruturado em modelo estrela.
Além da modelagem dimensional, o projeto contemplou:
- criação de camada de dados brutos (staging/repositório)
- processo completo de ETL
- tratamento e padronização de dados
- construção de Data Warehouse
- criação de Data Mart analítico
- preparação para consumo no Power BI
Empresas de e-commerce geram diariamente grandes volumes de dados relacionados a pedidos, clientes, produtos, pagamentos e entregas.
Entretanto, dados operacionais normalmente encontram-se fragmentados em múltiplas tabelas e sistemas, dificultando análises estratégicas rápidas.
Dessa forma, o projeto buscou responder questões importantes para o negócio, como:
- Qual o volume total de vendas?
- Quais categorias mais vendem?
- Quais estados possuem maior receita?
- Qual o tempo médio de entrega?
- Quais formas de pagamento são mais utilizadas?
- Como as vendas evoluem ao longo do tempo?
- Quais vendedores possuem maior participação?
Para resolver esse problema, foi desenvolvido um ambiente analítico baseado em Data Warehouse.
O dataset utilizado foi o:
Brazilian E-commerce Public Dataset by Olist
Disponível na plataforma Kaggle.
O conjunto de dados contém informações reais de pedidos realizados entre os anos de 2016 e 2018.
Os principais arquivos utilizados foram:
| Arquivo | Descrição |
|---|---|
| olist_orders_dataset | Informações dos pedidos |
| olist_order_items_dataset | Itens vendidos |
| olist_order_payments_dataset | Pagamentos |
| olist_customers_dataset | Clientes |
| olist_products_dataset | Produtos |
| olist_sellers_dataset | Vendedores |
| product_category_name_translation | Tradução das categorias |
O projeto foi dividido em três camadas principais:
Responsável por armazenar os dados brutos sem transformações significativas.
Schema utilizado:
repositorioTabelas armazenadas:
- customers
- orders
- order_items
- payments
- products
- sellers
- categoria
Essa camada foi criada para atender boas práticas de ETL e os requisitos da disciplina.
O objetivo foi preservar os dados originais antes da realização de qualquer transformação.
Responsável pela modelagem dimensional.
Schema utilizado:
dwNesta camada foram criadas:
- tabela fato
- dimensões
- chaves substitutas (surrogate keys)
- relacionamentos analíticos
Foi adotado o modelo estrela com pequenas características snowflake.
Responsável pela preparação analítica dos dados para consumo no Power BI.
Schema utilizado:
datamartFoi criada a view:
vw_vendas_analiticasEssa view centraliza as informações analíticas necessárias para construção dos dashboards.
O processo de ETL (Extract, Transform, Load) foi uma das etapas mais importantes do projeto.
Todas as transformações foram realizadas utilizando Python e Pandas.
Os dados foram carregados a partir dos arquivos CSV utilizando a biblioteca Pandas.
Exemplo:
orders = pd.read_csv('olist_orders_dataset.csv')Todos os datasets foram carregados individualmente.
Após o carregamento, iniciou-se o tratamento e preparação dos dados.
As principais transformações realizadas foram:
Os nomes das colunas foram organizados para facilitar a modelagem.
Campos de data foram convertidos para formatos adequados.
Exemplo:
- order_purchase_timestamp
- order_delivered_customer_date
Também foram tratados campos numéricos e categóricos.
Durante a análise foi identificado que alguns pedidos não possuíam data de entrega.
Isso ocorre porque determinados pedidos:
- foram cancelados
- ainda estavam em trânsito
- não haviam sido entregues
Esses valores nulos foram mantidos propositalmente, pois representam comportamento real do negócio.
Foi criada uma coluna calculada chamada:
dias_entrega
Essa métrica representa a diferença entre:
- data da compra
- data da entrega
A coluna foi criada para facilitar análises logísticas e indicadores de desempenho.
Durante o desenvolvimento foi identificado um grande volume de registros duplicados na tabela fato.
Inicialmente:
- mais de 12 mil duplicidades foram encontradas
Após investigação, verificou-se que o problema ocorria devido ao relacionamento entre pedidos e pagamentos.
Alguns pedidos possuíam múltiplas linhas de pagamento, fazendo com que os merges gerassem replicação de registros.
Foi realizada uma análise detalhada dos pedidos duplicados.
Após validação, os registros efetivamente duplicados foram removidos.
Resultado final:
Duplicados: 0
Também foram identificados alguns registros sem chave de pagamento.
Após investigação verificou-se que determinados pedidos não possuíam informações válidas na tabela de pagamentos.
Esses registros foram removidos da tabela fato por não possuírem integridade dimensional.
Após todas as transformações, os dados foram carregados no PostgreSQL utilizando SQLAlchemy.
Exemplo:
.to_sql()Os dados foram enviados para:
- schema repositorio
- schema dw
Foi adotado um modelo estrela para organização analítica dos dados.
A granularidade definida para a tabela fato foi:
Um registro por item de pedido vendido
Essa granularidade permite análises detalhadas por:
- produto
- cliente
- vendedor
- data
- pagamento
Tabela criada:
fato_vendas
Métricas armazenadas:
- price
- freight_value
- dias_entrega
Também foram armazenadas as chaves das dimensões.
Foram criadas as seguintes dimensões:
| Dimensão | Objetivo |
|---|---|
| dim_cliente | Informações dos clientes |
| dim_produto | Informações dos produtos |
| dim_vendedor | Informações dos vendedores |
| dim_tempo | Informações temporais |
| dim_pagamento | Informações de pagamento |
| dim_categoria | Informações de categoria |
O projeto atende ao requisito mínimo de seis dimensões.
A dimensão tempo foi criada para permitir análises temporais.
Campos criados:
- ano
- mês
- nome do mês
- trimestre
- semestre
- dia da semana
- indicador de fim de semana
Essa dimensão é fundamental para análises históricas e evolução temporal.
A dimensão pagamento foi criada a partir dos dados:
- tipo de pagamento
- quantidade de parcelas
Foi criada uma surrogate key:
sk_pagamento
Essa abordagem reduz redundância e melhora performance analítica.
Foi criada uma dimensão específica para categorias de produtos.
Essa dimensão possui:
- nome em português
- tradução em inglês
A separação da categoria em outra dimensão permitiu aplicar parcialmente o conceito snowflake.
O projeto aplicou diversos conceitos avançados de modelagem dimensional.
Foi criada uma dimensão temporal completa.
Conceito obrigatório aplicado.
O campo:
order_id
foi mantido diretamente na tabela fato.
Isso caracteriza uma dimensão degenerada.
A estrutura:
dim_produto → dim_categoria
representa um snowflake parcial.
Isso ocorre porque a categoria foi separada em uma dimensão própria.
Após a finalização do Data Warehouse, foi criada uma camada analítica simplificada.
O objetivo foi facilitar o consumo dos dados pelo Power BI.
Foi criada a view:
vw_vendas_analiticasEssa view centraliza:
- métricas de vendas
- informações temporais
- categorias
- clientes
- vendedores
- pagamentos
Tudo em uma única estrutura analítica.
Dados brutos:
- customers
- orders
- order_items
- payments
- products
- sellers
- categoria
Modelo dimensional:
- fato_vendas
- dim_cliente
- dim_produto
- dim_vendedor
- dim_tempo
- dim_pagamento
- dim_categoria
Camada analítica:
- vw_vendas_analiticas
Durante o desenvolvimento do projeto foram encontrados diversos desafios técnicos.
O principal desafio ocorreu durante os merges relacionados aos pagamentos.
Foi necessário investigar:
- cardinalidade
- granularidade
- relacionamentos
para eliminar replicações indevidas.
Foi necessário garantir que todos os registros da tabela fato possuíssem chaves válidas.
Registros inconsistentes foram identificados e tratados.
Diversos campos necessitaram conversão para garantir compatibilidade entre Python, PostgreSQL e Power BI.
A organização correta das dimensões exigiu planejamento para evitar redundâncias e preservar a performance analítica.
Ao final do projeto foi possível construir:
- um ambiente completo de Business Intelligence
- um Data Warehouse funcional
- um Data Mart analítico
- uma estrutura pronta para dashboards e indicadores
O modelo permite análises sobre:
- receita
- frete
- tempo de entrega
- comportamento temporal
- categorias de produtos
- estados
- vendedores
- pagamentos
Com a estrutura criada é possível desenvolver diversos KPIs no Power BI.
Exemplos:
- Receita Total
- Quantidade de Pedidos
- Ticket Médio
- Frete Médio
- Tempo Médio de Entrega
- Crescimento Mensal
- Ranking de Categorias
- Participação por Estado
- Forma de Pagamento Mais Utilizada
- Evolução de Vendas
O projeto permitiu aplicar na prática os principais conceitos estudados na disciplina de Business Intelligence.
Foi desenvolvido um fluxo completo envolvendo:
- dados brutos
- ETL
- modelagem dimensional
- Data Warehouse
- Data Mart
- preparação para análise em BI
Além do aprendizado técnico, o projeto demonstrou a importância da organização de dados para suporte à tomada de decisão.
A utilização de um modelo dimensional permitiu transformar dados operacionais complexos em uma estrutura analítica eficiente, escalável e adequada para geração de insights de negócio.
O resultado final foi uma solução completa de Business Intelligence utilizando PostgreSQL, Python e Power BI.