Normalizacao

Banco de Dados Teoria da Normalização

BD_05 (01) 02 de fevereiro de 2005

Gabriel Issa Jabra Shammas

TEORIA DA NORMALIZAÇÃO ● Relação de siglas utilizadas neste trabalho: 1FN: Primeira Forma Normal. 2FN: Segunda Forma Normal. 3FN: Terceira Forma Normal. 4FN: Quarta Forma Normal. 5FN: Quinta Forma Normal. 6FN: Sexta Forma Normal. FN: Forma Normal. SGBD: Sistema Gerenciador de Banco de Dados. SI: Sistema de Informação.

1/15

1. TEORIA DA NORMALIZAÇÃO Em 1970, o Professor Dr. Edgar F. Codd, analista da IBM, desenvolveu uma série de estudos sobre como tratar os dados, a fim de eliminar as anomalias e as suas consequências desagradáveis para as organizações. Deste esforço surgiram duas inovações que revolucionaram a maneira de tratar os dados. A primeira destas inovações é o Modelo Relacional, no qual se basearam os Sistemas Gerenciadores de Base de Dados (SGBD) da metade da década de 1980 e início de 1990. A segunda inovação é a Teoria da Normalização, sendo que ambas estão intimamente relacionadas.

2/15

2. O MODELO RELACIONAL O Modelo Relacional é um modelo matemático derivado da Teoria dos Conjuntos que propõe que as estruturas de dados devem ser encaradas como conjuntos. Cada conjunto contém apenas elementos do mesmo tipo. A estes conjuntos, o Modelo Relacional atribui o nome de tabela ou relação. Assim, todos os funcionários de uma organização podem ser refletidos em uma tabela “FUNCIONÁRIO” que representa o tipo de informações que devem ser armazenadas e recuperadas sobre os funcionários, de modo que a tabela “FUNCIONÁRIO” permite o armazenamento de informações sobre o seu nome, cargo, salário, data de nascimento, data de admissão, entre outros. Cada um destes tipos de informação é disposto como coluna desta tabela. As linhas da tabela representam cada um dos indivíduos ou ocorrências desta tabela. Ou seja, cada linha da tabela “FUNCIONÁRIO” contém informações sobre um único funcionário. As colunas da tabela representam cada uma das características presentes em cada um dos indivíduos ou ocorrências desta tabela. Cada coluna coluna corresponde a um atributo da entidade. Além disso, a Teoria dos Conjuntos diz que todo elemento de um conjunto deve possuir uma identidade própria que permita ser individualizado do todo. Portanto, toda tabela deve possuir uma coluna que contenha o tipo de informação que individualize cada um dos funcionários: esta coluna chama-se chave primária. No caso do funcionário, o seu número de matrícula é a chave primária, uma vez que não existem dois funcionários com o mesmo número de matrícula. Assim, se o número de matrículo do funcionário for conhecido, é possível obter suas outras informações, porque as colunas da tabela “FUNCIONÁRIO” dependem funcionalmente ou existem em função da chave primária. Desta forma, construir o Modelo Relacional consiste em reduzir um ambiente complexo de dados (como geralmente existem nas bases de dados antigas) em um grupo de tabelas simples que contenham informações sobre apenas um padrão de dados e onde cada coluna dependa funcionalmente da chave primária.

3/15

2.1. Dependência funcional No modelo matemático, diz-se que Y = F(X), se para cada valor de X existe um, e somente um, valor correspondente de Y. No modelo de dados, vamos encontrar a dependência funcional quando um atributo depende apenas da chave primária. Assim, considerando a tabela “FUNCIONÁRIO”, cuja chave primária é o NÚMERO DE MATRÍCULA, tem-se que: NOME = f (MATRÍCULA); SALÁRIO = f (MATRÍCULA); CARGO = f (MATRÍCULA); DATA DE NASCIMENTO = f (MATRÍCULA) Deste modo, dado um valor de matrícula do funcionário, existe apenas um conjunto de informações sobre um funcionário que se relacione com aquela matrícula. Este conjunto individualiza ou particulariza cada um dos funcionários. Outros exemplos de tabelas simples onde existe somente a dependência funcional são: Cliente, Fornecedor, Distribuidor, entre outras. Para estes casos, o Modelo Relacional se apresenta como um modelo bem simples e fácil de ser desenvolvido.

