Relacionamento-Banco-de-Dados

Prévia do material em texto

1 
Modelagem de Dados 
 4. MODELO E-R E SEUS CONCEITOS 
 
4.1. Entidades 
 
Uma entidade é uma coisa que pode ser identificada distintamente. 
Em nosso centro de interesse, uma entidade é todo o objeto ou evento, abstrato ou não, 
sobre o qual desejamos armazenar informações. 
Dentro do conceito de coisa, podemos então dizer que em uma empresa existem 
muitas coisas que são de interesse para a mesma. 
É responsabilidade do projetista de sistemas em banco de dados selecionar as 
entidades que são adequadas para os objetivos da empresa. 
Dentro do conceito de que um banco de dados relacional clássico, a representação de 
entidades é feita por um retângulo com nome da mesma em seu interior. 
Por uma questão de sintaxe correta, devemos estabelecer, como regra, utilizar sempre 
o nome das entidades como substantivo no singular (vide quadro abaixo). 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.1 – Entidades 
 
ENTIDADE é todo o objeto ou evento sobre o qual 
armazena-se informação 
 
CLIENTE 
 
EMPRESA 
 
PRODUTO 
 
COTAÇÃO 
 
FILME 
 2 
Modelagem de Dados 
4.2. Atributos 
 
 
 
 
 
 
 
 
 
 
Figura 4.2 – Atributos 
 
É uma característica inerente a uma entidade. O que difere um atributo de uma 
entidade? 
Um atributo é um dado que se refere a uma entidade, ou seja, um valor ou propriedade 
descritiva que caracteriza uma coisa (entidade). Em comparação aos sistemas tradicionais, um 
atributo corresponde a um campo, ou melhor, a um item de dado de um arquivo convencional. 
Dentro da abordagem relacional, um atributo é uma coluna da tabela que representa 
uma entidade. 
 
 
 
 
 
• É uma característica inerente de uma entidade 
• Um valor ou propriedade descritiva das entidades 
 
 
• ATRIBUTO = ITEM DE DADO = DADO 
ATRIBUTOS 
 3 
Modelagem de Dados 
4.2.1. Domínio de um atributo 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.3 – Domínio de um atributo 
 
Chamamos de domínio de um atributo o conjunto de valores que ele pode assumir, 
para a entidade a qual ele caracteriza. Um conjunto formado por valores de atributos de uma 
entidade caracteriza o que denominamos de tupla, ou seja, uma linha tabela. E o conjunto 
destas tuplas chamamos de relação, ou seja, a tabela em si. O gráfico acima nos fornece uma 
visão dos conceitos apresentados. 
 
 
 
 
É o conjunto de valores 
de um atributo, tais 
como: 
 
• pesos 
• valores 
• cores 
• nomes, etc. 
DOMÍNIO 
5 
a b c 
9 
3 
(3,a) 
(5,b) 
(9,c) 
Domínio de X 
Domínio 
de Y 
 4 
Modelagem de Dados 
4.2.2. Atributo – chave ou identificador 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.4 – Atributo-chave ou identificador 
 
Em uma tupla, um atributo ou conjunto de atributos possui a propriedade de 
determinar uma única ocorrência de uma tupla em uma relação. Este atributo ou conjunto de 
atributos denominamos atributo-chave. 
Em uma tabela, um atributo chave caracteriza um item de busca, não representando, 
por ser chave, qualquer forma de ordenação. 
 
 Atributo → Chave 
 Atributo → Obrigatório 
 Atributo → Facultativo 
 Atributo → Derivado 
 Atributo → Composto 
 Atributo → Estrangeira 
 
 
 
 
 
É um atributo ou conjunto de atributos que determina 
unicamente uma ocorrência de entidade. 
 
ATRIBUTO-CHAVE OU 
IDENTIFICADOR 
 
Matrícula 
Nome 
Mãe 
Nome 
Pai 
 
Idade 
Data 
Ingresso 
 
Nome 
Entidade ALUNO 
Atributo-chave 
F 
D 
C 
@ 
 5 
Modelagem de Dados 
4.3. Relacionamentos 
 
4.3.1. O que é relacionamento 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.5 – Relacionamentos 
 
Quando duas entidades apresentam interdependência, em que uma determinada tupla 
(linha) de uma delas origina ou se associa a “1” ou “n” tuplas de outra, dizemos que elas 
apresentam um relacionamento. 
O relacionamento é representado por um segmento contínuo ligando as duas entidades. 
 
 
 
 
 
 
 
 
Adão 
 
Jarbas 
 
Pedro 
Empregado Departamento 
Produção 
Compras 
 
 
Vendas 
Departamento Empregado 
Está lotado 
LOTADO 
 6 
Modelagem de Dados 
4.3.2. Como identificar um relacionamento 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.6 – Relacionamentos 
 
A tarefa de identificação de relacionamento entre entidades é facilitada pela 
verificação de existência de atributos comuns nas tuplas (linhas) respectivas. 
 
 
4.3.3. Cardinalidade 
 
Havendo relacionamento dentre duas entidades, a próxima etapa é identificar a 
cardinalidade, ou seja, quantas tuplas de uma entidade “A” estão associadas a uma tupla da 
entidade “B” e vice-versa. 
Existem quatro tipos de cardinalidade que são representadas graficamente por uma 
simbologia dupla em que o primeiro símbolo identifica o número mínimo e o segundo o 
número máximo de ocorrências de tuplas associadas. 
 
 
 
 
 
 
 
