JP2001187477A - Data base system having hierarchic link table - Google Patents

Abstract

PROBLEM TO BE SOLVED: To obtain a data base system which can deal flexibly and quickly even with addition/modification of the content of business or associated data (including information related to the content of service or client). SOLUTION: Information (e.g. a pointer) for linking data bases (entities) is not included (hierarchic node data base), as a rule, in a data base containing data processed according to each business processing program. On the other hand, a table (hierarchic link table) principally comprising information for linking data bases is formed in correspondence with each business processing program. Each business processing program can accesses a required hierarchic node data base with reference to a corresponding hierarchic link table. When modification in the hierarchic structure of data, e.g. addition of a business based on a new business, is required, a corresponding correction is simply required to reflect on the hierarchic link table.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a database system accessed by an application program (business processing program) for performing a certain business process, and particularly flexibly copes with additions and changes of business contents and related data. About possible database systems.

[0002]

2. Description of the Related Art Data handled by an application program (business processing program) for performing a certain business process is large and therefore usually stored and managed in a database system. This database system is typically constructed as follows. First, a database (also referred to as an entity) necessary for all business processing programs and data items (also referred to as attribute items of each entity) in the database are identified. The relations between databases (hierarchical structure such as parent-child relations) and the relations between data items in the database (relationships between these relations) so that all assumed business processing programs can perform efficient processing. Ship). These determined relationships can be expressed as an ER diagram (entity relationship diagram). This ER diagram is defined as an actual database using the function of a database management system (DBMS). For example,
In the case of a relational database, the database is defined using a language such as SQL. As a result, in each database, association information (pointer, etc.) indicating the record identifier of the related database is generated in a record (key area, column, etc.) storing the actual value, contents, etc. (instance) of each data. Is done. In practice, such association information (such as a pointer) is often created by a business processing program as a part of normal business processing.

When the processing requirements of a business are changed, a new business is added, or a database is added / changed, the relation / hierarchical structure between the databases is corrected (for example, elimination / addition / reversal of parent-child relationship). Will be done. In this case, it is necessary to perform a linking operation between databases as described above, and to create a changed hierarchical structure in the database by using a function of the database management system (DBMS). Further, it is necessary to change the association information such as a pointer existing in a record (column) in each existing database. Specifically, a program for the change is created and the change is made to the database.

When such a change operation is performed, all business processing programs using the changed database (which means reading and processing data items, and writing / updating the data items) are executed. In this case, it is necessary to correct the contents in accordance with the change in the hierarchical structure of the database or at least to perform a test for confirming that there is no influence. The relationship between the databases, that is, the hierarchical structure of the database is not changed, but the association between the record in the database and the record in another database related thereto is changed (for example, when the customer A If you transfer a phone number to another person,
The so-called parent-child relationship change / affiliation change at the instance level) can occur as part of normal business processing, and the business processing program performs such change processing.

When viewed from a specific business processing program, there is a relationship and a hierarchical structure necessary for the processing between the database groups used by the program itself. (Partial set), it is not always necessary to separately create a relation / hierarchical structure for the business processing program. That is, by following the association information such as the pointer indicating the relationship between all the databases, it is possible to reach the necessary database.
However, in consideration of processing efficiency and the like, a relation / hierarchical structure corresponding to the business processing program is usually created using a function of a database management system (DBMS) called a view. The business processing program can access the corresponding database group by referring to the views and the like created separately in this way.

From another viewpoint, focusing on operational databases used for these business processes, individual records in each database usually store the actual value / content (instance) of the “latest” data. Only this "latest" data is available. Here, the “latest” is the value at the end of the previous night's processing (nightly batch processing result, etc.), or the latest state (real-time processing result) added / updated every time transaction processing (transaction) occurs. ). For example, when the business processing program performs processing in a certain period unit, for example, when records stored in one month are aggregated / calculated at the end of the month, the business processing program is executed. The program accesses the database at the end of the month and performs certain processing based on all the latest data records stored therein. However, at some point during the month, the relationship between databases or data records may change (for example, when customer A transfers one telephone number to another person, so-called instance- When parent-child relationship changes / affiliation changes occur at the level). In this case, the conventional association information (pointer or the like) does not hold data that indicates when the relationship was valid from when to when. As a result, when that change occurs,
It is necessary to execute the business processing program once based on the latest data and association information, and to execute the program again based on the latest, ie, changed data and association information at the end of the month after the change. Occurs.

