Subtyping and inheritance in OOP

The minimum level of support for subtyping in OOP, as provided, for instance, by Java and C#, allows defining inheritance of properties and methods in single-inheritance hierarchies, which can be inspected with the help of an is-instance-of predicate that allows testing if a class is the direct or an indirect type of an object. In addition, it is desirable to be able to inspect inheritance hierarchies with the help of

1. a predefined instance-level property for retrieving the direct type of an object (or its direct types, if multiple classification is allowed);
2. a predefined type-level property for retrieving the direct supertype of a type (or its direct supertypes, if multiple inheritance is allowed).

A special case of an OOP language is JavaScript, which did originally not have an explicit language element for defining classes, but only for defining constructor functions. Due to its dynamic programming features, JavaScript allows using various code patterns for implementing classes, subtyping and inheritance. In modern JavaScript, starting from ES2015, defining a superclass and a subclass is straightforward. First, we define a base class, Person, with two properties, firstName and lastName:

1
2
3
4
5
6
7

class Person {
  constructor (first, last) {
    // assign base class properties
    this.firstName = first; 
    this.lastName = last; 
  }
}

Then, we define a subclass, Student, with one additional property, studentNo:

1
2
3
4
5
6
7
8

class Student extends Person {
  constructor (first, last, studNo) {
    // invoke constructor of superclass
    super( first, last);
    // assign additional properties
    this.studentNo = studNo;
  }
}

Notice how the constructor of the superclass is invoked with super( first, last) for assigning the superclass properties.

Subtyping and inheritance with XML Schema

In XML Schema, a subtype can be defined by extending or by restricting an existing complex type. While extending a complex type means extending its intension by adding elements or attributes, restricting a complex type means restricting its extension by adding constraints. We can define a complex type Person and a subtype Student by extending Person in the following way:

1
2
3
4
5
6
7
8
9
10
11
12

<xs:complexType name="Person">
  <xs:attribute name="firstName" type="xs:string" />
  <xs:attribute name="lastName" type="xs:string" />
  <xs:attribute name="gender" type="GenderValue" />
</xs:complexType>

<xs:complexType name="Student">
  <xs:extension base="Person">
    <xs:attribute name="studentNo" type="xs:string" />
  </xs:extension>
</xs:complexType>

We can define a subtype FemalePerson by restricting Person in the following way:

1
2
3
4
5
6
7
8

<xs:complexType name="FemalePerson">
  <xs:restriction base="Person">
    <xs:attribute name="firstName" type="xs:string" />
    <xs:attribute name="lastName" type="xs:string" />
    <xs:attribute name="gender" type="GenderValue" 
        use="fixed" value="f" />
  </xs:restriction>
</xs:complexType>

Notice that by fixing the value of the gender attribute to "f", we define a constraint that is only satisfied by the female instances of Person.

Subtyping and inheritance with OWL

In the Web Ontology Language OWL, property definitions are separated from class definitions and properties are not single-valued, but multi-valued by default. Consequently, standard properties need to be declared as functional. Thus, we obtain the following code for expressing that Person is a class having the property name:

1
2
3
4
5
6

<owl:Class rdf:ID="Person"/>
<owl:DatatypeProperty rdf:ID="name">
    <rdfs:domain rdf:resource="#Person"/>
    <rdfs:range rdf:resource="xsd:string"/>
    <rdf:type rdf:resource="owl:FunctionalProperty"/>
</owl:DatatypeProperty>

OWL allows stating that a class is a subclass of another class in the following way:

1
2
3
4
5
6
7
8

<owl:Class rdf:ID="Student">
    <rdfs:subClassOf rdf:resource="#Person"/>
</owl:Class>
<owl:DatatypeProperty rdf:ID="studentNo">
    <rdfs:domain rdf:resource="#Student"/>
    <rdfs:range rdf:resource="xsd:string"/>
    <rdf:type rdf:resource="owl:FunctionalProperty"/>
</owl:DatatypeProperty>

For better usability, OWL should allow to define the properties of a class within a class definition, using the case of functional properties as the default case.

Representing class hierarchies with SQL database tables

