|


ADMINISTRAÇÃO DE BANCO DE DADOS

GRUPO: ADRIANO PEREIRA FRAZÃO

FRANCISCO PINHEIRO DA SILVA ROSA
ISAIAS LEAL DA SILVA
MARCELO JOSÉ MENDES DA COSTA
RUBENS SILVA RODRIGUES
 2
NORMALIZAÇÃO DE DADOS

   

 
 3
NORMALIZAÇÃO DE DADOS

Vamos pensar um pouco!

 4
NORMALIZAÇÃO DE DADOS

Resposta

È A normalização é basicamente criar um esquema de banco de

dados que seja evitados dados duplicados e redundantes. Se
alguma parte dos dados é duplicado vários lugares no banco de
dados, há o risco de que ele é atualizado em um só lugar, mas não
o outro, levando a corrupção de dados.

È Há um número de níveis de normalização de 1. forma normal a 5.

forma normal. Cada formulário normal descreve como se livrar de
algum problema específico, geralmente relacionado a redundância.
 Você sabia? NORMALIZAÇÃO DE DADOS
5

        !" #

 $%&' (  )* +    ++
, -
  ++ +   +
.+* Vida
Nascido em Portland Bill, Dorset (Reino Unido), pai de couro fabricante e mãe professora, ele estudou
matemática e química na Universidade de Oxford. Mais tarde, durante a Segunda Guerra Mundial, era um
capitão-piloto da Real Força Aérea entre 1942 e 1945.

Em 1948 ele se mudou para New York para trabalhar como um matemático programador da IBM, mas se
mudou para Ottawa em 1953 devido a divergências políticas com o U. S. senador Joseph McCarthy. Após
retornar de uma década depois dos Estados Unidos obteve um doutorado em ciência da computação na
Universidade de Michigan, Ann Arbor (1965). Em 1967 ele se mudou para a Califórnia, onde trabalhou no
Laboratório de Pesquisa da IBM em San Jose.

Em 1978 ele se divorciou de sua esposa Elizabeth, e em 1990 casou-se com Sharon Weinberg, um colega
da IBM e da matemática. Em 1981 recebeu o Prémio Turing em Ciência da Computação, o prêmio mais
alto em seu campo. Ele morreu de insuficiência cardíaca em Williams Island, na Filadélfia (EUA), 23 de abril
de 2003.

Obra
Nos anos sessenta e setenta, trabalhou em suas teorias sobre a modelagem de dados, publicando seu trabalho "Um
Modelo Relacional de Dados para grandes bancos de dados compartilhados" ("Um Modelo Relacional de Dados para
grandes bancos de dados compartilhados") em 1970 . Para seu desgosto, a IBM não se apressou a explorar as suas
sugestões, até que começou a ser implementado por empresas rivais. Por exemplo, Larry Ellison, projetou o banco de
dados Oracle com base em idéias de Codd.

Codd continuou a se expandir e desenvolver o seu modelo relacional, por vezes em colaboração com Chris Date. Ele
também trabalhou na área de autômatos celulares, em que lidou com sua tese de doutorado. Codd definiu as três
primeiras Normal formulários para requerer a normalização dos sistemas de banco de dados. Além disso, o Boyce-Codd
Normal Form é nomeado em sua honra. Ele também cunhou o termo OLAP e escreveu os doze leis de processamento
analítico informatizado.
 6
NORMALIZAÇÃO DE DADOS
Entendendo mais...
È Um dos passos mais importantes na criação de um banco de dados é o conhecimento de que
os dados estão distribuídos corretamente nas suas diversas tabelas. Com estruturas de dados
corretas, o restante do aplicativo (as consultas, os formulários, os relatórios, os códigos) fica
significativamente simplificado. O nome formal da criação correta de tabelas é normalização
de banco de dados.

 /+ 0+

+     + 1+-   

 + .   + +  
++    ++  * +  + 2+ +  2   
+22  2*

3+ / + 0+ |++,+

$*    2- 4  + ++ +  + +    + +

+ ++,+  +1   + 2*  5-
  6 + 7+-
  2   + + - - + + 5+ | + +
  .
 +1- 1   ++-
  +   ++ 
 7 *

8* 9 2 +1 + + ++,+- 2:+    + 2* + +

+ +    ++ + + + ;+<  2+
+,   + +

=* >  1 ? 

+ + + ++,+    + 2  
++      1 1  +*
 7
NORMALIZAÇÃO DE DADOS
Entendendo mais...

O Que Vai Ser Feito com os Dados?

