Amigos, cada vez mais percebo a importância de um bom planejamento na hora de fazer um sistema. Jamais imaginei que seria assim. Obrigado, professor, Fábio!
Parabéns Xará. Como este trabalho prático tem contribuído para melhor compreensão e entendimento da parte teórica. Principalmente nesta parte de normalização que é de supra importância e um pouquinho mais complicada. Sinceramente, com seu método de ensinamento tudo fica mais fácil. E o mais importante, mais completo. Valeu, e, ansioso espero pelo próximo vídeo (3FN). Um abraço.
6 років тому+1
Muito obrigado mais uma vez amigo! Próximo vídeo já está no forno. Abraço!
Excelente, vídeo, assim como todo o curso!! Acredito que no caso da tabela de endereço, como o relacionamento com a tabela aluno é 1-n, e o inverso é 1-1, o ideal é a chave primária ser exportada como chave estrangeira na tabela aluno, porque cada aluno só pode ter 1 endereço pela regra de negócio; já um endereço pode contemplar alunos irmãos ou cônjuges, por exemplo. Mas é uma possibilidade, posso estar equivocado. Obrigado, Fabio!!
Na tabela Turma o atributo Período fica um pouco confuso, porque parece que está fazendo referência ao período que o aluno está cursando naquele momento. Exemplo: Turma do quinto período. Eu acho que ficaria mais interessante usar ao invés de período o atributo Turno.
Olá Fábio, tudo bem? Suas explicações são ótimas e me ajudou muito, parabéns! Gostaria de tirar uma dúvida. No caso de telefones_Alunos ao invés de criar uma chave primária para registrar esses telefones eu poderia usar como chaves primárias o próprio número de telefone e o RA do aluno também como chave primária? Nesse caso ficaria teria RA e Num_telefone como chaves primárias
Nesse caso do endereço, fica correto criar uma associativa entre Aluno e Endereço ? Criei uma associativa com o nome de Endereco_Aluno, nela coloquei o código do endereço, RA, número do endereço e o complemento. Liguei na tabela de endereço que contem o Logradouro, CEP, Bairro, Município, Estado e Pais. Também criei uma tabela para o tipo do endereço.
Parabéns pela excelente aula. Gostaria de sanar uma dúvida. Por que a Tabela 'Aluno' não possui as chaves estrangeiras das Tabelas: Telefone_Aluno e Tipo_Telefone ?
Oi Fábio seguinte a tabela telefones_alunos possui um relacionamento n:m com a tabela alunos eu teria que transformar esse relacionamento em 1:n criando outra entidade? obrigado pelo material
Se a tabela professor precisasse conter endereço assim como aluno, seria correto criar uma tabela especifica para endereço e colocar as chaves estrangeiras (aluno e professor) na tabela endereço ou colocar os campos (rua, cep, numero...) nas duas tabelas Aluno e Professor?
Fábio, primeiramente, gostaria de informa que me sinto honrado de ter uma aula de qualidade como esta no youtube, de forma gratuita. Segundo, queria saber se por acaso as datas de inicio e fim da entidade histórico não tem dependência das datas de inicio e fim da entidade turma, pois, elas também constam no histórico.
Olá, jovem Fabio. Td bem? No caso do nome do pai e da mãe, se tivéssemos alunos que são irmãos, no mesmo curso e turma, teriam o mesmo pai e mãe. Esses atributos continuariam a ser dependentes?
Acredito que sim. Entretanto os campos em questão não podem ser o tipo "UNIQUE", caso fossem não poderiam estar associados a mais de um RA, pois seriam únicos em um registro, não permitindo assim seu cadastro em outra ficha de aluno.
Mais ou menos aos 03:50 você diz que o sobrenome do professor (sobrenome_professor) depende de forma conjunta do código do professor e do nome do professor, porém e se na situação houver dois professores com o mesmo sobrenome?, por exemplo os professores Nicole Dias Sá e Rogério Dias Sá. Note que os nomes são diferentes, mas o sobrenome é o mesmo, assim sendo se mudar o código do professor (cod_professor) há a situação de você possuir o mesmo sobrenome, bastando obviamente que duas pessoas tenham o mesmo sobrenome, o mesmo pode acontecer na tabela de alunos, dois irmãos que estudarem na instituição podem ter o mesmo sobrenome, entretanto com nomes diferentes, de novo muda o código do aluno (RA) muda-se o nome, mas necessariamente o sobrenome. Pra resolver essa situação não é melhor criar um campo só para o nome completo?
No endereço do aluno, mesmo separando o endereço em outra tabela, continuamos com o mesmo problema. Na tabela endereco_aluno como utilizamos uma FK para RA, dois alunos com o mesmo endereço geram duas entradas no BD pois os RA são diferentes causando redundância do mesmo jeito. Creio que uma forma de corrigir isso seria tirando a FK de RA na tabela endereco_aluno e adicionando um campo FK cod_endereco_aluno na tabela aluno, assim dois alunos com o mesmo endereço fariam referência ao mesmo cod_encereco_aluno, sem precisar repetir os dados.
Com esse seu raciocínio, só seria possível ter um único endereço por aluno. No vídeo, o professor fala sobre a possibilidade de guardar o endereço comercial do aluno. Para tal, bastaria incluir um campo na tabela Endereco_Aluno e manter a cardinalidade atual. E sim, poderá haver redundância em Endereco_Aluno quando houverem, p.ex., dois irmãos estudando na mesma faculdade.
@@scgalves0 vocês está certo. No entanto, acredito que é completamente desnecessário separar o telefone residencial da tabela aluno por meio da justificativa de que a mesma família possuirá o mesmo telefone. Isso porque, independentemente de criar uma nova tabela essa redundância ainda existirá. Porém, se a regra de negócio diz que o aluno pode der diversos telefones, aí sim uma justificativa válida para fazer tal coisa.
No caso do nome do pai e da mãe, se tivéssemos alunos que são irmãos, no mesmo curso e turma, teriam o mesmo pai e mãe. Esses atributos continuariam a ser dependentes?
A chave primária permite que não aconteça esse erro de integridade,pode haver dois nomes repetidos,mas se eu selecionar o "código 1" vai vim os dados de certo aluno e se eu chamar o "código 2" vai vim dados de outro aluno com o mesmo nome,porém com dados diferentes até pq não se trata da mesma pessoa.
Professor, seria interessante adicionar os campos "cidade", "bairro" e "Estado". Tratando-se de uma faculdade, ela pode receber alunos oriundos de outras cidades e Estados. O que o sr. acha? Obrigado.
Olá Prof.! Sim, você tem toda a razão: estes campos são muito importantes. No vídeo até cito essa ideia, mas acabei não implementando por simplicidade. Mas na prática é altamente aconselhável acrescentar esses dados, provavelmente criando tabelas separadas para armazenar os nomes das cidades e dos estados. E, dependendo da faculdade, até mesmo de países. Abraço!
Olá. Não percebi completamente a lógica para perceber se os atributos dependem do aluno. Porque os argumentos utilizados na morada e no telefone é que se mudar o aluno / RA não necessariamente irá alterar a morada e telefone. Mas isso aplica-se a quase todos os campos. Se mudar o aluno, o primeiro nome pode ser igual, inclusive o ultimo, uma vez que há várias pessoas com o mesmo nome, o sexo também pode ser igual, pois varia apenas de M / F, o status, nome do pai e mãe também podem ser iguais. Obrigado
Sim, tem algumas escolhas de modelagem nesses videos de normalização que parecem mera arbitrariedade. Eu particularmente escolhi por criar tabelas separadas para endereço e telefone, por que eu acho interessante por motivo de registro da faculdade, ter um histórico de telefones e endereços que o aluno já teve, (vai que o cara saiu da casa dos pais durante a faculdade, sei lá, me soa relevante saber o telefone dos pais dele tbm). Mas confesso que refletindo me perguntei como esses diversos registros poderiam ser realmente relevantes pra faculdade ainda mais quando eu penso na quantidade de armazenamento que isso pode consumir em uma escala maior. (uma faculdade que expande o seu numero de campus e numero de alunos por sala, mas conserva a mesma base de dados por exemplo). Ainda, refleti se não seria mais interessante ainda ter um atributo de telefone, e uma entidade separada de telefones antecedentes, que pudesse ser renovado toda vez que a camada de aplicação solicitasse uma atualização no telefone. Como eu falei, são arbitrariedades extremamente relativas, e principalmente relativas a regra de negócio do cliente.
No caso pai e mãe de aluno também não está ligado diretamente ao PK, pq podemos ter 2 ou 3 irmãos na mesma escola.
Amigos, cada vez mais percebo a importância de um bom planejamento na hora de fazer um sistema. Jamais imaginei que seria assim. Obrigado, professor, Fábio!
Show
top!
Muito bom.
Boa, Bóson Treinamentos. Muito obrigado!
Parabéns Xará. Como este trabalho prático tem contribuído para melhor compreensão e entendimento da parte teórica. Principalmente nesta parte de normalização que é de supra importância e um pouquinho mais complicada. Sinceramente, com seu método de ensinamento tudo fica mais fácil. E o mais importante, mais completo. Valeu, e, ansioso espero pelo próximo vídeo (3FN). Um abraço.
Muito obrigado mais uma vez amigo! Próximo vídeo já está no forno. Abraço!
Excelente, vídeo, assim como todo o curso!! Acredito que no caso da tabela de endereço, como o relacionamento com a tabela aluno é 1-n, e o inverso é 1-1, o ideal é a chave primária ser exportada como chave estrangeira na tabela aluno, porque cada aluno só pode ter 1 endereço pela regra de negócio; já um endereço pode contemplar alunos irmãos ou cônjuges, por exemplo. Mas é uma possibilidade, posso estar equivocado. Obrigado, Fabio!!
Tooop
Olá! A chave primária da tabela de Endereco_Aluno não poderia ser o RA do aluno? Por que seria necessária a chave primária Cod_Enderenco_Aluno?
Na tabela Turma o atributo Período fica um pouco confuso, porque parece que está fazendo referência ao período que o aluno está cursando naquele momento. Exemplo: Turma do quinto período. Eu acho que ficaria mais interessante usar ao invés de período o atributo Turno.
Olá Fábio, tudo bem? Suas explicações são ótimas e me ajudou muito, parabéns! Gostaria de tirar uma dúvida. No caso de telefones_Alunos ao invés de criar uma chave primária para registrar esses telefones eu poderia usar como chaves primárias o próprio número de telefone e o RA do aluno também como chave primária? Nesse caso ficaria teria RA e Num_telefone como chaves primárias
ñ deveria ter Cod_EndereçoAluno como FK em Aluno? o mesmo para COd_Telefone_Aluno?
Ali no atributo "Num_Rua" não seria "Num_Casa"?
Nesse caso do endereço, fica correto criar uma associativa entre Aluno e Endereço ?
Criei uma associativa com o nome de Endereco_Aluno, nela coloquei o código do endereço, RA, número do endereço e o complemento.
Liguei na tabela de endereço que contem o Logradouro, CEP, Bairro, Município, Estado e Pais.
Também criei uma tabela para o tipo do endereço.
Parabéns pela excelente aula. Gostaria de sanar uma dúvida. Por que a Tabela 'Aluno' não possui as chaves estrangeiras das Tabelas: Telefone_Aluno e Tipo_Telefone ?
Oi Fábio seguinte a tabela telefones_alunos possui um relacionamento n:m com a tabela alunos eu teria que transformar esse relacionamento em 1:n criando outra entidade?
obrigado pelo material
Se a tabela professor precisasse conter endereço assim como aluno, seria correto criar uma tabela especifica para endereço e colocar as chaves estrangeiras (aluno e professor) na tabela endereço ou colocar os campos (rua, cep, numero...) nas duas tabelas Aluno e Professor?
como tenho um irmão na na hora veio o pensamento da pergunta do Fábio Oliveira... não daria problema em nome do pai e da mãe ?
Fábio, primeiramente, gostaria de informa que me sinto honrado de ter uma aula de qualidade como esta no youtube, de forma gratuita. Segundo, queria saber se por acaso as datas de inicio e fim da entidade histórico não tem dependência das datas de inicio e fim da entidade turma, pois, elas também constam no histórico.
Olá, jovem Fabio. Td bem? No caso do nome do pai e da mãe, se tivéssemos alunos que são irmãos, no mesmo curso e turma, teriam o mesmo pai e mãe. Esses atributos continuariam a ser dependentes?
Bom dia! Ia fazer essa pergunta quando desci você já tinha feito kkk! obteve a resposta?
Acredito que sim. Entretanto os campos em questão não podem ser o tipo "UNIQUE", caso fossem não poderiam estar associados a mais de um RA, pois seriam únicos em um registro, não permitindo assim seu cadastro em outra ficha de aluno.
Vim comentar a mesma coisa.
Mais ou menos aos 03:50 você diz que o sobrenome do professor (sobrenome_professor) depende de forma conjunta do código do professor e do nome do professor, porém e se na situação houver dois professores com o mesmo sobrenome?, por exemplo os professores Nicole Dias Sá e Rogério Dias Sá. Note que os nomes são diferentes, mas o sobrenome é o mesmo, assim sendo se mudar o código do professor (cod_professor) há a situação de você possuir o mesmo sobrenome, bastando obviamente que duas pessoas tenham o mesmo sobrenome, o mesmo pode acontecer na tabela de alunos, dois irmãos que estudarem na instituição podem ter o mesmo sobrenome, entretanto com nomes diferentes, de novo muda o código do aluno (RA) muda-se o nome, mas necessariamente o sobrenome.
Pra resolver essa situação não é melhor criar um campo só para o nome completo?
Qual carteira bitcoin você utiliza?
No endereço do aluno, mesmo separando o endereço em outra tabela, continuamos com o mesmo problema. Na tabela endereco_aluno como utilizamos uma FK para RA, dois alunos com o mesmo endereço geram duas entradas no BD pois os RA são diferentes causando redundância do mesmo jeito. Creio que uma forma de corrigir isso seria tirando a FK de RA na tabela endereco_aluno e adicionando um campo FK cod_endereco_aluno na tabela aluno, assim dois alunos com o mesmo endereço fariam referência ao mesmo cod_encereco_aluno, sem precisar repetir os dados.
Com esse seu raciocínio, só seria possível ter um único endereço por aluno. No vídeo, o professor fala sobre a possibilidade de guardar o endereço comercial do aluno. Para tal, bastaria incluir um campo na tabela Endereco_Aluno e manter a cardinalidade atual.
E sim, poderá haver redundância em Endereco_Aluno quando houverem, p.ex., dois irmãos estudando na mesma faculdade.
@@scgalves0 vocês está certo. No entanto, acredito que é completamente desnecessário separar o telefone residencial da tabela aluno por meio da justificativa de que a mesma família possuirá o mesmo telefone. Isso porque, independentemente de criar uma nova tabela essa redundância ainda existirá. Porém, se a regra de negócio diz que o aluno pode der diversos telefones, aí sim uma justificativa válida para fazer tal coisa.
@@flawtista Ele cometeu alguns erros nesse vídeo. Pelo menos foi o que percebi.
No caso do nome do pai e da mãe, se tivéssemos alunos que são irmãos, no mesmo curso e turma, teriam o mesmo pai e mãe. Esses atributos continuariam a ser dependentes?
Venho expor a mesma dúvida.
Fiquei um pouco confusa do pq a tabela Aluno nao possui uma chave estrangeira de endereço.
Pq ele já colocou a chave estrangeira da tabela aluno na tabela endereço,mas eu tenho outro questionamento,pq não poderia ser o inverso?
Exato, Por que a Tabela 'Aluno' não possui as chaves estrangeiras das Tabelas: Telefone_Aluno e Tipo_Telefone ?
Mas podem haver vários alunos com o mesmo nome. Sendo assim, por que "Nome_Aluno" depende da chave primária da tabela aluno?
pelo que eu entendi, o nome do aluno depende do RA, então pode até ter dois alunos com o mesmo nome, mas terão RA's diferentes
A chave primária permite que não aconteça esse erro de integridade,pode haver dois nomes repetidos,mas se eu selecionar o "código 1" vai vim os dados de certo aluno e se eu chamar o "código 2" vai vim dados de outro aluno com o mesmo nome,porém com dados diferentes até pq não se trata da mesma pessoa.
A tabela Disciplina neste video esta com o Cod_Disciplina PK e FK está correto?
Não tá não, a ID_Disciplina tem origem na propria tabela Disciplina, ela é FK em outras tabelas, não em disciplina em si
Professor, seria interessante adicionar os campos "cidade", "bairro" e "Estado". Tratando-se de uma faculdade, ela pode receber alunos oriundos de outras cidades e Estados. O que o sr. acha? Obrigado.
Olá Prof.! Sim, você tem toda a razão: estes campos são muito importantes. No vídeo até cito essa ideia, mas acabei não implementando por simplicidade. Mas na prática é altamente aconselhável acrescentar esses dados, provavelmente criando tabelas separadas para armazenar os nomes das cidades e dos estados. E, dependendo da faculdade, até mesmo de países.
Abraço!
observando que com o CEP podemos saber cidade, estado e em alguns casos bairro.
Sei que teve um início só não sei qual, tudo teve um começo até o universo
Tenho uma dúvida, e se o nome do aluno for igual a de outro aluno, ou seja heterônimo, pode haver algum conflito?
Não, pois eles se diferenciam pelo RA.
O sexo tb não poderia ser um atributo independente? Existem várias pessoas do sexo masculino ou feminino.
Mas cada aluno tem seu sexo definido,ou seja,ela depende do aluno.Penso dessa forma..
Olá. Não percebi completamente a lógica para perceber se os atributos dependem do aluno. Porque os argumentos utilizados na morada e no telefone é que se mudar o aluno / RA não necessariamente irá alterar a morada e telefone. Mas isso aplica-se a quase todos os campos. Se mudar o aluno, o primeiro nome pode ser igual, inclusive o ultimo, uma vez que há várias pessoas com o mesmo nome, o sexo também pode ser igual, pois varia apenas de M / F, o status, nome do pai e mãe também podem ser iguais. Obrigado
Sim, tem algumas escolhas de modelagem nesses videos de normalização que parecem mera arbitrariedade. Eu particularmente escolhi por criar tabelas separadas para endereço e telefone, por que eu acho interessante por motivo de registro da faculdade, ter um histórico de telefones e endereços que o aluno já teve, (vai que o cara saiu da casa dos pais durante a faculdade, sei lá, me soa relevante saber o telefone dos pais dele tbm). Mas confesso que refletindo me perguntei como esses diversos registros poderiam ser realmente relevantes pra faculdade ainda mais quando eu penso na quantidade de armazenamento que isso pode consumir em uma escala maior. (uma faculdade que expande o seu numero de campus e numero de alunos por sala, mas conserva a mesma base de dados por exemplo). Ainda, refleti se não seria mais interessante ainda ter um atributo de telefone, e uma entidade separada de telefones antecedentes, que pudesse ser renovado toda vez que a camada de aplicação solicitasse uma atualização no telefone. Como eu falei, são arbitrariedades extremamente relativas, e principalmente relativas a regra de negócio do cliente.