Dois Atributos Com Nomes Iguais de Tabelas Distintas

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE DE SISTEMAS

Normalização Passo a Passo

NÍVEIS DE MODELAGEM

Ao projetar um sistema de informações para ser implementado no computador, o analista elabora um modelo da realidade. Devido à complexidade do mundo real e seguindo a linha de abordagem de refinamentos sucessivos (top down), o processo de modelagem atravessa diversas fases as quais denominamos Níveis de Abstração.

Portanto, os níveis de abstração representam as diferentes visões que um modelador pode obter de uma realidade (mundo real, objetos observados), a medida que avança no processo de modelagem com o objetivo de implantar um sistema.

A estratégia de utilização de níveis diferentes de modelagem teve origem junto ao grupo ANSI-X3-SPARK, na década de 70. Com a disseminação dos primeiros SGBD, havia uma forte preocupação com estabelecimento de padrões que pudessem regrar este novo ambiente. Assim surgiu o conceito de Schema, que é o conjunto de parâmetros e especificações para mapeamento das estruturas de dados, incluindo aspectos conceituais, lógicos e físicos. Estes aspectos são abordados em diferentes níveis do schema, com o objetivo de tornar a implementação física do banco de dados independente do seu schema conceitual. Isso possibilita que um mesmo modelo de dados, concebido para uma aplicação, possa ser utilizado para implementação em diferentes SGBD (hierárquico, rede ou relacional), sem que isso exija transformações significativas no modelo original.

Mundo Real: envolve todos os objetos (normas, pessoas, eventos, fatos, ambiente, sistemas, etc.) que compõem o cenário a ser modelado.

Modelo Conceitual: os objetos, suas características e relacionamentos têm a representação fiel ao ambiente observado, independente de quaisquer limitações impostas por tecnologias, técnicas de implementação ou dispositivos físicos. É o modelo utilizado para o nível de conversação, entendimento, transmissão, validação de conceitos, mapeamento de ambiente e etc, sendo o mais adequado para envolvimento do usuário no projeto. Nesse nível devem ser ignoradas quaisquer particularidades de implementação . Este modelo permanecerá imutável tanto se vier a ser implementado em um SGBD relacional, como em um SGBD rede, por exemplo. É gerado na fase de análise e nunca na fase de projeto.

Modelo Lógico: os objetos, suas características e relacionamentos têm a representação de acordo com as regras de implementação e limitantes impostos por algum tipo de tecnologia. Entretanto, esse modelo é independente dos dispositivos ou meios de armazenamento físico das estruturas de dados por ele definidas. Aspectos como chaves de

PROF. EDUARDO JOSE RIBEIRO DE CASTRO

MODELO CONCEITUAL

MODELO LÓGICO

MODELO FÍSICO

SchemaConceitual

SchemaExterno

SchemaInterno



acesso, chaves primárias, itens repetitivos, normalização e integridade referencial devem ser observados e respeitados. A obtenção de um modelo lógico de dados se dará pela aplicação de regras de derivação sobre um modelo conceitual já construído. Está associado à fase de projeto.

Modelo Físico: a representação dos objetos é feita sob o foco do nível físico de implementação das entidades e seus relacionamentos. Cada SGBD diferente poderá definir um modo diferente de implementação física das características e recursos necessários para o armazenamento e manipulação das estruturas de dados. Esse modelo é representado pelo conjunto de linhas de código geradas em linguagem de definição de um SGBD específico (por exemplo SQL para Oracle ou SQL Server).




NORMALIZAÇÃO

O processo de normalização tem sido visto por muitas pessoas apenas como um formalismo necessário à implementação de estruturas relacionais. Esse formalismo, quando não compreendido em sua finalidade, acaba por transformar-se em mais um fator complicante do que em um fator otimizador durante o projeto do banco de dados.

Encarar a normalização como imposição de regras que simplesmente restringem nossa liberdade no projeto de banco de dados é Ter uma visão muito simplificada do que representa esse processo. Acima de tudo, a normalização propõe uma série de passos a serem seguidos para que tenhamos um processo de verificação, validação e ajuste das estruturas de dados que porventura tenham sido observadas, modelas, mas que ainda apresentem distorções quanto à realidade.

O primeiro ponto importante a ser definido para que se tenha a correta visão desse processo é de que:

A normalização não é um processo com finalidade restritiva, mas sim com caráter organizativo.