È Os usuários precisarão editar os dados e, se sim, como os dados deverão ser mostrados para que possam entendê-
los e editá-los? Existem regras de validação e tabelas de pesquisa relacionadas? Existem situações de auditoria
associadas com a entrada de dados que exigem a manutenção de cópias de segurança das exclusões e alterações?
Que tipo de informações resumidas devem ser apresentadas ao cliente? Será necessária a exportação de arquivos?
Com estas informações pode-se ter uma idéia de como os dados contidos no banco se relacionam.
Como os Dados Se relacionam?

È Agrupe seus dados em campos relacionados (como informações relativas aos clientes, informações relativas aos
pedidos, e assim por diante). Cada grupo de campos representa uma futura tabela no banco de dados. Deve-se,
então, considerar como elas se relacionam. Por exemplo, quais tabelas são relacionadas em relacionamentos um-
para-muitos (por exemplo, um cliente pode ter vários pedidos)? Quais tabelas têm relacionamentos um-para-um (que
podem, talvez, ser combinadas em uma única tabela)?
O Que Vai Acontecer com os Dados com o Tempo?

È Depois que as tabelas são criadas, o impacto do tempo raramente é considerado, podendo causar sérios problemas
mais adiante. Muitas tabelas funcionam muito bem no uso imediato. Entretanto, muitas delas desmoronam à medida
que o usuário modifica ou acrescenta dados com o correr do tempo. Muitas vezes os desenvolvedores necessitam
reestruturar suas tabelas para atender a estas mudanças. Quando a estrutura de uma tabela é alterada, todas as
suas dependências (consultas, formulários, relatórios, códigos) também necessitam ser alterados. Entender e
antecipar estas alterações permite uma implementação que minimize os problemas.
 8
NORMALIZAÇÃO DE DADOS

È Normalização de dados é o processo formal passo

a passo que examina os atributos de uma entidade,
com o objetivo de evitar anomalias observadas na
inclusão, exclusão e alteração de registros.

È Uma regra de ouro que devemos observar quando do

projeto de um Banco de Dados baseado no Modelo
Relacional de Dados é a de "não misturar assuntos
em uma mesma Tabela". Por exemplo: na Tabela
Clientes devemos colocar somente campos
relacionados com o assunto Clientes. Não devemos
misturar campos relacionados com outros assuntos,
tais como Pedidos, Produtos, etc. Essa "Mistura de
Assuntos" em uma mesma tabela acaba por gerar
repetição desnecessária dos dados bem como
inconsistência dos dados.
 9
NORMALIZAÇÃO DE DADOS

È Normalmente após a aplicação das regras de normalização de dados, algumas tabelas acabam
sendo divididas em duas ou mais tabelas, o que no final gera um número maior de tabelas do
que o originalmente existente. Este processo causa a simplificação dos atributos de uma tabela,
colaborando significativamente para a estabilidade do modelo de dados, reduzindo-se
consideravelmente as necessidades de manutenção.

Analisando teremos:
Todos os clientes possuem Rua, CEP e Bairro, e
essas informações estão na mesma célula da
tabela, logo ela não está na primeira forma normal.
Para normalizar, deveremos colocar cada
informação em uma coluna diferente, como no
exemplo a seguir:

Tabela desnormalizada, ou seja, não está na 1ª forma normal

Tabela ainda não está na primeira forma normal

 10
NORMALIZAÇÃO DE DADOS

È Mesmo com o ajuste acima, a tabela ainda não está na primeira forma normal, pois há clientes com
mais de um telefone e os valores estão em uma mesma célula. Para normalizar será necessário criar
uma nova tabela para armazenar os números dos telefones e o campo-chave da tabela cliente. Veja o
resultado a seguir:

Tabela na 1ª forma normal

Tabela na 1ª forma normal

No exempo acima foi gerado uma segunda entidade para que a primeira forma normal fosse
satisfeita, contudo é possível manter a tabela original, admitindo-se valores duplos em uma
mesma coluna, como exemplo o campo telefone ficaria assim: 11-3400-3563 e 19-3500-9650.
Neste caso a tabela ficaria desnormalizada, mas muitos acabam preferindo assim,
principalmente quando há poucos casos de repetição.
 11
NORMALIZAÇÃO DE DADOS

Uma tabela está na Segunda Forma Normal 2FN se ela estiver na 1FN e todos os atributos não chave forem
totalmente dependentes da chave primária (dependente de toda a chave e não apenas de parte dela).
Se o nome do produto já existe na tabela produtos, então não é necessário que ele exista na tabela de produtos. A
segunda forma normal trata destas anomalias e evita que valores fiquem em redundâcia no banco de dados.