RELACIONAMENTOS 
 
Funcionário 
 
Cargo 
ocupa 
Cargo Funcionário 
MATR. NOME CARGO 
E34 JOÃO 05 
E27 CARLOS 10 
E89 SILVIO 10 
E67 CARLA 11 
E56 CLÁUDIA 12 
 
CODIGO NOME 
04 DIRETOR 
10 AUXILIAR 
11 SECRETÁRIA 
20 DENTISTA 
12 COZINHEIRA 
 
 7 
Modelagem de Dados 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.7 – Cardinalidade 
 
 
4.4. Tipos de Relacionamentos no Modelo Relacional 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.8 – Tipos de Relacionamentos 
 
 
 
 
CARDINALIDADE 
Notação Clássica 
 0 ou 1 ocorrência no máximo 
Relacionamento opcional 
 1 e somente 1 ocorrência 
Relacionamento obrigatório 
 0 a n ocorrências 
Relacionamento opcional 
 1 a n ocorrências 
Relacionamento obrigatório 
 
 
 
 
 
 
TIPOS DE RELACIONAMENTO 
NOTAÇÃO CLÁSSICA 
DIVISÃO 
FORNECE
DOR 
VENDA 
GERENTE 
ITEM DE 
VENDA 
PRODUTO 
1:1 
um : um 
n:n 
muitos : muitos 
1:n 
um : muitos 
 8 
Modelagem de Dados 
4.4.1. Relacionamento 1 para 1 
 
O relacionamento 1 para 1 ocorre quando, para cada uma ocorrência na tabela A, 
temos somente uma ocorrência na tabela B. Este tipo de relacionamento pode conter, 
normalmente, casos em que existam ocorrências nas entidades (tabelas) sem relacionamento. 
 
 
4.4.2. Relacionamento 1 para muitos 
 
Este é o relacionamento em que temos “n” ocorrências de uma entidade associada a 
uma ocorrência de outra entidade (tabela). No quadro exemplo, temos uma venda possuindo 
“n” itens de venda. 
 
 
4.4.3. Relacionamento de muitos para muitos 
 
Neste tipo de relacionamento, não existe restrição na formação de associações, ou seja, 
uma ocorrência de A pode estar associada a “n” ocorrências de uma entidade B e vice-versa. 
Em nosso quadro, um fornecedor pode estar associado a vários produtos e um produto pode 
ter ou ser fornecido por vários fornecedores. 
 
 
4.4.4. O modelo E-R e a Simplificação do Diagrama de Relacionamentos 
 
Em 1976, Peter Chen elaborou uma extensão do modelo Relacional Clássico, 
conhecido como modelo E-R (Entidade-Relacionamento), firmando-se por uma semântica 
mais completa e por uma diagramação mais simples. 
A representação diagramática de relacionamentos é um losango com um verbo no 
interior, que contém, ou melhor, expressa o significado do relacionamento no mundo real. 
 
 
 9 
Modelagem de DadosFigura 4.9 – Modelo E-R 
 
 
4.5. Relacionamento do Modelo Entidade-Relacionamento 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.10 – Relacionamentos do modelo E-R 
 
Todo relacionamento muitos para muitos se caracteriza por ser um relacionamento 
 
 
 
 
 
MODELO 
ENTIDADE-RELACIONAMENTO 
DIVISÃO 
FORNECE
DOR 
VENDA 
GERENTE 
ITEM DE 
VENDA 
PRODUTO 
Peter Chen (1976) MT – Notação do Modelo E-R 
* Notação com mais semântica 
n:n 
muitos : muitos 
1:n 
um : muitos 
1:1 
um : um 
1 1 
1 N 
N N 
Diagrama mais simplificado 
 
 
 
 
RELACIONAMENTO COM CAMPOS 
 
MÉDICO 
 
PACIENTE consulta 
 
FORNECEDOR 
 
PRODUTO consulta 
CODIGO 
MEDICO 
CODIGO 
PACIENTE 
DATA 
CONSULTA 
HORA 
CONSULTA 
PRODUTO FORNECEDOR PREÇO PRAZO 
 10 
Modelagem de Dados 
com campos, uma extensão do modelo E-R. 
Em alguns casos, um analista poderá enxergar este tipo de relacionamento como sendo 
uma entidade, ou seja, uma tabela, mas outro analista terá a visão dos dados como um 
relacionamento, no mundo real. Isto ocorre, principalmente, com eventos, já que objetos são 
estáveis no tempo e eventos ocorrem em determinados períodos de tempo. 
Os dois exemplos apresentados no quadro acima indicam, respectivamente, como 
possíveis campos de um relacionamento: 
CONSULTA: DIA DA CONSULTA / HORA DA CONSULTA 
FORNECE: PREÇO DE VENDA / PRAZO DE ENTREGA 
 
 
4.6. Auto-relacionamento 
 
Em alguns casos a entidade pode se relacionar com ocorrências dela mesma. Nestes 
casos, temos o AUTO-RELACIONAMENTO ou RELACIONAMENTO REFLEXIVO. 
Peter Chen especifica a existência de um papel para cada elemento da entidade 
(tabela) para os relacionamentos, mas é no auto-relacionamento que isto realmente se torna 
necessário. Esta especificação deve ser então realizada na definição do relacionamento em si. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.11 – Relacionamento Reflexivo 
 
 
 
 
RELACIONAMENTO REFLEXIVO 
CODIGO É 
COMPOSTO 
COD PROD 
COMPOSTO 
COD PROD 
COMPONENTE 
 
