MXPA98003639A - Apparatus and method for maintaining consistency of data integrated through multiple bases of da - Google Patents

Abstract

The present invention relates to a database network having a primary database and a plurality of heterogeneous subscriber databases for replicating data updates of the primary database in the heterogeneous subscriber databases that include a device of database connected to the primary database to capture the data updates in the primary database, a request manager connected to the database device to generate requests, where each of the requests is translated into base to a specified format for each of the heterogeneous subscriber databases, and a data distributor connected to the request manager to distribute the translated requests to the heterogeneous subscriber databases

Description

APPARATUS AND METHOD FOR MAINTAINING CONSISTENCY OF INTEGRATED DATA THROUGH MULTIPLE DATABASES BACKGROUND OF THE INVENTION This invention relates to the synchronization of several databases in a network. More particularly, the invention relates to the synchronization of replicated data through heterogeneous databases in a communication network. Many types of databases are known. There are relational model databases, hierarchical model databases, network model databases and many other database models. Among the available database models, the relational model is the most popular model. In the relational database model, the database is divided into two areas - physical model and logical model where the physical model is based on each entity, and the logical model is based on the relationship of the entity. The physical and logical models are then used to generate a physical structure of a relational model database. The hierarchical model has structured data in a parent-child relationship where the child's data can REF: 27025 # be accessed only through the parent. Therefore, in a hierarchical database, the access to a child entity depends on the fact that the parent entity can only be accessed, if the key that the parent entity sends to 5 is available. In contrast, in the relational model, the data of any entity can be accessed insofar as there is an appropriate key that leads to such a database. For example, a way to have access to a relational database is the well-known defining request language called structural request language ("SQL" or Sequel). But for the hierarchical database, since there is no relationship connecting the entities, a very specific function is required to request access to each entity by providing the segment key or by providing some other type of identifier to access the parent of the entity. Once the parent is accessed, the child segment can be examined or a number of segments can be called directly to locate the entity. If the entity is still in another child segment, the search continues down to a deeper level until the entity is located. The network model is similar to the relational model. The entities are related, all of them, where the The relationship between the segments is called owner and membership. The owner has many members and each member can own other members. Other database models include a registered database model and an object-oriented database model. The proprietary database model can be of any construction that is suitable for the use of the particular programming elements of the vendor. Therefore, the registered model can have any of the combined characteristics derived from the relational, hierarchical and network models or it can have a structure totally different from any of the traditional database models. Since the significant amount of replicated information resides between network elements, operating systems, billing and support systems, it is important that the replicated copies of primary data are synchronized with the primary data. However, the maintenance of consistent replicated information becomes more difficult when the network elements can be of any type of the subscribed database models such as the relational model, the hierarchical model or the network model. In the telecommunications industry, a standard interface called open data base connectivity ("ODBC") is used for communication between various types of platforms such as IBM main arrays and unique workstations. However, ODBC is not useful if the databases of these different platforms are of a different type. For example, when the primary database is relational and the subscriber databases are hierarchical, the updated data in the primary database may not propagate because the # primary database uses the request language structural ("SQL") while the subscriber databases do not recognize SQ L. The inconsistency of data between database models, when presented, not only causes significant losses in revenue from one point of view business, but also requires an extremely high cost manual data synchronization. In addition, manual data synchronization involves the human service and can cause more data inconsistency problems. The systems currently available for updating subscriber databases are designed for homogeneous databases. Current systems also use the protocol called "double agreement". The double agreement means that the subscriber database update occurs only when the whole of the subscriber's databases can be updated.

# Although this type of system provides that all subscriber databases at all times contain the same information, database updates may not propagate to the databases that need the 5 updates due to a failure in recognition from the databases. databases that do not need the updates. In addition, if a single subscriber database fails to recognize an update availability, it prevents all of the rest of the subscriber databases receive database updates. Therefore, it is an object of this invention to provide an efficient system and method that accurately and quickly synchronize heterogeneous databases in a network. A further objective of this invention is to provide a system and method that correctly propagates the updates in the primary data only to subscriber databases that the updates.

