Histórico BD

Colega,

Relacionamentos n para n são resolvidos por meio de uma entidade associativa.

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

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.

:?:

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 solução apresentada pelo colega Eduardo Pereira parece a mais sofisticada e plausível para o problema apresentado. :)

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