The Network Query Language NOAH

deposit_hagen

Publikationsserver der Universitätsbibliothek

Mathematik und

Informatik

Informatik-Berichte 22 – 12/1981

The Network Query Language NOAH

THE NETWORK QuERY LANGUAGE

NOAH

M. Rieskamp, G. Schlageter, U. Prädel, R. Unland University of Hagen

Postfach 940 5800 Hagen Germany West

Abstract

A non-procedural query 1anguage 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.

have been studied intensively and with great success, there is only a small number of investigations on query languages for network-oriented databases-

/TSI 76, DEH 76, QL 77, IQS 79 , HOU 79/. The reason for this is obviously the conceptual simplicity o f t h e r_e 1 a t i o n a 1 da t a m o de l , w h i c h l end s i t s e l f i n 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 languages.

An end-user language should certainly not be naviga- tional 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 /ZAN79/). Thus, the question is what type of higher-level language a network data- base system could offer in order to make the database accessible in an easier way for those persons 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 i s a n e ff o r t t o m a k e n e t w o r k d a t a b a se·s o f t h e C O DAS Y L - t y p e 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 langer 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 con- cerned 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.

- 2 -

- 2 -

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 may 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 language by a series of examples of increasing complexity, and conclude with some remarks on the merits and weaknesses of the approach.

2,

DATA MODEL AND USER

NOAH is a query language for network databases of the CODASYL type /CO71, CO78/. The data are modelled by ~eco~d type~ and ~et type~, where a set type

represents a 1: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:

- 3 -

- 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

tobe 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 ha~ 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.

- 4 -

- 4 -

-

3,

BASIC CONCEPTS OF

NOAH

To formulate a query the user proceeds as follows:

(1) He specifies the search path, i .e. the database subschema relevant to the query. The main

semantical function of the search path is that it specifies the sequence in which sets of records are tobe associated one with each other. For instance: The user is interested

in universities andin professors associated with these, and so on.

(2) He specifies the conditions which must be met before records (from the record types in the search path) are selected.

(3) He specifies the data tobe output (printed, displayed) from the s~lected records.

This procedure describes in general terms the

philosophy of NOAH. In the sequel, we will discuss the basic concepts of the language in more detail.

SEARCH PATH

The user wishes to get information which may be contained in different records and sets of the

database. He specifies a ~ea~Qh path for his query, which is a description of the database structure

(record types and set types) relevant to the query, and a specification of the sequence in which sets of records are tobe associated one with each other via sets. The search path is a connected part of the overall database structure (some restrictions are imposed).

Together with a record r all data of the owners of r (in all sets where r is a member) are available.

A simple naming convention has tobe applied to

exploit this feature. This is not of interest for the moment but for the fact that one may see a record as a schema record extended by the data of its owners.

The search path is defined as [S

0 ] R

0,

s

1R1, ... , SnRn' where R; are record types and S; are set types which connect record types of the search path. S;R;- means:

record type Ri is connected via set type S; to some Rj specified in the search path before R;

(Rj is uniquely defined by Si): R; may be member or owner in Si. S

0 is a singular set type; the details are not of interest here. No R; may appear twice in the search path, i.e. cycles are not

allowed. l) (Nevertheless the processing of cycles is possible to some extent by the use of the

inheritance concept explained later.)

The search path defines the data -0paee of interest.

This data space contains each r

0 E R

0 2 ), together with each r; ER; related to r

0 via a sequence of sets as specified in the search path. If no r. ER.

,

^.

,

is related to a given r

0 , this r

0 and the other records related to it nevertheless belang to the data space of interest.

l) The reason for not allowing cycles is the following: let R, ••• , R be a cycle in the search path, and let the user specify that he wishes to see the value of R.X. In this case i t is not clear which one of the records

2)

r, r' (r, r' ER) is rneant. Of course, there are solutions to this problern, but the overhead to implernent a general solution was considered too high for a small database system. Irnplemented query languages we know of do not allow the processing of cycles at all.

In case of a singular set type S only those r

0 0

belonging to the set of type S .

0

- 6 -

