O modelo relacional

Um nome de cliente, uma data de pedido e um preço são dados: fatos registrados. Um banco de dados é uma coleção organizada de dados relacionados. Um sistema de gerenciamento de banco de dados, ou SGBD, é o software que armazena e gerencia essa coleção. PostgreSQL é um SGBD; o banco de dados store de uma loja é uma das coleções que ele gerencia.

Armazene cada informação em seu lugar

Suponha que uma planilha repita o telefone de Maria Garcia em todas as suas 14 vendas. Uma mudança de telefone exige 14 edições. Uma célula esquecida deixa registros conflitantes. Em um banco de dados relacional, customers contém os dados de Maria uma única vez, sob customer_id 1. Cada venda registra esse identificador. Atualizar seu telefone em uma linha de cliente fornece um único número atual para buscas posteriores.

Um banco de dados relacional organiza informações em tabelas. “Relacional” vem de relação, o nome matemático de uma tabela. E. F. Codd apresentou o modelo em 1970. Sua separação central é útil: os usuários descrevem os dados que desejam por meio de tabelas e valores; o SGBD cuida de como encontrar esses dados em disco.

Regras e acesso compartilhado

Uma tabela tem colunas nomeadas, tipos de dados e restrições. Uma restrição é uma regra que o SGBD verifica, como “um pedido deve fazer referência a um cliente existente”. Essas verificações protegem dados compartilhados quando vários aplicativos usam o mesmo banco de dados. A imposição de tipos varia: PostgreSQL rejeita texto como 'twelve' em uma coluna de preço numérica, enquanto tabelas comuns do SQLite têm tipos flexíveis.

Um SGBD também gerencia usuários simultâneos, permissões, cópias de segurança e recuperação. Dois funcionários podem trabalhar com dados compartilhados sem trocar cópias separadas de uma planilha. As permissões podem permitir que um usuário de relatórios leia as vendas e, ao mesmo tempo, limitar quem pode alterá-las. Um processo de cópia de segurança e recuperação ajuda a restaurar os dados após uma falha.

Mantenha um conjunto de alterações unido

Uma transação trata várias alterações como uma unidade: todas são salvas ou nenhuma é. Transferir R$ 200 entre contas exige subtrair o valor da conta-corrente e adicioná-lo à poupança. Se uma falha interromper a transferência antes de sua conclusão, o SGBD poderá desfazer a transação inacabada. Salvar apenas a subtração deixaria um saldo incorreto.

Uma planilha continua útil para pequenos cálculos e layouts flexíveis. Um banco de dados oferece uma estrutura definida para registros compartilhados e regras. Uma planilha do Excel tem um limite fixo de 1.048.576 linhas; bancos de dados costumam gerenciar coleções muito maiores, sujeitas aos limites de armazenamento, hardware e produto.

Dados e tarefas diferentes

Dados estruturados se encaixam em colunas nomeadas compartilhadas por todas as linhas. Dados semiestruturados, como documentos JSON, podem ter campos diferentes em registros diferentes. Dados não estruturados, como áudio ou e-mails de texto livre, não têm essa estrutura tabular fixa. As organizações frequentemente combinam bancos de dados relacionais com armazenamentos de documentos, armazenamentos de chave-valor ou armazenamento de arquivos.

A carga de trabalho também importa. Um sistema transacional, também chamado de OLTP, registra eventos cotidianos por meio de muitas pequenas leituras e gravações: um pedido, um pagamento, uma mudança de endereço. Um sistema analítico, ou OLAP, lê muitos registros armazenados para responder a perguntas como “Como as vendas mensais variaram por região?”. Ambos podem usar tabelas e chaves relacionais.

SQL, sigla de Structured Query Language, é uma linguagem. PostgreSQL, MySQL, SQLite, Microsoft SQL Server e Oracle Database são produtos que a usam. SQL Server é um SGBD, não outro nome para a própria SQL.

Como um aplicativo acessa os dados

Em um sistema cliente-servidor, um programa servidor gerencia o banco de dados. Um cliente, como um site, uma ferramenta de relatórios ou um editor de consultas, envia solicitações a esse servidor. PostgreSQL, MySQL, SQL Server e Oracle geralmente funcionam dessa forma. Ferramentas como psql, pgAdmin, DBeaver e SQL Server Management Studio permitem que as pessoas inspecionem bancos de dados e enviem solicitações.

Um mecanismo embarcado é executado dentro de um aplicativo. O SQLite usa uma biblioteca e um arquivo de banco de dados comum, como store.db, sem um servidor de banco de dados separado. Ele é comum em celulares, navegadores e aplicativos de desktop. Um serviço gerenciado em nuvem, como Azure SQL Database, Amazon RDS ou Google Cloud SQL, permite que um provedor administre os servidores de banco de dados. “Gerenciado” descreve quem opera o serviço; isso não substitui tabelas e chaves por um modelo diferente.

Uma instalação de SGBD pode gerenciar vários bancos de dados, como store e payroll. Uma conexão seleciona o banco de dados a ser usado, sujeito a permissões.

Diga qual resultado você deseja

SQL é declarativa: ela descreve o resultado necessário enquanto o SGBD escolhe como obtê-lo. Leia esta instrução:

