🎬 Introdução

Até aqui, produtos viveu sozinho, como se fosse a única coisa que existe no universo. Mas pense num sistema de loja de verdade, existem:

• Clientes
• Pedidos
• Cada pedido tem produtos dentro dele.
• Nenhuma dessas entidades faz sentido sozinha — elas se relacionam.

Esse é, sem dúvida, o capítulo mais importante do curso. Dominar relacionamentos é o que separa quem só sabe criar tabelas soltas de quem sabe modelar um sistema de verdade.

Vamos usar como exemplo um mini-sistema de pedidos de uma loja, com três entidades: clientes, pedidos e produtos.

🧠 Cardinalidade: Quantos se Relacionam com Quantos

No Modelo ER, quando duas entidades se relacionam, precisamos definir a cardinalidade — ou seja, quantos registros de uma entidade se conectam com quantos registros da outra.

Existem três tipos principais:

1 : 1 (Um para Um)

Um registro de A se relaciona com no máximo um registro de B, e vice-versa.

graph LR
    A["Pessoa"] ---|"1"| B["1"]
    B --> C["Carteira de Identidade"]

    style A fill:#3b82f6,color:#fff
    style C fill:#3b82f6,color:#fff

Exemplo: uma pessoa tem um único CPF, e um CPF pertence a uma única pessoa.

1 : N (Um para Muitos)

Um registro de A pode se relacionar com vários registros de B, mas cada registro de B se relaciona com apenas um registro de A.

graph LR
    A["Cliente"] -->|"1 cliente<br>faz N pedidos"| B["Pedido"]

    style A fill:#3b82f6,color:#fff
    style B fill:#22c55e,color:#fff

Exemplo: um cliente pode fazer vários pedidos, mas cada pedido pertence a um único cliente.

N : N (Muitos para Muitos)

Vários registros de A podem se relacionar com vários registros de B, ao mesmo tempo.

graph LR
    A["Pedido"] -->|"N pedidos<br>têm N produtos"| B["Produto"]

    style A fill:#22c55e,color:#fff
    style B fill:#f59e0b,color:#fff

Exemplo: um pedido pode ter vários produtos, e um mesmo produto pode aparecer em vários pedidos diferentes.

1️⃣ Relacionamento 1:N — Chave Estrangeira (FOREIGN KEY)