Modelo conceitual DER

Prévia do material em texto

1 
 
Sumário 
1 Componentes do DER ............................................................................................................. 2 
1.1 Entidades ......................................................................................................................... 2 
1.2 Atributos .......................................................................................................................... 4 
1.2.1 Atributos monovalorados .......................................................................................... 5 
1.2.2 Atributo Multivalorado .............................................................................................. 5 
1.2.3 Atributo simples VS composto .................................................................................. 6 
1.3 Relacionamentos ............................................................................................................. 9 
1.3.1 Restrições em relacionamento (Cardinalidade) ...................................................... 11 
1.3.2 Relacionamento ternário ......................................................................................... 19 
1.3.3 Autorrelacionamento .............................................................................................. 20 
1.3.4 Atributos de relacionamento................................................................................... 21 
2 Exemplo prático assistência técnica ..................................................................................... 23 
 
 
 
Esse conteúdo foi retirado do material do professor Jean Rojas do IFMS/Corumbá e da sexta 
edição do livro de Carlos Alberto Heuser, obra intitulada Projeto de Banco de Dados. 
 
 
 
Diagrama Entidade Relacionamento: DER 
 
O Diagrama Entidade-Relacionamento (DER) é um modelo conceitual de alto nível, criado na 
década de 70, e que é empregado no desenvolvimento de projetos de aplicações que vão manipular 
Banco de Dados. Seu objetivo é o de facilitar a compreensão por parte do usuário, sendo visto como 
uma ferramenta útil durante o processo de projeto da base de dados, descartando detalhes de como os 
dados serão armazenados. 
A figura 2.1 apresenta uma solução proposta de modelagem de alto nível utilizando o DER para 
o estudo de caso EMPRESA apresentado no material da primeira semana. 
 
2 
 
 
1 Componentes do DER 
 
Um DER é composto pelos seguintes elementos: 
• Entidades: objeto do mundo real com identificação distinta e com um significado próprio. 
• Atributos: qualificadores de uma entidade (características que a descrevem). 
• Relacionamentos: dependência entre entidades associadas: quando um atributo de uma 
entidade se refere a outra. 
• Restrições em relacionamentos: limitam a possibilidade de combinações de entidades 
que podem participar do relacionamento (restrições estruturais). 
 
A seguir, analisaremos cada um deles com detalhes. 
 
1.1 Entidades 
No modelo ER a entidade é um dos conceitos-chave. Uma entidade representa um conjunto de 
objetos, sejam reais ou abstratos, que se deseja manter informações cadastradas. Ao falar sobre 
conjunto de dados, algumas pessoas com conhecimento em sistemas de banco de dados relacionais, 
 
3 
 
logo fazem referência a tabelas. Mas existe diferença entre tabelas e entidades, que será explicada na 
parte relacional. 
Graficamente, o jeito mais fácil de representar uma entidade é como mostra a figura abaixo: 
 
A entidade é Cliente e Maria Santos é uma ocorrência específica da entidade Cliente. 
Outros exemplos de entidades seriam: Carro, Fornecedor, Funcionário. Os nomes das entidades 
são sempre representados por substantivos concretos ou abstratos. Não é aconselhável colocar o nome 
no plural; por definição, uma entidade já é um conjunto. A definição de acentos no nome das entidades 
é opcional, como o modelo que estamos construindo é abstrato, não faz diferença, único detalhe é na 
hora da tradução para o modelo lógico, pois a maioria dos SGBDs não aceitam caracteres especiais no 
nome dos objetos. 
 
Uma entidade tem as seguintes características: 
• Representa uma classe de dados, onde suas instâncias (ocorrências) são a representação 
desses dados. 
• É representado por retângulos com nome em seu interior, sendo que o nome deve estar 
no singular, representando o conjunto (de instâncias). 
• Possui atributos qualificadores de uma entidade (características que a descrevem). 
 
 
Uma Entidade pode ser um objeto (livro), uma pessoa (empregado), abstrato (curso), 
acontecimento (inscrição). O nome depende do contexto (pessoa: Aluno, Professor, Segurado, 
Contribuinte, Empregado). 
 
4 
 
1.2 Atributos 
O atributo corresponde a um dado que é associado a cada ocorrência de uma entidade ou 
relacionamento. Eles são dados relacionados com aquela ocorrência específica no diagrama entidade 
relacionamento. 
 Os atributos são representados por pequenos círculos. Atributos são representados 
