UM GUIA SIMPLES PARA CINCO FORMAS

NORMAIS NA TEORIA DE BANCO DE

DADOS RELACIONAL.
1 INTRODUÇÃO
As formas normais definidas na teoria de banco de dados relacional representam
orientações para design de gravação. As orientações correspondentes à primeira das
cinco formas normais que são apresentadas, em termos que não necessitam e
compreensão da teoria relacional. A concepção das orientações são significativas,
mesmo que um banco de dados relacional sistema não é utilizado.
Apresentamos as orientações sem referir-se aos conceitos do modelo relacional,
a fim de enfatizar sua generalidade e torná-los mais fáceis de entender. Nossa
apresentação transmite um senso intuitivo da intenção de proceder constrangimentos à
concepção do registro, embora, na sua informalidade, pode ser imprecisa em alguns
detalhes técnicos. Um tratamento completo do tema é fornecida pela Date [4].
[4]. Date, C.J. An Introduction to Database Systems. 3rd Ed. Addison-Wesley,
Reading, MA, 1981.
As regras de normalização são desenvolvidas para evitar anomalias na
atualização e inconsistência de dados. No que diz respeito à performance trade-offs,
estas orientações são tendenciosas em direção a suposição de que todas as não-
chaves(nonkey) serão atualizados com freqüência. Elas tendem a penalizar a
recuperação, uma vez que os dados podem acabar sendo recuperados a partir de vários
registros na forma normalizada. Não há qualquer obrigação íntegra de normalizar todos
os registros quando desempenho real é requisito levado em conta.

2 PRIMEIRA FORMA NORMAL

A Primeira Forma Normal [1] trata da "forma" de um tipo de registro. Sob
primeira forma normal, todas as ocorrências de um tipo de registro deve conter o
mesmo número de domínios. A Primeira forma normal exclui variável repetindo
campos e grupos. Isto não é tanto uma concepção orientação como uma questão de
definição. A teoria de Banco de dados relacional não trata de registros que tenham um
número variável de campos.

3 SEGUNDA E TERCEIRA FORMAS NORMAIS

Segunda e terceira formas normais [2, 3, 7] lidam com o relacionamento entre
“não-chaves” e campos principais. Nos termos da segunda e terceira formas normais,
uma “não-chave”campo deve fornecer uma verdade acerca da chave, toda a chave, e só
a chave. Além disso, o registro deve satisfazer a primeira forma normal.
Estamos agora apenas lidando com dependências de um atributo. Uma
dependência de um atributo pode ser uma relação de um-para-muitos assim ocomo o
departamento de um gerente ou uma relação um-para-um assim como a esposa do
gerente. Deste modo, a frase "Y é dependente de X" significa uma relação de um-para-
um ou um-para-muitos entre Y e X. No caso geral, Y pode consistir de um ou mais
campos assim como X. No exemplo seguinte, QUANTITY é uma verdade sobre a
combinação de PART e WAREHOUSE.
3.1 Segunda Forma Normal
A segunda forma normal é violada quando um campo não chave é dependente de
um subconjunto de uma chave. Isto somente é relevante quando a chave é composta,
isto é, consiste de varios campos. Considere o seguinte registro:

A chave aqui consiste dos campos PART e WAREHOUSE juntos, mas

WAREHOUSE-ADDRESS somente depende de WAREHOUSE. Os problemas basicos
com este design são:
- O WAREHOUSE-ADDRESS é repetido em todo registro que se refere a
PART armazenada na WAREHOUSE.
- Se WAREHOUSE-ADDRESS mudar, todo o registro que esta referenciando a
PART armazenada na WAREHOUSE será atualizada.
- Por causa da redundancia, os dados podem ser insconsistentes, com reigstros
diferentes mostrando WAREHOUSE-ADDRESS diferentes para a mesma
WAREHOUSE.
- Se em algum momento não ouverem PARTS armazenadas em uma
WAREHOUSE, pode não haver registro onde armazenar um WAREHOUSE-
ADDRESS.
Para satisfazer a segunda forma normal, o registro mostrado a seguir deve ser
decomposto em (substituido por) dois registros:

Quando o design de um dado é mudado desta maneira, isto é, substituir registros