4/15

3. A TEORIA DA NORMALIZAÇÃO No entanto, os dados possuem tantas particularidades no mundo real dos Negócios que, para aplicar o Modelo Relacional, fez-se necessário definir algumas regras cujo propósito é auxiliar na simplificação das estruturas de dados mais complexas. Ao conjunto destas regras foi dado o nome de TEORIA DA NORMALIZAÇÃO, que é o mecanismo para transformar estruturas complexas de dados em sua forma mais simples. Portanto, diz-se que uma estrutura de dados está “normalizada” quando está em seu estágio de maior simplicidade. Para entender melhor o que é normalização, é necessário entender o que é simplicidade para as estruturas de dados. Simplicidade de uma estrutura pode ser definida como a existência apenas de dependência funcional. Assim, uma tabela deve conter apenas informações que se refiram a um mesmo tipo de dados. Ou seja, todas as colunas da tabela devem depender funcionalmente da chave primária. No exemplo do funcionário, somente dados sobre os funcionários devem ser armazenados na tabela de “FUNCIONÁRIO”. Qualquer outra informação colocada na mesma tabela gera automaticamente uma anomalia de redundância, inflexibilidade e dificuldade de manutenção. Em resumo: a normalização consiste em descobrir o lugar certo para cada coisa e colocar cada coisa no seu devido lugar. “Normalizar” uma gaveta da mesa de uma secretária desorganizada, por exemplo, é simplificar a “confusão” de objetos que existem lá dentro (e que torna difícil achar qualquer coisa). Para isso, basta definir um lugar para a agenda, para os clips, para os lápis e as canetas, para os documentos etc. Esta separação se baseia, portanto, nos tipos de objetos. No que se refere aos dados, o processo é o mesmo. Normalizar é colocar cada tipo de informação no seu devido lugar, pois existe um lugar para cada coisa e cada coisa deve estar no seu lugar. Existem seis tipos de anomalias ou estruturas confusas e complexas, sendo que 3 (três) são principais: grupos repetitivos, dependência funcional parcial e dependência transitiva. Para cada tipo de anomalia, existe uma regra na normalização que deve ser usada para eliminá-la, tornando a estrutura de dados cada vez mais simples. Assim, o processo de normalização consiste em eliminar anomalias, fazendo com que as estruturas complexas mudem de estágio rumo à maior simplicidade possível. A cada um desses estágios, dá-se o nome de Forma Normal (FN). Para cada forma normal (FN), o analista deve utilizar uma regra para simplificar a estrutura de dados. Existem 6 (seis) formas normais (FN), sendo que as três primeiras são as que possuem maior aplicação prática e as demais são de uso mais acadêmico. Assim, a Teoria da Normalização, proposta pelo Dr. Codd, tem o objetivo de assegurar a precisão dos dados. Com o uso desta técnica, as entidades e os relacionamentos são “filtrados” sucessivamente de forma a eliminar as anomalias de atualização, ou seja, inserção, modificação e exclusão de dados. Os “filtros”, como foram mencionados anteriormente, nada mais são do que as formas normais, de modo que, para se atingir os objetivos da Teoria da Normalização, é necessário aplicar estas formas normasis (1FN, 2FN, 3FN, 4FN etc.).

5/15

A normalização é aplicada em diferentes estágios do projeto de sistemas. Quando a normalização é aplicada na fase de levantamento de dados, ou seja, quando são analisados relatórios, notas fiscais, formulários e outros documentos relacionados ao projeto em questão para a elaboração do projeto de modelo de dados, pode-se utilizar da técnica bottom-up. Quando a normalização é aplicada após a elaboração do modelo de dados, de modo a assegurar a melhor implementação no banco de dados a ser construído, pode-se utilizar a técnica top-down.

6/15

3.1. Estruturas não normalizadas e complexas Antes de falar sobre as estruturas normalizadas (ou seja, simples), é necessário entender o que não é normalizado e, portanto, complexo. Como já foi citado, a simplicidade de uma estrutura de dados está intimamente relacionada ao grau de afinidade entre suas colunas. Assim, o modelo está normalizado se cada tabela contiver apenas colunas que se refiram somente a ela e a nenhuma outra, possuindo o nível máximo de afinidade. Esse nível de afinidade é definido como dependência funcional. Diz-se que uma coluna depende funcionalmente de outra se, para saber o seu conteúdo, é preciso primeiramente saber o conteúdo da outra. Dessa forma, uma estrutura de dados estará normalizada sempre que todas as suas colunas dependerem funcionalmente da sua chave primária. Exemplo: para recuperar os atributos nome, endereço e telefone de um funcionário deve-se conhecer apenas a matrícula desse funcionário. Portanto, existe uma dependência funcional entre esses atributos e a chave primária. No entanto, podem ser encontradas estruturas de dados complexas que não se encontram no estágio máximo de simplicidade, onde existe somente a dependência funcional. Por isso, diz-se que essa estrutura não está adequada ao padrão de simplicidade, ou seja, está desnormalizada. São 6 (seis) os casos de anomalias que caracterizam uma estrutura de dados desnormalizada, sendo que os três principais são:   

Grupo Repetitivo, Dependência Funcional Parcial, Dependência Funcional Transitiva (ou Indireta).

3.1.1. Grupo Repetitivo de Atributos Um grupo repetitivo de atributos é o conjunto de atributos de uma entidade que ocorre múltiplas vezes para cada ocorrência da entidade. Por exemplo: a entidade “FUNCIONÁRIO” possui os seguintes atributos: MATRÍCULA, NOME, ENDEREÇO COMPLETO, NOME DO DEPENDENTE, DATA DE NASCIMENTO DO DEPENDENTE, GRAU DE PARENTESCO DO DEPENDENTE. Neste caso, existe um conjunto de atributos que se refere aos dependentes do funcionário (NOME DO DEPENDENTE, DATA DE NASCIMENTO DO DEPENDENTE, GRAU DE PARENTESCO DO DEPENDENTE) e não ao funcionário. Esse conjunto poderá ocorrer múltiplas vezes para cada funcionário, dependendo da quantidade de dependentes que ele possua, e é denominado de Grupo Repetitivo.

7/15

3.1.2. Dependência Funcional Parcial A dependência funcional parcial é a dependência funcional de um atributo em relação a uma parte da chave primária da entidade, caso ela seja composta por mais de um atributo. Se uma entidade “E1” possui como chave primária a concatenação dos atributos A e B, e um atributo C depende funcionalmente apenas de B, então diz-se que o atributo C depende parcialmente da chave primária. Por exemplo: a entidade “ESTOQUE DE PRODUTOS” possui os seguintes atributos: CÓDIGO DO PRODUTO, NÚMERO DE SÉRIE, DATA DE FABRICAÇÃO, QUANTIDADE EM ESTOQUE, DESCRIÇÃO DO PRODUTO, PREÇO DO PRODUTO. A chave primária é composta pelos atributos CÓDIGO DO PRODUTO e NÚMERO DE SÉRIE. Nesse caso, a DATA DE FABRICAÇÃO e a QUANTIDADE EM ESTOQUE dependem de toda a chave primária. Por outro lado, a DESCRIÇÃO DO PRODUTO e o PREÇO DO PRODUTO dependem apenas do CÓDIGO DO PRODUTO, ou seja, de parte da chave primária. 3.1.3. Dependência Funcional Transitiva (ou Indireta) A dependência funcional transitiva é a dependência funcional indireta existente entre dois ou mais atributos. Se um atributo C depende funcionalmente de um atributo B e o atributo B depende funcionalmente de um atributo A, então diz-se que o atributo C depende indiretamente (transitivamente) do atributo A. Por exemplo: a entidade “PEDIDO DE VENDAS” possui os seguintes atributos: NÚMERO DO PEDIDO, DATA DO PEDIDO, SITUAÇÃO DO PEDIDO, CÓDIGO DO CLIENTE, NOME DO CLIENTE, ENDEREÇO DO CLIENTE. A chave primária é o NÚMERO DO PEDIDO. Nesse caso, os atributos DATA DO PEDIDO, SITUAÇÃO DO PEDIDO e CÓDIGO DO CLIENTE dependem funcionalmente da chave primária (NÚMERO DO PEDIDO), o que é normal. No entanto, os atributos NOME DO CLIENTE e ENDEREÇO DO CLIENTE dependem funcionalmente do CÓDIGO DO CLIENTE (que é a chave primária da entidade “CLIENTE”) e indiretamente da chave primária da entidade “PEDIDO DE VENDAS”. Assim, os atributos do cliente estão dependendo de duas chaves primárias, configurando uma anomalia.