graficamente conforme ilustrado na figura abaixo: 
 
 
Na prática, muitas vezes os atributos não são representados graficamente para não 
sobrecarregar os diagramas, já que entidades podem possuir muitos atributos. Nesses casos é preferível 
o uso de representação textual. 
É importante ressaltar que toda entidade deve ter pelo menos um atributo, sendo que deve 
apresentar atributo identificador: 
• Valor sempre distinto para cada instância, caracterizando que não existem objetos 
repetidos; 
• Restrição de unicidade ou chave primária; 
• Não pode ser um valor nulo (vazio, desconhecido). 
 
 
 
5 
 
1.2.1 Atributos monovalorados 
 
Assim como nos relacionamentos existem cardinalidade, nos atributos elas também existem. O 
objetivo é dizer quantos valores daquele atributo podem estar em uma ocorrência da entidade ou 
relacionamento. 
 
Monovalorado opcional 
Veja o exemplo de atributo monovalorado opcional, cardinalidade (0,1): 
 
O atributo Complemento é monovalorado opcional, pois ele pode ou não ter valor, afinal, 
existem endereços que não têm complemento. 
 
Monovalorado obrigatório 
Quando não existe cardinalidade explícita ao lado do atributo, automaticamente entende-se que 
a cardinalidade dele é (1,1), ou seja, o atributo é monovalorado e obrigatório. Veja como ficaria o 
diagrama acima se a cardinalidade fosse expressa nos atributos monovalorado obrigatório: 
 
Como a maioria dos atributos mostrados no modelo entidade relacionamento são do tipo 
monovalorado obrigatório (Cardinalidade (1,1)), se fosse preciso exibir a cardinalidade deles, isso 
tornaria o diagrama visualmente mais poluído. 
 
1.2.2 Atributo Multivalorado 
 
Assim como os relacionamentos têm cardinalidade N, indicando que uma ocorrência pode se 
relacionar com várias outras ocorrências, os atributos também possuem a cardinalidade N para indicar 
que eles podem receber vários valores daquele atributo. Veja um exemplo de atributo multivalorado 
opcional: 
 
Uma ocorrência da entidade Contato pode ter no mínimo 0 telefone e, no máximo, N. Apesar de 
ser muito difícil, hoje em dia, uma pessoa não ter telefone, pode acontecer. Assim como existem pessoas 
que possuem vários números de telefone. 
 
6 
 
 
Atributo multivalorado obrigatório 
Além dos atributos multivalorados opcionais, existem os multivalorados obrigatórios. Veja: 
 
No caso do cadastro de um site, o usuário obrigatoriamente deve possuir, no mínimo, um e-mail; 
e, caso queira, pode cadastrar mais de um e-mail para contato. 
Assim como na área da programação, existe uma infinidade de regras de bons costumes como: 
manter a formatação do código e manter o padrão dos nomes das variáveis, classe e etc. No DER 
também existem os bons costumes. Assim como os relacionamentos ternários não são muito utilizados 
devido a alguns problemas, os atributos multivalorados também enfrentam um grande problema que 
os tornam questão de mau costume. Ao transformar o modelo do exemplo para relacional, na hora de 
implementar no banco, será precisoque ele tenha suporte para campos multivalorados ou array. Mas 
o grande problema é que alguns não têm essa funcionalidade e outros até têm, mas são difíceis de 
trabalhar. Então, ao invés de criar um atributo multivalorado, você deverá usar uma nova tabela. 
Veja o exemplo do Usuário, usando uma entidade adicional: 
 
O modelo acima, além de ser mais fácil de implementar nos SGBDs relacionais, possibilita 
adicionar mais detalhes sobre o e-mail, como Descrição. 
Agora vem a pergunta que não quer calar: Por que aprender sobre atributos multivalorados no 
curso? 
Porque na modelagem existem várias decisões que devem ser tomadas pelo modelador. Em 
último caso, você pode usar os atributos multivalorados como opção. Outra coisa que poderia acontecer 
é, em um projeto, ter um atributo multivalorado e você nem mesmo ter ideia do que significa. Então, 
durante o curso, será mostrado o máximo de elementos possíveis e porque devem ser usados ou não. 
 
1.2.3 Atributo simples VS composto 
 
Atributo Simples 
Todos os atributos mostrados até agora são considerados simples e conhecidos como atômicos 
(do grego átomo, que significa indivisível). Exemplo de atributos simples: 
 
7 
 
 
Pela lógica não faz sentido dividir o atributo login em duas partes. Por exemplo, para que dividir 
o login: Maria_2010 em duas partes? Não há necessidade alguma. A mesma coisa para os atributos 
senha e frase de segurança. 
 
Atributo Composto 
Agora pense no atributo endereço. O que compõe esse atributo? 
R: logradouro, número, complemento 
 
Pode-se criar um atributo composto Endereço, que contenha todos esses atributos. Veja o 
exemplo: 
 
Segundo a definição, um atributo composto é aquele que pode ser divido em partes menores. 
Veja outro exemplo: 
 
O atributo nome_completo foi separado em nome e sobrenome. O atributo end_completo foi 
separado em estado, cidade e bairro. O grande detalhe está no atributo end_rua, pois se trata de um 
atributo composto dentro de outro. Você pode criar quantos atributos compostos alinhados quiser, mas 
lembre-se que se deve manter os diagramas sempre os mais limpos possíveis. É desnecessário criar 
vários atributos se eles podem ser representados apenas no modelo relacional. 
 
Modelo equivalente 
No modelo entidade relacionamento quase sempre existem vários jeitos de representar um 
mesmo modelo, o que é chamado de equivalente. No caso dos atributos compostos não é diferente: 
pode ser feito um modelo equivalente colocando-se todos os atributos simples na própria entidade. 
Veja como fica a entidade Pessoa: 
 
8 
 
 
No capítulo de transformação entre modelos, você verá que os dois diagramas são equivalentes 
(geram o mesmo resultado). É opção do modelador escolher qual usar. 
 
Atributos Identificadores 
Conforme já mencionado, toda entidade tem sempre pelo menos um atributo. Quando o 
atributo permite distinguir uma ocorrência das demais ocorrências de uma mesma entidade, ele é 
considerado um especial conhecido como atributo identificador de entidade. 
Note, contudo, que um atributo identificador corresponde a um conjunto de um ou mais 
atributos ou relacionamentos. A figura abaixo apresenta um atributo concatenado, que é um atributo 
identificador composto por mais do que um atributo, nesse caso composto pelos atributos Nome e 
Número: 
 
Outro aspecto a ser observado é a característica do atributo identificador, que pode ser inerente 
à entidade ou dependente de uma entidade ou relacionamento externo. No primeiro caso, a entidade 
que possui um atributo identificador próprio é chamada de entidade primária ou entidade forte. Já 
quando a entidade não pode ser identificada somente através de seus próprios atributos, muitas vezes 
dependendo de um relacionamento para poder ser identificada, ela é chamada de entidade fraca, sendo 
representada por um retângulo com linha dupla conforme demonstrado na próxima figura. A seguir 
apresentamos alguns exemplos para ajudar a compreender esses conceitos. 
 
Entidade primária ou entidade forte: 
• Atributo próprio (CPF, número da placa); 
• Código atribuído pelo sistema (Número de Matrícula, Código de Fornecedor). 
 
Entidade fraca: 
• Um dependente, que precisa do nome do seu pai ou mãe. 
• Um item em uma Nota Fiscal, que precisa do número da Nota Fiscal e possivelmente o 
código do produto correspondente. 
 
9 
 
 
1.3 Relacionamentos 
 
Um Relacionamento é a representação de um conjunto de associações entre as ocorrências de 
entidades. Dessa forma, podemos representar as interações existentes no mundo real, que foram 
identificadas no processo de análise, entre as entidades. Em um DER, um relacionamento é 
representado por uma linha reta ligando as entidades relacionadas e, em geral, tem como nome um 
verbo que represente o contexto da relação em questão. A figura abaixo apresenta alguns exemplos de 
relacionamentos utilizando a notação original, onde o nome do relacionamento aparece dentro de um 
losango na interligação de suas respectivas entidades. 
 
 
Os relacionamentos são usados para manter o histórico das associações mantidas entre a 
ocorrência de uma entidade com outra ocorrência. 
Por exemplo, suponha que você queira saber quais os funcionários que trabalham em 
determinado projeto: 
 
• Funcionario armazena os objetos do tipo funcionário. 
• Projeto armazena os objetos do tipo projeto. 
• Trabalha armazena a relação entre os objetos do tipo funcionário e projeto. 
 
 
Graficamente, um exemplo desse relacionamento ficaria assim representado: 
 
10 
 
 
 