QUANTIDADE 
 
COMPONENTE 
 
COMPOSTO 
 
PRODUTO 
N 
N 
 11 
Modelagem de Dados 
No exemplo apresentado na figura 4.11, vemos que os papéis que o PRODUTO tem 
no relacionamento COMPOSIÇÃO como COMPONENTE_DE e COMPOSTO-POR. 
Usualmente, estes papéis são denominados de ROLES ou ALIÁS. 
Um relacionamento reflexivo pode, normalmente, se caracterizar como um 
relacionamento com campos. 
 
 
4.7. Relacionamentos Múltiplos 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.12 – Relacionamentos Multiplos 
 
Existem casos em que os relacionamentos acontecem entre mais de duas entidades. 
 
 
4.7.1. Relacionamentos Ternários 
 
Por exemplo: dado um aluno, este pode cursar várias disciplinas, e uma disciplina 
possui um professor. 
Um professor pode lecionar várias disciplinas, mas um aluno só pode ter um professor 
 
 
 
 
RELACIONAMENTOS MÚLTIPLOS 
P–A–D 
 
Professor 
 
Aluno 
 
Disciplina 
n n 
n 
Um professor tem 
muitos alunos 
Um professor leciona 
muitas disciplinas 
Um disciplina tem um 
professor 
Um aluno tem um 
professor por 
disciplina 
Um aluno cursa 
várias disciplinas 
 12 
Modelagem de Dados 
por disciplina. 
Um professor pode ter vários alunos em uma disciplina. 
 
 
4.7.2. Agregações 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.13 – Agregações 
 
Como o modelo de Peter Chen não prevê relacionamentos entre relacionamentos, 
introduz-se aqui uma extensão deste modelo. 
Existem casos em que um Relacionamento comporta-se como uma entidade 
(principalmente nos casos de relacionamento com campos). 
Agrega-se os elementos do primeiro relacionamento, como se tivéssemos a visão de 
uma entidade, e relaciona-se esta agregação com a terceira entidade (vide quadro). 
 
 
 
 
 
AGREGAÇÃO 
 
Máquina 
TRABALHA 
 
Funcionário 
 
Projeto 
N N 
N 
USA 
 13 
Modelagem de Dados 
4.8. Particionando entidades 
 
4.8.1. Generalização 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.14 – Generalização 
 
Uma outra extensão do modelo E-R é a denominada GENERALIZAÇÃO. 
Quando duas entidades ou um conjunto de entidades representa elementos do mundo 
real, que se subdividem em categorias, com seus atributos parcialmente distintos, ou mesmo 
iguais, isso nos conduz a entender que é uma entidade única. 
Mas como estas categorias possuem relacionamentos diferentes com outras entidades, 
são consideradas, então, como se fossem SUBCONJUNTOS DA ENTIDADE BÁSICA. 
No exemplo da figura 4.14, funcionários podem ser do tipo motorista, ou secretária, ou 
engenheiro. Cada um destes tipos possui dados comuns, mas uma secretária não possui 
carteira de habilitação, por exemplo. 
 
 
 
 
 
 
 
GENERALIZAÇÃO 
 
Funcionário 
 
Secretária 
 
Engenheiro 
 
Motorista 
Tipo de funcionário 
 14 
Modelagem de Dados 
Então, criam-se tipos com diferenciador. Os dados não-comuns constituem-se, então, 
em subconjuntos de entidade principal. 
A chave da entidade subconjunto é composta pela chave da entidade principal, e um 
atributo específico e não repetitivo da mesma. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.15 – Generalização 
 
 
 
 
 
 
ENTIDADES SUBCONJUNTO 
 
Funcionário 
 
Motorista 
CATEG 
1 
1 
CARTEIRA 
MOTORISTA 
PLACA DO 
CARRO 
 
 
CODIGO DO 
FUNCIONÁRIO 
Categoria 
 15 
Modelagem de Dados 
5. MODELAGEM PRÁTICA DE DADOS 
 
A primeira etapa da modelagem de dados consiste no que denominamos ANÁLISE 
DE ENTIDADES E RELACIONAMENTOS. Esta etapa constitui-se, de uma fase na qual 
determinaremos quais as entidades que interessam ao modelo parcial de necessidade da 
empresa que estamos enfocando. Esta análise e definição pode ser baseada no modelo 
conceitual obtido após as entrevistas e análise de documentos. 
 
5.1. Reconhecer as Entidades 
 
Ao analisarmos este contexto, deveremos ter em mente uma forma de pensar E-R, ou 
seja, que cada entidade é sempre representada por uma tabela. Logo, algo que não requeira 
pelo menos dois atributos para descrevê-lo, provavelmente não caracterizará uma entidade, e 
sim, atributo de alguma outra, ou simplesmente uma variável do contexto. É importante 
estabelecermos alguns princípios para que se obtenha, ou melhor, se extraia dos 
levantamentos e entrevistas com usuários as entidades de interesse para aplicação que está 
em projeto. O USUÁRIO sempre se refere a processo. Pense e lembre que o modelo de dados 
não é fluxograma. Logo, não tem começo, nem fim. Esteja atento para referências a 
substantivos, pois é um ponto de indicação de uma entidade. 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.1 – Modelagem prática de dados 
 
 
 
 
MODELAGEM PRÁTICA DE DADOS 
Especificação das Entidades 
Especificação dos Relacionamentos 
Que coisas são trabalhadas? 
O que pode ser identificado por número, código 
Pode assumir forma de uma tabela? 
É um documento externo? Candidato a entidade 
Tem significado próprio? 
Qual a entidade principal? 
ESPECIFICAÇÃO DAS ENTIDADES 
 16 
Modelagem de Dados 
� Adjetivos colocados pelos usuários indicam normalmente atributos de uma 
entidade. 
� Verbos indicam relacionamentos. 
� Advérbios temporais indicam campos de um relacionamento. 
� Procure sempre visualizar qual éa entidade principal do contexto sob análise. 
 
Dica útil: entidades cujo nome termine por “ento” ou por “ão” geralmente são 
procedimentos. 
 
� Documentos externos (recibo, contra-cheque, fatura) são sempre fortes candidatos 
a entidades. 
 
Após termos obtido e identificado as entidades que compõem o contexto de aplicativo 
que estamos projetando, a próxima etapa consiste na definição dos relacionamentos que 
existem entre as entidades e que interessam ao nosso contexto. 
No momento em que obtivermos o domínio dos relacionamentos e entidades, 
poderemos traçar um primeiro diagrama E-R, que nos servirá de base para as etapas seguintes. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.2 – Especificação de relacionamentos 
 
 
 
 
ESPECIFICAÇÃO DE 
RELACIONAMENTO 
Verbos: possíveis relacionamentos. 
Obter o tipo de relacionamento visualizado. 
Analisar as entidades aos pares. 
Para cada relacionamento encontrado 
Questionar: 
• É necessário? 
• É útil? 
• É redundante? 
• Se redundante, retirar? 
• Qual a finalidade? (documentar) 
 17 
Modelagem de Dados 
Observa-se que neste ponto ainda não determinamos quais atributos compõem as 
entidades e tão pouco os atributos, caso os relacionamentos sejam compostos. 
Para se obter os relacionamentos, inicialmente são analisadas as entidades aos pares, 
verificando-se a existência de algum relacionamento (verbo) referindo-se a algumas delas, ou 
melhor, entre as duas. 
Não existe, neste momento, a preocupação de que estejam realmente diferenciados os 
relacionamentos e sua validade no momento, mas formam, a base para as etapas seguintes. 
 
 
5.2. Definição de atributos e valores 
 
Uma vez montado o diagrama Entidade-Relacionamento, devemos, então, identificar 
as propriedades de entidades e de relacionamentos, que são de interesse para a aplicação que 
estamos desenvolvendo. Numa primeira etapa, vamos apenas associar os atributos os atributos 
relativos e conhecidos das entidades e dos relacionamentos já delineados. No processo de 
definição de atributos, vamos muitas vezes, nos valer da Análise de Relacionamentos e das 
considerações de variação temporal dos dados no sistema. 
Questione sempre se o usuário tem interesse e condições de manter o atributo por ele 
definido. Sempre que for definido um atributo, devemos documentar o porque de sua 
existência, assim como os valores limites de seu domínio e suas restrições. É muito 
importante também considerar os atributos similares, ou seja, atributos idênticos em entidades 
distintas, que possuem a mesma nomenclatura e significados diferentes. 
 
 
5.2.3 Variação temporal 
 
Para cada entidade definida, como seus atributos delineados, devemos perguntar: 
� Quais de seus atributos se transformarão com o tempo? 
� Precisamos armazenar dados históricos deste atributo? 
� Se positivo, em que período de tempo ou através de quantas alterações? 
 
 18 
Modelagem de Dados 
Toda vez que uma decisão de armazenar o histórico de atributo for tomada, 
determina-se implicitamente um relacionamento de 1 para muitos, entre a entidade que 
contém o atributo e a entidade que irá conter o histórico deste atributo. Existe, então, uma 
tabela dependente contendo toda a data em que houve alteração do atributo e o valor do 
atributo a partir de cada data (no mínimo). 
 
 
Exercício de Modelagem 
 
Construção de um diagrama E-R 
Construir um diagrama E-R para administradora de condomínios: 
Premissas: 
� Um condomínio é formado por diversas unidades habitacionais. 
� Cada unidade habitacional pertence a um proprietário, o qual pode ser proprietário 
de várias unidades. 
� Cada unidade pode estar alugada. 
� Toda pessoa (Proprietário ou Locatário) possui um código, um nome e um 
endereço. 
� Toda unidade possui um código que a identifica no condomínio. 
� Um condomínio é identificado por um código e um endereço. 
� Entre os proprietários de um condomínio, um é o síndico. 
 
 
 
 
 
 
 
 
 
 19 
Modelagem de Dados 
5.4. Análise de Relacionamentos 
 
5.4.1. Análise de Relacionamentos 1 para 1 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.3 – Análise de relacionamentos 1:1 
 
Sempre que é detectado um relacionamento de 1 para 1, a questão é saber se as duas 
entidades são realmente distintas ou se elas podem ser unidas. 
Se possuem a mesma chave primária, há uma forte razão para unir as entidades em 
uma só. 
No quadro de entidades acima, observa-se que as entidades PRODUTO e ESTOQUE 
possuem seguramente a mesma chave, logo, podemos visualizar as informações todas em uma 
só entidade. 
 
Exemplo 
Se tivermos, como no quadro acima, entidade MÁQUINA e outra entidade MISTURA 
DE COMBUSTÍVEL, cada máquina tem sua própria mistura de combustível, e cada mistura 
relaciona-se com uma e somente uma máquina. Consequentemente, a mistura de combustível 
é um atributo de máquina. 
 
 
 
 
ANÁLISE DE RELACIONAMENTO 1:1 
POSSUI 
 
