Go to: hibernate link ing

1. Unidirectional N-1

2. Unidirectional 1-1

3. Unidirectional 1-N

4. Unidirectional N-N

5. Bidirectional 1-N

6. Bidirectional N-N

7. Bidirectional 1-1

The following is a simple summary of the seven associations:

I. One-way multi-to-one

View two pojo

Public class person {

Private int PID;

Private string name;

Private address;

... // Generate the corresponding getter and setter Methods

}

----------------------------------------

Public Class address {

Private int ID;

Private string detail;

... // Generate the corresponding getter and setter Methods

}

Here we need to maintain the relationship is that multiple persons can correspond to the same address, using a one-way N-1 ing we only need to add a foreign key at one end to one end.

** View the configuration file

<Class name = "person">

<ID name = "ID">

<Generator class = "native"/>

</ID>

... // Some field configurations are omitted

<Your-to-one name = "Address" column = "addressid"/> // key Configuration

</Class>

After this configuration, Hibernate will add a foreign key SSID to point to one end at one end (person ).

2. Unidirectional 1-1 (foreign key Association)

You can use the <sequence-to-one> label to specify unique = true for multiple ends. This limits the uniqueness of multiple ends.

Ing one-to-one unique foreign key association using this method

You only need to modify the configuration file:

<Your-to-one name = "Address" column = "addressid" unique = "true"/>

3. Unidirectional 1-N

** Looking at the code, we know that a class has multiple students. This is a typical 1-N relationship.

Public class classes {
Private int ID;
Private string name;
Private set students;

... // Generate the corresponding getter and setter Methods

}

---------------------------------------------------------------------------

Public class student {
Private int ID;
Private string name;

.. // Generate the getter and setter methods.

}

** Ing principle: One-to-Multiple Association ing adds a foreign key to one end on multiple ends, and maintains a link pointing to multiple

** Configuration file:

<Class name = "classes" table = "t_classes">
<ID name = "ID">
<Generator class = "native"/>
</ID>
<Property name = "name"/>
<Set name = "Students">
<Key column = "classesid"/> // The foreign key added at one end points to multiple ends (by default, the municipal primary key matches)
<One-to-operate class = "XXX. Student"/> // note that it maintains a multi-point relationship.
</Set>
</Class>

Iv. Bidirectional 1-N

As mentioned above, one-way 1-N can point to multiple ends by adding a foreign key at one end. For bidirectional 1-N, it is similar to a N-N, and no <one-to-minus>

The <sequence-to-sequence> element is used for element ing to associate attributes. To ensure one end, you must add the unique = "true" attribute.

** Configuration: simple modification of one-way 1-N Configuration Files

<Class name = "XXX. Classes" table = "t_classes">
<ID name = "ID">
<Generator class = "native"/>
</ID>
<Property name = "name"/>
<Set name = "Students">
<Key column = "classesid"/>

<Role-to-define class = "XXX. Student" unique = "true"/>
</Set>
</Class>

5. One-way, many-to-many

** First look at two pojo

Public class user {
Private int ID;
Private string name;
Private set roles;

.. // Generate the corresponding getter and setter Methods

}

---------------------------------------------------------------------------

Public class role {
Private int ID;
Private string name;

.. // Generate the corresponding getter and setter Methods

}

Now you need to map this N-N relationship, a user can have multiple role, and a role can be owned by multiple users

So we can split a N-N relationship into two N-1 relationships.

** View the configuration file

<Class name = "XXX. User" table = "t_user">
<ID name = "ID">
<Generator class = "native"/>
</ID>
<Property name = "name"/>
<Set name = "Roles" table = "t_user_role">
<Key column = "userid"/>
<Role-to-define class = "XXX. role" column = "roleid"/>
</Set>
</Class>

In this way, our relationship is clear.

T_user t_user_role t_role

ID name <------- userid roleid -----> ID name