Procedimentos:
a) Identificar os atributos que não são funcionalmente dependentes de toda a chave primária;
b) Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles.

A chave primária da nova entidade será o atributo do qual os atributos do qual os atributos removidos são
funcionalmente dependentes.

Exemplo de segunda forma normal

Considere a tabela vendas abaixo:

Vendas
N_pedido
Código_produto
Produto
Quant
Valor_unit
Subtotal
 12
NORMALIZAÇÃO DE DADOS
Agora a tabela com os dados:

Tabela não está na segunda forma normal

Analisando teremos:

O nome do produto depende do código do produto, porém não depende de N_pedido que é a chave primária da
tabela, portanto não está na segunda forma normal. Isto gera problemas com a manutenção dos dados, pois se
houver alteração no nome do produto teremos que alterar em todos os registros da tabela venda.

Para normalizar esta tabela teremos de criar a tabela Produto que ficará com os atributos Código_produto e produto e
na tabela Venda manteremos somente os atributos N_pedido, código_produto, quant, valor_unit e subtotal. Veja o
resultado abaixo:

Tabela na 2ª forma normal

Tabela na 2ª forma normal

# 2+    -

 +   
2+ 1+    ++ + + +
 + + +*
 13
NORMALIZAÇÃO DE DADOS

Uma tabela está na Terceira Forma Normal 3FN se ela estiver na 2FN e se nenhuma
coluna não-chave depender de outra coluna não-chave.
Na terceira forma normal temos de eliminar aqueles campos que podem ser obtidos pela
equação de outros campos da mesma tabela.

Procedimentos:
a) Identificar todos os atributos que são funcionalmente dependentes de outros atributos
não chave;
b) Removê-los.
A chave primária da nova entidade será o atributo do qual os atributos removidos são
funcionalmente dependentes.
Exemplo de normalização na terceira forma normal
Considere a tabela abaixo:

Tabela não está na terceira forma normal

Considerando ainda a nossa tabela Venda, veremos que a mesma não está na terceira
forma normal, pois o subtotal é o resultado da multiplicação Quant X Valor_unit, desta
forma a coluna subtotal depende de outras colunas não-chave.
 14
NORMALIZAÇÃO DE DADOS

Para normalizar esta tabela na terceira forma normal teremos de

eliminar a coluna subtotal, como no exemplo a seguir:

Tabela na terceira forma normal

# 2+ + +     +  
-     1 +   + +*
@. 1   + |  +  + + +*
Sintetizando.... NORMALIZAÇÃO DE DADOS
15

1ª FORMA NORMAL:

UMA RELAÇÃO ESTÁ NA 1FN SE NÃO

TEM GRUPOS DE ATRIBUTOS OU
ATRIBUTOS REPETITIVOS.

2ª FORMA NORMAL:

UMA RELAÇÃO ESTÁ NA 2FN SE ESTÁ

NA 1FN E SE TODOS OS ATRIBUTOS
NÃO CHAVE DEPENDEM DA
TOTALIDADE DA CHAVE.
3ª FORMA NORMAL:

UMA RELAÇÃO ESTÁ NA 3FN SE ESTÁ

NA 2FN E, TODOS OS SEUS ATRIBUTOS
NÃO CHAVE NÃO SÃO IDENTIFICADOS
POR UM OUTRO TAMBÉM NÃO CHAVE.
 16
NORMALIZAÇÃO DE DADOS

NORMALIZAÇÃO?

É importante?

Sim, é muito importante. Por ter um banco de

dados sem erros de normalização, não correo
risco de ficar com dados inválidos ou danificados
dados no banco de dados. É muito difícil se livrar
de dados corrompidos, quando pela primeira vez
ele foi inserido no banco de dados.
 17
NORMALIZAÇÃO DE DADOS

O Esquema Relacional assim obtido garante:

‡ Redundância Mínima : A informação referente a um Produto ou a um Cliente, ocorrem apenas uma vez.

‡ Facilidade de manutenção: Qualquer alteração é efectuada num só local. Por exemplo, a alteração do
preço de um determinado Produto não altera informação presente em nenhuma outra relação. É possível
obter informação referente a um Cliente mesmo que esse não tenha efectuada nenhuma compra. É
possível obter informação referente a um Produto mesmo que esse não esteja incluído em nenhuma
Factura.

‡ Estabilidade: Qualquer necessidade posterior, de tratamento da informação presente neste esquema, é

facilmente satisfeita.
 18
NORMALIZAÇÃO DE DADOS

Com isso podemos concluir que como

resultado do Processo de Normalização,
iremos obter um número maior de tabelas,
porém sem problemas de redundância e
inconsistência dos dados.