PRODUTO 
 
ESTOQUE 
1 1 
USA 
 
MÁQUINA 
MISTURA DE 
COMBUSTÍVEL 
1 1 
Cod–Produto 
Descrição 
Preço 
Cod–Produto 
Quantidade 
 20 
Modelagem de Dados 
Se as duas entidades forem realmente distintas, o relacionamento se dará através de 
um elo explícito, ou seja, uma chave ESTRANGEIRA. 
Ao projetar, devemos analisar a possibilidade de o relacionamento 1 para 1 
futuramente tornar-se um relacionamento 1 para muitos. 
O exemplo da figura 5.4 mostra duas possibilidades de relacionamento. A estrutura de 
atributos proposta à entidade DIVISÃO, no primeiro desempenho, permite que, no futuro, um 
EMPREGADO possa vir a gerenciar mais de uma divisão. 
Já o segundo não permitiria. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.4 – Análise de relacionamentos 1:1 
 
 
 
 
 
 
ANÁLISE DE RELACIONAMENTO 1:1 
Codigo_Unidade 
Nome_Divisao 
Id_Empr_Gerente 
Orçamento 
DIVISÃO 
Codigo_Unidade 
Nome_Divisao 
Orçamento 
DIVISÃO 
Id_Empregado 
Nome 
Endereço 
Telefone 
PESSOAL 
Id_Empregado 
Nome 
Cod_Unidade_GER 
Endereço 
Telefone 
PESSOAL 
Permite que o 
impresso seja no 
futuro GER de mais 
divisões 
 21 
Modelagem de Dados 
5.4.2. Análise de relacionamentos 1 para muitos 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.5 - Análise de relacionamentos 1:N 
 
Este é um tipo de relacionamento mais fácil para análise. 
A chave da entidade UM faz parte da entidade MUITOS (pode ser parte da chave ou 
não). 
Seja o exemplo: VENDA e ITEM DE VENDA 
Se considerarmos agora que um cliente pode ter muitas vendas sendo feitas a ele, o 
código do cliente deverá fazer parte da tabela VENDAS, mas não necessariamente da chave, 
pois o número de venda identifica claramente a venda. 
No mesmo exemplo, um cliente está associado a “n” vendas, e cada venda a “n” itens 
de venda. 
Deve, então, o código do cliente ser incluído também na tabela item de venda? 
Obrigatoriamente não, pois se quisermos saber quais clientes pediram ou compraram 
um determinado produto, podemos pesquisar todas as ocorrências de itens de venda para o 
produto em pauta obtendo o número de suas vendas, e, posteriormente, pesquisar em vendas 
quais os clientes que as efetuaram. 
Mas simplificaria a programação e a pesquisa, se colocássemos o código do cliente 
 
 
 
 
ANÁLISE DE RELACIONAMENTO 1:N 
CONTÉM 
 
VENDA 
 
ITEM_VENDA 
1 N 
POSSUI 
 
CLIENTE 
1 N 
VENDA 
Nº DA VENDA 
DATA_VENDA 
CÓDIGO_VENDEDOR 
chave Nº DA VENDA 
NUM_ITEM 
COD_ITEM 
QUANTIDADE 
chaveCOD_CLIENTE 
NOME 
ENDEREÇO 
chave NUM_VENDA 
DATA 
COD_VENDEDOR 
COD_CLIENTE 
chave 
 22 
Modelagem de Dados 
também em item de venda. 
O ZIM permite que se estabeleça esta ligação de relacionamento entre as três 
entidades, já que ele pode acessar diretamente um relacionamento do tipo: 
 
 
CLIENTE POSSUI VENDA CONTÉM ITEM_DE_VENDA 
 
FIND CLIENTE POSSUI VENDA CONTÉM ITEM_DE_VENDA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.6 – Análise de relacionamento 1:N 
 
 
 
 
 
 
 
 
 
 
 
QUAIS OS ITENS QUE UM CLIENTE 
COMPRA? 
CLIENTE POSSUI CONTÉM 
NUM_VENDA 
DATA 
COD_VENDEDOR 
COD_CLIENTE 
VENDA 
ITEM DE 
VENDA 
NUM_VENDA 
NUM_ITEM 
COD_PRODUTO 
QTDE_PRODUTO 
???????????? 
ID_CLIENTE 
NOME 
ENDERECO 
COD_CLIENTE 
 23 
Modelagem de Dados 
5.4.3. Relacionamentos muitos para muitos 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.7 – Análise de relacionamentos N:N 
 
Em todo relacionamento muitos para muitos, a pergunta que se faz é: QUEM 
REFERENCIA QUEM? 
Este caso sempre pode ser resolvido com o desdobramento em 2 relacionamentos 1 
para muitos e a criação de uma entidade que faça a associação entre as duas. A chave da 
entidade associação é a concatenação ou combinação das chaves das duas entidades originais. 
Em nosso exemplo, temos a situação em que FORNECEDOR fornece muitos 
PRODUTOS e qualquer PRODUTO poderá ser fornecido por vários fornecedores. 
Pergunta-se então: Qual a entidade que possui esta concatenação de chaves? 
Que atributos constituem esta entidade? 
Que elementos podem ser determinados se soubermos que estamos lidando com 
determinado PRODUTO de um FORNECEDOR específico? (Qual a razão desta ligação?) 
Damos, então, o nome de ORIGEM DO PRODUTO a esta entidade. 
Um PRODUTO poderá estar disponível em diferentes fornecedores, com preços e 
prazos diferenciados, e um fornecedor poderá ofertar diversos produtos. 
Aqui, aproveitamos para lembrar mais uma característica saudável do ZIM: 
 
 
 
 
ANÁLISE DE RELACIONAMENTO N:N 
POSSUI ORIGINA 
ORIGEM 
PRODUTO 
FORNECED PRODUTO 
FORNECED 
N FORNECE PRODUTO 
N 
 24 
