Modelagem de Dados: Projeto de Banco de Dados

Prévia do material em texto

Antonio Cesar de Barros Munari 1
 
Capítulo 2: Modelagem de dados 
A definição do conteúdo que devemos armazenar no banco de dados é chamada de "projeto 
do banco de dados" e constitui-se numa tarefa das mais importantes e complexas de todo o 
processo de desenvolvimento de um sistema informatizado. Sua importância está ligada a dois 
fatores principais: o conteúdo da base de dados interessa potencialmente a todos os módulos 
do sistema e um defeito de projeto nesse aspecto será notado em diversas partes da aplicação; 
além disso, como o banco de dados representa um certo tipo de infra-estrutura do sistema, já 
que é sobre ele que as funcionalidades mais importantes são construídas, uma correção na sua 
estrutura pode requerer também a modificação de diversos programas, dependendo do tipo de 
problema detectado. A complexidade, por sua vez, está ligada à natureza das decisões 
tomadas pelos projetistas, que basicamente precisam capturar os aspectos importantes da 
realidade que precisam ser representados no sistema. Um sistema informatizado deve ser visto 
como um modelo, uma representação simplificada do mundo real, simulando os aspectos 
relevantes de uma área, chamada algumas vezes de mini-mundo, universo de discurso ou, 
ainda, de domínio do problema. Essa tentativa de captura da realidade, realidade essa que é 
naturalmente complexa e dinâmica, coloca para o projetista um grande número de questões de 
interpretação e julgamento, que devem ser respondidas adequadamente para que o sistema a 
ser desenvolvido tenha sucesso. Assim, conseguir gerar uma representação que seja, ao 
mesmo tempo, satisfatoriamente simples mas também fiel à realidade é a árdua tarefa dos 
projetistas, que para isso valem-se de diversas técnicas desenvolvidas e refinadas ao longo dos 
anos. 
O projeto de um sistema requer a modelagem tanto dos dados como dos processos 
(atividades) envolvidos no domínio do problema e o grau de separação que se faz entre dado e 
processo nesse contexto é um dos aspectos geralmente utilizados para caracterizar cada 
técnica de modelagem: há técnicas que tratam os dados mais isoladamente dos processos, 
como o fazem as abordagens estruturadas convencionais, e outras que os abordam mais 
conjuntamente, como ocorre tipicamente no paradigma orientado a objetos. Este capítulo, que 
inicia o tratamento de questões mais específicas sobre o projeto de banco de dados, apresenta 
inicialmente uma discussão sobre os diversos níveis de detalhe empregados durante a 
modelagem e define alguns conceitos correlatos da área de bancos de dados; em seguida faz 
uma breve explanação sobre as principais técnicas de modelagem de alto nível e, por fim, 
discorre mais detalhadamente sobre uma delas, chamada de técnica ou abordagem Entidade / 
Relacionamento, que é de grande emprego na criação de bancos de dados relacionais e que 
possui um foco maior nos dados que nos processos. 
2.1 Níveis de abstração da realidade 
A utilização de computadores nas tarefas do dia a dia de uma organização requer um alto grau 
de sistematização das atividades e a identificação de uma série de elementos-chave para o 
bom andamento dos negócios. A modelagem é um processo que ocorre em níveis diferentes 
de abstração, contemplando desde a visão geral dos negócios (num ponto de vista macro, 
onde participam representantes de todas as áreas gerenciais e usuários finais) até os detalhes 
de uma parte específica do conjunto, numa visão em nível de subsistema. O trabalho de 
análise e modelagem de um sistema requer do analista a capacidade de enxergar determinados 
elementos em diversos níveis de detalhe, ora mais genéricos, ora mais específicos. A título de 
ilustração, seria como se em alguns momentos, devêssemos conseguir visualizar toda a 
floresta de um parque e, em outros, enxergar apenas uma de suas árvores em particular. A 
figura 2.1 procura representar essa hierarquia de níveis de detalhe segundo a percepção da 
área de bancos de dados. 
Antonio Cesar de Barros Munari 2
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.1: Relação entre os 3 níveis de abstração em um projeto de banco de dados. 
Um modelo em um nível mais alto de abstração pode dar origem a mais de uma representação 
no nível imediatamente abaixo. Por exemplo: o modelo conceitual de um negócio poderia ser 
implementado no nível lógico utilizando a abordagem relacional ou a orientada a objetos, que 
são duas alternativas para solucionar o mesmo tipo de problema. Um mesmo modelo lógico 
poderia ter uma determinada tabela mantida com seus dados fisicamente ordenados ou não-
ordenados no disco ou, ainda, poderia ser armazenada na forma de uma estrutura hash, ou 
seja, vários arranjos físicos para o mesmo objeto lógico. De uma forma simplificada podemos 
dizer que o modelo conceitual tenta responder à pergunta “O quê devemos armazenar no 
banco de dados?”, o modelo lógico tenta responder à questão “Como devemos armazenar o 
que precisamos no banco de dados?” e o modelo físico tenta descrever com ainda mais 
detalhes à questão tratada pelo modelo lógico. O modelo físico é importante ao tratarmos de 
questões envolvendo o desempenho geral das operações de consulta e manutenção sobre o 
banco de dados, que são situações em que a análise apenas do modelo lógico seria insuficiente 
para qualquer trabalho mais produtivo. 
Em geral utilizamos o termo Modelagem de Dados para a etapa que tem por objetivo produzir 
o modelo conceitual, que procura definir o contexto dos dados em que os diversos sistemas da 
empresa funcionam. A geração do modelo lógico costuma ser chamada de Projeto Lógico e a 
definição do modelo físico seria então o Projeto Físico, embora muitas definições importantes 
sobre o esquema físico sejam feitas posteriormente, aos poucos, ao se ajustar o desempenho 
das aplicações durante o ciclo de vida do sistema. 
O modelo conceitual, que é o objeto de estudo deste capítulo, deve ser o mais fiel possível à 
realidade e, além disso, possuir uma característica adicional muito importante: as suas 
especificações não devem implicar em nenhuma implementação lógica ou física em 
particular. Tudo aquilo que for proposto nesse modelo deve ocorrer em alto nível de 
abstração, nos termos das regras de negócio daquele mini-mundo, de maneira a não viciar a 
análise pela restrição do ponto de vista da equipe de analistas. Os detalhes lógicos e físicos 
são introduzidos naturalmente nas etapas seguintes do processo. 
Realidade 
(mini-mundo)
Alto nível 
de abstração
Baixo nível 
de abstração
Modelo conceitual 
(coisas, objetos, entidades, 
relacionamentos, etc)
Modelo lógico 
(tabelas, tipos de dados, 
regras de nomes, etc)
Modelo físico 
(arquivos, páginas em disco, 
índices, etc) 
Hardware / software 
(implementação) 
Antonio Cesar de Barros Munari 3
 
