Ótima aula, usou algo já disponível web, acessível, a todos e a melhorou com exemplos práticos facilitando o aprendizado. Gostei do fato de ter escolhido a wikipedia ajudando a desmistificar a sua má reputação.
Pensei que eu nunca entenderia, sinceramente hehe... Fiz o técnico mas normalização de tabelas não entrava de jeito nenhum na minha cabeça, mas aqui está bem esclarecido. Muito obrigado.
Muito bom os vídeos! Assisti o 1FN, 2FN e agora o 3FN. Poderia fazer também o BCFN? dentre esses quatro é o que tenho mais dúvidas, principalmente na decomposição ...
Prof. DB, primeiramente gostaria de elogiar a sua didática, é simples, direto ao assunto. Na definição da chave primária para a tabela pedidos, definir char(3) como tipo de dado da chave primária não restringe o número de pedidos possíveis? Fiz os cálculos aqui, cada char ocupa 1 byte de memória, que significa 256 possibilidades possíveis (bits) , se for char(3) a chave primária da tabela pedidos, daria 16.777.216 possibilidades combinatórias possíveis de pedidos sem violar a unicidade da chave primária, isso utilizando todos os caracteres possíveis, conforme a tabela ASC. Significa que este modelo de dados só poderia armazenar no máximo esta combinação de pedidos. Não poderíamos definir um inteiro longo? Considerando que os dígitos "00" à esquerda dos números trataríamos como máscara de exibição na aplicação? Outra! Se a chave só considerasse a existência da combinação de números decimais em 3 casas, a combinação seria, 10 elevado a 3 (terceira), onde o sistema só guardaria 1000 pedidos, de 001 a 999, sem quebrar a unicidade da chave primária. É algo a se pensar! Prof. quando vejo as FN colocadas assim na internet, de forma tão didáticas, sem fronteiras, me faz pensar que a educação é a chave primária para o futuro desta nação! Parabéns! Abs,
Olá professor muito boa sua aula! Entendi que vc definiu o npedido com char3 apenas para seguir a tabela demonstrativa. Mas no caso numa aplicação real estaríamos limitando a tabela pedidos para guardarmos apenas 999 registros. Estou certo?
Marciel Assiz, sou usuário de Linux há muitos anos e raramente tenho dificuldades para encontrar softwares equivalentes aos que usava em Windows. Se estiver em dificuldades, faça uma busca assim no Google: "nomedosoftwarequevoceprecisa linux alternative". Você vai se surpreender.
Cara valew pela dica preciosa, vi aqui um monte de softwares que precisava fazendo esse esse esquema de busca, sou usuario do linux ubuntu a poucos meses, mas esse relacionamento ate agora so tem agregado valor a profissao.
òtima aula,além de explicar o assunto usando exercícios e recursos da web,fez uma ótima explicação sobre o assunto,deixando a aula mais prática.Mais eu tenho uma dúvida,me corrija se eu tiver errado,o número na tabela pedidos não tinha que interligar com o núm_pedido na tabela prod_pedido ? De qualquer forma,Òtima video aula !
Parabens pela video aula, muito boa!!. Só não entendi o porquê de vc usar nome cliente como unique. Os nome podem repetir, não existe apenas um Antonio ou Maria, seria mais coerente se fosse no campo CPF por exemplo. Não leve a mal, só estou comentando como eu faria rsrs, bastante esclarecedora sua didática. Parabens!!!
Muito boa sua aula, e a propósito, de acordo com meu conhecimento em linguagem de programação Varchar, acredito eu, que seja a junção da palavra "Variavel + Caracterer". Portanto todo dado que contenha "Varchar" de inicio, seria um dado do tipo caractere :)
Exatamente Maycon. Em alguns SGBDs esse campo eh chamado "character varying", ou seja, caracteres variaveis. Todo dado textual de tamanho dinamico pode ser entendido como VARCHAR.
boa noite professor, primeiramente gostaria de agradecer pelos videos que me esclareceram bastante o assunto. Só uma duvida no momento (2:45) você diz que não tem violação da 1FN mas tem, o nome do cliente por exemplo não deveria estar um por linha? No 1NF você faz isso. Muito Obrigado
Ola Reno. Nao entendi a pergunta, pois o nome do cliente so aparece uma vez por linha. O tipo de tabela usada nesse exercicio eh facil de ser construida planilhas Excel, por isso usei como exemplo.
Cara parabéns, seus vídeos são os melhores de DB que eu já vi, melhor que muitos cursos pagos por ai. Agora uma dúvida, o campo nome vc diz que é Unique, mas existem pessoas com o mesmo nome, o correto não seria deixar o campo unique desmarcado?
+110715630108881965544 , no caso desse exercicio NOME foi marcado como UNIQUE porque esse eh o unico dado que temos. Obviamente, no mundo real, lancariamos mao de algum identificador natural para distinguir um cliente de outro.
Embora este exemplo seja usado apenas para simples fim de explicação do processo de normalização, um erro grave é associar o valor unitário ao produto. Nessa configuração, qualquer alteração de valor de produto afetaria todos os pedidos, incluindo... os já emitidos.
Professor DB pode me ajudar em uma tabela na parte 2NF? tenho uma questão que queria ajuda!
10 ปีที่แล้ว +1
Mas prof. os valores dos produtos em relação ao tempo podem variar, por exemplo, em um ano o valor de um produto pode aumentar ou diminuir. Não seria interessante guardar de alguma forma esta informação?
Oi Lucas. Voce esta absolutamente correto; o valor de um produto sofre variacoes ao longo do tempo. A maneira obvia de resolver esse problema seria guardar o valor unitario do produto no proprio pedido. Essa solucao, entretanto, cria um outro problema: duplicacao de dados, o que resulta em maior consumo de disco. Uma solucao que me parece mais eficiente seria armazenar o historico de alteracao nos valores unitarios dos produtos. Voce conseguem pensar em outra solucao?
Professor DB Parabéns pelo vídeo. Estava estava revendo os conceitos sobre normalização e ficou mais fácil que antes. Bom, quanto a criação de uma tabela de histórico de preço para esse fim, vejo outro problema: numa consulta de um pedido antigo, teria que buscar o valor nessa tabela de histórico e identificar, talvez para data do pedido, o valor correspondente. Nesse caso, acho melhor mesmo é criar um campo valor na tabela do item do pedido, sendo uma "redundância" necessária. O valor muda em uma tabela e não pode mudar em outra. O que acham? (Valeu pelo vídeo)
Julio Fulgencio depende do caso. Se a empresa que usa o sistema emitir 5.000 pedidos por dia (Submarino, Americanas, Casa e Video), cada pedido com dois itens em media, significa que voce vai guardar 10.000 campos redundantes por dia, 3.600.000 por ano todo ano. Para um negocio pequeno, essa redundancia nao vai gerar impacto significativo, porem o impacto aumenta significativamente a medida que o negocio cresce.
Não seria adequado guardar em outra tabela relacionada ao produto a data de modificação do preço do produto? 2FN? Daí quando fizer a consulta, comparamos com a data do pedido! Para saber o preço do produto naquele dado tempo! É um dado transitório, não concordam?
+Cícero Goss , eu concordo. Se fosse modelar algo nesse dominio de negocio, separaria as tabelas Produto e Preco. A tabela Preco seria um tipo de historico, armazenando tanto o preco atual quanto as alteracoes ao longo do tempo.
+sandro silva , pior que parece mesmo!!! Tive que rir! Acredite se quiser: usei um microfone de lapela para gravar os videos, so que o microfone eh muito ruim e gera muita interferencia. Essa ficou engracada.
Falando nisso (11: 22) "UN - UNSIGNED" nao existe no MSSQL. Eu devo usar o inicio ID com (INT -2147483648 ate 2147483647). Minha tabela iniciaria com Identity(-2147483648, 1) total de 4294967295 registos. Ou devo fazer algo diferente. Oque eu realmente tenho que fazer professor?
+srherry , o MySQL oferece algumas "comodidades" que nao sao vistas em outros bancos, uma delas eh o UNSIGNED. Se voce trabalha com Oracle, MSSQL, PostgreSQL e afins, e precisa garantir que um campo numerico seja sempre positvo, minha recomendacao eh voce usar um CHECK CONSTRAINT. Adicionalmente, recomendo que voce nunca use numeros negativos ou de ponto flutuante como chave primaria. Voce vai deixar os programadores furiosos...
nunca pensei que teria uma aula de banco de dados com o Guilherme briggs
Ótima aula, usou algo já disponível web, acessível, a todos e a melhorou com exemplos práticos facilitando o aprendizado. Gostei do fato de ter escolhido a wikipedia ajudando a desmistificar a sua má reputação.
Melhor explicaçao de normalizaçao que tive! Muito bom! Se tiver mais mande para gente...
Show d bola todos os videos ... Parabéns
Pensei que eu nunca entenderia, sinceramente hehe...
Fiz o técnico mas normalização de tabelas não entrava de jeito nenhum na minha cabeça, mas aqui está bem esclarecido.
Muito obrigado.
parabéns cara, suas vídeo aulas são ótimas.
Rápido, simples e conciso. Muito bons vídeos!
Parabéns pelos vídeos! Muito boa sua didática!!
Muito bom os vídeos! Assisti o 1FN, 2FN e agora o 3FN.
Poderia fazer também o BCFN? dentre esses quatro é o que tenho mais dúvidas, principalmente na decomposição ...
Iago César Fernandes Nogueira, vou pensar no caso. Talvez faça. Obrigado pela dica.
goste da aula to fazendo
SI e pra mim ta dificil destrinchar essas tabelas, bela aula!!!
Otima aula , sua voz parece com a do Guilherme Briggs
pensei a mesma coisa haha
Muito bom ! Ótimo trabalho
Ótima aula! Gostei bastante...
Prof. DB, primeiramente gostaria de elogiar a sua didática, é simples, direto ao assunto. Na definição da chave primária para a tabela pedidos, definir char(3) como tipo de dado da chave primária não restringe o número de pedidos possíveis? Fiz os cálculos aqui, cada char ocupa 1 byte de memória, que significa 256 possibilidades possíveis (bits) , se for char(3) a chave primária da tabela pedidos, daria 16.777.216 possibilidades combinatórias possíveis de pedidos sem violar a unicidade da chave primária, isso utilizando todos os caracteres possíveis, conforme a tabela ASC. Significa que este modelo de dados só poderia armazenar no máximo esta combinação de pedidos. Não poderíamos definir um inteiro longo? Considerando que os dígitos "00" à esquerda dos números trataríamos como máscara de exibição na aplicação? Outra! Se a chave só considerasse a existência da combinação de números decimais em 3 casas, a combinação seria, 10 elevado a 3 (terceira), onde o sistema só guardaria 1000 pedidos, de 001 a 999, sem quebrar a unicidade da chave primária. É algo a se pensar! Prof. quando vejo as FN colocadas assim na internet, de forma tão didáticas, sem fronteiras, me faz pensar que a educação é a chave primária para o futuro desta nação! Parabéns! Abs,
Olá professor muito boa sua aula! Entendi que vc definiu o npedido com char3 apenas para seguir a tabela demonstrativa. Mas no caso numa aplicação real estaríamos limitando a tabela pedidos para guardarmos apenas 999 registros. Estou certo?
Concordo com Adriano, no ubuntu e Workbench fica tudo 10.
Marciel Assiz, sou usuário de Linux há muitos anos e raramente tenho dificuldades para encontrar softwares equivalentes aos que usava em Windows. Se estiver em dificuldades, faça uma busca assim no Google: "nomedosoftwarequevoceprecisa linux alternative". Você vai se surpreender.
Cara valew pela dica preciosa, vi aqui um monte de softwares que precisava fazendo esse esse esquema de busca, sou usuario do linux ubuntu a poucos meses, mas esse relacionamento ate agora so tem agregado valor a profissao.
òtima aula,além de explicar o assunto usando exercícios e recursos da web,fez uma ótima explicação sobre o assunto,deixando a aula mais prática.Mais eu tenho uma dúvida,me corrija se eu tiver errado,o número na tabela pedidos não tinha que interligar com o núm_pedido na tabela prod_pedido ? De qualquer forma,Òtima video aula !
Parabéns pela aula ajudou demais!
mto top sua explicacao parabens
Professor, partindo dessa tabela aí, como ficaria na forma normal de Boyce-Codd? Ainda não peguei essa diferença
Parabens pela video aula, muito boa!!. Só não entendi o porquê de vc usar nome cliente como unique. Os nome podem repetir, não existe apenas um Antonio ou Maria, seria mais coerente se fosse no campo CPF por exemplo. Não leve a mal, só estou comentando como eu faria rsrs, bastante esclarecedora sua didática. Parabens!!!
Muito boa sua aula, e a propósito, de acordo com meu conhecimento em linguagem de programação Varchar, acredito eu, que seja a junção da palavra "Variavel + Caracterer". Portanto todo dado que contenha "Varchar" de inicio, seria um dado do tipo caractere :)
Exatamente Maycon. Em alguns SGBDs esse campo eh chamado "character varying", ou seja, caracteres variaveis. Todo dado textual de tamanho dinamico pode ser entendido como VARCHAR.
boa noite professor, primeiramente gostaria de agradecer pelos videos que me esclareceram bastante o assunto.
Só uma duvida no momento (2:45) você diz que não tem violação da 1FN mas tem, o nome do cliente por exemplo não deveria estar um por linha? No 1NF você faz isso.
Muito Obrigado
Ola Reno. Nao entendi a pergunta, pois o nome do cliente so aparece uma vez por linha. O tipo de tabela usada nesse exercicio eh facil de ser construida planilhas Excel, por isso usei como exemplo.
Cara parabéns, seus vídeos são os melhores de DB que eu já vi, melhor que muitos cursos pagos por ai.
Agora uma dúvida, o campo nome vc diz que é Unique, mas existem pessoas com o mesmo nome, o correto não seria deixar o campo unique desmarcado?
+110715630108881965544 , no caso desse exercicio NOME foi marcado como UNIQUE porque esse eh o unico dado que temos. Obviamente, no mundo real, lancariamos mao de algum identificador natural para distinguir um cliente de outro.
Nem todo campo que não é chave é volátil. Então a 3fn é quando não depende de campos chaves ou de transitivos?
Ótima aula
Por que id_cliente não é chave primária no pedidos?
Muito bom mesmo!
Ótima aula!
Embora este exemplo seja usado apenas para simples fim de explicação do processo de normalização, um erro grave é associar o valor unitário ao produto. Nessa configuração, qualquer alteração de valor de produto afetaria todos os pedidos, incluindo... os já emitidos.
Professor DB pode me ajudar em uma tabela na parte 2NF? tenho uma questão que queria ajuda!
Mas prof. os valores dos produtos em relação ao tempo podem variar, por exemplo, em um ano o valor de um produto pode aumentar ou diminuir. Não seria interessante guardar de alguma forma esta informação?
Oi Lucas. Voce esta absolutamente correto; o valor de um produto sofre variacoes ao longo do tempo. A maneira obvia de resolver esse problema seria guardar o valor unitario do produto no proprio pedido. Essa solucao, entretanto, cria um outro problema: duplicacao de dados, o que resulta em maior consumo de disco. Uma solucao que me parece mais eficiente seria armazenar o historico de alteracao nos valores unitarios dos produtos. Voce conseguem pensar em outra solucao?
Professor DB Parabéns pelo vídeo. Estava estava revendo os conceitos sobre normalização e ficou mais fácil que antes. Bom, quanto a criação de uma tabela de histórico de preço para esse fim, vejo outro problema: numa consulta de um pedido antigo, teria que buscar o valor nessa tabela de histórico e identificar, talvez para data do pedido, o valor correspondente. Nesse caso, acho melhor mesmo é criar um campo valor na tabela do item do pedido, sendo uma "redundância" necessária. O valor muda em uma tabela e não pode mudar em outra. O que acham? (Valeu pelo vídeo)
Julio Fulgencio depende do caso. Se a empresa que usa o sistema emitir 5.000 pedidos por dia (Submarino, Americanas, Casa e Video), cada pedido com dois itens em media, significa que voce vai guardar 10.000 campos redundantes por dia, 3.600.000 por ano todo ano.
Para um negocio pequeno, essa redundancia nao vai gerar impacto significativo, porem o impacto aumenta significativamente a medida que o negocio cresce.
Não seria adequado guardar em outra tabela relacionada ao produto a data de modificação do preço do produto? 2FN? Daí quando fizer a consulta, comparamos com a data do pedido! Para saber o preço do produto naquele dado tempo! É um dado transitório, não concordam?
+Cícero Goss , eu concordo. Se fosse modelar algo nesse dominio de negocio, separaria as tabelas Produto e Preco. A tabela Preco seria um tipo de historico, armazenando tanto o preco atual quanto as alteracoes ao longo do tempo.
boa aula!
Não consegui pegar a diferença entre "pedidos" e "prod_pedido"
o kra peidou nessa aula!rsrsrs 10:39 do video
+sandro silva , pior que parece mesmo!!! Tive que rir! Acredite se quiser: usei um microfone de lapela para gravar os videos, so que o microfone eh muito ruim e gera muita interferencia. Essa ficou engracada.
Isso que é prestar atenção "na aula", porque é quase inaudível o som do "peido", rs...
Falando nisso (11: 22) "UN - UNSIGNED" nao existe no MSSQL.
Eu devo usar o inicio ID com (INT -2147483648 ate 2147483647).
Minha tabela iniciaria com Identity(-2147483648, 1) total de 4294967295 registos. Ou devo fazer algo diferente.
Oque eu realmente tenho que fazer professor?
+srherry , o MySQL oferece algumas "comodidades" que nao sao vistas em outros bancos, uma delas eh o UNSIGNED. Se voce trabalha com Oracle, MSSQL, PostgreSQL e afins, e precisa garantir que um campo numerico seja sempre positvo, minha recomendacao eh voce usar um CHECK CONSTRAINT. Adicionalmente, recomendo que voce nunca use numeros negativos ou de ponto flutuante como chave primaria. Voce vai deixar os programadores furiosos...
vlw !!
prnt.sc/l13dqj corrije pra mim nas 1nf 2nf e 3nf pfr e me manda uma resposta