Normalização

ToC

• Normalização
• Dependências
  • Dependência Funcional
  • Dependência Funcional Parcial
  • Dependência Funcional Transitiva
• Formas
  • Antes de tudo
  • Forma 1
    • Aplicando
      • Tabela Aluno
      • Tabela Historico
  • Forma 2
    • Aplicando
      • Exemplo:
      • Aluno
  • Forma 3
• Referencias

O que é?

A normalização se baseia em dois pilares:

                     Formalização
╭──────────────────────────╮───────────────────────────╮
│          Menos           │          Menos            │
│        Dependência       │        Redundância        │
│         ╱    ╲           │         ╱    ╲            │
│        ╱      ╲          │        ╱      ╲           │
│       ╱        ╲         │       ╱        ╲          │
│      ╱          ╲        │      ╱          ╲         │
│     ╱            ╲       │     ╱            ╲        │
│    ╱              ╲      │    ╱              ╲       │
│   ╱                ╲     │   ╱                ╲      │
│  ╱                  ╲    │  ╱                  ╲     │
│ ╱                    ╲   │ ╱                    ╲    │
│╱                      ╲  │╱                      ╲   │
╰──────────────────────────╯───────────────────────────╯

Ou seja, a normalização de uma base de dados (tabelas) visa deixar o banco menos:

• redundante => muitas informações iguais
• dependência => menos dependência entre atributos Assim devemos fazer a verificação (ou seja, a normalização) no modelo lógico.

Dependências

As dependências são importantes conceitos que deve ser entendido e se trata daquela musica que o Cirilo canta: "Não existo longe de você";
É a mesma coisa que acontece quando um campo tem dependência em outro

Dependência Funcional

É dito quando tenho um atributo A e um B, tal que o B depende funcionalmente

Nessa dependência um atributo faz com que todos os outros sejam dependentes dele, por exemplo, em uma dependência funcional (DF) de uma entidade (ou tabela) alunos temos:

Matricula -> Nome
Matricula -> Sexo
Matricula -> Celular

Assim, precisamos saber a matricula para saber os atributos Nome, Sexo e Celular do Aluno

O inverso não funciona, já que sexo, celular e nem nome identifica a matricula do aluno
❗Lembre-se que a Matricula é um identificador que consegue identificar outros atributos

Dependência Funcional Parcial

É quando temos uma chave composta e os atributos tem uma dependência por parte da chave.

Por exemplo, para os dados de médicos:

CRM + SinglaEstado -> Nome, Sexo, EstadoEmissor

Note que a chave composta é: CRM + SiglaEstado. E o campo EstadoEmissor depende parcialmente da chave composta já que só precisa da SiglaEstado

💡 Quando temos apenas uma chave primaria simples, ela não terá dependência funcional parcial

Dependência Funcional Transitiva

É definido como uma dependência de um atributo não chave com outro atributo não chave.

Exemplo de DFT com dados de alunos:

Matricula -> Nome, CodCurso, NomeCurso

Tal que o campo não chave NomeCurso depende diretamente do campo não chave CodCurso
O campo chave neste exemplo é a Matricula

Formas

Existem cinco formas e elas são um conjunto de passos para aplicar nas tabelas (modelo lógico).

💡A 4FN e a 5FN não são usadas muito

Antes de tudo

Vamos praticar com um exemplo de um sistema para uma universidade

No campo COD_DEPARTAMENTOdependendo dos requisitos pode ser que um professor faça parte de um ou mais departamento, logo teríamos um atributo multivalorado e esse tipo de atributo não respeita a primeira forma, assim teria que aplicar a 1FN

Na turma também temos uma questão dependendo do requisito, podemos ter vários valores para as datas, assim teríamos um campo multivalorado e como bem sabe deveríamos então aplicar a 1FN neste campo, isto se nossa regra de negocio pedisse, mas ela não pede então deixaremos, assim como no campo COD_DEPARTAMENTO

Em geral tabelas menores costumam já estar na 1FN

💡 Tabelas maiores tem mais chances de não estarem nas formas normais

Forma 1

🥇 Para estar no 1FN:
Tem que ter um atributo único -> cada tabela deve ter sua PK

Não aceitamos fragmentados -> não ter campos multivalorados ou compostos e se tiver é só desmembrar os campos
✍️ É como dizia Jack Estripador: Corte sempre em picadinhos

Para um tabela atingir a primeira forma normal, deve-se seguir as regras:

• EXISTE uma chave primaria
• Somente POSSUI valores atômicos (atributos simples)
• As relações também NÃO possui os atributos multivalorados ou relações aninhadas
  • relações aninhadas são tabela dentro de outras tabelas
