JP2008181457A - Retrieval system and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To increase the retrieval speed for large quantities of data with respect to a retrieval system and method. <P>SOLUTION: A data access server program stores parts of information which are predicted to be useful for speeding up retrieval when being cached, in logical volumes into cache areas for the logical volumes which are provided on a memory area of a data access server 5 correspondingly to respective logical volumes. Storage capacities of these cache areas are changed by characteristics of retrieval. The storage capacities of cache area are dynamically controlled as follows; the storage capacity of a cache area i for a logical volume i is increased in response to the increase in frequency of retrieval relating to this logical volume i and is reduced in response to the reduction in frequency of retrieval relating to this logical volume j, and parts highly relevant to each other, of data included in logical volumes are selectively stored in the cache areas. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a search system configured by combining a plurality of unit information and performing a search for a plurality of search target information to be searched and a method thereof.

For example, Patent Document 1 discloses a database that defines relationships between a plurality of information nodes.
In this database, a direct relationship is defined as a role between two directly related information nodes, and a plurality of information nodes having some relationship with each other are thus directly related to the two information nodes. Can be grasped as a chain of
In this database, the degree of association between a plurality of information nodes can be determined based on the number of direct associations defined between information nodes.
That is, for example, the smaller the number of associations defined between any two information nodes, the closer the association between these two information nodes can be grasped.
Conversely, the greater the number of associations defined between any two information nodes, the more sparse the associations between these two information nodes may be.
JP 2006-120056 A

  The present invention is made on the premise of the background art described above, and performs high-speed information retrieval using the degree of relation that can be grasped between arbitrary information nodes based on the relation defined between the information nodes. It is an object of the present invention to provide a search system and method improved so that

  In order to achieve the above object, each of the search systems according to the present invention is a search system configured by combining a plurality of unit information, and performing a search for a plurality of search target information to be searched, A search device having a predetermined storage capacity, storing all of the plurality of search target information, and in response to a request indicating unit information of the search target information from the search device, the search target indicated by the request A storage device that reads unit information of information at a predetermined data transfer rate and returns the unit information to the search device, and the search device includes a plurality of target storage capacities corresponding to the plurality of search target information Each of the plurality of target storage capacities includes at least part of the unit information included in the plurality of search target information, and each of the plurality of target storage capacities Each of the plurality of pieces of search target information, and cache means for outputting the cached unit information at a data transfer rate higher than the data transfer rate of the storage device in response to an external request. On the basis of the search characteristics of the storage unit, a capacity control unit that controls the size of each of the plurality of target storage capacities included in the cache unit, and unit information corresponding to a search request received from the outside are cached in the cache unit. The unit information is requested and read out from the cache means when it is, and the unit information is requested and read out from the storage device and returned to the search request source at other times.

  Preferably, each of the plurality of unit information further includes an information creation device that defines the strength of the relationship, combines these unit information, and creates each of the plurality of search target information, The search device controls the cache unit to cause the cache unit to cache the unit information based on the strength of the relationship defined between the unit information included in the plurality of search target information. It further has a cache control means.

  Preferably, the information creating device includes a direct relationship defining means for defining a direct relationship between a combination of two unit information included in the plurality of unit information, and two units in which the direct relationship is defined. Information generating means for generating the search target information by further combining combinations of information, and the cache control means of the search device stores any two of the target storage capacities stored in the cache means. The unit caches the unit information so that one or more direct relationships are defined between the unit information.

  Preferably, the cache control means of the search device minimizes the number of direct relationships defined between any two unit information stored in each of the plurality of target storage capacities of the cache means. The unit information is cached in the cache means.

  Preferably, the cache control unit causes the cache unit to cache the unit information so that the frequency of requesting the unit information to the storage device is minimized.

  Preferably, the information creation unit of the information creation device creates the search target information by combining all of the plurality of unit information so as to belong to a community defined between the unit information.

  Preferably, the storage device stores the search target information using a disk storage device, and the cache unit of the search device stores the unit information using a semiconductor memory.

  Further, the search device according to the present invention is a search device configured by combining a plurality of unit information, and performing a search for a plurality of search target information to be searched, all of the search target information Has a predetermined storage capacity, and in response to a request indicating the unit information of the search target information from the search device, reads the unit information of the search target information indicated by the request at a predetermined data transfer rate. Cache means including a plurality of target storage capacities stored in a storage device returned to the search device and corresponding to the plurality of search target information, wherein each of the plurality of target storage capacities includes the plurality of search target information. At least a part of the included unit information is cached in an amount corresponding to the size of each of the plurality of target storage capacities, and the cached unit information is externally stored. And a plurality of targets included in the cache unit based on a search characteristic for each of the plurality of search target information, and a cache unit that outputs at a data transfer rate higher than a data transfer rate of the storage device in response to the request When the capacity control means for controlling the size of each storage capacity and the unit information corresponding to the search request received from the outside are cached in the cache means, the unit information is requested and read from the cache means. In other cases, there is a search means for requesting and reading out the unit information from the storage device and returning it to the search request source.

  The search method according to the present invention includes a computer, and is configured by a combination of a plurality of unit information, and is executed by a search device that performs a search for a plurality of search target information to be searched. In the method, all of the search target information has a predetermined storage capacity, and in response to a request indicating unit information of the search target information from the search device, a unit of the search target information indicated by the request The plurality of target storage capacities for a cache including a plurality of target storage capacities stored in a storage device that reads information at a predetermined data transfer rate and returns the information to the search device. Each caches at least part of unit information included in the plurality of search target information by an amount corresponding to the size of each of the plurality of target storage capacities. In response to a request from the outside, the cached unit information is output at a data transfer rate higher than the data transfer rate of the storage device, and based on the search characteristics for each of the plurality of search target information, When the capacity control step for controlling the size of each of the plurality of target storage capacities included in the cache means and the unit information corresponding to the search request received from the outside are cached in the cache means, the unit information is And requesting the cache means to read, otherwise, the computer is caused to execute a search step of requesting and reading the unit information from the storage device and returning it to the search request source.

  The program according to the present invention is a program executed by a search apparatus that includes a computer and is configured by combining a plurality of unit information, and performs a search for a plurality of pieces of search target information to be searched. All of the search target information has a predetermined storage capacity, and in response to a request indicating the unit information of the search target information from the search device, the unit information of the search target information indicated by the request is changed. Read out at a predetermined data transfer rate, stored in a storage device that is returned to the search device, and each of the plurality of target storage capacities for a cache including a plurality of target storage capacities corresponding to the plurality of search target information And caching at least a part of the unit information included in the plurality of search target information by an amount corresponding to the size of each of the plurality of target storage capacities. A cache step of outputting the cached unit information at a data transfer rate higher than the data transfer rate of the storage device in response to an external request, and a search characteristic for each of the plurality of search target information A capacity control step for controlling the size of each of the plurality of target storage capacities included in the cache means, and unit information corresponding to a search request received from the outside is cached in the cache means. The information is requested to the cache means and read, and otherwise, the computer is caused to execute a search step of requesting the unit information to be read from the storage device and returning it to the search request source.

  According to the search system and method according to the present invention, information can be searched at high speed using the degree of relation that can be grasped between arbitrary information nodes based on the relation defined between the information nodes. Can do.

[Community information search system 1]
FIG. 1 is a diagram illustrating a configuration of a community information search system 1 according to the present invention.
As shown in FIG. 1, the community information search system 1 according to the present invention includes a company server 102-1 to 102-n, a management PC 104, a profile specification management device 12, an external profile management device 14-1 to 14-n, an external Profile information storage devices 15-1 to 15-n, policy servers 16-1 to 16-n, service execution devices 18-1 to 18-n, client PCs 2-1 to 2-n used by users # 1 to #n, The data access devices 3-1 to 3-n, the data access server 5, the community-related data management device 7 and the identifier management device 8 are communicably connected to each other via a network 100 such as the Internet or a LAN (Local Area Network). Configured.

The community information search system 1 creates and stores data (community information) indicating the community formed by the user using these components, and searches the stored community information in response to a request from the user or application (program). And return the search result.
In the community information retrieval system 1, the community-related data management device 7 uses various tables (AR (Association Role)) tables, T, which are used by the data access server 5 to cache community information in the memory area. A node identifier (ID (Identifier)) table and an A node identifier (ID) table; FIGS. 14 to 16) are created.
In addition, the data access devices 3-1 to 3-n and the external profile information management devices 14-1 to 14-n store and manage community information as a plurality of types of profile information in a distributed manner.
The profile specification information management device 12 stores and manages information (profile specification information) related to community information (profile information).

In FIG. 1 and each of the following figures, n is an integer of 1 or more, and not all n are the same number.
Further, when any one of a plurality of possible components such as the company servers 102-1 to 102-n is indicated without being specified, it may be simply referred to as the company server 102.
In addition, in FIG. 1 and each of the following figures, components that can be the subject of communication and information processing, such as the company server 102, the profile specification management device 12, and the client PC 2, may be collectively referred to as cluster nodes.
In the community information search system 1, any two or more cluster nodes can be appropriately integrated as long as there is no contradiction in function or the like.
In the following drawings, substantially the same components and processes are denoted by the same reference numerals.

FIG. 2 is a diagram illustrating a hardware configuration of each cluster node such as the client PC 2 shown in FIG.
As shown in FIG. 2, each cluster node of the community information search system 1 includes a cluster node main body 110 including a CPU 112 and a memory (memory area) 114, an input / output device 116 including a display device and a keyboard, a recording device 118, The communication device 122 is used for communication with other cluster nodes.
That is, each cluster node of the community information search system 1 includes a hardware component as a computer that can communicate with other cluster nodes.
An OS (not shown) is installed and executed on each cluster node of the community information search system 1.
Various programs installed in each cluster node are executed by specifically using the hardware of each cluster node via the OS.

The memory 114 is composed of a semiconductor memory (ROM, RAM, etc.).
The recording device 118 is, for example, a disk recording device such as a CD device, a DVD device, or an HDD device, and records and reproduces data on a recording medium 120 such as a CD, DVD, HD, and FD.
Generally, the storage capacity of the memory 114 is smaller than the storage capacity of the recording device 118.
On the other hand, generally, the data transfer rate of data transferred between the CPU 112 and the memory 114 is higher than the data transfer rate of data transferred between the CPU 112 and the recording device 118.

[community]
Before describing the details of the community information search system 1, first, a community will be described for understanding.
FIG. 3 is a first diagram illustrating a community indicated by community information to be searched by the community information search system 1 shown in FIG.
For example, when the company server 102-1 shown in FIG. 1 manages a subscriber of the game magazine A published by the company / publisher X among the users of the community information search system 1, as shown in FIG. The subscribers # 1 to #n of the game magazine A form one community (game magazine A subscriber community).

FIG. 4 is a second diagram illustrating the community indicated by the community information to be searched by the community information search system 1 shown in FIG. 1, and (A) is formed by the community shown in FIG. The state of the user of the community information search system 1 before being performed is shown, (B) shows the formation of the community shown in FIG. 3, and (C) shows the derivation of the community shown in FIG.
As shown in FIG. 4A, before the publisher X manages the subscribers of the game magazine A by the company server 102, at least a community related to the subscribers of the game magazine A of the publisher X is formed. It has not been.
That is, in the community information search system 1, the user is in a state where the user has no relation with respect to the subscription of the game magazine A of the publisher X.

Next, as shown in FIGS. 3 and 4B, some of the users of the community information search system 1 become subscribers # 1 to #n of the game magazine A of the publisher X, and the publisher X When the subscriber server is managed by the company server 102, a community related to the subscriber of the game magazine A of the publisher X is formed in the community information search system 1.
Further, as shown in FIG. 4C, the game maker Y issues an advertisement message of the online game B to the community of the subscriber of the game magazine A.
In response to this advertisement, some of the subscribers of the game magazine A become online game participants # 1 to #n, and when the game maker Y manages the participants by the company server 102, the online game The community of participants in B is derived from the community of subscribers of publisher X's game magazine A.

When the game magazine A is suspended or the online game B service ends, the community of the game magazine A or the community of participants of the online game B disappears, and the game magazine A subscription or online Regarding participation in the game B, the user of the community information search system 1 returns to an unrelated state as shown in FIG.
That is, as shown in FIGS. 4A to 4C, in the community information search system 1, various communities are formed, changed, derived from other communities, and further disappeared.

FIG. 5 is a third diagram illustrating a community indicated by community information to be searched by the community information search system 1 shown in FIG.
As shown in FIG. 5, each user of the community information search system 1 is a community of the game magazine A shown in FIGS. 3 and 4B, and the online game B shown in FIG. 4C. Since it is possible to arbitrarily join the community of the participant and the community of the subscriber of the other magazine C, duplication may occur in the members of the community in the community information search system 1.

[Relation between data]
Furthermore, the relationship between the data defined in the community information search system 1 is demonstrated.
Data including various elements is efficiently collected and stored.
It is desired to read out data from stored data as necessary and to accurately reproduce these data.
In general, in a subset R⊆A × B of a Cartesian product set A × B, when aRb is expressed for an ordered pair (a, b) εR, this means that “a has a relation R with b”. To do.
As an example of simple data, “writer Shakespeare wrote drama Hamlet” is taken as an example.

Since these data are in a binary relationship, by placing “writer Shakespeare” = a, R = author-works, b = “drama Hamlet”, the data “writer Shakespeare wrote drama Hamlet” Indicated as “aRb”.
These data are stored as “a”, “R”, and “b” when stored in the database, and can be uniquely reproduced when the data is read out.
However, when the number of data components increases, that is, when there is an n-term relationship instead of a binary relationship, a series of data having these relationships is expressed as a hypergraph structure, and processing is not easy.
For this reason, generally, a method is used in which n-term relationships are divided into binary relationships, expressed as combinations thereof, and stored in a database.

As a first example, “writer Shakespeare wrote drama Hamlet in England around 1600” as an example.
This example represents a four-term relationship, but when expanded into a two-term relationship, 4C2 = 6, so it is expressed as a combination of six binary relationships as shown in Table 1.

  That is, when n increases, it is necessary to express nC2 binary relationships in order to express n-term relationships.

  Furthermore, as a second example, “writer Shakespeare wrote drama 12th night around 1600.” When expressed in a combination of binary terms, 3 terms, ie n = 3, 3C2 = 3. As shown in Table 2.

Here, when the information of the first example and the information of the second example are stored in the same database, the same binary relation consisting of “writer Shakespeare” — “author—creation age” — “around 1600” The problem of being remembered.
Further, there arises a problem that it is impossible to determine which of the binary relations shown as the first and second examples is combined to reproduce the original information.
These are problems that can be solved by attaching an identifier for each binary relationship, but have the disadvantage that the data structure and processing become complicated.

As a method for storing data having two or more data components, a storage method using a relational database is known.
In this method, a table in which data item names (data attributes) are assigned to columns is defined and created, and specific data is sequentially input to the rows of the table.

“The writer Shakespeare wrote drama Hamlet in England around 1600,” explains.
Data item names include (1) “who”, (2) “what”, (3) “what”, (4) “where”, (5) “why”, (6) “how” Can be specified.
Corresponding to these data items, (1) “writer Shakespeare”, (2) “drama Hamlet”, (3) “around 1600”, (4) “UK”, (5) “(blank)”, (6) “Written” data can be stored.

However, this method has the following problems.
(1) The data item name cannot be easily added later in accordance with the acquired data. In the case of data consisting of standard components, there is no problem. However, when data including various components is entered, the schema for adding data item names each time the component increases. Changes are required. Schema changes are generally difficult when entering data online.
(2) Since it is not easy to add later, it is conceivable to construct a schema with the maximum number of data items at the time of the first database construction. However, even for data that is unlikely to be input, building a schema as a data item inevitably reduces the memory usage efficiency.

In order to solve such problems, a data storage method based on the “Associative Model of Data” method by the UK “Lazy Software” company has been proposed as a model to replace the conventional relational data model.
In this data model, information is regarded as a relationship between things, and this relationship is expressed in a “Source-Verb-Target” syntax.
This eliminates some of the problems that arise with the relational database storage method described above.
However, when dealing with complex data relationships, the method of expressing the relationship between data is complicated and not intuitive, and the n-ary relationship is expressed using a binary tree-like form, so the expression is uniquely determined. First, when storing data in the database, the structure of the data can be arbitrarily changed by the operator, so when data is read from the database and reproduced, the input information may not be reproduced accurately. There is.

As described above, conventionally, a relational database has been known as a method of storing a plurality of mutually related data.
In this method, data items to be stored are determined in advance, and data corresponding to the data items are stored.
Although there is an advantage that the relation of data is easy to see, it is not easy to add the data item of the database once configured, that is, to change the structure (schema) of the database once configured.
Further, the data corresponding to the data item added later has a problem in that the use efficiency of the memory is deteriorated due to a blank area with respect to the data stored previously.
On the other hand, the data-related model proposed by Lazy Software solves the problems such as difficulty in adding the number of data items and reduced memory usage efficiency, but the description content of the data is complicated. Therefore, it is not intuitive to look at the data structure, and another problem arises that the data notation / storage method is not unique.

In the community information search system 1, a new relationship node (hereinafter referred to as the present specification) is created for the relationship network type data including the found node group and the edge group indicating the relationship between the nodes. In this document, it is referred to as “A node”), and a role that is related to the A node (hereinafter referred to as “T node” in the present specification) plays a role (hereinafter referred to as “this node specification”). In this case, a data model including edges having attributes as “relevance roles” is defined (FIG. 6).
From the data structure transformed according to this model, one A node and T node, and the relationship roles between them are extracted as basic components, and these are defined as relationship roles defined in the relational database as shown in Table 3. A method of storing and managing the table (hereinafter referred to as “AR table” in the present specification) in association with a row (record) of the table (relative database management system) is realized.

As a result, new attribute information relating to a certain data (finding node) is defined as another relevance data, and a corresponding combination of the A node, the T node, and the edge between the nodes (basic components in the data model) If it is expressed as data associated with the rows of the AR table, new attribute information can be added without changing the existing table structure (database schema).
Further, an identifier that can be uniquely identified is assigned to each of the A node and the T node, and an identifier having a node type that represents the attribute type of the node and a node name that represents an attribute value, that is, a specific content of the node, for each identifier. A table (hereinafter referred to as “ID table” in the present specification) is defined (Table 5).

These data are stored and managed by the relational database management system in the same manner as the AR table.
In addition, one T node is newly provided as data that specifically describes the meaning of the relationship indicated by a certain A node, and these two nodes are associated with a predefined relationship role of “reification”.
A relationship that exists between the relationships indicated by the original two A nodes by defining and describing the relationship between the T node and another newly established T node for another A node as well Can be expressed.

The T node related by the relevance role “reification” introduced specifically for describing the meaning of the A node can be stored and managed by the AR table.
By managing each node using these ID table and AR table, a data representation method is realized that allows not only the relationship between the A node and the T node, but also the relationship between the A node and the A node. .

In general, when a data set composed of n pieces of data having one common relationship is expressed by a binary relation, a set of nC2 pieces of data is required. A pair is sufficient.
In other words, for a data set having n elements having one common relationship (FIG. 7A), when storing these data in a database, a node (A node) common to the data set is set. One is newly provided, and then the relevance role is defined for each element (FIG. 7B).
Thus, if the “A node”, “T node” and “relevance role” are defined as a set of data, the data structure of the present invention can be constructed (Table 4).

“A1” used in FIG. 7B and Table 4 is an identifier assigned to the A node, and what is a group of data (T node) to which different identifiers “T1” to “Tn” are assigned? This indicates that they have a common relationship.
If the identifiers assigned to the A node are different, the series of data has some common relationship in another sense.
Further, as shown in Table 5, an ID table having a node type and a node name as data attributes is created for the A node and T node to which the identifier is assigned.

In addition, with respect to the relevance network type data in which T nodes T1 and T2 are related by A node A1 and T nodes T1 and T3 are related by A node A2 (FIG. 8A), the relevance of A node A1 is shown. A T node (identifier T11) that specifically describes the meaning is newly provided and associated with A1 with a predefined relevance role of “reification”.
Similarly, the A node A2 and the new T node T12 are associated with the relationship role “reification”, and the relationship between these two T nodes T11 and T12 is defined using the A node A11 (see FIG. 8 (b)).
Thereby, the relationship between the original two A nodes A1 and A2 can be expressed using an AR table as shown in Table 6.