SELECT first_name, city
FROM customers
WHERE state = 'TX';

Ela solicita os primeiros nomes e as cidades das linhas de clientes cujo estado é TX. Ela não diz qual página do disco deve ser lida primeiro. Palavras-chave em maiúsculas facilitam a leitura da instrução; select e SELECT significam a mesma coisa. Um ponto e vírgula normalmente encerra uma instrução.

Reconheça a função da instrução

Alguns livros colocam SELECT em um grupo separado de linguagem de consulta de dados. A distinção útil é a função efetiva da instrução: adicionar uma coluna altera a estrutura; adicionar um cliente altera os dados.

SQL se tornou um padrão ANSI em 1986 e é padronizada internacionalmente como ISO/IEC 9075. Os produtos acrescentam seus próprios dialetos. Um limite de dez linhas aparece como LIMIT 10 no SQLite, PostgreSQL e MySQL, TOP 10 no SQL Server ou FETCH FIRST 10 ROWS ONLY na SQL padrão e no Oracle.

Leia textos e outros objetos de banco de dados

Literais de texto usam aspas simples: 'TX'. A SQL padrão usa aspas duplas para identificadores, como nomes de colunas. Um apóstrofo dentro de um texto é duplicado: 'O''Brien' representa O'Brien.

Uma visão é uma consulta salva usada como uma tabela; uma visão comum não tem linhas armazenadas próprias. Um índice é uma estrutura de busca que pode ajudar a encontrar linhas rapidamente. A maioria dos sistemas indexa chaves primárias automaticamente. Procedimentos armazenados e funções são códigos salvos que podem ser executados pelo nome.

Uma tabela armazena informações sobre um tipo de elemento. Cada linha em customers descreve um cliente; cada coluna contém uma propriedade. Sua interseção contém um valor.

Leia um registro de ponta a ponta

Veja algumas colunas de clientes:

Encontre customer_id 4 e leia city: a cidade de Wei é Seattle. Para descobrir quem mora em Denver, leia o nome na linha de Denver: James Wilson. Uma linha vizinha descreve outro cliente.

A tabela completa tem oito colunas: customer_id, first_name, last_name, email, phone, city, state e zip_code. O telefone de James é NULL: o valor está ausente, mas sua linha ainda tem a coluna de telefone.

Relacione os termos

Uma tupla é uma linha inteira, não uma célula. Um atributo nomeia uma propriedade compartilhada por todas as linhas. “Registro 4” pode significar um identificador ou uma posição na exibição; verifique qual deles, pois as posições podem mudar.

Conte a estrutura

O grau conta as colunas; a cardinalidade da tabela conta as linhas. A tabela completa tem grau 8 e cardinalidade 4. A exibição acima mostra seis colunas sem alterar o grau da tabela.

Adicionar um cliente aumenta a cardinalidade para 5; o grau permanece 8. Adicionar birth_date aumenta o grau para 9 e dá a cada linha um lugar para esse valor, mesmo quando ele está ausente. Um novo cliente acrescenta uma linha, não uma coluna.

A cardinalidade do relacionamento, como um para muitos, descreve os vínculos permitidos, não a quantidade de linhas de uma tabela.

Leia nomes qualificados

Os nomes das colunas são únicos dentro de uma tabela. orders.customer_id e customers.customer_id distinguem colunas com o mesmo nome em tabelas diferentes: o ponto separa os nomes da tabela e da coluna.

snake_case usa palavras minúsculas separadas por sublinhados, como em zip_code. Nomes com espaços precisam estar entre aspas em SQL. Nomes de tabelas no singular ou no plural podem funcionar; use uma convenção consistente.

Uma tabela relacional tem uma estrutura lógica além de sua aparência retangular. No modelo formal, ela é um conjunto de linhas. Conjuntos não contêm elementos duplicados e não têm ordem. As colunas são identificadas pelo nome, então mover uma coluna na exibição não altera a informação que ela representa.

A identidade não vem da posição

Um SGBD pode retornar linhas em uma ordem diferente após atualizações, exclusões ou uma mudança na forma como lê o armazenamento. “A terceira linha” não é uma forma duradoura de identificar um cliente. customer_id 3 continua identificando Aisha mesmo quando sua linha aparece em primeiro lugar. Uma consulta que precisa de uma ordem específica a solicita com ORDER BY.

Tabelas SQL diferem de relações formais: sem uma chave primária ou outra restrição de unicidade adequada, elas podem conter linhas idênticas. Duas cópias de ('Coffee mug', 12.50) não oferecem um valor que as diferencie nessas colunas. Uma chave primária dá a cada linha um identificador único e impede linhas completamente duplicadas.

Uma coluna, um domínio

Um domínio é o conjunto de valores permitidos em uma coluna. Uma quantidade tem um tipo inteiro e também pode precisar de uma regra que exija que ela seja positiva. Um código de estado é texto, mas nem todo valor de texto é um código de estado válido. Tipos de dados e restrições descrevem os valores permitidos para o SGBD.

Todas as linhas compartilham as mesmas colunas. Um pedido não pode receber uma coluna extra de mensagem para presente apenas para ele. A tabela pode ter uma coluna gift_note para todos os pedidos, com NULL onde nenhuma mensagem foi registrada. Informações opcionais ainda têm um lugar definido.

