एक-से-कई, कई-से-एक और कई-से-कई के बीच अंतर?

Question

ठीक है, तो यह संभवतः एक तुच्छ प्रश्न है लेकिन मुझे मतभेदों को समझने और समझने और प्रत्येक का उपयोग करने में परेशानी हो रही है। मैं थोड़ा अस्पष्ट भी हूं कि कैसे यूनि-दिशात्मक और द्वि-दिशात्मक मैपिंग जैसी अवधारणाएं एक-से-कई / कई-कई संबंधों को प्रभावित करती हैं। मैं अभी हाइबरनेट का उपयोग कर रहा हूं, इसलिए 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
}

तो इस मामले में मेरे पास किस तरह की मैपिंग होगी? इस विशिष्ट उदाहरण के उत्तर निश्चित रूप से सराहे गए हैं, लेकिन मैं यह भी वास्तव में पसंद करूंगा कि कब-कब एक-से-कई और कई-से-कई का उपयोग करना है और कब शामिल होने वाली तालिका बनाम एक जॉइन कॉलम और यूनिडायरेक्शनल बनाम बिडायरेक्शनल का उपयोग करना है।

Comments

लगता है कि हर कोई केवल एक से कई बनाम कई-से-कई का जवाब दे रहा है। एक-से-एक बनाम कई-से-एक के लिए मेरे जवाब को देखें।

— अलेक्जेंडर सुरफेल

Answer 1

एक से कई : एक व्यक्ति के पास कई कौशल होते हैं, एक कौशल व्यक्ति के बीच पुन: उपयोग नहीं किया जाता है

• यूनिडायरेक्शनल : एक व्यक्ति सीधे अपने सेट के माध्यम से कौशल को संदर्भित कर सकता है
• द्विदिश : प्रत्येक "बच्चे" कौशल में व्यक्ति को एक एकल सूचक होता है (जो आपके कोड में नहीं दिखाया गया है)

कई-कई : एक व्यक्ति के पास कई कौशल हैं, व्यक्ति के बीच एक कौशल का पुन: उपयोग किया जाता है

• यूनिडायरेक्शनल : एक व्यक्ति सीधे अपने सेट के माध्यम से कौशल को संदर्भित कर सकता है
• द्विदिश : एक कौशल में व्यक्ति का एक सेट होता है जो उससे संबंधित होता है।

एक-से-कई संबंधों में, एक वस्तु "माता-पिता" है और एक "बच्चा" है। माता-पिता बच्चे के अस्तित्व को नियंत्रित करते हैं। कई-कई में, दोनों प्रकार के बाहर (बड़े अनुप्रयोग संदर्भ में) किसी भी प्रकार का अस्तित्व निर्भर है।

आपका विषय (डोमेन) तय करना चाहिए कि संबंध एक-से-कई या कई-से-कई हैं - हालांकि, मुझे लगता है कि संबंध को यूनिडायरेक्शनल या बिडायरेक्शनल बनाना एक इंजीनियरिंग निर्णय है जो स्मृति, प्रसंस्करण, प्रदर्शन को बंद करता है , आदि।

क्या भ्रामक हो सकता है कि एक कई-से-कई द्विदिश संबंध सममित होने की आवश्यकता नहीं है! यही है, लोगों का एक समूह एक कौशल को इंगित कर सकता है, लेकिन कौशल को केवल उन लोगों से संबंधित नहीं होना चाहिए। आमतौर पर यह होता है, लेकिन ऐसी समरूपता कोई आवश्यकता नहीं है। उदाहरण के लिए, प्यार लो - यह द्वि-दिशात्मक है ("आई-लव", "लव्स-मी"), लेकिन अक्सर असममित ("मैं उससे प्यार करता हूं, लेकिन वह मुझे प्यार नहीं करता है")!

ये सभी हाइबरनेट और जेपीए द्वारा समर्थित हैं। बस याद रखें कि हाइबरनेट या कोई अन्य ओआरएम द्वि-दिशात्मक कई-से-कई संबंधों का प्रबंधन करते समय समरूपता बनाए रखने के बारे में कोई संकेत नहीं देता है ... सभी एप्लिकेशन पर लागू होते हैं।

Comments

स्पष्ट करने के लिए, कोई भी संबंध आपके बीएल में या आपके ओ / आर मैपिंग में (एक-दूसरे के स्वतंत्र रूप से, यहां तक ​​कि!) कोई भी हो सकता है।

— ज्योन्गदेव

"LOVE" उदाहरण ने इसे स्पष्ट किया। ManyToMany मेरे प्रकार का मानचित्रण है।

— अब्दुल्ला खान

उत्तम। यह इसे अच्छी तरह से समझाता है (और ओपी के उदाहरण के संदर्भ में)

— अनुपम

सवाल का ठीक से जवाब नहीं देता। आप बहुत से एक हिस्से को याद करते हैं। यद्यपि एक से कई और कई से एक धारणा का विषय है, इस उत्तर का उल्लेख नहीं है।

— मंज़ूर अलही

Answer 2

ऐसा लगता है कि हर कोई One-to-manyबनाम जवाब दे रहा है Many-to-many:

और One-to-many, के बीच का अंतर :Many-to-oneMany-to-Many

One-to-manyबनाम Many-to-oneपरिप्रेक्ष्य का विषय है । Unidirectionalबनाम Bidirectionalमानचित्रण को प्रभावित नहीं करेगा लेकिन इस बात पर फर्क पड़ेगा कि आप अपने डेटा तक कैसे पहुँच सकते हैं।

• में पक्ष के संदर्भ रखेंगे पक्ष। एक अच्छा उदाहरण "ए स्टेट्स द सिटीज" है। इस मामले में एक पक्ष है और कई पक्ष हैं। तालिका में एक कॉलम होगा ।Many-to-onemanyoneStateCitystate_idcities

में दिशाहीन , Personवर्ग होगा List<Skill> skillsलेकिन Skillनहीं होगा Person person। में द्विदिश , दोनों गुण जोड़ रहे हैं और यह आप के लिए एक का उपयोग करने की अनुमति देता है Personएक कौशल (यानी दिया skill.person)।

• में One-to-Manyएक तरफ संदर्भ के बारे में हमारी बात हो जाएगा। उदाहरण के लिए, "एक उपयोगकर्ता के पास एक पता है"। इस मामले में हम तीन कॉलम हो सकता है address_1_id, address_2_idऔर address_3_idया एक मेज के ऊपर देखो पर अद्वितीय बाधा के साथ user_idऔर address_id।

में दिशाहीन , एक Userहोगा Address address। कक्षा में द्विदिश एक अतिरिक्त होगा ।List<User> usersAddress

• में Many-to-Manyप्रत्येक पार्टी के सदस्यों के अन्य पार्टी के सदस्यों की मनमाना संख्या के संदर्भ में रख सकते हैं। इसे प्राप्त करने के लिए एक लुक अप टेबल का उपयोग किया जाता है। इसके लिए उदाहरण डॉक्टरों और रोगियों के बीच का संबंध है। एक डॉक्टर के पास कई रोगी हो सकते हैं और इसके विपरीत।

Comments

यह स्वीकृत उत्तर होना चाहिए, अन्य उत्तरों में से अधिकांश प्रश्न याद आते हैं।

— arg20

पहला उदाहरण गलत है। यदि आपके पास A व्यक्ति है और व्यक्ति के पास SkO के साथ @OneToMany है, तो उस टेबल preson_skills में skill_id पर एक अद्वितीय अवरोध होगा। तो एक कौशल केवल एक व्यक्ति के लिए मैप किया जाएगा। और आप निकाल नहीं सकते s.persons, क्योंकि वहां केवलs.person

— Иван Николайчук

वास्तव में One-to-manyजैसा आप वर्णन करते हैं, वैसा ही Many-to-manyसंबंध है क्योंकि personकई का संदर्भ है, skillsलेकिन skillविशेष व्यक्ति का संदर्भ नहीं रखता है और कई का personsसंदर्भ एक ही हो सकता है skill। और आपका Many-to-oneसंबंध वास्तव में है One-to-manyक्योंकि प्रत्येक कौशल में केवल एक का संदर्भ है personक्योंकि एक बच्चे की केवल एक माँ है।