Muitas pessoas acreditam que a normalização é um processo que é realizado somente após definidas as prováveis tabelas de um sistema. Acreditam que a normalização só ocorre como um elemento posterior ao projeto inicial do banco de dados. Isso, apesar de verdadeiro, não é sempre verdade. A normalização pode ocorrer em momentos distintos:

Durante o processo de concepção do modelo conceitual Durante a derivação do modelo lógico Após a derivação do modelo lógico

Normalização durante o Processo de Concepção do Modelo Conceitual

O grau de normalização de um modelo conceitual vai depender entre outras coisas, de alguns fatores como:

- Abrangência do Modelo: quanto mais abrangente (em termos de escopo) for um modelo, mais chances haverá de que ele tenha um baixo grau de normalização. Por outro lado, quando menor for o escopo, quanto mais restrito for o ambiente a ser modelado, mas chances haverá de que tenhamos um modelo mais normalizado.

- Facilidade de abstração e compreensão: o correto entendimento dos elementos presentes em um ambiente a ser modelado poderá nos levar mais facilmente à concepção de um modelo normalizado.

- Conhecimento prévio do ambiente: o fato de termos conhecimento prévio do ambiente a ser modelado, e assim do próprio resultado a ser obtido, tanto no nível conceitual como no nível lógico, nos induzirá, por mais que não queiramos, a previamente “enxergar” o ambiente de modo normalizado.

Normalização durante a Derivação do Modelo Lógico

Ao transformar um modelo conceitual em um modelo lógico para implementação em ambiente relacional, deveremos ter a certeza de que ele respeita os preceitos da tecnologia relacional. A existência de estruturas de dados normalizadas é um desses preceitos e não poderá ser violado. Caso o modelo conceitual ainda não tenha sofrido qualquer tipo de normalização sobre as estruturas de dados das entidades, este é o melhor momento.




Normalização após a Derivação do Modelo Lógico

Durante a abordagem das três formas normais, veremos que o fato de uma tabela não se encontrar normalizada traduz, sob o ponto de vista de sistema de informações, anomalias que comprometem processos, integridade, disponibilidade de informação, etc. Assim, normalizar uma tabela não é só uma possibilidade mais sim uma necessidade se desejarmos Ter sistemas ao menos, “bem comportados”. Acreditar que se pode conviver com tabelas não normalizadas de modo sistemático é uma idéia equivocada. Sistemas de informação terão poucas ou nenhuma chance de sobreviver sem estruturas de dados normalizadas.

Quando falamos em “desnormalizar” tabelas para fins de desempenho, ajuste ou outra finalidade qualquer, não estamos falando em não normalizar. Estamos sim falando em após termos normalizado uma tabela, regredi-la, intencionalmente, a uma forma não normalizada. Perceba que desnormalizar implica antes normalizar. Existem casos onde isso é possível, dentro de limites e controle seguros. Não é uma operação simples e requer conhecimento para que possa ser executada; portanto, tenha critérios e use o bom senso para avaliar em que situações se justifica esse procedimento.

Benefícios da Normalização:

Estabilidade do Modelo lógico

A implementação de tabelas não normalizadas faz com que a estabilidade do modelo lógico seja comprometida. Por estabilidade, entendemos a capacidade de um modelo manter-se inalterado face a mudanças que venham a ser introduzidas no ambiente que tenha sido modelado.

Imagine um caso simples onde um modelo tenha sido concebido desnormalizado já em sua primeira forma normal. Mesmo que ainda não conheçamos a primeira forma normal, assuma que ela, sem mais simples e restrito formato estabeleça que “uma tabela não deve Ter itens de repetição”.

Exemplo:

Tabela FUNCIONÁRIONomeData de NascimentoEndereçoValor do salário baseTelefoneRamalValor de Contribuição Sindical (repetindo 5 vezes)

Vejamos como a estabilidade lógica de dados e aplicações sobre este modelo seria afetada.Imagine que um vetor, previamente definido para Ter 5 ocorrências, e que esteja sendo

manipulado por uma série de aplicações distintas, precise ser expandido ou reduzido em suas dimensões. Isso poderia ocorrer ser fosse necessário, por implicações legais, manter as 10 últimas contribuições e não somente as últimas 5. Muito provavelmente, os algoritmos de manipulação dos campos poderiam sofrer impactos.