Note that in CODASYL-based systems a search path R₀^,

s

1 R1 in general has a different meaning and produces different results from R1,

s

₁ R

0• This

is due to the fact that sets are partial functions;

in the example, there may be r

1 ^E R

1 not connected to r

0 E R

0, such that, coming from R

0, not all

r 1 ^E R1 are reached, whereas starting from R1, all r 1 but possibly not all r

0 are reached.

We consider the data space to consist of a set of -0ea~eh path oeeu~~enee-0, where a search path

occurrence is constructed as follows: select some r₀; if Ri is related to R₀ via Si in the search path definition, then select one ri related to r₀ (if one exists); if Rj is related to Ri via Sj' select one of the rj related to r;, etc. That is, we pick up a set of records, including one r

0 and

at most one record from each other type, interconnected via sets of the types specified in the search path.

A search path occurrence is maximal, that is if SPO = {r

0, r;, ... } is a search path occurrence, and there is no record rj E Rj in SPO, then no record rj exists which could be added to SPO according to the given construction rule.

The conditions for sets and records, specified in different clauses, define which of the search path occurrences in the data space are valid, i .e. contain the data we are looking for:

- 7 -

The set of search path occurrences is first restricted by the ~et condition~. A set condition specifies,

for instance, that a set of type S =(R1,R2)1

) rnust have five members. This means that a search path occurrence SPO ⁼ {r

0, ••• , r 1, o•., r 2, ... } can only be a valid occurrence, if r

1, r2 are taken from a set of type S which has five members.

The set of search path occurrences is then further restricted by the ~eco~d condition~. A record

condition rnay be DEPARTMENT.NAME ^{= 11} COMPUTER-SCIENCE¹¹

SEMANTICS OF A NOAH QUERY

The semantics of a NOAH query is as follows:

(1) Unless specified otherwise by set conditions, only those search path occurrences can be valid which contain one record for each record type;

(2) tobe valid, the set conditions and record conditions must be satisfiedo

That is, if no condition for records or sets is specified, those search path occurrences are valid which contain one record for each record type in the search path definitiono

One may release the existential quantifier on each

R;

expressed by rule (1): One can declare some R; (i ^-1: o) tobe ¹¹optional ^{11 ,} such that search path occurrences may be valid which do not contain

a ri ER;· This is expressed by explicitly allowing a set tobe empty. All conditions applicable to these search path occurrences must be satisfied;

1 ) S = (R1, R2 ): set type with ownertype R1 and membertype ·R

2.

- 8 -

- 8 -

the conditions not applicable because of the missing ri are neglected. Of course, if Rj can be reached from R

0 only via Ri' then in this case no rj is in the search path occurrence, etc.

According to the outlined approach a NOAH query consists of four building blocks:

(1) Search path (2) Set conditions (3) Record conditions

(4) Select clause (specification of the values

which are to be displayed from each search path occurrence)

An optional fifth clause provides limited formatting facilities.

EXAMPLE

For an example consider the search path

UNIVERSITY, SUD DEPARTMENT, SDP PROFESSOR UNIVERSITY

SUD DEPARTMENT

SDP PROFESSOR

If no conditions are specified, a valid occurrence of this search path is any tuple (u,d,p), where u is a university record, d is a record of a department of this university, and p is the record of a professor of this department. Thus, if the NOAH query is

PATH UNIVERSITY, SUD DEPARTMENT, SDP PROFESSOR SELECT UNIVERSITY.NAME, DEPARTMENT.NAME

all tuples (university.name, department.name) are displayed for those universities and departments which have a professor.

!f we are also interested in those universities and departments which (let that be possible for a moment) have no professors, we would specify a set conditions

SETCOND SET SOP COUNT~ O.

Of course, in this example, if we omit SOP PROFESSOR from the search path we get the same result. If the output additionally is PROFESSOR.NAME then the difference is more obvious: without COUNT~ 0 we get all tuples (u,d,p), but with COUNT l O we also get the tuples (u,d) for those d which have no professor.

A condition for SOP might be

11the department must have five professors^{11 ,}