[Data storage method / data structure]
Hereinafter, a data storage method and a data structure will be described.
As a specific example, “writer Shakespeare wrote drama Hamlet in England around 1600” is explained as the first data.
This information represents a four-term relationship with the elements of (1) “writer Shakespeare”, (2) “drama Hamlet”, (3) “around 1600”, and (4) “UK”.
When the data relationship is expressed by being divided into binary relations, 4C2 = 6, so it is expressed as 6 combinations as shown in Table 7 below.

These pieces of information are converted in accordance with the present invention. First, the first data is converted.
The “writer Shakespeare” in the find node 1 indicates that it is an “author” in this information. Therefore, “writers” and “shakespeare” are divided into “writers” and “shakespeare” as T nodes and “authors”. Relevance role. Further, as described later, “writer” is a node type of a T node.
For the edge “author-work” indicating relevance, an A node is provided as “about Hamlet work” to indicate that the series of information is the same group.
Since the data about “Hamlet's work” is used to indicate that a series of information belongs to the same group, other expressions may be used as long as they can be distinguished from information of other groups.

  When described in the structure of “A node” − “T node” − “association role”, it is as shown in Table 8.

Similarly, “drama hamlet” in the finding node 2 is “works” in this information, and thus is converted as shown in Table 9.
Also, “drama” is a node type of T node.

  Next, when the second data is similarly converted, Table 10 is obtained.

  Here, the information about “Hamlet's work”, “Shakespeare”, and “author” can be omitted because it is redundant data. Similarly, all data is converted and redundant data is deleted, as shown in Table 11.

Therefore, if a data set composed of four data having one common relationship is expressed by a binary relation, since 4C2 = 6, six data sets are required. It can be seen that four data sets are sufficient.
In other words, when storing these data in a database for a data set having four elements, one new node (A node) common to the data set is provided, and then the relevance for each element is set. If a role is defined and “A node”, “T node” and “association role” are defined as a set of data, the data structure of the present invention can be constructed.
Here, the identifier “A1” is assigned to the A node “About Hamlet Works”. It can be seen that these data having the node identifier “A1” in common belong to one group.
Further, identifiers “T11” to “T14” are assigned to the four T nodes “Shakespeare”, “Hamlet”, “around 1600”, and “UK”, respectively.
Thus, the AR table created from the first example is as shown in Table 12.

  In addition, the node type of the A node (identifier A1) indicating “about Hamlet's work” is set as “work related information”, and the node types of the T nodes assigned with the identifiers T11 to T14 are “writer”, “drama”, “ By setting “year” and “country”, an ID table as shown in Table 13 is created.

Furthermore, as the second data, the information “Japanese translation version based on drama Hamlet was published by XX publisher in February 2003” is taken as an example.
When these pieces of information are constructed in accordance with the present invention, data is as follows. Here, an A node common to a series of information elements is “about Hamlet Japanese translation”, and an identifier “A2” is given as shown in Table 14.

  Since the original “Hamlet” has already been assigned the identifier “T12”, the identifier “T23” and “T24” are assigned to the translated version Hamlet and the publication date and publisher, respectively. Table 15 shows the AR table for data.

In addition, an ID table shown in Table 16 is created.

  Since these first and second data and other data subjected to the same data conversion process are also stored in the same database, the AR table and ID table as shown in Table 17 and Table 18 are finally obtained. It is done.

Furthermore, as shown in FIG. 9, T nodes are provided for specifically describing the meaning of the relationship indicated by the A nodes whose identifiers are A1 and A2, and the identifiers “T31” and “T32” are respectively provided. And associate with the node A1 and the node A2 by the relevance role “reification”.
The node type of these two new T-nodes is “copyright information”, and the node names are “about Hamlet work” and “about Hamlet Japanese translation”, respectively.
An A node indicating the relationship between the node T31 and the node T32 is newly provided as an identifier A3, and the node type is “original work-translation information”.
Further, the roles played by the node T31 and the node T32 in the relation here are “original information” and “translation information”, respectively. From the above processing, the AR table shown in Table 19 and the ID table shown in Table 20 are added.

In order to directly store the above first and second data in the relational database, the data item name is a new item corresponding to “Hamlet” or “XX Publisher” (data). Attribute) must be added. This is not easy because it changes the table structure of the database.
As shown in the example, by adding a row to the existing AR table, it is possible to store information having different data attributes as a plurality of sets.
Also, FIG. 9 shows the first and second data expressed using the A node, the T node, and edges indicating the relationship between the nodes.
It provides a method for easily expressing data with such a complex structure and a method for storage and management in a relational database.

Next, a case where desired data is searched from the database of the present invention will be described.
In the following, a case where the user wants to know the publisher of the Japanese translation of the drama Hamlet written by writer Shakespeare will be described as an example.
FIG. 10 shows the flowchart.
Hereinafter, the flowchart shown in FIG. 10 will be described.

110: The user inputs the search condition as “drama” of “shakespeare” which is “writer”.
120: A plurality of sets of data matching the search conditions are collected.
130: Information corresponding to “drama” is sequentially displayed from the information detected in plural sets.
140: The user selects a desired drama name, that is, “Hamlet” from these.
150: “Hamlet” and “translated version” are set as new conditions, and data is searched.
160: Multiple sets of data that match the search conditions are collected.
170: Data relating to “publisher” and “publication date” are sequentially displayed from the detected plurality of sets.
180: The user selects a desired publisher.

Details will be described below.
As a search condition, the user searches for information by inputting that the node name of the T node is “Shakespeare” and the relevance role is “writer”.
The AR table is referenced in the database, the identifier of the T node whose relevance role is “writer” is detected, the node name attribute stored in the ID table is subsequently referenced, and “Shakespeare” is identified as the node name. A plurality of sets of A node identifiers corresponding to T nodes are detected.
From the information having a plurality of sets of detected A node identifiers, another search condition, that is, a T node identifier whose relevance role is “drama” is selected from the AR table.
Based on this identifier, information about the corresponding play is sequentially displayed from the ID table.

In other words, the names of plays such as “Hamlet”, “Jajama Tame”, “Venice Merchant”, “Midsummer Night's Dream”, “Lear King”, etc. are sequentially displayed. The user selects a desired drama name, that is, “Hamlet” from these.
Subsequently, using the identifier “T12” of the selected “Hamlet” as a key, the A node identifier including the identifier of “Hamlet” in the T node ID and having the relevance role “translated version” is searched from the AR table. .
Thereby, a plurality of sets of information associated with the A node identifier satisfying the search condition are detected.
From the detected plural sets of information, node names of T nodes having “publisher” and “publishing date” as relevance roles are sequentially displayed while referring to the ID table.
The user can select a desired publisher from among them, that is, “XX publisher” that recently published a translated version of the drama Hamlet in “February 2003”.

The example shown in FIG. 10 has been described as an example of a search example.
In other words, when the search condition increases, the database search is not limited to twice as shown in FIG. 10, and it goes without saying that the search is repeated any number of times according to the desired condition.
Moreover, in the specific example shown here, although the single attribute is assigned as a relevance role, it is not limited to this.
That is, it is possible to give a plurality of attributes to the relevance role. In the above example, the relationship role “drama” is defined by adding more genres such as “tragedy”, “comedy”, “romance play”, “historic play”, etc. can do.

[Features of data storage method and data structure]
According to the data storage method and data structure described above, a series of data having a relation of 3 terms or more, and generally n terms, using a relational database table format which is widely used at present. Data can be stored and managed while maintaining the hypergraph structure representing the relationship.
Further, the method of directly mapping the relevance network type data to the relational database table solves the problem that data representing three or more relations, generally data representing n-term relations, cannot be efficiently stored and managed.

Also, in order to make changes such as adding attribute information to data already stored in the database, it is necessary to change the table design of the relational database, which is not flexible and requires a lot of effort. Is resolved.
Furthermore, in the same database schema framework, the meaning of a series of relationships can be described using identifiers and relationship roles assigned to data.

[Details of Community Information Search System 1]
Hereinafter, details of the community information search system 1 according to the present invention will be described.

[Community-related data management device 7]
First, the community related data management apparatus 7 shown in FIG. 1 will be described.
In the following description of the community-related data management device 7, in the description of the data storage method and data structure according to the present invention described above with reference to FIGS. Although terms may vary, corresponding terms between these descriptions are substantially the same.
Regarding the description of the community-related data management device 7, the following terms take precedence over the terms in the above description of the data storage method and data structure according to the present invention.

[data structure]
In the community-related data management device 7, various tables (FIGS. 14 to 16) are created by applying the above-described data storage method and data structure (FIGS. 9, 10 and 7 to 20). Is done.
First, the data structure and data search in the community-related data management device 7 will be described.
FIG. 11 is a diagram showing the relevance of the data illustrated in FIG.
As shown in FIG. 11, in the community-related data management device 7, as in the above-described data storage method and data structure according to the present invention, the found node (hereinafter referred to as T node) is 1 A relation attribute R is defined between the T node and the A node associated with one or more association nodes (hereinafter referred to as A node).
The relation attribute R may be any attribute that can be defined for the relation between the T node and the A node. However, for the sake of concreteness and clarification of the description, the data storage method and As in the description of the data structure, a case where the related attribute R is the relevance role R is taken as a specific example.

The data relationship shown in FIG. 8A is expressed as shown in FIG. 11 by rewriting.
Among A nodes A1 to An shown in FIG. 11 (hereinafter, n represents an integer equal to or greater than 1. However, not all n necessarily represent the same number), A node A1 is related to A node A1. The T nodes T1-1 to T1-3 and T2-1 to be connected are connected by edges.
Similarly, the T nodes T2-1, T2-2, and Tn-1 related to the A node A2 and the A node A2 are connected by an edge.
The same applies to the A node An, and the T nodes Tn-1 to Tn-4 related to the A node An and the A node An are connected by an edge.
That is, FIG. 11 shows that the T node T2-1 is related to both the A nodes A1 and A2, and the T node Tn-1 is related to both the A nodes A2 and An. Has been.

FIG. 12 is a diagram showing a generalized data structure shown in FIG.
In FIG. 11, when the edge is traced from the T node T1-1 to the A node An through the A node A1, the T node T2-1, the A node A2, and the T node Tn-1, in FIG. A path extending in the downward direction is obtained.

In FIG. 12,
(1) The T nodes T1-1 to T1-m1 and T2-1 are associated with the A node A1, and the association (edge) between the T nodes T1-1 to T1-m1 and T2-1 and the A node A1 Defines the relevance roles R1-1 to R1-m1, R1-0,
(2) The T nodes T2-1 to T2-m2 and the T node omitted in FIG. 12 are associated with the A node A2, and the association between the T nodes T2-1 to T2-m2 and the A node A2 , Relevance roles R2-1 to R2-m2 are defined,
(3) Hereinafter, similarly, the T node and the A node which are omitted in FIG. 12 are associated, and the relationship role R is defined between them,
(4) The T nodes Tn-1 to Tn-mn and the T node omitted in FIG. 12 are associated with the A node An, and the relationship between the T nodes Tn-1 to Tn-mn and the A node An is The case where the relationship roles Rn-1 to Rn-mn (m1 to mn, n are integers) is defined is shown as a specific example.

That is, in the community-related data management device 7, each T node is associated with one or more A nodes, and each A node is associated with one or more T nodes, so that Multiple T nodes can be associated, and multiple A nodes can be associated via the T node.
In the community-related data management device 7, a plurality of combinations of associated A node and T node can be stored as shown in FIG.

FIG. 13 is a diagram showing the relationship between the data shown in FIGS. 8B and 9 in a generalized manner.
The relationship between the data shown in FIGS. 8B and 9 can be generalized as shown in FIG.
In FIG. 13, T nodes T1-1 to T1-3 (, T3-1) related to A node A1 and A node A1 are connected by an edge, and T nodes T2-1 to T2- related to A node A2 are connected. 3 (, T3-2) and the A node A2 are connected by an edge, and the A node An and the T nodes Tn-1 to Tn-3, T2-3 (, T3-n) are connected by an edge.
The T node T2-3 is connected to both of the A nodes A2 and An by an edge, which indicates that the T node T2-3 is related to both of the A nodes A2 and An.
Here, when a series of information related by the A nodes A1, A2, and An has a common relationship, a new related node A3 can be defined.
For example, when the A node A1 is information related to Hamlet originals, the A node A2 is information related to Hamlet translation, and the A node An is information related to Hamlet performances, these A nodes A1, A2, The related information indicated by An has commonality as information regarding Hamlet.

Therefore, a new related node A3 is defined and stored in the database in order to indicate that the information associated by the A nodes A1, A2 and An has commonality.
Further, as shown by surrounding with a broken line in FIG. 13, in order to describe specifically a series of information indicated by the A node A1 and the T nodes T1-1 to T1-3, a new T node T3-1 is provided. Defined and stored in the database.
Similarly, new T nodes T3-2 and T3-n that specifically describe the relationship between the A nodes A2 and An are defined and stored in the database.
For example, in the T node T3-1, the headline content is “About Hamlet work”, the T node T3-2 is the headline content “About Hamlet Japanese translation”, and the T node T3-n is the headline content. As such, data such as “About Hamlet Performance” is defined and stored in the database.

Furthermore, the relationship role R is defined between the new A node A3 and each of the T nodes 3-1 to T3-n and stored in the database.
For example, “original information” is defined as the relationship role R between the new A node A3 and the T node T3-1, and the relationship role between the new A node A3 and the T node T3-2. “Translation information” is defined as R, and data such as “performance information” is defined as the relationship role R between the new A node A3 and T node T3-n, and stored in the database.
Similarly, for example, a relationship role R defined in advance by the system as “reification” is defined between the A nodes A1, A2, and An and the T nodes T3-1, T3-2, and T3-n. The

FIG. 14 is a diagram showing an association role (AR) table used for storing data having the structure shown in FIG.
FIG. 15 is a diagram showing a T-node identifier (ID (Identifier)) table used for storing data having the structure shown in FIG.
FIG. 16 is a diagram showing an A-node identifier (ID) table used for storing data having the structure shown in FIG.
In the community-related data management device 7, the A node and T node associated with the structure shown in FIG. 12 and the data of the T node are stored using the AR table shown in FIG. 14 and the ID table shown in FIG. Is done.

Each entry in the AR table shown in FIG. 14 includes one A node, one T node associated with the A node, and an association role defined between the associated A node and T node. (R), an identifier (ID) of a certain A node, an identifier of a T node associated with the A node, and an associated role (R) defined between the associated A node and T node. )including.
That is, each entry in the AR table has an identifier of an A node at one end of any edge shown in FIG. 12, an identifier of a T node at the other end of this edge, and an association defined for this edge. Including sex roles.

Such entries are created for all the edges shown in FIG. 12 (edges between T1-1 and A1 to edges between Tn-mn and An), and stored in the AR table, as shown in FIG. The relationship between the A node and the T node is stored in the AR table shown in FIG.
Each T node has contents (such as the name of the T node, data of the T node itself, and data referenced by the T node), and each T node is stored in each entry of the AR table. In addition to the identifier (ID), an attribute of this T node (node type (NT); finding attribute) is defined (hereinafter, the T node has only its name (node name (N)) as its contents. A specific example is the case of having it.)

Each entry in the ID table for the T node shown in FIG. 15 includes an identifier (ID) of one of the T nodes shown in FIG. 12, an attribute defined for the T node (node type (NT)), and And the name of the T node (node name (N)).
Such entries are created for all the T nodes T1-1 to Tn-mn shown in FIG. 12, and stored in the T node ID table, so that the data for all the T nodes shown in FIG. Is memorized.
Each entry in the ID table for the A node shown in FIG. 16 includes an identifier (ID) of one of the A nodes shown in FIG. 12 and attributes (node type (NT ′)) defined for the A node. And the name of this A node (node name (N ′)).
By creating such entries for all the A nodes A1 to An shown in FIG. 12 and storing them in the ID table for the A node, the data for all the A nodes shown in FIG. 12 is stored. .

In order to store the relationship between the A node and the T node, the data of the A node, and the data of the T node shown in FIG. A specific example is the case of using an AR table and an ID table.
Depending on the use, configuration, or processing contents of the community-related data management device 7, as shown in FIG. 14, in the AR table, each entry is a T-node content (node Name (N)).
Similarly, in the AR table, each entry may further include the contents of the T node.

[data search]
FIG. 17 is a diagram illustrating a data search method in the community-related data management device 7 shown in FIG.
Here, as shown in FIG. 17, T node T1 to Tn and T node Tret (T return) to be a search result (output) are associated with a certain A node, and A node and T nodes T1 to Tn, A specific example is a case where relationship roles R1 to Rn and Rret are defined between Tret and T nodes T1 to Tn and Tret have node names N1 to Nn and Nret.

In the community-related data management device 7, the relevance role Rret defined for the T node to be obtained as a search result and the attributes of the A node that can be used for the search (node type NT; ANT1, ANT2 in FIG. 17) ) And one or more combinations of the relationship role R of the T node and the node name N that can be used for the search.
As shown in FIG. 17, this search condition is, for example, (Rret, (ANT1, ANT2,..., Filter), Filter = ((R1, N1), (R2, N2),. Rn, Nn)).
As will be described later, this search condition can further include an attribute NT (third condition data) of the T node.
Among the above search conditions, one or more combinations (R1, N1), (R2, N2),..., (Rn, Nn) of the relevance role R and node name N of the T node included in the filter are Since it is used as a filter for search, it is also described as a search filter hereinafter.

Of the search conditions, the attributes of the A node (ANT1, ANT2,...) Can be omitted.
FIG. 18 is a first flowchart showing the overall search processing (S1070) in the community-related data management apparatus 7 shown in FIG.
As shown in FIG. 18, in step 1700 (S1700), the community-related data management device 7 responds to the searcher's operation on the input / output device 116 of the client PC 2 (FIG. 1) or the community-related data management device 7, for example. The search conditions illustrated in FIG. 17 are accepted.

In step 1072 (S1072), a related node is selected based on a search filter described later with reference to FIG.
In step 1074 (S1074), a node ID and a node name described later with reference to FIG. 20 are acquired.

In step 1702 (S1702), the community-related data management device 7 returns a response to the searcher from the identifier (node ID) and node name (Nret) of the T node Tret obtained as a search result by the process of S74. create.
Examples of the response include various data such as only the node name Nret, various data referred to by the node Tret, or data indicating the node Tret itself.

In step 1704 (S1704), the community-related data management device 7 determines whether or not the inquiry by the searcher has ended.
The community-related data management device 7 ends the process when the inquiry by the searcher is ended, and returns to the process of S1700 otherwise.

FIG. 19 is a flowchart showing related node selection processing (S1072) based on the search filter shown in FIG.
As shown in FIG. 19, in the processing of S1700 shown in FIG. 18, the community-related data management device 7 searches the search conditions (Rret, (ANT1, ANT2,...), Filter), Filter = ((R1, N1 ), (R2, N2),..., (Rn, Nn)), the associated node list used for processing is initialized in step 1720 (S1720).

In this related node list, among the A nodes obtained from the AR table (FIG. 14), one of the attributes of the A node in the search condition (node type; ANT1, ANT2,...) The identifier of the A node included as the node type NT) is stored.
If the attribute of the A node is omitted in the search condition ((ANT1, ANT2,...) = Null), all the identifiers of the A node obtained from the AR table (FIG. 14) are obtained in the processing of S1720. Is memorized.
In step 1722 (S 1722), the community-related data management device 7 determines whether or not all search filters (Ri, Ni) have been processed.

The community-related data management device 7 proceeds to the processing of S1074 (FIGS. 18 and 20) when processing has been performed for all processing, and in any other case, any of the search filters (Ri that have not yet been processed) , Ni), the process proceeds to S1724.
In step 1724 (S1724), the community-related data management device 7 searches the ID table for the T node (FIG. 15), finds all the entries including the node name Ni of the search filter (Ri, Ni), and finds them. A set of T node identifiers (node ID set T) included in the entered entry is created (T = {Ti | node name = Ni in ID table}).
When the search condition includes the attribute of the T node (node type; NT) and the search filter is expressed as (Ri, Ni, NTi), the community-related data management device 7 performs the ID table in the process of S1724. Thus, an entry including the node name Ni and the node type NTi of the search filter (Ri, Ni, NTi) is searched, and a set of T-node identifiers included in the searched entry may be set as a node ID set T.

