3
respostas

[Sugestão] Questão ambígua

A solução indicada no exercício é: Criar duas tabelas: Produtos(ProdutoID, NomeProduto, Categoria, Preço, FornecedorID) e Fornecedores(FornecedorID, NomeFornecedor, TelefoneFornecedor).

Mas não especifica as regras de negócio e a resolução fica ambígua. Alguma regra de negócio deveria ser usada no enunciado pois poderíamos ou não ter um produto que é fornecido por mais de um fornecedor e isso nao está explícito.

Fora que pelos exemplos das aulas, eu poderia precisar criar uma tabela de contato do fornecedores, dado que um fornecedor pode ter mais de um telefone.... Então a tabela de Fornecedores sugerida na resposta nao estaria na 1FN.

3 respostas

Olá, Tamires, bom dia.

Entendo sua dúvida, mas, segundo os dados da questão, essa era a única resposta possível. As regras de negócio estão implícitas na tabela original, removendo ambiguidades:

Dado a questão

Você é um analista de dados contratado por uma empresa de e-commerce para otimizar o banco de dados de produtos. Atualmente, a tabela de produtos contém as seguintes colunas: ProdutoID, NomeProduto, Categoria, Preço, FornecedorID, NomeFornecedor, TelefoneFornecedor. Seu objetivo é aplicar a segunda forma normal (2FN) para eliminar dependências parciais e melhorar a eficiência do banco de dados.

Se a tabela atual contém um produto com FornecedorID e TelefoneFornecedor, está implícito que só há um fornecedor por produto, e um telefone por fornecedor. Se assim não o fosse, esses campos seriam arrays, e se chamariam FornecedorIDs ou FornecedoresID ou IDFornecedores ou Fornecedores, e TelefonesFornecedor ou TelefonesFornecedores (e aí já teria que ser um objeto, em caso de múltiplos telefones e fornecedores, tornando esse campo inviável).

Portanto, para a tabela original que foi apresentada, a menos que a regra de negócio daquela tabela estivesse incorreta, algo que seria uma suposição que os dados da questão não alimentam, a única solução possível seria separar em duas tabelas, dada a relação de muitos para um entre produtos e fornecedor, com cada fornecedor contendo apenas um telefone associado.

Mas que bom que consegue imaginar essas outras possibilidades, isso indica que consegue projetar possíveis problemas, só lhe faltou mesmo ler mais atentamente os requisitos, mas isso se dá com prática.

Bons estudos sempre!

Olá,

Eu reparei que o nome das colunas não estão no plural, neste quesito não me faltou atenção. Você pode achar que está implícito que a tabela tenha um produto por fornecedor porque a amostra de dados (que no enunciado nem tem) não mostra o contrário, ou talvez você tenha elaborado o enunciado e para você está óbvio que é assim. Mas se um aluno chega para você com essa dúvida, e como você bem disse "imaginando essas outras possibilidades" é por que o enunciado é vago e dá margem para isso.

O fato de o nome de uma coluna chamar-se 'TelefoneFornecedor' pode deixar implícito que o campo nao é um array, mas poderia muito bem significar que existe um telefone por linha e que o FornecedorID se repetisse a cada ocorrencia de Telefone. Não se sabe como esta suposta tabela de produtos está "estruturada", ou melhor, o quão desestruturada ela está.

Então como havia dito, o enunciado está vago, ambiguo e dando margem para múltiplas respostas corretas (se quiser posso listá-las à você). Sugiro fortemente que reformulem. Afinal, não é a primeira vez que eu encontro um enunciado mal formulado aqui na plataforma... eu entendo que você ache que o enunciado está com as "informações implícitas" afinal você deve ser expert em banco de dados, só lhe faltou mesmo ser mais crítico com a redação do enunciado e olhar a questão com os olhos do aluno.

Atenciosamente,

Calma, Tamires, eu também sou aluno, eu não fiz o enunciado, eu nem fiz esse curso ainda, só tenho experiência na área, e isso me ajudou a conseguir responder a pergunta. Só estava comentando pois uma boa análise de requisitos é algo que é pedido por nós no mercado, e é importante que consigamos desenvolver essas habilidades.

Não, eu não sou nenhum especialista em bancos de dados, quem me dera, eu só trabalhei com eles, e tenho a opinião que, questões que nos ajudem a desenvolver habilidades de análise de requisitos são questões importantes, pois no mercado, muitas vezes a gente não tem informações detalhadas, só um card com a task, e, como atuei principalmente como freelancer, muitas vezes nem isso.

Nós não temos uma amostra de dados nessa questão, e por isso, devemos tentar inferir como é a tabela a partir dos dados que temos. Entendo que estamos todos estudando aqui, e por isso, podemos ter dificuldade e não pegar de primeira, é assim mesmo. Por isso também fiz aquele comentário, para explicar como podemos entender como a tabela está organizada, mesmo sem ter todos os dados, pois, às vezes, como nesse caso, somente esses dados bastavam, mas isso só se descobre com prática. Não tem problema nenhum errar essas questões, é assim que se aprende. Nós aprendemos muito mais com nossos erros que com nossos acertos, e por isso expliquei como chegar na resposta a partir dos dados apresentados.

É assim mesmo que a gente aprende. Fiz aquele post para explicar a resposta, pois, é assim que a gente aprende. Eu sou dev, e apendi muito mais no começo, errando, e depois sofrendo com esses erros, que depois, quando já estava adaptado, e passava a maior parte do tempo fazendo do jeito certo a mesma coisa que eu já tinha feito 10 outras vezes.

De qualquer forma, bons estudos, espero que minha intenção e meus comentários lhe cheguem bem!