não normalizados com registros normalizados, o processo é chamado normalização. O
termo normalização é as vezes usado relacionado a uma forma normal em particular.
Deste modo, registros podem ser normalizados respeitando a segunda forma normal
mas não respeitando a terceira forma normal.
O design normalizado melhora a integridade dos dados minimizando a
redundancia e a insonsistencia, mas pode haver alguns custos de performance oara
certas aplicações. Considerando uma aplicação que quer todos os WAREHOUSE-
ADDRESS armazenados de uma certa PART. Na forma não normal, a aplicação
procura um tipo de registro. Com a forma normalizada, a aplicação precisa procurar
dois tipos de registro e conectar os pares apropriados.

3.2 Terceira forma normal.

Terceira forma normal é violado quando um campo não-chave é um domínio
sobre outro campo não chave, como em:
 O campo FUNCIONÁRIO é a chave. Se cada departamento está localizado em
um lugar e, em seguida, a localização campo é um facto sobre o departamento -, além
de ser um facto sobre o empregado. Os problemas com esta concepção são as mesmas
que foram causados por violações de segunda forma normal:
• A localização do Departamento é repetido no registro de todos os funcionários
atribuídos a esse serviço.
• Se a localização do departamento mudou, cada tal registo deve ser atualizado.
• Devido à redundância, os dados poderão tornar-se incoerentes, com diferentes
registos mostrando diferentes localizações para o mesmo departamento.
• Se um departamento não tem empregados, pode não haver registro para manter a
localização do departamento.
Para satisfazer a terceira forma normal, o registro mostrado acima devem ser
decomposto em dois registros:

Para resumir, é um registro na segunda e terceira formas normais se cada campo

ou é parte da chave ou presta um (único-valorizada) sobre exatamente o fato de toda
chave e nada mais.

3.3 Dependências funcionais

Na teoria ralacional de banco de dados, segunda e terceira formas normais são
definidas em termos de dependências funcionais, que correspondem aproximadamente a
nossa única-valorizada.(não sei se é isto....Lia). Um campo Y é " dependente
funcionalmente" em um campo (ou campos) X, se for inválida a ter dois registros com o
mesmo valor X, mas diferentes valores para y. Ou seja, um determinado valor-X deve
ocorrer sempre com o mesmo valor-Y. Quando X é uma chave, então todos os campos
são, por definição dependentes funcionalmente de X de uma maneira trivial, uma vez
que não pode haver dois registos com o mesmo valor X.
Existe uma ligeira diferença técnica entre dependências funcionais e fatos
(único-valorizado) , tal como nós apresentamos-los. Dependências funcionais só
existem quando as coisas envolvidas tem único e singular identificadores
(representações). Por exemplo, suponha um endereço da pessoa é um fato (único-
valorizado), ou seja, uma pessoa tem apenas um endereço. Se não fornecer
identificadores únicos para as pessoas, então não haverá uma dependência funcional em
termos de dados:

Embora cada pessoa tem um endereço exclusivo de um determinado nome pode

aparecer em vários endereços diferentes. Daí nós não temos uma dependência funcional
que corresponde a nosso fato (single-valued) único-valorizado.
Do mesmo modo, o endereço tem de ser escrito identicamente em cada
ocorrência, a fim de ter uma dependência funcional. Nos seguintes casos a mesma
pessoa parece estar vivendo em dois endereços diferentes, novamente afastando-se da
dependência funcional.

Não estamos defendendo a utilização de representações “nonunique” ou

“nonsingular”. Essas práticas muitas vezes levam a manutenção de dados dos seus
próprios problemas. Nós desejamos salientar, no entanto, que as várias dependências
funcionais e formas normais são realmente definidas apenas para situações em que
existem identificadores únicos e singulares. Assim, as orientações que estamos
apresentando são mais fortes do que as formais definições das formas normais.
Por exemplo, nós sabemos que desenhos como no seguinte exemplo, há um
único fato sobre um atributo que não é chave primária, e, portanto, o desenho é
suscetível à atualizar todas as anomalias mencionadas anteriormente.

No entanto, em termos formais, não existe uma dependência funcional entre aqui
ENDEREÇO -PAI e PAI, e, portanto, não há violação da terceira forma normal.

4. QUARTA E QUINTA FORMAS NORMAIS

Quarta [5] e quinta [6] formas normais lidam com fatos multivalorados. Um fato
multivalorado pode corresponder a uma relação “muitos pra muitos”, como com os
empregados e as competências, ou para muitos relacionamentos “um-para-um”, como
acontece com os filhos de um trabalhador (assumindo que apenas um dos pais é um
empregado). Por "muitos para muitos", entendemos que um empregado pode ter várias
habilidades e / ou que uma habilidade pode pertencer a vários trabalhadores.
Note que olhamos para o relacionamento “muitos-para-um” relacionamento
entre crianças e pais como um único fato cerca de um filho, mas um fato multivalorado
a cerca de um pai. A quarta e quinta formas normais também tem chaves compostas.
Estas formas normais tentam minimizar o número de campos envolvidos em uma chave
composta, como sugerido pelos exemplos que se seguem.