2.2 Levantamento de requisitos 
O ponto de partida para o desenvolvimento dos sistemas de informação em uma empresa são 
algumas definições elaboradas em um nível corporativo, que servem como pedras 
fundamentais para orientar as atividades de todos os setores da organização. São definições 
estratégicas e restrições, voluntárias ou não, relacionadas às políticas adotadas na condução 
dos negócios, à legislação vigente e às próprias características do ramo de atividade em si. 
Exemplos típicos de tais definições seriam o levantamento das personagens, eventos e 
procedimentos envolvidos com o dia a dia da organização; as características particulares a 
cada um desses elementos; os relacionamentos existentes entre eles; os detalhes da legislação 
que se aplica à área; os objetivos finais da organização; suas prioridades, etc. Essas são as 
chamadas regras de negócio, e é com base nelas que se torna possível o detalhamento das 
informações necessárias ao desempenho das atividades normais de cada setor de uma 
organização. A tarefa delevantamento, documentação, estruturação e análise das regras de 
negócio e dos dados correspondentes constitui uma etapa crucial de qualquer projeto de 
desenvolvimento de sistemas e, na área da Engenharia de Software, recebe o nome de 
Levantamento (ou Extração) de Requisitos. 
Existem diversos paradigmas de engenharia de software, tais como os chamados clássico, 
evolutivo e espiral, que determinam quais atividades devem ser realizadas durante o 
desenvolvimento de um sistema, bem como a seqüência em que devem ser executadas. Em 
praticamente todos eles existe uma etapa inicial de levantamento de requisitos, cujos 
resultados são decisivos para todo o restante do trabalho de desenvolvimento e que procura 
identificar 3 tipos de elementos: 
a) requisitos funcionais, que captam o que deve ser realizado pelo sistema, e que são o 
alvo da modelagem de dados; 
b) requisitos não-funcionais, que indicam aspectos de confiabilidade, precisão, 
desempenho e outras restrições gerais impostas ao sistema; 
c) requisitos de desenvolvimento e manutenção, que envolvem aspectos de teste e 
planejamento de manutenções. 
O produto desta etapa é um documento formal que deve ter a aprovação do usuário final e que 
será então utilizado pela equipe de desenvolvimento para planejar, estimar custos, 
desenvolver e testar o produto final solicitado. Para que tenha valor prático, além de ser 
correta e precisa, a especificação de requisitos deve ser elaborada em um vocabulário que seja 
compreensível pela comunidade de usuários finais, incorporando a terminologia própria da 
área coberta pelo sistema. Além disso é importante que as especificações geradas nesse 
documento sejam independentes de qualquer aspecto ligado à tecnologia de implementação, 
pois além de nesse momento ser prematuro determinar qualquer coisa nesse sentido, há o 
risco adicional de que algumas restrições tecnológicas venham a limitar artificialmente as 
alternativas possíveis para os problemas a serem tratados nas fases seguintes do processo. 
Podemos estruturar o processo de extração de requisitos em 4 etapas: 
a) compreensão do domínio do problema, onde a equipe encarregada do problema deve 
procurar se informar ampla e profundamente sobre os principais aspectos da área em 
estudo; 
b) extração e análise dos requisitos, em que os requisitos são identificados, organizados e 
priorizados; 
c) especificação dos requisitos, que é o registro formal dos mesmos em alguma 
linguagem escrita ou gráfica; 
Antonio Cesar de Barros Munari 4
 
d) validação dos requisitos, onde se procura atestar a completeza e correção dos 
requisitos identificados. 
As principais técnicas informais utilizadas para o levantamento de requisitos são: a entrevista 
com os usuários finais e patrocinadores do projeto, a análise de documentos e a aplicação de 
questionários. Como exemplos de técnicas formais temos a modelagem conceitual e a 
prototipação. 
2.3 Técnicas de modelagem de dados 
É muito importante que exista uma metodologia simples, precisa e eficiente para a 
representação dos objetos modelados pelo analista e que também seja de fácil transposição 
para o esquema lógico dos diversos modelos de SGBD disponíveis. Em 1976 foi lançada pelo 
professor Peter Chen a metodologia chamada de "Entidade-Relacionamento" (CHEN, 1990), 
muito utilizada desde então para fins de representação de modelos de dados, que podem 
posteriormente ser implementados em SGBDs de várias filosofias diferentes tais como 
relacionais, objeto-relacionais, etc. Posteriormente, com a continuidade dos estudos na área de 
modelagem, novos conceitos e técnicas foram acrescentados àqueles propostos inicialmente 
por Chen, originando-se aquilo que se convencionou chamar de modelo Entidade / 
Relacionamento Estendido. 
As principais características da técnica de modelagem Entidade / Relacionamento são: 
a) foi concebida visando preservar a independência de dados e de SGBD; 
b) permite a representação gráfica formal do modelo de dados produzido durante a 
modelagem, através de diagramas (chamados diagramas E/R); 
c) incentiva no analista a preocupação com a semântica (ou seja, o significado) dos 
relacionamentos entre as entidades, levando assim a uma melhor compreensão da 
realidade; 
d) devido à sua relativa simplicidade e seu alto nível de abstração, é ideal para a 
comunicação com usuários leigos, e também 
e) permite a construção de modelos mais estáveis. 
2.4 Técnica de modelagem Entidade / Relacionamento 
Conceitos básicos 
A abordagem Entidade / Relacionamento define alguns conceitos fundamentais, que devem 
ser utilizados pelo analista para a correta identificação das características dos dados alvo da 
análise e tampouco a determinação dos critérios mais adequados para a sua organização. A 
seguir, uma rápida exposição dos conceitos e do vocabulário fundamentais relacionados à 
modelagem de dados. 
Entidades 
Correspondem a quaisquer "coisas" do mundo real sobre as quais se deseja armazenar 
informações. São exemplos típicos de entidades: pessoas (físicas ou jurídicas, tais como 
funcionário, empresa, fornecedor e cliente); objetos (materiais ou abstratos, como produto, 
veículo, disciplina e projeto) e eventos (como pedido, viagem, empréstimo e venda), 
principalmente. Nos diagramas Entidade/Relacionamento as entidades são representadas por 
meio de um retângulo contendo ao centro o seu nome, que deve ser um substantivo no 
singular. 
Uma entidade geralmente apresenta várias manifestações dela mesma. Por exemplo, a 
entidade FUNCIONÁRIO representa cada um dos funcionários da empresa, e não apenas um 
Antonio Cesar de Barros Munari 5
 
