Uma empresa de e-commerce está enfrentando problemas de redundância e inconsistência em seu sistema de gerenciamento de pedidos. O analista de sistemas foi incumbido de analisar a estrutura inicial do banco de dados para identificar possíveis violações às formas normais, visando melhorar a integridade dos dados. A tabela abaixo, denominada Pedidos, representa a estrutura original, sem nenhuma normalização aplicada previamente. Considere que a chave primária dessa tabela é composta pelos atributos (ClienteID, PedidoID, ProdutoID): Considerando esta situação, assinale a alternativa correta sobre a normalização da tabela:
- A)A estrutura viola a Segunda FormaNormal (2FN), pois há atributos que dependem apenas parcialmente da chave primária composta.
Correta, porque há atributos que dependem apenas de parte da chave primária composta, caracterizando violação da 2FN.
- B)A estrutura apresenta violação da Primeira Forma Normal (1FN), devido à presença de atributos compostos ou multivalorados.
Errada, porque a questão não indica atributos multivalorados ou grupos repetidos, que seriam problema de 1FN.
- C)A tabela está devidamente normalizada até a Terceira Forma Normal (3FN), não apresentando redundâncias nem dependências indiretas.
Errada, pois a tabela não está normalizada até a 3FN se já existe violação da 2FN por dependência parcial.
- D)A estrutura viola a Terceira Forma Normal (3FN), pois há dependências transitivas, como NomeCliente depender de ClienteID, que por sua vez depende de PedidoID.
Errada, porque o problema principal não é dependência transitiva, e sim dependência parcial em chave composta.
Gabarito: A
Quando a tabela tem chave primária composta, o primeiro alerta é simples: pergunte se algum atributo depende da chave inteira ou só de uma parte dela. Se depender apenas de um pedacinho da chave, a estrutura já cai na Segunda Forma Normal (2FN). E foi exatamente isso que aconteceu aqui. Na tabela Pedidos, a chave é formada por (ClienteID, PedidoID, ProdutoID). Só que atributos como NomeCliente, EnderecoCliente, DataPedido e talvez outros não precisam de toda essa combinação para existir. NomeCliente, por exemplo, depende de ClienteID; DataPedido depende de PedidoID; e DescricaoProduto depende de ProdutoID. Isso cria dependências parciais, que são vedadas pela 2FN. Ou seja: a tabela pode até estar em 1FN, se os campos forem atômicos, mas não passa da 2FN porque mistura informações de cliente, pedido e produto na mesma estrutura. O caminho correto seria separar em tabelas como Cliente, Pedido, Produto e uma tabela de itens do pedido. Assim, você elimina redundância e evita a famosa bagunça de atualizar o mesmo dado em vários lugares. A alternativa A está certa porque identifica exatamente essa regra: em chave composta, nenhum atributo não-chave deve depender apenas de parte da chave. Esse é um conceito clássico de normalização, usado em teoria de bancos de dados e cobrado com frequência em prova.