sexta-feira, 8 de junho de 2012

Banco de Dados para Concursos - Normalização

O objetivo da Normalização é evitar anomalias de inserção, deleção e atualização. Não é evitar joins ou melhorar performance.

Normalização de dados é a decomposição de esquemas para evitar anomalias de atualização. Uma boa modelagem evita redunância de dados e anomalias. Normalização é um mecanimos formal para analisar relações baseado nas chaves e dependências entre os atributos.

Uma relação em uma forma normal mais alta, está necessariamente em uma forma normal mais baixa. A ordem é a seguinte:

Relação qualquer, sem normalização < 1ª forma normal < 2ª forma normal < 3ª forma normal < FNBC (forma particular da terceira forma normal) < 4ª forma normal < 5ª forma normal e outras.

Uma relação na terceira forma normal encontra-se também na primeira e na segunda formas normais.

Primeira Forma Normal - 1FN
Foi definida para não permitir atributos multivalorados, compostos e suas combinações. Campos compostos podem ser exemplificados com o caso do endereço. Dependendo da semântica, um endereço pode precisar ser dividido em bairro, rua, número e cep. Se tudo isso estiver em uma só coluna e for necessário acessar essas informações separadamente, então, este é um atributo composto. Atributos multi-valorados podem ser exemplificados com o caso do telefone onde existe mais de um número de telefone em uma mesma coluna.

Pela definição de RELAÇÃO, para que uma tabela seja considerada uma relação, ela DEVE estar na primeira forma normal.

"Uma relação está na 1FN se e somente se todos os atributos contiverem apenas valores atômicos (simples e indivisíveis)"

Como resolver o problema dos campos multi-valorados (caso do telefone)? Cria-se uma tabela extra, chamada telefone e essa tabela terá dois campos, a chave estrangeira que vem da primeira tabela e o campo telefone. A chave primária da tabela telefone é composta pela chave estrangeira + campo telefone. 

Como resolver o problema do campo composto (caso do endereço)? Divíde-se este campo em vários campos.

As soluções ficariam formalmente representadas da seguinte forma:

pessoa (cpf, nome, cep, bairro, rua, numero)
telefone (cpf, telefone)
cpf referencia pessoa

Dependência Funcional
Uma coluna C2 depende funcionalmente de C1 (ou C1 determina a coluna C2) quando, em todas as linhas da tabela, para cada valor diferente de C1, sempre aparece um mesmo valor de C2 associado. C1 -> C2.

C1       C2 ... outros campos
A         1
B         2
A         1
C         4
C         4
B         2
D         4
E         1

Traduzindo: sempre que eu vejo um valor de C1, eu já sei qual é o valor de C2.

Exemplo do mundo real: CPF e nome. Sempre que eu vejo o CPF eu já sei qual é o nome. Então CPF determina o nome e nome é dependente funcional de CPF mas o contrário não é verdade, podem existir duas pessoas com o mesmo nome. CPF -> nome

É preciso tomar cuidado, porque em um universo restrito, onde os nomes são todos diferentes, podemos achar que o nome também determina o CPF simplesmente por não percebermos ou não encontrarmos nenhum nome repetido no conjunto de dados disponível.

A dependência funcional é utilizada para se determinar a chave primária da tabela.

Segunda Forma Normal - 2FN
"Uma relação encontra-se na segunda forma normal (2FN) se e somente se estiver na primeira forma normal e não contém dependências funcionais parciais"

Suponha uma tabela empregadoProjeto definida da seguinte forma:

empregadoProjeto (cpf, num-projeto, horas, nome-empregado, nome-projeto, local-projeto)

Reparem que CPF determina nome-empregado. Num-projeto determina nome-projeto e local-projeto e a combinação de CPF e num-projeto determina horas. Ou seja, a dependência não é total da chave primária inteira, alguns campos dependem de uma parte e outros campos dependem da outra parte da chave, existe dependência funcional parcial.


Qual é o problema dessa abordadem? Porque normalizá-la?
 Imagine que um funcionário trabalha em vários projetos. O nome e CPF desse funcionário vai aparecer várias vezes na tabela, uma vez para cada projeto em que ele trabalha. Como um projeto sempre é composto por vários funcionários, o nome do projeto e o local também vão aparecer várias vezes na tabela.

Se você quiser alterar o nome do funcionário, nome ou local do projeto, você terá que alterar em vários locais.

Se o funcionário não estiver trabalhando em nenhum projeto no momento e você excluir todas as tuplas onde ele aparece trabalhando, você irá exlcuir o empregado do seu banco de dados. Se você demitir todas as pessoas de um projeto para contratar outras pessoas, ao excluir essas pessoas você irá excluir também o projeto. 

O correto deveria ser o seguinte

empregado (cpf, nome-empregado)
projeto (num-projeto, nome-projeto, local-projeto)
trabalha (cpf, num-projeto, horas)
cpf referencia empregado
num-projeto referencia projeto

Dependência Funcional Transitiva
Acontece quando uma coluna depende da chave primária e também depende de outra coluna ou conjunto de colunas da tabela. Existe uma coluna não-chave que é funcionalmente determinada por outra coluna (ou conjunto de colunas) não-chave.

