DEV Community

Cover image for Normalização
Mr Punk da Silva
Mr Punk da Silva

Posted on

Normalização

ToC

O que é?

A normalização se baseia em dois pilares:

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

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

Image description

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

Departamento
PK COD_DEPARTAMENTO NUMERO
NOM_DEPARTAMENTO CARACTERE
Professor
PK COD_PROFESSOR NUMERO
NOME_PROFESSOR CARACTERE
SOBRENOME_PROFESSOR CARACTERE
STATUS BOOLEAN
FK COD_DEPARTAMENTO NUMERO

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

Turma
PK COD_TURMA NUMERO
PERIODO CARACTERE
NUMERO_ALUNOS NUMERO
DATA_INICIO DATA
DATA_FIM DATA
FK COD_CURSO NUMERO

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

Curso
PK COD_CURSO NUMERO
NOME_CURSO CARACTERE
FK COD_DEPARTAMENTO NUMERO

Em geral tabelas menores costumam já estar na 1FN

Aluno
PK RA NUMERO
NOME_ALUNO CARACTERE
SOBRENOME_ALUNO CARACTERE
NOME_RUA CARACTERE
NUMERO_RUA NUMERO
CEP CARACTERE
STATUS BOOLEAN
FILIACAO CARACTERE
SEXO CARACTERE
CONTATO CARACTERE
CPF CARACTERE
TELEFONE CARCTERE
FK COD_CURSO NUMERO
FK COD_TURMA NUMERO

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

Curso_Disciplina
PK,
FK		 COD_DISCIPLINA NUMERO
PK,
FK		 COD_CURSO NUMERO
Historico
PK COD_HISTORICO NUMERO
PERIODO_REALIZACAO DATA
FK RA NUMERO
Disciplina
PK,
FK		 COD_DISCIPLINA NUMERO
NOME_DISCIPLINA CARACTERE
DESCRICAO CARACTERE
NUMERO_ALUNOS NUMERO
CARGA_HORARIA NUMERO
FK COD_DEPARTAMENTO NUMERO
Aluno_Disciplina
PK,
FK		 RA NUMERO
PK,
FK		 COD_DISCIPLINA NUMERO
Disciplina_Historico
PK,
FK		 RA NUMERO
PK,
FK		 COD_DISCIPLINA NUMERO
NOTA NUMERO
FREQUENCIA NUMERO

Forma 1

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

Image description

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
Image description

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:

Aluno
PK RA NUMERO
NOME_ALUNO CARACTERE
SOBRENOME_ALUNO CARACTERE
NOME_RUA CARACTERE
NUMERO_RUA NUMERO
CEP CARACTERE
STATUS BOOLEAN
NOME_MAE CARACTERE
NOME_PAI CARACTERE
SEXO CARACTERE
EMAIL CARACTERE
WHATSAPP CARACTERE
CPF CARACTERE
TELEFONE_RESIDENCIAL CARCTERE
TELEFONE_CELULAR CARCTERE
FK COD_CURSO NUMERO
FK COD_TURMA NUMERO
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
Historico
PK COD_HISTORICO NUMERO
DATA_INICIO DATA
DATA_FIM DATA
FK RA NUMERO

Forma 2

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

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

    Image description

  • Caso negativo, é cilada bino

    Image description

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
Professor
PK COD_PROFESSOR NUMERO
NOME_PROFESSOR CARACTERE
SOBRENOME_PROFESSOR CARACTERE
STATUS BOOLEAN
FK COD_DEPARTAMENTO NUMERO

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

Telefone_Aluno
PK COD_TELEFONE_ALUNO NUMERO
FK RA NUMERO
FK COD_TIPO_TELEFONE NUMERO
NUMERO_TELEFONE NUMERO
Tipo_Telefone
PK COD_TIPO_TELEFONE NUMERO
TIPO_TELEFONE CARACTERE
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.

Endereco_Aluno
PK COD_ENDERECO_ALUNO NUMERO
FK RA NUMERO
FK COD_TIPO_LOGRADOURO NUMERO
CEP CARACTERE
NUMERO_RUA NUMERO
NOME_RUA CARACTERE
COMPLEMENTO CARACTERE
Tipo_Logradouro
PK COD_TIPO_LOGRADOURO NUMERO
TIPO_LOGRADOURO CARACTERE

Agora a tabela Aluno ficara assim:

Aluno
PK RA NUMERO
NOME_ALUNO CARACTERE
SOBRENOME_ALUNO CARACTERE
STATUS BOOLEAN
NOME_MAE CARACTERE
NOME_PAI CARACTERE
SEXO CARACTERE
EMAIL CARACTERE
WHATSAPP CARACTERE
CPF CARACTERE
FK COD_CURSO NUMERO
FK COD_TURMA NUMERO

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
Image description

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

Top comments (1)

Collapse
 
matheusvict profile image
Matheus Victor •

Conteúdo extramente completo e direto ao ponto. O autor conseguiu reunir imagens que mostram a relevância do assunto. Só tenho duas palavras, para béns

Read next

sarvabharan profile image

System Design 03 - Load Balancing: Because Even Your System Needs to Chill

Sarva Bharan -

patrick_61cbc6392b72286f6 profile image

Improve REST API development efficiency with EchoAPI for VSCode.

Patrick -

patrick_61cbc6392b72286f6 profile image

10 Best Postman Alternatives in 2024 | Free & Open Source Tools

Patrick -

wizzyb profile image

Provide storage for the IT department testing and training

Wisdom Benson -