8/15

3.2. As formas normais A Teoria da Normalização classifica o nível de simplicidade de uma Estrutura de Dados com base na existência de um dos tipos de anomalias mencionados anteriormente. Cada estágio de simplicidade é denominado Forma Normal (FN). Portanto, se uma estrutura de dados não possui a primeira anomalia, então diz-se que ela está na primeira forma normal (1FN). Consequentemente, a ausência da segunda anomalia faz com ela esteja na segunda forma normal (2FN), bem como a ausência da terceira anomalia faz com ela esteja na terceira forma normal (3FN). São 6 (seis) as formas normais (FN), uma para cada anomalia, sendo que as três primeiras são as principais. 3.2.1. 1a Forma Normal (1FN) Uma estrutura de dados encontra-se na primeira forma normal (1FN) se todas as suas colunas ocorrerem uma única vez, não existindo grupos repetitivos. Os grupos repetitivos, se houverem, devem ser extraídos, criando-se uma nova estrutura de dados derivada da primeira, que deve possuir uma chave primária composta da seguinte maneira: a) chave primária da estrutura de dados original, b) um atributo (coluna) que diferencie cada uma de suas ocorrências. 3.2.2. 2a Forma Normal (2FN) Uma estrutura de dados encontra-se na segunda forma normal (2FN) se já estiver na primeira forma normal (1FN) e se todas as suas colunas que não são chave primária não apresentarem a anomalia da dependência funcional parcial em relação à chave primária. A anomalia da dependência funcional parcial ocorre quando a chave primária é composta por dois ou mais atributos (colunas) e outros atributos (colunas) não chave dependem de parte dessa chave primária. Nesse caso, deve-se criar uma nova estrutura de dados que contenha os atributos (colunas) que dependem de parte da chave primária, eliminando-se essa dependência funcional parcial. 3.2.3. 3a Forma Normal (3FN) Uma estrutura de dados encontra-se na terceira forma normal (3FN) se já estiver na segunda forma normal (2FN) e se não existir a anomalia da dependência transitiva ou indireta entre um atributo (coluna) e a chave primária. Portanto, uma estrutura de dados estará na terceira formal normal (3FN) se todos os seus atributos (colunas) dependerem funcionalmente apenas da chave primária e de nenhum outro atributo.

9/15

