4.7 GEOLOGICAL RESOURCES 4.7.1 Introduction 4.7.2 Methodology
4 … · Web viewpor disciplina. Um professor pode ter vários alunos em uma disciplina. 4.7.2....
Transcript of 4 … · Web viewpor disciplina. Um professor pode ter vários alunos em uma disciplina. 4.7.2....
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