banco de dados i – bd i prof. lineu mialaret aula 18: teoria da normalização

©Prof. Lineu MialaretAula 18 - 1/68Banco de Dados I

Banco de Dados I – BD I Prof. Lineu Mialaret

Aula 18: Teoria da Normalização

Instituto Federal de Educação, Ciência e Tecnologia de São Paulo - IFSP

Campus de Caraguatatuba

Tecnólogo em Análise e Desenvolvimento de Sistemas

10 Semestre de 2013


PessoacompraProduto

nome

preco nome rg

Modelo Conceitual

Modelo Relacional

Normalização

Desenvolvimento de Aplicativos de BD


Introdução (1)

Normalização é uma técnica para produzir relações (tabelas) com propriedades desejáveis. É formalmente fundamentada em conceitos matemáticos.

Por meio do processo de normalização, pode-se substituir ou decompor, gradativamente, um conjunto de tabelas por um outro, mais adequado, que contenha uma menor redundância de dados.

Esta decomposição requer que nenhuma informação seja perdida e a reconstrução das tabelas originais seja possível.

O conceito de normalização foi introduzido por E. F. Codd em 1970, e desde então vem sendo muito estudado na pesquisa científica em Tecnologia de de Banco de Dados.

A normalização pode ser: Utilizada depois da modelagem conceitual ou de forma independente.

Especialmente útil para base de dados que já tenham sido projetadas e implementadas sem o uso de técnicas formais.


O propósito da normalização é desenvolver esquemas relacionais que minimizem redundâncias e anomalias de atualizações.

Redundância ocorre quando o mesmo valor de dado ou informação é armazenado mais de uma vez na tabela. Redundância ocupa espaço e reduz a performance do SGBD.

Anomaly: is an undesirable consequence of a data modification.

Anomalias de Atualização surgem quando se tenta inserir, remover ou atualizar linhas numa tabela. Essa anomalias numa base de dados surgem devido a ocorrência de, por exemplo:

Grupos repetitivos de dados.

Dependências parciais de chave.

Inexatidão de representações de fatos da realidades (modelos).

Dependências transitivas entre atributos.

Introdução (2)


Todas essas dificuldades podem ser reduzidas ou minimizadas por meio do uso da técnica de normalização.

Esta técnica torna o Modelo Relacional que se está utilizando, bastante estável, isto é, sujeito a poucas manutenções.

Resumindo:

O objetivo da normalização é produzir um conjunto de esquemas relacionais ajustados R1,R2,...,Rm de um conjunto de atributos A1,A2,A3,...,An.

Supondo que todos os atributos estejam originalmente em uma grande relação R = {A1,A2,...,An}, a qual pode ser chamada de relação universal, a

normalização vai dividir essa relação em várias relações otimizadas R1,R2,...,Rm.

Introdução (3)


Há três principais tipos de anomalias de atualização: Anomalia de inserção, onde a inserção de uma linha numa tabela requer a

inserção de informação redundante ou não pode ser realizada por atribuir valores nulos para atributos chaves.

Anomalia de remoção, em que a remoção de uma linha da tabela pode causar a perda de informação que ainda precisa ser armazenada.

Anomalia de modificação, quando a mudança de um atributo de uma linha da tabela pode exigir múltiplas mudanças desse valor em várias outras linhas da mesma.

Anomalias de Atualização (1)


Seja a seguinte tabela COMPANHIA que representa informações sobre uma determinada companhia.

Nome Endereco DataFundacao NomeDono Cargo #Acoes

Se a companhia possui três donos, há três linhas na tabela COMPANHIA para esta empresa.

COMPANHIA


Walita Rua X 1970 José Presidente 500

Walita Rua X 1970 João Gerente 400

Walita Rua X 1970 Joaquim Supervisor 100

COMPANHIA



