Olá pessoal tudo bem com o professor Everson Estamos aqui na nossa web aula 4 da disciplina de sistemas de banco de dados tudo bem com vocês Pessoal espero que todos estejam bem nessa web aura nós vamos ver o assunto normalização de dados [Música] muito bem pessoal então estamos aqui na nossa unidade 4 tratando do assunto normalização de dados antes da gente entrar em normalização de dados nós vamos verificar ainda as fases do projeto de banco de dados nós já vimos nas aulas anteriores Vamos Fazer Uma Breve revisão e vamos conhecer os conceitos e objetivos da
normalização de dados muito bem pessoal então vamos começar Então quais são os benefícios que nós temos da modelagem de dados Então a partir do negócio A modelagem de dados nos traz oportunidades e ficasse incrementada a resposta de mudança certo isso no âmbito do negócio podemos ainda a partir dessa modelagem de dados reduzir os riscos certo e reduzir os custos ainda como avaliando as situações e implementando melhoria num processo certo ainda nós temos na espera do suporte é uma possibilidade de integração do sistemas à medida que a gente levanta as entidades e podemos utilizar o reuso
daquelas entidades que nós chamamos de Dados Mestres certo com uma integração do sistema e também com Interface com relação a dados né vamos tratar as questões do mínimo de redundância e dados compatíveis com o negócio que nós estamos apoiando isso tudo A modelagem de dados nos traz como benefícios desde sistemas de dados até o próprio negócio nas reflexões que podemos ter é fruto dessa abstração da modelagem certo muito bem então aqui a gente relembra o processo né de construção é de um banco de dados a gente parte então de uma especificação dos requisitos né Então
essa especificação vai vai levar em consideração o mundo real de como as coisas acontecem e mesmo a gente apresentando uma entidade ela pode ter contexto diferentes dependendo do negócio que nós estamos modelando né vamos é um esquema conceitual que independe do sistema gerenciador de banco de dados Então esse esquema conceitual está é para o modelo conceitual Então nós vamos desenvolver esse esquema conceitual é para que a gente resolva o problema de persistência de dados que aquele sistema ele precisa né Então dependendo do sistema ele vai preservar persistir dados e quais dados a gente vai fazer
isso na especificação de requisitos e encontrar essa solução para necessidade de armazenamento certo então o primeiro passo é desenvolver um esquema conceitual um modelo conceitual para que a gente consiga abstrair as entidades as características dessas entidades na forma de atributos e depois os relacionamentos entre elas depois nós vamos passar para a próxima etapa que o esquema lógico a partir do esquema lógico a gente já começa a ter uma dependente ao sgbd você é uma gerenciador de banco de dados vamos resolver algumas questões aqui né que ficaram no modelo conceitual e isso é aceito e vamos
refinar ainda mais esse modelo lógico até um esquema físico certo aonde nós temos a origem do projeto físico de banco de dados aqui só que então nós estamos revisando aquilo que nós já vimos nas aulas anteriores mas é importante Então olha só é considerando aqui os tipos de modelo de dados nós temos aqui o modelo conceitual que o grande objetivo é abstrair quais são as entidades que nós temos e como essas entidades se relacionam também é importante que a gente já tem a elaboração a concepção dos atributos que são as características né dessas entidades mas
o principal aqui é o modelo do modelo conceitual é o levantamento das entidades e seus relacionamentos no caso aqui é período com vendas produto com vendas e estoque com vendas e também em Alto Nível A gente considerar os atributos E aí a gente pode estar nesse momento trabalhando com atributos compostos muito valorizados atributos Chaves identificadores o importante é que a gente consiga aqui uma um primeiro desenho o primeiro rascunho de como o nosso banco vai surgir então na aula 3 a nossa web aula 3 A gente trabalhou bastante com o diagrama entidade melhor dizendo o
modelo de relacionamento que tem um passo a passo ali para que a gente consiga conceder essas entidades do modelo conceitual vocês percebam aqui pela figura que a partir da transformação desse modelo conceitual em um modelo lógico a gente já começa a ter é uma figura onde a grama diferente né então a gente já contempla aqui as questões é dos atributos Já começamos a considerar um sgbd que vai ser utilizado como objeto dessa modelagem e a gente principalmente resolve questões como generalização especialização aqui no modelo lógico Então a gente tem os relacionamentos um ou muito para
muitos resolvendo a generalização e também resolvemos as questões de entidade associativa né onde ele surgiram fruto de um de uma carnalidade de relacionamento muitos e n para n então do modelo conceitual é aceito aqui no modelo lógico a gente já resolve essa situação do mundo para muitos trazendo uma tabela associativa certo entre essa solução e depois a gente aprimora ainda mais esse modelo com modelo físico certo aonde aqui nesse modelo físico a gente tem todas as construções de banco né fora em que né então note Lu chave estrangeira a chave primária as questões de cheque
construiente e de unique perfeito aqui considerando todos no modelo físico tipo de dados também importante porque ele é totalmente aderente ao sgbd que nós estamos criando Então se a gente for utilizar o órgão a gente vai utilizar um tipo de dado vamos usar o pós-grêmiosql vamos usar um outro tipo de dado né para representar o mesmo número por exemplo Então dependendo do sgbd a gente vai escolher os data types né os tipos de dados correspondente e acaba coluna conforme nós vimos no modelo relacional e esse modelo vai ficar pronto para que a gente consiga então
é criar o script SQL a partir desse modelo de dados físicos em algumas ferramentas né case de engenheiro software auxiliado por computador nós podemos ter o addl né a linguagem de definição de dados automaticamente né mas se você não tem a disposição a essa ferramenta você pode desenvolver os comandos para criar os objetos do banco conforme o os operadores da linguagem as quer então o cliente table vai colocar os campos do tipo de dado as construintes e enfim Todas aquelas particularidades do modelo físico são importantes aqui então a gente revisando o projeto de banco de
dados o modelo conceitual então é um modelo que vai ser vai definir a comunicação em relação em Alto Nível entre entidades e aqui a gente pode perceber que a as entidades aluno disciplina Professor com seus atributos específicos aqui cada um deles tem e os relacionamentos aqui por exemplo aluno estuda em disciplinas e uma disciplina é estudada por n alunos Aqui nós temos um mundo para muitos nesse modelo isso é tranquilo né que a gente está representando como as coisas acontecem no mundo real mas na transformação desse modelo então em um modelo lógico isso já já
resolvido chamando atenção aqui também para um sublinhado em alguns atributos é representando o atributo chave né que vai ser transformado em chave primária quando a gente chegar lá no modelo físico né e os relacionamentos entre as entidades né da forma que a gente tem um professor lecionando em disciplina se uma disciplina é relacionada por um somente um professor Ok então a gente já viu essas questões e são importantes que a gente conheça essa essa questão do modelo conceitual principalmente para a gente trabalhar com normalização né então a normalização a gente vai aplicar normalmente lá entre
o modelo lógico e o modelo físico certo aqui ainda a gente tá no mundo das ideias a gente é tá em alto nível aqui e a gente vai ver que a normalização ela vai dar uma refinada aqui nesse modelo né para verificar se cada Campo está de acordo em cada entidade quando eu falo no campo eu tô me referindo a modelo físico então entidade atributo tabela coluna tá bom ou campo vamos lá então olha só a gente tem aqui um esquema representando duas entidades pessoa e carro aonde nós temos atributos CPF nome e Sexo para
pessoa e os atributos placa modelo e ano para carro CPF ou atributo chave para pessoa placa é um atributo chave para carro e a gente tem aqui a carnalidade onde uma pessoa dirige e n carros e um carro dirigido por n pessoas então quando a gente está no mundo conceitual no modelo conceitual isso é aceitável e aqui a gente já vai resolvendo essas questões para o modelo lógico Já prevendo aqui as questões dos tipos de dados né que a gente vai ter no sgbd que são importantes do modelo físico e a gente já vai dependendo
da cardinalidade mapeada aqui nesse mundo ele conceitual a gente pode ter aqui a questão é da resolução dos muitos para muitos só que aqui a gente percebe que é a placa do carro aqui que a chave primária né aqui no nesse modelo lógico ela está sendo referenciada na pessoa então a pessoa tem um carro né e um carro só pode ser de uma pessoa nesse exemplo que foi implementado com essa regra de negócio perfeito Então a gente tem que levar em consideração aquilo que foi passado Qual é a regra de negócio não como a gente
acha que deve ser a coisa talvez em um mini mundo né isso tem sentido mas a gente tem aqui é a placa né como chave estrangeira é da tabela carro que já no mundo lógico no mundo do modelo lógico ok então o modelo Lógico né diferente do conceitual é onde nós já temos um tipo de banco de dados já em mente né como ele serve no órgão ou uma SQL então a gente representa essa estrutura já com as questões de entidades positiva resolvidas e as questões de higienização também resolvidas Tá certo isso é importante essas
considerações já o modelo físico Aqui nós temos o grande objetivo de ter todas as características da implementação em um banco de dados Chaves primárias estrangeiras métodos de acesso se um cão foi sem indexado ou não se aquele se aquela tabela vai ser parte do sinal partirocinada em vários em várias tabelas Isso é uma técnica para otimizar Consultas por exemplo por ano a gente faz uma partição por ano e a gente leva para memória só naquele ano na consulta enfim são são situações é que a gente deve em consideração totalmente o sistema gerenciador de banco de
dados onde vai ser implementado esse banco de dados Ok então é essa esse é o grande objetivo e a gente vai trabalhar um pouco mais com essa questão da implementação do modelo físico como o banco de dados a partir da nossa unidade cinco que vamos trabalhar com a ddl e depois dml ok vamos em frente aqui então aqui a gente tem mais uma vez o modelo físico sendo representado com as tabelas de clientes de pedido de relação de itens né estoque produto e como essas tabelas se relacionam Lembrando que Todo relacionamento é implementado uma chave
estrangeira para que a gente consiga garantir a integridade dos dados entre as tabelas Esse é o grande lance do modelo relacional Esse é um grande lance do banco de dados relacional é ter as chaves estrangeiras com diversas tabelas consistindo os dados a partir da integridade referencial certo então a gente pode observar aqui é por exemplo que nós temos uma tabela de cliente certo e uma tabela de pedido e aí nós vamos ter aqui o Haiti cliente da tabela de pedido né como uma chave estrangeira da tabela de cliente então todo o número que for colocado
todo e o identificador do cliente ele vai ser analisado pelo sgbd se existe na tabela Pai ela tabela de clientes se não existir esse mecanismo do banco vai dar um erro de foreign de chave estrangeira isso mantém a consistência do dado que é o mais importante em um banco internacional ser consistente e íntegro Ok Isso é muito importante Ok fechando aqui essa primeira abordagem do projeto bom de dados a gente tem aqui ainda o projeto físico de banco de dados considerando né o modelo de dados lógico homologado Ou seja a partir desse modelo eu posso
transformar e esse modelo lógico em físico ele toma logado já foi chancelado por uma área né eu não preciso voltar nesse modelo novamente eu posso me basear nele como um ponto de partida para o meu projeto físico de banco de dados onde Vou definir padrões regras normas políticas estruturas Tecnológica do sgbd certo com uma outra coisa importante é o mapa de acesso lógico para saber quais entidades serão consideradas para cada grupo de usuários né então cada grupo de usuários da sala quais tabelas com permissões isso nós temos dentro do mapa de acesso lógico e ainda
podemos desenvolver relatórios de apoio ao projeto né para que a gente tenha condições de prover informações para os debates [Música] e por desenvolvedores também ok como por exemplo um cenário de dados que é uma [Música] extração das características de um banco de dados tabelas as colunas os tipos de dados Quais são os constantes que nós temos se achar estrangeira se possui notebook se possui uma propriedade única enfim e a partir de todas essas considerações a gente desenvolve o modelo físico podemos ser implementado automaticamente inclusive no banco de dados Ok Isso é muito importante [Música] [Música]
[Música] bom pessoal agora vamos a resposta da nossa questão né da nossa enquete aqui na nossa melhor dizendo Nossa pergunta que nós deixamos para vocês para ver se o aprendizado está de acordo Então vamos lá qual etapa do projeto de banco de dados que deve se escolher um sgbt para implementar nosso projeto de banco de dados e converter um projeto conceitual em um esquema de banco de dados no modelo de dados do sgbd escolhido Então qual etapa do projeto de banco de dados análise requisitos Então vamos entender a pergunta qual etapa do projeto de validade
que implementa certo que escolhe um sgbd então escolhe um sgbd já a gente já pode tratar aqui de um modelo lógico ou um modelo físico certo para implementar o projeto que vão te dados e convertendo o projeto conceitual e um esquema de banco de dados Então o que vem depois o projeto conceitual é o Projeto lógico então análise requisitos não é a resposta dessa pergunta porque a análise requisitos vem antes do modelo conceitual e a gente tá perguntando aqui qual é o projeto que vem depois do projeto conceitual Então tá descartado projeto conceitual também não
é porque a gente tá perguntando na conversão desse projeto em um esquema então ele também não é nenhum refinamento do esquema porque o refinamento ainda não está pronto para ser tratado com uma normalização de dados então a gente tá saindo do modelo conceitual e indo para um outro projeto que é o Projeto lógico certo o projeto físico também não é a resposta dessa questão porque ele não não depende do modelo conceitual na estrutura que a gente viu aqui ele depende do projeto lógico de banco de dados então a resposta correta da nossa pergunta é a
alternativa é projeto lógico de banco de dados certo porque ele já leve consideração no sgbd né para implementar a solução e converte o projeto conceitual um esquema de banco de dados é o nosso projeto lógico de banco de dados Ok Ficou claro para vocês muito bem pessoal então agora a gente é vai trabalhar com a normalização de dados começando então com as dependências funcionais certo então nós temos as dependências funcionais E essas dependências funcionais elas podem ser divididas em uma dependência funcional Total uma dependência funcional parcial uma dependência funcional transitiva então em cima dessa desse
conceito das dependências funcionais que nós vamos conseguir conceituar e entender os objetivos da normalização certo bom então vamos lá Vamos partir então é de uma dependência funcional Total Então essa dependência funcional ela trabalha da seguinte forma nós vamos observar os campos não Chaves Ok se nós temos uma dependência total é desse Campo não chave com os Campos Chaves Então a gente tem uma tabela chamado item venda essa tabela tem as colunas corte com venda com primária aqui e código produto também como por Mário aqui abre a mariquia ela pode ser formada por n colunas uma
ou em colunas quando a gente tem mais de uma coluna formando achar primária a gente diz que aquela chave primária é composta então nesses exemplos de dependência funcional nós vamos trabalhar aqui com uma tabela que possui uma chave primária composta primária código e venda e código produto para que eu saiba que eu eu o campo quantidade tem uma dependência funcional total é quando esse campo Depende de ambas as colunas Chaves então a quantidade depende do código do produto Depende se eu mudar o código do produto eu vou mudar a quantidade de item venda e o
campo quantidade ele depende do código de venda sim se eu mudar a venda eu vou mudar a quantidade do produto que foi vendido Então a gente tem aqui a característica nessa tabela com os campos código venda pode produto e quantidade o campo quantidade tem uma dependência funcional total a chave primária composta da tabela e tem lenta Ok Ficou claro dependência funcional Total Campos não Chaves Depende de toda a chave primária de toda a composição da chave primária bom vamos agora partir para uma outra investigação que trabalha aqui com a questão da dependência funcional parcial então
nós temos a mesma tabela tabela de item venda com os campos código da venda código produto esses dois Campos São primário aqui é uma Charme primária composta da mesma forma do exemplo anterior nós temos o campo quantidade né como na quantidade que a gente já viu que tem uma dependência Total só que o preço do produto depende apenas do código do produto o preço do produto não depende da venda Ah se eu vendi para a o preço é x Se for para B é 2x não o preço do produto depende apenas de parte da chave
parte do código do produto então preço produto não depende código da venda mas depende do código do produto se eu alterar o código do produto o preço do produto é modificado mas não depende da venda então nessa situação né Nós temos uma dependência funcional parcial do campo da coluna preço produto em relação à sua chave primária Ok então ficou Claro para vocês a dependência funcional Total todos os campos da tabela é possuem uma dependência funcional Total com a chave primária e uma dependência funcional parcial significa que algum dos Campos não chave ele depende apenas de
parte da chave então desenvolvendo uma dependência funcional parcial Ok Ficou claro isso o conceito para vocês muito bem pessoal isso é importante vamos em frente e agora a gente trabalha com uma dependência funcional transitiva significa essa dependência funcional transitiva Estamos aqui na mesma tabela de tem venda com o código de venda como chave primária código do produto também como chave primária uma chave primária composta temos o campo quantidade que depende totalmente da chave temos aqui o campo preço produto que depende apenas de parte da chave depende apenas do código do produto mas não depende do
Código da venda a gente viu isso agora a pouco e esse próximo Campo o campo a coluna Total parcial Então esse Total parcial ela tem uma dependência funcional transitiva dos Campos não Chaves então uma dependência funcional transitiva não leva em consideração a Chaves deve os campos Não Chaves é o total parcial ela ele é um campo calculado entre a quantidade vezes o preço do produto então quando eu altero a quantidade eu altero o total parcial quando eu altero o preço do produto é o altero o total parcial se eu alterar qualquer um desses dois atributos
o atributo total parcial vai ser alterado Então dessa forma esse campo Total parcial tem uma dependência funcional transitiva com Campos não chave então isso caracterizado uma dependência funcional transitiva certo isso é importante que a gente vai a partir dessas análises das dependências funcionais nós vamos entender a normalização certo então depois dessa conceituação das dependências constitucionais né É lembrando mais uma vez dependência funcional Total Campos não chave com os Campos Chaves dependência funcional parcial quando apenas é uma um campo Depende de parte da chave isso uma dependência possual parcial e a dependência funcional transitiva é quando
nós temos um campo que depende de Campos não Chaves A medida que o altero um desses Campos o total parcial ele é alterado também certo muito bem passado essa questão dos conceitos pessoal a gente trabalha agora com a questão é do objetivo da normalização então nós estávamos trabalhando até aqui né numa num projeto de banco de dados a gente começou tratando o modelo conceitual nesse modelo né de alto nível que é um instrumento conversar com um aqui para a gente ter certeza é do início do projeto que Quais são as entidades e atributos a gente
pode ter dentro desse modelo algumas questões como Campos multilourados podemos ter Campos compostos né podemos ter a questão da dependência funcional de um campo calculado como esse Total parcial isso tudo lá no modelo conceitual é válido então quando a gente utiliza a técnica de normalização a gente vai investigar cada coluna se tá bem empregado daquela tabela ou não se faz sentido ela existir se ela pode ser suprimida se de repente é aquela coluna vai formar uma nova tabela isso tudo nós vamos refinar a partir da normalização então a gente começa que com a descrição de
documento o arquivo ou sgb não relacional a gente passa então do mundo das ideias do mundo do Minimundo aqui ao esquema de tabela relacional não normalizada que a gente pode encarar aqui como é uma abstração do modelo conceitual até o modelo lógico aqui que a gente vai investigar a partir do modelo físico certo então a gente vai passar pela primeira forma normal pela segunda forma normal e pela terceira fórmula normal E aí nós vamos dizer que aquele esquema relação está normalizado significa que eu garanto que cada Campo está bem alocado em cada tabela o campo
xpto tá bem alocado aqui então eu fiz um refinamento do meu modelo a partir da normalização eu vou verificar se cada Campo está bem está condizente com aquela tabela se ele pode ser suprimido se ele deriva por uma outra tabela conforme eu já mencionei então essa técnica de normalização ele é muito importante porque nos dá essa essa certeza né que cada atributo que cada Campo está bem empregado da tabela muito bem então vamos começar a tratar a normalização com esse exemplo temos aqui a tabela boletim que possui uma chave primária composta representada pelos Campos matrícula
do aluno período e corte da disciplina ok percebe-se que o campo nota Depende de toda a chave primária anota aqui ó ele depende do aluno depende do período e também depende da disciplina se eu alterar o aluno é o Altera a nota se o altar o período eu Possivelmente possa alterar a nota e se eu alterar a disciplina Eu também altero a nota então Aqui nós temos uma dependência funcional Total aqui desse Campo nota em relação a chave para melhor composta perfeito muito bem porém o nome da disciplina certo depende apenas de parte da chave
ou seja do campo disciplina o nome da disciplina depende do aluno não depende da matrícula do aluno o nome da disciplina depende do período não depende do período não deve disciplina depende do corte da disciplina se eu trocar o corda você plena eu vou mudar o nome disciplina então Aqui nós temos uma dependência funcional parcial do campo nome disciplina em apenas parte da chave primária composta então a tabela acima configura em um caso de independência funcional parcial pois no campo o nome da disciplina depende apenas de parte da chave ok então a gente começa a
verificar que essa questão da dependência funcional parcial é importante para que a gente entenda essas questões na normalização Então vamos lá nós temos aqui é a tabela de item pedido com os campos o número do pedido código do produto e a quantidade do produto Então essa quantidade de produto Depende de toda a chave depende do produto e também depende do pedido se eu mandar o pedido muda a quantidade Se eu mudar o corte do produto eu também Altera a quantidade de produto então Aqui nós temos uma dependência funcional Total esse campo está bem empregado aqui
na tabela aí tem pedido Ok Posso manter esse cara aqui agora vamos lá numa tabela pedido eu tenho a chave primária número do pedido eu tenho o corte como vendedor como chave estrangeira eu tenho ainda um campo prazo de entrega e o nome do vendedor Então eu tenho aqui uma dependência funcional transitiva que o nome do vendedor Depende de um campo não chave que é o código do vendedor certo então esse nome vendedor não tá bem colocado aqui na tabela eu não preciso dele na tabela de pedido Eu só preciso do código do vendedor como
chave estrangeira certo Inclusive a chave estrangeira me proporciona ainda uma otimização da integridade porque ele vai lá na tabela de vendedor verificar se esse código existe no caso do nome vendedor eu não tenho essa garantia né e a gente Verifica que nós temos uma dependência funcional transitivo aqui em relação a um campo não chave um campo nome vendedor não sabe Depende de outro não chave Então a gente tem que retirar esse nome vendedor da tabela de pedido Ok Isso é importante esse essa abstração da gente saber se um campo está bem ou não empregado bom
em relação às formas normais nós temos aqui uma primeira forma normal para estar na segunda tentar na primeira e fazer mais alguma coisa ela tá na terceira forma eu tenho que estar na segunda tem que estar no primeiro então eu vou sendo mais específico aqui a medida que a gente tem é essa série de formas normais nós temos uma variação da chave ou melhor da terceira forma normal da forma normal board code que trabalha com Chaves candidatas temos a quarta forma normal a quinta forma normal entre outras formas normais tá pessoal mas se diz pela
literatura que nós temos um modelo de dados normalizado quando a gente atinge pelo menos a terceira forma normal as demais elas podem não ser empregadas Porque a gente já tem o modelo normalizado perfeito mas a título de curiosidade a gente tem outras variações de formas normais bom então num quadro esquematizado da normalização a gente pode ter o seguinte primeira fórmula normal nós temos que termos atributos atômicos indivisíveis certo a gente não pode ter aqui atributos multi-lorados né Por exemplo um campo telefônico não é atômico que eu tenho mais de um dado mais de uma informação
ali dentro Ok primeira forma normal atributo atômico indivisíveis segunda forma normal a ausência de dependências parciais então eu tô na segunda forma normal quando eu tô na primeira e eu não tenho dependências parciais né ou seja um campo não chave que depende apenas de parte da chave ok e a terceira forma normal né então tem que estar na segunda na primeira e a terceira forma normal ela é caracterizada pela ausência de dependência transitiva S aquela questão do campo calculado tão lembrados e o campo não chave com outro Campo não chave forma normal de boy de
corte trabalha com dependências ausência de dependências entre os atributos dão chave considerando aqui uma Chaves candidatas nós temos aqui a quarta fórmula normal que trabalha com ausência de dependências e a questão é da Quinta forma normal ausência de dependências de junção Ok então isso é importante que a gente saiba que pelo menos até terceira forma normal nós temos que chegar em todo o modelo físico vamos lá para que a gente alcance a primeira forma normal nós temos que primeiro eliminar grupos repetitivos das tabelas individuais criar tabelas separados para cada grupo de dados relacionados identificar cada
grupo de dados relacionados com a chave primária segundo a forma normal nós temos que criar tabela separadas para adequar grupos de dados que se aplicam em vários registros e ainda relacionar essas tabelas mediante uma chave externa como uma chave estrangeira por exemplo e terceira forma normal eliminar questões de Campos com dependências de Campos não Chaves ok Então vamos lá vamos analisar essa tabela aqui então uma a tabela está na primeira forma normal se não tiver também nas alinhadas uma dentro da outra então a gente observa que essa tabela eu tenho aqui código do projeto tipo
descrição Eu tenho um código do empregado Eu tenho um nome eu tenho categoria tem do salário eu tenho data de início e tempo de tempo alocado no projeto quando a gente percebe aqui né que eu tenho tabelas alinhadas aqui dentro Eu tenho essas três primeiras colunas Parece que elas não são empregadas na tabela de empregado eu tô confundindo aqui as questões de projeto com empregado certo então para atender essa forma normal podemos criar tabelas de projeto e alocação de empregado E aí a gente teria essa quebra aqui ó uma tabela específica de projeto e uma
tabela específica de alocação empregado perfeito e aí a gente vai é ter aqui na primeira forma normal é ausência de tabelas alinhadas dentro de uma célula por exemplo de uma coluna né E também não temos a questão é de um campo multilourado ou um campo que não é atômico perfeito e aqui também nas tabelas de alocação empregado a gente não tem aqui é Campos muitos colorados ou questões de Campos com que não são átomos então a gente sai dessa tabela aqui grande e com os conceitos da primeira forma normal nós chegamos a separar essa tabela
em duas uma primeira tabela de projeto e uma segunda tabela de locação empregado está na primeira forma normal porque nós cumprimos os requisitos para que essa tabela esteja na primeira forma normal então primeira forma normal certo a gente observa que é a aplicação por exemplo da tabela associada onde a gente tinha um ID o nome do associado a rua certo ou f e o CEP como aqui um campo composto né E a questão da do telefone se a gente tivesse um telefone dentro da tabela associado a gente teria um campo não atômico porque você percebam
que o Adriano que o ai de um Adriano associado ao Adriano ele tem dois telefones se a gente colocasse um campo telefone na tabela associado eu teria não teria um campo atômico então Já se resolveu tirou o telefone da tabela associada e se criou uma tabela fone associado E aí ele pode ter quantos telefones ele quiser porque a chave aqui a primária é composta entre o ardido o usuário ou melhor associado e o telefone então o Adriano É de um tem um telefone 9999 e ele também tem o id o Adriano tem o 988 perfeito
então aqui nós empregamos a solução da primeira forma normal onde a gente considerou o atributo o campo telefone como um campo não atômico muito bem agora a gente parte aqui para a questão da segunda forma normal então a tabela estará na segunda forma normal se a tabela já estiver na primeira forma é um pré-requisito e não possuir dependências parciais lembra das dependências parciais então a gente Analisa os campos não Chaves se esses campos não sabes Depende de toda a chave primária Então a gente tem aqui a tabela de empregado né e de anotação empregado a
gente tinha antes normalizado aqui alocação empregado né com código do projeto o código do empregado nome é categoria [Música] salário data de início e o tempo colocado então a gente parte dessa tabela e verifica que alguns Campos da tabela alocação empregados não estavam bem naquela tabela como o nome a categoria do empregado e o salário então a gente mais uma vez divide a tabela alocação empregada para deixar os campos que são pertinentes à locação empregado como o código do projeto o código do empregado a data de início o tempo de locação então aqui no caso
a gente tem a chave primária como o código do projeto e o código do empregado o campo data início Depende de ambas as colunas Chaves e o tempo colocado também depende do empregado depende do projeto então Aqui nós temos essa segunda a segunda forma normal aplicada na tabela de locação do pregado e a gente retirou os campos dela para que não estavam de acordo com essa parcial né Por exemplo um campo nome só dependia do código empregado Não dependia do código do projeto né então a gente desenvolveu uma nova tabela chamada tabela empregada onde a
gente tem a chave primária código do empregado o nome depende do código do empregado a categoria depende do código do empregado e o salário depende ainda do código do empregado todos os campos não Chaves dependem da chave primária então a gente sofisticou um pouquinho mais do nosso modelo por meio da chave ou melhor da forma da segunda forma normal a gente Conseguiu perceber que tinha algumas colunas que não estavam bem empregadas na tabela alocação do empregado e aí a gente concebeu mais uma tabela chamada tabela empregada agora a gente tem essas duas tabelas normalizadas na
segunda forma normal a gente não tem Campos que não atômicos não temos tabelas alinhadas em células aqui da minha tabela é e também não tenho dependências funcionais parciais todos os campos não Chaves dependem da Chaves primárias das tabelas que a gente criou agora a pouco então a tabela alocação empregado deve ser segmentada em outra tabela empregado como resolução da segunda forma normal Ok então a segunda forma normal mais uma vez a gente observa que deve estar na primeira fase normal e a gente não deve atributos não chave na tabela devem dependendo de alguma da chave
da tabela é o da totalidade da Chaves então a gente percebe aqui nesse exemplo de locações e detalhes da locação que por exemplo as questões de [Música] categoria depende da locação né e da questão aqui do pagamento depende do Código da locação então a gente chega na segunda forma Normal também seguindo essa mesma Filosofia de Campos não chave depender de toda a chave primária e agora a gente chega na última forma normal que deve ser considerada Ok Aonde nós temos a questão da terceira forma e por uma tabela está na terceira forma elas devem estar
na segunda forma normal e não possuir dependências transitivas né então a gente percebe que no exemplo que nós vimos trabalhando empregado acumula categoria salário podem ser segmentados em uma nova tabela então a gente tinha esse cenário né onde nós tínhamos através de empregado com o código do empregado nome categoria salário e agora a gente retira o salário da tabela de empregado o empregado vai estar apenas com o nome e a categoria que ele pertence então o campo salário ele aqui na tabela empregado ele tinha uma dependência funcional transitiva ele dependia o salário dependia de um
campo não chave que a categoria seu mundo categoria eu vou mudar o salário então é existe aqui a dependência funcional transitiva que a gente fez a gente criou uma nova tabela chamada categoria salário ou não vão ser o código O código da categoria E o salário daquela categoria E na tabela de empregado a gente mantém apenas a coluna categoria então o João tá na categoria 1 ou a Maria também tá na categoria 1 e assim sucessivamente para todos os outros empregados ok muito bem então analisando aqui é o outro exemplo de locações e detalhes né
a gente vê que a gente para tentar para estar na terceira fórmula normal nós temos que estar na segunda forma normal e atributos dão chave da tabela é dependendo dos elementos da chave primária da tabela então a gente observa que o saldo aqui ele depende do cliente tá vendo Então a gente vai ter aqui uma tabela só de cliente com o cliente o saldo que ele tem vamos manter os outros atributos de locação como código pagamento cliente e telefone né Lembrando que aqui o telefone também poderia estar em outra tabela conforme a gente viu agora
há pouco né a gente percebe que telefone aqui é do cliente não tá bem empregado aqui nessa terceira forma normal Ok e a categoria está dependendo da locação que tem um código então nós temos aqui uma análise ainda ser realizada nessas tabelas elas não estão na terceira forma normal conforme o exemplo demonstra porque a gente ainda tem dependências funcionais transitivas muito bem pessoal agora vamos responder a pergunta né da questão vamos lá então quando sabemos que um modelo atendeu a segunda forma normal vamos lá se atender as condições da primeira forma normal verdadeiro e te
ver os atributos não identificadores né os atributos não Chaves apresentando dependência funcional no identificador então é essa está correta então a gente está na primeira fórmula normal e os atributos não Chaves apresentado tem uma dependência funcional Total com a chave primária Então essa alternativa está correta porque é mais uma vez né Nós não temos dependência funcional parcial ou seja os campos não Chaves os atributos não identificadores apresentando dependência funcional aos Campos Chaves então atendeu a questão é essa verdadeira essa alternativa correta vamos ver porque que a alternativa b não é correta se atender as condições
da primeira forma normal ou tiver atributos não identificadores apresentados não é Ou ele tenta na primeira fórmula normal e também é os campos não Chaves devem estar totalmente aderentes a chave primário então a b tá descartada por causa desse ou aqui a alternativa c Se tivermos atributos não identificadores apresentando dependência funcional não identificador então faltou aqui a questão da estar na primeira fórmula normal os atributos não identificadores né os campos não Chaves dependem dos Campos Chaves mas faltou um pedaço que é estar na primeira fórmula normal por isso que a c também não é a
correta a alternativa dele se atender as condições da terceira forma né a gente está analisando a segunda forma então a terceira forma é depois da da segunda então a gente ele ela também não considera porque a segunda forma normal considera a dependência parcial né e não a dependência transitiva funcional dependência que são transitiva conforme o terceiro forma normal e se atender as condições da primeira forma normal primeira forma normal onde nós temos os campos atômicos e não temos um dia assim é multi coloração dentro dessa dessa coluna né como o telefone por exemplo então a
alternativa correta dessa questão é a alternativa atentando a primeira forma normal e os atributos não Chaves devem depender dos atributos Chaves muito bem pessoal então era isso que eu tinha para passar para vocês nessa web aula Espero que todos tenham curtido a nossa web aula 4 vamos em frente com quem comigo e até a próxima pessoal grande abraço a todos vamos em frente
