Início

Software Design

UA16 — Modelo de Entidades e Relacionamentos (MER)

O MER é a especificação lógica e implementável do banco de dados. Enquanto o DER é conceitual (independe de tecnologia), o MER detalha tabelas, colunas, tipos de dados e constraints prontos para ser implementados em SQL.

Do DER ao MER — as regras de conversão

  1. Cada entidade forte vira uma tabela.
  2. Cada atributo vira uma coluna com tipo de dado.
  3. O atributo-chave vira a PRIMARY KEY.
  4. Relacionamentos 1:N geram uma FOREIGN KEY na tabela do lado N.
  5. Relacionamentos N:N geram uma tabela associativa com as FKs de ambas as entidades.
  6. Entidades fracas incorporam a PK da entidade forte como FK.
A Matriz de Tradução do Arquiteto
MER conceitual → esquema lógico → SQL físico — os três mundos
Fase 2: Tradução para o Modelo Lógico
Cada entidade vira tabela; cada atributo vira coluna

Tipos de dados mais usados

TipoUsoExemplo de coluna
INT / BIGINTNúmeros inteiros. BIGINT para IDs de sistemas com muitos registros.id, quantidade
VARCHAR(n)Texto variável até n caracteres. Mais eficiente que CHAR para dados variáveis.nome, email, cep
TEXTTexto longo sem limite definido.descricao, observacao
DECIMAL(p,s)Número decimal exato (p dígitos totais, s após vírgula). Nunca use FLOAT para dinheiro.preco, salario
DATEData no formato YYYY-MM-DD.data_nascimento, data_pedido
DATETIMEData e hora. Considere TIMESTAMP com timezone para sistemas internacionais.criado_em, atualizado_em
BOOLEANVerdadeiro/Falso (1/0 em muitos SGBDs).ativo, verificado, pago

Constraints essenciais

ConstraintGarante
PRIMARY KEYUnicidade e não-nulidade do identificador
FOREIGN KEYIntegridade referencial — não deixa criar um registro órfão
NOT NULLCampo obrigatório — nunca pode ser vazio
UNIQUEValor único na tabela (ex.: email, CPF)
DEFAULTValor padrão quando não informado
CHECKValidação de regra de negócio (ex.: preco > 0)
O Ponto de Ancoragem: Chave Primária (PK)
PK: numérica, única, incremental e absolutamente irrepetível
Construindo Pontes: Chave Estrangeira (FK)
FK transforma o losango do DER na coluna id_referência da tabela

Exemplo completo — Sistema Imobiliário

CREATE TABLE Proprietario (
  id_proprietario INT          PRIMARY KEY AUTO_INCREMENT,
  nome            VARCHAR(100) NOT NULL,
  cpf             VARCHAR(14)  UNIQUE NOT NULL,
  telefone        VARCHAR(18),
  email           VARCHAR(100) NOT NULL
);

CREATE TABLE Imovel (
  id_imovel       INT            PRIMARY KEY AUTO_INCREMENT,
  endereco        VARCHAR(255)   NOT NULL,
  tipo            VARCHAR(50)    NOT NULL,
  preco           DECIMAL(12,2)  NOT NULL CHECK (preco > 0),
  disponivel      BOOLEAN        DEFAULT TRUE,
  id_proprietario INT            NOT NULL,
  FOREIGN KEY (id_proprietario) REFERENCES Proprietario(id_proprietario)
);

CREATE TABLE Contrato (
  id_contrato  INT  PRIMARY KEY AUTO_INCREMENT,
  tipo         ENUM('venda', 'aluguel') NOT NULL,
  data_inicio  DATE NOT NULL,
  data_fim     DATE,
  valor        DECIMAL(12,2) NOT NULL,
  id_imovel    INT  NOT NULL REFERENCES Imovel(id_imovel),
  id_cliente   INT  NOT NULL REFERENCES Cliente(id_cliente),
  id_corretor  INT  REFERENCES Corretor(id_corretor)
);
Fase 3: O Projeto Físico (DDL)
CREATE TABLE — a abstração ganha restrições físicas de memória
O Sistema Vivo: Inserção de Dados (DML)
INSERT com validação de FK — o banco rejeita registros órfãos

Elementos do MER

O MER é constituído por três elementos básicos: entidades, atributos e relacionamentos. (Fileto, 2006: “facilitar o projeto do BD, possibilitando especificar a estrutura lógica geral do BD”)

Tipos de entidades

