Modelagem

da Informação
 Material Teórico
Modelo e Diagrama Entidade Relacionamento (MER e DER)

Responsável pelo Conteúdo:

Prof. Me. José Ahirton Batista Lopes Filho

Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
 Modelo e Diagrama Entidade
Relacionamento (MER e DER)

• Introdução – A Importância do Levantamento de Requisitos;

• Modelo Entidade Relacionamento (MER);
• Diagrama Entidade Relacionamento (DER);
• Considerações, Limitações e Boas Práticas;
• Criando um Diagrama ER.

OBJETIVOS DE APRENDIZADO
• Capacitar os alunos quanto à abstração e à construção de Modelos Entidade Relaciona-
mento (MER);
• Impulsionar o pensamento crítico quanto ao desenho e à utilização de modelos no pro-
cesso de modelagem da informação, como parte do levantamento de requisitos e design
de soluções, aplicativos ou funcionalidades diversas;
• Qualificar os alunos para lidarem com o processo de gestão e construção de conhecimen-
to quando inseridos em equipes ágeis, adotando uma verdadeira cultura de dados em
suas vidas profissionais.
 Orientações de estudo
Para que o conteúdo desta Disciplina seja bem
aproveitado e haja maior aplicabilidade na sua
formação acadêmica e atuação profissional, siga
algumas recomendações básicas:
Conserve seu
material e local de
estudos sempre
organizados.
Aproveite as
Procure manter indicações
contato com seus de Material
colegas e tutores Complementar.
para trocar ideias!
Determine um Isso amplia a
horário fixo aprendizagem.
para estudar.

Mantenha o foco!
Evite se distrair com
as redes sociais.

Seja original!
Nunca plagie
trabalhos.

Não se esqueça
de se alimentar
Assim: e de se manter
Organize seus estudos de maneira que passem a fazer parte hidratado.
da sua rotina. Por exemplo, você poderá determinar um dia e
horário fixos como seu “momento do estudo”;

Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma

alimentação saudável pode proporcionar melhor aproveitamento do estudo;

No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão sua
interpretação e auxiliarão no pleno entendimento dos temas abordados;

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e de
aprendizagem.
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

Introdução – A Importância do
Levantamento de Requisitos
Nas Unidades anteriores, pudemos notar a importância da construção de mode-
los logo ao iniciarmos o desenvolvimento de um novo sistema ou mesmo de uma
nova funcionalidade ou aplicação para um sistema existente.

Mais especificamente, os processos da chamada Engenharia de Requisitos são

cada vez mais perceptíveis, visto essa ser uma das fases iniciais do processo de
Engenharia de Software, a qual está diretamente ligada aos processos de coleta,
entendimento, armazenamento e gerenciamento de requisitos.

Por exemplo, Sommerville (2007) aborda em seu livro que, durante o processo
de Engenharia de Requisitos é que se acaba definindo o que de fato o sistema deve
fazer, quais suas características, tanto essenciais quanto desejáveis, assim como as
restrições possíveis quanto à sua operação e o seu processo de desenvolvimento.

Um processo que, quando não executado de forma adequada, pode levar à cons-
trução de sistemas falhos e complexos, que de fato não atendam ao proposto pelo
cliente. Então, na fase de elicitação e análise de requisitos, a primeira atividade na
Engenharia de Requisitos, é dada ênfase na busca e aquisição de requisitos para o
desenvolvimento do software, utilizando técnicas e métodos adequados para obtê-los.

Porém, cabe aqui ressaltar que essa atividade não ocorre apenas uma única vez,
sendo um processo iterativo, ou seja, nas demais atividades do processo de Enge-
nharia de Requisitos, ela também pode ser empregada.

É nessa fase que clientes, usuários, desenvolvedores, gerentes de projeto e to-

dos os demais envolvidos com o projeto de software, estabelecem as informações
necessárias, que darão suporte aos engenheiros de software e demais papéis que
atuarão na produção dos requisitos adequados para o sistema.

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 exe-
cutado é o estudo, tendo em vista a construção do produto final.

