Bancos de dados relacionais: tabelas, chaves e consultas

Um banco de dados relacional organiza informações em relações, geralmente apresentadas como tabelas, e permite consultá-las por operações bem definidas. As relações não são apenas planilhas colocadas lado a lado. Seu significado depende de atributos, domínios, chaves e restrições que descrevem quais estados dos dados são permitidos.

Considere uma biblioteca que registra livros e empréstimos. O cadastro de um exemplar descreve o objeto disponível; o registro de um empréstimo descreve um evento. Separar essas entidades e ligá-las por identificadores permite consultar o histórico sem repetir toda a descrição do exemplar em cada nova retirada.

Relações, linhas, colunas e significado dos dados

Uma relação tem atributos e tuplas; no uso cotidiano, falamos em colunas e linhas. Cada coluna representa uma característica com um domínio de valores possíveis. Datas, números e textos possuem comportamentos diferentes, e a escolha do tipo influencia comparações, validações e operações disponíveis nas consultas.

No modelo relacional matemático, uma relação é um conjunto de tuplas e não possui ordem intrínseca. Em SQL, resultados podem conter linhas repetidas, conforme a consulta, e a ordenação só deve ser considerada garantida quando explicitamente solicitada. Essa diferença importa ao interpretar contagens e ao exibir os primeiros resultados.

Uma coluna também precisa de unidade e convenção. “Prazo” pode representar dias corridos, dias úteis ou uma data limite; cada interpretação produz consultas diferentes. Registre a definição escolhida no esquema e na documentação. O banco consegue verificar formatos e restrições declaradas, mas não adivinha a intenção de uma coluna mal definida.

A linguagem SQL fornece mecanismos para definir estruturas e manipular dados. O sistema gerenciador executa essas operações, administra armazenamento, concorrência e permissões. SQL é uma linguagem; PostgreSQL é um exemplo de gerenciador. Confundir os dois dificulta distinguir características gerais do modelo de recursos específicos de uma implementação.

Chaves primárias, candidatas e estrangeiras

Uma chave candidata é um conjunto mínimo de atributos capaz de identificar uma tupla. “Mínimo” significa que retirar um atributo elimina essa capacidade. Uma das candidatas pode ser escolhida como chave primária. O nome de uma pessoa costuma ser inadequado porque pode se repetir e mudar ao longo do tempo.

A chave primária identifica cada linha e não admite valores nulos. Ela pode ter uma coluna, como exemplar_id, ou várias colunas. Um identificador artificial facilita referências estáveis, mas não substitui outras regras de unicidade: se o código patrimonial precisa ser exclusivo, essa exigência deve ser declarada separadamente.

Uma chave estrangeira exige correspondência com uma chave referenciada, conforme suas regras e tratamento de nulos. Em empréstimos, exemplar_id pode referenciar exemplares. Isso impede registrar um empréstimo para um identificador inexistente, mas não verifica sozinho se a pessoa está autorizada a retirar o livro.

A cardinalidade descreve quantas ocorrências podem se relacionar. Uma pessoa pode ter vários empréstimos ao longo do tempo; cada empréstimo do exemplo pertence a uma pessoa. Uma relação muitos para muitos, como alunos e disciplinas, costuma ser representada por uma tabela associativa que registra cada vínculo e seus atributos próprios.

Também é preciso decidir o que acontece quando o registro referenciado é excluído. Bloquear a exclusão, propagar a operação ou alterar a referência são políticas distintas. Uma exclusão em cascata não é mera conveniência técnica: pode apagar um histórico necessário. A regra deve refletir o significado dos dados e as necessidades de conservação.

Restrições de integridade e valores ausentes

A integridade depende de regras explícitas. NOT NULL exige presença de valor; UNIQUE impõe unicidade segundo a semântica do gerenciador; CHECK verifica uma condição sobre dados; FOREIGN KEY protege referências. Um esquema bem definido faz o banco recusar estados inválidos mesmo quando diferentes aplicações acessam a mesma base.

No exemplo, a data de devolução pode ser ausente enquanto o empréstimo estiver aberto. Quando presente, uma regra pode exigir que ela não anteceda a retirada. A ausência precisa ser representada de maneira consistente, em vez de usar textos como “pendente” dentro de uma coluna cujo tipo deveria ser data.

O marcador NULL representa ausência ou desconhecimento, conforme a interpretação da coluna. Não é zero nem texto vazio. Comparações usuais com NULL não funcionam como comparações com valores conhecidos; para identificar nulos, utiliza-se IS NULL. Condições SQL podem produzir verdadeiro, falso ou desconhecido, o que afeta a seleção de linhas.

