03_Modelo_e_Diagrama_Entidade_Relacionamento_(MER e DER)

Prévia do material em texto

Modelagem 
da Informação
Material Teórico
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.
• 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;
• Qualifi car 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 profi ssionais.
OBJETIVOS DE APRENDIZADO
Modelo e Diagrama Entidade 
Relacionamento (MER e DER)
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: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
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.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
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
9
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.
Ex
pl
or
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!
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.
Importante!
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, 
normalmente, no nível de funções ou sistemas específicos.Ex
pl
or
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
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
Nome ID_Estudante Vagas ID_Disciplina Nome ID_Professor
Registrado em Disciplina Lecionada por 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
11
Estudante
+ String: Nome
+ String: ID_Estudante
+ String: Nome
+ String: ID_Estudante
+ Int: Vagas
+ String: Nome
+ String: ID_Professor
Disciplina Professor
Figura 2 – Exemplo simplifi cado 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
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
13
Médico
n n
n
n
Prescrição
Paciente
Medicamento
Consulta
Figura 3 – Exemplo simplifi cado 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
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
15
• 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
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 sistemasaté a geração automática de códi-
go fonte.
16
17
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.
StarUML disponível gratuitamente em: http://bit.ly/35FjoIy
Ex
pl
or
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.
Paciente
Hotels
Hotel ID <PK>
Zipcode
City
State
Phone Number
Hotel_Address
Sold
Billing
Billing # <PK>
Room charge
Misc charge
Credit card No
Payment Date
Costumer_ID <FK>
Reservation_Number <FK>
Hotel_ID <FK>
Costumer
Costumer ID <PK>
Last_Name
Phone number
First_Name
City
State
Zip code
Reservation
Reservation Number <PK>
Costumer ID <FK>
Check in date
Check out date
Status
Guest_fname
Guest_lname
Room Type
Number of guests
Reservation date
Hotel_ID <FK>
Service ID <FK>
Roome Number <FK>
Services
Service ID <PK>
Service_name
Service_code
Rooms
Room Number <PK>
Room Type
Rates
Room location
Custumer_ID <FK>
Hotel_ID <FK>
Figura 4 – Exemplo de diagrama ER a ser modelado na StarUML
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
19
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
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
PK Hotel Id
Zipcode
City
PhoneNo
int
int
string
string
int
Rooms
PK RoomNo
Room Type
Rates
Room Location
Number of Beds
Costumer_ID
int
int
Reservation
PK Res Number
Costumer Id
Check in Date
Check out Date
Status
Number of Guests
Reservation
Room Number
int
int
int
Billing
PK Billing Id
Room charge
Misc charges
Credit card no
Payment date
Custumer Id
int
int
Costumer
PK Costumer_ID
last Name
phone Number
First_Name
City
State
Zip Code
int
Services
PK Service Id
Service Name
Service Cost
Res Number
int
int
Figura 8 – Exemplo de criação de diagrama ER na StarUML
20
21
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
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
Usuário
1 n
n
n
n
Contém
Empréstimo
Livro
1
Pertence
Sessão
Efetua
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, 
disponível em: http://bit.ly/37PCDk7
Ou também o Astah para auxiliá-lo nessa tarefa, disponível em: http://bit.ly/2NcYzOa
Ex
pl
or
22
23
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 multivaloradoshttp://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
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