Durante essa análise, são identificadas as principais partes e objetos envolvidos,

suas possíveis ações e responsabilidades, suas características e como elas interagem
entre si.

Assim, a partir das informações de requisitos obtidas, pode-se, então, desenvol-

ver um modelo conceitual, como visto em unidades anteriores, que será utilizado
para orientar o desenvolvimento, fornecendo informações sobre os aspectos rela-
cionados ao domínio do projeto.

8
Explor
De modo geral, a criação e o posterior sucesso de um projeto de software dependem de um
processo de Engenharia de Requisitos bem elaborado e definido, visto que tal processo auxi-
lia em aspectos como a construção de tarefas tangíveis, que podem ajudar na compreensão
do impacto do produto a ser criado no negócio, permitindo, também, o alinhamento entre o
desejado pelo cliente e o que de fato é entregue aos usuários finais.

Modelo Entidade Relacionamento (MER)

O Modelo Entidade Relacionamento (Modelo ER ou MER) é um modelo con-
ceitual 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 os relacionamentos.

Em geral, esse modelo representa, de forma abstrata, a estrutura que possuirá o

Banco de Dados de um sistema ou aplicação.

Cabe a ressalva de que o Banco de Dados poderá conter várias outras entida-
des, como chaves e tabelas intermediárias, que podem só fazer sentido no contexto
de Bases de Dados Relacionais.

Importante! Importante!

Nem sempre criaremos modelos para um sistema completo, pois ele pode acabar muito
extenso e de difícil interpretação. Dependendo da complexidade do que estaremos de-
senvolvendo, podemos criar modelos apenas para uma parte do sistema, um módulo, ou
mesmo uma única funcionalidade.

Por exemplo, de acordo com nosso caso anterior de um aplicativo de mobilidade

urbana, imagine que um sistema pode, então, contemplar viagens feitas, dados do
passageiro, do motorista etc., no qual várias entidades podem estar presentes em
mais de uma camada do sistema.

Logo, não é de interesse e nem mesmo necessária a criação de um modelo com-

pleto, único, para o sistema.

Assim, é importante ressaltar que se pode dividir a modelagem em várias partes menores,
Explor

normalmente, no nível de funções ou sistemas específicos.

Comumente, o MER descreve a estrutura de um Banco de Dados com a ajuda

de um diagrama, conhecido como Diagrama Entidade Relacionamento (Diagrama
ER ou DER).

9
9
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

Um MER pode ser encarado como design ou, mais especificamente, o desenho
de uma planta de um Banco de Dados, que pode ser implementado posteriormente
como um Banco de Dados.

Os principais componentes do MER são, então, o conjunto de entidades e o

conjunto de relacionamentos.

Já um DER mostra o relacionamento entre conjuntos de entidades, no qual um

conjunto de entidades é um grupo de entidades semelhantes, e essas entidades
podem, então, ter atributos.

Diagrama Entidade Relacionamento (DER)

Enquanto o MER é um modelo conceitual, o Diagrama Entidade Relacionamen-
to (Diagrama ER ou ainda DER) é a sua representação gráfica e principal ferra-
menta. Em situações práticas, o diagrama é tido, muitas vezes, como sinônimo de
modelo, vez que, sem uma forma de visualizar as informações, o modelo pode ficar
abstrato demais para auxiliar no desenvolvimento de sistemas.

Dessa maneira, quando se está modelando um domínio, o mais comum é já

criar sua representação gráfica, seguindo algumas regras. Além disso, a utilização
de diagramas tende a facilitar a comunicação entre os integrantes da equipe, pois
oferece uma linguagem comum utilizada tanto por analistas, responsáveis por le-
vantar os requisitos, quanto 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, con-
tendo 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á apare-
cem listados na própria entidade. Essa forma torna o diagrama mais limpo e fácil
de ser lido.

Nas Figuras 1 e 2, a seguir, temos, respectivamente, exemplo de DER para um

sistema de consulta de alunos, disciplinas e professores de uma universidade em
ambas as notações, no original de Peter Chen e no formato utilizada na UML.

