Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

🔗 CAPÍTULO 07: CHAVES, RELACIONAMENTOS E CARDINALIDADE

A grande força de um banco de dados Relacional está no seu próprio nome: Relacionamentos. Neste capítulo, vamos entender como tabelas isoladas se conectam para formar um ecossistema inteligente, capaz de responder perguntas de negócios complexas. 🛡️🧩


🎯 Objetivo Curricular

Dominar o uso de Chaves Estrangeiras (Foreign Keys - FK) para implementar relacionamentos. Compreender e mapear as cardinalidades 1:1, 1:N e N:M no modelo físico.


🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, o RH solicitou um sistema para controlar quais motoristas estão utilizando quais caminhões. Além disso, eles precisam de um sistema de entregas, onde um cliente pode ter vários pacotes. Os estagiários de TI desenharam tabelas, mas não conseguiram "conectá-las".

"Seu desafio é ser o Engenheiro de Integração: usar Chaves Estrangeiras para garantir que nenhum pacote seja registrado sem um cliente responsável, dominando as cardinalidades 1:N e N:M."


🧠 Fundamentos: O Fio Condutor (FK)

A Chave Estrangeira (FK) é o mecanismo de vínculo. Ela é literalmente o valor da Chave Primária (PK) de uma tabela, copiado para dentro de outra tabela.

📊 Diagrama de Cardinalidade (Crow's Foot)

Existem 3 tipos básicos de relacionamentos, representados pela notação "Pé de Galinha":

erDiagram
    CLIENTE ||--o{ PACOTE : "possui (1:N)"
    MOTORISTA |o--o| CAMINHAO : "dirige (1:1)"
    ENTREGADOR }|--|{ ROTA : "atua (N:M)"

🔍 Detalhamento Visual:

  • ||: Indica que a participação é obrigatória (ex: Mínimo 1).
  • o{: Indica "Zero ou Muitos". Um cliente pode acabar de se cadastrar e ainda não ter pacotes (zero), ou pode ter dezenas (muitos).

📐 O Guia de Ouro da Cardinalidade

Onde eu coloco a Chave Estrangeira? Esta é a pergunta que mais derruba candidatos em entrevistas.

CardinalidadeAnalogiaOnde colocar a FK?
1:1 (Um para Um)Casamento exclusivoEm qualquer lado (prefira a tabela dependente).
1:N (Um para Muitos)Pai e FilhosSempre no lado N. (O pacote recebe o ID do Cliente).
N:M (Muitos para Muitos)Atores e FilmesCria uma Terceira Tabela! (Associativa).

📖 Exemplo Guiado: O Relacionamento 1:N (Pai e Filho)

A TecProExpress quer vincular um cliente aos seus pacotes. Veja como aplicar isso no SQL garantindo a ordem correta (DDL -> DML).

🛠️ Código do Exemplo

-- PASSO 1: DDL (Criar a tabela PAI primeiro)
CREATE TABLE cliente_exp (
    id INT PRIMARY KEY,
    nome VARCHAR(100)
);

-- PASSO 2: DDL (Criar a tabela FILHO com a Chave Estrangeira)
CREATE TABLE pacote (
    codigo INT PRIMARY KEY,
    descricao VARCHAR(100),
    id_cliente INT, -- A coluna que receberá o link
    CONSTRAINT fk_cliente_pacote FOREIGN KEY (id_cliente) REFERENCES cliente_exp(id)
);

-- PASSO 3: DML (Inserir Pai, depois Filho)
INSERT INTO cliente_exp VALUES (10, 'Maria Silva');
INSERT INTO pacote VALUES (5001, 'Notebook', 10);

🔍 Detalhamento do Código:

  • A Regra da Ordem: Você não pode nascer sem ter pais. No SGBD, você não pode inserir um pacote apontando para o cliente 10 se o cliente 10 ainda não foi cadastrado (INSERT).
  • FOREIGN KEY: Avisa o SGBD para vigiar esta coluna. Se alguém tentar deletar a Maria Silva, o banco bloqueará, avisando que existem pacotes vinculados a ela.

🛠️ Prática Obrigatória: Resolvendo o Caos do N:M

Cenário: O sistema de Entregadores e Rotas da TecProExpress. Um Entregador pode atuar em Várias Rotas. Uma Rota pode ser feita por Vários Entregadores.

  1. Crie as tabelas independentes entregador e rota.
  2. Crie a tabela associativa escala_trabalho contendo a chave estrangeira de ambos.
  3. Insira dados provando a vinculação.

🚀 Script de Seed (Gabarito de Associação)

-- DDL PAI 1
CREATE TABLE entregador ( id INT PRIMARY KEY, nome VARCHAR(50) );
-- DDL PAI 2
CREATE TABLE rota ( id INT PRIMARY KEY, regiao VARCHAR(50) );

-- DDL FILHO ASSOCIATIVO (A ponte entre os dois)
CREATE TABLE escala_trabalho (
    id_entregador INT,
    id_rota INT,
    PRIMARY KEY (id_entregador, id_rota), -- Chave Composta
    FOREIGN KEY (id_entregador) REFERENCES entregador(id),
    FOREIGN KEY (id_rota) REFERENCES rota(id)
);

-- DML (Carregando a base)
INSERT INTO entregador VALUES (1, 'Carlos'), (2, 'Ana');
INSERT INTO rota VALUES (100, 'Centro'), (200, 'Litoral');

-- DML (O Relacionamento N:M na prática)
INSERT INTO escala_trabalho VALUES (1, 100); -- Carlos atende o Centro
INSERT INTO escala_trabalho VALUES (1, 200); -- Carlos atende o Litoral
INSERT INTO escala_trabalho VALUES (2, 100); -- Ana também atende o Centro

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

Use o operador e para critérios rigorosos e ou para critérios flexíveis. Salve os arquivos com a extensão .sql (Ex: Atividade_XX_SeuNome.sql ou Atividade_XX_SeuNome.png ou Atividade_XX_SeuNome.drawio


💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Em um relacionamento Muitos para Muitos (N:M), por que a Tabela Associativa (escala_trabalho) tem uma PRIMARY KEY composta pelos dois IDs? (Resposta: Para garantir que o mesmo entregador não seja escalado duas vezes exatamente para a mesma rota no mesmo turno). 🧠🛡️