10.5 - As Chaves Mestras — Primária e Estrangeira

Já montamos a estrutura básica do nosso QG com tabelas, colunas e linhas. Mas como a gente garante que cada linha (cada usuário, cada post, cada jogo) seja única? E como a gente faz nossas tabelas "conversarem" entre si?

É aqui que entram as Chaves Mestras! Elas são colunas especiais que têm superpoderes no nosso banco de dados.

Existem dois tipos principais que vamos usar direto:

1. Chave Primária (Primary Key - PK): O RG único de cada linha.

2. Chave Estrangeira (Foreign Key - FK): O elo secreto que conecta tabelas.

Vamos desvendar cada uma!

Chave Primária (PK): O RG da Linha 🆔

Pensa na sua carteira de identidade (RG) ou no seu CPF. É um número único, só seu, que te identifica em qualquer lugar do Brasil, certo? Ninguém mais tem o mesmo número.

A Chave Primária (PK) funciona exatamente assim dentro de uma tabela! É uma coluna (ou um conjunto de colunas) que garante que cada linha naquela tabela seja única e possa ser identificada sem erro.

Regras de Ouro da Chave Primária:

1. NÃO PODE SE REPETIR: Assim como não existem dois CPFs iguais, os valores na coluna da chave primária não podem se repetir NUNCA dentro da mesma tabela.

2. NÃO PODE SER NULA (VAZIA): Toda linha TEM que ter um valor na chave primária. Não dá pra ter um cidadão sem RG!

Pra que serve?

• Identificação Única: Permite que você (e o banco de dados) encontre exatamente a linha que você quer, sem confusão. "Quero atualizar o email do usuário com ID 5". Pronto!

• Base para Conexões: A chave primária é a "âncora" que outras tabelas vão usar pra se conectar a esta (através das chaves estrangeiras, que veremos a seguir).

Como escolher a PK?

• IDs Numéricos Sequenciais: Muitos bancos usam um número inteiro que aumenta automaticamente (1, 2, 3...). É simples, mas pode ter uns probleminhas em sistemas muito grandes ou distribuídos.

• CPF, Email, Username? Às vezes, uma informação que já é única na vida real (como CPF ou email) poderia ser PK. Mas e se a pessoa mudar de email? Ou se não quisermos guardar o CPF? Geralmente não é a melhor ideia.

• UUID (Universally Unique Identifier): Esse é o queridinho do Supabase (e de muitos sistemas modernos)! É um código GIGANTE e super aleatório (tipo f47ac10b-58cc-4372-a567-0e02b2c3d479). A chance de gerar dois UUIDs iguais no universo é praticamente ZERO! É ótimo porque:

  • É único mesmo entre tabelas diferentes.

  • Você pode gerar o ID antes mesmo de salvar no banco.

  • É mais seguro (não expõe a sequência de quantos usuários você tem, por exemplo).

No Supabase, quando você cria uma tabela, ele geralmente já sugere criar uma coluna id do tipo uuid e marcá-la como Chave Primária. É uma ótima prática!

Chave Estrangeira (FK): O Elo Secreto 🔗

Ok, cada linha tem seu RG (a PK). Mas como a gente conecta as informações? Como eu sei qual Usuario escreveu qual Post? Ou quais Produtos estão num Pedido?

É aí que entra a Chave Estrangeira (Foreign Key - FK)! Ela é a cola que une nossas tabelas.

A FK é uma coluna em uma tabela que guarda a Chave Primária de uma linha de OUTRA tabela. Ela cria um link, uma referência, um relacionamento.

Exemplo:

Imagina a tabela posts:

id (PK - uuid)	texto_do_post	data_publicacao	usuario_id (FK -> usuarios.id)	numero_likes
a1b2c3d4...	"Que dia legal!"	2025-06-03 10:00:00	f47ac10b... (ID do João)	15
e5f6g7h8...	"Aprendendo Supabase!"	2025-06-03 11:30:00	z9y8x7w6... (ID da Maria)	22
i9j0k1l2...	"Adorei o capítulo 5"	2025-06-03 15:00:00	f47ac10b... (ID do João)	10