Mantenha valores individuais separados

Um valor atômico é um valor para a finalidade da coluna. Uma célula de telefone que contém “512-555-0147, 512-555-0199” contém uma lista de dois números. Encontrar, verificar ou remover apenas um número se torna difícil. Uma tabela customer_phones pode dar a cada telefone sua própria linha, com customer_id indicando de quem é o número.

Atômico não significa que todo valor de texto deva ser dividido em suas menores partes. Um nome de cidade pode conter várias palavras e continuar sendo um único valor de cidade. A questão é se a célula armazena uma informação do tipo que a coluna representa ou uma coleção que deve ser tratada separadamente.

Leia uma exportação de planilha com atenção

Uma planilha de vendas pode incluir um cabeçalho repetido no meio, uma linha inferior identificada como “TOTAL” e um preço escrito como “12,50 (promoção)”. Essas escolhas de organização são úteis para uma pessoa, mas misturam tipos diferentes de conteúdo nas mesmas colunas.

Para lê-la como uma tabela relacional:

1. Trate os nomes das colunas como cabeçalho, não como registros de venda.
2. Mantenha cada linha de dados referente a uma venda; calcule o total a partir dessas linhas.
3. Armazene o preço numérico separadamente de uma observação sobre a promoção.
4. Dê a cada venda uma chave para que sua linha possa ser identificada.

Uma linha de total misturada com vendas poderia ser contada como outra venda ou somada novamente ao total. Uma observação misturada a um preço numérico impede operações numéricas comuns.

Tabelas lógicas e armazenamento físico

Uma tabela é a visão lógica do usuário. O SGBD pode armazenar seus dados em arquivos, páginas e índices organizados para acesso eficiente. Independência de dados significa que alterações nessa organização física não precisam alterar os nomes das tabelas, os significados das colunas ou as solicitações usadas pelos aplicativos.

Um tipo de dados informa ao SGBD que tipo de valor uma coluna contém e como trabalhar com ele. Adição numérica, comparação de texto e ordenação de datas são operações diferentes. Um nome de tipo familiar também pode se comportar de maneira diferente em produtos de banco de dados distintos.

Números: inteiros, exatos e aproximados

No PostgreSQL, MySQL e SQL Server, INTEGER varia de −2147483648 a 2147483647. BIGINT alcança 9.223.372.036.854.775.807; o armazenamento de inteiros do SQLite também pode alcançar esse intervalo.

Para decimais, precisão é o número total de dígitos e escala é o número de dígitos após a vírgula decimal. DECIMAL(8, 2) deixa seis dígitos antes da vírgula: seu máximo é 999999,99. O preço 12,50 cabe; 1234567,00 não cabe. PostgreSQL, MySQL, SQL Server e Oracle oferecem armazenamento decimal exato. O SQLite aceita essa declaração, mas não impõe sua precisão nem escala e pode armazenar frações como números binários de ponto flutuante.

O ponto flutuante aproxima muitas frações decimais. Em precisão dupla, somar 0,1 e 0,2 resulta em 0,30000000000000004. O SQLite trata esses literais decimais como ponto flutuante. O PostgreSQL trata literais decimais sem tipo explícito como numéricos exatos, então o mesmo cálculo escrito ali pode ser exato; valores explicitamente definidos em precisão dupla mostram a aproximação.

Texto, datas e indicadores

CHAR(n) é texto de comprimento fixo; PostgreSQL e SQL Server completam valores menores com espaços. VARCHAR(n) permite comprimentos variáveis até um limite. O SQLite ignora ambas as configurações de comprimento e não completa com espaços. TEXT armazena textos longos no SQLite, PostgreSQL e MySQL. O SQL Server usa VARCHAR(MAX) ou NVARCHAR(MAX) para essa finalidade; seu tipo TEXT mais antigo está obsoleto.

Um DATE armazena uma data do calendário, um TIME uma hora do dia e o TIMESTAMP da SQL padrão uma data e uma hora. Escreva datas na forma ano-mês-dia, como '2026-03-02', para evitar confundir 2 de março com 3 de fevereiro. Datas tipadas têm um formato interno de armazenamento; o aplicativo escolhe seu formato de exibição. O SQLite não tem um tipo de data dedicado e geralmente armazena datas como texto ISO. O SQL Server usa DATETIME2 para data e hora: seu TIMESTAMP significa ROWVERSION, um contador binário de versões.

Um BOOLEAN representa TRUE ou FALSE, ou NULL quando o valor está ausente. PostgreSQL tem um tipo booleano; SQL Server usa BIT, MySQL trata BOOLEAN como um inteiro pequeno e SQLite armazena os indicadores como 1 e 0. Tipos binários como BLOB ou BYTEA do PostgreSQL armazenam bytes, incluindo pequenas imagens. Arquivos maiores costumam ser armazenados separadamente, com um caminho ou URL em uma tabela.

Afinidade de tipo do SQLite