Estudante Registrado em Disciplina Lecionada por Professor

Nome ID_Estudante Vagas ID_Disciplina Nome ID_Professor

Figura 1 – Exemplo simplificado de DER para sistema de consulta de alunos,

disciplinas e professores de uma universidade na notação de Peter Chen

10
 Estudante Disciplina Professor
+ String: Nome + String: Nome + String: Nome
+ String: ID_Estudante + String: ID_Estudante + String: ID_Professor
+ Int: Vagas

Figura 2 – Exemplo simplificado de DER para sistema de consulta de alunos,

disciplinas e professores de uma universidade na notação da UML

Entidades
Uma entidade é comumente descrita como algo que pode ser definido e que
pode ter dados armazenados sobre ela, tais como uma pessoa, um objeto ou um
evento. Normalmente, entidades são pensadas como substantivos tais como um
estudante ou um consumidor.

Mais especificamente, em termos de modelagem, uma entidade é uma tabela, ou

atributo de uma tabela, no banco de dados; portanto, ao mostrar o relacionamento
entre tabelas e seus atributos, o DER mostra a estrutura lógica completa de um
banco de dados.

As entidades são então baseadas em um grupo de coisas definíveis, como estu-

dantes, atletas e clientes, ao passo que uma única entidade seria, então, um estu-
dante, um atleta e um cliente em específico.

Tais entidades são comumente categorizadas como físicas ou lógicas, 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 (seja uma pessoa, seja uma empresa etc.) ou um
produto (seja um carro, seja um computador, seja um tênis);
• Já as entidades lógicas são aquelas que existem, geralmente em decorrência da
interação entre, ou com, entidades físicas; que acabam fazendo sentido dentro
de um certo contexto de 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 a devida classificação de um objeto (modelo,

espécie, função de um usuário do sistema, e assim sucessivamente).

Como dito anteriormente, as entidades são nomeadas por substantivos concre-

tos 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, Grupo e Função, dentre outros.

11
11
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

Também podemos classificar as entidades de acordo com o motivo para sua

existência, sejam elas fortes, fracas ou associativas:
• Entidades fortes: são aquelas cuja existência independe de outras entidades,
ou seja, por si só elas já possuem total sentido de existir e podem ser definidas
unicamente pelos seus próprios atributos. Por exemplo, em um sistema de
registro de sócios e seus dependentes em um determinado clube, a entidade
Sócio independe de quaisquer outras para existir;
• Entidades fracas: já as entidades fracas são aquelas que dependem de ou-
tras entidades para existirem, pois elas não fazem sentido de maneira in-
dividual, ou seja, não podem ser definidas unicamente por seus próprios
atributos. A partir do exemplo anterior, uma entidade Dependente só existe
por conta da entidade Sócio;
• Entidades associativas: tal tipo de entidade surge quando há a necessidade
de se associar uma entidade a um relacionamento existente, ou seja, junta en-
tidades dentro de um conjunto de entidades.

As entidades associativas existem, pois, na MER, não é possível que um relacio-

namento 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 um sistema

de uma Clínica Médica na qual temos todas as prescrições de todos os médicos que
atendem nessa clínica para seus pacientes após realizadas as devidas consultas.

Nesse caso, temos, então, as entidades Médico e Paciente que se relacionam por
meio de uma entidade associativa Consulta, de maneira muitos-para-muitos, vez
que em nosso sistema existem vários médicos e pacientes diferentes que podem
estar relacionados no mesmo sistema, com também diferentes consultas para dife-
rentes médicos.

Isso ocorre pois, imagine que queiramos saber se o medicamento que o médico
receitou para o paciente em uma consulta qualquer necessita de receita (um flag na
entidade Medicamento).

Nesse caso, relacionar a entidade Medicamento para com somente a entidade

Médico ou para com somente a entidade Paciente não faz sentido, logo vê-se,
então, a necessidade de uma entidade que associe Médico e Paciente, no caso, a
entidade associativa Consulta.

