Um Ministério Público Estadual mantém cadastro de membros e servidores para controle de contatos funcionais, e precisa armazenar múltiplos telefones por pessoa (institucional, plantão e gabinete) com histórico auditável. Nesse caso, a modelagem relacional que atende corretamente ao requisito é
Aarmazenar os telefones em um único atributo TELEFONES em formato JSON na tabela PESSOA e impor validação por constraint.
Bcriar colunas TELEFONE1, TELEFONE2 e TELEFONE3 na tabela PESSOA, mantendo um telefone por coluna e permitindo nulos.
Carmazenar os telefones em um único atributo TELEFONES na tabela PESSOA, separados por delimitador, preservando a ordem de cadastro.
Drepresentar telefones como atributo multivalorado no MER e persistir esse atributo em uma única coluna do tipo ARRAY no banco relacional.
Ecriar a tabela TELEFONE_PESSOA com chave primária própria e chave estrangeira para PESSOA, mantendo um telefone por linha e atributos como TIPO.
Revelar gabarito e comentário▾
GabaritoE — criar a tabela TELEFONE_PESSOA com chave primária própria e chave estrangeira para PESSOA, mantendo um telefone por linha e atributos como TIPO.
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”.
Modelagem relacional: atributo multivalorado e tabela associativa
Gabarito: letra E. Para armazenar múltiplos telefones por pessoa com histórico auditável, a modelagem relacional correta é criar uma tabela separada TELEFONE_PESSOA com chave primária própria e chave estrangeira para PESSOA, mantendo um telefone por linha e atributos como TIPO — é a forma de representar um atributo multivalorado no modelo relacional, garantindo atomicidade e flexibilidade.
O problema central é modelar um atributo multivalorado (uma pessoa pode ter vários telefones) em um banco relacional. O modelo relacional exige que os atributos sejam atômicos — ou seja, cada célula deve conter um único valor. Essa é a base da Primeira Forma Normal (1FN). Quando uma entidade tem um atributo que pode assumir múltiplos valores (como telefones), a solução correta é criar uma nova tabela para representar esse conjunto de valores, ligada à tabela original por uma chave estrangeira. Essa nova tabela é chamada de tabela associativa ou tabela de relacionamento.
A alternativa E descreve exatamente essa solução: uma tabela TELEFONE_PESSOA com chave primária própria (para identificar cada telefone individualmente) e chave estrangeira para PESSOA (para saber a qual pessoa o telefone pertence). O atributo TIPO permite distinguir entre telefone institucional, de plantão ou de gabinete, atendendo ao requisito de classificação. Além disso, essa estrutura permite histórico auditável, pois cada linha pode ter atributos como data de inclusão ou de alteração.
As demais alternativas violam princípios fundamentais do modelo relacional. Armazenar múltiplos valores em um único atributo (JSON, delimitador ou ARRAY) quebra a atomicidade exigida pela 1FN e dificulta consultas, validações e auditoria. Criar colunas fixas (TELEFONE1, TELEFONE2, TELEFONE3) é inflexível e não atende ao requisito de múltiplos telefones sem limite definido. A alternativa D, embora mencione o atributo multivalorado no MER, propõe persistir em uma única coluna ARRAY, o que não é a abordagem relacional clássica.
A pegadinha da banca está em confundir o conceito de atributo multivalorado no modelo conceitual (MER) com sua implementação no modelo relacional. No MER, um atributo multivalorado é representado como um atributo com dupla elipse. No modelo relacional, porém, ele deve ser transformado em uma tabela separada. A alternativa D mistura esses dois níveis de abstração, sugerindo uma implementação não relacional (ARRAY) para um conceito do MER.
Guarde a fronteira: atributo multivalorado no MER vira tabela no modelo relacional. É exatamente nessa distinção que as alternativas se dividem.
Critério
A (JSON)
B (Colunas fixas)
C (Delimitador)
D (ARRAY)
E (Tabela associativa)
Atomicidade (1FN)
❌ Viola
✅ Cada coluna atômica
❌ Viola
❌ Viola
✅ Cada linha atômica
Limite de telefones
✅ Ilimitado
❌ Fixo (3)
✅ Ilimitado
✅ Ilimitado
✅ Ilimitado
Consulta individual por telefone
❌ Difícil
✅ Possível
❌ Difícil
❌ Difícil
✅ Fácil (WHERE)
Classificação por tipo
❌ Complexa
✅ Colunas separadas
❌ Complexa
❌ Complexa
✅ Atributo TIPO
Histórico auditável
❌ Limitado
❌ Limitado
❌ Limitado
❌ Limitado
✅ Linhas com data/versão
Conformidade com modelo relacional
❌ Não
⚠️ Parcial
❌ Não
❌ Não
✅ Total
Alternativa A — ❌ Incorreta
Armazenar telefones em um único atributo JSON viola a atomicidade exigida pelo modelo relacional (1FN). Embora alguns SGBDs modernos suportem JSON, essa abordagem dificulta consultas individuais, validação por constraint e auditoria histórica. O modelo relacional clássico não prevê esse tipo de estrutura.
Alternativa B — ❌ Incorreta
Criar colunas fixas TELEFONE1, TELEFONE2 e TELEFONE3 é inflexível: limita o número de telefones por pessoa e não atende ao requisito de múltiplos telefones sem limite definido. Além disso, colunas com muitos valores nulos são um sinal de modelagem inadequada, indicando que o atributo deveria estar em uma tabela separada.
Alternativa C — ❌ Incorreta
Armazenar telefones em um único atributo separado por delimitador viola a atomicidade e dificulta consultas, validações e auditoria. Essa abordagem é típica de sistemas de arquivos, não de bancos de dados relacionais, e não permite manipular cada telefone individualmente.
Alternativa D — ❌ Incorreta
Embora reconheça o atributo multivalorado no MER, propõe persistir em uma única coluna do tipo ARRAY. Isso não é a implementação relacional correta: o modelo relacional exige que atributos multivalorados sejam transformados em tabelas separadas, não em colunas com múltiplos valores. A alternativa confunde o nível conceitual com o nível físico.
Alternativa E — ✅ Correta ⟵ GABARITO
Criar a tabela TELEFONE_PESSOA com chave primária própria e chave estrangeira para PESSOA é a modelagem relacional correta para atributos multivalorados. Cada telefone fica em uma linha, com atributos como TIPO para classificação (institucional, plantão, gabinete). Essa estrutura garante atomicidade, flexibilidade para qualquer número de telefones e permite histórico auditável com atributos adicionais.