4.1 Quarta forma normal

Na quarta forma normal, um tipo de registro não deve conter duas ou mais fatos
independente multivalorados sobre n entidades. Além disso, o registro deve satisfazer a
terceira forma normal. O termo "independente" será debatido após considerar um
exemplo. Considere empregados, as qualificações, e línguas, onde um empregado pode
ter várias habilidades e várias línguas. Temos aqui dois relacionamentos “muitos-para-
muitos”, uma entre trabalhadores e competências, e uma entre os trabalhadores e as
línguas. Nos termos da quarta forma normal, estas duas relações não deve ser
representada em um único registro como:
 Em vez disso, elas devem estar representados em dois registros

Note que outros campos, que não envolvam fatos multivalorados, podem estar
no registro, como no caso do campo QUANTIDADE no exemplo anterior
PART/WAREHOUSE. O problema principal com a violação da quarta forma normal é
que ela conduz a incertezas na manutenção políticas. Várias políticas são possíveis para
manter dois fatos multivalorados independentes, em um registro.
(1) A formato disjunto, no qual um registro contém tanto uma habilidade ou de uma
língua, mas não ambos.

Isso não é muito diferente de manter dois tipos distintos de registro. Fazemos
notar que tal formato também leva a dúvidas quanto ao significado dos campos em
branco. Um branco para APTIDÕES poderia significar que a pessoa não tem
habilidade, que o campo não é aplicável a esse trabalhador, que os dados não são
conhecidos, ou, como neste caso, que os dados podem ser encontrados em outro
registro.

(2) Uma combinação aleatória, com três variações

(a) número mínimo de registros com repetições.

(b) número mínimo de registros, com valores nulos

(c) irrestrito.

(3) A forma "cross-product", onde para cada trabalhador, deve haver um registro
dos possíveis emparelhamentos de uma de suas habilidades com um de seus idiomas.
 Outros problemas causados pela violação da quarta forma normal são similares
em espírito aos mencionados anteriormente pela violação da segunda ou terceira formas
normais. Eles assumem diferentes variações dependendo da política de manutenção
escolhida.
1. Se há repetições, então devem ser feitas atualizações nos vários registros, pois os
registros podem tornar-se inconsistentes
2. A inserção de uma nova habilidade pode implicar olhar para um registro com
uma habilidade em branco, inserindo um novo registro com, possivelmente, uma
língua em branco, ou inserindo vários registros, emparelhando a nova habilidade
com algumas ou todas as línguas.
3. A remoção de uma habilidade pode implicar limpar o campo habilidade em um
ou mais registros (talvez com uma verificação de que este não deixa dois
registros com a mesma língua e uma habilidade em branco) ou apagar um ou
mais registros, juntamente com uma verificação de que a última menção a
alguma língua não foi deletada também.

A quarta forma normal minimiza tais problemas de atualização.

4.1.1 Independência: Nós mencionamos anteriormente a independência multivalorada,

e agora vamos esclarecer o que significa este termo. Os dois relacionamentos muitos-
para-muitos, empregado:habilidade e empregado:língua, são independentes, sendo que
não há conexão direta entre habilidades e línguas. Há apenas uma conexão indireta, pois
eles pertencem a algum empregado em comum. Isto é, não importa que habilidade está
ligada com que língua no registro; a ligação não fornece nenhuma informação. É
exatamente por isso que todas as políticas de manutenção mencionadas anteriormente
podem ser aceitas.
Em contrapartida, suponhamos que um empregado só pode exercer determinadas
habilidades em certas línguas. Talvez Smith possa preparar somente comida francesa,
mas pode falar francês, alemão e grego. Então a ligação de habilidades e línguas torna-
se significativa, e já não há uma ambigüidade de políticas de manutenção. Neste caso,
somente apenas a seguinte forma está correta.

Assim, os relacionamentos empregado:habilidade e empregado:língua já não são