A seguir, na Figura 3, temos o exemplo simplificado descrito, com ênfase na

entidade associativa Consulta, de forma que o que foi abordado anteriormente em
texto fique mais claro.

12
 n n
Médico Consulta Paciente

Prescrição

Medicamento

Figura 3 – Exemplo simplificado de DER para consulta de

prescrição de medicamentos em sistema de clínica médica

Relacionamentos
Tendo em vista que entidades atuam umas sobre as outras, ou estão associadas
uma para com as outras, pense em relacionamentos como se fossem verbos. Do
nosso exemplo anterior, temos que Médicos consultam Pacientes e podem prescre-
ver Medicamentos.

Logo, uma vez que as entidades são identificadas, deve-se, então, definir como
se dá o relacionamento entre elas. Comumente, os relacionamentos são classifica-
dos de três formas, de acordo com a quantidade de objetos envolvidos em cada lado
do relacionamento:
• Relacionamentos 1..1 (um para um): cada uma das duas entidades envolvi-
das referência, obrigatoriamente, apenas uma unidade da outra. Por exemplo,
em um Banco de Dados policial, cada infrator cadastrado possui somente uma
ficha criminal na base, ao mesmo tempo em que cada ficha criminal só perten-
ce a um único infrator cadastrado;
• Relacionamentos 1..n ou 1..* (um para muitos): nesse tipo de relacionamen-
to, 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 a uma unidade da outra entidade. Por exemplo, no nosso exemplo
do tópico anterior sobre entidades, com relação ao sistema de um clube, cada
Sócio pode ter vários Dependentes, mas cada Dependente, invariavelmente,
só pode estar ligado a um Sócio. Nesse caso, em específico, o que se modifica
é a quantidade de objetos envolvidos de cada lado do relacionamento;
• Relacionamentos n..n, n:m ou *..* (muitos para muitos): neste tipo de rela-
cionamento, cada entidade, de ambos os lados, pode referenciar múltiplas uni-
dades da outra. Por exemplo, em um sistema de publicação de artigos científi-
cos, um Artigo pode ter vários Autores enquanto um Autor também pode ter
participação na autoria de diferentes artigos. Assim, um objeto do tipo Autor
pode referenciar múltiplos objetos do tipo Artigo.

13
13
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

Como dito anteriormente, pense em relacionamentos, em geral, como verbos,

ou melhor, como expressões que representam a forma como as entidades intera-
gem entre si e para com as outras (as ações envolvidas).

Essa nomenclatura pode variar de acordo com a direção em que se lê o relacio-

namento em que, por exemplo, um Autor pode escrever vários Artigos, enquanto
um Artigo é escrito por vários Autores.

Atributos
Atributos são as características que descrevem as propriedades ou as caracte-
rísticas de cada uma das entidades envolvidas dentro de um domínio. De nosso
exemplo anterior, um Paciente pode possuir Nome, Endereço, Telefone, Número
de Convênio Médico associado e uma série de outras informações relevantes.

Mais especificamente, durante a análise de requisitos, são identificados os atribu-

tos relevantes de cada entidade naquele contexto de negócio ou domínio em especí-
fico, de forma a manter o modelo o mais simples possível e, consequentemente, de
forma que armazenemos apenas as informações mais relevantes para uso.

Um médico possui características tais como etnia, escolaridade, altura, peso

e preferências pessoais, porém, no contexto de nosso sistema estas informações
possivelmente não são relevantes. Os atributos, podem ser, então, classificados de
acordo com a sua função, em descritivos, nominativos e referenciais:
• Descritivos: representam as características intrínsecas de um objeto, tais como
nome, idade ou cor;
• Nominativos: além de também cumprirem a função de descritivos, têm a fun-
ção de definir e identificar um objeto. Nomes, códigos, números e siglas se
encaixam nessa categorização;
• Referenciais: representam uma citação ou a ligação de uma entidade com
outra em um relacionamento, não propriamente definindo uma característica
do objeto, mas explicitando um relacionamento. Por exemplo, uma Consulta
pode possuir um identificador único, que a relaciona a uma entidade Paciente.

