Pessoal, estou com um problema e não sei como modelar. O problema acho que se parece com herança, mas a questão é que não existe aquela relação de “é um”. Vou explicar.
Eu tenho uma atividade que pode ser executada por uma pessoa ou um grupo de pessoas. Como nos sistemas operacionais. Temos Raquel, Cristiano e Pedro como Analistas e Marcos como Administrador. Você pode delegar uma tarefa para a Raquel ou para Analistas (qualquer um dos). Como posso fazer isso?
As tabelas acho que poderiam ser:
USUARIOS
ID
NOME
etc.
GRUPOS
ID
NOME
USUARIO_GRUPO
ID_GRUPO
ID_USUARIO
TAREFA
…
eu posso linkar com GRUPO ou USUARIO, mas como?
Eu acho que a ideia de termos 2 campos em TAREFA que nunca estarão preenchidos ao mesmo tempo, mas apenas um, meio tosca.
Acho que você sempre tem que associar a tarefa a um grupo. Crie quantos grupos quiser, mesmo que tenha apenas um componente presente neste grupo. Na verdade, o grupo não seria uma espécie de “Role” (perfil)?
Mas do jeito que você falou ficaria super “gambi” em algumas situações.
Por exemplo, tem uma tarefa que eu quero que só a Raquel faça. E ela é analista. Eu vou ter que criar um grupo Analista Raquel que só tenha ela? Eu teria que ter um grupo com um membro para cada usuário do sistema! Nem sempre eu vou querer que qualquer analista faça.
usuario --> usuariotarefa <-- tarefa
usuario --> grupousuario <-- grupo
tarefa --> grupotarefas <-- grupo
E se necessário saber quem do grupo assumiu ou fez a tarefa ainda podemos:
colocar um atributo na tabela grupotarefas <–> usuario ou melhor ainda, para o caso de mais de um usuário ter feito (ou responsável pela) a tarefa:
grupotarefas --> grupotarefasusuarios <-- usuario.
Eu jamais recorreria a uma modelagem hierárquica, para um problema que não possui hierarquia imposta na regra de negócio (aplicação do conceito de perfil ou rules proposto), mas é um preconceito meu.
No caso da OO, você poderia criar uma interface, chamada responsável (por exemplo), os objetos grupo e usuarios poderiam implementar essa interface. E a tarefa pode ter uma propriedade responsavel ou responsaveis.
usuario --> usuariotarefa <-- tarefa
usuario --> grupousuario <-- grupo
tarefa --> grupotarefas <-- grupo
E se necessário saber quem do grupo assumiu ou fez a tarefa ainda podemos:
colocar um atributo na tabela grupotarefas <–> usuario ou melhor ainda, para o caso de mais de um usuário ter feito (ou responsável pela) a tarefa:
grupotarefas --> grupotarefasusuarios <-- usuario.
Eu jamais recorreria a uma modelagem hierárquica, para um problema que não possui hierarquia imposta na regra de negócio (aplicação do conceito de perfil ou rules proposto), mas é um preconceito meu.
No caso da OO, você poderia criar uma interface, chamada responsável (por exemplo), os objetos grupo e usuarios poderiam implementar essa interface. E a tarefa pode ter uma propriedade responsavel ou responsaveis.
fw[/quote]
Nossa. Gostei demais desta solução! Acho que vou usuá-la!
Bem, eu não ia querer com hierarquia, eu apenas quis dizer que se assemelha ao problema por estarmos relacionando a “possíveis” coisas, diferentes. Tipo, em vez de associar um grupo a um usuário, eu estaria associando uma tarefa a um: ou grupo ou usuário. Assim como na herança onde algo pode estar relacionado a um: filho ou pai ou avô ou ?