Em tabelas comuns do SQLite, um tipo declarado é uma preferência chamada afinidade de tipo. Uma coluna INTEGER converte '42' no número 42, mas pode manter 'abc' como texto. Uma tabela STRICT do SQLite rejeita texto que não pode se tornar um inteiro válido.

Comece pelo significado de um valor e por como ele será usado. Um CEP americano contém dígitos, mas ninguém soma CEPs americanos para obter um total significativo. Uma quantidade também contém dígitos, e somar quantidades é útil. A aparência, por si só, é uma orientação ruim para escolher o tipo.

Faça cinco perguntas

1. Quais são os valores típicos e quais extremos precisam caber?
2. Os valores serão usados em cálculos?
3. Eles precisam ser exatos ou uma aproximação é aceitável?
4. Como devem ser ordenados e comparados?
5. Que tamanho comporta valores futuros realistas?

Valores monetários e medidas

Valores monetários precisam ser exatos. No PostgreSQL, MySQL e SQL Server, um preço pode usar DECIMAL(8, 2). Três itens a R$ 12,50 custam exatamente R$ 37,50. O armazenamento binário de ponto flutuante pode deixar pequenos erros após somas repetidas, tornando comparações exatas pouco confiáveis. No SQLite, declarar DECIMAL não oferece armazenamento decimal exato; use centavos inteiros para valores exatos, de modo que R$ 12,50 seja armazenado como 1250.

Uma medida como peso pode usar REAL quando pequenas diferenças de arredondamento são aceitáveis. Escolha a unidade como parte do significado da coluna: weight_lb torna a unidade libra visível em seu nome. Um tipo numérico sozinho não registra essa unidade.

A moeda também precisa ser identificada. Se uma tabela mistura moedas, acrescente currency_code, como USD, EUR ou JPY. As casas decimais variam conforme a moeda, e moedas diferentes devem ser convertidas antes que seus valores possam ser somados.

Códigos e nomes são texto

Use texto para CEPs americanos, telefones, números de conta e códigos de estoque. O CEP americano de Boston '02108' perde o zero inicial quando convertido em inteiro. VARCHAR(10) também pode armazenar ZIP+4, como '02108-1234'. Telefones podem conter um sinal de mais, espaços e hífens. Esses caracteres fazem parte da representação de um identificador, não são sinais aritméticos.

Reserve espaço para nomes e endereços reais. “Christopher Montgomery” tem 22 caracteres, então VARCHAR(10) é curto demais. PostgreSQL e SQL Server rejeitam o valor; MySQL o rejeita no modo estrito e pode truncá-lo nos demais casos. O SQLite o armazena porque ignora os comprimentos de texto declarados. Um campo de comprimento variável generoso evita rejeitar nomes comuns sem reservar seu comprimento máximo para cada linha.

A ordenação revela uma escolha errada

A ordenação de texto compara caracteres. Números armazenados como texto podem aparecer na ordem '1', '10', '2', '25', '3'. Uma coluna numérica ordena esses valores numericamente. Escolher texto para todos os campos transfere o trabalho de verificação e conversão para os cálculos posteriores.

Datas apresentam uma armadilha semelhante. Datas em texto no formato dos EUA colocam '12/01/2025' depois de '03/02/2026' na ordem de texto, embora dezembro de 2025 seja anterior. Use um tipo de data ou texto ISO formatado de maneira consistente no SQLite para preservar a ordem do calendário.

Leia os tipos de um produto em conjunto

Um produto pode usar product_id INTEGER, sku VARCHAR(20), name VARCHAR(100), price DECIMAL(8, 2), weight_lb REAL, in_stock BOOLEAN e added_on DATE. Cada tipo atende a uma função: identificação, armazenamento de código, nome, valor monetário exato, medida, indicador ou data. No SQLite, armazene o preço como centavos inteiros e a data como texto ISO.

NULL marca um valor ausente. Ele é diferente de zero, do texto vazio '' e do texto 'NULL'. Um desconto conhecido de 0 significa que não há desconto; um desconto NULL significa que o valor não foi registrado. Uma coluna que permite NULL aceita dados ausentes, enquanto NOT NULL exige um valor.

Ausência tem mais de um significado

James Wilson não tem telefone registrado. O pedido 102 não tem data de envio porque ainda não foi enviado. Uma empresa cadastrada como cliente pode não ter um sobrenome aplicável. Todos podem ser representados por NULL, mas NULL não registra qual motivo se aplica. Um dicionário de dados deve informar o significado em cada coluna.

Texto vazio é um valor de texto presente no PostgreSQL e no SQLite. Atualmente, o Oracle trata texto vazio como NULL. Ferramentas de consulta podem exibir ambos como uma célula aparentemente vazia, então a aparência sozinha não permite distingui-los.

Comparações podem ser desconhecidas

Comparações SQL têm três resultados possíveis: TRUE, FALSE e UNKNOWN. Uma comparação que envolve NULL, incluindo NULL = NULL, resulta em UNKNOWN. Não se sabe se duas informações ausentes têm o mesmo valor.

Uma cláusula WHERE mantém apenas resultados TRUE. Leia estas condições:

• phone IS NULL encontra telefones ausentes.
• phone IS NOT NULL encontra telefones registrados.
• phone = NULL resulta em UNKNOWN e não encontra nenhuma linha.

