The basic procedure

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. The Publisher-Book-Author information design model with two bidirectional associations 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:

1. Eliminate unidirectional associations, connecting a source with a target class, by replacing them with a reference property in the source class such that the target class is its range.
2. Eliminate bidirectional associations by replacing them with a pair of mutually inverse reference properties.

How to eliminate unidirectional associations

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).

How to eliminate bidirectional associations

A bidirectional association, such as the authorship association between the classes Book and Author in the model shown in Figure 1-1. The Publisher-Book-Author information design model with two bidirectional associations 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

1. In the case of a bidirectional one-to-one association, this leads to a pair of mutually inverse single-valued reference properties, one in each of the two associated classes. Since both of them represent essentially the same information (the same collection of links/relationships), one has to choose which of them is considered the master property, such that the other one is the slave property, which is derived from the master property by inversion. In the class diagram, the slave property is designated as a derived property that is automatically updated whenever 1) a new master object is created, 2) the master reference property is updated, or 3) a master object is destroyed. This transformation is illustrated with the following example:

   

   

   

2. A bidirectional many-to-many association is mapped to a pair of mutually inverse multi-valued reference properties, one in each of the two classes participating in the association. Again, in one of the two classes, the multi-valued reference property representing the (inverse) association is designated as a derived property that is automatically updated whenever the corresponding property in the other class (where the association is maintained) is updated. This transformation is illustrated with the following example:

   

   

   

The resulting OO class model

After replacing both bidirectional associations with reference properties, we obtain the OO class model shown in 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.

New issues

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

1. We define the derived inverse reference properties, like Publisher::/publishedBooks, without a check operation and without a set operation.
2. We also have to take care of maintaining the derived inverse reference properties by maintaining the derived (sets of) inverse references that form the (collection) value of a derived inverse reference property. This requires in particular that
   1. whenever the value of a single-valued master reference property is initialized or updated (such as assigning a reference to a Publisher instance p to b.publisher for a Book instance b), an inverse reference has to be assigned (or added) to the corresponding value (set) of the derived inverse reference property (such as adding b to p.publishedBooks); when the value of the master reference property is updated and the derived inverse reference property is multi-valued, then the obsolete inverse reference to the previous value of the single-valued master reference property has to be deleted;
   2. whenever the value of an optional single-valued master reference property is unset (e.g. by assigning null to b.publisher for a Book instance b), the inverse reference has to be removed from the corresponding value of the derived inverse reference property (such as removing b from p.publishedBooks), if the derived inverse reference property is multi-valued, otherwise the corresponding value of the derived inverse reference property has to be unset or updated;
   3. whenever a reference is added to the value of a multi-valued master reference property (such as adding an Author reference a to b.authors for a Book instance b), an inverse reference has to be assigned or added to the corresponding value of the derived inverse reference property (such as adding b to a.authoredBooks);
   4. whenever a reference is removed from the value of a multi-valued master reference property (such as removing a reference to an Author instance a from b.authors for a Book instance b), the inverse reference has to be removed from the corresponding value of the derived inverse reference property (such as removing b from a.authoredBooks), if the derived inverse reference property is multi-valued, otherwise the corresponding value of the derived inverse reference property has to be unset or updated;
   5. whenever an object with a single reference or with multiple references as the value of a master reference property is destroyed (e.g., when a Book instance b with a single reference b.publisher to a Publisher instance p is destroyed), the derived inverse references have to be removed first (e.g., by removing b from p.publishedBooks).
   Notice that when a new object is created with a single reference or with multiple references as the value of a master reference property (e.g., a new Book instance b with a single reference b.publisher), the Book.add method will take care of creating the derived inverse references.

Coding Summary

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

1. Code the property checks in the form of class-level ('static') methods. Take care that all constraints of a property as specified in the JS class model are properly coded in the property checks.
2. For each single-valued property:
   1. In some setters, the corresponding property (non-asynchronous) check is invoked and the property is only set/unset, if the check does not detect any constraint violation; other (asynchronous) checks are invoked on the database operation (Create or Update), after form submission.
   2. If the concerned property is the inverse of a derived reference property (representing a bidirectional association), make sure to assigns/unsets the corresponding inverse reference to/from (the collection value of) the inverse property.