deles; a entidade PRODUTO representa todos os produtos com os quais a empresa trabalha, 
etc. Dizemos então que uma entidade possui ocorrências ou instâncias, e cada um dos 
funcionários descritos pela entidade FUNCIONÁRIO é uma de suas manifestações, ou 
ocorrências, ou instâncias1. 
Atributos de Entidades 
Dada uma entidade que seja de nosso interesse, precisaremos manter suas informações mais 
relevantes, de maneira que possamos descrevê-la com precisão sempre que necessário. 
Chamamos de Atributos (ou propriedades) a esse conjunto de informações que descrevem as 
particularidades de uma entidade e é importantíssimo que durante a modelagem 
identifiquemos todos os atributos requeridos para o funcionamento adequado dos processos 
de negócio. Dessa forma, os atributos de um funcionário poderiam ser o seu Nome, Número 
de Matrícula, Cargo, Sexo, Data de Admissão, Salário, etc. Analogamente, os atributos de um 
produto seriam o seu Código, Descrição, Tamanho, Unidade de Medida, Quantidade 
Disponível, etc. 
É conveniente identificar, dentro do conjunto de atributos correspondente a uma entidade, 
aquele que permite identificar, sem ambigüidades, cada uma de suas ocorrências. Esse 
atributo, cujo valor não se repete e é sempre conhecido, recebe o nome de atributo 
identificador. Por exemplo, Número de Matrícula (do funcionário) e Código (do produto) 
podem ser bons atributos identificadores para as entidades Funcionário e Produto, 
respectivamente, assim como Sigla do Estado é adequado para uma entidade Unidades da 
Federação. Muitas vezes o atributo identificador é um dado artificial, como os diversos 
códigos criados pelo analista ou pela organização para referenciar ocorrências de 
determinadas entidades. É possível também a adoção de identificadores compostos por mais 
de um atributo, para situações em que nenhum atributo individualmente consegue atender aos 
requisitos de um identificador, sendo que nesse caso o valor que não se repete é aquele 
referente à combinação dos atributos selecionados. 
A notação original para representar atributos em um diagrama E/R é uma pequena elipse ou 
círculo contendo o nome do atributo e que é ligada à sua respectiva entidade ou 
relacionamento através deuma linha contínua, conforme mostrado na figura 2.2. O atributo 
identificador é representado por meio de algum tipo de ênfase como, por exemplo, um 
sombreado ou sublinhado. 
 
 
 
 
 
 
Figura 2.2: Alguns atributos da entidade Funcionário indicados na notação clássica. 
Essa notação é, entretanto, pouco prática na maioria das vezes, pois os diagramas tendem a 
ser extensos, com dezenas de entidades e inúmeros atributos, o que tende a torná-los muito 
complexos em termos visuais. Notações alternativas mais simplificadas são então adotadas e 
uma das mais utilizadas é a apresentada na figura 2.3, onde o atributo apresentado em negrito 
é o identificador. 
 
1 Alguns autores, por outro lado, utilizam o termo “conjunto de entidades” para expressar o conceito de entidade 
e, nesse caso, utilizam o termo “entidade” para indicar cada uma de suas ocorrências ou instâncias. 
 
FUNCIONÁRIO 
Matrícula 
Nome Sexo 
Data Adm. 
Antonio Cesar de Barros Munari 
 
 
 
 
 
Figura 2.3: Alguns atributos da entidade Funcionário indicados em uma notação mais prática. 
Em alguns momentos, quando não estamos interessados nos detalhes sobre os atributos, 
podemos simplificar os diagramas apresentando apenas as entidades e os relacionamentos, 
sem qualquer atributo, ou ainda, mantendo apenas o atributo identificador de cada entidade 
ou, então, indicando apenas um pequeno subconjunto de seus atributos mais importantes e 
representativos. 
Relacionamentos 
No mundo real uma entidade muito raramente apresenta-se isolada, tendo existência 
completamente independente de quaisquer outras. Geralmente ocorre o contrário: é detectada 
a existência de uma associação entre as ocorrências de duas entidades distintas. A essa 
conexão lógica entre duas ou mais entidades damos o nome de relacionamento, que é 
representado em um diagrama Entidade/Relacionamento por meio de uma linha unindo as 
entidades associadas, contendo ainda um losango com o nome do relacionamento ao centro. 
Os nomes dos relacionamentos são importantes porque permitem expressar com clareza a 
natureza da ligação modelada entre as entidades em questão. Dizemos que diagramas como o 
DER tentam2 expressar modelos semânticos, ou seja, modelos onde há uma grande 
preocupação com o significado das coisas que estão sendo modeladas, e por isso faz sentido 
dizer que “lemos” um diagrama Entidade/Relacionamento. Recomenda-se, então, que os 
nomes dos relacionamentos sejam significativos (o termo técnico usado para isso é 
mnemônico3), devendo ser compostos por verbos flexionados, ou seja, verbos que não estão 
no infinitivo. Por exemplo, deve-se usar o termo “possui” ou “possuído”, em vez de 
“possuir”; “compõe” ou “composto”, em vez de “compor”; “faz” ou “feito” em vez de 
“fazer”, etc. O uso de verbos flexionados torna mais natural a leitura dos diagramas. 
Um exemplo clássico de relacionamento seria aquele existente entre Funcionário e 
Departamento dentro de uma empresa: uma ocorrência da entidade Funcionário deverá 
sempre estar associada a uma ocorrência da entidade Departamento. Poderíamos inclusive 
batizar de "Pertence" à associação entre essas duas entidades, visto que um funcionário 
sempre "pertence" a um departamento. 
Esquematicamente: 
 
 
Figura 2.4: Exemplo de relacionamento entre duas entidades. 
Ao lermos da esquerda para a direita o pequeno modelo E/R da figura 2.4 temos a frase 
“Funcionário pertence departamento”, que dá uma clara idéia da ligação observada entre as 
duas entidades. Se tentarmos ler o diagrama da direita para a esquerda, teríamos a frase 
“Departamento pertence funcionário”, que já não é uma afirmação tão feliz. Por esse motivo, 
é possível atribuir mais de um nome a um relacionamento, de maneira a permitir uma leitura 
 
