Papers in PDF format

Substituting the composer's name for the ComposerID would be a substantial improvement here. We saw no way of
automatically deducing which fields of a referenced table are meaningful for the reader of the web page. This
information has to be supplied by additional user input in the form of additional indexes on tables; existing alternate
unique indexes can help the user in this process, since these indexes usually are created on fields that describe an entry
in a way meaningful to a human reader. By entering additional indexes for tables the user can provide the HTML
generator with information on which fields are ``natural keys'' for that table i. e. the contents of those fields will identify
the entry to the user; e. g. in the table Composer, natural keys would be the columns which contain the composer's first
and last name. To give this information, the user would enter an additional index of type ``A'' (alternate). The generator
uses this information for the key expansion. This information is also used to create more meaningful titles of web pages
in the form of : .
In complex cases, the key expansion is done in several steps: the meta base table Relationships describes a network of
connections between tables in the application which is traversed by the generator using a graph algorithm until it arrives
at meaningful contents for hypertext fields.
6.3 Associative Entities
In the music database, the information on which artists participated in the recording of a piece is stored in a table
Performs. This table is an associative entity: it is neccessary for the implementation of the many-to-many relationship:
more than one artist can take part in a recording, and each artist can take part in more than one recording in a particular
role. However, the table Performs is not interesting in itself; the reader of the hypertext would prefer to perceive the
information only in the form of a list added to the Recording page: this list should directly state the artists taking part in
the recording plus their role, not the entries in the table Performs that reference this recording. The table Performs
should not be part of the hypertext system in the same way that Composer, Piece, Artist, Role and Recording are: we
want the information of artist participance in recordings, but we do not want a web page for each entry in the table
Performs.
If foreign keys are defined in the application, we can automatically deduce the information of whether an entity is an
associative entity and should be omitted: in our prototype no web pages are created for tables that consist only of
foreign keys.
Often information on foreign keys is not supplied within the RDBMS; our experience confirms what [Premerlani
&Blaha 1994] say: ``Finding candidate keys is easy, finding foreign keys is difficult.''
The declaration of foreign keys is often lacking for reasons of performance, or because legacy RDBMS did not support
the corresponding definitions. Additional user input (deriving from knowledge of the application domain) can clarify the
situation.
6.4 Groupings and Listings
Readability and accessability of our generated hypertexts have been significantly improved by the introduction of
groupings and listings which serve as entry points to sets of instance web pages [Fig. 2]. Hierarchical groupings and
ordered lists are defined by special index types (indicated in our meta base by ``G'' and ``L'', resp.). These have to input
by the user.
7 Future Work
During the development of our system, several topics have been postponed to future investigation. They fall into the two
areas of formatting and structural improvements:
7.1 Formatting Improvements
Treatment of long lists:
in cases where an entry in a parent table is referenced by many children, the list of the relationship can grow very