Veja algumas observações sobre a imagem acima: 
A função do relacionamento Trabalha é guardar os funcionários que trabalham em determinado 
projeto, como mostra o exemplo acima: 
• O funcionário 7 trabalha no projeto 1. 
• O funcionário 3 trabalha no projeto 4. 
• O funcionário 4 trabalha no projeto 3. 
 
Note que existem ocorrências de funcionarios que não trabalham em nenhum projeto: f1, f2, f5 
e f6; e existe o projeto p2 que não tem funcionário. Não há problema nisso. 
Ao abordar entidade, foi mostrado um exemplo sobre ocorrência de entidade, lembrando que 
ocorrência é um registro único da entidade. Os relacionamentos também possuem ocorrência de 
relacionamento. Veja a imagem abaixo: 
 
O par f7- p1 é uma ocorrência de relacionamento. Como mostra a imagem acima, f7 é uma 
ocorrência de funcionario e p1 é de projeto. 
Os relacionamentos geralmente representam a ação de uma entidade sobre outra. Por esse 
motivo, o nome dos relacionamentos preferencialmente deve ser verbo. 
 
 
11 
 
1.3.1 Restrições em relacionamento (Cardinalidade) 
No processo de modelagem é importante identificar não apenas as entidades e seus 
relacionamentos, mas também estabelecer a quantidade de ocorrências de cada um desses 
relacionamentos. A essa propriedade damos o nome de cardinalidade, que se desdobra em 
cardinalidade máxima e a cardinalidade mínima. 
 A cardinalidade tem como principal objetivo dizer ao modelo com quantas ocorrências da outra 
entidade, uma única ocorrência daquela entidade pode se relacionar. 
No Diagrama entidade relacionamento as cardinalidades são representadas por dois números, 
que ficam ao lado da entidade, sendo a primeira cardinalidade mínima e a segunda cardinalidade 
máxima. 
Veja alguns relacionamentos e suas cardinalidades: 
 
 
 
 
 
No início, pode parecer um tanto confuso, mas não se preocupe. Você irá entendendo ao 
acompanhar a explicação passo a passo. 
 
1.3.1.1 Cardinalidade máxima 
 
No DER existem as cardinalidades mínimas e máximas. A cardinalidade máxima, como o próprio 
nome indica, tem o objetivo de mostrar o máximo que uma ocorrência da entidade X pode se relacionar 
com a da entidade Y. 
 
 
12 
 
1.3.1.1.1 Relacionamento 1 para 1 
 
Aproveitando o exemplo usado até agora, funcionário projeto, veja a imagem abaixo: 
 
No caso acima, está indicado que um funcionário pode participar de, no máximo, um projeto; e 
um projeto pode ter, no máximo, um funcionário. Vejao gráfico abaixo: 
 
Nessa cardinalidade, um projeto não pode estar associado a mais de um funcionário, assim como 
um funcionário não pode estar em mais de um projeto. 
 
1.3.1.1.2 Relacionamento 1 para N 
 
Agora veja este outro exemplo: 
 
Nesse exemplo está indicado que um funcionário pode trabalhar em, no máximo, um projeto; e 
que em um projeto podem trabalhar, no máximo, dez funcionários. 
Parece estranho, mas no DER a cardinalidade de um elemento fica no lado oposto dele. Veja: 
 
Esse é o modo correto de ler um relacionamento. Com o tempo, isso fica tão natural que nem 
se percebe que os lados são trocados. 
 
 
13 
 
O exemplo acima contém um problema: no DER não existe cardinalidade máxima que indique 
o número exato de ocorrências que podem se relacionar, pois, para o banco de dados, é indiferente se 
vão se relacionar 2 funcionários para um projeto, 10, 100 ou 1000. Então, sempre que for mais de 1 será 
representado pela letra N. 
 
Ajustando, o diagrama acima ficaria assim: 
 
Agora, independente, se há 10 ou 1000 funcionários em um projeto, o diagrama cobrirá sem 
problema algum. 
 
Graficamente ficaria assim: 
 
Cada funcionário só pode trabalhar em um único projeto, mas um projeto pode ter vários 
funcionários. Lembrando que não existe problema se, em um projeto, trabalhar apenas um funcionário, 
como é o caso do p3. 
 
1.3.1.1.3 Relacionamento N para N 
 
Veja o gráfico abaixo: 
 
 
14 
 
