DBMS - Normalização

Dependência Funcional

Dependência funcional (FD) é um conjunto de restrições entre dois atributos em uma relação. A dependência funcional diz que se duas tuplas têm os mesmos valores para os atributos A1, A2, ..., An, então essas duas tuplas devem ter os mesmos valores para os atributos B1, B2, ..., Bn.

A dependência funcional é representada por um sinal de seta (→) ou seja, X → Y, onde X determina funcionalmente Y. Os atributos do lado esquerdo determinam os valores dos atributos do lado direito.

Axiomas de Armstrong

Se F é um conjunto de dependências funcionais, então o fechamento de F, denotado como F ⁺ , é o conjunto de todas as dependências funcionais logicamente implícitas pelos Axiomas de F. Armstrong são um conjunto de regras que, quando aplicado repetidamente, gera um fechamento de dependências funcionais .

Reflexive rule - Se alpha for um conjunto de atributos e beta is_subset_of alpha, então alpha conterá beta.
Augmentation rule- Se a → b é válido ey é o atributo definido, então ay → por também é válido. Ou seja, adicionar atributos nas dependências, não altera as dependências básicas.
Transitivity rule- O mesmo que regra transitiva em álgebra, se a → b é válido eb → c é válido, então a → c também é válido. a → b é chamado como um funcionalmente que determina b.

Dependência funcional trivial

Trivial- Se uma dependência funcional (FD) X → Y for mantida, onde Y é um subconjunto de X, então ela é chamada de FD trivial. FDs triviais sempre valem.
Non-trivial - Se um FD X → Y for válido, onde Y não é um subconjunto de X, então é chamado de FD não trivial.
Completely non-trivial - Se um FD X → Y for válido, onde x intersecta Y = Φ, é dito que é um FD completamente não trivial.

Normalização

Se o design de um banco de dados não for perfeito, ele pode conter anomalias, que são como um pesadelo para qualquer administrador de banco de dados. Gerenciar um banco de dados com anomalias é quase impossível.

Update anomalies- Se os itens de dados estiverem espalhados e não estiverem vinculados uns aos outros adequadamente, isso pode levar a situações estranhas. Por exemplo, quando tentamos atualizar um item de dados com suas cópias espalhadas por vários lugares, algumas instâncias são atualizadas corretamente enquanto outras são deixadas com valores antigos. Essas instâncias deixam o banco de dados em um estado inconsistente.
Deletion anomalies - Tentamos excluir um registro, mas partes dele não foram excluídas por falta de conhecimento, os dados também são salvos em outro lugar.
Insert anomalies - Tentamos inserir dados em um registro que não existe.

A normalização é um método para remover todas essas anomalias e trazer o banco de dados a um estado consistente.

Primeira Forma Normal

A Primeira Forma Normal é definida na própria definição das relações (tabelas). Esta regra define que todos os atributos em uma relação devem ter domínios atômicos. Os valores em um domínio atômico são unidades indivisíveis.

Reorganizamos a relação (tabela) como abaixo, para convertê-la para a Primeira Forma Normal.

Cada atributo deve conter apenas um único valor de seu domínio predefinido.

Segunda Forma Normal

Antes de aprendermos sobre a segunda forma normal, precisamos entender o seguinte -

Prime attribute - Um atributo, que faz parte da chave candidata, é conhecido como atributo principal.
Non-prime attribute - Um atributo, que não faz parte da chave principal, é considerado um atributo não principal.

Se seguirmos a segunda forma normal, então cada atributo não principal deve ser totalmente funcionalmente dependente do atributo de chave principal. Ou seja, se X → A for válido, então não deve haver nenhum subconjunto apropriado Y de X, para o qual Y → A também é verdadeiro.

Vemos aqui na relação Student_Project que os atributos-chave principais são Stu_ID e Proj_ID. De acordo com a regra, os atributos não-chave, ou seja, Stu_Name e Proj_Name, devem ser dependentes de ambos e não de nenhum atributo da chave principal individualmente. Mas descobrimos que Stu_Name pode ser identificado por Stu_ID e Proj_Name pode ser identificado por Proj_ID independentemente. Isso é chamadopartial dependency, o que não é permitido na segunda forma normal.

Rompemos a relação em dois, conforme ilustrado na imagem acima. Portanto, não existe dependência parcial.

Terceira Forma Normal

Para uma relação estar na Terceira Forma Normal, ela deve estar na Segunda Forma Normal e o seguinte deve satisfazer -

Nenhum atributo não principal é transitivamente dependente do atributo de chave principal.
Para qualquer dependência funcional não trivial, X → A, então -
- A é o atributo principal.

Descobrimos que na relação Student_detail acima, Stu_ID é a chave e o único atributo da chave principal. Descobrimos que a cidade pode ser identificada por Stu_ID e também pelo próprio Zip. Nem Zip é uma superchave nem Cidade um atributo principal. Além disso, Stu_ID → Zip → Cidade, então existetransitive dependency.

Para trazer essa relação à terceira forma normal, dividimos a relação em duas relações da seguinte forma -

Forma normal de Boyce-Codd

A Forma Normal de Boyce-Codd (BCNF) é uma extensão da Terceira Forma Normal em termos estritos. BCNF afirma que -

Para qualquer dependência funcional não trivial, X → A, X deve ser uma superchave.

Na imagem acima, Stu_ID é a superchave na relação Student_Detail e Zip é a superchave na relação ZipCodes. Então,

Stu_ID → Stu_Name, Zip

CEP → Cidade

O que confirma que ambas as relações estão no BCNF.