# 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!
***
###