MER e DER: Modelagem de Bancos de Dados

Quando se inicia o desenvolvimento de um novo sistema, ou mesmo de uma nova

funcionalidade para um sistema existente, um dos primeiros passos a ser executado é
o estudo e levantamento dos requisitos necessários para a construção do produto
final. Durante essa análise, identifica-se as principais partes e objetos envolvidos,
suas possíveis ações e responsabilidades, suas características e como elas interagem
entre si.

A partir das informações obtidas, pode-se desenvolver um modelo conceitual que

será utilizado para orientar o desenvolvimento propriamente dito, fornecendo
informações sobre os aspectos relacionados ao domínio do projeto em questão.

Modelo Entidade Relacionamento

O Modelo Entidade Relacionamento (também chamado Modelo ER, ou

simplesmente MER), como o nome sugere, é um modelo conceitual utilizado
na Engenharia de Software para descrever os objetos (entidades) envolvidos em um
domínio de negócios, com suas características (atributos) e como elas se relacionam
entre si (relacionamentos).

Em geral, este modelo representa de forma abstrata a estrutura que possuirá o banco
de dados da aplicação. Obviamente, o banco de dados poderá conter várias outras
entidades, tais como chaves e tabelas intermediárias, que podem só fazer sentido no
contexto de bases de dados relacionais.

Observação: Nem sempre criaremos modelos para um sistema completo, pois isso poderia

resultar em um modelo muito extenso e difícil de interpretar. Dependendo da magnitude do que

estaremos desenvolvendo, podemos criar modelos apenas para uma parte do sistema, um

módulo, ou mesmo uma funcionalidade. Imagine, por exemplo, um sistema ERP de grande

porte que contemple vendas, finanças, recursos humanos, etc. Várias entidades estão presentes

em mais de uma parte do sistema, mas não seria muito interessante, e provavelmente nem

mesmo necessário, criar um único modelo para todo o sistema, por isso pode-se dividir a

modelagem em várias partes menores.

Entidades

Os objetos ou partes envolvidas um domínio, também chamados de entidades, podem

ser classificados como físicos ou lógicos, de acordo sua existência no mundo real.
Entidades físicas: são aquelas realmente tangíveis, existentes e visíveis no mundo
real, como um cliente (uma pessoa, uma empresa) ou um produto (um carro, um
computador, uma roupa). Já as entidades lógicas são aquelas que existem geralmente
em decorrência da interação entre ou com entidades físicas, que fazem sentido
dentro de um certo domínio de negócios, mas que no mundo externo/real não são
objetos físicos (que ocupam lugar no espaço). São exemplos disso uma venda ou uma
classificação de um objeto (modelo, espécie, função de um usuário do sistema).

As entidades são nomeadas com substantivos concretos ou abstratos que representem

de forma clara sua função dentro do domínio. Exemplos práticos de entidades
comuns em vários sistemas são Cliente, Produto, Venda, Turma, Função, entre
outros.

Podemos classificar as entidades segundo o motivo de sua existência:

• Entidades fortes: são aquelas cuja existência independe de outras entidades, ou

seja, por si só elas já possuem total sentido de existir. Em um sistema de
vendas, a entidade produto, por exemplo, independe de quaisquer outras para
existir.
• Entidades fracas: ao contrário das entidades fortes, as fracas são aquelas que
dependem de outras entidades para existirem, pois individualmente elas não
fazem sentido. Mantendo o mesmo exemplo, a entidade venda depende da
entidade produto, pois uma venda sem itens não tem sentido.
• Entidades associativas: esse tipo de entidade surge quando há a necessidade de
associar uma entidade a um relacionamento existente. Na modelagem
Entidade-Relacionamento não é possível que um relacionamento seja associado
a uma entidade, então tornamos esse relacionamento uma entidade associativa,
que a partir daí poderá se relacionar com outras entidades. Para melhor
compreender esse conceito, tomemos como exemplo uma aplicação de vendas
em que existem as entidades Produto e Venda, que se relacionam na forma
muitos-para-muitos, uma vez que em uma venda pode haver vários produtos e
um produto pode ser vendido várias vezes (no caso, unidades diferentes do
mesmo produto). Em determinado momento, a empresa passou a entregar
brindes para os clientes que comprassem um determinado produto. A entidade
Brinde, então, está relacionada não apenas com a Venda, nem com o Produto,
mas sim com o item da venda, ou seja, com o relacionamento entre as duas
entidades citadas anteriormente. Como não podemos associar a entidade
Brinde com um relacionamento, criamos então a entidade associativa "Item da
Venda", que contém os atributos identificadores das entidades Venda e
Produto, além de informações como quantidade e número de série, para casos
específicos. A partir daí, podemos relacionar o Brinde com o Item da Venda,
 indicando que aquele prêmio foi dado ao cliente por comprar aquele produto
especificamente.

Mais adiante veremos um exemplo prático onde poderemos observar a existência

dessas entidades de forma mais clara.

Relacionamentos

Uma vez que as entidades são identificadas, deve-se então definir como se dá o
relacionamento entre elas. De acordo com a quantidade de objetos envolvidos em
cada lado do relacionamento, podemos classifica-los de três formas:

• Relacionamento 1..1 (um para um): cada uma das duas entidades envolvidas
referenciam obrigatoriamente apenas uma unidade da outra. Por exemplo, em
um banco de dados de currículos, cada usuário cadastrado pode possuir apenas
um currículo na base, ao mesmo tempo em que cada currículo só pertence a
um único usuário cadastrado.
• Relacionamento 1..n ou 1..* (um para muitos): uma das entidades envolvidas
pode referenciar várias unidades da outra, porém, do outro lado cada uma das
várias unidades referenciadas só pode estar ligada uma unidade da outra
entidade. Por exemplo, em um sistema de plano de saúde, um usuário pode ter
vários dependentes, mas cada dependente só pode estar ligado a um usuário
principal. Note que temos apenas duas entidades envolvidas: usuário e
dependente. O que muda é a quantidade de unidades/exemplares envolvidas de
cada lado.
• Relacionamento n..n ou *..* (muitos para muitos): neste tipo de
relacionamento cada entidade, de ambos os lados, podem referenciar múltiplas
unidades da outra. Por exemplo, em um sistema de biblioteca, um título pode
ser escrito por vários autores, ao mesmo tempo em que um autor pode escrever
vários títulos. Assim, um objeto do tipo autor pode referenciar múltiplos
objetos do tipo título, e vice versa.

Os relacionamentos em geral são nomeados com verbos ou expressões que

representam a forma como as entidades interagem, ou a ação que uma exerce sobre a
outra. Essa nomenclatura pode variar de acordo com a direção em que se lê o
relacionamento. Por exemplo: um autor escreve vários livros, enquanto um livro é
escrito por vários autores.

Atributos

Atributos são as características que descrevem cada entidade dentro do domínio. Por
exemplo, um cliente possui nome, endereço e telefone. Durante a análise de
requisitos, são identificados os atributos relevantes de cada entidade naquele
contexto, de forma a manter o modelo o mais simples possível e consequentemente
armazenar apenas as informações que serão úteis futuramente. Uma pessoa possui
atributos pessoais como cor dos olhos, altura e peso, mas para um sistema que
funcionará em um supermercado, por exemplo, estas informações dificilmente serão
relevantes.

Os atributos podem ser classificados quanto à sua função da seguinte forma:

• Descritivos: representam característica intrínsecas de uma entidade, tais como

nome ou cor.
• Nominativos: além de serem também descritivos, estes têm a função de definir
e identificar um objeto. Nome, código, número são exemplos de atributos
nominativos.
• Referenciais: representam a ligação de uma entidade com outra em um
relacionamento. Por exemplo, uma venda possui o CPF do cliente, que a
relaciona com a entidade cliente.

Quanto à sua estrutura, podemos ainda classificá-los como:

• Simples: um único atributo define uma característica da entidade. Exemplos:

nome, peso.
• Compostos: para definir uma informação da entidade, são usados vários
atributos. Por exemplo, o endereço pode ser composto por rua, número, bairro,
etc.

Alguns atributos representam valores únicos que identificam a entidade dentro do

domínio e não podem se repetir. Em um cadastro de clientes, por exemplo, esse
atributo poderia ser o CPF. A estes chamamos de Chave Primária.

Já os atributos referenciais são chamados de Chave Estrangeira e geralmente estão

ligados à chave primária da outra entidade. Estes termos são bastante comuns no
contexto de bancos de dados. Mantendo o exemplo anterior, a entidade cliente tem
como chave primária seu CPF, assim, a venda possui também um campo “CPF do
cliente” que se relaciona com o campo CPF da entidade cliente.

Diagrama Entidade Relacionamento

Enquanto o MER é um modelo conceitual, o Diagrama Entidade Relacionamento

(Diagrama ER ou ainda DER) é a sua representação gráfica e principal ferramenta.
Em situações práticas, o diagrama é tido muitas vezes como sinônimo de modelo,
uma vez que sem uma forma de visualizar as informações, o modelo pode ficar
abstrato demais para auxiliar no desenvolvimento do sistema. Dessa forma, quando
se está modelando um domínio, o mais comum é já criar sua representação gráfica,
seguindo algumas regras.
O diagrama facilita ainda a comunicação entre os integrantes da equipe, pois oferece
uma linguagem comum utilizada tanto pelo analista, responsável por levantar os
requisitos, e os desenvolvedores, responsáveis por implementar aquilo que foi
modelado.

Em sua notação original, proposta por Peter Chen (idealizador do modelo e do

diagrama), as entidades deveriam ser representadas por retângulos, seus atributos
por elipses e os relacionamentos por losangos, ligados às entidades por linhas,
contendo também sua cardinalidade (1..1, 1..n ou n..n). Porém, notações mais
modernas abandonaram o uso de elipses para atributos e passaram a utilizar o
formato mais utilizado na UML, em que os atributos já aparecem listados na própria
entidade. Essa forma torna o diagrama mais limpo e fácil de ser lido.

Observe na Figura 1 um exemplo simples de um diagrama para um sistema de

imobiliárias.

Figura 1.
Diagrama Entidade Relacionamento de sistema de imobiliária

No domínio representado pelo diagrama acima temos as seguintes entidades e

relacionamentos:

• Proprietário contata Corretor (um proprietário pode contatar vários corretores

e um corretor pode ser contatado por vários proprietários).
• Corretor atende Inquilino (um corretor pode atender vários inquilinos e um
inquilino pode ser atendido por vários corretores).
• Inquilino aluga Imóvel (um inquilino aluga um imóvel e um imóvel pode ser
alugado por vários inquilinos).
• Proprietário possui Imóvel (um proprietário possui vários imóveis e um imóvel
pertence a apenas um proprietário).
Uma variante da Figura 1 pode ser vista na Figura 2, onde a cardinalidade do
relacionamento é exibida junto do losango.

Figura 2.
Diagrama de Entidade Relacionamento (variação)

Uma outra variação já mostra a cardinalidade de uma forma mais completa, deixando
claro as possibilidades de números de objetos envolvidos em cada relacionamento.
Nesse modelo, em cada lado do relacionamento os números aparecem no formato
(X,Y) ao invés de um único número como vemos nas figuras anteriores. A Figura
3 ilustra um exemplo desse tipo.

Figura 3.
Diagrama Entidade Relacionamento (variação 2)

Neste diagrama, lemos os relacionamentos da seguinte forma:

• 1 ou 1 grupo possui 0 ou muitos produtos. Como de um lado temos “1 ou 1”, isso

equivale a apenas “1”, pois não temos várias possibilidades. Já do lado do
produto, indicamos que um grupo pode possuir nenhum produto, mas também
pode possuir vários.
• 0 ou várias vendas contém 1 ou muitos produtos. Ou seja, um produto pode
nunca ser vendido (0 vendas) como também pode ser vendido várias vezes (n
vendas). Já uma venda deve conter 1 ou vários produtos, pois uma venda não
pode estar vazia (0 produtos).

