Modelo Entidade-Relacionamento: A Base da Modelagem

// Introdução ao MER

O Modelo Entidade-Relacionamento (MER) é uma técnica de modelagem conceitual que representa a realidade de forma abstrata, antes de seu mapeamento para um modelo relacional (C.J. Date). Ele permite projetar bancos de dados com independência do SGBD.

Baseia-se em entidades (objetos distinguíveis), seus atributos (propriedades), e os relacionamentos entre eles.

db_design@postgres:~#

-- Exemplo: Entidade Fornecedores no MER
CREATE TABLE fornecedores (
  sid VARCHAR(10) PRIMARY KEY,
  sname VARCHAR(100) NOT NULL,
  cidade VARCHAR(50)
);

Atividade Prática: Identifique 3 entidades no sistema Fornecedor-Peça-Projeto.

Fornecedores, Peças, Projetos

Entidades: Os Blocos do MER

// Fortes e Fracas

Definição

Uma entidade é qualquer objeto distinguível do mundo real que deve ser representado no banco de dados (C.J. Date).

Tipos de Entidades

Fortes: Possuem chave primária própria (ex.: Fornecedores, com SID único).
Fracas: Dependem de outra entidade via chave estrangeira (ex.: Fornecimentos, depende de Fornecedores e Peças).

db_design@postgres:~#

-- Entidade Forte: Fornecedores
CREATE TABLE fornecedores (
  sid VARCHAR(10) PRIMARY KEY,
  sname VARCHAR(100) NOT NULL
);
-- Entidade Fraca: Fornecimentos
CREATE TABLE fornecimentos (
  sid VARCHAR(10) REFERENCES fornecedores,
  pid VARCHAR(10) REFERENCES pecas,
  qty INTEGER,
  PRIMARY KEY (sid, pid)
);

Atividade Prática: Crie uma entidade fraca para o sistema Fornecedor-Peça-Projeto.

CREATE TABLE fornecimentos_projeto (
  sid VARCHAR(10) REFERENCES fornecedores,
  pid VARCHAR(10) REFERENCES pecas,
  jid VARCHAR(10) REFERENCES projetos,
  qty INTEGER,
  PRIMARY KEY (sid, pid, jid)
);

Atributos e Chaves: Descrevendo Entidades

// Simples, Compostos, Multivalorados, Chaves

Tipos de Atributos

Simples: Atômicos, indivisíveis (ex.: SNAME). No modelo relacional, todos os atributos devem ser atômicos (C.J. Date).
Compostos: Divisíveis em subatributos (ex.: Endereço → Rua, Cidade).
Multivalorados: Múltiplos valores (ex.: Telefones, mapeado como tabela separada).
Derivados: Calculados (ex.: Idade a partir de Data de Nascimento).

Chaves

Chave Primária (PK): Identificador único, nunca nulo (Regra de Integridade 1).
Chave Candidata: Outros atributos/combinações que poderiam ser PK.

db_design@postgres:~#

-- Entidade com atributos e chaves
CREATE TABLE pecas (
  pid VARCHAR(10) PRIMARY KEY, -- Chave primária
  pname VARCHAR(100), -- Simples
  endereco_rua VARCHAR(100), -- Composto (parte)
  endereco_cidade VARCHAR(50) -- Composto (parte)
);
-- Tabela para atributo multivalorado
CREATE TABLE pecas_cores (
  pid VARCHAR(10) REFERENCES pecas,
  cor VARCHAR(20),
  PRIMARY KEY (pid, cor)
);

Atividade Prática: Identifique as chaves candidatas na tabela `fornecedores` (SID, SNAME, Cidade).

SID (único), SNAME (se for único no domínio)

Relacionamentos: Conectando Entidades

// Binário, Ternário, Unário

Um relacionamento é uma associação bidirecional entre entidades, descrevendo como interagem (C.J. Date).

Grau do Relacionamento

Binário: Entre duas entidades (ex.: Fornecedores fornecem Peças).
Ternário: Entre três entidades (ex.: Fornecedores, Peças, Projetos).
Unário: Entidade relacionada consigo mesma (ex.: Funcionário gerencia Funcionário).

db_design@postgres:~#

-- Relacionamento Binário (Fornecedores-Peças)
CREATE TABLE sp (
  sid VARCHAR(10) REFERENCES fornecedores,
  pid VARCHAR(10) REFERENCES pecas,
  PRIMARY KEY (sid, pid)
);
-- Relacionamento Unário (Funcionários)
CREATE TABLE funcionarios (
  fid VARCHAR(10) PRIMARY KEY,
  gerente_id VARCHAR(10) REFERENCES funcionarios
);

Atividade Prática: Crie uma tabela para um relacionamento ternário entre Fornecedores, Peças e Projetos.

CREATE TABLE spj (
  sid VARCHAR(10) REFERENCES fornecedores,
  pid VARCHAR(10) REFERENCES pecas,
  jid VARCHAR(10) REFERENCES projetos,
  PRIMARY KEY (sid, pid, jid)
);

