Questão de Tecnologia da Informação · FGV STN 2024 (nº 40)

A Forma Normal Boyce-Codd (BCNF) é uma regra de normalização de bancos de dados que exige que, para cada dependência funcional (DF) não trivial $X \rightarrow Y$ em uma tabela, o determinante $X$ seja uma superchave. Uma superchave é qualquer conjunto de atributos que contém uma chave candidata (um conjunto mínimo de atributos que identifica unicamente cada linha da tabela). Em termos simples, em BCNF, apenas superchaves podem determinar outros atributos.

Vamos analisar a questão:
Tabela: T (C, H, N, P)
Dependências Funcionais (DFs) identificadas:

1. C \rightarrow H\
2. C \rightarrow P\
3. C \rightarrow N\
4. $P \rightarrow C$

Comando SQL:
create table T ( C int not null unique, H int null unique, P int null unique, N int not null )

Análise Inicial:

1. Chaves Candidatas (CKs) a partir das DFs:
   • $C^+ = \{C, H, P, N\}$ (C determina todos os atributos, então C é uma CK).
   • $P^+ = \{P, C, H, N\}$ (P determina todos os atributos, pois $P \rightarrow C$ e $C \rightarrow H, C \rightarrow P, C \rightarrow N$. Então P é uma CK).
   • CKs identificadas pelas DFs: {C}, {P}.
2. Chaves Candidatas (CKs) a partir do SQL:
   • C int not null unique: C é uma CK.
   • P int null unique: P é uma CK.
   • H int null unique: H é uma CK.
   • CKs identificadas pelo SQL: {C}, {P}, {H}.

O Conflito:
O SQL declara H como uma chave candidata (UNIQUE), mas as DFs fornecidas não implicam que H seja uma CK. Para H ser uma CK, $H \rightarrow C, H \rightarrow P, H \rightarrow N$ deveriam ser verdadeiras. No entanto, a partir das DFs dadas, $H^+ = \{H\}$, o que significa que H não é uma CK. Essa é a inconsistência que a questão pede para resolver, garantindo que o esquema esteja em BCNF. Precisamos adicionar uma DF que torne H uma CK e que, com todas as DFs, o esquema esteja em BCNF.

Análise das Alternativas:

• A) C, H, P -> N

  • Incorreta: O determinante $\{C, H, P\}$ é um superconjunto de C, que já é uma CK. Portanto, $\{C, H, P\}$ já é uma superchave. Adicionar esta DF não resolve a inconsistência de H não ser uma CK e não introduz uma violação de BCNF.

• (B) Correta: H -> P

  • Por que é o gabarito: Se adicionarmos a DF $H \rightarrow P$ ao conjunto existente:
    1. Novas DFs: $C \rightarrow H, C \rightarrow P, C \rightarrow N, P \rightarrow C, H \rightarrow P$.
    2. Verificando se H se torna uma CK:
       • $H \rightarrow P$ (adicionada)
       • $P \rightarrow C$ (dada) $\implies H \rightarrow C$ (por transitividade)
       • $C \rightarrow H$ (dada) $\implies C \leftrightarrow H$ (C e H são chaves equivalentes)
       • $C \rightarrow N$ (dada) e $C \leftrightarrow H \implies H \rightarrow N$
       • Portanto, $H^+ = \{H, P, C, N\}$. H agora determina todos os atributos, tornando-o uma Chave Candidata, consistente com a declaração UNIQUE no SQL.
    3. Verificando BCNF:
       • As chaves candidatas agora são {C}, {P}, {H} (pois $C \leftrightarrow P \leftrightarrow H$).
       • Para cada DF no novo conjunto:
         • $C \rightarrow H$: C é CK. OK.
         • $C \rightarrow P$: C é CK. OK.
         • $C \rightarrow N$: C é CK. OK.
         • $P \rightarrow C$: P é CK. OK.
         • $H \rightarrow P$: H é CK. OK.
       • Todos os determinantes são superchaves. Assim, o esquema está em BCNF e a inconsistência de H como CK é resolvida.

• C) N -> P

  • Incorreta: Se adicionarmos $N \rightarrow P$:
    1. Novas DFs: $C \rightarrow H, C \rightarrow P, C \rightarrow N, P \rightarrow C, N \rightarrow P$.
    2. Verificando se H se torna uma CK:
       • $H^+ = \{H\}$. H não se torna uma CK. Embora $N \rightarrow P \rightarrow C \rightarrow H$ implique $N \rightarrow H$, não há DFs que comecem com H para determinar outros atributos.
       • Portanto, esta opção não resolve a inconsistência de H ser declarado UNIQUE mas não ser uma CK.
    3. Armadilha: Esta alternativa pode ser tentadora porque, se considerarmos apenas as DFs e as chaves que elas implicam ({C}, {P}, {N}), o esquema estaria em BCNF (pois N se torna uma CK). No entanto, ela falha em resolver a inconsistência crucial com a restrição UNIQUE de H no SQL.

• D) N -> H

  • Incorreta: Se adicionarmos $N \rightarrow H$:
    1. Novas DFs: $C \rightarrow H, C \rightarrow P, C \rightarrow N, P \rightarrow C, N \rightarrow H$.
    2. Verificando CKs: $N^+ = \{N, H\}$. N não é uma CK.
    3. Verificando BCNF: A DF $N \rightarrow H$ tem N como determinante, mas N não é uma superchave. Isso cria uma violação de BCNF, em vez de resolvê-la.

• E) P, H -> C

  • Incorreta: O determinante $\{P, H\}$ é um superconjunto de P, que já é uma CK. Portanto, $\{P, H\}$ já é uma superchave. Adicionar esta DF não resolve a inconsistência de H não ser uma CK e não introduz uma violação de BCNF.