For being able to easily retrieve the committees that are chaired or co-chaired by a club member, we add two reference properties to our Committee-ClubMember example model: the property of a club member to be the chair of a committee (ClubMember::chairedCommittee) and the property of a club member to be the co-chair of a committee (ClubMember::coChairedCommittee). We assume that any club member may chair or co-chair at most one committee (where the disjunction is non-exclusive). So, we get the following model:

Notice that there is a close correspondence between the two reference properties Committee::chair and ClubMember::chairedCommittee. They are the inverse of each other: when the club member Tom is the chair of the budget committee, expressed by the tuple ("budget committee", "Tom"), then the budget committee is the committee chaired by the club member Tom, expressed by the inverse tuple ("Tom", "budget committee"). For expressing this inverse correspondence in the diagram, we append an inverse property constraint, inverse of chair, in curly braces to the declaration of the property ClubMember::chairedCommittee, and a similar one to the property Committee::chair, as shown in the following diagram:

Using the reference path notation of OOP languages, with c referencing a Committee object, we obtain the equation:

Or, the other way around, with m referencing a ClubMember object, we obtain the equation:

Notice that when a property p₂ is the inverse of a property p₁, this implies that, the other way around, p₁ is the inverse of p₂. Therefore, when we declare the property ClubMember::chairedCommittee to be the inverse of Committee::chair, then, implicitly, Committee::chair is the inverse of ClubMember::chairedCommittee. We therefore call Committee::chair and ClubMember::chairedCommittee a pair of mutually inverse reference properties. Having such a pair in a model implies redundancy because each of the two involved reference properties can be derived from the other by inversion. This type of redundancy implies data storage overhead and update overhead, which is the price to pay for the bidirectional navigability that supports efficient object access in both directions.

For maintaining the duplicate information of a mutually inverse reference property pair, it is common to treat one of the two involved properties as the master, and the other one as the slave, and take this distinction into consideration in the code of the change methods (such as the property setters) of the affected model classes. We indicate the slave of an inverse reference property pair in a model diagram by declaring the slave property to be a derived property using the UML notation of a slash (/) as a prefix of the property name as shown in the following diagram:

The property chairedCommittee in ClubMember is now derived (as indicated by its slash prefix). Its annotation {inverse of chair} defines a derivation rule according to which it is derived by inverting the property Committee::chair.

There are two ways how to realize the derivation of a property: it may be derived on read via a read-time computation of its value, or it may be derived on update via an update-time computation performed whenever one of the variables in the derivation expression (typically, another property) changes its value. The latter case corresponds to a materialized view in a database. While a reference property that is derived on read may not guarantee efficient navigation, because the on-read computation may create unacceptable latencies, a reference property that is derived on update does provide efficient navigation.

When we designate an inverse reference property as derived by prefixing its name with a slash (/), we indicate that it is derived on update. For instance, the property /chairedCommittee in the example above is derived on update from the property chair.

In the case of a derived reference property, we have to deal with life cycle dependencies between the affected model classes requiring special change management mechanisms based on the functionality type of the represented association (either one-to-one, many-to-one or many-to-many).

In our example of the derived inverse reference property ClubMember::chairedCommittee, which is single-valued and optional, this means that

In the case of a derived inverse reference property that is multi-valued while its inverse base property is single-valued (like Publisher::publishedBooks in Figure 1.4 below being derived from Book::publisher), the life cycle dependencies imply that

Notice that from a purely computational point of view, we are free to choose either of the two mutually inverse reference properties (like Book::authors and Author::authoredBooks) to be the master. However, in many cases, associations represent asymmetrical ontological existence dependencies that dictate which of the two mutually inverse reference properties is the master. For instance, the authorship association between the classes Book and Author represents an ontological existence dependency of books on their authors. A book existentially depends on its author(s), while an author does not existentially depend on any of her books. Consequently, the corresponding object lifecycle dependency between Book and Author implies that their bidirectional association is maintained by maintaining Author references in Book::authors as the natural choice of master property, while Author::authoredBooks is the slave property, which is derived from Book::authors.

Since classical OO programming languages do not support explicit associations as first class citizens, but only classes with reference properties representing implicit associations, we have to eliminate all explicit associations for obtaining an OO class model.

2.4. The resulting OO class model

After replacing both bidirectional associations with reference properties, we obtain the following OO class model:

Figure 1.4. The OO class model

Since books are entities that existentially depend on authors and possibly on publishers, and not the other way around, it's natural to maintain the master references in book objects, and consider the inverse references in publisher and author objects as derived (or slave) data. Therefore, we define publishedBooks and authoredBooks as derived inverse reference properties, which is indicated by their slash prefix in the OO class model.

The starting point for making our JS class model is an OO class model with derived inverse reference properties like the following one:

Notice that the model contains two derived inverse reference properties: Publisher::/publishedBooks and Author::/authoredBooks. Each of them is linked to a master property, from which it is derived. Consequently, each of them represents a pair of mutually inverse reference properties corresponding to a bidirectional association.

The meaning of the OO class model can be illustrated by a sample data population for the three model classes involved:

