artigo SQL Magazine 7 - Formas normais superiores

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista SQL Magazine -Edição 7.

 Atenção: por essa edição ser muito antiga não há arquivo PDF para download.
Os artigos dessa edição estão disponíveis somente através do formato HTML.

capnet43.jpg

Clique aqui para ler todos os artigos desta edição

 

FORMAS NORMAIS SUPERIORES

 

Na edição anterior, analisamos alguns conceitos importantes à compreensão do processo de normalização e exploramos as três primeiras formas normais (FNs). Neste artigo, daremos continuidade ao assunto e abordaremos os seguintes temas:

 

FNBC (Forma Normal de Boyce e Codd):

4FN (4a Forma Normal);

5FN (5a Forma Normal).

 

Existem ainda duas outras formas normais, mas, por serem pouco práticas, falaremos brevemente sobre elas e indicaremos uma bibliografia para consulta posterior.

A exemplo do artigo anterior, antes de entrarmos propriamente nas formas normais, será necessário analisar alguns novos conceitos.

 

CONCEITOS ÚTEIS

 

Mais sobre chaves

 

·         Chaves simples: são aquelas que contêm somente um atributo;

·         Chaves compostas: são aquelas que contêm mais de um atributo;

·         Chaves superpostas: dizemos que duas chaves são superpostas quando pelo uma delas é composta e entre elas existe pelo menos um atributo em comum;

·         Chaves disjuntas: dizemos que duas chaves são disjuntas se entre elas não existe superposição.

 

Exemplo: considere a tabela da Figura 1. Nela, temos várias chaves candidatas: a) CodGeral; b) Semestre+CodDisc; c) Semestre+Disciplina. Observe os tipos de chave desta tabela:

 

§         Chaves simples: somente a);

§         Chaves compostas: b) e c);

§         Chaves superpostas:  b) é sobreposta a c), pois o campo semestre está nas duas chaves;

§         Chaves disjuntas: a) é disjunta a b) e a) é disjunta a c).

 

Figura 1:

 

 

  

 

Relacionamentos binários           

 

·         Conceito utilizado na etapa de projeto de banco de dados. Indica que uma entidade se relaciona de alguma forma com outra entidade. Representa, portanto, a forma como duas entidades se relacionam.

 

Relacionamentos ternários

 

·         Indica que uma entidade se relaciona de alguma forma com duas outras entidades. Representa, portanto, a forma como três entidades se relacionam.

 

NOTA: as formas normais a seguir se aplicam somente a tabelas com chaves compostas. Portanto, se ao normalizar até a 3FN você obtiver tabelas com apenas chave simples, elas já estarão na FNBC, 4FN e 5FN.

 

Forma Normal de Boyce e Codd (FNBC)

No processo de normalização, essa forma normal deve ser aplicada às tabelas em 3FN que possuam mais de uma chave candidata (lembre-se de que a chave primária é também uma chave candidata), onde pelo menos uma delas seja composta e onde haja superposição entre elas. Mais adiante, veremos como essa FN pode ser utilizada para substituir as formas normais anteriores.

 

NOTA: a 3FN e a FNBC são muito próximas e, normalmente, analisamos essas duas etapas de uma só vez.

 

Para simplificar, definimos que uma tabela está em FNBC se e somente se todos os determinantes são chaves candidatas. Ou seja, se houver algum atributo que seja determinado por outro(s) atributo(s) que não é (sejam) uma chave candidata, não estamos na FNBC. A solução é levar esses atributos para outra tabela, utilizando o conceito de decomposição sem perdas.

 

NOTA: tabelas na 3FN que não possuem superposição de chaves já estão na FNBC.

 

Vejamos um exemplo. Suponha que em um processo de normalização você chegue na tabela da Figura 2, que contém os dados de cliente, agência e gerente. As colunas da chave primária estão indicadas em negrito.

 

Figura 2

 

 

 

 Observe que ela está na 3FN pois: i) todos os atributos são atômicos (1FN); ii) todos osatributos não-chave dependem totalmente da chave primaria (2FN); iii) não existe transitividade em relação à chave primária (3FN).