Considere ainda que tenha havido uma diminuição de 5 para 3 anos na necessidade de retenção dos dados de contribuição. O que aconteceria com a estrutura de dados da tabela? Teria de ser ajustada para “exclusão” das ocorrências. Isso implicaria, dependendo do SGBD, maior ou menor esforço de manutenção, mas, de qualquer forma teríamos impactos novamente nas estruturas lógicas dos programas.




Flexibilidade

Por flexibilidade entendemos a capacidade de adaptação a demandas diferenciadas, a expansão e redução, a omissão ou presença, etc. Se, em uma estrutura de dados implementada, não tivermos a devida flexibilidade, estaremos impondo restrições de uso e tornando as estruturas de dados e de processos dependentes de limites rígidos. Isso fará com que se tornem instáveis, o que nos trará implicações já abordadas anteriormente.

Integridade

As estruturas de dados obtidas pelo processo de modelagem necessitam de recursos para que os dados a serem nelas armazenados possam Ter “qualidade”. A qualidade de um dado está vinculada a diversos fatores. Entre eles podemos citar a atualidade, veracidade, fidelidade, acuracidade, integridade, etc.

A integridade de modo genérico diz respeito à qualidade do dado. Se um dado sobre certo objeto aparecer mapeado em mais de um local de modo diferente, com valores diferentes, podermos Ter indícios de que não há integridade entre eles. Esse tipo de anomalia é algo que a normalização de tabelas procurará coibir. As 2ª e 3ª formas normais nos induzirão a corrigir alguma anomalia que permita a existência de dados repetidos desnecessariamente e, assim, sujeitos a falta de integridade.

Economia

O aspecto economia tem sido visto basicamente sob o prisma da economia de espaço para armazenamento. Mas isso parece exagerado quando consideramos o barateamento cada vez maior das mídias de armazenamento de massa. E se tivermos espaço de sobra? Será que mesmo assim é necessário levarmos esse aspecto em conta?

A resposta é “sim”. Os custos de armazenamento, gerados pela redundância, pela desnormalização e por outras anomalias presentes na construção de tabelas não são, entretanto, os maiores custos existentes. Além do custo de armazenamento temos também o custo de manipulação.

Esse custo representa todo e qualquer esforço, tempo, ou valor agregado ao fato de manipularmos volumes de dados maiores do que os efetivamente necessários. Tempos envolvidos em processamento, unidades de disco, controladoras, mídias para backup, local para armazenamento das mídias de backup e tantos outros elementos podem Ter seus custos aumentados simplesmente porque nosso projeto não está otimizado. Os processos de atualização também refletirão a redundância, desde que se pretenda manter o sincronismo entre as cópias redundantes. Isso liga-se ainda ao fato de termos que executar mais processos para manter integridade e, por sua vez, processos mais demorados, causando atraso no fornecimento da informação desejada.

I - Primeira Forma Normal (1FN)

Um modelo está na primeira forma normal se: É formado por tabelas As linhas da tabela são unívocas As linhas não contêm itens repetitivos Os atributos são atômicos.

É formado por tabelas...

Se o nosso objetivo é conceber um modelo relacional correto, o primeiro ponto a ser observado é que ele esteja definido em forma de TABELAS, ou seja, respeite a característica de LINHAS e COLUNAS.

As linhas da tabela são unívocas ...

Devemos definir obrigatoriamente o(s) identificador(es) unívoco(s), ou chave(s) primária(s) da tabela. Só assim asseguramos a não existência de linhas iguais.




As linhas não contêm itens repetitivos ...

Grupos repetitivos são estruturas de dados artificiais criadas para facilitar o manuseio de ocorrências repetitivas de elementos de dados. Como uma relação é definida como um conjunto de domínios não necessariamente distintos, deveremos também na definição de nossas tabelas apresentar os elementos repetitivos de modo isolado, dando a cada um uma denominação distinta, ou utilizar uma outra estrutura que os apresente associados ao conjunto inicial de dados não repetitivos.

Os atributos são atômicos

Estruturas de agrupamento de itens de dados tornaram-se bastante comuns em linguagens tipo COBOL. Definir um item de dado do tipo DATA e sob ele hierarquizar definições para DIA, MÊS, ANO. Esses agrupamentos e suas redefinições não são permitidas no ambiente relacional. Isso tem correlação com a definição de relação. Não é possível conceber um domínio DATA subdividido em sudomínios DIA, MÊS, ANO. Não há esse tipo de percepção no âmbito dos domínios.