A standard DBMS stores information (objects) in the rows of tables, which have been conceived as set-theoretic relations in classical relational database systems. The relational database language SQL is used for defining, populating, updating and querying such databases. But there are also simpler data storage techniques that allow to store data in the form of table rows, but do not support SQL. In particular, key-value storage systems, such as JavaScript's Local Storage API, allow storing a serialization of a JS entity table (a map of entity records) as the string value associated with the table name as a key.

While in the classical version of SQL (SQL92) there is no support for subtyping and inheritance, this has been changed in SQL99. However, the subtyping-related language elements of SQL99 have only been implemented in some DBMS, for instance in the open source DBMS PostgreSQL. As a consequence, for making a design model that can be implemented with various frameworks using various SQL DBMSs (including weaker technologies such as MySQL and SQLite), we cannot use the SQL99 features for subtyping, but have to model inheritance hierarchies in database design models by means of plain tables and foreign key dependencies. This mapping from class hierarchies to relational tables (and back) is the business of Object-Relational-Mapping frameworks such as JPA Providers (like Hibernate), Microsoft's Entity Framework, or the Active Record approach of the Rails framework.

There are essentially three alternative approaches how to represent a class hierarchy with database tables:

1. Single Table Inheritance (STI) is the simplest approach, where the entire class hierarchy is represented by a single table, containing columns for all attributes of the root class and of all its subclasses, and named after the name of the root class.
2. Table per Class Inheritance (TCI) is an approach, where each class of the hierarchy is represented by a corresponding table containing also columns for inherited properties, thus repeating the columns of the tables that represent its superclasses.
3. Joined Tables Inheritance (JTI) is a more logical approach, where each segment subclass is represented by a corresponding table (subtable) connected to the table representing its superclass (supertable) via its primary key referencing the primary key of the supertable, such that the (inherited) properties of the superclass are not represented as columns in subtables.

Notice that the STI approach is closely related to the Class Hierarchy Merge design pattern discussed in Section 1.5. The Class Hierarchy Merge Design Pattern above. Whenever this design pattern has already been applied in the design model, or the design model has already been re-factored according to this design pattern, the class hierarchies concerned (their subclasses) have been eliminated in the design, and consequently also in the data model to be coded in the form of class definitions in the app's model layer, so there is no need anymore to map class hierarchies to single tables. Otherwise, the design model contains a class hierarchy that is implemented with a corresponding class hierarchy in the app's model layer, which would be mapped to database tables with the help of the STI approach.

We illustrate the use of these approaches with the help of two simple examples. The first example is the Book class hierarchy, which is shown in Figure 1-1. The object type Book with two subtypes: TextBook and Biography above. The second example is the class hierarchy of the Person roles Employee, Manager and Author, shown in the class diagram in Figure 1-8. An information design model with a Person roles hierarchy below.

Single Table Inheritance

Consider the single-level class hierarchy shown in Figure 1-1. The object type Book with two subtypes: TextBook and Biography above, which is an incomplete disjoint segmentation of the class Book, as the design for the model classes of an MVC app. In such a case, whenever we have a model class hierarchy with only one level (or only a few levels) of subtyping and each subtype has only a few additional properties, it's preferable to use STI, so we model a single table containing columns for all attributes such that the columns representing additional attributes of segment subclasses ("segment attributes") are optional, as shown in the SQL table model in Figure 1-9. An SQL table model with a single table representing the Book class hierarchy below.

It is a common approach to add a special discriminator column for representing the category of each row corresponding to the subclass instantiated by the represented object. Such a column would normally be string-valued, but constrained to one of the names of the subclasses. If the DBMS supports enumerations, it could also be enumeration-valued. We use the name category for the discriminator column, which, in the case of our Book class hierarchy example, has a frozen value constraint since the textbook-biography segmentation is rigid.

Based on the category of a book, we have to enforce that if and only if it is "TextBook", its attribute subjectArea has a value, and if and only if it is "Biography", its attribute about has a value. This implied constraint is expressed in the invariant box attached to the Book table class in the class diagram above, where the logical operator keyword "IFF" represents the logical equivalence operator "if and only if". It needs to be implemented in the database, e.g., with an SQL table CHECK clause or with SQL triggers.