Observe, entretanto, que existe anomalia de atualização, pois a agência está sendo repetida para o mesmo gerente. Essa anomalia só desaparecerá com a FNBC (observe que existe outra chave candidata e que ela pode ser sobreposta à chave primária):

 

Há sobreposição pois o campo Cliente encontra-se nas duas chaves candidatas.

 

 


 

Chave primária {Cliente, Agência} è {Gerente} 

Chave candidata {Cliente, Gerente} è {Agência} 

 

Observamos também que existe outro determinante que não é chave candidata:

 

Chave candidata {Gerente} è {Agência} 

 

Para estarmos na FNBC, decompomos a tabela conforme a Figura 3 (o atributo determinado por um campo que não é chave candidata vai para outra tabela):

 

Figura 3

 

 

          

 

 

A FNBC substitui as FNs anteriores

 

Ao contrário das outras formas normais, a FNBC não exige que a tabela já esteja na forma normal anterior (3FN) para que seja aplicada. Ou seja, podemos ir de uma tabela não normalizada diretamente para a FNBC. Vamos constatar isso observando a tabela da Figura 4, que a princípio se encontra na 1FN:

 

Figura 4

 


 

 

Fazendo um levantamento das chaves candidatas, temos:

·         {CPF, Produto} è {Qtde, FormaPagto, TipoPagto}

 

Fazendo um levantamento das dependências funcionais, temos:

·         {CPF, Produto} è {Qtde}

·         {CPF, Produto} è {FormaPagto}

·         {CPF, Produto} è {TipoPagto}

·         { FormaPagto } è {TipoPagto}

 

Nas etapas normais da normalização, veríamos que ela já está na 2FN e levaríamos, pela 3FN, TipoPagto para outra tabela, pois teríamos transitividade. Nesse caso, obteríamos as tabelas da Figura 5.

 

    

   

  

 

Figura 5

 

Como não temos mais de uma chave em nenhuma tabela, já estamos automaticamente na FNBC. Observe agora que, se aplicássemos a regra da FNBC diretamente na tabela ainda em 1FN, obteríamos o mesmo resultado, pois FormaPagto é determinante, mas não é uma chave candidata.

O interessante é que a regra da FNBC se aplica a todas as tabelas, independente de elas já estarem na 3FN ou 2FN. Ou seja, ela serve como um “atalho” para as formas normais anteriores.

Você pode se perguntar: “por que a 1FN, 2FN e 3FN, se podemos ir diretamente para a FNBC?” Veja algumas explicações para essa questão:

 

Ø       Pela historicidade dos fatos (a FNBC surgiu depois);

Ø       As três primeiras formas normais existem independentemente da FNBC (podemos desnormalizar, lembra?);

Ø       As três primeiras formas normais são mais difundidas por serem mais fáceis de compreender;

Ø       A FNBC algumas vezes pode levar à perda de DF. Observe no exemplo cliente-agência-gerente que na FNBC perdemos a DF: {Cliente, Agência} è {Gerente} pois cada atributo foi para uma tabela separada. Se for preciso manter esta DF em uma tabela, teremos que desnormalizar para 3FN.

 

 

4a Forma Normal (4FN)

Para compreender a 4FN, precisamos do conceito de Dependência Multivalorada.

 

Dependência Multivalorada (DMV)

A Dependência Multivalorada é, na verdade, uma ampliação da Dependência Funcional. Na DF, o valor de um atributo determina o valor de outro atributo; na DMV, o valor de um atributo determina um conjunto de valores de outro atributo. Sendo assim, toda DF é uma DMV de apenas uma ocorrência; a recíproca não é verdadeira.

Assim como a DF é representada por XèY, a DMV é representada por XèèY. Lemos que X multidetermina Y ou que Y é multidependente de X. Veja os exemplos:

 

DF:  {CPF}è             {Nome}             Pois temos somente um nome para cada CPF

 

DMV:     {CPF}èè    {Nome Dependente}      Pois temos vários dependentes para cada pessoa

                 {CPF}èè    {Idade  Dependente}            Pois temos vários dependentes para cada pessoa

 