BRIEF DESCRIPTION OF THE INVENTION These and other objects of the invention are carried out in accordance with the principles of the invention by providing a database network having a primary database and a plurality of heterogeneous subscriber databases for updating replicating data. of the primary database in the bases of 5 heterogeneous subscriber data. The database network includes a primary database device connected to the primary database to capture the data updates in the primary database. A # request manager connected to the base device data to generate requests translates the requests based on a format specified for each of the heterogeneous subscriber databases. A data distributor connected to the request manager distributes the translated requests to the databases heterogeneous subscribers. The database network may further include a subscription controller to verify that at least one of the subscriber databases needs the updates made in the primary database of the subscriber database. so that the requesting agent generates only requests for subscriber databases that need the updates. The database network can also include a synchronization manager to control the sequences of the row distribution where each row is "categorized as an immediate or deferred row based on the time sensitivity of the request. The row can be categorized as a retry row if the previous transmission failed. Further features of the invention, its nature and various advantages will become more apparent from the accompanying drawings and the following detailed description of the preferred embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a simplified block diagram of the illustrative network which may operate in accordance with this invention. Figure 2 is a more detailed block diagram of the integrated data consistency server illustrative of the network of Figure 1. Figures 3-5 are a flow chart of the steps for carrying out an illustrative embodiment of the method of this invention.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES In the illustrative embodiment shown in Figure 1, the database network 100 of the present invention includes the primary system 102 connected to the subscriber systems 104 by means of a communication network 106. The primary system 102 contains the primary application 108, the primary database device 110, the primary database 112, and an integrated data consistency server 114. The primary database device 110 detects transactions in the # application 108 primary that causes updates in the database 112 and captures the updates to be sent to the integrated consistency server 114. At the time of receiving the updates, the integrated consistency server 114 runs the steps illustrated in Figures 3 and 4, while they are performed update database transactions in primary database 112. The communication network 106 supplies the processed results of the integrated data consistency server 114 to the base devices 116, 118 and 120 appropriate data from the 104 subscriber systems. For example, the subscriber systems 104 include database devices 116, 118, and 120 attached to the hierarchical database 122, the relational database 124, and the network database 126. You can add many other types of databases to 104 M subscribers systems. Each of the database devices 116, 118 and 120 receive updates from appropriately formatted databases and updates the hierarchical database 122, the relational database 124 and the base 5 of network data 126, respectively. Figure 2 shows an integrated data consistency server 114 (Figure 1) connected to a primary database device 110 (Figure 1) and a communication network 106 (Figure 1) in more detail.

Embedded data consistency server 114 includes the subscription controller ("SC") 200, the request manager ("QM") 204, the update rows ("A") 206, the row controllers ("Qc" ) 208, the concurrency controller ("CC") 210, a data distributor ("DD") 212 and a response handler ("RH") 214. The subscription controller 200 is connected to the database device 110 and receives the data updates captured or recorded by the primary database device 110. Based on the data updates captured, the subscription controller 200 determines whether the data updates need to be propagated in any way. Data updates need to be propagated if any of the databases 122, 124 and 126 need the data updates for your application.

Based on the findings of the subscription controller 200, the request handler 204 connected to the subscription controller 200 generates requests only for the databases that need the 5 updates. The request manager 200 then determines which of the subscriber databases require translations and subsequently translates the requests into appropriate formats based on the types of subscriber database models. The request manager 202 is connects to the synchronization manager 204 so that when a request is generated, a note alerts the synchronization manager 204. The update rows 206 connected to both the request manager 204 and the manager 204 of synchronization stores the generated requests of the request manager 204. Each row contains the number of updated transactions ("A") which indicates the total update transactions stored in each update row. Each of the row controllers 208 is connected to each of the corresponding update rows 206 and the synchronization manager 204. Therefore, the number of controllers in row indicates the number of rows present waiting for a transmission to the subscription system 104.

# The concurrency controller 210 connected to the row controller 208 and the synchronization manager 204 controls the openings of the distribution channel of the data distributor 212 and contains information of the control level ("Cl") which indicates the number of channels of the control. distribution available. The data distributor 212 connects to both the concurrent controller 210 and the synchronization manager 204 and distributes updates in the rows to the subscriber systems 104. The communication network 106 connects the data distributor 212 and the subscription systems 104. The communication network 106 may contain various types of communication means such as underground telecommunication links 15, and satellite links. The communication network 106 may also contain a subnetwork such as a computer network or a cable television network. The functions of the subscription controller 200, the request manager 204, the update row 206, the row controller 208 and the concurrency controller 210, the data distributor 212 and the response handler 214 are also illustrated with respect to the stages in figures 3 and.