Uma restrição CHECK e uma obrigação NOT NULL cumprem tarefas diferentes. Uma condição que resulta em desconhecido por causa de NULL pode não rejeitar a linha. Portanto, exigir que uma quantidade seja positiva não resolve necessariamente a obrigação de preenchê-la. As duas condições devem ser consideradas quando ambas fazem parte da regra.

Nem toda regra cabe em uma restrição simples. Impedir dois empréstimos abertos para o mesmo exemplar pode exigir recurso apropriado do gerenciador e atenção à concorrência. Verificar apenas na interface, antes de inserir, permite que duas solicitações simultâneas passem pela mesma checagem e produzam um conflito.

Consultas e junções sem confundir repetição

Uma consulta declara quais informações devem compor o resultado. SELECT escolhe expressões ou colunas; FROM indica as fontes; WHERE restringe linhas. A instrução SELECT exemplar_id FROM emprestimos WHERE data_devolucao IS NULL procura identificadores de exemplares com empréstimos ainda abertos no esquema didático.

Uma junção combina linhas que satisfazem uma condição. Ao ligar pessoas a empréstimos por pessoa_id, cada empréstimo encontra seu usuário correspondente. Se uma pessoa possui três empréstimos, seu nome pode aparecer três vezes. Essa repetição no resultado decorre da relação um para muitos, e não demonstra três cadastros da mesma pessoa.

Um INNER JOIN mantém combinações correspondentes. Um LEFT JOIN também preserva linhas da tabela à esquerda sem correspondência, preenchendo o outro lado com nulos. Isso permite listar pessoas sem empréstimos. Colocar uma condição sobre a tabela da direita no WHERE pode eliminar essas linhas e mudar o efeito pretendido da junção.

Contagens exigem atenção à unidade analisada. COUNT(*) conta linhas do resultado, enquanto COUNT(coluna) ignora nulos naquela expressão. Depois de um LEFT JOIN, contar todas as linhas pode atribuir uma ocorrência a uma pessoa sem empréstimos. Contar a chave do empréstimo distingue a ausência de correspondência nesse cenário.

Usar DISTINCT para esconder linhas repetidas pode mascarar uma junção incorreta. Antes, confira as chaves da condição e o que cada linha deveria representar. Um relatório pode desejar uma linha por pessoa ou uma por empréstimo; essas perguntas exigem resultados diferentes. Definir a unidade do resultado vem antes de escolher agregações.

Transações e um roteiro para conferir o modelo

Uma transação reúne operações que precisam ser tratadas como uma unidade. Se registrar uma retirada depende de atualizar informações relacionadas, uma falha intermediária não deve deixar apenas parte da alteração concluída. BEGIN, COMMIT e ROLLBACK expressam esse controle em SQL, conforme as operações e regras do gerenciador.

O isolamento influencia como operações simultâneas observam dados e entram em conflito. Não basta testar um fluxo com um único usuário. O modelo e o nível de isolamento precisam preservar as regras quando duas sessões alteram o mesmo recurso. Índices podem acelerar consultas e apoiar certas restrições, mas não corrigem automaticamente um significado de dados ambíguo.

A organização interna de dados também se conecta a estruturas de dados, embora o modelo lógico não determine sozinho a estrutura física usada pelo gerenciador. Em uma aplicação com programação orientada a objetos, classes e tabelas ainda exigem um mapeamento deliberado; não são representações automaticamente equivalentes.

Perguntas frequentes sobre bancos relacionais

Uma tabela de banco é igual a uma planilha?

A aparência pode ser parecida, mas o banco oferece tipos, restrições, consultas e controle de transações segundo um esquema. O ponto decisivo é o significado e a integridade das relações, e não apenas a organização visual em linhas e colunas.

Uma chave estrangeira precisa ser única?

Não na tabela que faz a referência. Vários empréstimos podem apontar para o mesmo exemplar em momentos diferentes. A chave referenciada precisa atender aos requisitos de unicidade do gerenciador. Confundir os dois lados impediria representar relações um para muitos.

Uma junção que repete nomes está errada?

Depende do resultado desejado. Um nome repetido por empréstimo pode estar correto. Para obter uma linha por pessoa, é necessário formular essa pergunta na consulta. Confira a condição de junção e a cardinalidade antes de remover repetições com DISTINCT.