Olá, Alexander. Como vai?
Seu diagrama está muito completo e demonstra um excelente avanço na compreensão de Modelagem de Dados. Você conseguiu mapear bem o fluxo complexo de uma conferência científica, incluindo desde a submissão de artigos até a organização das sessões.
Analisando a imagem do seu modelo conceitual, ele faz bastante sentido, mas gostaria de destacar alguns pontos técnicos importantes para garantir que sua modelagem esteja preparada para a fase lógica (quando virar tabelas no banco de dados):
IDParticipante, IDConferencia, etc.) sublinhando-as. Isso é fundamental para garantir a integridade referencial no SQL.Material). Na modelagem ER, isso indica uma Entidade Fraca, que depende da existência de outra (neste caso, o material só existe se houver uma apresentação). Está correto e muito bem aplicado.1,n, 0,n e 1,1 estão bem posicionadas. Por exemplo, a relação entre Sessões e Apresentações como 1,1 para 1,n indica que uma sessão deve obrigatoriamente incluir pelo menos uma apresentação, o que reflete bem a realidade de um evento.Dicas de Boas Práticas para Refinamento:
Apresentações, você tem o atributo DuraçãoPrevista. Se no futuro você tiver o horário de início e fim, a duração passaria a ser um atributo derivado (representado por uma elipse tracejada), pois pode ser calculada.avaliar entre revisores e Artigos/resumos, você colocou os atributos Decisão e Feedback ligados ao losango. Essa é a forma correta de modelar dados que pertencem ao fato da avaliação e não especificamente ao revisor ou ao artigo isoladamente.Participante não poderia ser dividida ou se os tipos de participação (palestrar, ouvir, organizar) não seriam melhor representados por uma tabela de Papéis, evitando repetição de dados básicos (como nome e e-mail).Seu modelo está muito maduro e cobre as principais regras de negócio de um evento científico. O próximo passo será converter essas entidades em tabelas e os relacionamentos em chaves estrangeiras (Foreign Keys).
Espero que possa ter lhe ajudado!