Os atributos, como já foi dito, podem aparecer no diagrama na forma de elipses

ligadas às entidades. Essa foi a notação original proposta, mas como podemos ver
na Figura 4, ela deixa o diagrama com muitos itens e pode atrapalhar um pouco a
organização destes.

Figura 4. Atributos apresentados

como elipses

Em uma notação mais atual, comumente utilizada na UML, os atributos aparecem

listados dentro do próprio retângulo da entidade, enquanto o nome da entidade
aparece no topo na forma de título. Na Figura 5 temos um exemplo.

Figura 5. Diagrama com atributos nas

entidades

Ferramentas CASE

Do inglês Computer-Aided Software Engineering, as chamadas ferramentas CASE são

aquelas baseadas em computadores (softwares) utilizadas na Engenharia de Software
para auxílio nas atividades desde análise de requisitos até, modelagem de dados.

As ferramentas CASE permitem a criação de diagramas de forma simples em um

ambiente de fácil utilização e com recursos para incluir as principais regras de
composição dos diagramas. Exemplos comuns desse tipo de ferramenta são: Star
UML, Astah e ERwin Data Modeler. Na Figura 6 vemos um exemplo de diagrama sendo
construído no Astah.
 Figura 6.
Diagrama no Astah Community

Além dessas ferramentas específicas, alguns IDEs (Integrated Development

Environment ou Ambiente de Desenvolvimento Integrado) como o Visual Studio e
ferramentas de gerenciamento de bancos de dados como SQL Server Management
Studio possuem funcionalidades para criar diagramas facilmente e já gerar o código
equivalente (SQL para criação das tabelas, chaves e relacionamentos, por exemplo).

Saiba mais sobre como criar diagramas com o Astah

Exemplo prático

Para fixar tudo que foi visto ao longo deste artigo, vamos agora desenvolver um
pequeno exemplo prático em que modelaremos um sistema de bibliotecas, focando
especificamente no empréstimo de livros.

Primeiramente precisamos identificar as entidades envolvidas nesse contexto.

Sabemos que as entidades físicas existentes são o Usuário da biblioteca e o Livro que
será emprestado. Além disso, consideraremos aqui que o livro pertence a uma
Sessão, que ajuda na organização das obras do acervo. Em um sistema real pode
haver outras informações sobre o livro, mas para esse exemplo a sessão é o bastante.
Por fim, temos a entidade lógica Empréstimo, que tanto está relacionada com o
usuário, quanto com o livro.
Assim já podemos esboçar nosso primeiro diagrama, simples, contendo as principais
entidades e o relacionamento entre elas (Figura 7).

Figura 7. Primeiro DER de

um sistema para biblioteca

Neste primeiro diagrama podemos identificar alguns dos conceitos vistos:

• Entidades fortes: Usuário, Livro e Sessão;

• Entidades fracas: Empréstimo;
• Relacionamentos: um Usuário efetua vários Empréstimos, vários Empréstimos
contêm vários Livros, vários Livros pertencem a uma Sessão.

Agora que visualizamos o domínio no diagrama, podemos adicionar os atributos e

outras entidades que se façam necessárias. Assim, passamos à Figura 8,
 Figura 8. DER
mais completo do sistema para bibliotecas

Neste ponto cabe fazer algumas observações importantes:

Especificamos os atributos de cada entidade e marcamos algumas elas com um

asterisco, indicando que aquela é a chave primária da tabela, ou seja, um atributo
único, que nunca poderá se repetir entre as entidades do mesmo tipo. Note que neste
momento ainda não é necessário especificar o tipo de cada atributo (texto, número,
data, etc.), isso só será necessário mais adiante, quando já estivermos planejando o
banco de dados da aplicação.

Surgiu a entidade associativa Livro_Empréstimo, que representa os livros contidos