2 Há alguma controvérsia sobre se os modelos Entidade/Relacionamento são realmente modelos semânticos. 
Muitos autores concordam com essa afirmação, mas outros, como Setzer[2005], argumentam que tais modelos 
são apenas sintáticos, e que o significado (a se pelo analista que o projetou ou que o utiliza. 
3 O termo significa “que auxilia a memória” s a variáveis, arquivos e rotinas de maneira a 
indicar o propósito ou significado desses objet
 
FUNCIONÁRIO 
 
DEPARTAMENTO 
 
Pertence 
FUNCIONÁRIO 
Matrícula 
Nome 
Sexo 
Data Adm. 
mântica) é atribuído
. Nomes atribuído
6
os são considerados mnemônicos. 
Antonio Cesar de Barros Munari 7
 
adequada conforme cada uma das possíveis direções utilizadas pelo leitor. Um exemplo dessa 
prática é encontrado na figura 2.5, onde o relacionamento é chamado de “pertence” para 
quando fazemos a leitura da esquerda para a direita e “pertencente” para quando a leitura 
ocorrer no sentido contrário, formando nesse caso a frase “Departamento pertencente 
funcionário”, que é equivalente a “Funcionário pertence departamento”. 
 
 
Figura 2.5: Exemplo de relacionamento com dois nomes. 
Um relacionamento possui sempre uma característica básica chamada cardinalidade ou 
multiplicidade. A cardinalidade de um relacionamento consiste na especificação do grau da 
associação entre as entidades envolvidas, indicando quantas ocorrências de cada entidade 
participam de uma instância do relacionamento. Por exemplo, um funcionário pertence 
sempre a no máximo um departamento, ou seja, para uma ocorrência específica da entidade 
Funcionário pode existir apenas uma ocorrência da entidade Departamento associada. Por 
outro lado, para um determinado departamento é possível que existam vários funcionários 
relacionados: mais de uma ocorrência da entidade Funcionário refere-se à mesma ocorrência 
da entidade Departamento. Dizemos nesse caso que a cardinalidade máxima do 
relacionamento "Pertence" é de 1:N ("um para ene" ou "um para muitos"). Na figura 2.6 
observamos a indicação da cardinalidade máxima do relacionamento “pertence”, e ao 
fazermos a leitura do diagrama no sentido da esquerda para a direita, temos “Um funcionário 
pertence a no máximo 1 departamento” e, lendo da direita para a esquerda, temos “A um 
departamento pertencem no máximo N funcionários”. 
 
 
 
Figura 2.6: Cardinalidade máxima do relacionamento “pertence”. 
Os relacionamentos de cardinalidade 1:N são clássicos, pois representam a maioria das 
situações encontradas no desenvolvimento de sistemas comerciais. Contudo, existem também 
relacionamentos que apresentam outras cardinalidades e que, do ponto de vista estritamente 
teórico, são considerados como variantes do modelo 1:N fundamental. 
O primeiro deles é o relacionamento de cardinalidade 1:1 ("um para um"). Um exemplo seria 
aquele existente entre GERENTE e DEPARTAMENTO, onde um gerente pode responder por 
apenas um departamento e um departamento só pode ser gerenciado por um único gerente. 
Esquematicamente: 
 
 
Figura 2.7: Exemplo de relacionamento de cardinalidade máxima 1 para 1. 
Apesar de existirem no mundo real situações que sugerem cardinalidades 1:1, devemos 
sempre desconfiar de tais relacionamentos, questionando-nos se na realidade as duas 
entidades envolvidas não são uma só. Uma forma de analisar essa possibilidade consiste em 
verificar se o principal identificador da primeira entidade é diferente do principal identificador 
da segunda entidade. Caso não o sejam, muito provavelmente estamos interpretando dois 
aspectos de uma mesma entidade como sendo entidades distintas. 
Existem também os relacionamentos de cardinalidade N:N ou N:M ("muitos para muitos"). 
São aqueles em que uma ocorrência da entidade "A" pode ter ligação com mais de uma 
ocorrência da entidade "B" e vice-versa. Um exemplo de relacionamento N:N típico ocorre 
 
FUNCIONÁRIO 
 
DEPARTAMENTO 
Pertence 
Pertencente 
 
FUNCIONÁRIO 
 
DEPARTAMENTO 
 
PertenceN 1
 
GERENTE 
 
DEPARTAMENTO 
 
Gerencia 
1 1
Antonio Cesar de Barros Munari 8
 
