01 - Introdução a projeto de banco de dados

Prévia do material em texto

1. Projetos de Bancos de Dados 
 
 
 
Bancos de Dados são componentes importantes dos sistemas de informação, portanto, o projeto 
do banco de dados torna-se uma atividade essencial na fase de desenvolvimento dos sistemas. 
 
Muitas vezes a falta de uma abordagem adequada para o projeto de um banco de dados pode 
incorrer em resultados indesejáveis, como queda de performance ao atender a demanda de 
aplicações e problemas com a manutenção do banco de dados. Geralmente a causa disso está 
associada a etapa de entendimento do problema e transcrição da representação para o modelo 
conceitual. 
De acordo com Korth1 Um modelo de dados pode ser definido como uma Coleção de ferramentas 
conceituais para descrição de dados, relacionamento entre os dados, semântica e restrições de 
dados. 
 
O Modelo de Dados é basicamente um conjunto de conceitos utilizados para descrever um Banco 
de Dados. Não existe uma única forma de representação deste modelo, porém qualquer forma 
que emite a correta compreensão das estruturas de dados compreendidas no Banco de Dados, 
pode ser considerada adequada. 
 
Os modelos são a base do design. Os engenheiros criam um modelo de carro para estudar os 
detalhes antes de colocá-lo em produção. Da mesma forma, projetistas de sistemas desenvolvem 
modelos para explorar idéias e compreender melhor o design de um banco de dados. 
 
Os modelos ajudam a comunicar conceitos imaginados pelas pessoas. É possível usá-los com os 
seguintes objetivos: 
 
• Comunicar 
 
• Categorizar 
 
• Descrever 
 
• Especificar 
 
• Investigar 
 
• Desenvolver 
 
• Analisar 
 
• Imitar 
 
 
O objetivo é produzir um modelo que se adapte a vários usos, possa ser compreendido por um 
usuário final e contenha detalhes suficientes para que um desenvolvedor crie um sistema de 
banco de dados. 
 
O projeto de um banco de dados pode ser decomposto em três fases básicas as quais 
denominamos modelo: 
 
• Modelo Conceitual; 
 
• Modelo Lógico; 
 
———————————————————— 
1 KORTH, H.F., SURDASHAN, S., SILBERSCHATZ, A., Sistema de Banco de Dados, Makron, 1999 
 
 
1 
 
 
 
 
• Modelo Físico 
 
 
 
 
Requisito 
de Dados 
 
 
 
 
 
Modelo 
Conceitual 
 
 
Esquema Conceitual 
 
 
Modelo 
Lógico 
 
 
Esquema Lógico 
 
 
Modelo 
Físico 
 
 
Esquema Físico 
 
 
 
 
 
 
 
 
 
Figura 1. 
 
 
 
1.1. Modelo Conceitual 
 
 
A construção do Modelo Conceitual é iniciada a partir da especificação dos requisitos e resulta 
no esquema conceitual do banco de dados, onde a semântica da realidade deve estar correta. 
Um esquema conceitual é uma descrição em alto nível da estrutura do banco de dados, 
independente do Sistema de Gerenciamento de Banco de Dados (SGBD) adotado para 
implementá-lo. É utilizado para descrever os esquemas conceituais. 
 
É chamado de modelo de alto nível, pois não está ligado (relacionado) a nenhum Banco de 
Dados. Sua verdadeira intenção é promover o entendimento dos fatos de uma realidade (mundo) 
para ser representado e tratado em um BD. 
 
De acordo com Cougo2 o modelo conceitual pode ser definido como um modelo no qual os 
objetos, suas características e relacionamentos têm a representação fiel ao ambiente observado, 
independente de quaisquer limitações impostas por tecnologias, técnicas de implementação ou 
dispositivos físicos. 
 
———————————————————— 
2 COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 
 
 
2 
 
 
Considerando o ciclo de vida de desenvolvimento de um sistema esta etapa pode ser considerada 
a fase de análise dos dados (ou requisitos) capturados na etapa anterior (levantamento de 
dados). São analisados os fatos (entidades ou conjunto de ocorrências de dados) de interesse e 
seus relacionamentos, juntamente com seus atributos (propriedades ou características) e 
construída uma notação gráfica (abstrata, uma representação de alto nível) para facilitar o 
entendimento dos dados e suas relações, tanto para os analistas quanto para os futuros usuários. 
 
 
1.1.1. Objetivos do Modelo Conceitual 
 
 
• Descrição das Informações – O objetivo do modelo conceitual é descrever as informações 
contidas em uma realidade, as quais estarão armazenadas em um banco de dados. 
 
• Resultado real – O resultado de um Modelo Conceitual é um esquema que representa a 
realidade das informações existentes, assim como as estruturas de dados que representam 
essas informações. 
 
• Independência de Manipulação e Manutenção dos Dados – Não é construído com 
considerações procedurais, não existindo preocupação com as operações de 
manipulação/manutenção dos dados. 
 
• Independência do SGBD – Não retrata aspectos ligados à abordagem do banco de dados que 
será utilizado e nem com as formas de acesso ou estruturas físicas implementadas por um 
SGBD. 
 
 
1.1.2. Características do Modelo Conceitual 
 
 
• Representação da Realidade – Registra as necessidades de informação de uma realidade. 
 
• Melhor Conhecimento do Sistema – Permite que os analistas possam interagir melhor com os 
usuários validando seus objetivos e metas permitindo a construção de um sistema de 
informações cada vez mais próximo da realidade do usuário. 
 
• Inicia o projeto – É a primeira etapa do projeto de um sistema de aplicação em banco de 
dados. 
 
 
A fase de projeto conceitual é tida como uma das mais (senão a mais) delicadas em todo esse 
processo, pois depende muito da habilidade do projetista do banco de dados e das qualidades do 
modelo de dados adotado para a elaboração do esquema conceitual. A meta nessa fase é obter 
um esquema conceitual do banco de dados que seja tão completo e expressivo quanto possível. 
Esse esquema deve procurar expressar o máximo da semântica envolvida na informação. 
Mecanismos de representação de alto nível são empregados, tais como representação de 
hierarquias de subconjunto e de generalização, representação de restrições de cardinalidade e de 
atributos compostos e multivalorados. 
 
O esquema conceitual deve permanecer como uma parte da documentação do processo de 
projeto, sendo utilizado durante a operação e manutenção do banco de dados, pois facilita o 
entendimento dos esquemas de dados e das aplicações que os utilizam. 
 
Para auxiliar o projetista a elaborar o projeto conceitual de um banco de dados existem as 
abstrações de dados, que apresentam as vantagens: 
 
• ajudam o projetista a entender, classificar e modelar a realidade, 
 
 
 
3 
 
 
• melhoram a eficiência de implementações subseqüentes, 
 
• permitem melhor representar a semântica das novas aplicações de banco de dados, 
provenientes de áreas não tradicionais. 
 
 
1.1.3. O Modelo Conceitual propicia 
 
 
 Melhor compreensão pelo usuário leigo: Um modelo conceitual é normalmente uma 
representação gráfica de fatos e relações do mundo real. Assim sendo, a compreensão 
destes conceitos é facilitada, se exposta graficamente. O usuário leigo, para o qual o BD será 
desenvolvido, tem melhores condições de criticar o projeto feito e interagir no projeto. 
 
 Independência de detalhes de implementação: Um modelo conceitual não é vinculado a 
nenhum modelo de dados de BD, ou seja, não apresenta detalhes de estruturação de dados 
que só precisam ser considerados no momento da criação do esquema em um SGBD. Assim, 
modificações nesta etapa do projeto são menos comprometedoras do que nas etapas 
seguintes. Inclusive, é recomendado que se critique bastante o modelo conceitual, para evitar 
mudanças depois. 
 
 Tradução para qualquer modelo de dados de BD: Um modelo conceitual pode ser 
mapeado para qualquer modelo de BD, desde que se saibam as regras para realizar tal 
tarefa. Isto facilita o upgrade do BD (por exemplo, migração de um SGBD relacional para um 
SGBD orientado a objetos), uma vez que não é preciso repensar do zero a nova 
organização lógica que os dados terão no novo modelo de dados. 
 
 Ferramenta indispensável para o processo de engenharia reversa de BD: Oupgrade (ou 
migração) de um esquema implementado em um certo modelo de dados de BD para outro 
exige a realização de um processo chamado engenharia reversa. O objetivo deste processo é 
justamente obter o modelo conceitual a partir de um modelo lógico (projeto de BD “ao 
contrário”), para que possa então ocorrer o upgrade, como comentado na vantagem anterior. 
 
 Maior estabilidade frente a mudanças a nível de implementação: O modelo conceitual, por 
ser um modelo de alto nível (semântico), tem menor probabilidade de ser afetado quando 
ocorrem mudanças a nível de implementação, realizadas no SGBD, como por exemplo, definir 
índices para aumentar a performance, tornar o BD distribuído, utilizar estratégias de 
clusterização para agilizar consultas, etc. Às vezes, mesmo modificações, por exemplo, em 
tabelas de um BD relacional, não inviabilizam o modelo conceitual, uma vez que as regras de 
mapeamento para um modelo lógico admitem algumas variações, como por exemplo, o fato de 
um relacionamento 1:1 com parcialidade gerar ou não uma tabela para o relacionamento. 
 
 Mais adequado para o exercício da criatividade: Um modelo conceitual é na verdade uma 
ferramenta que admite diversas alternativas de solução para a interpretação de uma 
realidade, dependendo de quem está modelando. É interessante que uma modelagem 
conceitual seja realizada por diversos analistas e comparada entre eles, para se determinar 
qual delas é a mais clara, ou seja, captura melhor a semântica da realidade. 
 
 
 
 
 
 
 
 
 
 
 
 
 
4 
 
 
 
 
1.1.4. Exemplo de Modelagem Conceitual 
 
 
 
Filme 
nome 
data 
copyright 
duracao 
custo 
id: nome 
data 
id’: copyright 
 
 
 
 
 
tem-atuacao 
1-N 
 
 
 
 
Paticipacao 
personagem 
cache 
s1/1 
 
 
 
 
atua 
1-N 
 
 
Ator 
nome_arstistico 
nac 
idade 
sexo 
tipo_papel [0-3] 
id: nome_artistico 
 
produzido-por 
1-1 
 
producao 
 
produz 
0-N 
 
Estudio 
nome 
dono 
tem-direcao-de 
1-1 
 
 
 
 
 
direcao 
 
 
 
 
 
dirige 
0-N 
 
 
Diretor 
nome 
nacionalidade 
premio [1-N] 
festival 
ano 
nome_premio 
fundacao 
faturamento 
id: nome 
 
Obs.: Notação ER da ferramenta DB Main 
 
Figura 2. 
 
 
 
 Explicação do Exemplo 
 
 
O modelo retrata o estudo de caso de uma produtora de filmes. 
 
• Um filme tem a atuação de vários atores; 
 
• Um filme é dirigido por um Diretor; 
 
• Um estúdio pode produzir vários filmes; 
 
 
Perceba que em nenhum momento este modelo relata tipo de dados ou fica preso a qualquer 
restrição de sistema. 
 
No caso apresentado ele demonstra as relações existentes entre cada objeto importante dentro 
da produtora de filmes e caracteriza cada um desses objetos com as informações existentes na 
realidade da situação. 
 
 
 
1.2. Modelo Lógico 
 
 
O Modelo Lógico inicia-se a partir do esquema conceitual e resulta no esquema lógico. Um 
esquema lógico é uma descrição da estrutura do banco de dados que pode ser processada por 
 
 
 
5 
 
 
 
 
um SGBD. Nesta etapa, o desenvolvimento do Banco de Dados começa a se voltar para o 
ambiente de implementação, uma vez que é feita a conversão do modelo conceitual para um 
modelo de dados de um Banco de Dados. 
 
Os modelos lógicos podem ser construídos de acordo com a abordagem: relacional, em redes, 
hierárquico ou Orientada a Objetos. O projeto lógico depende da abordagem do modelo de dados 
usado pelo SGBD, mas não do SGBD específico usado. 
De acordo com Cougo3 o modelo lógico é aquele em que os objetos, suas características e 
relacionamentos têm a representação de acordo com as regras e limitantes impostos por algum 
tipo de tecnologia, mas essa representação é independente dos dispositivos ou meios de 
armazenamento físico e das estrutura de dados por ela definidos. 
 
 Na abordagem relacional esta etapa se baseia no uso de regras de mapeamento de um modelo 
ER para o modelo de dados escolhido. O resultado é uma estrutura lógica, como um conjunto de 
tabelas relacionadas. 
 
Considerando o ciclo de vida de desenvolvimento de sistemas está associado à fase de projeto. 
Os modelos lógicos podem ser baseados em objetos ou baseados em registros. 
 
• Modelos lógicos baseados em objetos: Descrição dos dados nos níveis conceitual e de 
visões de usuários. 
 
Exemplos: Entidade-relacionamento, orientado a objetos. 
 
• Modelos lógicos baseados em registros: Descrição dos dados nos níveis conceitual e de 
visões de usuários; o banco de dados é estruturado em registros de formatos fixos, de diversos 
tipos; cada tipo de registro tem sua coleção de atributos; há linguagens para expressar 
consultas e atualizações no banco de dados. 
Exemplos: Relacional, Rede, Hierárquico. 
No modelo relacional, dados e relacionamentos entre dados são representados por tabelas, cada 
uma com suas colunas específicas. 
 
 
 
Funcionário 
 
Código do Funcionario 
 
Nome do Funcionário 
Endereço do Funcionário 
Telefone do Funcionário 
Salário do Funcionário 
Cargo do Funcionário 
Data de Admissão do Funcionário 
Data de Nascimento do Funcionário 
Observações do Funcionário 
 
 
 
Dependente 
 
Código do Dependente 
 
Nome do Dependente 
Data de Nascimento do Dependente 
Grau de Parentesco do Dependente 
Código do Funcionário (FK) 
 
 
 
Figura 3. 
 
 
 
 
———————————————————— 
3 COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 
 
 
6 
 
 
 
 
1.3. Modelo Físico 
 
 
Esta última etapa é realizada a adequação do modelo lógico ao formato de representação de 
dados do SGBD escolhido para a implementação. 
 
O Modelo Físico inicia-se a partir do esquema lógico e resulta no esquema físico. Um esquema 
físico é uma descrição da implementação do banco de dados; ele descreve as estruturas de 
armazenamento e métodos de acesso usado para efetivamente realizar o acesso aos dados. O 
projeto físico é direcionado para um SGBD específico. Decisões tomadas durante o projeto físico, 
para melhorar o desempenho, podem afetar a estrutura do esquema lógico. O esquema físico do 
banco de dados é influenciado pelas fases por que passou a construção do banco de dados. 
De acordo com Cougo4 o modelo físico de dados é aquele em que a representação dos objetos é 
feita sob o foco do nível físico de implementação das ocorrência, ou instâncias das entidades e 
seus relacionamentos. 
 
