Questão 1794397

• Banca: FCC
• Órgão: MPE-PB
• Ano: 2015
• Provas: FCC - 2015 - MPE-PB - Analista de Sistemas – Administrador de Banco de Dados
• Disciplina: Banco de Dados
• Assuntos: Administração de banco de dados; Gerência de Transações

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: 

• A. Colocar 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.
• B. 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.
• C. Colocar 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.
• D. Desnormalizar 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.
• E. Criar 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.

Gabarito: B

Comentários

• Quando tratamos de Tunning de banco de dados, devemos levar em conta que quanto maior for a normalização das tabelas, menor será o desempenho das consultas devido a possíveis junções que deverão ser realizadas para extrair os dados. Desta forma, a literatura destaca que o DBA deverá sempre analisar o custo benefício do Desempenho X Normalização.

   

  Diante disso podemos elimitar as alternaticas A) e C). A alternativa D) está incorreta pois vai de encontro ao que destaquei acima. Ora, se normalizado já é um problema, imagina inseririndo mais tabelas. 

   

  A alternativa D) é absurda pois os dados da tabela TP_MTVO_RCLM são ESTÁVEIS e por isso  não tem impacto no desempenho.

   

  Portanto a alternativa correta é a A).

   

  avante!

• Como o colega acima pontuou, a desnormalização geralmente aumenta o desempenho. O equívoco da alternativa D está em "primeira forma normal". A primeira forma normal apenas prevê o uso de atributos atômicos (por exemplo, endereço não é atômico porque inclui rua, cidade, CEP etc.). A terceira forma normal trata da ausência de dependência transitiva (o atributo deve depender apenas da chave primária). O atributo de descrição da reclamação, ao ser inserido na tabela RCLM, fere a terceira forma normal, porque depende de outros atributos da referida tabela (são 150 linhas de tipo para 30.000 linhas de reclamações, ou seja, os tipos se repetem e variam de acordo com as reclamações) não apenas na chave primária. GABARITO: B