entre as entidades PRODUTO e FABRICANTE, quando um Fabricante pode fornecer mais 
de um Produto e um Produto pode ser fornecido por mais de um Fabricante, como mostra a 
figura 2.8. 
 
 
Figura 2.8: Exemplo de relacionamento de cardinalidade máxima N para N. 
A correta identificação da cardinalidade de um relacionamento é muito importante para a 
modelagem de dados, pois obriga o analista a questionar objetivamente suas fontes de 
informação, aumentando seu grau de conhecimento da realidade que está sendo modelada. 
Também permite prever com maior segurança as possibilidades de sucesso da representação 
adotada no modelo. Finalmente, caso a implementação do banco de dados seja feita 
posteriormente utilizando o paradigma relacional, as cardinalidades máximas terão um papel 
importante a desempenhar na definição das vinculações entre as tabelas por meio das chaves 
estrangeiras. 
Além da cardinalidade máxima existe também o conceito de cardinalidade mínima para um 
relacionamento, que indica se este é obrigatório ou não. Para determinar a cardinalidade 
mínima de um relacionamento entre as entidades “A” e “B”, precisamos responder às 
seguintes perguntas: uma ocorrência da entidade A está associada com no mínimo quantas 
ocorrências da entidade B? Uma ocorrência da entidade B está associada com no mínimo 
quantas ocorrências da entidade A? Em ambos os casos a resposta deverá ser zero ou um. 
Uma cardinalidade mínima zero indica que pode existir uma ocorrência de uma entidade que 
não se relaciona com ninguém da entidade oposta. Uma cardinalidade mínima 1 indica que 
para cada ocorrência da entidade deve existir sempre alguém correspondente na outra 
entidade que participa do relacionamento. A idéia ficará mais clara se retomarmos o exemplo 
anterior do relacionamento entre Funcionário e Departamento: considere que pelas normas da 
empresa, não pode existir um Funcionário sem Departamento, mas pode, eventualmente, 
existir um Departamento sem Funcionário (como por exemplo na situação em que um novo 
Departamento foi criado mas nenhum Funcionário foi ainda alocado a ele). Temos então um 
caso em que o relacionamento “pertence” é obrigatório para os membros da entidade 
Funcionário, mas é opcional para os membros da entidade Departamento. Fazendo as 
perguntas certas temos: uma ocorrência da entidade Funcionário está associada com no 
mínimo quantas ocorrências da entidade Departamento? A resposta é 1. Uma ocorrência da 
entidade Departamento está associada com no mínimo quantas ocorrências da entidade 
Funcionário? A resposta é zero. A figura 2.9 representa essa situação. 
 
 
 
Figura 2.9: Cardinalidades máxima e mínima do relacionamento “pertence”. 
Além da forma utilizada até aqui para indicar as cardinalidades de um relacionamento, 
existem diversas outras notações empregadas pelas ferramentas de modelagem. Uma das 
notações mais comuns é a da chamada Engenharia da Informação, que utiliza símbolos 
gráficos nas extremidades das linhas dos relacionamentos para indicar a cardinalidade, como 
mostra a figura 2.10. Um símbolo especial, parecido com um garfo ou tridente, chamado de 
pé-de-galinha, indica uma cardinalidade máxima N, a falta de um pé-de-galinha indica 
cardinalidade máxima 1. A existência de uma bolinha indica cardinalidade mínima zero, a 
ausência dessa bolinha indica cardinalidade mínima 1. 
 
PRODUTO 
 
FABRICANTE 
 
Fornecido 
N N
 
FUNCIONÁRIO 
 
DEPARTAMENTO 
 
Pertence 
N:0 1:1
Antonio Cesar de Barros Munari 9
 
 
 
 
 
 
 
 
Figura 2.10: Notação de cardinalidade segundo a Engenharia da Informação. 
Atributos de Relacionamentos 
A exemplo do que ocorre com as entidades, alguns relacionamentos podem possuir atributos, 
uma vez que é possível que existam informações que não se refiram particularmente a 
nenhuma das entidades envolvidas, mas apenas à associação entre elas. Como exemplo dessa 
possibilidade temos, para o relacionamento “Fornece” mencionado anteriormente, os atributos 
Marca do Produto, Tamanho do Lote Mínimo, Preço, etc, que variam em função de cada 
combinação Produto / Fabricante mapeada por “Fornece”. A notação para os atributos dos 
relacionamentos é a mesma que é usada para os atributos das entidades, conforme pode ser 
observado na figura 2.11. 
 
 
 
 
 
 
 
 
 
Figura 2.11: Exemplo da indicação de atributos de entidades e relacionamentos. 
Relacionamentos reflexivos (Auto-Relacionamentos) 
Ao trabalharmos situações e componentes do dia-a-dia de uma organização, poderemos 
encontrar casos em que elementos de uma mesma entidade relacionam-se entre si devido ao 
fato de apresentarem uma estrutura de natureza hierárquica. São exemplos clássicos a 
modelagem de estrutura de produtos e a representação de hierarquias de pessoal, que 
abordaremos com mais detalhes neste material. 
Hierarquia de pessoal 
Suponha a existência de uma empresa estruturada em células funcionais compostas por 
conjuntos de funcionários. Alguns funcionários são supervisores de outros funcionários, 
conforme podemos verificar no quadro apresentado na figura 2.12: 
 
Fornecido 
N N
Marca 
Tam. Lote
Preço 
 
PRODUTO 
Código Descrição 
 