Considerando o ciclo de vida de desenvolvimento de um sistema esta etapa está associada a 
etapa de implementação (codificação ou desenvolvimento). 
Para a realização desta etapa, deve-se conhecer a linguagem para descrição e controle 5 do 
Sistema Gerenciador de banco de dados para realizar a descrição do modelo lógico. 
 
O resultado é a especificação do esquema da aplicação, juntamente com a implementação de 
restrições de integridade e visões. 
 
 
 
Funcionário 
cd_funcionario:NUMBER(10) 
 
nm_funcionario:VARCHAR2(40) 
nm_endereco_funcionario:VARCHAR2(40) 
nr_telefone_funcionario:VARCHAR2(20) 
vl_salario_funcionario:NUMBER(13,2) 
nm_cargo_funcionario:VARCHAR2(40) 
dt_admissao_funcionario:DATE 
dt_nascimento_funcionario:DATE 
ds_funcionario:VARCHAR2(4000) 
 
 
 
Dependente 
 
cd_dependente:NUMBER(3) 
 
nm_dependente:VARCHAR2(40) 
dt_nascimento_dependente:DATE 
nm_parentesco_dependente:VARCHAR2(20) 
cd_funcionario: NUMBER(10) 
 
 
 
Figura 4. 
 
 
 
Nesta etapa também é necessário conhecimento sobre a Linguagem de Manipulação de Dados 
(DML), pois é por meio dela que será possível o acesso e manipulação dos dados organizados 
pelo modelo de dados apropriado e sobre gerenciamento de transações. Uma transação é uma 
coleção de operações que realizam uma única ação lógica na aplicação do banco de dados. 
 
A gerência de transações assegura que o banco de dados permaneça em um estado consistente 
(correto) a despeito de falhas no sistema (ex.: quedas de energia, e crashes do sistema 
operacional) e falhas de transações. 
 
 
———————————————————— 
4 COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 
5A linguagem de Definição de dados (DDL) é uma notação de especificação para definição do esquema do banco de 
dados. O compilador da DDL gera um conjunto de tabelas armazenadas em um dicionário de dados. A estrutura de 
armazenamento e métodos de acesso usados pelo sistema de banco de dados são especificados. 
 
 
7 
 
 
 
 
A gerência de controle de concorrência controla as interações através de transações 
concorrentes, para assegurar a consistência do banco de dados. 
 
 
1.3.1. O que acontece na Conversão do Modelo Lógico para o Modelo Físico? 
 
 
A especificação de campos, ou seja, o modelo lógico está mais perto do usuário e o modelo físico 
vai ficar bem mais próximo da máquina. 
 
 Os campos são a base do banco de dados. Eles representam características dos assuntos que 
 são importantes para a organização. Eles armazenam os dados que são recuperados e depois 
 apresentados como informações – informações que são vitais para as operações diárias, para o 
sucesso e para o futuro crescimento da organização. Eles são os bem mais ignorados, 
subutilizados e freqüentemente negligenciados da organização! Freqüentemente, pouco ou 
nenhum tempo é gasto para se garantir a integridade estrutural e lógica /dos campos do banco de 
dados. 
 
A especificação de campos é muito importante por inúmeras razões, dentre elas podemos citar: 
 
• A integridade em nível de campo é estabelecida e imposta como resultado da definição de 
Especificação de Campo 
 
• A definição de especificação de campo para cada campo melhora a integridade dos dados. 
 
• A definição de Especificações de Campo o impulsiona a adquirir um entendimento completo da 
natureza e propósito dos dados do banco de dados. 
 
 
 
 Elementos de Campo Ideal 
 
° Ele representa uma característica do assunto da tabela; 
° Ele contém apenas um valor; 
° Ele não pode ser dividido em componentes menores; 
° Ele não contém um valor calculado ou concatenado; 
° Ele é único dentro da estrutura inteira do banco de dados; 
° Ele mantém todas as suas características, caso apareça em mais de uma tabela. 
 
 
As especificações de campo compreendem vários elementos que são usados para definir cada 
atributo de um campo. Esses elementos são divididos em três categorias: Elementos Gerais, 
Elementos Físicos e Elementos Lógicos. Há uma quarta categoria separada: Informações de 
Especificação. Agrupar os elementos dessa maneira torna-os mais fáceis de encontrar. Isso 
também permite que você focalize um aspecto específico do campo para o qual você está 
definindo a Especificação de Campo. 
 
Os itens encontrados dentro de cada categoria são: 
 
• Elementos Gerais: Nome de campo, tabela de origem, rótulo, compartilhado por, alias (um ou 
mais), descrição. 
 
• Elementos Físicos: Tipo de Dados, suporte de caracteres, comprimento, casas decimais, 
máscara de entrada, formato de exibição. 
 
 
 
 
8 
 
 
 
 
• Elementos Lógicos: Tipo de Chave, exclusividade, valor obrigatório, suporte a nulo, regra de 
edição, comparações permitidas, operações permitidas, valores introduzidos por valor 
padrão, intervalo de valores. 
 
• Informações de Especificação: Tipo de especificação, baseadas em especificação existente, 
especificação de origem. 
 
 
 
 
2. Modelos de Banco de Dados 
 
 
 
2.1. Modelo Hierárquico de Banco de Dados 
 
 
O modelo de banco de dados hierárquico funcionou muito bem com os sistemas de 
armazenamento em fita, usado pelos computadores nos anos 70 e foi muito popular nas 
companhias que usavam este sistema. Apesar de o modelo hierárquico oferecer acesso rápido e 
direto aos dados e ter sido um modelo de grande utilidade em numerosas circunstâncias, era 
clara a necessidade de ser ter um novo modelo que resolvesse os problemas de dados 
redundantes e relacionamentos complexos de dados. 
A própria IBM6 nos informa que a linguagem de dados da IBM DL/I-(Data Languagem/I) constitui 
um relevante exemplo de gerenciamento de banco de dados, cujo método utilizado é o modelo 
hierárquico. Onde esta linguagem faz parte em banco de dados de seu sistema de gerenciamento 
de informações (IMS - Information Management System) e sistema de controle de informações 
sobre o cliente (CICS - Custemar Information Control System). 
 
Descreve uma Hierarquia como um conjunto de registros interligados, isto é, em cada um há um 
tipo de registro “PAI”, exceto a Raiz. 
 
Numa Hierarquia, o acesso aos dados é utilizado através de segmento “Raiz”, quando um campo 
é escolhido como campo-chave e os outros são baseados em índice ou acesso aleatório. 
 
 
 
Nome Sobrenome Rua Conta Saldo 
 
 
cliente conta 
 
 
 
 
 
 
 
Campo-chave conta Campo-chave cliente 
 
Figura 5. Diagrama de estrutura de árvore com campo-chave. 
 
 
 
No modelo hierárquico o os dados são armazenados em registros organizados hierarquicamente 
como árvores. Os registros são conjuntos de campos conectados uns aos outros por meio de um 
“link”, onde cada “link” deve relacionar apenas dois registros. 
———————————————————— 
6 IBM Training Center, Fundamentos de Bancos de Dados, 1989. 
 
 
9 
 
 
 
 
 
 
 
 
 
 
 
 
Inês Coel Vergueiro Ana Knor Laguna Vera Henfil Correio 
 
 
 
 
 
0933 4000 1024 3280 0020 6000 1963 4000 
 
 
Figura 6. Exemplo de Modelo Hierárquico. 
 
 
 
Na Figura 5. – Exemplo de Banco de Dados Hierárquico: há dois tipos de registros, Cliente e 
Conta. O registro Cliente é composto por três campos: Nome, Sobrenome e Rua. O registro 
Conta é composto por dois campos: Número da Conta e Saldo. Podemos ver que o cliente Inês 
tem a conta 0933, o cliente Ana tem as contas 1024 e 0020 e o cliente Vera tem a conta 1963. 
 
O conjunto de todos os registros de clientes e de contas é organizado na forma de uma raiz, em 
que a raiz da árvore é um nó vazio (dummy). Como podemos ver, um banco de dados hierárquico 
é uma coleção do tipo de árvores com raiz e, por isso, forma uma floresta. Podemos nos referir a 
cada uma dessas árvores com raiz como sendo uma árvore de banco de dados 7. 
 
O modelo hierárquico acessa os dados rapidamente por trabalhar com ponteiros, mas sua 
estrutura em árvore pode levar a redundância de dados e isso, eventualmente, pode resultar em 
dados inconsistentes quando ocorrer uma atualização, sem contar com o desperdício – inevitável 
– de espaço. 
 
O acesso aos dados só pode ser feito através de programas desenvolvidos por especialistas. 
 
 
DICA: Para saber mais sobre bancos de dados hierárquicos consulte 
http://www.cs.yale.edu/homes/avi/db-book/b.pdf 
 
 
 
 
2.2. Modelo Banco de Dados em Rede 
 
 
A primeira especificação-padrão de banco de dados, chamada de relatório CODSYL 8 DBTG 1971, 
foi escrita no final da década de 1960 pelo Database Task Group. Vários sistemas de 
gerenciamento de banco de dados se baseiam nesse modelo de rede que ficou conhecido 
apenas como modelo “CODASYL”. 
 
Uma rede é, essencialmente, um conjunto ilimitado de nós (tipos de registros neste caso) e de 
ramais de ligação, ou bordas. Na verdade, uma hierarquia (visto no tópico anterior) é apenas um 
tipo particular de rede. 
 
Uma rede não apresenta o conceito de nó “raiz” e os registros podem ter diversos tipos de 
registros-pais, assim como diversos tipos de registros-filhos. 
———————————————————— 
7 Silberschatz, Abraham; Korth, Hary F. e Sudashan, S., Sistema de Banco de Dados, Editora Makron Books, 1999 
8 CODASYL: Conferência Sobre Linguagem de Sistemas de Dados (Conference on Data Sistems Languages). 
 
 
10 
 
 
 
 
Abaixo temos um modelo de um banco de dados em rede mostrando detalhadamente. 
 
 
 
 
Inês Coel Vergueiro 0933 4000,00 
 
 
 
 
1024 3280,00 
 
Ana Knor Laguna 
 
0020 6000,00 
 
 
 
 
Vera 
 
Henfil 
 
Correio 1963 4000,00 
 
Figura 7. Exemplo de Modelo de Rede. 
 
 
 
Na Figura 7. – Exemplo de modelo de rede podemos ver que o cliente Inês possui a conta 0933, o 
cliente Ana possui as contas 1024 e 0020 e o cliente Verapossui a conta 1963. 
 
Funcionalmente os modelos de rede e hieráquico possuem muitas semelhanças. Tal como no 
modelo hierárquico os registros são interligados por ponteiros e as linhas entre os registros 
(também conhecidos como ramais) representam relacionamentos um-para-muitos. Outras 
semelhanças com o modelo hierárquico persistem, por exemplo, ambos precisam usar de 
artifícios para implementar uma relação muitos-para-muitos; no modelo de rede foi criado um 
registro especial chamado de “ligação” para implementar esse relacionamento. No modelo 
hierárquico esse registro especial é chamado de “registro virtual”. 
 
É importante lembrar que ambos os sistemas-hierárquicos e de rede são chamados de “sistemas 
de navegação” já que, nos dois casos, os programadores precisam atravessar um conjunto de 
registros pré-articulados (pré-interligados). Sabe-se que esta pré-articulação representa um 
benefício em termos de desempenho, embora seja restrita em termos da complexibilidade do 
processo do projeto e das modificações posteriores ao projeto. 
 
O modelo Banco de Dados em rede foi criado na tentativa de resolver alguns problemas do 
modelo hierárquico. O modelo em rede também pode ser representado como uma árvore 
invertida. Entretanto, podem existir inúmeras árvores invertidas compartilhando galhos, que são 
parte de uma mesma estrutura de bando de dados. 
 
Os relacionamentos num modelo em rede são estabelecidos e representados por uma estrutura 
de conjunto. Uma estrutura de conjunto é uma construção transparente que relaciona duas 
tabelas ao mesmo tempo, usando uma tabela como proprietária e outra como membro. Estruturas 
de conjunto suportam relacionamentos um-para-muitos, o que significa que numa estrutura de 
conjunto, um registro numa tabela proprietária pode ser associado a vários registros na 
tabela-membro, mas um único registro da tabela-membro está relacionado a um só registro na 
tabela-proprietária. Um registro da tabela-membro também não pode existir sem que ele esteja 
relacionado com um registro existente na tabela-proprietária. Por exemplo, uma conta-corrente 
deve ser associada a um cliente, apesar de poder existir um cliente sem conta-corrente 9. 
 
 
 
———————————————————— 
9 Silberschatz, Abraham; Korth, Hary F. e Sudashan, S., Sistema de Banco de Dados, Editora Makron Books, 1999 
 
 
11 
 
 
 
 
 
Cliente 
 
 
 
Deposita 
Tabela - Proprietária 
 
 
 
Estrutura de Conjunto 
 
 
 
 
Conta/Corrente 
Tabela - Membro 
 
 
Figura 8. Exemplo de Estrutura de Conjunto. 
 
 
 
Na figura 8. – Exemplo de Estrutura de Conjunto um cliente pode depositar em uma ou mais de 
suas contas correntes. 
 
No modelo em rede os dados podem ser acessados rapidamente, o que é uma das vantagens 
deste modelo. O usuário pode elaborar consultas mais complexas no modelo em rede do que no 
modelo hierárquico. 
 
Como no modelo hierárquico o usuário deve estar familiarizado com a estrutura do banco de 
dados para poder trabalhar através das estruturas de conjunto. Na figura 8, por exemplo, é 
obrigatório que o usuário esteja familiarizado com as estruturas de conjunto para que ele possa 
descobrir se uma apresentação específica foi paga. 
 
Também, não é fácil mudar a estrutura do banco de dados sem afetar as aplicações do programa 
que interagem com ele. Os relacionamentos são definidos como estruturas de conjunto, uma 
estrutura de conjunto não pode ser mudada sem afetar as aplicações do programa, pois são 
usadas pela aplicação para navegar pelos dados. Se uma estrutura de conjunto é mudada, todas 
as referências usadas nas aplicações daquela estrutura deverão ser alteradas. 
 
 
DICA: Para saber mais sobre bancos de dados em rede consulte: 
 
http://www.cs.yale.edu/homes/avi/db-book/a.pdf 
 
 
 
 
2.3. Modelo Relacional10 
 
 
Nos anos 60, Dr. E.F. Codd, um pesquisador cientista da IBM, estava procurando novas maneiras 
de lidar com grandes volumes de dados. Insatisfeito com os modelos e produtos de banco de 
dados daquele tempo, ele teve a idéia de que aplicando disciplinas e estruturas matemáticas na 
administração de dados, ajudaria a resolver muitos dos problemas encontrados nos outros 
modelos de banco de dados, tais como: redundância de dados, grande dependência física na 
implementação e falha na integridade de dados. 
 
