Distribuição de entidades

[FabianoSouza 5]

Pessoal, não sou nenhum fera em modelagem, por isso estou recorrendo ao fórum.
Meu problema se refere às entidades Curso, Turmas e Inscritos.

Pela lógica, há uma hierarquia nisso, certo?
Ou seja, um Curso têm muitos Turmas e uma Turma têm muitos Inscritos. Ok?

Situação 1
Bom, quero saber se numa situação é correto que o usuário possa criar estes três itens de forma independente seguindo a regra:

Ao criar um Inscrito é requerido um Curso e uma Turma.
Ao criar uma Turma é requerido um Curso.

Situação 2
Ou então se o cara tem que sempre criar um a Turma "dentro do Curso" e o Inscrito "dentro da Turma",

Deu pra entender?

A situação 2 parece mais lógica e rígida. A situação 1 parece mais flexível e "menos lógica".

Obrigado.

[Bruno Augusto 417]

No contexto de o que parece ser uma escola, um curso nada mais é do que uma categoria que, por si só, já é uma coisa bem definida. Uma categoria não precisa daquilo que ela categoriza para existir.

 

Já a recíproca não é verdadeira. Numa escola em que é necessário formar uma Turma, a Turma é turma de algum curso, logo ela depende da existência da categoria, no caso de um Curso.

 

Porém, às vezes, uma Turma pode ser turma de mais de um curso por isso não pode ser uma relação 1:1. Um assim comumente chamado Curso de Webdesign, por exemplo, é composto por vários cursos como Photoshop, Fireworks, Flash... Logo uma Turma de Webdesign, que é a notação mais apropriada (já que "Curso de Webdesign não existe - na minha opinião) se relaciona com vários Cursos diferentes.

 

Quanto à obrigatoriedade de um inscrito estar associado à uma Turma, eu vejo como sendo uma afirmação inválida, afinal sempre há a possibilidade de um aluno preferir pagara a mais para ter a totalidade da atenção do professor e concluir o curso de forma mais rápida.

 

Logo, um aluno pode estar diretamente relacionado com um ou mais cursos, como se ele fosse sua própria Turma. Como programaticamente falando isso pode ser difícil de modelar (pelo menos pra mim que não mano muito), você poderia criar uma ou mais Turmas "VIP" as quais aceitariam um único aluno cada e te permite reutilizar uma mesma modelagem para dois cenários.

[FabianoSouza 5]

Olá Bruno.

Bem interessantes seu ponto de vista. Passei semanas refletindo sobre sua perspectiva.

No meu caso é uma ferramenta para ajudar o gerenciamento de cursos do RH de onde trabalho.

 

Minha lógica é a seguinte. Um curso no meu caso, tem várias informações como carga horária, nota de corte, metodologia, público alvo e etc. Então criei um "cardápio" de cursos. Pois cada um deles será realizado inúmeras vezes (através de turmas distintas).

 

Acredito que preciso ter na minha estrutura um curso (que será "reutilizado"), as turmas (1, 2, 3...) deste curso e por fim, cada turma terá seus participantes.

 

Para minha realidade esta lógica parece fazer sentido.

 

 

Queria a opinião dos colegas para saber se a coisa está coerente.

[Bruno Augusto 417]

Se entendi bem é justamente o que eu disse.

 

Quando você separa as informações em tabelas distintas você já tem a possibilidade de reutilização pois cada nova Turma inserida requisitará um ID de um Curso previamente cadastrado em outra tabela e na hora de "ler" essas informações você poderia, por exemplo, agrupar pelo ID do Curso ou seu nome...

[FabianoSouza 5]

Perfeito!

Muito obrigado.