Figure 3 shows an illustrative sequence of the steps according to this invention to update the subscriber systems 104 (Figure 1) with the data updates performed on the primary system 102 (Figure 1). However, in order that the steps are not critical and can be placed in various different ways without compromising the operation of the heterogeneous database network 100 (Figure 1) of this • invention. 10 In step 300, the primary application 108 (figure 1) processes transactions that require database updates in the primary database 112 (figure 1). In step 302, the base device 110 The primary data (figure 1) detects the database update transactions and captures the data updates that are going to be made in the primary database 112 (figure 1). In step 304, the primary data base device 110 passes the captured data updates to the subscriber controller 200 (FIG. 2) while updating the primary database 112 (FIG. 1). In step 306, the subscriber controller 200 (Figure 2) determines the subscription of systems 104 of Subscription (figure 1), that is, if any database in the subscription systems 104 (figure 1) is affected by the update transactions. The subscriber controller 200 (FIG. 2) in this manner determines whether any of the subscriber databases 5 122, 124 and 126 need the updates that are performed in the primary database 112 (FIG. 1). If none of the databases 122, 124 and 126 subscribers (Figure 1) needs the updates, the server 114 of integrated data consistency (Figure 1) becomes inactive and returns to step 302 to wait for the detection of a database device 110 (FIG. 1) for the next update transaction in the primary system 102 (FIG. 1). If any of the subscribing databases 122, 124 and 126 (Figure 1) need the updates of the primary database 112 (Figure 1), then the request manager 202 (Figure 2) in Step 308 receives the updates. In step 310, the request manager 202 (Figure 2) retrieves the registration data from the primary database 112 (Figure 1) or, alternatively, a separate database (not shown) that contains the registration data. The registration data contains information about databases 122, 124 and 126 (Figure 1) of the subscription system 104. The registration data also * contain predetermined or sample request descriptions that can be used by the request manager to construct the appropriate requests for each of the subscriber databases 122, 124 and 126 (Figure 1). In step 312, the request manager 202 (Figure 2) generates a database request for each of the databases 122, 124 and 126 (Figure 2) in the • Subscription system 104 (figure 1) based on the data records recovered. For example, database requests are constructed in the standard structured query ("SQL") language designed for relational database. Using information from databases of the subscriber, the request manager 202 (Figure 2) performs request translations of a general request received from the primary database LID device (Figure 1) to a request that is recognizable by the subscriber databases 122, 124 and 126 (figure 1). The format for translations is defined by subscriber devices 116, 118 and 120 (figure 1). The synchronization manager 204 (FIG. 2) in step 314 determines whether the request has an immediate mode, that is, it requires immediate attention so that the request is distributed rapidly to the subscriber systems 104 (FIG. 1). If this is not the case, the synchronization manager 204 (figure 2) establishes a date range and time for each request so that the row containing such request can be distributed on the date and time previously specified. In step 318, the synchronization manager 204 (FIG. 2) in step 318 stores the translated 10 requests in the update rows 206 (FIG. 2) wherein the request with the immediate mode is placed in an immediate row, and the request with specified date and time is placed in a deferred row. The update rows 206 (FIG. 2) therefore are in any of three of the following categories: immediate row ("I"), delayed row ("D") and retry row ("R"). The retry row is established when the recognition of the subscriber systems (Figure 1) indicates a failure in the transmission process and 20 is described in greater detail with respect to Figure 5. In step 320, the synchronization manager 204 ( figure 2) confirms that the request has been generated in the rows.