TipoDefiniçãoExemplo
FísicasExistem no mundo realCliente, Produto, Fornecedor, Funcionário
LógicasNascem da interação entre entidades físicasVenda, Matrícula, Relatório, Grupo de usuários
ClassificaçãoDefiniçãoExemplo
FortesExistem por si mesmas, sem dependênciaProduto em sistema de estoque
FracasDependem de outra entidade para existirFornecedor (depende de Produto existir)
AssociativasExistem para representar relacionamentos com atributos próprios”Desconto de compra” entre Fornecedor e Compra
Quando o Relacionamento Exige Sua Própria Tabela
N:N entre Animal e Veterinário gera a tabela Consulta — com atributos próprios

Tipos de atributos

TipoDescriçãoExemplo
DescritivoDescreve uma característica da entidadenome
NominativoDescreve e também identifica a entidade como únicacódigo do cliente
ReferencialRepresenta a entidade na relação com outra (chave estrangeira)CPF do cliente na tabela Venda
ClassificaçãoDescriçãoExemplo
SimplesUm único atributo define a característicanome
CompostoMúltiplos atributos combinados definem uma característicaendereço = rua + número + bairro + cidade + estado

Nota: campos numéricos são preferidos como chave primária — o banco já indexa a coluna automaticamente, acelerando consultas.

Os três níveis do MER

Conceitual

Visão abstrata e de alto nível. Define entidades e relacionamentos sem preocupação com detalhes técnicos. Linguagem do negócio.

Lógico

Adapta o modelo conceitual para BD relacional: adiciona atributos, chaves primárias e estrangeiras. Tecnologia-independente.

Físico

Transforma o modelo lógico em tabelas reais (SQL) em um SGBD específico, com tipos de dados, constraints e índices.

Exemplo prático — Livraria (MER do zero)

EntidadeChave PrimáriaAtributos
ClienteCPFNome, Sobrenome, Telefone, Celular, Endereço, Bairro, Cidade, Estado
LivroISBNNome, Autor, Coautor, Estoque, Qtd_páginas, Valor, Fornecedor
VendedorIDNome, Comissão, Horário de trabalho
RelacionamentoCardinalidade
Cliente ↔ LivroN:N (cliente compra vários livros; livro é comprado por vários clientes)
Cliente → VendedorN:1 (cliente é atendido por um vendedor; vendedor atende vários clientes)
Livro ↔ VendedorN:N (livro é vendido por vários; vendedor vende vários livros)

Checklist de um MER bem feito

✓ Toda tabela tem PRIMARY KEY  |  ✓ FKs definidas para toda relação  |  ✓ Campos obrigatórios com NOT NULL  |  ✓ Tipos de dados adequados (DECIMAL para dinheiro, nunca FLOAT)  |  ✓ Sem redundância: dados que mudam em um lugar só ficam em um lugar  |  ✓ Nomes consistentes (snake_case, singulares para tabelas)

Práticas Modernas — MER e Implementação de Banco

  • Schema-as-Code com Prisma: o arquivo schema.prisma define tabelas, colunas, relacionamentos e constraints em uma sintaxe legível — é o MER lógico versionado em Git, executável como migração.
  • Migrations automáticas: prisma migrate dev, flyway migrate e alembic upgrade head aplicam alterações de schema automaticamente no deploy — substituem scripts SQL manuais.
  • Zero-downtime migrations: em produção com alto tráfego, alterações de schema (adicionar coluna, criar índice) precisam ser feitas em etapas para não bloquear tabelas. Ferramentas como gh-ost (GitHub) e pt-online-schema-change (Percona) gerenciam isso.
  • Normalização vs. desnormalização: em aplicações modernas com leitura intensiva (read-heavy), desnormalizar algumas tabelas e usar banco read-replica ou Redis cache é padrão — a 3FN é o ponto de partida, não o destino.

Dicas para a prova — UA16

  • 3 elementos do MER: entidades, atributos e relacionamentos. (Tabelas, consultas e triggers são conceitos SQL, não MER.)
  • Entidades = objetos; atributos = características; relacionamentos = como interagem. Atributos NÃO definem relações entre entidades.
  • Relacionamento correto numa clínica: Paciente –(1:N)– Consulta (cada paciente agenda múltiplas consultas; cada consulta tem um paciente).
  • Entidade forte = existe por si só; entidade fraca = depende de outra; associativa = representa relacionamento com dados próprios.
  • Atributos: descritivo (característica), nominativo (identifica), referencial (FK para outra entidade).
  • 3 níveis do MER: conceitual → lógico → físico.
  • MER facilita o desenvolvimento — mas NÃO elimina a necessidade de definir atributos durante a implementação.

Referências bibliográficas desta UA

  • Barboza, F. F. M. Modelagem e Desenvolvimento de Banco de Dados. Porto Alegre: SAGAH, 2018.
  • Fileto, R. O Modelo Entidade-Relacionamento. UFSC, 2006.