Banco de Dados · FGV · 2025 | Questão sqc-fg115307

Normalização e implementação física no PostgreSQL

Gabarito: letra A. A questão cobra a tradução de um modelo lógico normalizado (Notação Crow's Foot) para um script SQL físico no PostgreSQL, com a correta definição das chaves primárias (PK), chaves estrangeiras (FK) e integridade referencial. A alternativa A é a única que implementa fielmente as cardinalidades e dependências do modelo, criando as tabelas com as PKs corretas e as FKs com as cláusulas REFERENCES adequadas, garantindo a integridade referencial exigida. A normalização de dados é o processo de organizar as tabelas de um banco relacional para reduzir redundâncias e evitar anomalias de inserção, exclusão e atualização. O processo é guiado pelas formas normais (1FN, 2FN, 3FN, BCNF, etc.), cada uma impondo uma condição mais forte que a anterior. A 1FN exige atributos atômicos (sem valores multivalorados); a 2FN exige que todo atributo não chave dependa da chave primária inteira (eliminando dependências parciais); a 3FN exige que não haja dependências transitivas entre atributos não chave. No modelo da questão, as entidades foram normalizadas, e o desafio é transformar esse modelo lógico em um script SQL físico correto.

No PostgreSQL, a implementação de um modelo relacional envolve comandos DDL (CREATE TABLE), definição de chaves primárias (PRIMARY KEY), chaves estrangeiras (FOREIGN KEY ou REFERENCES) e restrições de integridade. A integridade referencial garante que um valor de chave estrangeira em uma tabela corresponda a um valor de chave primária existente na tabela referenciada, mantendo a consistência dos dados. A notação Crow's Foot indica as cardinalidades dos relacionamentos: por exemplo, um relacionamento 1:N (um para muitos) significa que uma entidade pode estar associada a várias ocorrências de outra, e a chave estrangeira deve ser colocada na tabela do lado "muitos". A pegadinha central desta questão é que o candidato precisa ler o modelo de dados (que não está transcrito aqui) e identificar corretamente: (1) quais são as chaves primárias de cada entidade; (2) em qual tabela deve ser inserida a chave estrangeira de cada relacionamento; (3) se a cardinalidade mínima é 0 (opcional) ou 1 (obrigatória), o que influencia o uso de NOT NULL ou a necessidade de tabelas de ligação em relacionamentos muitos-para-muitos (N:N). A alternativa A é a única que reflete essas decisões corretamente, enquanto as demais contêm erros como: FK no lado errado, ausência de REFERENCES, cardinalidades mal interpretadas, ou tabelas desnecessárias. O critério decisivo é: para cada relacionamento, a FK deve estar na tabela do lado N (muitos), e a cardinalidade mínima 1 exige NOT NULL na FK, enquanto a mínima 0 permite NULL. Guarde esse critério — é exatamente nele que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa A implementa corretamente o modelo normalizado: cria as tabelas com as chaves primárias adequadas e define as chaves estrangeiras com REFERENCES, respeitando as cardinalidades do modelo Crow's Foot. A integridade referencial é garantida pela cláusula FOREIGN KEY, que assegura que os valores da FK existam na tabela referenciada. Esta é a única alternativa que traduz fielmente o modelo lógico para o físico.

Alternativa B — ❌ Incorreta

Esta alternativa provavelmente inverte o lado da chave estrangeira em um relacionamento 1:N, colocando a FK na tabela do lado "1" (um) em vez do lado "N" (muitos). Isso viola a modelagem relacional: a FK deve sempre estar na tabela que representa o lado muitos do relacionamento, pois é ela que armazena a referência à entidade pai. Colocar a FK no lado um criaria redundância e quebraria a integridade referencial.

Alternativa C — ❌ Incorreta

O erro aqui pode estar na interpretação da cardinalidade mínima: se o modelo indica que a participação é obrigatória (mínima 1), a coluna FK deve ser definida com NOT NULL. Esta alternativa provavelmente omite a restrição NOT NULL, permitindo que a FK seja nula, o que contraria a cardinalidade mínima 1 do modelo. Alternativamente, pode estar criando uma tabela de ligação desnecessária para um relacionamento que é 1:N, em vez de simplesmente adicionar a FK na tabela correta.

Alternativa D — ❌ Incorreta

Esta alternativa pode conter erro na definição das chaves primárias: pode estar definindo uma PK composta onde o modelo indica uma PK simples, ou pode estar usando uma coluna como PK que não é a chave candidata correta. Também pode estar omitindo a cláusula REFERENCES em uma FK, o que quebraria a integridade referencial — sem REFERENCES, o PostgreSQL não valida se o valor da FK existe na tabela pai, permitindo dados órfãos.

Alternativa E — ❌ Incorreta

O erro desta alternativa pode ser a ausência de definição das chaves estrangeiras, criando tabelas sem os vínculos de integridade referencial. Sem as FKs, o modelo físico não reflete os relacionamentos do modelo lógico, e o banco não garante a consistência entre as tabelas. Alternativamente, pode estar usando tipos de dados incorretos para as chaves (ex.: VARCHAR em vez de INTEGER), o que comprometeria a eficiência e a integridade.

NÃO CAIA NESSA!

A banca adora inverter o lado da chave estrangeira ou omitir a restrição NOT NULL conforme a cardinalidade mínima. No modelo Crow's Foot, a FK sempre fica no lado "muitos" (N), e a cardinalidade mínima 1 exige NOT NULL. Se você identificar essas duas coisas no modelo, elimina as alternativas erradas rapidamente. 💪 💡 Dica: Para traduzir um modelo lógico para SQL físico, siga o passo a passo: (1) identifique cada entidade e sua chave primária; (2) para cada relacionamento 1:N, adicione a FK na tabela do lado N com REFERENCES; (3) para relacionamentos N:N, crie uma tabela de ligação com PK composta pelas duas FKs; (4) verifique a cardinalidade mínima — se for 1, use NOT NULL na FK; se for 0, deixe a coluna anulável. Treine com questões da FGV que cobram a mesma habilidade de leitura de diagramas ER.

Gabarito: letra A