NOAH(ID:5593/noa001)

Network query language featuring inheritance 

network query language

Featured polymorphic and inherited values
References:
  • Schlageter, G.; Rieskamp, M.; Prädel, U.; Unland, R. "The network query language NOAH" view details Abstract: A non-procedural query language for network databases is described. The language is very powerful as compared to other implemented languages. It allows to formulate complex queries which, among other things, include conditions for CODASYL-sets and conditions for n:m-relationships. Cyclic database structures can be processed to some extent.Note: This report is not written for the "naive" user of NOAH, and is not meant to replace a NOAH manual. Instead, this report describes the foundations, the underlying concepts, and the structure of the language in more theoretically oriented, technical terms.This research was performed at the university of Hagen, West Germany, and was partially supported by Triumph Adler AG, Nürnberg, West Germany. Abstract: INTRODUCTION

    While query languages for relational database systems have been studied intensively and with great success, there is only a small number of investigations on query languages for network-oriented databases. The reason for this is obviously the conceotual simplicitv of the relational data model, which iends ;tself in a very natural way to set-oriented higher level query languages. The network data model is, by its very nature, oriented towards the navigational user, and is therefore a comparatively poor basis for set-oriented language.

    An end-user language should certainly not be navigational on a record at-a-time level. On the other hand it is, in most cases, very difficult to support a fully relational view upon a network database (this approach was discussed in [ZA79]). Thus, the question is what type of higher-level language a network database system could offer in order to make the database accessible in an easier way for thosepersons who are not programmers but do understand the semantics of the database sufficiently to ask reasonable questions.

    In this paper we describe a language called NOAH, which is an effort to make network databases of the CODASYL-type accessible for non-programmers in an ad-hoc fashion. The data model as seen by the user remains the network model, but he has no longer to navigate on a record-at-a-time basis. NOAH allows to express complex queries in a non-procedural way. In no case the user is concerned with the intricacies of programming in network-DML, such as currency and looping. There is no resort to procedural constructs in order to enhance the power of the language. The effort was not to produce a language as powerful as possible, but to produce an easy to use, reasonably powerful language which can be supported on a small system. An implementation of NOAH has been done for the CODASYL database system of Triumph Adler, which runs on a 16-bit minicomputer.

    NOAH offers in an integrated way several levels of complexity. The unexperienced user may begin to work with the database system using very simple query features only; the more experienced user mav make use of more powerful constructs. All features are based on a consistent keyword-oriented syntax. The paper is organized as follows: we first describe the general philosophy and the main concepts of NOAH. then illustrate the lanquaqe by a series of examples of increasing complexity, and conclude with some remarks on the merits and weaknesses of the approach.     
    Abstract: DATA MODEL AND USER
    NOAH is a query language for network databases of the CODASYL type [CO71, CO78]. The data are modelled by record types and set types, where a set type represents a l:n-relationship from the owner record type to the member record type.

    An essential feature of the network data model is that set types do not only represent logical access paths but may be information bearing. For instance, there may be two set types between PROFESSOR and STUDENT: - one set type connecting a professor to his master degree students - one set type connecting a professor to his PhD students.

    The record types and set types may be defined such that the removal of a set type is not possible without loss of information, e.g., which students are PhD students of which professor.

    Any query which requires data of professors and the related students, has to indicate the set type to be exploited. This is not a burden for the user which should be avoided, but reflects the fact that a user - regardless of the query language - must understand the semantics of the data in order to ask reasonable queries. The set types, however, are part of the semantics of a network database. Hence, a query language for CODASYL-type systems which tries to eliminate the set concept from the users view, is not realizable for conceptual reasons.

    Languages which tried to do this had to resort to one of two solutions: either the user had to resolve the detected ambiguities (which again means that he hti to understand the semantics of the set types) or one restricted the schemas or the queries in a severe way. The only way to eliminate the set concept from the users view would be to build a non-network interface on top of the network database. Apart from the general difficulties of this approach, the overhead would be enormous, and certainly not bearable in a minicomputer database system.

          in Proceedings of the 1982 ACM SIGMOD International Conference on Management of Data (Orlando, Florida, June 1982) view details