FABRICANTE 
Código Nome Telefone
 
 
a) Máximo N e Mínimo 1 
 
 
c) Máximo 1 e Mínimo 1 
 
 
d) Máximo 1 e Mínimo 0 
 
 
b) Máximo N e Mínimo 0 
Antonio Cesar de Barros Munari 10
 
 
Nome Cargo Depto Supervisor 
João Silva Pedreiro D01 Roberto Rodrigues 
Roberto Rodrigues Porteiro D01 Não tem 
Ivo Pereira Pedreiro D03 Cláudio Silva 
Joel Nepomuceno Desenhista D02 Júlia Santos 
Cláudio Silva Contador D03 Não tem 
André Paiva Gerente D03 Não tem 
Júlia Santos Projetista D02 Não tem 
Ricardo Alves Porteiro D02 Júlia Santos 
Ana Garcia Escriturário D03 Cláudio Silva 
Sílvio Coelho Desenhista D03 André Paiva 
Figura 2.12: Detalhes sobre os funcionários de uma empresa. 
Concluímos que existem ocorrências da entidade Funcionário que se relacionam com outras 
ocorrências dessa mesma entidade. Na última coluna do quadro exibido na figura 2.12 está 
indicado o nome do Supervisor correspondente àquele Funcionário. Portanto, nessa 
modalidade de relacionamento entre dois funcionários um deles sempre desempenha o papel 
de Supervisor. Um Supervisor pode supervisionar um ou mais funcionários; um Funcionário 
pode ter zero ou um Supervisor. Isso caracteriza um relacionamento chamado de reflexivo na 
entidade Funcionário, que pode ser representado no modelo E/R conforme mostra a figura 
2.13. 
 
 
 
 
 
 
Figura 2.13: Exemplo de relacionamento reflexivo entre funcionários. 
Para implementar o relacionamento reflexivo, levamos em conta a sua cardinalidade, que é 
determinada de forma semelhante aos outros tipos de relacionamento e, no nosso exemplo, a 
cardinalidade máxima é de 1 para N pois um Funcionário pode ter no máximo 1 Supervisor; 
um Supervisor pode ter no máximo N Funcionários. A cardinalidade mínima é obtida de 
maneira semelhante, e verificamos que o relacionamento “supervisiona” é opcional nos dois 
sentidos: pode haver um Funcionário que não supervisiona nenhum outro Funcionário e 
também pode haver um Funcionário que não é supervisionado por nenhum outro Funcionário. 
Estrutura de produto 
O quadro indicado na figura 2.14 representa uma parte dos produtos comercializados por uma 
empresa do setor de montagem, manutenção e venda de equipamentos de informática. 
Observe que existem produtos básicos (como a placa de fax, o disco rígido e o pente de 
memória) que não se decompõem em partes menores (pelo menos do ponto de vista da 
empresa que os comercializa). Por outro lado, alguns dos produtos oferecidos constituem 
aquilo que podemos chamar de produtoscompostos, uma vez que são o resultado da 
combinação de um determinado conjunto de outros produtos (como por exemplo o 
computador CompStation XXX Pro e o kit multimídia). Verificamos ainda que um produto 
composto pode entrar na composição de um outro produto, como é o caso do kit multimídia, 
que é componente do computador CompStation XXX Pro. 
 
FUNCIONÁRIO 
1:0
N:0
Supervisiona
Antonio Cesar de Barros Munari 11
 
Supondo que seja necessário armazenarmos informações referentes aos produtos em estoque, 
precisaremos representar convenientemente a estrutura de cada produto em nosso modelo, de 
modo que algumas consultas essenciais sejam possíveis, como por exemplo: 
a) quais os componentes de um dado produto? 
b) de quais produtos compostos um produto é componente? 
c) dado o custo unitário de cada componente, qual o preço de custo total de um produto 
composto? 
Produto Composição 
CompStation XXX Pro (1) Processador Pentium IV 3.2 GHz 
(2) Pente memória RAM 512MB DDR400 
(1) Monitor 17” SVGA dot pitch 0.2 Samsung 
(1) Placa de vídeo GeForce FX6200, 256MB DDR2 
(1) HD Seagate 80Gb 7200rpm SATA II 
(1) Kit multimídia XPTO 
(1) Placa fax-modem 56.600 bps 
(1) Teclado padrão 104 teclas 
(1) Mouse 2 botões padrão Microsoft 
(1) Gabinete K-MEX preto 
Placa fax modem 56.600 bps 
Kit multimídia XPTO (1) Placa de som SoundBlaster 16 bits XXXXX 
(1) Unidade de CD-ROM Toshiba 52x 
(2) Caixa de som estéreo JBL 
HD Seagate 80Gb 7200rpm SATA II 
Pente memória RAM 512MB DDR400 
...etc... 
Figura 2.14: Detalhes sobre alguns produtos comercializados por uma empresa. 
Com isso, podemos resumir a situação da seguinte forma: existem ocorrências da entidade 
Produto que se relacionam com outras ocorrências dessa mesma entidade. E mais: num 
relacionamento entre dois produtos, um deles desempenha o papel de Composto e o outro, o 
papel de Componente. Um produto pode ser componente de zero ou mais produtos; um 
produto pode ser composto por zero ou mais componentes. A exemplo do que ocorreu no caso 
da hierarquia de funcionários, temos aqui um caso de relacionamento reflexivo na entidade 
Produto, que pode ser representado no modelo E/R conforme ilustrado na figura 2.15, onde 
pode-se observar, inclusive, que o atributo referente à quantidade de cada componente no 
produto composto final é mapeado como pertencendo ao relacionamento. 
 
 
 
 
 
 
 
 
 
Figura 2.15: Exemplo de relacionamento reflexivo entre produtos. 
Assim, como pôde ser observado nos dois exemplos anteriores, existem relacionamentos 
reflexivos (auto-relacionamentos) de quaisquer cardinalidades, inclusive N:N. 
 
N:0
N:0
Composto
Qtde do 
Componente 
 
PRODUTO 
Código Descrição 
Antonio Cesar de Barros Munari 12
 
