A teoria parece correta, mas a aplicação das 3 formas normais, na prática, não normalizou as tabelas. 1- Tabela Clientes: - Poderia ter uma chave única, como um código de cliente, por exemplo. - Ok, a chave composta nome e telefone vai ser exclusiva, pois não vai haver dois clientes com o mesmo nome e telefone. Mas se errar o nome do cliente, já furou a chave... - Campo saldo, até pode ser usado para melhorar a performance, mas é de praxe nunca armazenar dados calculados no banco de dados, pois ele mudam com frequência, logo devem ser calculados em tempo de execução. Por exemplo, não armazena-se a idade de uma pessoa, pois ela muda com o passar do tempo (óbvio), mas calcula-se com base na data de nascimento e a data corrente. 2- Tabela Locações - Pagamento deveria ser uma outra tabela, com chave própria, e só iríamos gravar a chave da Forma de Pagamento na tabela Locações como chave estrangeira. - Como explicado no item 1, só gravariamos a chave única da tabela Clientes como chave estrangeira na tabela Locações (isso também iria economizar espaço). - Poderia ter a data da locação, mas isso é uma questão de análise de negócio e não de normalização. 3- Tabela Detalhes - Da mesma forma se dividiria em tabela Filmes e tabela Categorias. - Aqui sim iríamos gravar o valor da locação de cada filme (buscando esse valor na tabela Filmes, provavelmente), pois o valor de locação do filme pode mudar, mas o valor da locação passada não muda. E esse campo então, seria usado para calcular o saldo. - Também poderia ter a informação de pago ou não, mas também está fora do escopo de normalização. Entendi que era apresentação de um trabalho do curso, e como tô acordado até tarde trabalhando exatamente com isso, e vi o video nas recomendações, resolvi escrever pra kct só pra distrair um pouco... Viu no que dá escolher essa carreira... vc fica velho e louco escrevendo de madrugada...
Tbm achei o mesmo. Fazer a ligação de informações entre a tabela locações e clientes iria fica meio estranha. Eu sempre liguei tudo com um id primário de clientes/contas pra fazer esse tipo de coisa. Mesmo agora que estou descobrindo molagem de dados, acho melhor esse método.
Props Douglas, fizeste-me passar no exame de base dados, fizeste muito mais que a chambel.
tirei minhas dúvidas nesta aula.Muito obrigado professor
A teoria parece correta, mas a aplicação das 3 formas normais, na prática, não normalizou as tabelas.
1- Tabela Clientes:
- Poderia ter uma chave única, como um código de cliente, por exemplo.
- Ok, a chave composta nome e telefone vai ser exclusiva, pois não vai haver dois clientes com o mesmo nome e telefone. Mas se errar o nome do cliente, já furou a chave...
- Campo saldo, até pode ser usado para melhorar a performance, mas é de praxe nunca armazenar dados calculados no banco de dados, pois ele mudam com frequência, logo devem ser calculados em tempo de execução. Por exemplo, não armazena-se a idade de uma pessoa, pois ela muda com o passar do tempo (óbvio), mas calcula-se com base na data de nascimento e a data corrente.
2- Tabela Locações
- Pagamento deveria ser uma outra tabela, com chave própria, e só iríamos gravar a chave da Forma de Pagamento na tabela Locações como chave estrangeira.
- Como explicado no item 1, só gravariamos a chave única da tabela Clientes como chave estrangeira na tabela Locações (isso também iria economizar espaço).
- Poderia ter a data da locação, mas isso é uma questão de análise de negócio e não de normalização.
3- Tabela Detalhes
- Da mesma forma se dividiria em tabela Filmes e tabela Categorias.
- Aqui sim iríamos gravar o valor da locação de cada filme (buscando esse valor na tabela Filmes, provavelmente), pois o valor de locação do filme pode mudar, mas o valor da locação passada não muda. E esse campo então, seria usado para calcular o saldo.
- Também poderia ter a informação de pago ou não, mas também está fora do escopo de normalização.
Entendi que era apresentação de um trabalho do curso, e como tô acordado até tarde trabalhando exatamente com isso, e vi o video nas recomendações, resolvi escrever pra kct só pra distrair um pouco... Viu no que dá escolher essa carreira... vc fica velho e louco escrevendo de madrugada...
Tbm achei o mesmo. Fazer a ligação de informações entre a tabela locações e clientes iria fica meio estranha. Eu sempre liguei tudo com um id primário de clientes/contas pra fazer esse tipo de coisa. Mesmo agora que estou descobrindo molagem de dados, acho melhor esse método.
Melhor comentário
@@lucasviniciusazevedodemora547 só tem esse comentário doido
@@glm1627 mas é o melhor de todos
Obgda, super entendi ❤
Todas essas tabelas são do curso da SoftBlue, curso de SQL, tudo bem que é um curso gratuito, mas dar os créditos sempre é bom né.
péssimo áudio: não tive paciencia de ouvir nem 30 segundos.