📚 GRUPO de preparação para CONCURSOS DE TI: Telegram: t.me/+EhlbaxZ7BsIwYjEx ⭐ Seja membro do canal e tenha acesso a todos os PDFs das aulas, além de conteúdos exclusivos: www.youtube.com/@ArnaldoJunior/join ❤ Inscreva-se: youtube.com/@ArnaldoJunior?sub_confirmation=1
Fiquei na dúvida sobre a exclusão da relação certificado. Se a relacao e de N:N nao deve virar uma tabela? A composicao nao poderia ser resolvida com uma chave estrangeira da equipe com participante?
Excelente Aula Professor👏 Tenho uma dúvida caso soube me ajudar, chave candidata são as chaves possíveis para serem escolhidas como PK Já as chaves que não foram escolhida com PK mais tem os mesmos atributos, podem ser chamadas de chave secundária, alternativa e única?
Professor, primeiramente obrigado pelo vídeo. Mas acho que deveria focar em questões da Cesgranrio. Aliás, se houvesse um material que respondesse passo a passo as questões recentes da Cesgranrio eu seria capaz de comprá-lo. As questões da Cesgranrio são bem mais difíceis e técnicas que as do Cespe. Até a notação de conjuntos é incomum.
Atributo chave, identifica exclusivamente um registro, o CPF, por exemplo. Atributo composto, é formado por subinformações, tal como o endereço, que possui quadra, lote, rua, etc.
Professor, essa questão do Hackathon deixou-me um pouco confuso. Eu fui primeiramente pelas cardinalidades Opicionais, ou seja solicitação e Certificado, ambos os lados são (0:n) (0n), ou seja, opicionais. Daí eu tirei a lógica que os dois relacionamentos poderiam ser descatáveis. Aparentemente não era, o que eu deveria pestar atenção era a leitura do texto que estava acima. Existe uma solicitação que deve constar o parcitipante que solicitou o auxilio, o mentor solicitado e a hora da solicitação - ENTÃO isso é obrigatório e ficaria assim: Participante(**CPF_Participante, nome, Formação, *CPF_Mentor, *nome_equipe) CPF_Participante PK, CPF_Mentor referência MENTOR, nome_equipe referência Equipe Solicitação(**(PK)CPF_Participante, **CPF_Mentor, data_hora) CPF_Participante PK, CPF_Participante referencia Participante e CPF_Mentor referencia Mentor Mentor(**CPF_Mentor, nome, especialidade, Equipe(**nome_equipe, instituição, cidade) AO FINAL: Cada participante recebe um certificado que constam seus dados pessoais e de sua equipe. Não vejo como não construir um certificado sem uma tabela própria, se eu colocasse ele em Mentor por exemplo, eu teria que ter uma chave estrageira chamada id_certificado e nome_certificado que seria referenciado também em equipe e Participante?
E Mais: Por que não poderia fazer isso em solicitação? n:n o melhor caso é construir uma tabela a mais. Mas não vi como esse relacionamento poderia sumir, por favor professor, consegue me dar uma luz?
📚 GRUPO de preparação para CONCURSOS DE TI:
Telegram: t.me/+EhlbaxZ7BsIwYjEx
⭐ Seja membro do canal e tenha acesso a todos os PDFs das aulas, além de conteúdos exclusivos:
www.youtube.com/@ArnaldoJunior/join
❤ Inscreva-se:
youtube.com/@ArnaldoJunior?sub_confirmation=1
Prof, sua forma de explicar é muito boa.
Forte abraço!
Valeu, mestre! Bons estudos!
obg pela aula e pdf!
Bons estudos!
muito bom professor
Valeu!
Poxa pessoal....mais de 5 mil visualizações e apenas 367 curtidas ? tá bem desproporcional isso aí ! vamos agradecer !
Agradeço!
Eu to amando as vídeo aulas desse professor, que didática maravilhosa, estou maratonando todos os vídeos e dando like em todos!
@@DipyBs agradeço 🙏
Fiquei na dúvida sobre a exclusão da relação certificado. Se a relacao e de N:N nao deve virar uma tabela? A composicao nao poderia ser resolvida com uma chave estrangeira da equipe com participante?
Na relação N:N, a fusão de tabelas é a opção mais indicada, mas não a única possibilidade.
Fazendo as últimas revisões antes da CAIXA! Obrigado pelas aulas Professor!
Vai pra cima!
didática muito boa, ótimo vídeo!
Obrigado!
Monstro! Vou ver todos os vídeos. o/
Valeu, Victor!
Thanks!!
Professor instância é mesma coisa que registro ou tupla ?
Pode-se dizer que sim. Em uma tabela de clientes, por exemplo, um registro contendo meus dados pode ser considerado uma instância do modelo.
Muito bom
Excelente Aula Professor👏
Tenho uma dúvida caso soube me ajudar, chave candidata são as chaves possíveis para serem escolhidas como PK
Já as chaves que não foram escolhida com PK mais tem os mesmos atributos, podem ser chamadas de chave secundária, alternativa e única?
Entendo que chaves candidatas e alternativas dizem respeito a mesma coisa.
Muitíssimo bem feito, obrigado
Obrigado!
Professor, primeiramente obrigado pelo vídeo. Mas acho que deveria focar em questões da Cesgranrio. Aliás, se houvesse um material que respondesse passo a passo as questões recentes da Cesgranrio eu seria capaz de comprá-lo.
As questões da Cesgranrio são bem mais difíceis e técnicas que as do Cespe. Até a notação de conjuntos é incomum.
Obrigado pelas dicas, vou considerá-las. Grande abraço!
Excelente conteúdo professor, virei assinante. Uma dúvida na questão 7: posso considerar então que entidade é diferente de ator?
Sim. A entidade representa algo do mundo que está sendo modelado. O ator é quem opera sobre esse algo.
Muito obrigado pelo apoio! Sucesso!
Rumo a aprovação!
Isso aí!
Professor,não entendi muito a diferença dos atributos chave,composto..poderia me explicar
Atributo chave, identifica exclusivamente um registro, o CPF, por exemplo. Atributo composto, é formado por subinformações, tal como o endereço, que possui quadra, lote, rua, etc.
@@ArnaldoJunior entendi 👏👏 vlww
Serve pra tec bancário caixa?
Se for sobre modelagem de banco de dados, serve sim.
serve para PF?
Tem que olhar os editais dos concursos anteriores, se tiver modelagem de banco de dados, então serve.
Professor, essa questão do Hackathon deixou-me um pouco confuso.
Eu fui primeiramente pelas cardinalidades Opicionais, ou seja solicitação e Certificado, ambos os lados são (0:n) (0n), ou seja, opicionais. Daí eu tirei a lógica que os dois relacionamentos poderiam ser descatáveis.
Aparentemente não era, o que eu deveria pestar atenção era a leitura do texto que estava acima.
Existe uma solicitação que deve constar o parcitipante que solicitou o auxilio, o mentor solicitado e a hora da solicitação - ENTÃO isso é obrigatório e ficaria assim:
Participante(**CPF_Participante, nome, Formação, *CPF_Mentor, *nome_equipe) CPF_Participante PK, CPF_Mentor referência MENTOR, nome_equipe referência Equipe
Solicitação(**(PK)CPF_Participante, **CPF_Mentor, data_hora) CPF_Participante PK, CPF_Participante referencia Participante e CPF_Mentor referencia Mentor
Mentor(**CPF_Mentor, nome, especialidade,
Equipe(**nome_equipe, instituição, cidade)
AO FINAL: Cada participante recebe um certificado que constam seus dados pessoais e de sua equipe.
Não vejo como não construir um certificado sem uma tabela própria, se eu colocasse ele em Mentor por exemplo, eu teria que ter uma chave estrageira chamada id_certificado e nome_certificado que seria referenciado também em equipe e Participante?
E Mais: Por que não poderia fazer isso em solicitação? n:n o melhor caso é construir uma tabela a mais. Mas não vi como esse relacionamento poderia sumir, por favor professor, consegue me dar uma luz?