O banco de dados de um sistema de e-commerce foi projetado seguindo rigorosamente as formas normais, resultando em um modelo lógico altamente normalizado. No entanto, durante os testes de carga, a equipe identificou que a consulta que gera o relatório de "Produtos Mais Vendidos por Região" está muito lenta. Essa consulta exige a junção de cinco tabelas (Venda, ItemVenda, Produto, Cliente e Endereco) para consolidar as informações. O sistema precisa gerar este relatório rapidamente para a tomada de decisão dos gestores. A decisão de arquitetura de dados a ser implementada é

Alternativa D - Criar uma tabela sumarizada e desnormalizada que contenha os dados pré-calculados necessários para o relatório

Análise do Cenário

O problema descrito é um clássico trade-off entre normalização e performance. O banco está altamente normalizado para garantir integridade dos dados, mas isso prejudica consultas de leitura complexas como relatórios analíticos.

Por que a consulta está lenta?

Justificativa da Resposta Correta

✅ Alternativa D - Tabela Sumarizada (CORRETA)

Desnormalização controlada para relatórios:

• Cria-se uma tabela agregada com resultados pré-calculados
• Os dados são atualizados periodicamente (ETL ou triggers)
• Consultas leem apenas uma tabela → muito mais rápido
• Padrão conhecido como Data Warehouse ou Materialized View

Vantagens:

• Performance de leitura otimizada
• Menor carga no banco transacional
• Ideal para dashboards e tomada de decisão

Desvantagens:

• Necessidade de manter consistência dos dados
• Armazenamento duplicado

❌ Alternativa A - Diagrama UML

Diagramas de classes não otimizam consultas. São ferramentas de documentação e modelagem conceitual, não afetam performance.

❌ Alternativa B - Chaves Primárias Compostas

Substituir chaves subrogadas por compostas pioraria a performance:

• Índices maiores ocupam mais espaço
• Junções ficam mais complexas
• Não resolve o problema de múltiplas tabelas

❌ Alternativa C - Aumentar Normalização para 4FN

Isso agravaria o problema:

• Mais tabelas = mais junções
• Consultas ficariam ainda mais lentas
• Normalização excessiva prejudica leitura

❌ Alternativa E - Relacionamentos Muitos-para-Muitos

Transformar relacionamentos complicaria o modelo:

• Mais tabelas de associação = mais JOINs
• Aumenta complexidade sem melhorar performance
• Não resolve o gargalo de consultas analíticas

Conclusão

Em sistemas de e-commerce, a prática recomendada é:

1. Manter OLTP normalizado para operações transacionais (vendas, estoque, cadastro)
2. Criar camadas desnormalizadas para relatórios e BI (data warehouse, tabelas sumarizadas)

Esta abordagem separa as preocupações de integridade (OLTP) e performance de leitura (OLAP), permitindo que ambos os requisitos sejam atendidos adequadamente.