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
- Cada entidade forte vira uma tabela.
- Cada atributo vira uma coluna com tipo de dado.
- O atributo-chave vira a
PRIMARY KEY. - Relacionamentos 1:N geram uma
FOREIGN KEYna tabela do lado N. - Relacionamentos N:N geram uma tabela associativa com as FKs de ambas as entidades.
- Entidades fracas incorporam a PK da entidade forte como FK.
Tipos de dados mais usados
| Tipo | Uso | Exemplo de coluna |
|---|---|---|
INT / BIGINT | Nú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 |
TEXT | Texto 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 |
DATE | Data no formato YYYY-MM-DD. | data_nascimento, data_pedido |
DATETIME | Data e hora. Considere TIMESTAMP com timezone para sistemas internacionais. | criado_em, atualizado_em |
BOOLEAN | Verdadeiro/Falso (1/0 em muitos SGBDs). | ativo, verificado, pago |
Constraints essenciais
| Constraint | Garante |
|---|---|
PRIMARY KEY | Unicidade e não-nulidade do identificador |
FOREIGN KEY | Integridade referencial — não deixa criar um registro órfão |
NOT NULL | Campo obrigatório — nunca pode ser vazio |
UNIQUE | Valor único na tabela (ex.: email, CPF) |
DEFAULT | Valor padrão quando não informado |
CHECK | Validação de regra de negócio (ex.: preco > 0) |
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)
);
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
| Tipo | Definição | Exemplo |
|---|---|---|
| Físicas | Existem no mundo real | Cliente, Produto, Fornecedor, Funcionário |
| Lógicas | Nascem da interação entre entidades físicas | Venda, Matrícula, Relatório, Grupo de usuários |
| Classificação | Definição | Exemplo |
|---|---|---|
| Fortes | Existem por si mesmas, sem dependência | Produto em sistema de estoque |
| Fracas | Dependem de outra entidade para existir | Fornecedor (depende de Produto existir) |
| Associativas | Existem para representar relacionamentos com atributos próprios | ”Desconto de compra” entre Fornecedor e Compra |
Tipos de atributos
| Tipo | Descrição | Exemplo |
|---|---|---|
| Descritivo | Descreve uma característica da entidade | nome |
| Nominativo | Descreve e também identifica a entidade como única | código do cliente |
| Referencial | Representa a entidade na relação com outra (chave estrangeira) | CPF do cliente na tabela Venda |
| Classificação | Descrição | Exemplo |
|---|---|---|
| Simples | Um único atributo define a característica | nome |
| Composto | Múltiplos atributos combinados definem uma característica | endereç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)
| Entidade | Chave Primária | Atributos |
|---|---|---|
| Cliente | CPF | Nome, Sobrenome, Telefone, Celular, Endereço, Bairro, Cidade, Estado |
| Livro | ISBN | Nome, Autor, Coautor, Estoque, Qtd_páginas, Valor, Fornecedor |
| Vendedor | ID | Nome, Comissão, Horário de trabalho |
| Relacionamento | Cardinalidade |
|---|---|
| Cliente ↔ Livro | N:N (cliente compra vários livros; livro é comprado por vários clientes) |
| Cliente → Vendedor | N:1 (cliente é atendido por um vendedor; vendedor atende vários clientes) |
| Livro ↔ Vendedor | N: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.prismadefine 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 migrateealembic upgrade headaplicam 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.