A reference can be either human-readable or an internal object reference. Human-readable references refer to identifiers that are used in human communication, such as the unique names of astronomical bodies, the ISBN of books and the employee numbers of the employees of a company. Internal object references refer to the computer memory addresses of OOP objects, thus providing an efficient mechanism for accessing objects in the main memory of a computer.

Some languages, like SQL and XML, only support human-readable, but not internal references. In SQL, human-readable references are called foreign keys, and the identifiers they refer to are called primary keys. In XML, human-readable references are called ID references and the corresponding attribute type is IDREF.

Objects in an OO program can be referenced either with the help of human-readable references (such as integer codes) or with internal object references, which are preferable for accessing objects efficiently in main memory. Following the XML terminology, we call human-readable references ID references. We follow the standard naming convention for ID reference properties where an ID reference property defined in a class A and referencing objects of class B has the name b_id using the suffix _id. When we store persistent objects in the form of records or table rows, we need to convert internal object references, stored in properties like publisher, to ID references, stored in properties like publisher_id. This conversion is performed as part of the serialization of the object by assigning the standard identifier value of the referenced object to the ID reference property of the referencing object.

In OO languages, a property is defined for an object type, or class, which is its domain. The values of a property are either data values from some datatype, in which case the property is called an attribute, or they are object references referencing an object from some class, in which case the property is called a reference property. For instance, the class Committee shown in Figure Figure 1.1 below has an attribute name with range String, and a reference property chair with range ClubMember.

Figure 1.1. A committee has a club member as chair expressed by the reference property chair

Object-oriented programming languages, such as JavaScript, PHP, Java and C#, directly support the concept of reference properties, which are properties whose range is not a datatype but a reference type, or class, and whose values are object references to instances of that class.

By default, the multiplicity of a property is 1, which means that the property is mandatory and functional (or, in other words, single-valued), having exactly one value, like the property chair in class Committee shown in Figure 1.1. When a functional property is optional (not mandatory), it has the multiplicity 0..1, which means that the property's minimum cardinality is 0 and its maximum cardinality is 1.

A reference property can be either single-valued (functional) or multi-valued (non-functional). For instance, the reference property Committee::chair shown in Figure 1.1 is single-valued, since it assigns a unique club member as chair to a club. An example of a multi-valued reference property is provided by the property Book::authors shown in Figure 1.11 below.

Normally, the collection value of a multi-valued reference property is a set of references, implying that the order of the references does not matter. In certain cases, however, the order matters and, consequently, the collection value of such a multi-valued reference property is an ordered set of references, typically implemented as a list.

References are important information items in our application's database. However, they are only meaningful, when their referential integrity is maintained by the app. This requires that for any reference, there is a referenced object in the database. Consequently, any reference property p with domain class C and range class D comes with a referential integrity constraint that has to be checked whenever

A referential integrity constraint also implies two change dependencies:

In certain cases, we may want to relax this strict regime and allow creating objects that have non-referencing values for an ID reference property, but we do not consider such cases.

Typically, object creation dependencies are managed in the user interface by not allowing the user to enter a value of an ID reference property, but only to select one from a list of all existing target objects.

A reference property (such as chair in the example shown in Figure 1.1 above) can be modeled in a UML class diagram in the form of an association end owned by its domain class, which is visualized with the help of a small filled circle (also called a "dot"). This requires to connect the domain class and the range class of the reference property with an association line, place an ownership dot at the end of this line at the range class side, and annotate this association end with the property name and with a multiplicity symbol, as shown in Figure 1.2 below for the case of our example. In this way we get a unidirectional association, the source class of which is the property's domain and the target class of which is the property's range.