Exemplo:
empregado-departamento (cpf, nome-empregrado, endereco, numero-depart, nome-depart, gerente-depart)

Repare que o nome-depart e gerente-depart também são dependentes de numero-depart.

Terceira Forma Normal - 3FN
"Uma relação está na Terceira Forma Normal se e somente se estiver na Segunda Forma Normal e nenhum atributo não-primo for transitivamente dependente da chave primária" Atributo não-primo é um atrbituo que não é membro de uma chave primária.

Traduzindo: para estar na 3FN a relação não pode ter dependência funcional transitiva.

Qual o problema que acontece na 3FN?
O gerente do departamento aparecerá várias vezes na tabela. Se o último funcionário de um departamento for deletado, o departamento some.

Para estar na 3FN, o exemplo anterior deveria ser feito da seguinte forma:

departamento(numero-depart, nome-depart, gerente-depart)
empregado(cpf, nome, endereco, numero-depart)
numero-depart referencia departamento 

Anomalias de Inserção - Inserir um empregado repete dados de departamento.
Anomalias de Exclusão - Excluir o único empregado também exclui o departamento
Anomalias de Modificação - Mudar o gerente de departamento requer a alteração de várias tuplas (linhas)

Forma Normal Boyce Codd (FNBC)
Toda relação na FNBC está necessariamente na 3FN. "Uma relação está na FNBC se para toda dependencia funcional de X em Z (df X -> Z), X é super-chave" É como a 3FN, mas é mais restritiva.

Chave Primária é uma Super-Chave mínima.

Abaixo uma relação da 3FN que não está na FNBC:

Aula (aluno, disciplina, professor)

ALUNO   DISCIPLINA   PROFESSOR
Carlos       Inglês               Joana
Carlos       Física               Antônio
Adriana     Inglês              Joana
Adriana     Português        Marta
Rafael       Português        Manoel

1FN - Não possui atributo atômico
2FN - Não possui dependência funcional parcial. Aluno e disciplina determinam professor. A dependencia funcional não é parcial
3FN - Não possui dependência funcional transitiva. Professor é o único atributo não-primo (que não é membro de uma chave primária) e ele não determina nenhum outro atributo não-primo. A dependência transitiva aconetce quando um atributo não-primo determina outro-não primo.

O problema dessa relação é que professor determina a disciplina e professor não é uma super-chave (Com professor não conseguimos diferenciar as tuplas unicamente).

Se Carlos sair da aula de Física e seu registro for excluído, não teremos como saber que Antônio também dá aula de Física.

Para resolver o problema podemos criar duas tabelas:

T1 (aluno, professor) e T2 (professor, disciplina)

Quarta Forma Normal - 4FN (pouco cobrado)
"Uma relação está na Quarta Forma Normal, se e somente se, estiver na 3FN e não contiver dependências multivaloradas."

O termo a se lembrar é: não possui dependência funcional multivalorada.

Lembrar do caso de ISBN, autores e assuntos, todos na mesma tabela. O ISBN se relaciona de forma independete com o autor e com o assunto. Um ISBN está relacionado a um ou mais autores e um ISBN está relacionado a um ou mais assuntos. O problema é que um IBSN se relaciona de forma independente com assunto e com autor.

ISBN   ASSUNTO   AUTOR
123      Java               Zezinho
123      Java               João
123      OO                Zezinho
123      OO                João

Devemos separar em duas tabelas, uma como ISBN e Assunto e outra com ISBN e Autor

Quinta Forma Normal - 5FN (pouco cobrado)
Não pode ter Dependência Funcional de Junção. Algumas relações precisam ser decompostas para entrar na 4FN. Só que se isso for feito em apenas duas tabelas, como exemplificado na 4FN, pode acontecer perda de semântica. Se for o caso, então é preciso que a decomposição seja feita em 3 ou mais tabelas.

Nesse caso, quando o caso do IBSN é dividido em duas tabelas e não é possível saber todos os relacionamentos originais só com as duas tabelas criadas, aconteceu perda de semântica. Então coloca-se uma terceira tabela para relacionar as outras duas. (algo assim)

"Uma relação R está na 5FN, também chamada de forma normalizada de projeção (PJ/NF) se, e somente se, toda dependência de junção em R for consequência de chaves candidatas de R."

Não boa. Só se preocupe com isso se você já domina tudo de banco de dados e das outras matérias e se for uma prova de TI.

Resumindo o resumo
1FN - Apenas atributos atômicos.

2FN - Estar na 1FN e sem dependência funcional parcial (chave primária composta e algum atributo é parcialmente dependente da chave primária)


3FN - Estar na 2FN e sem dependência funcional transitiva (atributo não-chave determinando atributo não-chave) Onde está escrito não chave, na verdade seria não-primo (não participa de chave) .

FNBC - Estar na 3FN e não pode existir um atributo A determinando outro B e sendo que A não é super-chave.


4FN - Estar na 3FN e não pode existir dependência funcional multivalorada. Caso do ISBN.


5FN - Estar na 4FN e não pode existir dependência funcional de junção. Caso do ISBN, mas com perda de semântica.