Analise o trecho de código a seguir, escrito em SQL:No código acima, são mostrados os comandos necessários para:
AAlterar a coluna e-mail para opcional e a coluna codigo_cliente para obrigatória.
BExcluir as colunas codigo_cliente e e-mail da tabela cliente.
CExcluir, respectivamente, as restrições de chave estrangeira da coluna codigo_cliente e de chave primária da coluna e-mail.
DAlterar as chaves da tabela cliente, fazendo com que a coluna e-mail passe a ser a chave primária e a coluna codigo_cliente passe a ser uma chave alternativa.
EDefinir a coluna e-mail como chave alternativa e excluir a coluna codigo_cliente.
Revelar gabarito e comentário▾
GabaritoD — Alterar as chaves da tabela cliente, fazendo com que a coluna e-mail passe a ser a chave primária e a coluna codigo_cliente passe a ser uma chave alternativa.
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”.
Comandos DDL: ALTER TABLE e restrições de chave
Gabarito: letra D. O trecho de código executa duas operações de ALTER TABLE sobre a tabela cliente: a primeira adiciona uma restrição PRIMARY KEY à coluna e-mail, e a segunda adiciona uma restrição UNIQUE à coluna codigo_cliente. Isso faz com que e-mail passe a ser a chave primária e codigo_cliente passe a ser uma chave alternativa (candidata). A alternativa D descreve exatamente esse efeito.
O comando ALTER TABLE é a instrução da DDL (Data Definition Language) usada para adicionar, deletar ou modificar colunas em uma tabela existente, bem como para adicionar ou remover restrições (constraints). As restrições são regras aplicadas aos dados de uma tabela, como PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK e DEFAULT. A chave primária identifica exclusivamente cada registro e não aceita valores nulos nem duplicados. Uma chave alternativa (ou chave candidata) é uma coluna ou conjunto de colunas que também poderia servir como chave primária, pois possui valores únicos e não nulos, mas que não foi escolhida para esse papel. No modelo relacional, uma tabela pode ter várias chaves candidatas, mas apenas uma é designada como chave primária; as demais são chamadas de chaves alternativas.
No trecho apresentado, a sintaxe típica seria algo como:
ALTER TABLE cliente ADD PRIMARY KEY (e-mail);
ALTER TABLE cliente ADD UNIQUE (codigo_cliente);
A primeira instrução define e-mail como chave primária. A segunda adiciona uma restrição UNIQUE sobre codigo_cliente, o que a torna uma chave alternativa, pois garante unicidade dos valores, mas não a define como chave primária. É importante notar que a restrição UNIQUE não torna a coluna obrigatória (não implica NOT NULL), mas, no contexto da questão, a coluna codigo_cliente já existia e, ao receber a restrição UNIQUE, passa a ser uma chave candidata.
A pegadinha da questão está em confundir o efeito das restrições: adicionar UNIQUE não exclui a coluna, não altera sua nulidade e não a transforma em chave estrangeira. A banca explora a diferença entre adicionar restrições e modificar a estrutura da coluna (como torná-la opcional ou obrigatória) ou excluí-la. O comando ALTER TABLE ... ADD CONSTRAINT adiciona uma restrição, mas não altera a definição da coluna em si (para isso, seria necessário ALTER COLUMN ou MODIFY COLUMN).
Guarde a distinção entre adicionar restrição (que afeta as regras de integridade) e alterar a coluna (que afeta o tipo, nulidade ou nome): é exatamente nessa fronteira que as alternativas se dividem.
Critério
e-mail (1º comando)
codigo_cliente (2º comando)
Comando executado
ADD PRIMARY KEY
ADD UNIQUE
Efeito na coluna
Vira chave primária
Vira chave alternativa (candidata)
Exclusão da coluna?
Não
Não
Alteração de nulidade?
Não
Não
Remoção de constraint?
Não
Não
Alternativa A — ❌ Incorreta
Afirma que o código altera a coluna e-mail para opcional e codigo_cliente para obrigatória. Isso não ocorre: o código adiciona restrições de chave, não modifica a nulidade das colunas. Para tornar uma coluna opcional ou obrigatória, seria necessário usar ALTER COLUMN ... DROP NOT NULL ou ALTER COLUMN ... SET NOT NULL, o que não está presente no trecho.
Alternativa B — ❌ Incorreta
Afirma que o código exclui as colunas codigo_cliente e e-mail. Isso é falso: o comando ALTER TABLE ... DROP COLUMN seria necessário para excluir colunas, e o trecho não contém DROP COLUMN. O código apenas adiciona restrições, não remove colunas.
Alternativa C — ❌ Incorreta
Afirma que o código exclui restrições de chave estrangeira e de chave primária. O trecho não contém DROP CONSTRAINT nem DROP FOREIGN KEY; ele adiciona restrições (ADD PRIMARY KEY e ADD UNIQUE), não as remove. Além disso, a coluna e-mail não é chave estrangeira, e codigo_cliente não é chave primária no contexto apresentado.
Alternativa D — ✅ Correta ⟵ GABARITO
O código adiciona uma restrição PRIMARY KEY à coluna e-mail, tornando-a a chave primária da tabela, e adiciona uma restrição UNIQUE à coluna codigo_cliente, o que a caracteriza como chave alternativa (candidata). Isso corresponde exatamente ao que a alternativa descreve: "Alterar as chaves da tabela cliente, fazendo com que a coluna e-mail passe a ser a chave primária e a coluna codigo_cliente passe a ser uma chave alternativa".
Alternativa E — ❌ Incorreta
Afirma que o código define e-mail como chave alternativa e exclui a coluna codigo_cliente. Há dois erros: primeiro, e-mail é definida como chave primária, não alternativa; segundo, não há DROP COLUMN para excluir codigo_cliente. O código adiciona UNIQUE a codigo_cliente, não a exclui.
No código acima, são mostrados os comandos necessários para: