Banco de Dados · FCC · 2015 | Questão sqc-fc020504

Banco de DadosGerência de Transações

Código: fc020504
Banca: FCC
Órgão: MPE-PB
Ano: 2015
Nível: Superior

Cargo: Analista de Sistemas – Administrador de Banco de Dados

Considere que em um Banco de Dados (BD) há duas tabelas: RCLM_CLIENTE (Reclamações de Clientes), com cerca de 30.000 linhas, e TP_MTVO_RCLM (Tipo do Motivo da Reclamação), com 150 linhas, que atendem à área de Ouvidoria de uma organização. Considere ainda que: − Há uma transação crítica no ambiente online que requer a leitura das duas tabelas em conjunto, pois sempre que recupera uma reclamação, precisa obter a descrição (DS_MTVO) do motivo. − São cerca de 4.000 usuários concorrentes. Usuários com permissão executam a transação crítica 5 vezes ao dia, em média, sendo que, em uma mesma execução, milhares das linhas da tabela RCLM_CLIENTE são acessadas.− A tabela de TP_MTVO_RCLM tem perfil estável, quase não há inclusões, alterações e exclusões. O Administrador, considerando que é necessário que o projeto físico do BD atenda ao requisito de qualidade de “alta performance na execução da transação crítica", propôs, corretamente:

AColocar a tabela RCLM_CLIENTE na 3ª forma normal não permitindo redundar a coluna DS_MTVO. Assim, ao se fazer o JOIN das tabelas, pode-se eliminar cerca de 20.000 acessos/dia à tabela TP_MTVO_RCLM.
BDesnormalizar a tabela RCLM_CLIENTE, ferindo a 3ª forma normal, redundando a coluna DS_MTVO. Assim evita-se o JOIN das tabelas, eliminando cerca de 20.000 acessos/dia à tabela TP_MTVO_RCLM. A estabilidade da coluna DS_MTVO foi fundamental para esta decisão.
CColocar a tabela TP_MTVO_RCLM na 3ª forma normal, não permitindo redundar a coluna DS_MTVO. Assim, ao se fazer o JOIN das tabelas, pode-se eliminar cerca de 20.000 acessos/dia à tabela RCLM_CLIENTE.
DDesnormalizar a tabela TP_MTVO_RCLM, ferindo a 1ª forma normal, ou seja, redundar a coluna DS_MTVO. Assim, ao se realizar o JOIN das tabelas, eliminam-se cerca de 20.000 acessos/dia à tabela RCLM_CLIENTE. A estabilidade da tabela TP_MTVO_RCLM foi garantida nesta decisão.
ECriar uma 3ª tabela através do operador UNION, combinando os resultados da transação crítica em um único result set, inserindo-os como linhas desta tabela, a partir de todas as queries envolvidas na execução. Isso é possível, pois o número e a ordem das colunas não são idênticos em todas as queries.

Revelar gabarito e comentário

GabaritoB — Desnormalizar a tabela RCLM_CLIENTE, ferindo a 3ª forma normal, redundando a coluna DS_MTVO. Assim evita-se o JOIN das tabelas, eliminando cerca de 20.000 acessos/dia à tabela TP_MTVO_RCLM. A estabilidade da coluna DS_MTVO foi fundamental para esta decisão.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Projeto físico de banco de dados: desnormalização para desempenho

Gabarito: letra B. A estratégia correta é desnormalizar a tabela RCLM_CLIENTE, ferindo a 3ª forma normal, ao redundar a coluna DS_MTVO (descrição do motivo) diretamente nela. Isso evita o JOIN entre as tabelas RCLM_CLIENTE e TP_MTVO_RCLM a cada consulta, eliminando cerca de 20.000 acessos/dia à tabela TP_MTVO_RCLM. A estabilidade da coluna DS_MTVO (tabela pequena e com raras alterações) torna a redundância segura e justifica a violação da normalização em prol da alta performance.

A questão cobra o trade-off entre normalização (evitar redundância) e desempenho (evitar JOINs). Em ambientes com alta concorrência e consultas frequentes que exigem dados de múltiplas tabelas, a desnormalização é uma técnica comum para reduzir o número de acessos a disco e o custo de junções.