4. ESTUDO DE CASO Para ilustrar uma estrutura de dados onde existem as anomalias citadas anteriormente, suponha uma Vídeo Locadora que necessita armazenar dados sobre todas as fitas emprestadas a seus clientes para controle de devolução. Para isso, foi projetado um formulário que contém todas estas informações. A ficha de empréstimos discrimina os dados da ficha (número e data), os dados cadastrais do cliente (nome do cliente, nome, endereço completo, telefone, fax e dia/mês de aniversário), os dados da fita emprestada (código e nome do filme, autor do filme, quantidade emprestada, preço do filme e valor a pagar de cada filme), os dados do vendedor (código, nome fantasia e data de admissão), bem como o desconto total e o valor total (já deduzido o desconto) do empréstimo. Geralmente, as estruturas de dados mais complexas são aquelas derivadas de documentos, formulários e relatórios, pois tem-se a tendência de reunir vários tipos de dados no mesmo local físico na ilusão de que a recuperação de informações se torna mais fácil e rápida. Porém, a prática tem demonstrado que esse é um critério ruim para definir as estruturas de dados. No exemplo em questão, foi criado um arquivo manual para armazenar cada uma das fichas de empréstimos dos clientes. Aí começam a surgir os problemas ... Vejamos alguns desses problemas. Em primeiro lugar, os dados cadastrais do cliente aparecem em várias listagens, uma vez que os clientes emprestam fitas várias vezes em dias diferentes. Portanto, se o cliente mudar de telefone, os administradores do arquivo devem atualizar todas as listagens, para poderem entrar em contato com o cliente caso as fitas não sejam devolvidas. Como as fichas são armazenadas em ordem de data, é fácil imaginar o transtorno. O segundo problema ocorre porque os dados do filme (código, nome, autor e preço unitário) aparecem quantas vezes uma fita for emprestada. Agora suponha que o preço seja reajustado. Então, todas as fichas de empréstimos deverão ser atualizadas, sob o risco de se cobrar, em alguns casos, o preço antigo. Um terceiro problema surge quando o dono da locadora resolve solicitar um relatório gerencial, discriminando, por filme, a quantidade de fitas emprestadas, o que significa que a ordem de acesso ao arquivo manual deve ser alterada, não mais devendo ser classificada por data, mas sim por filme. Como a estrutura do arquivo manual é inflexível e complexa, os administradores têm de reclassificar todo o arquivo para anotar o nome do filme e a quantidade de fitas; depois, devem sumarizar os dados, por filme, para entregar ao dono da locadora. Essa operação é demorada e deve ser repetida a cada solicitação feita, atrapalhando os negócios do dia-a-dia. Finalmente, o dono da vídeo locadora resolve incluir na ficha de empréstimo dados sobre o limite de crédito do cliente. Como esse dado não existe, as fichas devem ser todas jogadas fora por não caber mais nenhuma informação no seu cabeçalho; aí, devem ser confeccionadas novas fichas de novo tipo e copiados os dados das antigas no novo formato. Estes procedimentos de conversão de estrutura de dados tomam muito tempo.

10/15

Neste ponto, o dono da empresa resolve implantar um Sistema de Informação (SI) para suportar a sua Área de Negócio de Empréstimos de Fitas de Vídeo, a fim de agilizar as operações e facilitar a recuperação de informações. Os analistas encarregados passam a estudar a estrutura de dados da Ficha de Empréstimo para simplificá-la, a fim de não incorporarem ao Sistema de Informação (SI) os mesmos problemas já mencionados. Isso porque tanto faz se o suporte é manual ou automatizado, pois os problemas e anomalias são idênticos. Para isso, são aplicadas as regras da Normalização! 4.1. Normalizando para a 1FN Neste exemplo da Vídeo Locadora deve se aplicar a regra número 1 da Teoria da Normalização para resolver os problemas existentes na Ficha de Empréstimos, eliminando os Grupos Repetitivos e “quebrando-se” a ficha em duas estruturas. Uma delas contém apenas os dados próprios da ficha e a outra correspondendo a cada linha que contém as fitas emprestadas. FICHA DE EMPRÉSTIMO: Número da Ficha, Data da Ficha, Código do Cliente, Nome do Cliente, Endereço do Cliente, Telefone do Cliente, Fax do Cliente, Data de Aniversário do Cliente, Desconto Total, Valor Total do Empréstimo. FITA EMPRESTADA: Código do Filme, Nome do Filme, Autor do Filme, Preço Unitário, Quantidade Emprestada, Valor a Pagar. No entanto, como identificar a que ficha pertence cada FITA EMPRESTADA? Este problema é resolvido, “exportando” a chave primária da tabela FICHA DE EMPRÉSTIMO (Número da Ficha) para a tabela FITA EMPRESTADA, gerando o que se chama de redundância controlada. Esse tipo de chave exportada chama-se chave estrangeira. Embora tenha-se criado uma redundância do número da ficha, pois ela aparece nas duas tabelas, a flexibilidade da estrutura é maior e compensa. Por outro lado, é impossível definir estruturas de dados sem qualquer redundância. O critério de redundância controlada se baseia no “menos pior”, ou seja, se é preciso criar alguma redundância, que ela seja criada para as Chaves Primárias, que são dados mais estáveis (sofrem pouca ou nenhuma atualização). Portanto, a nova estrutura criada de FITA EMPRESTADA possui uma chave primária (identificador único de cada fita emprestada) composta por duas colunas: o número da ficha e o código do filme. FITA EMPRESTADA: Número da Ficha, Código do Filme, Nome do Filme, Autor do Filme, Preço Unitário, Quantidade Emprestada, Valor a Pagar. Desta forma, a estrutura está mais simples e pode-se dizer que está na Primeira Forma Normal (1FN) e as consultas sbore filmes emprestados são agora mais fáceis de obter, pois cada fita está descrita em um lugar e não todas juntas dentro da ficha, tornando bem mais simples a classificação por filmes.