Modelagem de Dados 
Trabalhando-se com o ZIM, não é necessário este desdobramento, já que o mesmo 
implementa diretamente o relacionamento de muitos para muitos. 
 
 
5.5. Formas Normais e o Processo de Normalização 
 
O conceito de normalização no modelo relacional foi introduzido por Codd em seu 
primeiro artigo sobre o modelo relacional de 1970, onde estabeleceu o que posteriormente 
chamou-se de 1ª Forma Normal. 
A teoria da Normalização está montada em torno deste conceito de formas normais. 
Uma tabela (entidade) está numa determinada forma normal se ela atender a um conjunto 
específico de restrições. 
A normalização, então, é um processo formal passo a passo que examina os atributos 
de uma entidade com o objetivo de evitar anomalias na inclusão, exclusão e alteração de 
tuplas específicas. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.8 – Normalização 
 
 
 
 
 
Codd 1970 – 1ª Forma Normal 
 1972 – 2ª e 3ª Forma Normal 
Fagin 1974 – 4ª Forma Normal 
 
Formas Normais: Conjunto de Restrições 
 
 
 
Objetivo: Estabilidade do modelo de dados 
 
NORMALIZAÇÃO 
Normalização: Processo Formal de Análise 
 de atributos de uma Entidade 
 25 
Modelagem de Dados 
5.5.1. Anomalias 
 
Anomalia de Inclusão: Ao ser incluído, um novo cliente já deve estar relacionado a 
uma venda. 
Anomalia de Exclusão: Se um cliente for excluído, poderão ser perdidos todos os 
dados de vendas. 
Anomalia de Alteração: Se a faixa de preço de determinada classe de produto for 
alterada, deverá ser verificada toda a relação para serem feitas múltiplas alterações. 
 
 
5.5.2. Redundância de Armazenamento 
 
Este processo causa a simplificação dos atributos de uma entidade, colaborando 
significativamente para a estabilidade do modelo, reduzindo-se consideravelmente as 
necessidades de manutenção. 
Para ser obtida esta estabilidade, é necessário que os atributos de uma mesma 
entidade sejam analisados de forma a verificar se a tabela é ou não normalizada. Para isso, 
devemos submeter essa tabela aos critérios de primeira, segunda , terceira e quarta formas 
normais. 
 
 
5.5.3. Dependência Funcional 
 
Conceituação 
Para fornecer subsídios de entendimento, iniciaremos introduzindo o conceito de 
Dependência Funcional. 
Um atributo depende funcionalmente de outro quando informa algo intrinsicamente 
ligado ao outro. 
Para visualizarmos, utilizaremos o nosso exemplo com a entidade MÉDICO. 
Nome e especialidade são dependentes funcionalmente de CODM, porque para cada 
valor de CODM está associado um e somente um valor de Nome e Especialidade. 
 26 
Modelagem de Dados 
Uma dependência funcional é uma forma especial de restrição de integridade. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.9 – Dependência Funcional 
 
Dependência Total 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.10 – Tipo de dependência 
 
 
 
 
 
 
 
 
 É uma restrição de integridade 
 
DEPENDÊNCIA FUNCIONAL 
Em uma tabela todos os atributos que não são chave 
dependem de todos os atributos chaves e de nenhum 
outro. 
Código do 
Médico 
Especiali-
dade 
 
Nome 
 
 
 
 Dependência Total 
 
TIPOS DE DEPENDÊNCIA 
Chave 
Dependência 
Parcial 
N_func Cód 
Curso 
Descr 
Curso 
Avaliação Data 
Conclusão 
 27 
Modelagem de Dados 
Um atributo é dependente total de outro se ele for funcionalmente dependendo do 
outro e não dependente de um subconjunto de outro. 
No nosso exemplo, podemos observar que o atributo AVALIAÇÃO é dependente 
total da chave composta por N_func + Codigo_Curso. Já o atributo Descr_Curso tem 
dependência parcial desta chave, pois depende somente de parte dela, ou seja: 
CÓDIGO_CURSO 
 
 
5.6. Formas Normais 
 
Dentro do que se tem do mundo real de casos de normalização, a obtenção de uma 
entidade na 3ª Forma Normal é recurso suficiente para obtermos modelos de estrutura de 
entidades e atributos estáveis e dentro de padrões de integridade. 
 
 
5.6.1. 1ª Forma Normal 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.11 – 1ª forma normal 
 
 
 PEDIDO Nº__________ 
SISTEMATIC LTDA PRAZO DE ENTREGA 
CLIENTE: 
ENDEREÇO: 
CIDADE: 
INSCRIÇÃO C.G.C. 
 
 
U.F.: 
INSCRIÇÃO ESTADUAL: 
 
 
 
CÓDIGO 
PRODUTO 
UNIDADE QTDE 
DESCRIÇÃO DOS 
PRODUTOS 
VALOR 
UNIT. 
VALOR 
TOTAL 
 
 
 
 
 
 
 28 
