I'll give you an answer to give you an orientation. If that's not what you need, it's complicated, because we can not keep debating here until you get to where you want, it would not be a question or an answer.

You did not specify the problem well. Of course, when specifying the model is almost ready. But without specifying it is difficult to help. I'll have to speculate. Especially because you said you do not want something more complex. To make everything right, something more complex is needed. But if you accept that everything is not "right", what is the acceptable limit? Only you know.

In fact, this is quite right in quotation marks because it is hard to say that you have right or wrong modeling. Correct from the academic point of view is not always very practical. Often to optimize the database it is necessary to do the "wrong".

When you want simple solutions that just work, doing everything as the books do can be an exaggeration.

But only you know the inflection point.

I'll give you some tips on what I'd do by looking over and doing some speculation.

Considerations

The cursoID of aluno field can even be used, but if you want to do it right you should have a table that ties the student to the course. It may be overkill to create a table just for this but it makes more sense (that's what I said that you can not know the limit). A student does not have a course, a course is something transient, something external and independent of the student.

For this there is the 1: 1 relationship. Interestingly people think that if it is 1: 1 can always ignore the creation of a table and put it all together. But if you think it's an exaggeration and it's up to the same table, I can agree. You decide. And who can say that it's going to be a problem?

I imagine that the student can have zero or one course and not just one. So it's to think about. Of course null exists for cases like this. There is a lot of controversy whether or not to use nulls for this (delete a relationship).

Does a course only exist for that course? Part of the modeling says yes, part says no.

No matter how you're going to relate, you still have to bind the table disciplina to curso in some way.

If the discipline only exists for those courses is a 1: 1 ratio, then you can choose whether to make a table to do the tying of the discipline to the course or will use a field like you did. Which is most certain is difficult to say. Can a discipline be without a course?

If the course is linked to only one course, if the student changes course he is no longer attending that course.

But if the discipline can exist in several courses has two things to consider: must have a tie between courses and discipline; and then it does not matter (?!? depends) on which course the student is attending, he / she attends the course.

And then the field cursoId of disciplinaAlunoCurso would not be necessary.

You have raised this possibility of the student to change course and still continue to study the discipline, so the discipline can not simply belong to the course, but several courses can have a relationship with the disciplines.

Then you will use the available information of all subjects that he has completed and all necessary for the course to know if he has completed the course. But we're already going beyond modeling.

Since there has been so much talk in classes in the comments and it is correct to consider creating a class table and relating the student and the discipline to the class. This does not solve every possible situation in a school, but it already solves an important one. And then obviously the mooring will be student X discipline X class. Eventually of course as well. I am a living example that this is necessary because I changed my shift and had to do various disciplines of my course in classes of other courses (which I sometimes discovered that the discipline was not quite the same).

Conclusion

If you are going to analyze everything that can happen, thinking that a course change probably needs to be properly recorded by keeping track of what it did, that there may be different classes, and that it has a number of other elements and factors involved, very complex. If you leave all this aside you may ultimately have a single table that takes care of everything.

But I do not guarantee any of this, it may need to be different. It is easier to model real situations. Or at least well-specified hypothetical situations.