16 - Capítulo 11 - Normalização Avançada 1 1FN, 2FN, 3FN, FNBC

CAPITULO 11
Normalizao avanada 1:
1FN, 2FN, 3FN, FNBC
11.1 INTRODUO
Em todo este livro, at agora, fizemos uso do banco de dados
de fornecedores e peas como exemplo continuado, com o
seguinte projeto lgico (em linhas gerais):
F { F#, FNOME, STATUS, CIDADE
PRIMARY KEY { F# }
P { P#, PNOME, COR, PESO, CIDADE
PRIMARY KEY { P# }
FP { F#, P#, QDE }
PRIMARY KEY { F#, P# 1
FOREIGN KEY { F# 1 REFERENCES F
FOREIGN KEY { P# } REFERENCES P
Esse projeto transmite um sentimento de correo: bvio
que trs variveis de relaes F, P e FP so necessrias;
tambm bvio que o atributo CIDADE de fornecedor pertence
varivel de relao F, o atributo COR de pea pertence
varivel de relao P, o atributo QDE de remessa pertence
varivel de relao FP, e assim por diante. Porm, o que tudo
isso nos diz? Algum discernimento sobre essa questo pode ser
obtido observando-se o que acontecer se o projeto for
alterado de algum modo. Por exemplo, suponha que o atributo
CIDADE de fornecedor seja deslocado da varivel de relao de
fornecedores para a varivel de relao de remessas
(intuitivamente, o lugar errado para ele, pois cidade de
fornecedor obviamente diz respeito a fornecedores, no a
remessas). A Figura 11.1, uma variao da Figura 10.1 do
Captulo 10, ilustra uma amostra de valores para essa
varivel de relao de remessas revisada. Nota: para evitar
confuso com nossa varivel de relao de remessas usual, FP,
chamaremos essa varivel de relao revisada de FCP, como
fizemos no Captulo 10.
Uma olhada na figura suficiente para mostrar imediatamente
o que est errado com esse projeto: a redundncia. Para
sermos especficos, toda tupla de FCP para o fornecedor F1
nos diz que Fi est localizado em Londres, toda tupla de FCP
para o fornecedor F2 nos diz que F2 est localizado em Paris,
e assim por diante. De modo mais geral, o fato de um dado
fornecedor estar localizado em uma de304 terminada cidade
enunciado tantas vezes quantas so as remessas para esse
fornecedor. Por sua vez,
essa redundncia leva a vrios outros problemas. Por exemplo,
depois de uma atualizao, o fornecedor Fi pode ser mostrado
como localizado em Londres de acordo com uma tupla e em
Amsterd de acordo com outra.* Assim, talvez um bom princpio
de projeto seja um fato em um lugar (isto , evitar
redundncia). O assunto de normalizao avanada , em
essncia, apenas uma formalizao de idias simples como essa
contudo, uma formalizao que tem grande aplicao prtica
no problema do projeto de bancos de dados.
FC P
Formas normais
FIGURA 1 1.1 Amostra de valores para a varivel de varivel
de relao FCP
Naturalmente, relaes sempre esto normalizadas, no que se
refere ao modelo relaciona!, como vimos no Captulo 5. No
caso das variveis de relaes podemos dizer que elas tambm
so normalizadas, pois seus valores vlidos so relaes
normalizadas; portanto, as variveis de relaes tambm so
sempre normalizadas, no que se refere ao modelo relaciona!.
De modo equivalente, podemos dizer que as variveis de
relaes (e as relaes) esto sempre na primeira forma
normal (abreviada como 1FN). Em outras palavras,
normalizada e na 1FN significam exatamente a mesma coisa
embora voc deva estar ciente de que o termo normalizada
usado com frequncia para indicar um dos nveis mais altos
de normalizao (em gera!, a terceira forma normal, 3FN);
esse ltimo modo de utilizao inadequado, mas muito comum.
Uma determinada varivel de relao poderia estar normalizada
no sentido anterior e ainda possuir certas propriedade no
desejveis; a varivel de relao FCP da Figura 11.1 um
exemplo. Os princpios de normalizao avanada nos permitem
reconhecer esses casos e substituir essas variveis de
relaes por outras mais desejveis de algum modo. Por
exemplo, no caso da varivel de relao FCP esses princpios
nos informariam exatamente o que est errado com essa
varivel de relao, e nos diriam como substitu-la por duas
variveis de relaes mais desejveis, uma com o cabealho
{F#,CIDADE} e outra com o cabealho {F#,P#,QDE}.
O processo de normalizao avanada de agora em diante
abreviado apenas como normalizao elaborado em torno do
conceito de formas normais. Dizemos que uma varivel de
relao est em uma
*Em todo este captulo e no seguinte necessrio supor (de
forma mais realista!) que os predicados de variveis de
relaes no esto sendo totalmente impostos pois, se
fossem, problemas como esse possivelmente no surgiriam (no
seria possvel atualizar a cidade para o fornecedor FI em
algumas tuplas e no em outras). De fato, um modo de pensar
sobre a disciplina de normalizao o seguinte: ela nos
ajuda a estruturar o banco de dados de modo a tornar mais
aceitveis logicamente as atualizaes de uma nica tupla do
que ocorreria em caso contrrio (ou seja, se o projeto no
estivesse completamente normalizado). Essa meta alcanada
porque os predicados de variveis de relaes so mais
simples em um projeto completamente normalizado.
305
F# CIDADE P# QDE
Fi Londres P1 300
Fi Londres P2 200
El Londres P3 400
El Londres P4 200
Fi Londres P5 100
Fi Londres P6 100
F2 Paris P1 300
F2 Paris P2 400
F3 Paris P2 200
F4 Londres P2 200
F4 Londres P4 300
que ainda no estamos em condies de apresentar uma
considerao detalhada. Vamos nos contentar com a declarao
bastante equivocada de que existem de fato formas normais
avanadas no mostradas na Figura 11.2, mas a SFN a forma
normal final em um sentido especial (mas importante).
Voltaremos a essa questo no Capitulo 12.
Estrutura do captulo
o objetivo deste capitulo examinar os conceitos de
normalizao avanada, at e inclusive a forma normal de
Boyce/Codd (deixamos as outras duas para o Capitulo 12). O
plano do captulo dado a seguir. Aps esta introduo um
tanto longa, a Seo 1 1 .2 discute o conceito bsico de
decomposio sem perdas e demonstra a importncia crucial de
dependncia funcional para esse conceito (na verdade, a
dependncia funcional constitui a base para as trs formas
normais originais de Codd e para a FNBC). A Seo 1 1 .3
descreve ento as trs formas normais originais, mostrando
por exemplo como uma dada varivel de relao pode ser
conduzida pelo procedimento de normalizao para chegar
3FN. A Seo 1 1 .4 faz uma pequena digresso para considerar
a questo de decomposies alternativas isto , a questo
de es- colher a melhor decomposio de uma varivel de
relao dada, quando h escolha. Em seguida, a Se- o 1 1 .5
discute a FNBC. Concluindo, a Seo 1 1.6 fornece um resumo e
apresenta algumas observaes finais.
Voc deve estar ciente de que no procuramos ser muito
rigorosos no texto que se segue; em vez disso, nos baseamos
em grande parte na simples intuio. De fato, observamos que
conceitos como decomposio sem perdas, FNBC etc., apesar
da terminologia um tanto esotrica, so idias muito simples
e de bom senso. Muitas das referncias tratam o material de
uma maneira muito mais formal e rigorosa. Um bom tutorial
pode ser encontrado na referncia [11.5].
Duas observaes introdutrias complementares:
1. Como j sugerimos, a idia geral de normalizao que o
projetista do banco de dados deve almejar ter variveis de
relaes em forma normal final (5FN). Porm, essa
recomendao no deve ser tomada como lei. Ocasionalmente
muito ocasionalmente! podem existir boas razes para
desafiar os princpios de normalizao (consulte o Exerccio
11.7, no final deste captulo). Na verdade, este um lugar
to bom quanto qualquer outro para se dizer que o projeto de
bancos de dados pode ser uma tarefa extremamente complexa
(pelo menos em um ambiente de grande banco de dados; o
projeto de um pequeno banco de dados de modo geral
comparativamente mais simples). A normalizao um apoio
til no processo, mas no uma panacia; quem quiser
projetar um banco de dados certamente deve estar
familiarizado com os princpios bsicos de normalizao, mas
ns no pretendemos sugerir que o projeto deva
necessariamente basear-se apenas nesses princpios. O
Captulo 13, discute vrios outros aspectos do projeto que
tm pouca ou nenhuma relao com a normalizao em si.
2. Como indicamos antes, usaremos o procedimento de
normalizao como base para introduzir e discutir as vrias
formas normais. Porm, no queremos sugerir que na prtica o
projeto de bancos de dados seja realizado pela aplicao
desse procedimento; na verdade, provvel que no muito
mais provvel que algum esquema top-down, como o que
descrevemos no Captulo 13, seja utilizado. As idias de
normalizao podem ento ser usadas para verificar que o
projeto resultante no viola de forma inadvertida quaisquer
dos princpios de normalizao. Apesar disso, o procedimento
de normalizao fornece um apoio conveniente na descrio
desses princpios; portanto, para as finalidades deste
captulo, adotaremos a hiptese til de que estamos de fato
executando o processo de projeto pela aplicao desse
procedimento.
11.2 DECOMPOSIO SEM PERDAS E DEPENDNCIAS FUNCIONAIS
Antes de chegar aos detalhes especficos do procedimento de
normalizao, precisamos examinar mais de perto um aspecto
crucial desse procedimento, ou seja, o conceito de
decomposio sem perdas. Vimos que o procedimento de
normalizao envolve a quebra ou decomposio de uma
determinada vari- 307
vel de relao em outras variveis de relaes, e tambm que
a decomposio tem de ser reversvel, de modo que nenhuma
informao seja perdida no processo; em outras palavras, as
nicas decomposies em que estamos interessados so aquelas
de fato sem perdas. Como veremos, a questo de saber se uma
determinada decomposio ou no sem perdas est intimamente
ligada ao conceito de dependncia funcional.
A ttulo de exemplo, considere a j familiar varivel de
relao F de fornecedores, com o cabealho {F#,STATUS,CIDADE}
(ignoramos o atributo FNOME por simplicidade). A Figura 11.3
ilustra uma amostra de valores dessa varivel de relao e
nas partes da figura identificadas como (a) e (b) duas
decomposies possveis que correspondem a essa amostra de
valores.
Examinando essas duas decomposies, observamos que:
1. No caso (a), nenhuma informao perdida; os valores de
FFT e FC ainda nos informam que o fornecedor F3 tem o status
30 e a cidade Paris, e que o fornecedor F5 tem o status 30 e
a cidade Atenas. Em outras palavras, essa primeira
decomposio de fato sem perdas.
2. No caso (b), ao contrrio, a informao definitivamente
perdida; ainda podemos dizer que os dois fornecedores tm
status 30, mas no podemos saber qual fornecedor tem qual
cidade. Em outras palavras, a segunda decomposio no sem
perdas, mas sim h perdas.
F
(a) FST F# STATUS FC F# CIDADE
F3 30 F3 Paris
F5 30 F5 Atenas
(b) FST STATUS STC
FIGURA 11.3 Amostra de valores para a varivel de relao F e
duas
decomposies correspondentes
O que exatamente que torna a primeira decomposio sem
perdas e a outra com perdas? Bem, primeiro observe que o
processo ao qual estamos nos referindo como decomposio
na verdade um processo de projeo; FFT, FC e STC na figura
so projees da varivel de relao F original. Assim, o
operador de decomposio no procedimento de normalizao na
verdade o de projeo. Nota: como na Parte II deste livro,
dizemos com frequncia algo como FFT uma projeo da
varivel de relao F, quando o que deveramos dizer mais
corretamente seria FFT uma varivel de relao cujo valor
em qualquer instante dado uma projeo da relao que o
valor da varivel de relao F nesse instante. Esperamos que
essas abreviaes no causem qualquer confuso.
Observe em seguida que, quando dizemos no caso (a) que
nenhuma informao perdida, o que realmente queremos dizer
que se juntarmos FFT e FC de novo, teremos de volta a
varivel de relao F ori308 gc Em contraste, no caso (b), se
juntarmos FFT e FC novamente, no obteremos de volta a
varivel de
F# STATUS CIDADE
F3 30 Paris
F5 30 Atenas
STATUS CIDADE
30 Paris
30 Atenas
relao original F e, portanto, teremos perda de
informaes.* Em outras palavras, reversibilidade significa
exatamente que a varivel de relao original seja igual
juno de suas projees. Assim, exatamente como o operador
de decomposio para fins de normalizao a projeo, o
operador de recomposio a juno.
Assim, a questo interessante a seguinte: se Ri e R2 so
projees de alguma varivel de relao R, e se Ri e R2 em
conjunto incluem todos os atributos de R, que condies devem
ser satisfeitas para garantir que a juno de Ri e R2 nos
dar de volta a varivel de relao original R? E aqui que
entram as dependncias funcionais. Voltando ao nosso
exemplo, observe que a varivel de relao F satisfaz ao
conjunto irredutvel de DFs:
F# > STATUS
F# > CIDADE
Tendo em vista que ela satisfaz a essas DFs, certamente no
pode ser coincidncia que a varivel de relao F seja igual
juno de suas projees sobre {F#,STATUS} e {F#,CIDADE}. E
naturalmente no . Na verdade, temos o seguinte teorema
(devido a Heath [11.4] ):
. Teorema de Heath: seja R{A,B,C} uma varivel de relao,
onde A, B, e C so conjuntos de atributos. Se R satisfaz
DFA * B, ento R igual juno de suas projees sobre
{A,B} e {A,C}.
Tomando-se A como F#, B como STATUS e C como CIDADE, esse
teorema confirma o que j observamos, ou seja, que a varivel
de relao F pode ser decomposta sem perdas em suas projees
sobre
{F#,STATUS} e {F#,CIDADE}.
Ao mesmo tempo, sabemos tambm que F no pode ser decomposta
sem perdas em suas projees sobre {F#,STATUS} e
{STATUS,CIDADE}. O teorema de Heath no explica porque isso
acontece;** porm, intuitivamente, podemos ver que o problema
que uma das DFs se perdeu nessa ltima decomposio.
Especificamente, a DF F# > STATUS ainda representada pela
projeo sobre {F#,STATUS}, mas a DF F# * CIDADE se perdeu.
Mais sobre dependncias funcionais
Conclumos esta seo com algumas observaes adicionais
sobre DFs.
1. DFs irredutveis esquerda: vimos no Captulo 10, que uma
DF dita irredutvel esquerda se o seu lado esquerdo no
grande demais. Por exemplo, considere a varivel de relao
FCP da Seo
11.1. Essa varivel de relao satisfaz DF:
F#, P# } -* CIDADE
Contudo, o atributo P# do lado esquerdo redundante para
fins de dependncia funcional; ou seja,
tambm temos a DF:
F# * CIDADE
(isto , CIDADE tambm funcionalmente dependente de F#
sozinho). Essa ltima DF irredutvel esquerda, mas a
anterior no ; de modo equivalente, CIDADE
irredutivelmente dependente de F#, mas no irredutivelmente
dependente de {F#,P#}.***
* Mais precisamente, teremos de volta todas as tuplas na
varivel de relao F original, junto com algumas tuplas
esprias adicionais; nunca obteremos de volta algo menos do
que a varivel de relao F original. (Exerccio: demonstre
essa afirmao.) Como em geral no temos meios de saber quais
tuplas so esprias e quais so genunas, na verdade perdemos
informaes.
* * Isso no ocorre porque ela da forma se ento ... e
no se e somente se ... ento ... (veja o Exerccio 11.1 no
final do captulo). Discutiremos uma forma mais forte do
teorema de Heath no prximo captulo (Seo 12.2).
DF irredutvel esquerda e irredutivelmente dependente
so nossos termos preferidos para indicar aquilo que se
costuma chamar DF completa e completamente dependente na
literatura (e tambm nas primeiras edies deste livro).
Esses ltimos termos tm o mrito da brevidade, mas so menos
descritivos e menos adequados. 309
DFs irredutveis esquerda e dependncias irredutveis se
mostraro importantes na definio da segunda e da terceira
forma normais (consulte a Seo 11.3).
2. Diagramas DF: seja R uma varivel de relao e seja 1
algum conjunto irredutvel de DFs que se aplicam a R (de
novo, consulte o Captulo 10, se precisar refrescar sua
memria em relao a conjuntos irredutveis de DFs). E
conveniente representar o conjunto 1 por meio de um diagrama
de dependncias funcionais (diagrama DF). Os diagramas DF
para as variveis de relaes F, FP e P que devem ser
auto-explicativos so dados na Figura 1 1 .4. Faremos uso
frequente desses diagramas em todo o restante deste captulo.
_1L PNOME
ENOME r-ii ________ . COR
:::::: QDE LEI PESO
f__CIDADE
F 1 G U R A 1 1 . 4 Diagramas DF para as variveis de
relaes F, FP e P
Como voc pode ver, toda seta nos diagramas da Figura 11.4
uma seta para fora de uma chave candidata (na verdade, a
chave primria) da varivel de relao relevante. Por
definio, sempre existiro setas para fora de cada chave
candidata* porque, para um valor de cada chave candidata,
sempre haver um valor de todo o restante; essas setas nunca
podem ser eliminadas. As dificuldades surgem se h quaisquer
outras setas. Assim, o procedimento de normalizao pode ser
caracterizado, muito informalmente, como um procedimento para
eliminar setas que no so setas saindo de chaves candidatas.
3. DFs so uma noo semntica: naturalmente, as DFs so um
tipo especial de restrio de integridade. Como tais, so
definitivamente uma noo semntica. Reconhecer as DFs
parte do processo de entender o que significam os dados; o
fato de a varivel de relao F satisfazer DF F# * CIDADE,
por exemplo, significa que cada fornecedor est localizado em
exatamente uma cidade. Em outras palavras:
- H uma restrio no mundo real que o banco de dados
representa, ou seja, a de que cada fornecedor est localizado
em exatamente uma cidade.
- Como parte da semntica da situao, essa restrio
precisa de algum modo ser observada no banco de dados.
- A maneira de garantir que ela ser observada especific-
la na definio do banco de dados, de modo que o SGBD possa
impor a restrio.
- O modo de especific-la na definio do banco de dados
declarar a DF.
Veremos mais adiante que os conceitos de normalizao
conduzem a um meio muito simples para se declarar DFs.
Mais exatamente, sempre haver setas saindo de superchaves.
Contudo, se o conjunto de DFs for irredutvel como declarado,
310 todas as DFs (ou setas) sero irredutveis esquerda.
11.3 PRIMEIRA, SEGUNDA E TERCEIRA FORMAS NORMAIS
Cuidado: em toda esta seo, supomos por simplicidade que
cada varivel de relao tem exatamente uma chave candidata,
que consideraremos como sendo a chave primria. Essa hiptese
se reflete em nossas definies, que (repetimos) no so
muito rigorosas. O caso de uma varivel de relao que tem
mais
de uma chave candidata discutido na Seo 11.5.
Agora, podemos descrever as trs formas normais originais de
Codd. Apresentamos primeiro uma definio preliminar muito
informal da 3FN, a fim de dar alguma idia do ponto que
desejamos atingir.
Depois, consideramos o processo de reduzir uma varivel de
relao arbitrria a uma coleo equivalente de variveis de
relaes em 3FN, apresentando pelo caminho definies um
pouco mais precisas das trs
formas. Porm, notamos de incio que 1FN, 2FN e 3FN no so,
por si prprias, muito significativas, exceto como degraus
para FNBC (e alm).
Ento, aqui temos nossa definio preliminar de 3FN:
. Terceira forma normal (definio muito informal): uma
varivel de relao est em 3FN se e somente se os atributos
no-chaves (se existem) so:
(a) Mutuamente independentes.
(b) Irredutivelmente dependentes da chave primria.
Explicamos as expresses atributo no-chave e mutuamente
independentes como a seguir:
. Um atributo no-chave qualquer atributo que no participa
da chave primria da varivel de relao considerada.
. Dois ou mais atributos so mutuamente independentes se
nenhum deles funcionalmente dependente de qualquer
combinao dos outros. Tal independncia implica que cada um
desses atributos pode ser atualizado independentemente dos
demais.
Por exemplo, a varivel de relao de peas P est em 3FN, de
acordo com a definio anterior: os atributos PNOME, COR,
PESO e CIDADE so todos independentes uns dos outros (
possvel mudar, por exemplo, a cor de uma pea sem ter de
mudar ao mesmo tempo seu peso) e todos eles so
irredutivelmente dependentes da chave primria {P#}.
A definio informal precedente de 3FN pode ser interpretada
de forma ainda mais intuitiva, assim:
- Terceira forma normal (definio ainda mais informal): uma
varivel de relao est em terceira forma normal (3FN) se e
somente se, por todo o tempo, cada tupla consiste em um valor
de uma chave primria que identifica alguma entidade,
acompanhado por um conjunto de zero ou mais valores de
atributos mutuamente independentes que descrevem de algum
modo essa entidade.
De novo, a varivel de relao P se enquadra na definio:
cada tupla de P consiste em um valor de chave primria (um
nmero de pea) que identifica alguma pea no mundo real,
junto com quatro valores adicionais (nome de pea, cor de
pea, peso de pea e cidade de pea), cada um dos quais serve
para descrever essa pea, e sendo cada um independente de
todos os restantes.
Vamos examinar agora o procedimento de normalizao.
Comeamos por uma definio da primeira forma normal.
- Primeira forma normal: uma varivel de relao est em 1FN
se e somente se, em todo valor vlido dessa varivel de
relao, cada tupla contm exatamente um valor para cada
atributo.
Essa definio diz apenas que qualquer varivel de relao
est sempre em 1FN, o que naturalmente est correto. Porm,
uma varivel de relao que est somente em primeira forma
normal (isto , uma varivel de relao 1FN, que no est em
2FN, e portanto tambm no est em 3FN) tem uma estrutura
indesejvel por uma srie de razes. Para ilustrar esse
ponto, vamos supor que as informaes referentes a
fornecedores e remessas, em vez de serem divididas em duas
variveis de relaes F e FP, estejam reunidas em uma nica
varivel de relao, como esta:
PRIMEIRA { F#, STATUS, CIDADE, P#, QDE
PRIMARY KEY { F#, P# } 311
Essa uma verso estendida da varivel de relao FCP da
Seo 11.1. Os atributos tm seus signifi- cados usuais mas,
para fins deste exemplo, introduzimos uma restrio
adicional:
CIDADE * STATUS
(STATUS funcionalmente dependente de CIDADE; o significado
dessa restrio que o status de um fornecedor determinado
pelo local desse fornecedor por exemplo, todos os
fornecedores de Londres precisam ter status igual a 20).
Tambm por simplicidade, ignoramos o atributo FNOME. A chave
primria de PRIMEIRA a combinao {F#,P#}; o diagrama DF
mostrado na Figura 11.5.
Observe que, em termos informais, esse diagrama DF mais
complexo que o diagrama DF para uma varivel de relao 3FN.
Como sugerimos na seo anterior, um diagrama 3FN tem setas
saindo somente de chaves candidatas, enquanto um diagrama no
3FN (tal como o diagrama para PRIMEIRA) tem setas saindo de
chaves candidatas juntamente com certas setas adicionais e
so essas setas adicionais que causam toda a dificuldade. De
fato, a varivel de relao PRIMEIRA viola ambas as condies
a. e b. na definio de 3FN anterior: os atributos no-chave
no so todos mutuamente independentes, porque STATUS depende
de CIDADE (uma seta adicional) e no so irredutivelmente
dependentes da chave primria, porque STATUS e CIDADE so
cada um dependente de F# sozinho (duas setas adicionais).
Como base para ilustrar algumas das dificuldades que surgem
dessas setas adicionais, a Figura 11.6 mostra um exemplo de
valores para a varivel de relao PRIMEIRA. Os valores de
atributos so basicamente os de costume, exceto pelo fato de
que o status do fornecedor F3 foi alterado de 30 para 10, a
fim de manter a coerncia com a nova restrio de que CIDADE
determina STATUS. As redundncias so evidentes. Por exemplo,
toda tupla para o fornecedor F1 mostra a CIDADE como Londres;
da mesma forma, toda tupla para a cidade Londres mostra o
STATUS como 20.
PRIMEIRA
CIDADE
fATUS
FIGURA 11.5 DFs para a varivel de relao PRIMEIRA
312 FIGURA 11.6 Amostra de valores para a varivel de relao
PRIMEIRA
F# STATUS CIDADE P# QDE
Fi 20 Londres P1 300
F1 20 Londres P6 100
F2 10 Paris P1 300
F2 10 Paris P2 400
F3 10 Paris P2 200
As redundncias na varivel de relao PRIMEIRA levam a
variedade daquelas que, por razes histricas, se costuma
chamar de anomalias de atualizao isto , dificuldades com
as operaes de atualizao INSERT, DELETE e UPDATE. Para
fixar nossas idias, vamos nos concentrar primeiro na
redundncia de fornecedor-cidade, correspondendo DF F# *
CIDADE. Ocorrem problemas com cada uma das trs operaes.
. INSERT: no podemos inserir o fato de que um determinado
fornecedor est localizado em uma cidade em particular at
que esse fornecedor fornea pelo menos uma pea. De fato, a
Figura 11.6 no mostra que o fornecedor F5 est localizado em
Atenas. A razo que, at FS fome- cer alguma pea, no
temos nenhum valor apropriado para a chave primria. (Estamos
supondo em todo este captulo, como fizemos no Captulo 9,
Seo 9.4 de forma bastante razovel que os atributos da
chave primria no tm nenhum valor default. Consulte o
Captulo 18.)
. DELETE: se eliminarmos a nica tupla de PRIMEIRA para um
determinado fornecedor, eliminaremos no apenas a remessa que
liga esse fornecedor a alguma pea, mas tambm a informa- o
de que o fornecedor est localizado em uma determinada
cidade. Por exemplo, se eliminarmos a tupla de PRIMEIRA com o
valor F3 em F# e o valor P2 em P#, perderemos a informao de
que F3 est localizado em Paris. (Os problemas de INSERT e
DELETE so na realidade duas faces da mesma moeda.)
Nota: o problema real aqui que a varivel de relao
PRIMEIRA contm informaes demais e muito amontoadas; por
isso, quando eliminamos uma tupla, eliminamos em excesso.
Para sermos mais precisos, a varivel de relao PRIMEIRA
contm informaes quanto a remessas e informaes relativas
a fornecedores; desse modo, a eliminao de uma remessa faz
com que informaes sobre fornecedores tambm sejam
eliminadas. A soluo desse problema, naturalmente,
desempacotar ou seja, inserir as informaes sobre
remessas em uma varivel de relao e as informaes sobre
fornecedores em outra (e isso exatamente o que faremos em
breve). Assim, outro modo informal de caracterizar o
procedimento de normalizao descrev-lo como um
procedimento de desempacotamento: inserir informaes
logicamente isoladas em variveis de relaes separadas.
- UPDATE: o valor cidade de um determinado fornecedor aparece
vrias vezes em PRIMEIRA, em geral. Essa redundncia gera
problemas de atualizao. Por exemplo, se o fornecedor Fi se
mudar de Londres para Amsterd, teremos de enfrentar o
problema de pesquisar PRIMEIRA para encontrar cada tupla que
conecta F 1 e Londres (e alter-la) ou a possibilidade de
produzir um resultado incoerente (a cidade para Fi pode
receber Amsterd em uma tupla e Londres em outra).
A soluo para esses problemas, como j sugerimos,
substituir a varivel de relao PRIMEIRA pelas duas
variveis de relaes:
SEGUNDA { F#, STATUS, CIDADE
e
FP { F#, P#, QDE }
Os diagramas DF para essas duas variveis de relaes so
dados na Figura 11.7; a Figura 11.8 apresenta uma amostra de
valores. Observe que as informaes correspondentes ao
fornecedor F5 agora foram includas (na varivel de relao
SEGUNDA, mas no na varivel de relao FP). Na realidade, a
varivel de relao FP agora exatamente nossa varivel de
relao de remessa usual.
313
FIGURA 11.7 DFs para as variveis de relaes SEGUNDA e FP
F 1 G U RA 1 1 . 8 Amostras de valores para as variveis de
relaes SEGUNDA e FP
Deve ficar claro que essa estrutura revisada resolve todos os
problemas com operaes de atualiza- o esboados antes:
. INSERT: podemos inserir a informao de que F5 est
localizado em Atenas, embora F5 no fornea nenhuma pea no
momento, simplesmente inserindo a tupla apropriada em
SEGUNDA.
. DELETE: podemos eliminar a remessa unindo F3 e P2,
eliminando a tupla apropriada de FP; no perderemos a
informao de que P3 est localizado em Paris.
. UPDATE: na estrutura revista, a cidade para um determinado
fornecedor aparece uma vez, no vrias vezes, porque h
exatamente uma tupla para um certo fornecedor na varivel de
relao SEGUNDA (a chave primria para essa varivel de
relao {F#}); em outra palavras, a redundncia de F#-
CIDADE foi eliminada. Assim, podemos alterar a cidade para Fi
de Londres para Amsterd, alterando-a de uma vez por todas na
tupla relevante de SEGUNDA.
Comparando as Figuras 11.7 e 11.5, vemos que o efeito da
decomposio de PRIMEIRA em SEGUNDA e FP foi eliminar as
dependncias que no eram irredutveis, e foi essa eliminao
que resolveu as dificuldades. Intuitivamente, podemos dizer
que na varivel de relao PRIMEIRA, o atributo CIDADE no
descrevia a entidade identificada pela chave primria, ou
seja, uma remessa; em vez disso, ele descrevia o fornecedor
envolvido nessa remessa (e, da mesma forma, o atributo
STATUS, claro). Misturar as duas espcies de informaes na
mesma varivel de relao foi o que gerou os problemas.
Damos agora uma definio da segunda forma normal:*
Estritamente falando, a 2FN pode ser definida apenas com
respeito a um conjunto especificado de dependncias, mas
usual ignorar esse ponto em contextos informais. Observaes
anlogas se aplicam a todas as formas normais (com exceo da
primeira,
314 claro).
CIDADE
EEI
SEGUNDA
FP F# P#
Fi P1
El P2
El P3
El P4
F1 P5
Fi P6
F2 P1
F2 P2
F3 P2
F4 P2
F4 P4
F4 P5
F# STATUS CIDADE
Fi
F2
F3
F4
F5
20
10
10
20
30
Londres
Paris
Paris
Londres
Atenas
. Segunda forma normal (definio supondo apenas uma chave
candidata, que consideraremos a chave primria): uma varivel
de relao est em 2FN se e somente se ela est em 1FN e todo
atributo no-chave irredutivelmente dependente da chave
primria.
As variveis de relaes SEGUNDA e FP esto ambas em 2FN (as
chaves primrias so F# e a combinao {F#,P#},
respectivamente). A varivel de relao PRIMEIRA no est em
2FN. Uma varivel de relao que est em primeira forma
normal, mas no em segunda, sempre pode ser reduzida a uma
cole- o equivalente de variveis de relaes 2FN. O
processo de reduo consiste em substituir a varivel de
relao 1FN por projees convenientes; a coleo de
projees assim obtida equivalente varivel de relao
original, no sentido de que a varivel de relao original
pode ser recuperada unindo-se de novo essas projees. Em
nosso exemplo, SEGUNDA e FP so projees de PRIMEIRA,* e
PRIMEIRA a juno de SEGUNDA e FP sobre F#.
Para resumir, o primeiro passo no procedimento de
normalizao o de tomar projees a fim de eliminar
dependncias funcionais no irredutveis. Assim, dada uma
varivel de relao R como esta:
R { A, 8, C, D
PRIMARY KEY { A, B }
1* supondo que A D vlida */
a disciplina de normalizao recomenda substituir R por suas
duas projees Ri e R2, como segue:
Ri { A, D
PRIMARY KEY { A }
R2 { A, 8, C
PRIMARY KEY { A, B
FOREIGN KEY { A } REFERENCES Ri
A varivel de relao R pode ser recuperada tomando-se a
juno de chave estrangeira para chave primria
correspondente de R2 e Ri.
Voltando ao exemplo: a estrutura SEGUNDA-FP ainda causa
problemas. A varivel de relao FP satisfatria; na
verdade, a varivel de relao FP est agora em 3FN e vamos
ignor-la no restante desta seo. Por outro lado, a varivel
de relao SEGUNDA ainda sofre pela falta de independncia
mtua entre seus atributos no-chaves. O diagrama DF para
SEGUNDA ainda mais complexo que um diagrama 3FN. Para
sermos especficos, a dependncia de STATUS sobre F#, embora
seja funcional e de fato irredutvel, transitiva (atravs
de CIDADE): cada valor de F# determina um valor de CIDADE, e
esse valor de CIDADE por sua vez determina o valor de STATUS.
De modo mais geral, sempre que as DFsA
> B e B + C so ambas vlidas, ento uma consequncia
lgica que a DF transitiva A * C tambm seja vlida, como
explicamos no Captulo 10. Alm disso, dependncias
transitivas levam mais uma vez a anomalias de atualizao.
(Agora, vamos nos concentrar na redundncia de cidade-status,
correspondendo DF CIDADE STATUS.)
- INSERT: no podemos inserir o fato de uma determinada
cidade ter um certo status por exemplo, no podemos
declarar que qualquer fornecedor em Roma deve ter status 50
at termos algum fornecedor realmente localizado nessa
cidade.
- DELETE: se eliminarmos a nica tupla de SEGUNDA para uma
determinada cidade, eliminaremos no apenas as informaes
para o fornecedor em questo, mas tambm a informao de que
essa cidade tem esse status em particular. Por exemplo, se
eliminarmos a tupla de SEGUNDA
* Exceto pelo fato de que SEGUNDA pode incluir tuplas, como a
tupla para o fornecedor F5 na Figura 11.8, que no tm
nenhurna contraparte em PRIMEIRA. Em outras palavras, a nova
estrutura pode representar informaes que no poderiam ser
representadas na anterior. Nesse sentido, a nova estrutura
pode ser considerada como representao ligeiramente mais
fiel do
mundo real. 315
para F5, perderemos a informao de que o status para Atenas
30. (Mais um vez, os problemas de INSERT e DELETE so na
realidade duas faces da mesma moeda.)
Nota: na verdade, mais uma vez o problema de empacotamento.
A varivel de relao SEGUNDA contm informaes relativas a
fornecedores e informaes relativas a cidades. E mais uma
vez a soluo desempacotar ou seja, inserir informaes
sobre fornecedores em uma varivel de relao e informaes
sobre cidades em outra.
- UPDATE: o status para uma dada cidade aparece muitas vezes
em SEGUNDA, em geral (a varivel de relao ainda contm
alguma redundncia). Assim, se precisarmos mudar o status
correspondente a Londres de 20 para 30, ficaremos diante do
problema de pesquisar em SEGUNDA, a fim de localizar cada
tupla para Londres (e alter-la) ou a possibilidade de
produzir um resultado incoerente (o status para Londres
poderia ser dado como 20 em uma tupla e 30 em outra).
Novamente, a soluo dos problemas substituir a varivel de
relao original (SEGUNDA, nesse caso) por duas projees, ou
seja, as projees:
FC { F#, CIDADE}
e
CS { CIDADE, STATUS
Os diagramas DF para essas duas variveis de relaes so
dados na Figura 11.9; a Figura 11.10 apresenta uma amostra de
valores. Observe que as informaes de status para Roma foram
includas na varivel de relao CS. A reduo novamente
reversvel, pois SEGUNDA a juno de FC e CS sobre CIDADE.
FIGURA 11.10 Amostra de valores para as variveis de relaes
FC e CS
Novamente, deve ficar claro que essa estrutura revisada
resolve todos os problemas com operaes de atualizao
esboadas antes. As consideraes detalhadas sobre esses
problemas ficam como exerccio. Comparando as Figuras 11.9 e
11.7, vemos que o efeito da nova decomposio eliminar a
dependncia transitiva de STATUS sobre F#, e mais uma vez foi
essa eliminao que resolveu os problemas. Intuitivamente,
podemos dizer que, na varivel de relao SEGUNDA, o atributo
STATUS no descrevia a entidade identificada pela chave
primria, ou seja, um fornecedor; em vez disso, ele descrevia
a cidade na qual esse fornecedor estava localizado. Mais uma
vez, misturar duas espcies de informaes na mes316 ma
varivel de relao foi o que causou os problemas.
CIDADE TATUS
FIGURA 11.9
DFs para as variveis de relaes FC e
CS
FC
F# CIDADE CS CIDADE
Fi Londres Atenas
F2 Paris Londres
F3 Paris Paris
F4 Londres
F5 Atenas
STATUS
30
20
10
Agora, fornecemos uma definio da terceira forma normal.
. Terceira forma normal (definio supondo apenas uma nica
chave candidata, que consideraremos como a chave primria):
uma varivel de relao est em 3FN se e somente se ela est
em 2FN e todo atributo no-chave dependente de forma no
transitiva da chave primria. Nota:
nenhuma dependncia transitiva implica nenhuma dependncia
mtua, no sentido desse termo explicado no incio desta
seo.
As variveis de relaes FC e CS esto ambas em 3FN (as
chaves primrias so F# e CIDADE, respectivamente). A
varivel de relao SEGUNDA no est em 3FN. Uma varivel de
relao que est em
2FN e no em terceira sempre pode ser reduzida a uma coleo
equivalente de variveis de relaes 3FN.
J indicamos que o processo reversvel e, portanto,
nenhuma informao perdida na reduo; porm,
a coleo 3FN pode conter informaes como o fato de que o
status para Roma 50, que no podia ser
representado na varivel de relao 2FN original.*
Para resumir, o segundo passo na normalizao tomar
projees para eliminar dependncias transitivas. Em outras
palavras, dada uma varivel de relao R como a seguinte:
R { A, B, C }
PRIMARY KEY { A }
1* supondo que 8 > C seja vlida */
a disciplina de normalizao recomenda substituir R por suas
duas projees Ri e R2, assim:
Ri { B, C
PRIMARY KEY { 8 }
R2 { A, B
PRIMARY KEY { A }
FOREIGN KEY { B } REFERENCES Ri
A varivel de relao R pode ser recuperada tomando-se a
juno de chave estrangeira para chave primria associada de
R2 e Ri.
Conclumos esta seo enfatizando que o nvel de normalizao
de uma varivel de relao dada uma questo de semntica,
no apenas uma questo de valores de dados que essa varivel
de relao possa conter em algum momento particular. No
possvel apenas olhar o valor de uma certa varivel de
relao em um dado momento e dizer se essa varivel de
relao est ou no (digamos) em 3FN tambm necessrio
saber o significado dos dados, isto , as dependncias, antes
de fazer tal julgamento. Observe ainda que, mesmo conhecendo
as dependncias, nunca possvel provar a partir do exame de
um determinado valor que uma varivel de relao est em
3FN. O melhor que pode ser feito mostrar que o valor em
questo no viola qualquer das dependncias; supondo-se que
no, ento o valor coerente com a hiptese de que a
varivel de relao est em 3FN, mas esse fato naturalmente
no garante que a hiptese seja vlida.
11.4 PRESERVAO DE DEPENDNCIAS
Durante o processo de reduo, frequentemente ocorre de uma
certa varivel de relao poder ser decomposta sem perdas, de
vrias maneiras diferentes. Considere mais uma vez a varivel
de relao SEGUNDA da Seo il.3, com as DFs F# * CIDADE e
CIDADE STATUS e, portanto, tambm (por transitividade) F#
* STATUS (ver Figura li. ii, em que a DF transitiva
mostrada como uma seta tra Isso resulta que, assim como a
combinao SEGUNDA-FP era uma representao do mundo real um
pouco melhor que a varivel de relao PRIMEIRA em 1FN,
tambm a combinao FC-CS uma representao ligeiramente
melhor que a varivel de
relao 2FN SEGUNDA. 317
cejada). Mostramos na Seo 11.3 que as anomalias de
atualizao encontradas com SEGUNDA poderiam ser resolvidas
substituindo-se essa varivel de relao por sua decomposio
em duas projees 3FN:
FC { F#, CIDADE
CS { CIDADE, STATUS
Vamos nos referir a essa decomposio como decomposio A.
Em contraste, aqui est uma decomposio alternativa
(decomposio B):
== FC { F#, CIDADE
FS { F#, STATUS
( a projeo FC a mesma em ambos os casos). A decomposio
B tambm sem perdas, e as duas projees esto novamente em
3FN. Porm, a decomposio B menos satisfatria que a
decomposio A, por vrias razes. Por exemplo, ainda no
possvel (em B) inserir a informao de que uma determinada
cidade tem um certo status, a menos que algum fornecedor
esteja localizado nessa cidade.
Vamos examinar esse exemplo um pouco mais de perto. Primeiro,
observe que as projees na decomposio A correspondem s
setas cheias na Figura 1 1 . 1 1 , enquanto uma das projees
na decomposio B corresponde seta tracejada. De fato, na
decomposio A, as duas projees so independentes uma da
outra, no seguinte sentido: podem ser feitas atualizaes em
uma delas sem se considerar a outra.* Desde que essa
atualizao seja vlida no contexto da projeo em questo
o que significa apenas que ela no deve violar a restrio de
unicidade da chave primria para essa projeo ento, a
juno das duas projees aps a atualizao sempre ser uma
SEGUNDA vlida (isto , a juno no ter a possibilidade
de violar as restries de DFs em SEGUNDA). Ao contrrio, na
decomposio B, atualizaes feitas em uma das duas projees
devem ser monitoradas para garantir que a DF CIDADE > STATUS
no ser violada (se dois fornecedores tiverem a mesma
cidade, ento eles devero ter o mesmo status; por exemplo,
considere o que acontece na decomposio B ao se mover o
fornecedor Fi de Londres para Paris). Em outras palavras, as
duas projees no so independentes uma da outra na
decomposio B.
o problema bsico que, na decomposio B, a DF CIDADE *
STATUS se torna para usar a terminologia do Captulo 8
uma restrio de banco de dados que abrange duas variveis de
relaes (implicando, a propsito, que em muitos produtos
atuais ela ter de ser mantida por cdigo procedural). Em
contraste, na decomposio A, a DF transitiva F# * STATUS
que se torna a restrio de banco de dados, e essa
restrio ser imposta de forma automtica se as duas
restries de varivel de relao F# * CIDADE e CIDADE *
STATUS forem impostas. Alm disso, a imposio dessas duas
ltimas restries naturalmente muito simples, envolvendo
nada mais que a imposio das restries correspondentes de
unicidade da chave primria.
O conceito de projees independentes fornece assim um fio
condutor para a escolha de uma decomposio particular quando
existe mais de uma possibilidade. Especificamente, uma
decomposio em que as projees so independentes no sentido
descrito , em geral, prefervel a uma na qual elas no o
so. Rissanen [11.6] mostra que as projees Ri e R2 de uma
varivel de relao R so independentes no sentido anterior,
se e somente se:
318 * Exceto no caso da restrio referencial de FC para CS,
claro.
CIDADE
STATii]
FIGURA 11.11 DFs para a varivel de relao SEGUNDA
FIGURA 1 1.12 DFs para a varivelde relao Fse {FNOME} uma
chave
candidata (e CIDADE * STATUS no vlida)
A varivel de relao F est em FNBC. Embora o diagrama DF
parea mais complexo que um diagrama para 3FN, ainda
ocorre que os nicos determinantes so chaves candidatas;
isto , as nicas setas so as que saem de chaves candidatas.
Ento, a mensagem desse primeiro exemplo apenas que ter
mais de uma chave candidata no algo necessariamente ruim.
(E claro que desejvel especificar ambas as chaves
candidatas na definio do banco de dados, de modo que o SGBD
possa impor ambas as restries de unicidade exigidas.)
Agora, apresentamos alguns exemplos nos quais as chaves
candidatas se superpem. Duas chaves candidatas se superpem
se elas envolvem dois ou mais atributos cada uma e tm pelo
menos um atributo em comum. Nota: de acordo com nossa
discusso sobre o assunto no Captulo 8, no tentaremos no
es- colher uma das chaves candidatas como chave primria nos
exemplos a seguir. Por isso, tambm no marcaremos quaisquer
colunas com sublinhado duplo em nossas figuras desta seo.
Como nosso primeiro exemplo, vamos supor novamente que os
nomes de fornecedores so exclusivos e vamos considerar a
varivel de relao:
FFP { F#, ENOME, P#, QDE }
As chaves candidatas so {F#,P#} e {FNOME,P#}. Essa varivel
de relao est em FNBC? A resposta no, porque ela contm
dois determinantes, F# e FNOME, que no so chaves candidatas
para a varivel de relao ({F#} e {FNOME} so ambas
determinantes porque cada uma determina a outra). Uma amostra
de valores para essa varivel de relao ilustrada na
Figura 11.13.
FIGURA 1 1 . 1 3 Amostra (parcial) de valores para a varivel
de relao FFP
Como mostra essa figura, a varivel de relao FFP envolve o
mesmo tipo de redundncias que as variveis de relaes
PRIMEIRA e SEGUNDA da Seo 1 1 .3 (e a varivel de relao
FCP da Seo 11.1), e portanto est sujeita ao mesmo tipo de
anomalias de atualizao. Por exemplo, a mudana do nome de
fornecedor de Smith para Robinson leva, mais uma vez, a
problemas de pesquisa ou a resultados possivelmente
inconsistentes. No entanto, a FFP est em 3FN pela antiga
definio, porque essa definio no exigia que um atributo
fosse irredutivelmente dependente de cada chave candidata, se
ele prprio fosse um componente de uma chave candidata da
varivel de relao, e assim o fato de FNOME no ser
irredutivelmente dependente de {F#,P#} era ignorado. Nota:
por 3FN queremos dizer aqui a 3FN definida originalmente na
referncia [10.4], no a forma simplificada que definimos na
Seo 11.3.
32
FFP F# FNOME P# QDE
Fi Smith P1 300
Fi Smith P2 200
F1 Smith P3 400
F1 Smith P4 200
A soluo dos problemas de FFP , naturalmente, desmembrar a
varivel de relao em duas projees, nesse caso as
projees:
FF { F#, FNOME }
FP {F#, P#, QDE )
ou, de modo alternativo, as projees:
FF { F#, FNOME }
FP {FNOME, P#, QDE }
(existem duas decomposies igualmente vlidas nesse
exemplo). Todas essas projees esto em FNBC. Nesse ponto,
provavelmente deveramos parar um instante e refletir sobre o
que realmente est
se passando aqui. O projeto original, consistindo na nica
varivel de relao FFP, claramente ruim; os problemas com
ele so intuitivamente bvios e improvvel que qualquer
projetista de banco de dados competente pensasse seriamente
em propor esse projeto, mesmo que no tivesse conhecimento
algum das idias de FNBC, etc. O senso comum diria ao
projetista que o projeto de FF-FP melhor. Entretanto, o que
entendemos por senso comum? Quais so osprincpios (dentro
do crebro do projetista) que ele est aplicando quando
escolhe o projeto FF-FP em vez do projeto FFP?
A resposta, claro, que so exatamente os princpios da
dependncia funcional e a forma normal de Boyce/Codd. Em
outras palavras, esses conceitos (DF, FNBC e todas as outras
idias formais que discutimos neste captulo e no prximo)
no so nem mais nem menos que senso comum formalizado. Toda
a importncia da teoria subjacente a essa rea est em tentar
identificar esses princpios do senso comum e formaliz-los
o que, naturalmente, no algo fcil de fazer! Porm, pode
ser feito, e ento podemos mecanizar esse princpios; em
outras palavras, podemos escrever um programa e fazer com que
a mquina execute o trabalho. Os crticos da normalizao em
geral no percebem esse ponto; eles afirmam (com toda razo)
que as idias so todas basicamente de senso comum mas, em
geral, no percebem que uma realizao significativa poder
afirmar que o senso comum quer dizer de modo preciso e
formal.
Voltemos ao fio principal da discusso. Como segundo exemplo
de chaves candidatas superpostas um exemplo que, devemos
adverti-lo, algumas pessoas podem considerar patolgico
consideramos a varivel de relao EAP com atributos E, A e
P, indicando estudante, assunto e professor, respectivamente.
O significado de uma tupla EAP {E:e,A;a,P:p} que o
estudante e aprende o assunto a ministrado pelo professor p.
Aplicam-se as seguintes restries:
a Para cada assunto, cada estudante aprende esse assunto
lecionado por um nico professor.
- Cada professor leciona apenas um assunto (mas cada assunto
ministrado por vrios professores).
Uma amostra de valores de EAP dada na Figura 11.14.
F 1 G U RA 1 1 . 1 4 Amostra de valores para a varivel de
relao EAP
Quais so as DFs na varivel de relao EAP? Da primeira
restrio, temos a DF {E,A} > P. Da segunda restrio,
temos a DF P > A. Finalmente o fato de cada assunto ser
ministrado por vrios professo-
322 res nos informa que a DF A > P no vlida. Ento, o
diagrama DF o que est ilustrado na Figura 11.15.
EAP
E
Smith
Smith
Jones
Jones
A
Matemtica
Fsica
Matemtica
Fsica
P
Prof. White
Prof. Green
Prof. White
Prof. Brow
L
FIGURA 1 1. 1 5 DFs para a varivelde relao EAP
Mais uma vez temos duas chaves candidatas superpostas, {E,A}
e {E,P}. De novo a varivel de relao est em 3FN e no em
FNBC; novamente, a varivel de relao sofre de certas
anomalias de atualiza- o por exemplo, se desejarmos
eliminar a informao de que Jones est estudando fsica, no
poderemos faz-lo sem perdermos ao mesmo tempo a informao
de que o Professor Brown leciona fsica. Essas dificuldades
so causadas pelo fato de que o atributo P um determinante,
mas no uma chave candidata. Outra vez, podemos superar os
problemas substituindo a varivel de relao original por
duas projees FNBC, no caso as projees:
EP { E, P }
PA {P, A }
Fica como exerccio mostrar os valores dessas duas variveis
de relaes correspondentes aos dados da Figura 11.14, traar
um diagrama DF correspondente, demonstrar que as duas
projees de fato esto em FNBC (quais so as chaves
candidatas?) e verificar que essa decomposio evita as
anomalias.
Porm, existe outro problema. O fato que, embora a
decomposio em EP e PA evite certas anomalias, ela
infelizmente introduz outras! A dificuldade est no fato de
que as duas projees no so independentes, no sentido de
Rissanen (consulte a Seo 1 1.4). Para sermos especficos, a
DF:
{ E, A } P
no pode ser deduzida da DF:
PA
(que a nica DF representada nas duas projees). Em
consequncia disso, as duas projees no podem ser
atualizadas independentemente. Por exemplo, uma tentativa de
inserir uma tupla para Smith e Prof. Brown na varivel de
relao EP deve ser rejeitada, porque o Prof. Brown leciona
fsica e Smith j est estudando fsica com o Prof. Green,
ainda que o sistema no possa detectar esse fato sem examinar
a varivel de relao PA. Somos forados desagradvel
concluso de que os dois objetivos de (a) decompor uma
varivel de relao em componentes FNBC e (b) decompor a
varivel de relao em componentes independentes podem
ocasionalmente estar em conflito; ou seja, nem sempre
possvel satisfazer si- multaneamente a ambos os objetivos.
Nota: na verdade, a varivel de relao EAP atmica
(consulte a Seo 11.4), embora no esteja em FNBC. Portanto,
observe que o fato de uma varivel de relao atmica no
poder ser decomposta em componentes independentes no
significa que ela no possa ser de todo decomposta (onde por
decomposta entendemos, claro, a decomposio sem perdas).
Assim, em termos intuitivos, atomicidade no um termo
muito bom para o conceito pois ela no necessria nem
suficiente para um bom projeto de banco de dados.
Nosso terceiro, e ltimo, exemplo de chaves candidatas com
superposio diz respeito a uma varivel de relao EXAME com
atributos E (estudante), A (assunto) e P (posio). O
significado de uma tupla de EXAME {E:e,A:a,P:p} que o
estudante e foi examinado sobre o assunto a e ficou na p-
sima posio na sua turma. Para os propsitos do exemplo,
supomos que a seguinte restrio vlida:
323
- No h empates; isto , dois estudantes nunca obtm a mesma
posio no exame sobre o mesmo
assunto.
Ento as DFs so aquelas mostradas na Figura 11.16.
Novamente, temos duas chaves candidatas com superposio, ou
seja, {E,A} e {A,P}, porque (a) se temos um estudante e um
assunto, ento h exatamente uma posio correspondente e, do
mesmo modo, (b) se temos um assunto e uma posio, h
exatamente um estudante correspondente. Porm, a varivel de
relao est em FNBC porque essas chaves candidatas so os
nicos determinantes e as anomalias de atualizao, como
aquelas discutidas no incio deste captulo, no ocorrem com
essa varivel de relao. (Exerccio: verifique essa
afirmao.) Assim, chaves candidatas superpostas no levam
necessariamente a problemas do tipo que estivemos discutindo
neste captulo.
Concluindo, vimos que o conceito de FNBC elimina certos
problemas adicionais que poderiam ocorrer sob a antiga
definio de 3FN. Alm disso, a FNBC conceitualmente mais
simples que a 3FN, no sentido de no fazer referncia aberta
aos conceitos de 1FN, 2FN, chave primria ou dependncia
transitiva. Mais ainda, a referncia que ela faz a chaves
candidatas poderia ser substituda por uma referncia noo
mais fundamental de dependncia funcional (a definio dada
na referncia [1 1.2] na verdade faz essa substituio). Por
outro lado, os conceitos de chave primria, dependncia
transitiva etc., so teis na prtica, pois do alguma idia
do real processo passo a passo que o projetista deve
percorrer a fim de reduzir uma varivel de relao arbitrria
a uma coleo equivalente de variveis de relaes FNBC.
Finalmente, observamos que a resposta ao Exerccio 1 1 .3 no
final do captulo inclui um algoritmo pelo qual uma varivel
de relao arbitrria pode ser decomposta sem perdas em um
conjunto de projees FNBC.
11.6 UMA OBSERVAO SOBRE ATRIBUTOS COM RELAO COMO VALOR
No Captulo 5, vimos que possvel uma relao incluir um
atributo cujos valores so por sua vez relaes (um exemplo
est ilustrado na Figura 1 1.17). Como resultado,
naturalmente, as variveis de relaes tambm podem ter
atributos com valor de relao. Porm, do ponto de vista do
projeto de bancos de dados, essas variveis de relaes so
em geral contra-indicadas porque tendem a ser assimtricas*
sem mencionar o fato de que seus predicados tendem a ser
bastante complicados! e tal assimetria pode conduzir a
vrios problemas prticos. Por exemplo, no caso da Figura
11.17, fornecedores e peas so tratados de forma
assimtrica. Em consequncia, as consultas (simtricas):
1. Obter F# para fornecedores que fornecem a pea P1.
2. Obter P# para peas fornecidas pelo fornecedor Fi.
tm formulaes muito diferentes:
1. ( FPQ WHERE P# ( P1' ) IN PQ { P# 1 ) { F# }
2. FPQ WHERE F# = F# ( Fi' ) ) { PQ } ) { P#
* Na verdade, essas variveis de relaes historicamente no
eram nem mesmo vlidas elas eram chamadas no normalizadas,
324 significando que no eram sequer consideradas como
estando em 1FN [10.4]. Consulte o Captulo 5.
.I. E
FIGURA 1 1.16 DFs para a varivelde relao EXAME
FPQ
lizaes a seguir:
FIGURA 1 1 . 1 7 Uma relao que tem um atributo com valor de
relao
Nesse caso, FPQ considerada uma varivel de relao cujos
valores so relaes da forma indicada pela Figura 11.17.
A situao fica ainda pior no caso das operaes de
atualizao. Por exemplo, considere as duas atua-
1. Criar uma nova remessa para fornecedor F6, pea P5,
quantidade 500.
2. Criar uma nova remessa para fornecedor F2, pea P5,
quantidade 500.
Com nossa varivel de relao de remessas FP habitual, no
existe nenhuma diferena qualitativa entre essas duas
atualizaes ambas envolvem a insero de uma nica tupla
na varivel de relao. Em contraste, no caso da varivel de
relao FPQ, as duas atualizaes diferem de forma
significativa em espcie (sem mencionarmos o fato de que
elas so ambas muito mais complicadas que sua equivalente
FP):
1. INSERT INTO FPQ RELATION
{ TUPLE { F# F# ( F6' ),
PQ RELATION { TIJPLE { P# ( P5 ),
QDE QDE ( 500 ) } ) } } ;
2. UPDATE FPQ WHERE F# = F# ( `F2
INSERT INTO PQ RELATION { TUPLE { P# ( P5' ),
QDE QDE ( 500 ) } }
As variveis de relaes pelo menos, as variveis de
relaes bsicas sem atributos com valor de relao so,
ento, normalmente preferidas porque o fato de terem uma
estrutura lgica mais simples conduz a simplificaes
correspondentes nas operaes que precisamos executar sobre
elas. Porm, entenda que essa posio deve ser vista apenas
como uma diretriz, no como uma lei inviolvel. Na prtica,
podem surgir casos em que um atributo com valor de relao
no faz sentido, mesmo no caso de uma varivel de relao
bsica. Por exemplo, a Figura 1 1 . 1 8 mostra (parte de) um
valor possvel para uma varivel de relao de catlogo RVK,
que lista as variveis de relaes no banco de dados e suas
chaves candidatas. O atributo CK nessa varivel de relao
um atributo com valor de relao. Ele tambm um componente
da nica chave candidata para RVK! Uma definio em Tutorial
D para RVK seria portanto semelhante a esta:
VAR RVK BASE RELATION
{ NOMEVR NOME, CC RELATION { NOMEATRIB NOME } 1
KEY { NOMEVR, CC } ;
325
F# PQ
Fi
F2
F5
QDE
1
No h empates; isto , dois estudantes nunca obtm a mesma posio no exame sobre o mesmo assunto.
Ento as DFs so aqueas mostradas na Fi!ura ""."#.
No$amente, temos duas cha$es candidatas com superposio, ou se%a, %E,&% e IA,I, porque 'a( se temos um
estudante e um assunto, ento h exatamente uma posio correspondente e, do mesmo modo, 'b( se temos
um assunto e uma posio, h exatamente um estudante correspondente. )orm, a $ari$e de reao est em
FN*+ porque essas cha$es candidatas so os ,nicos determinantes e as anomaias de atuai-ao, como
aqueas discutidas no in.cio deste cap.tuo, no ocorrem com essa $ari$e de reao. (Exerccio: $eri/ique
essa a/irmao.( &ssim, cha$es candidatas superpostas no e$am necessariamente a probemas do tipo que
esti$emos discutindo neste cap.tuo.
+oncuindo, $imos que o conceito de FN*+ eimina certos probemas adicionais que poderiam ocorrer sob a
anti!a de/inio de 0FN. &m disso, a FN*+ conceituamente mais simpes que a 0FN, no sentido de no
/a-er re/erncia aberta aos conceitos de "FN, 1FN, cha$e primria ou dependncia transiti$a. 2ais ainda, a
re/erncia que ea /a- a cha$es candidatas poderia ser substitu.da por uma re/erncia 3 noo mais
/undamenta de dependncia /unciona 'a de/inio dada na re/erncia 4"".1" na $erdade /a- essa
substituio(. )or outro ado, os conceitos de cha$e primria, dependncia transiti$a etc., so ,teis na prtica,
pois do a!uma idia do rea processo passo a passo que o pro%etista de$e percorrer a /im de redu-ir uma
$ari$e de reao arbitrria a uma coeo equi$aente de $ari$eis de rea5es FN*+.
Finamente, obser$amos que a resposta ao Exerc.cio "".0 no /ina do cap.tuo incui um a!oritmo peo qua
uma $ari$e de reao arbitrria pode ser decomposta sem perdas em um con%unto de pro%e5es FN*+.
11.6 UMA OBSERVAO SOBRE ATRIBUTOS COM RELAO COMO
VALOR
No +ap.tuo 5, $imos que poss.$e uma reao incuir um atributo cu%os $aores so por sua $e- rea5es
'um exempo est iustrado na Fi!ura ""."6(. +omo resutado, naturamente, as $ari$eis de rea5es tambm
podem ter atributos com $aor de reao. )orm, do ponto de $ista do pro%eto de bancos de dados, essas
$ari$eis de rea5es so em !era contra7indicadas porque tendem a ser assimtricas* sem mencionar o
/ato de que seus predicados tendem a ser bastante compicados8 e ta assimetria pode condu-ir a $rios
probemas prticos. )or exempo, no caso da Fi!ura ""."6, /ornecedores e peas so tratados de /orma
assimtrica. Em conseq9ncia, as consutas 'simtricas(:
". ;bter F< para /ornecedores que /ornecem a pea )".
1. ;bter )< para peas /ornecidas peo /ornecedor Fi.
tm /ormua5es muito di/erentes:
1. ' FPQ WHERE P# ' P1 ( IN PQ = P# > ( = F#
1. FPQ WHERE F# = F# ( Fi ) ) { PQ } ) { P#
* Na $erdade, essas $ari$eis de rea5es historicamente no eram nem mesmo $idas eas eram chamadas
no normalizadas, 01? si!ni/icando que no eram sequer consideradas como estando em "FN 4"@.?". +onsute
o +ap.tuo 5.
FIGURA 1 1.16 DFs para a varivel de relao E!"E
FPQ
P# QDE
FIGURA 1 1.17 #ma relao $%e tem %m atri&%to com valor de relao
Nesse caso, F)A considerada uma $ari$e de reao cu%os $aores so rea5es da /orma indicada pea
Fi!ura ""."6.
& situao /ica ainda pior no caso das opera5es de atuai-ao. )or exempo, considere as duas atuai-a5es
a se!uir:
". +riar uma no$a remessa para /ornecedor F#, pea '5, quantidade B@@.
1. +riar uma no$a remessa para /ornecedor F1, pea '5, quantidade B@@.
+om nossa $ari$e de reao de remessas F) habitua, no existe nenhuma di/erena quaitati$a entre essas
duas atuai-a5es ambas en$o$em a insero de uma ,nica tupa na $ari$e de reao. Em contraste, no
caso da $ari$e de reao F)A, as duas atuai-a5es di/erem de /orma si!ni/icati$a em espcie 'sem
mencionarmos o /ato de que eas so am&as muito mais compicadas que sua equi$aente F)(:
1. INSERT INTO FPQ RELATION
TUPLE = F# F# ' F6 (,
PQ RELATION = TUPLE = P# ' P5 (,
QDE QDE ( 500 ( ) ) ) )
1. UPDATE FPQ WHERE F# = F# ( F2
INSERT INTO PQ RELATION { TUPLE { P# ( P5 ),
QDE QDE ( 500 ) } } ;
&s $ari$eis de rea5es peo menos, as $ari$eis de rea5es bsicas sem atributos com $aor de reao
so, ento, normamente pre/eridas porque o /ato de terem uma estrutura C!ica mais simpes condu- a
simpi/ica5es correspondentes nas opera5es que precisamos executar sobre eas. )orm, entenda que essa
posio de$e ser $ista apenas como uma diretri-, no como uma ei in$io$e. Na prtica, podem sur!ir casos
em que um atributo com $aor de reao no /a- sentido, mesmo no caso de uma $ari$e de reao bsica.
)or exempo, a Fi!ura ""."D mostra 'parte de( um $aor poss.$e para uma $ari$e de reao de catlo*o
EFG, que ista as $ari$eis de rea5es no banco de dados e suas cha$es candidatas. ; atributo +G nessa
$ari$e de reao um atributo com $aor de reao. Ee tambm um componente da ,nica cha$e
candidata para EFG8 Hma de/inio em Iutoria D para EFG seria portanto semehante a esta:
VAR RVK BASE RELATION
NOMEVR NOME, CC RELATION { NOMEATRIB NOME }
KEY { NOMEVR, CC 1
PQ
Fi
F2
F5
325
RV K
+ota: a resposta ao Exerc.cio "".0 no /ina do cap.tuo mostra como eiminar atributos com $aor de
reao, se essa eiminao /or considerada dese%$e 'e normamente (.J Fe%a tambm a discusso
sobre o operador HNKE;H) no +ap.tuo # 'Leo #.D(.
"".6 EELH2;
Msso nos tra- ao /ina do primeiro de nossos dois cap.tuos sobre normai-ao a$anada. Discutimos os
conceitos de primeira, se!unda e terceira /ormas normais, am da /orma norma de *oNceO+odd. &s $rias
/ormas normais 'incusi$e a quarta e a quinta, que sero discutidas no prCximo cap.tuo( constituem uma
ordenao total, no sentido de que toda $ari$e de reao em um dado n.$e de normai-ao tambm est
automaticamente em todos os n.$eis in/eriores, enquanto o in$erso no $erdadeiro existem $ari$eis de
rea5es em cada n.$e que no esto em nenhum n.$e mais ato. &m disso, a reduo a FN*+ 'e na
$erdade at a LFN( sempre poss.$e; isto , quaquer $ari$e de reao dada sempre pode ser sempre
substitu.da por um con%unto equi$aente de $ari$eis de rea5es em FN*+ 'ou LFN(. & /inaidade de ta
reduo e$itar redundPncia e portanto e$itar certas anomaias de atuai-ao.
; processo de reduo consiste em substituir a $ari$e de reao dada por certas pro%e5es, de ta modo que
/a-endo a %uno dessas pro%e5es possamos obter de $ota a $ari$e de reao ori!ina; em outras paa$ras,
o processo re$ers.$e 'de modo equi$aente, a decomposio sem perdas(. Fimos tambm o pape crucia
que as dependncias /uncionais desempenham no processo; na $erdade, o teorema de Heath nos di- que, se
uma certa DF satis/eita, ento uma determinada decomposio sem perdas. Essa situao pode ser $ista
como outra con/irmao do que /oi dito no +apituo "@, que as DFs Qno so to /undamentais, mas quase
issoR.
* E poss.$e8 Note que no poss.$e no caso de EFG, peo menos no diretamente 'isto , sem a introduo de a!uma espcie 01# de
atributo N;2E++ Qnome de cha$e candidataR(.
FIGURA 11.18 !mostra de valores para a varivel de relao de catlo*o ,-.
Iambm discutimos o conceito de Eissanen de pro%e5es independentes e su!erimos que mehor /a-er a
decomposio em tais pro%e5es, em $e- de pro%e5es que no so independentes, quando h escoha.
Di-emos que uma decomposio em tais pro%e5es independentes preser$a dependncias. Mn/ei-mente,
tambm $imos que os dois ob%eti$os de 'a( decomposio sem perdas para FN*+ e 'b( preser$ao de
dependncias podem ocasionamente ser con/itantes.
+oncu.mos este cap.tuo com um par de de/ini5es muito ee!antes 'e totamente precisas(, de$ido a Sanioo
4"".6", dos conceitos de 0FN e FN*+. )rimeiro, a 0FN:
Ierceira /orma norma (de/inio de 0aniolo(: se%a , uma $ari$e de reao, se%a T quaquer
subcon%unto dos atributos deE e se%a & quaquer atributo isoado deE. Ento, , est em 0FN se e somente se,
para cada DF T * & em ,, peo menos uma das a/irma5es a se!uir $erdadeira:
". T contm ! 'ento, a DF tri$ia(.
1. T uma supercha$e.
0. ! est contida em uma cha$e candidata de ,.
& de/inio de /orma !"#a$ %e B!&'e(C!%% obtida a partir da de/inio de 0FN, simpesmente
descartando7se a possibiidade n,mero 0 'um /ato que mostra com care-a que a FN*+ estritamente mais
/orte que a 0FN(. & propCsito, a possibiidade n,mero 0 exatamente a causa da QinadequaoR na de/inio
ori!ina de +odd de 0FN 4"@.?U 3 qua nos re/erimos na introduo a este cap.tuo.
E)ERC*CIOS
""." )ro$e o teorema de Veath. O in$erso desse teorema $idoW
"".1 Xs $e-es se a/irma que toda $ari$e de reao binria est necessariamente em FN*+. Essa a/irmao
$idaW
"".0 & Fi!ura ""."Y mostra as in/orma5es a serem re!istradas no banco de dados de pessoa de uma
empresa, representadas como estariam em um sistema 1ierr$%ico como o M2L 'Mn/ormation 2ana!ement
LNstem( da I*2 'consute o +ap.tuo "(. & /i!ura de$e ser ida como a se!uir:
& empresa tem um con%unto de departamentos.
+ada departamento tem um con%unto de empre!ados, um con%unto de pro%etos e um con%unto de escritCrios.
+ada empre!ado tem um histCrico de /uno 'con%unto de /un5es que o empre!ado te$e(. )ara cada ta
/uno, o empre!ado tem tambm um histCrico de sario 'con%unto de sarios recebidos enquanto exercia
essa /uno(.
+ada escritCrio tem um con%unto de tee/ones.
FIGURA 11.1+ O &anco de dados de %ma empresa (viso 1ierr$%ica(
,-7
; banco de dados de$e conter as se!uintes in/orma5es:
)ara cada departamento: n,mero de departamento ',nico(, oramento, e o n,mero de empre!ado do !erente do
departamento ',nico(.
)ara cada empre!ado: n,mero de empre!ado ',nico(, n,mero de pro%eto atua, n,mero do escritCrio e n,mero de
tee/one: am disso, tituo de cada /uno que o empre!ado ocupou, e mais a data e o sario para cada sario distinto
recebido nessa /uno.
)ara cada pro%eto: n,mero de pro%eto ',nico( e oramento.
)ara cada escritCrio: n,mero de escritCrio ',nico(, rea ocupada e n,meros de tee/ones ',nicos( para todos os tee/ones
nesse escritCrio.
)ro%ete um con%unto apropriado de $ari$eis de rea5es para representar essas in/orma5es. Enuncie quaisquer
suposi5es que /i-er sobre as dependncias /uncionais.
"".? Hm banco de dados usado em um sistema de entrada de pedidos de$e conter in/orma5es sobre cientes, itens e
pedidos. &s in/orma5es a se!uir de$em ser incu.das.
)ara cada ciente:
N,mero do ciente 'excusi$o(
Endereos Qpara remessaR '$rios por ciente(
Lituao de pa!amento
Zimite de crdito
Desconto
)ara cada pedido:
Mn/orma5es de cabeaho: n,mero do ciente
endereo para remessa
data do pedido
Zinhas de detahe '$rias por pedido(: n,mero de item
quantidade pedida
)ara cada item:
N,mero de item 'excusi$o(
Fbricas de manu/atura
Auantidade dispon.$e em cada /brica
N.$e de risco de estoque para cada /brica
Descrio do item
&m disso, por ra-5es de processamento interno, um $aor de Qquantidade comprometidaR est associado a cada inha de
detahe de cada pedido; esse $aor iniciamente de/inido como i!ua 3 quantidade do item pedido e 'pro!ressi$amente(
redu-ido at -ero, 3 medida que as remessas 'parciais( so /eitas. )ro%ete um banco de dados para esses dados. +omo na
questo anterior, enuncie quaisquer suposi5es que /i-er quanto 3s dependncias.
11.. Luponha que no Exerc.cio "".? somente um n,mero muito pequeno de cientes, di!amos "[ ou menos, de /ato
tenha mais de um endereo para remessa. 'Msso t.pico em situa5es reais, nas quais ocorre com /req9ncia que apenas
a!umas exce5es quase sempre muito importantes deixam de obedecer a a!um padro !era.( Foc pode $er a!uma
de/icincia na sua souo para o Exerc.cio "".?W )ode pensar em a!um aper/eioamentoW
11.6 (-erso modi/icada do Exerccio 23.24(. Hma $ari$e de reao V;E\EM; de/inida com os se!uintes
atributos:
D Dia da semana '" a 5(
' )er.odo dentro do dia '" a D(
+ N,mero da saa de aua
5 Nome do pro/essor
L Nome do auno
! Nome da aua
,-8
& tupa 6D:d,':p,7:c,5:t,8:s,!:a) aparece nessa $ari$e de reao se e somente se na hora 6D:d,':p) o auno s est
assistindo 3 aua a, que est sendo ministrada peo pro/essor t na saa de aua c. Foc pode supor que as auas tm um
per.odo de durao e que toda aua tem um nome excusi$o com reao a todas as auas ministradas na semana. Eedu-a
V;E&EM; a uma estrutura mais dese%$e.
"".6 (-erso modi/icada do Exerccio 23.29(. & $ari$e de reao NENDE tem os atributos N;2E 'excusi$o(,
EH&, +MD&DE, ELI&D; e +E). )ara quaquer +E) dado, existe apenas uma cidade e um estado. &m disso, para
quaquer rua, cidade e estado dados, h somente um +E). NENDE est em FN*+W 0FNW 1FNW Foc poderia pensar em
um pro%eto mehorW
REFER/0CIAS E BIBLIOGRAFIA
&m das se!uintes, consute tambm as re/erncias no +ap.tuo "@, em especia os arti!os ori!inais de +odd sobre "FN,
1FN e 0FN 4"@.? e 23.52.
""." )hiip &. *ernstein: QLNnthesi-in! Ihird Norma Form Eeations /rom Functiona DependenciesR, !7" 5:D8 2,
N,mero ? 'de-embro de "Y6#(.
Neste cap.tuo, discutimos tcnicas para decompor Q!randesR $ari$eis de rea5es em $ari$eis de rea5es QmenoresR
'isto , aqueas de !rau menor(. Nesse arti!o, *ernstein considera o probema in$erso de usar QpequenasR $ari$eis de
rea5es para construir $ari$eis de rea5es QmaioresR 'isto , aqueas de !rau mais ato(. ; probema no reamente
caracteri-ado dessa /orma no arti!o; em $e- disso, descrito como o probema de sintetizar $ari$eis de rea5es dados
um con%unto de atributos e um con%unto de DFs correspondentes, com a restrio de que as $ari$eis de rea5es
sinteti-adas de$em estar em 0FN. )orm, como atributos e DFs no tm nenhum si!ni/icado /ora do contexto de a!uma
$ari$e de reao que os contenha, seria mais preciso considerar a construo primiti$a como uma $ari$e de reao
binria en$o$endo uma DF, em $e- de um par de atributos mais uma DF.
+ota: seria i!uamente poss.$e considerar que o con%unto dado de atributos e DFs de/ine uma $ari$e de reao
uni$ersa por exempo, consute a re/erncia 4"1.Y" que satis/a- a um certo con%unto de DFs e, nesse caso, o processo
de Qs.nteseR pode aternati$amente ser percebido como um processo de decomposio dessa $ari$e de reao
uni$ersa em pro%e5es de 0FN. )orm, $amos /icar com a interpretao ori!ina da Qs.nteseR para os /ins desta discusso.
Ento, o processo de s.ntese o de construir $ari$eis de rea5es n7rias a partir de $ari$eis de rea5es binrias, dado
um con%unto de DFs que se apiquem a essas $ari$eis de rea5es binrias, e dado o ob%eti$o de que todas as $ari$eis de
rea5es constru.das este%am em 0FN. '& FN*+ ainda no tinha sido de/inida quando esse trabaho /oi reai-ado.( Lo
apresentados a!oritmos para execuo dessa tare/a.
Hma ob%eo 3 aborda!em 'reconhecida por *ernstein( que as manipua5es e/etuadas peo a!oritmo de s.ntese so de
nature-a puramente sinttica, e no e$am em conta a semPntica. )or exempo, dadas as
DFs:
! * ; 'para a $ari$e de reao ,6!, ;)(
; * 7 'para a $ari$e de reao 86;, +>(
! * 7 'para a $ari$e de reao 56!, 7)(
a terceira poderia ser ou no redundante 'isto , impicada pea primeira e a se!unda(, dependendo do si!ni/icado deE, Le
5. +omo um exempo de onde ea no impicada, considere & um n,mero de empre!ado, ; um n,mero de escritCrio, +
como um n,mero de departamento; considere , como QescritCrio de empre!adoR, L como Qdepartamento ao qua pertence
o escritCrioR, Icomo Qdepartamento de empre!adoR; e considere ainda o caso de um empre!ado que trabahe em um
escritCrio pertencente a um departamento ao qua o empre!ado no pertence. ; a!oritmo de s.ntese simpesmente assume
que, por exempo, os dois atributos + so o mesmo 'na $erdade, ee no reconhece em absouto nomes de $ari$eis de
rea5es(; assim, ee depende da existncia de a!um mecanismo externo ou se%a, a inter$eno humana para e$itar
manipua5es semanticamente in$idas. No caso atua, seria de responsabiidade da pessoa de/inir as DFs ori!inais para
usarem nomes de atributos 7l e +1 'di!amos( distintos nas duas $ari$eis de rea5es L e 5.
"".1 E. F. +odd: QEecent Mn$esti!ations into Eeationa Data *ase LNstemsR, )roc. MFM) +on!ress, Estocomo, Lucia
'"Y6?( e em outros u!ares.
01Y
Esse arti!o /ocai-a uma coeo um tanto misturada de tCpicos. )orm, em particuar, ee o/erece uma
Qde/inio aper/eioada da terceira /orma normaR, onde Qterceira /orma normaR se re/ere de /ato ao que conhecemos
a!ora como /orma norma de ;o<ce=7odd. ;utros tCpicos discutidos incuem vis>es e at%alizao de vis>es,
s%&lin*%a*ens de dados, interc?m&io de dados e investi*a>es necessrias 'todas de
"Y6?(.
"".0 +. ]. Date: Q& Normai-ation )robemR, em ,elational Data&ase @ritin*s 2AA2B2AA9. Eeadin!. 2ass.:
&ddison7êseN (2AA5(.
)ara citar o resumo, esse arti!o Qexamina um probema simpes de normai-ao e o utii-a para /a-er a!umas
obser$a5es sobre o assunto de pro%eto de bancos de dados e decarao exp.cita de restri5es de inte!ridadeR. ;
probema en$o$e uma apicao simpes de companhia area e as se!uintes D/s:
VO } - DESTINO
VO } HORA
DIA, VO } PORTO
DIA, VO } - PILOTO
DIA, HORA, PORTO } - DESTINO
DIA, HORA, PORTO } - VO
DIA, HORA, PORTO } PILOTO
DIA, HORA, PILOTO } DESTINO
DIA, HORA, PILOTO } -, VO
DIA, HORA, PILOTO } -, PORTO
Dentre outras coisas, esse exempo ser$e como uma boa iustrao do /ato de que o pro%eto de banco de dados QcorretoR
raramente pode ser decidido com base apenas em princ.pios de normai-ao.
"".? ". ]. Veath: QHnacceptabe Fie ;perations in a Eeationa DatabaseR, )roc. "Y6" &+2 LMKFMDEI ôr_shop on
Data Description, &ccess, and +ontro, Lan Die!o, +ai/. 'no$embro de "Y6"(.
Esse arti!o /ornece uma de/inio de Q0FNR que na $erdade /oi a primeira de/inio pubicada de F+;7. Ee tambm
incui uma pro$a daquio a que nos re/erimos na Leo "".1 como teorema de Ceat1. ;bser$e que os trs passos no
procedimento de normai-ao discutido no texto deste cap.tuo representam todos apica5es desse teorema.
"".B îiam Gent: Q& Limpe Kuide to Fi$e Norma Forms in Eeationa Database IheorNR, 7!7" 1#, N,mero
1 '/e$ereiro de "YD0(.
& ori!em da caracteri-ao intuiti$amente atraente a se!uir de Q0FNR 'mais precisamente, FN*+(: cada atributo de$e
representar um /ato sobre a cha$e, toda a cha$e e nada am da cha$e 'i!eiramente para7 /raseado(.
"".# ]orma Eissanen: QMndependent +omponents o/ EeationsR,&+2 5:D8 D, N,mero ? 'de-embro de "Y66(.
"".6 +aro Sanioo: Q& Ne` Norma Form /or the Desi!n o/ Eeationa Database LchemataR, !7" 5:D8 E, N,mero 0
'setembro de "YD1(.
& ori!em das ee!antes de/ini5es de 0FN e FN*+ mencionadas na Leo "".6. & principa /inaidade do arti!o de/inir
uma no$a /orma norma, a /orma normal de c1ave elementar 'FN+E( que est entre a 0FN e FN*+, e Qcaptura as
quaidades saientes de ambasR, enquanto e$ita os probemas das duas 'ou se%a, que a 0FN Qdemasiado condescendenteR
e a FN*+ Qpropensa 3 compexidade computacionaR(.
; arti!o tambm mostra que o a!oritmo de *ernstein 4""."" de /ato !era $ari$eis de rea5es que esto em FN+E, no
apenas em 0FN.
RES1OSTAS A E)ERC*CIOS SELECIO0A2OS
""." ; teorema de Veath di- que se E=&,*,+> satis/a- 3 DF! > ; 'onde !, ; e + so con%untos de atributos(, ento ,
i!ua 3 %uno de suas pro%e5es ,i sobre 6!,;) e ,D sobre 6!,7). Na demonstrao desse teorema que /aremos em
se!uida, adotaremos nossa abre$iao usua para tupas, escre$endo por exempo (a,&,c( em $e- de 6!:a,;:&,7:c).
)rimeiro, mostramos que nenhuma tupa de , perdida, tomando as pro%e5es e depois /a-endo a %uno dessas pro%e5es
de $ota. Le%a (a,&,c( E ,. Ento (a,&( E ,i e (a,c( E ,D, e assim (a,&,c( E ,i ];MNE1. 1
330
Em se!uida, mostramos que toda tupa da %uno de /ato uma tupa de , 'isto , a %uno no !era tupas
Qesp,riasR(. Le%a (a,b,c) e ,F ];MNE1. )ara !erar uma determinada tupa na %uno de$emos ter (a,&( e ,F e
(a,c( e ,D. )ortanto, de$e existir uma tupa (a,&G,c( e , para a!um &G, a /im de !erar a tupa (a,c( E ,D.
&ssim, de$emos ter (a,&G( e ,l. &!ora temos (a,&( c,2 e (a,&G( e Ei; da., de$emos ter & = &G, porque & * ;.
Desse modo (a,&,c( e ,. ;
& rec.proca do teorema de Veath seria enunciar que, se ,6!,;,7) i!ua 3 %uno de suas pro%e5es sobre 6!,;) e sobre
=&,+>, ento , satis/a- 3 DF & * ;. Essa decarao /asa. )or exempo, a Fi!ura i1.1 do prCximo cap.tuo mostra uma
reao que certamente i!ua 3 %uno de duas de suas pro%e5es e, ainda assim, no satis/a- a nenhuma DF 'no tri$ia(.
"".1 & a/irmao quase $ida. ; contra7exempo patoC!ico a se!uir /oi tirado da re/erncia H5.5I. +onsidere a
$ari$e de reao HL& =)&ML,ELI&D;>, interpretada como QELI&D; um eemento de )&MLR, onde
)&ML corresponde aos Estados Hnidos da &mrica em toda tupa. Ento, a DF:
PAIS
$ida nessa $ari$e de reao, e ainda assim o con%unto $a-io = } no uma cha$e candidata. Ento, HL& no est em
FN*+ 'pode ser decomposta sem perdas em suas duas pro%e5es unrias embora o /ato de de$er ou no ser reamente
normai-ada dessa maneira possa ser assunto de debate(.
& propCsito, obser$e que em !era per/eitamente poss.$e ha$er uma cha$e candidata que seJa o con%unto $a-io8 Fe%a a
resposta ao Exerc.cio D.6 no +ap.tuo D, a /im de examinar uma discusso adiciona.
"".0 & Fi!ura "".1@ mostra todas as dependncias /uncionais mais importantes, tanto as impicadas peo enunciado do
exerc.cio quanto as que correspondem a hipCteses semPnticas ra-o$eis 'enunciadas expicitamente
a se!uir(. )retende7se que os nomes de atributos se%am auto7expicati$os.
ORAMENTO
DEPTO# GEREMP#
PORC
SALRIO
FIGURA 11.-3 Dia*rama DF para o Exerccio 22.4
CipKteses sem?nticas:
Nenhum empre!ado !erente de mais de um departamento ao mesmo tempo.
Nenhum empre!ado trabaha em mais de um departamento ao mesmo tempo.
Nenhum empre!ado trabaha em mais de um pro%eto ao mesmo tempo.
Nenhum empre!ado tem mais de um escritCrio ao mesmo tempo.
Nenhum empre!ado tem mais de um tee/one ao mesmo tempo.
Nenhum empre!ado exerce mais de uma /uno ao mesmo tempo.
Nenhum pro%eto atribu.do a mais de um departamento ao mesmo tempo.
Nenhum escritCrio desi!nado para mais de um departamento ao mesmo tempo.
N,meros de departamentos, n,meros de empre!ados, n,meros de pro%etos, n,meros de escritCrios e n,meros de
tee/ones so todos Q!obamenteR excusi$os.
REA
331
Le quaquer $ari$e de reao , ainda incuir quaisquer atributos com $aor de reao, executar uma seq9ncia
ano!a de opera5es sobre ,.
;btemos a se!uinte coeo de $ari$eis de rea5es com 'como indicamos( todos os atributos com $aor de reao
eiminados. )orm, obser$e que, embora as $ari$eis de rea5es resutantes este%am ' caro( em "FN, eas no esto
necessariamente em nenhuma /orma norma mais ata.
DEPTO1 = DEPTO#, DORC, GEREMP# >
PRIMARY KEY = DEPTO# >
ALTERNATE KEY = GEREMP# >
EMP1 = DEPTO#, EMP#, PROJ#, ESCRI#, TEL# >
PRIMARY KEY = DEPTO#, EMP#
FUN1 = DEPTO#, EMP#, CARGO
PRIMARY KEY = DEPTO#, EMP#, CARGO
SALHIST1 = DEPTO#, EMP#, CARGO, DATA, SALRIO
PRIMARY KEY = DEPTO#, EMP#, CARGO, DATA
PROJ1 = DEPTO#, PROJ#, PORC >
PRIMARY KEY = DEPTO#, PROJ# >
ESCRI1 = DEPTO#, ESCRI#, REA
PRIMARY KEY = DEPTO#, ESCRI# >
TEL1 = DEPTO#, ESCRI#, TEL# >
PRIMARY KEY = DEPTO#, ESCRI#, TEL# >
'asso D: red%zir L DF+
&!ora, redu-imos as $ari$eis de rea5es produ-idas no )asso " a uma coeo equi$aente de $ari$eis de rea5es em
1FN, eiminando quaisquer DFs no irredut.$eis. Famos considerar as $ari$eis de rea5es uma a uma.
DE)I;": Essa $ari$e de reao % est em 1FN.
E2)": )rimeiro, obser$e que DE)I;< na $erdade redundante, como um componente da cha$e primria para essa
$ari$e de reao. )odemos tomar =E2)<> so-inha como cha$e primria e, nesse caso, a $ari$e de reao /ica em
1FN como % est.
FHN": De no$o, DE)I;< no necessrio como componente da cha$e primria. +omo DE)I;< /uncionamente
dependente de E2)<, temos um atributo no7cha$e 'DE)I;<( que no irreduti$emente dependente da cha$e primria
'a combinao =E2)<,+&EK;>(, e ento FHN" no est em 1FN. )odemos substitu.7a por:
FUN2A = EMP#, CARGO
PRIMARY KEY = EMP#, CARGO
e
FUN2B = EMP#, DEPTO# >
PRIMARY KEY = EMP# >
)orm, FHN1& uma pro%eo de L&ZVMLI1 '$e%a a se!uir( e FHN1* uma pro%eo de
E2)" 'renomeada como E2)1 a se!uir(, de modo que essas duas $ari$eis de rea5es
podem ser descartadas.
333
L&ZVMLI": +omo ocorre no caso de FHN", podemos eiminar inteiramente por pro%eo DE)I;<. &m disso, +&EK;
no exi!ido como componente da cha$e primria. )odemos considerar a combinao =E2)<,D&I&> como cha$e
primria, a /im de obter a $ari$e de reao 1FN.
SALHIST2 { EMP#, DATA, CARGO, SALRIO
PRIMARY KEY 1 EMP#, DATA
)E;]": +omo ocorre com E2)", podemos considerar DE)I;< como um atributo no7cha$e; a $ari$e de reao /ica
ento em 1FN como % est.
EL+EM": &picam7se obser$a5es semehantes.
IEZ": )odemos eiminar inteiramente DE)I;<, pois a $ari$e de reao =DE)I;<,EL+EM<> uma pro%eo de
EL+EM" 'renomeada como EL+EM1 a se!uir(. &m disso, EL+EM< /uncionamente dependente de IEZ<; assim,
podemos considerar =IEZ<> so-inho como cha$e primria, obtendo assim a $ari$e de reao 1FN:
TEL2 { TEL#, ESCRI# }
PRIMARY KEY { TEL# }
;bser$e que essa $ari$e de reao no necessariamente uma pro%eo de E2)1 'tee/ones ou escritCrios poderiam
existir sem estarem associados a empre!ados(, de modo que podemos descartar essa $ari$e de reao.
&ssim, nossa coeo de $ari$eis de rea5es 1FN :
DEPTO2 { DEPTO#, DORC, GEREMP# }
PRLMARY KEY { DEPTO# 1
ALTERNATE KEY { GEREMP# 1
EMP2 { EMP#, DEPTO#, PROJ#, ESCRI#, TEL# }
PRIMARY KEY { DEPTO#, EMP# }
PRIMARY KEY { EMP#, DATA
PROJ2 { PROJ#, DEPTO#, PORC }
PRIMARY KEY { PROJ# }
ESCRI2 { ESCRI#, DEPTO#, REA
PRIMARY KEY { ESCRI#
TEL2 { TEL#, ESCRI# 1
PRIMARY KEY { TEL# 1
'asso 4: red%zir L 4F+
&!ora, redu-imos as $ari$eis de rea5es 1FN a um con%unto 0FN equi$aente eiminando dependncias
transiti$as. & ,nica $ari$e de reao 1FN que ainda no est em 0FN a $ari$e de reao E2)1, na qua
EL+EM< e DE)I;< so ambos transiti$amente dependentes da cha$e primria =E2)<> EL+EM< atra$s de
IEZ< e DE)I;< atra$s de )E;]< e tambm de EL+EM< 'e, ento, atra$s de IEZ<(. &s $ari$eis de rea5es
0FN 'pro%e5es( correspondentes a E2)1 so:
EMP3 { EMP#, PROJ#, TEL# 1
PRIMARY KEY { EMP# }
334
X { TEL#, ESCRI# }
Y { PROJ#, DEPTO# }
PRIMARY KEY { PROJ# 1
Z { ESCRI#, DEPTO# }
PRIMARY KEY { ESCRI# }
)orm, T IEZ1, a uma pro%eo de )E;]1 e S uma pro%eo de EL+EM1. )ortanto, nossa coeo de $ari$eis de
rea5es 0FN simpesmente:
DEPTO3 { DEPTO#, DORC, GEREMP# }
PRIMARY KEY { DEPTO# }
ALTERNATE KEY { GEREMP# }
EMP3 { EMP#, PROJ#, TEL# }
PRIMARY KEY { EMP# 1
PRIMARY KEY { EMP#, DATA
PROJ3 { PROJ#, DEPTO#, PORC }
PRIMARY KEY { PROJ# }
ESCRI3 { ESCRI#, DEPTO#, REA
PRIMARY KEY { ESCRI# }
TEL3 { TEL#, ESCRI# }
)or /im, /ci $er que cada uma dessas $ari$eis de rea5es 0FN est de /ato em FN*+.
;bser$e que, dadas certas restri5es semPnticas adicionais 'ra-o$eis(, essa coeo de $ari$eis de rea5es FN*+
/ortemente redundante 4B."U, porque a pro%eo da $ari$e de reao )E;]0 sobre =)E;]<,DE)I;<> , a todo
momento, i!ua a uma pro%eo da %uno de E2)0 e IEZ0 com EL+EM0.
Finamente, obser$e que poss.$e QdescobrirR as $ari$eis de rea5es FN*+ a partir do dia!rama DF 'comoW(. +ota:
no a/irmamos que sempre poss.$e QdescobrirR uma decomposio FN*+ apenas que /req9entemente poss.$e
/a-7o em casos prticos. Hm enunciado mais preciso o se!uinte: dada uma $ari$e de reao E que satis/a- a um
con%unto de DFs L, o a!oritmo a se!uir ')assos de ; a D( !arante produ-ir uma decomposio D de E em $ari$eis de
rea5es 0FN 'no FN*+(, ao mesmo tempo sem perdas e preser$ando as dependncias:
;. Mniciai-ar D como o con%unto $a-io.
". Le%a 2 uma cobertura irredut.$e de L.
1. Le%a T um con%unto de atributos que aparecem no ado esquerdo de a!uma DF T * M em 2.
0. Le%a T * a", T * MD, ... T * Mn o con%unto competo de DFs em " com o ado esquerdo T.
?. Le%a S a unio de MF, MD, ..., Mn.
5. Lubstitua D pea unio de D com a pro%eo de E sobre T e 0.
#. Eepita os )assos de 0 a 5 para cada T distinto.
7. Le%am !F,!D, ...,!n os atributos deE 'se existirem( ainda no e$ados em considerao 'isto , ainda no incu.dos em
quaquer $ari$e de reao em D(. Lubstitua D pea unio de D e a pro%eo deE sobre !F, !D, ...,!n.
00B
D. Le nenhuma $ari$e de reao em D incuir uma cha$e candidata de ,, substitua D pea unio de D com a pro%eo
de , sobre a!uma cha$e candidata de ,.
&m disso, o a!oritmo a se!uir ')assos de ; a 0( o/erece a !arantia de produ-ir uma decomposio D deE em $ari$eis
de rea5es FN*+ que so sem perdas, mas no necessariamente com preser$ao de dependncias:
;. Mniciai-e D para conter apenas ,.
". )ara cada $ari$e de reao Iem D, execute os )assos 1 e 0.
1. Le%a T M uma DF para 5 que $ioa os requisitos para FN*+.
0. Lubstitua Iem D por duas de suas pro%e5es, ou se%a, a pro%eo sobre T e M e a pro%eo sobre todos os atributos,
exceto os atributos pertencentes a M.
Fotando ao exempo de banco de dados da empresa: como exerc.cio compementar que no tem muita reao com a
normai-ao em si, embora se%a muito ree$ante para o pro%eto de bancos de dados em !era experimente estender o
pro%eto precedente para incorporar tambm as especi/ica5es necessrias de c1aves estran*eiras.
"".? & Fi!ura "".1" mostra as DFs mais importantes para esse exerc.cio. &s suposi5es semPnticas so as se!uintes:
Dois cientes nunca tm o mesmo endereo para remessa.
+ada pedido identi/icado por um ,nico n,mero de pedido.
+ada inha de detahe dentro de um pedido identi/icado por um n,mero de inha, ,nico no pedido.
Hm con%unto apropriado de $ari$eis de rea5es FN*+ o se!uinte:
CLIEN { CLIEN#, SALDO, LIMCRED, DESCONTO
KEY { CLIEN# }
ENVPARA { ENDEREO, CLIEN# }
KEY { ENDEREO
CABPED { PED#, ENDEREO, DATA
KEY { PED# }
LINHAPED{ PED#, LINHA#, ITEM#, QDEPED, QDESAI }
KEY { PED#, LINHA# }
ITEM { ITEM#, DESCR }
KEY { ITEM# }
IP { ITEM#, FBRICA#, QDEEST, PERIGO
KEY { ITEM#, FBRICA# }
00# FMKHE& "".1" Dia*rama DF para o Exerccio 22.9
"".B +onsidere o processamento que de$e ser executado por um pro!rama que ida com pedidos. Famos supor que a
entrada de pedidos especi/ique o n,mero do ciente, o endereo para remessa e os detahes dos itens pedidos 'n,mero dos
itens e quantidades(.
RETRIEVE CLI !ERE CLI# = CLI# entrada
saldo de cheques, limite de crdito etc.
RETRIEVE ENVIARPARA WHERE ENDER = ENDER entrada
&ND +ZM< = CLI# entrada
/* isto verifica o endereo para envio /
IF tudo est 0K THEN processa o pedido ; END IF
Le YY[ dos cientes sC ti$erem um endereo para remessa, seria um tanto ine/iciente inserir esse endereo em outra
$ari$e de reao que no +ZM 'se consideramos apenas esses YY[, ENDEE ser de /ato /uncionamente dependente de
+ZM<(. )odemos mehorar a situao da maneira descrita a se!uir. E caro que, para os YY[, o endereo principa o
,nico endereo. Auaisquer outros endereos sero chamados sec%ndrios. & $ari$e de reao +ZM pode ento ser
rede/inida como
CLI { CLI#, ENDER, SALDO, LIMCRED, DESCONTO
KEY { CLI# }
e a $ari$e de reao ENDEE2 pode ser substitu.da por
SEC { ENDER, CLI# }
KE" { ENDER }
&qui +ZM contm o endereo principa, e LE+ contm todos os endereos secundrios 'e os n,meros de cientes
correspondentes(. Essas $ari$eis de rea5es esto ambas em FN*+. ; pro!rama de processamento de pedidos a!ora
semehante a:
RETRIEVE CLI WHERE CLI# = CLI# entrada
saldo de cheques, limite de crdito etc.
MF ENDER recuperado ENDER entrada THEN
RETRIEVE SEC WHERE ENDER = ENDER entrada
AND CLI# = CLI# entrada
/ isto verifica o endereo para envio */
END IF
IF tudo est 0K THEN processa o pedido ; END IF
&s $anta!ens desse en/oque incuem:
; processamento mais simpes e i!eiramente mais e/iciente para YY[ dos cientes.
Le o endereo para remessa /or omitido do pedido de entrada, o endereo principa poder ser usado como padro.
Luponha que o ciente possa ter descontos di/erentes para cada endereo de remessa. +om a aborda!em inicia 'mostrada
na resposta ao exerc.cio anterior(, o atributo DEL+;NI; teria de ser desocado para a $ari$e de reao
ENFM&E)&E&, tornando o processamento ainda mais compicado. )orm, com a aborda!em re$isada, o desconto
principa 'correspondente ao endereo principa( pode ser representado pea presena de DEL+;NI; em +ZM, e os
descontos secundrios peo aparecimento correspondente de DEL+;NI; em LE+. &mbas as $ari$eis de rea5es ainda
esto em FN*+, e o processamento de no$o mais simpes para YY[ dos cientes.
Em suma: isoar casos excepcionais parece ser uma tcnica $aiosa para obter o mehor de dois mundos isto , para
combinar as $anta!ens de FN*+ com a simpi/icao na recuperao que poder ocorrer se as restri5es da FN*+ /orem
$ioadas.
337
"".# & Fi!ura "".11 mostra as dependncias /uncionais mais importantes. Hma poss.$e coeo de $ari$eis
de rea5es :
PROGRA { A, T, C, D, P }
KEY { A }
KEY { T, D, P }
KEY { C, D, P }
ESTUDO { S, A
KEY { S, A }
FIGURA "".11 Dia*rama DF para o Exerccio 22.N
"".6 NENDE 1FN, mas no 0FN 'e, portanto, no FN*+(. Hm pro%eto mehor seria:
NRC { NOME, RUA, CEP
KEY { NOME
CCE { CEP, CIDADE, ESTADO}
KEY { CEP }
Essas duas $ari$eis de rea5es esto ambas em FN*+. +ontudo, obser$e que:
+omo EH&, +MD&DE e ELI&D; so quase in$aria$emente exi!idos em con%unto 'pense na impresso de uma ista de
correspondncia( e os cCdi!os postais no mudam com muita /req9ncia, pode7se ar!umentar que di/icimente essa
decomposio $aeria a pena. 'Em outras paa$ras, a normai-ao de$e ser em !era reai-ada com respeito a
dependncias relevantes no necessariamente a todas as dependncias.(
;bser$e em particuar que a busca do endereo competo para um dado N;2E exi!e a!ora uma %uno 'embora essa
%uno pudesse /icar ocuta do usurio de/inindo7se NENDE como uma $iso de NE+ e ++E(. Em outras paa$ras,
poderia ser dito que a normai-ao para FN*+ &oa para at%alizao, mas r%im para &%sca isto , a
redundPncia que ocorre na ausncia da competa normai-ao certamente causa probemas com a atuai-ao, mas
poderia a%udar na busca.J & redundPncia causa di/icudades se descontroada; mas redundPncia controlada 'isto ,
redundPncia que decarada para o LK*D e !erenciada peo LK*D( pode ser aceit$e em certas situa5es.
& DF =EH&,+MD&DE,ELI&D;> > +E) no est diretamente representada por esse pro%eto; em $e- disso, ea ter de
ser mantida separadamente, ou de /orma decarati$a 'se o LK*D admitir uma in!ua!em de inte!ridade decarati$a
se!undo as inhas esboadas no +ap.tuo D( ou, caso contrrio, de /orma procedura. Na $erdade, caro, as $ari$eis de
rea5es NE+ e ++E no so independentes no sentido de Eissanen 4"".#U.
)or outro ado, essa redundPncia na reaidade pode impedir certas buscas 'isto , pode tornar a /ormuao das consutas
cor00D respondentes mais compicada(, como $eremos na Leo "1.B do prCximo cap.tuo.
L
L#$1
E%
&
E'
E
L
E
E%
E!
L
E%
E%
&
&(1
&E%

16 - Capítulo 11 - Normalização Avançada 1 1FN, 2FN, 3FN, FNBC

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

16 - Capítulo 11 - Normalização Avançada 1 1FN, 2FN, 3FN, FNBC

Caricato da

Copyright:

Formati disponibili

CAPITULO 11

Potrebbero piacerti anche