ENTIDADE é todo o objeto ou evento sobre o qual armazena-se informação

CLIENTE

EMPRESA

PRODUTO

COTAÇÃO

FILME

1

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

Modelagem de Dados

É uma característica inerente de uma entidadeUm valor ou propriedade descritiva das entidades

ATRIBUTO = ITEM DE DADO = DADO

ATRIBUTOS

2

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.

Modelagem de Dados

É o conjunto de valoresde um atributo, taiscomo:

pesosvalorescoresnomes, etc.

DOMÍNIO

5

a b c

9

3(3,a)

(5,b)

(9,c)

Domínio de X

Domínio de Y

3

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.

Modelagem de Dados

É um atributo ou conjunto de atributos que determina unicamente uma ocorrência de entidade.

ATRIBUTO-CHAVE OU IDENTIFICADOR

MatrículaNome Mãe

NomePaiIdade

DataIngressoNome

Entidade ALUNO

Atributo-chave

F

D

C

@

4

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

Modelagem de Dados

Adão

Jarbas

Pedro

Empregado Departamento

Produção

Compras

Vendas

DepartamentoEmpregado

Está lotado

LOTADO

5

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.

Modelagem de Dados

RELACIONAMENTOS

Funcionário Cargoocupa

CargoFuncionário

6

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.

Modelagem de Dados

CARDINALIDADE

Notação Clássica

TIPOS DE RELACIONAMENTONOTAÇÃO CLÁSSICA

DIVISÃO

FORNECEDOR

VENDA

GERENTE

ITEM DE VENDA

PRODUTO

1:1um : um

n:nmuitos : muitos

1:num : muitos

7

Figura 4.7 – Cardinalidade

4.4. Tipos de Relacionamentos no Modelo Relacional

Figura 4.8 – Tipos de Relacionamentos

Modelagem de Dados

8

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.

Modelagem de Dados

MODELO ENTIDADE-RELACIONAMENTO

DIVISÃO

FORNECEDOR

VENDA

GERENTE

ITEM DE VENDA

PRODUTO

Peter Chen (1976) MT – Notação do Modelo E-R * Notação com mais semântica

n:nmuitos : muitos

1:num : muitos

1:1um : um

1 1

1 N

N N

Diagrama mais simplificado

RELACIONAMENTO COM CAMPOS

MÉDICO PACIENTEconsulta

FORNECEDOR PRODUTOconsulta

CODIGOMEDICO

CODIGOPACIENTE

DATACONSULTA

HORA CONSULTA

PRODUTO FORNECEDOR PREÇO PRAZO

9

Figura 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

Modelagem de Dados

RELACIONAMENTO REFLEXIVO

CODIGO É COMPOSTO

COD PRODCOMPOSTO

COD PROD COMPONENTE QUANTIDADE

COMPONENTE

COMPOSTO

PRODUTO

N

N

10

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 ReflexivoModelagem de Dados

RELACIONAMENTOS MÚLTIPLOS

P–A–D Professor Aluno

Disciplina

n n

n

Um professor tem muitos alunos Um professor leciona muitas disciplinasUm disciplina tem um professor

Um aluno tem um professor por disciplinaUm aluno cursa várias disciplinas

11

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 Modelagem de Dados

AGREGAÇÃO

Máquina

TRABALHA Funcionário Projeto

N N

N

USA

12

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).

Modelagem de Dados

GENERALIZAÇÃO

Funcionário

Secretária

Engenheiro

Motorista

Tipo de funcionário

13

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.

Modelagem de Dados

ENTIDADES SUBCONJUNTO

Funcionário

Motorista

CATEG

1

1

CARTEIRA MOTORISTAPLACA DO CARROCODIGO DO FUNCIONÁRIO

Categoria

14

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

Modelagem de Dados

MODELAGEM PRÁTICA DE DADOSEspecificação das EntidadesEspecificação dos Relacionamentos

Que coisas são trabalhadas?O que pode ser identificado por número, códigoPode assumir forma de uma tabela?É um documento externo? Candidato a entidadeTem significado próprio?Qual a entidade principal?

ESPECIFICAÇÃO DAS ENTIDADES

15

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 de Dados

ESPECIFICAÇÃO DE RELACIONAMENTO

Verbos: possíveis relacionamentos.Obter o tipo de relacionamento visualizado.

Analisar as entidades aos pares.

Para cada relacionamento encontradoQuestionar:É necessário?É útil?É redundante?Se redundante, retirar?Qual a finalidade? (documentar)

16

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

Modelagem de Dados

17

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?

Modelagem de Dados

18

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.

Modelagem de Dados

ANÁLISE DE RELACIONAMENTO 1:1

POSSUI PRODUTO ESTOQUE

1 1

USA MÁQUINA

MISTURA DE COMBUSTÍVEL1 1

Cod–Produto DescriçãoPreço

Cod–Produto Quantidade

19

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.

Modelagem de Dados