[0007]

However, in the above-described database construction technique, it is necessary to preliminarily identify and define or determine relationships between all databases required by all assumed business processing programs. Is extremely difficult and very time consuming.
For this reason, in practice, definitions and decisions are compromised to some extent, so that the work of changing the relationship between databases frequently occurs later, and this is accompanied by the change and testing of many business processing programs. And consumes a great deal of labor and time. A hierarchical structure created by using a function of a database management system (DBMS) called a view as described above is a subset of the entire hierarchical structure, and is not an actual database. Therefore, this cannot be changed alone, and the same problem still occurs.

This means that it is not possible to provide a database system that can flexibly and quickly respond to addition of a new business or change of the contents of an existing business.
That is, even if a new business requirement having a new database relationship / hierarchical structure occurs (for example, a parent-child relationship
Even if you want to offer a new product or service with a grouping relationship), you cannot update your database system quickly. In addition, when the parent-child relationship between databases required for one business processing program is reversed from the parent-child relationship required for another business processing program, or when business requirements are changed, the parent-child relationship between databases is reversed. If it is desired, the hierarchical structure of the database may not be defined in the first place, and such business requirements may not be realized. Also, although a business processing program was designed to process a specific database serving as a reference (parent entity) and a group of databases (child entities) associated therewith, a new requirement for the reference database is given. If another entity is added above the (parent entity) (parent position) and the database group must be processed based on this (for example, billing or If there is a business processing program that performs discount processing, it is necessary to add "holding company" as an entity higher than "company" and process it in units based on this) Significant changes are required in the database, its association information, and the business processing programs involved. It is also often give up. Further, in the above example, when data records (instances) of two reference databases (entities) are united into one (for example, when two companies are merged into one). Case) also has the same problem.

As another problem from another viewpoint, in a business processing program that performs processing in a fixed period unit, if a change in data records of a database or a change in a relation between databases occurs in the middle of the period, As described above, a complicated program execution process is required. This usually means that the database used for business processing only keeps the data content corresponding to the point of time "latest", so even if only the database is accessed, it is not possible to retroactively process it. to cause. In such a case, a program must be executed each time a change in the database or the like occurs, or a file (for example, a log file or the like) for storing past records must be read and special processing must be executed. Without
It is necessary to build a special function for it in a business processing program or the like. This leads to complicated and enormous business processing programs, deterioration of quality, and increase in development and maintenance costs.

Further, the hierarchical structure created by using a function of a database management system (DBMS) called a view is not the actual entity of the database as described above. Cannot be set, and this does not solve the problem described above.

[0011]

SUMMARY OF THE INVENTION The present invention solves the above-mentioned problem, that is, the problem that existing database systems cannot flexibly and promptly respond to changes in business contents and database contents and relationships. That is its purpose. Therefore, the present invention provides a database management method that can flexibly set and change the relationship between databases (entities) without putting a large burden on the development / maintenance of a database or a business processing program, and a database using a business processing program. The timing of processing and the timing of adding / changing the relationship between databases or the timing of adding / modifying data records (instances) are treated independently, and the mutual dependency is increased to improve the isochronous axis (time flow). Provides a database management method that provides flexibility. This makes it possible to realize a database system that is flexible against changes.

More specifically, in the present invention, first, in principle, the association information (pointer, etc.) between databases (entities) is not provided in each database to be processed (and in its data record). The database configured in this manner is called a “hierarchical node database”. On the other hand, a table (a type of database) mainly having association information between databases (entities) is created separately for each business processing program. The table configured in this manner is called a “hierarchical link table”. Each business processing program can access the hierarchical node database required by referring to the corresponding hierarchical link table. (However, for reasons such as processing performance, so that the hierarchical link table can be restored by following another route even if it is broken for some reason, a method is adopted in which some association information is provided in the hierarchical node database. May be used.)

