Questão de Banco de Dados — Sublinguagens SQL (DDL, DML, DQL, DCL e DTL) — FGV 2024

Sublinguagens SQL: DDL e a criação de tabelas

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 ClienteID, além da unicidade — é exatamente isso que a alternativa B afirma. A DDL (Data Definition Language) é a sublinguagem do SQL responsável por definir a estrutura dos objetos do banco (tabelas, índices, visões), e é nela que se declaram as restrições de integridade, como PRIMARY KEY, UNIQUE, NOT NULL e FOREIGN KEY.

A DDL (Data Definition Language) é a sublinguagem do SQL que lida com a estrutura do banco de dados, não com os dados em si. Enquanto a DML (Data Manipulation Language) interage com os registros (INSERT, UPDATE, DELETE, SELECT), a DDL define e modifica os objetos: CREATE, ALTER, DROP, TRUNCATE e RENAME. É importante entender essa separação: a DDL cria o "esqueleto" (tabelas, colunas, restrições), e a DML manipula o "conteúdo" (linhas).

Quando um desenvolvedor executa um comando CREATE TABLE, ele está usando a DDL para definir não apenas as colunas e seus tipos, mas também as restrições de integridade que garantem a qualidade e a consistência dos dados. A restrição PRIMARY KEY é uma das mais importantes: ela combina duas propriedades — a unicidade (nenhum valor pode se repetir) e a não nulidade (nenhum valor pode ser NULL). Isso significa que a coluna definida como chave primária não pode ficar vazia, pois cada linha precisa ser identificada de forma única.

Na prática, considere o comando típico:

CREATE TABLE Clientes (
    ClienteID INT PRIMARY KEY,
    Nome VARCHAR(100) NOT NULL,
    Email VARCHAR(100) UNIQUE,
    DataCadastro DATE DEFAULT CURRENT_DATE
);

Aqui, a DDL define que ClienteID é a chave primária (não nula e única), que Nome é obrigatório (NOT NULL), que Email não pode se repetir (UNIQUE) e que DataCadastro, se não for informado, recebe a data atual (DEFAULT). Cada uma dessas cláusulas é uma restrição de integridade declarada na DDL.

A pegadinha desta questão está em confundir o papel da DDL. Muitos candidatos acham que a DDL apenas "cria" tabelas sem impor regras, mas a verdade é que a DDL é justamente o mecanismo para definir essas regras. A alternativa D, por exemplo, afirma exatamente o contrário — que a DDL não pode definir restrições — o que é um erro grave. A alternativa A também erra ao dizer que a DDL não impõe unicidade por padrão: a unicidade é imposta quando se declara UNIQUE ou PRIMARY KEY, e a DDL é o local onde isso acontece.

Guarde a fronteira entre estrutura (DDL) e dados (DML): é nela que as alternativas se dividem. A DDL define o que pode ser armazenado e como; a DML define o que é armazenado.

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 segunda parte: a DDL pode e deve impor restrições de unicidade, através das cláusulas UNIQUE e PRIMARY KEY. Se o comando CREATE TABLE tivesse definido Email como UNIQUE, a duplicidade seria bloqueada. A DDL não impõe unicidade "por padrão" em todas as colunas, mas tem total capacidade de impor quando o desenvolvedor declara a restrição. A afirmação generaliza incorretamente, sugerindo que a DDL é incapaz de garantir unicidade.

Alternativa B — ✅ Correta ⟵ GABARITO

A alternativa está correta porque a chave primária (PRIMARY KEY) tem como propriedade intrínseca a não nulidade. Uma coluna definida como PRIMARY KEY não pode conter valores NULL, pois cada linha deve ser identificada de forma única e a ausência de valor não pode identificar nada. Além disso, a chave primária também garante a unicidade. Portanto, a coluna ClienteID, sendo chave primária, não pode ser nula — exatamente o que a alternativa afirma.

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 valor padrão. O erro está na conclusão: a DDL permite definir um valor padrão (DEFAULT) para uma coluna. Se o comando CREATE TABLE tivesse incluído DataCadastro DATE DEFAULT CURRENT_DATE, o campo seria preenchido automaticamente com a data atual quando o usuário não informasse um valor. A ausência de um valor padrão não é uma limitação da DDL, mas uma escolha do desenvolvedor. A alternativa confunde a ausência de DEFAULT no comando específico com uma incapacidade da linguagem.

Alternativa D — ❌ Incorreta

Afirma que a DDL não pode ser usada para definir restrições de integridade, como chaves primárias ou únicas. Isso é totalmente falso. A DDL é exatamente o local onde essas restrições são declaradas. No comando CREATE TABLE, é possível (e comum) definir PRIMARY KEY, UNIQUE, NOT NULL, FOREIGN KEY, CHECK e DEFAULT. A DDL é a ferramenta para definir a estrutura e as regras de integridade do banco. A alternativa inverte completamente o papel da DDL.

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 generalização. É verdade que, na maioria dos SGBDs, executar CREATE TABLE para uma tabela que já existe gera um erro. No entanto, a DDL permite substituir tabelas de outras formas: o comando DROP TABLE seguido de CREATE TABLE, ou o comando ALTER TABLE para modificar a estrutura existente. Além disso, alguns SGBDs oferecem a cláusula IF NOT EXISTS (no MySQL, por exemplo) que evita o erro. A afirmação de que a DDL "não permite a substituição" é imprecisa e generalizada demais.

Gabarito: letra B