Resumo TI Banco de Dados: CREATE TABLE com Restrições

Com o banco e o schema criados, o próximo passo é a peça central de qualquer esquema relacional: a tabela. Este resumo cobre a sintaxe completa do CREATE TABLE e apresenta o conceito de restrição (constraint) — o mecanismo que faz o próprio SGBD garantir a integridade dos dados, em vez de depender da disciplina de quem escreve a aplicação.

Neste resumo, você vai aprender a sintaxe completa do CREATE TABLE, entender o que é uma restrição e por que ela muda o comportamento do banco diante de dados inválidos, e ver a diferença entre declarar uma restrição em nível de coluna ou em nível de tabela. Os tipos específicos de restrição — chave primária, chave estrangeira, unicidade e validação de condição — são aprofundados no próximo resumo; obrigatoriedade (NOT NULL) e valor padrão (DEFAULT) ficam para o resumo seguinte.

🏗️ Sintaxe completa do CREATE TABLE

A estrutura geral é: CREATE TABLE nome_tabela (coluna1 tipo restrição, coluna2 tipo restrição, ...); — uma lista de colunas, cada uma com seu tipo de dado (visto no resumo sobre tipos de dados SQL) e, opcionalmente, uma ou mais restrições. A cláusula IF NOT EXISTS evita erro caso a tabela já exista, mas não verifica se a estrutura da tabela existente é igual à que está sendo declarada.

🛡️ O que é uma restrição (constraint)

Uma restrição é uma regra declarada junto com a estrutura da tabela que o SGBD passa a impor automaticamente: toda tentativa de INSERT ou UPDATE que a viole é rejeitada com erro, antes mesmo de chegar a alterar os dados. Sem restrições, garantir a integridade dependeria inteiramente da disciplina da aplicação — algo fácil de esquecer em algum ponto do sistema. Os tipos mais comuns são PRIMARY KEY (chave primária), FOREIGN KEY (chave estrangeira), UNIQUE (unicidade), CHECK (validação de condição), NOT NULL (obrigatoriedade) e DEFAULT (valor padrão) — cada uma detalhada nos próximos resumos da trilha.

📍 Restrição em nível de coluna x em nível de tabela

Uma restrição pode ser declarada de duas formas. Em nível de coluna, escrita logo depois do tipo, na mesma linha da coluna — funciona apenas quando a restrição envolve uma única coluna. Em nível de tabela, escrita como um item separado na lista, referenciando explicitamente o nome de uma ou mais colunas entre parênteses — é a única forma válida quando a restrição envolve mais de uma coluna, como uma chave primária composta: CREATE TABLE item_pedido (pedido_id INT, produto_id INT, quantidade INT, PRIMARY KEY (pedido_id, produto_id));.

🏷️ Nomeando restrições explicitamente

É possível (e recomendável) dar um nome a cada restrição com a palavra-chave CONSTRAINT: CONSTRAINT pk_item_pedido PRIMARY KEY (pedido_id, produto_id). Sem um nome explícito, o SGBD gera um nome automático — geralmente pouco legível — o que dificulta identificar qual restrição foi violada numa mensagem de erro, ou removê-la depois com ALTER TABLE ... DROP CONSTRAINT nome (sintaxe padrão em PostgreSQL e SQL Server; no MySQL a cláusula de remoção varia conforme o tipo de restrição).

⚠️ Pegadinhas comuns

• Restrição não é obrigatória para criar uma tabela válida — uma tabela sem nenhuma restrição é sintaticamente correta; a ausência de chave primária, por exemplo, é uma falha de modelagem, não um erro de sintaxe;
• Restrição em nível de coluna só serve para uma coluna: qualquer restrição que precise enxergar duas ou mais colunas ao mesmo tempo (como chave composta) exige a sintaxe de nível de tabela;
• Nomear a restrição é opcional, mas não nomear tem custo depois: sem CONSTRAINT nome, o nome gerado automaticamente pelo SGBD dificulta a manutenção futura do esquema;
• IF NOT EXISTS não compara estruturas — ele só evita o erro de “tabela já existe”; se a tabela existente tiver colunas diferentes das declaradas, o comando não altera nada e não avisa sobre a divergência.

🎯 Dica Final para a Prova

Ao ver uma restrição que envolve mais de uma coluna, lembre que apenas o formato de nível de tabela (separado, com o nome das colunas entre parênteses) é válido — restrição de nível de coluna nunca aceita mais de uma coluna na mesma declaração.

✓ Com a sintaxe geral do CREATE TABLE e o conceito de restrição estabelecidos, o próximo resumo aprofunda os quatro tipos mais cobrados em prova: PRIMARY KEY, FOREIGN KEY, UNIQUE e CHECK.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Em breve no Dicionário do Concurseiro: Resumo TI Banco de Dados: PRIMARY KEY, FOREIGN KEY, UNIQUE e CHECK

📘 Uma restrição transfere a responsabilidade pela integridade dos dados da aplicação para o próprio banco — e chave composta só se declara em nível de tabela. Continue estudando!