Em 1970 o Dr. Codd apresentou o seu trabalho, agora patenteado, “Um Modelo Relacional de 
Dados para Grandes Bancos de Dados Compartilhados”. Neste trabalho ele primeiramente 
apresenta o modelo relacional de banco de dados. Este modelo se baseou em duas vertentes da 
matemática – teoria dos conjuntos e lógica de predicado de primeira ordem. Na verdade o modelo 
relacional deriva seu nome do termo “relação”, que é uma parte da teoria dos conjuntos. 
 
———————————————————— 
10 O modelo de banco de dados relacional será estudado em detalhes ao longo dos capítulos seguintes. 
 
 
12 
 
 
 
 
Em um modelo relacional, os dados são armazenados em relações, que são percebidas pelo 
usuário como sendo tabelas. Cada relação é composta de tuplas ou registros e atributos ou 
campos. A ordem física em que os registros encontram-se numa tabela é totalmente arbitrária. 
Cada registro de uma tabela é identificado por um campo que contém valores únicos. Essas duas 
características do modelo relacional permitem que os dados existam, independente da forma 
como eles foram fisicamente armazenados. Então, o usuário não precisa saber o local físico de 
um registro para poder trabalhar com ele. Por este lado, o modelo relacional é diferente do 
modelo hierárquico e do de rede, pois nestes modelos era imprescindível que o usuário 
conhecesse o desenho da estrutura para que pudesse usar os seus dados. 
 
 
 
 
Cliente 
 
 
 
 
 
 
Conta Empréstimo 
 
 
Figura 9. Exemplo de modelo relacional. 
 
 
 
Na figura 9. – Exemplo de modelo relacional, um cliente pode ter uma ou mais contas correntes. 
Empréstimos podem ser depositados em sua conta corrente. Esse mesmo cliente pode fazer 
pagamento do empréstimo através de depósito em conta corrente. 
 
Uma das principais características do modelo relacional é a possibilidade de relacionar várias 
tabelas para evitar a redundância no armazenamento de dados. Os relacionamentos no modelo 
relacional podem ser um-para-um, um-para-muitos e muitos-para-muitos. Duas tabelas (A e B) 
estarão conectadas quando uma delas (A, por exemplo) tiver um campo de compartilhamento que 
poderá ser plenamente usado em outra (B) para diminuir redundância de dados nas inserções de 
registros e facilitar futuras buscas e/ou pesquisas. Logo várias tabelas podem estar 
compartilhando um mesmo campo de uma determinada tabela. 
 
A partir do momento em que o usuário esteja familiarizado com os relacionamentos entre as 
tabelas do banco de dados, ele pode acessar os dados de inúmeras formas diferentes. Ele pode 
acessar os dados de tabelas que estejam diretamente conectadas, como de tabelas que estejam 
indiretamente conectadas. 
 
No exemplo a seguir, apesar da tabela Cliente estar indiretamente conectada a tabela de 
Empréstimo, o usuário pode gerar uma listagem de empréstimos por cliente ou por conta. O 
usuário pode facilmente fazer isso, porque a tabela de Empréstimos está diretamente conectada à 
tabela de Conta. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
13 
 
 
 
 
Cliente 
 
Identificação 
do Cliente 
Prenome do 
Cliente 
Sobrenome 
do Cliente 
Data da 
Contratação 
 
100 
 
Inês 
 
Coel 
 
21/10/02 
 
101 
 
Ana 
 
Knor 
 
12/01/01 
 
102 
 
Vera 
 
Henfil 
 
15/02/99 
 
 
 
 
 
 
Conta 
 
Identificação 
da Conta 
 
Identificação 
do Cliente 
Saldo Código 
Empréstimo 
 
0933 
 
100 
 
4000,00 
 
A15 
 
1024 
 
101 
 
3280,00 
 
0020 
 
101 
 
6000,00 
 
1963 
 
102 
 
4000,00 
 
B26 
 
 
 
 
 
Tabela 1. 
 
 
 
2.3.1. Vantagens do Modelo Relacional 
 
 
• Construção de Níveis Múltiplos de Integridade: A integridade dos dados neste modelo é 
construída em nível decampo para assegurar a acuracidade dos dados; em nível de tabela 
para assegurar que os registros não estão duplicados e para detectar se estão faltando 
valores na chave-primária; em nível de relacionamentos para assegurar que o relacionamento 
entre duas tabelas é válido, e em nível do negócio, propriamente dito, para assegurar que os 
dados estão acurados de acordo com o negócio. 
 
• Independência Física e Lógica da Aplicação do Banco de Dados: Nem as mudanças 
efetuadas pelo usuário no projeto lógico do banco de dados, tampouco as mudanças físicas de 
implementação do banco de dados feitas pelos fabricantes de software irão prejudicar as 
aplicações nele construídas. 
 
• Garantia da Consistência e Acuracidade dos Dados: Os dados são acurados e 
consistentes graças aos vários níveis de integridade que você pode impor ao banco de dados. 
 
• Fácil Armazenamento de Dados: Ao comando do usuário, os dados podem ser 
armazenados numa tabela ou em várias tabelas do banco de dados. 
 
 
 
 
 
 
 
 
14 
 
 
 
 
2.4. Modelo Orientado a Objetos11 
 
 
A técnica de modelagem orientada a objetos normalmente é empregada nos casos onde os dados 
envolvidos na aplicação apresentam uma estrutura complexa. 
 
A principal diferença entre os modelos de dados relacional, hierárquico e em redes e os modelos 
de dados orientados a objetos está na maneira como os dados são tratados. 
 
A meta dos bancos de dados orientados a objetos é manter a correspondência direta entre os 
objetos do mundo real e os do banco de dados, isso implica que podemos identificar e manipular 
os objetos como um todo. Representar um objeto complexo no modelo relacional significa que o 
objeto tem que ser subdividido em um grande número de linhas ou tuplas, o que leva à 
necessidade de realizar um considerável número de operações de junção para recuperar o objeto. 
 
Nos modelos de dados tradicionais os dados são vistos como uma coleção de tipos de registros 
ou de relações, cada qual tendo uma coleção de registros, linhas ou tuplas armazenadas em um 
banco de dados. Em um modelo de dados orientado a objetos um banco de dados é considerado 
como uma coleção de objetos do mundo real. 
 
Os bancos de dados orientados a objetos foram propostos para dar suporte às necessidades de 
aplicações mais complexas, como aquelas que exigem transações mais longas, textos longos e 
armazenamento de imagens. 
 
Muitos dos conceitos das Linguagens de Programação Orientadas a Objetos (LPOO) são 
utilizados nos Banco de Dados Orientados a Objetos (BDOO) apesar de estes necessitarem de 
conceitos próprios. Por exemplo, os objetos nas LPOO são transitórios, isto é, só existem durante 
a execução do programa enquanto que nos BDOO os objetos são persistentes, isto é, a 
existência de um objeto pode ser estendida de modo que sejam armazenados permanentemente. 
Vejamos mais alguns dos principais conceitos envolvidos com BDOO: 
 
• Métodos: Os objetos nos SGBDOOs são manipulados através de métodos. Em geral, a 
definição de um método consiste de assinatura e corpo. A assinatura especifica o nome do 
método, os nomes e classes dos argumentos e a classe do resultado, se existir. O corpo 
representa a implementação do método e consiste de um conjunto de instruções expressas em 
uma dada linguagem de programação. 
 
• Tipos e Classes: Um tipo modela as características comuns de um conjunto de objetos e 
corresponde à noção de tipos abstratos de dados. Uma classe é um conjunto de objetos que 
tem exatamente a mesma estrutura interna, i.é, os mesmos atributos e mesmos métodos. Os 
modelos de dados orientados a objetos usam o conceito de classe como uma base para 
instanciação. 
 
• Herança: É um mecanismo de reusabilidade muito poderoso. Com herança, uma classe 
chamada uma subclasse pode ser definida com base na definição de outra classe chamada a 
superclasse. A subclasse herda os atributos, métodos e mensagens de sua superclasse e 
pode ter atributos específicos, métodos e mensagens adicionais. 
 
• Polimorfismo: Os SGBDOOs oferecem o recurso de polimorfismo de operações, também 
conhecido como sobrecarga de operador (overloading). Outros conceitos relacionados com o 
polimorfismo são os de late binding (ligação tardia) e overriding (redefinição de operação). 
 
 
 
 
———————————————————— 
11 Modelagem de sistemas complexos será visto com mais detalhes em capítulo específico ao tema 
 
 
15 
 
 
 
 
• Valores: A maioria dos SGBDOOs representam as entidades primitivas, tais como inteiros ou 
caracteres, por valores (não possuem OIDs), enquanto as entidades não primitivas são 
representadas como objetos. 
 
• Estrutura do objeto: O valor de cada atributo de um objeto pode ser: 
 
° atômico: integer, real, character, booleano, etc. 
° complexo: definido através de construtores: array, table, UDT12. 
• Encapsulamento: A cada objeto está associado sua estrutura e seu comportamento (os 
métodos ou operações). O comportamento é armazenado no banco de dados junto com a 
estrutura do objeto. 
 
• Objetos e Identidade: Cada entidade do mundo real é modelada como um objeto. 
 
A cada objeto é associado um estado e um comportamento: o estado é representado pelos 
valores dos atributos do objeto; o comportamento é definido pelos métodos que agem sobre o 
estado do objeto pela invocação de operações. 
 
A cada objeto armazenado no banco de dados é associado um identificador único ( OID: Object 
Identifier), que é gerado pelo SGBDOO (sistema de gerenciamento de banco de dados 
orientado a objetos) 
 
• OIDs x Chaves Primárias 
 
Nos modelos orientados a objetos não existe o conceito de chave primária como acontece no 
modelo relacional. Ao invés disso, existem os OIDs dos objetos que, como já dito, são criados e 
mantidos pelo sistema de gerenciamento de banco de dados e não são de acesso do usuário. 
 
 
As vantagens do uso de OIDs com relação às chaves são: 
 
• os programadores de aplicações não precisam se preocupar com a seleção de chaves para as 
várias classes de objetos; 
 
• obtém-se melhor desempenho, pois os OIDs são implementados em baixo nível pelo sistema; 
 
• embora as chaves sejam mais significativas ao usuário, muitas vezes o usuário precisa usar 
códigos artificiais, sem significado semântico, para poder identificar as tuplas de uma relação. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
———————————————————— 
12 UDT - User Defined Type. Tipo de dado definido pelo usuário. Caso necessário é possível criar tipos de dados 
diferentes do tipos de dados padrão do BD. Ex: litro, pneu, galão, perímetro. 
 
 
16 
 
 
 
 
 
 
3. Modelo Entidade Relacionamento (MER) 
 
 
 
3.1. Conceitos Básicos 
 
 
Neste capítulo serão apresentados de maneira simplificada os conceitos básicos que serão 
utilizados e detalhados ao longo do curso. 
 
 
 
3.2. Dados e Informações 
 
 
Os dados existem fisicamente e precisam de um contexto para adquirir algum significado. São 
estáticos, isto é, permanecem no mesmo estado até que sejam modificados por um processo 
manual ou automático. 
 
 
 
Mellanzone 
 
55 
 
03909-70 22,00 Mesozóica 
 
 
Isoladamente estes dados não têm nenhum sentido. O que é Mellanzone? Será o nome de uma 
pessoa, de um supermercado ou de uma pizza? E 55? É um código? Uma soma? Uma nota? 
 
Os dados tornam-se informações quando são associados a um contexto e transmitem 
significados lógicos às pessoas. 
 
 
 
Nome da Pizza 
 
Ingredientes 
 
Código Pizza 
 
Preço da Pizza
 
Apelido da Pizza 
 
Mellanzone 
 
55 
 
03909-70 
 
22,00 
 
Mesozóica 
 
Tabela 2. 
 
 
3.2.1. Qual é a diferença entre Dado e Informação? 
 
 
Se lhe dissermos que a temperatura ambiente está em 28ºC ou que estamos viajando a 
140km/hora, você estará recebendo dados ou informações? Mas se agora lhe dissermos que a 
temperatura ambiente é de 82ºF ou que estamos viajando a 87 milhas/hora? Qual é a sua 
resposta? Os dados 28ºC e 140 km/hora são rapidamente convertidos em sensaçõestérmicas e 
de velocidade (informação) – porque você compreende essas unidades de medida. Mas se você 
não teve uma formação anglo-saxônica, 82ºF ou 87 milhas/hora não lhe fornecem a exata 
sensação de frio ou calor, ou de velocidade baixa ou alta. 
 
Vejamos mais um exemplo. Encontramos uma pessoa de 5 pés e 10 polegadas de altura que 
colocou 16 galões de combustível no seu carro, pois iria viajar para uma cidade a 100 milhas de 
distância, com 100 francos no bolso. Temos certeza de que você não conseguiu transformar 
todos os dados embutidos na frase em informações. Mas se lhe disséssemos que encontramos 
uma pessoa de 1,78m de altura que colocou 61 litros de combustível no seu carro, pois iria viajar 
 
 
 
 
17 
 
 
 
 
para uma cidade a 161 km de distância com R$ 100,00 no bolso, você certamente compreenderia 
melhor. 
 
A informação existe quando o cérebro humano recebe um conjunto de dados e os utiliza como 
entrada para algum tipo de processamento neural. Se não houver esse processamento neural, o 
dado não se transforma em informação; continua sendo dado. 
 
A informação é a compreensão do dado, matéria-prima para atividade cerebral. Se alguém 
conversa em russo, grego ou chinês conosco, recebemos dados, mas se não conhecermos o 
idioma (protocolo de comunicação) não podemos traduzir os dados em informações. Ficamos 
parados – sem ação. Sem dados e um mecanismo (processo) de compreensão desses dados, 
não existe o exercício cerebral. 
 
 
 
Informação versus Dado 
 
Informação 
 
Dado 
 
Idade: 35 anos 
 
Data do Nascimento: 16/07/61 
 
Quente 
 
Medição x Métrica de 
Temperatura = 38º C 
 
Longe 
 
Medição x Métrica de 
Distância = 10.000 
 
Tabela 3. 
 
 
 
O Dado é tão importante ao ser humano que permanecemos 24 horas por dia com nossos 
sensores ligados ou de prontidão! 
 
Para nossos propósitos de modelagem, estaremos estudando as informações que queremos ou 
precisamos para transformá-las em dados. Nosso objetivo é obtenção de um modelo de dados 
onde não exista informação. Declaração estranha para um observador casual, mas um modelo de 
dados, conforme o próprio nome sugere, deve conter dados, e não informações. 
 
