Modelagem ER (Entidade Relacionamento)

Introdução

Antes de criar uma única tabela, um banco de dados bem projetado começa no papel. A Modelagem ER é a técnica usada para representar visualmente a estrutura de um domínio - quais coisas existem, quais atributos elas têm, e como se relacionam entre si. É a planta baixa do banco de dados.

O modelo foi proposto por Peter Chen em 1976, num artigo que se tornaria um dos mais citados na história da computação. A ideia central era simples: representar o mundo real através de entidades, atributos e relacionamentos, e fazer isso de forma independente de qualquer banco de dados específico. O diagrama ER é uma linguagem de comunicação entre analistas, desenvolvedores e clientes, antes de qualquer linha de SQL ser escrita.

Entidades

Uma entidade é qualquer coisa do mundo real que tem existência independente e sobre a qual queremos armazenar informações. No diagrama, entidades são representadas por retângulos. Exemplos de entidades: Cliente, Produto, Pedido, Funcionário, Departamento.

Existe uma distinção importante entre:

• Tipo de entidade: a definição abstrata - o conceito de "Cliente"
• Instância de entidade: um cliente específico - "Ana Lima, CPF 123.456.789-00"

Quando o modelo é convertido para o banco, o tipo de entidade vira uma tabela e cada instância vira uma linha.

Entidade Forte vs Entidade Fraca

Uma entidade forte tem existência própria - pode ser identificada por seus próprios atributos, independente de qualquer outra entidade. Cliente é uma entidade forte: existe um cliente mesmo sem nenhum pedido.

Uma entidade fraca depende de outra entidade para existir e ser identificada. No diagrama, é representada por um retângulo duplo. Um exemplo clássico: Item de Pedido não existe sem um Pedido - e seu identificador só faz sentido dentro do contexto daquele pedido (item 1 do pedido 10, item 1 do pedido 11 são coisas diferentes, mas têm o mesmo número).

Atributos

Atributos descrevem as propriedades de uma entidade. No diagrama, são representados por elipses conectadas à entidade.

Atributo Simples

Valor único e indivisível. nome, preco, data_nascimento. É o tipo mais comum.

Atributo Composto

Pode ser subdividido em partes menores com significado próprio. endereco pode ser decomposto em rua, numero, cidade, cep. No diagrama, o atributo composto tem sub-elipses conectadas a ele.

Na conversão para tabelas, há uma escolha: manter como coluna única (endereco VARCHAR) ou expandir em colunas separadas (rua, numero, cidade). A decisão depende de se será necessário filtrar ou ordenar por partes do endereço.

Atributo Multivalorado

Pode ter mais de um valor para a mesma entidade. Uma Pessoa pode ter vários telefones. No diagrama, é representado por uma elipse dupla.

Na conversão para tabelas, atributos multivalorados viram tabelas separadas - pois uma coluna não pode guardar múltiplos valores (violaria a 1FN).

CREATE TABLE telefones (
    id INT PRIMARY KEY,
    pessoa_id INT REFERENCES pessoas(id),
    numero VARCHAR(20)
);

Atributo Derivado

Calculado a partir de outro atributo - não é armazenado, é computado. idade é derivado de data_nascimento. No diagrama, é representado por uma elipse tracejada.

Em SQL, atributos derivados podem ser implementados como colunas calculadas ou simplesmente computados na consulta:

SELECT nome, EXTRACT(YEAR FROM AGE(data_nascimento)) AS idade FROM pessoas;

Atributo-Chave

O atributo que identifica unicamente cada instância da entidade. No diagrama, é sublinhado. Corresponde à chave primária na tabela.

Relacionamentos

Um relacionamento representa uma associação entre duas ou mais entidades. No diagrama, é representado por um losango conectado às entidades participantes.

[Cliente] --- <faz> --- [Pedido]

Assim como entidades, relacionamentos também podem ter atributos. Um relacionamento Matricula entre Aluno e Curso pode ter o atributo data_matricula e nota - valores que pertencem à relação, não a nenhuma das entidades isoladamente.

Grau do Relacionamento

O grau indica quantas entidades participam do relacionamento.

• Binário (grau 2): o mais comum. Dois tipos de entidade se relacionam.

  [Cliente] --- <compra> --- [Produto]
  

• Ternário (grau 3): três entidades participam simultaneamente. Um Médico prescreve um Medicamento para um Paciente - e os três fazem parte do mesmo relacionamento.
• Unário (grau 1 / auto-relacionamento): uma entidade se relaciona consigo mesma. Funcionário pode ser gerenciado por outro Funcionário.

  [Funcionário] --- <gerencia> --- [Funcionário]
  

Cardinalidade

A cardinalidade define quantas instâncias de uma entidade podem se associar a instâncias da outra. É a informação mais importante de um relacionamento.

1:1 - Um para Um

Cada instância de A se associa a no máximo uma instância de B, e vice-versa.

[Pessoa] -- 1 -- <tem> -- 1 -- [Passaporte]

Uma pessoa tem um passaporte; um passaporte pertence a uma pessoa. Na conversão, a chave estrangeira pode ficar em qualquer um dos lados - por convenção, fica na entidade mais fraca ou mais dependente.

1:N - Um para Muitos

Cada instância de A pode se associar a várias de B, mas cada instância de B se associa a apenas uma de A.

[Cliente] -- 1 -- <faz> -- N -- [Pedido]

Um cliente faz vários pedidos; cada pedido pertence a um cliente. A chave estrangeira sempre fica no lado N - pedidos.cliente_id.

N:N - Muitos para Muitos

Cada instância de A pode se associar a várias de B, e vice-versa.

[Aluno] -- N -- <matricula> -- N -- [Curso]

Um aluno se matricula em vários cursos; um curso tem vários alunos. Na conversão, exige uma tabela de junção - pois não há como representar isso com uma simples chave estrangeira.

CREATE TABLE matriculas (
    aluno_id INT REFERENCES alunos(id),
    curso_id INT REFERENCES cursos(id),
    data_entrada DATE,
    nota_final DECIMAL(4,2),
    PRIMARY KEY (aluno_id, curso_id)
);

Do Diagrama ER ao Esquema Relacional

A conversão segue regras sistemáticas: