Difference Between One-To-Many and Many-To-One Relationship

Difference Between One-to-Many, Many-to-One and Many-to-Many?

One-to-Many: One Person Has Many Skills, a Skill is not reused between Person(s)

  • Unidirectional: A Person can directly reference Skills via its Set
  • Bidirectional: Each "child" Skill has a single pointer back up to the
    Person (which is not shown in your code)

Many-to-Many: One Person Has Many Skills, a Skill is reused between Person(s)

  • Unidirectional: A Person can directly reference Skills via its Set
  • Bidirectional: A Skill has a Set of Person(s) which relate to it.

In a One-To-Many relationship, one object is the "parent" and one is the "child". The parent controls the existence of the child. In a Many-To-Many, the existence of either type is dependent on something outside the both of them (in the larger application context).

Your subject matter (domain) should dictate whether or not the relationship is One-To-Many or Many-To-Many -- however, I find that making the relationship unidirectional or bidirectional is an engineering decision that trades off memory, processing, performance, etc.

What can be confusing is that a Many-To-Many Bidirectional relationship does not need to be symmetric! That is, a bunch of People could point to a skill, but the skill need not relate back to just those people. Typically it would, but such symmetry is not a requirement. Take love, for example -- it is bi-directional ("I-Love", "Loves-Me"), but often asymmetric ("I love her, but she doesn't love me")!

All of these are well supported by Hibernate and JPA. Just remember that Hibernate or any other ORM doesn't give a hoot about maintaining symmetry when managing bi-directional many-to-many relationships...thats all up to the application.

Difference between one-to-many and many-to-one relationship

Yes, it a vice versa. It depends on which side of the relationship the entity is present on.

For example, if one department can employ for several employees then, department to employee is a one to many relationship (1 department employs many employees), while employee to department relationship is many to one (many employees work in one department).

More info on the relationship types:

Database Relationships - IBM DB2 documentation

Difference between one-to-one and one-to-many relationship in database

In a sense, all the relationships we talk about are not known to the database, they are constructs we have invented to better understand how to design the tables.

The big difference in terms of table structure between one-to-one and one-to-many is that in one-to-one it is possible (but not necessary) to have a bidirectional relationship, meaning table A can have a foreign key into table B, and table B can have a foreign key into the associated record in table A. This is not possible with a one-to-many relationship.

One-to-one relationships associate one record in one table with a single record in the other table. One-to-many relationships associate one record in one table with many records in the other table.

one to many vs many to many relationship

The food sample does work well for a one-to-many relationship: One customer can order many dishes.

The many-to-many relationship is better described by a book sample:

An author can write many books (that would be a one-to-many relationship). But he can have co-authors also involved - one book can have many authors.

Is it alway necessary to have both @oneToMany and @manyToOne for a relationship in hibernate?

Bidirectional one-to-many and both many-to-one association mappings are fine. But you should avoid unidirectional one-to-many associations in your domain model. Otherwise, Hibernate might create unexpected tables and execute more SQL statements than you expected.

Difference between using @OneToMany and @ManyToMany

Well, the difference is in the design you're trying to reflect using objects.

In your case, every Question can be assigned to multiple Categories - so that's a sign of @*ToMany relationship. Now you have to decide if:

  • each Category can have only one Question assigned to it (it will result in a unique constraint which means that no other Category can refer the same Question) - this will be @OneToMany relationship,
  • each Category can have multiple Questions assigned to it (there will be no unique constraint in the Category table) - this will be @ManyToMany relationship.

@OneToMany (Question -> Category)

This relationship can be represented by join table only if you explicitly define so using @JoinTable or when it is a unidirectional relationship in which the owning side is the 'One' side (it means that in the Question entity you have a collection of Categories, but in the Categories you don't have any reference to the Question).

If you think about it, it seems quite reasonable that the join table is used. There is no other way the DBMS could save a connection between one row in Question table with multiple rows in Categories table.

However, if you would like to model a bidirectional relationship you need to specify that the Category ('Many' side) is the owning side of the relationship. In this case the DBMS can create a join column with foreign key in the Category table because each Category row can be connected with only one Question.

In this way you don't have any join table but simple foreign keys (still, as pointed at the beginning, you can force to create the join table using @JoinTable).

@ManyToMany

This relationship must be represented as a join table. It basically works very similar to the unidirectional @OneToMany relationship, but in this case you may have multiple rows from Question joined with multiple rows from Categories.

why One-To-Many association cannot be Bidirectional and it should just be Unidirectional?

First of all, any relationship can be unidirectional or bidirectional, it's all depend on how you want to display or retrieve your data, and your business rules.

When we can have these two statements, then it is Bidirectional. Then
why she said it can be just Unidirectional?

There is also a big mismatch between the object oriented approach of ORMs like Hibernate and how tables and relationships are defined in a relational database. She can be wright, because, in the point of view of a database, relationships are by default unidirectional.

The difference between unidirectional and bidirectional is defined by the fact that you can access the records of the other side of your relationship from where you are.

What is Bidirectional's exact definition with which she came to such a
conclusion?

In your example we can interpret your relationship like this:

  • Unidirectional: you can get all your addresses from person, but not the inverse

     class Person {

    @OneToMany
    List<Address> addresses;

    }

    class Address {

    // Here you don't add the ManyToOne
    Person p;
    }
  • Bidirectional: you can get all your addresses from person and get a person from an address

     class Person {

    @OneToMany
    List<Address> addresses;
    }

    class Address {

    @ManyToOne
    Person p;
    }

Take a look at those links below:

Difference between unidirectional and bidirectional relational relationship

https://www.baeldung.com/spring-data-rest-relationships

What is Object/Relational mismatch



Related Topics



Leave a reply



Submit