Chave primária SQL: Um tutorial técnico completo

Em bancos de dados relacionais, a chave primária é super importante pra garantir que os dados de uma tabela sejam únicos e fiquem certinhos. Uma chave primária é uma restrição que identifica de forma única cada registro em uma tabela, servindo como um elemento fundamental para indexação, garantindo a integridade da entidade e estabelecendo relações entre tabelas.

Neste tutorial, vou te mostrar tudo sobre chaves primárias SQL, falando sobre os princípios básicos, métodos de implementação e técnicas de otimização. Também vou falar sobre alguns erros comuns e melhores práticas, além de dar exemplos reais. Se você ainda está aprendendo SQL, recomendo que dê uma olhada no nosso roteiro completo de SQL e faça o nosso programa de habilidades Fundamentos de SQL. 

O que é uma chave primária SQL?

Uma chave primária SQL é uma coluna ou um conjunto de colunas que identifica de forma única cada linha de uma tabela. Isso quer dizer que não pode ter duas linhas com o mesmo valor de chave primária. Uma tabela só pode ter uma chave primária, que pode ser uma ou várias colunas.

As chaves primárias são essenciais para garantir a integridade dos dados e permitir consultas eficientes. Vamos ver alguns pontos básicos.

As chaves primárias são essenciais para a normalização do banco de dados e a integridade relacional.

Principais propriedades das chaves primárias

1. Exclusividade: Garantir que todos os valores na(s) coluna(s) da chave primária sejam únicos.
2. Não nulidade: As colunas de chave primária não podem ter valores NULL.
3. Imutabilidade: O ideal é que os valores da chave primária não mudem durante toda a sua vida útil, pra evitar inconsistências nas tabelas de referência.

Restrições e indexação

Quando uma chave primária é definida, o banco de dados cria automaticamente um índice exclusivo para fazer valer a restrição. Esse índice deixa as consultas mais rápidas, principalmente quando você está procurando algo.

Com esse sistema de índices, as chaves primárias ajudam o mecanismo do banco de dados a otimizar o plano de execução. Isso vai fazer com que suas consultas sejam mais rápidas.

Tipos de dados comuns para chaves primárias

As chaves primárias podem variar entre vários tipos de dados. Aqui estão alguns tipos diferentes que estão sendo usados:

• INTEGER ou SERIAL: Eficiente e mais usado.
• BIGINT: É útil para tabelas que devem guardar bilhões de linhas.
• UUID: Ótimo pra sistemas distribuídos e pra evitar previsibilidade sequencial.
• CHAR/VARCHAR: Use com cuidado, geralmente em tons naturais quando for preciso.

Tipos e arquitetura de chaves primárias SQL

As chaves primárias podem ser classificadas em vários tipos com base na sua estrutura e origem. Alguns exemplos são:

• Chaves naturais: Vem de dados que já existem (por exemplo, número de segurança social, e-mail) e são fáceis de entender e, muitas vezes, importantes para quem usa o negócio. Mas isso traz o risco de atualizações, duplicação e possíveis problemas de privacidade.
• Chaves substitutas: Chaves artificiais, como IDs geradas pelo sistema, que geralmente são implementadas com SERIAL, BIGSERIAL ou UUID. Usar essas chaves dá estabilidade, privacidade e facilita a manutenção.

Comparando-os com base nas características, podemos ver as diferenças na tabela resumida a seguir:

Arquitetura de chave primária composta

Uma chave primária composta é uma maneira comum de criar uma chave única nas tabelas. A chave geralmente vem dos dados que estão em duas ou mais colunas.

Essas chaves são comuns em tabelas de junção ou associativas, onde a própria relação exige exclusividade.

• Exemplo: Uma tabela course_enrollments pode usar uma chave composta de student_id e course_id.

Considerações:

• Minimalismo: Evite colunas desnecessárias na chave composta.
• Complexidade: As junções e as referências de chaves estrangeiras ficam mais complicadas.
• Tamanho do índice: Os índices podem ficar grandes e afetar o desempenho.

Chaves adicionais usadas em bancos de dados

Além da chave primária, tem várias outras chaves que podem ser usadas, tipo:

• Chave do candidato: Um conjunto de atributos que podem identificar uma linha de forma única.
• Super chave: Qualquer superconjunto de uma chave candidata (inclui colunas adicionais).
• Chave alternativa: Uma chave candidata que não foi escolhida como chave primária.

Se você está decidindo qual campo de dados usar como chave primária, pode considerar os seguintes fatores:

• Frequência de alteração dos dados: Com que frequência os dados mudam?
• Tipo e tamanho dos dados da coluna: O tipo de dados é adequado para indexação?
• Padrões de consulta esperados: Esse campo vai servir pra fazer consultas?

Definindo e mudando chaves primárias no SQL

Agora, vamos ver como declarar e gerenciar chaves primárias no PostgreSQL usando comandos SQL. 

Vamos ver vários cenários, como criar tabelas, mexer nas tabelas que já existem e controlar o comportamento das restrições.

Declaração e modificação Sintaxe

Durante a criação da tabela

Na fase de criação da tabela, você deve criar campos que provavelmente serão encontrados. Nesse caso, vamos criar um ID de funcionário que é composto por números inteiros únicos.

CREATE TABLE employees (
    employee_id SERIAL PRIMARY KEY,  -- Automatically generates unique integers
    name TEXT NOT NULL,              -- Basic text field, required
    email TEXT UNIQUE                -- Unique constraint to prevent duplicate emails
);

Mais informações sobre comandos SQL em nossa Folha de Referência Básica sobre SQL.

Esse exemplo mostra como definir uma chave primária inline usando o pseudo-tipo SERIAL. O PostgreSQL trata SERIAL como uma coluna inteira com autoincremento, ideal para chaves substitutas. A coluna e-mail também tem uma restrição UNIQUE, que permite que ela seja usada como uma chave alternativa.

Usando ALTER TABLE

Agora, vamos definir o campo “ employee_id ” como a chave primária.

ALTER TABLE employees ADD PRIMARY KEY (employee_id);

Esse comando é usado quando uma tabela já foi criada sem uma chave primária e você quer adicionar uma depois. Certifique-se de que a coluna à qual você está adicionando a chave primária não tem valores NULL ou duplicados, ou o comando vai falhar.

Excluindo a chave primária

Com a nossa chave primária definida, você também pode remover a restrição da chave primária.

ALTER TABLE employees DROP CONSTRAINT employees_pkey;

