wiki

BDA - Aula 10 - 2014/2

Normalização


3FN


  • Uma relação encontra-se na 3a. Forma Normal se estiver na 2a. Forma Normal e se não existirem atributos descritores (não pertencentes a nenhuma Chave Candidata) a dependerem funcionalmente de outros atributos descritores (não-chaves)


  • Após a aplicação das regras da 2FN se ainda restarem dados redundantes na tabela avaliada pode-se empregar a 3FN


  • Terceira Forma Normal (3FN):
    • Efetivamente, uma tabela encontra-se na terceira forma normal, quando, além de estar na 2FN, não contém dependências transitivas
  • Dependência transitiva:
    • Uma dependência funcional transitiva ocorre quando uma coluna, além de depender da chave primária da tabela, depende de outra coluna ou conjunto de colunas da tabela
    • Assim sendo, cada atributo deve depender apenas das Chaves Candidatas da relação.


Caso 5


  • Em Pedidos, existem atributos que identificam:
    • um cliente (nome do cliente e endereço completo)
    • um vendedor (nome do vendedor)


  • Os dados dos atributos:
       NomeCliente
       EndCliente
       CidCliente
       UFCliente
  • são dependentes de CodCliente
  • Podemos criar outra entidade => Cliente


  • Da mesma forma, NomeVendedor é dependente de CodVendedor


  • Entidades:
    • Arquivo:BDA-Normalizacao-3FN.pdf


  • Tabelas populadas:
    • Arquivo:BDA-Normalizacao-3FN-B.pdf


FNBC


  • Uma relação está na forma normal de Boyce-Codd se e somente se, para todas as dependências funcionais X -> Y existentes na relação, X é chave ou super-chave da relação


  • A 2FN e a 3FN só tratam dos casos de dependência parcial e transitiva de atributos fora de qualquer chave (primária ou candidata). Aplica-se a FNBC quando:
    • Encontramos duas ou mais chaves candidatas
    • As chaves candidatas são compostas (apresentam mais de um atributo)
    • Todas as chaves candidatas têm um atributo em comum


  • Uma tabela está na FNBC se e somente se toda DF (dependência funcional) não trivial e irredutível à esquerda tem uma chave candidata como determinante


  • A Forma Normal de Boyce/Codd foi criada com a intenção de resolver algumas situações que não eram inicialmente cobertas pelas três primeiras formas normais
  • Foco especial para quando haviam várias chaves na entidade formadas por mais de um atributo
    • E que compartilhavam ao menos um atributo
  • Isso porque as formas normais tratam atributos dependentes das chaves primárias


  • Para estar na FNBC, uma entidade precisa possuir somente atributos que são chaves candidatas