According to the database management method of the present invention, it is not necessary to identify and define / determine all the databases and the like required by all assumed business processing programs in advance. Only the requirements of each business processing program need to be set in the hierarchical link table. When a business processing program based on a new requirement is added, it is only necessary to reflect the corresponding correction in the hierarchical link table. Also, when the parent-child relationship between databases required for one business processing program and the parent-child relationship required for another business processing program are reversed, or when new business requirements change and the parent-child relationship is to be reversed, There is no need to modify the hierarchical node database that stores the data itself, and it is sufficient to define the parent-child relationship / hierarchical structure required only for the hierarchical link table corresponding to each business processing program. In addition, when a specific database (entity) serving as a reference is added or modified (example of “holding company” described above) or when data records (instances) of two reference databases (entities) are combined ( The same applies to the above-mentioned example of merger of companies).

Each data record in the hierarchical link table is a relatively short record that only stores association information (pointers and the like) and, if necessary, validity period information to be described later. Can be easily executed in a short period of time, even if it involves various backups in preparation for a trouble. In addition, since the range of influence is limited to one or a very small number of the corresponding business processing programs, the confirmation test after the change can be performed with relatively little trouble.

Further, according to the present invention, the parent / child relationship / hierarchical structure between the hierarchical node databases (data records) held by the data records as pointer information corresponds to each data record of the hierarchical link table. It is also possible to set a period that is valid from the viewpoint of the business processing program to be executed, that is, a date and time when the data becomes valid (valid start date) and a date and time when the data becomes invalid (valid end date). The valid start date and the valid end date set in this way are collectively referred to as valid period information. By adding the validity period information, each business processing program can execute processing retroactively in the past.

Whether validity period information is set in the hierarchical node database is optional. Generally, the hierarchical node database is commonly accessed by various business processing programs. Therefore, set a date and time that is valid for all business processing programs that are accessed, or set multiple valid dates and times for the main business processing programs. You can select either to set or not to set at all. Conversely, when it is desired to set the validity period only for a specific business processing program, the validity period information on the hierarchical link table only needs to be adjusted, and there is no need to maintain such information on the hierarchical node database side. .

In summary, the present invention provides a hierarchical node database for storing data used in processing of a business processing program for executing a predetermined business in a data record as node data, A hierarchical link table provided correspondingly and holding, as a data item of a data record, association information defining a hierarchical structure between data nodes stored in the hierarchical node database.
Implemented by the system. This hierarchical link table can hold valid period information defining the valid period of each data record as a data item of each data record. Optionally, the hierarchical node database may hold such validity period information.

[0018]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The embodiments of the present invention will be described below. Here, for convenience of explanation, an embodiment applied to a system for calculating costs (such as a telephone charge) (discount processing) will be used. However, it should be noted that the present invention is not limited to such an embodiment, and can be applied to other embodiments as long as it is intended to construct a database system that is flexible against changes.

FIG. 1 is a block diagram for explaining a data processing system constituting the present invention. A business processing program 100, which is an application program for performing a specific business processing, includes a database management system 200
, Data necessary for the processing is acquired from the database system 300. In the database system 300 of the present invention, a hierarchical link table 310 is provided so as to correspond to each business processing program 100. The hierarchical link table 310 is a table that holds association information (pointers and the like) between databases (entities).
The information on the hierarchical structure of the hierarchical node database 320 having the data necessary for the processing of 00 is stored. The hierarchy node database 320 is a database that holds a data body that does not have such association information in principle. Although not shown, table information such as a cycle control table described later is also stored in the database 310.

Next, a database management method using a hierarchical link table according to the present invention will be described with reference to FIGS.

