Подтвердить что ты не робот

Разница между "один-ко-многим", "многие-к-одному" и "многие-ко-многим"?

Хорошо, так что это, вероятно, тривиальный вопрос, но у меня возникают проблемы с визуализацией и пониманием различий и когда использовать их. Я также немного не понимаю, как такие понятия, как однонаправленные и двунаправленные отображения, влияют на отношения "один-ко-многим" и "многие-ко-многим". Я использую Hibernate прямо сейчас, поэтому любое объяснение, связанное с ORM, будет полезно.

В качестве примера предположим, что у меня есть следующая настройка:

public class Person{
    private Long personId;
    private Set<Skill> skills;
    //Getters and setters
}

public class Skill{
    private Long skillId;
    private String skillName;
    //Getters and setters
}

Итак, в этом случае, какое отображение я бы имел? Ответы на этот конкретный пример, безусловно, оценены, но мне также очень хотелось бы ознакомиться с тем, когда использовать "один-ко-многим" и "многие ко многим" и когда использовать таблицу соединений в сравнении с столбцом объединения и однонаправленным или двунаправленным.

4b9b3361

Ответ 1

Один-ко-многим: у одного человека есть много навыков, навык не используется повторно между Person (s)

  • Однонаправленный: человек может напрямую ссылаться на Навыки через свой Set
  • Двунаправленный: каждый "дочерний" навык имеет один указатель, возвращающийся к Лицо (которое не показано в вашем коде)

Много-ко-многим: у одного человека есть много навыков, навык используется повторно между Person (s)

  • Однонаправленный: человек может напрямую ссылаться на Навыки через свой Set
  • Двунаправленный: У умения есть Набор Лица (лиц), которые относятся к нему.

В отношении "Один-ко-многим" один объект является "родительским", а один - "дочерним". Родитель контролирует существование ребенка. В "Много-ко-многим" существование любого типа зависит от чего-то вне их обоих (в более широком контексте приложения).

Ваша тема (домен) должна диктовать, является ли отношение "один-ко-многим" или "многие-ко-многим", однако я считаю, что создание отношения однонаправленного или двунаправленного - это инженерное решение, которое торгует памятью, обработки, производительности и т.д.

Что может сбить с толку, так это то, что двунаправленное отношение "многие ко многим" не обязательно должно быть симметричным! То есть, группа людей может указать на умение, но умение не обязательно относится к этим людям. Как правило, это было бы, но такая симметрия не является требованием. Возьмите любовь, например, - это двунаправленная ( "I-Love", "Loves-Me" ), но часто асимметричная ( "Я люблю ее, но она меня не любит" )!

Все они хорошо поддерживаются Hibernate и JPA. Просто помните, что Hibernate или любой другой ORM не дают критического замечания о сохранении симметрии при управлении двунаправленными отношениями "многие ко многим"... все это зависит от приложения.

Ответ 2

Похоже, что все отвечают One-to-many vs Many-to-many:

Разница между One-to-many, Many-to-one и Many-to-many такова:

One-to-many vs Many-to-one - вопрос перспективы. Unidirectional vs Bidirectional не повлияет на отображение, но будет определять, как вы можете получить доступ к своим данным.

  • В One-to-many сторона many будет ссылаться на сторону one. Хорошим примером является "У человека много навыков". В этом случае Person есть одна сторона, а Skill - большая сторона. В таблице skills будет столбец person_id.

В однонаправленном классе Person будет List<Skill> skills, но Skill не будет Person person. В двунаправленном добавлены свойства, и он позволяет вам получить доступ к Person с учетом умение (т.е. skill.person).

  • В Many-to-one большая часть будет нашей точкой отсчета. Например, "Пользователь имеет адрес". В нашей системе многие пользователи могут обмениваться адресами (например, число людей может иметь один и тот же номер блока). В этом случае столбец address_id в таблице users будет использоваться несколькими строками users. В этом случае мы говорим, что users и addresses имеют отношение Many-to-one.

В однонаправленном a User будет Address address. Двунаправленный будет иметь дополнительный List<User> users в классе Address.

  • В Many-to-many члены каждой стороны могут ссылаться на произвольное число членов другой стороны. Для этого используется таблица поиска. Пример для этого - отношения между врачами и пациентами. Врач может иметь много пациентов и наоборот.

Ответ 3

1) Круги - это объекты /POJOs/ Beans

2) deg - аббревиатура степени, как в графах (число ребер)