Observe que, neste exemplo, as duas DMVs estão relacionadas entre si (nome dependente e idade dependente estão conectados). Entretanto, poderíamos ter em uma mesma tabela as seguintes DMVs:

 

DF:        {CPF}èè  {Carro}               Pois temos vários carros para cada pessoa

   DMV:     {CPF}èè  {Nome Dependente}       Pois temos vários dependentes para cada pessoa

 

Nesse caso, as DMVs não possuem relação direta (dependente e carro não estão conectados) e são tidas como DMVs independentes.

 

4a Forma Normal

       Neste nível de normalização, lidaremos com o conceito de dependência multivalorada, que também pode trazer anomalias de atualização.

 

NOTA: por causa da DMV, alguns autores confundem a 4FN com relacionamentos binários do tipo “muitos para muitos”. A diferença é que a DMV ocorre “dentro” de uma tabela, ao contrário dos relacionamentos.

 

A 4FN só é necessária se a tabela contiver:

 

·         Um multideterminante que aponte para mais de um multidependente;

·         Independência entre esses multidependentes. É como se uma tabela contivesse duas outras tabelas (ou mais) que não possuíssem relação entre si.

 

         De uma forma simples, dizemos que uma tabela está em 4FN quando ela está em FNBC e não possui duas ou mais DMVs independentes (não considerando as DFs que, como vimos, também são DMVs) de um mesmo multideterminante.

 

Por exemplo, imagine um condomínio que deseja cadastrar os veículos e os motoristas que os dirigem (para cada apartamento). Considere que qualquer motorista do apartamento pode dirigir qualquer carro daquela moradia (isso cria uma independência entre veículos e motoristas). Um exemplo de dados seria o mostrado na Figura 6.

 

 

Figura 6

 

 

Aplicando a 1FN, teríamos a tabela da Figura 7.

 

Figura 7

 

  Ao normalizarmos até a Forma Normal de Boyce Codd, teremos as tabelas da Figura 8.

 

Figura 8

 

 

                      

 

 

 

 

  

Apesar de já estar na FNBC, a primeira tabela continua com anomalias de atualização. Se o apartamento 101 comprar mais um carro, digamos de placa GAA-3433 (que deve ser inserido na terceira tabela), precisaremos inserir mais 3 linhas na primeira tabela, já que ele poderá ser dirigido tanto pelo Sr. Juca como por Pedro ou por D. Marilda. Se o apartamento 102 vender o carro, perderemos a informação de quem mora no referido apartamento. Como exercício, verifique as outras anomalias.

Estas anomalias existem nesta tabela pela presença de duas DMVs independentes:

 

###########  Frase acima ##############

 

{Apartamento}èè {Nome}

{Apartamento}èè {Placa}

 

Ou ainda, representadas de uma forma muito usual em algumas bibliografias:

 

{Apartamento}èè {Nome} | {Placa}

 

Observe que, neste exemplo, podemos ter vários motoristas em um apartamento e vários veículos para o mesmo apartamento. Como o motorista de um apartamento pode dirigir qualquer carro desse mesmo apartamento, temos uma independência entre carro e veículos (o que não seria verdade se cada um tivesse seu próprio carro). No entanto, observe que um motorista não pode dirigir o veículo de outro apartamento e, logicamente, um veículo não pode ser dirigido pelo motorista de outro apartamento. Isso evidencia a multidependência de motorista/veículo em relação a apartamento:

 

 

Apartamento

èè

èè

Independentes

Motorista

 

 

 

Veículo

 

 


 

Para deixarmos a tabela na 4FN, devemos efetuar a decomposição sem perdas e levar cada DMV para uma tabela diferente.

 Observe na Figura 9 que já não temos mais as anomalias de atualização e que podemos voltar à tabela original
se fizermos a junção de todas as tabelas.

 

Figura 9

 

Surgiram das DMVs

    

 

 

 

  

  
                Surgiram das DMVs

 