Caso 6


  • Assumindo que um professor possa estar associado a mais de uma escola e uma sala.


   Aluno (NomeAluno, EnderecoAluno, NomeEscola, NumeroSala, NomeProfessor)


  • Chaves candidatas:
       NomeAluno+EnderecoAluno
       NomeAluno+NumeroSala
       NomeAluno+NomeProfessor


  • Encontramos três chaves candidatas
    • Todas apresentam mais de um atributo (concatenados)
    • Todas compartilham um mesmo atributo: NomeAluno


  • Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas
    • uma que contém todos os atributos que descrevem o aluno
    • outra que contém os atributos que designam um professor em uma determinada escola e número de sala


   Aluno (NomeAluno, EnderecoAluno, NomeEscola, NumeroSala)
   Sala (NomeEscola, NumeroSala, NomeProfessor)


  • Resumo


  • 1FN
  1. Cria-se uma tabela na 1FN referente à tabela N e que contém apenas colunas com valores atômicos, isto é, sem as tabelas aninhadas;
  2. Para cada tabela aninhada, cria-se uma tabela na 1FN compostas pelas seguintes colunas:
    1. A chave primária de uma das tabelas na qual a tabela em questão está aninhada
    2. As colunas da própria tabela
  3. São definidas as chaves primárias das tabelas na 1FN que correspondem a tabelas aninhadas


  • 2FN
  1. Copiar para a 2FN cada tabela que tenha chave primária simples ou que não tenha colunas além da chave
  2. Para cada tabela com chave primária composta e com pelo menos uma coluna não chave
  3. Criar na 2FN uma tabela com as chaves primárias da tabela na 1FN
  4. Para cada coluna não chave fazer a seguinte pergunta: a coluna depende de toda a chave ou de apenas parte dela?
  5. Caso a coluna dependa de toda a chave
    1. Criar a coluna correspondente na tabela com a chave completa na 2FN
  6. Caso a coluna não dependa apenas de parte da chave
    1. Criar, caso ainda não existir, uma tabela na 2FN que tenha como chave primária a parte da chave que é determinante da coluna em questão
  7. Criar a coluna dependente dentro da tabela na 2FN


  • 3FN
  1. Copiar para o esquema da 3FN cada tabela que tenha menos de duas colunas não chave, pois neste caso não há como haver dependências transitivas
  2. Para tabelas com duas ou mais colunas não chaves, fazer a seguinte pergunta: a coluna depende de alguma outra coluna não chave?
  3. Caso dependa apenas da chave
    1. Copiar a coluna para a tabela na 3FN
  4. Caso a coluna depender de outra coluna
    1. Criar, caso ainda não exista, uma tabela no esquema na 3FN que tenha como chave primária a coluna na qual há a dependência indireta
    2. Copiar a coluna dependente para a tabela criada
    3. A coluna determinante deve permanecer também na tabela original


  • 4FN


  • Em geral uma relação na BCNF já está 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.


  • A normalização na 4a. Forma Normal requer que não exista nenhuma dependência multi-valorada não-trivial de conjuntos de atributos em algo mais de que um superconjunto de uma chave candidata


  • Mesmo tendo chegado na 3FN, pode ser que a uma entidade contenha um ou mais fatos multivalorados


  • Exemplos:


Caso 7


  • Antes da aplicação da 4FN:
    • Arquivo:BDA-Normalizacao-4FN-Antes.pdf


Caso 8


  • Após aplicação da 4FN:
    • Arquivo:BDA-Normalizacao-4FN-Apos.pdf


  • 5FN


  • A 5a. Forma Normal requisita a não existência de dependências de joins não triviais que não venham de restrições chave.


  • A 5a. Forma Normal lida com relacionamentos múltiplos (ternário, quaternário, etc)


  • Uma entidade estará na 5FN, se estando na 4FN, não for possível reconstruir as informações originais a partir do conteúdo dos outros registros menores
  • O processo de Normalização ajuda imensamente o projetista do Banco de Dados, porém, em alguns casos, algumas formas normais eventualmente, podem ser ignoradas, visando o aprimoramento da performance do sistema


Caso 9


  • Sistema de uma loja de materiais elétricos:
    • Venda de materiais como fios, fusíveis, lâmpadas, etc
    • Padrões de entrada do cliente: postes de concreto, caixa de medidor, etc
    • Na venda de um padrão, o sistema deve baixar o estoque de cada um dos seus componentes
  • Cada um desses componentes pode ser comprado pela loja individualmente, ou sejam podem constar de vários pedidos de compra


  • Entidade:
    • Arquivo:BDA-Normalizacao-5FN-Antes.pdf