independentes. Esses registros não violam a quarta forma normal. Quando há uma
interdependência entre os relacionamentos, é aceitável representá-los em um único
registro.
4.1.2 Dependências Multivaloradas: Para os leitores interessados em conhecer o plano
de fundo técnico das quatro formas normais um pouco mais adiante, mencionamos que
as quatro formas normais são definidas em termos de dependências multivaloradas, que
correspondem à independência multivalorada de fatos. Dependências multi valoradas,
por sua vez, são definidas essencialmente como relações que aceitam a política de
manutenção "cross-product" acima mencionadas. Para o nosso exemplo, cada uma das
habilidades do trabalhador deve aparecer emparelhado com cada uma de suas
linguagens. Pode ou não ser óbvio para o leitor que isso é equivalente a nossa noção de
independência, uma vez que todas as duplas possíveis devem estar presentes, não há
nenhuma "informação" nas duplas. Essas duplas transmitem informações somente se
alguma delas pode estar ausente. Se todas as duplas estão sempre presentes, então os
relacionamentos são realmente independentes. Devemos também salientar que
dependências multi valoradas e a quarta forma normal também se aplica às relações que
envolvem mais de dois campos. Por exemplo, suponha que seja estendido o exemplo
anterior para incluir projetos, no seguinte sentido:
- Um funcionário usa determinadas habilidades em determinados projetos.
- O empregado utiliza certas linguagens em determinados projetos.
Se não houver nenhuma ligação direta entre as habilidades e as linguagens que
utiliza um empregado em um projeto, então podemos tratar isso como dois
relacionamentos n-para-n independentes na forma do EP:S e EP:L, onde EP representa a
combinação de um trabalhador com um projeto. Um registro incluindo empregado,
projeto, habilidade, e a linguagem podem violar a quarta forma normal. Dois registros,
contendo campos E, P, S e E, P, L, respectivamente, iria satisfazer a quarta forma
normal.

4.2 Quinta forma normal

Quinta forma normal lida com casos em que as informações possam ser
reconstruídas a partir de pequenos pedaços de informação que pode ser mantido com
menor redundância. Segunda, terceira e quarta formas normais também servem este
proposito, mas a quinta forma normal generaliza a casos não abrangidos pelos outros.
Não vamos tentar uma abrangente exposição de quinta forma normal, mas vamos
ilustrar o conceito central com um comumente exemplo, a saber, um envolvendo
agentes, empresas e produtos. Se agentes representam as empresas, as empresas fazem
produtos e agentes vendem produtos, então podemos querer manter um registo de que
agente que vende produtos para qual companhia. Esta informação poderá ser mantida
em um tipo de registro com três campos:

Este formulário é necessário, no caso geral. Por exemplo, embora agente Smith
venda automóveis feitos pela Ford e caminhões feita pela GM, ela não vende caminhões
Ford ou carros GM. Assim, precisamos da combinação de todos os três campos para
saber quais combinações são válidas e quais não são. Mas supondo que uma
determinada regra está em vigor: se um agente vende um determinado produto e que
representa a empresa que faz esse produto e, em seguida, ele vende o produto para essa
empresa.
 Neste caso, verifica-se que nós podemos reconstruir todos os fatos verdadeiros
de uma forma normalizada, composto por três tipos diferentes de registros, contendo.
cada um deles dois campos.

Estes três tipos de registros estão na quinta forma normal, considerando os três-
campos correspondentes não são mostrados previamente pelo registro.
Em grosso modo, nós podemos dizer que um tipo de registro esta na quinta
forma normal quando o conteúdo de sua informação não pode ser reconstituído a partir
de vários tipos de registros menores, isto é , cada tipo de registro tem menos campos
que um registro original. O caso em que todas os registros pequenos tem a mesma chave
excluída. Se um tipo de registro somente pode ser decomposto em pequenos registros
no qual todos tem a mesma chave, então o tipo de registro é considerado com estando
na quinta forma normal sem decomposição. Um registro na quinta forma normal
também esta na quarta, terceira, segunda e primeira forma normal.
Quinta forma normal não difere da quarta forma normal a menos que exista três
constrangimentos simétricos tais como as regras sobre agentes, as empresas e
protocolos. Na ausência de tal constrangimento, um tipo de registro na quarta forma
normal esta sempre na quinta forma normal.
Uma vantagem da quinta forma normal é que certa redundância pode ser
eliminada. Em uma forma normalizada, o fato de vender carros Smith é gerado apenas
uma vez; na forma desnormalizada, isto pode ser representado muitas vezes.
Deve ser observado que embora a forma normalizada envolve mais tipos de
registros, pode haver menor número de ocorrências menor que o total de ocorrências no
registro. Esta não é parente quando há apenas alguns fatos para registros, como no
exemplo acima. A vantagem é realizada como mais fatos são registrados, uma vez que o
tamanho dos arquivos de normalização aumenta em um modo de soma, em quanto o
tamanho de um arquivo de desnormalização aumenta em um modo de multiplicação.
Por exemplo, se nós adicionarmos um agente que vende x produtos para y companias,
onde cada uma destas companias faz cada um destes produtos, nós temos adicionado x
+ y novos registros para a forma normalizada, mas x . y novos registros para um
formulário desnormalizado.
Note-se também que todos os três tipos de registros são necessários no
formulário normalizado, a fim de reconstruir as mesmas informações.Desde o primeiro
registro dois tipos apresentados acima nos ensinam que Jones representa Ford e que
Ford faz caminhões. Mas nós não podemos determinar se Jones vende caminhões Ford
até nós olharmos para o terceiro tipo de registro se Jones vende em todos os caminhões.
O exemplo a seguir ilustra um caso em que a regra sobre agentes, empresas, e
produtos está satisfeito, e que claramente exige que todos os três tipos de registro na
forma normalizada. Qualquer dos dois tipos de registro tomadas isoladamente implica
algo falso.

