A alternativa correta é a B: Criar as tabelas MUNICIPIO, ORGAO, AUDITOR e FISCALIZACAO, mantendo nesta última apenas os identificadores do órgão e do auditor, relacionados por chaves estrangeiras, e relacionando cada órgão ao respectivo município.

Justificativa:

A questão descreve um problema clássico de redundância e inconsistência de dados (divergências na grafia), que deve ser resolvido por meio da normalização de banco de dados.

Ao aplicar as regras de normalização:

Entidades Separadas: Os dados que se repetem e geram inconsistências devem ser movidos para tabelas próprias (MUNICIPIO, ORGAO e AUDITOR), garantindo que cada nome seja gravado de forma única (eliminando erros de grafia).

Relacionamentos e Integridade:

Como cada órgão pertence a um único município, a tabela ORGAO deve conter uma chave estrangeira apontando para MUNICIPIO.

Como a tabela FISCALIZACAO registra o evento conduzido por um auditor em um órgão, ela deve conter apenas as chaves estrangeiras (id_orgao e id_auditor), além de seus dados próprios. Não há necessidade de colocar o identificador do município diretamente na fiscalização, pois ele já é obtido indiretamente através do órgão (evitando redundância).

Por que as outras alternativas estão incorretas?

A e D: Mantêm os dados unificados ou criam chaves compostas ineficientes, perpetuando o problema da redundância e da inconsistência de grafia.

C: Sugere a desnormalização voluntária (duplicar os nomes nas duas tabelas), o que mantém o problema original de divergência de grafia ativo.

E: Criar uma tabela física para cada município é uma péssima prática de modelagem de dados, dificultando consultas gerais e a manutenção do sistema.

A alternativa correta é a LETRA B.

• A) Incorreta. Manter todos os campos em uma única tabela mantém a estrutura completamente desnormalizada (violando a 2ª e a 3ª Formas Normais - 2FN e 3FN). Criar uma chave primária composta superdimensionada (id_fiscalizacao, id_orgao, id_municipio, id_auditor) não resolve a dependência funcional transitiva e parcial dos atributos descritivos (nome_municipio, nome_orgao, nome_auditor). As divergências de grafia continuarão acontecendo a cada novo registro inserido na tabela única.

• B) Correta. Aplica rigorosamente os princípios da 3ª Forma Normal (3FN) e da Integridade Referencial:

  1. MUNICIPIO (id_municipio [PK], nome_municipio): Centraliza os dados do município em um único registro.

  2. ORGAO (id_orgao [PK], nome_orgao, id_municipio [FK]): Como cada órgão pertence a um único município, o id_municipio entra como chave estrangeira (FK) em ORGAO.

  3. AUDITOR (id_auditor [PK], nome_auditor): Isolado em sua própria tabela para eliminar repetição do nome do auditor.

  4. FISCALIZACAO (id_fiscalizacao [PK], id_orgao [FK], id_auditor [FK], data...): Armazena apenas os identificadores numéricos das entidades relacionadas via Chaves Estrangeiras (Foreign Keys). Com essa estrutura, a grafia de cada município, órgão ou auditor é cadastrada uma única vez, eliminando redundâncias e divergências.

• C) Incorreta. Trata-se de uma desnormalização indevida. Manter os campos descritivos (nome_orgao, nome_municipio, nome_auditor) na tabela FISCALIZACAO reintroduz exatamente a redundância e o risco de inconsistências de grafia que o problema exigia eliminar.

• D) Incorreta. Apresenta uma falha lógica grave. Eliminar os identificadores numéricos e utilizar campos de texto sujeitos a divergências de grafia (nome_orgao, nome_municipio) como chaves de relacionamento destrói a integridade referencial, além de ser um anti-padrão de modelagem física (chaves primárias textuais e instáveis).

• E) Incorreta. Trata-se de um anti-padrão de particionamento horizontal e criação de tabelas dinâmicas por instância de dado ("uma tabela por município"). Além de violar a teoria relacional, obrigaria a alteração do esqueleto DDL do banco sempre que um novo município fosse cadastrado.

"Cada entidade forte no seu quadrado"

• identificou relacionamentos 1:N com repetição de texto (como nomes de municípios e órgãos), normalize isolando a entidade em tabela própria e use apenas a Chave Estrangeira (FK) na tabela dependente.