JP2002175327A - Method for managing database - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide database management technology, capable of unitarily managing databases arranged distributedly over a network. SOLUTION: An integrated object repository server requests the extraction of various information by a query language (e.g., a query language, based on an XML base) to distributed databases connected with a network by using meta-index information owned by the server itself, e.g. the address of a target database, the specific ID of a target person. Information obtained by the inquiry is mapped on the meta-index information stored in an integrated object repository, so that a plurality of pieces of information arranged distributedly in a plurality of databases(DBs) can be unitarily referred to, as though they have been collected to one place.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a cross-sectional management method for various databases distributed on a network such as the Internet.

[0002]

2. Description of the Related Art Recently, various types of information have been converted into electronic data and databases.

In such a database, the determination of the target area and the determination of the database schema are as follows:
It is left to the arbitrariness of the creator.

[0004] That is, the sole purpose is to store and process and use information in a target area that is deemed to be useful for the creator, and other information is often discarded.

[0005] For example, even when the scope of authority is clearly divided, such as an administrative unit or an organizational unit, it is usual to create a database limited to the area of authority.

[0006]

However, such a database creation centered on the creation subject often causes a phenomenon that various attribute information related to the same entity are distributed and arranged in different databases on a network. I have.

For example, as shown in FIG. 1, a first database (DB)
In 1), a first attribute (for example, occupation), a second attribute (for example, hobby), and a third attribute (for example, family composition) of a person are registered, and in the second database (DB2), a fourth attribute is registered. (For example, educational background) and the fifth attribute (for example, possession qualification) are registered.

[0008] In a situation where the database of persons is dispersed in this way, from the standpoint of the information collecting side (database searcher), various attribute information belonging to the same entity crosses the database (database transparent). There is a demand that we want to collect.

In the above example, when a database searcher wants to collect data on a person's occupation, family structure, and possession qualifications, he first accesses the first database (DB1) to determine the occupation (first attribute). A family structure (third attribute) is extracted, and a second database (DB2) is accessed to extract a holding qualification (fifth attribute), and a new database (DB) is created based on the attribute information obtained thereby.
n) had to be constructed.

However, in actual work, the database is complex and diversified, the attribute information is enormous, and it is difficult for the searcher to confirm the location of each database. (DB
Construction of n) was virtually impossible.

The present invention has been made in view of such a point, and it is an object of the present invention to provide a database management technique capable of centrally managing databases distributed on a network.

[0012]

SUMMARY OF THE INVENTION The present invention manages a distributed database across an integrated object repository server using an integrated object repository server. Using a location address of the database, a specific ID of the target person, and the like, a query language (for example, XM
L-based query language) to request extraction of various information. Then, the information obtained by the inquiry is mapped under the meta index information on the integrated object repository, and the information distributed and arranged in a plurality of DBs can be referred to in a unified manner as if they were aggregated into one place. .

[0013]

BEST MODE FOR CARRYING OUT THE INVENTION

[0014]

Embodiments of the present invention will be described below with reference to the drawings.

FIG. 2 shows the overall configuration of this embodiment. As shown in the figure, the system configuration of the present embodiment mainly includes a network based on the Internet, and includes an integrated object repository server, database servers 1 to n, and web clients 1 to n connected thereto.

Next, a method of storing index information in the integrated object repository server will be described with reference to FIG.

First, a relation from the integrated object repository server to the index information on each distributed database is set for records identified as the same person using the person as a key. Next, the meta index information is stored on the integrated object repository server. As a result, a basic index is created for integrated management of the entity database separately stored on the distributed database, on the integrated object repository server.

Next, as shown in FIG. 4, each of the distributed databases is XML-based using meta-index information (location of the target database, target person identification ID, etc.) constructed on the integrated object repository server. Request the extraction of various information using the query language. And
The information obtained by the inquiry is mapped under the meta index information on the integrated object repository server. And the information distributed in multiple databases is
It is possible to refer centrally as if they were collected in one place.

In this way, as shown in FIG. 5, a new relationship that does not exist in the distributed database can be defined on the integrated object repository server.
As a result, the integrated object repository server plays a role that goes beyond the mere merging of entities on the distributed database.

For example, (1) when the person B is a spouse of the person A, if a relationship called “spouse relationship” is defined between the person A and the person B, the credit management information including the spouse can be obtained. Etc. can be obtained. (2) If it is determined that the person B is a pseudonym and is actually the same person as the person A, a relation “same person” is defined between the person A and the person B. Thus, it is possible to acquire integrated information that goes beyond a simple name identification function.

