Excelente aula, aprendi muitos conceitos novos. 👏👏👏 Eu só não entendi na parte do relacionamento "cursar". Se não é obrigado virar uma tabela então pq esse relacionamento tem atributos ? 🤔🤔🤔
Caso mais alguém tenha essa dúvida, aqui vai uma explicação: Os atributos devem ser colocados nas entidades quando eles estão diretamente relacionados à entidade em si e não dependem da relação em que a entidade está envolvida. Por exemplo, considere um sistema de reserva de voos, onde você tem as entidades "passageiro" e "voo". A relação entre essas entidades pode ser "reserva", e nessa relação você pode ter atributos como "data da reserva", "classe do assento" ou "status da reserva". Esses atributos estão diretamente relacionados à relação "reserva" e não são características das entidades "passageiro" ou "voo". Outro cenário em que é apropriado usar atributos na relação é quando você tem atributos derivados que são calculados com base nas entidades relacionadas. Ou seja estar ou não na relação não é razão para virar tabela visto que, a depender da cardinalidade esses atributos podem ir para uma tabela ou outra da relação.
na entidade Fones_Alunos, 'telefone' e 'mat_alunoFK' serão AMBAS chaves primárias? 'mat_alunoFK' não deveria ser chave estrangeira? Não percebi bem essa última parte. A mesma dúvida surge na entidade Aluno_Disciplina_cursar. 'semestre', 'mat_alunoFK' e 'cod_disciplinaFK' são as 3 chaves primárias? Excelente aula professor.
Olá Tomas, fico feliz que você tenha gostado da aula. Obrigado! Sobre suas dúvidas, realmente 'mat_alunoFK' é uma chave estrangeira que referencia a chave primária de aluno. Porém, além de chave estrangeira, ela também compõe a chave primária da tabela 'Fones_Alunos', juntamente com o atributo 'telefone'. Há a necessidade de ser uma chave composta, para que o mesmo aluno possa ter vários telefones e, eventualmente, o mesmo 'telefone' possa ser atribuído a diferentes alunos. Sobre a tabela 'Aluno_Disciplina_cursar', fruto do relacionamento 'cursar', além das duas chaves estrangeiras, o atributo 'semestre' precisa fazer parte da chave primária por ser uma 'chave fraca' no modelo conceitual; isto é, para possibilitar que o 'mesmo aluno' possa cursar a 'mesma disciplina' mais de uma vez, desde que seja em 'semestres diferentes'. Dessa forma, o banco de dados será capaz de armazenar o 'histórico' de notas e faltas de cada vez que o aluno cursou a disciplina.
Acho que errou, devia existir uma ligação entre o funcionário e o cliente, não entre funcionário e o empréstimo. porque no enunciado diz que "Um cliente pode ser atendido por 1 ou mais funcionários e um funcionário pode atender um ou mais clientes DE CADA VEZ "
Olá Humberto, peço desculpas pela demora em te responder. Hoje estava passando por alguns comentários não lidos e vi o seu. Acho que ele é relativo a outro vídeo, sobre modelagem conceitual. Sobre esse ponto, realmente há diferentes maneiras de se resolver o problema; essa é uma das belezas da modelagem, não é mesmo? A maneira que você sugere é possível sim: trocar um relacionamento ternário por relacionamentos binários. O enunciado na verdade induz mais para essa interpretação. Porém, quando possível, é muito bom ter relacionamentos "N"ários no modelo, desde que sejam relacionamentos legítimos e não forçados. Isso tende a reduzir a complexidade das consultas, reduzindo a necessidade de "joins", entende? Mas repito, a sua proposta de solução está igualmente correta e expressaria a mesma "informação" Mais uma vez, obrigado por seu comentário.