Processo para obtenção da Primeira Forma Normal

1. Definir as chaves candidatas e escolher a chave primária da tabela

Existem situações em que nenhuma das colunas ou combinações de colunas nos levará à identificação de uma chave primária. Nesse caso deverá ser definida uma nova coluna, dita “artificial”, para que ela supra a demanda necessária de identificação. Essa coluna poderá ser uma coluna do tipo CONTADOR ou NÚMERO SEQUENCIAL. Entretanto, esse recurso deverá ser utilizado com a máxima restrição e bom senso, pois é comum a definição de colunas artificiais sem necessidade.

2. Tornar atributos compostos em atributos atômicos.

3. Eliminar em cada tabela os grupos repetitivos, gerando uma nova tabela, na qual cada um dos itens repetitivos dará origem a uma nova linha e na qual a chave primária será a concatenação da chave da tabela original com uma nova coluna que identifique de modo unívoco a linha.

Exemplo:

emite

TABELA DE PEDIDOS

Número Pedido

Data Emissão

Nome doFornecedor

CGC EndereçoProdutos

Cód. Nome Qtde Preço

003 20/01/1998 CTIS 832563991Asa NorteBrasília

15B Fita 03 4,5005C DOS 01 12,0010B Cabo 10 3,00


FILIAL

CGCRAZÃO SOCIALTELEFONEENDEREÇOBAIRROCEP

PEDIDO

NÚMERO DO PEDIDODATA DE EMISSÃONOME DO FORNECEDORCGC DO FORNECEDORENDEREÇO DO FORNECEDORPRODUTOS (ATÉ 10) CONTENDO:

CÓDIGO DO PRODUTONOME DO PRODUTOQUANTIDADE PEDIDAPREÇO UNITÁRIO



004 08/03/1998 LORENO 999876288Asa SulBrasília

02M COREL 02 90,0010B Cabo 05 4,00

005 14/03/1998 MICROBRÁS 1207609938Copacabana Rio de Janeiro

33C Office 20 110,0005C DOS 03 10,00

006 25/06/1998 COMPUSHOW 3456789002 Centro Goiânia 29I WIN 50 200,00

Passos para Normalização da Tabela PEDIDOS

1. Acabar com itens de repetição: deveremos tomar cada um dos itens de repetição e com eles dar origem a novas linhas da tabela onde o conteúdo das demais colunas será o mesmo da linha original.

Número Pedido

Data Emissão

Nome doFornecedor

CGC EndereçoProdutos

Cód. Nome Qtde Preço

003 20/01/1998 CTIS 832563991Asa Norte - Brasília

15B Fita 03 4,50


05C DOS 01 12,00


10B Cabo 10 3,00

004 08/03/1998 LORENO 999876288Asa Sul – Brasília

02M COREL 02 90,00

004 08/03/1998 LORENO 999876288Asa Sul – Brasília

10B Cabo 05 4,00

005 14/03/1998 MICROBRÁS 1207609938Copacabana – Rio de Janeiro

33C Office 20 110,00

005 14/03/1998 MICROBRÁS 1207609938Copacabana – Rio de Janeiro

05C DOS 03 10,00

006 25/06/1998 COMPUSHOW 3456789002Centro - Goiânia

29I WIN 50 200,00

2. Transformar os Atributos em Atributos Atômicos: O endereço será desmembrado em Bairro e Cidade por se tratar de dados com naturezas completamente distintas, representando características completamente diferentes.

Número Pedido

Data Emissão

Nome doFornecedor

CGC Endereço CidadeProdutos

Cód. Nome Qtde Preço003 20/01/1998 CTIS 832563991 Asa Norte Brasília 15B Fita 03 4,50003 20/01/1998 CTIS 832563991 Asa Norte Brasília 05C DOS 01 12,00003 20/01/1998 CTIS 832563991 Asa Norte Brasília 10B Cabo 10 3,00004 08/03/1998 LORENO 999876288 Asa Sul Brasília 02M COREL 02 90,00004 08/03/1998 LORENO 999876288 Asa Sul Brasília 10B Cabo 05 4,00

005 14/03/1998 MICROBRÁS 1207609938 CopacabanaRio de Janeiro

33C Office 20 110,00

005 14/03/1998 MICROBRÁS 1207609938 CopacabanaRio de Janeiro

05C DOS 03 10,00