FIG. 2 is a diagram for explaining a relation between conventional databases (entities). Here, a hierarchical structure of a database in which the entity A is a parent and the entity B is a child is shown. In this conventional method, in the data record (instance) of entity B,
The pointer information indicating the parent entity A is held. Therefore, when the hierarchical structure is changed, it is necessary to correct the database B itself.

FIG. 3 is a diagram for explaining the association using the hierarchical link table of the present invention. Here, the entities A and B to be processed are constructed as a hierarchical node database having no pointer information. The relationship between the two is defined in a hierarchical link table X having pointer information separately. Therefore, even if the hierarchical structure is changed, it is not necessary to modify the database itself, but only the contents of the smaller hierarchical link table.

FIG. 4 is a diagram for explaining the hierarchical link table system of the present invention in comparison with the conventional system. In this figure, a certain business processing program uses a database composed of six entities (actually, instances thereof). Looking at the hierarchical structure, Entity 1 is the highest node, Entity 2 and 3 as child nodes under it, Entity 4 below Entity 2,
The entities 5 and 6 are located below the entity 3. When this data structure is described in a conventional manner, it is as shown in the middle column. As illustrated, in each data record (data field), pointer information indicating a parent-child relationship (specifically, indicating a parent entity) is stored in addition to the attribute information which is the data body. . If the same data structure is described in the hierarchical link table, it is as shown in the lower column. As shown, the pointer information is a data record (data field) of the hierarchical link table.
, And only the attribute information is held in the data record (data field) of the hierarchical node database.

FIG. 5 is a diagram for explaining the contents of the hierarchical node database. The hierarchical node database assigns a node ID (identifier) to each entity required for all business processing programs, and stores a data body as a node attribute for each entity. That is, the hierarchical node database holds data that can be commonly used by each business processing program in each data record (data field) as node data. Each business processing program can specify a necessary database and its hierarchical structure by referring to this node ID through the above-described hierarchical link table.

FIG. 6 is a view for explaining an embodiment of a hierarchical link table in a case where each business processing program has a different data hierarchical structure. The hierarchical node database used by the business processing program is shown here as "entity". Business processing program AP1
In the database used in, the entity 1 is the top node and the entities 2, 5, 4,
3 has a hierarchical structure connected in a relationship as shown. The hierarchical structure of the data relating to the AP1 is held by link information of links 28 to 31, which describe relationships between entities stored in the hierarchical link table T1. On the other hand, the database used in the business processing program AP2 has a hierarchical structure in which the entity 6 is the highest-order node and the entities 2, 1, and 4 are connected under the entity 6 in the lower layer. The hierarchical structure of the data relating to the AP2 is the hierarchical link table T2.
Link 3 describing the relationships between the entities stored in the
It is held by link information 2-34. As can be seen from this figure, the hierarchical link table of the present invention is:
It is created and stored for each business processing program.

FIG. 7 is a diagram for explaining the relationship between the business processing program, the hierarchical link table, and the hierarchical node database as described above. The hierarchical link table A is
It is provided corresponding to the business processing program A. The hierarchical link table A stores association information (hierarchical structure information) viewed from the business processing program A, validity period information described later, and the like. Based on this, the hierarchical node databases X, Y, and Z to be processed are accessed to obtain necessary data, and a specific task is processed using the data.

FIG. 8 is a diagram for explaining an example in which the database management system using the hierarchical link table of the present invention is applied to a toll service support system of a telecommunications carrier. Here, five business processing programs (AP1 to AP5) as illustrated are running for each customer. Since the hierarchical structures are different from the viewpoint of each business, a hierarchical link table corresponding to each business processing program is defined. The change of the hierarchical structure
It is possible to respond flexibly by changing the table. It should also be noted that a different hierarchical structure can be used (or more often) for each customer. Although not shown in the figure, each product / service in the basic contract service structure of the AP 1 is associated not only with the upper layer customer but also with the lowest layer of another structure. Some of these tasks will be described, and embodiments thereof will be described with reference to FIGS.