Suponha que venhamos a armazenar a informação idade de uma pessoa em vez do dado data de 
nascimento. Daqui a alguns anos, as pessoas cujas informações (e não dados) estão 
armazenadas conosco continuarão a apresentar a mesma idade de hoje, pois, é evidente, 
armazenado 35 anos de idade hoje, tal informação será a mesma com o passar do tempo! Mas 
armazenando-se a data de nascimento, digamos, 21/12/1960, podemos saber com precisão e em 
qualquer ponto da régua do tempo a informação da idade da pessoa. A conclusão é que 
armazenando informação perdemos informações. 
 
Na vida real, verifica-se freqüentemente o armazenamento de informações, e não de dados, por 
motivos de limitações técnicas do processamento de dado em larga escala. Caso típico é o dos 
correntistas de bancos que fazem ao longo de suas vidas, como clientes, uma infinidade de 
transações de crédito e débito em suas contas correntes, sendo estes os dados básicos 
resultantes que devem ser armazenados. Todavia, se quisermos obter o saldo atual das contas, 
teríamos de promover as somas e subtrações de todos os movimentos, o que seria impraticável 
do ponto de vista de carga de processamento e tempo de resposta. Portanto, a solução técnica 
mais viável é armazenar os saldos dos correntistas (saldo é uma informação) em uma dada 
posição de tempo, não muito distante da atual fazendo-se os cálculos aritméticos com os dados 
mais recentes para se obter a última posição de saldo. Essa situação é aceitável, uma vez que 
não há outra forma mais eficaz de contornar o problema, restando-nos apenas a preocupação de 
manter a informação armazenada consistente com os movimentos realizados, se ocorrer um 
lançamento retroativo à data do saldo, este último deverá ser ajustado automaticamente. Tais 
 
18 
 
 
 
 
limitações técnicas têm conduzido à criação de bases de informações, como é o caso das bases 
de dados executivas. Vemos a utilização de bases de informações apenas como um artifício 
técnico que não deve representar a base de dados principal de uma organização. 
 
 
 
3.3. Entidade 
 
 
Uma entidade13 ou classe de entidade é uma representação abstrata de “coisas semelhantes”, 
concretas ou abstratas, que existem no mundo real, sobre a qual um sistema de informação 
captura, armazena e processa dados para cumprir seus objetivos na empresa, atendendo, assim, 
às necessidades de seus usuários. 
 
Para Korth14 uma entidade é uma “coisa” ou objeto no mundo real que pode ser identificada de 
forma unívoca em relação a todos os outros objetos. Por exemplo, um aluno é uma entidade que 
tem um conjunto de propriedades (dados), dentre elas o número do registro acadêmico, que deve 
ser um valor único capaz de identificar cada ocorrência desta entidade. 
Cada ocorrência15 de uma entidade é um conjunto de propriedades (atributos)16 que identificam, 
qualificam ou quantificam esta entidade, por exemplo a entidade aluno tem como atributos nome, 
registro acadêmico, data de nascimento, entre outros. Estas ocorrências devem satisfazer duas 
regras básicas: 
 
• Todas as “coisas do mundo real” que compõem o conjunto - suas ocorrências - devem ter as 
mesmas características; 
 
• Todas as ocorrências devem estar sujeitas e em conformidade com as mesmas normas. 
 
 
 
3.4. Atributos 
 
 
Cada entidade tem propriedades particulares, chamadas atributos, estas propriedades podem 
identificar, qualificar ou quantificar a entidade. Em outras palavras os atributos descrevem as 
entidades. Por exemplo, uma entidade empregado pode ser descrita pelo seu nome, o trabalho 
que realiza, data de nascimento, endereço e salário. Cada ocorrência de uma entidade terá um 
valor para cada um de seus atributos. 
 
Os valores de atributos que descrevem cada entidade ocupam a maior parte dos dados 
armazenados na base de dados. A figura 10. ilustra duas entidades com seus atributos. 
 
 
 
 
 
 
 
 
 
 
———————————————————— 
13 As entidades são representadas por tabelas na etapa de implementação do Banco. 
14 Silberschatz, A; Korth, H. R. e Sudarshan, S. Sistemas de Bancos de dados. São Paulo: Makroon Books, 1999 
15 Uma ocorrência é o mesmo que um registro. 
16 Um atributo é representado em uma tabela por um campo. O campo é a menor estrutura de armazenamento de 
dados em um banco de dados relacional 
 
 
19 
 
 
 
 
 
Nome = João da Silva 
 
 
Endereço = Rua Goiás 711, 
e1 São Paulo, SP - 1301100 c1 
Idade = 55 
 
Telefone residencial = 713-749 
 
Nome = Cooper Sugar 
 
 
Sede = Ribeirão Preto 
 
 
Presidente = João da Silva 
 
Figura 10. Exemplo de duas entidades (e1 e c1) com seus atributos. 
 
 
 
A entidade EMPREGADO e1 tem quatro atributos: Nome, Endereço, Idade e Telefone residencial. 
Os seus valores (dados) são: “João da Silva”, Rua Goiás 711, São Paulo, SP, 1301100”, “55” e 
“713-749”, respectivamente. 
 
A entidade companhia c1 tem três atributos: Nome, Sede e Presidente. Seus valores (dados) são: 
“Cooper Sugar”, “Ribeirão Preto”, “João da Silva”. 
 
 
Atenção: 
 
 
• Os atributos de uma entidade permanecem constantes para todos os seus relacionamentos. 
 
• Os atributos de uma entidade são independentes de todas as demais entidades 
 
 
 
3.5. Chaves 
 
 
• Chave Primária: É um campo ou um conjunto de campos que identifica unicamente cada 
registro da tabela, sendo assim, um registro não pode conter, neste campo, um dado que já 
esteja armazenado em outro registro. 
 
Exemplo: No contexto de um sistema de controle acadêmico o número de matricula de uma 
entidade aluno é um atributo identificador já que identifica de forma única um aluno dentro de 
uma faculdade. 
 
• Chave Estrangeira: É um campo ou conjunto de campos usado para estabelecer um 
relacionamento entre duas tabelas. Na tabela de origem deve ser chave primária. 
 
• ChaveSecundária (Terciária, etc): São chaves que possibilitarão pesquisas ou ordenações 
alternativas, ou seja, diferentes da ordem criada a partir da chave primária ou da ordenação 
natural (física) da tabela. 
 
• Chave Composta: É a chave que contém mais de um atributo (Por exemplo, um cadastro 
ordenado alfabeticamente por Estado, Cidade e Nome do Cliente, necessitaria de uma chave 
composta que contivesse esses três atributos). 
 
• Chave candidata: São atributos que podem vir a ser chave primária. 
 
Exemplo: A entidade FUNCIONARIO tem os atributos: registro funcional, nome, cpf, rg, 
endereco, dt_nascimento. Os atributos registro funcional, cpf e rg são chaves candidatas, pois 
podem identificar cada ocorrência de FUNCIONARIO. Mas para que uma chave candidata 
possa ser eleita a chave primária deverá atender a restrição de unicidade, isto é o conteúdo do 
campo deverá ser único para cada ocorrência da entidade. 
 
20 
 
d1
d2
d3
 
 
 
3.6. Relacionamentos 
 
 
Um relacionamento estabelece a conexão entre duas tabelas dentro de um banco de dados por 
meio das chaves primária e estrangeira ou por meio de tabelas de vínculo. 
 
No exemplo da figura 11. podemos ver que um aluno pode se matricular em mais de uma 
disciplina. Ao dizermos que um aluno está matriculado em muitas disciplinas estamos 
determinando a cardinalidade de nosso relacionamento. Como veremos mais à frente, neste caso 
a cardinalidade e’ de 1:N. 
 
 
 
 
 
a1 
a2 
a3 
 
 
Aluno Matrícula Disciplina 
 
Figura 11. Exemplo de Relacionamento. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
21 
 
 
 
 
 
 
4. Metodologias para Modelagem de Bancos de Dados 
Relacionais 
 
 
 
Segundo o dicionário Michaelis a Metodologia é o estudo científico dos métodos, que por sua vez 
é o conjunto dos meios dispostos convenientemente para alcançar um fim e especialmente para 
chegar a um conhecimento científico ou comunicá-lo aos outros. Uma metodologia para 
modelagem de bancos de dados relacionais é um conjunto de regras que são empregadas para 
demonstrar como será constituído o banco de dados, isto é, como as tabelas serão relacionadas. 
É uma ferramenta de comunicação de alto nível. 
 
Neste capítulo serão apresentadas algumas metodologias e definições propostas por diferentes 
autores e que são utilizadas para modelagem de bancos de dados relacionais. 
 
 
 
4.1. Metodologia de Peter Chen17 
 
 
Na década de 70, Peter Chen propôs uma técnica de diagramação que, associada a um conjunto 
de conceitos, tornou-se o que conhecemos como a abordagem entidade-relacionamento (E-R) 
para o processo de modelagem de dados. 
 
Em sua essência, o modelo E-R representa coisas do mundo real (Entidades), que possuem 
características próprias (Atributos) e que se relacionam entre si (Relacionamentos). 
 
 
 
Representação de uma Entidade 
Identificador da 
entidade 
 
 
 
Exemplo: Funcionário trabalha em Departamento. 
Neste exemplo temos duas entidades: Funcionário e Departamento. 
Representação dessas duas entidades fica da seguinte forma: 
 
 
 
 
Departamento Funcionário 
 
 
 
 
 
 
Representação dos Atributos Identificador do aTributo 
 
 
 
 
 
———————————————————— 
17 Chen p., Modelo Entidade-Relacionamento. São Paulo: Makroon Books, 1999 
 
 
22 
 
 
Departamento 
 
 
 
 
 
Atenção: Muitas vezes, com o objetivo de manter o modelo simples e claro, os atributos só são 
representados no dicionário de dados. 
 
 
Exemplos de atributos da Entidade DEPARTAMENTO: 
 
• Código (do Departamento) 
 
• Nome (do Departamento) 
 
• Localização (do Departamento) 
 
 
 
 
DEPARTAMENTO 
 
 
 
 
 
 
 
 
CÓDIGO NOME LOCALIZAÇÃO 
 
 
Figura 12. Exemplo da entidade departamento. 
 
 
 
Podemos usar uma representação alternativa para os atributos. No exemplo abaixo usaremos 
traços ao invés de elipses: 
 
 
 
 
Funcionário Trabalha em 
 
 
 
 
 
NOME TELEFONE 
 
ENDEREÇO 
 
CÓDIGO 
 
NOME 
 
Figura 13. Representação alternativa para atributos. 
 
 
 
Representação dos relacionamentos: Na notação original de Chen, são representados por 
losangos. 
 
 
 
 
Identificação 
 
 
Figura 14. 
 
 
 
 
 
 
 
23 
 
 
 
 
Exemplo: Funcionário trabalha em DEPARTAMENTO 
 
 
 
 
 
FUNCIONÁRIO trabalha DEPARTAMENTO 
 
 
 
Figura 15. Relacionamento na notação de Chen 
 
 
 
Representação da cardinalidade: 
 
 
O grau da cardinalidade é expresso acima da linha do relacionamento e pode ser representado 
por 0, 1 ou N 
 
 
 
 
FUNCIONÁRIO 
N 1 
trabalha 
 
DEPARTAMENTO 
 
 
 
Figura 16. 
 
 
Pode-se também expressar o grau mínimo e máximo de relacionamento entre as entidades: 
 
 
 
 
FUNCIONÁRIO 
0 : N 1 : 1 
trabalha 
 
DEPARTAMENTO 
 
 
 
Figura 17. 
 
 
Na notação expandida de Chen a cardinalidade é representada da seguinte forma: 
 
 
 
Um-para-um 
 
Um-para-muitos 
 
Muitos 
 
Um-e-apenas-um 
 
Zero-para-um 
 
Zero-ou-muitos 
 
Um-ou-muitos 
 
Figura 18. Cardinalidade segundo Chen. 
 
 
 
24 
 
 
 
 
4.2. Metodologia de James Martin18 
 
 
Na década de 80, James Martin apresentou uma nova proposta de modelagem que visava 
estabelecer a fronteira entre o modelo lógico e físico, desviando o foco do processo e centrando o 
foco nos eventos do sistema. 
 
Com essa nova proposta ele estabelece o particionamento por eventos, delimitando a área de 
atuação do sistema, através da utilização da lista de eventos e incorpora a modelagem de dados 
na especificação, introduzindo o modelo Entidade Relacionamento e Atributo (ERA). 
 
 
4.2.1. Representação da Entidade 
 
 
 
 
Identificador da entidade 
 
 
 
 
 
 
 
 
Figura 19. 
 
 
 
Exemplo: Funcionário trabalha em Departamento. 
 
 
Neste exemplo temos duas entidades: Funcionário e Departamento. A representação dessas 
duas entidades fica da seguinte forma: 
 
 
 
 
FUNCIONÁRIO DEPARTAMENTO 
 
 
 
 
 
 
 
 
Figura 20. Exemplo de Entidade. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
———————————————————— 
18 Silberschatz, A; Korth, H. R. e Sudarshan, S. Sistemas de Bancos de dados. São Paulo: Makroon Books, 1999 
 
 
25 
 
 
 
 
4.2.2. Representação dos Atributos 
 
 
 
 
ENTIDADE 
 
 
 
Identificador 
dos atributos 
 
 
 
Figura 21. 
 
 
 
Exemplos de atributos da Entidade DEPARTAMENTO do exemplo anterior: 
 
• Código (do Departamento) 
 
• Nome (do Departamento) 
 
• Localização (do Departamento) 
 
 
 
 
DEPARTAMENTO 
 
 
 
cod_dept 
nome 
local 
 
 
 
 
Figura 22. Exemplo de atributo representado com a entidade. 
 
 
4.2.3. Representação dos Relacionamentos e Cardinalidade 
 
 
No método proposto por Martin devemos indicar a cardinalidade do relacionamento. Dessa forma 
temos: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
26 
 
 
 
 
Cardinalidade - 1:1 Esta linha indica que um departamento 
está relacionando com apenas um registro 
de funcionário 
 
 
 
 
FUNCIONÁRIO 
 
 
Código 
Nome 
Contratação 
Gerente 
Salário 
Comissão 
Departamento 
 
DEPARTAMENTO 
 
 
Código 
Nome 
Localização 
 
 
Esta linha indica que um funcionário 
está relacionado com apenas um 
registro de departamento 
 
Figura 23. 
 
 
 
 
Cardinalidade - 1:1 Esta linha indica que um departamento 
está relacionando com apenas um registro 
de funcionário 
 
 
 
FUNCIONÁRIO 
 
 
Código 
Nome 
Contratação 
Gerente 
Salário 
Comissão 
DEPARTAMENTO 
 
 
Código 
Nome 
Localização 
 
Esta linha indica que um funcionário 
está relacionado com apenas um 
registro de departamento 
 
Figura 24. 
 
 
 
Neste caso a leitura da relação das tabelas é: Cada funcionário está em um departamento e um 
departamento tem vários funcionários. 
 
 
 
 
 
 
 
 
 
 
27 
 
 
 
 
4.2.4. Relacionamento Opcional 
 
 
 
