The work described in this paper has its origins in the MDBS database management system developed by Micro Data Base Systems, Inc., of Lafayette, Indiana. MDBS uses the CODASYL network data model, which is unusual for a microcomputer-based database management system.

Micro Data Base Systems also provides a stand-alone query/report language, QRS, for querying MDBS databases. QRS requires explicit path specification, which the authors of this paper feel is not compatible with ease-of-use. Also, QRS is a retrieve-only language.

To overcome these limitations, t`e authors developed the VIADUCT language. VIADUCT provides commands and menus for creating, maintaining, and listing MDBS databases. The language allows reference only to records and items (for example, “LIST TEACHER.NAME, SECTION.TITLE, STUDENT.NAME”). Reference to sets is not provided. (The terms “record,” “item,” and “set” are CODASYL terms.) If there is a single primary entry path to a specified record, it is used. (A primary entry path is one that is unique, or, that consists only of automatic and fixed or mandatory sets.) If multiple primary entry paths exist, VIADUCT will automatically choose the one that minimizes the number of record accesses. If no primary entry path exists, the user will be asked to choose one. It is in this sense that VIADUCT is “almost path-free.”

The bulk of the paper is devoted to a detailed description of the VIADUCT user interface and path-finding algorithms. The descriptions are clearly written and should be of value to persons developing end-user interfaces to CODASYL-type databases.

Although VIADUCT is characterized as a “very high-level” DML, it is actually at the same logical level as the CODASYL data model. It appears to be at a higher logical level because the CODASYL set construct is (normally) not visible to the end-user. The down-side of this strategy is that it prevents the user from using his or her knowledge of the relationships that exist in a database in order to make queries more precise or more efficient. The use of relationship information in queries is not, in the reviewer’s opinion, inconsistent with ease-of-use objectives, and need not (as is commonly assumed) expose the implementation or “structure” of the database to the user.