Welcome to lesson 5, associations. Here we will implement many JPA annotations to represent associations between entities. We will use transitive persistence across relationships using various cascade options to secure and also persist object graphs that represent relationships between our entities, and have those relationships represented in the database through primary key, foreign key relationships. We also have build element collections of strings or embeddable classes that we can use in our entities using the same relationships that we would use between two different entities. Then finally, we'll look at some inheritance relationship modeling. Your Java applications basically have a web of data relationships that can become a tangled mess if improperly handled. Within a relational database schema, this is frequently implemented with primary, foreign Key relationships. For classes, we need to map entities to such relationships, and we do so using various JPA annotations, One-to-Many, Many-to-Many, and Many-to-One, for example. By leveraging these relationships, complete object graphs can both be retrieved in one go and also persisted in one go, rather than interacting with the database in your code multiple times. In order to have a relationship, you need to have entities somehow annotated to dictate that relationship. Each participant has its own view of the relationship or it's role. We will show you how we will map the various participants in a relationship to that database schema types through primary, foreign Key relationships. In order to work with relationships in a domain, OO system, we have to have a way to model and manage them. The system by an entity having an attribute that refers to a related entity is a class member variable, for example. We somehow have to say when we persist this, or when we retrieve it, that there is a relationship to manage the other end on the database. Uni and bidirectional relationships differ in that, one of both sides will have attributes that reference the entities at the other end of the relationship. Cardinality refers to the type of compositional relationship that we're talking about here: One-to-Many, Many-to-Many, Many-to-One, One-to-One. This entity has a collection of this other entity, or this entity belongs to many other different entities in a compositional relationship. Now if you look at this little example of employee and qualification, we will see that the employee table has a primary key EMPID, and that the qualification table also has a primary key QUALID, but it also has a foreign key, EMPID. We're going to try and model an employee and a qualification relationship in a domain entity OO model. The first thing we'll do is to manage the qualification class. We have here a Many-to-One annotation targetEntity Employee.class. That's not always required actually. It'll work it out by whatever thus member variable you're annotating. Then it will have a joinColumn annotation EMPLOYEEID that refers to the foreign key on the table associated with the qualification entity. If we go back to our little schema, we can see we're talking about EMPID on the right-hand side in the qualification table. I mentioned that the targetEntity attribute is optional. By default, you'll use the class member variable type. The joinColumn is as well. If you don't put it in, it'll make an attempt to figure out what the foreign key is on the table. It will use the name of the entity qualification underscore. Then it'll say, "Well, I'm annotating a property called employee, which is a type employee. So I am going to look to see what the primary key of employee is. It's EMPID. I'm going to look for a foreign key on the qualification table of QUALIFICATIONS_EMPID." Obviously, that's not the case here. We did use joinColumn. The owning side is the side that has the foreign key. For Many-to-One mappings, the many side is always the owning side. Annotations that define the mappings to the columns in the database will always appear on the owning side. Looks like we're retrieving a qualification using the entity manages find method. You will clearly see here in the SQL that it doesn't eager fetch as we call it, on the employee because this is a singular relationship. Singular relationships are fetched eagerly. We clearly see the left data join on the employee table to go and get the employee. When you look at the qualification that you've retrieved, the employee member variable will be populated with all its properties. How do we maintain these relationships? If we wanted to create a new quantification, we need a student. How do we maintain these relationships? It's pretty simple. You just use your Java code to manage each side of the relationship. For example, here I'm creating an employee, I'm creating a new qualification, and I'm setting the employee property owning qualification to the retrieved or managed employee. Now, you must remember, since it's managed, it has a primary identifier. When we come to insert this in the qualification table, it can get hold of that foreign key, which is the primary key of employee. Indeed here's the insert SQL. Remember I talked about logging in, insert, and hibernate, duplicating depending on your configurations in the persistence XML. Our relationship is unidirectional. There's no attribute on the employee side. We can change this by adding an index attribute such as a collection list, settle map to the employee to make it bidirectional. Here I've put in a collection of qualifications as a member variable, probably with getters and setters as well, and I've annotated with One-to-Many. The mappedBy attribute of this annotation is actually looking at the owning side of the relationship. How does it know what the owning side is? Because of the generic on the collection. It's looking on qualification and saying qualification should have a member variable called employee. Associated with that is a joinColumn. That joinColumn will identify the foreign key on the qualification table that maps the primary key column on the employee table which this employee entity is associated with. Simply retrieving the employee will now bring back a collection of qualifications because it can transgress from the primary key on EMPLOYEE to the foreign key on the QUALIFICATION table. That's what we've got here. It's an M1 select because One-to-Many relationships in JPA are fetch lazily. What that means is I will fetch the employee first and it's not until I take action on the qualification collection like getting its size that you'll see the SQL that will go against the qualification table. You can see it quite clearly the foreign key is being used, which is the primary key of the enclosing employee, so to speak. Only the owning side which generates SQL for this relationship. Everything is done from the owning side qualification. JPA requires you to clear the property of an interface in a One-to-Many relationship as an interface type collection list, etc, not an implementation type. This is because JPA may return a different implementation of that interface. Now, we saw all the N1 select. If I just put fetch type eager on the One-to-Many on the employee side to get the qualifications, you will see the SQL has changed, I immediately, upon getting the employee back, will also eagerly get all it's qualifications back using a left outer join.