PK = первичный ключ, FK = внешний ключ

Обратите внимание на противоречие между степенью и именем стороны. Многим соответствует степень = 1, а одна соответствует степени > 1.

Illustration of one-to-many many-to-one

Ответ 4

Взгляните на эту статью: Сопоставление отношений объектов

Существует две категории отношений объектов, с которыми вам нужно иметь дело при сопоставлении. Первая категория основана на множественности и включает три типа:

*One-to-one relationships.  This is a relationship where the maximums of each of its multiplicities is one, an example of which is holds relationship between Employee and Position in Figure 11.  An employee holds one and only one position and a position may be held by one employee (some positions go unfilled).
*One-to-many relationships. Also known as a many-to-one relationship, this occurs when the maximum of one multiplicity is one and the other is greater than one.  An example is the works in relationship between Employee and Division.  An employee works in one division and any given division has one or more employees working in it.
*Many-to-many relationships. This is a relationship where the maximum of both multiplicities is greater than one, an example of which is the assigned relationship between Employee and Task.  An employee is assigned one or more tasks and each task is assigned to zero or more employees. 

Вторая категория основана на направленности и содержит два типы, однонаправленные отношения и двунаправленные отношения.

*Uni-directional relationships.  A uni-directional relationship when an object knows about the object(s) it is related to but the other object(s) do not know of the original object.  An example of which is the holds relationship between Employee and Position in Figure 11, indicated by the line with an open arrowhead on it.  Employee objects know about the position that they hold, but Position objects do not know which employee holds it (there was no requirement to do so).  As you will soon see, uni-directional relationships are easier to implement than bi-directional relationships.
*Bi-directional relationships.  A bi-directional relationship exists when the objects on both end of the relationship know of each other, an example of which is the works in relationship between Employee and Division.  Employee objects know what division they work in and Division objects know what employees work in them. 

Ответ 5

это, вероятно, вызовет отношение отношения "многие ко многим" следующим образом



public class Person{

    private Long personId;
    @manytomany

    private Set skills;
    //Getters and setters
}

public class Skill{
    private Long skillId;
    private String skillName;
    @manyToMany(MappedBy="skills,targetClass="Person")
    private Set persons; // (people would not be a good convenion)
    //Getters and setters
}

вам может понадобиться определить joinTable + JoinColumn, но он будет работать и без...

Ответ 6

Прежде всего, прочитайте весь мелкий шрифт. Обратите внимание, что NHibernate (таким образом, я предполагаю, Hibernate также) реляционное отображение имеет смешную корреляцию с отображением DB и объектов. Например, отношения "один-к-одному" часто реализуются как отношения "много-к-одному".

Во-вторых, прежде чем мы сможем рассказать вам, как вы должны писать свою карту O/R, мы также должны увидеть вашу БД. В частности, может ли один навык обладать несколькими людьми? Если это так, у вас есть отношение "многие ко многим" ; в противном случае это много-к-одному.

В-третьих, я предпочитаю не реализовывать отношения "многие ко многим" напрямую, а вместо этого моделировать "таблицу соединений" в вашей модели домена - т.е. рассматривать ее как сущность, например:

class PersonSkill 
{
    Person person;
    Skill skill;    
}

Тогда вы видите, что у вас есть? У вас есть два отношения "один ко многим". (В этом случае у Человека может быть коллекция PersonSkills, но у него не будет набора Навыков.) Однако некоторые предпочитают использовать отношения "многие ко многим" (между Person и Skill); это противоречиво.

В-четвертых, если у вас есть двунаправленные отношения (например, у человека не только коллекция Навыков, но также и у Навыка есть коллекция людей), NHibernate не обеспечивает двунаправленность в вашем BL для вас; он понимает только двунаправленность отношений для целей сохранения.

В-пятых, много-к-одному гораздо проще использовать правильно в NHibernate (и я предполагаю, что Hibernate), чем один-ко-многим (сопоставление коллекции).

Удачи!

Ответ 7

Я бы объяснил так:

Отношения OneToOne - OneToOne relationship

@OneToOne
Person person;

@OneToOne
Nose nose;

отношения OneToMany - ManyToOne relationship

@OneToMany
List<Shepherd> shepherd;

@ManyToOne
Sheep sheep;

отношения ManyToMany - ManyToMany relationship

@ManyToMany
List<Traveler> traveler;

@ManyToMany
List<Destination> destination;