Composite Identifiers And Associations-1

As seen in an earlier post, Composite Identifiers are used when you have natural primary keys as opposed to surrogate keys.In this case the primary keys are assigned by the user. There exists the case when the primary key used is actually the primary key of some other table. i.e. it is a foreign key. In this case how do we manage the identifier and also create an association for directional navigation ??

Using a Map with the formula attribute

In different posts I have worked with different data in collections - with java data type (Strings), components and then with entities. For maps the technique was based on having a value that became the map key and the value was the data as String or a Component or the Entities. This meant that there were two columns - one holding the key and the other representing the value.

Creating a Ternary Relation -2

In the absence of any extra information, a map can be used to represent a ternary relationship. Considering the same example of People, chocolates and the Shops selling them. The relation could be maintained as  a map:

class Person {
    Map<Shop, Chocolate> shopChocolate;
}

I had to get rid of the additional join columns from the previous example. The detailed example would involve the same entities as last time.

Creating a Ternary Relation -1

In the previous post we saw how to manage a many to many relation with join data. The same concept can be extended further to create a simple ternary relation. In the earlier example  the "shopName" attribute of the join table was a simple String. This could be changed to a Shop Entity instead.

Adding columns to the join table

Previously we created a many to many relation between People and the chocolates they liked. This resulted in a "many people like many chocolates" relation. The relation data was mapped to a separate join table. Now we would like to hold some additional information such as date a person first tasted the chocolate and shop name from where the chocolate was eaten. (I know the example gets weirder and weirder but what the heck, I want to try this example out.)
This now means that the join table will have to hold information additional to the association details.

Creating a many to many association - BiDirectional

Continuing from the last post, I shall now make the Person Chocolate relation bidirectional. This means that chocolate will also hold a collection of its fans. Instead of using a set here, I decided to use a bag. The updated java files are as below:

Creating a many to many association - UniDirectional

After one to many, its time to try a many-to-many association. This association is rarely used , instead being replaced with 2 many-to-one associations. For this example I decided to create two entities- people and chocolate (ya am still on chocolates only :) ). Many people like mannnnnnnnnnnnnnnny chocolates. As we are considering unidirectional relation, the mapping can be seen from the People class only.

One To Many association that is optional

We have seen one to many relations before but Hibernate also supports an optional one to many relationship. Consider chocolates and Bags. There is a possibility that some chocolates exists outside of a bag. Every chocolate can at any given time be in one and only one bag. However a particular chocolate may also not be in any bag. This makes the one to many relation an optional association.

One to One Association Using Foreign Key

In the earlier technique I  mapped a one-to-one relation using a shared primary key. Now I shall attempt to create the same relation-ship using foreign keys.
Both the tables in this case will have their own independent primary key and id generation strategies. One of the tables (mostly the entity owning the relation, in this case the Order_Data) has  a column which references the primary key from the other table.

One to one association that is optional

In previous posts I have tried out one to one associations involving shared primary keys and foreign keys.In the that example an Order had a one to one relation between BillDetail.Consider the scenario wherein an Order is created separately from the BillDetail. The Bill Detail information is added at a later date. This means that the one-to-one relation between the two entities is optional and may not be always present.The relation would require that