Levando em conta a cardinalidade vista anteriormente 1 para N, esse gráfico estaria totalmente 
errado, pois o funcionário f3 trabalha no projeto p1 e ao mesmo tempo no p4. Segundo o diagrama, um 
funcionário poderia trabalhar em, no máximo, 1 projeto. Nessa parte entra a cardinalidade máxima N 
para N. 
Existem situações em que é necessário que a cardinalidade máxima de ambas as partes seja do 
tipo N. Veja o exemplo: 
 
Com o diagrama acima, o gráfico ficou correto. Agora um mesmo funcionário pode trabalhar em 
vários projetos, e um projeto pode ter vários funcionários. 
A cardinalidade é muito importante para o modelo de dados. Você aprenderá no andamento do 
curso, que ao transformar do modelo conceitual para o modelo lógico, se houver problemas nas 
cardinalidades, o modelo lógico poderá sair diferente do que se queria representar no modelo 
conceitual. 
 
Exemplos de cardinalidade máxima 
 
Primeiro exemplo 
 
Nesse exemplo um cliente pode ter no máximo um contrato e um contrato pode ter apenas um 
cliente. Vale relembrar que a cardinalidade é lida pelo lado oposto. O 1 ao lado do Contrato indica que 
um cliente pode ter no máximo um contrato; e o 1, ao lado de Cliente, indica que um contrato pode ter 
no máximo um cliente. 
 
Segundo exemplo 
 
Um aluno pode ter no máximo 1 curso; já um curso pode ter N alunos, ou seja, vários alunos. 
 
Terceiro exemplo 
 
 
15 
 
Um produto pode ter vários pedidos e um pedido pode ter vários produtos. 
 
1.3.1.2 Cardinalidade Mínima 
 
No diagrama entidade relacionamento, se deve expressar o número máximo que uma 
ocorrência de entidade pode se relacionar com outras ocorrências de entidade, como explicado no 
tópico anterior, além de indicar o mínimo que uma ocorrência de entidade pode se relacionar com outra 
ocorrência. 
As cardinalidades mínimas existentes são 0 e 1, sendo que 0 expressa relacionamento opcional 
e 1 expressa relacionamento obrigatório. 
 
1.3.1.2.1 Relacionamento opcional 
 
Os relacionamentos opcionais são indicados pela cardinalidade mínima 0. Nesse tipo de 
relacionamento podem existir ocorrências de entidade que não se relacionam com nenhuma outra 
ocorrência dentro daquele relacionamento. 
Veja o gráfico a seguir: 
 
Para expressar o gráfico acima, no modelo entidade relacionamento, ficaria assim: 
 
Note que esse relacionamento é opcional para os dois lados, pois tanto o projeto pode ter no 
mínimo 0 funcionário, como o funcionário pode trabalhar em no mínimo 0 projeto. Lembrando que no 
caso acima apenas as cardinalidades mínimas estão sendo mostradas. 
No fim deste capítulo você encontrará vários exemplos de relacionamentos completos com 
cardinalidade mínima e máxima. 
 
1.3.1.2.2 Relacionamento obrigatório 
 
O relacionamento obrigatório é representado pela cardinalidade mínima 1. Nesse tipo de 
relacionamento a entidade que for representada com cardinalidade 1 deve, obrigatoriamente, ter todas 
as ocorrências relacionadas. 
 
Obrigatório de um lado 
 
16 
 
No exemplo acima, as cardinalidades são opcionais para os dois lados. Suponha que você queira 
forçar todo projeto ter no mínimo 1 funcionário trabalhando. Veja como ficaria o diagrama: 
 
Agora todo projeto deve ter no mínimo 1 funcionário. Logo, o Projeto se tornou relacionamento 
obrigatório. 
Veja um gráfico válido para o diagrama acima: 
 
Obrigatório para ambos os lados 
Se, por algum motivo, for preciso que cada funcionário trabalhe, no mínimo, em um projeto, o 
diagrama ficaria assim: 
 
 
Veja o gráfico: 
 
 
O relacionamento 1 para 1 é obrigatório para os dois lados. Agora todo funcionário deve 
trabalhar em, no mínimo, 1 projeto; e um projeto deve ter, no mínimo, um funcionário trabalhando. 
Acompanhe alguns exemplos de gráficos errados para o relacionamento mínimo 1 para 1 
acima: 
 
17 
 
 
Os funcionários f1, f2, f5 e f6 não trabalham em nenhum projeto e, segundo o diagrama, eles 
deveriam trabalhar no mínimo em um. 
 
 
Nos projetos p2 e p5 não trabalha nenhum funcionário, sendo que o mínimo deveria ser um 
funcionário por projeto. 
 