FIG. 9 shows a discount calculation operation (AP
It is a figure explaining the Example of the hierarchical structure in 2). Here, as shown in the product ID column of the hierarchical node database "product catalog", the hierarchy of the database is composed of seven nodes. In the figure, for example, there are two “attributes 4”, but this is described for convenience of reference, and does not mean that information having the same content is stored. Note that the hierarchical node database stores individual information corresponding to each node (FIG. 1).
0 is the same). Discount calculation business program AP shown in FIG.
The hierarchical structure of 2 is a hierarchical link table "discount structure 1"
Indicated by As can be determined from this table, here, there are three parent nodes “charge calculation 4”, “discount 5”, and “discount 6”, and the corresponding child nodes are defined. For example, discount 5 is applied to products /
For services 1 and 2 only, product / service 3
It can be seen that this does not apply to や and ４.

FIG. 10 is a diagram showing the billing totalization service (AP
It is a figure explaining the Example of the hierarchical structure in 4). Basically, the description similar to that of FIG. 9 is appropriate, except that a hierarchical node database called “organizational entity DB” exists here. Note that the hierarchical node database “product catalog” in FIG. 10 is described as being different from FIG. 9 for convenience of description, but may be the same database as FIG. 9.

In the above paragraphs, the database management system using the hierarchical link table of the present invention has been described. Below, as a more effective mechanism,
A database management method using “validity period information” will be described.

FIG. 11 is a view for explaining an embodiment in which validity period information is set in a data record (data field) of a hierarchical link table or a hierarchical node database. The validity period information refers to the period during which each data record in a table or database is valid as viewed from the corresponding business processing program. Usually, the date and time when the data record becomes valid (valid start date) and the date and time when it is no longer valid (valid end date) Day) as data. For example,
In the example of application to the hierarchical link table in the figure, the link 30 is valid from January 10, 1999 and remains valid until March 31, 1999. After this validity period ends, the parent-child relationship between the parent node 101 and the child node 103 also ends. On the other hand, the link 31 has been effective since April 1, 1999, and is still effective. Therefore, after April 1 of the same year, the parent node 101
The parent-child relationship between the child node 102 and the child node 102 is applied as valid.

In FIG. 11, validity period information is also set in the data record of the hierarchical node database. However, whether or not to set the validity period information in the hierarchical node database is optional. Generally, the hierarchical node database is commonly accessed by various business processing programs, so that a valid date and time can be set for all the business processing programs that are accessed, or a plurality of valid dates and times can be set for the main business processing programs. When it is set, it is meaningful to set the validity period information also on the hierarchical node database side. For example, there is a case where the provision of new products is started (or stopped) all at once from a specific date. Conversely, when it is desired to set the validity period only for a specific business processing program, it is sufficient to adjust only the validity period information on the hierarchical link table side, and the hierarchical node database stores such information. No need.

Since the business processing program executes the process by looking at the validity period information of the corresponding hierarchical link table, it does not mistakenly execute the process outside the validity period. For example, when the business processing program performs processing in a certain period unit (for example, records stored in one month are aggregated / calculated at the end of the month of the month).
During the month, the relationship / hierarchy between the data record in the database and another data record associated therewith may change (eg, customer A transfers one telephone number to another B) As in the case where a change in parent-child relationship / change of affiliation occurs at a so-called instance level). In the conventional method, it was necessary to run the business processing program once when the change occurred,
According to the configuration of the present invention using the validity period information, it is not necessary to execute such processing.

FIG. 12 is a view for explaining an embodiment to which a hierarchical link table in which validity period information is set is applied. Here, a description will be given assuming that the present invention is applied to the case of the above-described charge calculation / billing aggregation processing of a communication carrier. In this assumed case, based on customer service usage information (call information) from the 20th of the previous month to the 19th of the current month, 26
A charge / discount calculation is performed on a day (here, 7
Month is the current month). First, (a) charge calculation / discount calculation when there is no change in the middle of the month will be described. The business processing program converts the call information from June 20 to July 19 on the 26th, which is the charge calculation / billing total date, according to the instructions of the cycle control table (cycle control table) as necessary. Select and perform charge calculation / discount calculation, and link the execution result under Discount 1. When a series of business processes are executed at fixed time intervals (yearly, quarterly, monthly, weekly, daily, etc.), the cycle control table indicates the execution timing and time interval ( Cycle) is a table (a type of database) for describing the cycle. Although not particularly shown, by using such a cycle table and designating an identifier (also referred to as a product ID) of a business processing program in the table, a hierarchy that can be flexibly managed under the present invention is provided. By using the structure, a necessary business processing program can be automatically executed.