Quanto à estrutura, podemos ainda classificar os atributos como:

• Simples: não possuem quaisquer características especiais. Então, um único
atributo define uma característica da entidade. Mais especificamente, quando
um atributo não é composto, recebe apenas um valor único como nome, e não
é um atributo chave, então ele será atributo simples. Exemplos: Nome e Peso.
A maioria dos atributos serão simples;
• Compostos: quando para definir uma informação da entidade, usam-se
vários atributos. Logo, seu conteúdo é formado por vários itens menores.
Por exemplo: endereço, visto que seu conteúdo poderá ser dividido em vários
outros atributos, tais como: Rua, Número, Complemento, Bairro, CEP e Cidade;

14
 • Atributo Multivalorado: quando seu conteúdo é formado por mais de um va-
lor. Por exemplo: telefone, visto que uma pessoa poderá ter mais de um núme-
ro de telefone. Costuma ser indicado colocando-se um asterisco precedendo o
nome do atributo;
• Atributo Determinante ou Chave Primária: identifica de forma única uma
entidade dentro do domínio e, portanto, não pode se repetir. Em um cadastro
de clientes, por exemplo, esse atributo poderia ser o CPF;
• Atributos Referenciais ou Chave Estrangeira: geralmente, estão ligados à
chave primária da outra entidade. Esses termos são bastante comuns no con-
texto de Bancos de Dados. Partindo do exemplo anterior, a entidade cliente
tem como chave primária seu CPF, assim, uma instância de venda possui
também um campo CPF do cliente, que se relaciona com o campo CPF da
entidade cliente.

A partir do exposto, pudemos perceber que a análise de atributos é parte im-

portante da análise e da modelagem de dados. A quantidade deles, tipo e outras
informações a seu respeito, geralmente, permitirão a construção de um Banco de
Dados com melhor performance.

Considerações, Limitações e Boas Práticas

Ao construirmos diagramas ER, devemos ter em mente os seguintes pontos:
• Os diagramas ER têm por objetivo a melhor visualização e o auxílio à compre-
ensão de relações. Logo, são utilizados apenas para dados relacionais;
• A menos que os dados sejam claramente delimitados em campos diferentes,
linhas ou colunas, os DER são de uso limitado quando estamos falando de
dados não estruturados, tais como os advindos de Mídia Social. O mesmo vale
para dados semiestruturados nos quais, muito provavelmente, somente alguns
terão utilidade;
• Devido ao uso de diferentes arquiteturas, o uso de modelos ER para a integra-
ção com Bancos de Dados previamente existentes pode ser dificultoso.

Já como boas práticas, temos os seguintes passos quando da conceptualização

e da construção de um DER:
• Finalidade e alcance: como primeiro passo, temos de definir a finalidade e o
alcance do que estamos analisando ou modelando;
• Entidades: temos de identificar as entidades envolvidas. Quando estiver pron-
to, comece a desenhá-las em retângulos (ou na forma adotada por seu sistema
de preferência) e rotulá-las como substantivos;
• Relacionamentos: determinamos como as entidades estão todas relacionadas.
Fazemos isso ao desenhar linhas entre elas para mostrar as relações e rotulá-las.
Algumas Entidades podem não estar relacionadas, e isso não é um problema;

15
15
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

• Atributos: acrescentamos, então, mais camadas de detalhes ao adicionar atri-

butos-chave de entidades. Como visto anteriormente, atributos são frequente-
mente apresentados como formas de elipses; 

• Cardinalidade: mostramos, então, se a relação é de um-para-um, um-para-
-muitos ou muitos-para-muitos.

Também de acordo com o abordado nas Unidades anteriores, é bom destacar os