Esta linha indica que um departamento 
está relacionando com muitos registros 
de funcionário. A bola cheia indica 
participação opcional. 
 
 
 
FUNCIONÁRIO 
 
 
Código 
Nome 
Contratação 
Gerente 
Salário 
Comissão 
Departamento 
DEPARTAMENTOCódigo 
Nome 
Localização 
 
 
 
 
Esta linha indica que um funcionário 
está relacionado com apenas um 
registro de departamento. A bola vazia 
indica participação obrigatória. 
 
Figura 25. 
 
 
 
Neste caso a leitura da relação das tabelas é: cada funcionário deve estar em um departamento e 
um departamento pode ter vários funcionários. 
 
 
 
4.3. CASE*MethodTM 
 
 
A notação CASE*MethodTM, foi criada por Richard Baker, Ian Palmer, Harry Ellis na época em que 
eram funcionários da empresa britânica de consultoria CACI. O CASE*MethodTM é usado por 
grandes companhias, como a Oracle Corporation. É uma derivação da metodologia de James 
Martin e Peter Chen. Seu uso deve-se ao fato de estar mais focado para o desenho de banco de 
dados do que para a estrutura inerente dos dados da empresa. 
 
 
4.3.1. Representação da Entidade 
 
 
 
 
Identificador da entidade 
 
 
 
 
 
 
 
 
Figura 26. 
 
 
 
 
28 
 
 
 
 
4.3.2. Representação dos Atributos 
 
 
 
 
ENTIDADE 
 
 
Identificador 
dos atributos 
 
 
 
 
Figura 27. 
 
 
 
Um ou mais atributos descrevem uma entidade, e os valores desses atributos descrevem as 
ocorrências da entidade. 
 
• Os identificadores dos atributos (nomes) devem estar no singular e em letras minúsculas. 
 
• Os atributos obrigatórios ou que devem ser conhecidos são marcados com *. 
 
• Os opcionais ou valores que podem ser conhecidos devem ser marcados com º. 
Identificadores exclusivos (Chaves primárias) devem ser marcados com #. 
 
 
Exemplo: 
 
 
 
 
DEPARTAMENTO 
 
 
#* código 
* nome 
º localização 
 
 
 
Figura 28. 
 
 
4.3.3. Representação dos Relacionamentos 
 
 
 
Simbologia 
 
Descrição 
 
Representação 
 
Linha tracejada 
 
Elemento opcional indicando 
“pode ser” 
 
 
Linha sólida 
 
Elemento obrigatória 
indicando “deve ser” 
 
 
Pé de galinha 
 
Elemento de grau indicando 
“um ou mais” 
 
 
Linha única 
 
Elemento de grau indicando 
“somente um” 
 
 
Tabela 4. 
 
 
 
 
29 
 
 
 
 
Como o relacionamento indica a relação entre duas entidades para cada direção do 
relacionamento, são necessários: 
 
• um label, verbo que indica o relacionamento; 
 
• uma opcionalidade, indicando que algo deve ser ou pode ser; 
 
• um grau (ou cardinalidade) indicando somente um ou um ou mais. 
 
 
Exemplo: 
 
 
 
 
FUNCIONÁRIO DEPARTAMENTO 
 
 
#* número 
* nome 
º cargo 
 
Trabalha em 
 
 
 
composto de 
#* código 
* nome 
º localização 
 
 
Figura 29. 
 
 
 
4.4. ERWin19 
 
 
O software ERWin foi criado pela Logic Works, sendo uma ferramenta para o projeto de sistemas 
cliente-servidor de banco de dados. A principal característica do software é a existência de 
editores que definem os objetos lógicos e físicos do Banco de Dados, e de suporte à linguagem 
de definição de dados dos diversos servidores de banco de dados, SQL e não SQL. Utilizando-se 
de uma interface totalmente gráfica, padrão Windows, esta ferramenta permite uma modelagem 
completa de entidades e relacionamentos, a partir de ferramentas de desenho, tornando sua 
utilização extremamente fácil. 
 
Esta ferramenta gera o modelo lógico e físico para diversos gerenciadores de Banco de Dados, 
sejam eles SQL ou não SQL, distribuídos ou não. O ERWin é uma ferramenta de modelagem de 
dados com capacidade de gerar DDL para os principais RDBMS de mercado podendo incorporar 
triggers, stored procedures, regras de validação, domínios e templates. Uma de suas 
características mais avançadas é a capacidade de fazer engenharia reversa através de scripts ou 
direto do dicionário de dados do banco podendo, através da função “COMPLETE COMPARE”, 
oferecer um relatório detalhado das eventuais discrepâncias entre o modelo e a base ou script 
podendo inclusive promover a sincronização entre ambos. 
 
Ao acessarmos o software encontramos o menu principal: 
 
 
 
 
 
 
 
 
 
 
———————————————————— 
19 Extraido do manual on-line do ERWin, traducao livre do autor 
 
 
30 
 
 
 
 
 
 
 
 
 
 
 
 
Gerador de 
relatórios de 
modelagem 
Visão de nível de 
entidade (para 
trabalhar até a fase 
2 de modelagem) 
Visão completa 
(para trabalhar 
nas fases 3 e 4) 
Visões funcionais 
(subject areas, para 
dividir o modelo 
em partes) 
 
Figura 30. Barra de ferramentas do ERWin 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 31. Menu principal do ERWin. 
 
 
 
O software permite trabalhar com o modelo físico, com o lógico ou ambos. Para isso basta 
escolher o modelo na caixa: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
31 
 
 
 
 
 
 
 
 
 
Indica modelo físico/lógico 
 
 
 
 
Indica modelo lógico 
 
 
 
 
Indica modelo físico 
 
Figura 32. Opção para escolha do modelo. 
 
 
 
A figura 33. mostra a diferença ente os dois modelos. O modelo lógico não se preocupa com os 
futuros campos das tabelas e, sim, com a criação do dicionário de dados. O modelo físico 
preocupa-se com os campos das tabelas, suas chaves e restrições. 
 
 
Physical Model Logical Model 
 
MOVIE 
 
movie_number 
 
movie_director 
movie_description 
movie_rating 
movie_name 
movie_genre 
movie_rental_rate 
 
MOVIE 
 
movie_number 
 
rating 
rental_rate 
genre_ 
movie_clip 
description 
movie title_ 
 
 
 
 
MOVIE_COPY 
 
movie_number 
movie_copy_number 
 
movie_format 
general_condition 
MOVIE_COPY 
 
movie copy number 
movie number (FI<) 
 
General_condition 
movie_format 
 
 
Figura 33. Exemplo do modelo lógico e do modelo físico 
 
 
 
O ERWin distingue as entidades usando retângulos. Esses retângulos podem ter os cantos 
arredondados (soft-box) ou não. Quando o retângulo não tiver os cantos arredondados dizemos 
que irá dar origem a uma tabela pai. Quando o retângulo tiver os cantos arredondados ( soft-box) 
indica que irá dar origem a uma tabela filho, ou seja, irá receber uma chave estrangeira da tabela 
pai. 
 
Não importa se você estiver usando o modelo físico ou lógico, você pode escolher a notação que 
deseja trabalhar. O ERWin trabalha com duas notações: 
 
 
 
 
32 
 
 
 
 
• IDEF1X (Integration DEFinition for Information Modeling) ou 
 
• IE (Information Engeneering) 
 
 
 
IDEF1X e IE usam símbolos diferentes para representar o relacionamento entre entidades e 
tabelas. A figura 34. mostra a diferença entre as duas notações. 
 
 
 
 
 
 
STORE 
store number 
 
manager 
address 
phone 
IDEF1X 
 
 
 
 
 
rents / 
is in 
 
MOVIE 
movie_number 
 
name 
director 
description 
star 
rating 
genre 
rental_rate 
 
 
 
 
 
STORE 
store number 
 
manager 
address 
phone 
IE 
 
 
 
 
 
rents / 
is in 
 
MOVIE 
movie_number 
 
name 
director 
description 
star 
rating 
genre 
rental_rate 
 
 
Figura 34. Diferença entre a notação IDEF1X e IE. 
 
 
 
A notação defaulf usada pelo ERWin é IDEF1X mas pode ser alterado a qualquer momento. 
Basta entrar em Model, Properties, e escolher a notação. Para os modelos físicos existe a opção 
de DM (Dimensional Notation) que é usado para modelagem de Datawarehouse. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
33 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DM option displays in 
physical models only 
 
 
Figura 35. Alterando o modelo. 
 
 
 
O toolbox é alterado conforme o modelo escolhido. Veja exemplo na figura 36. 
 
 
 
 
Logical 
IE Notation 
Physical 
 
 
 
 
 
 
 
IDEF1X Notation 
 
Logical 
 
 
Physical 
 
 
 
 
 
 
 
 
Figura 36. Diferença entre a notação IE e a IDE1X. 
 
 
 
Existem três tipos de relacionamentos no ERWin: 
 
• O relacionamento identificado, representado pela linha contínua com uma bola cheia na ponta 
(Notação IDEF1X) ou com um pé de galinha (Notação IE) 
 
• O relacionamento não-identificado, representado pela linha tracejada com uma bola cheia na 
ponta (Notação IDEF1X) ou com um pé de galinha (Notação IE) 
 
• O relacionamento muitos-para-muitos, representado pela linha contínua com uma bola cheia 
em cada ponta (Notação IDEF1X) ou com um pé de galinha em cada ponta (Notação IE) 
 
34No caso do relacionamento identificado a chave primária da tabela pai faz parte da chave primária 
da tabela filho. 
 
No caso do relacionamento não-identificado a chave primária não faz parte da chave primária da 
tabela filho. A figura 37. nos ajuda a compreender melhor.. 
 
 
 
CUSTOMER 
 
customer number 
 
credit card 
customer first_name 
 
 
Identifying 
relationship 
 
 
 
migrated 
key attribute 
credit card exp 
status code 
customer address 
customer phone 
email 
 
 
migrated 
non-key attribute 
 
MOVIE RENTAL RECORD 
 
customer number 
rental record date 
 
due date 
rental status 
payment transation number 
overdue charge PAYMENT 
 
payment transation number 
 
type 
amount 
date 
status 
 
rental rate 
rental date 
 
 
non-identifying 
relationship 
 
 
Figura 37. Exemplo de relacionamento identificado e não-identificado. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
35 
 
 
 
 
4.5. Quadro Resumido 
 
 
 Peter Chen 
 
James Martin CASE 
*MethodTM IDEF1X IE 
 
Entidade 
ENTIDADE 
 
 
Atributos 
ENTIDADE 
 
atributo chave 
 
 
Atributos 
 
Atributo 
 
Relacionamento 
 
 
Cardinalidade 
 
 
0 : 1 
 
 
 
0 : N 
 
 
 
1 : 1 
 
 
 
1 : N 
 
 
 
N : M 
 
 
Figura 38. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
36 
 
 
 
 
 
 
5. Entidade 
 
 
 
De acordo com o que vimos nos capítulos anteriores. uma entidade 20 ou classe de entidade é 
uma representação abstrata de “coisas semelhantes”, concretas ou abstratas, que existem no 
mundo real, sobre a qual um sistema de informação captura, armazena e processa dados para 
cumprir seus objetivos na empresa, atendendo, assim, às necessidades de seus usuários. 
 
 
 
5.1. Como identificar uma Entidade 
 
 
Com o tempo e a experiência em modelagem passamos a identificar as entidades de forma quase 
intuitiva, mas enquanto ainda não temos essa experiência podemos utilizar várias técnicas para 
isso, por exemplo na fase de levantamento podemos identificar as entidades através de 
substantivos. 
Uma outra técnica consiste na proposta apresentada Shlaer & Mellor 21 na qual podemos detectar 
as entidades através da observação de cinco grupos de elementos: 
 
• As coisas tangíveis 
 
• As funções exercidas por elementos 
 
• Eventos ou ocorrências 
 
• Interações 
 
• Especificações 
 
 
Segundo Cougo[2], esta separação das entidades será tratada como grupos de classificação que 
serão úteis apenas para identificação das entidades. 
 
Coisas tangíveis – Tudo aquilo que pode ser tocado, que tem existência concreta. 
 
Exemplos: caminhão, computador, moto, tear. 
 
O agrupamento desses objetos em Entidades dependerá do nível de abstração que se deseja 
atingir na modelagem do ambiente observado. 
 
 
 
Por exemplo: 
 
 
 
Entidade 
 
Objetos 
 
Produto 
 
Caminhão, computador, moto, tear 
 
Tabela 5. 
 
 
 
———————————————————— 
20 As entidades são representadas por tabelas na etapa de implementação do Banco. 
21 apud Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 
 
 
37 
 
 
 
 
Atingindo um nível de abstração maior podemos ter: 
 
 
 
Entidade 
 
Objetos 
 
Veículo 
 
Caminhão, moto 
 
Equipamento 
 
computador, tear 
 
Tabela 6. 
 
 
Podemos abstrair um pouco mais e ter: 
 
 
 
Entidade 
 
Objetos 
 
Caminhão 
 
Todos os caminhões observados 
 
Moto 
 
Todas as motos observadas 
 
Computador 
 
Todos os computadores observados 
 
Tear 
 
Todos os teares observados 
 
Tabela 7. 
 
 
 
Funções – Papel, atribuição, classificação ou outra característica que especifique a atuação de 
um objeto identificado no ambiente observado. 
 
Exemplos: Uma analista de suporte, um engenheiro civil, departamento de Recursos Humanos. 
 
 
 
Entidade 
 
Objetos 
 
"Coisa" Tangível 
 
Especialista 
 
Analista, Engenheiro 
 
Pessoa 
 
Tabela 8. 
 
 
 
Abstraindo um pouco mais temos: 
 
 
 
Entidade 
 
Objetos 
 
"Coisa" Tangível 
 
Analista 
 
Todas as especialidades 
de analista 
 
Pessoa 
 
Engenheiro 
 
Todas as especialidades 
de engenheiro 
 
Pessoa 
 
Tabela 9. 
 
 
 
 
 
 
 
 
 
 
 
38 
 
 
 
 
Eventos ou ocorrências – Cougo22 define como objetos que são materializáveis quando alguma 
ação ou fato acontece. “Enquanto programado, durante sua execução ou após encerrado, esse 
elemento caracteriza-se como um evento ou ocorrência ao qual podemos fazer alguma 
referência.” 
 
Exemplos: Uma partida de futebol, um vôo de avião, uma viagem de carro. 
 
 
Interações – Resultantes da associação entre objetos em função de um processo sendo 
executado. Também podem ser modelados como entidades associativas (relacionamentos). 
 
Exemplos: A compra de um imóvel, a venda de um produto a um cliente. 
 
 
Especificações – Entidades que reúnem as características de objetos pertencentes a outros 
objetos. Podem ser identificados já na modelagem conceitual, ou aparecerem somente no modelo 
lógico, em função da aplicação de técnicas de normalização. 
Exemplo: Automóvel; Modelo do automóvel 
 
