Différence entre un pour plusieurs, plusieurs pour un et plusieurs pour plusieurs?

on dirait que tout le monde répond One-to-many vs Many-to-many :

la différence entre One-to-many , Many-to-one et Many-to-Many est:

One-to-many vs Many-to-one est une question de perspective . Unidirectional vs Bidirectional n'affectera pas la cartographie, mais fera une différence sur la façon dont vous pouvez accéder à vos données.

• Dans One-to-many le many side conservera la référence du côté one . Un bon exemple est "Une personne possède de nombreuses compétences". Dans ce cas Person est un côté et Skill est le côté beaucoup. Il y aura une colonne person_id dans le tableau skills .

Dans unidirectionnel Person classe List<Skill> skills mais Skill n'aura pas Person person . Dans bidirectionnel les deux les propriétés sont ajoutées et il vous permet d'accéder à un Person un compétence( c'est à dire skill.person ).

• Dans Many-to-one du côté "plusieurs" sera notre point de référence. Par exemple, "Un Utilisateur a une Adresse". Dans notre système, beaucoup d'utilisateurs peuvent partager une adresse( un certain nombre de personnes peuvent partager le même numéro de bloc, par exemple). Dans ce cas, la colonne address_id de la table users est partagée par plusieurs users lignes. Dans ce cas, nous disons que users et addresses ont Many-to-one relation.

Dans unidirectionnel un User aura Address address . bidirectionnel aura un List<User> users supplémentaire dans la classe Address .

• In Many-to-Many les membres de chaque parti peuvent faire référence à nombre arbitraire de membres de l'autre partie. Pour ce faire, on utilise une table de recherche 1519690920". La relation entre les médecins et les patients en est un exemple. Un médecin peut avoir beaucoup de patients et vice versa.

1) les cercles sont Entities/POJOs/Beans

2) deg est une abréviation pour le degré que dans les graphiques (nombre d'arêtes)

PK=clé primaire, FK =clé étrangère

notez la contradiction entre le degré et le nom du côté. Plusieurs correspondent à un degré=1 tandis qu'un correspond à un degré >1.

regardez cet article: Mapping Object Relationships

il y a deux catégories de relations objet dont vous devez tenir compte lors de la cartographie. La première catégorie est basée sur la multiplicité et elle comprend trois types:

*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. 

La deuxième catégorie est basée sur directionalité et contient deux types, relations unidirectionnelles et relations bidirectionnelles.

*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. 

cela nécessiterait probablement une relation de plusieurs à plusieurs comme suit

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
}

vous pouvez avoir besoin de définir une joinTable + JoinColumn mais il sera possible de travailler aussi sans...

tout d'Abord, lire tous les petits caractères. Notez que la cartographie relationnelle de NHibernate (donc, je suppose, Hibernate aussi) a une correspondance amusante avec la cartographie de DB et de graphe objet. Par exemple, les relations individuelles sont souvent mises en œuvre sous la forme d'une relation individuelle.

Deuxièmement, avant que nous puissions vous dire comment vous devez écrire votre carte O/R, Nous devons voir votre DB aussi. En particulier, une seule Compétence être possède par plusieurs personnes? Si donc, vous avez une relation de plusieurs à plusieurs; autrement, c'est une relation de plusieurs à un.

Troisièmement, je préfère ne pas mettre en œuvre les relations de plusieurs à plusieurs directement, mais plutôt modéliser la "table de jointure" dans votre modèle de domaine--i.e., le traiter comme une entité, comme ceci:

class PersonSkill 
{
    Person person;
    Skill skill;    
}

alors voyez-vous ce que vous avez? Tu as deux relations un-pour-plusieurs. (Dans ce cas, la personne peut avoir un ensemble de compétences personnelles, mais n'aurait pas un ensemble de compétences.) Toutefois, certains préféreront pour utiliser la relation de plusieurs à plusieurs (entre la personne et la compétence); ceci est controversé.

Quatrièmement, si vous avez des relations bidirectionnelles (par exemple, non seulement la personne a un ensemble de compétences, mais aussi, la compétence a un ensemble de personnes), NHibernate ne pas appliquer la bidirectionnalité dans votre BL pour vous; il ne comprend la bidirectionnalité des relations à des fins de persistance.

Cinquièmement, beaucoup-à-un est beaucoup plus facile à utiliser correctement à NHibernate (et je suppose Hibernate) qu'à one-to-many (cartographie de collection).

bonne chance!