Modelagem de Dados 
Em determinados documentos que posteriormente serão registrados em entidades de 
uma base de dados, existem algumas informações que se repetem, retratando ocorrências de 
um mesmo fato (atributo) dentro de uma única tupla (linha) vinculados a sua chave de 
identificação (chave primária). 
A aplicação da 1ª Forma Normal sobre a tabela da entidade PEDIDO, ainda não 
normalizada, conforme as figuras 5.11 e 5.12, criará a entidade PEDIDO-ITEM, que herdará 
os atributos repetitivos e destacados da entidade PEDIDO. 
Observa-se nas figuras apresentadas que, em uma análise detalhada, encontramos no 
documento um grupo repetitivo de informações sobre os produtos solicitados em um pedido. 
Estes atributos que observamos multivalorados caracterizam-se por não possuírem um 
número de ocorrências claramentedefinido, uma vez que nem sempre estarão preenchidas 
todas as linhas do documento. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.12 – 1ª Forma Normal 
 
Portanto, definimos a 1ª Forma Normal na formalidade de uma regra simples: 
Em uma entidade na 1ª Forma Normal para cada chave há a ocorrência de uma 
informação de cada atributo. 
Codd estabeleceu um procedimento para a 1ª Forma Normal que é decompor a 
entidade não-normalizada em tantas entidades quanto for o número de atributos 
 
 
 
 
1ª FORMA NORMAL 
Atributos multivalorados 
Número de ocorrências indefinido 
PRAZO ENT CLIENTE ENDER Nª PEDIDO UF CGC INS.EST CIDADE 
 
 
 
 
UNIDADE QUANT DESCRIÇÃO COD-
PRODUTO 
VALOR 
TOTAL 
VALOR 
UNIT 
 29 
Modelagem de Dados 
multivalorados. 
 
 
5.6.2. Resultado Obtido sobre Pedido após a Aplicação da 1ª Forma Normal 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.13 – Resultado da aplicação da 1ª forma normal 
 
Os quadros apresentados a seguir resumem o resultado da aplicação da 1ª Forma 
Normal sobre a entidade PEDIDO. 
Obtivemos, então, neste instante a visão diferenciada de 2 entidades, sendo que a 
segunda entidade, e recém criada, apresenta um relacionamento estabelecido por chave 
concatenada com a entidade que o originou. 
Neste momento, podemos obter um diagrama de Entidade-Relacionamento entre as 
duas entidades resultantes da 1ª Forma Normal. Este relacionamento caracteriza-se por ser do 
tipo 1 para muitos. 
 
 
 
 
 
 
 
 
APÓS A 1ª FORMA NORMAL 
NUMERO 
PEDIDO 
PRAZO 
ENTREGA CODIGO 
CLIENTE ENDER 
CIDADE 
UF 
CGC 
INSCRIÇÃO 
ESTADUAL 
NUMERO 
PEDIDO 
COD 
PRODUTO 
UNIDADE 
QTDE 
DESCRIÇÃO 
VALOR 
UNITÁRIO 
VALOR 
TOTAL 
 30 
Modelagem de Dados 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.14 – Diagrama E-R após 1ª forma normal 
 
 
5.7. 2ª Forma Normal 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.15 – 2ª forma normal 
 
 
 
 
DIAGRAMA E-R APÓS A 1ª F.N. 
Relacionamento estabelecido por chave concatenada 
(referência lógica) 
 
PEDIDO 
CONTÉM ITEM-DO-
PEDIDO 
 
 
 
 
2ª FORMA NORMAL 
Analisar atributos em 
dependência parcial 
CÓDIGO 
DO 
PRODUTO 
 
QUANT 
 
DESCRIÇÃO 
NÚMERO 
DO 
PEDIDO 
 
VALOR 
UNITÁRIO 
 
UNIDADE 
 
VALOR 
TOTAL 
CHAVE 
 31 
Modelagem de Dados 
Então, podemos afirmar que uma relação R está na segunda Forma Normal (2FN) se, 
e somente se, ela estiver na 1FN e todos os atributos não-chave forem totalmente dependentes 
da chave primária. 
Devemos, então, verificar, já que a entidade possui chave composta, se todos os 
atributos restantes apresentam dependência da chave. A dependência parcial é uma situação 
particular onde um atributo depende somente de parte da chave concatenada. 
Com a finalidade de tornar ainda mais estável o modelo, aplicamos a 2ª Forma Normal 
sobre a entidade, criando novas entidades que herdarão a chave parcial e observarão os 
atributos dependentes desta chave parcial. 
Conforme podemos observar no quadro abaixo, criamos uma entidade para 
PRODUTO, a qual herdou a chave parcial código_produto. Os atributos UNIDADE e 
DESCRIÇÃO também foram passados para a nova entidade. 
Então, a 2ª Forma Normal é a normalização de uma entidade que apresenta uma chave 
concatenada, e que seus atributos, apresentam dependência total desta chave. 
Em uma entidade na 2ª Forma Normal não existem atributos com dependência parcial 
da chave. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.16 – Entidades normalizadas na 2ª forma normal 
 
 
 
 
 
 
 
ENTIDADES NORMALIZADAS NA 2ª F.N. 
Nova entidade 
criada 
Chave 
NUM 
PEDIDO 
CODIGO 
PRODUTO 
QUANTIDA
DE 
VALOR 
UNITÁRIO 
VALOR 
TOTAL 
CODIGO 
PRODUTO 
UNIDADE DESCRIÇÃO 
 32 