Negar uma comparação não recupera um valor ausente. Acrescente Daniel Brown, cujo estado é NULL, aos quatro clientes da loja. A condição state <> 'TX' mantém CO, MA e WA: três linhas. Daniel é excluído porque a comparação de seu estado é UNKNOWN. Para incluir também estados ausentes, a condição é state <> 'TX' OR state IS NULL.

Combine condições com cuidado

Pense em UNKNOWN como “pode ser TRUE ou FALSE”. Um resultado só é determinado se ambas as possibilidades produzirem o mesmo resultado.

Cálculos e resumos

A aritmética comum com NULL resulta em NULL: 5 + NULL é NULL. O preço de um item multiplicado por uma quantidade ausente também é ausente, não zero. Concatenar texto com || e NULL resulta em NULL no PostgreSQL e no SQLite; a concatenação do Oracle trata NULL como texto vazio.

Funções de resumo geralmente ignoram entradas NULL. Com cinco clientes, incluindo James e Daniel sem telefone, COUNT(*) conta as cinco linhas. COUNT(phone) conta os três telefones registrados. A média de 4, NULL e 2 é 3, porque os dois números conhecidos são divididos por dois; tratar NULL como zero resultaria incorretamente em 2.

Use NOT NULL para informações que devem estar presentes, como uma data de pedido. Isso não exige um número positivo nem texto não vazio: essas são regras separadas. Chaves primárias exigem identificadores diferentes de NULL; tabelas comuns do SQLite têm uma exceção histórica para algumas declarações de chave primária, então NOT NULL explícito é importante nesse caso.

Uma chave identifica uma linha por meio de seus valores. Nomes podem se repetir; identificadores de clientes distinguem registros para que possam ser lidos, alterados ou vinculados.

Teste a unicidade e a minimalidade

Uma superchave é uma coluna ou combinação que identifica uma linha de forma única. Uma chave candidata é uma superchave mínima: remover qualquer coluna faz essa garantia desaparecer. Escolha uma candidata como chave primária; as demais são chaves alternativas.

Suponha que employee_id, ssn e email sejam cada um obrigatório e único. Cada um é uma chave candidata. (employee_id, department) é uma superchave, mas não uma candidata: employee_id sozinho identifica o funcionário. Um sobrenome repetido não passa no teste de unicidade.

Quatro clientes com sobrenomes diferentes não estabelecem uma chave: um quinto pode compartilhar um sobrenome. A unicidade deve valer para todos os dados futuros permitidos. Uma repetição refuta uma chave proposta; uma amostra sem repetições ainda precisa de uma regra de negócio que a sustente.

Leia a declaração

Uma tabela tem no máximo uma chave primária. Seus valores são únicos e suas colunas não podem conter NULL. Valores estáveis evitam alterações repetidas nas referências. Procure PRIMARY KEY: nem o nome nem a posição de uma coluna a declara como chave.

Se o cliente 1 existe, outro cliente com a chave 1 é rejeitado. Uma chave omitida precisa de um valor padrão ou gerado. INTEGER PRIMARY KEY do SQLite gera um inteiro quando o valor é omitido ou informado como NULL. Historicamente, algumas outras declarações de chave primária em tabelas comuns do SQLite permitem NULL; NOT NULL explícito, uma tabela STRICT ou a forma de chave primária inteira elimina essa brecha.

Leia uma chave composta

Em enrollments(student_id, course_id, term, grade), um aluno pode cursar várias disciplinas e cursar uma delas novamente em outro período. (student_id, course_id, term) identifica uma matrícula: uma chave primária composta, não três chaves primárias separadas.

Os componentes individuais podem se repetir; a combinação completa não pode. A maioria dos SGBDs cria um índice de chave primária para buscas, mas a chave não garante a ordem dos resultados de uma consulta.

Uma chave natural vem de dados do mundo real, como o VIN de um veículo, o ISBN de uma edição de livro ou um código de estado. Uma chave substituta existe apenas para identificar uma linha, muitas vezes como um inteiro gerado ou UUID.

Escolha um identificador duradouro

Prefira valores únicos, presentes, estáveis, compactos e seguros para compartilhar. Nomes se repetem; telefones e e-mails mudam ou são compartilhados. Números de seguridade social são sensíveis e alguns clientes não os têm; usá-los em tabelas que fazem referências espalha essas informações.

Um customer_id gerado permite que Maria mantenha o identificador 1 quando seus dados de contato mudam. Um state_code natural, como TX, pode funcionar bem porque é compacto, padronizado e útil em registros de endereço.

Proteja identificadores de negócio separadamente

A mesma pessoa pode se cadastrar duas vezes e receber dois identificadores substitutos. Os identificadores distinguem linhas; eles não detectam pessoas duplicadas.

Se o e-mail deve identificar cada conta, use NOT NULL UNIQUE. UNIQUE sozinho permite vários valores NULL no PostgreSQL, SQLite e MySQL. O SQL Server normalmente permite um NULL em uma restrição de unicidade de uma única coluna. Presença e unicidade são regras separadas.

