Tecnologia de Base de Dados
Processo de Normalização
Porquê normalizar?
• Após a construção do modelo conceptual dos dados é feita a transformação para um modelo lógico (esquema relacional)
• O conjunto de tabelas obtido representa a estrutura da informação de um modo natural e completo
• Mas é necessário avaliar o grau de redundâncias existente
• A normalização tem como objectivo modificar o conjunto de tabelas obtido, por transformação do modelo conceptual, num outro conjunto de tabelas equivalente menos redundante e mais estável.
Relações bem-estruturadas
• O que são:
– Contêm um mínimo de redundância;
– Permitem aos utilizadores inserir, modificar e apagar linhas em tabelas, sem erros e inconsistências.
Relações bem-estruturadas
Empregado 1
Emp_ID Nome Depart Salário
100 Margarida Marketing 42000 140 Hélio Financeira 39000 110 Cristóvão Sist. Informação 41500 190 Lourenço Contabilidade 38000 150 Susana Marketing 38500
Empregado 2
Emp_ID Nome Depart Salário Curso Dta de conclusão
100 Margarida Marketing 42000 SPSS 19-06-2002 100 Margarida Marketing 42000 Pesquisa 07-10-2002 140 Hélio Financeira 39000 IVA 08-12-2002 110 Cristóvão Sist. Informação 41500 SPSS 01-12-2002 110 Cristóvão Sist. Informação 41500 C++ 22-04-2002 190 Lourenço Contabilidade 38000 Investimentos 07-05-2002 150 Susana Marketing 38500 SPSS 19-06-2002 150 Susana Marketing 38500 TQM 12-08-2003
Tendo em atenção as duas tabelas seguintes qual a que representa uma relação bem-estruturada?
Claro que é a 1ª, uma vez que só apresenta informação sobre um empregado e qualquer modificação, como por ex. o salário, será confinado a uma única linha da tabela.
A 2ª contém informação sobre os empregados e os cursos que eles
frequentaram, donde a chave para esta tabela terá de ser uma combinação entre EmpID e Curso.
Relações bem-estruturadas
Redundâncias
numa
tabela
podem
resultar
em
erros
e
inconsistências, quando o utilizador tenta actualizar os dados na
tabela. São 3 os tipos de anomalias:
•Anomalias de inserção
– Caso se pretenda inserir um novo empregado natabela 2, como a chave é Emp_ID e Curso, só é possível efectuar a inserção se ambas existirem;
•Anomalias de remoção
– se, p.ex., os dados do empregado 140 forapagado da tabela, também perdemos informação sobre o curso que esse empregado frequentou. Será que é isso que se pretende?
•Anomalias de Modificação
– Imagine-se que o empregado 100 tem umaumento de vencimento. Então esse aumento tem de ser registado em cada uma das linhas em que a existem ocorrências desse empregado. Não é muito práctico, pois não?
Relações bem-estruturadas
• Então a tabela Empregado_2 não é uma relação bem
estruturada e pode ser dividida em 2 relações:
–Empregado
–Curso
O conceito de Normalização tem por base esta explicação e a
capacidade de efectuar relações bem-estruturadas.
NORMALIZAÇÃO
• Normalização é um processo sistemático através do qual uma
tabela relacional não normalizada é transformada em um
conjunto de tabelas normalizadas, que representem da melhor
forma possível uma realidade a ser modelada.
• Um conceito básico usado para a normalização é o conceito de
dependência funcional.
NORMALIZAÇÃO
1. Dependência Funcional
• Dada uma relação, um atributo Y é dito funcionalmente
dependente de um outro atributo X se e, somente se,
cada ocorrência de X está associada sempre com a
mesma ocorrência de Y.
X -> Y
Diz-se que:
X determina Y
2. Processo de Normalização
O processo de normalização passa pelas seguintes etapas:
• O documento ou arquivo a ser normalizado é representado na forma de uma tabela não normalizada;
• A tabela vai sendo decomposta em tabelas normalizadas ("bem projetadas"). A normalização dá-se em três passos principais, passando por três formas normais;
• Uma forma normal é um conjunto de regras que uma tabela deve obedecer. Estas regras destinam-se a eliminar as redundâncias de dados.
NORMALIZAÇÃO
- Exemplo de documento a normalizar: Relatório de Alocação a Projeto
CÓDIGO DO PROJETO: LSC001 TIPO: Novo Desenv. DESCRIÇÃO: Sist. Estoque. NOEMP NOME CATEG SALÁRIO INÍCIO TEMPO
PROJETO ALOCAÇÃO
2146 João A1 40 01/11/91 24
3145 Sílvio A2 40 02/10/91 24
6126 José B1 90 03/10/92 18
1181 Carlos A2 40 01/11/92 12
CÓDIGO DO PROJETO: PAG02 TIPO: Manutenção DESCRIÇÃO: Sistema de RH. NOEMP NOME CATEG SALÁRIO INÍCIO TEMPO
PROJETO ALOCAÇÃO
1181 Carlos A2 40 01/11/93 14
5672 Luís A1 40 12/10/91 24
NORMALIZAÇÃO
Forma Não Normalizada
• Uma tabela não normalizada (NN) contém valores de atributos não atômicos, isto é, contém tabelas embutidas (grupos repetidos, arrays).
• Representação não normalizada :
PROJ ( CODPROJ, TIPOPROJ, DESCR,
(NOEMP, NOME, CAT, SAL, DATAINÍCIO,TEMPOALOC))
• Deve-se observar a representação do embutimento de tabelas através de parênteses e a indicação das chaves primárias em cada nível de embutimento.
2.1 Primeira Forma Normal
• Uma tabela na primeira forma normal (PFN) não contém tabelas embutidas.
• A passagem à primeira forma normal é feita nos seguintes passos:
1. Para cada tabela embutida (cada uma abre parênteses), inclusive a mais externa, é criada uma tabela na PFN que contém:
- as chaves primárias de cada tabela externa à tabela embutida; - os atributos da própria tabela embutida.
• 2. São definidas as chaves primárias das tabelas na PFN.
NORMALIZAÇÃO
2.1.1 Passagem à PFN - decomposição de tabelas - Tabela1: corresponde ao nível externo
PROJ ( CODPROJ, TIPOPROJ, DESCR) - Tabela2: corresponde à tabela embutida
PROJEMP (CODPROJ, NOEMP, NOME, CAT, SAL,
NORMALIZAÇÃO
2.1.2 Passagem à PFN - identificação de chaves - Tabela1: corresponde ao nível externo
PROJ ( CODPROJ, TIPOPROJ, DESCR) - Tabela2: corresponde à tabela embutida
PROJEMP (CODPROJ, NOEMP, NOME, CAT, SAL,
NORMALIZAÇÃO
2.2 Segunda Forma Normal
• Uma tabela está na segunda forma normal (SFN) quando, além de estar na PFN, cada atributo não chave primária depende funcionalmente de toda a chave primária e não de apenas parte dela.
• Ao passar uma tabela para a SFN é necessário considerar apenas tabelas que tenham:
- chave primária composta;
NORMALIZAÇÃO
Para o caso do exemplo:
PROJ (CODPROJ, TIPOPROJ, DESCR)
PROJEMP (CODPROJ, NOEMP, DATAINÍCIO,TEMPOALOC) EMP (NOEMP, NOME, CAT, SAL )
NORMALIZAÇÃO
2.3 Terceira Forma Normal
• Uma tabela está na terceira forma normal (TFN) quando, além de estar na SFN, cada atributo não chave primária depende directamente da chave primária, isto é, não há dependências entre atributos não chave;
• Na passagem à TFN, basta considerar tabelas com mais de um atributo não chave.
NORMALIZAÇÃO
Para o caso do exemplo:
PROJ (CODPROJ, TIPOPROJ, DESCR)
PROJEMP (CODPROJ, NOEMP, DATAINÍCIO,TEMPOALOC)
NORMALIZAÇÃO
EMP é subdividida em duas:
EMP ( NOEMP, NOME, CAT ) CATEGORIA (CAT, SAL )
NORMALIZAÇÃO
Documento normalizado:
PROJ (CODPROJ, TIPOPROJ, DESCR)
PROJEMP (CODPROJ, NOEMP, DATAINÍCIO,TEMPOALOC) EMP ( NOEMP, NOME, CAT )
NORMALIZAÇÃO
Na Terceira Forma Normal:
• Atributos Calculados podem ser desconsiderados;
• Chaves candidatas não devem ser consideradas
determinantes funcionais.
2.4 Forma Normal Boyce/Codd (BCFN)
A BCFN é um aperfeiçoamento da 3FN, destinada a lidar com
situações em que se verifique a existência de mais do que uma
chave candidata e que duas chaves candidatas possuam
elementos comuns.
Uma relação está na BCFN quando todos os atributos estão
dependentes da chave, de toda a chave e de nada mais do que a
chave.
Forma Normal Boyce/Codd (BCFN)
(paciente, serviço) médico R(doente, serviço, médico)
(um doente, num determinado serviço hospitalar é sempre observado pelo mesmo médico, donde um médico só pertence a um e um só
serviço)
R1 (paciente,médico) R2 (médico, serviço)
Mas esta solução permite ter um paciente com 2 médicos do mesmo serviço
Tratamento a nível aplicacional,
mantendo a relação R e R2 (criando redundância)
Forma Normal Boyce/Cood (BCFN)
Imaginemos que temos a relação R(CodAluno, CodDisciplina, Professor) na 3FN, onde os alunos frequentam várias disciplinas. Cada professor só lecciona uma disciplina, mas uma disciplina pode ser leccionada por vários professores. Portanto, podemos verificar a seguinte dependência funcional (CodAluno, CodDisciplina) -> Professor.
No entanto, existem duas chaves candidatas compostas, (CodAluno, CodDisciplina) e (CodAluno, Professor) e o atributo Professor não é chave candidata mas determina o CodDisciplina (Professor -> CodDisciplina), pois um professor só lecciona uma disciplina.
Quarta Forma Normal (4FN)
Quinta Forma Normal (5FN)
Em geral uma relação na BCNF está já na 4FN e 5FN,
que surgem para resolver problemas muito raros.
• Uma relação encontra-se na 4FN, se está na BCFN e
não existem dependências multivalor.
• Uma relação R está na 5FN se não puder ser mais
decomposta sem perda de informação.
Consequências da Normalização
1FN 2FN 3FN BCFN 4FN 5FN -+ + relações - redundânciaCompromisso, bom senso, avaliação do desempenho do sistema e, eventualmente, necessidade de
desnormalizar
Desnormalização
O SGBD para além de implementar o modelo de dados
de um universo, deverá considerar alguns aspectos que
permitem melhorias na utilização do sistema.
Trata-se de estabelecer um compromisso entre a
flexibilidade do sistema e a viabilidade da sua utilização.
Pretende-se um esquema equilibrado que não ponha em
risco a integridade da BD, mas que, simultane-amente,
tenha um desempenho razoável. Por essa razão, na
maioria dos casos, o processo de norma-lização pára na
3FN.
Exercício de Normalização 1
• "Uma fábrica de móveis vai informatizar os pedidos de produtos especificados por funcionários para revendedores. Cada pedido contém um número, data, prazo de entrega, nome do cliente (revendedor), endereço, cidade e inscrição estadual do revendedor. Além disso, um pedido contém vários itens de pedido. Cada item de pedido registra o código do produto, descrição, sector, quantidade, valor unitário, desconto e subtotal."
• Forma Não-Normalizada:
PEDIDO (NUM_PEDIDO, DATA, PRAZO, NOME_REV, ENDEREÇO, CIDADE, INSCR_EST, NUM_FUN(COD_PROD, DESC, SECTOR, QUANTIDADE, VALOR_UNIT, DESCONTO, SUBTOTAL) )