Use essa instrução para remover uma restrição de chave primária existente. O nome da restrição “ employees_pkey ” segue a convenção de nomenclatura padrão do PostgreSQL (

No PostgreSQL, o nome padrão da restrição para chaves primárias é table_name_pkey.

Saiba mais sobre o PostgreSQL na nossa folha de dicas.

Tratamento de valores nulos e gerenciamento de colisões

Valores NULL não são permitidos em colunas de chave primária. Valores duplicados também vão causar erros de violação de restrição.

Algumas estratégias pra lidar com isso são:

• Usando INSERT ... ON CONFLICT pra evitar duplicatas.
• Usando transações pra conferir se a chave tá disponível antes de inserir.

Estratégias de autoincremento e identificador global

Os tipos ` SERIAL`, ` BIGSERIAL` e ` IDENTITY ` do PostgreSQL facilitam a geração de IDs.

Além disso, os UUIDs são identificadores globais seguros. A natureza não sequencial e imprevisível deles também aumenta a segurança, principalmente na prevenção de ataques de enumeração. 

Aqui tá como dá pra criar um UUID e usar como chave primária

CREATE EXTENSION IF NOT EXISTS "pgcrypto";
CREATE TABLE users (
    user_id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    username TEXT NOT NULL
);

Chaves primárias em relações e aumento do desempenho

As chaves primárias são essenciais para garantir a consistência entre tabelas relacionais e melhorar o desempenho.

Aplicação da integridade da entidade

A integridade da entidade é garantida por chaves primárias, que não aceitam valores NULL nem duplicatas. Ter um identificador único ajuda a evitar anomalias nos dados durante as operações de inserção/atualização.

Chaves estrangeiras e integridade referencial

As chaves estrangeiras precisam combinar com os valores da chave primária que já estão na tabela que você está referenciando. A integridade referencial garante que todas as referências entre tabelas continuem válidas e evita “registros órfãos”, que são registros que fazem referência a dados que não existem.

As ações em cascata mantêm a consistência quando as chaves primárias referenciadas mudam. 

Isso pode incluir funções em cascata comuns, como:

• ON DELETE CASCADE
• ON UPDATE CASCADE
• SET NULL e SET DEFAULT

Indexação e otimização de consultas

Índices exclusivos nas chaves primárias aceleram as consultas SELECT e JOIN. Mas, um design ruim das chaves pode deixar os índices pesados e o desempenho meio ruim.

Se suas consultas estão lentas e você acha que é por causa de uma indexação ruim, use EXPLAIN ANALYZE para dar uma olhada nos planos de consulta e ver como está o uso do índice.

Melhores práticas de design e possíveis armadilhas

Um bom design de chave facilita a manutenção, o desempenho e a escalabilidade. Vamos dar uma olhada em algumas das melhores práticas e erros comuns.

Diretrizes importantes para a escolha

• Escolha tipos de dados curtos e de comprimento fixo (por exemplo, INT, UUID).
• Evite chaves que possam mudar.
• Certifique-se de que a chave não tem nenhum significado comercial embutido para evitar confusão lógica.
• Use chaves substitutas para simplificar e normalizar.

Erros comuns de implementação

• Usando várias chaves primárias (só dá pra usar uma por tabela).
• Rotular errado restrições únicas como chaves primárias.
• Não definir chaves primárias, o que leva a registros órfãos.

As correções incluem:

• Adicionando chaves que faltam pelo ALTER TABLE.
• Normalizando o design do esquema.
• Usar convenções de nomenclatura consistentes.

Considerações sobre escalabilidade

Quando estiver criando uma solução de banco de dados que pode crescer, tente usar chaves substitutas para manter tudo uniforme em conjuntos de dados grandes. Evite chaves compostas em sistemas distribuídos, a menos que seja necessário. Também é importante ficar de olho no tamanho das tabelas/índices.

Cenários de implementação avançada

Lidar com chaves primárias em sistemas complexos, como bancos de dados distribuídos ou sistemas antigos, precisa de estratégias avançadas.

Sistemas de banco de dados distribuídos

Os bancos de dados distribuídos são mais complicados. Você precisa garantir que a geração de chaves não tenha conflitos entre os nós. Pra isso, você pode tentar usar UUIDs e serviços de gerenciamento de chaves centralizadas.

Considerações sobre particionamento:

• Cuida pra que as chaves não criem pontos de acesso.
• Use chaves com hash ou aleatórias ao fragmentar.

Migração do sistema antigo

Quando estiver migrando um sistema de um banco de dados antigo, primeiro veja quais são os identificadores únicos que já existem. Depois, vá introduzindo as chaves substitutas junto com as chaves naturais.

Seja cuidadoso e use o suporte para chaves duplas antes de fazer a transição completa.

Processo de migração:

1. Adicionar coluna de chave substituta.
2. Preencha as chaves para os registros já existentes.
3. Alterar as consultas do aplicativo.
4. Jogue fora as chaves naturais antigas depois de verificar.

Demonstração de chaves primárias usando PostgreSQL

Antes de criar tabelas e inserir dados, você precisa de um ambiente PostgreSQL que funcione. Esta seção começa com um guia rápido sobre como configurar o PostgreSQL, seguido de instruções para definir e usar um conjunto de dados de exemplo para praticar os conceitos básicos de chave primária.

Passo 1: Configuração inicial para PostgreSQL

Se você ainda não instalou o PostgreSQL, siga estas etapas para começar:

1. Instalar o PostgreSQL
• Dá uma olhada no site oficial: https://www.postgresql.org/download/
• Escolha o seu sistema operacional (Windows, macOS ou Linux).
• Baixe e execute o instalador, certificando-se de instalar o pgAdmin (uma interface gráfica) junto com o servidor PostgreSQL.
2. Inicie o serviço PostgreSQL
• Depois de instalar, o serviço PostgreSQL geralmente começa automaticamente.
• Você também pode iniciar manualmente através do gerenciador de serviços do seu sistema operacional (por exemplo, Serviços no Windows ou systemctl no Linux).
3. Inicie o pgAdmin ou conecte-se via CLI
• Use o pgAdmin para gerenciar e consultar bancos de dados de forma visual.
• Ou então, abre um terminal e conecta usando:psql -U postgres
• Troca postgres pelo seu nome de usuário PostgreSQL, se for diferente.
4. Criar um novo banco de dados
• Em “ pgAdmin ”, clique com o botão direito do mouse em “Databases” e selecione “Create > Database”.

• Ou usa o seguinte comando SQL:```sql

Criar banco de dados pk_tutorial;

Connect to the new database in psql with:```bash
\c pk_tutorial

Quando o seu ambiente estiver pronto, você pode continuar com o resto da configuração do conjunto de dados, como já foi explicado no tutorial.

Agora, vamos ver um guia passo a passo pra criar um conjunto de dados de exemplo usando o PostgreSQL. O conjunto de dados tem duas tabelas relacionadas: customers e orders.

A tabela “ customers ” usa uma chave substituta para simplificar, enquanto a tabela “ orders ” usa uma chave primária baseada em UUID para mostrar a exclusividade global.

Passo 2: Criando tabelas

O primeiro passo é definir o esquema e estabelecer restrições de chave primária para ambas as tabelas. Também definimos uma relação de chave estrangeira entre orders.customer_id e customers.customer_id para mostrar a integridade relacional.

Para a tabela " customers ", a chave primária é " customer_id".

Para a tabela " orders ", a chave primária é " order_id".

CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY, -- Auto-incremented surrogate key
    name TEXT NOT NULL,
    email TEXT UNIQUE -- Ensures no duplicate email addresses
);