O e-mail obrigatório e único é uma chave alternativa. Alterá-lo deixa o número substituto do cliente nos pedidos existentes inalterado. Alterar uma chave primária referenciada também exige que suas referências nas tabelas filhas permaneçam consistentes.

Reconheça a sintaxe de chave gerada

O PostgreSQL também tem a forma mais antiga SERIAL. Exclusões, inserções malsucedidas e operações canceladas podem deixar lacunas. Os identificadores 1, 2 e 4 identificam três linhas, não quatro. Renumerar para fechar lacunas pode quebrar referências.

Reconheça UUIDs

Um UUID é um identificador de 128 bits, normalmente escrito com 36 caracteres e hífens: 7c9e6679-7425-40de-944b-e07fc1f90ae7. Computadores podem gerá-los independentemente com risco muito baixo de colisão, o que é útil quando registros de vários lugares serão combinados.

UUIDs ocupam mais espaço e são mais difíceis de ler que inteiros pequenos. Escolha de acordo com a forma como os registros são criados e referenciados. Qualquer um dos tipos de chave é um rótulo: seu valor máximo não é uma contagem de linhas, e sua ordem não precisa indicar os horários dos eventos.

Uma chave estrangeira é uma coluna ou grupo de colunas que faz referência a uma chave primária ou a outra chave única adequada. A tabela que contém a referência é a filha; a tabela para a qual ela aponta é a pai. Um valor de chave estrangeira diferente de NULL deve corresponder a uma chave pai existente quando a restrição é imposta.

Siga um valor entre tabelas

orders.customer_id faz referência a customers.customer_id. O pedido 102 aponta para o cliente 2, James Wilson. Os pedidos 101 e 103 apontam para a cliente 1, Maria Garcia. A repetição é permitida na chave estrangeira; a chave pai referenciada é única.

Essa regra é a integridade referencial. Um pedido para o cliente 99 é rejeitado se o cliente 99 não existir. Caso contrário, seria uma linha órfã: uma linha filha sem uma linha pai correspondente. Um nome sozinho não cria uma restrição. Uma chave estrangeira chamada placed_by ainda pode fazer referência a customer_id; a referência declarada cria o vínculo, com tipos correspondentes para as colunas de chave.

Opcional ou obrigatório

Um coupon_id que permite NULL pode ser NULL quando um pedido não tem cupom. Um customer_id declarado NOT NULL exige que todo pedido tenha uma referência a cliente, e a chave estrangeira exige que esse cliente exista. Essas duas restrições funcionam juntas: uma exige um valor e a outra verifica a referência.

Chaves estrangeiras não precisam atravessar limites de tabelas. Em employees(employee_id, name, manager_id), manager_id pode fazer referência a employee_id na mesma tabela. A pessoa que dirige a empresa pode ter uma referência NULL para gerente.

Alterações na tabela pai precisam de uma regra

Com a ação padrão, a cliente 1 não pode ser excluída enquanto os pedidos 101 e 103 ainda fizerem referência a ela. A propagação em cascata de um pedido para seus itens pode fazer sentido porque esses itens pertencem ao pedido. ON UPDATE especifica o comportamento correspondente quando uma chave pai muda. A propagação em cascata não significa que excluir uma linha filha exclua sua linha pai.

Referências compostas e aplicação

Se um item de pedido é identificado por (order_id, product_id), um envio que faz referência a esse item precisa de ambas as colunas. A combinação deve corresponder a um item existente. Encontrar um pedido e um produto separadamente não basta: esse produto pode nunca ter aparecido naquele pedido. Uma referência composta obrigatória declara todas as suas colunas como NOT NULL.

PostgreSQL, SQL Server, Oracle e o mecanismo InnoDB usual do MySQL impõem as chaves estrangeiras declaradas. No SQLite, habilite e verifique a aplicação de chaves estrangeiras em cada conexão com PRAGMA foreign_keys = ON; antes de depender dela. Uma restrição declarada, mas desativada, não pode proteger as linhas. Chaves estrangeiras também não combinam resultados de consultas por si só; uma consulta deve seguir o vínculo explicitamente, geralmente por meio de uma junção.

Para identificar um relacionamento, faça duas perguntas: “Para uma linha aqui, quantas linhas ali podem ser vinculadas?” e depois a pergunta inversa. Inclua o mínimo e o máximo. A amostra de hoje mostra o que aconteceu; as restrições descrevem o que é permitido.

Um cliente, muitos pedidos

Um cliente pode fazer zero ou mais pedidos. Cada pedido da loja pertence a exatamente um cliente porque orders.customer_id é uma chave estrangeira que não permite NULL. Esse é um relacionamento um para muitos. A chave estrangeira pertence a orders, o lado muitos: cada pedido armazena uma referência a cliente.

Maria tem os pedidos 101 e 103; James tem o pedido 102. Aisha e Wei não têm nenhum. Sua ausência de orders é válida. Uma chave estrangeira exige uma linha pai para cada linha filha, mas não exige que toda linha pai tenha uma linha filha.

Um para um também exige unicidade

Em user_profiles(user_id, bio, photo_url), considere que user_id seja tanto a chave primária quanto uma chave estrangeira para users. Cada perfil faz referência a um usuário, e um usuário pode ter no máximo um perfil porque a chave do perfil não pode se repetir. Um usuário pode ainda não ter perfil.

