Questão de Banco de Dados — Consultas e Comandos em SQL — Quadrix 2024

Consultas SQL com JOIN e subconsulta no MySQL

Gabarito: ERRADO (letra E). A consulta apresentada não retorna os artigos da revista RECEN com seus autores porque o INNER JOIN é feito entre Artigos e Autores sem a tabela de ligação Autor_Artigo, o que gera um produto cartesiano entre as duas tabelas, e não a associação correta. Para relacionar artigos e autores, é obrigatório incluir a tabela Autor_Artigo no JOIN, pois é ela que contém as chaves estrangeiras que ligam as duas entidades.

O problema central está na ausência da tabela associativa Autor_Artigo na cláusula FROM e no JOIN. No modelo relacional apresentado, a relação entre Artigos e Autores é muitos-para-muitos, materializada pela tabela Autor_Artigo, que possui as chaves estrangeiras AutorID e ArtigoID. Sem essa tabela, o INNER JOIN entre Artigos e Autores não tem condição de junção válida, resultando em um produto cartesiano: cada artigo seria combinado com todos os autores, independentemente de serem os autores reais daquele artigo. A consulta correta precisaria incluir Autor_Artigo no FROM e fazer os JOINs adequados, como em FROM Artigos INNER JOIN Autor_Artigo ON Artigos.ArtigoID = Autor_Artigo.ArtigoID INNER JOIN Autores ON Autor_Artigo.AutorID = Autores.AutorID.

Além disso, há um detalhe adicional: a subconsulta filtra por Nome = 'NomeDaRevista', mas o enunciado pede a revista RECEN. Mesmo que a subconsulta estivesse correta, o filtro deveria ser Nome = 'RECEN'. Esse é um erro secundário, mas reforça a incorreção do comando.

Para entender a gravidade do erro, é essencial compreender o papel da tabela associativa em um relacionamento muitos-para-muitos. No modelo relacional, quando duas entidades têm relação N:N, é necessário criar uma tabela intermediária que armazene as chaves estrangeiras de ambas. No caso, Autor_Artigo é essa tabela, com chave primária composta por AutorID e ArtigoID. Sem ela, não há como saber quais autores escreveram quais artigos. O INNER JOIN direto entre Artigos e Autores não encontra colunas em comum para a condição de junção, então o SGBD combina cada linha de Artigos com cada linha de Autores, gerando um produto cartesiano. Isso retornaria um número de linhas igual ao produto do número de artigos pelo número de autores, o que é incorreto.

A pegadinha da banca está em apresentar uma consulta que parece plausível, mas que omite a tabela de ligação. O candidato que não conhece o modelo de dados pode não perceber que falta o JOIN com Autor_Artigo. Para resolver corretamente, seria necessário:

SELECT Artigos.Titulo AS TituloArtigo, Autores.Nome AS NomeAutor
FROM Artigos
INNER JOIN Autor_Artigo ON Artigos.ArtigoID = Autor_Artigo.ArtigoID
INNER JOIN Autores ON Autor_Artigo.AutorID = Autores.AutorID
WHERE Artigos.RevistaID = (SELECT RevistaID FROM Revistas WHERE Nome = 'RECEN');

Essa consulta inclui a tabela associativa e faz os dois JOINs necessários, além de filtrar corretamente pela revista RECEN.

Item — ❌ Errado

A afirmação está incorreta porque a consulta não utiliza a tabela Autor_Artigo, essencial para o relacionamento muitos-para-muitos entre Artigos e Autores. O INNER JOIN entre Artigos e Autores sem condição de junção gera um produto cartesiano, retornando combinações incorretas. Além disso, a subconsulta filtra por 'NomeDaRevista' em vez de 'RECEN', o que também está errado. Para a consulta funcionar, seria necessário incluir Autor_Artigo no FROM e fazer os JOINs adequados, além de corrigir o filtro da subconsulta.

Gabarito: letra E — a afirmação está errada.