which means that the SOP-set must have five members.

If the SOP-set of a given department d' has five members p

1, ..• , p5, then each of the tuples (u,d',p

1), ... , (u,d',Ps) is a valid search path occurrence; if n -j, 5, then no tuple (u,d' ,p) is valid. Thus, NOAH allows to ask a query of the type

11 find universities with a computer science department with five professors and list name of university and name of department^{11 •}

This query would be written in NOAH as follows:

PATH UNIVERSITY, SUD OEPARTMENT, SDP PROFESSOR SETCOND SOP COUNT= 5

WHERE DEPARTMENT.NAME = 'COMPUTER-SCIENCE' SELECT UNIVERSITY.NAME, OEPARTMENT.NAME

- 10 -

- 10 -

SET CONDITION

Set conditions may be of the following types:

(1) the set must contain member records which satisfy certain conditions, e.g.:

11professor.age > 60 "professoroage < 30¹¹

The department must include at least one professor older than ⁶⁰ and at least one professor younger than ³⁰ years.

(2) the number of members in the set must satisfy some condition:

setname COUNT> 5

(there must be more than five members in the set).

In general:

setname COUNT { cpo _IN

~

_,nterval ^{nteger }}

where interval := integer-1, integer-2 , and integer-1 < integer-20 cpo is a

comparison operator.

COUNT< integer includes O as a possible value.

By any COUNT specification for a set type S = (R

0, RM) which includes COUNT=O we allow

11optional ¹¹ records, i.e. search path occurrences which do not include an rm e RM. (as indicated in SEMANTICS OF A NOAH QUERY). By COUNT= 0 we ~eclare

that the owner of the set in the search path occurrence must not be related to any record of the membertypeo

COUNT can be specified irrespective of the direction of the search path, but it always refers to the members of the set. Of course, S COUNT~

a

mak~s no sense, if S =

(Ra,

RM) and the search path is RM' S

Ra:

either

s

Search Path

rM E RM is a member of a set of type S (then COUNT= 0 is not satisfied), or rM

is not a member (then COUNT= 0 is meangingless).

Hence, COUNT= 0 is considered a contradictory and therefore incorrect condition in this case.

The same argument holds for ·coUNT < integer, since this includes the case COUNT= 0. To express that rM should not be in a set of a given type another formulation is available.

Note that the specification COUNT>O(existential quantifier) is not required because of the basic semantic of a NOAH search path.

It is essential that a COUNT condition, as in case (1), only validates or invalidates sets for a query, and thus set~ of search path occurrences. If the validation succeeds, then a search path occurrence may be selected by conditions for records. Consider an example: we are interested in the ·departments which have at least one professor older than 60 years (set condition); for these departments we wish to be shown the professors younger than 30 years

(record condition). This is written in NOAH:

PATH DEPARTMENT, SDP PROFESSOR SETCOND SDP PROFESSOR.AGE > 60 WHERE PROFESSOR.AGE < 30

SELECT DEPARTMENT.NAME, PROFESSOR.NAME.

- 12 -

- 12 -

(3) Let R be defined as a CODASYL-optional member of the set type ~etname. Then we may only be interested in records r ER which actually are not members of a set of type ~etname. This is expressed by

setname WITHOUT OWNER.

Of course this does not mean that a set exists without owner; it is tobe read in the context:

r ER must not have an owner in a set of type

~ etname.

Set conditions can be combined to boolean expressions in the usual way by AND, OR and brackets.

For example:

SETCOND SDP COUNT< 10 AND SDP PROFESSOR.AGE > 60 SETCOND SA COUNT> 5 OR SB COUNT> 7

RECORD CONDITION

The user may specify conditions for records of the search path. A search path occurrence is only valid if all the record conditions are satisfied by the records of this occurrence.

A record condition is composed of expressions of the form

dataelementl cpo dataelement2 or

dataelement cpo value,

where cpo is a comparison operator. Expressions of

these types may again be combined to boolean expressions by AND, OR and brackets.

SELECT

The select clause specifies the values tobe shown to the user. The clause may not only contain