006 25/06/1998 COMPUSHOW 3456789002 Centro Goiânia 29I WIN 50 200,00

3. Definir uma chave para que tenhamos unicidade nas linhas da Tabela

Normalmente os atributos chaves estão associados a domínios definidos para Códigos ou Números, entretanto, esta não é uma exigência de caráter teórico e sim prático.

Um atributo que nos chama atenção no exemplo é o próprio NÚMERO DO PEDIDO. Se os pedidos já têm originalmente um número, é grande a probabilidade de que ele sirva como meio para diferenciar linhas dessa tabela. Devemos fazer algumas indagações para nos certificarmos que esse atributo serve como chave:

Um número de pedido pode se repetir em uma mesma filial? Não. Um número de pedido pode se repetir em diferentes filiais? Não.




Já sabemos que um número de pedido não se repete para dois pedidos distintos. Mas seria isso suficiente? Não. Precisamos tornar distintas as linhas da tabela PEDIDO e isso envolve analisar toda a linha. É fácil perceber que as linhas 1,2 e 3 da tabela têm o número do pedido igual a 003. Somente com o atributo NÚMERO DO PEDIDO não conseguiremos identificar de modo distinto uma linha da tabela. Isso nos indica que devemos buscar outro identificador para a tabela, ou devemos associar mais algum atributo ao NÚMERO DO PEDIDO.

Perceba que as combinaçõesNÚMERO DO PEDIDO + CÓDIGO DO PRODUTO eNÚMERO DO PEDIDO + NOME DO PRODUTOSão chaves candidatas da tabela, pois não definem potencialmente mais de uma linha. Nesse

caso, como temos duas chaves candidatas, escolheremos como chave primária da tabela PEDIDO a associação NÚMERO DO PEDIDO + CÓDIGO DO PRODUTO, pois nos parece mais natural trabalhar, internamente no sistema, com códigos do que com nomes.

Número Pedido

Código Produto

Nome doFornecedor

CGC Endereço CidadeData Emissão

Nome Prod.

Qtde Prod.

Preço Prod.

003 15B CTIS 832563991 Asa Norte Brasília 20/01/1998 Fita 03 4,50003 05C CTIS 832563991 Asa Norte Brasília 20/01/1998 DOS 01 12,00003 10B CTIS 832563991 Asa Norte Brasília 20/01/1998 Cabo 10 3,00004 02M LORENO 999876288 Asa Sul Brasília 08/03/1998 COREL 02 90,00004 10B LORENO 999876288 Asa Sul Brasília 08/03/1998 Cabo 05 4,00

005 33C MICROBRÁS 1207609938 CopacabanaRio de Janeiro

14/03/1998 Office 20 110,00


14/03/1998 DOS 03 10,00

006 29I COMPUSHOW 3456789002 Centro Goiânia 25/06/1998 WIN 50 200,00

Chave Primária: NÚMERO DO PEDIDO + CÓDIGO DO PRODUTO

Anomalias da Primeira Formal Normal

Inserção: Só é possível incluir um novo fornecedor a partir de um pedido.Como a inclusão dos dados do fornecedor está ligada a um pedido, nada impede que dois pedidos diferentes contenham dados diferentes para um mesmo fornecedor. Isso poderá acontecer com qualquer um dos atributos do fornecedor: nome, endereço, cidade, CGC, etc.

Exclusão: Se eliminarmos o pedido 006, perderemos toda a informação sobre o fornecedor “COMPUSHOW”.

Atualização: Se a data do pedido 003 tiver de ser alterada para 22/01/1998, teremos que efetuar essa operação em pelo menos 3 linhas da tabela. Ainda, se algum dado do fornecedor LORENO mudar, termos que atualizar diversas linhas da tabela, inclusive em diferentes pedidos.

O fato de atributos pertencentes, única e exclusivamente ao pedido, estarem associados a linhas da tabela que representam cada um dos produtos do pedido, faz com que haja redundância de dados.

II - Segunda Forma Normal (2FN)

Uma tabela está na Segunda forma normal se está na 1FN e cada uma das colunas não pertencentes à chave primária não for parcialmente dependente dessa chave.

Está na 1FN ...




Para aplicar a 2FN, devemos garantir que a tabela já esteja na 1FN.

Cada uma das colunas não pertencentes à Chave Primária ...

