oi oi pessoal na aula de hoje nós vamos falar sobre normalização para entender esse vídeo é fundamental que vocês tenham entendido o assunto de dependência funcional vou deixar o link aqui embaixo para o vídeo de independência funcional se você não tiver assistindo ele ainda a normalização é um processo de análise que visa assegurar que uma relação está bem informada a ideia é decompor relações relações aqui são tabelas com anomalias para produzir relações menores mais bem estruturadas as tabelas normalizados às podem passar por inserções remoções e atualizações sem anomalias as anomalias são problemas que ocorrem nos
bancos de dados decorrem do mal planejamento na hora de modelar os nossos dados a gente pode não modelar de forma muito adequada no diagrama de idade relacionamentos ou então a gente pode fazer uma modelagem boa mas na hora de implementar a gente implementa errado a três tipos de anomalias de inserção de remoção de atualização exemplo bom dia de inclusão o de inserção imaginem duas relações empregado e departamento empregado tem a sigla do departamento como chave estrangeira aqui a gente está falando de um relacionamento que é ou 1 para 1 ou um por um departamento para
n empregados como sigla de departamento é uma chave estrangeira quando a gente for inserir um novo empregado no banco de dados a gente precisa antes ter inserido a sigla do departamento no departamento ou seja a gente tem que ter criado o departamento para criar o empregado se a gente tentar inserir um empregado antes de criar um departamento a gente vai ter uma anomalia de inserção porque se dado não vai existir ainda anomalia de exclusão usando aí do nosso mesmo exemplo imaginem que eu excluo departamento do meu banco de dados mas eu não excluo departamento dos
meus empregados que trabalhavam nele é uma anomalia de exclusão se eu tenho um dado que foi retirado do departamento esse dado também tem que ser retirado de tô o legado que trabalhava naquele departamento então a remoção de um departamento implica na remoção dos empregados que trabalhavam para ele ou então a gente tem que colocar no no valor da seguinte o departamento anomalia de atualização segue a mesma ideia se eu atualizo a sigla do meu departamento eu tenho que atualizar essa segura também na tabela empregado para todos os empregados que trabalham nesse departamento se isso não
ocorre eu tenho uma anomalia de atualização quando nós temos as relações do nosso banco de dados normalizados as anomalias de inserção remoção e atualização não ocorrem por isso que a normalização é importante a normalização é um conceito que foi criado por boys cod e que foi divulgada em 1972 em um artigo bastante famoso trata-se de um conjunto de testes para certificar que uma relação satisfaz formas normais que a gente abrevia por fn boskot propôs que as relações boas é uma linhas atendem a pelo menos três formas normais que são 1fn 2fn 3fn então antes de
nós implementarmos o nosso banco de dados a gente precisa se certificar de que as nossas relações estejam todas na 3fn existem outras formas normais por exemplo da forma normal depois code que pode ser usado como uma alternativa a 3fn e a4 e a5 fnx nessa aula eu vou falar sobre a 1fn 2fn e três fm primeira forma normal 1fn para que uma relação esteja na primeira forma normal a gente não pode ter nenhum atributo multivalorado ou composto ou uma combinação dessas duas coisas lembrando que atributos compostos são aqueles atributos que podem ser divididos em atributos
menores e atributos multivalorados são aqueles que e tem mais de um valor vamos olhar essa tabela aqui pessoa cpf nome endereço e telefone são os atributos de pessoa nota em que endereço da forma como está aqui é um atributo composto por que a gente consegue separá-lo em rua número cidade-estado país cep por exemplo telefone tem um problema de ser multivalorado então a marta alves de souza possui aqui dois telefones o lázaro dias também possui dois telefones nós temos nessa tabela um atributo composto e um atributo multivalorado então ela não está na 1fn como que a
gente coloca essa tabela na 1fn para o caso dos atributos compostos a gente vai de compor o atributo em atributos menores então endereço vai ser subdividido em logradouro número cidade o estado eo país ou seja ao invés de endereço eu vou ter todos esses novos atributos aqui no caso do atributo multivalorado a gente vai transformar o atributo em uma nova tabela qual seria a lógica por trás desta modelagem uma pessoa possui vários telefones e um telefone vai pertencer a uma pessoa poderia pertencer a mais de uma também mas a que eu considerei pertencendo a uma
pessoa então a gente vai criar uma tabela que vai conter como atributo o telefone e essa tabela vai ter um e de que vai ser a sua chave primária e como chave estrangeira vai vir a chave primária da tabela anterior então cpf da pessoa vem para cá como chave estrangeira então ao invés de temos um atributo telefone em pessoa nós teremos pessoa com cpf nome o endereço desmembrado como no slide anterior e o telefone será uma outra tabela que vai conter e de como chave primária cpf como chave estrangeira e o telefone então notem que
o cpf zero 23698 não sei o que lá tem dois telefones ele então aparece duas vezes aqui em duas tuplas diferentes esse cpf no e um o primeiro telefone este mesmo cpf com e dois para outro telefone se a modelagem fosse n para m esse cpf junto com este id formaria uma chave primária composta de uma terceira tabela e a tabela telefone com teria apenas a chave primária e de sem o cpf resumindo então uma relação está na 1fn se todos os atributos são atômicos ou seja não consigo dividir luz não são compostos a apenas
um dado por coluna não tenho nada multi não existe pelo menos uma chave primária e não há relações alinhadas ou seja tabelas dentro de tabela nós identificarmos a possibilidade de formarmos outras tabelas a gente vai formar outra tabelas para colocarmos uma relação na primeira forma normal se o atributo for multivalorado a gente cria nova tabela se o atributo for composto a gente divide em sub-atributos segunda forma normal 2fn a relação está na segunda forma normal se ela estiver na primeira forma normal ou seja não pode ter nada composto em nada multivalorado e ela não com
tiver dependências parciais então a segunda forma normal exige que todas as relações tenham dependência total o que significa isso para o caso de chaves primárias compostas a chave composta como um todo deve determinar funcionalmente os demais atributos e não pode haver um atributo dependendo de apenas uma parte da chave primária composta vamos analisar essa tabela ela tem os campos e de membro e de tarefa nome papel descrição data de início e horas alocadas as será que ela está na 2fn se ela não estiver como a gente faz para corrigir esse problema prestar na 2fn ela
tem que estar na 1fn e ela não pode ter dependência parcial nós não temos nem atributos compostos nem atributos multivalorados aqui vamos analisar então os campos que são potencialmente chaves nesta tabela e de membro e de tarefa são potencialmente chave primária será que de membro sozinho é uma chave primária não porque já temos aqui uma repetição então não é sozinho uma chave primária e de tarefa sozinha é uma chave primária também não nós temos repetição aqui combinada será que elas podem formar uma chave primária é bom combinadas nós não temos repetições então pode ser que
sejam sim uma chave primária composta nesse caso ótimo vamos analisar os outros campos nome nome está associado ao ip membro opa se a chave primária é composta desses dois campos e pelo e de membro eu identifica o nome da pessoa então eu tenho um campo não chave dependendo funcionalmente de uma parte só da minha chave primária ou seja tem uma dependência parcial concluindo a relação não está na 2fn papel eu também sei o papel da pessoa pelo id do membro descrição descrição está relacionada a tarefa eu sei a descrição pelo id da tarefa então não
tem que eu tenho aqui uma tabela que deveria ser na verdade duas tabelas membro e tarefa a chave primária composta de de membro e de tarefa devem ser na verdade desmembrada com duas chaves cada uma delas em uma tabela uma tabela membro em uma tabela tarefa então eu tenho um problema de normalização da 2fn e eu corrijo isso transformando essa tabela em duas tabelas membro e tarefa então um membro realiza tarefa opa já sei as entidades e já tem um relacionamento aqui entre elas qual seria a cardinalidade aqui vamos analisar a mel que a melissa
ela executa o planejamento e orçamento e também executa o projeto de sistema ela executa as tarefas 1701 1701 logo um membro realiza mais de uma tarefa agora vamos analisar o outro lado dado uma tarefa quantos membros podem realizá-la a gente tem a tarefa projeto de sistema que a tarefa 1701 e ela está sendo executada tanto pela melissa a mel quanto pelo asdrubal aacd logo e a eva pode ser executada por mais de uma pessoa então nós temos uma cardinalidade n para m o pezinho de galinha aqui indica multiplicidade muitos para muitos é mesma coisa de
colocar eniac e m aqui legal já sabemos então a cardinalidade o que falta sabemos os atributos vamos analisar tabela de novo e de membro será a chave primária da tabela membro e de tarefa chave primária da tabela tarefa nome será um atributo de membro papel será um atributo de membro descrição será um atributo da tarefa então nós temos três atributos aqui para membro e temos dois atributos para tarefa e já sabemos as chaves primárias faltam dois atributos que são data de início e horas alocadas será que esses atributos são de tarefa de membro ou do
relacionamento entre eles dá uma olhada a tarefa projeto de sistema foi iniciada no mesmo dia para duas pessoas diferentes da mesma forma detalhamento de modelos também foi iniciada no mesmo dia implementação de componentes também foi iniciada no mesmo dia então por essa tabela dá a entender que a data de início está atrelada a a tarefa se por exemplo o projeto de sistema começasse no dia 15/2 para a melissa mas começasse no dia quinze do três para o asdrubal nós teríamos essa data de início como um atributo do relacionamento porque ela estaria dependendo tanto do membro
quanto da tarefa aqui eu vou assumir que data de início está atrelado a sua mente a tarefa vamos olhar horas alocadas projeto de sistemas tem 120 horas alocadas para uma pessoa e 180 horas alocadas para uma outra pessoa ou cê que horas alocadas não está relacionada exclusivamente a tarefa então não é um atributo de tarefa como pode ser data de início será que ela é um atributo de membro bom a melissa a mel tem 120 horas para este projeto aqui mas essa mesma mel tem 80 horas para um outro projeto ou seja horas alocadas é
claramente um atributo do relacionamento porque ela depende tanto da tarefa quanto do membro o nosso diagrama entidade-relacionamento então vai ficar assim membro com três atributos e de membros nome papel realiza com atributo horas alocadas as tarefa com os atributos e de tarefa descrição e data início lembrando que data início também poderia ser colocado aqui deixando o nosso diagrama mais genérico mas do jeito que está aqui ele contempla realidade da nossa tabela também nota em que quando pensarmos no modelo relacional para este diagrama aqui e teremos membro com uma chave primária que vai determinar funcionalmente os
outros dois campos então nós teremos dependência total nessa tabela nós teremos para a tabela tarefa uma chave primária determinando funcionalmente os outros campos então nós teremos também dependência total em tarefa nós não temos nada composto e nada multivalorado ou seja este diagrama está na 1fn e na 2fn a gente saiu de uma decisão de projeto completamente equivocada e bagunçada e a gente corrigiu essa decisão chegando nesse diagrama aqui perceba o quanto foi difícil a gente partir de uma decisão de projeto errada para gente corrigir essa decisão de projeto quando na verdade seria muito fácil e
direto a gente já conseguir modelar esse diagrama entidade-relacionamento aqui então quando a gente tem muito conhecimento o mini mundo a gente consegue elaborar diagramas entidade-relacionamento seus diretos ali pelo menos na segunda forma normal e isso já vai conomizar um baita trabalho para gente resumindo então uma relação que já está na 1fn está também na 2fn se a chave primária for simples óbvio porque aí não vai existir dependência funcional parcial ou se nenhum atributo não-chave existe na relação também é óbvio porque se só existir chave primária na relação também não a dependência parcial ou se todo
atributo não-chave é dependente é funcionalmente de tudo conjunto de atributos da chave primária terceira forma normal uma tabela está na terceira forma normal sexta na segunda forma normal e não há atributo não-chave determinado funcionalmente por outro atributo não-chave ou seja não a ver dependência transitiva para solucionarmos tabelas que estão fora da 3fn para cada dependência transitiva ou seja atributo não-chave determinando outro atributo não-chave a gente vai criar uma nova tabela o atributo não-chave será a chave primária dessa nova tabela e a gente vai mover os atributos dependentes funcionalmente dessa nova chave primária que a gente
acabou de criar para essa nova tabela confuso vamos ver um exemplo a gente tem uma tabela a chamada venda e ela tem como chave primária a nota fiscal e ela tem também os dados código do vendedor nome do vendedor código do produto e quantidade vendida opa pelo código do vendedor eu sei o nome do vendedor código do vendedor não é atributo chave então eu tenho uma dependência transitiva aqui como que eu resolvo isso simples eu vou criar uma tabela vendedor que vai ter esse e não chave da tabela venda como a chave primária de vendedor
e vou transportar esse nome parece tabela vendedor então vai ficar assim terei uma tabela chamada vendedor com o código do vendedor como chave primária e nome do vendedor o nome do vendedor deixa desistir nessa tabela aqui e passa a existir como atributo dessa tabela vendedor código do vendedor a chave primária aqui e como ele existe nessa outra tabela também ele vai ver como chave estrangeira e o problema está resolvido nós temos a tabela na primeira segunda e terceira formas normais espero que vocês tenham gostado do vídeo se gostaram do vídeo bem joinha aqui embaixo se
inscrevam no canal porque é muito importante para nós um abraço e até a próxima
