The starting point of our association elimination procedure is an information design model with various kinds of unidirectional and bidirectional associations, such as the model shown in Figure 1.1 above. If the model still contains any non-directed associations, we first have to turn them into directed ones by making a decision on the ownership of their ends, which is typically based on navigability requirements.

Notice that both associations in the Publisher-Book-Author information design model, publisher-publishedBooks and authoredBooks-authors (or Authorship), are bidirectional as indicated by the ownership dots at both association ends. For eliminating all explicit associations from an information design model, we have to perform the following steps:

A unidirectional association connecting a source with a target class is replaced with a corresponding reference property in its source class having the target class as its range. Its multiplicity is the same as the multiplicity of the target association end. Its name is the name of 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).

A bidirectional association, such as the authorship association between the classes Book and Author in the model shown in Figure 1.1 above, is replaced with a pair of mutually inverse reference properties, such as Book::authors and Author::authoredBooks. Since both reference properties represent the same information (the same set of binary relationships), it's an option to consider one of them being the "master" and the other one the "slave", which is derived from the master. We discuss the two cases of a one-to-one and a many-to-many association

After replacing both bidirectional associations with reference properties, we obtain the OO class model shown in 1.2.

Figure 1.2. The OO class model with two pairs of mutually inverse reference properties

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 meaning of this 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.

Consider the following table pairs representing the populations of the classes A and B where the columns A::id and B::id are primary keys and A::b_id and B::a_id are foreign keys referencing B, respectively A.

In which of the following cases does the property pair A::b_id and B::a_id implement a bidirectional association? Select one or more:

Representing a bidirectional association with a pair of mutually inverse reference properties implies (select one or many):

Consider the following information design model with a bidirectional association between the classes Aa and Bb.

Which of the following OO class models are correct representations of this model? Select one or more:

A bidirectional association Committee-isChairedBy-ClubMember between the classes Committee and ClubMember corresponds to ... (select one or more):

Compared to the unidirectional association app, we have to deal with a number of new technical issues:

Code each class of the JS class model as an ES6 class with implicit getters and setters:

These steps are discussed in more detail in the following sections.

For instance, the Publisher class from the JS class model is coded in the following way:

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

Notice that the (derived) multi-valued reference property publishedBooks has no setter method and is not assigned in the constructor function because it is a read-only property that is assigned implicitly when its inverse master reference property Book::publisher is assigned.

Any setter for a reference property that is coupled to a derived inverse reference property (implementing a bidirectional association), now also needs to assign (or add/remove) inverse references to (or from) the corresponding (collection) value of the inverse reference property. An example of such a setter is publisher in the Book class:

set publisher( p) {
  if (!p) {  // the publisher reference is to be deleted/unset
    // delete the inverse reference in Publisher::publishedBooks
    delete this._publisher.publishedBooks[ this._isbn];
    // unset the publisher property
    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 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;
    }
  }
}

For any multi-valued reference property that is coupled to a derived inverse reference property, both the add and the remove method also have to assign/add/remove corresponding references to/from (the value set of) the inverse property.

For instance, for the multi-valued reference property Book::authors that is coupled to the derived inverse reference property Author::authoredBooks for implementing the bidirectional authorship association between Book and Author, the Book::addAuthor method is coded in the following way:

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;
  }
}

For the remove operation removeAuthor we obtain the following code:

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;
  }
}

In the object-to-storage conversion of a publisher or author object with toJSON(), the derived properties Publisher::publishedBooks and Author::authoredBooks are not included since their information is redundant (derived from the Book::publisher and Book::authors properties). For instance, the Author::toJSON function is coded in the following way:

toJSON() {
  var rec = {};
  // loop over all Author properties
  for (const p of Object.keys( this)) {
    // keep underscore-prefixed properties except "_authoredBooks"
    if (p.charAt(0) === "_" && p !== "_authoredBooks") {
      // remove underscore prefix
      rec[p.substr(1)] = this[p];
    }
  };
  return rec;
}

When a Book instance b, with a single reference b.publisher to a Publisher instance p and multiple references b.authors to Author instances, is destroyed, depending on the chosen deletion policy (1) CASCADE or (2) DROP-REFERENCES, (1) the dependent Publisher instance and Author instances have to be deleted first or (2) the derived inverse references have to be removed first (e.g., by removing b from p.publishedBooks). We assume Existential Independence for both associated object types and, consequently, implement the DROP-REFERENCES policy:

Book.destroy = function (isbn) {
  const book = Book.instances[isbn];
  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
    for (const authorID of Object.keys( book.authors)) {
      delete book.authors[authorID].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!`);
  }
};

For showing information about published books in the Retrieve/List All publishers use case, we can now exploit the derived inverse reference property publishedBooks:

const tableBodyEl = document.querySelector("section#Publisher-R > table > tbody");
tableBodyEl.innerHTML = "";
for (const key of Object.keys( Publisher.instances)) {
  const publisher = Publisher.instances[key];
  const row = tableBodyEl.insertRow();
  // create list of books published by this publisher
  const publBooksListEl = createListFromMap( publisher.publishedBooks, "title");
  row.insertCell().textContent = publisher.name;
  row.insertCell().textContent = publisher.address;
  row.insertCell().appendChild( publBooksListEl);
}

The following addMember methods are supposed to be part of the JS class that implements the Committee class from the above class model. Which of the following methods is correct? Select one:

Maintaining the derived set of inverse references that form the collection value of the derived inverse reference property ClubMember::committees requires that ... (select one or more):

Which is the correct JS class model for the ClubMember class derived from the above model? Select one: