09. SQL: DDL — definição de dados

Antes de inserir uma linha, o banco precisa conhecer a estrutura que a receberá. A DDL cria e transforma esse esquema, definindo objetos e restrições que servirão de base para todas as operações posteriores.

O percurso começa pela representação do mundo real. Primeiro entendemos a arquitetura e os níveis de modelagem; depois construímos o modelo relacional, protegemos sua integridade e aprendemos SQL. Ao final, levamos essa base para o ambiente analítico dimensional. Este é o capítulo 9 de 12 da disciplina Modelagem de Dados e SQL. A leitura retoma SQL e seus dialetos e usa essa base para avançar. Depois, seguiremos para SQL: consultas (SELECT).

O fio condutor

Banco de dados deve ser estudado como um sistema de decisões conectadas. O significado atribuído ao dado orienta o modelo; o modelo condiciona consultas e atualizações; o SGBD executa essas operações sob regras de segurança, concorrência, desempenho e recuperação. Quando uma dessas camadas muda, as demais podem ser afetadas.

Ao longo da leitura, acompanhe sempre quatro perguntas: qual problema está sendo resolvido, qual estrutura representa o problema, que garantia precisa ser preservada e qual custo acompanha a escolha. Esse roteiro ajuda a compreender os conceitos em vez de apenas memorizar nomes.

As sublinguagens do SQL

Começamos por As sublinguagens do SQL, pois essa base permite compreender as decisões apresentadas nas seções seguintes.

Repare como DDL, DML, DQL, DCL e TCL, TRUNCATE é DDL participam da mesma decisão. Ao relacionar esses elementos, fica mais fácil prever o comportamento do banco e reconhecer os efeitos de cada escolha.

CREATE TABLE e restrições

A seção anterior apresentou As sublinguagens do SQL. Agora chegamos a CREATE TABLE e restrições, que acrescenta a próxima peça do mesmo raciocínio.

CREATE TABLE pedido (
  id          INTEGER      NOT NULL,
  cliente_id  INTEGER,
  valor       DECIMAL(10,2) DEFAULT 0,
  CONSTRAINT pk_pedido   PRIMARY KEY (id),
  CONSTRAINT fk_ped_cli  FOREIGN KEY (cliente_id) REFERENCES cliente (id)
);

• Restrição inline (junto à coluna) alcança só aquela coluna; chave ou unicidade composta exige a forma de tabela, listando as colunas entre parênteses. Repetir PRIMARY KEY em duas colunas não cria chave composta — cria duas chaves primárias, o que é proibido.
• As duas formas aceitam nome. Nomear (CONSTRAINT ck_salario_pos CHECK (salario > 0)) não muda a verificação, mas permite remover ou desabilitar por ALTER TABLE e torna a mensagem de erro legível — sem nome, o SGBD gera algo como SYS_C0012345.
• PRIMARY KEY equivale a NOT NULL + UNIQUE; declarar os dois juntos é redundante, mas válido. DEFAULT não é restrição: é propriedade da definição da coluna.