Deixa claro que, ao analisar uma tabela para normalizá-la para a 2FN, devemos excluir de nossa análise as colunas formadoras da chave primária. Isso é válido tanto para tabelas com somente uma coluna definindo a chave primária como para tabelas onde a associação de diversas colunas é necessária para a definição da chave.

Não for parcialmente dependente dessa chave.

A dependência parcial de uma chave só será possível se a chave primária da tabela for definida por mais de uma coluna. Dizemos que uma coluna depende parcialmente da chave se, para que seu valor seja determinado não necessitarmos conhecer a chave como um todo, mas sim, somente um ou alguns de seus valores. Assim, cada coluna de uma tabela que não pertença à chave e que possa Ter seu valor determinado por um “pedaço” da chave está dependente parcialmente da chave.

Processo para obtenção da Segunda Forma Normal

1. Identificar as colunas que não participam da chave primária da tabela.2. Para cada um das colunas identificadas, analisar se seu valor é determinado por

parte, ou pela totalidade da chave.Para identificar a dependência de uma coluna em relação à chave deve-se indagar:-Para que seu valor seja determinado, quais são as colunas da chave que devem ser

conhecidas?-Qual seria o menor “pedaço da chave” que me permitiria obter um valor para a coluna

analisada?Uma boa estratégia é utilizar-se de exemplos com valores reais. Pense neles e observe como os valores de colunas distintas estão ligados, e como uns determinam os outros.

3. Para as colunas parcialmente dependentes da chave, criar novas tabelas onde a chave primária será(ão) a(s) coluna(s) da chave primária original que determinou(aram) o valor da coluna analisada e excluir da tabela original as colunas dependentes parcialmente da chave.O processo de normalização da 2FN dará origem a novas tabelas, fazendo com que objetos não observados distintamente e colocados juntos em uma mesma tabela venham a ser separados.




Passos para colocar a tabela PEDIDOS na 2FN

Número Pedido

Código Produto

Nome doFornecedor

CGC Endereço CidadeData Emissão

Nome Prod.

Qtde Prod.

Preço Prod.

003 15B CTIS 832563991 Asa Norte Brasília 20/01/1998 Fita 03 4,50003 05C CTIS 832563991 Asa Norte Brasília 20/01/1998 DOS 01 12,00003 10B CTIS 832563991 Asa Norte Brasília 20/01/1998 Cabo 10 3,00004 02M LORENO 999876288 Asa Sul Brasília 08/03/1998 COREL 02 90,00004 10B LORENO 999876288 Asa Sul Brasília 08/03/1998 Cabo 05 4,00


14/03/1998 Office 20 110,00


14/03/1998 DOS 03 10,00

006 29I COMPUSHOW 3456789002 Centro Goiânia 25/06/1998 WIN 50 200,00

1. Analisar colunas não chave...Colunas: NOME DO FORNECEDOR,

CGC,ENDEREÇO,CIDADE,DATA EMISSÃO,NOME DO PRODUTO,QUANTIDADE DO PRODUTO,PREÇO DO PRODUTO.

2. Identificando as dependências parciais ...

Coluna Dependência

Chave

NOME FORNECEDOR PARCIAL NÚMERO DO PEDIDOCGC PARCIAL NÚMERO DO PEDIDOENDEREÇO PARCIAL NÚMERO DO PEDIDOCIDADE PARCIAL NÚMERO DO PEDIDODATA EMISSÃO PARCIAL NÚMERO DO PEDIDONOME DO PRODUTO PARCIAL CÓDIGO DO PRODUTOQUANTIDADE DO PRODUTO TOTAL NÚMERO DO PEDIDO + CÓDIGO DO PRODUTOPREÇO DO PRODUTO TOTAL NÚMERO DO PEDIDO + CÓDIGO DO PRODUTO

3. Criando novas tabelas com as colunas dependentes parcialmente das chaves, e excluindo essas colunas da tabela original.

TABELA ORIGINAL DE PEDIDOS: todas as colunas são dependentes totalmente da chave.

Número Pedido

Código Produto

Quantidade Produto

Preço Produto

003 15B 03 4,50003 05C 01 12,00003 10B 10 3,00004 02M 02 90,00004 10B 05 4,00005 33C 20 110,00005 05C 03 10,00006 29I 50 200,00

TABELA OBTIDA POR DEPENDÊNCIA PARCIAL: Chave NÚMERO DO PEDIDO.




Número Pedido

Nome doFornecedor

CGC Endereço Cidade Data Emissão

003 CTIS 832563991 Asa Norte Brasília 20/01/1998004 LORENO 999876288 Asa Sul Brasília 08/03/1998005 MICROBRÁS 1207609938 Copacabana Rio de Janeiro 14/03/1998006 COMPUSHOW 3456789002 Centro Goiânia 25/06/1998

TABELA OBTIDA POR DEPENDÊNCIA PARCIAL: Chave CÓDIGO DO PRODUTO

Código Produto Nome Produto15B Fita05C DOS10B Cabo02M COREL33C Office29I WIN

Anomalias existentes na Segunda Forma Normal

Inserção: Só é possível incluir um novo fornecedor a partir de um pedido. Essa anomalia, identificada na 1FN, ainda persiste.

Exclusão: Se eliminarmos o pedido 006, perdemos todas as informações sobre o fornecedor “COMPUSHOW”.

Atualização: Se a data do pedido 003 tiver de ser alterada para 22/01/1998, teremos que efetuar essa operação sobre várias linhas da tabela. Essa anomalia identificada na 1FN foi corrigida na normalização para 2FN e não existe mais.Diminuímos consideravelmente o nível de redundância na tabela, mas ainda temos de atualizar diversas linhas da tabela se o dado de um fornecedor for alterado.

III - Terceira Forma Normal (3FN)

Uma tabela está na terceira forma normal se está na 2FN, e se nenhuma coluna não pertencente à chave primária fica determinada transitivamente por esta e armazenada em outra tabela. Na terceira forma normal todas as dependências transitivas devem ser eliminadas.

Se está na 2FN ...

Também nesse ponto é importante garantir que os passos anteriores (1Fn e 2FN) já foram realizados devidamente.

Se nenhuma coluna não pertencente à chave ...

As colunas que nos interessam para essa análise, são somente as não formadoras da chave primária da tabela.

Fica determinada transitivamente por esta.

A dependência transitiva de uma chave só será possível se a tabela tiver ao menos duas colunas não pertencentes à chave. Caso tenhamos somente uma coluna externa à chave, essa tabela já estará automaticamente na 3FN.

Dizemos que uma coluna depende transitivamente da chave se seu valor é determinado pelo conteúdo de uma coluna não chave que, por sua vez, também já é determinada pela chave primária da tabela.

Processo para obtenção da Terceira Forma Normal




1. Identificar as colunas que não participam da chave primária da tabela.2. Para cada uma das colunas identificadas, analisar se seu valor é determinado

por alguma outra coluna não pertencente à chave,Para identificar a dependência transitiva de uma coluna, deve-se indagar:

-Qual outra coluna não pertencente à chave poderia determinar o valor desta coluna?-O valor dessa coluna pode ser obtido a partir do conhecimento de algum outro valor

existente nessa tabela?

3. Para as colunas dependentes transitivamente da chave, criar novas tabelas onde a chave primária será(ão) a(s) coluna(s) que determinou(aram) o valor da coluna analisada, agregando a essas tabelas as colunas dependentes transitivamente, e excluir das tabelas de origem as colunas dependentes transitivamente das chaves, mantendo porém, a coluna determinante da transitividade na tabela.Agora estaremos agindo sobre as tabelas que já são resultados da 2FN, aplicando sobre cada uma delas o processo acima. Dele resultarão novas tabelas já na 3FN.

Passos para colocar as tabelas resultantes da Tabela PEDIDOS na 3FN

TABELA 1: ORIGINAL DE PEDIDOS: todas as colunas são dependentes totalmente da chave.

Número Pedido

Código Produto

Quantidade Produto

Preço Produto

003 15B 03 4,50003 05C 01 12,00003 10B 10 3,00004 02M 02 90,00004 10B 05 4,00005 33C 20 110,00005 05C 03 10,00006 29I 50 200,00

TABELA 2: OBTIDA POR DEPENDÊNCIA PARCIAL: Chave NÚMERO DO PEDIDO.

Número Pedido

Nome doFornecedor



TABELA 3: OBTIDA POR DEPENDÊNCIA PARCIAL: Chave CÓDIGO DO PRODUTO


1. Analisar as colunas não chave

TABELA 1: QUANTIDADE DO PRODUTOPREÇO DO PRODUTO

TABELA 2: NOME DO FORNECEDORCGCENDEREÇO




CIDADEDATA EMISSÃO

TABELA 3: Nenhuma, pois ela já está na 3FN (só tem uma coluna não pertencente à chave).

