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 1 0 Semestre de 2013. Banco de Dados I – BD I Prof. Lineu Mialaret Aula 18: Teoria da Normalização. Desenvolvimento de Aplicativos de BD. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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).
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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.