— मिश्रण

@ आपकी टिप्पणी ने मुझे समाप्त कर दिया और मुझे मेरे अधिकांश उत्तर को फिर से लिखना शुरू कर दिया। कृपया इसे फिर से देखें! धन्यवाद

— अलेक्जेंडर Suraphel

आप "एक" पक्ष के महत्व के आधार पर एक-से-कई और कई-से-एक के बीच अंतर करते हैं। दोनों उदाहरणों में "उपयोगकर्ता" सबसे महत्वपूर्ण इकाई है। इसलिए, जब 'द वन' पर है (उपयोगकर्ताओं और कौशल, skillsहै person_idतो आप कई एक-से-इसे कहते लेकिन जब यह एक "कई" पक्ष (उपयोगकर्ताओं और पते, है) usersहै address_id) तो आप इसे कहते कई-टू-वन। लेकिन संरचनात्मक रूप से दोनों मामले समान हैं और इन्हें वन-टू-कई कहा जाता है।

— मिक्स

Answer 3

1) मंडलियां इकाई / पीओजेओ / बीन्स हैं

2) डिग्री ग्राफ के रूप में डिग्री के लिए एक संक्षिप्त नाम है (किनारों की संख्या)

पीके = प्राथमिक कुंजी, एफके = विदेशी कुंजी

डिग्री और पक्ष के नाम के बीच विरोधाभास पर ध्यान दें। कई डिग्री = 1 से मेल खाते हैं जबकि एक डिग्री> 1 से मेल खाता है।

Comments

वास्तव में प्यार है कि यह दोनों दिशाओं में टेबल पर ऑब्जेक्ट ग्राफ को कैसे जोड़ता है।

— दिमित्री मिन्कोवस्की

Nerds देखें, यह है कि है PROGRAMMER की हस्तरेखा कैसी दिखती है: D

— मेहराज मलिक

मैंने देखा कि तुमने यहाँ क्या किया।

— निक गैलीमोर

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

Comments

this occurs when the maximum of one multiplicity is one and the other is greater than onelol WUT?

— सर्ग

Answer 5

यह एक बहुत ही सामान्य प्रश्न है, इसलिए यह उत्तर इस लेख पर आधारित है जो मैंने अपने ब्लॉग पर लिखा था।

अनेको के लिये एक

एक से कई तालिका संबंध निम्नानुसार दिखते हैं:

रिलेशनल डेटाबेस सिस्टम में, एक-से-कई टेबल रिलेशनशिप Foreign Keyबच्चे में एक कॉलम के आधार पर दो टेबल्स को जोड़ता है जो Primary Keyपेरेंट टेबल रो के संदर्भ को संदर्भित करता है।

ऊपर तालिका आरेख post_idमें, post_commentतालिका में स्तंभ तालिका id स्तंभ के Foreign Keyसाथ एक संबंध है :postPrimary Key

ALTER TABLE
    post_comment
ADD CONSTRAINT
    fk_post_comment_post_id
FOREIGN KEY (post_id) REFERENCES post

@ManyToOne एनोटेशन

वन-टू-टेबल टेबल रिलेशनशिप को मैप करने का सबसे अच्छा तरीका @ManyToOneएनोटेशन का उपयोग करना है ।

हमारे मामले में, बाल इकाई, एनोटेशन का उपयोग करते हुए फॉरेन की कॉलम को PostCommentमैप करती है :post_id@ManyToOne

@Entity(name = "PostComment")
@Table(name = "post_comment")
public class PostComment {

    @Id
    @GeneratedValue
    private Long id;

    private String review;

    @ManyToOne(fetch = FetchType.LAZY)
    private Post post;

}

JPA @OneToManyएनोटेशन का उपयोग करना

सिर्फ इसलिए कि आपके पास @OneToManyएनोटेशन का उपयोग करने का विकल्प है , इसका मतलब यह नहीं है कि यह हर एक-से-कई डेटाबेस संबंध के लिए डिफ़ॉल्ट विकल्प होना चाहिए । संग्रह के साथ समस्या यह है कि हम उनका उपयोग केवल तब कर सकते हैं जब बाल रिकॉर्ड की संख्या सीमित है।

@OneToManyएसोसिएशन को मैप करने का सबसे अच्छा तरीका यह है कि @ManyToOneसभी इकाई राज्य परिवर्तनों के प्रचार के लिए पक्ष पर निर्भर रहें:

@Entity(name = "Post")
@Table(name = "post")
public class Post {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @OneToMany(
        mappedBy = "post", 
        cascade = CascadeType.ALL, 
        orphanRemoval = true
    )
    private List<PostComment> comments = new ArrayList<>();

    //Constructors, getters and setters removed for brevity

    public void addComment(PostComment comment) {
        comments.add(comment);
        comment.setPost(this);
    }

    public void removeComment(PostComment comment) {
        comments.remove(comment);
        comment.setPost(null);
    }
}

मूल इकाई, Postमें दो उपयोगिता विधियाँ (जैसे addCommentऔर removeComment) हैं, जिनका उपयोग द्विदिश संघ के दोनों पक्षों को सिंक्रनाइज़ करने के लिए किया जाता है। जब भी आप एक द्विदिश संघ के साथ काम कर रहे हों, तो आपको हमेशा ये तरीके प्रदान करने चाहिए, अन्यथा, आप बहुत ही सूक्ष्म राज्य प्रसार मुद्दों का जोखिम उठाते हैं ।

यूनिडायरेक्शनल @OneToManyएसोसिएशन को टाला जा सकता है क्योंकि यह @ManyToOneद्विदिश @OneToManyएसोसिएशन का उपयोग करने से कम कुशल है ।

@OneToManyजेपीए और हाइबरनेट के साथ संबंध का सबसे अच्छा तरीका के बारे में अधिक जानकारी के लिए , इस लेख को देखें ।

एक से एक

एक-से-एक तालिका संबंध निम्नानुसार दिखता है:

रिलेशनल डेटाबेस सिस्टम में, एक-से-एक टेबल रिलेशनशिप Primary Keyबच्चे में एक कॉलम के आधार पर दो टेबल्स को जोड़ता है जो पेरेंट टेबल रो का एक Foreign Keyसंदर्भ भी है Primary Key।

इसलिए, हम कह सकते हैं कि चाइल्ड टेबल Primary Keyपैरेंट टेबल के साथ साझा करता है ।

उपरोक्त तालिका चित्र में, idमें स्तंभ post_detailsतालिका भी एक है Foreign Keyके साथ संबंध postतालिका id Primary Keyस्तंभ:

ALTER TABLE
    post_details
ADD CONSTRAINT
    fk_post_details_id
FOREIGN KEY (id) REFERENCES post

एनपीए का उपयोग एनोटेशन के @OneToOneसाथ@MapsId

@OneToOneरिश्ते को मैप करने का सबसे अच्छा तरीका उपयोग करना है @MapsId। इस तरह, आपको एक द्विदिश संघ की भी आवश्यकता नहीं है क्योंकि आप हमेशा इकाई पहचानकर्ता PostDetailsका उपयोग करके इकाई ला सकते हैं Post।

मानचित्रण इस तरह दिखता है:

[कोड भाषा = "java"] @Entity (नाम = "PostDetails") @Table (नाम = "post_details") सार्वजनिक वर्ग PostDetails {

@Id
private Long id;

@Column(name = "created_on")
private Date createdOn;

@Column(name = "created_by")
private String createdBy;

@OneToOne(fetch = FetchType.LAZY)
@MapsId
@JoinColumn(name = "id")
private Post post;

public PostDetails() {}

public PostDetails(String createdBy) {
    createdOn = new Date();
    this.createdBy = createdBy;
}

//Getters and setters omitted for brevity

} [/ कोड]

इस तरह, idसंपत्ति प्राथमिक कुंजी और विदेशी कुंजी दोनों के रूप में कार्य करती है। आप देखेंगे कि पहचानकर्ता के पहचान के साथ आबादी के बाद से @Idकॉलम अब @GeneratedValueएनोटेशन का उपयोग नहीं करता है post।