Next, (b) charge calculation / discount calculation when a change is made in the middle of a month will be described. Here 7
It is assumed that the contract under the previous service (discount 1) ends on the 13th of the month, and the contract under the new service (discount 2) starts on the 14th of July. In the control from the normal cycle control table, the call information from June 20 to July 19 is selected to calculate the charge / discount. Since the effective end date of the hierarchical link table indicating (contract status) is July 13, only the calculation from June 20 to July 13 is performed. The result is linked below Discount 1. As for discount 2, charge is similarly calculated for the period from July 14 (until the same day as 19) specified in the validity period information of the hierarchical link table, and the result is linked under discount 2. deep.

Regarding (c) billing totaling, billing 1 (billing totaling program) is based on data records (discount 1 and discount 2) of a hierarchical node database called “discount” linked to its own lower layer. ), The billing amount can be calculated only by summing up the calculation results linked to them, and the billing process for the company 2 as the customer can be executed based on this.

FIG. 13 is a diagram for explaining an embodiment of a variable-length column for further improving the flexibility of the database management system according to the present invention. All or a major part of the hierarchical node database described above can be in the same record format database format consisting of fixed length columns and variable length columns. Specifically, in the fixed-length column of each data record, only essential data items whose data size is always constant, such as a record identifier (node identifier) and validity period information, are stored. All attribute information is stored in variable-length columns. By doing so, it is possible to standardize the record format of various types of entities such as customers, services, facilities, etc., consolidate them into a very small number of super types, and reduce the burden of database maintenance and management work . In FIG. 13, in order to facilitate the maintenance and management of the equipment database of the telecommunications carrier and to ensure the flexibility for changes,
An example is shown in which the type and attribute information of the facility-related entities are all stored in the variable-length column portion, and only the validity period information is stored in the fixed-length column portion, so that various entities have the same database structure. be able to.

While the advantages of the present invention have been described in terms of several embodiments, there are additional advantages. The point is that it is possible to control processing targets that are logically separated and independent from each other for each business process. This will be described with reference to FIGS. 14 and 15 while referring to some of the tasks shown in FIG.

FIG. 14 is a diagram for explaining an embodiment in which the database management system of the present invention is applied to a rebate amount calculation which is one of the fee operations of a communication carrier. What is rebate calculation?
It refers to a calculation process for charging a fee (including a discount calculation) calculated for each customer to a billing destination (rebate destination) specified by the customer at a rate specified by the customer. In FIG. 14, (a)
Is separated from the charge calculation / discount calculation hierarchical structure of (b) and the billing hierarchical structure of (b) by defining another hierarchical link table. In operation, the charge calculation in (a) /
Based on the discount calculation hierarchical structure, charges are calculated according to various discount services, etc., and based on the billing hierarchical structure of (b),
Charge a fee according to the method specified by the customer. As a result, for example, the customer can specify and change the billing destination in (b), so that the flexibility for the change is increased, and the maintenance of each hierarchical structure is also facilitated. Usually, the charge calculation / discount calculation hierarchical structure of (a) is determined by the specification of the product / service, and the billing hierarchical structure of (b) is determined by the organization and location of the customer. In this figure, the rebate at the time of discount calculation is a simple proportional distribution, and a discount amount aggregation hierarchy structure is prepared separately from the pre-discount charge aggregation hierarchy structure at the time of billing amount aggregation. Various discount distribution (rebate) methods, ie, proportional distribution (contribution distribution) /
The same amount / special allocation can be flexibly realized.