CREATE TABLE orders (
    order_id UUID DEFAULT gen_random_uuid() PRIMARY KEY, -- Globally unique identifier
    order_date DATE NOT NULL,
    customer_id INT REFERENCES customers(customer_id) ON DELETE CASCADE -- Enforces referential integrity
);

Explicação:

• customer_id usa a palavra-chave “ SERIAL ” para criar IDs únicos automaticamente.
• email tem uma restrição " UNIQUE " para evitar duplicatas.
• order_id é um arquivo de configuração ( UUID ) gerado automaticamente pelo site gen_random_uuid().
• A cláusula “ ON DELETE CASCADE ” garante que, ao excluir um cliente, também sejam excluídos os pedidos associados a ele.

É assim que deve aparecer na interface do pgAdmin:

Passo 3: Inserindo dados de amostra

Depois, preenchemos as tabelas com registros de exemplo pra ver como as chaves primárias e estrangeiras se comportam durante operações típicas de inserção. Esses dados mostram um cenário básico de comércio eletrônico.

INSERT INTO customers (name, email) VALUES
('Alice Tan', 'alice@example.com'),
('Ben Koh', 'ben@example.com'),
('Clara Lim', 'clara@example.com');

INSERT INTO orders (order_date, customer_id) VALUES
('2025-07-01', 1),
('2025-07-02', 2),
('2025-07-03', 3);

É assim que deve aparecer na interface do pgAdmin:

Passo 4: Consultando dados

Por fim, fazemos uma consulta SQL “ JOIN ” pra pegar as informações das duas tabelas, mostrando como a chave estrangeira permite junções relacionais perfeitas entre pedidos e clientes.

Aqui tá o código que vamos rodar:

SELECT o.order_id, o.order_date, c.name, c.email
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id;

Aqui tá um exemplo de resultado:

Como você pode ver na imagem acima, a tabela de saída mostra os dados das duas tabelas. Por exemplo, a tabela unida inclui o campo “ order_date ” da tabela “ orders ” e o campo “ name ” da tabela “ customers ”.

Conclusão

As chaves primárias SQL são essenciais para bancos de dados relacionais, garantindo a exclusividade, permitindo consultas eficientes e mantendo a integridade dos dados. 

A gente falou sobre os princípios, classificações, sintaxe, melhores práticas e estratégias avançadas para chaves primárias SQL. Se quiser mais recursos de aprendizagem, dá uma olhada no nosso curso Introdução a bancos de dados relacionais em SQL ou no curso Junção de dados em SQL.

Se você curte ler tutoriais, o guia Restrições de integridade no SQL ou a Folha de dicas sobre junções SQL também podem ajudar bastante.