The fact that an association end is owned by the class at the other end, as visually expressed by the association end ownership dot at the association end chair in the example shown in Figure 1.2 below, implies that the association end represents a reference property. In the example of Figure 1.2, the represented reference property is Committee::chair having ClubMember as range. Such an association, with only one association end ownership dot, is unidirectional in the sense that it allows `navigation´ (object access) in one direction only: from the class at the opposite side of the dot (the source class) to the class where the dot is placed (the target class).

Figure 1.2. An association end with a "dot"

Thus, the two diagrams shown in Figure 1.1 and Figure 1.2 express essentially equivalent models. When a reference property, like chair in Figure 1.1, is modeled by an association end with a "dot", then the property's multiplicity is attached to the association end. Since in a design model, all association ends need to have a multiplicity, we also have to define a multiplicity for the other end at the side of the Committee class, which represents the inverse of the property. This multiplicity (of the inverse property) is not available in the original property description in the model shown in Figure 1.1, so it has to be added according to the intended semantics of the association. It can be obtained by answering the question "is it mandatory that any ClubMember is the chair of a Committee?" for finding the minimum cardinality and the question "can a ClubMember be the chair of more than one Committee?" for finding the maximum cardinality.

When the value of a property is a set of values from its range, the property is non-functional and its multiplicity is either 0..* or n..* where n > 0. Instead of 0..*, which means "neither mandatory nor functional", we can simply write the asterisk symbol *. The association shown in Figure 1.2 assigns at most one object of type ClubMember as chair to an object of type Committee. Consequently, it's an example of a functional association.

The following table provides an overview about the different cases of functionality of an association:

Notice that the directionality and the functionality type of an association are independent of each other. So, a unidirectional association can be either functional (one-to-one or many-to-one), or non-functional (one-to-many or many-to-many).

A unidirectional association between a source and a target class can be represented as a reference property of the source class. This is illustrated in Figure 1.3 below for two unidirectional associations: a many-to-one and a many-to-many association.

Figure 1.3. Representing unidirectional associations as reference properties

Notice that, in a way, we have eliminated the two explicit associations and replaced them with corresponding reference properties resulting in a class model that can be coded with a classical OOP language in a straightforward way. OOP languages do not support associations as first class citizens. They do not have a language element for defining associations. Consequently, an OOP class design model, which we call OO class model, must not contain any explicit association.

When we make an information model in the form of a UML class diagram, we typically end up with a model containing one or more associations that do not have any ownership defined for their ends, as, for instance, in Figure 1.4 below. When there is no ownership dot at either end of an association, such as in this example, this means that the model does not specify how the association is to be represented (or realized) with the help of reference properties. Such an association does not have any direction. According to the UML 2.5 specification, the ends of such an association are "owned" by itself, and not by any of the classes participating in it.

Figure 1.4. A model of a non-directed association between Committee and ClubMember

An information design model that contains an association without association end ownership dots is acceptable as a relational database design model, but it is incomplete as a design model for OOP languages.

For instance, the model of Figure 1.4 provides a relational database design with two entity tables, committees and clubmembers, and a separate one-to-one relationship table committee_has_clubmember_as_chair. But it does not provide a design for Java classes, since it does not specify how the association is to be implemented with the help of reference properties.

There are three options how to turn an information design model of a non-directed association (without any association end ownership dots) into an information design model where all associations are either unidirectional or bidirectional: we can place an ownership dot at either end or at both ends of the association. Each of these three options defines a different way how to represent, or implement, the association with the help of reference properties. So, for the association shown in Figure 1.4 above, we have the following options:

So, whenever we have modeled an association, we have to make a choice, which of its ends represents a reference property and will therefore be marked with an ownership dot. It can be either one, or both. This decision also implies a decision about the navigability of the association. When an association end represents a reference property, this implies that it is navigable (via this property).

In the case of a functional association that is not one-to-one, the simplest design is obtained by defining the direction of the association according to its functionality, placing the association end ownership dot at the association end with the multiplicity 0..1 or 1 . For a non-directed one-to-one or many-to-many association, we can choose the direction as we like, that is, we can place the ownership dot at either association end.

The model shown in Figure 1.6 below (about publishers and books) serves as our running example for a unidirectional functional association in this tutorial. Notice that it contains the unidirectional many-to-one association Book-has-Publisher.

Figure 1.6. The Publisher-Book information design model with a unidirectional association

We may also have to deal with a non-functional (multi-valued) reference property representing a unidirectional non-functional association. For instance, the unidirectional many-to-many association between Book and Author shown in Figure 1.7 below, models a multi-valued (non-functional) reference property authors.

Figure 1.7. The Publisher-Book-Author information design model with two unidirectional associations

Since classical OO programming languages do not support associations as first class citizens, but only classes and reference properties representing unidirectional associations, we have to eliminate all explicit associations from general information design models for obtaining OO class models.

7.1. The basic elimination procedure restricted to unidirectional associations

The starting point of our restricted association elimination procedure is an information design model with various kinds of unidirectional associations, such as the model shown in Figure 1.6 above. If the model still contains any non-directional associations, we first have to turn them into directional ones by making a decision on the ownership of their ends, as discussed in Section 5.

A unidirectional association connecting a source with a target class is replaced with a corresponding reference property in its source class having

1. the same name as the association end, if there is any, otherwise it is set to the name of the target class (possibly pluralized, if the reference property is multi-valued);

2. the target class as its range;

3. the same multiplicity as the target association end,

4. a uniqueness constraint if the unidirectional association is inverse functional.

This replacement procedure is illustrated for the case of a unidirectional one-to-one association in Figure 1.3 below.

Figure 1.8. Turning a functional association end into a reference property

For the case of a unidirectional one-to-many association, Figure 1.9 below provides an illustration of the association elimination procedure. Here, the non-functional association end at the target class Point is turned into a corresponding reference property with name points obtained as the pluralized form of the target class name.

Figure 1.9. Turning a non-functional association end into a multi-valued reference property

7.2. Eliminating associations from the design model

In the case of our running example, the Publisher-Book-Author information design model, we have to replace both unidirectional associations with suitable reference properties. In the first step, we replace the many-to-one association Book-has-Publisher in the model of Figure 1.6 with a functional reference property publisher in the class Book, resulting in the following OO class model:

Figure 1.10. An OO class model for Publisher and Book

Notice that since the target association end of the Book-has-Publisher association has the multiplicity 0..1, we have to declare the new property publisher as optional by defining its multiplicity to be 0..1.

The meaning of this OO class model and its reference property publisher can be illustrated by a sample data population for the two model classes Book and Publisher as presented in the following tables:

Table 1.4. Sample data for Publisher

Name	Address
Bantam Books	New York, USA
Basic Books	New York, USA

Table 1.5. Sample data for Book

ISBN	Title	Year	Publisher
0553345842	The Mind's I	1982	Bantam Books
1463794762	The Critique of Pure Reason	2011
1928565379	The Critique of Practical Reason	2009
0465030793	I Am A Strange Loop	2000	Basic Books

In the second step, we replace the many-to-many association Book-has-Author in the model of Figure 1.7 with a multi-valued reference property authors in the class Book, resulting in the following OO class model:

Figure 1.11. An OO class model for all three classes

After the platform-independent OO class model has been completed, one or more platform-specific data models, for a choice of specific implementation platforms, can be derived from it. Such a platform-specific data model can still be expressed in the form of a UML class diagram, but it contains only modeling elements that can be directly coded in the chosen platform. Thus, for any platform considered, two guidelines are needed: 1) how to make the platform-specific data model, and 2) how to code this model.

The widgets used for data input and output in a (CRUD) data management user interface (UI) normally correspond to properties defined in a model class of an app. We have to distinguish between (various types of) input fields corresponding to (various kinds of) attributes, and choice widgets (such as selection lists) corresponding to enumeration attributes or to reference properties. Representing reference properties in the UI with select controls, instead of input fields, prevents the user from entering invalid ID references, so it takes care of referential integrity.

In general, a single-valued reference property can be rendered as a single-selection list in the UI, no matter how many objects populate the reference property's range, from which one specific choice is to be made. If the cardinality of the reference property's range is sufficiently small (say, not greater than 7), then we can also use a radio button group instead of a selection list.

A multivalued reference property can be rendered as a multiple-selection list in the UI. However, the corresponding multiple-select control of HTML is not really usable as soon as there are many (say, more than 20) different options to choose from because the way it renders the choice is visually too scattered. In the special case of having only a few (say, no more than 7) options, we can also use a checkbox group instead of a multiple-selection list. But for the general case of having in the UI a list containing all associated objects chosen from the reference property's range class, we need to develop a special UI widget that allows to add (and remove) objects to (and from) a list of chosen objects.

Such a multiple-choice widget consists of

A single-valued reference property, such as the property publisher of the object type Book, allows storing internal references to objects of another type, such as Publisher. When creating a new object, the constructor function needs to have a parameter for allowing to assign a suitable value to the reference property. In a typed programming language, such as Java, we may have to take a decision if this value is expected to be an internal object reference or an ID reference. Using the JPA object-to-storage mapping technology, we can work with object references and leave the mapping to corresponding ID references to JPA. The Book class is extended as follows:

@Entity @Table( name="books")
@ViewScoped @ManagedBean( name="book")
public class Book {
  ...
  private Publisher publisher;
	
  public Book() {}
  public Book( String isbn, String title, Integer year, 
      Publisher publisher) {...}
	
  public Publisher getPublisher() {...}
  public void setPublisher( Publisher publisher) {...}
  ...
}

The starting point for making a Java Entity class model is an OO class model like the one shown in Figure 1.10.

As explained in the previous parts of this tutorial, we obtain the Java Entity class Publisher from the corresponding information design class by (1) making all properties private, (2) using Java datatype classes (String, Integer, etc.), (3) adding the stereotype «get/set» to properties (specifying public getters and setters), (4) adding a toString function, (5) adding the (class-level) data storage methods create, retrieve, update and delete:

In a Java Entity class model, for any association end dot in the OO class model, we show the reference property representing the association end and annotate it with the functionality type of the unidirectional association represented by it. In our example, we add a reference property publisher in the entity class Book and annotate it with the association's functionality type manyToOne:

Compared to the single-class apps discussed in the previous parts of this tutorial, we have to deal with a number of new technical issues:

The Java Entity class model can be directly coded for getting the model layer code of our Java back-end app.

@Entity @Table( name="books")
@ViewScoped @ManagedBean( name="book")
public class Book {
  @Id @NotNull( message="An ISBN is required!")
  private String isbn;
  @Column( nullable=false)
  @NotNull( message="A title is required!")
  private String title;
  @Column( nullable=false)
  @NotNull( message="A year is required!")
  private Integer year;
  @ManyToOne( fetch=FetchType.EAGER)
  private Publisher publisher;

  public Book() {}
  public Book( String isbn, String title, 
      Integer year, Publisher publisher) {
    this.setIsbn( isbn);
    this.setTitle( title);
    this.setYear( year);
    this.setPublisher( publisher);
  }
  ...  // getters, setters, etc.
}

CREATE TABLE IF NOT EXISTS `books` (
  `ISBN` varchar(10) NOT NULL,
  `TITLE` varchar(255) NOT NULL,
  `YEAR` int(11) NOT NULL,
  `PUBLISHER_NAME` varchar(255) DEFAULT NULL 
      FOREIGN  KEY (`PUBLISHER_NAME`) REFERENCES `publishers` (`NAME`)
);

@Id @NotNull( message="A name is required!")
private String name;

@Column( nullable=false)
@NotNull( message="An address is required!")
private String address;

public static void delete( EntityManager em, UserTransaction ut, 
    String name) throw Exception {
  ut.begin();
  Publisher publisher = em.find( Publisher.class, name);
  // find all Books which have this publisher
  Query query = em.createQuery( 
      "SELECT b FROM Book b WHERE b.publisher.name = :name");
  query.setParameter( "name", name);
  List<Book> books = query.getResultList();
  // clear these books' publisher reference
  for ( Book b: books) { b.setPublisher( null);}
  em.remove( publisher);
  ut.commit();
}

The user interface (UI) consists of a start page for navigating to the data management UI pages and one UI page for each object type and data management use case. All these UI pages are defined in the form of JSF view files in subfolders of the WebContent/views/ folder. We create the Main Menu page index.xhtml in the subfolder WebContent/views/app with the following content:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ui="..." xmlns:h="..." xmlns:f="...">
  <ui:composition template="/WEB-INF/templates/page.xhtml">
    <ui:define name="content">
      <h2>Public Library</h2>
      <h:button value="Manage publishers" 
          outcome="/views/publishers/index" />
      <h:button value="Manage books" outcome="/views/books/index" />
      <h:form>
        <h:commandButton value="Clear database" 
            action="#{appCtrl.clearData()}" />
        <h:commandButton value="Create test data" 
            action="#{appCtrl.createTestData()}" />
      </h:form>
    </ui:define>
  </ui:composition>
</html>

It creates the menu buttons which provide the redirects to corresponding views for each of the management pages. Additionally, we need to create a corresponding AppController class which is responsible for the creation and deletion of the test data. The controller is used to combine code of the Publisher.createTestData and Publisher.clearData methods with Book.createTestData and Book.clearData methods as follows:

@ManagedBean( name="appCtrl")
@SessionScoped
public class AppController {
  @PersistenceContext( unitName="UnidirAssocApp")
  private EntityManager em;
  @Resource()
  UserTransaction ut;

  public String clearData() {
    try {
      Book.clearData( em, ut);
      Publisher.clearData( em, ut);
    } catch ( Exception e) {
      e.printStackTrace();
    }
    return "index";
  }
  public String createTestData() {
    try {
      Publisher.createTestData( em, ut);
      Book.createTestData( em, ut);
    } catch ( Exception e) {
      e.printStackTrace();
    }
    return "index";
  }
}

The deletion of Book and Publisher data must be done in a particular order for avoiding referential integrity violations (books have to be deleted first, before their publishers are deleted).

<ui:composition template="/WEB-INF/templates/page.xhtml">
  <ui:define name="content">
    <h:dataTable value="#{bookCtrl.books}" var="b">
      ...
      <h:column>
        <f:facet name="header">Publisher</f:facet>
        #{b.publisher.name}
      </h:column>
    </h:dataTable>
    <h:button value="Main menu" outcome="index" />
  </ui:define>
</ui:composition>

@FacesConverter( value="pl.m.converter.PublisherConverter")
public class PublisherConverter implements Converter {
  @Override
  public Object getAsObject( FacesContext context, 
      UIComponent component, String value) {
    PublisherController ac = FacesContext
        .getCurrentInstance()
        .getApplication()
        .evaluateExpressionGet( context, "#{publisherCtrl}",
            PublisherController.class);
    EntityManager em = ac.getEntityManager();
    if (value == null) return null;
    else return em.find( Publisher.class, value);
  }
  @Override
  public String getAsString( FacesContext context, 
      UIComponent component, Object value) {
    if (value == null) return null;
    else if (value instanceof Publisher) {
      return ((Publisher) value).getName();
    }
    else return null;
  }
}

PublisherController ac = FacesContext.getCurrentInstance()
     .getApplication()
     .evaluateExpressionGet( context, "#{publisherCtrl}", 
          PublisherController.class);

@ManagedBean( name="publisherCtrl")
@SessionScoped
public class PublisherController {
  @PersistenceContext( unitName="UnidirAssocApp")
  private EntityManager em;
  @Resource()
  UserTransaction ut;

  public EntityManager getEntityManager() {
    return this.em;
  }
  ...
}

@Override
public boolean equals( Object obj) {
  if (obj instanceof Publisher) {
    Publisher publisher = (Publisher) obj;
    return ( this.name.equals( publisher.name));
  } else return false;
}

<ui:composition template="/WEB-INF/templates/page.xhtml">
 <ui:define name="content">
  <h:form id="createBookForm" styleClass="pure-form pure-form-aligned">
   <h:panelGrid columns="3">
    ...
    <h:outputLabel for="publisher" value="Publisher:" />
    <h:selectOneMenu id="publisher" value="#{book.publisher}">
     <f:selectItem itemValue="" itemLabel="---" />
     <f:selectItems value="#{publisherCtrl.publishers}" var="p" 
                    itemLabel="#{p.name}" itemValue="#{p}" />
     <f:converter converterId="pl.m.converter.PublisherConverter" />
    </h:selectOneMenu>
    <h:message for="publisher" errorClass="error" />
    </h:panelGrid>
     <h:commandButton value="Create" 
         action="#{bookCtrl.create( book.isbn, book.title, 
         book.year, book.publisher.name)}" />
  </h:form>
 </ui:define>
</ui:composition>

public List<Publisher> getPublishers() {
  return Publisher.getAllObjectsAll( em);
}

public String create( String isbn, String title, Integer year, 
    Publisher publisher) {
  try {
    Book.create( em, ut, isbn, title, year, publisher);
    // Enforce clearing the form after creating the Book row.
    // Without this, the form will show the latest completed data
    FacesContext facesContext = FacesContext.getCurrentInstance();
    facesContext.getExternalContext().getRequestMap().remove( "book");
  } catch ( EntityExistsException e) {
    try {
      ut.rollback();
    } catch ( Exception e1) {
      e1.printStackTrace();
    }
    e.printStackTrace();
  } catch ( Exception e) {
    e.printStackTrace();
  }
  return "create";
}

<ui:composition template="/WEB-INF/templates/page.xhtml">
 <ui:define name="content">
  <h:form id="createBookForm" styleClass="pure-form pure-form-aligned">
   <h:panelGrid columns="3">
    ...
    <h:outputLabel for="selectBook" value="Select book: " />
    <h:selectOneMenu id="selectBook" value="#{book.isbn}">
     <f:selectItem itemValue="" itemLabel="---" /> 
     <f:selectItems value="#{bookCtrl.books}" var="b" 
         itemValue="#{b.isbn}" itemLabel="#{b.title}" /> 
     <f:ajax listener="#{bookCtrl.refreshObject( book)}" 
         render="isbn title year publisher"/>
    </h:selectOneMenu>
    <h:message for="selectedBook"/>
     ...
   </h:panelGrid>
   <h:commandButton value="Create" action="#{bookCtrl.create( 
       book.isbn, book.title, book.year, book.publisher.name)}" />
  </h:form>
 </ui:define>
</ui:composition>

A multi-valued reference property, such as Book::authors, allows storing a collection of references to objects of some type, such as references to Author objects. When creating a new object of type Book, it must be possible to assign one or more authors to the book. to assign the constructor needs an extra parameter for the multi-valued reference property. In general, we can allow this value to be a set (or list) of internal object references or of ID references. However, using JPA there is no need for ID references, being very easy to use object references:

@Entity @Table( name="books")
@ManagedBean( name="book")
@ViewScoped
public class Book {
  ...
  private Set<Author> authors;
  
  public Book() { // required by JPA @Entity annotation!}
  public Book( String isbn, String title, Integer year, Publisher publisher, Set<Author> authors) {...}

  public Set<Author> getAuthors() { return this.authors;}
  public void setAuthors( Set<Author> authors) { this.authors = authors;}
  ...
}

The starting point for making a Java Entity class model is an OO class model where reference properties represent associations. The following model for our example app contains the multi-valued reference property Book::authors, which represents the unidirectional many-to-many association Book-has-Author:

This model contains, in addition to the unidirectional many-to-one association Book-has-Publisher, the unidirectional many-to-many association Book-has-Author, which corresponds to the multi-valued reference property Book::authors.

The meaning of the OO class model and its reference properties publisher and authors can be illustrated by a sample data population for the three model classes:

We obtain the Java Entity class Author from the corresponding class in the OO class model, as explained in the previous parts of this tutorial, by (1) making all properties private, (2) using Java datatype classes, (3) adding public getters and setters, (4) adding a toString function, (5) adding the data storage methods create, retrieve, update and delete:

In the Java Entity class model, any reference property specified in the OO class model is annotated with the functionality type of the association represented by it. In our example, we annotate the reference property authors in the Entity class Book with manyToMany:

Compared to dealing with a unidirectional functional association, as discussed in the previous section, we have to deal with the following new technical issues:

The last issue, allowing to select a collection of associated objects from a list of all existing instances of some class, in general, cannot be solved with the help of an HTML select multiple form element because of usability problems. Whenever the set of selectable options is greater than a certain threshold (defined by the number of options that can be seen on the screen without scrolling), the HTML select multiple element is no longer usable, and an alternative multi-selection widget has to be used.

The Java Entity class model can be directly coded for getting the code of the model layer of our Java back-end app.

@Entity @Table( name="books")
@ViewScoped @ManagedBean( name="book")
public class Book {
  ...
  @ManyToMany( fetch=FetchType.EAGER)
  private Set<Author> authors;
 
  public Book() {}
  public Book( String isbn, String title, Integer year, 
      Publisher publisher, Set<Author> authors) {...}
  ...
  public Set<Author> getAuthors() { return this.authors;}
  public void setAuthors( Set<Author> authors) { this.authors=authors;}
  ...
}

CREATE TABLE IF NOT EXISTS `books_author` (
  `Book_ISBN` varchar(10) NOT NULL,
  `authors_PERSONID` int(11) NOT NULL
);

@JoinTable( name="books_authors", 
            joinColumns = {@JoinColumn( name="book_isbn", referencedColumnName="ISBN")},
            inverseJoinColumns = {@JoinColumn( name="author_personid", referencedColumnName="PERSONID")}

@Entity
@Table( name="author")
@ManagedBean( name="author")
@ViewScoped
public class Author {
  @Id @PositiveInteger
  private Integer personId;
  @Column( nullable=false)
  @NotNull( message="A name is required!")
  private String name;
  @Column( nullable=false)
  @NotNull( message="A date of birth is required!")
  @Past private Date dateOfBirth;
  @Past private Date dateOfDeath;

  public Author() {}
  public Author( Integer personId, String name, Date dateOfBirth, 
      Date dateOfDeath) {...}

  public Integer getPersonId() {...}
  public void setPersonId( Integer personId) {...}
  public String getName() {...}
  public void setName( String name) {...}
  public Date getDateOfBirth() {...}
  public void setDateOfBirth( Date dateOfBirth) {...}
  public Date getDateOfDeath() {...}
  public void setDateOfDeath( Date dateOfDeath) {...}

  public static void create( EntityManager em, UserTransaction ut, Integer personId, 
      String name, Date dateOfBirth, Date dateOfDeath) {...}
  public static void update( EntityManager em, UserTransaction ut, Integer personId, 
      String name, Date dateOfBirth, Date dateOfDeath) {...}
  public static void delete( EntityManager em, UserTransaction ut, 
      Integer personId) {...}
}

public static void delete( EntityManager em, UserTransaction ut, 
    Integer personId) throws Exception {
  ut.begin();
  Author author = em.find( Author.class, personId);
  // find all books with this author
  Query query = em.createQuery( "SELECT DISTINCT b FROM Book b "+
      "INNER JOIN b.authors a WHERE a.personId = :personId");
  query.setParameter( "personId", personId);
  List<Book> books = query.getResultList();
  // update the corresponding book-to-author relations from the association
  // table (otherwise the author can't be deleted)
  for ( Book b : books) {
    b.getAuthors().remove( author);
  }
  // remove the author entry (table row)
  em.remove( author);
  ut.commit();
}

Running your application is simple. First stop (if already started, otherwise skip this part) your Tomcat/TomEE server by using bin/shutdown.bat for Windows OS or bin/shutdown.sh for Linux. Next, download and unzip the ZIP archive file containing all the source code of the application and also the ANT script file which you have to edit and modify the server.folder property value. Now, execute the following command in your console or terminal: ant deploy -Dappname=unidirectionalassociationapp. Last, start your Tomcat web server (by using bin/startup.bat for Windows OS or bin/startup.sh for Linux). Please be patient, this can take some time depending on the speed of your computer. It will be ready when the console display the following info: INFO: Initializing Mojarra [some library versions and paths are shonw here] for context '/unidirectionalassociationapp'. Finally, open a web browser and type: http://localhost:8080/unidirectionalassociationapp/faces/views/app/index.xhtml

You may want to download the ZIP archive containing all the dependency libaries, or run the unidirectional association app directly from our server.