If this is not the case, the synchronization manager 204 (Figure 2) returns to step 312 to place the request in a row. If confirmed, the synchronization manager 204 (Figure 2) determines whether there are more subscriber systems 104 that need the request containing the updates in the primary system 110 (Figure 1). If there is a subscriber system 104 (figure 1) that needs the update request, then the synchronization manager 204 (figure 2) returns to step 310 to generate a request for the additional subscriber system (figure 1) based on the specific registration data for the 104 additional subscriber system (figure 1). 15 If there is no subscriber system 104 (Figure 1) that requires the updates, the synchronization manager (Figure 2) in step 324 increases the number of update transactions ("A") in one. In step 326, the synchronization manager 104 (Figure 2) determines that all the subscriber systems 104 (Figure 1) that need updates already have translated requests in rows waiting to be transmitted to the subscriber systems 104 (Figure 1). If this is not the case, the synchronization manager 104 (Figure 2) returns to step 308, so that the request manager 202 (Figure 2) reviews the updates that were received from the primary system 102 (Figure 2). If all the necessary rows have been generated to update the subscriber systems 104 (Figure 1), the synchronization manager 104 (Figure 2) in the stage 328 is urged to move forward with the distribution as described in more detail with respect to Figure 4.

• With reference to Figure 4, the synchronization manager 204 10 (Figure 2), in step 400, constantly checks the status of the requests in the rows 206 (Figure 2) that need to be transmitted. The synchronization manager 204 (FIG. 2) verifies the status of the row by first determining in step 401 whether there is any row in the row controller 208 (FIG. 2) having the immediate mode. If there is any row that has the immediate mode, the synchronization manager 204 (Figure 2) in step 402 selects the totality of rows with the immediate mode and group them for transmission to the systems 104 subscribers (figure 1). For each of the databases 112, 124 and 126 (Figure 1), synchronization manager 204 (figure 2) in step 404 processes the verification of concurrency when determining first in step 406 whether the number of update transactions, Un, is greater than or equal to l, that is, if there is at least one update in the row. If there is at least one update transaction in the row, the synchronization manager 204 (FIG. 2) in step 408 determines whether the number of requests subtracted by the concurrency level is greater than 0. The synchronization manager 204 this • way verifies if the concurrency driver 210 (Figure 2) can handle the number of requests handled by the request manager 202. If it is found that the concurrency controller 210 (Figure 2) can handle the number of requests handled by the request manager 202, the synchronization manager 204 (figure 2) in step 410 allows the concurrency controller 210 (figure 2) to open the distribution channels for rows and the data distributor 212 (figure 2) distributes the updated transaction, formatted for each one of the database devices 116, 118 and 120 (figure 1) of subscriber system 104 (figure i) via communication network 106 (figure 1). The synchronization manager 204 (figure 2). Returns to step 400 to determine if they have been processed the totality of the rows with the immediate mode.

# If there are no more immediate rows, the synchronization manager 204 (FIG. 2) in step 412 selects and groups the entire retry rows in the update rows 206 (FIG. 2). The synchronization manager 204 (FIG. 2) in step 414 determines if any retry row of step 412 is found. If not, the synchronization manager 204 (FIG. 2) advances to the • step 422 to process the rest of the rows which 10 may be deferred rows at this point. If any retry row is found, the synchronization handler 204 (FIG. 2) in the step 416 examines the retry row by verifying that the retry count does not exceed the maximum account number predetermined. If the retry account exceeds a predetermined maximum number of requests, the synchronization manager 204 (Figure 2) requests in step 418 a notice to a system administrator that the retry count exceeds the maximum number. This stage ensures that transmission resources and row resources are not wasted in rows that are directed to lost or defective subscriber systems. If the retry count does not exceed the maximum number of requests, the synchronization manager 204 (figure 2) determines whether the date and time appended to the row are valid, that is, in the date and time they are within a certain interval. assigned to the distribution of data. 5 If the date and time are within the specific range assigned for the data distribution, the synchronization manager 204 (Figure 2) proceeds to step 404 for concurrency verification and subsequent distribution. 10 If the data and time are not within the specific range assigned for data transmission, the synchronization manager 204 (Figure 2) proceeds to step 422 to select and group deferred rows. Subsequently, the manager 204 of The synchronization proceeds to step 404 to verify subsequent concurrency and distribution. Figure 5 illustrates the distribution process to subscriber systems 104 (Figure 1) that will be discussed in relation to step 410 in more detail. 20 In step 500, in the data distributor 212 (figure 2) transmits the update transaction request, the status of the shipment request is recorded to the records with date and time. The update request that is sent to the systems 104 subscribers (figure 1) requires recognition and * T of the database requests (figure 1) that the recognition be returned. The acknowledgment indicates whether the subscriber systems have received the transmitted request with the following 5 symbols: update of completed request ("Uc") or update of failed request ("Uf"). In step 502, the response handler 214 (FIG. 2) receives the recognition of the database device 116, 118 or 120, and records the recognition. 10 In step 504, the response handler 214 (Figure 2) activates synchronization manager 204 (Figure 2) to maintain current information with recognition. The synchronization manager 204 (FIG. 2) 15 in step 506 determines whether the acknowledgment for each request indicates that the request transmission was successful and completed. -If the acknowledgment indicates that the request transmission is a failure, the manager 204 of synchronization (FIG. 2) in step 508 moves the row so that the retry row will be picked up for transmission again in step 326 (FIG. 3). If the synchronization manager 204 (Figure 2) receives the recognition that indicates a successful transmission, the synchronization manager 204 (Figure 2) in step 510 removes the row from the update row 206 (Figure 2) and decreases the level of concurrency control in the concurrency controller 210 (Figure 2) in one . It will be understood that the foregoing is only illustrative of the principles of the invention and that various modifications may be made by those familiar with the art without departing from the scope and spirit of the invention. It is noted that in relation to this date, the best method known by the applicant to carry out the aforementioned invention, is the conventional one for the manufacture of the objects to which it relates: The invention having been described as above, Claims as property what is contained in the following:

