Say I have the following ER diagram:
What I know is that the "one" side of the relationship means the following:
Each student can meet 0 or 1 teacher.
So for example student3 can meet teacher7, but it can't also meet teacher4.
But does the "one" side of the relationship also mean that student3 can meet teacher7 twice or more?
I think part of your confusion comes from your ER diagram not accurately describing the scenario.
In between your Teacher and Student tables should be a "Meeting" table. This meeting table could cover one or more business scenarios:
Depending on which of these scenarios suits your requirements, defines the one to many or many to many relationship between Teacher and Meeting and/or Student and Meeting.
Additionally, the scenarios with multiple teachers or students it might be desirable to have two more tables listing the teachers or students that are represented in the meeting.
But does the "one" side of the relationship also mean that student3 can meet teacher7 twice or more?
This is simply not reflected in your current setup. If you re-read your question, you'll see that you're contradicting yourself:
The bolded parts contradict each other. Inherently, the answer to your question is no.
The issue here is that you're asking about how a same student can meet the same teacher more than once. This suggests that you're looking to track a history of meetings, as opposed to a current state.
For example, think of a BlockBuster application:
Therefore, you set up your schema as zero/one customer to many videos.
This seems correct, until you realize that you want to know which customers have rented this particular video in the past. Therefore, you need to track the history of rentals.
Logically speaking, only one customer can currently rent the same video. However, many customers can historically have rented this same video.
The need for tracking historical changes requires you to extend your data model. In the BlockBuster example, what you need is a Rental entity which resides inbetween the customer and the video.
In your case, it's very similar. You will need to define a Meeting entity which defines a single meeting between a teacher and student.
Note: This schema does not actually prevent you from having a single student who attends meetings held by different teachers. However, that is something you enforce through business logic rather than data structure logic.
The diagram doesn't define student and teacher either. The diagram shows that Student and Teacher are entities. It doesn't define their specific properties but that's not the point. It's merely to contrast this with the Meeting entity, which is not on the diagram (whereas Student/Teacher are on the diagram). Your model doesn't quantify meetings: just the general fact of which teacher met which student, so multiple meetings are not necessarily precluded.
You can change the model is a number of ways: add more verbs to distinguish:
but you can see this is not a great way to count things.
If you want a count of the meetings, you either need a counter value, or to name the specific meetings so that they can be individually counted.
Either way, you need to make manifest some notion of meetings, not just a has-met relationship.
For the former (just counting), it is a relationship between teacher & student realized with a count value. This is called an association class in UML: it is an association (capturing the relationship) but is represented by a class so it can have attributes, like a count of how many times met. Also sometimes called reification, e.g. in RDF, where we make a noun (concept) for a verb (relationship) so we can attach properties to the noun that represents the relationship. Either way, it makes the relationship something that itself can have attributes, in this case a count value.
For the latter, you would document each meeting, giving each individual meeting an identity of sorts: could be an id, or a start time, something unique.
FWIW, I'm wary of models that prematurely preclude general cardinalities (i.e. require limited cardinalities). Sometimes (not always) one-to-many relationships are premature optimizations on many-to-many relationships. In this case, for example, you'd like to be sure there are business rules that preclude a student from meeting with other teachers, and, that these rules aren't going to be just mollified when there's trouble. You could use many-to-many here (even if never used to capture relationships beyond one-to-many) and perhaps not ever have a (performance) problem.