Critério	Alternativa A (Manter 3FN RCLM_CLIENTE)	Alternativa B (Desnormalizar RCLM_CLIENTE)	Alternativa C (Manter 3FN TP_MTVO_RCLM)	Alternativa D (Desnormalizar TP_MTVO_RCLM)
Violação de forma normal	Nenhuma (mantém 3FN)	Sim (viola 3FN)	Nenhuma (mantém 3FN)	Sim (viola 1FN)
Efeito sobre JOIN	JOIN obrigatório em toda consulta	JOIN eliminado	JOIN obrigatório em toda consulta	JOIN permanece (redundância inútil)
Acessos eliminados/dia	Nenhum (mantém ~20.000 acessos)	~20.000 acessos à TP_MTVO_RCLM	Nenhum (mantém ~20.000 acessos)	Nenhum (redundância não elimina JOIN)
Impacto no desempenho	Baixo (JOIN custoso com milhares de linhas)	Alto (elimina JOIN, reduz I/O)	Baixo (JOIN custoso com milhares de linhas)	Baixo (redundância não otimiza consulta)
Risco de inconsistência	Nenhum (dados normalizados)	Baixo (coluna estável, raras alterações)	Nenhum (dados normalizados)	Alto (redundância em tabela pequena sem benefício)
Adequação ao cenário	❌ Não atende requisito de performance	✅ Atende requisito de performance	❌ Não atende requisito de performance	❌ Não atende requisito de performance

Alternativa A — ❌ Incorreta

Manter a 3ª forma normal na tabela RCLM_CLIENTE (sem redundar DS_MTVO) não elimina a necessidade do JOIN. Pelo contrário, obriga que toda consulta realize a junção com a tabela TP_MTVO_RCLM, gerando os mesmos 20.000 acessos/dia que se pretendia eliminar. A proposta não atende ao requisito de desempenho.

Alternativa B — ✅ Correta ⟵ GABARITO

Desnormalizar a tabela RCLM_CLIENTE, add a coluna DS_MTVO, elimina o JOIN. Como a tabela TP_MTVO_RCLM é pequena e estável, a redundância não acarreta grandes problemas de manutenção. O número de 20.000 acessos/dia eliminados corresponde aproximadamente ao total de execuções da transação (4.000 usuários × 5 execuções/dia = 20.000), que antes exigiriam um acesso à TP_MTVO_RCLM por linha recuperada da RCLM_CLIENTE (milhares de linhas por execução). Com a redundância, cada execução acessa apenas RCLM_CLIENTE.

Alternativa C — ❌ Incorreta

Colocar a tabela TP_MTVO_RCLM na 3ª forma normal (já está normalizada) não altera a necessidade do JOIN. A alternativa sugere eliminar acessos à tabela RCLM_CLIENTE, o que é incoerente: a transação precisa dos dados de RCLM_CLIENTE. O JOIN continuaria sendo feito, e o desempenho não melhoraria.

Alternativa D — ❌ Incorreta

Desnormalizar a tabela TP_MTVO_RCLM (tabela pequena) redundando DS_MTVO nela mesma não faz sentido. A coluna DS_MTVO já está nela. Além disso, a proposta fala em eliminar acessos à RCLM_CLIENTE, mas a transação precisa ler as reclamações (RCLM_CLIENTE). O JOIN ainda seria necessário e a desnormalização não traria ganho.

Alternativa E — ❌ Incorreta

Criar uma terceira tabela com UNION não é uma técnica de otimização de desempenho para essa transação. UNION combina resultados de queries, mas não evita JOINs. Além disso, o UNION exige que as colunas sejam compatíveis; as tabelas RCLM_CLIENTE e TP_MTVO_RCLM têm estruturas diferentes. A proposta não atende ao cenário.

Conclusão: A única alternativa que corretamente propõe uma solução de projeto físico para alta performance é a letra B, utilizando desnormalização com base na estabilidade dos dados.

Gabarito: letra B.

Link permanente: /questoes/fc020504