wiki

BDA - Aula 06 - 2013/1

Revisão de 21h04min de 8 de julho de 2013 por Lclaudio (discussão | contribs) (→2FN)

Normalização




Dependência Funcional


  • Consiste numa restrição entre dois conjuntos de atributos de uma mesma entidade/relação
  • Uma dependência funcional é representada pela relação X -> Y, em que X e Y são subconjuntos de atributos de uma relação qualquer
  • Isso impõe uma restrição na qual um componente Y de uma tupla (registro) é dependente de um valor do componente X (ou é determinado por ele)


  • Do mesmo modo, o valores do componente X determinam de forma unívoca os valores do componente Y
  • Resumindo, Y é dependente funcionalmente de X


  • Supondo o esquema de uma relação abaixo, onde os três primeiros atributos, cujos nomes se encontram destacados, representam a chave primária da relação
 MatriculaAluno CodigoCurso CodigoDisciplina NomeAluno DataMatricula NomeCurso	NomeDisciplina NotaProva


  • Podemos estabelecer 4 dependências funcionais neste exemplo:
  1. MatriculaAluno -> {NomeAluno, DataMatricula) => O valor do atributo MatriculaAluno determina o valor dos atributos NomeAluno e DataMatricula
  2. CodigoCurso -> NomeCurso => O valor do atributo CodigoCurso determina o valor do atributo NomeCurso
  3. CodigoDisciplina -> NomeDisciplina => O valor do atributo CodigoDisciplina determina o valor do atributo NomeDisciplina
  4. {MatriculaAluno, CodigoCurso, CodigoDisciplina} -> NotaProva => A combinação de valores dos atributos MatriculaAluno, CodigoCurso e CodigoDisciplina determina o valor do atributo NotaProva.


Categorias


  • Total ou Completa:
    • Podemos ter situações em que não se utilizam atributos simples para determinar os valores de outros atributos
    • Neste caso, teremos um atributo que é dependente funcional da combinação de dois ou mais atributos
    • Quando um atributo que não faz parte da chave primária depende funcionalmente de todos os atributos que fazem parte da chave, tem-se uma dependência funcional total.


  • É considerado o 1o. tipo, onde a dependência só existe se a chave primária composta por vários atributos determinar univocamente um atributo ou um conjunto de atributos
  • No nosso exemplo, o atributo NotaProva é dependente total da chave primária formada pelos atributos MatriculaAluno/ CodigoCurso/CodigoDisciplina.
  • Exemplo: Entidade DEPENDENTE
    • (CodigoPaciente, DataNascimento} -> {NomeDependente} (?)
  • No caso, os valores dos atributos CodigoPaciente e DataNascimento determinam o valor para o atributo NomeDependente
    • O nome do dependente só pode ser determinado em função de dois atributos



  • Parcial:
    • Temos uma situação em que um atributo/conjunto de atributos depende de outro(s) atributo(s) que não fazem parte de uma chave primária
    • Quando um atributo que não faz parte da chave primária depende funcionalmente de apenas alguns dos atributos que fazem parte da chave primária, o 2o. tipo, então, ocorre visto que o atributo/conjunto de atributos depende apenas de parte dos valores da chave primária
  • Exemplo: Banco de Dados com as entidades MEDICO e PACIENTE
    • CRM -> NomeMedico
    • CodigoPaciente -> {NomePaciente, CPF, RG }
  • A 1a, dependência especifica que o valor atributo CRM da entidade MEDICO determina de forma unívoca o valor do atributo NomeMedico dessa mesma entidade
  • O valor do atributo CodigoPaciente (entidade PACIENTE) determina o nome, o CPF e o RG do paciente
  • É importante notar que apenas o valor dos atributos CRM e CodigoPaciente é necessário para que seja possvel determinar o nome do médico ou o CPF e RG do paciente, ou seja, é uma dependência parcial


  • Transitiva ou Indireta:
    • Esta dependência ocorre quando a dependência funcional se realiza entre atributos que não fazem parte da chave primária
    • Exemplo:
      • Numa tabela de Vendas, temos o atributo PreçoTotal. Este campo é o resultado do valor unitário do produto multiplicado pela quantidade, isto é, para um preço total existir ele DEPENDE de valor unitário e quantidade
      • O ValorUnitário deve estar numa tabela Produtos, relacionada à venda e Quantidade está na própria tabela Vendas.
      • PreçoTotal depende destes dois campos e eles não são campos-chave.