FIG. 6 is a table showing a method of storing meta index information on the integrated object repository server.

In the figure, the class includes "class name", "attribute name", and "relation" as minimum information.
Has "connection class". “Class name” is a name for identifying the class from other classes, and “attribute name” is attribute information held by the class.

A "relation" is a relationship set between classes, and a "connection class" represents a class of a connection destination related by the relation.

According to the above example, the class “user” is related to the class “DB information” by the relation “owned”, and “user” is “spouse-related” and “guarantor”. It is possible to associate with "user" by the relation "relationship." In addition,
The number of relations that can be defined is not particularly limited.

Here, an instance in which a concrete attribute value is given to a class and instantiated is called an instance. The contents described in FIGS. 3 to 5 using FIGS.
Explain how it is instantiated.

On the integrated object repository server, only instances of the user class as shown in FIG. 7 are held as meta index information.

Next, the DB information of each user existing in the distributed database is referred to the real database each time in response to a request from the web client, and an instance of the DB information class is set as a mapping of the real database (temporarily). ).

FIG. 8 is a table configuration showing an instance of the DB information class relating to the person A. FIG. 9 is a table configuration showing an instance of the DB information class relating to the person B.

The user instance and the DB information instance appear to be related as shown in FIG. 10 by the meta index information (the relation of “holding”) on the integrated object repository server.

At this stage, a view is provided in which data on the distributed database is simply "name-named" under the same person.

Here, the "spouse relationship" defined in the "user" class on the object repository
Pay attention to the relation of "guarantor relationship."

Originally, the DB information of each person is distributed and arranged on a physically separated database, and such a relationship is not defined between the information, but each distributed information is distributed on the integrated object repository server. A new relation can be defined independently of the definition in the database.

For example, when it is found that the person B has a spouse relationship with the person A, as shown in FIG. 11, the person B is set as the connection instance destination of the relation “in a spouse relationship” of the instance of the person A. Just specify it.

By this operation, not only the person B but also the database information relating to the person B having a spouse relationship can be transparently accessed on the integrated object repository server as shown in FIG.

FIG. 13 is an example of a display screen for defining a new relationship on the object repository, and FIG. 14 is an example of a display screen of a new view across the database obtained thereby.

FIG. 15 is a functional block diagram of the integrated object repository server.

As shown in the figure, the integrated object repository server comprises a database operation instruction device, an integrated object repository operation / maintenance / management device, a real database search device, and an integrated object repository database.

The database operation instruction device is a device that the user directly confronts through a user interface, and basically uses a web browser application program.

There are provided a user interface for an administrator who can systematically manage the integrated object repository server itself, and a user interface for a general user who only utilizes object repository information.

Operation, maintenance, and operation of the integrated object repository
The management device has a function of storing meta-index information in which index information of data stored in the distributed real database group is associated with a request from the database operation instruction device. It is also possible to define entirely new relationships between objects in the object repository. This device has a function of issuing a data search request to the real database search device, receiving a search result from the real database search device, and mapping it on the integrated object repository.

The integrated object repository database is an entity of an integrated database that holds meta-index information and relationship information of data stored in a real database group.

The real database search device has a function of issuing a query language such as an SQL statement to the real database group in response to a search request from the integrated object repository operation / maintenance / management device, and receiving a search result. .

The real database group indicates a database group distributed and arranged outside.