Cardinalidade e Participação: Definindo Regras

// 1:1, 1:N, N:M e Obrigatória/Opcional

Cardinalidade

Tipo	Definição	Exemplo
1:1	Uma entidade associada a uma única ocorrência de outra.	Funcionário e CPF.
1:N	Uma entidade associada a várias ocorrências de outra.	Projeto e Tarefas.
N:M	Várias ocorrências de ambas as entidades associadas.	Fornecedores e Peças.

Participação

Obrigatória (total): Linha dupla, chave estrangeira não nula (Regra de Integridade 2).
Opcional (parcial): Linha simples, chave estrangeira pode ser nula.

db_design@postgres:~#

-- 1:N, Participação Obrigatória
CREATE TABLE tarefas (
  tid VARCHAR(10) PRIMARY KEY,
  jid VARCHAR(10) REFERENCES projetos NOT NULL
);
-- N:M, Participação Opcional
CREATE TABLE sp (
  sid VARCHAR(10) REFERENCES fornecedores,
  pid VARCHAR(10) REFERENCES pecas,
  PRIMARY KEY (sid, pid)
);

Atividade Prática: Defina a cardinalidade e participação para o relacionamento entre Funcionários e Departamentos.

1:N (um Departamento tem muitos Funcionários), 
participação obrigatória (cada Funcionário 
deve estar em um Departamento).

Estudo de Caso: Sistema Fornecedor-Peça-Projeto

// Diagrama ER no PostgreSQL

Estudo de Caso Guiado:
Desenhe um diagrama ER para o sistema Fornecedor-Peça-Projeto:
1. Entidades: Fornecedores, Peças, Projetos, Fornecimentos.
2. Atributos e chaves (ex.: SID, PNAME, QTY).
3. Relacionamentos com grau, cardinalidade e participação.
4. Analise o plano de execução de uma consulta com EXPLAIN.

db_design@postgres:~#

-- Diagrama ER Textual
[Fornecedores] -- N:M --> [Peças]
  SID (PK)              PID (PK)
  SNAME                PNAME
                       CIDADE
[Fornecimentos]
  SID (FK), PID (FK), QTY
-- Consulta exemplo
SELECT s.sname, p.pname
FROM fornecedores s
JOIN sp ON s.sid = sp.sid
JOIN pecas p ON sp.pid = p.pid;
EXPLAIN ANALYZE SELECT s.sname, p.pname
FROM fornecedores s
JOIN sp ON s.sid = sp.sid
JOIN pecas p ON sp.pid = p.pid;

Resposta Modelo:

Entidades:
- Fornecedores (SID, SNAME, CIDADE)
- Peças (PID, PNAME, CIDADE)
- Projetos (JID, JNAME)
- Fornecimentos (SID, PID, JID, QTY)
Relacionamentos:
- Fornecedores-Peças: N:M, 
opcional, via Fornecimentos
- Fornecedores-Projetos: N:M, 
opcional, via Fornecimentos
- Peças-Projetos: N:M, 
opcional, via Fornecimentos

EXPLAIN ANALYZE SELECT s.sname, p.pname
FROM fornecedores s
JOIN sp ON s.sid = sp.sid
JOIN pecas p ON sp.pid = p.pid;
-- Output: Mostra uso de índices 
nas chaves estrangeiras

Quiz Interativo

// Teste seus conhecimentos sobre MER

Teste de Conhecimento

Responda às perguntas para consolidar o aprendizado sobre o Modelo Entidade-Relacionamento.

1. O que define uma entidade forte?

a) Depende de outra entidade

b) Possui chave primária própria

c) Tem atributos multivalorados

d) É sempre opcional

Resposta Correta: b) Possui chave primária própria. Entidades fortes têm identificadores únicos independentes.

2. Qual tipo de atributo é atômico?

a) Composto

b) Simples

c) Derivado

d) Multivalorado

Resposta Correta: b) Simples. Atributos simples são indivisíveis, conforme exigido no modelo relacional (C.J. Date).

3. O que é uma chave candidata?

a) Atributo que pode ser nulo

b) Atributo que identifica tuplas unicamente

c) Atributo derivado

d) Atributo multivalorado

Resposta Correta: b) Atributo que identifica tuplas unicamente. Chaves candidatas são combinações de atributos que poderiam ser chave primária.

4. Qual é um exemplo de relacionamento unário?

a) Fornecedores-Peças

b) Funcionário-Gerente

c) Projeto-Tarefas

d) Fornecedores-Projetos

Resposta Correta: b) Funcionário-Gerente. Um relacionamento unário conecta uma entidade consigo mesma.

5. O que indica participação obrigatória?

a) Chave estrangeira nula

b) Chave estrangeira não nula

c) Relacionamento 1:1

d) Relacionamento N:M

Resposta Correta: b) Chave estrangeira não nula. Participação obrigatória exige que a entidade esteja relacionada, sem valores nulos (Regra de Integridade 2).

db_quiz_results:~#

RUN mer_quiz_check;
-- Quiz finalizado. Parabéns por explorar o MER!