Normalização


  • Após a construção do modelo conceitual dos dados (Modelo Entidade/Relacionamento) é feita a transformação para o modelo lógico (Esquema de Tabelas)
  • O desenho de tabelas obtido representa a estrutura da informação de um modo natural e completo.


  • Normalização é um processo baseado nas chamadas formais normais
    • Uma forma normal é uma regra que deve ser aplicada na construção das tabelas do banco de dados para que estas fiquem bem estruturadas
    • A normalização pode ser entendida como um processo submetido a estas varias formas normais


  • Objetivo principal: eliminar a redundância nos dados armazenados em tabelas, resultando na diminuição do espaço e dos riscos de inconsistências em atualizações de dados
  • Quando um atributo é alterado em uma tabela que não está totalmente normalizada, é necessário alterá-lo em todas as linhas em que ele ocorre, haja visto a sua repetição
  • Tal operação poderia ser executada apenas uma vez, caso este atributo estivesse normalizado
  • As formas têm uma ordem e são dependentes, isto é, para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante.


  • Efetivamente, a Normalização tem como objetivo avaliar a qualidade do Modelo de Tabelas e transformá-lo (em caso de necessidade) num Modelo (Conjunto de Tabelas) equivalente, menos redundante e mais estável.


1FN


  • Verificação de Tabelas Aninhadas


  • Uma relação está na 1a. Forma Normal se e somente se cada linha contiver exatamente um valor para cada atributo
  • Dado que as Relações(Tabelas) são estruturas bidimensionais, então no cruzamento de uma linha com uma coluna (atributo) só é possível armazenar valores atômicos.
  • Para isso, não deve conter tabelas aninhadas


  • Um jeito fácil de verificar esta norma é fazer uma leitura dos campos das tabelas fazendo a pergunta:
    • Este campo depende de algum outro?


  • Se sim, então devemos arrumar um método para corrigir o problema.


  • Método:
    • Remover o grupo de repetição
    • Expandir a chave primária


  • Seguindo a definição devemos normalizar a tabela decompondo-a em duas
    • Uma relação R está na 1FN se:
    • Todo valor em R for atômico
    • Ou seja, R não contém grupos de repetição


  • Considerações:
    • Geralmente considerada parte da definição formal de uma relação
    • Não permite atributos multivalorados, compostos ou suas combinações


Caso 1


   cliente (NroCliente, Nome, {End-Cliente})
   Corrigindo o problema:
       Solução: cliente (NroCliente, Nome, End-Cliente, CidCliente, UFCliente)


Caso 2


  • Exemplificando com a tabela Venda
  • Esquema relacional da tabela:
       Venda
           Codvenda (Int)
           Cliente (Str)
           Endereco (Str)
           Cep (Int)
           Cidade (Str)
           Estado (Str)
           Telefone (Int)
           Produto (Str)
           Quantidade (Float)
           ValorUnitário (Float)
           PreçoTotal (Float)


  • Análise:
    • A tabela Venda, deve armazenar informações da venda
    • O campo Cliente é dependente de CodVenda, afinal para cada Venda há um cliente
    • Campo Endereço: não depende de Codvenda, e sim de Cliente, pois é uma informação particular ao cliente
    • Não existe um endereço de venda, existe sim um endereço do cliente para qual se fez a venda
    • Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, são referentes ao cliente e não é venda
       Venda (Codvenda, [Cliente, Endereço, Cep, Cidade, Estado, Telefone], Produto, Quantidade, ValorUnitário, PreçoTotal)


  • Solução:
    • Extrair estes campos para uma nova tabela
    • Adicionar uma chave-primária à nova tabela
    • Relacioná-la com a tabela Venda criando uma chave-estrangeira


  • Resultado:
       Cliente (Codcliente, Nome, Endereço, Cep, Cidade, Estado, Telefone).
       Venda (Codvenda, Codcliente, Produto, Quantidade, ValorUnitário, PreçoTotal).


  • Aplicando novamente a 1a. forma normal às 2 tabelas geradas
  • Uma situação comum em tabelas de cadastro é o caso Cidade-Estado
  • Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade
  • No entanto Cidade, também depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre deverá ser Paraná, porém se o Estado for Paraná, a cidade também poderá ser Londrina
  • Isso é o que chamamos de Dependência funcional:
    • aparentemente, uma informação depende da outra


  • No caso Cidade-Estado a solução é simples:
    • Extraímos Cidade e Estado, de Cliente e geramos uma nova tabela
    • Em seguida, o mesmo processo feito anteriormente:
      • Adicionar uma chave-primária à nova tabela e relacioná-la criando uma chave-estrangeira na antiga tabela


   Cidade (Codcidade, Nome, Estado). 
   Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone) 
   Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, ValorUnitário, PreçoTotal)


  • Seguindo com o exemplo, a tabela Cliente encontra-se na 1a. forma normal, pois não há mais tabelas aninhadas
  • Verificando Venda, identificamos mais uma tabela aninhada
  • Os campos entre colchetes são referente à mesma coisa: Produto de Venda
   Venda (Codvenda, Codcliente, Codcidade, [Produto, Quantidade, Valorunitario, Valorfinal])


  • Na maioria das situações, produtos têm um valor previamente especificado
  • O ValorUnitário depende de Produto
  • Já a Quantidade não depende do Produto e sim da Venda
   Cidade (Codcidade, Nome, Estado) 
   Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone) 
   Produto (Codproduto, Nome, ValorUnitário) 
   Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, PreçoTotal)


  • Utilizando a 1a. Forma Normal na tabela Venda, obtivemos 3 tabelas


2FN


  • A 2a. Forma Normal exige um pouco mais de conhecimento sobre as dependências funcionais, prioritariamente para a dependência funcional total
  • Uma relação está na 2a. Forma Normal se estiver na 1a. e se todos os atributos descritores (não pertencentes a nenhuma chave candidata) dependerem da totalidade da chave (e não apenas de parte dela)


  • Isso quer dizer que uma tabela encontra-se na 2FN, quando, além de estar na 1FN, não contem dependências parciais
    • Dependência parcial = uma dependência parcial ocorre quando uma coluna depende apenas de parte de uma chave primária composta


  • Resumindo, a entidade se encontra na 2FN se, além de estar na 1a., todos os seus atributos são totalmente dependentes da chave primária composta
  • Significa que atributos que são parcialmente dependentes devem ser removidos.
  • Se observarmos as tabelas e identificarmos repetição dos dados nas tuplas requer-se a 2FN


  • Relendo cada campo e questionando:
    • Este campo depende de toda a chave?
    • Se não, temos uma dependência parcial


Caso 3


  • Uma entidade Item possui chave primária composta que é constituída pelos atributos NumPedido e CodProduto
  • Os atributos Descricao e PrecoUnit não dependem totalmente dessa chave, ao contrário de Quantidade e ValorTotal
    • Nova entidade: Produto


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


  • Tabelas populadas:
    • Arquivo:BDA-Normalizacao-2FN-b.pdf


Caso 4


  • Reavaliando o caso Cidade-Estado que gerava uma dependência funcional
  • Após a normalização da tabela Venda, obtivemos uma chave composta de 4 campos:
       Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, PreçoTotal)


  • A questão agora é verificar se cada campo não-chave depende destas 4 chaves


  • Procedimento:
  • O 1o. campo não-chave é Quantidade
    • Quantidade depende de Codvenda => Para cada venda há uma quantidade específica de itens
    • Quantidade depende de Codvenda e Codcliente => Para um cliente podem ser feitas várias vendas, com quantidades diferentes
    • Quantidade não depende de Cidade e quem depende de Cidade é Cliente


  • Temos uma dependência parcial pois Quantidade depende de Codproduto, pois para cada produto da Venda há uma quantidade certa


  • Quantidade depende de 3 campos, dos 4 que compõe a chave de Venda
  • Quem sobra nessa história é Codcidade
  • A tabela Cidade já está ligada com Cliente, que já está ligada com Venda
  • A chave Codcidade em Venda é redundante, portanto podemos eliminá-la
           Venda (Codvenda, Codcliente, Codproduto, Quantidade, PrecoTotal)


  • Problema:
    • Existe alguma necessidade de manter CodCidade como campo não-chave?


  • O próximo campo não-chave é PreçoTotal


  • Avaliando PreçoTotal da mesma forma que Quantidade
    • Chega-se à conclusão de que ele depende de toda a chave de Venda.


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
       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
       Para tabelas com duas ou mais colunas n�o chaves, fazer a seguinte pergunta: �a coluna depende de alguma outra coluna n�o chave?�
       Caso dependa apenas da chave
           Copiar a coluna para a tabela na 3FN 
       Caso a coluna depender de outra coluna
           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
           Copiar a coluna dependente para a tabela criada
           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


[editar] 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


[editar] 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


[editar] 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


[editar] 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)


[editar] 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.


[editar] 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

[editar] Exerc�cios


