Questão de Informática · FCC BANRISUL 2018 (nº 45)

Quando duas entidades, como Cliente e ContaCorrente, têm um relacionamento muitos-para-muitos (N:M) – onde um Cliente pode ter várias Contas e uma Conta pode pertencer a vários Clientes – você não pode ligá-las diretamente usando apenas chaves estrangeiras em uma das tabelas.

• (A) Incorreta: Colocar a chave primária de Cliente em ContaCorrente permitiria que uma conta tivesse apenas um cliente, e vice-versa, não resolvendo o relacionamento N:M. Fazer as duas coisas ao mesmo tempo é redundante e inviável.
• (B) Incorreta: Uma restrição de integridade referencial direta (chave estrangeira) funciona para relacionamentos um-para-muitos (1:N), mas não para N:M, pois não há como registrar múltiplos valores da chave estrangeira na mesma linha. Armadilha da banca: Esta alternativa é tentadora porque "restrição de integridade referencial" é o mecanismo correto para ligar tabelas, mas a palavra "direta" esconde a complexidade do N:M.
• (C) Incorreta: Embora tabelas possam ter chaves primárias compostas, isso não é uma exigência para as tabelas Cliente e ContaCorrente em si para resolver o relacionamento N:M. A chave primária composta será necessária na tabela de associação, não nas tabelas originais.
• (D) Incorreta: Não existe um conceito padrão de "restrição circular de cardinalidade n:m direta" em bancos de dados relacionais que resolva este problema. Relacionamentos N:M não são implementados diretamente entre as duas tabelas principais.
• (E) Correta: Para implementar um relacionamento muitos-para-muitos (N:M) em um banco de dados relacional, a solução padrão e correta é criar uma tabela de associação (também conhecida como tabela de ligação ou junção). Esta nova tabela conterá as chaves primárias de Cliente e ContaCorrente como chaves estrangeiras, e a combinação dessas duas chaves estrangeiras geralmente formará a chave primária da tabela de associação, permitindo registrar todas as combinações de clientes e contas.