em um empréstimo (considerando um empréstimo contém vários livros e um livro
pode estar contido em vários empréstimos). Esta entidade é composta pelas chaves
das duas entidades principais. Se fosse necessário, nesta entidade também
poderíamos adicionar informações complementares como quantidade (não se aplica
neste caso, mas caberia em um sistema de vendas, por exemplo) e observações sobre
o item.
Na entidade associativa, o relacionamento n..n foi dividido em dois relacionamentos
do tipo 1..n, agora lidos da seguinte forma: um empréstimo contém vários itens, mas
um item só pode estar contido em um único empréstimo (restrito pelas chaves
primárias); um livro pode estar contido em vários itens de empréstimo (ser
emprestado várias vezes), mas cada item refere-se a um único livro.

O Modelo Entidade Relacionamento (e principalmente o diagrama) é uma

importante ferramenta durante o desenvolvimento de sistemas, principalmente
aqueles mais complexos e difíceis de visualizar sem uma análise mais aprofundada.

A correta modelagem auxilia no correto desenvolvimento da base de dados e evita

que várias alterações sejam necessárias para corrigir erros de concepção
provenientes de falhas durante a análise, ou ainda por problemas de comunicação
entre os membros da equipe.

Modelagem de dados: 1:N ou N:N?

Você sabe quando usar um relacionamento do tipo 1:N ou N:N? Optar pelo tipo
incorreto pode impactar diretamente no negócio. Portanto, a decisão por qual usar
deve ser tomada com cuidado na fase de modelagem.

Relacionamento 1:N

Relacionamentos do tipo 1:N (um para muitos) ocorrem quando uma ocorrência de
uma entidade pode se relacionar com várias ocorrências de outra entidade. No
contexto do banco de dados isso significa que para um registro em uma tabela podem
existir vários registros relacionados em outra.

Veja abaixo alguns exemplos desse tipo de relacionamento:

Note que do lado “N” do relacionamento há sempre um campo que aponta para a
chave primária do lado “1”. Por exemplo, o produto possui o ID_Marca, que receberá
o ID da marca à qual ele pertence.

Essa é uma característica dos relacionamentos 1:N. Na tabela do lado “N” cria-se uma
“chave estrangeira” que aponta para a chave primária da tabela “1”.

Relacionamento N:N

Os relacionamentos do tipo N:N (muitos para muitos) ocorrem quando vários

registros de uma tabela se relacionam a vários registros de outra. Ou seja, em
nenhum dos lados há exclusividade no relacionamento.

Diferente do que ocorre no 1:N, nessas situações não é possível que uma tabela tenha
uma referência direta à outra, pois isso indicaria que cada registro está relacionado
unicamente a um da outra tabela.

Surge nesse caso uma tabela intermediária que relaciona as outras duas, como
podemos ver nos exemplos abaixo:
Note que a tabela intermediária possui sempre duas chaves estrangeiras que apontam
para as chaves primárias das duas tabelas principais. Dessa forma é possível dizer,
por exemplo, que o Ator 123 atuou nos filmes 456 e 789, ou que o produto 100
pertence à categoria 10 e também à categoria 20.

Há casos também em que a tabela intermediária pode ter dados adicionais, além das
chaves estrangeiras, como ilustra a Figura 1.

Figura
1. Produtos x Vendas

Aqui a tabela intermediária armazena os dados dos produtos incluídos em cada

venda. Observe a Figura 2.
 Figura 2. Dados
dos itens vendidos

Observe que a partir da tabela de produtos não é possível saber sobre suas vendas, da
mesma forma que na tabela de vendas não há informações sobre os produtos que
foram vendidos. Esses dados ficam na tabela de itens da venda, a partir da qual
podemos tirar algumas conclusões:

• A venda de ID 1 contém 3 itens, sendo 2 camisas e 1 óculos. Ainda nessa venda

os óculos que custam 25,00 foram vendidos por 20,00;
• A venda de ID 2 contém 2 sapatos;
• A venda de ID 3 contém 1 óculos.