When the given segmentation is disjoint, a single-valued enumeration attribute category is used for representing the information to which subclass an instance belongs. Otherwise, if it is non-disjoint, a multi-valued enumeration attribute categories is used for representing the information to which subclasses an instance belongs. Such an attribute can be implemented in SQL by defining a string-valued column for representing a set of enumeration codes or labels as corresponding string concatenations.

Consider the class hierarchy shown in Figure 1-8. An information design model with a Person roles hierarchy above. With only three additional attributes defined in the subclasses Employee, Manager and Author, this class hierarchy can again be mapped with the STI approach, as shown in the SQL table model Figure Figure 1-10. An STI table model representing the Person roles hierarchy below.

Notice that now the discriminator column categories is multi-valued, since the segmentation of Person is not disjoint, but overlapping, implying that a Person object may belong to several categories. Notice also that, since a role segmentation (like Employee, Manager, Author) is not rigid, the discriminator column categories does not have a frozen value constraint.

An example of an admissible population for this model is the following:

Notice that the Person table contains four different types of people:

1. A person, Harry Wagner, who is both an author (with a biography) and an employee (with an employee number).
2. A person, Peter Boss, who is a manager (a special type of employee), managing the Sales department.
3. A person, Tom Daniels, who is neither an author nor an employee.
4. A person, Immanuel Kant, who is an author (with a biography).

Pros of the STI approach: It leads to a faithful representation of the subtype relationships expressed in the original class hierarchy; in particular, any row representing a subclass instance (an employee, manager or author) also represents a superclass instance (a person).

Cons: (1) In the case of a multi-level class hierarchy where the subclasses have little in common, the STI approach does not lead to a good representation. (2) The structure of the given class hierarchy in terms of its elements (classes) is only implicitly preserved.

Table per Class Inheritance

In a more realistic model, the subclasses of Person shown in Figure 1-8. An information design model with a Person roles hierarchy above would have many more attributes, so the STI approach would be no longer feasible. In the TCI approach we get the SQL table model shown in Figure 1-11. A TCI table model representing the Person roles hierarchy below. A TCI model represents each concrete class of the class hierarchy as a table, such that each segment subclass is represented by a table that also contains columns for inherited properties, thus repeating the columns of the table that represents the superclass.

A TCI table model can be derived from the information design model by performing the following steps:

1. Replacing the standard ID property modifier {id} in all classes with {pkey} for indicating that the standard ID property is a primary key.
2. Replacing the singular (capitalized) class names (Person, Author, etc.) with pluralized lowercase table names (people, authors, etc.), and replacing camel case property names (personId and empNo) with lowercase underscore-separated names for columns (person_id and emp_no).
3. Adding a «table» stereotype to all class rectangles.
4. Replacing the platform-independent datatype names with SQL datatype names.
5. Dropping all generalization/inheritance arrows and adding all columns of supertables (such as person_id and name from people) to their subtables (authors and employees).

Each table would only be populated with rows corresponding to the direct instances of the represented class. An example of an admissible population for this model is the following:

Pros of the TCI approach: (1) The structure of the given class hierarchy in terms of its elements (classes) is explicitly preserved. (2) When the segmentations of the given class hierarchy are disjoint, TCI leads to memory-efficient non-redundant storage.

Cons: (1) The TCI approach does not yield a faithful representation of the subtype relationships expressed in the original class hierarchy. In particular, for any row representing a subclass instance (an employee, manager or author) there is no information that it represents a superclass instance (a person). Thus, the TCI database schema does not inform about the represented subtype relationships; rather, this meta-information, which is kept in the app's class model, is de-coupled from the database. (2) The TCI approach requires repeating column definitions, which is a form of schema redundancy. (3) The TCI approach may imply data redundancy whenever the segment subclasses overlap. In our example, authors can also be employees, so for any person in the overlap, we would need to duplicate the data storage for all columns representing properties of the superclass (in our example, this only concerns the property name).

Joined Tables Inheritance