A coluna usuario_id na tabela posts é uma Chave Estrangeira. O valor que ela guarda (f47ac10b... ou z9y8x7w6...) é a Chave Primária de um usuário lá na tabela usuarios.

Assim, olhando pra um post, a gente sabe exatamente quem o escreveu, seguindo o link da FK!

Regras da Chave Estrangeira:

1. Deve Corresponder a uma PK: O valor na coluna FK tem que existir como PK na tabela que ela referencia (a tabela "pai"). Você não pode colocar um usuario_id que não existe na tabela usuarios.

2. Pode se Repetir: Diferente da PK, a FK PODE ter valores repetidos. No exemplo acima, o João (f47ac10b...) escreveu dois posts.

3. Pode ser Nula (às vezes): Dependendo da regra do seu negócio, uma FK pode ser opcional (nula). Exemplo: um comentário pode ser anônimo, então a FK para usuario_id poderia ser nula.

Pra que serve?

• Conectar Informações: Permite cruzar dados de tabelas diferentes (vamos ver isso com JOIN depois!).

• Garantir a Integridade Referencial: O banco de dados te ajuda a não criar "órfãos". Ele não deixa você criar um post com um usuario_id inválido. E (dependendo das regras que você definir), ele pode impedir que você delete um usuário que ainda tem posts associados, ou pode apagar os posts juntos (veremos ON DELETE no capítulo de Constraints).

No Supabase, ao criar uma coluna, você pode clicar no ícone de link (🔗) pra definir que ela é uma Chave Estrangeira e escolher qual tabela e qual coluna (a PK da outra tabela) ela referencia.

Relacionamentos: Como as Tabelas "Conversam" 💬

Essas conexões criadas pelas Chaves Estrangeiras formam os Relacionamentos entre as tabelas.

Os tipos mais comuns são:

• Um-para-Muitos (1:N): É o mais comum! Um registro em uma tabela pode se relacionar com muitos registros em outra. Mas cada registro da segunda tabela só se relaciona com um da primeira.

  • Exemplo: Um Usuario pode ter Muitos Posts. Mas cada Post pertence a apenas Um Usuario. (A FK fica na tabela do lado "Muitos", ou seja, usuario_id fica na tabela posts).

  • Exemplo: Uma Categoria pode ter Muitos Produtos. Mas cada Produto pertence a apenas Uma Categoria.

• Um-para-Um (1:1): Menos comum. Cada registro em uma tabela se relaciona com no máximo um registro na outra, e vice-versa.

  • Exemplo: Um Usuario pode ter Um PerfilDetalhado. Cada PerfilDetalhado pertence a apenas Um Usuario. (Poderia ser uma tabela separada pra guardar infos extras do usuário que nem todos têm).

• Muitos-para-Muitos (N:N): Um pouco mais complexo. Um registro em uma tabela pode se relacionar com muitos registros na outra, e vice-versa.

  • Exemplo: Um Aluno pode se inscrever em Muitas Disciplinas. E Uma Disciplina pode ter Muitos Alunos.

  • Exemplo: Um Post pode ter Muitas Tags (tipo #supabase, #database). E Uma Tag pode estar em Muitos Posts.

  • Como resolve? A gente não conecta as duas tabelas direto. Criamos uma tabela intermediária (às vezes chamada de tabela de junção ou tabela associativa) que tem duas Chaves Estrangeiras, uma pra cada tabela original.

    • Para Alunos e Disciplinas, teríamos uma tabela inscricoes com aluno_id (FK para alunos) e disciplina_id (FK para disciplinas).

    • Para Posts e Tags, teríamos uma tabela post_tags com post_id (FK para posts) e tag_id (FK para tags).

Entender esses relacionamentos é crucial pra modelar seu banco de dados corretamente!

Ufa! Chaves Primárias e Estrangeiras são o coração dos bancos de dados relacionais. Elas garantem a identidade única e permitem que a gente conecte tudo!

No próximo módulo, vamos finalmente aprender a "conversar" com nosso banco usando a linguagem secreta SQL! Vamos aprender a buscar, inserir, atualizar e deletar dados usando comandos como SELECT, INSERT, UPDATE e DELETE. Preparado(a) pra dar ordens ao Supabase? Bora!

---