The means for realizing the cross-database integrated object repository using each of these functional units is understood from a collaboration diagram (FIG. 16) in terms of objects and message flows, and the same contents are understood as a sequence on a time axis. Sequence diagram (Figure 1)
7). (1). Search request First, a search request is issued by setting search conditions from the browser program of the integrated object repository server. (2). Search analysis Next, the browser control module of the integrated object repository server analyzes search requests from the browser.
Integrate. Various search conditions set by AND conditions (logical product conditions), OR conditions (logical sum conditions), etc. are converted into a format that can be processed by business logic and delivered. (3). XML search request The search request analyzed and integrated by the browser control module is converted into an XML search request. (4). Metadata search request (native) API (Application Program Interface) provided by integrated repository by XML data access module
Sends a request to obtain the meta index information stored on the integrated repository. Here, the expression "native" means that information is acquired using an API provided by the repository system for an external inquiry. Hereinafter, the expression "native" is also used for the query part for the distributed unique database, but this is also an API provided by various database vendors.
Means that information is obtained through (5) Metadata search Receives a metadata search request via the repository API and issues a search request to the actual integrated repository. (6). Search Result The metadata search result is returned to the repository API. (7). Metadata search result (native) The metadata search result is transferred to the XML data access module through the native API of the repository. (8). XML metadata search result The XML data access module converts the metadata search result into XML format and passes it to the business logic. (9). XML metadata search result analysis Business logic analyzes the XML metadata search results. When there are a plurality of metadata search requests and results, this analysis process is recursively repeated. (10). XML unique data search request Based on the meta index information acquired from the integrated repository, a search request for unique data existing on the distributed database is issued in XML XML format. (11). Unique data search request 1 (native) The XML data access module makes a unique data search request to an API provided by various databases. (12). Unique data search 1 Receives a unique data search request through the database API and issues a search request to the actual unique database. (13). Unique data search result 1 The unique data search result is returned to the database API. (14). Unique data search result 1 (native) Unique data search result XM through database API
Transfer to the L data access module. (15). XML unique data search result 1 The XML data access module converts the unique data search result into the XML format and passes it to the business logic. (16). Unique data search request 2 (native) When the XML unique data search request in (10) extends over a plurality of unique databases at different locations, a search request for the unique database is also issued a plurality of times. In that case, a second (or later) unique data search request is made to the database API. (17). Unique Data Search 2 A second (or later) search is performed on the unique database through the database API. (18). Unique data search result 2 The second (and subsequent) unique data search results are stored in database A
Return to PI. (19). Unique data search result 2 (native) The second (or later) unique data search result is passed to the XML data access module through the database API. (20). XML unique data search result 2 The XML data access module converts the second (or later) unique data search result into XML format and passes it to the business logic. (21). XML unique data search result synthesis (1 + 2) processing The business logic performs synthesis processing on a plurality of search results. (22). Unique data search result The combined search result is passed to the browser control module as a response to the search request from the browser in (1). (23). Search result display The browser control module arranges the display format while referring to the style sheet and the like, and displays the search result to the browser.

[0045]

According to the present invention, it is possible to centrally manage databases distributed on a network.

[Brief description of the drawings]

FIG. 1 is an explanatory diagram showing information distributed and arranged in an individual database according to the related art.

FIG. 2 is an overall network configuration diagram in an embodiment of the present invention.

FIG. 3 is a diagram showing a storage state of index information in an integrated object repository server according to the embodiment;

FIG. 4 is a diagram showing a mapping state to an integrated object repository server on the distributed database according to the embodiment;

FIG. 5 is a diagram showing a definition state of a new relationship on the integrated object repository server according to the embodiment;

FIG. 6 is a diagram illustrating a configuration of each user and class table according to the embodiment;

FIG. 7 is a table configuration diagram showing an instance of a user class according to the embodiment;

FIG. 8 is a table configuration diagram showing an instance of a DB information class according to the embodiment (1).

FIG. 9 is a table configuration diagram showing an instance of a DB information class according to the embodiment (2).

FIG. 10 is a conceptual diagram illustrating a relationship between a user instance and a DB information instance according to the embodiment;

FIG. 11 is a table configuration diagram of an instance of a person A according to the embodiment;

FIG. 12 is a conceptual diagram showing a transparent relationship between persons according to the embodiment.

FIG. 13 is an example of a display screen for defining a new relationship on the object repository of the embodiment.

FIG. 14 is a display screen example of a new view across the database according to the embodiment.

FIG. 15 is a functional block configuration diagram of the integrated object repository server according to the embodiment;

FIG. 16 is a collaboration diagram of the cross-database integrated object repository of the embodiment.

FIG. 17 is a sequence diagram of the cross-database integrated object repository of the embodiment.

 ──────────────────────────────────────────────────の Continuing on the front page (72) Inventor Hiroaki Ozaki 5-47, Akasaka 7-chome, Minato-ku, Tokyo F-term in Web Eye (reference) 5B075 KK02 5B082 GA08 GC04 HA08 HA09

Claims (1)

[Claims] 1. An integrated object repository server connected to two or more databases connected via a network, wherein the integrated object repository server refers to its own meta index information to each database via the network. Requesting the extraction of various information using a query language by using a query language; receiving the information obtained by the query by the integrated object repository server; and the integrated object repository server storing the information in a lower hierarchy of the meta index information. A database management method.