6. Bidirectional Multi-to-Multi-Relationship

Two-way multi-to-Multi- ing requires that a set element be added to both sides for ing set attributes.

Modify the unidirectional N-N ing above

Add set attributes in role

Public class role {
Private int ID;
Private string name;

Privarte Set User

.. // Generate the corresponding getter and setter Methods

}

Modify configuration file

<Class name = "XXX. User" table = "t_user">
<ID name = "ID">
<Generator class = "native"/>
</ID>
<Property name = "name"/>
<Set name = "Roles" table = "t_user_role">
<Key column = "userid"/>
<Role-to-define class = "XXX. role" column = "roleid"/>
</Set>
</Class>

Bytes ------------------------------------------------------------------------------------------------

<Class name = "XXX. role" table = "t_role">
<ID name = "ID">
<Generator class = "native"/>
</ID>
<Property name = "name"/>
<Set name = "users" table = "t_user_role" Order-by = "userid">
<Key column = "roleid"/>
<Role-to-define class = "XXX. User" column = "userid"/>
</Set>
</Class>

Note: 1. You must specify the table name and the column name of the foreign key column for the connection table on both sides of the two-way multi-to-Multi-Join Operation.

2. The table values of the Set elements must be specified and must be the same.

7. Bidirectional one-to-one Association

Two-way 1-1 Association has two forms:

1. Bidirectional 1-1 association based on foreign keys

We can recall the one-way 1-1 ing mentioned above, which is a special case with a N-1, you only need to add the unique = "true" attribute at one end of the <strong-to-one> tag to form a one-to-one ing relationship, so how can we change this ing to bidirectional?

Next let's take another example: a user must have a unique identityid.

First, create two pojo classes.

Public class person {

Private int ID;
Private string name;
Private identityid;

.. // Generate the corresponding getter and setter Methods

}

Public class identityid {
Private int ID;
Private string cardno;
Private person;

.. // Generate the corresponding getter and setter Methods

}

** View the configuration file

<Class name = "XXX. Person" table = "t_person">
<ID name = "ID">
<Generator class = "native"/>
</ID>
<Property name = "name"/>
<Example-to-one name = "identityid" class = "XXX. identityid" unique = "true"/>
</Class>

Bytes -----------------------------------------------------------------------------------

<Class name = "XXX. identityid" table = "t_identity">
<ID name = "ID">
<Generator class = "native"/>
</ID>
<Property name = "cardno"/>
<One-to-one name = "person" class = "XXX. Person" property-ref = "identityid"/>
</Class>

Note: The property-ref attribute here indicates that the association from the identity object to the person object is established.

Therefore, you only need to call the getidentityid () method of the Identity persistence object to navigate to the person object:

The person object and the identityid object are two-way associations. Person. getidentityid (). getperson ()

2. 1-1 bidirectional association based on primary keys

The above pojo class does not need to be changed. We only need to modify the configuration file.

<Class name = "XXX. Person" table = "t_person">
<ID name = "ID" column = "ID">
<Generator class = "foreign">
<Param name = "property"> identityid </param>
</Generator>
</ID>
<Property name = "name"/>
<One-to-one name = "Identity" clsss = "XXX. identityid" constrained = "true"/>
</Class>

Note: Constrained = "true" indicates that the primary key ID of the person table is also used as the foreign key reference identityid table.

Bytes --------------------------------------------------------------------------------------

<Class name = "XXX. Identity" table = "t_identity">
<ID name = "ID">
<Generator class = "native"/>
</ID>
<Property name = "cardno"/>
<One-to-one name = "person" class = "XXX. Person"/>
</Class>

Note: here, the ID in the person table is both a primary key and a foreign key reference table identityid, because the foreign identifier generation policy hibernate ensures that the person

The object shares a primary key with the associated identityid object.

In summary, the object ing method of Hibernate is flexible. If we use hibernate ing properly, we can greatly simplify data access at the persistent layer!