NOTA: se não partíssemos do princípio que cada pessoa pudesse dirigir qualquer carro de sua residência, não teríamos DMVs independentes, pois o veículo teria relação direta com motorista. Essa relação direta nos impediria de decompor a tabela, pois causaria erros quando efetuássemos a junção.

 

Observação: note que a primeira tabela pode ser unida à terceira tabela e que a segunda tabela também pode ser unida à quarta tabela, sem problemas (gerando assim tabelas mais adequadas para o contexto do problema). Ficaríamos então com as tabelas da Figura 10.

Ou seja, a normalização nem sempre leva ao formato ideal, exigindo sempre uma análise do seu resultado.

 

Figura 10

 

 

 

 

  

5a Forma Normal (5FN)

Para compreender a 5FN, precisamos analisar o conceito de Dependência de junção.

 

Dependência de Junção (DJ)

A DJ utiliza os conceitos de decomposição sem perdas e de junção. Na edição anterior, aprendemos a decompor uma tabela em duas outras, sem perda de informação. Aqui, ampliaremos esse conceito para tabelas que possam ser decompostas em mais de duas, sem perda de informação (denominado tabela n-decomponível, onde “n” é maior que dois). Claramente, este conceito só é aplicado em tabelas com 3 ou mais atributos.

Este conceito determina o seguinte:

 

1)     Se uma tabela T possui três atributos {a1, a2, a3};

2)     Teremos três projeções possíveis para ela: T1: {a1, a2}, T2: {a1, a3}, T3: {a2, a3};

3)     Dizemos que há uma dependência de junção se todas as linhas em T puderem ser formadas a partir da junção dessas três projeções simultaneamente. Ou seja, se a tabela T original puder ser decomposta em 3 tabelas menores T1, T2 e T3 (3-decomponível), as quais sejam originadas de suas projeções, teremos na tabela T o que chamamos dependência de junção.

 

Para representar que T tem dependência de junção com suas projeções, usamos esta forma: T*(T1,T2,T3).

 

Para exemplificar, utilizaremos o trio Autorizada-Montadora-Espécie:

 

o        Vamos considerar o seguinte: se uma autorizada vende determinada espécie de veículo e representa uma montadora que fabrica essa espécie, então ela comercializará tal espécie para a montadora.

o        Quando encontrar situações semelhantes a essa, verifique se existe a chamada restrição cíclica, que pode ser representada nas quatro observações abaixo:

 

Ø       Se a autorizada A  vende a espécie de veículo V (projeção T2: {a1,a3} );

Ø       Se a autorizada A representa a montadora M (projeção T1: {a1,a2} );

Ø       Se a montadora M fabrica a espécie de veículo V (projeção T3: {a2,a3} );

Ø       Significa que a autorizada A comercializará a espécie de veículo V para a montadora M (Tabela T).

 

Portanto se considerarmos essa restrição verdadeira, teremos a dependência de junção, como demonstra a Figura 11.

 

Figura 11

Tabela original T                                             Tabela T1              Tabela T2                 Tabela T3

 

 


 

Pelo fato de a tabela T possuir dependência de junção, ela contém anomalias de atualização. Por exemplo: não será possível armazenar a informação de que a montadora Honda produz moto enquanto não houver uma autorizada designada para ela. Ou ainda, se a FORD deixar de produzir CARRO, teremos de eliminar duas linhas (a 3a e a 6a) e ainda perderemos a informação de que a GTC representa a FORD.

A Figura 12 nos mostra que, se fizermos a junção das tabelas T1, T2 e T3, chegaremos na tabela T (indicando assim a dependência de junção). Iniciamos com a junção de T1 e T3; na tabela resultante, fazemos a junção com T2.

 

 

Figura 1
 
 
 
 
 
 
 
 
 
 
 

Estas linhas são chamadas espúrias e serão descartadas na junção com a terceira tabela

 

T2

 

                                                             

 

 

 

Experimente iniciar a junção por (T1 T2) ou (T2 T3) e verá que o resultado final será o mesmo

 

 

  

 

 