Claims (14)

CLAIMS:

1. A database network that has a primary database and a plurality of databases 5 heterogeneous subscribers to replicate data updates of the primary database in the heterogeneous subscriber databases, characterized in that: a database device connected to the * primary database for capara: updates of 10 data in the primary database; a request handler connected to the database device to generate requests, each of the requests is translated based on a specified format for each of the databases 15 heterogeneous subscribers, - and a data distributor connected to the request manager to distribute the translated requests to the heterogeneous subscriber databases.

2. The database network according to claim 1, characterized in that it further comprises: a subscription controller to verify that at least one of the databases subscribes the needs of the updates, - and T - 24- • a request controller to generate requests only for at least one of the subscriber databases that need updates.

3. The database network according to claim 1, characterized in that it comprises a synchronization manager connected to the request manager to control the request distribution.

4. The database network according to claim 3, characterized in that it further comprises a plurality of update rows connected to the request handler for storing the generated requests of the request handler. 15-jgjjji

5. The database network according to claim 4, characterized in that it comprises a row controller connected to the update rows to prioritize rows in distribution.

6. The database network according to claim 5, characterized in that it further comprises: a concurrency controller connected to the row controller to open distribution channels of the distributor; and the synchronization manager activates the concurrency controller only if the rows can be handled by the concurrency controller.

7. The database network according to claim 3, characterized in that it further comprises: a response handler to verify the complication of updates in the subscriber's database; and 10 the synchronization manager to redistribute the requests if the updates in the subscriber databases fail.

8. A method for replicating data updates of a primary database in a plurality of heterogeneous subscriber databases in a database network having the primary database and the heterogeneous subscriber databases, characterized in that it comprises: capture data updates in the primary database; generate requests, each of the requests is translated based on a format specified for each of the heterogeneous subscriber databases; and # distribute translated requests to heterogeneous subscriber databases.

9. The method according to claim 8, characterized in that it further comprises the steps of: verifying that at least one of the subscriber databases needs updates; and generate requests only for at least 10 of the subscriber databases that need the updates.

10. The method according to claim 8, characterized in that it also comprises the 15 stage of controlling the application distribution.

11. The method according to claim 10, characterized in that it also comprises the step of storing the requests generated from the 20 request manager.

12. The method according to claim 11, characterized in that it comprises the step of prioritizing the rows in distribution.

13. The method according to claim 12, characterized in that it also comprises the steps of: opening distributor distribution channels; and activate the distribution channels only if the rows can be managed by the distribution channels.

14. The method according to claim 10, characterized in that it also comprises the steps of: verifying the completion of the updates in the subscriber databases; and 15 redistributing the requests if the updates in the subscriber databases fail. . A database network having a primary database and a plurality of heterogeneous subscriber databases 5 for replicating data updates of the primary database in the heterogeneous subscriber databases that include a connected database device with the primary database to capture data updates in the database 10 primary, a request manager connected to the database device to generate requests, where each of the requests is translated based on a format specified for each of the heterogeneous subscriber databases, and a data distributor 15 connected with the request manager to distribute the translated requests to the heterogeneous subscriber databases.