O caso acima está errado tanto nos relacionamentos das ocorrências da entidade Funcionário 
quanto de Projeto, pois todas as ocorrências devem se relacionar com, no mínimo, uma instância da 
outra entidade. 
 
Exemplos de relacionamentos 
Para fixar os conceitos de relacionamentos e cardinalidade, acompanhe alguns exemplos básicos. 
Ao final dos tópicos de relacionamento será demonstrado um exemplo completo. 
 
Primeiro exemplo: 
 
18 
 
 
No exemplo acima: 
• Um cliente pode ter no mínimo 0 contrato e no máximo 1 contrato. 
• Um contrato pode ter no mínimo 1 cliente e no máximo 1 cliente. 
• Todo contrato deve ter um cliente associado a ele, pois um contrato sem cliente perde o 
sentido. 
• O cliente pode ser atendido pela empresa, mesmo sem ter contrato, mas não pode ter 
mais de um contrato. 
 
Segundo exemplo: 
 
No exemplo acima: 
• Um produto pode ter no mínimo 0 pedido e no máximo N pedidos. 
• Um pedido deve ter no mínimo 1 produto e no máximo N produtos. 
• O produto pode existir sem nunca ter sido vendido em um pedido. Por isso sua 
cardinalidade mínima é 0. Um mesmo produto pode estar em vários pedidos diferentes, 
por isso a cardinalidade máxima é N. 
• Um pedido sem produto não tem significado. Então, a cardinalidade mínima dele é 1. 
Assim, obrigatoriamente todo pedido deve ter no mínimo um produto. Não existe limite 
de produtos em um pedido, podendo ter N produtos no mesmo pedido. Por isso a 
cardinalidade máxima dele é N. 
 
Terceiro exemplo: 
 
No exemplo acima: 
• Um curso pode ter no mínimo 1 aluno e no máximo N alunos. 
• Um aluno pode fazer no mínimo 1 curso e no máximo 1 curso. 
• Todo curso deve ter pelo menos 1 aluno na turma, pois não faz sentido o professor 
ministrar um curso sem alunos. Por isso a cardinalidade mínima é 1. Em um curso é 
 
19 
 
possível ter vários alunos. No DER, mais de um é expresso como N; a cardinalidade 
máxima dele é N. 
• Em diversas faculdades públicas existem situações em que 1 aluno só pode fazer um 
curso por vez. Nesse caso, a cardinalidade máxima dele é 1. Também não faz sentido 
manter um aluno no cadastro se ele não faz nenhum curso, por isso a cardinalidade 
mínima dele é 1. 
 
1.3.2 Relacionamento ternário 
 
No DER (diagrama entidade relacionamento) podem existir relacionamentos com grau maior 
que dois. Esses relacionamentos podem ser ternários, quaternários etc. Seu uso não é muito comum, 
mas é bom você conhecê-los e saber que existem. 
Exemplo derelacionamento ternário: 
 
Em um relacionamento binário as cardinalidades estão sempre ligadas ao quanto uma 
ocorrência de entidade pode se relacionar com a ocorrência da outra entidade. Já no relacionamento 
ternário, um par de ocorrências é que está relacionada à outra entidade. 
Exemplo: Em um relacionamento chamado Locação, há as entidades Projeto, Funcionário e 
Função. Você deve pensar do seguinte modo: “um par Funcionário Função pode estar alocado em 
quantos projetos?”. 
 
Veja como fica o diagrama: 
 
• Um funcionário e uma função podem participar de, no mínimo, 0 projeto; e no máximo 
N projetos. 
• Uma função em um projeto pode ser usada por, no mínimo, 0 funcionário; e no máximo 
N funcionários. 
 
20 
 
• Um funcionário em um projeto pode exercer, no mínimo, 0 função; e no máximo N 
funções. 
 
Veja o exemplo de gráfico do relacionamento acima: 
 
 
Nesse gráfico estão 3 ocorrências de relacionamento. Porém, ao invés de ser um par de 
referências, é um trio. 
O relacionamento ternário não é muito utilizado, pois é possível fazer modelos equivalentes e 
mais simples de entender com relacionamentos binários. Modelos equivalentes serão demonstrados 
no decorrer do curso. 
 
1.3.3 Autorrelacionamento 
 