Da mesma forma que toda DF é uma DMV (conforme mencionamos anteriormente), aqui também a DJ é uma generalização de DMV. Porém, essa demonstração é mais complexa e, por isso, não a incluiremos aqui. Entretanto, o leitor que quiser comprová-la pode consultar as páginas 342 a 346 do livro “Introdução a Sistemas de Bancos de Dados”, de C.J.Date. Essa generalização é mostrada graficamente na Figura 13.

 

Figura 13

 

 

Os retângulos representam generalizações

 

 

 

 

  

·         Resumindo: quando tivermos uma tabela que possa ser representada de uma forma mais simples por suas projeções (e isso só será possível se tivermos a restrição cíclica), teremos uma DJ nessa tabela.

 

Para facilitar ainda mais o entendimento, vejamos outro exemplo em que não teremos a dependência de junção. Suponha que nós tenhamos empresas que façam doações de alguns objetos para algumas pessoas, como na tabela original T da Figura 14.

 

Figura 14

 

 

 

Observe que aqui não temos a DJ, pois se fizermos a junção das projeções de T teremos a tabela da Figura 15 (que não é igual a T):

 

Figura 15

 

  

 

 

 

  

Ou seja, a dependência de junção não existe pois não temos a restrição cíclica:

 

Ø                                     Se o doador D doou para o receptor R;

Ø                                     Se o doador D doou o objeto O;

Ø                                     Se o receptor R recebeu o objeto O;

Ø                                     Não significa que o doador D doou o objeto O para o receptor R.

 

De fato, observe que a empresa A doou para João. A empresa A doou sapato. João recebeu sapato. Porém, a empresa A não doou sapato para João.

 

 

 

5a Forma Normal

 

Esta forma ocorre muito raramente e exige uma atenção maior para que se perceba a sua necessidade. Esse fato colabora para que nem todas os autores a citem em seus artigos.

Precisamos aqui estar bem familiarizados com os processos de decomposição sem perdas e de junção e com o conceito de dependência de junção. Esta forma normal é também chamada forma normal de projeção-junção (FN/PJ).

 

Uma tabela estará em 5FN se estiver em 4FN e não contiver DJs que não sejam determinadas por chaves candidatas. Em outras palavras, se for possível n-decompor a tabela, então ela deverá ser substituída por suas n projeções para estar na 5FN.

 

########## Frase acima #############

 

NOTA: alguns autores confundem a 5FN com relacionamentos ternários. Ao contrário dos relacionamentos, a DJ acontece internamente na tabela. 

 

Como exemplo, utilizaremos o trio Piloto – Avião - Trajeto. Para tal, considere o seguinte:

 

1)     Se o Piloto P pilota determinado avião A;

2)     Se o Piloto P pilota pelo trajeto T;

3)     Se o avião A faz o trajeto T;

4)     Então o piloto P pilota o avião A pelo trajeto T.

 

Temos aqui a restrição cíclica. Observe que a terceira consideração não é derivada das duas considerações anteriores, como pode parecer à primeira vista. Repare que o piloto P poderia pilotar o avião A em um trajeto diferente de T, e o avião A poderia fazer o trajeto T com outro piloto que não o P.

Veja o gráfico da Figura 16.

  

 


 

Observe que T encontra-se em 4FN, pois, apesar de existir a relação piloto èè avião | trajeto, não temos independência entre avião e trajeto.

Como projeções de T, temos: T1: {piloto, avião}, T2: {piloto, trajeto}, T3: {avião, trajeto}. Há uma dependência de junção, pois todas as linhas em T podem ser formadas pela junção das três projeções simultaneamente. Portanto, na 5FN teríamos três tabelas no lugar da tabela original.

 

NOTA: o processo da 5FN é trabalhoso, pois temos de verificar todas as projeções e o resultado de suas junções (imagine uma tabela 5-decomponível).

 

Observe que as três tabelas armazenam os dados em uma forma mais simples que a tabela original. Nelas, podemos informar que o piloto “0030” pilotará o avião “103” sem que haja um trajeto definido para aquele avião ou piloto. Repare também que, se o piloto “0010” passar a fazer o trajeto “Rio-Spa”, bastará inserir essa linha na tabela T2. Se o piloto “0020” não pilotar mais o avião “105”, ao excluirmos essa linha da tabela original T, perdemos a informação de que o avião “105” faz o trajeto “Rec-Rio”. Já no trio de tabelas, essa operação poderia ser feita facilmente na tabela T1.

 

