JPS6355625A - Recursive view processing system - Google Patents

Abstract

PURPOSE:To retrieve an unfixed level due to the data contents in an inquiry language processing system for an SQL language against a relational data base, by providing recurrent properties to a view function. CONSTITUTION:A view defining part 18 accepts even such a view that has a recurrent definition including the subject view definition name in its retrieving subjects in terms of the view definition in the same way as the ordinary view definition and registers said view to a view definition information part 20. When a retrieving command is supplied form an input part 10 to the view defined recursively, an inquiry language processing part 11 analyzes a syntax structure via a syntax structure analyzing part 12 and optimizing the syntax structure via an optimization processing part 14 with reference to the definition information on the part 20 through a meaning analyzing part 13. Then a production code 17 is produced by a code generating part 15. The code 17 includes a recurrent call related to the generation of a retrieving data and an inquiry result is obtained from gathering sum of the retrieving results obtained in response to each nest level.

Description

[Detailed Description of the Invention] [Summary] The present invention provides recursiveness to the view function in query language processing such as SQL language for relational databases, thereby performing searches at an undefined level depending on data content. This makes it possible.

[Industrial application field]

The present invention relates to a recursive view processing method, and particularly to a recursive view processing method that allows so-called child component expansion and parent search expansion to be easily performed in a relational database.

In recent years, relational databases (relational databases) have been increasingly adopted as database systems that are easy for users to use.

In database systems, it is desirable that users be able to extract the data they need from a variety of managed data, not just relational databases, by making specifications as simple as possible.

[Conventional technology]

Relational databases manage data in table format. For example, the SQL language is known as a query language for this relational database. In the SQL language, a search can be specified in the following format:

5ELECT (Target column name) FROM (Table name) WHERE (Condition) Additionally, the SQL language extracts only data that satisfies a predetermined condition from one or more tables and dynamically constructs a virtual table. It has a view function to

However, in a view definition, the table that can be specified as a search target must be a table that has already been defined, so it is not allowed to use the view definition part in the view itself.

[Problem that the invention seeks to solve]

FIG. 4 is a diagram for explaining the present invention in detail.

For example, consider data having a parent-child relationship as shown in FIG. 4(a). Pl to Pl are data of each part, and PL is data of P2. This indicates that parts P3° and P4 are used. P2 is.

P3. Use P5 parts. Also parts below P3.

Use other parts in the same way. Part data like this,
If managed in a table format using a relational database, it will look like table T2 (table name PP) shown in FIG. 4(b). That is, A# represents a parent component and C# represents a child component. Column QTY is the quantity of child parts. Note that table T1 (table name PARTS) is a table that stores attribute data for each part.

In such a table T2, when expanding child parts such as 1, for example, "What are all the child parts necessary for the configuration of Pl?", from Pl to P2, P3. Find P4, and then calculate P3 from P2. It is necessary to search the table over many levels, such as finding P5, finding P6 from P5, and so on. This level depends on the data content.

Since the query language is undefined, there is a problem in that it is not possible to easily obtain search results using the query language systems that have been used in the past. For example, "What are all the parent parts that use Pl?"

The same is true when performing parent search expansion.

That is, in the case of a conventional network-type database, etc., the above-mentioned child part expansion and parent search expansion can be processed relatively easily, but in the case of a relational database, a special data structure is used. Special treatment must be assembled separately.

It was not possible to perform complete expansion of child parts.

SUMMARY OF THE INVENTION The present invention aims to solve the above-mentioned problems and to provide a means for easily performing searches at an undefined level without significantly changing the existing language system for relational databases.

[Means for solving problems]

FIG. 1 shows an example of the basic configuration of the present invention.

In FIG. 1, 10 is an input section for inputting search commands, view definition information, etc., 11 is a query language processing section, and 1
2 is a syntax analysis unit that analyzes the syntax of commands, etc.; 13 is a semantic analysis unit that analyzes the meaning of the syntax analysis results; and 14 is an optimization processing unit that schedules access to actual tables.

