Modelagem de Dados: DER

Entidades, Relacionamentos, Cardinalidades e Chaves

1. O que é DER?

Diagrama Entidade-Relacionamento

É a "planta baixa" do banco de dados.

  • Representação gráfica da estrutura lógica.
  • Independente do banco de dados específico (MySQL, Oracle, SQL Server).
  • Facilita a comunicação entre desenvolvedores e analistas.

Componentes do DER

  1. Entidades (Retângulos)
    • Objetos ou "coisas" do mundo real.
    • Exemplos: Cliente, Produto, Pedido.
  2. Atributos (Ovais)
    • Características da entidade.
    • Exemplos: Nome, Preço, Data.
  3. Relacionamentos (Losangos)
    • Associações entre entidades.
    • Exemplo: Um Cliente faz um Pedido.

2. Chave Primária (PK)

Primary Key é o identificador único de cada registro.

Imagine uma fila de pessoas com o mesmo nome. Como distinguir quem é quem?

  • Regras de Ouro:

    1. Única: Nunca se repete.
    2. Não Nula: Nunca fica vazia.
    3. Imutável: O valor ideal nunca muda.

  • Melhor Prática:

    • Usar IDs gerados pelo sistema (id_cliente, id_pedido).
    • Evitar dados do mundo real (como documentos pessoais), pois eles podem mudar ou conter erros de digitação.

Exemplo de PK

Tabela: Alunos

id_aluno (PK) nome cidade
001 João Silva São Paulo
002 Maria Souza Rio de Janeiro
003 João Silva Belo Horizonte

Mesmo com nomes iguais, o id_aluno garante que cada um é único.

3. Chave Estrangeira (FK)

Foreign Key cria a conexão lógica entre tabelas.

É a PK de uma tabela que "migra" para outra tabela para indicar o vínculo.

  • Função Principal:
    Garantir a Integridade Referencial.
    • Exemplo: O banco não permitirá cadastrar um pedido para um id_cliente que não exista na tabela de clientes.

Exemplo Prático de FK

Tabela: Cliente

  • id_cliente (PK)
  • nome

Tabela: Pedido

  • id_pedido (PK)
  • data
  • id_cliente (FK) <-- Aponta para o Cliente

Sabemos quem fez o pedido olhando o id_cliente dentro da tabela Pedido.

4. Cardinalidades

Define "Quantos" registros participam de uma relação.

Existem três tipos principais:

  1. Um para Um (1:1)
  2. Um para Muitos (1:N)
  3. Muitos para Muitos (N:M)

Cardinalidade: Um para Um (1:1)

Um registro de A se relaciona com apenas um de B.

  • Exemplo: Funcionário e Crachá.

    • Um funcionário tem um crachá.
    • Um crachá pertence a um funcionário.

  • Implementação:
    A PK de uma tabela vai para a outra e também vira PK lá.

Cardinalidade: Um para Muitos (1:N)

O mais comum!

Um registro de A se relaciona com muitos de B. Mas B se relaciona com apenas um de A.

  • Exemplo: Departamento e Funcionário.

    • Um departamento tem vários funcionários.
    • Um funcionário trabalha em apenas um departamento.

  • Implementação:
    A PK da tabela "Um" (Departamento) migra como FK para a tabela "Muitos" (Funcionário).

Cardinalidade: Muitos para Muitos (N:M)

Muitos registros de A se relacionam com muitos de B.

  • Exemplo: Aluno e Disciplina.

    • Um aluno cursa várias disciplinas.
    • Uma disciplina tem vários alunos.

  • Implementação:
    Não existe conexão direta.
    É obrigatório criar uma Tabela Associativa (terceira tabela) para "quebrar" essa relação em duas relações 1:N.

Resolvendo N:M (Exemplo Prático)

Cenário: Aluno e Disciplina.

Criamos a tabela intermediária: Matricula.

  1. Aluno (1) --- (N) Matricula
  2. Disciplina (1) --- (N) Matricula

A tabela Matricula terá duas chaves estrangeiras: id_aluno e id_disciplina.

5. Estudo de Caso: E-commerce

Vamos modelar um sistema simples de vendas.

Requisitos:

  1. Cadastrar Clientes.
  2. Cadastrar Produtos.
  3. Registrar Pedidos (sabendo quais produtos e qual cliente).

Passo 1: Identificar Entidades

  • Cliente
    • id_cliente (PK)
    • nome
  • Produto
    • id_produto (PK)
    • nome
    • preco
  • Pedido
    • id_pedido (PK)
    • data

Passo 2: Definir Relacionamentos

  1. Cliente x Pedido

    • Um cliente faz vários pedidos.
    • Um pedido pertence a um cliente.
    • Cardinalidade: 1:N
    • Ação: Colocar id_cliente como FK na tabela Pedido.

  2. Pedido x Produto

    • Um pedido tem vários produtos.
    • Um produto pode estar em vários pedidos.
    • Cardinalidade: N:M
    • Ação: Criar tabela associativa Item_Pedido.

Passo 3: Estrutura Final do Banco

Cliente

  • id_cliente (PK)
  • nome

Pedido

  • id_pedido (PK)
  • id_cliente (FK)
  • data

Passo 3: Estrutura Final do Banco

Produto

  • id_produto (PK)
  • nome

Item_Pedido (Tabela Associativa)

  • id_pedido (FK)
  • id_produto (FK)
  • quantidade

Resumo da Aula

Conceito Definição Exemplo
PK Identificador Único id_produto
FK Chave de outra tabela (ligação) id_produto dentro de Item_Pedido
1:1 Um para Um Pessoa <-> Passaporte
1:N Um para Muitos Mãe <-> Filhos
N:M Muitos para Muitos Aluno <-> Professor

Exercício de Fixação

Modele um sistema para uma Biblioteca:

  1. Quais são as entidades?
  2. Qual a cardinalidade entre Usuário e Empréstimo?
  3. Onde deve ficar a Chave Estrangeira?

Pense na resposta antes de avançar.

Resposta do Exercício

Entidades: Livro, Usuario, Emprestimo.

Cardinalidade (Usuário x Empréstimo):

  • Um usuário faz muitos empréstimos (1:N).
  • Um empréstimo pertence a um usuário.

Chave Estrangeira:
A id_usuario (PK da tabela Usuário) deve ser colocada como FK na tabela Emprestimo.

Fim da Aula

Dúvidas?

Lembre-se: Uma boa modelagem evita dores de cabeça no futuro!