Durante a implementação de um banco de dados, um desenvolvedor utiliza a Linguagem de Definição de Dados (DDL) para criar uma tabela para armazenar informações sobre clientes. Considere o seguinte comando SQL:Assinale a opção correta.
AO campo Email pode conter valores duplicados, pois a DDL não impõe restrições de unicidade por padrão.
BO comando cria a tabela Clientes com uma coluna ClienteID que não pode ser nula, uma vez que é definida como chave primária.
CO campo DataCadastro não será preenchido automaticamente se o usuário não inserir um valor, pois não possui um valor padrão.
DA DDL permite a criação de tabelas, mas não pode ser usada para definir restrições de integridade, como chaves primárias ou únicas.
EO comando falhará na execução se a tabela Clientes já existir, pois a DDL não permite a substituição de tabelas.
Revelar gabarito e comentário▾
GabaritoB — O comando cria a tabela Clientes com uma coluna ClienteID que não pode ser nula, uma vez que é definida como chave primária.
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: CREATE TABLE e restrições de integridade
Gabarito: letra B. A chave primária (PRIMARY KEY) impõe, por definição, a restrição de não nulidade (NOT NULL) sobre a coluna que a compõe — no comando, a coluna ClienteID é declarada como chave primária, logo não pode conter valores nulos. As demais alternativas distorcem conceitos da DDL: a DDL pode definir restrições de integridade (letra D errada), o DataCadastro pode ser preenchido automaticamente por um valor padrão (letra C errada), e a DDL permite substituir tabelas com DROP TABLE ou CREATE TABLE IF NOT EXISTS (letra E errada).
A DDL (Data Definition Language) é a sublinguagem do SQL responsável por definir a estrutura do banco de dados — criar, alterar e remover objetos como tabelas, índices, visões e restrições. Seus comandos principais são CREATE, ALTER e DROP (e, em alguns SGBDs, TRUNCATE). É uma linguagem declarativa: o usuário especifica o que deve ser criado, não como o SGBD deve executar. O comando CREATE TABLE é o coração da DDL para criação de tabelas, e é nele que se declaram as colunas, os tipos de dados e as restrições de integridade — como PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL e CHECK. Essas restrições são parte essencial da definição do esquema, garantindo a consistência dos dados.
A chave primária é o conceito central desta questão. Ela identifica de forma única cada linha da tabela e, por isso, o padrão SQL impõe duas propriedades: unicidade (não pode haver duas linhas com o mesmo valor) e não nulidade (nenhum componente da chave pode ser NULL). Na prática, ao declarar ClienteID INT PRIMARY KEY, o SGBD cria automaticamente uma restrição NOT NULL sobre essa coluna — mesmo que o NOT NULL não seja escrito explicitamente. É exatamente isso que a alternativa B afirma, e é por isso que ela está correta.
Vamos analisar cada alternativa com cuidado, pois a banca explora confusões comuns entre DDL, DML e as propriedades das restrições.
Alternativa A — ❌ Incorreta
Afirma que o campo Email pode conter valores duplicados porque a DDL não impõe restrições de unicidade por padrão. O erro está na generalização: a DDL pode impor unicidade, e isso depende de como a coluna é declarada. Se o Email fosse definido com a restrição UNIQUE, valores duplicados seriam proibidos. A ausência de UNIQUE no comando (que não vemos na imagem) permitiria duplicatas, mas a justificativa apresentada — "a DDL não impõe restrições de unicidade por padrão" — é falsa, pois a DDL é justamente o mecanismo para definir tais restrições. A alternativa confunde a ausência de uma restrição específica com uma incapacidade da linguagem.
Alternativa B — ✅ Correta ⟵ GABARITO
A alternativa está correta porque a chave primária (PRIMARY KEY) impõe, por definição, a restrição NOT NULL sobre a coluna ClienteID. O padrão SQL determina que toda chave primária é implicitamente NOT NULL — não é possível inserir um valor nulo em uma coluna que faz parte da chave primária. Isso é uma propriedade fundamental do modelo relacional: a chave primária identifica cada linha de forma única, e um valor nulo não pode identificar nada. Portanto, a afirmação de que ClienteID "não pode ser nula, uma vez que é definida como chave primária" está tecnicamente correta.
Alternativa C — ❌ Incorreta
Afirma que o campo DataCadastro não será preenchido automaticamente se o usuário não inserir um valor, pois não possui um valor padrão. O erro está na conclusão: a ausência de um valor padrão (DEFAULT) não impede o preenchimento automático. Em muitos SGBDs, é possível definir um valor padrão com a cláusula DEFAULT, como DataCadastro DATE DEFAULT CURRENT_DATE, que preencheria a coluna automaticamente. Além disso, mesmo sem DEFAULT, o campo poderia ser preenchido por um TRIGGER ou por uma aplicação. A alternativa confunde a ausência de DEFAULT com a impossibilidade de preenchimento automático — o que não é verdade.
Alternativa D — ❌ Incorreta
Afirma que a DDL permite criar tabelas, mas não pode ser usada para definir restrições de integridade, como chaves primárias ou únicas. Isso é falso: a DDL é exatamente a linguagem usada para definir restrições de integridade. No comando CREATE TABLE, é possível declarar PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL e CHECK diretamente na definição da tabela. A alternativa inverte o papel da DDL, que é justamente o de estruturar o esquema e suas regras de integridade.
Alternativa E — ❌ Incorreta
Afirma que o comando falhará se a tabela Clientes já existir, pois a DDL não permite a substituição de tabelas. O erro está na segunda parte: a DDL permite substituir tabelas, mas não com o mesmo comando CREATE TABLE — é necessário usar DROP TABLE para remover a tabela existente e depois CREATE TABLE novamente, ou usar CREATE TABLE IF NOT EXISTS (em alguns SGBDs) para evitar erro. A alternativa confunde a impossibilidade de recriar uma tabela com o mesmo nome sem antes removê-la com a ideia de que a DDL não permite substituição. Na verdade, a DDL oferece mecanismos para isso, como DROP TABLE e ALTER TABLE.
NÃO CAIA NESSA!
A banca explora a confusão entre o que a DDL pode fazer e o que um comando específico faz. A letra D é a mais traiçoeira: parece plausível para quem não sabe que a DDL define restrições, mas é justamente o contrário — a DDL é a ferramenta para criar chaves primárias, únicas e estrangeiras. A letra E também induz ao erro: o CREATE TABLE falha se a tabela existir, mas a DDL como um todo permite substituição via DROP/ALTER. Fique atento: a banca adora inverter o papel das sublinguagens (DDL vs. DML) e as propriedades das restrições.
PEGA ESSA DICA!
Para questões de DDL, lembre-se do papel de cada sublinguagem: DDL define estrutura (CREATE, ALTER, DROP), DML manipula dados (INSERT, UPDATE, DELETE), DCL controla acesso (GRANT, REVOKE). E guarde as propriedades da chave primária: única e não nula. Se a alternativa falar que a chave primária pode ser nula, está errada; se falar que a DDL não define restrições, está errada. Esses são os dois erros clássicos que a FGV explora.
Assinale a opção correta.