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 iguaisdependê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:
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 to 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 to 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
DepartamentoPKCOD_DEPARTAMENTONUMERONOM_DEPARTAMENTOCARACTEREProfessorPKCOD_PROFESSORNUMERONOME_PROFESSORCARACTERESOBRENOME_PROFESSORCARACTERESTATUSBOOLEANFKCOD_DEPARTAMENTONUMERO
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
TurmaPKCOD_TURMANUMEROPERIODOCARACTERENUMERO_ALUNOSNUMERODATA_INICIODATADATA_FIMDATAFKCOD_CURSONUMERO
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
CursoPKCOD_CURSONUMERONOME_CURSOCARACTEREFKCOD_DEPARTAMENTONUMERO
Em geral tabelas menores costumam já estar na 1FN
AlunoPKRANUMERONOME_ALUNOCARACTERESOBRENOME_ALUNOCARACTERENOME_RUACARACTERENUMERO_RUANUMEROCEPCARACTERESTATUSBOOLEANFILIACAOCARACTERESEXOCARACTERECONTATOCARACTERECPFCARACTERETELEFONECARCTEREFKCOD_CURSONUMEROFKCOD_TURMANUMERO
💡 Tabelas maiores tem mais chances de não estarem nas formas normais
Curso_DisciplinaPK,
FKCOD_DISCIPLINANUMEROPK,
FKCOD_CURSONUMEROHistoricoPKCOD_HISTORICONUMEROPERIODO_REALIZACAODATAFKRANUMERODisciplinaPK,
FKCOD_DISCIPLINANUMERONOME_DISCIPLINACARACTEREDESCRICAOCARACTERENUMERO_ALUNOSNUMEROCARGA_HORARIANUMEROFKCOD_DEPARTAMENTONUMEROAluno_DisciplinaPK,
FKRANUMEROPK,
FKCOD_DISCIPLINANUMERODisciplina_HistoricoPK,
FKRANUMEROPK,
FKCOD_DISCIPLINANUMERONOTANUMEROFREQUENCIANUMERO
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 primariaSomente POSSUI valores atômicos (atributos simples)As relações também NÃO possui os atributos multivalorados ou relações aninhadasrelações aninhadas são tabela dentro de outras tabelasRelaçã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 multivaloradoAssim 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:
AlunoPKRANUMERONOME_ALUNOCARACTERESOBRENOME_ALUNOCARACTERENOME_RUACARACTERENUMERO_RUANUMEROCEPCARACTERESTATUSBOOLEANNOME_MAECARACTERENOME_PAICARACTERESEXOCARACTEREEMAILCARACTEREWHATSAPPCARACTERECPFCARACTERETELEFONE_RESIDENCIALCARCTERETELEFONE_CELULARCARCTEREFKCOD_CURSONUMEROFKCOD_TURMANUMERO
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_INICIODATA_FIMHistoricoPKCOD_HISTORICONUMERODATA_INICIODATADATA_FIMDATAFKRANUMERO
Forma 2
🥈 Para estar no 2FN tem que:
Ser dependente do Spotify PK (Chave Primaria) -> caso contrario está fora
Regras da 2FN:
Estar na 1FNTodos os atributos simples são funcionalmente dependentes de todas as partes da chave primariaNão deve existir dependência parcial => ou seja. depende da PK e de outro campoAtributos 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 2FNProfessorPKCOD_PROFESSORNUMERONOME_PROFESSORCARACTERESOBRENOME_PROFESSORCARACTERESTATUSBOOLEANFKCOD_DEPARTAMENTONUMERO
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_AlunoPKCOD_TELEFONE_ALUNONUMEROFKRANUMEROFKCOD_TIPO_TELEFONENUMERONUMERO_TELEFONENUMEROTipo_TelefonePKCOD_TIPO_TELEFONENUMEROTIPO_TELEFONECARACTERE
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_AlunoPKCOD_ENDERECO_ALUNONUMEROFKRANUMEROFKCOD_TIPO_LOGRADOURONUMEROCEPCARACTERENUMERO_RUANUMERONOME_RUACARACTERECOMPLEMENTOCARACTERETipo_LogradouroPKCOD_TIPO_LOGRADOURONUMEROTIPO_LOGRADOUROCARACTERE
Agora a tabela Aluno ficara assim:
AlunoPKRANUMERONOME_ALUNOCARACTERESOBRENOME_ALUNOCARACTERESTATUSBOOLEANNOME_MAECARACTERENOME_PAICARACTERESEXOCARACTEREEMAILCARACTEREWHATSAPPCARACTERECPFCARACTEREFKCOD_CURSONUMEROFKCOD_TURMANUMERO
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 2FNNão existe dependências transitivasNenhuma 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=E2MJuCg87PWLMtCFhttps://www.youtube.com/watch?v=-2xK-fkqagIhttps://www.youtube.com/watch?v=XhLmF3-Ew8chttps://learn.microsoft.com/pt-br/office/troubleshoot/access/database-normalization-descriptionhttps://www.alura.com.br/artigos/normalizacao-banco-de-dados-estrutura?srsltid=AfmBOorWZZuuFq0g6ToGPC2OF-n8TMuQHE0z9QbJ3EXa_qUvSrr554gE
Deixe um comentário