seguintes pontos vistos até agora:
• Lembre-se de mostrar o nível de detalhe necessário para o seu propósito.
Você pode desenhar um modelo conceitual, lógico ou físico, dependendo dos
detalhes necessários;
• Fique atento à existência de entidades ou de relacionamentos redundantes em
seu projeto;
• Se estiver solucionando um problema de Banco de Dados, fique atento a falhas
quanto aos relacionamentos, ou entidades ou atributos ausentes;
• Certifique-se de que todas as suas entidades e os seus relacionamentos estão
devidamente rotulados;
• Você pode traduzir repetidas vezes tabelas relacionais e diagramas ER, se isso,
de algum modo, ajuda-lo a atingir seu objetivo;
• Certifique-se de que o diagrama ER suporta todos os dados que você pre-
cisa armazenar.

Ferramentas Case
Para auxílio no processo de análise de requisitos e modelagem, e nos últimos
tempos, até na programação e testes, têm-se utilizado bastante as ferramentas
CASE, do inglês, Computer-Aided Software Engineering; ferramentas para auxílio
nas mais variadas atividades em Engenharia de Software.

Mais especificamente, utilizado há décadas, o termo CASE aplica-se a ferramentas

que, literalmente, auxiliam o processo de desenvolvimento de software. Compila-
dores, editores estruturados, sistemas de controle de código fonte e ferramentas de
modelagem são alguns exemplos, ou seja, ferramentas cujo objetivo principal seja
permitir que o desenvolvedor trabalhe em um nível de abstração mais elevado, eli-
minando a preocupação com detalhes intrínsecos os ambientes de desenvolvimento.

Nos últimos anos, as ferramentas CASE têm evoluído em direções diferentes,

abrangendo desde a especificação de sistemas até a geração automática de códi-
go fonte.

16
 No tópico a seguir, é demonstrado como, a partir de uma ferramenta deste tipo,
o StarUML, software especializado para criação dos mais diversos diagramas da
UML), podemos construir diagramas ER para um exemplo, de forma rápida e faci-
litada, mostrando, passo a passo, como se dá a criação de nosso modelo de dados,
entidades, criação de colunas e relacionamentos, tendo em vista otimizar seu pro-
cesso de desenvolvimento de software.
Explor

StarUML disponível gratuitamente em: http://bit.ly/35FjoIy

Exemplo Prático
Como exemplo do uso do StarUML, suponha que temos de modelar um sistema
para um hotel, em que estamos interessados no sistema de reservas e de cobranças
de serviços ligados a essas reservas, assim como pode ser verificado na Figura 4 a
seguir, no qual se notam as informações que podem vir a ser utilizadas como parte
de nosso modelo de dados, nossas entidades, que vão ser modeladas como nossas
colunas, seus atributos e relacionamentos.

Rooms
Paciente
Room Number <PK>
Services

Room Type Service ID <PK>

Hotels Rates
Room location Service_name
Custumer_ID <FK> Service_code
Hotel ID <PK> Hotel_ID <FK>
Reservation
Zipcode
City
State Reservation Number <PK>
Phone Number Costumer ID <FK>
Billing
Hotel_Address Check in date
Sold Check out date
Billing # <PK>
Status
Room charge Guest_fname
Misc charge Guest_lname
Credit card No Costumer Room Type
Payment Date Number of guests
Costumer_ID <FK> Reservation date
Costumer ID <PK>
Reservation_Number <FK> Hotel_ID <FK>
Hotel_ID <FK> Last_Name Service ID <FK>
Phone number Roome Number <FK>
First_Name
City
State
Zip code

Figura 4 – Exemplo de diagrama ER a ser modelado na StarUML

17
17
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

Criando um Diagrama ER
A Figura 5, a seguir, ilustra os passos para a criação de um diagrama ER
entre entidades:
• Do seu lado direito, em Model Explorer, favor selecionar primeiro um elemen-
to em que um novo Diagrama de Entidade-Relacionamento possa ser contido
como filho;
• Selecione o modelo em Model |Add Diagram | ER Diagram na barra de
menus ou selecione Add Diagram | ER Diagram no menu de contexto.

Figura 5 – Exemplo de criação de diagrama ER na StarUML

Fonte: Acervo do Conteudista