In step 1726 (S1726), the community-related data management device 7 determines whether or not the node ID set T obtained by the process of S1724 is an empty set.
When the node ID set T is an empty set, the community-related data management device 7 performs a process for ending the search process (for example, displaying a search failure to the searcher), and ends the search process. Otherwise, the process proceeds to S1728.
In step 1728 (S1728), the community-related data management device 7 searches the AR table (FIG. 14) and updates the related node list A.
That is, the community-related data management device 7 obtains the relevance role Ri of the search filter (Ri, Ni) and the identifier of any T node included in the node ID set T obtained by the processing of S1724 from the AR table. All of the included entries are searched, and the identifier of the A node included in the found entry is stored in the related node list A (A = {Aj | role Ri, T node identifier Ti (all i), A node identifier) ∈ A in AR table}).

In step 1730 (S1730), the community-related data management device 7 determines whether or not the related node list A obtained by the processing of S1728 is an empty set.
The community related data management device 7 performs a process for ending the search process when the related node list A is an empty set, ends the search process, and otherwise proceeds to the process of S1732.
In step 1732 (S1732), the community-related data management device 7 reads an unprocessed search filter included in the search condition, and returns to the process of S1722.

FIG. 20 is a flowchart showing the node ID and node name acquisition processing (S1074) shown in FIGS.
As shown in FIG. 20, when the related node selection processing (S1072) based on the search filter is completed, in step 1740 (S1740), the community related data management device 7 searches the AR table (FIG. 14), and the T node An identifier set T is created.
That is, the community-related data management device 7 determines from the AR table the relevance role Rret included in the search condition and the identifier of any A node included in the related node list A obtained by the processing of S1728 (S1728). Are searched for, and a set of T node identifiers (T node identifier set T) included in the found entries is created (T = {Tm | role = Rret, A node identifier ∈ A in AR) table}).

In step 1742 (S 1742), the community-related data management device 7 determines whether or not the T node identifier set T obtained by the processing of S 1740 is an empty set.
The community-related data management device 7 performs an end process when the T node identifier set T is an empty set, ends the search process, and otherwise proceeds to the process of S1744.
In step 1744 (S1744), the community-related data management device 7 searches the T node ID table (FIG. 15) and creates a set P of node ID / node name pairs.
That is, the community-related data management device 7 searches the ID table for all entries including any of the T node identifiers Tm included in the T node identifier set T created by the processing of S1740, and is included in this entry. A set P of a set of the node name Nm and the T node identifier Tm is created (P = {(Tm, Nm) | T node identifier = Tm (all m) in ID table}).

In step 1746 (S1746), the community-related data management device 7 determines whether or not the set P of the T node identifier and T node name obtained by the processing of S1744 is an empty set.
The community-related data management device 7 performs an end process when the set P of the T node identifier and the T node name is an empty set, ends the search process, and otherwise proceeds to the process of S1702.
This set P is used to create a response to the searcher in the processing of S1702 shown in FIG.

[Community-related data management program 70]
FIG. 21 is a diagram showing a configuration of a community-related data management program 70 executed in the community-related data management apparatus 7 shown in FIG.
In FIG. 21, the lines indicating the data flow are omitted as appropriate for clarity of illustration.
As shown in FIG. 21, the community-related data management program 70 includes a DB management unit 72, a DB unit 76, and a DB search unit 78.

The DB management unit 72 includes a management operation receiving unit 720, an AR entry creation unit 722, an ID entry creation unit 724, an AR database management unit (ARDB management unit) 726, and an ID database management unit (IDDB management unit) 728.
The DB unit 76 includes an AR database (ARDB) 760, an ID database (IDDB) 762 for T node, and an ID DB 764 for A node.
The DB search unit 78 includes a search operation acceptance unit 780, a search condition creation unit 782, a search control unit 784, an AR database search unit (ARDB search unit) 786, and an ID database search unit (IDDB search unit) 788.

The community-related data management program 70 is supplied to the community-related data management device 7 via the recording medium 120 (FIG. 2), loaded into the memory 114, and executed on the community-related data management device 7, for example. It is executed by specifically using the hardware of the community-related data management device 7 (the same applies to the following programs).
The community-related data management program 70 creates the AR database (FIG. 14) and ID database (FIGS. 15 and 16) described with reference to FIGS. The used data is searched (FIGS. 17 to 20).

In the DB unit 76, the ARDB 760 stores the AR table shown in FIG.
The IDDB 762 stores an ID table for the T node shown in FIG.
The IDDB 764 stores the ID table for the A node shown in FIG.
FIG. 21 shows a specific example in which the ID table for T node and the ID table for A node shown in FIGS. 15 and 16 are stored in IDDBs 242 and 244, respectively. The ID table for A and the ID table for A node may be stored in the same database.
Further, the ID table for the T node and the ID table for the A node are not necessarily created separately, and may be created integrally in one database.

In the DB management unit 72, the management operation accepting unit 720 manages an operation for managing or changing data stored in the AR table and the ID table from the input / output device 116 (FIG. 2) or the network. It is received from other cluster nodes (FIG. 1) via 100 and output to the ARDB management unit 726 and IDDB management unit 728.
In addition, the management operation receiving unit 720 associates the A role with the A node and the T node, the association between the A node and the T node, and the relationship role R, the A node, and the T node defined between the A node and the T node (edge). Accepting the user's operation specifying the identifier (ID) attached, the node name (N) attached to the T node, and the attribute defined in the T node (FIG. 12), the AR entry creation unit 202 and the ID entry The data is output to the creation unit 724.
For example, the management operation accepting unit 720 displays on the input / output device 116 a user interface (UI) image that displays the A node, the T node, and the relationship between them as shown in FIG. Accept user's operations on the image and accept these designations.

The AR entry creation unit 722 creates an entry in the AR table shown in FIG. 14 according to the user's designation input from the management operation receiving unit 200 and outputs it to the ARDB management unit 726.
The ARDB management unit 726 adds the AR table entry input from the AR entry creation unit 722 to the AR table stored in the ARDB 760.
Further, the ARDB management unit 726 changes the contents of the AR table stored in the ARDB 760 in accordance with a user operation input from the management operation receiving unit 720.

Further, the ARDB management unit 726 searches for an entry in the AR table stored in the ARDB 760 in response to the search by the ARDB search unit 786, and outputs it to the ARDB search unit 786.
The ID entry creating unit 724 creates ID table entries for the T node and the A node shown in FIGS. 15 and 16 according to the searcher's designation input from the management operation accepting unit 720, and the IDDB management unit 728. Output for.

The IDDB management unit 728 adds the entry in the T node ID table input from the ID entry creation unit 724 to the T node ID table stored in the IDDB 762.
Also, the IDDB management unit 728 adds the entry in the ID table for A node input from the ID entry creation unit 724 to the ID table for A node stored in the IDDB 764.
Further, the IDDB management unit 728 changes the contents of the ID table stored in the IDDBs 762 and 764 in accordance with a user operation input from the management operation receiving unit 720.
Further, the IDDB management unit 728 searches for an entry in the ID table stored in the IDDBs 762 and 764 in response to the search by the IDDB search unit 788 and outputs it to the IDDB search unit 788.

In the DB search unit 78, the search operation accepting unit 780 includes a search condition (FIG. 17 and an attribute of an arbitrary T node (node type (NT)) used in the search process shown in FIGS. The searcher's operation for designating the user is accepted from the input / output device 116 (FIG. 2) or from another cluster node (FIG. 1) via the network 100.
The search operation accepting unit 780 outputs the accepted operation to the search condition creating unit 782.

For example, when the search operation accepting unit 780 accepts a search condition in the form of a question sentence in a natural language, the search condition creating part 782 parses the question sentence and extracts a word.
Next, the search condition creation unit 782 searches the AR table and ID table stored in the ARDB 760 and the IDDBs 762 and 764 via the ARDB search unit 786, the IDDB search unit 788, the ARDB management unit 726, and the IDDB management unit 728. Extract words that can be used as search conditions.
Further, the search condition creating unit 782 combines the extracted words along the structure of the question sentence, and retrieves the search conditions (Rret, (ANT1, ANT2,...), ((R1, N1), (R2, N2),..., (Rn, Nn))) are derived and output to the search control unit 264.

It should be noted that the searcher is in the format shown in FIG. 17 (Rret, (ANT1, ANT2,...), ((R1, N1), (R2, N2),..., (Rn, Nn))). When the search condition is directly specified, the search condition creating unit 782 can be omitted.
In addition, the search condition creating unit 262 searches for search conditions (Rret, (ANT1, ANT2,...), ((R1, N1), (R2, N2),..., (Rn, Nn)) by the searcher. ) May be a tool for assisting in derivation.

The search control unit 784 includes search conditions (Rret, (ANT1, ANT2,...), ((R1, N1), (R2, N2), input from the search condition creation unit 782 (search operation receiving unit 780). ..., (Rn, Nn))), the ARDB search unit 786 and the IDDB search unit 788 are controlled, and the ARDB 760 via the ARDB management unit 726 and the IDDB management unit 728 as shown in FIGS. (AR table; FIG. 14) and IDDBs 762 and 764 (ID table; FIGS. 15 and 16) are searched.
Further, when a search result (set P; FIG. 20) is obtained by the search according to the search condition, the search control unit 784 creates a response based on the search result and sends it to the input / output device 116 (FIG. 2). Displayed or displayed on the input / output device 116 of another cluster node via the network 100 (FIG. 1) and shown to the searcher.

The ARDB search unit 786 searches the ARDB 760 (AR table; FIG. 14) via the ARDB management unit 726 under the control of the search control unit 784, and returns the search result to the search control unit 784.
The IDDB search unit 788 searches the IDDBs 762 and 764 (ID tables; FIGS. 15 and 16) via the IDDB management unit 728 under the control of the search control unit 784, and returns the search results to the search control unit 784.

[Operation of community-related data management device 7]
Hereinafter, the overall operation of the community-related data management apparatus 7 (community-related data management program 70; FIG. 21) shown in FIG. 1 will be described with a specific example.

[Create AR table and ID table]
First, the AR table and ID table creation processing by the DB management unit 72 of the community-related data management program 70 will be described.
FIG. 22 exemplifies data input to the community-related data management apparatus 7 (community-related data management program 70; FIG. 21) shown in FIG. 1 and search conditions included in the search for the data included therein. It is a figure to do.
For example, the associated data as shown in FIG. 22 is input to the management operation receiving unit 720 of the community related data management program 70.
The data shown in FIG. 22 includes an A node and a T node that are associated as follows, and each T node is given a node name (however, the attribute of the A node (node type (NT) ), Node name, and T node attribute (node type (NT)) are omitted in the following (1) to (8) and FIG.

(1) “A node A1” and “T node T11” are associated with each other, and an association role R “author” is defined between them, and “T node T11” has “Shakespeare (another person of the same name)” "Is attached to the node name.
(2) “A node A9” and “T node T92, T41” are associated with each other, and an associated role R “works” and “author” is defined between them, and “T nodes T92, T42” , “Venice merchants” and “Shakespeare” are named.
(3) “A node A4” and “T nodes 41, T42” are associated with each other, and an associated role R of “author” and “works” is defined between them, and “T node T42” includes “ The node name is “Hamlet”.
(4) “A node A13” and “T node T42” are associated with each other, and an association role R “screenplay” is defined between them.
(5) “A node A19” and “T node T42” are associated with each other, and an association role R “original” is defined between them.
(6) “A node A10” and “T node T42” are associated with each other, and an association role R “original” is defined between them.
(7) “A node A10” and “T node T103, T101” are associated with each other, and an association role R of “publishing” and “translated version” is defined between them, and “T node T103” includes The node name “XX Publishing” is attached.
(8) “A node A19” and “T node T191” are associated with each other, and an associated role R “translated version” is defined between them.

The management operation accepting unit 720 accepts the input data and outputs it to the AR entry creating unit 722 and the ID entry creating unit 724.
The AR entry creation unit 722 creates each entry in the AR table from the data shown in FIG. 22 and outputs it to the ARDB management unit 726.

FIG. 23 is a diagram illustrating an AR table created by the AR entry creation unit 722 (FIG. 21) and the ARDB management unit 726 and stored in the ARDB 760.
In the following diagram, null indicates that there is no attribute (node type) / name (node name).
The ARDB management unit 726 sequentially adds the AR table entry input from the AR entry creation unit 722 to the AR table stored in the ARDB 760.
As a result of processing by the AR entry creation unit 722 and the ARDB management unit 726, an AR table as shown in FIG. 23 is created from the data shown in FIG. 22 and stored in the ARDB 760.

FIG. 24 is a diagram illustrating an ID table for a T node created by the ID entry creation unit 724 (FIG. 21) and the IDDB management unit 728 and stored in the IDDB 762.
The ID entry creation unit 724 creates each entry in the ID table for the T node from the data shown in FIG. 22 and outputs it to the IDDB management unit 728.
The IDDB management unit 728 sequentially adds entries in the ID table for the T node input from the ID entry creation unit 724 to the ID table stored in the IDDB 762.
As a result of processing by the ID entry creation unit 724 and the IDDB management unit 728, an ID table for a T node as shown in FIG. 24 is created from the data shown in FIG.

FIG. 25 is a diagram illustrating an ID table for the A node created by the ID entry creation unit 724 (FIG. 21) and the IDDB management unit 728.
Further, the ID entry creation unit 724 creates each entry of the ID table for the A node from the data shown in FIG. 22 and outputs it to the IDDB management unit 728.
The IDDB management unit 728 sequentially adds the ID table entry input from the ID entry creation unit 724 to the ID table for the A node stored in the IDDB 764.
As a result of the processing by the ID entry creation unit 724 and the IDDB management unit 728, an ID table for the A node as shown in FIG. 25 is created from the data shown in FIG. 22 and stored in the IDDB 764.

[Search Data]
For example, a searcher publishes a translated version based on the drama Hamlet among the works whose author is Shakespeare, to the input / output device 116 (FIG. 2) of the community-related data management device 7. When the search condition is entered in the form of a question sentence, the search condition creation unit 782 analyzes the question sentence, and, as shown in FIG. Divide into two.
Since the search condition creating unit 782 searches for data related to “works” for the first half of the question sentence “among works whose author is Shakespeare”, the relevance role of the T node Tret to be the search result Let Rret be a “work”.
In addition, the search condition creation unit 782 creates a search filter (R1 = “author”, N1 = “Shakespeare”) from the first half of the section “make Shakespeare the author”.
Further, the search condition creating unit 782 corresponds to the first half of the question sentence from the relevance role (Rret = “works”) of the T node Tret and the search filter (R1 = “author”, N1 = “Shakespeare”). The search condition (Rret, (ANT1), ((R1, N1))) = (works, (null), ((author, shakespeer))) is created.

In addition, the search condition creation unit 782 searches for information on “publishing company” for the second half of the “publishing company name publishing translated version based on drama Hamlet” search. The relevancy role Rret of the T node Tret to be the result is “published”.
Further, the search condition creating unit 782 creates a first search filter (R1 = “original”, N1 = “hamlet”) from the condition that “hamlet” included in the latter half is “original”. Then, a second search filter (R2 = “translation version”, N2 = “null (no specification)”) is created from the “translation version” included in the latter half.
Further, the search condition creating unit 782 includes the relevance role (Rret = “publishing”), the first search filter (R1 = “original work”, N1 = “hamlet”), and the second search filter (R2 = “translation”). Version ”, N2 =“ null ”), and the search condition (Rret, (ANT1), ((R1, N1), (R2, N2))) = (publishing, (null), ((Original, Hamlet), (Translated version, null))).

Based on the search condition created by the search condition creation unit 262, the search control unit 784 performs the ARDB 760 (AR table; FIG. 23) and IDDB 762 (T) via the ARDB search unit 786 and the IDDB search unit 788 as shown below. The node ID table; FIG. 24) is searched to obtain a search result.
First, from the search conditions obtained from the first half of the question text,
(1) The search control unit 784 refers to the ID table of the T node stored in the IDDB 242 (FIG. 21), searches for all identifiers (ID) of T nodes whose node name is “Shakespeare”, and the result of this processing T11, T31, T41, T51, and T81 (FIG. 24) are obtained.
(2) The search control unit 784 refers to the AR table (FIG. 23) stored in the ARDB 760, and the role is “author” and the T node identifier is the T node identifier obtained by the processing of (1). All matching A node identifiers are searched, and A1, A4, and A9 are obtained as a result of this processing.
(3) The search control unit 784 refers to the AR table, and among the A node identifiers obtained by the processing of (2), the identifier of the T node corresponding to the A node whose relevance role R is “works” ( ID; generally a plurality) are searched, and T42 and T92 are obtained as a result of this processing.
(4) The search control unit 784 refers to the ID table, and uses the node name corresponding to the T node identifier obtained by the process of (3) as the search result together with the identifier (ID) of the T node. .
That is, the search control unit 784 performs a search based on the search conditions (works, (null), ((author, shakespeer))) obtained from the first half of the question sentence by the processes (1) to (4). The search result (T42, Hamlet), (T92, merchant of Venice) is obtained.
Next, from the search conditions obtained from the second half of the question sentence and the search results corresponding to the first half,
(5) The search control unit 784 has a node name of the search result (T42, Hamlet) and (T92, merchant of Venice) corresponding to the first half of the question sentence as the first search filter (original, Hamlet). The corresponding (T42, Hamlet) is selected, and its node identifier (ID) T42 is obtained. (6) The search control unit 784 refers to the AR table, the role is “original”, and the T node identifier is (5 ) All the identifiers of the A node that match the node identifier (ID) obtained by the processing of () are searched, and as a result, A10 and A19 are obtained.
(7) The search control unit 784 refers to the AR table and searches for all of the A node identifiers obtained by the processing of (6) whose role is “translated version”. As a result, A10, A19 Get.
(8) The search control unit 784 refers to the AR table, and searches for the T node identifier corresponding to the A node whose role is “publishing” among the A node identifiers obtained by the processing of (7). (If a translated version is issued from a plurality of publishers, a plurality of T node identifiers are obtained).
(9) The search control unit 784 refers to the ID table, the node name corresponding to the T node identifier obtained in (8) with the node ID and the search result (T103, XX publication) To do.

That is, the search control unit 784 executes the search conditions (publishing, (null), ((original, hamlet), (translated version, null) obtained from the latter half of the question sentence by the processes (5) to (9). )) To obtain a search result (T013, XX publication).
(10) The search control unit 784 displays the search result on the input / output device 126 (FIG. 2) or the like and indicates it to the searcher.

[Management of community information by the community related data management device 7]
FIG. 26 is a diagram illustrating a community information management method by the community-related data management device 7 shown in FIG. 1 and the like.
For example, the community-related data management device 7 processes the data sent from the client PC 2 or the company server 102 and creates an AR table (FIGS. 14 and 23) as shown in FIG. 3 to manage community information indicating the community shown in FIG.
That is, as shown in FIG. 26, the community-related data management device 7 has a community ID for identifying a community and user IDs # 1 and # 2 for identifying a user of the community information search system 1 for the A nodes A1 and A2. , # 3 are associated with each other as a T node ID, and a community, an organizer (creator), and a participant are associated with each other as a relationship role R to create an AR table.

For example, in the community information search system 1, when a search related to the user # 1 is made from another node cluster node or the like, the community related data management device 7 refers to the AR table shown in FIG. The community # 1 sponsored by # 1 and the community # 2 in which the user with the user ID # 1 participates can be grasped as the community related to the user # 1.
As described above, the community-related data management device 7 refers to the AR table when a search is made for a certain user, and sequentially follows the T node ID and the relationship role R one or more times. , Community information related to the user who is the target of the search can be returned.

The community-related data management device 7 can determine whether the relationship between a certain user and the community is large or small, for example, based on the number of relationship roles R defined between the user and the community.
That is, when there is a relationship role R defined between a certain user and a certain community, the community-related data management device 7 can determine that these relationships are denser as the number is smaller, Conversely, as the number increases, it can be determined that these relationships are sparse.
Note that when the number of relationship roles R defined between a certain user and a certain community is zero, these relationships are most sparse.
Or, for example, when determining the strength of the relationship between the user and the community, use an indicator that the “host” or “creator” is more relevant than the “participant”. Regardless of the number of sex roles, it is also possible to determine the strength of the relationship between the user and the community.

[Profile Information]
Hereinafter, profile information handled in the community information search system 1 will be described.
FIG. 27 is a diagram illustrating user profile information read from the data access device 3 and / or the external profile information management device 14 by the data access server 5 shown in FIG. 1 in response to a request from the client PC 2. is there.
In the community information search system 1, the user profile information itself exists independently of the formation and deletion of the community, and the user profile information is identified by a path and becomes a search target.
As shown in FIG. 27, the user profile information includes a path and one or more attributes.
The path includes a combination of a profile name and a user ID (profile name and user ID will be described later).
In addition to these pieces of information, the path may include elements other than the profile name and user ID, such as attribute names included in the user profile information.