For avoiding the data redundancy problem of TCI in the case of overlapping segmentations, we could take the JTI approach as exemplified in the SQL table model shown in Figure 1-12. A JTI table model representing the Person roles hierarchy below. This model connects tables representing subclasses (subtables) to tables representing their superclasses (supertables) by defining their primary key column(s) to be at the same time a foreign key referencing their supertable's primary key. Notice that foreign keys are visualized in the form of UML dependency arrows stereotyped with «fkey» and annotated at their source table side with the name of the foreign key column.

An example of an admissible population for this model is the following:

Pros of the JTI approach: (1) Subtyping relationships and the structure of class hierarchies are explicitly preserved. (2) Data redundancy in the case of overlapping segmentations is avoided.

Cons: (1) The main disadvantage of the JTI approach is that for querying a subclass, join queries (for joining the segregated entity data) are required, which may create performance issues.

Make the JS class model

We make the JS class model in 3 steps:

1. Replace the platform-independent datatypes (used as the ranges of attributes and parameters) with JS datatypes. This includes the case of enumeration-valued attributes, such as category, which are turned into number-valued attributes restricted to the enumeration integers of the underlying enumeration type.
2. Decorate all properties with a «get/set» stereotype for indicating that they have implicit getters and setters.
3. Add property check functions, as described in Part 2 of this tutorial. The checkCategory function, as well as the checks of the segment properties need special consideration according to their implied semantics. In particular, a segment property's check function must ensure that the property can only be assigned if the category attribute has a value representing the corresponding segment. We explain this implied validation semantics in more detail below when we discuss how the JS class model is coded.

This leads to the JS class model shown in Figure 2-1. The JS class model of the merged Book class hierarchy, where the class-level ('static') methods are underlined:

New issues

Compared to the enumeration app discussed in Part 3 of this tutorial, we have to deal with a number of new issues:

1. In the model code we have to take care of
   1. Adding the constraint violation class FrozenValueConstraintViolation to errorTypes.js.
   2. Coding the enumeration type (BookCategoryEL in our example) to be used as the range of the category attribute . Coding the checkCategory function for the category attribute.
   3. In our example this attribute is optional, due to the fact that the Book segmentation is incomplete. If the segmentation, to which the Class Hierarchy Merge pattern is applied, is complete, then the category attribute is mandatory.
   4. Coding the check functions for all segment properties such that they take the category as a second parameter for being able to test if the segment property concerned applies to a given instance.
   5. Refining the serialization function toString() by adding a category case distinction (switch) statement for serializing only the segment properties that apply to the given category.
   6. Implementing the Frozen Value Constraint for the category attribute in Book.update by updating the category of a book only if it has not yet been defined. This means it cannot be updated anymore as soon as it has been defined.