Dicas práticas para modelagem 
Obs.: Este material foi retirado (com algumas adaptações) da apostila do curso de modelagem 
de dados da RCM-SP. 
A primeira etapa da modelagem de dados consiste no que denominamos Análise de Entidades 
e Relacionamentos. Esta etapa constitui-se de uma fase na qual determinaremos quais as 
entidades que interessam ao modelo parcial de necessidade da empresa que estamos 
enfocando. Esta análise e definição pode ser baseada no modelo conceitual obtido após as 
entrevistas e análise de documentos. 
Passo 1: Reconhecer as ENTIDADES 
Ao analisarmos o contexto, deveremos ter em mente uma forma de pensar E/R. Logo, algo 
que não requeira pelo menos 2 atributos para descrevê-lo, provavelmente não caracterizará 
uma entidade e sim um atributo de alguma outra entidade, ou será simplesmente uma variável 
do contexto. É importante estabelecermos alguns princípios para que obtenhamos (a partir dos 
levantamentos e entrevistas com os usuários) as entidades de interesse para a aplicação que 
está em projeto. O usuário sempre se refere a processo. Pense e lembre que o modelo de dados 
não é fluxograma, logo não tem começo nem fim. Esteja atento para referências a 
substantivos, pois pode ser a indicação de uma entidade. 
Algumas perguntas úteis: 
� Que coisas são trabalhadas? 
� O que pode ser identificado por número, código? 
� Tem atributos? Esses atributos são relevantes, pertinentes? 
� Essa coisa pode assumir a forma de uma tabela? 
� É um documento externo (recibo, fatura, nota fiscal)? Se sim, é forte candidato a 
entidade. 
� Tem significado próprio? 
� Qual a entidade principal do contexto? 
Dicas: 
� Substantivos que não possuem atributos podem ser atributos de outras entidades. 
� Adjetivos colocados pelos usuários indicam normalmente atributos de uma entidade. 
� Verbos indicam prováveis relacionamentos. 
� Advérbios temporais indicam prováveis atributos de um relacionamento. 
� Procure sempre visualizar qual é a entidade principal do contexto sob análise. 
� Entidades cujo nome termine por “ento” ou por “ão” geralmente são procedimentos. 
Passo 2: Reconhecer os RELACIONAMENTOS 
Após termos obtido e identificado as entidades que compõem o contexto de aplicativo que 
estamos projetando, a próxima etapa consiste na definição dos relacionamentos que existem 
entre as entidades e que interessam aos nossos propósitos. No momento em que obtivermos o 
domínio dos relacionamentos e entidades, poderemos traçar um primeiro diagrama E/R que 
nos servirá de base para as etapas seguintes. 
Perguntas: 
� O relacionamento é necessário? 
� Ele é útil? 
An
 
� É redundante? 
� Se redundante, retirar? 
� Qual a sua finalidade? (Documentar) 
Dicas: 
� Verbos indicam possíveis relacionamentos. 
Ob des e 
tão nto a 
pre e no 
mo
Pa
Um
pro
est
da
va
da
Qu
de
ex
tam
dis
Ex
A 
atr
uti
do
co
rel
Es
A 
po
ou
aq
fig
 
 
 
Te
é c
em
de
� Analisar as entidades aos pares. 
serva-se que neste ponto ainda não determinamos quais atributos compõem as entida
 pouco os eventuais atributos dos relacionamentos. Também não existe neste mome
ocupação de que estejam realmente diferenciados os relacionamentos e sua validad
tonio Cesar de Barros Munari 13
mento, mas formam a base para as etapas seguintes. 
sso 3: Definir os ATRIBUTOS 
a vez montado o diagrama Entidade/Relacionamento, devemos então identificar as 
priedades das entidades e dos relacionamentos que são de interesse para a aplicação que 
amos desenvolvendo. Numa primeira etapa, vamos apenas associar os atributos conhecidos 
s entidades e dos relacionamentos já delineados. Nesse processo vamos muitas vezes 
lermo-nos da Análise de Relacionamentos e das considerações de variação temporal dos 
dos no sistema. 
estione sempre se o usuário tem interesse e condições de manter o atributo por ele 
finido. Sempre que for definido um atributo, devemos documentar o porquê de sua 
istência, assim como os valores limite de seu domínio e suas restrições. É muito importante 
bém considerar os atributos similares, ou seja, atributos de mesmo nome em entidades 
tintas e que possuem significados diferentes. 
tensões ao modelo E-R 
esta altura já temos um razoável conhecimento sobre entidades, relacionamentos e 
ibutos. Exercitamos também a identificação desses elementos em situações típicas e 
lizamos o mapeamento da cardinalidade dos relacionamentos para aprofundar e 
cumentar melhor nossa compreensão de um determinado tema. Assim, estamos agora em 
ndição de tratar alguns tópicos complementares da modelagem de dados, referentes a 
acionamentos reflexivos, especialização e agregação. 
pecialização (Tipo / Subtipo) 
modelagem de dados algumas vezes coloca diante de nós a situação em que uma entidade 
ssui um conjunto de atributos básicos, comuns a todas as suas ocorrências e também dois 
 mais subconjuntos de atributos que se aplicam a apenas algumas delas. Um caso típico é 
uele em que necessitamos guardar os seguintes dados sobre Clientes, comoos mostrados na 
ura 2.16. 
Figura 2.16: Exemplo de alguns possíveis atributos para a entidade Cliente. 
mos na figura 2.16 três conjuntos de dados distintos: aquele marcado com sublinhado, que 
omum a todos os clientes; os escritos em itálico, que dizem respeito a clientes que são 
presas (pessoas jurídicas) e os restantes, exclusivos dos clientes pessoas físicas. Um 
terminado cliente terá seus dados para todos os atributos sublinhados e também para um 
Código Nome CNPJ CPF RG 
Inscr. Estadual Endereço Telefone comercial Telefone residencial 
Data Nascimento Contato Comercial Sexo Endereço p/ entrega 
Profissão Ramo de atividade Situação de Crédito Data Última Compra 
Antonio Cesar de Barros Munari 14
 