11/15

4.2. Normalizando para a 2FN No entanto, alguns problemas ainda existem na FICHA DE EMPRÉSTIMO, porque o problema de atualização do preço do filme ainda tem de ser realizado em todas as fitas emprestadas. Isto ocorre porque existe uma anomalia na estrutura de dados FITAS EMPRESTADAS: a dependência funcional parcial, ou seja, existem algumas informações que dependem apenas do código do filme e não de toda a chave primária da tabela (entidade), ou seja, do Número da Ficha e do Código do Filme. Em outras palavras, o Nome do Filme, seu Autor e seu Preço não mudam para cada empréstimo feito. Eles são sempre os mesmos, porque dependem do Código do Filme. Note que o uso das expressões “do filme” para identificar o Nome e o Autor já induzem a pensar que a dependência funcional destas colunas é com o filme e não com a fita emprestada. Isto não acontece com a Quantidade e o Valor a Pagar, porque dependem de cada empréstimo feito. Um cliente pode ter emprestado um filme com 2 fitas; um outro cliente, o mesmo filme com uma única fita. Assim sendo, a quantidade e o valor dependem de toda a chave primária da tabela (entidade) FITA EMPRESTADA, ou seja, do Número da Ficha e do Código do Filme. Desta forma, é hora de retirar os dados do filme que estão juntos com a fita, eliminando a dependência funcional parcial. Ficariam, portanto, da seguinte forma as estruturas de dados: FICHA DE EMPRÉSTIMO: Número da Ficha, Data da Ficha, Código do Cliente, Nome do Cliente, Endereço do Cliente, Telefone do Cliente, Fax do Cliente, Data de Aniversário do Cliente, Desconto Total, Valor Total do Empréstimo. FITA EMPRESTADA: Número da Ficha, Código do Filme, Quantidade Emprestada, Valor a Pagar. FILME: Código do Filme, Nome do Filme, Autor do Filme, Preço Unitário. Com esta atitude, elimina-se a dependência funcional parcial e simplifica-se ainda mais a estrutura, colocando-a no estágio 2 de simplicidade ou na Segunda Forma Normal (2FN). Agora, cada vez que o preço do filme se alterar, basta atualizar a estrutura FILME e, quando forem consultadas as fitas emprestadas, o novo preço pode ser obtido diretamente da tabela de FILME, através da chave estrangeira Código do Filme contida na estrutura FITA EMPRESTADA. Em outras palavras, as ligações entre a FITA EMPRESTADA e o seu FILME é dada por um acesso lógico ao FILME, feito em tempo de consulta, e não pela junção física das duas tabelas. 4.3. Normalizando para a 3FN Todavia, ainda resta um problema a resolver. Caso haja mudança nos dados do cliente, porque ele trocou o número de seu telefone, por exemplo, estes dados devem ser alterados em todas as fichas daquele cliente.

12/15

