Histórico BD
Caros Colegas,
Estou com uma dúvida em relação à modelagem.
Seguinte: Imaginem um sistema acadêmico no qual existam cursos. Cada curso tem um único coordenador e um coordenador só pode coordenar um curso, configurando assim um relacionamento 1:1.
No entanto, precisamos guardar todo um histórico de instâncias anteriores do BD, pois um coordenador pode já ter coordenado vários cursos, assim como um curso pode já ter tido vários coordenadores (no passado), configurando um relacionamento n:m.
Alguém poderia me dar uma dica de qual seria a melhor forma de modelar um sistema desse tipo?
Nando
[color=green:8bb6fccb25]Título editado por gandalf.nho. Favor não postar em maiúsculas.[/color:8bb6fccb25]
Estou com uma dúvida em relação à modelagem.
Seguinte: Imaginem um sistema acadêmico no qual existam cursos. Cada curso tem um único coordenador e um coordenador só pode coordenar um curso, configurando assim um relacionamento 1:1.
No entanto, precisamos guardar todo um histórico de instâncias anteriores do BD, pois um coordenador pode já ter coordenado vários cursos, assim como um curso pode já ter tido vários coordenadores (no passado), configurando um relacionamento n:m.
Alguém poderia me dar uma dica de qual seria a melhor forma de modelar um sistema desse tipo?
Nando
[color=green:8bb6fccb25]Título editado por gandalf.nho. Favor não postar em maiúsculas.[/color:8bb6fccb25]
Paulo Fernando
Curtidas 0
Respostas
Aroldo Zanela
08/06/2005
Colega,
Relacionamentos n para n são resolvidos por meio de uma entidade associativa.
Relacionamentos n para n são resolvidos por meio de uma entidade associativa.
GOSTEI 0
Paulo Fernando
08/06/2005
Caro Colega,
Entendo que o relacionamento seja resolvido de forma associativa, como vc disse, no entanto, acho que vc não entendeu a minha dúvida.
No primeiro caso (relacionamento 1:1) bastaria entrar com a matrícula do professor/coordenador na tabela de cursos e estaria resolvido o problema, certo?
Porém, se quero guardar todo um histórico, a solução não seria viável dessa forma, pois tornaria o relacionamento n:m, o que acarretaria uma nova tabela coordenador/curso a ser criada com as chaves das duas tabelas.
Pois bem, se optarmos por essa última solução corremos o risco de ter dois coordenadores associados a um mesmo curso e isso não seria correto, já que o relacionamento coordendor/curso é 1:1.
Espero ter sido mais claro dessa vez. Caso vc ou qualquer outra pessoa tenha alguma solução, ficarei grato.
Paulo Fernando
Entendo que o relacionamento seja resolvido de forma associativa, como vc disse, no entanto, acho que vc não entendeu a minha dúvida.
No primeiro caso (relacionamento 1:1) bastaria entrar com a matrícula do professor/coordenador na tabela de cursos e estaria resolvido o problema, certo?
Porém, se quero guardar todo um histórico, a solução não seria viável dessa forma, pois tornaria o relacionamento n:m, o que acarretaria uma nova tabela coordenador/curso a ser criada com as chaves das duas tabelas.
Pois bem, se optarmos por essa última solução corremos o risco de ter dois coordenadores associados a um mesmo curso e isso não seria correto, já que o relacionamento coordendor/curso é 1:1.
Espero ter sido mais claro dessa vez. Caso vc ou qualquer outra pessoa tenha alguma solução, ficarei grato.
Paulo Fernando
GOSTEI 0
Beppe
08/06/2005
Acho que eu não entendi também, pq parece simples em demasiado. Mas se eu entendi bem, só acrescente outra entidade ([u:209b89b290]Coordenador, Curso[/u:209b89b290], <mais atributos como desejado>).
Ao mudar algo nos cursos, insira um registro nesta tabela.
:?:
Ao mudar algo nos cursos, insira um registro nesta tabela.
:?:
GOSTEI 0
Eduardo Pereira
08/06/2005
Para manter o histórico de associações entre coodrenador e cursos a solução é a propostas pelos colegas: uma entidade associativa com a chaves das duas entidades.
A confusão quanto a cardinalidade é porque um coordenardor só pode coordenar um curso (e vice-versa) em um determinado momento do tempo (cardinalidade 1:1). Ao longo do tempo, porém, um coordenador poderá ter coordenado vários cursos e um curso poderá ter sido coordenado por vários coordenadores. Quando se considera relacionamentos ao longo do tempo, eles sempre tenderão a ser n:m.
No seu caso, poderiam ser usados na tabela associativa, além das chaves primárias de coordenador e curso, atributos de data de inicio e data de término da coordenação. Consultando esta tabela se obtém todo o histórico de coordenações de um coordenador ou de um curso. Para saber a coordenação atual de um curso ou coordenador, basta localizar o registro da tabela associativa que tem data término nula.
A restrição de um coordenador só poder coordenar um curso e um curso só poder ser coordenado por um coordenador deve ser implementada por um trigger.
Esta modelagem ainda tem a vantagem de ser mais flexível. Se houver alguma mudança nas regras de negócio, como um coordenador passar a poder coordenar mais de um curso, a única alteração deverá ser feita no trigger.
[]´s
Eduardo Pereira
A confusão quanto a cardinalidade é porque um coordenardor só pode coordenar um curso (e vice-versa) em um determinado momento do tempo (cardinalidade 1:1). Ao longo do tempo, porém, um coordenador poderá ter coordenado vários cursos e um curso poderá ter sido coordenado por vários coordenadores. Quando se considera relacionamentos ao longo do tempo, eles sempre tenderão a ser n:m.
No seu caso, poderiam ser usados na tabela associativa, além das chaves primárias de coordenador e curso, atributos de data de inicio e data de término da coordenação. Consultando esta tabela se obtém todo o histórico de coordenações de um coordenador ou de um curso. Para saber a coordenação atual de um curso ou coordenador, basta localizar o registro da tabela associativa que tem data término nula.
A restrição de um coordenador só poder coordenar um curso e um curso só poder ser coordenado por um coordenador deve ser implementada por um trigger.
Esta modelagem ainda tem a vantagem de ser mais flexível. Se houver alguma mudança nas regras de negócio, como um coordenador passar a poder coordenar mais de um curso, a única alteração deverá ser feita no trigger.
[]´s
Eduardo Pereira
GOSTEI 0
Mordred
08/06/2005
A solução apresentada pelo colega Eduardo Pereira parece a mais sofisticada e plausível para o problema apresentado. :)
GOSTEI 0
Luiz_ro
08/06/2005
Complementando ainda a resposta do colega Eduardo, você poderia utilizar como atributo identificador do relacionamento (entidade associativa) a data de início da coordenação, dessa forma, quando você fizer a transformação, vc pode usar como chave primária da tabela associativa o conjunto formado por: cod_coordenador/cod_curso/data_inicio_coordenacao. Mas, caso prefira, pode usar um código que distinguirá um registro dos demais, ou seja uma coordenação da outra (na tabela associativa).
Boa sorte,
Luiz
Boa sorte,
Luiz
GOSTEI 0