Anda di halaman 1dari 15

Banco de Dados BD_05 (01)

Teoria da Normalização 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