Esta anomalia ocorre porque os dados do cliente aparecem em cada FICHA DE EMPRÉSTIMO, gerando um redundância descontrolada e uma consequente dificuldade de atualização e manutenção. A esta anomalia chama-se dependência funcional transitiva ou indireta, a qual ocorre quando existem algumas colunas da FICHA DE EMPRÉSTIMO que não dependem da chave primária que é o Número da Ficha, mas de outra coluna que não é parte integrante da chave primária. Por exemplo, o Nome, o Endereço, o Telefone, o Fax e a Data de Aniversário do Cliente dependem do Código do Cliente e não do Número da Ficha. Isto porque o Nome do Cliente não muda em função de cada empréstimo (é sempre o mesmo). Então, não há sentido em repetir-se os dados do Cliente em cada FICHA DE EMPRÉSTIMO (deve-se notar que, mais uma vez, a expressão “do Cliente” induz que a dependência existe com o Cliente e não com a Ficha). Com esta anomalia, cada vez que se altera um dado do Cliente, isto não é automaticamente refletido para todas as fichas a ele pertencentes, necessitando atualizações duplicadas. O fato de uma coluna não depender funcionalmente da chave primária, mas de uma outra coluna que depende da chave primária, chama-se dependência funcional transitiva (ou indireta). O Código do Cliente depende funcionalmente do Número da Ficha, pois cada Ficha possui apenas um Cliente. No entanto, os demais dados do Cliente dependem primeiramente do Código do Cliente e indiretamente do Número da Ficha. Matematicamente, diz-se que se A depende de B e B depende de C, então A depende transitivamente (indiretamente) de C. A dependência funcional transitiva deve, também, ser eliminada, bastando, para tal, quebrar a estrutura FICHA DE EMPRÉSTIMO em duas outras. Assim, uma estrutura deve conter os dados próprios do Cliente e a outra os dados da Ficha mais uma identificação do Cliente a quem pertence a Ficha (chave estrangeira). FICHA DE EMPRÉSTIMO: Número da Ficha, Data da Ficha, Código do Cliente, Desconto Total, Valor Total do Empréstimo. CLIENTE: Código do Cliente, Nome do Cliente, Endereço do Cliente, Telefone do Cliente, Fax do Cliente, Data de Aniversário do Cliente. Como o Código do Cliente depende funcionalmente somente do Número da Ficha, a dependência transitiva foi eliminada. A chave estrangeira é uma redundância “controlada”, porque sendo a chave primária do Cliente ela não sofrerá alterações (é um dado estável). Desta forma, é melhor duplicar chaves a ter redundância de outros dados que se alteram facilmente. No entanto, no caso da FICHA DE EMPRÉSTIMO, existe uma outra ocorrência da dependência funcional transitiva: o Valor Total do Empréstimo. Este dado não depende somente da chave primária (Número da Ficha), mas também de outras colunas. Isto porque o Valor Total do Empréstimo é o resultado da somatória entre os valores a pagar de cada filme emprestado.

13/15

Supondo que o preço de algum filme se altere, então o valor total passa a ser inconsistente. Por isso, a estrutura ainda não está na 3FN, uma vez que o Valor Total de Empréstimo depende transitivamente da chave primária. Para eliminar esta anomalia, o Valor a Pagar deve ser eliminado da Ficha, devendo ser produto de cálculo. Com a eliminação da dependência funcional transitiva, a estrutura Ficha de Empréstimo chega ao terceiro estágio de simplicidade, ou seja, encontra-se na terceira forma normal (3FN). FICHA DE EMPRÉSTIMO: Número da Ficha, Data da Ficha, Código do Cliente, Desconto Total. CLIENTE: Código do Cliente, Nome do Cliente, Endereço do Cliente, Telefone do Cliente, Fax do Cliente, Data de Aniversário do Cliente. FITA EMPRESTADA: Número da Ficha, Código do Filme, Quantidade Emprestada, Valor a Pagar. FILME: Código do Filme, Nome do Filme, Autor do Filme, Preço Unitário.

14/15

Observação: A técnica BOTTON-UP é usada quando aplicarmos a normalização na fase de levantamento de dados, ou seja, quando analisamos Relatórios, Notas Fiscais, Formulários e outros documentos relacionados ao projeto em questão para a elaboração do projeto de modelo de dados. A técnica TOP-DOWN é usada após a elaboração do modelo de dados, quando aplicamos a normalização para assegurar a melhor implementação em nosso banco de dados. Os “filtros” que foram comentados acima são as formas normais, ou seja, a Primeira Forma Normal (1FN), Segunda Forma Normal (2FN) e Terceira Forma Normal (3FN). Desta maneira temos que aplicar a 1FN a 2FN e a 3FN para chegarmos nos objetivos da Teoria da Normalização.

15/15