Automóvel é uma “coisa” tangível que poderíamos detalhar com os atributos: cor, modelo, ano de 
fabricação entre outros. 
 
Já a entidade Modelo do automóvel é uma entidade que específica (detalha) dados sobre o 
modelo tais como: banco de couro, direção hidramática, cambio hidráulico, farol de milha, entre 
outros. 
 
 
 
5.2. Representações de Entidade 
 
 
O símbolo utilizado para representação de uma entidade depende da metodologia escolhida para 
a modelagem, conforme vimos nos capítulos anteriores. Neste material utilizaremos a 
metodologia proposta por Peter Chen e em alguns exemplos ilustraremos como é a 
representação utilizada pelo Erwin23. 
 
 
 
Peter Chen 
 
Erwin 
 
 
 
 
IDENTIFICADOR 
DA 
ENTIDADE 
 
IDENTIFICADOR DA ENTIDADE 
 
Figura 39. 
 
 
 
 
 
 
 
———————————————————— 
22 Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 
23 Ferramenta de Modelagem relacional comercializada pela empresa Computer Associates. 
 
 
39 
 
 
 
 
 
Exemplos: 
 
 
1. Sistema de Controle de Conta Corrente 
 
 
No ambiente de um sistema de controle de conta corrente, temos pessoas que são clientes de um 
banco. Pode-se então definir uma entidade cliente. Neste mesmo sistema, as contas mantidas no 
banco poderão ser definidas como uma entidade conta. 
 
 
 
 
CLIENTE CONTA 
 
 
 
Figura 40. 
 
 
 
Exemplo: Sistema de Controle de contas de um Hospital 
 
No contexto de um sistema de controle de contas de um hospital, algumas pessoas 
desempenham a função de médicos. Neste mesmo sistema, as pessoas que irão realizar uma 
consulta desempenham a função de pacientes. Estas pessoas são ocorrências de entidades 
distintas: médicos e pacientes. Note que um médico em um determinado momento também pode 
desempenhar a função de um paciente. 
 
 
 
 
MÉDICO PACIENTE 
 
 
Figura 41. 
 
 
 
Atenção: O identificador de uma entidade deve ser um nome relevante ao assunto que 
representará e recomenda-se que: 
 
• Não sejam utilizados caracteres especiais tais como acento, cedilha, *, $, entre outros; 
 
• Não seja iniciado por números; 
 
• Esteja no singular. 
 
 
Na etapa de implementação do modelo deve-se também atentar para as recomendações e 
particularidades do SGBDR utilizado. 
 
 
 
5.3. Cuidado: Aquilo que é entidade numa circunstância, pode não ser 
em outra! 
 
 
 
Portanto, ao identificar as entidades de um sistema de informação, os desenvolvedores de 
software devem estar atentos à possibilidade de uma “coisa do mundo real” desempenhar mais 
de um papel no contexto deste sistema. 
 
 
 
40 
 
 
 
 
5.4. Tipos de Entidades 
 
 
5.4.1. Entidade Meramente Conceitual 
 
 
Uma entidade meramente conceitual é aquela que representa uma classe de domínio e que não 
tem outras propriedades que não seu próprio conceito. 
 
Exemplos: Data, Hora,Período 
 
 
5.4.2. Entidade Forte 
 
 
Uma entidade forte é aquela que não depende de outra entidade para existir. Exemplo: No 
contexto de uma organização faz-se necessário o armazenamento de dados de um funcionário 
por diversas demandas, uma delas é a folha de pagamento. Cada ocorrência de funcionário é r 
identificada de forma única, por exemplo por uma atributo identificado por registro funcional, 
sendo assim a entidade funcionário é uma entidade forte. 
 
 
5.4.3. Entidade Fraca 
 
 
Entidades cuja existência depende da existência de outra entidade, dita forte. É representada por 
um retângulo duplo, podendo, opcionalmente, ser indicada uma seta que parte dela e chega a sua 
entidade forte, para tornar mais clara a dependência. A cardinalidade de uma ocorrência de uma 
entidade fraca com a forte é sempre (1,1), indicando que ela sempre depende de uma ocorrência 
da entidade forte. 
 
Em poucas palavras, entidade fraca é aquela que depende de uma outra entidade para existir. À 
entidade da qual depende dá-se o nome de entidade pai. 
 
Exemplo: Os funcionários de uma empresa possuem dependentes, por exemplo, seus filhos, 
cujos dados são utilizados por exemplo para concessão de benefícios ou descontos de IRRF. Os 
dados de dependentes estão relacionados diretamente à existência de uma ocorrência de 
funcionário. 
 
 
 
 
1 : 1 possui
 0 : N 
FUNCIONÁRIO DEPENDENTE 
 
 
 
Figura 42. 
 
 
5.4.4. Entidade Associativa 
 
 
Uma entidade associativa é aquela que não existe por si só e sua existência está condicionada à 
existência de duas ou mais entidades, a partir das quais ela é concebida. 
 
 
 
 
 
 
41 
 
 
 
 
Exemplo: 
 
 
A entidade associativa aluno x disciplina surge quando há a derivação do modelo lógico a partir 
do modelo conceitual devido ao relacionamento n:n entre a entidade aluno e a entidade 
disciplina24. 
 
 
5.4.5. Entidade de Dados 
 
 
Podem ser subdivididas em diversas categorias de elementos (Subtipos), cada uma se 
caracterizando por atributos específicos. 
 
 
 
Pessoa 
 
 
 
Física Jurídica 
 
 
 
 
Figura 43. 
 
 
 
Supertipo: É o conjunto de características que originou o subtipo. 
 
Subtipo: É definido como um subconjunto de características de um tipo. 
 
 
Exemplo: Supertipo pessoa e subtipos Pessoa Física e Pessoa Jurídica. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
———————————————————— 
24 Veja tópico sobre Derivação do Modelo Lógico a partir do Modelo Conceitual nos capítulos anteriores. 
 
 
42 
 
 
 
 
 
 
6. Atributos 
 
 
 
Conforme vimos anteriormente, cada entidade tem propriedades particulares, chamadas atributos, 
estas propriedades podem identificar, qualificar ou quantificar a entidade, em outras palavras os 
atributos descrevem as entidades. Por exemplo, uma entidade funcionário pode ser descrita pelo 
seu nome, o trabalho que realiza, data de nascimento, endereço e salário. Cada ocorrência de 
uma entidade terá um valor para cada um de seus atributos. 
 
 
 
6.1. Como Identificar os Atributos 
 
 
Para identificar um atributo devemos estabelecer quais são suas características. Remetendo-nos 
a entidade funcionário, podemos perguntar “Quais são as características de um funcionário? O 
que o identifica?”. Responder a essas perguntas traz os atributos da entidade. 
 
No nosso exemplo, as respostas poderiam ser: Nome, Endereço, Telefone, Data de Nascimento, 
Cargo, Salário, Código do Funcionário. Percebam que essas características são os atributos do 
funcionário. 
 
 
 
6.2. Representações de Atributos 
 
 
Assim como para as entidades, a representação de uma atributo depende da metodologia 
escolhida para a modelagem, conforme vimos nos capítulos anteriores. Neste material 
utilizaremos a metodologia proposta por Peter Chen que utiliza uma elipse para representar os 
atributos e em alguns exemplos ilustraremos como é a representação utilizada pelo Erwin 25. 
 
 
 
Peter Chen Erwin 
 
 
FUNCIONÁRIO 
 
 
 
 
 
cod_func endereço 
dt_nasc 
 
nome cargo 
 
FUNCIONARIO 
cod_func 
nome 
dt_nasc 
cargo 
endereco 
Figura 44. 
 
 
 
 
 
———————————————————— 
25 Ferramenta de Modelagem relacional comercializada pela empresa Computer Associates. 
 
 
43 
 
 
 
 
6.3. Classificação de Atributos 
 
 
Cougo26 classifica os atributos em três grupos: 
 
 
• Atributos Descritivos: Atributos que expressam características intrínsecas ao objeto, isto é, 
que representam qualidades ou descrições de um objeto. Por exemplo: data de nascimento, 
endereço, cor dos cabelos, peso, sexo, modelo de um automóvel. 
 
• Atributos Nominativos: Atributos que podem identificar um objeto, mesmo que não o faça de 
maneira única. Por exemplo: Nome de um funcionário, Registro acadêmico de um aluno, 
Código do produto, Placa de um automóvel. 
 
Atenção: Os atributos nominativos podem ser chaves candidatas e aqueles que atendem aos 
critérios podem vir a ser chaves primárias. 
 
• Atritutos Referenciais: Atributos que não pertencem à entidade a qual estão alocados, mas 
que fazem algum tipo de citação ou estabelecem uma relação entre esta entidade e a 
entidade de origem. Normalmente estes atributos são as chaves estrangeiras. No exemplo 
apresentado a seguir note que a entidade FUNCIONARIO tem o atributo cod_dept (código do 
departamento), mas este atributo, originalmente é um atributo nominativo da tabela 
DEPARTAMENTO, sendo assim para a entidade FUNCIONARIO este atributo é um atributo 
referencial, pois será utilizado para estabelecer um relacionamento 27 com a tabela 
DEPARTAMENTO. 
 
 
 
 
FUNCIONÁRIO DEPARTAMENTO 
 
 
 
 
 
cod_func cod_dept 
 
 
nome_func end 
cod_func nome_dept cod_dept 
 
 
Figura 45. 
 
 
6.4. Tipos de atributos 
 
 
Independente da sua classificação um atributo pode possuir características que nos possibilitam 
defini-los como: 
 
• Atributo Simples 
 
• Atributo Composto 
 
• Atributo Monovalorado 
 
 
———————————————————— 
26 Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 
27 Este assunto foi apresentado anteriormente e será detalhado no próximo capítulo 
 
 
44 
 
 
 
 
• Atributo Multivalorado 
 
• Atributo Derivado ou virtual 
 
• Atributo Opcional 
 
• Atributo Chave 
 
 
6.4.1. Atributo Simples 
 
 
Atributos que não são divisíveis são chamados simples ou atômicos, por exemplo o atributo cargo 
para a entidade FUNCIONARIO. 
 
 
6.4.2. Atributo Composto 
 
 
Alguns atributos podem ser divididos em subpartes com significados independentes. Um atributo 
que é composto de outros atributos mais básicos é chamado composto. 
 
Atenção: Atributos compostos podem formar uma hierarquia. 
 
No exemplo a seguir o endereço da entidade FUNCIONARIO pode ser dividido em endereço da 
rua, cidade, estado e cep; o atributo endereço da rua pode ser subdividido em nome da rua, 
numero do imóvel e complemento. 
 
 
 
 
FUNCIONÁRIO 
 
 
 
 
 
 
cod_func cod_dept 
 
nome_func end 
 
 
 
cep UF 
 
end_rua cidade 
 
 
 
 
nome_rua complemento 
 
 
número 
 
 
Figura 46. 
 
 
 
Atributos compostos são úteis quando os usuários referenciam o atributo composto como uma 
unidade e, em outros momentos, referenciam especificamente a seus componentes. Se o atributo 
 
 
45 
 
 
 
 
composto for sempre referenciado como um todo, não existe razão para subdividi-lo em 
componentes elementares. 
 
 
6.4.3. Atributo Monovalorado 
 
 
Um atributo monovalorado - também chamado de univalorado - possui um valor único, ou seja, só 
existe uma representação daquele atributo para a mesma tupla. Vejamos, por exemplo, o atributo 
idade: um funcionário nunca poderá ter mais de uma idade ao mesmo tempo, o que torna esse 
atributo monovalorado. 
 
 
6.4.4. Atributo Multivalorado 
 
 
Uma única entidade que tem ocorrências com diversos valores para este atributo. 
 
Atributos multivalorados podem possuir uma multiplicidade, indicando as quantidades mínima e 
máxima de valores.FUNCIONARIO 
1:1 0:N 
POSSUI 
 
DEPENDENTE 
 
 
 
 
 
 
cod_func dt_nasc endereco cod_finc nome 
 
 
nome cargo 
 
 
Figura 47. 
 
 
6.4.5. Atributo Derivado ou Virtual 
 
 
De acordo com Silberschatz [1] o valor deste tipo de atributo pode ser derivado de outros atributos 
ou entidades a ele relacionados. Por exemplo a idade de um funcionário pode ser obtida a partir 
da subtração entre o valor do atributo data de nascimento e a data corrente. 
 
Em outro caso, alguns valores de atributos podem ser derivados de entidades relacionadas, por 
exemplo, um atributo número de funcionários de uma entidade DEPARTAMENTO que pode ser 
calculado contando-se o número de funcionários relacionados com cada departamento. 
 
 
6.4.6. Atributo Opcional ou Nulo 
 
 
São atributos para os quais não existe a obrigatoriedade de preenchimento de dados, isto é, são 
atributos cujo preenchimento de dados é opcional. 
 
De acordo com Silberschatz [1] um atributo nulo é usado quando uma entidade não possui um 
valor para um determinado atributo. Por exemplo, o atributo complemento aplica-se somente 
 
46 
 
 
 
 
àqueles funcionários que residam em algum prédio ou vila, nesse caso nas ocorrências da 
entidade FUNCIONARIO para as quais os dados do atributo complemento não forem informados 
o valor deste atributo será nuto. 
 
Atenção: O nulo pode ser utilizado para denotar que o valor é desconhecido ou inexistente. 
 
 
6.4.7. Atributo Chave 
 
Os atributos utilizados para identificar uma entidade, para indexar as ocorrências da entidade ou 
os atributos referenciais são chaves. Conforme vimos anteriormente as chaves podem ser: 
 
• Chave Primária: É um atributo ou um conjunto de atributos que identifica unicamente cada 
ocorrência da entidade, sendo assim, uma ocorrência não pode conter, neste atributo, um dado 
(valor) que já esteja armazenado em outra ocorrência. 
 
Exemplo: No contexto de um sistema de controle acadêmico o número de matricula de uma 
entidade aluno é um atributo identificador já que identifica de forma única um aluno dentro de 
uma faculdade. 
 
• Chave Estrangeira: É um atributo ou conjunto de atributos usado para estabelecer um 
relacionamento entre duas entidades. Na entidade de origem deve ser chave primária. 
 
• Chave Secundária(Terciária, etc): São chaves que possibilitarão pesquisas ou ordenações 
alternativas, ou seja, diferentes da ordem criada a partir da chave primária ou da ordenação 
natural (física) da tabela. 
 
• Chave Composta: É a chave que contém mais de um atributo (Por exemplo, um cadastro 
ordenado alfabeticamente por Estado, Cidade e Nome do Cliente, necessitaria de uma chave 
composta que contivesse estes três atributos). 
 
• Chave candidata: São atributos que podem vir a ser chave primária. 
 