3. For each multi-valued property, code its add and remove operations, as well as the specified get/set operations:
   1. Code the add/remove operations as (instance-level) methods.
   2. Code the setter such that it invokes the add operation for each item of the collection to be assigned.
   3. If the concerned property is the inverse of a derived reference property (representing a bidirectional association), make sure to assign/unset (or add/remove) the corresponding inverse reference to/from (the collection value of) the inverse property.
4. Write the code of the serialization functions toFirestore and fromFirestore within the converter functions, for converting JS objects to a JS Firestore records/documents, or vice versa, with the derived properties publishedBooks and authoredBooks not included since their information is redundant (they are derived from the publisher and authors properties of books).
5. Take care of deletion dependencies in the destroy method. Make sure that when an object with a single reference (or with multiple references) as the value of a master reference property is destroyed, all referenced objects are destroyed as well or their (derived) inverse references are unset (or removed) first.

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

Code each class of the JS class model

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

class Publisher {
  // using a single record parameter with ES6 function parameter destructuring
  constructor ({name, address}) {
    // assign properties by invoking implicit setters
    this.name = name;
    this.address = address;
  };
  ...
  get name() {...}
  static checkName( n) {...}
  static checkNameAsId( n) {...}
  static checkNameAsIdRef( n) {...}
  set name( n) {...}
  get address() {...}
  static checkAddress( a) {...}
  set address( a) {...}
  get publishedBooks() {...}
}

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.

Code Create use case that handles derived inverse references properties

Any 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 single-valued and multi-valued references in a batch write transaction in the Book class for Create:

Book.add = async function (slots) {
  let book = null, validationResult = null;
  try {
    // validate data by creating Book instance
    book = await new Book( slots);
    // invoke asynchronous ID/uniqueness check
    validationResult = await Book.checkIsbnAsId( book.isbn);
    if (!validationResult instanceof NoConstraintViolation) throw validationResult;
    validationResult = await Publisher.checkNameAsIdRef( book.publisher_id);
    if (!validationResult instanceof NoConstraintViolation) throw validationResult;
    for (const a of book.authorIdRefs) {
      const validationResult = await Author.checkAuthorIdAsIdRef( String(a.id));
      if (!validationResult instanceof NoConstraintViolation) {
        throw validationResult;
      }
    }
  }
  ...
  if (book) {
    const bookDocRef = fsDoc( fsDb, "books", book.isbn)
        .withConverter( Book.converter),
      publishersCollRef = fsColl( fsDb, "publishers")
        .withConverter( Publisher.converter),
      authorsCollRef = fsColl( fsDb, "authors")
        .withConverter( Author.converter);
    const bookInverseRef = {isbn: book.isbn, title: book.title};
    try {
      const batch = writeBatch( fsDb); // initiate batch write object
      await batch.set( bookDocRef, book); // create book record (master)
      // iterate ID references (foreign keys) of slave class objects (authors) and
      // create derived inverse reference properties to master class object (book)
      // Author::authoredBooks
      await Promise.all( book.authorIdRefs.map( a => {
        const authorDocRef = fsDoc( authorsCollRef, String( a.id));
        batch.update( authorDocRef, {authoredBooks: arrayUnion( bookInverseRef)});
      }));
      if (book.publisher_id) {
        // create derived inverse reference properties between slave class objects
        // (publisher) with master class object (book) Publisher::publishedBooks
        const publisherDocRef = fsDoc( publishersCollRef, book.publisher_id);
        batch.update( publisherDocRef, {publishedBooks: arrayUnion( bookInverseRef)});
      }
      batch.commit(); // commit batch write
      console.log(`Book record "${book.isbn}" created!`);
    } catch (e) {
      console.error(`${e.constructor.name}: ${e.message}`);
    }
  }
};

Code Update use case that handles derived inverse references properties

For the Update case, several things happen sequentially. In the first block we initialize variables, and, in a try/catch block, we retrieve the data of the up-to-date book record/document (bookBeforeUpdate):

Book.update = async function ({isbn, title, publicationDate,
    publisher_id, authorIdRefsToAdd, authorIdRefsToRemove}) {
  let validationResult = null,
    bookBeforeUpdate = null;
  const bookDocRef = fsDoc( fsDb, "books", isbn).withConverter( Book.converter),
    updatedSlots = {};
  try {
    // retrieve up-to-date book record
    bookBeforeUpdate = (await getDoc( bookDocRef)).data();
  } catch (e) {
    console.error(`${e.constructor.name}: ${e.message}`);
  }
  ...

if (bookBeforeUpdate) {
  if (bookBeforeUpdate.title !== title) updatedSlots.title = title;
    if (bookBeforeUpdate.publicationDate !== publicationDate)
      updatedSlots.publicationDate = Timestamp.fromDate(new Date(
        publicationDate));
  if (publisher_id && bookBeforeUpdate.publisher_id !== publisher_id) {
    updatedSlots.publisher_id = publisher_id;
  } else if (!publisher_id && bookBeforeUpdate.publisher_id !== undefined) {
    updatedSlots.publisher_id = deleteField();
  }
  if (authorIdRefsToAdd) for (const authorIdRef of authorIdRefsToAdd)
    bookBeforeUpdate.addAuthor( authorIdRef);
  if (authorIdRefsToRemove) for (const authorIdRef of authorIdRefsToRemove)
    bookBeforeUpdate.removeAuthor( authorIdRef);
  if (authorIdRefsToAdd || authorIdRefsToRemove)
    updatedSlots.authorIdRefs = bookBeforeUpdate.authorIdRefs;
  ...
}

Take care of deletion dependencies

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, again in a batch write transaction:

Book.destroy = async function (isbn) {
  const bookDocRef = fsDoc( fsDb, "books", isbn)
      .withConverter( Book.converter),
    publishersCollRef = fsColl( fsDb, "publishers")
      .withConverter( Publisher.converter),
    authorsCollRef = fsColl( fsDb, "authors")
      .withConverter( Author.converter);
  try {
    const bookRec = (await getDoc( bookDocRef
      .withConverter( Book.converter))).data();
    const inverseRef = {isbn: bookRec.isbn, title: bookRec.title};
    const batch = writeBatch( fsDb); // initiate batch write object
    // delete derived inverse reference property, Authors::/authoredBooks
    await Promise.all( bookRec.authorIdRefs.map( aId => {
      const authorDocRef = fsDoc( authorsCollRef, String( aId.id));
      batch.update( authorDocRef, {authoredBooks: arrayRemove( inverseRef)});
    }));
    if (bookRec.publisher_id) {
      // create derived inverse reference property, Publisher::/publishedBooks
      const publisherDocRef = fsDoc( publishersCollRef, bookRec.publisher_id);
      batch.update( publisherDocRef, {publishedBooks: arrayRemove( inverseRef)});
    }
    batch.delete( bookDocRef); // create book record (master)
    batch.commit(); // commit batch write
    console.log(`Book record "${isbn}" deleted!`);
  } catch (e) {
    console.error(`Error deleting book record: ${e}`);
  }
};

Show published books in Retrieve/List All publishers

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 = pubRSectionEl.querySelector("table > tbody")
document.getElementById("RetrieveAndListAll").addEventListener("click", async function () {
  tableBodyEl.innerHTML = "";
  pubMSectionEl.hidden = true;
  pubRSectionEl.hidden = false;
  showProgressBar( "Publisher-R");
  const publisherRecs = await Publisher.retrieveAll();
  for (const publisher of publisherRecs) {
    const row = tableBodyEl.insertRow();
    row.insertCell().textContent = publisher.name;
    row.insertCell().textContent = publisher.address;
    // create list of books published by this publisher
    if (publisher.publishedBooks && publisher.publishedBooks.length) {
      const listEl = createListFromMap(publisher.publishedBooks, "title");
      row.insertCell().appendChild(listEl);
    }
  }
  hideProgressBar( "Publisher-R");
});