Uma chave estrangeira sem unicidade permitiria vários perfis para o mesmo usuário, resultando em um para muitos. A restrição de unicidade altera o máximo. Essas tabelas de perfil separadas podem manter dados opcionais ou sensíveis à parte do registro principal do usuário.

Muitos para muitos usa uma tabela de pares

Um pedido pode conter vários produtos, e um produto pode aparecer em vários pedidos. Uma tabela associativa, também chamada de tabela de junção, de ligação ou intermediária, registra cada combinação:

order_id faz referência a orders; product_id faz referência a products. A chave primária composta (order_id, product_id) permite o mesmo produto em pedidos diferentes, mas impede que o mesmo par apareça duas vezes. Dois vínculos um para muitos implementam o relacionamento muitos para muitos.

quantity e unit_price pertencem à combinação. Eles descrevem quanto daquele produto foi vendido naquele pedido e o preço cobrado naquele momento. O preço atual de um produto pode mudar depois; isso não deve reescrever o valor cobrado no passado.

Para o pedido 101, os dois valores de item são duas canecas a R$ 12,50, resultando em R$ 25,00, e um carregador a R$ 8,99. Juntos, custam R$ 33,99. A quantidade indica quantas canecas foram compradas; armazenar duas linhas duplicadas de caneca entraria em conflito com a chave escolhida para essa tabela.

Evite listas e espaços fixos

Uma célula product_ids contendo “11,12” esconde várias referências dentro de um valor de texto. Colunas como product1, product2 e product3 impõem um limite fixo e deixam espaços sem uso. Uma tabela associativa acrescenta uma linha para cada combinação adicional e permite que o SGBD verifique cada referência separadamente.

Um relacionamento autorreferente usa o mesmo padrão dentro de uma tabela: muitos funcionários podem fazer referência ao mesmo gerente por meio de manager_id. O gerente também é uma linha de funcionário. Leia cada vínculo como um papel, para manter distintos o identificador do funcionário e a referência ao gerente.

Um esquema descreve tabelas, colunas, tipos de dados e restrições. Uma instância é o conjunto de dados armazenados em um determinado momento. Adicionar um pedido altera a instância; adicionar uma nova coluna altera o esquema. O esquema informa o que pode ser armazenado, enquanto as linhas mostram o que está armazenado agora.

Leia uma descrição abreviada

customers(customer_id, first_name, last_name, email, phone, city, state, zip_code) lista uma tabela e suas colunas. Anotações podem sublinhar chaves primárias ou marcá-las com PK e marcar referências com FK. Por exemplo, orders(order_id PK, customer_id FK → customers, order_date, shipped_date) identifica a chave principal e o vínculo com o cliente.

Leia uma definição completa de tabela

CREATE TABLE orders (
  order_id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL REFERENCES customers (customer_id),
  order_date DATE NOT NULL,
  shipped_date DATE
);

Leia uma coluna de cada vez. order_id é a chave primária inteira. customer_id é obrigatório e deve fazer referência a um cliente. order_date é obrigatório. shipped_date pode ser NULL. Essa definição fornece a estrutura permitida, não uma lista dos pedidos existentes.

As restrições respondem a perguntas diferentes:

Um valor padrão não substitui um valor inválido informado. Se status tem DEFAULT 'pending', omitir o status fornece 'pending'; um valor informado ainda deve atender às demais regras da coluna.

Combine regras para um item de pedido

CREATE TABLE order_items (
  order_id INTEGER NOT NULL REFERENCES orders (order_id),
  product_id INTEGER NOT NULL REFERENCES products (product_id),
  quantity INTEGER NOT NULL CHECK (quantity > 0),
  unit_price DECIMAL(8, 2) NOT NULL,
  PRIMARY KEY (order_id, product_id)
);

A chave primária na parte inferior usa duas colunas. Um segundo item para o mesmo pedido e produto é rejeitado. A quantidade 0 não passa na verificação. Uma quantidade ausente não passa em NOT NULL: a verificação sozinha permitiria NULL porque NULL > 0 é UNKNOWN, não FALSE. NOT NULL explícito em ambas as partes da chave também evita a exceção histórica do SQLite para chaves compostas que permitem NULL. No SQLite, use centavos inteiros para um unit_price exato; a declaração decimal sozinha não oferece armazenamento exato.

Encontre o esquema e seus significados

No terminal do SQLite, .schema orders exibe a definição; no psql do PostgreSQL, \d orders a descreve. As visões INFORMATION_SCHEMA listam metadados estruturais no PostgreSQL, MySQL e SQL Server. O SQLite lista objetos em sqlite_schema, e ferramentas gráficas mostram tabelas e colunas em uma árvore.

“Esquema” também é o nome de um espaço de nomes em sistemas como PostgreSQL e SQL Server. sales.orders significa a tabela de pedidos no esquema de vendas. Um dicionário de dados fornece significados que a estrutura não consegue expressar, como a moeda do preço ou se uma data de envio ausente significa “não enviado”. Para ver as linhas, uma consulta como SELECT * FROM orders; lê a instância atual.

Um diagrama do esquema representa cada tabela como uma caixa. O título nomeia a tabela; o conteúdo lista as colunas e muitas vezes os tipos. PK marca chaves primárias, e FK marca chaves estrangeiras. Linhas de relacionamento mostram qual chave estrangeira faz referência a qual chave pai.

Primeiro identifique o tipo de linha

Alguns diagramas usam uma seta de uma chave estrangeira para sua chave referenciada. Uma seta de orders.customer_id para customers.customer_id descreve a direção da referência. Outras ferramentas usam símbolos nas extremidades para descrever quantas linhas podem ser vinculadas. Verifique a legenda do diagrama: a direção de uma seta e a quantidade de linhas em um relacionamento são informações diferentes.

Leia os símbolos de pé de galinha

Na notação pé de galinha, uma barra significa um, um círculo significa zero e um pé de três pontas significa muitos. Cada extremidade de linha indica um mínimo e um máximo. O símbolo mais próximo da tabela fornece o máximo; o outro fornece o mínimo.

Ao ler a partir de uma tabela, olhe os símbolos ao lado da outra tabela. Esses símbolos descrevem quantas linhas ali podem corresponder à sua linha inicial.

Analise clientes e pedidos

A linha da loja tem símbolos de exatamente um junto a customers e símbolos de zero ou mais junto a orders.

1. Comece com um cliente. Olhe a extremidade de pedidos: o cliente pode ter zero ou mais pedidos.
2. Comece com um pedido. Olhe a extremidade de clientes: o pedido pertence a exatamente um cliente.
3. Verifique a definição: a chave estrangeira que não permite NULL está em orders, então esse é o lado muitos, e cada pedido precisa de um cliente válido.

O pé de galinha fica junto à tabela que contém a chave estrangeira repetível. Ler a extremidade próxima ao começar pela mesma tabela inverte o significado. Uma referência a cliente que permitisse NULL mudaria a extremidade de clientes para zero ou um; ela não limitaria cada cliente a um pedido.

Reconheça uma tabela associativa

A loja tem vínculos um para muitos de orders para order_items e de products para order_items. Ambas as extremidades muitos se encontram em order_items. Suas duas chaves estrangeiras formam a chave primária. Essa estrutura permite que um pedido contenha vários produtos e que um produto apareça em vários pedidos.

O diagrama descreve conexões permitidas, não as contagens de hoje. Ele permite que Maria tenha vários pedidos e que Aisha não tenha nenhum. Para saber quantos pedidos cada uma realmente tem, leia as linhas. Um mínimo de um da tabela pai para a filha pode expressar uma regra de negócio adicional; uma chave estrangeira sozinha não exige que uma linha pai tenha linhas filhas.

Reconheça estilos de diagrama relacionados

Um diagrama entidade-relacionamento criado durante o projeto pode mostrar entidades do negócio antes de as tabelas existirem. Diagramas no estilo Chen usam ovais para atributos e losangos para relacionamentos. Um diagrama do esquema mostra as tabelas reais e suas chaves declaradas. Ambos ajudam a comunicar a estrutura, mas seus símbolos precisam ser lidos de acordo com suas próprias legendas.

Localize cada informação solicitada e siga as chaves que a conectam ao registro inicial. Nomes podem se repetir ou mudar; compare os valores das chaves.

Encontre o cliente de um pedido

“Em que cidade mora o cliente que fez o pedido 102?” segue este caminho:

1. Encontre o pedido 102 por orders.order_id.
2. Leia seu customer_id: 2.
3. Encontre o cliente 2 por customers.customer_id.
4. Leia customers.city: Denver.

O número de pedido 102 não é o identificador do cliente. Junções SQL automatizam essas correspondências de chave; posições na exibição não conectam os registros.

Encontre produtos e um total histórico

O pedido 101 tem estas linhas em order_items. Siga cada product_id até products para obter seu nome:

Use o preço registrado no item para obter o valor cobrado:

• Duas canecas a R$ 12,50 custam R$ 25,00.
• Um carregador a R$ 8,99 custa R$ 8,99.
• Total: R$ 33,99.

O preço atual do produto poderia indicar incorretamente o custo de um pedido antigo. O pedido 102 tem uma luminária a R$ 34,00; o pedido 103 tem quatro canecas a R$ 12,50, totalizando R$ 50,00.

Interprete valores ausentes e regras

A data de envio do pedido 102 é NULL, documentado aqui como “não enviado”. Teste-a com IS NULL, não com igualdade a NULL.

Leia todas as restrições relevantes ao avaliar uma alteração:

• Um item para o pedido 104 é rejeitado se esse pedido não existir.
• Outro item com a chave (101, 11) é rejeitado porque o par já existe.
• A quantidade 0 não passa na verificação de quantidade positiva.
• O comportamento padrão da chave estrangeira bloqueia a exclusão do produto 11 enquanto itens fizerem referência a ele.

Uma chave não usada não torna uma linha válida quando sua referência está ausente.

Identifique as novas linhas

Um cliente já cadastrado que compra dois produtos diferentes já existentes acrescenta uma linha a orders e duas linhas a order_items. O cliente e os produtos já existem. Oferecer um novo produto acrescenta uma linha a products, sem exigir um pedido.