Existem relacionamentos entre duas entidades diferentes (binários); existem relacionamentos 
entre três entidades (ternários); e existem também relacionamentos entre ocorrências da mesma 
entidade, chamados autorrelacionamento, ou relacionamento recursivo, como trazem algumas 
bibliografias. 
Uma ocorrência da entidade exerce uma ação sobre outra ocorrência da mesma entidade. Veja 
o exemplo de diagrama: 
 
 
Um exemplo usando casamento pode ser meio traumático, para alguns. Porém, para fins 
didáticos, ele atende perfeitamente. Uma pessoa pode ser casada ou solteira. Então, a cardinalidade 
 
21 
 
mínima deve ser opcional. Por outro lado, uma pessoa não pode ser casada com duas pessoas ao 
mesmo tempo – pelo menos é isso que está previsto em lei – então, a cardinalidade máxima será um. 
Note que, no autorrelacionamento, uma ocorrência de entidade exerce uma ação sobre outra 
ocorrência da mesma entidade. No caso do exemplo, um é marido e a outra, esposa. 
Veja um possível gráfico de ocorrências para o diagrama acima: 
 
 
No gráfico, estão três ocorrências do relacionamento Casamento e apenas um sortudo, o p7, 
que é o único solteiro do gráfico. 
1.3.4 Atributos de relacionamento 
 
Os atributos são propriedades de uma ocorrência de entidade ou relacionamento, cujo objetivo 
é tornar a ocorrência particular, com características próprias. Até agora, todos os atributos 
demonstrados estavam ligados às entidades. Mas existem casos em que um atributo não pode ser de 
responsabilidade de nenhuma entidade. 
Veja o exemplo abaixo: 
 
Primeiro relembre como ler um atributo: 
• Um paciente pode estar em, no mínimo, 0 consultas; e, no máximo, em N consultas. 
• Um médico pode realizar, no mínimo, 0 consultas; e, no máximo, N consultas. 
 
Até aqui tudo perfeito. Dispõe-se das informações do paciente e das informações do médico. 
Mas o histórico de data e hora das consultas deve ser salvo no banco de dados. Onde colocar esses 
atributos? Primeiro, os atributos Data e Hora foram inseridos em Paciente, como mostra a imagem: 
 
22 
 
 
Com os atributos data e hora na entidade Paciente, não é possível mais considerar as 
cardinalidades expressas do diagrama, pois como a data e hora da consulta estão fixadas no paciente, 
ele só poderá participar de uma consulta. Quando ele for realizar outra consulta você deverá apagar o 
campo data e hora e gravar novamente, perdendo assim o histórico da primeira consulta. 
Se tirar os atributos da entidade Paciente e colocá-los na entidade Médico, ocorrerá o mesmo 
problema. O único modo de resolver a questão do diagrama acima, sem criar uma entidade chamada 
consulta, é fixar os atributos data e hora diretamente no relacionamento consulta. 
Veja como fica: 
 
Agora sim, um médico pode ter consultas marcadas em horários diferentes com vários pacientes, 
assim como um paciente pode ter várias consultas marcadas com diferentes médicos, todas em horários 
distintos. 
 
Gráfico do relacionamento 
 
 
Modelo equivalente 
O diagrama acima do Médico e Paciente pode ser reescrito de forma equivalente, sem usar 
atributos de relacionamento. Veja este diagrama: 
 
23 
 
 
Note que o relacionamento foi substituído por uma entidade. Leia os relacionamentos e você 
verá que eles produzem o mesmo resultado. 
 
 
2 Exemplo prático assistência técnica 
 
Você chegou ao fim dos tópicos sobre relacionamento. Faça um exercício de modelagem de 
dados simples. Tente primeiro fazer sozinho, e só depois olhe a correção. 
 
O problema: Sr. Mário é uma pessoa, que deseja manter informações sobre seu negócio. Ele 
possui uma assistência técnica especializada em computadores, notebook, impressoras, monitores etc. 
A primeira coisa que ele deseja saber é quais são os equipamentos que entram para manutenção, em 
sua empresa. Toda vez que um cliente traz um equipamento até a assistência técnica do Sr. Mário, deve 
ser aberta uma ordem de serviço, mesmo que o equipamento já esteja cadastrado. Outro problema 
existente é quanto ao histórico do técnico que fez a manutenção em determinado equipamento. Sr. 
Mário também deseja manter um cadastro de clientes para futuros contatos e coisas do tipo. 
Crie um modelo de dados baseado na descrição acima. 
 
MER (Modelo entidade relacionamento) 
 
 
24 
 