FIG. 15 is a diagram for explaining another embodiment in which the database management system of the present invention is applied to a charge business of a telecommunications carrier. This figure shows an example in which the billing structure and the reporting structure of each customer are defined arbitrarily and independently of each other by using separate hierarchical link tables. The relationship / hierarchical structure between the databases used for the billing process is also called a billing group structure. This billing group structure conventionally requires a modification work every time a customer's request changes, and many related database changes are made. It was a task that required a lot of operation. However, if this association is defined using a hierarchical link table, only the small hierarchical link table needs to be changed, so that the change operation can be easily performed. That is, it can be said that the system of the present invention having the method of defining the billing group structure by the hierarchical link table can flexibly cope with a change in customer requirements.

Here, the “claim” business processing program is:
As billing (billing 1) processing to customer a, which is a customer,
Customer a, the department under it x. . . The charge calculation results of the service used in y are totaled and charged to the address of the customer a. The “report” business processing program provides the customer a, the department x. . . The result of the aggregation of y (and the details) is reported to the address of the customer a.
Report the result (and details) of department y to the address of department y.

[0042]

As described above, according to the database management system employing the hierarchical link table of the present invention, addition or change of business contents or related data (including information on service contents and customers) is performed. A flexible and prompt database system is provided. Further, by further providing the configuration of the validity period information of the present invention, even in the case where the above addition / change occurs in the middle of the period to be processed, the process retroactively to the past data is appropriate and prompt. , It can be done easily.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a data processing system constituting the present invention.

FIG. 2 is a diagram for explaining a relation between conventional databases (entities).

FIG. 3 is a diagram for explaining association using a hierarchical link table according to the present invention.

FIG. 4 is a diagram for explaining a hierarchical link table method of the present invention in comparison with a conventional method.

FIG. 5 is a diagram illustrating the contents of a hierarchical node database.

FIG. 6 is a hierarchical link provided for each business processing program.
It is a figure explaining a table.

FIG. 7 is a diagram illustrating the relationship between a business processing program, a hierarchical link table, and a hierarchical node database.

FIG. 8 is a diagram for explaining an embodiment in which the present invention is applied to a toll service support system of a telecommunications carrier;

FIG. 9 is a diagram illustrating an example of a hierarchical structure in a discount calculation operation in FIG.

FIG. 10 is a diagram for explaining an embodiment of a hierarchical structure in the billing task in FIG.

FIG. 11 is a diagram illustrating an embodiment in which validity period information is set in a hierarchical link table or the like.

FIG. 12 is a diagram illustrating an example of a hierarchical link table in which validity period information is set.

FIG. 13 is a diagram illustrating an embodiment of a variable-length column according to the present invention.

FIG. 14 is a diagram illustrating an embodiment in which the present invention is applied to a rebate calculation operation of a communication carrier.

FIG. 15 is a diagram illustrating another embodiment in which the present invention is applied to a charge business of a communication carrier.

[Explanation of symbols]

100: business processing program, 200: database management system, 300: database system, 310: hierarchical link table, 320 ...
・ Hierarchy node database

Claims (5)

[Claims] 1. A database system for storing and managing data used in the processing of a business processing program for executing a predetermined business, wherein the data used in the processing of the business processing program is stored in node data. As a hierarchical node database to be stored in the data record, and provided for each of the business processing programs,
A hierarchical link table that holds, as a data item of a data record, association information defining a hierarchical structure between data nodes stored in the hierarchical node database. 2. The hierarchical link table holds validity period information defining a validity period of each data record as a data item of each data record.
Database system as described in. 3. The hierarchical node database stores valid period information defining a valid period of each data record as a data item of each data field.
The database system according to claim 1. 4. Each data record of the hierarchical node database has a fixed length column for storing only data items having a fixed data size, and a variable length column for storing data having a variable data size. 1 to 3
The database system according to any one of claims 1 to 4. 5. The system according to claim 1, further comprising a cycle control table having cycle information defining execution timing of a business processing program in which business processing is executed at a predetermined time interval. Database system.