Exemplo: A entidade FUNCIONARIO tem os atributos: registro funcional, nome, cpf, rg, 
endereco, dt_nascimento. Os atributos registro funcional, cpf e rg são chaves candidatas, pois 
podem identificar cada ocorrência de FUNCIONARIO. Mas para que uma chave candidata 
possa ser eleita a chave primária deverá atender a restrição de unicidade, isto é o conteúdo do 
campo deverá ser único para cada ocorrência da entidade. 
 
A seguir apresentamos um exemplo de classificação de atributos para as entidades 
FUNCIONARIO, DEPARTAMENTO e DEPENDENTES: 
 
 
 
 
ENTIDADE 
 
FUNCIONÁRIO 
 
Classificação dos Atributos 
 
 
 
 
atributos 
reg_funcional atributo nominativo – chave primária 
 
nome_func 
 
atributo nominativo – chave candidata 
 
endereço 
 
atributo descritivo composto 
 
cpf 
 
atributo nominativo – chave candidata 
 
rg 
 
atributo nominativo – chave candidata 
 
cod_dept 
 
atributo referencial – chave estrangeira a origem do atributo 
está na entidade DEPARTAMENTO. 
 
Tabela 10. 
 
 
47 
 
 
 
 
 
ENTIDADE 
 
DEPENDENTE 
 
Classificação dos Atributos 
 
 
 
 
 
 
 
atributos 
 
reg_funcional 
 
atributo referencial – chave estrangeira 
 
cod_dependente 
 
atributo nominativo – junto com o atributo 
reg_funcional compõe a chave primária; esta é uma 
entidade FRACA, pois a existência de uma ocorrência desta 
entidade depende de um relacionamento com a entidade 
FUNCIONÁRIO; não possui um atributo que sozinho consiga 
identificar cada ocorrência da entidade. 
 
data_nascimento 
 
atributo descritivo 
 
parentesco 
 
atributo descritivo 
 
nome_dependente 
 
atributo nominativo 
 
Tabela 11. 
 
 
 
 
 
ENTIDADE 
 
DEPENDENTE 
 
Classificação dos Atributos 
 
 
 
 
 
 
 
atributos 
 
reg_funcional 
 
atributo referencial _ chave estrangeira 
 
cod_dependente 
 
atributo nominativo – junto com o atributo reg_funcional 
compôe a chave primária; esta é uma entidade FRACA, pois 
a existência de uma ocorrência desta entidade depende de 
um relacionamento com a entidade FUNCIONÁRIO; não 
possui um atributo que sozinho consiga identificar cada 
ocorrência da entidade. 
 
data_nascimento 
 
atributo descritivo 
 
parentesco 
 
atributo descritivo 
 
nome_dependente 
 
atributo nominativo 
 
Tabela 12. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
48 
 
 
 
 
 
 
7. Relacionamentos 
 
 
 
7.1. Introdução 
 
 
De acordo com Machado [3] os relacionamentos podem ser definidos como o fato ou o 
acontecimento que liga dois objetos (entidades), duas “coisas” do mundo real. No ambiente 
relacional podemos entender o relacionamento como o fato que efetua a junção de duas ou mais 
tabelas de dados. 
 
 
 
 
F1 P1 
F2 
 
F3 P2 
 
Funcionário Trabalha Projeto 
 
 
 
N N 
Funcionário Trabalha Projeto 
 
 
 
Figura 48. Relacionamento Binário. 
 
 
 
Um relacionamento estabelece a conexão entre duas tabelas dentro de um banco de dados. Este 
relacionamento entre tabelas é possível através da relação entre as chaves primária e 
estrangeira ou através de uma terceira tabela chamada tabela de vínculo. Esta conexão entre 
tabelas depende do tipo de relacionamentos existente entre elas. 
 
 
 
7.2. Porque um Relacionamento é fundamental dentro de um Banco de 
Dados? 
 
 
• Estabelece uma conexão entre tabelas que estão logicamente relacionadas, entre os dados 
contidos nelas. 
 
• É o mecanismo que permite que dados de várias tabelas sejam agrupados para extração 
simultânea. 
 
• Permite aprimorar as definições das estruturas de tabelas e a redução de dados redundantes. 
 
• Estabelece a integridade em nível de relacionamento quando é definido corretamente. 
 
 
A importância na definição dos relacionamentos corretamente está relacionada com a qualidade 
do banco de dados projetado, pois se mal projetados trarão prejuízo na manipulação simultânea 
entre tabelas, para inserção, atualização e exclusão de registros em tabelas relacionadas. 
 
 
 
49 
 
 
 
 
7.3. Como Identificar os Relacionamentos? 
 
 
De acordo com Cougo28, o que estabelecerá relacionamentos válidos ou não será o grau de 
fidelidade e completeza que se consegue atingir durante o processo de modelagem. Segundo ele 
são possíveis os relacionamentos entre instâncias de objetos (entidades) de diferentes tipos ou 
relacionamentos entre instâncias de um mesmo tipo de objeto (entidade). 
 
Para identificarmos a existência dos relacionamentos entre as entidades basta observarmos como 
estes objetos (entidades) se comportam no mundo real, por exemplo se tivermos a seguinte 
situação: 
 
Matheus é proprietário de um imóvel na praia de Ubatuba. 
 
Cougo29 sugere as seguintes etapas para identificação e mapeamento dos relacionamentos: 
 
 
• Identificar as entidades envolvidas. 
Matheus é uma ocorrência30 da entidade que chamaremos de PESSOA; 
 
Imóvel na praia de Ubatuba é uma ocorrência da entidade que chamaremos de IMOVEL 
 
 
• Identificar os atributos das entidades. 
 
Atenção: Para isso é importante valer-se das técnicas para levantamento de dados e análise 
de requisitos. 
 
PESSOA pode ser caracterizada pelos atributos: nome, data de nascimento, rg, cpf 
 
IMOVEL pode sercaracterizado pelos atributos: endereço, tamanho, tipo 
 
 
• Representação das entidades 
 
 
 
PESSOA IMÓVEL 
 
 
Figura 49. 
 
 
 
• Identificação dos relacionamentos 
 
PESSOA é proprietária de um IMÓVEL. 
 
 
• Caracterização do relacionamento entre as entidades 
 
Nem toda PESSOA é proprietária de um IMOVEL. 
Um IMOVEL pode (ou não) pertencer a uma ou muitas ocorrências da entidade PESSOA. 
Algumas ocorrências de PESSOA poderão possuir mais de um IMOVEL. 
 
 
———————————————————— 
28 Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 
29 Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 
30 Ocorrência, instância e registro são similares. 
 
50 
 
 
DEPARTAMENTO 
deptno nome-dept Loc 
 
10 
 
Accouting 
 
New 
 
20 
 
Research 
 
YorkDallas 
 
30 
 
Sales 
 
Chicago 
 
40 
 
operations 
 
Boston 
 
 
 
• Representação do Relacionamento 
 
 
 
 
PESSOA 
0:N 0:N 
Possui 
 
IMÓVEL 
 
 
 
Figura 50. Relacionamento entre PESSOA X IMÓVEL - metodologia de Peter Chen 
 
 
 
Observe no exemplo apresentado que o primeiro passo para identificar o relacionamento é 
compreender como “as coisas” se comportam no mundo real, a partir deste entendimento é 
possível caracterizar o relacionamento entre elas, isto é, definir o grau do relacionamento entre as 
entidades. Em outras palavras, definir se uma ocorrência de uma entidade poderá ou deverá se 
relacionar com uma ou muitas ocorrências da outra tabela e vice-versa. 
 
 
 
7.4. Cardinalidade 
 
 
A cardinalidade ou grau do relacionamento é uma restrição que expressa o número de 
ocorrências de uma entidade ao qual outra entidade pode estar associada por meio de um 
relacionamento. Por exemplo: 
 
– Todo FUNCIONARIO trabalha em um DEPARTAMENTO. 
 
– O DEPARTAMENTO pode ter muitos FUNCIONARIOS. 
 
A seguir, considerando a caracterização do relacionamento entre as entidades FUNCIONARIO e 
DEPARTAMENTO veja como é a relação entre as ocorrências das entidades: 
 
 
 
FUNCIONÁRIO 
 
cod_func 
 
nome_func 
 
deptno 
 
7839 
 
King 
 
10 
 
7782 
 
Clark 
 
10 
 
7566 
 
Jones 
 
20 
 
7698 
 
Blake 
 
30 
 
Tabela 13. 
 
 
 
– O FUNCIONÁRIO King trabalha no DEPARTAMENTO 10. 
 
– O FUNCIONÁRIO CLARK trabalha no DEPARTAMENTO 10. 
 
– O DEPARTAMENTO 10 possui 2 ocorrências de FUNCIONARIO (King e Clark), mas cada 
uma destas ocorrências de FUNCIONARIO está associada a apenas uma ocorrência de 
DEPARTAMENTO (10). 
 
 
 
 
 
51 
 
 
Departamento possui um/ 
 trabalha em
 
 
 
As cardinalidade possíveis são: 
 
• Zero-para-um (0:1) - Uma entidade A pode estar associada a uma entidade em B, não havendo 
obrigatoriedade de associação da entidade B com a entidade A. 
 
• Zero-para-muitos (0:N) - Uma entidade em A pode estar associada a qualquer número de entidades 
em B, não havendo obrigatoriedade de associação da entidade B com a entidade A. É um caso 
específico da cardinalidade N:M onde N vale 0. 
 
• Um-para-um (1:1) - Uma entidade em A está associada a no máximo uma entidade em B, e uma 
entidade em B está associada a no máximo uma entidade em A. 
 
• Um-para-muitos (1:N) - Uma entidade em A está associada a qualquer número de entidades em B, 
entretanto uma entidade em B está associada a no máximo uma entidade em A. 
 
• Muitos-para-muitos (N:N) - Uma entidade em A está associada a qualquer número de entidades em 
B, e uma entidade em B está associada a qualquer número de entidades em A. 
 
 
Exemplos: 
 
 
 
 
FUNCIONARIO 
1:1 1:1 
Trabalha 
em 
 
DEPARTAMENTO 
 
 
 
 
possui um/ 
Departamento Funcionário 
trabalha em 
 
 
 
 
Funcionário 
 
 
Figura 51. 
 
 
• Cada funcionário trabalha em um departamento 
 
• Um departamento pode conter nenhum ou muitos funcionários; 
 
 
 
 
 
FUNCIONARIO 
1:1 1:1 
Possui 
 
CONTRATO 
 
 
 
 
 
Funcionário 
possui um/ 
 
pertence a um 
 
Contrato 
 
 
 
Funcionário 
possui um/ 
 
pertence a um 
 
Contrato 
 
 
Figura 52. 
 
 
52 
 
 
 
 
• Cada funcionário possui um contrato 
 
• Cada contrato pertence a um funcionário 
 
 
 
 
 
FUNCIONARIO 
N:N N:N 
PARTICIPA 
 
PROJETO 
 
 
 
 
 
Funcionário 
participa de/ 
 
realizado por 
 
Projeto 
 
 
 
Funcionário 
participa de/ 
 
realizado por 
 
Projeto 
 
Figura 53. 
 
 
• Cada funcionário pode participar de muitos projetos 
 
• Cada projeto pode ser realizado por muitos funcionários 
 
 
 
 O que deve ser feito em casos de relacionamentos muitos-para-muitos 
 
 
Por definição o modelo relacional não permite a representação de relacionamentos 
muitos-para-muitos. Para resolver essa limitação do modelo relacional é preciso criar uma 
entidade intermediária conhecida como entidade associativa. A entidade associativa é, portanto, 
uma entidade intermediária gerada a partir de duas entidades com relacionamento 
muitos-para-muitos. 
 
Por exemplo, no caso das entidades FUNCIONÁRIO e PROJETO existe um relacionamento 
muitos-para-muitos porque muitos funcionários trabalham em muitos projetos e muitos projetos 
são executados por muitos funcionários. Nesse caso precisaremos de uma entidade associativa. 
A nova entidade será chamada de FUNCIONÁRIO/PROJETO e terá relacionamento 1:N com 
FUNCIONÁRIO e 1:n com PROJETO. A chave primária das entidades associativas é uma chave 
composta pela chave primária de FUNCIONÁRIO e pela chave primária de PROJETO. 
 
 
 
 
PROJETO 
N 1 FUNCIONÁRIO/ 
PROJETO 
1 N
FUNCIONÁRIO 
 
 
Figura 54. 
 
 
 
 
 
 
 
 
 
 
 
 
 
53 
 
 
 
 
 
 
8. Modelo Entidade Relacionamento Estendido 
 
 
 
8.1. Natureza do Relacionamento 
 
 
• Relacionamentos Parciais e Totais 
 
• Relacionamentos Recursivos ou Auto-Relacionamento 
 
• Relacionamentos Múltiplos 
 
• Agregação 
 
 
8.1.1. Relacionamentos Parciais e Totais 
 
Quando todo o elemento da entidade está obrigatoriamente no relacionamento, caso contrário 
temos um relacionamento parcial. 
 
 
 
 
 
Funcionário Lota 
N 1 
Departamento 
 
 
 
Figura 55. 
 
 
 
Todo funcionário obrigatoriamente ( | ) lota um departamento, mas nem todo (0) departamento é 
lotado por funcionários 
 
 
8.1.2. Relacionamentos Recursivos ou Auto-Relacionamento 
 
Os auto-relacionamentos são casos especiais onde uma Entidade se relaciona com si própria. 
Os auto-relacionamentos podem ser de tipo Um-para-Um, Um-para-Muitos ou 
Muitos-para-Muitos. 
 
 
 
 
Funcionário 
 
 
GERENCIA 
N 
GERENCIADO 
 
 
 
Gerencia 
 
 
 
 
Figura 56. 
 
 
54 
 
 
 
 
Funcionário desempenha o papel de gerente ou de subordinado. 
 
 
8.1.3. Relacionamentos Múltiplos / Agregação 
 
 
É a associação que envolve mais de duas Entidades. 
 
 
 
 
N N 
Professor Ensina 
 
Disciplina 
 
 
 
N 
 
 
Aluno 
 
 
Figura 57. 
 
 
 
Obs.: Para entendermos este relacionamento devemos cortar uma das arestas e fazermos um 
relacionamento binário. 
 
Devido a uma limitação do modelo E-R não é possível expressar relacionamentos entre 
relacionamentos. Para resolver esse problema usamos a agregação. 
 
Ao associarmos um conjunto de Entidades e um Relacionamento temos uma Agregação. A 
agregação é aplicada aos modelos para facilitar o entendimento semântico e tornar mais claros os 
graus dos relacionamentos ternários ou de maior número. A agregação é, na realidade, uma 
abstração do modelo E-R através da qual relacionamentos são tratados como entidades de nível 
superior. Vamos ver no exemplo: 
 
 
 
 
Funcionário N Trabalha 
N 
Projeto 
 
 
N N 
 
Utiliza 
 
 
N 
 
Máquina 
 
 
 
Figura 58. 
 
 
 
Temos um relacionamento N:N entre FUNCIONÁRIO e PROJETO, outro relacionamento N:N 
entre FUNCIONÁRIO e MÁQUINA e, por fim, outro relacionamento N:N entre MÁQUINA e 
PROJETO. Agora iremos representar o relacionamento entre duas entidades como se fosse uma 
nova entidade. Vamos considerar o relacionamento entre FUNCIONÁRIO e PROJETO como se 
fosse uma nova entidade e iremos representá-lacomo sendo uma nova entidade. A seguir 
 
 
 
55 
 
 
 
 
devemos estabelecer o relacionamento entre a entidade MÁQUINA e a nova entidade. Veja como 
essa operação fica representada graficamente: 
 
 
 
 
Funcionário N Trabalha N Projeto 
 N 
 
Utiliza 
 
 
N 
 
Máquina 
 
 
Figura 59. 
 
 
 
Note que o relacionamento é feito com a nova entidade e não com o relacionamento (a reta vai 
até a nova entidade e não até o relacionamento TRABALHA). 
 
A partir dessa nova modelagem podemos fazer uma releitura do modelo. Podemos interpretar que 
quando um funcionário trabalha em um projeto ele utilizará uma máquina. 
 
 
 
Funcionário N Trabalha N Projeto 
 N 
 
Utiliza 
 
 
N 
 
Máquina 
 
 
Figura 60. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
56 
 
 
 
 
 
 
N N 
Professor Ensina Disciplina 
 
 
 
N 
 
 
 
 
Cursa 
 
 
 
N 
 
 
Aluno 
 
 
Figura 61. 
 
 
 
O modelo E-R é uma ferramenta valiosa para qualquer sistema com múltiplos depósitos (objetos) 
e complexos relacionamentos de dados. Ele é inteiramente voltado para os relacionamentos de 
dados, sem oferecer quaisquer informações sobre as funções que criam ou utilizam os dados. 
 
 
 
8.2. Generalização-Especialização 
 
 
Existem casos em que uma entidade pode ser dividida em categorias, cada qual com atributos 
específicos, isto é, a entidade pode possuir subclasses ou pertencer asuperclasses. 
 
A associação entre uma Generalização (superclasses) e suas Especializações (subclasses) é 
representado por um triângulo e recebe o nome de "IS A" (é um). 
 
 
 
 
 
Filial 
 
N N 
atende Cliente 
Código 
 
Nome 
 
 
 
 
CIC 
 
 
Sexo 
 
 
Pessoa 
Física 
 
 
Pessoa 
Jurídica 
 
 
CGC 
 
 
Figura 62. 
 
 
 
No caso temos a Super-Classe CLIENTE e as Sub-Classes PESSOA FÍSICA e PESSOA 
JURÍDICA. O que diferencia essas duas subclasses são alguns poucos atributos. 
 
 
57 
 
 
 
 
O uso de uma estrutura de Generalização-Especialização também é conhecido como 
PARTICIONAMENTO. Sua principal utilidade é que com ele podemos representar ENTIDADES 
com ATRIBUTOS parcialmente disjuntos, além de permitir que um RELACIONAMENTO fique 
restrito a um subconjunto de uma ENTIDADE. 
 
Uma superclasse é, portanto, uma GENERALIZAÇÃO de um conjunto de ESPECIALIZAÇÕES 
(subclasses). Cada ESPECIALIZAÇÃO herda atributos e relacionamentos da ENTIDADE da qual 
derivou. O RELACIONAMENTO entre Especializações de uma mesma Generalização é um tipo 
de Auto-Relacionamento. 
 
 
 
 
9. Normalização 
 
 
 
A Normalização é um processo formal passo a passo que examina os atributos de uma entidade 
com o intuito de evitar anomalias de armazenamento de tuplas (registros) específicas. Esse 
processo causa a simplificação dos atributos dentro da respectiva tupla, eliminando grupos 
repetitivos, dependências parciais de chaves concatenadas, dependências transitivas, entre 
outros, colaborando sobremaneira para integridade e a estabilidade do modelo. A experiência tem 
mostrado que o investimento de tempo que se faz para efetuar manutenções em uma base de 
dados implementada é inversamente proporcional ao tempo aplicado no processo de 
normalização. 
 
Para se atingir esse estágio, é necessário que as tuplas sejam analisadas de modo a verificar se 
seus atributos apresentam relações não normalizadas, submetendo-as a conceitos subseqüentes 
de primeira, segunda e terceira forma normal (FN). 
 
Há também outras formas normais superiores à terceira FN, ou seja, Boyce-Cood (BCFN), quarta 
forma normal, quinta forma normal e chave-domínio, que visam a agrupar atributos em tuplas 
mais refinadas e distintas a fim de se evitarem anomalias específicas. Porém, atingir o nível de 
terceira forma normal é suficiente para a maioria dos propósitos práticos de normalização, sendo 
rara a necessidade de perseguir formais superiores. 
 
A normalização é um mecanismo para transformar estruturas complexas de dados em sua forma 
mais simples. Portanto, diz-se que uma estrutura de dados está "normalizada" quando está em 
seu estágio de maior simplicidade. 
 
Simplicidade de uma estrutura pode ser definida como a existência de apenas dependência 
funcional. Assim, uma tabela deve conter apenas informações que se refiram a um mesmo tipo de 
dados, ou seja, todas as colunas da tabela devem depender funcionalmente da chave primária. 
 
Em resumo, a normalização consiste em descobrir o lugar certo para cada coisa e colocar cada 
coisa em seu devido lugar, com o objetivo de: 
 
• minimização de redundâncias e inconsistências; 
 
• facilidade de manipulações do Banco de Dados; 
 
• facilidade de manutenção do Sistema de Informações. 
 
 
Os três principais casos de anomalias que caracterizam uma estrutura desnormalizada são: 
 
• Grupo Repetitivo: Conjunto de atributos de uma entidade que ocorre múltiplas vezes para 
cada ocorrência da Entidade. 
 
58 
 
 
 
 
• Dependência Funcional Parcial: Quando um atributo depende de parte da chave primária 
(chave composta) 
 
• Dependência Transitiva: Dependência indireta entre dois ou maisatributos. 
 
 
 
9.1. Primeira Forma Normal (1FN) 
 
 
Por definição, a 1ª Forma Normal consiste na normalização da tupla, de forma que o 
relacionamento entre a sua chave e os seus atributos sejam unívocos, isto é, para cada chave há 
a ocorrência de um e somente um dado. 
 
 
 Procedimentos 
 
• identificar a chave primária da entidade; 
 
• identificar os atributos que formam o grupo repetitivo e removê-lo da entidade; 
 
• criar uma nova entidade com a chave primária da entidade anterior e o grupo repetitivo. 
 
 
A chave primária da nova entidade será obtida pela concatenação da chave primária da entidade 
inicial e um ou mais atributos do grupo repetitivo. 
 
 
Exemplo: 
 
 
A empresa Bits Ltda possui um formulário para solicitação de compra de produtos para empresa. 
 
 
 
BITS SA 
 
ORDEM DE COMPRA 
 
ORD Nº 1234 
Fornecedor: 0256 NEW DATA SYSTEM LTDA Dt de Cadastro 01/01/2003 
Plano comissão: A Dt de entrega 05/01/2003 
 
Código do Produto 
 
Descrição do Produto Quantidade Valor Unitário 
 
Valor Total 
015460 PAPEL A4 RESMA-500 FLS 5 10,00 50,00 
122236 CD-RW 700M 100 1,20 120,00 
456698 TINTA P/IMPRESSORA HP850 6 85,00 510,00 
 TOTAL: 680,00 
 
Tabela 14. 
 
 
 
Analisamos o formulário por ela utilizado e verificamos a necessidade de criar uma entidade 
ORDEM com seus atributos. 
 
Aplicando a 1ª Forma Normal criamos uma entidade chamada ORDEM_ITEM que armazenará o 
grupo repetitivo encontrado. 
 
Como chave primária para entidade ORDEM_ITEM teríamos uma chave concatenada (Código da 
Ordem + Código do Item). 
 
 
 
 
59 
 
 
Entidade 
 
ORDEM_ITEM 
PK Código da Ordem 
PK Código do Produto 
 Descrição do Produto 
 Preço Unitário do Produto 
 Quantidade do Produto 
 Preço Total do Produto 
 N 
 1 
 
Entidade 
 
ORDEM 
PK Código da Ordem 
 Data de Cadastro 
 Plano de Comissão 
 Data da Entrega 
 Código Fornecedor 
 Nome do Fornecedor 
 Valor Total da Ordem 
 
 
 
Notem que, no diagrama, os atributos Código da Ordem e Código do Produto foram indicados 
como PK. Isso foi feito para ressaltar que ambas formam uma chave primária composta. Código 
da Ordem é, na verdade, uma chave estrangeira. 
 
 
 
Entidade ORDEM 
PK Código da Ordem 
 Data de Cadastro 
 Plano de Comissão 
 Data da Entrega 
 Código Fornecedor 
 Nome do Fornecedor 
 Valor Total da Ordem 
 Código do Produto 
 Descrição do Produto 
 Preço Unitário do Produto 
 Quantidade do Produto 
 Preço Total do Produto 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 63. 
 
 
 
9.2. Segunda Forma Normal (2FN) 
 
 
Conforme vimos anteriormente, existem algumas tuplas que, para serem identificadas e 
individualizadas, necessitam conter em sua chave mais de um atributo, formando uma chave 
concatenada. 
 
Após submeter a tupla à análise e conversão para a 1ª Forma Normal, o próximo passo é verificar 
se a mesma possui chave concatenada, e, se for o caso, constatar se todos os atributos não 
chavesnão apresentam dependência parcial com a referida chave. A dependência parcial é uma 
situação particular em que os atributos não chaves dependem parcialmente de um atributo da 
chave concatenada. 
 
 
 
 Procedimentos 
 
• Identificar os atributos que possuem dependência parcial. 
 
 
60 
 
 
Entidade 
 
ORDEM_ITEM 
PK Código da Ordem 
PK Código do Produto 
 Descrição do Produto 
 Preço Unitário do Produto 
 Quantidade do Produto 
 Preço Total do Produto 
 N 
 1 
 
Entidade 
 
ORDEM 
PK Código da Ordem 
 Data de Cadastro 
 Plano de Comissão 
 Data da Entrega 
 Fornecedor 
 Valor Total da Ordem 
 
 
 
• Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles. 
 
• A chave primária da nova entidade será o atributo do qual os atributos removidos são 
funcionalmente dependentes. 
 
Exemplo : Continuando a análise da Ordem de Compra. 
 
A criação da entidade ORDEM_ITEM fez com que a chave primária da entidade ORDEM fosse 
transportada para a nova entidade ORDEM_ITEM, que juntamente com os atributos transferidos 
pela aplicação da 1ª Forma Normal fossem para a entidade ORDEM_ITEM. 
 
A chave da nova entidade passou a ser a chave concatenada formada por [Código da Ordem + 
Código do Item]. 
 
Entretanto o atributo [Descrição do Produto] apresenta dependência parcial com a chave primária 
concatenada da entidade ORDEM_ITEM, sugerindo a aplicação da 2ª Forma Normal. 
 
 
 
 
Entidade 
 
PRODUTO 
PK Código do Produto 
 Descrição do Produto 
1 
 
 
 
N 
 
Entidade 
 
PK 
 
PK - FK 
ORDEM_ITEM 
 
Código do Item 
 
Código do Produto 
Preço Unitário do Produto 
Quantidade do Produto 
Preço Total do Produto 
N 
 
 
 
 
 1 
 
Entidade 
 
ORDEM 
PK Código da Ordem 
 Data de Cadastro 
 Plano de Comissão 
 Data da Entrega 
 Código Fornecedor 
 Nome do Fornecedor
 Valor Total da Ordem
 
Figura 64. 
 
 
 
 
61 
 
 1 
 
Entidade 
 
ORDEM 
PK Código da Ordem 
 Data de Cadastro 
 Plano de Comissão 
 Data da Entrega 
 Código Fornecedor 
 Nome do Fornecedor 
 Valor Total da Ordem Fi
gu
ra
 6
5.
 
 
 
 
9.3. Terceira Forma Normal (3FN) 
 
 
Na definição de uma tupla, pode ocorrer de alguns atributos não serem dependentes diretos da 
chave da mesma, mas sim, por transitividade através de outros atributos residentes na mesma 
tupla referenciada. 
 
Submetida a tupla à análise e conversão para a 2ª Forma Normal, verifica-se em seguida se todos 
os atributos não chaves não apresentam dependência transitiva com a sua chave. 
 
A dependência transitiva é dependência indireta que um determinado atributo tem com a chave 
da tupla através de um outro atributo não chave, do qual é diretamente dependente. 
 
 
 Procedimentos 
 
• Identificar todos os atributos que possuem dependência transitiva. 
 
• Removê-los e criar uma nova entidade com os mesmos. 
 
• A chave primária da nova entidade será o atributo do qual os atributos removidos são 
funcionalmente dependentes. 
 
 
 
Entidade 
 
PK 
PRODUTO 
 
Código do Produto 
 
Descrição do Produto 
Entidade 
 
PK 
PRODUTO 
 
Código do Produto 
 
Descrição do Produto 
 
1 1 
 
 
 
 
Entidade 
 
PK 
 
PK - FK 
N 
 
ORDEM_ITEM 
Código do Item 
Código do Produto 
Preço Unitário do Produto 
Quantidade do Produto 
Preço Total do Produto 
N 
 
 
Entidade 
 
PK 
 
PK - FK 
N 
 
ORDEM_ITEM 
Código do Item 
Código do Produto 
Preço Unitário do Produto 
Quantidade do Produto 
Preço Total do Produto 
N 
 
 
 
 
 
 
Entidade 
 
 
 
1 
 
 
ORDEM 
Entidade 
 
PK 
FORNECEDOR 
 
Código do Fornecedor 
 
Nome do Fornecedor 
 
1 
 
PK Código da Ordem N 
 
Data de Cadastro 
Plano de Comissão 
Data da Entrega 
FK Código Fornecedor 
 
Valor Total da Ordem 
 
 
 
62 
 
 
 
 
9.4. Resumo dos Passos para Normalização 
 
 
1. Identifique atributos (ou grupos) que possuam múltiplos valores para uma ocorrência da 
entidade - 1FN 
 
2. Remova os atributos (ou grupos) com uma copia da chave primária - 1FN 
 
3. Identifique atributos dependentes somente de parte da chave primária - 2FN 
 
4. Remova os atributos encontrados com uma cópia de parte da chave primária - 2FN 
 
5. Identifique atributo(s) dependente(s) de outro(s) atributo(s) não chave - 3FN 
 
6. Remova esses atributos com uma cópia do atributo do qual depende.