Esses dois tipos de relacionamento são muito comuns e às vezes podem ser
confundidos, o que pode causar problemas no futuro. Por exemplo, imagine que no
momento da modelagem do sistema a relação entre produtos e categorias foi
modelada como 1:N, em que um produto só pertencia a uma categoria. Mais à frente
viu-se a necessidade de vincular um mesmo produto a várias categorias e o sistema
não suportava essa situação.

Portanto, é fundamental analisar com cautela as possíveis condições a fim de evitar

problemas futuros.
1:1 – Neste relacionamento, cada um dos elementos de uma entidade só pode se
relacionar com apenas um elemento de outra entidade. Então, consideremos as
tabelas Clientes e Documentos, em que cada um dos clientes pode ter apenas um
documento (considerando que nesta tabela um mesmo cliente não pode ter mais de
um documento), assim como cada um dos documentos só pode pertencer a apenas
um cliente.

Confira nas imagens abaixo a criação das tabelas, das constraints e inserção de
alguns registros:

Perceba que na tabela Documentos criei uma Foreign Key (chave estrangeira) se
relacionando com a Primary Key da tabela

[Link] como ficarão as tabelas:

Assim temos o relacionamento de um-para-um.

1:N – Neste relacionamento, que é um dos mais comuns hoje em dia, cada elemento
da entidade “A” pode ter um relacionamento com vários elementos da entidade “B”.
Em contrapartida, cada um dos elementos da entidade B pode estar relacionado a
apenas um elemento da A. Dito isto, consideremos a tabela Clientes já criada e agora
vamos criar a tabela Telefones com o código a seguir, já que neste caso cada cliente
pode ter vários telefones, mais cada telefone pode pertencer a um, e somente um
cliente:

CREATE TABLE Telefones

(
IdTelefone INT IDENTITY(1,1),
IdCliente INT NULL,
TipoTelefone VARCHAR(15) NOT NULL,
NumeroTelefone VARCHAR(15) NOT NULL

CONSTRAINT PK_Telefone PRIMARY KEY (IdTelefone),

CONSTRAINT FK_Telefones_IdCliente FOREIGN KEY (IdCliente)
REFERENCES Clientes (IdCliente)
)

--Insiro alguns registros na tabela Telefones

INSERT INTO Telefones VALUES (1, 'Residencial', '3243-2015')
INSERT INTO Telefones VALUES (3, 'Comercial', '3221-0132')
INSERT INTO Telefones VALUES (1, 'Celular', '9777-2112')
INSERT INTO Telefones VALUES (2, 'Residencial', '3353-9899')
INSERT INTO Telefones VALUES (2, 'Celular', '8871-1015')

Confira nas imagens a seguir a inserção de alguns registros e o resultado da consulta

a ela:

Assim temos o relacionamento de um-para-muitos.

N:N – Neste relacionamento, que é diferente dos outros, os dados estão

diretamente relacionados ao fato, e não às entidades, como os outros dois
anteriores. Seguindo as regras deste tipo de relacionamento, temos que,
obrigatoriamente, criar três tabelas, já que a terceira tem a responsabilidade crucial
de fazer o relacionamento entre as outras duas.

Para uma melhor compreensão, vamos usar novamente a tabela Clientes e a

tabela Pedidos, criada no artigo anterior. Com elas, temos a seguinte situação: um
cliente pode fazer diversos pedidos, ao passo que um pedido pode ser feito por
diversos clientes.

Como já temos as tabelas criadas, vamos apenas criar a terceira tabela,

denominada ClientesXPedidos, responsável por interliga-las. Veja as imagens a seguir de
sua criação, inserção de registros (note que ela conterá apenas as chaves das duas
outras tabelas) e posterior consulta:

Perceba na imagem acima que os mesmos campos, IdCliente e IdPedido, são chaves
primárias e também são chaves estrangeiras, criando assim o relacionamento entre
as tabelas Cliente e Pedido.

Assim temos o relacionamento de muitos-para-muitos.