JPH08101784A - Method and device for mounting subtype relation in relational data base - Google Patents

Abstract

PURPOSE: To improve the memory efficiency with respect to table design of a relational data base. CONSTITUTION: When a table includes subtype relations with respect to table design of the relational data base, the table where there are plural attributes having the fields where values are not entered is divided into a table (master table) having only common attributes (attributes of fields where values are all entered) and a table (slave table) having attributes other than common attributes and key attributes of the table as the base to store the data. Since data is divided into data of the master table and data of the slave table and is stored, the frequency in occurrence of divisional read/write of records is reduced in the case of a large number of attributes in comparison with conventional, and the access efficiency is improved.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a subtype relation mounting method and apparatus in a relational database.

[0002]

2. Description of the Related Art In the prior art, as described in Yoshifumi Masunaga: Introduction to Relational Database; Science Co .; p59-p89, normalization work is performed in relational database table design. -Restructuring the table taking into account subtype relationships after the Bull definition was not mentioned.

[0003]

In the conventional method, when a table of a relational database is defined, even if there is a subtype relationship, the table is defined as one table, so that the number of attributes is large. In some cases, divided read / write of records may occur. There is also a problem that unnecessary memory is required when many fields that do not contain values are included. The purpose of the present invention is to
A table containing subtype relationships is divided into a parent table and a child table to improve the access efficiency to the data in the table and the memory efficiency.

[0004]

In order to achieve the above object, the present invention is provided with a table having a plurality of attributes having fields that do not contain values, a table definition and data to be stored in the table. At this time, it is divided into a table (parent table) that has only common attributes (attributes that have values in all fields), an attribute other than common attributes, and a table (child table) that has key attributes of the original table. Then, the data is stored.

[0005]

Operation: In the table design of a relational database, if the table contains subtype relationships,
By defining the table by dividing it, the data is stored separately from the data of the parent table and the data of the child table. Therefore, if the number of attributes is larger than before, you can divide the record and read / write it. Is reduced and access efficiency is improved. Further, since the field having no value can be eliminated, the memory efficiency can be improved.

[0006]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to FIGS. FIG. 1 shows the system configuration of a subtype relation mounting system handled in this embodiment. This system consists of the following. Reference numeral 101 is a processing device that performs processing in response to a request from the input device 102. An input device 102 inputs a processing request. A display device 103 displays the data input from the input device 102 and the processing result of the processing device 101. Reference numeral 104 is a parent table information file that stores management information of a table that becomes a parent when the table is divided. Reference numeral 105 is a child table information file that stores management information of a child table when the table is divided.
Reference numeral 106 is a parent table data file that stores the data of the parent table. 107 is a child table data file for storing the data of the child table. Reference numeral 202 is a registration table input area for setting the table definition input from the input device 102 and the data stored in the table.
Reference numeral 203 denotes a parent table attribute generation work area in which the attributes of the table that is a candidate for the parent table are set when the table is divided. Reference numeral 204 is a child table attribute generation work area for setting the attributes of tables that are candidates for child tables when the table is divided. Reference numeral 201 denotes a table registration program that stores a table divided into a parent table and a child table based on the information input from the input device 102. A file access system program 205 accesses the parent table data file 106 and the child table data file 107 based on the file name.
Reference numeral 206 is a table access program that acquires corresponding data from the parent table data file 106 and the child table data file 107 in response to an inquiry request input from the input device 102.

First, the outline of the processing flow will be described. First, the table definition input from the input device 102 and the data stored in the table are registered in the registration table input area 20.
Set to 2. Next, the data entered in the registration table input area 202 is searched to find an attribute name having null data. The found attribute name having null data is set in the child table attribute generation work area 204, and the other attribute names having no null data are set in the parent table attribute generation work area 203. After this, one attribute name set in the child table attribute generation work area 204 is extracted and stored in the child table information file 105 together with the key attribute of the table set in the registration table input area 202. The above process is repeated for all the attribute names set in the child table attribute generation work area 204. Similarly, all the attribute names set in the parent table attribute generation work area 203 are stored in the parent table information file 104. Finally, the actual data set in the registration table input area is stored in the parent table data file 106 and the child table data file 107 using the file access system program.

In the following, the table structure will be described first, and then the table registration program 201 will be described in detail with reference to FIG.
This is done using the flowchart in. FIG. 2 shows a registration table input area 202, which is a table name area 202a of the table input from the input device 102, attribute name areas 202b-1 to 202b-n which are the keys of the table, and an attribute name area 202c of the table.
-1 to 202c-N, data area 20 corresponding to each attribute
It is composed of 2d-1 to 202d-s. FIG. 3 shows a parent table attribute generation work area 203, which is composed of areas 203-1 to 203-k for setting attribute names which are attributes of the parent table.
FIG. 4 shows a child table attribute generation work area 204 in which an attribute name serving as an attribute of the child table is set 204-1.
~ 204-q. FIG. 5 shows a parent table information file 104, which is a data file name area 104a in which actual data is stored, a parent table name area 104b, child table name areas 104c-1 to 104c-t, and a parent table attribute name area. It is composed of 104d-1 to 104d-k. FIG. 6 shows a child table information file 105, which is a data file name area 105a in which actual data is stored, a child table name area 105b,
It is composed of attribute name areas 105c-1 to 105c-r of the child table. FIG. 7 shows the parent table data file 106, and of the data 202d-1 to 202d-s of the registration table input area 202, areas 106-1 to 106 in which the data of the parent table is stored.
Composed of -k. Figure 8 shows child table data file 10
7 and the data 202d-1 of the registration table input area 202
Of 202d-s, the area where the child table data is stored
It is composed of 107-1 to 107-r.