elementary data elements, but also groups of data elements, repeating groups, and whole records.

Data made accessible by ¹¹ inheritance¹¹ (see below) can also be specified as output.

The SELECT clause outputs the selected data in a

11 user friendly¹¹ default format. If the user wishes to see the data in another format, he can specify this by a simple FORMAT clause, which allows to define tabular output. The flexibility of output formatting is very limited, since we do not view NOAH as a report generation language. Rather, NOAH is tobe considered as a language for query and data extraction with limited format control.

THE CONCEPT OF INHERITANCE

As has already been said, each record type R of the search path inherits the data elements of the ownertypes of those set types in which R is a member- type. That is, together with r ER all the data

elements of its owners are available and can be used for conditions or output. (Thus, as has been indicated, the data space also contains the data of the owners of the record types in the search path.) The owner- types need not tobe contained in the search path.

Inheritance is not recursive, i .e. data elements

inherited by Rare not again inherited by membertypes of R.

Ta use an inherited data element the following naming convention is applied:

- 14 -

- 14 -

R membertype of set type ST, R¹ ownertype (so R inherits from R^{1) ;} we want to use R'.D. This is expressed as

R WITH ST R¹ .D.

For instance we could use the data el~ment LOCATION of the record type UNIVERSITY as a data element of DEPARTMENT, and could use this element in a

condition:

DEPARTMENT WITH SUD UNIVERSITY.LOCATION = ¹BERLIN ¹ We are looking for departments located in Berlin.

Inherited data elements can be used like any other data element, i.e. they may appear in set conditions, record conditions and in the select clause.

Though cyclic structures are not a1lowed in the search path, one can process a class of cyclic structures by the use of inheritance. Consider an example:

We have student, university and city records, and the following network:

CITY-STUD

STUDENT CITY

CITY-UNI

- 15 -

We wish to ask the query:

11List name and city of the students who da not live at the place of their university. ¹¹

This query would require a cyclic search path, and one has to express that the city tobe shown is the one of the student and not the one of the university.

In NOAH, the query is formulated as follows:

PATH STUDENT, CITY-STUD CITY, UNI-STUD UNIVERSITY WHERE UNIVERSITY WITH CITY-UNI CITY.NAME f CITY.NAME SELECT STUDENT.NAME, CITY.NAME

In the WHERE-clause we make explicit use of the fact that UNIVERSITY inherits the name of the related city;

this name is compared to the name of the city related to the student. That is, CITY.NAME refers to the CITY- record of the current search path occurrence, whereas UNIVERSITY WITH CITY-UNI CITY.NAME refers to the

UNIVERSITY-record of the same search path occurrence which inherits the value of CITY.NAME from the owner of type CITY (which may be different from the

CITY-record in the search path occurrence).

A second important possibility introduced by

inheritance is to formulate set conditions in the case of n:m-~elation4hlp4 expressed by link records.

Consider the example schema:

S 1 s-;;-,K~ S 2

\ SUPPLI ER 1

~

¹ PARTS

We wish to find those supplierswho supply part XA and part XB.

This query represents a condition concerning the n:m-relationship SUPPLIER-PARTS. It can be expressed by a set condition if we use the inheritance concept to make the PARTS attributes available in recordtype K:

- 16 -

- 16 -

SETCOND Sl K WITH S2 PARTS.NAME= 'XA' AND Sl K WITH S2 PARTS.NAME= ¹XB¹

That is: there must exist a set of type Sl which

includes members with part names XA and XB: which part names are inherited from PARTS via the set type S2.

4. NOAH

BY EXAMPLES

All examples of this section refer to the following database schema:

c-s

CITY

c-c

C-STUD

STUDENT COLLEGE

c-o

s-v

DEPARTMENT

0-P

ST-CO PROFESSOR

P-C

v-s

COURSE

1. ¹¹List all cities¹¹ PATH CITY

SELECT CITY.NAME

2. ¹¹Find cities in Bavaria which have a university with a computer science department. List name

of city, name of university, number of department. ¹¹ PATH CITY, C-C COLLEGE, C-0 DEPARTMENT