Normalizar sequencialmente segundo as formas normais, sempre que poss�vel: 


   01. Encomenda de Livros:
   PedidoLivro (NomeCliente, ISBN, DataPedido, Titulo, Autor(es), Quantidade, Pre�o, ValorTotal)
       Vilson:
           Arquivo:Normalizacao-PedidoLivro.pdf 



   02. Projetos:
       Empregado (NroEmpregado, NomeEmpregado, NroDepto, NomeDepto, NroGerente, NomeGerente, NroProjeto, NomeProjetom, DataInicio, FTE)
       Guilherme:
           Arquivo:Normalizacao-Empregado.pdf 



   03. Compras:
       Ordem de Compra (CodOrdemCompra, DataEmissao, CodFornecedor, NumFornecedor, EndFornecedor, CodMaterial (n vezes), DescricaoMaterial (n vezes), QuantComprada (n vezes), ValorUnit (n vezes), ValorTotalItem (n vezes), ValorTotalOC)
       Rog�rio:
           Arquivo:Normalizacao-OC.pdf 



   04. Notas Fiscais:
       NotasFiscais (Num_ NF, S�rie, Data emiss�o, CodCliente, Nome Cliente, EndCliente, CgcCliente, CodigoMercadoria, DescricaoMercadoria, QuantidadeVendida, PrecoVenda, TotalVendaMercadoria, TotalGeral)
       Daniel:
           Arquivo:Normalizacao-NF.pdf 



   05. Gest�o de Projetos:
       Gestao Projetos (NumProjeto, NumEmpregado, NomeProjeto, NomeEmpregado, Funcao, Salario, Horas)
       Vilson:
           Arquivo:Normalizacao-GestaoProjetos.pdf 



   06. Vendas:
       Vendedor (NumVendedor, NomeVendedor, EndVendedor, Telefone, Cep, Localidade, NumProduto, DescricaoProduto, Saldo, PrecoUnit�rio, NumFatura, QuantVendida, Total)
       Guilherme:
           Arquivo:Normalizacao-Vendedor.pdf 



   07. Recursos Humanos:
       Funcionario (NumFuncionario, NomeFuncionario, NumEmpresa, NomeEmpresa, NumDepto, NomeDepto)
       Rog�rio:
           Arquivo:Normalizacao-Funcionario.pdf 



   08. Controle Acad�mico:
       Aluno ( NroAluno, CodDepto, NomeDepto, SiglaDepto, CodOrientador, NomeOrientador,FoneOrientador, CodCurso)
       As seguintes depend�ncias funcionais devem ser garantidas na normaliza��o:
           CodDepto ? {NomeDepto, SiglaDepto}
           CodOrientador ? {NomeOrientador, FoneOrientador}
           NroAluno ? {CodDepto, CodOrientador, CodCurso} 
       Observa��es adicionais:
           Um aluno somente pode estar associado a um departamento
           Um aluno cursa apenas um �nico curso
           Um aluno somente pode ser orientado por um �nico orientador 
       Daniel:
           Arquivo:Normalizacao-Aluno.pdf 



   09. Corporativo:
       Empresa (CodEmpresa, NomeEmpresa, EndEmpresa, NomeFundador, NacionalidadeFundador, { Filial (FilialNro, FilialLocal, FilialDataAbertura) })
       As seguintes depend�ncias funcionais devem ser garantidas na normaliza��o:
           CodEmpresa ? {NomeEmpresa, EndEmpresa, NomeFundador}
           NomeFundador ? NacionalidadeFundador
           {CodEmpresa, FilialNro} ? {FilialLocal, FilialDataAbertura}
           Observa��es adicionais:
               Uma empresa somente pode ter sido fundada por um �nico fundador 
       Ariel:
           Arquivo:Normalizacao-Empresa.pdf 



   10. Vendas:
       Vendedor (NroVendedor, NomeVendedor, SexoVendedor,{Cliente (NroCliente, NomeCliente, EndCliente ) })
       As seguintes depend�ncias funcionais devem ser garantidas na normaliza��o:
           NroVendedor ? NomeVendedor, SexoVendedor
           NroCliente ? NomeCliente, EndCliente
           Observa��es adicionais:
               Um vendedor pode atender diversos clientes, e um cliente pode ser atendido por diversos vendedores 
       Ariel:
           Arquivo:Normalizacao-Vendas.pdf
Disponível em “http://3.143.69.156/wiki/index.php?title=BDA_-_Aula_06_-_2013/1&oldid=15891”