Caso 10


  • Se realizarmos uma junção dessas três entidades, utilizando o atributo NumeroPedido como o determinante, teremos como resultado o seguinte:


  • Repare que o penúltimo registro abaixo (destaque) não havia na relação original
  • Se a junção for efetuada tomando o atributo Fornecedor, o resultado será:


  • Entidade:
    • Arquivo:BDA-Normalizacao-5FN-Apos.pdf


  • Novamente, um registro que não existia na relação original é gerado


  • Durante o processo de normalização de dados, descobre-se duas situações, diametralmente opostas:
    • o número de campos das tabelas diminui enquanto o número de tabelas aumenta
  • O SGBD gerencia tranquilamente e eficientemente, as associações que vão aumentando em função de análise do profissional


  • Exemplo


  • 1a. Forma Normal


  • Uma Tabela está na 1a. FN quando seus atributos não contém grupos de repetição (tabelas aninhadas):
       Projeto (CodProjeto, Descricao, (CodFunc, Nome, Salario, DataInicio)) => Não está na 1FN
       Projeto (CodProjeto, Descricao) => Está na 1FN
       ProjFunc (CodProjeto, CodFunc, Nome, Salario, DataInicio) => Está na 1FN


  • 2a. Forma Normal


  • Ocorre quando a chave primária é composta por mais de uma coluna
  • Neste caso, deve-se observar se todas as colunas que não fazem parte da chave dependem de todos os colunas que compõem a chave
  • Se alguma coluna depender somente de parte da chave composta (dependência funcional parcial), então esta coluna deve pertencer a outra tabela
       ProjFunc (CodProj, CodFunc, Nome, Cargo, Salario, DataInicio) => Não está na 2FN
       ProjFunc (CodProj, CodFunc, DataInicio) => Está na 2FN
       Func (CodFunc, Nome, Cargo, Salario) => Está na 2FN


  • 3a. Forma Normal


  • Uma tabela está na 3a. Forma Normal quando cada coluna não chave depende diretamente da chave primária, isto é, quando não há dependências funcionais transitivas ou indiretas
  • Uma dependência funcional transitiva acontece quando uma coluna não chave primária depende funcionalmente de outra coluna ou combinação de colunas não chave primária
       Func (CodFunc, Nome, Cargo, Salario) => Não está na 3FN
       Func (CodFunc, Nome, CodCargo) => Está na 3FN
       Cargo (CodCargo,Salario) => Está na 3FN


  • Forma Normal de Boyce-Codd


  • A 2FN e a 3FN só tratam dos casos de dependência parcial e transitiva de atributos fora de qualquer chave (primária ou candidata)
  • Aplica-se a FNBC quando:
    • Encontramos duas ou mais chaves candidatas
    • As chaves candidatas são compostas (apresentam mais de um atributo)
    • Todas as chaves candidatas têm um atributo em comum


  • Uma tabela está na FNBC se e somente se toda DF (dependência funcional) não trivial e irredutível à esquerda tem uma chave candidata como determinante
  • Exemplo:
    • Assumindo que um professor possa estar associado a mais de uma escola e uma sala.
 Aluno (NomeAluno, EnderecoAluno, NomeEscola, NroSala, NomeProfessor)


  • Chaves candidatas:
       NomeAluno + EnderecoAluno
       Nomeluno + NroSala
       NomeAluno + NomeProfessor


  • Encontramos três chaves candidatas
    • Todas apresentam mais de um atributo (concatenados)
    • Todas compartilham um mesmo atributo: NomeAluno


  • Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas
    • uma que contém todos os atributos que descrevem o aluno
    • outra que contém os atributos que designam um professor em uma determinada escola e número de sala
   Aluno (NomeAluno, EnderecoAluno, NomeEscola, NroSala)
   Sala (NomeEscola, NroSala, NomeProfessor)


  • 4a. Forma Normal


  • Uma tabela está na 4a. Forma Normal caso não possua mais de uma dependência funcional multivalorada


  • Uma situação onde temos um controle de projetos ligados a funcionários e a equipamentos.


  • Arquivo:BDA-Normalizacao-Exemplo-4FN.pdf
   CodProj multidetermina de forma independente CodFunc e CodEquip.


  • 5a. Forma Normal


  • Aplicada em casos de relacionamentos múltiplos
  • Trata do conceito de dependência de junção
  • Primeiro decompõe-se a tabela através de uma operação de projeção e em seguida faz-se a reconstrução da mesma através de uma junção
  • A tabela está na 5a. Forma Normal quando seu conteúdo não puder ser reconstruído através da junção destas tabelas secundárias


  • Arquivo:BDA-Normalizacao-Exemplo-5FN.pdf
  • Reconstruindo o conteúdo da tabela original através da junção natural das tabelas secundárias
  • Arquivo:BDA-Normalizacao-Exemplo-5FNApos.pdf
Disponível em “http://3.143.69.156/wiki/index.php?title=BDA_-_Aula_10_-_2014/2&oldid=30512”