Durante uma análise das rotinas do sistema, o analista deparou‑se com o script SQL a seguir, utilizado diariamente para gerar relatórios financeiros de fisioterapeutas cadastrados. SELECT p.nome, c.cidade, COUNT(a.id) AS total_atendimentos, SUM(a.valor) AS receita_total FROM Profissional p INNER JOIN Atendimento a ON p.id = a.id_profissional LEFT JOIN Clinica c ON a.id_clinica = c.id WHERE p.especialidade = ‘Fisioterapia’ GROUP BY p.nome, c.cidade HAVING COUNT(a.id) > 10 ORDER BY receita_total DESC; Com base nessa situação hipotética e a partir da análise estrutural dessa query e dos conceitos fundamentais de banco de dados, julgue o item seguinte. No contexto apresentado, a tabela Atendimento funciona como tabela de relacionamento ao vincular profissionais e clínicas por meio de chaves estrangeiras.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
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”.
Tabela de relacionamento no modelo relacional
Gabarito: CERTO (letra C). A tabela Atendimento atua como tabela de relacionamento (ou tabela associativa) ao conectar Profissional e Clinica por meio de chaves estrangeiras (id_profissional e id_clinica), representando a associação entre essas entidades no modelo relacional.
No modelo relacional, uma tabela de relacionamento (também chamada de tabela associativa, tabela de junção ou tabela de ligação) é criada para representar um relacionamento muitos-para-muitos (N:N) entre duas entidades. Ela armazena as chaves estrangeiras das entidades envolvidas, formando uma chave primária composta, e pode conter atributos próprios do relacionamento. No script apresentado, a tabela Atendimento possui id_profissional (chave estrangeira referenciando Profissional) e id_clinica (chave estrangeira referenciando Clinica), além de atributos como id, valor e outros. Isso caracteriza exatamente uma tabela de relacionamento: ela não representa uma entidade independente do mundo real, mas sim a associação entre um profissional e uma clínica em um atendimento.
A consulta SQL ilustra bem esse papel: o INNER JOIN entre Profissional e Atendimento usa p.id = a.id_profissional, e o LEFT JOIN entre Atendimento e Clinica usa a.id_clinica = c.id. A tabela Atendimento é o ponto central que liga as duas outras tabelas, permitindo agregar dados (contagem de atendimentos e soma de valores) por profissional e cidade. Sem essa tabela de relacionamento, seria impossível representar diretamente a relação entre profissionais e clínicas no modelo relacional, pois seria necessário duplicar dados ou criar estruturas inadequadas.
É importante distinguir a tabela de relacionamento de uma tabela comum (entidade). Uma entidade representa um conceito do mundo real com existência própria (ex.: Profissional, Clinica), enquanto uma tabela de relacionamento existe apenas para conectar duas ou mais entidades, podendo carregar atributos descritivos do próprio relacionamento (ex.: data do atendimento, valor cobrado). No caso, Atendimento carrega atributos como valor, que são propriedades do relacionamento entre profissional e clínica, reforçando seu papel de tabela associativa.
A pegadinha que a banca explora aqui é a confusão entre "tabela de relacionamento" e "tabela de entidade". O candidato pode achar que Atendimento é uma entidade independente (como um serviço prestado), mas, na estrutura apresentada, ela funciona como elo entre Profissional e Clinica, pois contém as chaves estrangeiras de ambas. O termo "tabela de relacionamento" é usado no modelo relacional para designar exatamente essa tabela que materializa a associação N:N, e é isso que a assertiva afirma.
Item — ✅ CERTO
A afirmativa está correta. A tabela Atendimento contém as colunas id_profissional e id_clinica, que são chaves estrangeiras referenciando, respectivamente, as tabelas Profissional e Clinica. Isso a caracteriza como tabela de relacionamento, pois ela vincula as duas entidades por meio dessas chaves. No modelo relacional, essa é a forma padrão de representar um relacionamento muitos-para-muitos (N:N) entre Profissional e Clinica, permitindo que um profissional atenda em várias clínicas e uma clínica tenha vários profissionais. A consulta SQL confirma essa função ao usar Atendimento como ponto de junção entre as duas tabelas.