dos outros dois grupos restantes, conforme seja o seu tipo. Para casos como esse devemos 
aplicar o conceito de especialização, ilustrado na figura 2.17. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.17: Representação da entidade Cliente utilizando especialização. 
Observe que representamos a situação através de 3 entidades (Cliente, Pessoa Física e Pessoa 
Jurídica) e que existe um relacionamento especial entre elas, indicado através de um triângulo 
que funciona como uma espécie de bifurcação. Essa é a representação clássica para uma 
especialização, que também é chamada de relacionamento Tipo / Subtipo. Na entidade Cliente 
estão os atributos comuns a todos os clientes (aqueles que estavam sublinhados na relação 
inicial) e as entidades especiais Pessoa Física e Pessoa Jurídica possuem apenas os atributos 
exclusivos de seu tipo. A entidade Cliente pode participar de outros relacionamentos 
normalmente, bem como também podemos relacionar Pessoa Física ou Pessoa Jurídica com 
quaisquer outras entidades, caso seja necessário, conforme ilustrado no exemplo da figura 
2.18. 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.18: Estrutura de dados com especialização e relacionamentos. 
O diagrama da figura 2.18 representa a situação em que qualquer Cliente pode fazer um 
Pedido, independentemente de ser uma pessoa física ou jurídica. Entretanto, apenas os 
clientes da variedade "Pessoa Física" pertencem a algum Ramo de Atividade. Portanto, 
dizemos que Pessoa Física e Pessoa Jurídica são espécies (ou tipos) de Cliente. Em algumas 
CLIENTE 
Código 
Nome 
Endereço 
Telefone Comercial 
Endereço p/ entrega 
Situação de crédito 
Data última compra 
PESSOA FÍSICA 
CPF 
RG 
Tel. Residencial 
Data de Nascimento 
Sexo 
Profissão 
PESSOA JURÍDICA 
CNPJ 
Inscr. Estadual 
Contato Comercial 
Ramo de atividade 
 
CLIENTE 
PESSOA 
 FÍSICA 
PESSOA 
JURÍDICA
 
PEDIDO Feito 
Faz 
RAMO 
ATIVIDADE 
Pertence 
Pertencente 
Antonio Cesar de Barros Munari 15
 
obras sobre modelagem de dados é comum chamar esse tipo de relacionamento de 
relacionamento É-UM (ou, em inglês, IS-A), pois podemos ler o modelo dizendo que Pessoa 
Física É UM Cliente, por exemplo. 
Agregação 
O modelo Entidade/Relacionamento, proposto por Peter Chen na década de 70, sofreu 
posteriormente algumas adaptações e extensões, que visaram torná-lo mais completo e 
abrangente. Uma dessas extensões foi o conceito de agregação, introduzido para viabilizar a 
modelagem de algumas situações típicas envolvendo relacionamentos de cardinalidade N:N. 
Veja o exemplo a seguir: 
Um determinado órgão público de planejamento possui alguns escritórios regionais 
estrategicamente distribuídos pelo interior do estado de São Paulo, de maneira a facilitar o 
suporte aos inúmeros projetos desenvolvidos por seus funcionários. Tipicamente os 
funcionários são alocados a projetos (muitas vezes simultâneos) que atingem várias regiões e 
tornam-se relativamente comuns situações em que um funcionário ou equipe desempenha 
algumas tarefas numa determinada região contando com os recursos locais do escritório mais 
próximo. Para isso, basta requisitar com antecedência os equipamentos necessários ao projeto. 
Como existem vários projetos em andamento ao mesmo tempo, com freqüência ocorre que 
um dado recurso seja alocado por mais de um funcionário, para projetos diferentes. 
Suponha agora que existem dois funcionários “A” e “B”, alocados a projetos distintos. “A” 
está alocado aos projetos 1 (“Levantamento cadastral de propriedades rurais”) e 2 (“Resumo 
estatístico da produção agrícola”), enquanto que o funcionário “B” está alocado aos projetos 3 
(“Censo agropecuário estadual”) e 2. Para o projeto 1 o funcionário “A” alocou um 
determinado veículo e um equipamento Notebook disponíveis no escritório de uma região. O 
funcionário “B” por sua vez, alocou o mesmo veículo para o projeto 3. Considere que, em 
princípio, não deveremos ter problemas ligados ao compartilhamento do automóvel pelos dois 
funcionários, visto que o projeto 3 depende da conclusão do projeto 1. Observe que são 
válidas portanto as seguintes afirmações: 
a) um funcionário pode estar alocado a mais de um projeto; 
b) um projeto pode ser desenvolvido por mais de um funcionário; 
c) um funcionário pode ou não requisitar um recurso para utilização num projeto; 
d) um recurso pode ser utilizado por mais de um funcionário, geralmente em projetos 
diferentes. 
Graficamente, podemos representar o relacionamento entre Funcionário e Projeto da seguinte 
forma: 
 
 
 
Figura 2.19: Relacionamento entre Funcionário e Projeto. 
Para associarmos um Recurso a um Funcionário, devemos levar em conta que é importante 
que esteja disponível a informação referente também ao Projeto para o qual o Recurso será 
utilizado. Dessa forma, não devemos relacionar Recurso nem unicamente a Funcionário, nem 
unicamente a Projeto, mas a ambos. Em termos mais práticos, seria o caso de associarmos a 
entidade Recurso ao relacionamento Alocado. Entretanto, o modelo Entidade/Relacionamento 
não permite esse tipo de ligação direta com um relacionamento com atributos. Assim, 
utilizamos uma agregação para representar essa situação, conforme ilustrado na figura 2.20. 
 
FUNCIONÁRIO 
 
PROJETO 
N NAlocado
Antonio Cesar de Barros Munari 16
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.20: Representação de uma agregação utilizando a notação clássica. 
O retângulo maior que envolve Funcionário/Alocado/Projeto tem a finalidade de representar 
que estamos enxergando esse conjunto de informações como se fosse uma entidade só, 
relacionada com Recurso através do relacionamento Requisita. Na prática, continuamos 
vinculando Recurso às informações proporcionadas pelo relacionamento Alocado: apenas a 
maneira de representar isso é que é um pouco diferente. Em algumas obras sobre modelagem 
de dados uma agregação pode ser representada de uma outra maneira: 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.21: Uma representação alternativa para a mesma agregação da figura 2.20. 
Observe que na representação da figura 2.21 fica mais evidente a ligação com o 
relacionamento Alocado. Outro dado importante é que neste exemplo, independentemente da 
notação adotada para representá-lo no diagrama Entidade / Relacionamento, a cardinalidade 
do relacionamento “Requisita” é irrelevante. Resumindo: utilizamos agregações para 
representar situações que envolvem relacionamentos independentes onde um dos lados é um 
outro relacionamento, de cardinalidade N : N. 
 
 
FUNCIONÁRIO 
 
PROJETO Alocado
 
RECURSO 
Requisita
 
FUNCIONÁRIO 
 
PROJETO Alocado
 
RECURSO 
Requisita