Altova MobileTogether Designer

A hierarchical DB is one with a tree structure in which every node has only one parent. In MobileTogether, the relationships between tables are used to build the tree structure of page sources. A relationship between two DB tables is defined either (i) in the DB (through foreign keys) or (ii) in the design file (in the definition of the DB-page-source structure). The relationships can be used flexibly to define the structure of the page source. For example, an author record can have children book records. Alternatively, a book record can have children author records. The hierarchical relationship is useful when representing records  in the design. For example, an author record can be created as a table control in the design, and the author's book records (from another DB table) can be created as the rows of this table control. (Note the distinction between the two types of table in this discussion: DB table and table control.) Furthermore, when saving data back to the DB, the data is saved to the respective DB tables and to the correct rows of these DB tables according to the relationship between the DB tables.

In the DB for our tutorial, we have two tables, Authors and Books, with the following columns.

The Books table is related to the Authors table via the Books.AuthorID column, which is the Books table's foreign key. It links each book to an author by specifying the integer that is the appropriate Authors.Author_ID in the Authors table.

When we add our DB page source, we can select the Authors table as the main table and then specify the Books table as its related (child) table. This will automatically create a hierarchy because of the foreign key relationship in the DB. Each author will have zero or more book children—those book records in the DB that have a foreign key that is equal to that author's Author_ID. The hierarchical tree would be represented as in the screenshot below of our $BookCatalog page source.

In the above tree, note that each Author node can have multiple Book child nodes—because multiple books can be related to one author (via the book's foreign key). The Book node in the page source represents all the books that can belong to the parent Author node. The Author node represents all the authors in the DB. In this way, the tree describes a structure of Author nodes with their respective Book children.

Also note that the foreign key of the Books table is automatically hidden in the page source. This is because the foreign key is the link between the tables and should not be modified.