Normalização passo-a-passo

1.      Faça um levantamento dos dados a serem armazenados. Procure organizá-los de forma a retirar todas as multivalorações, deixando cada linha com apenas um valor por coluna. Com isso obtemos tabelas na 1FN;

2.      Para cada tabela na 1FN, elimine as dependências funcionais parciais (movendo para outra tabela os atributos que dependem de parte da chave primária). Este passo produzirá várias tabelas na 2FN;

3.      Para cada tabela na 2FN, elimine as dependências funcionais transitivas (movendo para outra tabela os atributos que não dependem somente da chave primária). Este passo produzirá tabelas na 3FN;

4.      Para cada tabela na 3FN que possua mais de uma chave candidata com sobreposição, elimine as dependências funcionais em que o determinante não seja uma chave candidata (movendo os atributos dependentes para outra tabela). Este passo produzirá tabelas na FNBC.

As regras de 2 a 4 podem ser resumidas em uma única orientação: “Obtenha projeções das tabelas originais até eliminar todas as DFs em que o determinante não seja uma chave candidata”;

5.      Para cada tabela na FNBC, verifique se existe mais de uma DMV (que não seja também DF) de um mesmo multideterminante e, se existir, se elas são independentes. Nesse caso, elimine-as, migrando essas colunas para outra tabela. Este passo produzirá tabelas na 4FN.;

6.      Para cada tabela na 4FN, verifique e elimine quaisquer DJs que não sejam determinadas por chaves candidatas  – embora talvez devamos acrescentar: “se você conseguir encontrá-las”. Este passo produzirá uma coleção de tabelas em 5FN.

 

 

CONCLUSÃO

Existem outras formas normais, como Forma Normal de Chave Domínio e Forma Normal de Restrição-União. Elas são baseadas na restrição de linhas de uma tabela. Assim como a projeção visa obter apenas algumas colunas de uma tabela (vertical), a restrição visa buscar apenas algumas linhas de uma tabela (horizontal). Essas restrições podem ser recompostas por meio de união, em contraposição à projeção de colunas vistas neste e no outro artigo, que podem ser recompostas por meio de junção.

Como essas formas normais não possuem aplicabilidade prática para os SGBD atuais (a união não apresenta as melhores performances), não descreveremos esse assunto em mais detalhes aqui. Contudo, se tiver interesse, você encontrará informações no livro “Introdução a Sistemas de Bancos de Dados”, de C.J.Date (capítulo 12, páginas 354 e 355).

Ressaltamos novamente que, na maioria dos projetos de banco de dados, o projetista (principalmente iniciante) precisará normalizar até a 3FN.

Espero ter contribuído para o seu aprendizado e até a próxima.

BIBLIOGRAFIA

  • C.J.DATE
    • Introdução a Sistemas de Banco de Dados – 7ª edição americana
  • Henry F. Korth e Abraham Silberschatz
    • Sistema de Banco de Dados – 2ª edição
  • Carlos Alberto Heuser
    • Projeto de Banco de Dados – 4a edição
  • Michael J. Hernadez
    • Aprenda a Projetar seu Próprio Banco de Dados
  • Prof. Fábio – UFSC / Fernando Fonseca e Ana Carolina.
    • Alguns exemplos retirados de transparências na WEB

REFERÊNCIAS

 

O Prof. Bráulio Ferreira de Carvalho (braulio@cic.unb.br ou brauliof@stf.gov.br) ministra as disciplinas “Banco de Dados” e “Organização de Arquivos” na graduação em Licenciatura da Computação da Universidade de Brasília – UNB. Atua também na área de Administração de Dados e Metodologia de Sistemas, na Secretaria de Informática do STF (Supremo Tribunal Federal). Além disso, aplica treinamentos e dá consultorias na área de desenvolvimento de sistemas de modo geral.

 

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?