Se a companhia muda para um novo endereço, o mesmo (novo endereço) deve ser atualizado consistentemente em todas as três linhas da tabela COMPANHIA: A atualização em apenas uma ou duas linhas da tabela deixará o banco

de dados num estado inconsistente (ou seja, gera uma anomalia).

Seria melhor ou mais adequado se o nome e o endereço da companhia estivessem numa tabela separada de modo que o endereço de cada companhia aparecesse em uma só linha dessa tabela.





COMPANHIA



Supondo que duas pessoas criem uma nova empresa e que: Os dois fundadores ainda não possuem cargos.

A distribuição do número de ações também não foi definida.

A nova empresa pode não ser inserida na tabela COMPANHIA pois não não há bastante informação para preencher todos aos atributos de uma linha da tabela, ou no máximo, valores nulos deverão ser usados para preencher uma linha.

Seria mais adequado que as informações sobre cargos e quantidade de ações fossem armazenadas numa tabela diferente.





Xerox Rua Y 2004 Jairo Null Null

Xerox Rua Y 2004 James Null Null

COMPANHIA



Supondo que um dos donos da companhia se retire do negócio mas ainda continue de posse de ações da mesma.

Se a linha da tabela COMPANHIA referente a esse dono é removida, perde-se a informação de quantas ações (#Acões) ele possui.

Se essa informação (a quantidade de ações possuída) estivesse armazenada numa tabela diferente, poderia-se manter ela armazenada, mesmo depois que a pessoa deixasse de ser dona da companhia.





COMPANHIA



Exemplo de Anomalia

Seja a seguinte atualização nesta tabela:

Inserir um departamento D4 que não possui empregados ainda.

O que ocorre?

Seja a seguinte tabela exemplo EMPDEPT:EMPDEPT


Propriedades Desejáveis de BD´s A técnica de normalização refere-se ao processo de converter um

Modelo Relacional arbitrário em outro com melhores propriedades operacionais.

Projetar um Banco de Dados Relacional não é apenas uma questão de especificar um conjunto de tabelas, que contém todos os atributos requeridos.

Tabelas que são bem projetadas possuem várias importantes características: A mais importante propriedade básica que a tabela possui é que seus

atributos são relacionados logicamente, ou seja os atributos nativos de uma tabela devem se referir a uma mesma entidade ou relacionamento.

A propriedade de lossless-join garante que a informação decomposta em muitas tabelas pode ser reconstruida usando-se junções naturais.

A propriedade de preservação de dependências garante que as restrições (requsitos) na tabela original podem ser reforçadas nas relações normalizadas.

Dessa forma, a normalização tem por objetivo produzir um Modelo Relacional que garanta a integridade dos dados, uma redundância mínima e sua evolução com o mínimo de efeito colateral.


Formas Normais (1) Uma tabela está numa particular Forma Normal – FN, se ela satisfaz

certas propriedades de normalização, ou seja, se ela atende os requisitos de uma determinada forma normal.

Há várias formas normais definidas:

Níveis de Formas Normais 1NF – First Normal Form (Primeira Forma Normal)

2NF – Second Normal Form (Segunda Forma Normal)

3NF – Third Normal Form (Terceira Forma Normal)

BCNF – Boyce-Codd Normal Form (Forma Normal de Boyce-Codd)

4NF – Fourth Normal Form (Quarta Forma Normal)

5NF – Fifth Normal Form (Quinta Forma Normal)

DK/NF – Domain/Key Normal Form (Forma Normal de Domínio/Chave)

A teoria da normalização é tradicionalmente expressa por meio de um conjunto de formas normais, as quais progressivamente otimizam as estruturas esquemáticas das tabelas de um Banco de Dados.


As formas normais são aninhadas (nesteds), ou seja, se uma determinada tabela R está na Terceira Forma Normal – 3FN, automaticamente ela está em 1FN e 2FN.

DK/NFDK/NF

Formas Normais (2)


1FN – 1a Forma Normal (1)

Domínio de um atributo: O conjunto de possíveis valores permitidos a esse atributo.

Exemplos de domínios:

X = { x | x -5 e x 5 }

Y = { y | y 0 }

Definição: Uma tabela está na Primeira Forma Normal - 1FN se, e

somente se, todos os seus atributos são atômicos. Grupos repetidos

de valores devem ser eliminados.

Uma tabela se encontra na 1FN quando todos os atributos são

simples (não sendo admitidos itens estruturados ou itens repetitivos),

ou seja, o valor de uma coluna da tabela é indivisível (ou único).

Quando uma tabela não está em 1FN diz-se que ela está em 0FN.


A 1FN é o primeiro passo do processo de normalização. Ela elimina os atributos multivalorados e compostos, permitindo apenas a ocorrência de atributos atômicos.

Exemplo de uma tabela EMPREGADO na 0FN:

Uma linha deve armazenar informações sobre os vários diferentes projetos nos quais um determinado empregado já trabalhou: Caso se coloque estas informações numa tabela relacional, já se está

normalizando para a 1FN.

Uma tabela no Modelo Relacional implicitamente já está em 1FN.


Matricula Nome CodCargo NomeCargo CodProj DataFim Horas

120 João 01 Programador 01

08

17/07/95

12/01/96

37

12

EMPREGADO



Há dois modos de converter uma tabela 0FN numa tabela que se encontre em 1FN.

Método da Divisão (Division Method) - dividir a tabela existente em duas tabelas, uma com os atributos não repetidos e a outra com os atributos repetidos: Criar uma nova tabela contendo a chave primária original mais os

atributos monovalorados.

Criar uma outra tabela tendo como chave primária a chave primária da tabela original concatenada com algum atributo multivalorado, e tendo como colunas os outros atributos multivalorados.

Método da Planificação (Flatenning Method) - criar novas linhas para os dados repetidos combinados com os dados que não são repetidos, e gerar uma nova chave primária (chave primária antiga concatenada com algum atributo multivalorado): Isto introduz redundância que será removida posteriormente pela

normalização.


1FN – Método da Divisão (1)

Matricula CodCargo NomeCargo CodProj DataFim Horas

120 1 Programador 01 17/07/95 37

08 12/01/96 12

121 1 Programador 01 17/07/95 45

08 12/01/96 21

Programador 12 21/03/96 107

270 2 Analista 08 12/01/96 10

12 21/03/96 38

273 3 Projetista 01 17/07/95 22

274 2 Analista 12 21/03/96 31

279 1 Programador 01 17/07/96 27

08 12/01/96 20

12 21/03/96 51

301 1 Programador 12 21/03/96 16

306 3 Projetista 17 21/03/96 67

EMPREGADO

Tabela EMPREGADO na 0FN.


Matricula Nome CodCargo NomeCargo

120 João 1 Programador

121 Hélio 1 Programador

270 Gabriel 2 Analista

273 Silva 3 Projetista

274 Abraão 2 Analista

279 Carla 1 Programador

301 Ana 1 Programador

306 Manoel 3 Projetista




08

17/07/95

12/01/96

37

12

Matricula CodProj DataFim Horas

120 01 17/07/95 37

120 08 12/01/96 12

121 01 17/07/95 45

121 08 12/01/96 21

121 12 21/03/96 107

270 08 12/01/96 10

270 12 21/03/96 38

273 01 17/07/95 22

274 12 21/03/96 31

279 01 17/07/96 27

279 08 12/01/96 20

279 12 21/03/96 51

301 12 21/03/96 16

306 17 21/03/96 67

EMPREGADO


1FN – Método da Planificação (1)


Matrícula Nome CodCargo NomeCargo CodProj DataFim Horas

120 João 1 Programador 01 17/07/95 37


121 Hélio 1 Programador 01 17/07/95 45



270 Gabriel 2 Analista 08 12/01/96 10


273 Silva 3 Projetista 01 17/07/95 22

274 Abraão 2 Analista 12 21/03/96 31

279 Carla 1 Programador 01 17/07/96 27



301 Ana 1 Programador 12 21/03/96 16

306 Manoel 3 Projetista 17 21/03/96 67

1FN – Método da Planificação (2)



08

17/07/95

12/01/96

37

12

EMPREGADO

EMPREGADO


Um dos objetivos da normalização é reduzir a redundância de dados, porém com a tabela EMPREGADO apresentada anteriormente ainda há a ocorrência dessa redundância.

É necessário realizar outros passos de normalização para se ter um bom projeto (eliminando-se desse modo as redundâncias).

A 1FN ainda possui características indesejáveis.

Uma tabela na 1FN pode apresentar anomalias de: Inclusão, Atualização e Remoção.

É necessário refinar a normalização, e para isso usa-se o conceito de Dependência Funcional - DF.












274 Abraão 2 Analista 12 21/03/96 31




301 Ana 1 Programador 12 21/03/96 16


308 Mané 3 null null null null


Anomalia de Inserção: não se pode inserir um empregado sem que este esteja alocado a um projeto, nem inserir um projeto sem que haja um empregado trabalhando nele.

EMPREGADO











274 Abraão 2 Analista 12 21/03/96 31




301 Ana 1 Programador 12 21/03/96 16



Anomalia de Remoção: se for necessário remover um projeto, as informações dos empregados que estiverem trabalhando apenas naquele projeto serão perdidas.

EMPREGADO











274 Abraão 2 Analista 12 21/03/96 31




301 Ana 1 Programador 12 21/03/96 16



Anomalia de Atualização: se um empregado for promovido de cargo, deve-se atualizar os atributos CodCargo e NomeCargo em todas as linhas nas quais este empregado está presente.

EMPREGADO


Dependência Funcional (1)

O Modelo Relacional fundamentou, baseado na teoria de funções

da matemática, o conceito de Dependência Funcional - DF.

Será utilizada a teoria de funções para explicar o conceito de

dependência funcional do Modelo Relacional.

Considere os seguintes conjuntos X e Y:

X

1

2

3

4

Y

11

12

13

14


Observa-se que há uma dependência entre os valores dos

conjuntos, que pode ser expressa pela função f(x) = x + 10, ou seja,

y é função de x, ou y = f(x) = x + 10.

Esta dependência pode também ser expressa através do gráfico

apresentado abaixo:

Y

13 12 11

0 0 1 2 3 X



Agora, sejam os conjuntos apresentados abaixo:

Nome

José

João

Rui

Manoel

CPF

1

2

3

4

Observa-se que há uma dependência entre os valores dos conjuntos,

que pode ser expressa pela função f(CPF) = nome.

O atributo nome é função do atributo CFP, ou seja, se houver um

número de CPF, pode-se encontrar o nome da pessoa

correspondente.



Esta dependência é expressa no Modelo Relacional da seguinte

maneira:

CPF NOME

Lê-se a notação acima do seguinte modo:

Com um número de CPF pode-se encontrar o nome da pessoa, ou ainda

O nome da pessoa depende funcionalmente do CPF.

Há uma série de regras formais para se manipular e raciocinar sobre

dependências funcionais.

O Axioma de Armstrong estabelece várias regras de inferência para

dependências funcionais.




Definição: Dada uma tabela R e os atributos X e Y, um atributo Y é funcionalmente dependente do atributo X se, e somente se, para cada valor de X está associado apenas um valor de Y.

Em outras palavras, o atributo X determina univocamente Y.

Simbologia:

X Y,

onde lê - se: X funcionalmente determina Y

Y é funcionalmente dependente de X

Y é função de X.

Para cada valor de X só existe um valor de Y.


Exemplo: O atributo eno determina funcionalmente o atributo ename.

Ou seja, pode-se dizer que eno ename.












274 Abraão 2 Analista 12 21/03/96 31




301 Ana 1 Programador 12 21/03/96 16


Exemplo: na tabela EMPREGADO acima há três linhas com valor 121 para matrícula, com o mesmo valor no atributo Nome (Hélio). Há um relacionamento semelhante entre Matricula e Nome nas demais linhas.

O atributo Nome é funcionalmente dependente de Matricula. Os atributos CodCargo e NomeCargo também são funcionalmente dependentes do atributo Matricula.



Uma dependência funcional tem o lado esquerdo denominado de determinante, podendo ser um conjunto de atributos e um atributo do lado direito (que também pode ser um conjunto de atributos).

Exemplo:

eno, pno hours



Geralmente há um só atributo do lado direito, mas pode-se combinar várias dependências funcionais em uma só.

Exemplo:

eno, pno hours

eno, pno resp

eno, pno hours, resp



Restrições (constraints) são regras que se aplicam a base de dados e limitam os valores de dados que podem ser armazenados.

Como toda restrição de integridade, dependências funcionais - DF´s são baseadas na semântica da aplicação: Pode-se checar uma instância de uma tabela e ver se uma DF é violada

ou não. Mas apenas com o exame de uma instância de uma tabela nunca se pode concluir se uma DF deve ser imposta ou não.

Uma dependência funcional - DF diz respeito a todas as possíveis instâncias de uma tabela.



Dependências Funcionais são direcionais:

eno ename não é o mesmo que ename eno

Exemplo: Dado um nome de empregado podem existir diversos valores para o

atributo eno se há empregados na base de dados com o mesmo nome.

Dessa forma, sabendo-se o valor do atributo ename não há como identificar unicamente o valor do atributo eno.



Uma dependência funcional é chamada de trivial se os atributos do seu lado esquerdo formam um superconjunto (superset) dos atributos do lado direito. Ou seja, um determinante (conjunto de atributos do lado esquerdo) com mais de um atributo pode determinar seus próprios membros quando isolado.

Exemplo: eno eno

eno, ename eno

eno, pno, hours eno, hours

Dependências funcionais triviais não são de interesse devido ao fato delas não dizerem absolutamente nada.

O interesse na normalização é pelas dependências não triviais.



Dependências Funcionais podem ser utilizadas para se determinar as chaves candidatas e primárias de uma relação.

Por exemplo, caso se saiba que um atributo funcionalmente determina todos os outros atributos numa relação, este atributo pode ser uma chave candidata.

Exemplo:

eno eno, ename, bdate, title, salary, supereno, dno

O atributo eno é uma chave candidata para a tabela Employee.


Employee


Definição alternativa de chaves: Um conjunto de atributos K é uma superchave para uma tabela R se o

conjunto dos atributos K funcionalmente determina todos os atributos em R.

Um conjunto de atributos K é uma chave candidata para uma tabela R se K é uma superchave mínima de R.



Regras para Dependências Funcionais (1)

Sejam A, B, C e D subconjuntos dos atributos de uma tabela R.

Regra 1: Reflexão

Se A B então A B

Um conjunto de atributos, sempre e trivialmente, determina qualquer subconjunto de si mesmo.

Exemplo:

Se {CPF, nome} {nome} então CPF, nome nome

Lê-se o exemplo acima do seguinte modo: Se o atributo nome é um subconjunto do conjunto formado pelos atributos

CPF e nome, então os atributos CPF e nome conjuntamente permitem encontrar o nome de uma pessoa.



Regra 2: Ampliação

Se A B então A,C B,C

A adição de um conjunto de atributos a ambos os lados da dependência funcional resulta em outra dependência funcional válida.

Exemplo:

Se CPF nome então CPF, endereco CPF, endereco

Lê-se o exemplo acima do seguinte modo: Se com um número de CPF encontra-se o nome de uma pessoa, então

com o número de CPF e o endereço pode-se encontrar o nome e o endereço de uma pessoa.


Regra 3: Transitividade

Se A B e B C então A C

Se um atributo determina um segundo atributo, e este atributo determina um terceiro atributo, então o primeiro atributo determina o terceiro atributo.

Exemplo:

Se CPF codigo-cidade e codigo-cidade nome-cidade

então

CPF nome-cidade

Lê-se o exemplo acima do seguinte modo:

Se com um número de CPF pode-se encontrar o código da cidade e com o código da cidade encontra-se o nome da cidade, então com o número do CPF pode-se encontrar o nome da cidade.



Há outras três regras que são derivadas das regras anteriores. Regra 4: Decomposição

Se A B,C então A B

e A C

Uma dependência funcional com dois atributos no lado direito pode ser decomposta em duas dependências funcionais com um atributo no lado direito.

Exemplo:

Se CPF nome, endereço então CPF nome

e CPF endereco

Lê-se o exemplo acima do seguinte modo: Se com um número de CPF encontra-se o nome e o endereço de uma

pessoa, então com este mesmo CPF pode-se encontrar apenas o nome, e com este mesmo CPF pode-se encontrar apenas o endereço.



Regra 5: União

Se A B e A C então A B,C

É o reverso da regra anterior.

Exemplo:

Se CPF nome e CPF endereço

então CPF nome, endereco

Lê-se o exemplo acima do seguinte modo: Se com um número de CPF encontra-se o nome de uma pessoa e com o

o mesmo número de CPF encontra-se seu endereço, então com este mesmo CPF pode-se encontrar o nome e o endereço da pessoa.



Regra 6: Composição

Se A B e C D então A,C B,D

É uma regra mais geral que a união, ou seja, ela combina duas dependências funcionais não sobrepostas em uma única dependência funcional.

Exemplo:

Se CPF código-funcionario e RG endereço

então CPF, RG código-funcionario, endereco

Lê-se o exemplo acima do seguinte modo: Se com um número de CPF encontra-se o código do funcionário, e com o

número de RG encontra-se seu endereço, então com os números de CPF e RG pode-se determinar o código do funcionário e seu endereço.



Conceito de Dependência Funcional Completa: Um atributo é considerado como tendo dependência funcional completa

de um outro conjunto de atributos, quando é funcionalmente dependente do conjunto inteiro, mas não de qualquer subconjunto do determinante.

A dependência funcional A B é considerada uma dependência funcional completa de B se a remoção de algum atributo de A resulta na inexistência (quebra) da dependência.

Diz-se que o atributo B é completamente dependente do atributo A.

Se há a remoção de algum atributo de A e a dependência funcional ainda existe, diz-se que o atributo B é parcialmente dependente do atributo A.

Dependência Funcional Completa (1)


Exemplo:

eno ename (dependência funcional completa)

eno, ename salary, title (dependência parcial, pois pode-se remover o atributo ename sem afetar a dependência)

eno, pno hours, resp (dependência funcional completa).



Exemplo: O atributo Horas está em dependência funcional completa dos atributos

Matricula e CodProj.

O atributo DataFim não está em dependência funcional completa de Matricula e CodProj pois DataFim é funcionalmente dependente do atributo CodProj sozinho.

Matricula Nome CodCargo NomeCargo CodProj DataFim Horas120 João 1 Programador 01 17/07/95 37120 João 1 Programador 08 12/01/96 12121 Hélio 1 Programador 01 17/07/95 45121 Hélio 1 Programador 08 12/01/96 21121 Hélio 1 Programador 12 21/03/96 107270 Gabriel 2 Analista 08 12/01/96 10270 Gabriel 2 Analista 12 21/03/96 38273 Silva 3 Projetista 01 17/07/95 22274 Abraão 2 Analista 12 21/03/96 31279 Carla 1 Programador 01 17/07/96 27279 Carla 1 Programador 08 12/01/96 20279 Carla 1 Programador 12 21/03/96 51301 Ana 1 Programador 12 21/03/96 16306 Manoel 3 Projetista 17 21/03/96 67



Uma tabela R está na Segunda Forma Normal - 2FN se: Ela está na 1FN.

Todo atributo não chave for totalmente funcionalmente dependente da chave primária. Isto é, não deve haver dependências parciais na chave.

Se uma tabela não está em 2FN, divide-se essa tabela em tabelas separadas, cada uma em 2FN, garantindo-se que a chave primária de cada nova tabela funcional e completamente determina todos os atributos da relação.

Por definição, qualquer tabela com uma chave primária de um único atributo sempre está na 2FN.



Seja a seguinte tabela EmpProj, com as seguintes DF´s:

df1

df2

df3

df4

Normaliza-se essa tabela para as seguintes tabelas: Emp (eno, ename, title, bdate, salary, supereno, dno)

WorksOn (eno, pno, resp, hours)

Proj (pno, pname, budget)



df1

df2

df3 df4












274 Abraão 2 Analista 12 21/03/96 31




301 Ana 1 Programador 12 21/03/96 16


Exemplo: Tabela Empregado em 1FN.



Matricula Nome CodCargo NomeCargo








306 Manuel 3 Projetista

Na 2FN, a tabela EMPREGADO resulta em três novas tabelas: Empregado, Projeto e Alocação:

CodProj DataFim01 17/07/9508 12/01/9612 21/03/96

Matricula CodProj Horas

120 01 37

120 08 12

121 01 45

121 08 21

121 12 107

270 08 10

270 12 38

273 01 22

274 12 31

279 01 27

279 08 20

279 12 51

301 12 16

306 17 67

A característica básica dessas novas tabelas geradas é que os atributos não chave estão em dependência total das chaves (não há dependência parcial).

Empregado Alocacao

Projeto



Entretanto, há anomalias que ocorrem na 2a Forma Normal - 2FN: Anomalia de Inserção - Só pode-se criar cargos se houver empregados

designados para ele.

Anomalia de Remoção - Caso seja removido o empregado que ocupa um único cargo na empresa, por exemplo um Gerente Geral, perde-se a informação sobre este cargo.

Anomalia de Atualização - Se um cargo mudar de nome, por exemplo, precisa-se alterar todas as tabelas nas quais este cargo aparece.

Definição: uma tabela R está em 3FN se, e somente se: Ela estiver em 2FN

Todos os atributos não chave (ou atributos não primos) de R forem dependentes não transitivos da chave primária.

Ou seja, uma tabela está em 3FN se todas as colunas da tabela são funcionalmente dependentes da chave inteira e de nenhum outro atributo além da chave. A 3FN elimina características potencialmente indesejáveis dos dados representados na 2FN ou 1FN.

2FN – 2a Forma Normal - Anomalias


Dependência Transitiva (1)

Suponha que se tenha uma tabela R com os atributos A, B e C.

Se o atributo C é funcionalmente dependente de B e B é funcionalmente dependente de A, então C é funcionalmente dependente de A.


Dependência Transitiva (2)

Exemplo: ao se analisar a tabela Emp descobre-se a dependência transitiva eno salary:

Remove-se essa dependência para uma nova tabela Pay:

fd1

fd2

fd1 fd2



Matrícula Nome CodCargo NomeCargo








306 Manuel 3 Projetista

Exemplo: ao analisar a nova Tabela Empregado que está em 2FN

Tem-se que NomeCargo é dependente transitivo de Matricula.

Matricula CodCargo NomeCargo


Removendo a dependência transitiva, obtém-se além das tabelas Projeto e Alocacao, as seguintes novas tabelas: Empregado e Cargo.

Matrícula Nome CodCargo

120 João 1

121 Hélio 1

270 Gabriel 2

273 Silva 3

274 Abraão 2

279 Carla 1

301 Ana 1

306 Manuel 3

CodCargo NomeCargo

1 Programador

2 Analista

3 Projetista


EmpregadoCargo

A característica básica dessas novas tabelas geradas é que os atributos não chave estão em dependência total das chaves (e não há dependências transitivas).


Superchave: Um ou mais atributos que permitem identificar cada linha da tabela

como única.

Chave Candidata: Corresponde a uma superchave mínima, ou seja, não existe um

subconjunto desta superchave que seja superchave.

{ cpf } é chave candidata?

{ cpf, nome } é chave candidata?

Chave Primária: Chave candidata escolhida para a tabela no projeto da base de dados.

Atributo Chave ou Atributo Primo: Atributo que compõe uma chave candidata.

Chaves de uma Relação


É uma forma normal mais restritiva que 3FN.

Relembrando, chama-se de determinante um atributo do qual algum outro atributo é funcionalmente dependente numa DF.

Definição: uma relação está na Forma Normal de Boyce-Codd - BCNF se, e somente se, cada determinante for uma chave candidata.

Para testar se uma relação está em BCNF, toma-se o determinante de cada DF na tabela e verifica-se se ele é uma chave candidata.

A diferença entre 3FN e BCFN é que a primeira permite uma DF do tipo A B permanecer na tabela se o atributo B é um atributo primo e o atributo A não é um atributo de chave candidata. A BCFN só permite essa DF se o atributo A é um atributo de chave candidata. A BCFN é mais restritiva que a 3FN. Entretanto, na prática a maioria das

relações em 3FN também estão em BCFN.

Essa forma normal cobre situações tais como: a tabela possui mais de uma chave candidata, as chaves candidatas são compostas ou as chaves candidatas se sobrepõem (possuem atributos em comum).

Forma Normal de Boyce-Codd (BCNF) (1)


Seja a tabela WoksOn onde tenha sido adicionada a restrição de que dado o número de horas trabalhadas, sabe-se exatamente o empregado que realizou determinado trabalho (ou seja, cada empregado é determinado funcionalmente pelo número de horas que trabalhou num determinado projeto).


A tabela WoksOn está em 3FN, mas não está em BCFN.

Caso se queira deixar a tabela em BCFN, deve-se dividir essa relação em duas, conforme apresentado a seguir.

df1

df2



A tabela WoksOn é dividida em duas tabelas.

Entretanto, observa-se que a dependência funcional

eno, pno resp, hours

não foi preservada nesta transformação.

df2


Exemplo: Seja a tabela AULA apresentada abaixo.

Cada linha desta tabela informa que um aluno E estuda uma disciplina A de um professor P.


AULA


Sejam as seguintes regras (ou restrições): Para cada disciplina, cada estudante da mesma recebe instrução de

um só professor.

Cada professor leciona apenas um assunto.

Dependências funcionais da tabela AULA:

Chaves candidatas:

{Aluno, Disciplina}

A relação AULA está em 3FN.



Anomalia: Se for removida a informação que o aluno Carlos estuda Física, perde-

se a informação que o professor Antonio ensina a disciplina de Física.

Solução: Decompor a tabela AULA nas seguintes tabelas:


Portanto tem-se as relações em BCNF.

Observa-se também que foi perdida a dependência funcional

aluno, disciplina professor

R1R2


Pode-se sempre decompor de 3FN para BCNF, mas as vezes isso não é interessante caso se perca uma dependência funcional.

A decisão de usar 3FN ou BCFN depende da quantidade de redundância que se está disposto a aceitar e da disposição para se perder uma dependência funcional.

Observa-se que sempre se pode reconstruir as tabelas originais numa BCFN, mas nem sempre se pode recuperar as dependências perdidas.

Ao contrário, na 3FN sempre se pode recuperar as tabelas originais, bem como as dependências funcionais.


banco de dados i – bd i prof. lineu mialaret aula 18: teoria da normalização

Documents