Next, a detailed description of the processing of the table registration program 201 will be given using the flowchart of FIG. First, the table name of the table input from the input device 102, the attribute name that is the key of the table, the attribute name of the table,
Data for each record is registered in the registration table input area 202
Set to (step 1001). Next, search the actual data areas 202d-1 to 202d-s of the registration table input area 202 to find the attribute name that has null data in the actual data,
Areas 204-1 to 20 of child table attribute generation work area 204
Set to 4-q (step 1002). Further, in the registration table input area 202, the attribute names having no null data in the actual data are set in the areas 203-1 to 203-k of the parent table attribute generation work area 203 (step 1003). Area 204-1 of child table attribute generation work area 204
~ One attribute name set in 204-q is taken out, a new relation is created together with all the key attribute names 202b-1 to 202b-n set in the registration table input area 202, and a child table information file is created. It is stored in 105 (step 1004). At this time, in the child table name area 105b,
A name obtained by adding a serial number to the table name 202a set in the registration table input area 202 is stored, and the same name as the child table name is stored in the data file name area 105a of the child table information file 105. The above process is repeated for all the attribute names stored in the child table attribute generation work area 204. If the created new relation already exists in the child table information file 105, it is stored in the child table information file 105. do not do. Further, a new relation is created by combining all the attribute names set in the areas 203-1 to 203-k of the parent table attribute generation work area 203 and stored in the parent table information file 104 (step 1005). At this time, the data file name area 104 of the parent table information file 104
a and the parent table name area 104b store the table name 202a set in the registration table input area 202, and the child table name areas 104c-1 to 104c-t store the area 105b of the child table information file 105. Store the child table name stored in. Finally, the parent table information file
Create a file with the same name as the data file name 104a of 104 and the data file name 105a corresponding to each child table of the child table information file 105, and save the actual data 202d-1 to 202d-s in the registration table input area. Area 1 of the parent table data file 106
The data of the child table is stored in areas 07-1 to 107-r of the child table data file 107 corresponding to each child table in steps 06-1 to 106-k (step 1006).

Next, an embodiment for accessing the data stored in the child table will be described with reference to the flowchart of the table access program 206 shown in FIG.

Here, when the attribute name of the child table is specified as the attribute name of the data to be searched, the parent table name is specified as the table name to be searched, and the attribute name of the child table is specified as the attribute name related to the search condition. think of. First, the input device 102 inputs the attribute name of the data to be searched, the table name to be searched, and the search condition. Next, the area 104b of the parent table information file 104 is searched based on the table name input from the input device 102, and the corresponding child table names 104c-1 to 104c-t are acquired (step 200).
1). Further, based on the acquired child table name and the attribute name of the data to be searched, which is input from the input device 102, the areas 105b and 105c-1 to 105c- of the child table information file 105 are acquired.
Search r and find the corresponding child table data file name 105
Acquires a (step 2002). Pass the acquired data file name to the file access system program,
The child table data file 107 is accessed to read the records of the child table data file 107 one by one (step 2003). Here, it is determined whether all the records stored in the child table data file 107 have been read (step 2004). If not, whether the read records satisfy the search condition input from the input device 102 is determined. The determination is made (step 2005), and if the search condition is satisfied, the corresponding data is stored in the work area (step 2006). If the search condition is not satisfied, the next record of the child table data file 107 is read (step 2003). When all the records of the child table data file 107 have been read by repeating the processing from steps 2003 to 2006, the data stored in the work area is displayed on the display device 103 (step 2007), and the processing ends.

If the table is not divided into the parent table data file and the child table data file in step 2003, the table access program 206 may divide the record and read it multiple times if the table has many attributes. It is possible. In this case, the record I / O
It takes a lot of time to perform, and the response characteristics are considered to deteriorate.

[0013]

As described above, according to the present invention, in the table design of a relational database, when a table has a subtype relationship, the table is divided and defined so that the data is the data of the parent table. , Because it is stored separately from the data of the child table,
When the number of attributes is large as compared with the related art, divided read / write of records is less likely to occur, and access efficiency is improved. Further, since the field having no value can be eliminated, the memory efficiency can be improved.

[Brief description of drawings]

FIG. 1 is a system configuration of a computer system to which an embodiment of the present invention is applied.

FIG. 2 is a detailed diagram of a registration table input area 202.

FIG. 3 is a detailed diagram of a parent table attribute generation work area 203.

FIG. 4 is a detailed diagram of a child table attribute generation work area 204.

5 is a detailed diagram of a parent table information file 104. FIG.

6 is a detailed diagram of a child table information file 105. FIG.

FIG. 7 is a detailed diagram of a parent table data file 106.

8 is a detailed diagram of a child table data file 107. FIG.

FIG. 9 is a flowchart showing detailed operations of the table registration program 201.

FIG. 10 is a flowchart showing detailed operations of the table access program 206.

[Explanation of symbols]

101 ... Processing device, 102 ... Input device, 103 ... Display device, 104 ... Parent table information file, 105 ... Child table information file, 106 ... Parent table data file, 107 ... Child table data file, 201 ... Table registration program, 202 ... registration table input area, 203 ... parent table attribute generation work area, 204 ... child table attribute generation work area, 205 ... file access system program, 206 ... table access program.

Claims (2)

[Claims] 1. In a table definition of a relational database, only a common attribute (attribute in which all fields have values) is a table in which there are a plurality of attributes having fields that do not have values in the normalized table. A subtype relation mounting method in a relational database, which is characterized by separately defining a table having a table, an attribute other than a common attribute, and a table having a key attribute of the original table. 2. In a table definition of a relational database, only a common attribute (attribute in which all fields have values) is a table in which there are a plurality of attributes having fields that do not have values in the normalized table. A subtype relation mounting apparatus in a relational database having means for separately defining a table having a table, an attribute other than a common attribute, and a table having a key attribute of the original table.