WHERE CITY.STATE = ¹BAVARIA¹ AND

COLLEGE.TYPE= ¹UNIVERSITY ¹ ANO

DEPARTMENT.NAME = ¹COMPUTER-SCIENCE ¹ SELECT CITY.NAME, COLLEGE.NAME, DEPARTMENT.NR The WHERE-clause contains conditions for different record types; in the same way, the output is

composed of data elements from different records.

This query might be formulated with the following search path definitions as well:

PATH DEPARTMENT, C-0 COLLEGE, C-C CITY PATH COLLEGE, C-C CITY, C-0 DEPARTMENT

Note, that in the second alternative there are two paths starting at COLLEGE.

3. ¹¹Find the departments which were established after the foundation of the college. List college names and names of departments. ¹¹ PATH COLLEGE, C-0 DEPARTMENT

WHERE DEPARTMENT.FOUNDATION > COLLEGE.FOUNOATION SELECT COLLEGE.NAME, DEPARTMENT.NAME

In this case for each college, all departments have tobe accessed. The values tobe compared within one condition of the WHERE-clause are tobe taken from different records.

- 18 -

- - -

- 18 -

4. "List the professors who do not give a course. ¹¹ PATH PROFESSOR, P-C COURSE

SETC0ND P-C COUNT= 0 SELECT PROFESSOR.NAME

This example shows how the empty-set condition is realized in NOAH.

5. "Find cities with more than 5000 students and more than 3 colleges. ¹¹

PATH CITY, C-C C0LlEGE, C-S STUDENT SETC0ND SET C-C COUNT> 3 AND

SET C-S COUNT> 5000 SELECT CITY.NAME

6. "Which colleges have both computer science and mathematic departments. List the colleges. ¹¹ PATH COLLEGE, C-D DEPARTMENT

SETC0ND C-D DEPARTMENT.NAME = ¹C0MPUTER-SCIENCE¹ AND C-D DEPARTMENT.NAME = ¹MATH¹

SELECT COLLEGE.NAME

Here the set conditions are required, since we

want a set to satisfy conditions, namely to include a member with ·¹computer-Science ¹ and another one with

1 Ma th ^{1 •}

7. "Find the students who do not live in the city of their university~"

PATH STUDENT, C-S CITY, C-STUD COLLEGE

WHERE COLLEGE WITH C-C CITY.NAME~ CITY.NAME SELECT STUDENT.NAME, CITY.NAME,

COLLEGE.NAME, COLLEGE WITH CITY.NAME This is an example for inheritance, mentioned fn the text already. The data elements of CITY are

- 19 -

inherited to COLLEGE. Without inheritance the search path would have to contain a cycle (namely by the set-type C-C) which is not allowed.

8. ¹¹Find the students in the third year, who

attend more than five courses. Among the courses a student attends must be 'Operating Systems' and ¹Database Systems'. List name and place of residence of student. ¹¹

PATH STUDENT, S-V ST-CO SETCOND S-V COUNT > 5 AND

S-V ST-CO WITH V-S COURSE. NAME = ¹ OPERATING-SYSTEMS ^I AND S-V ST-CO WITH V-S COURSE. NAME ^{= 1} DATABASE SYSTEMS ¹ WHERE STUDENT.YEAR = 3

SELECT STUDENT.NAME,

STUDENT WITH C-S CITY.NAME

The set conditions for S-V include a COUNT as well as a condition requiring the existence of two

specified members. The n:m-relationship is resolved by the use of inheritance. Also, the student¹s place of residence is made available by inheritance in this example.

- 20 -

5, NOAH

^AND RELATED

WoRK

It is not clear how to describe the ¹¹power¹¹ of a query language. The standard test for relational languages is not meaningful here; obviously, NOAH would not be relatiönally complete, e.g. because

it does not contain setoperators. As far as we are aware of other implemented query languages for net- work databases (e.g. /IQS79, QL77/), NOAH is the most powerful. This relative power mainly stems from the concepts of setcondition and inheritance. There have been other language proposals in the literature, the most intere.sti.ng perhaps NUL /DEH76/ and QUEST /HOU79/.

