Altova MobileTogether Designer

Eine hierarchische Datenbank ist eine Datenbank mit einer Baumstruktur, in der jeder Node nur einen Parent (übergeordneten Node) hat. In MobileTogether wird die Baumstruktur von Seitenquellen anhand der Beziehungen zwischen Tabellen erstellt. Eine Beziehung zwischen zwei Datenbanktabellen ist entweder (i) in der Datenbank (mit Hilfe von Sekundärschlüsseln) oder (ii) in der Design-Datei (in der Definition der DB-Seitenquellenstruktur) definiert. Mit Hilfe von Beziehungen kann die Struktur der Seitenquelle flexibel definiert werden. So kann z.B. ein Autordatensatz untergeordnete Buchdatensätze haben. Alternativ dazu kann ein Buchdatensatz untergeordnete Autordatensätze haben. Die hierarchische Beziehung eignet sich gut zur Darstellung von Datensätzen im Design. So kann etwa ein Autordatensatz im Design als Tabellensteuerelement erstellt werden und die Buchdatensätze des Autors (aus einer anderen Datenbanktabelle) können als Zeilen dieses Tabellensteuerelements erstellt werden. (Beachten Sie in dieser Erläuterung die Unterscheidung zwischen den beiden Tabellenarten: Datenbanktabelle und Tabellensteuerelement.) Wenn die Daten dann wieder in der Datenbank gespeichert werden, werden sie gemäß der Beziehung zwischen den Datenbanktabellen in der entsprechenden Datenbanktabelle und in der entsprechenden Zeile dieser Datenbanktabelle gespeichert.

Die Datenbank für unser Tutorial hat zwei Tabellen, Authors und Books, mit den folgenden Spalten.

Die Tabelle Books ist mit der Tabelle Authors über die Spalte Books.AuthorID verknüpft. Diese Spalte bildet den Sekundärschlüssel der Tabelle Books. Durch Angabe der Zahl, die die entsprechende Authors.Author_ID des jeweiligen Autors in der Tabelle Authors darstellt, wird jedes Buch mit einem Autor verknüpft.

Wenn wir unsere DB-Seitenquelle im Design hinzufügen, können wir die Tabelle Authors als Haupttabelle auswählen und anschließend die Tabelle Books als damit verknüpfte Child-Tabelle definieren. Aufgrund der Sekundärschlüsselbeziehung in der Datenbank entsteht dadurch automatisch eine Hierarchie. Jeder Autor hat null oder mehr Bücher (als untergeordnete Datensätze) - diejenigen Bücherdatensätze in der Datenbank, die einen Sekundärschlüssel haben, der gleich dem der Author_ID des Autors ist. In der Abbildung unten sehen Sie die hierarchische Struktur der Seitenquelle \$BookCatalog.

Beachten Sie, dass jeder Author-Node in der obigen Struktur mehrere Book-Child Nodes haben kann, da (über den Sekundärschlüssel des Buchs) mehrere Bücher mit einem Autor verknüpft werden können. Der Node Book in der Seitenquelle repräsentiert alle Bücher, die zum übergeordneten Author Node gehören können. Der Node Author steht für alle Autoren in der Datenbank. Dadurch wird in der Baumstruktur eine Gliederung aus Author-Nodes mit ihren jeweiligen Book Children dargestellt.

Beachten Sie außerdem, dass der Sekundärschlüssel der Tabelle Books automatisch ausgeblendet wird, da der Sekundärschlüssel die Verknüpfung zwischen den Tabellen bildet und daher nicht geändert werden sollte.