Modelagem de Dados 
5.8. 3ª Forma Normal 
 
Na definição da tupla de uma entidade podem ocorrer casos em que um atributo não 
seja dependente direto da chave ou de parte dela, mas sim, dependente de um outro atributo 
constante da tupla e não-chave. 
A aplicação da 3ª Forma Normal sobre este exemplo poderá ser visualizada nos 
quadros seguintes que apresentamos. 
Chamamos este fato de DEPENDÊNCIA TRANSITIVA. É uma forma de 
dependência indireta de chave. 
A aplicação da 3ª Forma Normal obriga a retirada dos atributos não-chaves, os quais 
migrarão para a tupla de outra entidade, caso sejam dependentes de atributo-chave 
estrangeira, ou simplesmente eliminados se forem resultado de cálculo efetuado a partir de 
outro atributo. 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.17 – Entidades normalizadas na 3ª forma normal 
 
Definimos a 3ª Forma Normal como a normalização de uma tupla de forma que não 
existam atributos com dependência transitiva com a chave, ou seja, não existam elementos 
intermediários entre a chave e o próprio atributo. 
 
 
 
 
ENTIDADES NORMALIZADAS – 3ª F.N. 
Se o atributo é resultado de cálculo é eliminado 
 
Se depende de atributo não-chave cria-se uma nova entidade que herdará o 
atributo com dependência transitiva 
 
NOME 
CURSO 
 
CÓDIGO 
CURSO 
 
CÓDIGO 
FUNCIONÁRIO 
 
NOME 
 
CÓDIGO 
CURSO 
CÓDIGO 
DO 
PRODUTO 
 
QUANT 
 
VALOR 
UNITÁRIO 
 
PEDIDO 
 33 
Modelagem de Dados 
5.9. 4ª Forma Normal 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.18 – 4ª forma normal 
 
Quando na 3ª Forma Normal, determinadas tuplas podem conter atributos não-chaves 
que apresentam múltiplos valores correspondentes à mesma chave. 
Chamamos esta anomalia de múltiplos valores para um mesmo valor de chave de 
DEPENDÊNCIA MULTIVALORADA. 
A aplicação da 4ª Forma Normal causará o desmembramento da tupla em “n” 
entidades, sendo “n” igual ao número de atributos que apresentam esta multivaloração. 
A situação da entidade com a anomalia de dependência multivalorada causa uma 
redundância acentuada do atributo na entidade e resulta em ocupação desnecessária dos 
membros da entidade, podendo causar situações críticas de indisponibilidade de área para 
novos desenvolvimentos. 
 
 
 
 
 
Fornecedor Peça Comprador 
F1 P1 C1 
F1 P2 C1 
F1 P3 C2 
F2 P1 C2 
F2 P4 C3 
F2 P2 C1 
 
DEPENDÊNCIA MULTIVALORADA 
 34 
Modelagem de Dados 
Solução 
Após a 4ª Forma Normal 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.19 – Normalização após a 4ª forma normal 
 
 
5.10. Roteiro para Normalização de Dados 
 
Tabela (Entidade) Não-normalizada 
Desmembrar a tabela em um ou mais tabelas sem grupos repetitivos de itens. 
Designar um ou mais atributos como Chave Primária das novas entidades. 
Tabela na 1ª forma normal 
Verificar a existência de atributos parcialmente dependentes da chave. Criar novas entidades, 
que absorverão os atributos com dependência funcional parcial, herdando a chave parcial 
Tabela na 2ª forma normal 
Verificar se não existem atributos dependentes de outros atributos não-chave. 
Destacar atributos dependentes de uma chave estrangeira e incorporar na tabela da chave 
estrangeira ou criá-las, se não existir. Eliminar os atributos obtidos por cálculos a partir de 
outros atributos da mesma tabela 
Tabela na 3ª forma normal 
 
Efetuar a normalização da entidade funcionário apresentada na figura 5.20 
 
 
 
 
NORMALIZAÇÃO APÓS A 4ª F.N. 
A 4ª Forma Normal causará o desmembramento da entidade 
em “n” entidade,onde “n” é igual ao número de atributos 
multivalorados. 
Codigo_Fornecedor 
Código_Peça 
 
FORNECEDOR – PEÇA 
Código_Fornecedor 
Código_Comprador 
FORNECEDOR – COMPRADOR 
 35 
Modelagem de Dados 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.20 – Exercício 
 
Utilize a tabela para a resolução do exercício. 
Entidade 
não-normalizada 
1ª forma normal 2ª forma normal 3ª forma normal 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ENTIDADE FUNCIONÁRIO 
CÓDIGO–FUNCIONÁRIO 
NOME–FUNCIONÁRIO 
DATA–ADMISSÃO 
CÓDIGO–CARGO 
VALOR–SALÁRIO 
NOME–DEPENDENTE OCORRE N VEZES 
DATA–NASC–DEPENDENTE OCORRE N VEZES 
IDADE–DEPENDENTE OCORRE N VEZES 
TOTAL–DE–DEPENDENTES 
DATA–NASC–FUNCIONÁRIO 
CÓDIGO–DEPARTAMENTO 
NOME–DEPARTAMENTO 
CÓDIGO–HABILIDADE OCORRE N VEZES 
NOME–HABILIDADE OCORRE N VEZES 
DATA–FORMAÇÃO–HABILIDADE OCORRE N VEZES 
 
 
EXERCÍCIO