@OneToOneजेपीए और हाइबरनेट के साथ संबंध का सबसे अच्छा तरीका के बारे में अधिक जानकारी के लिए , इस लेख को देखें ।

कई कई

कई-से-कई तालिका संबंध निम्नानुसार है:

रिलेशनल डेटाबेस सिस्टम में, कई-टू-टेबल टेबल रिलेशनशिप में दो पैरेंट टेबल को चाइल्ड टेबल के माध्यम से लिंक किया जाता है जिसमें दो पेरेंट टेबल Foreign Keyके Primary Keyकॉलम को संदर्भित करने वाले दो कॉलम होते हैं ।

ऊपर तालिका आरेख post_idमें, post_tagतालिका में स्तंभ Foreign Keyका postतालिका आईडी Primary Keyस्तंभ के साथ भी संबंध है :

ALTER TABLE
    post_tag
ADD CONSTRAINT
    fk_post_tag_post_id
FOREIGN KEY (post_id) REFERENCES post

और, tag_idमें स्तंभ post_tagतालिका एक है Foreign Keyके साथ संबंध tagतालिका आईडी Primary Keyस्तंभ:

ALTER TABLE
    post_tag
ADD CONSTRAINT
    fk_post_tag_tag_id
FOREIGN KEY (tag_id) REFERENCES tag

जेपीए @ManyToManyमानचित्रण का उपयोग करना

यह आप many-to-manyजेपीए और हाइबरनेट के साथ तालिका संबंध कैसे बना सकते हैं :

@Entity(name = "Post")
@Table(name = "post")
public class Post {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @ManyToMany(cascade = { 
        CascadeType.PERSIST, 
        CascadeType.MERGE
    })
    @JoinTable(name = "post_tag",
        joinColumns = @JoinColumn(name = "post_id"),
        inverseJoinColumns = @JoinColumn(name = "tag_id")
    )
    private Set<Tag> tags = new HashSet<>();

    //Getters and setters ommitted for brevity

    public void addTag(Tag tag) {
        tags.add(tag);
        tag.getPosts().add(this);
    }

    public void removeTag(Tag tag) {
        tags.remove(tag);
        tag.getPosts().remove(this);
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Post)) return false;
        return id != null && id.equals(((Post) o).getId());
    }

    @Override
    public int hashCode() {
        return 31;
    }
}

@Entity(name = "Tag")
@Table(name = "tag")
public class Tag {

    @Id
    @GeneratedValue
    private Long id;

    @NaturalId
    private String name;

    @ManyToMany(mappedBy = "tags")
    private Set<Post> posts = new HashSet<>();

    //Getters and setters ommitted for brevity

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Tag tag = (Tag) o;
        return Objects.equals(name, tag.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name);
    }
}

1. tagsमें संघ Postइकाई केवल परिभाषित करता है PERSISTऔर MERGEझरना प्रकार के। जैसा कि इस लेख में बताया गया है , REMOVE इकाई राज्य परिवर्तन एक @ManyToManyजेपीए एसोसिएशन के लिए कोई मतलब नहीं है क्योंकि यह एक श्रृंखला विलोपन को ट्रिगर कर सकता है जो अंततः एसोसिएशन के दोनों पक्षों को मिटा देगा।
2. जैसा कि इस लेख में बताया गया है , यदि आप द्विदिश संघों का उपयोग करते हैं तो ऐड / रिमूवल यूटिलिटी मेथड अनिवार्य हैं ताकि आप यह सुनिश्चित कर सकें कि एसोसिएशन के दोनों पक्ष सिंक में हैं।
3. Postक्योंकि यह किसी भी अद्वितीय व्यापार कुंजी का अभाव इकाई समानता के लिए इकाई पहचानकर्ता का उपयोग करता है। जैसा कि इस लेख में बताया गया है , आप समानता के लिए इकाई पहचानकर्ता का उपयोग तब तक कर सकते हैं जब तक आप यह सुनिश्चित कर लेते हैं कि यह सभी इकाई बदलावों के अनुरूप है ।
4. Tagइकाई एक अद्वितीय व्यवसाय कुंजी जो हाइबरनेट विशेष के साथ चिह्नित है है @NaturalIdएनोटेशन। जब ऐसा होता है, तो अद्वितीय व्यवसाय कुंजी समानता जांच के लिए सबसे अच्छा उम्मीदवार है ।
5. संस्था में एसोसिएशन की mappedByविशेषता यह इंगित करती है कि, इस द्विदिश संबंध में, इकाई एसोसिएशन का मालिक है। इसकी आवश्यकता तब होती है जब केवल एक पक्ष ही एक संबंध स्थापित कर सकता है, और परिवर्तन केवल इस विशेष पक्ष से डेटाबेस के लिए प्रचारित किए जाते हैं।postsTagPost
6. Setएक का उपयोग कर के रूप में, पसंद किया जा रहा है Listके साथ @ManyToManyकम कुशल है।