2. In the UI code we have to take care of
   1. Adding a "Category" column to the display table of the "Retrieve/list all books" use case in books.html. A book without a special category will have an empty table cell, while for all other books their category will be shown in this cell, along with other segment-specific attribute values. This requires a corresponding switch statement in the books.js view code file.
   2. Adding a "Category" choice widget (typically, a selection list), and corresponding form fields for all segment properties, in the forms of the "Create book" and "Update book" use cases in books.html. Segment property form fields are only displayed when a corresponding book category has been selected. Such an approach of rendering specific form fields only on certain conditions is sometimes called dynamic forms.
   3. Disabling the "Category" selection field in the "Update book" use case, after selecting a book to be updated, if the selected book has a category value (in order to prevent any changes of the category attribute's value).

Code the model classes of the JS class model

The JS class model can be directly coded for getting the code of the model classes of our JS front-end app.

Summary

1. Code the enumeration type BookCategoryEL to be used as the range of the category attribute with the help of the meta-class Enumeration, as explained in Part 3 of this tutorial.
2. Code the model class Book in the form of a ES6 class definition with get and set methods as well as static check functions.

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

Code the enumeration type BookCategoryEL

The enumeration type BookCategoryEL is coded with the help of our library meta-class Enumeration at the beginning of the Book.js model class file in the following way:

1
2

BookCategoryEL = new Enumeration([ "Textbook", "Biography"]);

Code the model class Book

We code the model class Book in the form of an ES6 class definition where the category attribute as well as the segment attributes subjectArea and about are optional, with getters, setters and static check functions for all properties:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

class Book {
  constructor ({isbn, title, year, category, subjectArea, about}) {
    this.isbn = isbn;
    this.title = title;
    this.year = year;
    // optional properties
    if (category) this.category = category;
    if (subjectArea) this.subjectArea = subjectArea;
    if (about) this.about = about;
  }
  get isbn() {...}
  static checkIsbn( isbn) {...}
  static checkIsbnAsId( isbn) {...}
  set isbn( isbn) {...}
  get title() {...}
  static checkTitle( t) {...}
  set title( t) {...}
  get year() {...}
  static checkYear( y) {...}
  set year( y) {...}
  get category() {...}
  static checkCategory( c) {...}
  set category( c) {...}
  get subjectArea() {...}
  static checkSubjectArea( sA, cat) {...}
  set subjectArea( s) {...}
  get about() {...}
  static checkAbout( a, cat) {...}
  set about( a) {...}
}

Notice that the constructor function is defined with a single record parameter using the ES6 syntax for function parameter destructuring.

We code the checkCategory and setCategory methods for the category attribute in the following way:

1
2
3
4
5
6
7
8
9
10
11

static checkCategory( c) {
  if (c === undefined || c === "") {
    return new NoConstraintViolation();  // category is optional
  } else if (!isIntegerOrIntegerString(c) || parseInt(c) < 1 ||
      parseInt(c) > BookCategoryEL.MAX) {
    return new RangeConstraintViolation(
        "Invalid value for category: "+ c);
  } else {
    return new NoConstraintViolation();
  }
};

1
2
3
4
5
6
7
8
9
10
11
12
13
14

set category( c) {
  var validationResult = null;
  if (this.category) {  // already set/assigned
    validationResult = new FrozenValueConstraintViolation(
        "The category cannot be changed!");
  } else {
    validationResult = Book.checkCategory( c);
  }
  if (validationResult instanceof NoConstraintViolation) {
    this._category = parseInt( c);
  } else {
    throw validationResult;
  }
}

While the getters for segment properties (in this example: subjectArea and about) follow the standard pattern, their checks and setters have to make sure that the property applies to the category of the instance being checked. This is achieved by checking a combination of a property value and a category, as in the following example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

static checkSubjectArea( sA, c) {
  if (c === BookCategoryEL.TEXTBOOK && !sA) {
    return new MandatoryValueConstraintViolation(
        "A subject area must be provided for a textbook!");
  } else if (c !== BookCategoryEL.TEXTBOOK && sA) {
    return new ConstraintViolation("A subject area must not " +
        "be provided if the book is not a textbook!");
  } else if (sA && (typeof(sA) !== "string" || sA.trim() === "")) {
    return new RangeConstraintViolation(
        "The subject area must be a non-empty string!");
  } else {
    return new NoConstraintViolation();
  }
} 

In the serialization function toString, we serialize the category attribute and the segment properties in a switch statement:

1
2
3
4
5
6
7
8
9
10
11
12

toString() {
  var bookStr = `Book{ ISBN: ${this.isbn}, title: ${this.title}, year: ${this.year}`;
  switch (this.category) {
    case BookCategoryEL.TEXTBOOK:
      bookStr += `, textbook subject area: ${this.subjectArea}`;
      break;
    case BookCategoryEL.BIOGRAPHY:
      bookStr += `, biography about: ${this.about}`;
      break;
  }
  return bookStr + "}";
};

In the update method of a model class, we only set a property if it is to be updated, that is, if there is a corresponding argument slot with a value that is different from the old property value. In the special case of a category attribute with a Frozen Value Constraint, we need to make sure that it can only be updated, along with an accompanying set of segment properties, if it has not yet been assigned. Thus, in the Book.update method, we perform the special test if book.category === undefined for handling the special case of an initial assignment, while we handle updates of the segment properties subjectArea and about in a more standard way:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

Book.update = function ({isbn, title, year, 
    category, subjectArea, about}) {
  const book = Book.instances[isbn],
        objectBeforeUpdate = cloneObject( book);
  var noConstraintViolated=true, updatedProperties=[];
  try {
    ...
    if (category && book.category !== category) {
      book.category = category;
      updatedProperties.push("category");
    } else if (category === "" && "category" in book) {
      throw FrozenValueConstraintViolation(
          "The book category cannot be unset!");
    }
    if (subjectArea && book.subjectArea !== subjectArea) {
      book.subjectArea = subjectArea;
      updatedProperties.push("subjectArea");
    }
    if (about && book.about !== about) {
      book.about = about;
      updatedProperties.push("about");
    }
  } catch (e) {
    ...
  }
  ...
};

Write the User Interface Code

The app's user interface (UI) consists of a start page that allows navigating to data management pages (in our example, to books.html). Such a data management page contains 5 sections: manage books, list and retrieve all books, create book, update book and delete book, such that only one of them is displayed at any time (by setting the CSS property display:none for all others).

Summary

We have to take care of handling the category attribute and the segment properties subjectArea and about both in the "Retrieve and list all books" use case as well as in the "Create book" and "Update book" use cases by

1. Adding a segment information column (with heading "Category") to the display table of the "Retrieve and list all books" use case in books.html.
2. Adding a "Category" selection field, and input fields for all segment properties, in the user interfaces of the "Create book" and "Update book" use cases in books.html. The form fields for segment properties are only displayed, when a corresponding book category has been selected.

Add a segment information column in Retrieve/List All

We add a "Category" column to the view table of the "Retrieve/list all books" use case in books.html:

1
2
3
4
5
6

<table id="books">
  <thead><tr>
   <th>ISBN</th><th>Title</th><th>Year</th><th>Category</th>
  </tr></thead>
  <tbody></tbody>
</table>

A book without a special category will have an empty table cell in this column, while for all other books their category will be shown in this column, along with other category-specific information. This requires a corresponding switch statement in the v/books.js file:

1
2
3
4
5
6
7
8
9
10

if (book.category) {
  switch (book.category) {
  case BookCategoryEL.TEXTBOOK:
    row.insertCell().textContent = book.subjectArea + " textbook";
    break;
  case BookCategoryEL.BIOGRAPHY: 
    row.insertCell().textContent = "Biography about "+ book.about;
    break;
  }
}

Add a category selection field in Create and Update

In both use cases, we need to allow selecting a special category of book ('textbook' or 'biography') with the help of a selection field, as shown in the following HTML fragment:

1
2
3
4
5
6
7
8
9

<div class="field">
 <label>Category: <select name="category"></select></label>
</div>
<div class="field Textbook"><!-- conditional field -->
 <label>Subject area: <input type="text" name="subjectArea" /></label>
</div>
<div class="field Biography"><!-- conditional field -->
 <label>About: <input type="text" name="about" /></label>
</div>

Notice that we have added "Textbook" and "Biography" as additional values of the class attribute of the segment field container elements. This supports the rendering and un-rendering of "Textbook" and "Biography" form fields, depending on the value of the category attribute.

In the handleCategorySelectChangeEvent handler, segment property form fields are only displayed, with displaySegmentFields, when a corresponding book category has been selected:

1
2
3
4
5
6
7
8
9
10
11

handleCategorySelectChangeEvent = function (e) {
  const formEl = e.currentTarget.form,
        // the array index of BookCategoryEL.labels
        categoryIndexStr = formEl.category.value;
  if (categoryIndexStr) {
    displaySegmentFields( formEl, BookCategoryEL.labels,
        parseInt( categoryIndexStr) + 1);
  } else {
    undisplayAllSegmentFields( formEl, BookCategoryEL.labels);
  }
};

Recall that the category selection list contains a no-selection option "---" with the empty string as its return value, and a list of options formed by the enumeration labels of BookCategoryEL.labels such that their value is the corresponding array index (starting with 0) as a string. Consequently, the variable categoryIndexStr has either the value "" (empty string) or one of "0", "1", "2", etc.

Make a JS class model

We design the model classes of our example app with the help of a JS class model that we derive from the design model by essentially leaving the generalization arrows as they are and just adding get/set methods and static check functions to each class. However, in the case of our example app, it is natural to apply the Class Hierarchy Merge design pattern (discussed in Section 1.5. The Class Hierarchy Merge Design Pattern) to the single-subclass-segmentation of Employee for simplifying the class model by eliminating the Manager subclass. This leads to the model shown in Figure 2-2. The JS class model of the Person roles class hierarchy below. Notice that a Person may be an Employee or an Author or both.

Make a JS entity table model

Since we use the browsers' Local Storage as the persistent storage technology for our example app, we have to deal with simple key-value storage. For each design model class with a singular (capitalized) name Entity, we use its pluralized lowercase name entities as the corresponding table name.

We design a set of suitable JS entity tables in the form of a JS entity table model that we derive from the information design model. We have to make certain choices how to organize our data store and how to derive a corresponding entity table model.

The first choice to make concerns using either the Single Table Inheritance (STI), the Table per Class Inheritance (TCI) or the Joined Tables Inheritance (JTI) approach, which are introduced in . In the STI approach, a segmentation (or an entire class hierarchy) is represented with a single table, containing columns for all attributes of all classes involved, as shown in the example model of Figure 2-3. An STI model of the Person roles class hierarchy.

Since the given segmentation is non-disjoint, a multi-valued enumeration attribute categories is used for representing the information to which subclasses an instance belongs.

Using the STI approach is feasible for the given example, since the role hierarchy does not have many levels and the segment subclasses do not add many attributes. But, in a more realistic example, we would have a lot more attributes in the segment subclasses of the given role hierarchy. The STI approach is not really an option for representing a multi-level role hierarchy. However, we may choose it for representing the single-segment class hierarchy Manager-is-subclass-of-Employee.

For simplicity, and because the browsers' Local Storage does not support foreign keys as required by JTI, we choose the TCI approach, where we obtain a separate table for each class of the Person segmentation, but without foreign keys. Our choices result in the model shown in Figure 2-4. A TCI model of the Person roles class hierarchy below, which has been derived from the design model shown in Figure 1-8. An information design model with a Person roles hierarchy by

1. Merging the Manager subclass into its superclass Employee, according to the Class Hierarchy Merge design pattern described in Section 1.5. The Class Hierarchy Merge Design Pattern.
2. Replacing the standard ID property modifier {id} of the personId attribute of Person, Author and Employee with {pkey} for indicating that the attribute is a primary key.
3. Replacing the singular (capitalized) class names (Person, Author and Employee) with pluralized lowercase table names (people, authors and employees).
4. Adding the «JS entity table» stereotype to all class rectangles (people, authors and employees).
5. Replacing the platform-independent datatype names with JS datatype names.
6. Dropping all generalization/inheritance arrows and adding all attributes of supertables (personId and name) to their subtables (authors and employees).

In the case of using the JTI approach, we would also take the steps 1-5 above, but instead of step 6, we would

7. Copy the primary key column (personId) of the root table (people) to all subtables (authors and employees).
8. Replace the generalization arrows with «fkey»-stereotyped dependency arrows (representing foreign key dependencies) that are annotated at their source end with the name of the subtable's primary key (here: personId).

New issues

Compared to the model of our first case study, shown in Figure 2-1. The JS class model of the merged Book class hierarchy above, we have to deal with a number of new issues in the model code:

1. Defining the subclass relationships between Employee and Person, as well as between Author and Person, using the JS keyword extends discussed in Section 2.1. Subtyping with ES6 Classes.
2. When loading the instances of the root class (Person.instances) from persistent storage (in Person.retrieveAll), we load (1) the records of the table representing the root class (people) for creating its direct instances and (2) also the records of all other tables representing its subclasses (authors and employees) for creating their direct instances, while also adding their object references to the root class population (to Person.instances). In this way, the root class population does not only contain direct instances, but all instances.
3. When saving the instances of Employee and Author as records of the JS entity tables employees and authors to persistent storage in Employee.saveAll and Author.saveAll (invoked in employees.js and authors.js), we also save the direct instances of Person as records of the people table.

Code the model classes of the JS class model

The JS class model shown in Figure 2-2. The JS class model of the Person roles class hierarchy above can be directly coded for getting the code of the model classes Person, Employee and Author as well as for the enumeration type EmployeeCategoryEL.

Defining subtype relationships

In the case of a superclass like Person, we define a class-level property subtypes for having a mechanism to loop over all subtypes of a superclass.

1
2

class Person {...} 
Person.subtypes = [];

The property subtypes holds a list of all subtypes of the given class. This list is initially empty.

The subtype relationships between the classes Employee and Person, as well as between Author and Person, are defined with the help of the ES6 keywords extends and super. For instance, in m/Author.js we define:

1
2
3
4
5
6
7
8
9
10
11
12

class Author extends Person {
  constructor ({personId, name, biography}) {
    super({personId, name});  // invoke Person constructor
    // assign additional properties
    this.biography = biography;
  }
  get biography() {return this._biography;}
  set biography( b) {this._biography = b;}  /***SIMPLIFIED CODE: no validation ***/
  toString() {...}
}
// add Author to the list of Person subtypes
Person.subtypes.push( Author);

Loading the instances of a root class

When retrieving the instances of a class hierarchy's root class (in our example, Person) from a persistent data store organized according to the TCI approach, we have to retrieve not only its direct instances from the table representing the root class (people), but also all indirect instances from all tables representing its subclasses (employees and authors), as shown in the following code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Person.retrieveAll = function () {
  var people = {};
  if (!localStorage["people"]) localStorage["people"] = "{}";
  try {
    people = JSON.parse( localStorage["people"]);
  } catch (e) {
    console.log("Error when reading from Local Storage\n" + e);
  }
  for (const key of Object.keys( people)) {
    try {  // convert record to (typed) object
      Person.instances[key] = new Person( people[key]);
    } catch (e) {
      console.log(`${e.constructor.name} ...`);
    }
  }
  // add all instances of all subtypes to Person.instances
  for (const Subtype of Person.subtypes) {
    Subtype.retrieveAll();
    for (const key of Object.keys( Subtype.instances)) {
      Person.instances[key] = Subtype.instances[key];
    }
  }
  console.log(`${Object.keys( Person.instances).length} records loaded`);
}