• Relação NÃO possui atributos compostos

Aplicando

Tabela Aluno

Como na tabela Aluno temos o campo FILIACAOque por sua vez é um capo que pode guardar mais de um valor, ou seja, filiação diz de quem você é filho e isso resulta em ter um pai e uma mãe => dois valores (a menos que seja um chiquititas).

• Logo precisamos desmembrar o campo FILIACAO -> por ele ser um campo multivalorado
• Assim deixaremos a tabela na 1FN

E temos o mesmo na tabela Aluno no campo CONTATOque pode receber tanto email, ou whatsapp ou outra forma de contato.

No campo TELEFONEacontece o mesmo. Já que teremos o telefone residencial e celular

Assim a nova tabela ficara:

Tabela Historico

Agora se olharmos para a tabela Historico temos o campo PERIODO_REALIZACAO que se refere a data de inicio e fim, ou seja, um campo com dois valores.

Assim a nova tabela ficara:

• Tiramos o campo PERIODO_REALIZACAO e adicionamos dois campos:
  • DATA_INICIO
  • DATA_FIM

Forma 2

🥈 Para estar no 2FN tem que:
Ser dependente do Spotify PK (Chave Primaria) -> caso contrario está fora

Regras da 2FN:

• Estar na 1FN
• Todos os atributos simples são funcionalmente dependentes de todas as partes da chave primaria
• Não deve existir dependência parcial => ou seja. depende da PK e de outro campo
• Atributos não dependem de chaves candidatas

Caso isso não estiver sendo atingido devemos fazer então uma nova tabela para os dados.

Um atributo-chave é um que é uma PK (Chave Primaria) ou é a parte de uma Chave Composta

Aplicando

Para aplicar devemos nos perguntar primeiro:

Tal campo, depende da PK?

• Caso positivo, então ta okay

  

• Caso negativo, é cilada bino

  

Exemplo:

Por exemplo na tabela Professor:

• Podemos nos perguntar -> NOME_PROFESSOR, SOBRENOME_PROFESSOR e STATUS depende de COD_PROFESSOR?
  • Positivo => logo a tabela Professor está na 2FN

Só devemos aplicar essa lógica nos atributos não chave (ou seja. em FK ou PK não aplicamos isso)

Aluno

Os campos Nome da Rua, Numero da Rua e CEP, não pendependem do RA do Alunos, eles não variam mesmo se o RA variar.

Se olharmos para Telefone_Residencial temos um problema, já que se mudar o RA pode ter a caso do telefone não mudar, então seria melhor colocar em outra tabela;

❗ Lembrando que podemos ou não fazer, isto é, o que estamos fazendo é uma convenção: é melhor fazer mas não é obrigatório

Telefone

Para obedecermos a 2FN iremos criar uma tabela para telefones dos alunos e para o tipo de telefone

Endereço

Como os campos que são do endereço ficam de forma parcialmente dependente do Aluno logo devemos criar uma tabela para o Endereço.

Agora a tabela Aluno ficara assim:

Forma 3

🥉 Para estar na 3FN tem que:
A pessoa deve ser dependente do estado (PK) e não de outra pessoa, ou seja não podemos ter atributos comuns que dependem de outros atributos comuns -> caso contrario está fora;
Ou então pense em classes, a classe dos operários devem ser dependentes dos patrões e não podem se juntar -> senão vão para outra tabela

Regras:

• Estar na 2FN
• Não existe dependências transitivas
• Nenhuma coluna não chave depender de outra coluna que não é uma chave

Caso não obedeça devemos criar uma nova tabela.

Como na 2FN, devemos nos perguntar, mas agora a pergunta muda um pouco já que devemos questionar se um atributo simples é dependente de um outro atributo simples, ou seja:

Por exemplo na tabela Professor:

• Podemos nos perguntar -> NOME_PROFESSOR é dependente de STATUS?
  • Vemos que não, já que se o status mudar o nome do professor não muda e vice-versa;

No caso, no exemplo ele já está na terceira forma normal. Então não precisa mexer com mais nada.

Referencias

• https://youtu.be/u6JYYOR_o6E?si=E2MJuCg87PWLMtCF
• https://www.youtube.com/watch?v=-2xK-fkqagI
• https://www.youtube.com/watch?v=XhLmF3-Ew8c
• https://learn.microsoft.com/pt-br/office/troubleshoot/access/database-normalization-description
• https://www.alura.com.br/artigos/normalizacao-banco-de-dados-estrutura?srsltid=AfmBOorWZZuuFq0g6ToGPC2OF-n8TMuQHE0z9QbJ3EXa_qUvSrr554gE