Observe que:

- Jones vende cartões e GM constrói carros, mas Jones não representa GM.
- Brown representa Ford e Ford constrói caminhões, mas Brown não vende
caminhões.
- Brown representa Ford e Brown vende autocarros, mas Ford não faz
autocarros.
Quarta e quinta formas normais as duas lidam com ambos conjuntos de fatos
multivalorados. Uma diferença é que os fatos abordados no âmbito da quinta forma
normal não são independentes, no sentido discutido anteriormente. Outra diferença é
que, apesar de quarta forma normal pode esta de acordo com mais que dois fatos
multivalorados, ele só reconhecido em grupos pairwise(não achei tradução). Nós
podemos explicar melhor isso nos termos da normalização do processo que implica na
quarta forma normal. Se um registro viola quarta forma normal, associado a
normalização de processo decompõe em dois registros, cada um contendo menos
campos que o registro original.
Se um registro viola a quarta forma normal o processo de normalizaçao
assossiado o decompoe em outros dois registros, cada um com alguns dos campos do
registro original. Qualquer violaçao a quarta forma normal é tratada recursivamente até
que os registros resultantes estejam na quarta forma normal. Em cada etapa o conjunto
de registros obtidos contem exatamente a mesma informaçao que o registro original
antes da normalizaçao.
No exemplo estudado nao é possivel uma decomposiçao. Nao existe uma
combinaçao de registros em pares que contenham a mesma informaçao que o registro
original. Todos os três registros menores sao necessarios. Portanto, uma divisão em par
para preservaçao da informaçao nao é possivel, e o registro original nao esta violando a
quarta forma normal. A quinta forma normal se faz necessária nesta caso para tratar a
redundancia.

5 REDUNDÂNCIAS INEVITÁVEIS
A normalizaçao certamente não remove todas redundancias. Certas redundancias
parecem ser inevitaveis, particularmente quando varios fatos multi valorados são
dependentes e independentes.
6 REDUNDÂNCIA INTER REGISTROS
A forma normal discute, aqui, sobre lidar com redundâncias ocorrendo entre
registros do mesmo tipo. A quinta forma normal é considerada como a ultima forma
normal que trata tal redundancia[6].
Outras redundancias podem ocorrer em registros multi tipados. No exemplo
sobre empregados, departamentos, e localizaçao, o seguinte registro encontra-se na
terceira forma normal nao levando em conta a redundancia obvia.

Na verdade, duas copias do mesmo tipo de registro constrituem o ultimo neste

tipo de redundancia. Redundancia inter registro tem sido reconhecida a algum tempo, e
recentemente foi catalogada em termos da forma normal e na normalizaçao[8].

7 CONCLUSÃO
Mesmo tendo mostrado a forma normal de uma maneira simples e
compreencivel, nao estamos de forma alguma sugerindo que o processo de designe dos
dados e simples. O processo de designe envolve muita complexidade que esta alem do
escopo deste trabalho. Em primeiro lugar, um conjunto inicial de dados e registros
devem ser desenvolvidos para serem candidatos a normalizaçao. Entao os passos da
normalizaçao devem ser aplicados:
- valor simples vs. fatos multi valorados
- dependencia na chave inteira
- independencia vs. fatos dependentes
- a presença de constantes mutuas
- a presença de representaçoes nao unicas ou nao singulares