For any subtype (here, Author and Employee), each record is retrieved and a corresponding entry is created in the map Subtype.instances and copied to Person.instances.

Saving the subtables when saving a supertable

Since the app's data is kept in main memory as long as the app is running (which is as long as the app's webpage is kept open in the browser), the data has to be saved to persistent storage when the app is terminated (e.g., by closing its browser tab). When saving the instances of Person (as records of the people table) to persistent storage in v/people.js, we also save the direct instances of ist subtypes Employee and Author (as records of the JS entity tables employees and authors in v/employees.js and v/authors.js). This is necessary because changes to Person instances may imply changes of Employee or Author instances.

We do this in v/people.js:

1
2
3
4
5
6
7
8

// save data when leaving the page
window.addEventListener("beforeunload", function () {
  Person.saveAll();
  // save all subtypes for persisting changes of supertype attributes
  for (const Subtype of Person.subtypes) {
    Subtype.saveAll();
  }
});

Take care of subtypes in the UI

The view table created in the use case "Retrieve/list all people" is to show the roles "author" or "employee" of each person in a special column "Role(s)".

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

document.getElementById("RetrieveAndListAll")
    .addEventListener("click", function () {
  ...
  for (const key of Object.keys(Person.instances)) {
    const person = Person.instances[key];
    const row = tableBodyEl.insertRow();
    const roles = [];
    row.insertCell().textContent = person.personId;
    row.insertCell().textContent = person.name;
    for (const Subtype of Person.subtypes) {
      if (person.personId in Subtype.instances) roles.push( Subtype.name);
    }
    row.insertCell().textContent = roles.toString();
  }
});

Notice that since the class Employee has the subtype Manager, it would be desirable to see the role "manager" for any person being an instance of Employee with a category value of EmployeeCategoryEL.MANAGER. However, for simplicity, this is not implemented in the model app.

Question 1: Abc

The purpose of the app.

Question 2: Abc

The purpose of the app.

Question 3: Abc

The purpose of the app.

Question 5: Abc

The purpose of the app.