The profile name indicates the name of user profile information.
The user ID indicates a value for identifying the user.
The attribute is data constituting user profile information, and the user profile information includes one or more attributes.
Each attribute in the user profile information is identified by an attribute name and has an attribute value as a value.
In the user profile information shown in FIG. 27, the attribute of “name”, “age”, and “sex” of a certain user, the attribute of “movie” that the user likes, and “other” are added. Including attributes, each of which includes an attribute name and an attribute value.

FIG. 28 is a diagram illustrating community profile information.
FIG. 29 is a diagram illustrating community list information.
FIG. 30 is a diagram illustrating community member information.
FIG. 31 is a diagram illustrating reverse lookup buddy list information.
FIG. 32 is a diagram illustrating identifier table information.
The community profile information, community list information, community member information, and reverse buddy list information shown in FIGS. 28 to 31 have the same configuration as the user profile information shown in FIG.
In response to a request from the client PC 2, these pieces of information are read from the data access device 3 and / or the external profile information management device 14 by the data access server 5 (FIG. 1).

When the community profile information is realized by a relationship table, one record corresponds to one community.
As shown in FIG. 28, the community profile information includes a profile name and a community ID, and includes, as attributes, a name of the community, a date and time when the community is created, a creator of the community, and community member information.
One record of community list information corresponds to one user, and the community list information includes an ID list of communities to which each user belongs as an attribute.
Each community ID refers to the corresponding record in the community profile information.
As illustrated in FIG. 29, the community list information includes a profile name and a user ID, and includes, as attributes, community IDs of all communities to which the user indicated by the user ID belongs.
The community member information is referred to by a pointer attribute included in the (record) of the community profile information. One table corresponds to one community, and each table stores user IDs and statuses of all users belonging to the community. Is done.
As shown in FIG. 30, the community member information includes a profile name and a community ID, and indicates the user IDs of all users belonging to the community and the status in the community (for example, online, offline, busy, etc.). Information) as an attribute.

One record of reverse lookup buddy list information corresponds to one user.
The reverse buddy list can be considered as one community, and the corresponding record of the reverse buddy list information is referred to by the user ID of the community list information.
As shown in FIG. 31, the reverse lookup buddy list information includes a profile name and a user ID, and includes the user IDs of all users who have this user as buddy as attributes.
The reverse lookup buddy list is used to improve the efficiency and speed of the search.
As shown in FIG. 32, the identifier table information is stored in the identifier management device 8 and has a large amount of data used for communication between the community information search system 1 and the outside thereof (for example, SIP represented as a character string). URI, etc.) and an identifier (for example, unsigned integer type (32 bits) data) with a small amount of data used in the community information search system 1 is used. Used to uniquely identify a user.
The information shown in FIGS. 27 to 31 is created by, for example, the client PC 2 or the company server 102, and is sent to the data access device 3 and the external profile management device 14 for storage.

For example, when there are 10 million users in the community information search system 1, the user profile information has a data amount of about 10 Gbytes for each profile type (such as the preference information regarding the movie shown in FIG. 27). is expected.
In general, a user profile includes basic information (age, occupation, address, etc.) representing user characteristics, as well as preferences, matters of interest, interests, purposes, knowledge, etc., which are identified (distinguished). A profile type is used for this purpose.
The community profile information is expected to have a data amount of about 100 Gbytes as the entire community information search system 1.
Further, the community list information is expected to have a data amount of about 100 Gbytes as the entire community information search system 1.
The community member information is expected to have a data amount of about 100 Mbytes for each community.
Further, the reverse lookup buddy list information is expected to have a data amount of about 100 GB for the community information search system 1 as a whole.
Further, the identifier table information is expected to have a data amount of about 1 Gbyte for the community information search system 1 as a whole.
Among these pieces of information, the reverse lookup buddy list information and the identifier table information are stored in the memory 114 for speeding up the processing, and all the other information is stored in the recording device 118. It is cached in the memory 114 for speeding up.

[Profile specification information]
FIG. 33 is a diagram illustrating profile specification information stored and managed in the profile specification information management apparatus 12 shown in FIG.
The profile specification information is metadata of profile information and corresponds to each of the information shown in FIGS.
As shown in FIG. 33, the profile specification information includes profile name, schema information, data source, data access device information, and execution service information.
Further, the data access device information includes a key filter and a key hash table.

The profile name describes the name of profile information to be associated and is used to identify profile specification information.
The schema information describes the data structure of profile information.
The data source describes in which cluster node the profile information is stored.
The data access device information indicates in which data access device the profile information is stored.
The execution service information is included in the profile specification information as necessary, and indicates a service executed in accordance with the operation of the profile information.

The key filter is a function (specifically, a hash function such as MD5 or SHA1) used to generate a fixed-length pseudo-random number from a given message (in this specification, a user ID or a community ID). )
Note that a fixed-length pseudo-random number generated by the key filter is referred to as a key filter value.
The key hash table describes a table associating key filter values with data to be searched (values identifying the data access device 3 shown in FIG. 1).
Hereinafter, the “value for identifying the data access device 3” is described as “data access device ID”.

FIG. 34 is a diagram illustrating the reference relationship of the information illustrated in FIGS.
As already described, the user profile information itself exists independently of community formation and deletion.
In addition, when the community profile information is implemented in a relationship table, one record corresponds to one community.
The community member information is referred to by a pointer attribute included in the (record) of the community profile information. One table corresponds to one community, and each table stores user IDs and statuses of all users belonging to the community. Is done.
In addition, the community list information corresponds to one user, includes the ID list of the community to which each user belongs as an attribute, and the corresponding record in the community profile information is referenced by each community ID .
Also, reverse record buddy list information also has one record corresponding to one user.
The reverse buddy list is also considered as one community, and the corresponding record of the reverse buddy list information is referred to by the user ID of the community list information.
As shown in FIG. 34, information such as the schema and data source of the corresponding user profile information is read from the profile specification information identified by the profile name, and the user ID converted for internal use of the system is used. User profile information is identified.
User information (FIG. 27) is referred to by the profile specification information.
An external identifier (for example, SIP URI) is converted into an identifier (user ID) used inside the community information search system 1 by the identifier table information, and used as an ID of user profile information and community list information.

The community profile information is referred to by an attribute indicating the community ID of each community to which each user included in the community list information belongs.
The reverse buddy list information is referred to by the user ID included in the community list information.
The community member information is referred to by a pointer attribute included in the community profile information (record thereof), and one table corresponds to one community.
Each table of community member information stores user IDs and statuses of all users belonging to the community.
The community member information is updated as needed according to the user's participation in the community and withdrawal from the community, and is updated as needed as the user profile information and community profile information are changed.

FIG. 35 is a diagram illustrating profile information stored and managed in the data access device 3 shown in FIG.
The profile name, user ID or community ID (ID), key filter value, and profile information are as described above.
Whether or not the flag is profile information stored in the data access device 3 associated with the data access device ID when a certain data access device ID is no longer associated with the key filter value in the key hash table. Indicates.

Thus, the profile name in the path is used for the data access device 3 to identify and search the profile specification information.
Further, the retrieved profile specification information and path are used by the data access device 3 to retrieve the profile information.
The path can be used not only to search the entire profile information but also to search a part of the profile information.

[Data access device 3]
The data access device 3 shown in FIG. 1 executes a profile information operation program 30 described later with reference to FIGS. 36 to 40, and performs the following processes (1) to (3).

(1) Profile information search processing:
When the user operating the client PC 2 (FIG. 1) designates a path known to the user and instructs the retrieval of information (FIGS. 27 and 35), the client PC 2 accepts the designation and instruction, and the data access device 3 to send.
The data access device 3 instructed to search searches for profile information.
The data access device 3 transmits the searched profile information to the client PC 2 that requested the search.

(2) Profile information storage processing:
As in “(1) Profile information search process” described above, when the user specifies a path and profile information to be stored and instructs storage of the profile information, the client PC 2 accepts the specification and instruction, and data Transmit to the access device 3.
The data access device 3 instructed to store stores profile information.

(3) Profile information deletion processing:
As in “(1) Profile information search process” described above, when the user designates a path and instructs deletion of profile information, the client PC 2 accepts the designation and instruction and transmits it to the data access device 3. .
Note that the user can specify a path and profile information to be deleted.
The data access device 3 instructed to delete deletes the profile information.

Further, the data access device 3 executes a profile specification information confirmation program 40, which will be described later with reference to FIG. 41, and performs the following process (4).
(4) Profile specification information confirmation processing:
When the profile specification information update unit 426 (FIG. 42) updates the profile specification information (FIG. 33), the data access device 3 reads the updated profile specification information and changes it to the key hash table included in the profile specification information. Check if there was any.

Further, the data access device 3 performs the following process (5) in cooperation with the profile specification information management device 12 (FIG. 1).
(5) Profile specification information search processing:
If the profile specification information search unit 324 (FIG. 37) fails to search the desired profile specification information (FIG. 33) from the profile specification information cache DB 302, the data access device 3 Request a search for profile specification information that could not be searched.
The profile specification information management apparatus 12 requested to search searches for profile specification information.

Further, the data access device 3 performs the following process (6) in cooperation with the external profile information management device 14 (FIG. 1).
(6) Profile information search processing:
A search for profile information by the data access device 3 (a search process in the profile information search unit 338, which will be described later with reference to FIG. 37) has been performed, but the profile information cache DB 304, user profile information DB 306, community profile information DB 308, community When the desired information (FIGS. 27 to 31) is not stored in the list information DB 310 and the reverse lookup buddy list information DB 312 and cannot be searched, the data access device 3 searches the external profile information management device 14 for search. Request a search for profile information that could not be done.
The external profile information management device 14 requested to search searches for profile information.

[Profile Information Operation Program 30]
FIG. 36 is a diagram showing a configuration of the profile information operation program 30 executed on the data access device 3 shown in FIG.
As shown in FIG. 36, the profile information operation program 30 includes a communication processing unit 300, a profile specification information cache DB 302, a profile information cache DB 304, a user profile information DB 306, a community profile information DB 308, a community list information DB 310, and a reverse buddy list information. It comprises a DB 314, an identifier table information DB 316, a community member information DB 312, a profile information search unit 32, a profile information storage unit 36, and a profile information deletion unit 38.

The communication processing unit 300 performs processing necessary for communicating with other cluster nodes.
The profile specification information cache DB 302 stores profile specification information (FIG. 33) as cache data.
Details of the cache processing will be described later with reference to FIGS. 46 and 47.
The profile information cache DB 304 stores the information shown in FIGS. 27 to 32 as cache data.
Details of the cache process will be described later with reference to FIGS. 49 to 52.
The user profile information DB 306 stores user profile information (FIG. 27).
The community profile information DB 308 stores community profile information (FIG. 28).
The community member information DB 312 stores the community member information DB 312 (FIG. 29).
The community list information DB 310 stores community list information (FIG. 30).
The reverse lookup buddy list information DB 314 stores reverse lookup buddy list information (FIG. 31).
The identifier table information DB 316 stores identifier table information (FIG. 32).

FIG. 37 is a diagram showing a configuration of the profile information search unit 32 shown in FIG.
As shown in FIG. 37, the profile information search unit 32 includes a user interface (UI) unit 320, a request interpretation unit 322, a profile specification information search unit 324, a data access device specifying unit 326, an access control unit 334, and a service execution control unit. 336, a profile information search unit 338, and a cluster node specifying unit 340.
Further, the data access device specifying unit 326 includes a key filter value calculation unit 328, a data access device ID acquisition unit 330, and a data access device ID determination unit 332.
Further, the cluster node specifying unit 340 includes a data source reading unit 342, a profile information search unit 344, and a profile information storage unit 346.

The profile information search unit 32 includes the communication processing unit 300, profile specification information cache DB 302, profile information cache DB 304, user profile information DB 306, community profile information DB 308, community list information DB 310, and reverse lookup buddy list information DB 314 based on these components. In cooperation with the community member information DB 312 and the cluster node specifying unit 340, the above-described “(1) profile information search process” is performed.
Similarly, the profile information search unit 32 performs the above-described “(2) Profile information storage process” in cooperation with the profile information storage unit 36 (described later with reference to FIG. 39) and the like.
Similarly, the profile information search unit 32 performs “(3) profile information deletion processing” in cooperation with the profile information deletion unit 38 (described later with reference to FIG. 40) and the like.

The UI unit 320 provides a user interface for assisting the operation of the user of the data access device 3.
Similarly, the UI unit 320 is a user interface for assisting the user of another cluster node such as the client PC 2 through the network 100 to operate the data access device 3 (profile information operation program 30). I will provide a.
Further, the UI unit 320 accepts an operation performed on the user interface, and outputs data indicating the accepted operation to the request interpretation unit 322.

The request interpreter 322 performs conversion into a user ID in the system based on information in the identifier table information DB 314, and interprets user operations (command type / path, etc.) and profile information input from the UI unit 320. To do.
When the command transmitted from the client PC 2 requests “(1) profile information search processing”, the request interpretation unit 322 uses the interpreted path as the profile specification information search unit 324, key filter value calculation unit 328, data access. The information is output to device ID determination unit 332, profile information search unit 338, and profile information search unit 344.

When the command transmitted from the client PC 2 requests “(2) profile information storage processing”, the request interpretation unit 322 uses the interpreted path as the profile specification information search unit 324, the key filter value calculation unit 328, and the like. The data is output to the data access device ID determination unit 332.
Further, the request interpretation unit 322 outputs the interpreted path to the profile information storage unit 362 (described later with reference to FIG. 39).
Further, the request interpretation unit 322 outputs the interpreted profile information to the precondition check unit 360 (described later with reference to FIG. 39) and the profile information storage unit 362.

When the command transmitted from the client PC 2 requests “(3) profile information deletion processing”, the request interpreting unit 322 uses the interpreted path as the profile specification information searching unit 324, key filter, and the like shown in FIG. The data is output to the value calculation unit 328 and the data access device ID determination unit 332.
Further, the request interpretation unit 322 outputs the interpreted path to the profile information deletion unit 380 (described later with reference to FIG. 40).
Furthermore, if there is interpreted profile information, the request interpreting unit 322 outputs the profile information to the precondition checking unit 360 (described later with reference to FIG. 40) and the profile information deleting unit 380.

As shown in FIG. 33, the profile name is uniquely defined for each profile specification information (FIG. 33).
Accordingly, the profile specification information can be searched using the profile name included in the path output from the request interpreter 322.
The profile specification information search unit 324 uses the profile name input from the request interpreter 322 to search for profile specification information from the profile specification information cache DB 302 or the like.
In “(1) Profile information search processing”, the profile specification information search unit 324 converts the searched profile specification information into a key filter value calculation unit 328, a data access device ID acquisition unit 330, a service execution control unit 336, and a data source read. Output to the unit 342.
In “(2) Profile information storage process”, the profile specification information search unit 324 uses the searched profile specification information (FIG. 33) as a key filter value calculation unit 328, a data access device ID acquisition unit 330, and a service execution control. The data is output to the unit 336.
Further, the profile specification information search unit 324 outputs the searched profile specification information to the profile information storage unit 362 (described later with reference to FIG. 39).

In “(3) Profile information deletion process”, the profile specification information search unit 324 uses the searched profile specification information (FIG. 33) as a key filter value calculation unit 328, a data access device ID acquisition unit 330, and a service execution control. The data is output to the unit 336.
Furthermore, the profile specification information search unit 324 outputs the searched profile specification information to the profile information deletion unit 380 (described later with reference to FIG. 40).

FIG. 38 is a diagram showing processing of the data access device specifying unit 326 shown in FIG.
The key filter value calculation unit 328 of the data access device specifying unit 326 includes a user ID or community ID (ID) included in the path input from the request interpretation unit 322 and profile specification information input from the profile specification information search unit 324. Is used to calculate a key filter value and output it to the data access device ID acquisition unit 330.
Specifically, the key filter value calculation unit 328 calculates the key filter value by substituting the ID into the key filter.

The data access device ID acquisition unit 330 uses the key filter value input from the key filter value calculation unit 328 and the key hash table included in the profile specification information input from the profile specification information search unit 324. An identifier (data access device ID) for identifying the data access device 3 is derived.
The data access device ID acquisition unit 330 outputs the derived data access device ID to the data access device ID determination unit 332.

The data access device ID determination unit 332 is a data indicating that the data access device 3 corresponding to the data access device ID input from the data access device ID acquisition unit 330 operates the profile information operation program 30. It is determined whether or not the access device ID is included.
For example, when the profile information operation program 30 is executed on the data access device 3-i (i = 1 to n), the data access device ID determination unit 332 included in the profile information operation program 30 It is determined whether or not the data access device 3-i is included in one or more data access devices 3 corresponding to the device ID.
The data access device ID determination unit 332 does not include the data access device ID in which the profile information operation program 30 is operating (in the above example, one or more data access devices 3 corresponding to the data access device ID are If it is determined that the data access device 3-i is not included, the following processing is performed.

The data access device ID determination unit 332 specifies the path input from the request interpretation unit 322 to the data access device 3 corresponding to the data access device ID input from the data access device ID acquisition unit 330, and sets the path A search for the associated information (FIGS. 27 to 31) is requested.
At this time, a communication error may occur, for example, the data access device 3 requested to search refuses access.
When a communication error occurs in the data access device 3 requested to be searched, the access device ID determination unit 332 records that the data access device 3 that has denied access is in an error state.
Furthermore, the access device ID determination unit 332 prevents the access device 3 in which the error is recorded from requesting search for profile information.

Specifically, the access device ID determination unit 332 sends an error status of the cluster node or the access device 3 to an SNMP (Simple Network Management Protocol) agent (not shown) connected to the community information search system 1 (FIG. 1). Send.
The network administrator can manage an error state transmitted from the SNMP agent by an SNMP manager (not shown) connected to the community information search system 1.
Thereafter, the same processing is performed when various communication errors occur.

If the process is not interrupted due to a communication error or the like, the data access device 3 requested to search searches the user profile information DB 306 or the like for profile information associated with the specified path.
The data access device 3 requested to search transmits the searched profile information to the data access device ID determination unit 332.

In “(1) Profile information search process”, the data access device ID determination unit 332 transmits the profile information returned from the data access device 3 to the client PC 2 that requested the search.
After the data access device ID determination unit 332 appropriately transmits the profile information to the client PC, the profile information operation program 30 ends the search process.
In “(2) Profile information storage process” and “(3) Profile information deletion process”, the data access device ID determination unit 332 uses the profile information returned from the data access device 3 as the precondition check unit 360 (FIG. 39). And to be described later with reference to FIG.
On the other hand, when the data access device ID determination unit 332 determines that the data access device 3 on which the profile information operation program 30 is operating is included, the profile information operation program 30 moves the operation process to the access control unit 334.

The access control unit 334 determines whether or not the access from the client PC 2 that has requested the operation processing to the data access device 3 is permitted according to the access policy.
Specifically, the access control unit 334 inquires to the policy server 16 whether or not the data access device 3 can be accessed from the client PC 2 that has requested the operation processing.
Upon receiving the inquiry, the policy server 16 transmits access permission information to the data access device 3.
When the policy server 16 permits access, the profile information operation program 30 moves the operation process to the service execution control unit 336.
On the other hand, when the policy server 16 denies access, the profile information operation program 30 moves the operation process to the cluster node specifying unit 340.

The service execution control unit 336 reads execution service information included in the specification information input from the profile specification information search unit 324.
The service execution control unit 336 requests the service execution device 18 to execute a service based on the content of the read execution service information.
Note that the timing at which the service is executed may be before or after the profile information is manipulated.
Also, no service is required.
After the service execution apparatus 18 requested to execute the service appropriately executes the service, the profile information operation program 30 moves the operation process to the profile information search unit 338.

The profile information search unit 338 receives information (FIGS. 27 to 31) from the profile information cache DB 304, the user profile information DB 306, the community profile information DB 308, the community list information DB 310, the reverse lookup buddy list information DB 314, and the community member information DB 312. Search for.
Alternatively, the profile information search unit 338 obtains information (FIGS. 27 to 31) from any one of the profile information cache DB 304, the user profile information DB 306, the community profile information DB 308, the community list information DB 310, and the reverse lookup buddy list information DB 314. Search for.
Since the path is unique for each profile information, the profile information search unit 338 uses the path input from the request interpretation unit 322 to search for profile information associated with the path.

In “(1) Profile information search processing”, the profile information search unit 338 searches for profile information, and transmits the searched profile information to the client PC 2 that requested the search.
After the profile information search unit 338 appropriately returns the profile information to the client PC 2, the profile information operation program 30 ends the search process.
If the profile information search unit 338 cannot search for profile information, such as when an error occurs during the process, the profile information operation program 30 moves the operation process to the cluster node specifying unit 340.

The cluster node specifying unit 340 searches for profile information from other cluster nodes when access is denied by the access control unit 334 or when profile information cannot be searched by the profile information search unit 338.
The data source reading unit 342 uses the data source included in the profile specification information (FIG. 33) input from the profile specification information search unit 324 to derive a cluster node in which information (FIGS. 27 to 31) is stored. To do.
The data source reading unit 342 outputs the derived cluster node information to the profile information search unit 344.

The profile information search unit 344 reads the cluster node information input from the data source reading unit 342.
Further, the profile information search unit 344 designates the path input from the request interpretation unit 322 to the read cluster node and requests a search for profile information associated with the path.

The cluster node requested to search searches the user profile information DB 306 of the cluster node for information (FIGS. 27 to 31) associated with the path specified by the profile information search unit 344.
Details of this search process will be described later with reference to FIG.
Further, the cluster node requested to search searches for profile information, and then transmits the searched profile information to the profile information search storage unit 346.

In “(1) Profile information search process”, the profile information storage unit 346 transmits the profile information transmitted from the cluster node to the client PC 2 that requested the search.
Further, the profile information storage unit 346 stores the profile information transmitted from the cluster node in the profile information cache DB 304.
After the profile information storage unit 346 appropriately processes the profile information, the profile information operation program 30 ends the search process.

In “(2) Profile information storage process” and “(3) Profile information deletion process”, the profile information storage unit converts the profile information transmitted from the cluster node into the precondition checking unit 360 (see FIGS. 39 and 40). To be described later.
Further, the profile information storage unit 346 stores the profile information transmitted from the cluster node in the profile information cache DB 304.

FIG. 39 is a diagram showing a configuration of the profile information storage unit 36 shown in FIG.
As shown in FIG. 39, the profile information storage unit 36 includes a precondition check unit 360 and a profile information storage unit 362.
The profile information storage unit 36 performs the above-described “(2) Profile information storage process” in cooperation with the profile information search unit 32 and the like.
Further, the profile information storage unit 36 informs the client PC 2 that requested the storage that the information (FIGS. 27 to 31) is appropriately stored in addition to “(2) Profile information storage processing” as necessary. Notice.

The precondition checking unit 360 reads the information (FIGS. 27 to 31) input from the request interpreting unit 322 shown in FIG. 37, and determines whether or not the preconditions for storing these information match. Check.
Whether or not the preconditions are matched indicates, for example, whether or not a value of a certain attribute is within a predetermined range, whether or not it conforms to a format, and the like.
After the precondition checking unit 360 confirms that the preconditions match, the profile information operation program 30 moves the storage process to the profile information storage unit 362.

The profile information storage unit 362 reads a data source included in the profile specification information input from the profile specification information search unit 324.
Further, the profile information storage unit 362 specifies the path transmitted from the request interpretation unit 322 for the cluster node associated with the read data source, and stores the profile information input from the request interpretation unit 322. Request.

If there are a plurality of cluster nodes associated with the read data source, the load on the network 100 may increase.
In order to avoid a high load state of the network 100, the profile information storage unit 362 performs service execution by the service execution control unit 336 (FIG. 37) generated along with the profile information storage process for all cluster nodes. In addition, the confirmation of the precondition by the precondition confirmation unit 360 may not be requested, or may be requested to some cluster nodes as necessary.
Furthermore, the profile information storage unit 362 updates the information (FIGS. 27 to 31) by designating the path input from the request interpretation unit 322 to the user profile information DB 306 and the like.
After the profile information storage unit 362 appropriately stores and updates, the profile information operation program 30 ends the storage process.

FIG. 40 is a diagram showing a configuration of the profile information deletion unit 38 shown in FIG.
As shown in FIG. 40, the profile information deleting unit 38 includes a precondition checking unit 360 and a profile information deleting unit 380.
The profile information deletion unit 38 performs the above-described “(3) Profile information deletion process” in cooperation with the profile information search unit 32 and the like using these components.
Furthermore, the profile information deleting unit 38 requests that the information (FIGS. 27 to 31) is appropriately stored in addition to “(3) Profile information deleting process” as necessary. Notify

The precondition checking unit 360 reads the profile information input from the profile information search unit 338 or the profile information storage unit 346 shown in FIG. 37, and determines whether or not the preconditions for deleting the profile information match. Check.
After the precondition checking unit 360 confirms that the preconditions match, the profile information operation program 30 moves the deletion process to the profile information deleting unit 380.

The profile information deletion unit 380 reads the data source included in the profile specification information (FIG. 33) input from the profile specification information search unit 324 shown in FIG.
Further, the profile information deletion unit 380 specifies the path input from the request interpretation unit 322 shown in FIG. 37 for the cluster node associated with the read data source, and sets the profile information associated with the path. Make a request to delete.
Furthermore, the profile information deletion unit 380 deletes the description regarding the cluster node associated with the read data source from the read data source.

Note that if there are a plurality of cluster nodes associated with the read data source, the load status of the network 100 (FIG. 1) may increase.
In order to avoid a high-load state of the network, the profile information deletion unit 380 may perform the service execution control unit 336 (FIG. 37) The execution and the confirmation of the precondition by the precondition confirmation unit 360 may not be requested.
Furthermore, the profile information deletion unit 380 specifies a path with respect to the user profile information DB 306 and the like, and deletes information associated with the path (FIGS. 27 to 31).
After the profile information deletion unit 380 appropriately deletes, the profile information operation program 30 ends the deletion process.

[Profile Specification Information Confirmation Program 40]
The data access device 3 (FIG. 1) executes the profile specification information confirmation program 40 shown in FIG. 41 to perform the “(4) profile specification information confirmation process” described above.
FIG. 41 is a diagram showing a configuration of a profile specification information confirmation program 40 that operates on the data access device 3.
As shown in FIG. 41, the profile specification information confirmation program 40 includes a communication processing unit 300 and a profile specification information confirmation unit 400.

When the profile specification information is updated, the data access device 3 receives the profile specification information from the profile specification information management device 12 (described later with reference to FIG. 42).
The data access device 3 checks whether there is a change in the information related to the data access device 3 that is currently processing in the key hash table included in the profile specification information received via the communication processing unit 300.
In other words, the data access device 3 does not describe the key filter value associated with the data access device 3 that is currently performing processing by updating the key hash table, and the profile specification information stored in the data access device 3 It is checked whether or not it is necessary to move the data to another data access device 3.
If the key hash table has not been updated, and if the key hash table has been updated but the key filter value associated with the data access device 3 currently performing processing has not been updated, the profile specification information confirmation The program 40 ends the confirmation process.
On the other hand, when the key filter value associated with the data access device 3 currently performing processing is not described by updating the key hash table, the profile specification information stored in the data access device 3 is changed to other data. It is necessary to move to the access device 3.

Specifically, the data access device 3 performs the following processing.
The data access device 3 sets the flag included in the profile specification information to be moved to be invalid, and prevents access from other cluster nodes while the flag is set to invalid.
Furthermore, the data access device 3 stores the profile specification information to be moved in the data access device 3 that is supposed to store the profile specification information in the updated key hash table.
After the data access device 3 appropriately stores the profile specification information, the profile specification information confirmation program 40 ends the confirmation process.
By such processing, data movement between the data access devices 3 is minimized.

[Profile Specification Information Management Device 12]
The profile specification information management device 12 (FIG. 1) executes the profile specification information operation program 42 shown in FIG. 42, and in addition to the “(5) profile specification information search process” described above, the following (7) to (7) Process (9) is performed.

(7) Profile specification information storage processing:
When profile specification information is designated and storage of the profile specification information is requested, the profile specification information management device 12 stores the profile specification information.

(8) Profile specification information update processing:
When the profile name and profile specification information are specified and the profile specification information associated with the profile name is requested to be updated to the specified profile specification information, the profile specification information management device 12 updates the profile specification information. To do.

(9) Profile specification information deletion processing:
When the profile name is designated and the deletion of the profile specification information associated with the profile name is requested, the profile specification information management apparatus 12 deletes the profile specification information.

[Profile Specification Information Operation Program 42]
FIG. 42 is a diagram showing a configuration of the profile specification information operation program 42 operating on the profile specification information management apparatus 12 (FIG. 1).
As shown in FIG. 42, the profile specification information operation program 42 includes a communication processing unit 300, a request interpretation unit 420, a profile specification information search unit 422, a profile specification information storage unit 424, a profile specification information update unit 426, and a profile information deletion unit. 428 and profile specification information DB 430.
The profile specification information operation program 42 uses these components to perform the above-mentioned “(5) Profile specification information search process”, “(7) Profile specification information storage process”, “(8) Profile specification information update process” and “( 9) The process “profile specification information deletion process” is performed.

The request interpreter 420 interprets instructions (command types, profile names, etc.) and profile specification information transmitted from other cluster nodes via the communication processor 300.
When an instruction transmitted from another cluster node requests “(5) profile specification information search processing”, the request interpreter 420 outputs the interpreted profile name to the profile specification information search unit 422.

  When an instruction transmitted from another cluster node requests “(7) Profile specification information storage processing”, the request interpreter 420 sends the interpreted profile name and profile specification information to the profile specification information storage 424. Output.

  When an instruction transmitted from another cluster node requests “(8) Profile specification information update processing”, the request interpreter 420 sends the interpreted profile name and profile specification information to the profile specification information update unit 426. Output.

  When the command transmitted from the other cluster node requests “(9) Profile specification information deletion processing”, the request interpretation unit 420 outputs the interpreted profile name to the profile specification information deletion unit 428.

In “(5) Profile specification information search process”, the profile specification information search unit 422 searches for the profile specification information, and sends the searched profile specification information to the cluster node that requested the search via the communication processing unit 300. Send.
After the profile specification information search unit 422 appropriately transmits the profile specification information, the profile specification information operation program 42 ends the search process.

In “(7) Profile specification information storage processing”, the profile specification information storage unit 424 uses the profile name input from the request interpretation unit 422 to convert the profile specification information input from the request interpretation unit 422 into profile specification information. Store in the DB 430.
After the profile specification information storage unit 424 appropriately stores the profile specification information, the profile specification information operation program 42 ends the storage process.

  In “(8) Profile specification information storage process”, the profile specification information update unit 426 uses the profile name input from the request interpretation unit 420 to obtain profile specification information associated with the profile name from the profile specification information DB 430. Search for.

Further, the profile specification information update unit 426 updates the searched profile specification information to the profile specification information input from the request interpretation unit 420.
Furthermore, the profile specification information storage unit 424 transmits the stored profile specification information to the data access device 3, and requests confirmation of the profile specification information as described above with reference to FIG.
After the profile specification information update unit 426 appropriately updates the profile specification information, the profile specification information operation program 42 ends the update process.

In “(9) Profile specification information deletion process”, the profile specification information deletion unit 428 uses the profile name input from the request interpretation unit 420 to transmit profile specification information associated with the profile name from the profile specification information DB 430. delete.
After the profile specification information deletion unit 428 appropriately deletes the profile specification information, the profile specification information operation program 42 ends the deletion process.
The profile specification information DB 430 stores profile specification information.

[Profile information search program 44]
The external profile information management apparatus 14 (FIG. 1) executes the above-described “(6) Profile information search process” by executing the profile information search program 44 shown in FIG.
FIG. 43 is a diagram showing a configuration of a profile information search program 44 that operates on the external profile information management apparatus 14 (FIG. 1).
As shown in FIG. 43, the profile information search program 44 includes a communication processing unit 300, a profile information search unit 440, a user profile information DB 306, a community profile information DB 308, a community list information DB 310, a reverse lookup buddy list information DB 312 and community member information. It consists of DB316.

The communication processing unit 300 receives a profile information search request from the data access device 3 and outputs it to the profile specification information search unit 440.
In response to the search request input from the communication processing unit 300, the profile information search unit 440 searches for information (FIGS. 27 to 31) from the user profile information DB 306 and the like.
The profile information search unit 440 transmits the searched profile information to the data access device 3 via the communication processing unit 300 after searching the profile information.
After the profile information search unit 440 appropriately transmits the profile specification information, the profile information search program 44 ends the search process.

Among the client PCs 2, the client PC 2 operated by the administrator of the external profile information management apparatus 14 is used as the management PC 104.
The management PC 104 executes the profile specification information operation program 46 shown in FIG. 44 and performs the following process (10).
(10) Instruction transmission processing:
When an administrator operating the management PC 104 designates a profile name and profile specification information known to the administrator and instructs the operation, the management PC 104 accepts the instruction, and the profile specification information management apparatus 12 (FIG. 1). Send to.

FIG. 44 is a diagram showing the configuration of the profile specification information operation program 46 operating on the management PC 104 (FIG. 1).
As shown in FIG. 44, the profile specification information operation program 46 includes a communication processing unit 300, a UI unit 320, a request interpretation unit 420, a profile specification information search unit 422, a profile specification information storage unit 424, a profile specification information update unit 426, and The profile specification information deletion unit 428 is configured.

The request interpreter 420 interprets an instruction (instruction type / profile name, etc.) and profile specification information (FIG. 33) issued from the management PC 104, a profile specification information search unit 422, a profile specification information storage unit 424, a profile. The data is output to the specification information update unit 426 or the profile specification information deletion unit 428.
When the request interpretation unit 420 determines that the request from the management PC 104 is a search request, the profile specification information operation program 46 searches the profile specification information by the profile specification information search unit 422.
When the request interpretation unit 420 determines that the request from the management PC 104 is a storage request, the profile specification information operation program 46 stores the profile specification information by the profile specification information storage unit 424.

When the request interpretation unit 420 determines that the request from the management PC 104 is an update request, the profile specification information operation program 46 updates the profile specification information by the profile specification information update unit 426.
When the request interpretation unit 420 determines that the request from the management PC 104 is a deletion request, the profile specification information operation program 46 deletes the profile specification information by the profile specification information deletion unit 428.

The profile specification information storage unit 422 requests the profile specification information management apparatus 12 (FIG. 1) to search for the profile specification information input from the request interpretation unit 420.
When the profile specification information management apparatus 12 requested to search appropriately searches the profile specification information as shown in FIG. 42, the profile specification information operation program 46 ends the search process.

The profile specification information storage unit 424 requests the profile specification information management apparatus 12 (FIG. 1) to store the profile specification information input from the request interpretation unit 420.
When the profile specification information management apparatus 12 requested to store the profile specification information appropriately stores the profile specification information as shown in FIG. 42, the profile specification information operation program 46 ends the storage process.

The profile specification information update unit 426 sends profile specification information corresponding to the profile name input from the request interpreter 420 to the profile specification information management apparatus 12 (FIG. 1). Request to update to information.
When the profile specification information management apparatus 12 requested to store the profile specification information appropriately stores the profile specification information as shown in FIG. 42, the profile specification information operation program 46 ends the storage process.

The profile specification information update unit 428 requests the profile specification information management apparatus 12 (FIG. 1) to delete the profile specification information corresponding to the profile name input from the request interpretation unit 420.
When the profile specification information management apparatus 12 requested to be deleted appropriately deletes the profile specification information as shown in FIG. 42, the profile specification information operation program 46 ends the deletion process.

As described above, the administrator can update the profile specification information from the management PC 104 via the profile specification information management device 12.
Also, the administrator can operate the data access device by updating the key hash table in the profile specification information as follows.
The administrator can add a new data access device 3 to the community information search system 1 (FIG. 1) by adding information on the new data access device 3 to the key hash table.
Similarly, the administrator can delete the data access device 3 from the community information search system 1 by deleting the information of the data access device 3 from the key hash table.
Furthermore, the administrator can distribute the load on the data access device 3 of the community information search system 1 by changing the association between the key filter value and the data access device ID in the key hash table.

[Operations of Client PC 2, Data Access Device 3, Profile Specification Management Device 12, External Profile Management Device 14, Policy Server 16, and Service Execution Device 18]
Hereinafter, the operations of the client PC 2, the data access device 3, the profile specification management device 12, the external profile management device 14, the policy server 16, and the service execution device 18 except for the data access server 5 among the components of the community information search system 1 will be described. explain.
45A to 45E show operations of the client PC 2, the data access device 3, the profile specification management device 12, the external profile management device 14, the policy server 16, and the service execution device 18 in the community information search system 1 (FIG. 1) (S10). FIG. 4 is a first communication sequence diagram illustrating processing when a profile information search request is issued from the client PC 2 to the data access device 3 and the profile information operation program 30 is activated.

[Search Profile Information]
As shown in FIG. 45A, in step 100 (S100), the client PC 2 requests the data access device 3 to search for information (FIGS. 27 to 31) by specifying a path.
In step 102 (S102), the data access device 3 requested to search searches the profile specification information management device 12 for the profile specification information (FIG. 33) associated with the designated profile name.
In step 104 (S104), after the profile specification information is obtained, the profile specification information management device 12 transmits the obtained profile specification information to the data access device 3.

FIG. 46 is a sequence diagram illustrating operations performed simultaneously when the data access device 3 searches the profile specification information management device 12 for profile specification information in response to a request from the client PC 2 shown in FIG. 45A. is there.
As shown in FIG. 46, the profile specification information (S102) retrieved from the profile specification information management device 12 can be transmitted to the data access device 3 (S104) and stored as cache data in the profile specification information cache DB 302.
By such processing, the profile specification information can be searched by the data access device 3 without searching the profile specification information management device 12 for the profile specification information.

47, the data access device 3 shown in FIG. 45A retrieves the profile specification information (FIG. 33) from the profile specification information cache DB 302 of the data access device 3 or the profile specification information DB 430 of the profile specification information management device 12. It is a sequence diagram which illustrates the process to perform.
As shown in FIG. 46, in step 104 (S104), once the profile specification information is retrieved, it is stored in the profile specification information cache DB 302 as cache data.
Therefore, when the data access device 3 is requested to search, first, the profile specification cache DB 302 is searched (S102-1). After the profile specification information is obtained, the obtained profile specification information is accessed as data. It holds in the device 3 (S104-1).

Only when the desired profile specification information cannot be searched from the profile specification cache DB 302, the data access device 3 searches the profile specification information DB 430 of the profile specification information management device 12 (S102-2).
After the profile specification information is obtained from the profile specification information DB 430, the profile specification information management device 12 transmits the obtained profile information to the data access device 3 (S104-2).
By such processing, the data access device 3 can perform a search more efficiently.

Hereinafter, returning to FIG. 45A, the continuation of the processing in step 104 (S104) will be described.
In step 104 (S104), the data access device 3 reads the data access device information and the data source included in the retrieved profile specification information.
The data access device 3 obtains the storage location of the profile information associated with the designated path based on the read data access device information and data source.

The profile information operation program 30 determines the type of profile information and search processing in the profile information operation program 30 according to the storage location of the profile information.
The same applies to the storage process and the deletion process in the profile information operation program 30 below.

FIG. 48 is a diagram illustrating the association between the storage location of profile information and the type of profile information.
As shown in FIG. 48, the profile information is classified into physical profile information, external profile information, and logical profile information according to the storage location of the profile information derived from the processing of S104 (FIG. 45A).
The data access device 3 uses the part of the profile specification information (data source and data access device information) obtained by the process of step 104 (S104) to determine the storage location of the profile information, and from that storage location Search for profile information.

[Physical profile information]
48, when nothing is described in the data source, the data access device 3 determines that the profile information is stored in the data access device 3 (s). .
At this time, the data access device 3 specifies the data access device 3 in which the profile information is stored using the data access device information.

As a method for specifying the data access device 3, as shown in FIG. 38, a method using a key filter and a key hash table is adopted.
Thus, the profile information stored in the specified data access device 3 is referred to as physical profile information.

[External profile information]
48, when the data source has a description (for example, URL) identifying the external profile information management device 14, the data access device 3 indicates that the profile information is external profile information. It is determined that it is stored in the management device 14 (plurality).
At this time, the data access device 3 specifies the external profile information management device 14 in which the profile information is stored using the description of the data source.

The external profile device means a device connected to an existing DB that stores profile information (for example, a DB used before the information search system is constructed).
Thus, the profile information stored in the specified external profile device 14 is referred to as external profile information.

The external profile information can be stored in the profile information cache DB 304 using the data access device information.
This process makes profile information redundant.

[Logical profile information]
48, when the profile name is described in the data source, the data access device 3 describes the storage location of the profile information in the profile specification information associated with the profile name. Then, it is determined that the profile information is stored in the profile information data access device 3 (s) and the external profile information management device 14 (s).
Thus, the profile information stored in the identified data access device 3 and external profile information management device 14 is referred to as logical profile information.
Similar to the external profile information, the logical profile information can be stored in the profile information cache DB 304 using the data access information.

Hereinafter, returning to FIG. 45A, the continuation of the processing in step 104 (S104) will be described.
When the profile information operation program 30 determines from the profile specification information read in step 104 (S104) that the storage location is the data access device 3 (= physical profile information), the processing of S106 to S120 (FIG. 45B). The process of S122 to S132 (described later with reference to FIG. 45C) is performed.

If the profile information operation program 30 determines that the storage location is the external profile information device 14 (= external profile information) from the profile specification information read in the processing of step 104 (S104), the processing of S134 to S148 (Described later with reference to FIG. 45D).
If the profile information operation program 30 determines from the profile specification information read in step 104 (S104) that the storage location is the data access device 3 and the external profile information device 14 (= logical profile information), the process proceeds to S150. The process of S162 is performed (described later with reference to FIG. 45E).

[Search physical profile information (1)]
In step 104 (S104), after deriving the data access device ID using the profile specification information, the data access device 3 performs a search process on the data access device 3 associated with the derived data access device ID. It is determined whether or not the data access device 3 is included.
When the data access device 3 performing the search process is not included, the profile information operation program 30 performs the processes of S106 to S120.
On the other hand, when the data access device 3 performing the search process is included, the profile information operation program 30 performs the processes of S122 to S132.
Hereinafter, the processing of each step will be described.

In step 106 (S106) shown in FIG. 45B, the data access apparatus 3 that has received the search request receives the data access apparatus 3 associated with the data access apparatus ID derived by the process of S104 in the process of S100. A search for information (FIGS. 27 to 31) is requested.
In step 108 (S108), the policy server 16 is inquired as to whether or not the data access device 3 is accessible from the client PC 2 that has issued the search request.
In step 110 (S110), the policy server 16 checks whether or not access is possible, and transmits it to the data access device 3 requested to be searched in the process of S106.

In step 112 (S112), the data access device 3 requested to search in the process of S106 reads the execution service information included in the profile specification information (FIG. 33) searched in the process of S104.
Further, the data access device 3 requested to search in the processing of S106 requests the service execution device 18 to execute a service based on the read execution service information.

Note that the profile information operation program 30 may or may not execute the service in the process of S112 before or after searching for profile information.
The same applies to the service execution associated with storing and deleting profile information.
After the service execution device 18 appropriately executes the service (S114), the data access device 3 requested to search in the process of S106 searches the user profile information DB 306 and the like (FIGS. 27 to 31) (see FIG. 27 to FIG. 31). S116).
The data access device 3 requested to search in step 106 (S106) searches the information (FIGS. 27 to 31), and then transmits the searched profile information to the data access device 3 that has received the search request from the client PC 2. (S118).

FIG. 49 is a sequence diagram illustrating operations performed simultaneously when the data access device 3 retrieves profile information from another data access device 3 in response to a request from the client PC 2 shown in FIG. 45A. .
As shown in FIG. 49, profile information (S116) retrieved from another data access device 3 that has received a path designation can be transmitted to the data access device 3 and stored as cache data in the profile information cache DB 304. (S118).
By such processing, the profile information can be searched by the data access device 3 without searching the profile information for another data access device 3.

FIG. 50 is a sequence diagram illustrating a process in which the data access device 3 illustrated in FIG. 45A searches the profile information for another data access device 3.
As shown in FIG. 49, in step 118 (S118), once the profile information is retrieved, it is stored as cache data in the profile information cache DB 304.
Therefore, the data access device 3 searches the profile information stored in the profile information cache DB 304 (S116-1) to obtain profile information before specifying a path to another data access device 3 (S106). After being obtained, the obtained profile information is held in the data access device 3 (S118-1).

Only when the desired profile information is not stored in the profile information cache DB 304, a search is performed by designating a path to another data access device 3 (S106 to S116-2).
The other data access device 3 that has received the path designation transmits the obtained profile information to the data access device 3 after the profile information is obtained (S118-2).
By this processing, the data access device 3 can perform a search more efficiently.
The other data access device 3 that has received the path designation transmits the obtained profile information to the data access device 3 after the profile information is obtained (S118-2).
By this processing, the data access device 3 can perform a search more efficiently.

Hereinafter, returning to FIG. 45B, the processing after step 120 (S120) will be described.
Receiving the profile information in step 118 (S118), the data access device 3 transmits the received profile information to the client PC 2 that requested the search (S120).
After the client PC 2 receives the transmitted profile information, the profile information operation program 30 ends the physical profile information search process.

[Search physical profile information (2)]
In step 122 (S122) shown in FIG. 45C, the data access device 3 inquires of the policy server 16 whether or not the client PC 2 that requested the search can access the data access device 3.
In step 124 (S124), the policy server 16 checks whether access is possible and transmits it to the data access device 3.

In step 126 (S126), the data access device 3 reads the execution service information included in the profile specification information searched in step 104 (S104).
Furthermore, the data access device 3 requests the service execution device 18 to execute a service based on the execution service information.
When the service execution device 18 appropriately executes the service (S128), the data access device 3 searches the profile information cache DB 304 or the like for profile information (S130).
The data access device 3 transmits the profile information searched by the process of step 130 (S130) to the client PC 2 that requested the search (S132).
After the client PC 2 receives the transmitted profile information, the profile information operation program 30 ends the physical profile information search process.

[Search external profile information]
In step 134 (S134) shown in FIG. 45D, the data access device 3 that has received the search request from the client PC 2 determines that it is the storage location of the profile information from the client PC 2 that issued the search request by the processing of S104 (FIG. 45A). The policy server 16 is inquired of whether or not the external profile information management apparatus 14 thus made accessible.
In step 136 (S136), the policy server 16 checks whether access is possible and transmits it to the data access device 3.

In step 138 (S138), the data access device 3 reads the execution service information included in the profile specification information (FIG. 33) retrieved in S104 (FIG. 45A).
Further, the data access device 3 requests the service execution device 18 to execute the service based on the read execution service information.
When the service execution device 18 appropriately executes the service (S140), the data access device 3 sends the profile information to the external profile information management device 14 determined as the storage location of the profile information in the processing of S104 (FIG. 45A). A search is requested (S142).
The external profile information management apparatus 14 requested to search in step 142 (S142) searches for information (FIGS. 27 to 31) from the profile information DB 306 and the like (S144).
After retrieving the profile information, the external profile information management device 14 transmits the retrieved profile information to the data access device 3 in step 146 (S146).

FIG. 51 is a sequence diagram illustrating operations performed simultaneously when the data access device 3 searches the external profile information management device 14 for profile information in response to a request from the client PC 2 shown in FIG. 45D. .
As shown in FIG. 51, a search request is received from the data access device 3 (S142), and the profile information searched from the external profile information management device 14 (S144) is transmitted to the data access device 3 (S146). , And can be stored in the profile information cache DB 304.
By this processing, the profile information can be searched by the data access device 3 without searching the profile information with respect to the external profile information management device 14.

FIG. 52 is a sequence diagram illustrating a process in which the data access device 3 illustrated in FIG. 45D searches the external profile information management device 14 for profile information.
As shown in FIG. 52, as shown in the process of S146 (FIG. 51), once the profile information is retrieved, it is stored as cache data in the profile information cache DB 304 of the data access device 3.

Therefore, the data access device 3 first searches the profile information stored in the profile information cache DB 304 before requesting the external profile information management device 14 to search (step 142 (S142)) (S144). -1) After the profile information is obtained, the obtained profile information is held in the data access device 3 (S146-1).
Only when the corresponding profile information is not stored in the profile information cache DB 304 of the data access device 3, the data access device 3 requests the external profile information management device 14 to search (S142), and the external profile information management device 14 Searches the user profile information DB 306 and the like (S144-2).
After obtaining the profile information, the external profile information management device 14 transmits the obtained profile information to the data access device 3 (S146-2).
By this processing, the data access device 3 can perform a search more efficiently.

Hereinafter, returning to FIG. 45D, the processing after step 148 (S148) will be described.
After receiving the profile information transmitted in step 146 (S146), the data access device 3 transmits the profile information to the client PC 2 that requested the search (S148).
After the client PC 2 receives the transmitted profile information, the profile information operation program 30 ends the external profile information search process.

[Search logical profile information]
As shown in FIG. 45E, in step 150 (S150), the data access device 3 determines from the client PC 2 that requested the search that the data access device 3 and the external profile information management determined as the storage location of the profile information by the processing of S104. The policy server 16 is inquired whether the device 14 is accessible.
In step 152 (S152), the policy server 16 checks whether access is possible and transmits it to the data access device 3.

In step 154 (S154), the data access device 3 reads the execution service information included in the profile specification information (FIG. 33) retrieved in the process of S104.
Further, the data access device 3 requests the service execution device 18 to execute a service based on the read execution service information.

When the service execution device 18 appropriately executes the service (S156), the data access device 3 and the external profile information management device 14 retrieve information (FIGS. 27 to 31) from the user profile information DB 306 and the like (S158). .
In step 160 (S160), the data access device 3 and the external profile information management device 14 transmit the profile information retrieved in the process of S158 to the data access device 3.

The data access device 3 receives the profile information transmitted in step 160 (S160), and transmits it to the client PC 2 that requested the search (S162).
After the client PC 2 receives the transmitted profile information, the profile information operation program 30 ends the logical profile information search process.

[Store profile information]
53A to 53E show operations of the client PC 2, the data access device 3, the profile specification management device 12, the external profile management device 14, the policy server 16, and the service execution device 18 in the community information search system 1 (FIG. 1) (S20). FIG. 6 is a second communication sequence diagram illustrating
53A to 53E show processing when a profile information storage request is issued from the client PC 2 to the data access device 3 and the profile information operation program 30 is activated.

In step 200 (S200) shown in FIG. 53A, the client PC 2 requests the data access apparatus 3 to store the profile information by specifying the path and profile information.
In step 202 (S202) shown in FIG. 53B, the data access device 3 that has received the search request from the client PC 2 designates the path and profile information for the data access device 3 that has been set as the storage location by the processing of S104, and the profile Request storage of information.
In step 204 (S204), the data access device 3 confirms whether or not the profile information specified in the process of S200 satisfies the precondition for storing the profile information.
After confirming that the preconditions match, the data access device 3 sends a profile information storage request to all the data access devices 3 determined as the storage location of the profile information in step S104 in step 206 (S206).

The data access device 3 that has received the storage request in step 206 (S206) and stored the profile information transmits success or failure of the storage to the data access device 3 that has received the storage request from the client PC 2 (S208).
The data access device 3 that has received the storage request from the client PC 2 transmits the success or failure of the transmitted storage to the client PC 2 that issued the storage request (S210).
After the client PC 2 receives the success or failure of the storage, the profile information operation program 30 ends the physical profile information storage process.

If there are a plurality of data access devices 3 determined as storage locations in step 104 (S104), the process of S108 (inquiry of access availability), the process of S110 (accessibility), the process of S112 (service execution request), The process of S114 (service execution) and the process of S204 (precondition check) need only be performed for one of them.
Similarly, in FIG. 53C, the processing in step 122 (S122) (accessibility inquiry), the processing in S123 (accessability), the processing in S126 (service execution request), the processing in S128 (service execution), and the processing in S212 (Precondition check) may be performed only for one of them.

Similarly, in FIG. 53D, when there are a plurality of data access devices 3 determined to be storage locations, the processing of S134 (inquiry of accessibility), the processing of S136 (accessibility), the processing of S138 (service execution request) The processing of S140 (service execution) and the processing of S218 (prerequisite check) need only be performed for one of them (hereinafter, the same applies when deleting profile information).
When the data access apparatus 3 confirms the precondition in step 218 (S218), the data access apparatus 3 requests the external profile information management apparatus 14 to store the profile information in the process of S220.

Similarly, in FIG. 53E, when there are a plurality of data access devices 3 determined to be storage locations, the processing at S150 (inquiry for accessibility), the processing at S152 (accessibility), and the processing at S154 (service execution request) The processing of S156 (service execution) and the processing of S228 (precondition check) need only be performed for one of them (hereinafter, the same applies when deleting profile information).
FIG. 53E shows an example in which service execution is requested only from the data access device 3 (S154), and the precondition is confirmed only in the data access device 3 (S228).

[Delete Profile Information]
54A to 54E show operations of the client PC 2, the data access device 3, the profile specification management device 12, the external profile management device 14, the policy server 16 and the service execution device 18 in the community information search system 1 (FIG. 1) (S30). FIG. 6 is a third communication sequence diagram illustrating
54A to 54E show processing when a profile specification information deletion request is issued from the client PC 2 to the data access device 3 and the profile information operation program 30 is activated.

As shown in FIG. 54A, in step 100 (S100), the client PC 2 designates a path and requests the data access device 3 to delete information (FIGS. 27 to 31).
At this time, the client PC 2 can specify profile information to be deleted for the data access device 3.
In step 204 (S204) shown in FIG. 54B, if there is profile information specified by the process of S200, the data access apparatus 3 deletes the profile information as in the process of S204 (FIG. 53A). Check whether the prerequisites for doing so are met.
In step S204, the data access device 3 confirms that the preconditions match. In step 300 (S300), the data access device 3 stores the profile information in all the data access devices 3 determined as the storage location of the profile information in step S104. Send a delete request.

After the data access device 3 receiving the deletion request from the client PC 2 transmits the success or failure of the deletion to the client PC 2, the profile information operation program 30 ends the physical profile information deletion process.
Similarly to step 204 (S204), whether or not the preconditions for deleting the profile information match also in the processing of S212 (FIG. 54C), S218 (FIG. 54D), and S228 (FIG. 54E). Check.
In FIG. 54D, after confirming the precondition in the process of S218, the data access apparatus 3 requests the external profile management apparatus 14 to delete the profile information in the process of S304.
Similarly to the processing in step 300 (S300), in S302 (FIG. 54C), S306 (FIG. 54D), and S308 (FIG. 54E), the profile information is deleted and whether or not the deletion is requested to the client PC 2 that requested the deletion. After the transmission, the profile information operation program 30 ends the deletion process.

As described above, in the community information search system 1, the client PC 2, the data access device 3, the profile specification management device 12, the external profile management device 14, the policy server 16, and the service execution device 18 ensure system redundancy. The load on the cluster nodes constituting the system can be distributed.
In the community information search system 1, the client PC 2, the data access device 3, the profile specification management device 12, the external profile management device 14, the policy server 16, and the service execution device 18 use key filters and key hashes when searching for information. By using identifiers via a table, the complexity associated with managing identifiers can be reduced, and the cluster nodes holding information can be appropriately distributed.
Furthermore, in the community information search system 1, the client PC 2, the data access device 3, the profile specification management device 12, the external profile management device 14, the policy server 16 and the service execution device 18 use the key hash table to In order to change the data, only the key hash table needs to be changed, and the data change can be minimized.

Logical volume
Next, the logical volume will be described.
FIG. 55 is a diagram illustrating a logical volume.
User profile information, community profile information, community list information, community member information, and reverse lookup buddy list information (FIGS. 27 to 31) have the reference relationship described above with reference to FIG.

User profile information, community profile information, community list information, and community member information (FIGS. 27 to 30) are managed by a total of four logical volumes, one for each logical volume shown in FIG.
Since the data size of the logical volume is enormous and increases, it is necessary to ensure scalability, and it is necessary to maintain the availability and reliability of the entire system, so that a plurality of data access devices 3 can be operated in a redundant configuration. Is appropriate.
The user profile information DB 306, community profile information DB 308, community list information DB 310, and community member information DB 316 (FIGS. 36 and 43) are appropriately partitioned based on the user ID and community ID, and the recording device 118 of the data access device 3 is used. (Disc area; FIG. 2).
Further, since the reverse lookup buddy list information is a target of particularly high-speed search, when the community information search system 1 is operated (operated), all information is stored in the in-memory storage unit 520 (described later with reference to FIG. 56). It is stored and is the target of search processing.
Furthermore, the data access device 3 and the external profile management device 14 may be provided with a log indicating a search history for the logical volume.

[Data access server 5]
The data access server 5 (FIG. 1) identifies which profile information is accessed by the profile name included in the path among the operations transmitted from the client PC 2, that is, which logical volume (data access device 3). Then, a process of transmitting a search execution command (request) to the corresponding data access device 3 is performed.
That is, part of the processing performed in the data access device 3 described above is executed in the data access server 5.

[Data Access Server Program 50]
FIG. 56 is a diagram showing a configuration of the data access server program 50 executed in the data access server 5 (FIG. 1).
From the viewpoint of processing, the data access server 5 is located between the client PC 2 and the data access device 3, and functions of the data cache corresponding to the logical volume (FIG. 55) and the relevance of the accessed data ( A new prefetch function based on semantic locality is provided.
As shown in FIG. 56, the data access server program 50 includes a search processing unit 500, an ID conversion unit 502, a search monitor unit 504, a cache capacity control unit 506, a profile specification information search unit 508, an in-memory storage management unit 510, a logic A volume management unit 512, a community related information search unit 514, a log processing unit 516, and an in-memory storage unit 520 are included.

With these components, the data access server program 50 accepts a search request from the client PC 2, executes a search using the data access device 3, and requests a search for the search result returned from the data access device 3. Return to client PC2.
If the data access server program 50 is cached in the data access server 5 in each of the logical volumes (FIG. 55) stored in the data access device 3 and the external profile management device 14, it is useful for speeding up the search. A part of the expected information (FIGS. 27 to 31) is cached on the logical volume provided corresponding to each of the logical volumes 1 to n on the memory 114 (memory area; FIG. 2) of the data access server 5. Store in areas 1-n.
The storage capacities of these cache areas are changed according to the search characteristics.
For example, when a large number of searches related to a certain logical volume i occur, the storage capacity of the cache area i of that logical volume is increased. Conversely, when a small number of searches related to a certain logical volume j occur, the cache area j of that logical volume increases. The storage capacity of the cache area is dynamically controlled such that the storage capacity is reduced.
Further, in these cache areas, portions of the data included in the logical volume that are highly related to each other are selectively stored.

In addition, the data access server program 50 accepts a search from the client PC 2, and when the searched information is in the cache areas 1 to n, reads the information from the cache areas 1 to n and returns it to the client PC 2 that requested the search. .
When the searched information is not in the cache areas 1 to n, the data access server program 50 executes a search using the data access device 3, and uses the search result returned from the data access device 3 as the client that requested the search. Return to PC2.

The search processing unit 500 accepts a search operation from the client PC 2, outputs information indicated by the operation to each component, and controls the processing of each component in order to execute the requested search.
In addition, the search processing unit 500 returns the search result obtained from the data access device 3 or the in-memory storage unit 520 to the client PC 2 that requested the search.
That is, the search processing unit 500 first searches the cache areas of the logical volumes 1 to n stored in the in-memory storage unit 520, and when there is a search result in the cache area, the search result is sent to the client PC 2. return.
On the other hand, when there is no search result in the cache area, the search processing unit 500 controls the logical volume management unit 512 to request the data access device 3 to search, and the search processing unit 500 requests the logical access of the data access device 3 or the external profile management device 14. A search result is obtained from the volume and returned to the client PC 2.

In the data access server program 50, the ID converter 502 cooperates with the identifier management device 8 (FIG. 1) to convert an identifier used for communication with the outside of the system and an identifier used inside the system.
The profile specification information search unit 508 uses the profile name input from the search processing unit 500 to search for profile specification information from the profile specification information cache DB or the profile specification management device 12 (profile specification information DB 430).
The in-memory storage unit 520 transfers a part of the logical volumes 1 to n to the logical volumes 1 to 1 of the memory 114 (memory area; FIG. 2) of the data access server 5 (FIG. 1) under the control of the in-memory storage management unit 510. Store in each n cache area.
The search monitor unit 504 monitors the search received from the client PC 2 and, for example, the number of searches related to each of the communities 1 to n and the number of searches related to each user to the data access server 5. Collect information about the search history and its characteristics.
The search monitor unit 504 outputs the collected information to the log processing unit 516 and stores it as a log.

The cache capacity control unit 506 optimizes the storage capacity of each cache area in the in-memory storage unit 520 based on the search characteristics obtained from the log processing unit 516.
That is, for example, when the number of searches related to the logical volume i is large and the number of searches related to the logical volume j (1 ≦ i, j ≦ n) is small, the cache capacity control unit 506 stores the cache area of the logical volume i. The in-memory storage management unit 510 is notified that the storage capacity should be increased and the storage capacity of the cache area of the logical volume j should be reduced.

The logical volume management unit 512 requests a search for the data access device 3 in accordance with the control from the in-memory storage management unit 510, and uses the information (FIGS. 27 to 31) returned from the data access device 3 in response to this request. To the in-memory storage management unit 510.
The community-related information search unit 514 sends the AR table, the T-node identifier table, and the A-node identifier table (FIGS. 14 to 16) to the community-related data management device 7 according to the control from the in-memory storage management unit 510. The information necessary for creating FIG. 26) is transmitted, and the AR table, T node identifier table, and A node identifier table are created.
Further, the community related information search unit 514 requests the AR table from the community related data management device 7 in response to the request from the in-memory storage management unit 510, and returns the AR table ( The information included in FIG. 26) is output to the in-memory storage management unit 510.

The in-memory storage management unit 510 increases or decreases the storage capacity of the cache area in the in-memory storage unit 520 according to the notification from the cache capacity control unit 506.
That is, when the cache capacity control unit 506 notifies that the storage capacity of the cache area of the logical volume i should be increased and the storage capacity of the cache area of the logical volume j should be reduced, the in-memory storage management In accordance with this notification, the unit 510 increases the storage capacity of the cache area of the logical volume i and decreases the storage capacity of the cache area of the logical volume j.
Further, the in-memory storage management unit 510 refers to, for example, the log processing unit 516, obtains a search target user, and notifies the user ID of this user to the community related information search unit 514. The community-related data management device 7 uses the user ID and the AR table (FIG. 26) transmitted from the community-related information search unit 514 to obtain other users and / or communities related to this user, The response is returned to the in-memory storage management unit 510 via the community related information search unit 514.

For example, in the cache of the logical volume i, the storage capacity of the cache of the logical volume i is newly set in a state in which a portion having relations within three relevance roles is stored for the user who is the object of the search. When the number is significantly increased, the in-memory storage management unit 510 obtains, from the data access device 3, a part of the logical volume i having a relation within five relevance roles to the search target user. Store in i's cache.
That is, by such processing, the in-memory storage management unit 510 does not simply increase the amount of information stored in the cache of the logical volume i whose storage capacity has increased, but only information related to the search target user. Are selectively added to the cache of the logical volume i.

Further, for example, the cache of the logical volume j is newly stored in the cache of the logical volume j in a state in which a portion related to the search target user within 5 relevance roles is stored. When the capacity is significantly reduced, the in-memory storage management unit 510 stores only the portion of the logical volume j that is related within three relevance roles in the cache of the logical volume j for the search target user. In this way, the other parts are deleted.
That is, by such processing, the in-memory storage management unit 510 does not simply reduce the amount of information stored in the cache of the logical volume j whose storage capacity has become small, but is highly related to the search target user. Only in the cache of logical volume j.
The in-memory storage management unit 510 causes the log processing unit 516 to store information indicating such a change in the storage capacity of the cache as a log.
The log stored in the log processing unit 516 is appropriately output to the in-memory storage management unit 510 and the cache capacity control unit 506 as needed for processing.

[Operation of Data Access Server 5]
Hereinafter, the operation of the data access server 5 will be described.
FIG. 57 is a flowchart showing the first cache capacity changing process by the data access server program 50 shown in FIG.
As shown in FIG. 57, in step 500 (S500), the cache capacity control unit 506 of the data access server program 50 refers to the log stored in the log processing unit 516, and performs a search related to the logical volume to be processed. Analyze the characteristics.

In step 502 (S502), the cache capacity control unit 506 determines whether it is necessary to change the cache storage capacity of the logical volume to be processed.
When it is not necessary to change the storage capacity of the cache, the data access server program 50 sets the processing target as another logical volume and returns to the processing of S500.
The data access server program 50 proceeds to the process of S504 when the cache storage capacity should be reduced, and proceeds to the process of S508 when the cache storage capacity should be increased.

In step 504 (S504), when the cache capacity control unit 506 notifies the in-memory storage management unit 510 that the storage capacity of the cache should be reduced, the in-memory storage management unit 510 has been stored in the cache. The information is stored in the recording device 118 (disk area) of the data access device 3.
In step 506 (S506), the in-memory storage management unit 510 performs a process necessary for reducing the cache capacity.

In step 508 (S508), when the cache capacity control unit 506 notifies the in-memory storage management unit 510 that the storage capacity of the cache should be increased, the in-memory storage management unit 510 causes the memory 114 of the data access server 5 to operate. It is determined whether or not there is a free area in (memory area).
The data access server program 50 proceeds to the processing of S510 when there is an empty area in the memory 114, and proceeds to the processing of S500 for other caches as processing targets otherwise.

In step 512 (S512), the cache capacity control unit 506 determines whether to continue control of the cache capacity.
When continuing to control the cache capacity, the data access server program 50 returns to the processing of S500 with another cache as a processing target, and ends the processing otherwise.

The case where the cache capacity is changed (reduced / enlarged) based on the community related information has been described with reference to FIG. 57. The amount of data that can be stored in the cache area is described below with reference to FIG. A case where the cache capacity is changed based only on the above will be described.
FIG. 58 is a communication sequence diagram showing a second cache capacity change process (reduction process; S82) by the data access server program 50 shown in FIG.
As shown in FIG. 58, in step 820 (S820), the cache capacity control unit 506 refers to the search log stored in the log processing unit 516.
In step 822 (S822), the log processing unit 516 returns the search characteristics to the cache capacity control unit 506.

In step 824 (S824), the cache capacity control unit 506 instructs the in-memory storage management unit 510 to reduce the cache capacity.
In step 826 (S826), the in-memory storage management unit 510 instructs the in-memory storage unit 520 to write back the profile information.
In step 828 (S828), the in-memory storage unit 520 returns profile information to the in-memory storage management unit 510.

In step 830 (S 830), the in-memory storage management unit 510 specifies path and profile information for the logical volume management unit 512.
In step 832 (S 832), the logical volume management unit 512 transmits path and profile information to the data access device 3.
In step 834 (S834), the data access device 3 stores the profile information sent from the logical volume management unit 512.

In step 836 (S836), the data access device 3 returns success or failure (success) in storing the profile information to the logical volume management unit 512.
In step 838 (S838), the logical volume management unit 512 notifies the in-memory storage management unit 510 of success or failure (success).
In step 840 (S840), the in-memory storage management unit 510 instructs the in-memory storage unit 520 to reduce the cache area.

In step 842 (S842), the in-memory storage unit 520 performs processing for reducing the cache area.
In step 844 (S844), the in-memory storage unit 520 notifies the in-memory storage management unit 510 of the success or failure of cache area reduction (success).
In step 846 (S846), the in-memory storage management unit 510 notifies the cache capacity control unit 506 of success or failure (success).

FIG. 59 is a communication sequence diagram showing a third cache capacity change process (enlargement process; S86) by the data access server program 50 shown in FIG.
In steps 820 and 822 (S820 and S822), the cache capacity control unit 506 refers to the search log stored in the log processing unit 516, and the log processing unit 516 returns the search characteristics to this.
In step 860 (S860), the cache capacity control unit 506 instructs the in-memory storage management unit 510 to expand the cache area.
In step 862 (S862), the in-memory storage management unit 510 instructs the in-memory storage unit 520 to expand the cache area.

In step 864 (S864), the in-memory storage unit 520 performs processing for expanding the cache area.
In step 866 (S866), the in-memory storage unit 520 returns the success or failure (success) of the expansion of the cache area to the in-memory storage management unit 510.
In step 868 (S868), the in-memory storage management unit 510 notifies the cache capacity control unit 506 of success or failure (success).

Here, prefetching (prefetch) processing of community related information will be described.
FIG. 60 is a flowchart showing a prefetch process (S88) of community related information.
As shown in FIG. 60, in step 880 (S880), the in-memory storage management unit 510 refers to the log stored in the log processing unit 516, analyzes the search history, and specifies the user to be accessed. (For example, the most recent access at the time of referring to the log is adopted as the specifying condition).

In step 882 (S882), an AR table related to the target user is acquired using the identified target user identifier.
In step 884 (S884), community related information corresponding to the strength of the relationship with the target user is specified.
In step 886 (S886), it is determined whether or not there is a free area in the cache area of the in-memory storage. If there is no free area, the process returns to the first process and the search history is analyzed.
When there is a free area, in step 888 (S888), the data access device 3 is instructed to read the corresponding profile information.

In step 890 (S890), the read profile information is written to the cache area of the in-memory storage.
In step 892 (S892), it is determined whether or not the prefetching process is continued. When the prefetching process is continued, the process returns to the first process, and when it is not continued, the process ends.

FIG. 61 is a communication sequence diagram showing a prefetch process (S90) of community related information.
As shown in FIG. 61, in step 900 (S900), the in-memory storage management unit 510 refers to the search log stored in the log processing unit 516.
In step 902 (S902), the log processing unit 516 returns the target user ID to the in-memory storage management unit 510.

In step 904 (S904), the in-memory storage management unit 510 notifies the community related information search unit 514 of the target user ID.
In step 906 (S906), the community related information search unit 514 notifies the target user ID to the community related data management device 7.
In step 908 (S908), the community-related data management device 7 searches the AR table.

In step 910 (S910), the community-related data management device 7 returns the AR table obtained as a result of the search to the community-related information search unit 514.
In step 912 (S912), the community related information search unit 514 transmits community information based on the strength of the relationship with the target user to the in-memory storage management unit 510.
In step 914 (S914), the in-memory storage management unit 510 designates a path to the logical volume management unit 512.
In step 916 (S 916), the logical volume management unit 512 designates a path for the data access device 3.
In step 918 (S918), the data access device 3 searches for profile information.

In step 920 (S920), the data access device 3 transmits the profile information obtained as a result of the search to the logical volume management unit 512.
In Step 922 (S922), the logical volume management unit 512 transmits profile information to the in-memory storage management unit 510.
In step 924 (S924), the in-memory storage management unit 510 transmits the profile information to the in-memory storage unit 520.
In step 926 (S926), the in-memory storage unit 520 stores profile information.
In step 928 (S928), the in-memory storage unit 520 notifies the in-memory storage management unit 510 of the success or failure (success) in storing the profile information.

FIG. 62 is a flowchart showing the overall processing (S54) of the data access server 5.
As shown in FIG. 62, in step 540 (S540), the logical volume management unit 512 of the data access server program 50 (FIG. 56) sends a relation table to the data access device 3 in accordance with an instruction from the in-memory storage management unit 510. The logical volume (FIG. 55) corresponding to is set.
In step 542 (S542), the in-memory storage unit 520 allocates a cache area to each logical disk volume in accordance with an instruction from the in-memory storage management unit 510.

In step 544 (S544), the search processing unit 500 receives an access request from the client PC2.
The search processing unit 500 instructs the ID conversion unit 502 to convert between an identifier outside the system and an identifier inside the system.
In step 546 (S546), the search processing unit 500 searches the profile specification information according to the path included in the search request.
When the profile specification information is returned, the process proceeds to S548. If the profile specification information is not obtained for some reason, an appropriate error process is performed, and the process returns to S544 to receive a new access request.

In step 548 (S548), the search processing unit 500 determines the request type received in S544.
The data access server program 50 proceeds to the process of S58 when the request type is write (profile information storage process or the like), and proceeds to the process of S60 when the request type is read (profile information search process).

In step 58 (S58), the in-memory storage management unit 510 executes a writing process (described later with reference to FIG. 63) to the in-memory storage unit 520.
In step 60 (S60), the in-memory storage management unit 510 executes a read process (described later with reference to FIG. 64) from the in-memory storage unit 520.

In step 550 (S550), the in-memory storage management unit 510 determines whether or not to continue the process.
The data access server program 50 proceeds to the process of S554 when continuing the process, and proceeds to the process of S552 otherwise.
In step 552 (S552), the in-memory storage management unit 510 reads the log information from the log processing unit 516 and instructs the logical volume management unit 512 to update the data stored in the logical volume.

In step 554 (S554), the in-memory storage management unit 510 converts the data stored in the cache area (memory area) corresponding to the logical volume of the in-memory storage into the disk area of the data access device that constitutes the logical volume. To determine whether to execute processing (synchronization processing) for maintaining data consistency between the memory and the disk.
The data access server program 50 proceeds to the process of S556 when executing the synchronization process, and proceeds to the process of S558 otherwise.

In step 556 (S556), the in-memory storage management unit 510 reads the log information from the log processing unit 516, and instructs the logical volume management unit 512 to update the data stored in the logical volume.
Before writing the data update (change) to the real device, the logical volume management unit 512 records the operation (difference) regarding the data as a log, and at an appropriate commit point (that is, when executing synchronous processing). Processing to reflect the recorded operation on the device (log application processing) is performed.
In step 558 (S558), the in-memory storage management unit 510 instructs the log processing unit 516 to add data update to the log.

FIG. 63 is a flowchart showing the write processing (S58) in the in-memory storage management unit 510 shown in FIG.
In step 580 (S580), the in-memory storage management unit 510 determines whether or not to write to the memory area.
When writing the memory area, the in-memory storage management unit 510 instructs the in-memory storage unit 520 to write data, and the process proceeds to S582.
In other cases, the in-memory storage management unit 510 instructs the logical volume management unit 512 to write data, and the process proceeds to S590.
In step 582 (S582), the in-memory storage unit 520 determines whether data exists in the memory area.
The in-memory storage management unit 510 proceeds to the process of S584 when data exists in the memory area, and proceeds to the process of S586 otherwise.

In step 584 (S584), the in-memory storage unit 520 overwrites and updates data in the memory area.
In step 586 (S586), the in-memory storage unit 520 stores the data in the memory area.
In step 588 (S588), the in-memory storage management unit 510 instructs the log processing unit 516 to add data update to the log.
In step 590 (S590), the logical volume management unit 512 instructs the data access device 3 to write data to the disk area.
In step 592 (S592), the in-memory storage management unit 510 makes a write response to the client PC2.

FIG. 64 is a flowchart showing the read processing (S60) in the in-memory storage management unit 510 shown in FIG.
In step 600 (S600), the in-memory storage management unit 510 determines whether or not reading from the memory area is requested.
When reading from the memory area is requested, the in-memory storage management unit 510 instructs the in-memory storage unit 520 to read data, and the process proceeds to S602.
In other cases, the in-memory storage management unit 510 instructs the logical volume management unit 512 to read data, and the process proceeds to S612.

In step 602 (S602), the in-memory storage unit 520 determines whether data exists in the memory area.
When data exists in the memory area, the in-memory storage unit 520 proceeds to the process of S604, and otherwise proceeds to the process of S606.
In step 604 (S604), the in-memory storage unit 520 reads data from the memory area.
In step 606 (S606), the in-memory storage unit 520 notifies the in-memory storage management unit 510 that there is no data in the memory area, and the in-memory storage management unit 510 reads the data from the logical volume management unit 512. Instruct.

In step 608 (S608), the in-memory storage management unit 510 that has received the data instructs the in-memory storage unit 520 to write the data to the memory area.
In step 610 (S610), the in-memory storage management unit 510 instructs the log processing unit 516 to add (update) data update to the log.
In step 612 (S612), the logical volume management unit 512 instructs the data access device 3 to read data from the disk area.
In step 614 (S614), the in-memory storage management unit 510 makes a read response to the client PC2.

The cache capacity change process in FIG. 57 is not directly linked with the read (search) / write (store) process described above with reference to FIGS. 62 to 64, but is implemented as a daemon process and independently in the background. Since it operates, it does not appear in the communication sequence diagrams of FIGS.
Also, the processing of S540 and S542 shown in FIG. 62 is the initial setting (initialization) processing of the data access server 5, and this processing is not described in FIGS. 65 and 66 described later.
FIG. 65 and FIG. 66 show the profile information search processing, which corresponds to the portion related to the read processing / response of FIG. 62 and FIG.
Also, since FIG. 63 is a flowchart of the writing process (storage, etc.), it is not related to FIGS. 65 and 66 described later.

Hereinafter, the overall processing of the community information search system 1 (FIG. 1) in which the data access server 5 operates will be described.
FIG. 65 is a communication sequence diagram showing search processing (S62) of the data access server 5 in the community information search system 1.
FIG. 66 is a communication sequence diagram showing in detail a part of the search processing (S66) of the data access server 5 in the community information search system 1 shown in FIG.
As shown in FIGS. 65 and 66, in step 620 (S620), the client PC 2 designates a path to the data access server 5.
In step 622 (S622), the data access server 5 searches the profile specification management apparatus 12 for profile specification information.
In step 624 (S624), the profile specification management device 12 returns profile specification information to the data access server 5.

When the profile specification information is returned from the profile specification management device 12, the search processing unit 500 of the data access server program 50 (FIG. 56) specifies a path to the in-memory storage management unit 510 in step 660 (S660). .
In step 662 (S662), the in-memory storage management unit 510 searches the in-memory storage unit 520 for profile information.
In step 664 (S664), the in-memory storage unit 520 returns profile information to the in-memory storage management unit 510.

When the profile information is returned from the in-memory storage unit 520, the logical volume management unit 512 outputs the physical profile information to the search processing unit 500 (corresponding to the processing in step 672 (S672)).
The following processes of S666, S626 to S638, and S670 are executed when there is no profile information in the in-memory storage unit 520.
In step 666 (S666), the in-memory storage management unit 510 designates a path to the logical volume management unit 512.

In step 626 (S626), the search processing unit 500 specifies a path from the data access server 5 to the user profile information DB 306 to the community member information DB 316 (FIG. 43) of the data access device 3.
In step 628 (S628), the data access device 3 inquires of the policy server 16 whether access is possible.
In step 630 (S630), the policy server 16 responds to the data access device 3 as to whether or not access is possible.
In step 632 (S632), the data access device 3 requests the service execution device 18 to execute the service.
In step 634 (S634), the service execution device 18 executes the service and returns the result to the data access device 3.

In step 636 (S636), the user profile information DB 306 to the community member information DB 316 of the data access device 3 search for profile information.
In step 638 (S638), the user profile information DB 306 to the community member information DB 316 of the data access device 3 transmit the profile information obtained as a result of the search to the logical volume management unit 512 of the data access server program 50. .

In step 670 (S670), the logical volume management unit 512 outputs profile information to the in-memory storage management unit 510.
In step 672 (S 672), the logical volume management unit 512 outputs physical profile information to the search processing unit 500.
In step 640 (S640), the data access server 5 transmits physical profile information to the client PC2.

FIG. 67 is a communication sequence diagram showing a cache saving process (S68) of profile specification information in the community information search system 1.
The search for the profile specification information is always performed in the process of S544 (step for determining access request reception) in FIG. 62 whenever an access request from the client PC 2 is received.
As shown in FIG. 67, in step 680 (S680), the search processing unit 500 specifies a path to the profile information search unit 508.
In step 682 (S682; however, the same processing as S622 in FIG. 65), the profile information search unit 508 of the data access server program 50 searches the profile specification information DB 430 of the profile specification management device 12 for profile specification information. Do.

In step 684 (S 684), the profile specification information DB 430 (FIG. 42) of the profile specification management apparatus 12 returns profile specification information to the profile information search unit 508 of the data access server program 50.
In step 686 (S686), the profile information search unit 508 stores the returned profile specification information in the profile specification information cache DB provided in the storage area of the profile information search unit 508.

FIG. 68 is a communication sequence diagram showing the profile specification information search process (S70) in the community information search system 1.
The search for the profile specification information is always executed when an access request from the client PC 2 is received.
In the processing of S622 and S624 shown in FIG. 65, profile specification information search processing that does not consider the cache DB is performed. FIG. 68 shows processing that considers the cache storage processing (FIG. 67). Yes.
Further, the process shown in FIG. 68 is performed in the process of S544 (step of determining access request reception) shown in FIG.

As shown in FIG. 68, in step 700 (S700), the search processing unit 500 designates a path to the profile specification information search unit 508.
In step 702 (S702), the profile specification information search unit 508 of the data access server program 50 searches the profile specification information cache DB for profile specification information.
In step 704 (S704), the profile specification information cache DB returns profile specification information to the profile specification information search unit 508.

In the processing of S702, even if the profile specification information cache DB is searched, if the profile specification information is not found, S706 and S708 are executed.
In step 706 (S706), the profile specification information search unit 508 searches the profile specification information DB 430 of the profile specification management device 12 for profile specification information.
In step 708 (S708), the profile specification information DB 430 of the profile specification management apparatus 12 returns the profile specification information obtained as a result of the search to the search processing unit 500.
In step 710 (S710), the profile specification information search unit 508 returns the profile specification information obtained as a result of the search to the search processing unit 500.

FIG. 69 is a communication sequence diagram showing a cache saving process (S72) of profile information in the community information search system 1.
In step 720 (S720; the same processing as S660 shown in FIG. 66), the search processing unit 500 of the data access server program 50 designates a path to the in-memory storage management unit 510.
In step 722 (S722; corresponding to S666, S626), the in-memory storage management unit 510 specifies a path for the user profile information DB 306 to the community member information DB 316 of the data access device 3.

In step 628 (S628) to step 638 (S638), as shown in FIGS. 65 and 66, an inquiry about whether access is allowed, a response about whether access is possible, a service execution request, a service execution response, and physical profile information transmission are performed.
In step 730 (S730), the in-memory storage management unit 510 outputs profile information to the in-memory storage unit 520.
The in-memory storage unit 520 stores profile information from the in-memory storage management unit 510.

FIG. 70 is a communication sequence diagram showing a profile information storage process (S74) in the community information search system 1.
71 is a communication sequence diagram showing in detail a part (S78) of the profile information storing process shown in FIG.
As shown in FIGS. 70 and 71, in step 740 (S740), the client PC 2 designates path and profile information to the data access server 5 (the search processing unit 500 of the data access server program 50).
In step 780 (S780), the search processing unit 500 outputs the path and profile information to the in-memory storage management unit 510.

In step 782 (S782), the in-memory storage management unit 510 outputs profile information to the in-memory storage unit 520.
In step 784 (S784), the in-memory storage unit 520 stores the input profile information.
In step 786 (S786), the in-memory storage unit 520 notifies the in-memory storage management unit 510 of success or failure of writing profile information to the cache area corresponding to the logical volume specified by the path.

In step 788 (S788), the in-memory storage management unit 510 designates path and profile information to the logical volume management unit 512.
In step 742 (S 742), the logical volume management unit 512 designates path and profile information for the data access device 3.

In step 628 (S628) to step 632 (S632), as shown in FIG. 65 and FIG. 66, an access permission inquiry, an access permission response, a service execution request, and a service execution response are performed.
In step 750 (S750), the user profile information DB 306 to the community member information DB 316 of the data access device 3 confirm the preconditions.
As described in the precondition checking unit 360 shown in FIG. 39, the process for checking the precondition is, for example, whether the value of a certain attribute is within a predetermined range with respect to the stored profile information. This is a process for confirming whether or not it conforms to the format.
This precondition checking process is performed in accordance with a write instruction issued from the logical volume management unit 512 to the data access device 3 in step 590 of the write process (FIG. 63) in the in-memory storage management unit 510. It is executed by the data access device 3.
In step 752 (S752), the user profile information DB 306 to the community member information DB 316 of the data access device 3 store profile information.

In step 754 (S754), the data access device 3 transmits success or failure of storing the profile information (in the profile information DB) to the data access server 5 (the logical volume management unit 512 of the data access server program 50). .
In step 794 (S794), the logical volume management unit 512 of the data access server program 50 outputs success or failure to the in-memory storage management unit 510.
In step 796 (S796), the in-memory storage management unit 510 outputs success or failure to the search processing unit 500.
In step 756 (S756), the data access server 5 (the search processing unit 500 of the data access server program 50) transmits success / failure to the client PC2.

  The present invention can be used for data retrieval.

It is a figure which illustrates the structure of the community information search system concerning this invention. It is a figure which illustrates the hardware constitutions of each cluster node, such as client PC shown in FIG. FIG. 3 is a first diagram illustrating a community indicated by community information to be searched by the community information search system shown in FIG. 1. It is the 2nd figure which illustrates the community shown by community information used as a candidate for search by the community information search system shown in Drawing 1, and (A) is a community before the community shown in Drawing 3 is formed. The state of the user of an information search system is shown, (B) shows formation of the community shown in FIG. 3, (B) shows the change of the community shown in FIG. FIG. 6 is a third diagram illustrating a community indicated by community information to be searched by the community information search system shown in FIG. 1. It is a figure which shows the data model at the time of converting relevance network type data. It is a figure which shows the data structure which converted n data which have a series of relations made into the memory | storage object according to the data model shown in FIG. It is a figure which shows an example of the method of expressing the relationship between related nodes. It is a figure which shows the structure of the relationship network type data which expressed the data of the 1st and 2nd example using the edge group which shows the relationship between a node group and each node. FIG. 2 is a block diagram for a preferred embodiment of the present invention. It is a figure which rewrites and shows the relation of the data illustrated to Fig.8 (a). FIG. 12 is a diagram showing a generalized data structure shown in FIG. 11. FIG. 10 is a diagram showing a generalized relationship between the data shown in FIGS. 8B and 9. FIG. 13 is a diagram showing an association role (AR) table used for storing data having the structure shown in FIG. 12. It is a figure which shows the identifier (ID (Identifier)) table for T nodes used in order to memorize | store the data which take the structure shown in FIG. It is a figure which shows the identifier (ID) table for A nodes used in order to memorize | store the data which take the structure shown in FIG. It is a figure which illustrates the data search method in the community related data management apparatus shown in FIG. It is a 1st flowchart which shows the whole process (S1070) of the search in the community relevant data management apparatus shown in FIG. It is a flowchart which shows the selection process (S1072) of the related node based on the search filter shown in FIG. 20 is a flowchart showing the node ID and node name acquisition process (S1074) shown in FIGS. It is a figure which shows the structure of the community relevant data management program performed in the community relevant data management apparatus shown in FIG. It is a figure which illustrates the data input with respect to the community related data management apparatus (community related data management program; FIG. 21) shown in FIG. 1, and the search conditions contained in the search of the data contained in this. It is a figure which illustrates the AR table created by the AR entry creation unit (FIG. 21) and the ARDB management unit and stored in the ARDB. It is a figure which illustrates the ID table for T nodes which are created by the ID entry creation unit (FIG. 21) and the IDDB management unit and stored in the IDDB. It is a figure which illustrates the ID table about A node created by ID entry creation part (Drawing 21) and an IDDB management part. It is a figure which illustrates the management method of the community information by the community related data management apparatus shown in FIG. It is a figure which illustrates the user profile information which the data access apparatus shown in FIG. 1 reads from a data access apparatus and an external profile information management apparatus or either of these according to the request | requirement from a client PC. It is a figure which illustrates community profile information. It is a figure which illustrates community list information. It is a figure which illustrates community member information. It is a figure which illustrates reverse lookup buddy list information. It is a figure which illustrates identification table information. It is a figure which illustrates the profile specification information memorize | stored and managed by the data access apparatus and profile specification information management apparatus which were shown in FIG. It is a figure which shows the reference relationship etc. of the information shown in FIGS. It is a figure which illustrates the profile information memorize | stored and managed by the data access apparatus shown in FIG. It is a figure which shows the structure of the profile information operation program run on the data access apparatus shown in FIG. It is a figure which shows the structure of the profile information search part shown in FIG. It is a figure which shows the process of the data access apparatus specific | specification part shown in FIG. It is a figure which shows the structure of the profile information storage part shown in FIG. It is a figure which shows the structure of the profile information deletion part shown in FIG. It is a figure which shows the structure of the profile specification information confirmation program which operate | moves on a data access apparatus. It is a figure which shows the structure of the profile specification information operation program 42 which operate | moves on a profile specification information management apparatus (FIG. 1). It is a figure which shows the structure of the profile information search program which operate | moves on an external profile information management apparatus (FIG. 1). It is a figure which shows the structure of the profile specification information operation program which operate | moves on management PC (FIG. 1). First part of first communication sequence illustrating operations (S10) of client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in community information search system (FIG. 1) FIG. Second part of the first communication sequence illustrating the operations (S10) of the client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in the community information search system (FIG. 1) FIG. Third part of the first communication sequence illustrating the operations (S10) of the client PC, data access device, profile specification management device, external profile management device, policy server, and service execution device in the community information search system (FIG. 1) FIG. Fourth part of the first communication sequence illustrating the operations (S10) of the client PC, data access device, profile specification management device, external profile management device, policy server, and service execution device in the community information search system (FIG. 1) FIG. The fifth part of the first communication sequence illustrating the operations (S10) of the client PC, data access device, profile specification management device, external profile management device, policy server, and service execution device in the community information search system (FIG. 1) FIG. FIG. 46 is a sequence diagram illustrating operations performed simultaneously when the data access device searches the profile specification information management device for profile specification information in response to a request from the client PC shown in FIG. 45A. FIG. 45A is a sequence diagram illustrating a process in which the data access device shown in FIG. 45A retrieves profile specification information (FIG. 33) from the profile specification information cache DB of the data access device or the profile specification information DB of the profile specification information management device. It is. It is a figure which illustrates matching with the memory | storage position of profile information, and the kind of profile information. FIG. 45B is a sequence diagram illustrating operations performed simultaneously when a data access device searches for profile information for another data access device in response to a request from the client PC shown in FIG. 45A. FIG. 45B is a sequence diagram illustrating a process in which the data access device illustrated in FIG. 45A searches for profile information for another data access device. FIG. 46 is a sequence diagram illustrating operations performed simultaneously when the data access device searches the external profile information management device for profile information in response to a request from the client PC shown in FIG. 45D. FIG. 45D is a sequence diagram exemplifying processing in which the data access device shown in FIG. 45D searches for profile information with respect to the external profile information management device. First part of second communication sequence illustrating operations (S20) of client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in community information search system (FIG. 1) FIG. Second part of second communication sequence illustrating operations (S20) of client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in community information search system (FIG. 1) FIG. Third part of second communication sequence illustrating operations (S20) of client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in community information search system (FIG. 1) FIG. Fourth part of second communication sequence illustrating operations (S20) of client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in community information search system (FIG. 1) FIG. The fifth part of the second communication sequence illustrating the operations (S20) of the client PC, data access device, profile specification management device, external profile management device, policy server, and service execution device in the community information search system (FIG. 1) FIG. First part of the third communication sequence illustrating the operations (S30) of the client PC, data access device, profile specification management device, external profile management device, policy server, and service execution device in the community information search system (FIG. 1) FIG. Second part of the third communication sequence illustrating the operations (S30) of the client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in the community information search system (FIG. 1) FIG. Third part of the third communication sequence illustrating the operations (S30) of the client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in the community information search system (FIG. 1) FIG. Fourth part of the third communication sequence illustrating the operation (S30) of the client PC, data access device, profile specification management device, external profile management device, policy server, and service execution device in the community information search system (FIG. 1) FIG. The fifth part of the third communication sequence illustrating the operations (S30) of the client PC, data access device, profile specification management device, external profile management device, policy server and service execution device in the community information search system (FIG. 1) FIG. It is a figure which illustrates a logical volume. It is a figure which shows the structure of the data access server program performed in a data access server (FIG. 1). 57 is a flowchart showing first cache capacity change processing by the data access server program shown in FIG. 56. FIG. 57 is a communication sequence diagram showing a second cache capacity change process (reduction process; S82) by the data access server program shown in FIG. 56. FIG. 57 is a communication sequence diagram showing a third cache capacity change process (enlargement process; S86) by the data access server program shown in FIG. 56. It is a flowchart which shows the prefetch (prefetch) process (S88) of community relevant information. It is a communication sequence diagram which shows the prefetch (prefetch) process (S90) of community related information. It is a flowchart which shows the whole process (S54) of a data access server. 63 is a flowchart showing a writing process (S58) in the in-memory storage management unit shown in FIG. 62. 63 is a flowchart showing a read process (S60) in the in-memory storage management unit shown in FIG. 62. It is a communication sequence diagram which shows the search document process (S62) of the data access server in a community information search system. FIG. 66 is a communication sequence diagram showing in detail a part (S 66) of search document processing of the data access server in the community information search system shown in FIG. 65. It is a communication sequence diagram which shows the cache preservation | save process (S68) of the profile specification information in a community information search system. It is a communication sequence figure showing search processing (S70) of profile specification information in a community information search system. It is a communication sequence diagram which shows the cache preservation | save process (S72) of the profile information in a community information search system. It is a communication sequence figure showing storage processing (S74) of profile information in a community information search system. FIG. 71 is a communication sequence diagram showing in detail a part (S78) of the profile information storage processing shown in FIG. 70.

Explanation of symbols

1 ... Community information search system,
12 ... Profile specification information management device,
14 ... External profile information management device,
15 ... External profile information storage device,
16: Policy server,
18 ... Service execution device,
2 ... Client PC,
110 .. Cluster node body,
112 ... CPU,
114 ... memory,
118... Recording device,
120... Recording medium,
122... Communication device,
DESCRIPTION OF SYMBOLS 3 ... Data access apparatus 30 ... Profile information operation program 300 ... Communication processing part 302 ... Profile specification information cache DB
304 ... Profile information cache DB
306 ... Profile information DB
308 ... Community profile information DB,
310 ... community list information DB,
312 ... Community member information DB,
314... Reverse buddy list information DB,
316 ... identifier table information DB,
32 ... Profile information search part,
320 ... UI unit,
322 ... request interpreter,
324 ... Profile specification information search unit,
326... Data access device specifying unit,
328 ... Key filter value calculation unit,
330: Data access device ID acquisition unit,
332 ... Data access device ID determination unit,
334 ... access control unit,
336 ... service execution control unit,
338: Profile information search unit,
340... Cluster node identification unit,
342... Data source reading unit,
344: Profile information search unit,
346: Profile information storage unit,
36: Profile information storage unit,
360 ... Prerequisite checking part,
362 ... Profile information storage unit,
38 ... Profile information deletion part,
380 ... Precondition check part,
382 ... Profile information deletion unit,
104 ... management PC,
40: Profile specification information confirmation program,
400: Profile specification information confirmation unit,
42 ... Profile specification information operation program,
420 ... request interpreter,
422 ... Profile specification information search unit,
424 ... Profile specification information storage unit,
426: Profile specification information update unit,
428 ... Profile specification information deletion unit,
430 ... Profile specification information DB,
44 ... Profile information search program,
440 ... Profile information search unit,
46 ... Profile specification information operation program,
5 ... Data access server,
50: Data access server program,
500 ... search processing unit,
502 ... ID converter,
504 ... Search monitor section,
506: Cache capacity control unit,
508: Profile specification information search unit,
510: In-memory storage management unit,
512 ... Logical volume management unit,
514 ... Community related information search part,
516: Log processing unit,
520: In-memory storage unit,
7 ... Community-related data management device,
70: Community related data management program,
72 ... DB management part,
720 ... Management operation receiving part,
722 ... AR entry creation unit,
726: ARDB management unit,
728 ... IDDB management unit,
76 ... DB section 76,
760 ... ARDB760,
762... IDDB 762
764... IDDB 764
78 ... DB search section,
780 ... Accepting search operation part,
782 ... Search condition creation unit,
784 ... Search control unit,
786 ... ARDB search unit,
788 ... IDDB search unit,
8: Identifier management device,

Claims (10)

Each of the search systems is configured by combining a plurality of unit information, and performs a search for a plurality of search target information to be searched.
A search device;
Unit information of the search target information indicated by the request in response to a request indicating unit information of the search target information from the search device, having a predetermined storage capacity, storing all of the plurality of search target information And a storage device that reads the data at a predetermined data transfer rate and returns it to the search device,
The search device includes:
A cache unit including a plurality of target storage capacities corresponding to the plurality of search target information, wherein each of the plurality of target storage capacities includes at least part of unit information included in the plurality of search target information, Caching means that caches an amount corresponding to the size of each of a plurality of target storage capacities, and outputs the cached unit information at a data transfer rate faster than the data transfer rate of the storage device in response to an external request When,
Capacity control means for controlling the size of each of the plurality of target storage capacities included in the cache means based on the search characteristics for each of the plurality of search target information;
When the unit information corresponding to the search request received from the outside is cached in the cache unit, the unit information is requested and read from the cache unit. Otherwise, the unit information is stored in the storage device. A search system comprising: a search means that requests, reads from, and returns to a search request source. Further comprising an information creation device that defines the strength of the relationship between each of the plurality of unit information, and creates each of the plurality of search target information by combining these unit information,
The search device includes:
A cache control means for controlling the cache means so as to cause the cache means to cache the unit information based on the strength of the relationship defined between the unit information included in the plurality of search target information. The search system according to claim 1. The information creation device includes:
Direct relationship defining means for defining a direct relationship between a combination of two unit information included in the plurality of unit information;
An information creating means for creating the search object information by further combining a combination of two unit information in which the direct relationship is defined;
The cache control means of the search device is configured so that one or more direct relationships are defined between any two unit information stored in each of the plurality of target storage capacities of the cache means. The search system according to claim 2, wherein the cache unit caches the data. The cache control unit of the search device is configured so that the number of direct relationships defined between any two unit information stored in each of the plurality of target storage capacities of the cache unit is minimized. The search system according to claim 3, wherein the cache unit caches the data. The search system according to claim 3 or 4, wherein the cache control unit causes the cache unit to cache the unit information so that the frequency of requesting the unit information to the storage device is minimized. The information creation means of the information creation device creates the search target information by combining all of the plurality of unit information so as to belong to a community defined between these unit information. The search system described in any one. The storage device stores the search target information using a disk storage device,
The search system according to claim 1, wherein the cache unit of the search device stores the unit information using a semiconductor memory. Each of the search devices is configured by combining a plurality of unit information and performs a search for a plurality of search target information to be searched, all of the search target information has a predetermined storage capacity, In response to a request indicating the unit information of the search target information from the search device, the unit information of the search target information indicated by the request is read at a predetermined data transfer rate and stored in a storage device that is returned to the search device. And
A cache unit including a plurality of target storage capacities corresponding to the plurality of search target information, wherein each of the plurality of target storage capacities includes at least part of unit information included in the plurality of search target information, Caching means that caches an amount corresponding to the size of each of a plurality of target storage capacities, and outputs the cached unit information at a data transfer rate faster than the data transfer rate of the storage device in response to an external request When,
Capacity control means for controlling the size of each of the plurality of target storage capacities included in the cache means based on the search characteristics for each of the plurality of search target information;
When the unit information corresponding to the search request received from the outside is cached in the cache unit, the unit information is requested and read from the cache unit. Otherwise, the unit information is stored in the storage device. A search device comprising: search means for requesting, reading out, and returning to a search request source. A search method that includes a computer and that is configured by combining a plurality of unit information, and that is executed by a search device that performs a search for a plurality of search target information to be searched, All have a predetermined storage capacity, and in response to a request indicating the unit information of the search target information from the search device, the unit information of the search target information indicated by the request is read at a predetermined data transfer rate. Stored in a storage device to be returned to the search device,
With respect to a cache including a plurality of target storage capacities corresponding to the plurality of search target information, each of the plurality of target storage capacities includes at least a part of unit information included in the plurality of search target information. A cache step that caches an amount corresponding to the size of each of the target storage capacities, and outputs the cached unit information at a data transfer rate faster than the data transfer rate of the storage device in response to an external request; ,
A capacity control step of controlling the size of each of the plurality of target storage capacities included in the cache unit based on the characteristics of the search for each of the plurality of search target information;
When the unit information corresponding to the search request received from the outside is cached in the cache unit, the unit information is requested and read from the cache unit. Otherwise, the unit information is stored in the storage device. A search method for causing the computer to execute a search step that requests, reads, and returns to a search request source. A program that includes a computer and that is configured by combining a plurality of unit information, and that is executed by a search device that performs a search for a plurality of search target information to be searched, all of the search target information Has a predetermined storage capacity, and in response to a request indicating the unit information of the search target information from the search device, reads the unit information of the search target information indicated by the request at a predetermined data transfer rate. , Stored in a storage device returned to the search device,
With respect to a cache including a plurality of target storage capacities corresponding to the plurality of search target information, each of the plurality of target storage capacities includes at least a part of unit information included in the plurality of search target information. A cache step that caches an amount corresponding to the size of each of the target storage capacities, and outputs the cached unit information at a data transfer rate faster than the data transfer rate of the storage device in response to an external request; ,
A capacity control step of controlling the size of each of the plurality of target storage capacities included in the cache unit based on the characteristics of the search for each of the plurality of search target information;
When the unit information corresponding to the search request received from the outside is cached in the cache unit, the unit information is requested and read from the cache unit. Otherwise, the unit information is stored in the storage device. A program that causes the computer to execute a search step that requests, reads, and returns to a search request source.

Images