@ManyToManyजेपीए और हाइबरनेट के साथ संबंध का सबसे अच्छा तरीका के बारे में अधिक जानकारी के लिए , इस लेख को देखें ।

Answer 6

यह संभवतः कई-से-कई संबंध जहाज के लिए निम्नानुसार कॉल करेगा

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 को परिभाषित करने की आवश्यकता हो सकती है, लेकिन यह बिना काम भी संभव होगा ...

Answer 7

मैं इस तरह समझाता हूँ:

OneToOne - वनटॉइन संबंध

@OneToOne
Person person;

@OneToOne
Nose nose;

OneToMany - ManyToOne संबंध

@OneToMany
Shepherd> shepherd;

@ManyToOne
List<Sheep> sheeps;

ManyToMany - ManyToMany संबंध

@ManyToMany
List<Traveler> travelers;

@ManyToMany
List<Destination> destinations;

Answer 8

सबसे पहले, सभी ठीक प्रिंट पढ़ें। ध्यान दें कि NHibernate (इस प्रकार, मुझे लगता है, हाइबरनेट के रूप में) संबंधपरक मैपिंग में DB और ऑब्जेक्ट ग्राफ़ मैपिंग के साथ एक मज़ेदार पत्राचार है। उदाहरण के लिए, एक-से-एक रिश्तों को अक्सर एक-से-एक संबंधों के रूप में लागू किया जाता है।

दूसरा, इससे पहले कि हम आपको बता सकें कि आपको अपना O / R नक्शा कैसे लिखना चाहिए, हमें आपका DB भी देखना होगा। विशेष रूप से, क्या एक एकल कौशल कई लोगों के पास हो सकता है? यदि हां, तो आपके कई-कई रिश्ते हैं; अन्यथा, यह कई-से-एक है।

तीसरा, मैं कई-से-कई संबंधों को सीधे लागू नहीं करना पसंद करता हूं, लेकिन इसके बजाय अपने डोमेन मॉडल में "ज्वाइन टेबल" को मॉडल करें - अर्थात, इसे एक इकाई के रूप में मानें:

class PersonSkill 
{
    Person person;
    Skill skill;    
}

फिर आप देखते हैं कि आपके पास क्या है? आपके दो-कई रिश्ते हैं। (इस मामले में, व्यक्ति के पास पर्सोस्किल्स का एक संग्रह हो सकता है, लेकिन कौशल का संग्रह नहीं होगा।) हालांकि, कुछ लोग कई-से-कई संबंधों (व्यक्ति और कौशल के बीच) का उपयोग करना पसंद करेंगे; यह विवादास्पद है।

चौथा, यदि आपके पास द्विदिश संबंध हैं (उदाहरण के लिए, न केवल व्यक्ति के पास कौशल का संग्रह है, बल्कि, कौशल का भी व्यक्तियों का एक संग्रह है), NHibernate आपके लिए आपके BL में द्विदिशता को लागू नहीं करता है ; यह केवल दृढ़ता उद्देश्यों के लिए संबंधों की द्विदिशता को समझता है।

पांचवां, कई-से-एक NHibernate में सही ढंग से उपयोग करने के लिए बहुत आसान है (और मुझे हाइबरनेट लगता है) एक से कई (संग्रह मानचित्रण)।

सौभाग्य!