Modelo de Dados
Para criar um Modelo de Dados (somente o elemento de modelo), via Menu:
• Selecionar um elemento em que o novo Modelo de Dados (Data Model) estará
contido;
• Selecionar Model |Add |Data Model na barra de menu ou Add |Data Model
no meu de contexto.

Entidade
Na Figura 6 ilustram-se os passos para criação de uma entidade, como descrito
a seguir.

Para criar uma entidade de maneira simples e rápida:

• Selecione Entidade na caixa de ferramentas (toolbox);
• Arraste no diagrama como se a ajustar o tamanho da Entidade.

18
 Para criar uma entidade (apenas o elemento de modelo) por meio do Menu:
• Selecione um Modelo de Dados em que uma nova Entidade seja contida;
• Selecione Model | Add | Entity na barra de menus ou Add | Entity no menu
de contexto.

Você também pode usar o QuickEdit for Entity clicando duas vezes ou pressio-
ne Enter em uma entidade selecionada:
• Name: Digite o nome;
• Add Note: adicione uma nota vinculada;
• Add Column (Ctrl + Enter): adiciona uma coluna;
• Add One to One: adicionando um relacionamento um a um com uma entidade;
• Ads One to Many: adicionando um relacionamento um a muitos com
uma entidade;
• Add Many to Many: adicionando um relacionamento muitos a muitos com
uma entidade.

Figura 6 – Exemplo de criação de diagrama ER na StarUML

Fonte: Acervo do Conteudista

Coluna
Na Figura 7, são ilustrados os seguintes passos para a criação de uma coluna,
como descrito a seguir.

Para criar uma coluna de maneira simples:

• Selecione uma Entidade;
• Select Model | Add | Column na barra de menus ou Add | Column no
menu de contexto.

Você pode usar o QuickEdit for Column clicando duas vezes ou pressionando
Enter em uma coluna selecionada.

19
19
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

• Column Expression: edita a expressão da coluna;

Sintaxe de expressão da coluna:
column :: = name [‘:’ tipo] [‘(‘ comprimento ‘)’]
nome :: = (identificador)
type :: = (identificador)
length :: = (string)
• Primary key (PK): verificando se a coluna é chave primária ou não;
• Add (Ctrl + Enter): adicione mais uma coluna abaixo;
• Exclude (Ctrl + Delete): exclua a coluna;
• Mover Up (Ctrl + Up): move a coluna para cima;
• Mover Down (Ctrl + Down): mova a coluna para baixo.

Figura 7 – Exemplo de criação de diagrama ER na StarUML

Fonte: Acervo do Conteudista

A partir daí, vamos construindo cada um dos elementos constituintes de nosso

Diagrama ER:

Hotels Rooms
PK Hotel Id int PK RoomNo int
Zipcode int Room Type Reservation
City string Rates
PK Res Number int
PhoneNo string Room Location
Costumer Id int
int Number of Beds
Check in Date
Costumer_ID int
Check out Date
Status
Number of Guests
Reservation
Room Number int

Billing Costumer Services

PK Billing Id int PK Costumer_ID int PK Service Id int
Room charge last Name Service Name
Misc charges phone Number Service Cost
Credit card no First_Name Res Number int
Payment date City
Custumer Id int State
Zip Code

Figura 8 – Exemplo de criação de diagrama ER na StarUML

20
Relacionamento
A partir do mesmo menu (toolbox) no qual interagimos com nossas Entidades,
agora podemos ir ajustando os Relacionamentos de acordo com o exemplo base,
como visto nas Figuras 9 e 10.

Para criar relacionamento:

• Selecione uma entre os diferentes tipos de relacionamentos, se One-to-One
Relationship (um para um), One-to-Many Relationship (um para muitos) ou
Many-to-Many Relationship (muitos para muitos);
• Também pode-se arrastar (drag) e trocar de entidade para entidade.

Você também pode usar o QuickEdit for Relationship ao clicar duas vezes ou
pressionando Enter em um relacionamento selecionado.
• Name: Digite o nome.
• Identifying: verifique se o relacionamento está identificando ou não.
• Add Note: adicione uma nota vinculada.
» Você também pode usar o QuickEdit para final do relacionamento clicando
duas vezes no lado final de um relacionamento.
• Nome: Digite o nome.
• Cardinalidade: selecione a cardinalidade do final do relacionamento selecionado.

Figura 9 – Exemplo de criação de diagrama ER na StarUML

Fonte: Acervo do Conteudista

21
21
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

Atividade
Agora, como atividade, suponha que queremos modelar um Sistema de Bibliote-
ca no qual estamos interessados numa aplicação de empréstimo de livros.

A Figura 10 mostra, então, o que poderia ser uma versão simplificada do esboço
de um DER referente a essa aplicação

1 n
Usuário Efetua Empréstimo

Contém

Livro

Pertence

1
Sessão

Figura 10 – Exemplo simplificado de DER para empréstimo de livros em uma Biblioteca

Fonte: Adaptado de Joel Rodrigues, Devmedia, 2014

A partir do exemplo, temos, então, os seguintes conceitos, vistos anteriormente:

• Entidades fortes: Usuário, Livro e Sessão a qual pertence determinado livro;
• Entidades fracas: Empréstimo;
• Relacionamentos: um Usuário pode efetuar vários Empréstimos. Tais Em-
préstimos podem conter vários Livros e vários Livros podem pertencer a uma
mesma Sessão.

Agora que conseguimos ter uma primeira versão de nosso diagrama, quais po-
deriam ser os atributos e outras entidades necessárias a serem adicionados para a
correta modelagem desse tipo de aplicação?

Tente usar ferramentas CASE como o StarUML que possui versão de avaliação gratuitamente,
Explor

disponível em: http://bit.ly/37PCDk7

Ou também o Astah para auxiliá-lo nessa tarefa, disponível em: http://bit.ly/2NcYzOa

22
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Leitura
Modelo de Entidade e Relacionamento – MER
http://bit.ly/2Tc8d7q
Entidade: Atributos simples, compostos e multivalorados
http://bit.ly/2uBxuOg
Relacionamento entre entidades: tipos e cardinalidade
http://bit.ly/2NcTIws
O que é um diagrama entidade relacionamento?
http://bit.ly/2KIvCZ2
Como fazer um diagrama entidade relacionamento
http://bit.ly/2FI2vlH
Guia Completo de Modelagem de Banco de Dados
http://bit.ly/307Ntzf
Cinco passos para criar uma cultura orientada por dados
http://bit.ly/2FC9Vaj
What is Entity Relationship Diagram (ERD)?
http://bit.ly/2FAfxld
Ferramentas CASE e qualidade dos dados: O paradigma da boa modelagem
http://bit.ly/2QFf0Vx

23
23
UNIDADE Modelo e Diagrama Entidade Relacionamento (MER e DER)

Referências
BOOCH, G.; RUMBAUGH, J; JACOBSON, I. The Unified Modeling Language
user guide. EUA: Addison-Wesley, 1997.

CHEN, P. The Entity-Relationship Model – Toward a Unified View of

Data. ACM Transactions on Database Systems. n. 1, v. 1, p. 9-6, 1976.

CHEN, P.  Suggested research directions for a new frontier: Active conceptual
modeling. ER 2006, v. 4215 of Lecture Notes in Computer Science, 1-4. Springer
Berlin/Heidelberg, 2006.

DE LIMA NETO, J. R. Modelo Entidade Relacionamento (MER) e Diagrama

Entidade Relacionamento (DER), 2014. Disponível em: <https://www.
devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-
relacionamento-der/14332>.

SOMMERVILLE, I. Engenharia de Software. 8 ed. São Paulo: Pearson Addison

Wesley, 2007.

STAR UML. Documentation, 2018. Disponível em: <https://docs.staruml.io/

working-with-diagrams/entity-relationship-diagram>.

TORLONE, R.  Conceptual Multidimensional Models. In: Maurizio Rafanelli

(ed.).  Multidimensional Databases: Problems and Solutions. Idea Group Inc
(IGI), 2003.

24