Say I have the following ER diagram:

enter image description here

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?

  • 1
    The diagram says nothing about that. – Goyo Aug 25 '18 at 16:51

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:

  • One Teacher - One Student
  • One Teacher - Multiple Students
  • Multiple Teachers - One Student
  • Multiple Teachers - Multiple Students

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:

  • Each student can meet 0 or 1 teachers.
  • student3 can meet teacher7 twice or more?

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:

  • Every video can either have one customer (= rented) or no customer (= not rented)
  • Every customer can rent many videos.

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.

  • A meeting has one teacher (not zero)
  • A student can attend many meetings.
  • A meeting has one student (not zero)
  • A teacher can have many meetings.

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.

  • How is meeting only a teacher twice or more times contradictory? There was a time when that was exactly my case. – Goyo Aug 27 '18 at 15:49
  • @Goyo: I guess I should've added the picture of the schema as the third bullet point to tie it all together. The current schema directly ties the student to the teacher, it does not actually define the concept of them "meeting". I infer it was OP's intention to have the teach-student relationship represent the meeting (as per the question), at which point these two things do actually become contradictory. I do agree with your comment, which is exactly why the answer therefore suggests distinguishing a third entity (the meeting itself). – Flater Aug 27 '18 at 15:56
  • The diagram doesn't define student and teacher either. But I don't understand you. The former myself meeting only one teacher several times is consistent with the diagram and actually happened. There can't be a contradiction in something that actually happens. Unless you thing the universe is contradictory, but then who cares about anything. – Goyo Aug 27 '18 at 16:09
  • @Goyo: The diagram doesn't prevent teacher and student from meeting in real life. But the diagram, as it was posted in the question, is unable to reflect that more than one meeting has taken place. Based on the data which conforms to the diagram, you will be unable to distinguish between a teacher and student who met once, or who met multiple times. OP's question was very specifically if the current diagram can account for multiple meetings (between the same teacher/student), which it cannot. – Flater Aug 27 '18 at 16:12
  • @Goyo: 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). – Flater Aug 27 '18 at 16:15

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:

  • met-once, vs.
  • met-twice vs.
  • met-thrice vs.
  • met-many-times

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.