15 a code generation unit that generates a series of intermediate codes or object codes for accessing the table;
16 is a code execution unit, 17 is a generated code generated by the code generation unit 15, 17A is an initial data generation unit, 1
7B is a synchronous buffering control unit, 17C is a search data generation unit, 18 is a view definition unit that registers the view definition front axis, 19 is a database, Z0 is a view definition information unit that stores view definition information, 21A and 21B are A table 22 that stores data in table form 2 represents a database access unit that inputs and outputs data to and from the database 19.

In the case of the present invention, the view definition section 1st includes the following on the view definition:
A view having a recursive definition that includes the target view definition part as a search target is also accepted in the same way as a normal view definition, and is registered on the view definition information part 20.

When a search command for a recursively defined view is input from the input unit 10, the query language processing unit 11 parses the syntax using the syntax analysis unit 12, and then uses the semantic analysis unit 13 to input the search command on the view definition information unit 20. The optimization processing section 14 performs optimization, and the code generation section 15 generates the generated code 17 with reference to the definition information.

This generated code 17 may be something like an intermediate code executed in an interpreter format, or something like a compiler output that can be directly executed. In particular, one generation code 17 related to the present invention includes a recursive call regarding search data generation.

In effect, one query result is obtained from the set sum of search results obtained according to each nesting level.

The code execution unit 16 interprets and executes the generated code 17,
Via the database access unit 22.

Access the database 19.

[Effect]

In the present invention, a recursive definition that includes the target view definition part as a search target is allowed on the view definition. Therefore, the search is at an indeterminate level depending on the data content.

The recursive view definition allows the view to be specified in advance, and a search command for that view allows a set sum of search results corresponding to each nesting level to be obtained.

〔Example〕

FIG. 2 is a conceptual diagram of processing by generated code according to an embodiment of the present invention, and FIG. 3 is an explanatory diagram of execution equivalent commands for explaining the operation of an embodiment of the present invention.

In the following embodiments, the SQL language, which is well known as a query language for relational databases, will be used as an example. It is equally applicable to other query languages with similar view functionality.

For example, when obtaining a list of component parts by expanding child parts for table T2 (table name PP) shown in FIG. 4(b), the following view definition is performed in advance.

