Monitoria

Parte 1

Vamos conferir o enunciado:

Muitas universidades, como a UFMT, ofertam programas de monitoria acadêmica, em que um estudante já aprovado em uma disciplina pode atuar como monitor, apoiando o docente e os estudantes no processo de ensino-aprendizagem. Qual diagrama ER possibilita representar um banco de dados para esse programa?

Como discutimos em sala de aula, há diferentes possibilidades de se resolver este exercício.

Solução com relacionamento envolvendo uma entidade associativa

ESTUDANTE(<u>rga</u>, nome)
DISCIPLINA(<u>codigo</u>,nome)
MONITORIA(<u>codigo</u>,status)

/* Entidade associativa */
CURSA(ESTUDANTE,DISCIPLINA,status,<u>semestre</u>)

/* Relacionamentos */
PARTICIPA(CURSA,MONITORIA) 1,N # se CURSA.status == APROVADO
OFERTA(DISCIPLINA,MONITORIA,<u>semestre</u>)

No caso acima, ESTUDANTE é ligado à DISCIPLINA pelo relacionamento CURSA, que armazena informações importantes: o semestre do vínculo e o status, atributo que pode ser APROVADO ou REPROVADO. A cardinalidade desse relacionamento é N:N, já que um aluno pode cursar várias disciplinas e uma disciplina pode ser cursada por vários alunos.

Entre DISCIPLINA e MONITORIA, há um relacionamento chamado OFERTA, com cardinalidade 1:N (há várias monitorias para uma disciplina, mas uma monitoria só pertence a uma disciplina). Esse relacionamento existe porque a lógica adotada na elaboração da resposta assume que uma monitoria é ofertada para uma disciplina, sem a necessidade de vinculação de um estudante à monitoria para a sua criação. Em analogia ao mundo real, é como se o estudante fosse selecionado depois, quando a monitoria já foi criada.

Por falar em estudante, agora vamos pensar no seu caso particular: o seu relacionamento com a MONITORIA. Esse relacionamento terá cardinalidade 1:N, pois o entendimento aqui é que um estudante pode participar de várias monitorias, mas uma monitoria só tem um estudante. Considere, então, que se uma disciplina tiver dois monitores no mesmo semestre, são duas monitorias diferentes. Essa, por acaso, é a lógica adotada pela UFMT.

Voltando à dinâmica do relacionamento, queremos aqui garantir que o estudante vinculado como monitor tenha sido aprovado na disciplina. Um caminho possível, portanto, é transformar CURSA em uma entidade associativa (o que é possível, já que a cardinalidade entre as entidades é N:N. Assim, podemos estabelecer um relacionamento (PARTICIPA) entre CURSA e MONITORIA, com cardinalidade 1:N (como já explicado). A ideia é: a aprovação de ALUNO em DISCIPLINA o habilita a atuar em diversas ocorrências de MONITORIA. Assim, na ligação desse relacionamento, indicamos a necessidade de uma restrição: para que este relacionamento seja válido, o atributo status de CURSA deve ter o valor APROVADO. Essa restrição precisará ser tratada pelo SBGD quando houver a inserção de uma instância de relacionamento.

Solução sem relacionamento com a entidade associativa

A segunda possibilidade de resolver o enunciado envolve relacionamentos binários entre entidades típicas. Os tipos de entidade ESTUDANTE, DISCIPLINA e MONITORIA continuam iguais, assim como os relacionamentos CURSA e OFERTA.

A grande mudança passa a ser no relacionamento PARTICIPA que, em vez de relacionar CURSA e MONITORIA, pode passar a relacionar ESTUDANTE e MONITORIA.

ESTUDANTE(<u>rga</u>, nome)
DISCIPLINA(<u>codigo</u>,nome)
MONITORIA(status)

CURSA(ESTUDANTE,DISCIPLINA,status(APROVADO,REPROVADO),<u>semestre</u>)

/* Relacionamentos */
PARTICIPA(ESTUDANTE,MONITORIA)
OFERTA(DISCIPLINA,MONITORIA,<u>semestre</u>)

Discutindo as abordagens

Na primeira abordagem, sempre que uma instância de CURSA for vinculada a uma ocorrência de MONITORIA, tem-se a seguinte pergunta:

Essa relação entre (ESTUDANTE, DISCIPLINA, semestre) resultou em aprovação? Se sim, possibilite o relacionamento.

Na segunda abordagem, ainda faz-se uma pergunta, mas um pouco diferente:

Esse ESTUDANTE tem alguma relacionamento com DISCIPLINA cujo status seja APROVADO? Se sim, possibilite o relacionamento.

Por um lado, a primeira abordagem de resolução tende a garantir de forma mais óbvia a garantia da restrição de que um estudante deve ter sido aprovado na disciplina em que atuará como monitor. A própria representação do diagrama assume que MONITORIA se relaciona com uma combinação de ESTUDANTE e DISCIPLINA, tenha essa vinculação terminada com aprovação ou não (lembre-se que a validação do status == APROVADOserá feita posteriormente, pelo SGBD).

Seguindo essa linha de pensamento, a segunda abordagem parece inadequada, já que possibilita vincular um estudante que nunca tenha cursado aquela disciplina a uma monitoria a ela vinculada. Isso de fato é verdade, mas esse tratamento pode ser feito também pelo SGBD. Se parássemos por aqui, a primeira solução poderia ser mais interessante, mas vamos analisar a seguinte situação motivada pelo segundo enunciado:

Parte 2 - monitoria remunerada ou voluntária

 Considere também que um monitor pode atuar de forma voluntária ou remunerada. Como a situação do monitor pode ser representada? Como as bolsas pagas podem ser armazenadas?

Agora que já conhecemos os conceitos de especialização e generalização, podemos entender que: todo ESTUDANTE pode cursar disciplinas e atuar em MONITORIA, mas há alguns detalhes importantes:

• se a monitoria for remunerada, precisamos ter dados bancários desse ESTUDANTE;
• uma monitoria remunerada gera pagamentos, enquanto uma monitoria remunerada não;

Logo, podemos adotar a seguinte dinâmica:

• criar um subtipo ESTUDANTE_BOLSISTA, tendo ESTUDANTE como supertipo;
• especializar MONITORIA em MONITORIA_VOLUNTARIA e MONITORIA_REMUNERADA(ou apenas a segunda);
• relacionarmos ESTUDANTE com MONITORIA_VOLUNTARIA (ATUA_VOLUNTARIAMENTE) e ESTUDANTE_BOLSISTA com MONITORIA_REMUNERADA (ATUA_REMUNERADO);
• criarmos uma entidade PAGAMENTO, que possui relacionamento com MONITORIA_REMUNERADA (GERA);