DP-900: como usar constraints para garantir integridade em dados relacionais

Vou ensinar como usar constraints em bases de dados relacionais no contexto do DP-900. Esta competência explica como garantir integridade dos dados (por exemplo, que relações entre tabelas se mantenham correctas) — tema frequente no exame e essencial para soluções reais em Azure SQL Database ou Managed Instance.

O que precisas de saber

Constraints são regras declarativas aplicadas a colunas ou tabelas para garantir que os dados inseridos cumprem determinadas condições. As principais constraints relacionais que deves conhecer são:

• PRIMARY KEY: identifica unicamente cada linha numa tabela; implica NOT NULL e UNIQUE.
• FOREIGN KEY: garante que um valor numa coluna corresponde a um valor existente na tabela referenciada (integridade referencial).
• UNIQUE: assegura que todos os valores numa coluna (ou conjunto) são distintos.
• NOT NULL: impede valores nulos nessa coluna.
• CHECK: define uma condição (expressão booleana) que os valores da linha devem satisfazer.

Exemplo simples: numa base de dados de vendas, a tabela Customers tem uma PRIMARY KEY CustomerID; a tabela Orders tem OrderID (PK) e CustomerID com FOREIGN KEY apontando para Customers(CustomerID). Assim, não se podem criar encomendas para clientes inexistentes.

Como funciona

As constraints são avaliadas pelo motor da base de dados sempre que há operações que alterem dados: INSERT, UPDATE, DELETE. Se a regra for violada, a operação falha e é retornado um erro. No Azure SQL Database o comportamento é idêntico ao do SQL Server on-premises.

Alguns detalhes importantes:

• As FOREIGN KEYs podem ter acções ON DELETE/ON UPDATE (NO ACTION, CASCADE, SET NULL, SET DEFAULT) que definem o efeito quando a linha referenciada é removida/actualizada.
• UNIQUE permite múltiplas colunas (constraint multicoluna) e pode ser suportada por índices para performance.
• CHECK pode usar expressões simples: e.g., CHECK (Quantity > 0) — útil para regras de negócio leves directamente na base de dados.

Na prática

A seguir tens exemplos práticos em T-SQL para criar tabelas e constraints. Imagina que estás a criar duas tabelas: Customers e Orders.

CREATE TABLE Customers (
  CustomerID INT PRIMARY KEY,
  Name NVARCHAR(100) NOT NULL,
  Email NVARCHAR(256) UNIQUE
);

CREATE TABLE Orders (
  OrderID INT PRIMARY KEY,
  CustomerID INT NOT NULL,
  OrderDate DATE NOT NULL,
  Quantity INT NOT NULL CHECK (Quantity > 0),
  CONSTRAINT FK_Orders_Customers FOREIGN KEY (CustomerID)
    REFERENCES Customers(CustomerID)
    ON DELETE CASCADE
);

Explicação rápida:

• CustomerID em Customers é PRIMARY KEY: garante unicidade e identifica cada cliente.
• Email é UNIQUE: impede duplicados no email de clientes.
• Orders.CustomerID é FOREIGN KEY com ON DELETE CASCADE: quando apagas um cliente, todas as suas encomendas são automaticamente removidas — útil mas tem implicações que explico em "Erros comuns".
• CHECK em Quantity evita valores ≤ 0.

Erros comuns

1) Usar ON DELETE CASCADE sem avaliar o impacto: pode remover muitas linhas inesperadamente. Antes de definir CASCADE, pensa nas regras de negócio e na política de recuperação de dados.

2) Confiar apenas nas constraints para regras complexas: constraints são excelentes para integridade básica, mas regras complexas de negócio (por exemplo, limites acumulados entre tabelas, verificações temporais avançadas) podem exigir triggers ou lógica na aplicação.

3) Criar demasiadas constraints ou índices sem considerar a performance: UNIQUE e FOREIGN KEY podem causar overhead em operações de escrita; testa e avalia trade-offs entre integridade e performance.

Como praticar

Pratica estes conceitos criando bases de dados no Azure SQL Database (podes usar uma instância de avaliação) ou localmente com o SQL Server. Executa operações INSERT/UPDATE/DELETE para ver como as constraints se comportam e experimenta as diferentes opções de ON DELETE/ON UPDATE.

Para preparação do exame DP-900 usa o Practice Assessment OFICIAL gratuito da Microsoft e a study guide oficial (ambos gratuitos). Estes recursos oficiais ajudam-te a validar conhecimentos sem recorrer a conteúdos não autorizados.

Em resumo

• Constraints (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK) garantem integridade dos dados a nível da base de dados.
• FOREIGN KEY assegura integridade referencial; ON DELETE/ON UPDATE controlam efeitos em cascata.
• Constraints ajudam a prevenir dados inválidos, mas não substituem lógica de negócio complexa.
• Testa sempre o impacto das constraints na performance e nos fluxos de escrita antes de as aplicar em produção.