Notice how Book records reference Publisher and Author records, and, vice versa, Publisher and Author records reference Book records.

Compared to making JS class models with unidirectional associations, the only new issue is:

This concerns the two derived inverse reference properties Publisher::/publishedBooks and Author::/authoredBooks. Thus, we get the following JavaScript class model:

The JS class model can be directly coded for getting the code of the model layer of our JavaScript frontend app.

class Publisher {
  constructor ({name, address}) {
    this.name = name;
    this.address = address;
    // derived inverse reference property
    this.publishedBooks = {};  // map of Book objects, inverse of Book::publisher
  }
  get name() {...}
  static checkName( n) {...}
  static checkNameAsId( n) {...}
  static checkNameAsIdRef( n) {...}
  set name( n) {...}
  get address() {...}
  static checkAddress( a) {...}
  set address( a) {...}
  toString() {...}
  toRecord() {...}
}

set publisher( p) {
  if (!p) {  // unset publisher
    delete this._publisher;
  } else {
    // p can be an ID reference or an object reference
    const publisher_id = (typeof p !== "object") ? p : p.name;
    const constraintViolation = Book.checkPublisher( publisher_id);
    if (constraintViolation instanceof NoConstraintViolation) {
      if (this.publisher) {
        // delete the obsolete inverse reference in Publisher::publishedBooks
        delete this.publisher.publishedBooks[ this.isbn];
      }
      // create the new publisher reference
      this._publisher = Publisher.instances[ publisher_id];
      // add the new inverse reference to Publisher::publishedBooks
      this.publisher.publishedBooks[ this.isbn] = this;
    } else {
      throw constraintViolation;
    }
  }
}

addAuthor( a) {
  // a can be an ID reference or an object reference
  const author_id = (typeof a !== "object") ? parseInt( a) : a.authorId;
  const validationResult = Book.checkAuthor( author_id);
  if (author_id && validationResult instanceof NoConstraintViolation) {
    // add the new author reference
    this._authors[author_id] = Author.instances[author_id];
    // automatically add the derived inverse reference
    this._authors[author_id].authoredBooks[this._isbn] = this;
  } else {
    throw validationResult;
  }
}

removeAuthor( a) {
  // a can be an ID reference or an object reference
  const author_id = (typeof a !== "object") ? parseInt( a) : a.authorId;
  const validationResult = Book.checkAuthor( author_id);
  if (validationResult instanceof NoConstraintViolation) {
    // automatically delete the derived inverse reference
    delete this._authors[author_id].authoredBooks[this._isbn];
    // delete the author reference
    delete this._authors[author_id];
  } else {
    throw validationResult;
  }
}

Book.destroy = function (isbn) {
  var book = Book.instances[isbn], keys=[], i=0;
  if (book) {
    console.log( book.toString() + " deleted!");
    if (book.publisher) {
      // remove inverse reference from book.publisher
      delete book.publisher.publishedBooks[isbn];      
    }
    // remove inverse references from all book.authors
    keys = Object.keys( book.authors);
    for (i=0; i < keys.length; i++) {
      delete book.authors[keys[i]].authoredBooks[isbn];
    }
    // finally, delete book from Book.instances
    delete Book.instances[isbn];
  } else {
    console.log("There is no book with ISBN " + isbn + " in the database!");
  }
};

In the UI code we can now exploit the inverse reference properties for more efficiently creating a list of inversely associated objects in the Retrieve/List All use case. For instance, we can more efficiently create a list of all published books for each publisher. However, we do not allow updating the set of inversely associated objects in the update object use case (e.g. updating the set of published books in the update publisher use case). Rather, such an update has to be done via updating the master objects (in our example, the books) concerned.

pl.v.publishers.retrieveAndListAll = {
  setupUserInterface: function () {
    const tableBodyEl = document.querySelector("section#Publisher-R>table>tbody");
    tableBodyEl.innerHTML = "";
    for (let key of Object.keys( Publisher.instances)) {
      const publisher = Publisher.instances[key];
      const row = tableBodyEl.insertRow(-1);
      // create list of books published by this publisher
      const listEl = util.createListFromMap( publisher.publishedBooks, "title");
      row.insertCell(-1).textContent = publisher.name;
      row.insertCell(-1).textContent = publisher.address;
      row.insertCell(-1).appendChild( listEl);
    }
    document.getElementById("Publisher-M").style.display = "none";
    document.getElementById("Publisher-R").style.display = "block";
  }
};

This project is based on the information design model below. The app from the previous assignment is to be extended by adding derived inverse reference properties for implementing the bidirectional associations. This is achieved by adding the multi-valued reference properties directedMovies and playedMovies to the model class Person, both with range Movie.

Figure 2.1. Two bidirectional associations between Movie and Person.

This project includes the following tasks:

You can use the following sample data for testing your app:

Make sure that your pages comply with the XML syntax of HTML5, and that your JavaScript code complies with our Coding Guidelines and is checked with JSHint.

If you have any questions about how to carry out this project, you can ask them on our discussion forum.