As to our knowledge both languages are not implemented.

QUEST is described as a language which is suitable for network, hierarchical and relational databases.

The authors stress that the paper is meant tobe a

theoretical study, not a proposal for an implementation.

Though QUEST is a very interesting proposal it is by far too complex tobe a candidate for a query language, especially for a small system.

NUL is a language which allows the user to navigate from one record set to another one through the sets of the database. The description of NUL is rather brief. NUL seems to allow to process arbitrary search paths and is very flexible in expressing selection conditions. As far as can be seen the language is very powerful as compared to NOAH but the set of queries expressible in NUL is not a real superset

of those expressible in NOAH. It has been argued /LEB79/

that NUL would not be an easy to use language. Further- more, NUL would not be implemented easily in its full generality, especially not on a small system.

- 21 -

6,

CONCLUSION

When NOAH was defined the aim was not to produce a language as powerful as possible, but to produce an easy to use, reasonably powerful language which can be supported in a reasonably efficient way on a small system. Experience gained so far shows that NOAH

satisfies these criteria to a great extent.

This paper describes NOAH as it is implemented.

Extensions are being considered, among them built-in functions, the possibility to compute values from the retrieved data, enhancement with respect to

quantification, and a method to allow the processing of arbitrary cyclic structures. The body of NOAH as presented in this paper allows the addition of these features without conceptual problems; the main concern is to find a good trade-off between the

practical usefulness of an extension., the complexity of usage for the user, and the overhead introduced into the system.

ÄCKNOWLEDGEMENT:

First of all we wish to thank D. Beulshausen who did substantial work in the design of the first version of NOAH. We furthermore thank the following persons for valuable discussions: C. Metzler whom we lost by a tragic accident; R. Ammen, H.W. Nau, R. Zieschang, Triumph Adler, Nürnberg; P. Dadam.

Very hard work during the implementation of NOAH was done by U. Manthey and R. Gerber.

- 22 -

REFERENCES:

C071 CODASYL 1971 Data Base Task Group April 71 Report, ACM, New York C078

DEH76

HOU79

IQS79

LEB79

QL77 TSI76

ZAN79

CODASYL 1978 COBOL J. Oevelopment, Materiel Data Management Center,

Quebec, Que. Earlier editions appeared in 1973 and 1968.

Deheneffe, C., Hennebert, H.:

NUL: A navigational user's language for a network structured data base.

Proc. ACM-SIGMOD 1976.

Housel, B.C.: QUEST: A high-level data manipulation language for network,

hierarchical, and relational databases.

IBM Res. Rep. RJ2588, 1979.

Siemens Interactive Query System (for UDS database system)

Lehmann, R., Blaser, A.: Query Languages in database systems. IBM Heidelberg

Technical Report 79.07.008

S p e r r y U n i v a c I n t e r a c t i ve Q u e r y L a n g u a g e . Tsichritzis, D.: LSL: A link and selector language. Proc. ACM-SIGMOD 1976.

Zanio1, C.: Design of relational views over network schemas. Proc. ACM-SIGMOD 1979.

Syntax of NOAH query:

searchpath [setselection)[recordselection] output searchpath:

PATH (setname-1] recordname-1 (, setname-2 recordname-2] .•.

setselection:

SETCONO boolean expression of scondition scondition:

setname {

rcondition COUNT

t ^~~o

WITHOUT OWNER

integer integer-1, integer-2

1

recordselection:

WHERE rcondition rcondition:

boolean expression of condition condition:

{

record-name-1.data-name-l

l

record-name-2 WITH set-name-3 record-name-3.data-name-3

J

cpo

{

literal

record-name-4.data-name-4 record-name-5 WITH set-name-6

<, <=, =, >=, >, <>

- 24 -

reco rd-name-6. da ta-name-6}

- 2 4 -

output:

SELECT outputelement-1 [, outputelement-2] ...

outputelement:

record-name-1 [.data-name-1]

record-name-2 WITH set-name-2 record-name-3 [odata-name-3]