Discussão sobre o modelo: 
Relacionamento Equipamento, Ordem de Serviço 
• Um equipamento pode estar, no mínimo, em uma ordem de serviço; e, no máximo, em 
N ordens de serviço. 
• Uma ordem de serviço pode ter, no mínimo, um equipamento; e, no máximo, 1 
equipamento. 
• Segundo a descrição do problema, sempre que um equipamento der entrada deve-se 
abrir uma nova ordem de serviço para ele; isso torna o relacionamento obrigatório 
(cardinalidade mínima 1). Um equipamento pode ser trazido à empresa para conserto e 
funcionar durante meses sem apresentar nenhum problema, mas depois de certo tempo 
voltar a dar problemas. Ao invés de ser preciso cadastrá-lo novamente no sistema, será 
possível apenas abrir uma ordem de serviço para ele. Logo, um mesmo equipamento 
pode estar em N ordens de serviço. 
• Por questão de regra de negócios, uma ordem de serviço deve ter apenas um 
equipamento associado a ela, o que torna um relacionamento obrigatório (cardinalidade 
mínima um, e cardinalidade máxima um). Seria possível considerar que uma ordem de 
serviço pudesse ter vários equipamentos. Como o texto não diz nada a respeito disso, 
fica a critério de quem fizer a modelagem. 
 
Relacionamento Cliente, Ordem de Serviço 
• Um cliente pode ter, no mínimo, 0 ordem de serviço; e, no máximo, N ordens de serviço. 
• Uma ordem de serviço pode ter, no mínimo, um cliente; e, no máximo, um cliente. 
• O texto sobre a descrição do cadastro de cliente não especifica se, para um cliente existir, 
é necessário que ele tenha ao menos uma ordem de serviço associada a ele. Por esse 
motivo, a cardinalidade mínima dele é zero; se no texto estivesse dizendo que para um 
cliente existir obrigatoriamente deve ter no mínimo uma ordem de serviço, aí sim seria 
preciso tornar a cardinalidade mínima um. Mas, como está implícita, a decisão pode ser 
tomada baseando-se no que se tem como melhor exemplo, e pensando no que mudaria 
se trocasse a cardinalidade, e nisso chegar à melhor opção. Um cliente pode trazer vários 
equipamentos para manutenção. Sendo assim, ele pode ter várias ordens de serviço, o 
que justifica a cardinalidade máxima N. 
• Toda ordem de serviço obrigatoriamente deve ter um cliente associado a ela. Caso 
contrário, ela perde seu significado; e deve ter, no máximo, um cliente. Em uma ordem 
de serviço com dois clientes, não se saberia ao certo o dono do equipamento. 
 
Relacionamento Técnico, Ordem de Serviço 
• Um técnico pode estar no mínimo,em 0 ordem de serviço; e, no máximo, em N ordens 
de serviço. 
• Uma ordem de serviço deve ter no mínimo um técnico e no máximo um técnico. 
• O texto não diz, em nenhum momento, que para um técnico existir é necessário que ele 
já tenha resolvido alguma ordem de serviço. Então, é possível supor que mesmo sem 
nenhuma ordem de serviço, o técnico pode existir. Logo, é um relacionamento opcional 
(cardinalidade mínima zero). Um técnico é pago para arrumar vários equipamentos, e 
cada ordem de serviço está relacionada a um equipamento. Assim, a cardinalidade 
máxima é N. 
 
25 
 
• Como no caso do relacionamento entre Cliente e Ordem de serviço, toda ordem de 
serviço obrigatoriamente deve ter um cliente relacionado, nesse relacionamento toda 
ordem de serviço também deve ter, no mínimo, um técnico relacionado para poder 
manter o histórico. Na cardinalidade máxima não se pode deixar que mais de um técnico 
seja associado a uma mesma ordem de serviço, pois isso tornaria mais difícil saber quem 
realmente fez a manutenção no equipamento daquela ordem de serviço. 
 
Esse é um clássico exercício de modelagem de dados. Existem outros semelhantes a ele. Por 
mais que pareça apenas um exemplo sem utilidade, ele traz vários elementos do mundo real que 
ajudam a pensar como construir um modelo entidade relacionamento. Exercícios assim, apenas com 
descrição textual, estão sujeitos a várias interpretações. Uma mesma descrição pode ser modelada de 
vários modos diferentes. 
Você deve ter estranhado o fato de os relacionamentos não possuírem nomes. No DER os nomes 
dos relacionamentos não são obrigatórios, ficando a cargo do modelador colocá-los ou não.