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 necessrios para a
construo do produto final. Durante essa anlise, identifica-se as principais
partes e objetos envolvidos, suas possveis aes e responsabilidades, suas
caractersticas e como elas interagem entre si.
A partir das informaes obtidas, pode-se desenvolver um modelo conceitual
que ser utilizado para orientar o desenvolvimento propriamente dito,
fornecendo informaes sobre os aspectos relacionados ao domnio do projeto
em questo.

Modelo Entidade Relacionamento

O Modelo Entidade Relacionamento (tambm 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 domnio de negcios, com suas caractersticas (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 aplicao. Obviamente, o banco de dados poder conter
vrias outras entidades, tais como chaves e tabelas intermedirias, que podem
s fazer sentido no contexto de bases de dados relacionais.
Observao: nem sempre criaremos modelos para um sistema completo, pois
isso poderia resultar em um modelo muito extenso e difcil de interpretar.
Dependendo da magnitude do que estaremos desenvolvendo, podemos criar
modelos apenas para uma parte do sistema, um mdulo, ou mesmo uma
funcionalidade. Imagine, por exemplo, um sistema ERP de grande porte que
contemple vendas, finanas, recursos humanos, etc. Vrias entidades esto
presentes em mais de uma parte do sistema, mas no seria muito interessante,
e provavelmente nem mesmo necessrio, criar um nico modelo para todo o
sistema, por isso pode-se dividir a modelagem em vrias partes menores.

Entidades
Os objetos ou partes envolvidas um domnio, tambm chamados de entidades,
podem ser classificados como fsicos ou lgicos, de acordo sua existncia no
mundo real. Entidades fsicas: so aquelas realmente tangveis, existentes e

visveis no mundo real, como um cliente (uma pessoa, uma empresa) ou um

produto (um carro, um computador, uma roupa). J as entidades lgicas so
aquelas que existem geralmente em decorrncia da interao entre ou com
entidades fsicas, que fazem sentido dentro de um certo domnio de negcios,
mas que no mundo externo/real no so objetos fsicos (que ocupam lugar no
espao). So exemplos disso uma venda ou uma classificao de um objeto
(modelo, espcie, funo de um usurio do sistema).
As entidades so nomeadas com substantivos concretos ou abstratos que
representem de forma clara sua funo dentro do domnio. Exemplos prticos
de entidades comuns em vrios sistemas so Cliente, Produto, Venda, Turma,
Funo, entre outros.
Podemos classificar as entidades segundo o motivo de sua existncia:
Entidades fortes: so aquelas cuja existncia 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 contrrio das entidades fortes, as fracas so
aquelas que dependem de outras entidades para existirem, pois
individualmente elas no fazem sentido. Mantendo o mesmo exemplo,
a entidade venda depende da entidade produto, pois uma venda sem
itens no tem sentido.
Entidades associativas: esse tipo de entidade surge quando h um
relacionamento do tipo muitos para muitos (explicado a seguir). Nestes
casos, necessria a criao de uma entidade intermediria cuja
identificao formada pelas chaves primrias (explicado mais adiante)
das outras duas entidades. No contexto de uma aplicao de vendas,
como precisamos relacionar vendas e produtos numa relao muitos
para muitos, a entidade produto no pode referenciar diretamente a
venda, nem o inverso, pois isso caracterizaria um relacionamento um
para um, ou um para muitos. Sendo assim, criamos uma entidade
intermediria para representar os itens da venda, que tanto possuem a
identificao do produto, quando da venda em que esto contidos.
Neste caso especfico, tambm caberiam a esta entidade informaes
como quantidade de itens e desconto unitrio, por exemplo.
Mais adiante veremos um exemplo prtico onde poderemos observar a
existncia dessas entidades de forma mais clara.

Relacionamentos
Uma vez que as entidades so identificadas, deve-se ento 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 trs
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 currculos, cada usurio
cadastrado pode possuir apenas um currculo na base, ao mesmo tempo
em que cada currculo s pertence a um nico usurio cadastrado.
Relacionamento 1..n ou 1..* (um para muitos): uma das entidades
envolvidas pode referenciar vrias unidades da outra, porm, do outro
lado cada uma das vrias unidades referenciadas s pode estar ligada
uma unidade da outra entidade. Por exemplo, em um sistema de plano
de sade, um usurio pode ter vrios dependentes, mas cada dependente
s pode estar ligado a um usurio principal. Note que temos apenas
duas entidades envolvidas: usurio 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
mltiplas unidades da outra. Por exemplo, em um sistema de biblioteca,
um ttulo pode ser escrito por vrios autores, ao mesmo tempo em que
um autor pode escrever vrios ttulos. Assim, um objeto do tipo autor
pode referenciar mltiplos objetos do tipo ttulo, e vice versa.
Os relacionamentos em geral so nomeados com verbos ou expresses que
representam a forma como as entidades interagem, ou a ao que uma exerce
sobre a outra. Essa nomenclatura pode variar de acordo com a direo em que
se l o relacionamento. Por exemplo: um autor escreve vrios livros, enquanto
um livro escrito por vrios autores.

Atributos
Atributos so as caractersticas que descrevem cada entidade dentro do
domnio. Por exemplo, um cliente possui nome, endereo e telefone. Durante
a anlise de requisitos, so identificados os atributos relevantes de cada
entidade naquele contexto, de forma a manter o modelo o mais simples

possvel e consequentemente armazenar apenas as informaes que sero 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 informaes dificilmente sero relevantes.
Os atributos podem ser classificados quanto sua funo da seguinte forma:
Descritivos: representam caracterstica intrnsecas de uma entidade, tais
como nome ou cor.
Nominativos: alm de serem tambm descritivos, estes tm a funo de
definir e identificar um objeto. Nome, cdigo, nmero so exemplos de
atributos nominativos.
Referenciais: representam a ligao 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 caracterstica da entidade.
Exemplos: nome, peso.
Compostos: para definir uma informao da entidade, so usados vrios
atributos. Por exemplo, o endereo pode ser composto por rua, nmero,
bairro, etc.
Alguns atributos representam valores nicos que identificam a entidade dentro
do domnio e no podem se repetir. Em um cadastro de clientes, por exemplo,
esse atributo poderia ser o CPF. A estes chamamos de Chave Primria.
J os atributos referenciais so chamados de Chave Estrangeira e geralmente
esto ligados chave primria da outra entidade. Estes termos so bastante
comuns no contexto de bancos de dados. Mantendo o exemplo anterior, a
entidade cliente tem como chave primria seu CPF, assim, a venda possui
tambm 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 representao grfica e

principal ferramenta. Em situaes prticas, o diagrama tido muitas vezes

como sinnimo de modelo, uma vez que sem uma forma de visualizar as
informaes, o modelo pode ficar abstrato demais para auxiliar no
desenvolvimento do sistema. Dessa forma, quando se est modelando um
domnio, o mais comum j criar sua representao grfica, seguindo
algumas regras.
O diagrama facilita ainda a comunicao entre os integrantes da equipe, pois
oferece uma linguagem comum utilizada tanto pelo analista, responsvel por
levantar os requisitos, e os desenvolvedores, responsveis por implementar
aquilo que foi modelado.
Em sua notao original, proposta por Peter Chen (idealizador do modelo e do
diagrama), as entidades deveriam ser representadas por retngulos, seus
atributos por elipses e os relacionamentos por losangos, ligados s entidades
por linhas, contendo tambm sua cardinalidade (1..1, 1..n ou n..n). Porm,
notaes 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 prpria entidade. Essa forma torna o diagrama mais
limpo e fcil de ser lido.
Observe na Figura 1 um exemplo simples de um diagrama para um sistema
de imobilirias.

Figura 1. Diagrama Entidade Relacionamento de sistema de imobiliria

No domnio representado pelo diagrama acima temos as seguintes entidades e

relacionamentos:
Proprietrio contata Corretor (um proprietrio pode contatar vrios
corretores e um corretor pode ser contatado por vrios proprietrios).
Corretor atende Inquilino (um corretor pode atender vrios inquilinos e
um inquilino pode ser atendido por vrios corretores).
Inquilino aluga Imvel (um inquilino aluga um imvel e um imvel
pode ser alugado por vrios inquilinos).
Proprietrio possui Imvel (um proprietrio possui vrios imveis e um
imvel pertence a apenas um proprietrio).
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 (variao)

Uma outra variao j mostra a cardinalidade de uma forma mais completa,
deixando claro as possibilidades de nmeros de objetos envolvidos em cada
relacionamento. Nesse modelo, em cada lado do relacionamento os nmeros
aparecem no formato (X,Y) ao invs de um nico nmero como vemos nas
figuras anteriores. A Figura 3 ilustra um exemplo desse tipo.

Figura 3. Diagrama Entidade Relacionamento (variao 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 no temos vrias possibilidades.
J do lado do produto, indicamos que um grupo pode possuir nenhum
produto, mas tambm pode possuir vrios.
0 ou vrias vendas contm 1 ou muitos produtos. Ou seja, um produto
pode nunca ser vendido (0 vendas) como tambm pode ser vendido
vrias vezes (n vendas). J uma venda deve conter 1 ou vrios produtos,
pois uma venda no 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 notao original proposta, mas como
podemos ver na Figura 4, ela deixa o diagrama com muitos itens e pode
atrapalhar um pouco a organizao destes.

Figura 4. Atributos apresentados como elipses

Em uma notao mais atual, comumente utilizada na UML, os atributos
aparecem listados dentro do prprio retngulo da entidade, enquanto o nome
da entidade aparece no topo na forma de ttulo. Na Figura 5 temos um
exemplo.

Figura 5. Diagrama com atributos nas entidades

Ferramentas CASE
Do ingls Computer-Aided Software Engineering, as chamadas ferramentas
CASE so aquelas baseadas em computadores (softwares) utilizadas na
Engenharia de Software para auxlio nas atividades desde anlise de requisitos
at modelagem de dados.
No contexto desse artigo, as ferramentas CASE permitem a criao de
diagramas de forma simples em um ambiente de fcil utilizao e com
recursos para incluir as principais regras de composio dos diagramas.
Exemplos comuns desse tipo de ferramenta so: Star UML, Astah Comunity e
ERwin data modeler. Na Figura 6 vemos um exemplo de diagrama sendo
construdo no Astah.

Figura 6. Diagrama no Astah Community

Alm dessas ferramentas especficas, 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 cdigo equivalente (SQL para criao das tabelas, chaves e
relacionamentos, por exemplo).

Exemplo prtico
Para fixar tudo que foi visto ao longo deste artigo, vamos agora desenvolver
um pequeno exemplo prtico em que modelaremos um sistema de bibliotecas,
focando especificamente no emprstimo de livros.
Primeiramente precisamos identificar as entidades envolvidas nesse contexto.
Sabemos que as entidades fsicas existentes so o Usurio da biblioteca e
o Livro que ser emprestado. Alm disso, consideraremos aqui que o livro
pertence a uma Sesso, que ajuda na organizao das obras do acervo. Em um
sistema real pode haver outras informaes sobre o livro, mas para esse
exemplo a sesso o bastante. Por fim, temos a entidade

lgica Emprstimo, que tanto est relacionada com o usurio, quanto com o
livro.
Assim j podemos esboar 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: Usurio, Livro e Sesso;
Entidades fracas: Emprstimo;
Relacionamentos: um Usurio efetua vrios Emprstimos, vrios
Emprstimos contm vrios Livros, vrios Livros pertencem a uma
Sesso.
Agora que visualizamos o domnio no diagrama, podemos adicionar os
atributos e outras entidades que se faam necessrias. Assim, passamos
Figura 8,

Figura 8. DER mais completo do sistema para bibliotecas

Neste ponto cabe fazer algumas observaes importantes:
Especificamos os atributos de cada entidade e marcamos algumas elas com
um asterisco, indicando que aquela a chave primria da tabela, ou seja, um
atributo nico, que nunca poder se repetir entre as entidades do mesmo tipo.
Note que neste momento ainda no necessrio especificar o tipo de cada
atributo (texto, nmero, data, etc.), isso s ser necessrio mais adiante,
quando j estivermos planejando o banco de dados da aplicao.
Surgiu a entidade associativa Livro_Emprstimo, que representa os livros
contidos em um emprstimo (considerando um emprstimo contm vrios
livros e um livro pode estar contido em vrios emprstimos). Esta entidade

composta pelas chaves das duas entidades principais. Se fosse necessrio,

nesta entidade tambm poderamos adicionar informaes complementares
como quantidade (no se aplica neste caso, mas caberia em um sistema de
vendas, por exemplo) e observaes 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 emprstimo
contm vrios itens, mas um item s pode estar contido em um nico
emprstimo (restrito pelas chaves primrias); um livro pode estar contido em
vrios itens de emprstimo (ser emprestado vrias 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 difceis de visualizar sem uma anlise mais
aprofundada.
A correta modelagem auxilia no correto desenvolvimento da base de dados e
evita que vrias alteraes sejam necessrias para corrigir erros de concepo
provenientes de falhas durante a anlise, ou ainda por problemas de
comunicao entre os membros da equipe.

Leia mais em: Modelo Entidade Relacionamento (MER) e Diagrama

Entidade-Relacionamento (DER) http://www.devmedia.com.br/modeloentidade-relacionamento-mer-e-diagrama-entidade-relacionamentoder/14332#ixzz46wR5jwSH