ANÁLISE DE RELACIONAMENTO 1:1

Codigo_UnidadeNome_DivisaoId_Empr_GerenteOrçamento

DIVISÃO

Codigo_UnidadeNome_DivisaoOrçamento

DIVISÃO

Id_EmpregadoNomeEndereçoTelefone

PESSOAL

Id_EmpregadoNomeCod_Unidade_GEREndereçoTelefone

PESSOAL

Permite que o impresso seja no futuro GER de mais divisões

20

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

Modelagem de Dados

ANÁLISE DE RELACIONAMENTO 1:N

CONTÉM VENDA ITEM_VENDA1 N

POSSUICLIENTE 1 N

VENDA

Nº DA VENDADATA_VENDACÓDIGO_VENDEDOR

chave Nº DA VENDANUM_ITEMCOD_ITEMQUANTIDADE

chave

COD_CLIENTENOMEENDEREÇO

chave NUM_VENDADATACOD_VENDEDORCOD_CLIENTE

chave

21

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

Modelagem de Dados

QUAIS OS ITENS QUE UM CLIENTE COMPRA?

CLIENTE POSSUI CONTÉM

NUM_VENDADATACOD_VENDEDORCOD_CLIENTE

VENDA

ITEM DE VENDA

NUM_VENDANUM_ITEM

COD_PRODUTOQTDE_PRODUTO

????????????

ID_CLIENTENOMEENDERECO

COD_CLIENTE

22

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

Modelagem de Dados

ANÁLISE DE RELACIONAMENTO N:N

POSSUI ORIGINA

ORIGEMPRODUTO

FORNECED PRODUTO

FORNECEDN FORNECE PRODUTO

N

23

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:

Modelagem de Dados

Codd 1970 – 1ª Forma Normal 1972 – 2ª e 3ª Forma NormalFagin 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

24

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

Modelagem de Dados

25

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.Modelagem de Dados

É 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-dadeNome

Dependência Total

TIPOS DE DEPENDÊNCIA

Chave

DependênciaParcial

N_func CódCurso

DescrCurso

Avaliação DataConclusão

26

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

Modelagem de Dados

27

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

Modelagem de Dados

1ª FORMA NORMAL

Atributos multivaloradosNúmero de ocorrências indefinido

PRAZO ENT CLIENTE ENDERNª PEDIDO UF CGC INS.ESTCIDADE

UNIDADE QUANT DESCRIÇÃOCOD-PRODUTO VALOR TOTALVALOR UNIT

28

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 claramente definido, 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 Modelagem de Dados

APÓS A 1ª FORMA NORMAL

NUMEROPEDIDO

PRAZO ENTREGACODIGO CLIENTE

ENDER

CIDADEUF

CGC

INSCRIÇÃO ESTADUAL

NUMEROPEDIDO

COD PRODUTOUNIDADE

QTDE

DESCRIÇÃO

VALOR UNITÁRIO

VALOR TOTAL

29

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.

Modelagem de Dados

DIAGRAMA E-R APÓS A 1ª F.N.

Relacionamento estabelecido por chave concatenada (referência lógica)

PEDIDOCONTÉM ITEM-DO-PEDIDO

2ª FORMA NORMAL

Analisar atributos emdependência parcial

CÓDIGO DO PRODUTOQUANT DESCRIÇÃO

NÚMERO DO PEDIDOVALOR UNITÁRIO

UNIDADE

VALOR TOTAL

CHAVE

30

Figura 5.14 – Diagrama E-R após 1ª forma normal

5.7. 2ª Forma Normal

Figura 5.15 – 2ª forma normal

Modelagem de Dados

ENTIDADES NORMALIZADAS NA 2ª F.N.

Nova entidadecriada

Chave

NUM PEDIDO CODIGO PRODUTOQUANTIDADE VALOR UNITÁRIOVALOR TOTAL

CODIGO PRODUTOUNIDADE DESCRIÇÃO

31

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

Modelagem de Dados

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 CURSOCÓDIGO CURSO

CÓDIGO FUNCIONÁRIO NOME CÓDIGO CURSO

CÓDIGO DO PRODUTOQUANT VALOR UNITÁRIOPEDIDO

32

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.

Modelagem de Dados

DEPENDÊNCIA MULTIVALORADA

33

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.

Modelagem de Dados

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_FornecedorCódigo_Peça

FORNECEDOR – PEÇA

Código_FornecedorCódigo_Comprador

FORNECEDOR – COMPRADOR

34

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-normalizadaDesmembrar 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 normalVerificar 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 tabelaTabela na 3ª forma normal

Efetuar a normalização da entidade funcionário apresentada na figura 5.20Modelagem de Dados

EXERCÍCIO

35

Figura 5.20 – Exercício

Utilize a tabela para a resolução do exercício.

Entidade

não-normalizada1ª forma normal 2ª forma normal 3ª forma normal

Modelagem de Dados