VIEW V (A#, C#, QTY) ASSE
LECT PP, A#, PP, C#, PP, QTYF
ROM PP, V WHERE PP, C#=V, A# This view definition is for table PP and view ■.
Select the column C# of PP and the column A# of V are equal, and depending on the A#, C#, and QTY of that PP, view, -■
is configured. In this view definition,
View definition part rVJ.

Because it is used in the FROM clause within its definition.

It is a recursive definition. Furthermore, this definition is.

Performed by the DBMS user.

Here, let us assume that we want to extract all the parts that make up one part P1. In this case, enter the following search command.

5ELECT * FROM V WHERE PP, C#=V, A# The query language processing unit 11 shown in FIG. 1 analyzes this search command and generates a generated code 17 as shown in FIG. 2, for example. The generation code 17 includes an initial data generation section 17A, a synchronous buffering control section 17B, and a search data generation section 17C. - The initial data generation unit 17A first sets the level to “0” through process (2), specifies “P1” as the search target item, and calls the synchronous buffering control unit 17B. Show that.

In the synchronous buffering control unit 17B, through process (2),
The level and search target item information are each variable 5YS.
When received at LEVEL, P#.

Buffering system for synchronization + II by processing ■
Execute I, process ■, variable 5YSLEVEL, P
# is specified to call the search data generation unit 17C.

The search data generation unit 17c performs process (2).

Upon receiving the request from the synchronous buffering control unit 17B, the search target c1 is declared in process (2). This C
1 may be considered a host interface used by the database access unit 22 shown in FIG. 1 to access the database 19. By processing ■, this C
Specifies search by 1.

Processing (2) instructs to repeat processing (2) to (@) until there are no search results. Processing ■ accesses the actual database 19, and one P#
is obtained. The obtained value of P# is output as one of the search results by the process [phase]. For example, if there is a constraint on the depth of the level, processing 0 will result in 5YSL
Check EVE and L, and skip the secondary process (2) if necessary.

In processing @, add 1 to the 5YSLEVELO value,
The synchronous buffering control unit 17B is called with P# set as the level and P# as a new search target item. Recursiveness will be realized by returning this data.

Process ◎ corresponds to process ■ and indicates the end of repetition. Processing ■ indicates the end of the search by C1.

Generate the above generated code 17 in an incremented manner.

Or, by directly converting it into something like object code and executing it, you can essentially create something like the one shown in Figure 3.
The search command will be interpreted and executed. In other words, the search command that specifies a view based on the recursive definition shown in Figure 3 (a) is essentially executed as a UNTON (set sum) of search commands corresponding to each host level shown in Figure 3 (b). The actions and their results are equivalent.

In FIG. 3 (b), PPI, PP2. ···teeth.

These are names specified for level-corresponding searches for each table PP. You may consider that the number of UNIONs is infinite and that above a certain level it will always be a union of empty sets, or you may consider that there are UNIONs up to a predetermined host level.

At level "0", PP is a child part of PI.

P3. P4 is obtained. At level "1", PP, P3. Regarding P4, its child part P3. P5. P6. P7 etc. are obtained. level"
2" and level "3" are the same, but level "4" is 2".
Since there are no child parts of part P6, the result is an empty set. Therefore, the merger by UNION will be canceled. The set of search results according to each host level obtained above is the desired P
The child parts of l are expanded.

For example, in the case of parent search expansion such as "What are all the parts that use part P7?"

Since the start and search directions are different from child parts expansion, 8
It is recommended to use the following view definition.

VIEWV(~) AS SELECT * FROM PP, V WHERE PP, A#=V, C# By using the following search command for this view, the above parent search expansion is possible.

5ELECT * FROM V WHERE V, C#='P7° This processing operation is the same as in the case of child component expansion, except for the search direction and the like.

By the way, there may be cases where the user wants to know the level of the host. In this case, the built-in function (S
YSLEVEL).

rSELECT 5YSLEVEL, A#,
C#, -j again. If a user incorrectly defines a view, a view that is not originally recursive may be interpreted as recursive, resulting in unexpected behavior. Since it is considered rare to use a recursive definition like the one used in the present invention,
A keyword such as ``primary'' may be provided in order to distinguish from a case of erroneous definition.

rDEFIN RECUR3I VE VIEW
V (-) J again. In order to allow the user to control the depth of the search level, it is desirable to be able to set the following conditions, for example.

rWHERE 5YSLEVEL<Constant" When this condition is specified, the recursive call is aborted when the level reaches the specified constant.

〔Effect of the invention〕

As explained above, according to the present invention, it is possible to perform data-dependent searches at an undefined level using a query language for relational databases, and also for child part expansion, parent search expansion, and the like.

You will be able to do it easily.

[Brief explanation of drawings]

FIG. 1 is a basic configuration example of the present invention, and FIG. 2 is a conceptual diagram of processing by generated code according to an embodiment of the present invention. FIG. 3 is an explanatory diagram of execution equivalent commands for explaining the operation of an embodiment of the present invention, and FIG. 4 is a diagram for explaining the present invention in detail. In the figure, 10 is an input section, 11 is a query language processing section, 1
2 is a syntax analysis unit, 13 is a semantic analysis unit, 14 is an optimization processing unit, 15 is a code generation unit, 16 is a code execution unit, 17 is a generated code, 17A is an initial data generation unit, 17B is a synchronous buffering control unit , 17C is a search data generation unit, 1
Reference numeral 8 represents a view definition section, 19 a database, 20 a view definition information section, 21A and 21B tables, and 22 a database access section. Patent Applicant Fujitsu Limited Sub-Agent Patent Attorney Yoshiyoshi Ogasawara 1 l Suspension 2 mouths

Claims (1)

[Scope of Claim] A database search processing system that processes queries to a relational database by inputting a query language that has a function of extracting a data group that matches a certain condition from a predefined view, comprising: Means for accepting a recursive definition that further specifies the own view as a search target within the definition (18
), and in response to a search request for the recursively defined view above, the query result is obtained from the set sum of search results obtained according to each nesting level.
Means for generating and executing code including recursive calls (15,
16) A recursive view processing method comprising: