©Prof. Lineu MialaretAula 18 - 1/68Banco de Dados I Banco de Dados I – BD I Prof. Lineu Mialaret...
Transcript of ©Prof. Lineu MialaretAula 18 - 1/68Banco de Dados I Banco de Dados I – BD I Prof. Lineu Mialaret...
©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
©Prof. Lineu MialaretAula 18 - 2/68Banco de Dados I
PessoacompraProduto
nome
preco nome rg
Modelo Conceitual
Modelo Relacional
Normalização
Desenvolvimento de Aplicativos de BD
©Prof. Lineu MialaretAula 18 - 3/68Banco de Dados I
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.
©Prof. Lineu MialaretAula 18 - 4/68Banco de Dados I
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)
©Prof. Lineu MialaretAula 18 - 5/68Banco de Dados I
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)
©Prof. Lineu MialaretAula 18 - 6/68Banco de Dados I
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)
©Prof. Lineu MialaretAula 18 - 7/68Banco de Dados I
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
Nome Endereco DataFundacao NomeDono Cargo #Acoes
Walita Rua X 1970 José Presidente 500
Walita Rua X 1970 João Gerente 400
Walita Rua X 1970 Joaquim Supervisor 100
COMPANHIA
Anomalias de Atualização (2)
©Prof. Lineu MialaretAula 18 - 8/68Banco de Dados I
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.
Nome Endereco DataFundacao NomeDono Cargo #Acoes
Walita Rua X 1970 José Presidente 500
Walita Rua X 1970 João Gerente 400
Walita Rua X 1970 Joaquim Supervisor 100
COMPANHIA
Anomalias de Atualização (3)
©Prof. Lineu MialaretAula 18 - 9/68Banco de Dados I
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.
Nome Endereco DataFundacao NomeDono Cargo #Acoes
Walita Rua X 1970 José Presidente 500
Walita Rua X 1970 João Gerente 400
Walita Rua X 1970 Joaquim Supervisor 100
Xerox Rua Y 2004 Jairo Null Null
Xerox Rua Y 2004 James Null Null
COMPANHIA
Anomalias de Atualização (4)
©Prof. Lineu MialaretAula 18 - 10/68Banco de Dados I
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.
Nome Endereco DataFundacao NomeDono Cargo #Acoes
Walita Rua X 1970 José Presidente 500
Walita Rua X 1970 João Gerente 400
Walita Rua X 1970 Joaquim Supervisor 100
COMPANHIA
Anomalias de Atualização (5)
©Prof. Lineu MialaretAula 18 - 11/68Banco de Dados I
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
©Prof. Lineu MialaretAula 18 - 12/68Banco de Dados I
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.
©Prof. Lineu MialaretAula 18 - 13/68Banco de Dados I
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.
©Prof. Lineu MialaretAula 18 - 14/68Banco de Dados I
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)
©Prof. Lineu MialaretAula 18 - 15/68Banco de Dados I
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.
©Prof. Lineu MialaretAula 18 - 16/68Banco de Dados I
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.
1FN – 1a Forma Normal (2)
Matricula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 01 Programador 01
08
17/07/95
12/01/96
37
12
EMPREGADO
©Prof. Lineu MialaretAula 18 - 17/68Banco de Dados I
1FN – 1a Forma Normal (3)
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.
©Prof. Lineu MialaretAula 18 - 18/68Banco de Dados I
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.
©Prof. Lineu MialaretAula 18 - 19/68Banco de Dados I
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
1FN – Método da Divisão (2)
Matricula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 01 Programador 01
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
©Prof. Lineu MialaretAula 18 - 20/68Banco de Dados I
1FN – Método da Divisão (3)
©Prof. Lineu MialaretAula 18 - 21/68Banco de Dados I
1FN – Método da Planificação (1)
©Prof. Lineu MialaretAula 18 - 22/68Banco de Dados I
Matrícula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 1 Programador 01 17/07/95 37
120 João 1 Programador 08 12/01/96 12
121 Hélio 1 Programador 01 17/07/95 45
121 Hélio 1 Programador 08 12/01/96 21
121 Hélio 1 Programador 12 21/03/96 107
270 Gabriel 2 Analista 08 12/01/96 10
270 Gabriel 2 Analista 12 21/03/96 38
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
279 Carla 1 Programador 08 12/01/96 20
279 Carla 1 Programador 12 21/03/96 51
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)
Matricula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 01 Programador 01
08
17/07/95
12/01/96
37
12
EMPREGADO
EMPREGADO
©Prof. Lineu MialaretAula 18 - 23/68Banco de Dados I
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.
1FN – 1a Forma Normal (4)
©Prof. Lineu MialaretAula 18 - 24/68Banco de Dados I
Matrícula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 1 Programador 01 17/07/95 37
120 João 1 Programador 08 12/01/96 12
121 Hélio 1 Programador 01 17/07/95 45
121 Hélio 1 Programador 08 12/01/96 21
121 Hélio 1 Programador 12 21/03/96 107
270 Gabriel 2 Analista 08 12/01/96 10
270 Gabriel 2 Analista 12 21/03/96 38
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
279 Carla 1 Programador 08 12/01/96 20
279 Carla 1 Programador 12 21/03/96 51
301 Ana 1 Programador 12 21/03/96 16
306 Manoel 3 Projetista 17 21/03/96 67
308 Mané 3 null null null null
1FN – 1a Forma Normal (5)
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
©Prof. Lineu MialaretAula 18 - 25/68Banco de Dados I
Matrícula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 1 Programador 01 17/07/95 37
120 João 1 Programador 08 12/01/96 12
121 Hélio 1 Programador 01 17/07/95 45
121 Hélio 1 Programador 08 12/01/96 21
121 Hélio 1 Programador 12 21/03/96 107
270 Gabriel 2 Analista 08 12/01/96 10
270 Gabriel 2 Analista 12 21/03/96 38
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
279 Carla 1 Programador 08 12/01/96 20
279 Carla 1 Programador 12 21/03/96 51
301 Ana 1 Programador 12 21/03/96 16
306 Manoel 3 Projetista 17 21/03/96 67
1FN – 1a Forma Normal (6)
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
©Prof. Lineu MialaretAula 18 - 26/68Banco de Dados I
Matrícula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 1 Programador 01 17/07/95 37
120 João 1 Programador 08 12/01/96 12
121 Hélio 1 Programador 01 17/07/95 45
121 Hélio 1 Programador 08 12/01/96 21
121 Hélio 1 Programador 12 21/03/96 107
270 Gabriel 2 Analista 08 12/01/96 10
270 Gabriel 2 Analista 12 21/03/96 38
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
279 Carla 1 Programador 08 12/01/96 20
279 Carla 1 Programador 12 21/03/96 51
301 Ana 1 Programador 12 21/03/96 16
306 Manoel 3 Projetista 17 21/03/96 67
1FN – 1a Forma Normal (7)
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
©Prof. Lineu MialaretAula 18 - 27/68Banco de Dados I
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
©Prof. Lineu MialaretAula 18 - 28/68Banco de Dados I
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
Dependência Funcional (2)
©Prof. Lineu MialaretAula 18 - 29/68Banco de Dados I
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.
Dependência Funcional (3)
©Prof. Lineu MialaretAula 18 - 30/68Banco de Dados I
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.
Dependência Funcional (4)
©Prof. Lineu MialaretAula 18 - 31/68Banco de Dados I
Dependência Funcional (5)
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.
©Prof. Lineu MialaretAula 18 - 32/68Banco de Dados I
Exemplo: O atributo eno determina funcionalmente o atributo ename.
Ou seja, pode-se dizer que eno ename.
Dependência Funcional (6)
©Prof. Lineu MialaretAula 18 - 33/68Banco de Dados I
Matricula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 1 Programador 01 17/07/95 37
120 João 1 Programador 08 12/01/96 12
121 Hélio 1 Programador 01 17/07/95 45
121 Hélio 1 Programador 08 12/01/96 21
121 Hélio 1 Programador 12 21/03/96 107
270 Gabriel 2 Analista 08 12/01/96 10
270 Gabriel 2 Analista 12 21/03/96 38
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
279 Carla 1 Programador 08 12/01/96 20
279 Carla 1 Programador 12 21/03/96 51
301 Ana 1 Programador 12 21/03/96 16
306 Manoel 3 Projetista 17 21/03/96 67
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.
Dependência Funcional (7)
©Prof. Lineu MialaretAula 18 - 34/68Banco de Dados I
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
Dependência Funcional (8)
©Prof. Lineu MialaretAula 18 - 35/68Banco de Dados I
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
Dependência Funcional (9)
©Prof. Lineu MialaretAula 18 - 36/68Banco de Dados I
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ência Funcional (10)
©Prof. Lineu MialaretAula 18 - 37/68Banco de Dados I
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.
Dependência Funcional (11)
©Prof. Lineu MialaretAula 18 - 38/68Banco de Dados I
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ência Funcional (12)
©Prof. Lineu MialaretAula 18 - 39/68Banco de Dados I
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.
Dependência Funcional (13)
Employee
©Prof. Lineu MialaretAula 18 - 40/68Banco de Dados I
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.
Dependência Funcional (14)
©Prof. Lineu MialaretAula 18 - 41/68Banco de Dados I
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.
©Prof. Lineu MialaretAula 18 - 42/68Banco de Dados I
Regras para Dependências Funcionais (2)
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.
©Prof. Lineu MialaretAula 18 - 43/68Banco de Dados I
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.
Regras para Dependências Funcionais (3)
©Prof. Lineu MialaretAula 18 - 44/68Banco de Dados I
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.
Regras para Dependências Funcionais (4)
©Prof. Lineu MialaretAula 18 - 45/68Banco de Dados I
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.
Regras para Dependências Funcionais (5)
©Prof. Lineu MialaretAula 18 - 46/68Banco de Dados I
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.
Regras para Dependências Funcionais (6)
©Prof. Lineu MialaretAula 18 - 47/68Banco de Dados I
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)
©Prof. Lineu MialaretAula 18 - 48/68Banco de Dados I
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).
Dependência Funcional Completa (2)
©Prof. Lineu MialaretAula 18 - 49/68Banco de Dados I
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
Dependência Funcional Completa (3)
©Prof. Lineu MialaretAula 18 - 50/68Banco de Dados I
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.
2FN – 2a Forma Normal (1)
©Prof. Lineu MialaretAula 18 - 51/68Banco de Dados I
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)
2FN – 2a Forma Normal (2)
©Prof. Lineu MialaretAula 18 - 52/68Banco de Dados I
df1
df2
df3 df4
2FN – 2a Forma Normal (3)
©Prof. Lineu MialaretAula 18 - 53/68Banco de Dados I
Matricula Nome CodCargo NomeCargo CodProj DataFim Horas
120 João 1 Programador 01 17/07/95 37
120 João 1 Programador 08 12/01/96 12
121 Hélio 1 Programador 01 17/07/95 45
121 Hélio 1 Programador 08 12/01/96 21
121 Hélio 1 Programador 12 21/03/96 107
270 Gabriel 2 Analista 08 12/01/96 10
270 Gabriel 2 Analista 12 21/03/96 38
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
279 Carla 1 Programador 08 12/01/96 20
279 Carla 1 Programador 12 21/03/96 51
301 Ana 1 Programador 12 21/03/96 16
306 Manoel 3 Projetista 17 21/03/96 67
Exemplo: Tabela Empregado em 1FN.
2FN – 2a Forma Normal (4)
©Prof. Lineu MialaretAula 18 - 54/68Banco de Dados I
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 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
2FN – 2a Forma Normal (5)
©Prof. Lineu MialaretAula 18 - 55/68Banco de Dados I
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
©Prof. Lineu MialaretAula 18 - 56/68Banco de Dados I
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.
©Prof. Lineu MialaretAula 18 - 57/68Banco de Dados I
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
©Prof. Lineu MialaretAula 18 - 58/68Banco de Dados I
3FN – 3a Forma Normal (2)
Matrícula 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 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
©Prof. Lineu MialaretAula 18 - 59/68Banco de Dados I
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
3FN – 3a Forma Normal (3)
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).
©Prof. Lineu MialaretAula 18 - 60/68Banco de Dados I
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
©Prof. Lineu MialaretAula 18 - 61/68Banco de Dados I
É 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)
©Prof. Lineu MialaretAula 18 - 62/68Banco de Dados I
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).
Forma Normal de Boyce-Codd (BCNF) (2)
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
©Prof. Lineu MialaretAula 18 - 63/68Banco de Dados I
Forma Normal de Boyce-Codd (BCNF) (3)
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
©Prof. Lineu MialaretAula 18 - 64/68Banco de Dados I
Exemplo: Seja a tabela AULA apresentada abaixo.
Cada linha desta tabela informa que um aluno E estuda uma disciplina A de um professor P.
Forma Normal de Boyce-Codd (BCNF) (4)
AULA
©Prof. Lineu MialaretAula 18 - 65/68Banco de Dados I
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.
Forma Normal de Boyce-Codd (BCNF) (5)
©Prof. Lineu MialaretAula 18 - 66/68Banco de Dados I
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:
Forma Normal de Boyce-Codd (BCNF) (6)
Portanto tem-se as relações em BCNF.
Observa-se também que foi perdida a dependência funcional
aluno, disciplina professor
R1R2
©Prof. Lineu MialaretAula 18 - 67/68Banco de Dados I
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.
Forma Normal de Boyce-Codd (BCNF) (7)