1. Identificando as dependências transitivas

TABELA 1 Número Pedido

Código Produto

Quantidade Produto

Preço Produto

003 15B 03 4,50003 05C 01 12,00003 10B 10 3,00004 02M 02 90,00004 10B 05 4,00005 33C 20 110,00005 05C 03 10,00006 29I 50 200,00

O valor da coluna PREÇO DO PRODUTO (refere-se a preço unitário) não pode ser definido com base no valor da coluna QUANTIDADE DO PRODUTO, pois para valores de quantidade iguais poderemos ter diferentes preços. O mesmo é válido em relação à coluna QUANTIDADE poder ser definida pela coluna PREÇO DO PRODUTO. Alguém pode pedir um produto que custa R$ 4,50 e requisitar 40 unidades e ao mesmo tempo pedir outro produto que também custa R$ 4,50, só requisitando 10 unidades.

Isso demonstra que o valor de uma coluna não pode ser determinado pelo valor da outra, logo não há dependência transitiva e a tabela já está na 3FN.

TABELA 2Número Pedido

Nome doFornecedor



Dado o valor de uma DATA EMISSÃO não é possível determinar o NOME DO FORNECEDOR, o CGC, o ENDEREÇO ou a CIDADE. Também dadas quaisquer outras colunas não é possível determinar a DATA EMISSÃO. Logo essa coluna não está envolvida em qualquer dependência transitiva.

Entretanto, dado o valor da coluna CGC é possível determinar um e só um valor para as colunas NOME DO FORNECEDOR, ENDEREÇO e CIDADE. Isso demonstra uma dependência transitiva dessas três colunas com relação à coluna CGC.

2. Criando novas tabelas onde a chave primária será(ão) a(s) coluna(s) que determinou(aram) o valor da coluna analisada, agregando a essas tabelas as colunas dependentes transitivamente, e excluir das tabelas de origem as colunas dependentes transitivamente mantendo a coluna que determinou a transitividade.

Resultado da 3FN:

TABELA 1: Já estava na 3FN. (TABELA DE ITENS DO PEDIDO)

Número Pedido

Código Produto

Quantidade Produto

Preço Produto

003 15B 03 4,50003 05C 01 12,00003 10B 10 3,00




004 02M 02 90,00004 10B 05 4,00005 33C 20 110,00005 05C 03 10,00006 29I 50 200,00

TABELA 2: Após a aplicação da 3FN, mantendo a coluna CGC que determinou a transitividade e sem as demais colunas que eram determinadas transitivamente.(TABELA DE PEDIDOS)

Número Pedido

CGC Data Emissão

003 832563991 20/01/1998004 999876288 08/03/1998005 1207609938 14/03/1998006 3456789002 25/06/1998

TABELA 3: Já estava na 3FN (TABELA DE PRODUTOS)


TABELA 4: Obtida a partir da TABELA 2 (por dependência transitiva do CGC) (TABELA DE FORNECEDORES)

CGCNome doFornecedor

Endereço Cidade

832563991 CTIS Asa Norte Brasília999876288 LORENO Asa Sul Brasília1207609938 MICROBRÁS Copacabana Rio de Janeiro3456789002 COMPUSHOW Centro Goiânia

Anomalias resolvidas pela 3FN

Inserção: Não há mais necessidade um novo pedido para incluir um novo fornecedor. Sempre que se queira incluir um novo fornecedor basta atualizar a Tabela de Fornecedores sem que se tenha qualquer envolvimento com a tabela que contém os dados de pedidos.

Exclusão: Se eliminarmos qualquer um dos pedidos existentes, não mais perderemos toda a informação sobre um determinado fornecedor. Como os dados do fornecedor não estão mais associados aos pedidos, e sim em uma tabela distinta, não há perda de informações sobre um determinado fornecedor mesmo que todos os pedidos feitos a ele sejam eliminados.

Atualização: Se algum dado de um fornecedor mudar, teremos que atualizar apenas uma linha da Tabela de Fornecedores e todos os pedidos refletirão esta mudança.

Modelo de Dados obtido após a 3FN

Emite possui


FILIAL PEDIDO ITEM DO PEDIDO

FORNECEDOR PRODUTO



É para um contém


Dois Atributos Com Nomes Iguais de Tabelas Distintas

Documents

Transcript of Dois Atributos Com Nomes Iguais de Tabelas Distintas