Olá mais uma vez aqui dando continuidade até os vídeos anteriores A ideia que o foco desse vídeo em específico é da gente trabalhar com normalização tá normalização basicamente bem né o objetivo que a gente possa reduzir inconsistência na nossa base de dados então é o que que seria até um exemplo de inconsistência é ter enfim você passa e vai no supermercado para você passar uma lata de refrigerante tem um preço e outra pessoa tem outro preço para o mesmo produto ou ainda tem o mesmo código de barras passa dois produtos completamente diferentes então sabe essas
coisas que realmente não fazem muito sentido então isso aí entra nesse universo de inconsistência de dados a nossa ideia é Poxa estou vendo algo de barras de uma lata de refrigerante A ideia é que quando eu passar lá no caixa aquele mesmo código de barra seja exatamente aquele tipo de refrigerante e naquele preço que eu vi na gôndola né então até essa consistência ela passa uma segurança nos dados né uma segurança realmente e que aquela informação que nós estamos vendo né que nós estamos trabalhando ela realmente faz sentido no dia a dia então isso é
muito importante aí para a gente é realmente trabalhar com base de dados outro exemplo de inconsistência que eu imagino que você não queira que aconteça você tem lá o seu a sua conta corrente cadastrada né sua agência você está trabalhando em uma empresa e aí simplesmente você não recebe seu salário porque alguém esqueceu de atualizar na base de dados alguma coisa e ainda que tem Bregue toda a documentação realmente você não está recebendo salário correto então né não está recebendo dinheiro Isso não é nada legal e também poderia ser uma inconsistência tá para resolver em
consciências a gente tem um passo a passo imagine realmente uma pirâmide né Nós temos uma base nós entendemos que todas as regras aquela base estejam aqui e aí nós vamos o segundo nível quando tudo estiver correto naquele segundo nível nós vamos para um terceiro nível e assim por diante o nome desses níveis são formas normais então por isso que a gente tem lá primeira forma normal segunda forma normal terceira forma normal e assim por diante nós temos naturalmente outros tipos de formas normais ou seja não existem somente essas três a gente também pode ter até
outros quer dizer um banco de dados real não necessariamente tem que estar Obrigatoriamente na terceira forma normal não não é isso cada caso realmente vai ser um caso específico né tudo tem seus prós e contras seja custo performance inconsistências mesmo e assim por diante mas é um bom entrevista profissional é importante que pelo menos você saiba como deixar na primeira forma normal né como até diferenciar uma quantidade não normalizado para um que esteja nessa primeira forma normal tá então até para trabalhar com isso eu peguei o exemplo lá da marmitaria né que nós vimos anteriormente
e resolvi enfim dá algumas pequenas modificações só para a gente começar a pensar nessas formas normais tá então de propósito Eu fiz algumas pequenas alterações nessa nesse diagrama né que você está vendo na sua tela só para gente conseguir trabalhar com a forma normal tá então assim primeiramente para que esse banco te dados ele esteja em uma primeira forma normal ele Obrigatoriamente tem que seguir algumas regras de uma forma resumida essa regra seria esse banco de dado se ele Obrigatoriamente em todas as suas tabelas ele não tem que ter nenhum valor multi valorado o valor
composto É tem que seguir de novo essa regra o que que seria um valor multi campo né multi valorado ou até mesmo composto olhando aqui na tabela cliente você pode ver que nós temos código de cliente nós temos nome nós temos telefones e até eu poderia ter aqui um endereço completo Qual que é o problema aqui tá se eu der um zoom nesse cliente você verá que nós temos de novo telefones e endereço completo nós temos aqui dois pequeninos pequeninos problemas tá primeiro o telefone como está no plural eu poderia ter 01 mais de um
enfim isso realmente não é ele poderia ter mais de um valor dentro desta deste dessa coluna chamada telefones isso não é muito legal tá outra endereço completo que que a gente pensa quando falamos endereço completo eu posso ter o logradouro né que a rua Avenida Enfim eu posso ter o número daquela residência Posso ter o CEP Posso ter o bairro Então são vários sub Campos que deu uma entrevista de vida real ele usa habilidade faria mais sentido quebrar né ou seja dividir segregar essa informação em colunas menores então o campo multievalorado aqui seria o telefones
tá porque eu posso ter mais de um telefone e Outro seria o endereço completo para resolver isso nós temos algumas alternativas então no caso do endereço completo eu posso simplesmente tirar essa coluna tá então vou remover que o endereço completo e eu vou criar outras colunas que realmente seriam Campos separados que em conjunto formariam esse endereço posso até então logradouro eu posso ter quem sabe número da residência eu posso ter complemento que pode ser bloco apartamento Enfim eu posso ter o CEP posso ter um município e eu posso ter a Unidade Federativa também Então olha
só nesse caso eu já quebrei aquele endereço em várias outras coluninhas aqui tá até deixa eu também de novo fazer essa colocar esses como obrigatórios Unidade Federativa pode ser obrigatório o município sim CEP também complemento não necessariamente né porque nem todas as casas possuem complemento até a residência pode ser algo opcional dependendo do caso porque também nós temos endereço que não tem número então aqui já faria essa alteração Beleza o segundo ponto são os telefones veja que os telefones como está no plural posso também quebrá-los sem em uma outra tabela que até eu posso ter
os telefones como se socialmente um relacionamento sabe de zero para ele então para resolver isso uma coisa que eu poderia não deveria tá eu já vou explicar porque que tá errado é fazer aqui um apagar né o telefone vou descer aqui eu vou fazer um telefone um telefone 2 telefone 3 e assim por diante isso não é uma boa prática por quê na primeira forma normal eu preciso ter nomes únicos de colunas então como eu tenho um telefone repetido três vezes aqui isso ainda não obedece a primeira forma normal até porque imagina a ciência alguém
tiver um quarto telefone um quinto telefone ou como impedir né que o pessoal faz cadastro do mesmo telefone repetido três vezes aqui então para deixar na forma normal eu apago esses três telefones eu posso criar aqui uma outra tabela chamada telefone clientes ou cliente lentes telefones quando a gente faz muitas tabelas é legal ter esse padrão no começo vai chover cliente cliente endereço cliente telefone enfim então por isso que poderia fazer sentido dessa forma código do cliente e telefone vou deixar ele como obrigatório e até se quiser eu poderia deixar o próprio telefone como chave
primária né só para permitir um único telefone ou melhor Mônica combinação de telefone por cliente mas eu vou deixar aqui dessa maneira por enquanto tá E aqui vou fazer aquela ligação né lembra da fechadura enfim Ou melhor se eu deixar a chave primária do código de cliente eu somente autorizaria né o único telefone aqui então ou eu deixo assim ou eu deixo os dois como Chaves primárias E aí o telefone vamos lá no conta-gotas aqui fechadura e chave e pronto aí as tabela né do cliente já está na nossa primeira forma normal se olhar aqui
nas demais tabelas eu tenho uma outra inconsistência que seria que impedidos olha só tá vendo tem um código cardápio está no plural Então isso é bem parecido com o vídeo né que seria lá da resolução da conversão de um modelo conceitual para o modelo lógico em que eu coloquei né aquele item expedidos né que seria um caso específico que um pedido poderia ter mais de uma marmita então aqui seria um exemplo disso né Tem quase o cardápios é muito valorado posso ter mais de um tipo de marmita sendo solicitado para resolver esse código cardápios também
poderia criar uma outra tabela então aqui pausar os segundos só para recriar aquela tabela para você pronto pronto olha só então aqui nós em tese já estaríamos na primeira forma normal de uma forma bem resumida tá então de novo primeiro a forma normal a ideia é garantir que nossa tabela não tenho nenhum nenhum atributo que seja composto ou multi valorado e se inclui até enfim garantir que tenha né o nome único evitar aquele telefone 1 telefone 2 telefone 3 e de uma forma que nós consigamos salvar várias linhas de uma forma que essa ordem que
nós vamos sair cadastrando armazena nos dados realmente não não acaba influenciando um no outro tá então aqui de novo nós já estamos na primeira forma normal e mais um passo seja estar na segunda forma normal primeiro a gente tem que garantir que está na primeira forma normal né que todas as regras a primeira forma normal estejam sendo seguidas e na segunda que a gente começa a a garantia que nós tenhamos uma dependência funcional completa o que que isso significa significa que todos os atributos que não são chaves eles precisam estar completamente relacionados a todas as
chaves então olhando aqui por exemplo pega a tabela clientes todas as informações que nós estamos vendo aqui de um cliente poderiam realmente ter um relacionamento exclusivo com aquele cliente né então todos os dados que são aqui realmente se referem a um cliente específico agora se eu olho por exemplo é o pedido né tinha esquecido de remover o preço marmita Deixa eu só remover ele para garantir que realmente está na primeira forma normal aí Quando eu olho aqui a tabela como ela está criada Eu tenho um probleminha no item expedido se olhar aqui no item expedido
Olha só eu tenho três atributos não tem o código pedido eu tenho um código do cardápio e o preço tá deixa eu dar um zoom aqui nessa tabela como eu tenho um código do pedido eu tenho um código do cardápio nós temos o preço o preço Ele é o único atributo que ele não é dependente melhor Ele é o único atributo que ele não é uma chave primária aqui nós precisamos garantir que o preço ele esteja completamente relacionado com os dois porém se a gente esquecer um pouco a quantidade de pensar na vida real preço
ele é um preço de uma marmita né se gente ignorar por exemplo descontos ou qualquer coisa do gênero o preço de novo ele é um preço exclusivo do cardápio ele não tem nada a ver com pedido né não tem sido Puxa meu amigo né vou dar em um desconto não preço é o que tá lá no cardápio então independentemente do pedido tem que pagar para aquilo então de novo esse preço aqui nós não temos uma dependência completa porque o preço ele está relacionado com um cardápio e não com o pedido tá de novo neste exemplo
aqui então para corrigir isso eu tenho que remover o preço que está aqui E aí eu tenho que colocar dentro de marmitas porque aí de novo o preço ele somente tem uma relação com a marmita né e não tem nada a ver com pedido e aqui já estaria na segunda forma normal então com a linha né dica garantir que cada atributo que não é chave ele possui dependência exclusiva daquela chave tá então é isso já garantiria que estaria na segunda forma normal Então beleza nós temos de novo primeira forma normal tá beleza segunda forma normal
então nós já avançamos um passo aqui a ideia é evitar dados redundantes então Imagine só eu tô salvando 15 pedidos hoje a gente feijoadas não faz sentido essa 15 vezes na base de dados aquele mesmo preço da Feijoada tô gastando espaço é muito dinheiro tá pensando aí grandes falando de dados e só para salvar uma informação repetida 15 vezes então isso ajuda a reduzir redundância e obviamente evitar até inconsistência imagine lá eu tenho hoje pediram 15 feijoadas e cobrei de uma forma diferente cada uma das feijoadas Isso não é legal então por isso que a
segunda forma normal né ela ajuda a resolver esse cenário aqui garantindo que nós passamos da primeira e da segunda forma normal daí nós temos finalmente a terceira forma normal a terceira forma normal ela basicamente garante que estejamos primeira forma normal na segunda forma normal e também que nós não tenhamos nenhum tipo de dependência transitiva O que que é uma dependência transitiva tá de uma forma bem simples é quando o relacionamento entre melhor relação que o termo relacionamento pode confundir quando a ligação entre uma chave primária e um atributo da mesma tabela não dependem diretamente um
do outro mas sim de um intermediário olha por exemplo aqui o cliente se a gente pegar por exemplo Curitiba né Curitiba é um município e o estado é Paraná o município de Curitiba ele é dependente do Estado porque afinal de contas Curitiba fica dentro do Estado do Paraná mas quando a gente pensa no código do cliente não tem nenhuma dependência assim direta entre o código do cliente e o município quer dizer existe o CEP não existe aí existem essas informações mas tanto aí o município Quanto estado até mesmo o logradouro né eles dependem do CEP
Então até se eu fizer aqui um cadastro da forma que está essa tabela clientes na prática poderia cadastrar um Curitiba São Paulo Curitiba Rio Grande do Sul Curitiba Paraná e ainda que a gente estivesse falando dessa capital né do Estado do Paraná eu teria o erro melhor problema de cadastrar ele em Estados separados em uma informação que seria incorreta então isso seria um problema e Independência transitiva para resolver isso eu tenho que garantir que toda vez que estiver falando de Curitiba que é a capital do Estado do Paraná Eu Sempre tem aquela combinação de município
Curitiba estado Paraná tá então para resolver isso também poderia criar uma nova tabela vejamos antes de tudo isso daqui eu poderia criar sabe diminuir quem primeiro um pouco Zoom né eu vou criar mais uma tabela da chamada endereços o endereço eu poderia princípio teu CEP cada CEP ele teria aí um município e também ele poderia ter uma Unidade Federativa uma coisa que eu confesso que eu não me lembro é se hoje em dia cada CEP ele seria aí um logradouro específico ou seja né uma rua ele seria equivalente uma ruim específico até tempos atrás realmente
tínhamos ceps que era pertencente uma cidade inteira então eu não tinha necessariamente o mesmo CEP para ruas diferentes não sei se ainda hoje é assim tá vamos partir da premissa que sim um CEP ele seja sempre compatível a uma rua específico de uma cidade específico Então nesse caso seria o município o f e logradouro tá então nós teríamos essas quatro informações aqui daí eu removo dentro do cliente o f removeria também o município e também eu removeria o logradouro ficando somente o número da residência e o complemento e daí o CEP naturalmente é uma fechadura
que vem lá do endereço então aqui ó e é isso é um ponto também que é importante de você saber sobre Chaves primárias até pensando um cliente né que tem um CPF ou não o endereço que tem o CEP não é legal a gente usar como chave primária atributos que nós não temos controle interno por exemplo CPF raramente nós utilizaremos aí o CPF como sendo uma chave primária e um banco chamado real ou um CNPJ qualquer coisa assim porque você pode mudar o CPF né que nem anteriormente existia o CIC no lugar de CPF o
próprio CEP né temos endereços que com o passar das décadas mudam o próprio código do CEP então não surgiram muito né utilizar aí o CEP CPF CNPJ como Chaves primárias e até quem sabe um código do endereço que aí sim é uma chave primária Deixa eu subir aqui um pouquinho o CEP dele Deixa de ser uma chave primária e o Marcos caixinha chamada o q de unique eu já vou explicar isso em um outro vídeo sobre essas caixinhas e os tipos de dados mas aqui eu já não permitiria que eu tivesse mais de uma entrada
com o mesmo CEP tá então enfim aqui nós já entendesse garantiríamos que a nossa base de dados estaria na terceira forma normal obedecendo aquelas regras de a dependência transitiva Então é isso de uma forma resumida né que eu queria trazer para vocês esses pontos sobre que que é a diferença das formas normais como que isso funciona na prática e como que nós resolvemos isso na prática partindo naturalmente os exemplos que nós já vimos na literatura beleza é isso e até a próxima [Música]
