Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Queries on a Hierarchical Data Structure

IP.com Disclosure Number: IPCOM000044050D
Original Publication Date: 1984-Oct-01
Included in the Prior Art Database: 2005-Feb-05
Document File: 6 page(s) / 24K

Publishing Venue

IBM

Related People

Larner, A: AUTHOR

Abstract

The system disclosed allows a user to express, modify and extend a query on a hierarchically structure data. The user, having gained an understanding of the reference of segments in a hierarchy, and knowing what his query is about at its lowest (detail) level, specifies the segments, or fields in those segments, pertaining to that lowest level. This constitutes his specification of segments which functionally determine the path of the query (determinant segments). Inbuilt rules about instance identity of segments and levels of accumulation of fields within segments, along with this identification of determinant segments, resolve ambiguities between queries defined using the same derivation of data in their results, and so save the user from complex specification of the structure of his query in relation to its data bases.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 17% of the total text.

Page 1 of 6

Queries on a Hierarchical Data Structure

The system disclosed allows a user to express, modify and extend a query on a hierarchically structure data. The user, having gained an understanding of the reference of segments in a hierarchy, and knowing what his query is about at its lowest (detail) level, specifies the segments, or fields in those segments, pertaining to that lowest level. This constitutes his specification of segments which functionally determine the path of the query (determinant segments). Inbuilt rules about instance identity of segments and levels of accumulation of fields within segments, along with this identification of determinant segments, resolve ambiguities between queries defined using the same derivation of data in their results, and so save the user from complex specification of the structure of his query in relation to its data bases. In addition, a useful and natural default formatting of query results is automatically generated. Accumulation of data at various levels is allowed by a slight modification of the relevant inbuilt rule and is made applicable to averages by a redefinition of that function. The user is allowed to treat certain segments as extensions of others, where this is appropriate. This avoids forcing accumulation of uniquely identifiable fields and allows the production of default values at the user's option. Hierarchically Structured Data Hierarchical structuring of data is a long established technique of data base organization, as used, for example, in the IBM Data Language DL/I, whose nomenclature is here used. A user of a query system is assumed to be presented with a number of data bases, each data base comprising a hierarchy of segments, and each segment comprising a sequence of fields (items of data). Segments and fields having a common name and format are said to be of the same type. The user expresses his query in terms of the type of segments or fields he is interested in; the result he requires however comprises data copied from all or some of the distinct fields in distinct segments (commonly termed field or segment instances). Such a hierarchical data base is, in graph theoretical terms, a forest, the segment instances being nodes. If segments of the same type are superimposed, the graph remains a forest (or, in the case of DL/I, a single tree - only one root segment type is allowed in each data base). The structure which is, implicitly or explicitly, available to the user is this forest, each node of which is a segment type.

Formulation of a Query In order to formulate a query the user must effectively define the derivation of each field in the required result. Each column in the result will have a common type of derivation, and it is this type of derivation that is determined by the user. Common examples of such derivations are that a field in the result should be: oa copy of a field in the data base, such as 'ITEM NAME', a function of one or more fields of different typ...