-- Normalização de Dados --

-> Trata-se de um processo de análise que visa assegurar que uma relação está bem
formada.
-> De forma prática, ela pretende decompor relações com anomalias, produzindo
relações menores e mais bem estruturadas. Dessa forma, com as relações
*normalizadas*, operações de inserção, remoção e atualização serão isentas de
anomalias.

-- Anomalias --

-> Problemas que ocorrem em bancos de dados, devido ao mau planejamento e má

modelagem.
^-> Excesso de dados em uma mesma relação
^-> Dados em locais errados
-> Existem anomalias de:
^-> Inserção;
^-> Remoção;
^-> Atualização;

-- Anomalia de Inserção --

-> Quando deve-se seguir uma ordem para inclusão de dados em uma relação

Ex:
Empregado(CPF_empregado (PK), nome_empregado, sigla_depto (FK))
Departamento (sigla_dpto (PK), nome_dpto)

-> Como sigla_dpto é uma chave estrangeira de Departamento, ao tentar inserir uma
tupla de empregado, é necessário que o Departamento já tenha sido criado, e que
essa chave já tenha sido inserida nessa relação.

-- Anomalia de Exclusão --

-> Ao excluir um registro em uma relação, os dados referentes aos registros em

outras relações devem ser excluídos

Ainda usando o exemplo:

Empregado(CPF_empregado (PK), nome_empregado, sigla_depto (FK))
Departamento (sigla_dpto (PK), nome_dpto)

-> Excluir um Departamento implica na exclusão dos empregados que trabalhavam

naquele departamento. O contrário configura uma anomalia de exclusão, ou seja, os
dados dos empregados continuam existindo após a exclusão do departamento onde
trabalhavam.
^-> Há a possibilidade de se colar o valor "NULL" na FK sigla_dpto

-- Anomalia de Atualização --

-> Ao alterar um registro em uma relação, os dados referentes aos registros em

outras relações devem ser alterados também

Ainda usando o exemplo:

Empregado(CPF_empregado (PK), nome_empregado, sigla_depto (FK))
Departamento (sigla_dpto (PK), nome_dpto)

-> A atualização da sigla de um departamento, por exemplo, deve atualizar as tuplas

referentes a ele na relação Empregado. O contrário configura uma anomalia de
atualização
-- Normalização de Dados (cont.) --

-> São testes feitos para certificar que uma relação satisfaz formas normais (FNs)
-> Boas relações atendem a, pelo menos, três formas normais
^-> 1FN
^-> Reprova atributos multivalorados, atributos compostos e suas combinações
^-> Atributos compostos são aqueles que podem ser dividos em mais de um
atributo, como o atributo "endereço"
^-> 2FN
^->
^-> 3FN
^->

-- Primeira Forma Normal (1FN) --

-> Na tabela Pessoa(CPF (pk), nome, endereço, telefone)

CPF Nome Endereço

448.347.458-80 Lucas de Mesquita Rua São Paulo, 428, Cidade Nova, BJP, SP,
Brasil

Telefone
(11)99859-2280
(11)97346-7101

-> O atributo "endereço" é composto, e o atributo "telefone" é multivalorado

-> Para começar a correção, devemos decompor o atributo "endereço" em atributos

menores:

-> Na tabela Endereço(logradouro, número, cidade, UF, país)

Logradouro Número Cidade UF País

Rua São Paulo 428 BJP SP Brasil

-> Já o atributo "telefone" deve ser transformado em uma nova tabela

-> Vários telefones pertecem a um telefone, um telefone pertence a uma pessoa

-> Na tabela Telefone(CPF (FK), ID(pk), telefone)

-> Se a relação entre CPF e Telefone fosse de N:N, o CPF e o ID formariam uma
terceira tabela, onde teriam a função de chave primária composta. A tabela telefone
seria formada apenas pelo ID e o telefone em si

-> Através desses passos, a relação está na 1FN

^-> Todos os valores são atômicos (indivisíveis)
^-> Há apenas um dado por coluna
^-> Existe, pelo menos, uma chave primária
^-> Não há relações aninhadas, ou seja, tabelas dentro de tabelas

-- Segunda Forma Normal (2FN) --

-> Deve estar na 1FN

-> Não há dependências parciais
^-> Na ocorrência de chaves primárias compostas, um atributo não-chave deve
estar dependente funcionalmente de ambas as chaves primárias
Ex:
-> Na tabela Empregado(id_membro(PK), id_tarefa(PK), nome, papel, descrição,
data_inicio, horas_alocadas)

-> Os atributos "nome" e "papel" estão dependentes apenas da chave primária

"id_nome"
-> Os atributos "descrição" e "data_inicio" estão dependentes apenas da chave
primária "id_tarefa"

-> Verifica-se, nesse caso, a necessidade de se criar duas tabelas separadas, cada
uma com suas próprias chaves primárias e atributos dependentes funcionalmente. Elas
serão unidas por um relacionamento, e a cardinalidade será de N:M.

-> tabela Membro(id_membro(pk), nome, papel)

-> tabela Tarefa(id_tarefa(pk), descrição, data_inicio)
-> relacionamento Realiza(id_membro(fk), id_tarefa(fk), horas_alocadas)

-> Através desses passos, a relação está na 2FN

^-> A chave primária é simples, ou seja, contém apenas um atributo
^-> Todo atributo não-chave é dependente funcionalmente de todo o conjunto de
atributos da chave primária.

-- Terceira Forma Normal (3FN) --

-> Deve estar na 2FN

-> Não há atributo não chave determinado funcionalmente por outro atributo não
chave (dependência transitiva)

-> Soluções:
^-> Para cada atributo não-chave que determina funcionalmente outro atributo,
deve-se criar uma nova tabela
^-> O atributo não chave em questão será a PK dessa nova tabela
^-> Todos os atributos funcionalmente dependentes da nova PK serão
transferidos para a nova tabela

Ex:
-> Na tabela Venda(nota_fiscal(PK), cod_vendedor, nome_vendedor, cod_produto,
qtde_vendida)

-> O atributo "cod_vendedor" determina funcionalmente o atributo "nome_vendedor",

mas não é atributo chave

-> Deve-se criar uma nova tabela "Vendedor"

Vendedor(cod_vendedor(PK), nome_vendedor)
relação Realiza(cod_vendedor(FK), nota_fiscal(FK))
Venda(nota_fiscal(PK), cod_vendedor(FK), cod_produto, qtde_vendida)