Normalização Álvaro Vinícius de Souza Coêlho

Dependência Funcional “Dada uma tabela T, a coluna Y de T é funcionalmente dependente da coluna X de T se e somente se cada valor de Y em T tiver a ele associado precisamente um valor X em T”

Dependência Funcional Opcionalmente, diz-se que X determina Y Exemplos –Matrícula determina Nome_Aluno (e endereço, telefone, etc.) –Placa determina Veículo –Número determina Competidor

Dependência Funcional A coluna determinante pode ser composta –(Aluno, Disciplina) determina Média –(Veículo, Condutor, Data) determina Multa Existem tipos variados de dependência funcional –Transitiva –Multivalorada –de Junção

Dependência Funcional Chaves: “Coluna que funciona como determinante funcional em uma tabela” Em Bancos de Dados Relacionais –Colunas que orientam para a seleção de uma ou mais linhas específicas em uma tabela

Dependência Funcional Exemplos de chaves –A matrícula de um aluno (existe outro com a sua?) –A Placa de um carro (ou o número do Chassi, ou o Renavam) –O Número de Inscrição de um competidor (só há um piloto com o carro número 1)

Dependência Funcional O CRA de um médico mais a Identificação de um plano de saúde identifica somente uma inscrição (Não dá para um CRA aparecer duas vezes na UNIMED).

Dependência Funcional Chave primária – Conjunto único de colunas (muitas vezes unitário) escolhido como identificador de uma Linha (como nos exemplos acima)

Dependência Funcional Chave Alternativa (ou candidata) - Conjunto único de colunas (normalmente unitário) que pode ser usado alternativamente como chave primária (como o número de chassis no lugar da placa do veículo).

Dependência Funcional Chave Estrangeira - Conjunto de colunas (muitas vezes unitário) que aponta uma Linha em outra tabela (é chave primária de outra tabela)

Dependência Funcional Exemplo: –Tabela (Vendedor#, NumNota, Loja#) –Colunas Vendedor# e Loja# são identificadores únicos (Chaves Primárias) em outras tabelas que contém: –Mais dados do vendedor – salário, nome, etc. –Ou da Loja – razão social, endereço, etc.

Normalização Normalização: “Colocar relações dentro de uma organização tal que atenda a um conjunto específico de restrições” –Usualmente determina-se 3 formas normais (acrescidas eventualmente de mais uma), que podem ser estendidas em mais 2. –mas no total são 8

Normalização Porque? Para diminuir as dificuldades e os problemas (anomalias) em operações de transação (inclusão, exclusão, alteração) nos dados.

Primeira Forma Normal 1FN: “Uma tabela está na 1FN sse todos os domínios básicos contiverem somente valores atômicos” Toda tabela que não possua colunas multivaloradas está na 1FN. –Tabelas em Bancos de Dados Relacionais tradicionais estão necessariamente na 1FN.

Primeira Forma Normal Ex: R1(F#, Status, Cidade, P#, Qtd) onde. –F# é o número do Fornecedor (uma chave estrangeira) –Status é a situação atual (em termos de probabilidade de negócio) de uma cidade –P# é a identificação (código) de uma peça (outra chave estrangeira) –Cidade e Qtd são auto-explicativos.

Primeira Forma Normal R1 F#StatusCidadeP#Qtd F120ItabunaP1300 F120ItabunaP2200 F120ItabunaP3400 F120ItabunaP4200 F120ItabunaP5100 F120ItabunaP6100

Primeira Forma Normal R1 (continuação) F210IlhéusP1300 F210IlhéusP2400 F310IlhéusP2200 F420ItabunaP2200 F420ItabunaP4300 F420ItabunaP5400

Primeira Forma Normal R1 está na 1FN! Anomalias –Inclusão: Só se sabe que um fornecedor está em uma determinada cidade quando ele passa a oferecer alguma peça

Primeira Forma Normal Anomalias –Exclusão: Se for excluída a última linha de um fornecedor, não se saberá mais em que cidade ele está –Alteração: Se um fornecedor troca de cidade, muitas linhas precisam ser alteradas (sob pena de haver inconsistência!)

Segunda Forma Normal Qual o problema? Há dependência entre colunas não chave e chaves diferentes ao mesmo tempo F# determina Cidade e o par F# e P# determina Qtd

Segunda Forma Normal 2FN: “Uma tabela está na 2FN sse ela está em 1FN e todas as colunas não-chave forem totalmente dependentes da chave primária”

Segunda Forma Normal R2(F#, Status, Cidade) e FP(F#, P#, Qtd) F#StatusCidade F120Itabuna F210Ilhéus F310Ilhéus F420Itabuna F530Itapetin ga

Segunda Forma Normal FP(F#, P#, Qtd) (continuação) F#P#Qtd F1P1300 F1P2200 F1P3400 F1P4200 F1P5100 F1P6100 F2P1300 F2P2400 F3P2200 F4P2200 F4P4300 F4P5400

Segunda Forma Normal R2 e FC estão na 2FN! Observar que não há perda de informação! Anomalias –Inclusão: O Status de uma cidade só é determinado se houver algum fornecedor para ela

Segunda Forma Normal Anomalias –Exclusão: Removendo-se o último fornecedor de uma cidade, perde-se o seu Status –Atualização: Para se substituir o Status de uma cidade, muitas linhas precisam ser trocadas

Terceira Forma Normal Qual o problema? Há dependência entre colunas não chave e outras colunas também não chave. Dependência funcional transitiva: –“Diz-se que A depende transitivamente de C se A depende de B e B depende de C”

Terceira Forma Normal No exemplo, –Status depende de Cidade, e Cidade depende de F#. –Daí que Status depende transitivamente de F#

Terceira Forma Normal 3FN: “Uma tabela está na 3FN sse está na 2FN e todos as colunas não-chave forem dependentes não transitivas da chave primária”

Terceira Forma Normal FC(F#, Cidade) CS(Cidade, Status) FP(F#, P#, Qtd) F#Cidade F1Itabuna F2Ilhéus F3Ilhéus F4Itabuna F5Itapetinga CidadeStatus Itabuna30 Ilhéus20 Itapetinga10

Terceira Forma Normal FC(F#, Cidade) CS(Cidade, Status) FP(F#, P#, Qtd) FC, CS E FP estão na 3FN! S#P#Qtd F1P1300 F1P2200 F1P3400 F1P4200 F1P5100 F1P6100 F2P1300 F2P2400 F3P2200 F4P2200 F4P4300 F4P5400

Forma Normal de Boyce-Codd Forma normal de Boyce-Codd (BCNF): “Uma tabela está em BCNF se cada determinante for candidato a chave primária” Pra que essa novidade?

Forma Normal de Boyce-Codd Suposição: Há um “Cadastro de Fornecedores” F(F#, FNome,...). Sendo que FNome é chave candidata (alternativa), pois também é única. A relação alternativa FP’(F#, FNome, P#, Qtd) está na 3FN?

Forma Normal de Boyce-Codd Vejamos: –Não há colunas multivaloradas. Logo, está na 1FN –A chave é (F#, P#). Todos os demais colunas dependem dela. Logo, está na 2FN –Não há dependência entre Qtd e FNome ou vice-versa (as colunas não-chave). Logo, está na 3FN Resposta: SIM!

Forma Normal de Boyce-Codd Mas não está na BCNF. Anomalias: –Alteração: Para se trocar o nome de um fornecedor, muitas linhas terão que ser modificadas, ou gera-se inconsistência Esta Forma normal é, então, interessante como um aperfeiçoamento da 3 a forma.

Quarta Forma Normal Dependência de Múltiplos Valores (ou Multivalorada) Até o presente estudo a Dependência Funcional é o fato de que uma coluna determina unicamente o valor de outra –Não é, porém, a visão mais completa

Quarta Forma Normal Tomemos um exemplo: (Projeto, Funcionários, Computadores) Um projeto tem vários funcionários alocados para ele, e será desenvolvido em vários computadores. Cada computador e cada funcionário é associado a apenas um projeto

Quarta Forma Normal Uma visão (não normalizada) seria: P#FNomeC# P1José João C1 C5 P2Carlos Ana C4 C6 C7 P3Pedro Marta Julia C2 C3

Quarta Forma Normal Como se poderia implementar isso num Banco de Dados Relacional? Uma alternativa seria a criação de uma tabela PFC(P#, Fnome, C#) com todas as combinações de alocações possíveis

Quarta Forma Normal Ficaria: P#FnomeC# P1JoséC1 P1JoséC5 P1JoãoC1 P1JoãoC5 P2CarlosC4 P2CarlosC6 P2CarlosC7

Quarta Forma Normal Continuação: P2AnaC4 P2AnaC6 P2AnaC7 P3PedroC2 P3PedroC3 P3MartaC2 P3MartaC3 P3JuliaC2 P3JuliaC3

Quarta Forma Normal A relação PFC está na 3FN? –Não possui multivalorados –Não possui dependências parciais –Não possui dependências transitivas SIM! Está na BCNF? –Todo mundo é chave (não há determinantes não chaves candidatos) SIM!

Quarta Forma Normal Anomalias: De inclusão: Como incluir um novo projeto ainda sem computador e/ou funcionários? De exclusão: Excluindo-se todos os computadores de um projeto, como saber os funcionários dele?

Quarta Forma Normal Anomalias: De alteração –Trocar um computador de um projeto para outro, ou um funcionário: Alteração de várias linhas –Alocar mais um computador ou funcionário para um projeto: Idem

Quarta Forma Normal Qual o problema? Há uma dependência multivalorada: Apesar de não determinar unicamente um funcionário ou um computador, P# determina um conjunto bem definido e único de C# ou de FNome

Quarta Forma Normal Dependência de Múltiplos Valores (MVD): Dada uma relação R com atributos A, B e C, a dependência de múltiplos valores R.A  R.B vale para R sse o conjunto de valores que se combinam com um dado par (valores de A e de C) depender somente de A e for independente de C.

Quarta Forma Normal MVD R.A  R.B  R.A  R.C –Se R.A determina multivaloradamente R.B, então também determina multivaloradamente R.C MVD R.A  R.B|R.C Como na dependência funcional vista até agora uma coluna determina apenas um elemento em outra, pode-se dizer que a DP é um caso especial de MVD

Quarta Forma Normal 4NF: Uma relação R está na quarta forma normal sse sempre que existir uma MVD em R (A  B), todos os atributos de R sejam funcionalmente dependentes de A ( ou seja, A  X para qualquer X em R)

Quarta Forma Normal Como fica? –Cria-se uma tabela PF(P#, Fnome) e uma tabela PC(P#, C#) Temos P#   Fnome e P#  C# Ou P#   C# e P#  Fnome Atendendo à 4FN

Quarta Forma Normal Relações: P#Fnome P1José P1João P2Carlos P2Ana P3Pedro P3Marta P3Julia P#C# P1C1 P1C5 P2C4 P2C6 P2C7 P3C2 P3C3

Normalização De modo geral os diagramas de modelagem de dados (diagramas de classes, MER, etc.) tendem a distribuir os dados já na 3FN, normalmente já na BCNF, salvo raríssimas exceções Em circunstâncias de projeto, com freqüência, considerações de performance acabam se impondo à observância das Formas Normais

Normalização Projetos de bancos de dados multidimensionais ou OLAP não devem se espelhar na normalização tradicional A Normalização destina-se a atender melhor às transações (OLTP)

Normalização. FIM! “Qualquer idéia, por mais simples que seja, pode ser expressa em termos complicados” Lei de Murphy aplicada à Tecnocracia Manet