JP2019219847A - Database management device, database management method, and program - Google Patents

Abstract

To provide a database management device capable of safely and smoothly progressing in the utilization of user data.SOLUTION: A database management device manages a database having a hierarchically logical structure including user data of a first hierarchy to be referred to by a plurality of reference main bodies, and user data of a second hierarchy to be referred to by reference main bodies being more limited than the first hierarchy. The database management device includes: a first hierarchical processing part for receiving a read request from a reference main body corresponding at least to the first hierarchy, reading the user data from the database and returning the user data to the reference main body; and a second hierarchical processing part for receiving a read request and a write request from a reference main body corresponding to the second hierarchy, reading the user data from the database, and returning the user data to the reference main body or updating the user data in the database.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a database management device, a database management method, and a program.

  Conventionally, technical information on a user database server that centrally manages user data used when providing a service via a network and reduces labor and cost of user management in each server that provides the service has been disclosed. (See Patent Document 1).

JP-A-2002-251573

  However, in the above-described conventional technique, since a large number of accompanying information is associated with the user data managed by the user database, the data amount of the user data itself increases, for example, the number of items constituting the data record increases. When the value of becomes large, the processing speed is remarkably reduced, and suitable control may not be performed. Further, in the above-described conventional technology, when another user tries to use the user data collected by a certain subject, no consideration is given to using the data within an appropriate range.

  SUMMARY An advantage of some aspects of the invention is to provide a database management device, a database management method, and a program that can safely and smoothly utilize user data. I do.

  One embodiment of the present invention provides a hierarchical system including first-tier user data referenced by a plurality of reference entities and second-tier user data referenced by a more limited reference entity than the first hierarchy. Is a database management device for managing a database having a logical structure, at least receiving a read request from a reference subject corresponding to the first hierarchy, reading user data from the database, and returning the user data to the reference subject. A second layer processing for receiving a read request and a write request from a reference entity corresponding to the second hierarchy, reading user data from the database and returning it to the reference entity, or updating user data in the database And a database management device.

  According to one embodiment of the present invention, utilization of user data can be promoted safely and smoothly.

The figure which shows typically the logical structure of the database which a database management apparatus manages. The figure explaining the relationship of single information, close information, and multi-use information. FIG. 2 is a diagram illustrating a configuration and a use environment of the database management apparatus 100 according to the first embodiment. The figure which shows typically the user data which the database management apparatus 100 manages. 5 is a flowchart showing an example of the flow of an access control process executed by the database management device 100. 9 is a flowchart illustrating an example of the flow of a process performed by an inspection unit. 5 is a flowchart illustrating an example of the flow of an analysis process performed by the database management apparatus 100. The figure which shows an example of the close information. FIG. 7 is a use case diagram showing a procedure in a hierarchical information design scene. 9 is a flowchart illustrating an example of the flow of a hierarchy definition process performed by the hierarchy definition unit. FIG. 9 is a schematic functional diagram of a database management device 100A according to a second embodiment. The flowchart which shows an example of the flow of a hierarchy generation process of 100 A of database management apparatuses. The figure which shows typically the user data which the database management apparatus 100A manages.

  Hereinafter, embodiments of a database management device, a database management method, and a program according to the present invention will be described with reference to the drawings.

  The database management device is realized by one or more processors. The database management device is configured to store first-level user data referenced by a plurality of reference entities (hereinafter, database users) and second-level user data referenced by database users that are more limited than the first level. Is a device that manages a database having a hierarchical logical structure including

  The database management device receives at least a read request from a database user corresponding to the first hierarchy, reads out user data from the database and returns it to a reference entity, and a reference corresponding to a second hierarchy. A second layer processing unit that receives a read request and a write request from a subject, reads user data from a database and returns it to a database user, or updates user data in the database.

  User data is various data related to a user. More specifically, the user data is data related to a user who receives a service via a network, and is various data known by a service provider. The user data includes, for example, information such as a user ID, name, age, gender, occupation, and address. The user data is not limited to the data input by the user, and may include data (for example, hobbies, tastes, etc.) estimated based on the behavior on the network. In that case, the user data is managed by the service provider. Therefore, a service provider is an example of a database user. In the following, it is assumed that the database user is a service provider.

  The service provider provides the user with services such as “shopping”, “auction”, “travel”, “game”, “map”, and “real estate” via a network, for example. The user enjoys these services via the terminal device.

  The database management device reads or updates (newly writes, overwrites, or deletes) user data within a range of authority given to the service provider, for example, in response to a request from the service provider. Further, the database management device transmits the data stored in the lower layer to the upper layer according to the definition information of the database.

  FIG. 1 is a diagram schematically illustrating a logical structure of a database managed by the database management device. User data managed by the database management device can be classified into, for example, single information, close information, and multi-use information. Single information is data specific to a single service. The single information is, for example, the purchase history tendency of the user in the service “shopping” and the user's successful bid history in the service “auction”. The single information is an example of “the lowest layer user data”.

  Note that the purchase history tendency of the user, which is user data corresponding to the single information, may include header information for specifying the purchase history (for example, information including a purchase number for centrally managing the purchase history), The body information corresponding to the detailed information of the purchase history (for example, information including the number specifying the purchased product or the number of purchased items) may not be included. The body information corresponding to the detailed information of the purchase history tendency is managed by, for example, an external data server (hereinafter, service server 500) that manages data of the service “shopping”. In addition, if the single information is an example of the “second hierarchical information”, the close information or the multi-use information is an example of the “first hierarchical information”. Also, if the close information is an example of “second hierarchical information”, the multi-use information is an example of “first hierarchical information”.

  Close information is data that is common to two or more services, or data that is defined by the database administrator as being considered to be common. The database administrator, for example, shares information A of the prefecture in which the user of one service resides and information B of the residence area (for example, “Metropolitan area”, “Kansai”) owned by another service. It is defined that it may be regarded as. The database administrator generates, for example, close information A + B that aggregates information A and information B.

  The multi-use information is data that can be further ranked higher in the close information. The multi-use information is, for example, a user ID commonly used in all services or a user name commonly used in many services.

  The close information is associated with one or more pieces of multi-use information. The single information is associated with one or more pieces of close information or one or more pieces of multi-use information.

  FIG. 2 is a diagram illustrating the relationship among single information, close information, and multi-use information. The multi-use information is information whose use frequency is higher and whose update frequency is lower than that of the close information. In addition, the close information is information whose use frequency is higher and whose update frequency is lower than that of the single information.

  Since the multi-use information is commonly referred to by a plurality of services, the format is fixedly defined. On the other hand, close information has a higher degree of freedom than multi-use information. When a format change is performed in the close information, the format change is applied after consultation by the administrator of the service provider and the database administrator of the related service. The single information has a higher degree of freedom than the close information, and the format can be arbitrarily determined by a manager on the service provider side.

  Since the multi-use information is information related to a plurality of services provided by the service provider, the multi-use information is information requiring a higher SLA (Service Level Agreement; service quality assurance) than the close information. Close information is information that requires a higher SLA than single information. The SLA is expressed by an average response time of a request to the database management device (for example, a response of a standard read request is returned within 5 seconds) or an allowable range of downtime, which is a time during which the database management device cannot be used. Is done. The permissible range may be set, for example, as “a maximum of about 4 minutes is allowed per month as a down time”, or as an equivalent “operation rate 99.99%”. You may.

  The database management device 100 realizes higher access efficiency by setting multi-use information and close information. The multi-use information and the close information realize, for example, an index function for user data. For example, when the database management apparatus receives a read request for one piece of close information set by the database administrator and a plurality of pieces of single information associated with the close information, the database management apparatus first searches for the close information, and then searches for the close information. The single information associated with the close information is searched, and the processing result of the obtained read request is returned to the service provider (hereinafter, may be referred to as a response) to realize smooth processing.

  Therefore, in the multi-use information, user data that requires higher responsiveness than the close information is set. Whether the information that is commonly referred to by multiple services is closed information or multi-use information is determined, for example, by counting the number of times the target information is inquired to the service provider for a certain period of time. Designed by the database administrator based on the results.

  It is desirable that the configuration of the close information and the multi-use information be periodically reviewed in accordance with the latest usage tendency of the service provider and the integration or abolition of the service provided by the service provider. In a conventional database system, a method of managing user data in a dedicated database for each service or cooperating with user data by an ETL (Extraction, Transformation and Load) system or the like has been adopted in some cases. . In the former case, since registration and updating of user data are performed for each service, it is expected that a great deal of cost will be required to ensure consistency by regular data cleansing and the like. In the latter case, the latest user data may not be confirmed in real time because the user data registered and updated in each system by periodic batch processing and the like are linked. Further, it is assumed that a large cost is required for development and operation of the ETL system.

  The database management device manages the above-described single information, close information, and multi-use information. In addition, the database management device enables the configuration of single information, close information, and multi-use information to be flexibly changed according to the settings of the database administrator.

  In the following description, generation of close information from single information, generation of multi-use information from single information, and generation of multi-use information from close information are referred to as “upper hierarchy”, and Returning to information, returning multi-use information to close information, and returning multi-use information to single information may be referred to as “lower layering”, and upper layering and lower layering may be referred to as “layer change”.

<First embodiment>
FIG. 3 is a diagram illustrating a configuration and a use environment of the database management device 100 according to the first embodiment. In the illustrated environment, the terminal device 10, the database management device 100, and the service server 500 are communicably connected to each other via a network NW. The network NW includes, for example, part or all of a WAN (Wide Area Network), a LAN (Local Area Network), the Internet, a provider device, a wireless base station, a dedicated line, and the like. In the example illustrated in FIG. 1, the number of the terminal devices 10 is N (N is an arbitrary natural number). In the example shown in FIG. 1, the number of service servers 500 is M (M is an arbitrary natural number). In the present specification, when the terminal devices 10-1 to 10-N do not distinguish the individual terminal devices 10-1 to 10-N, for example, when describing common matters, the terminal devices 10-1 to 10-N are simply referred to as the terminal devices 10. Call. Further, in the present specification, when the service servers 500-1 to 500-M do not distinguish the individual service servers 500-1 to 500-M, for example, when describing common matters, the service servers 500-1 to 500-M are simply referred to as the service servers 500. Call.

  The terminal device 10 is a mobile phone such as a smartphone, a tablet terminal, a personal computer, or the like. The terminal device 10 transmits a request (command) relating to user data to the database management device 100 in response to an operation performed by the database user (again, referred to as such), and transmits a processing result of the returned request to the terminal device 10. Display on the display.

  The database management device 100 realizes the functions described below, for example, by publishing a standard API (Application Programming Interface) used for transmitting and receiving a request by the terminal device 10 to a database user. The database management device 100 includes, for example, the communication unit 102, the interpretation unit 104, the hierarchy definition information 108, the level 1 request processing unit 110, the level 2 request processing unit 112, the level 3 request processing unit 114, and the The processing unit 116 includes a processing status analysis unit 118, an access management unit 120, and an auditing unit 124. If the single information is an example of the “second hierarchical information”, the level 1 request processing unit 110 and the level 2 request processing unit 112 are an example of the “first hierarchical processing unit”, and the level 3 request processing unit 114 Is an example of a “second hierarchical processing unit”. If the close information is an example of the “second hierarchy information”, the level 1 request processing unit 110 is an example of the “first hierarchy processing unit”, and the level 2 request processing unit 112 and the level 3 request processing unit 114 Is an example of a “second hierarchical processing unit”.

  The communication unit 102 communicates with the terminal device 10 or the service server 500. The communication unit 102 receives the request from the terminal device 10 and outputs the request to the interpretation unit 104. In addition, the communication unit 102 transmits the processing result output by the interpretation unit 104 to the terminal device 10.

  The interpreting unit 104 interprets the request content obtained from the communication unit 102, and according to the result of the analysis of the request content, the hierarchy defining unit 106, the level 1 request processing unit 110, the level 2 request processing unit 112, the level 3 request processing unit An interpreted result (in the sense of an interpreted request, simply referred to as a request) is output to one of the 114, the inter-layer processing unit 116, the use state analyzing unit 118, the access managing unit 120, and the auditing unit 124.

  Further, the interpretation unit 104 includes a tier definition unit 106, a level 1 request processing unit 110, a level 2 request processing unit 112, a level 3 request processing unit 114, an inter-tier processing unit 116, a use status analysis unit 118, and an access management unit 120. The processing result output from one of the auditing units 124 is inversely converted into an expression corresponding to the transmission source of the request, and output to the communication unit 102. The inverse transformation means, for example, that information to be output to the communication unit 102 (for example, information indicating the processing result) is extracted from the processing result output to the interpretation unit 104 by the hierarchy definition unit 106, and the extracted content is communicated to the communication unit. The conversion into the data format to be transmitted to the terminal device 10 by 102.

  The tier definition unit 106 generates a tier definition of the user data in response to the tier definition request output by the interpretation unit 104. The hierarchy definition unit 106 causes the storage unit to store the hierarchy definition of the generated user data as hierarchy definition information 108.

  The tier definition unit 106 stores the tier definition information designed by the database administrator in the storage unit as the tier definition information 108, for example. The hierarchy definition of the user data is, for example, a definition of a tree structure including the close information and the single information. The hierarchy definition information 108 is referred to, for example, when the inter-layer processing unit 116 described later performs a hierarchy design reflection process for a plurality of hierarchies. Further, the hierarchy definition information 108 may be referred to by the level 2 request processing unit 112 and the level 3 request processing unit 114.

  The level 1 request processing unit 110 performs a process related to the multi-use information according to the request acquired from the interpretation unit 104. Specifically, the level 1 request processing unit 110 performs a process of receiving a read request for multi-use information, and the like.

  The level 1 request processing section 110 generates a query (or command) for inquiring the user database 200 based on the read request for the multi-use information acquired from the interpretation section 104. The level 1 request processing unit 110 transmits the generated query to a reading circuit (not shown) of the user database 200 (hereinafter, simply referred to as “transmit to the user database 200”). The level 1 request processing unit 110 receives the processing result of the user database 200 and outputs it to the interpreting unit 104.

  The level 2 request processing unit 112 processes the user data related to the close information according to the request acquired from the interpretation unit 104. Specifically, it is a process of accepting a read request for close information.

  The close information may refer to multi-use information due to its characteristics. Each of the multi-use information, the close information, and the single information may have data stored so as to be completed in the own hierarchy, but the data stored in the multi-use information and the data stored in the close information Alternatively, all the user data of a certain user may be grasped by having the data stored in the single information together (see FIG. 4 described later). In that case, when reading the close information, it is necessary to read out and combine both the multi-use information and the close information of the corresponding user and return a response. In this case, there is a possibility of referring to the multi-use information.

  Therefore, the level 2 request processing unit 112 refers to the hierarchy definition information 108 as necessary, and transmits a query requesting to read out both the multi-use information and the close information to the user database 200. The level 2 request processing unit 112 receives the processing result of the user database 200 and outputs it to the interpreting unit 104. When the user data is completed in each layer, the 112 transmits a query requesting to read the close information to the user database 200.

  The level 3 request processing unit 114 performs a process of accepting a read request or a write request for single information in accordance with the interpreted request acquired from the interpreting unit 104.

  The single information may refer to the multi-use information and the close information due to its characteristics. Therefore, the level 3 request processing unit 114 transmits a query generated by referring to the definition of the multi-use information and the close information in the hierarchy definition information 108 as necessary, to the user database 200. The level 3 request processing unit 114 receives the processing result of the user database 200 and outputs it to the interpreting unit 104.

  When the interpreted request acquired from the interpreting unit 104 is a read request for single information, the level 3 request processing unit 114 accepts the read request for single information and generates a query for inquiring the user database 200 in response to the request. I do. Further, when the request output by the communication unit 102 is a write request for single information, the level 3 request processing unit 114 accepts the write request for single information, and issues a query for updating the user database 200 in response to the request. Generate. The level 3 request processing unit 114 transmits the generated query to the user database 200. The level 3 request processing unit 114 receives the processing result of the user database 200 and outputs it to the interpreting unit 104.

  The inter-layer processing unit 116 refers to the layer definition information 108 and performs a process of propagating the data of the lower layer of the user data to the upper layer. The inter-layer processing unit 116 performs, for example, batch processing not once in real time but at a frequency of once a day.

  (1) Batch processing in a case where all the user data of a certain user is grasped by aligning the data stored in the multi-use information, the data stored in the close information, and the data stored in the single information

  As a specific procedure, first, the inter-layer processing unit 116 reads out data that has not been subjected to the batch processing from among the data that is the source of the single information in the user database 200, and expands the data in the memory of the database management device 100.

  Next, the inter-layer processing unit 116 performs a process of extracting data to be propagated to the upper layer from the data expanded in the memory and writing the data to the upper layer of the user database 200.

  Next, the inter-layer processing unit 116 instructs the 200 to delete the data written in the upper layer. The inter-layer processing unit 116 confirms the end of the data deletion, and ends the batch processing.

  (2) Batch processing when multi-use information, close information, and single information are completed in their own hierarchy

  In this case, for example, the inter-layer processing unit 116 reads out all the single information of the user database 200 and expands the single information in the memory of the database management device 100.

  Next, the inter-layer processing unit 116 performs a process of extracting data to be propagated to the upper layer from the data expanded in the memory and overwriting the data in the upper layer of the user database 200. The inter-layer processing unit 116 confirms the end of the overwriting processing, and ends the batch processing.

  When performing the above-described batch processing (1) or (2), the inter-layer processing unit 116 calls the level 1 request processing unit 110, the level 2 request processing unit 112, and the level 3 request processing unit 114 as appropriate. A function may be used.

  The usage status analysis unit 118 analyzes the usage status of the database user for each hierarchical structure based on the request acquired from the interpretation unit 104. Details of the analysis processing will be described later. The use state analysis unit 118 transmits a processing result to the terminal device 10 via the interpretation unit 104 and the communication unit 102.

  The access management unit 120 performs an access control process based on the request acquired from the interpretation unit 104. The access control processing will be described later. The access management unit 120 outputs the processing result to the interpretation unit 104.

  The auditing unit 124 performs an auditing process based on the request acquired from the interpreting unit 104. The audit processing will be described later. The inspection unit 124 outputs the processing result to the interpretation unit 104.

[User data]
FIG. 4 is a diagram schematically showing user data managed by the database management device 100. The multi-use information is information that is common to many services or all services, such as “user ID”. On the other hand, the close information is information that is common to a plurality of services, such as “user name”, but is not referred to in some services. The single information is information that is useful in a single service but not useful in other services, such as “reservation tendency”.

[Access control processing]
The database management device 100 has an access control function. The access control function is to permit or disallow a read request or a write request for user data based on the authority assigned to a database user who uses the database management apparatus 100 from the outside. It should be noted that the database user can basically perform only a read request for multi-use information and close information, and cannot execute a write request. For the multi-use information and the close information, for example, only a write request by a predetermined operation (for example, rewriting the definition of the hierarchy definition information 108) by the database administrator is permitted.

  For the database user, whether or not a single information write request or read request can be executed (write authority, read authority) is set by the database administrator.

  A service provider providing a certain service is given a read right and a write right for single information corresponding to the service. In addition, a service provider that provides a certain service is given a read right to the close information corresponding to another service if the same type of close information corresponds to the close information corresponding to the own service.

  For example, a service provider providing the service “shopping” is granted read authority for “user name” and “living area”, which are close information corresponding to the service “shopping”, regardless of the service of the data source. Is done. However, read authority is not given to “news preference”, which is close information that does not correspond to the service “shopping”.

  Hereinafter, the access control processing by the access management unit 120 will be described. For example, the data administrator sets in advance an access right such that a database user engaged only in the service “shopping” is not allowed to refer to user data related to the section “news” and the section “advertisement”, and stores the access right information 122 as a storage section. To be stored.

  The interpreting unit 104 interprets the interpreted request in each processing unit (the hierarchy definition unit 106, the level 1 request processing unit 110, the level 2 request processing unit 112, the level 3 request processing unit 114, the inter-tier processing unit 116, the use status analysis unit 118). ), The information of the database user who transmitted the request is output to the access management unit 120. The access management unit 120 acquires the database user information included in the request acquired from the interpretation unit 104 and searches the access authority information 122 to obtain the hierarchy definition information 108 based on the access authority of the database user. It is determined whether a read request or a write request to the user data stored by the user may be accepted.

  The access management unit 120 outputs the determination result to the interpretation unit 104. The interpretation unit 104 determines whether to output a request to each processing unit based on the determination result output by the interpretation unit 104. If the access management unit 120 does not determine that the request for the user data of the database user may be accepted, the access management unit 120 generates predetermined error information and returns the error information to the terminal device 10 via the communication unit 102. .

  FIG. 5 is a flowchart illustrating an example of the flow of an access control process performed by the database management device 100. First, the access management unit 120 acquires a request from the terminal device 10 used by the database user via the communication unit 102 and the interpretation unit 104 (S100). Next, the access management unit 120 determines whether or not the database user has the right to execute the request for the target user data (S102). When the access management unit 120 determines that the database user has the authority to execute the request for the target user data, the access management unit 120 determines whether the request is a user data read request or a user data write request (S104). When determining that the request is a read request, the access management unit 120 causes the interpreting unit 104 and the communication unit 102 to transmit the read request to the user database 200 and return the obtained response to the terminal device 10 (S106). When determining that the request is a write request, the access management unit 120 causes the interpreting unit 104 and the communication unit 102 to return a response to the write request from the user database 200 to the terminal device 10 (S108).

  In S102, if the access management unit 120 determines that the database user does not have the request authority for the target user data, the access management unit 120 generates error information and causes the interpreting unit 104 and the communication unit 102 to return to the terminal device 10 (S110). ). As described above, the processing of this flowchart ends.

[Audit processing]
It is desirable that the above-described access control processing be audited at predetermined intervals to determine whether the function is sufficiently functioning, whether the setting of the access authority is appropriate, and the like. Therefore, the audit unit 124 generates audit information for auditing the usage status of the database user based on the audit request of the data administrator. The audit information is, for example, information such as the database user, the time stamp of the execution of the request processing, the request content, the request processing reception status (success or failure of the request processing), etc., based on the statistical information of the access control log. The audit information is generated, for example, in a predetermined file format. The file generated as the audit information may be transmitted to the terminal device 10 used by the data manager via the interpretation unit 104 and the communication unit 102, or may be generated in a predetermined file storage location.

  Also, the audit processing may accept designation of conditions of predetermined categories, services, user data hierarchies, and database users. Further, the auditing process may be performed not only at a predetermined interval but also temporarily.

  FIG. 6 is a flowchart illustrating an example of the flow of a process performed by the inspection unit 124. First, the audit unit 124 acquires an audit request from the terminal device 10 used by the data manager via the communication unit 102 and the interpretation unit 104 (S200). Next, the auditing unit 124 extracts the access control log based on the audit request (S202), and generates and outputs a file including the extraction result (S204). As described above, the processing of this flowchart ends.

[Analysis processing]
Returning to FIG. 4, a description will be given of a hierarchical structure analysis process performed by the usage status analysis unit 118.

  The database user periodically reviews whether or not the hierarchical structure of the user data is appropriate in accordance with the latest usage tendency of the user database 200 and the integration of services provided by the service provider as the database user. The database administrator reviews the definition of the hierarchical structure based on the result of the analysis processing by the usage status analysis unit 118.

  Hereinafter, the processing content of the database management device 100 when the request for the analysis process is transmitted by the terminal device 10 used by the database administrator will be described. The interpreting unit 104 outputs the analysis request from the terminal device 10 used by the database administrator output by the communication unit 102 to the usage status analyzing unit 118. The analysis request may be a request for analyzing all of the user data or a request for analyzing a part of the user data. The usage status analysis unit 118 analyzes the user data based on the analysis request, and outputs an analysis result (recommended setting of close information and multi-use information) to the communication unit 102 via the interpretation unit 104. The communication unit 102 transmits the analysis result to the terminal device 10 used by the database administrator. The analysis result includes, for example, an extraction result of a single information candidate that can be converted into close information, a matching rate thereof, and information on whether or not a conversion table is required when converting the single information into close information. The conversion table will be described later.

  The analysis result of the usage status analysis unit 118 may be provided to the database administrator in a format (for example, outputting a file according to a common format definition) that is easy to refer to when designing a hierarchy described later.

  FIG. 7 is a flowchart illustrating an example of the flow of the analysis process of the database management device 100. First, the usage status analysis unit 118 acquires an analysis request from the terminal device 10 used by the database administrator via the communication unit 102 (S300). Next, the usage status analysis unit 118 extracts a candidate for a tier change (S302). Next, the usage status analysis unit 118 calculates a matching rate when a candidate for a tier change is applied (S304). Next, the usage status analysis unit 118 derives the necessity of the conversion table when the candidate for the tier change is applied (S306). Next, the usage status analysis unit 118 analyzes the user data and outputs an analysis result (S308). As described above, the processing of this flowchart ends.

  The analysis process by the usage status analysis unit 118 may be a batch process executed in response to an analysis request of the database administrator, or a resident process of collecting information for a certain period based on the analysis request of the database administrator. It may be.

  FIG. 8 is a diagram illustrating an example of the close information. When the analysis process is a resident process, for example, as shown in FIG. 8, the usage status analysis unit 118 determines whether or not the close information and the single information of the user database 200 can be hierarchized. It is determined whether or not a conversion table needs to be set, and the determination result is held as an “upper hierarchy flag” and “conversion table required”.

[Hierarchy design scene]
Hereinafter, as an example of a case where the analysis processing and the hierarchy generation processing of the database management apparatus 100 are applied, a case where a database administrator designs hierarchy information (a situation where definition information is constructed) will be described. The data manager may perform the user data hierarchy design based on the analysis result of the usage status analysis unit 118, or may perform the user data hierarchy design based on the definition information of the service server 500 or the like. In the following, a description will be given of the processing content when performing user data hierarchical design based on the analysis result of the usage status analysis unit 118.

  FIG. 9 is a use case diagram showing a procedure of a hierarchical information design scene. The database administrator obtains the result of the analysis processing of the usage status analysis unit 118 (S400). The database administrator generates design information of the hierarchy definition based on the analysis processing result and inputs the design information to the database management device 100 (S402). The design information of the hierarchy definition includes the design contents of “tier change design” and “conversion table design”. The hierarchy change design is, for example, generating close information from one or more pieces of single information or distributing the close information into one or more pieces of single information.

  When the conversion table design generates close information A + B that aggregates data A and B defined by the database administrator as being considered to be common to two or more services, the data A or B is derived from each service as the derivation source. The purpose is to generate a conversion table used when referring to the close information so that the data B can be referred to and the close information A + B functions.

  The database administrator inputs the hierarchy definition design information to the database management device 100 and reflects it in the user database 200 (S404). The above-mentioned design contents by the database administrator are reflected on the user database 200 by the database management apparatus 100 at the time of night batch or regular maintenance, for example.

  The database administrator may design the hierarchy information by himself / herself based on the design information of the service server 500. However, the database administrator must verify the design content by referring to the conformity of the analysis result by the usage analysis unit 118. Is desirable.

[Hierarchy design reflection processing]
The hierarchical design reflection process performed by the data manager will be described. FIG. 10 is a flowchart illustrating an example of the flow of a hierarchy definition process performed by the hierarchy definition unit 106. First, the hierarchy definition unit 106 acquires a hierarchy definition generation request via the communication unit 102 (S500). Next, the hierarchy definition unit 106 or the level 1 request processing unit 110 generates definition information of the multi-use information (S502). Next, the hierarchy definition unit 106 or the level 2 request processing unit 112 generates definition information of the close information (S504). Next, the hierarchy definition unit 106 or the level 3 request processing unit 114 generates definition information of single information (S506). Next, the interpretation unit 104 outputs each definition information to the hierarchy definition information 108 and stores it (S508). As described above, the processing of this flowchart ends.

  According to the first embodiment described above, the multi-use information referred to by a plurality of database users, the close information referred to by a more limited database user compared to the multi-use information, and the close information Manages a user database 200 having a hierarchical logical structure including single information referred to by a relatively more limited database user, accepts a read request from a database user corresponding to multi-use information, A level 1 request processing unit 110 that reads the corresponding user data from the database 200 and returns it to the database user; and receives a read request from the database user corresponding to the close information and reads the corresponding user data from the user database 200. Day A level 2 request processing unit 112 to be returned to the base user, a read request and a write request from the database user corresponding to the single information are received, and the user data corresponding to the read request is read from the user database 200 to the database user. By providing the level 3 request processing unit 114 for returning or updating the user data in the user database 200 in response to the write request, utilization of the user data can be safely and smoothly performed.

<Second embodiment>
FIG. 11 is a schematic functional diagram of the database management device 100A according to the second embodiment. The database management device 100A includes a hierarchy definition unit 106A instead of the hierarchy definition unit 106, hierarchy definition information 108A instead of the hierarchy definition information 108, and an access management unit 120A instead of the access management unit 120. The following mainly describes the hierarchy definition unit 106A, the hierarchy definition information 108A, and the access management unit 120A.

  The hierarchy definition unit 106A according to the second embodiment assigns category information to the hierarchy definition information 108A based on the user data obtained from the service server 500 and the category information related to the user data. The category information in the close information is, for example, a category such as “commerce” and “news”.

  FIG. 13 is a diagram schematically illustrating user data managed by the database management device 100A. The user data shown in FIG. 13 can be identified by a “division” including one or more services as compared with the user data shown in FIG. “Commerce”, “news”, and “advertisement” shown in the upper part of FIG. 13 indicate categories of services provided by a service provider who is a database user. The service classification is, for example, to collectively distinguish similar services. For example, the category “Commerce” includes the services “Travel reservation”, “Shopping” and “Auction”.

  The close information may be information common to a plurality of sections or information common to a plurality of types belonging to the same section. The close information may be configured by all types belonging to the section, or may be configured by some types belonging to the section. The close information is, for example, “user name” which is information common in the section “Commerce”, information common in the section “commerce”, part of the service “news”, and service “advertisement”. It is a certain "living area". By setting the category information by the hierarchy definition unit 106A, the database user can refer to the close information more efficiently or refer to or write the single information related to the close information more efficiently. It becomes possible.

  In the first embodiment, the close information is provided with the read authority regardless of the service of the data source. However, in the second embodiment, the access management unit 120A is, for example, the same as the close information related to the service. Even in the case of the close information, access to the close information of the service having a different division is prevented. This eliminates the need to search for unnecessary data, and makes it easier for the service provider who is the database user to smoothly acquire only the user data relating to the provided service.

  FIG. 12 is a flowchart illustrating an example of the flow of a hierarchy generation process of the database management device 100A. The process of S600 is the same as the process of S500 in the flowchart of FIG. Further, the processing of S602 is the same as the processing of S502 in the flowchart of FIG. Further, the processing of S606 is the same as the processing of S506 in the flowchart of FIG. Therefore, S604 will be described below.

  After the processing of S602, the level 2 request processing unit 112 and the hierarchy definition unit 106A generate close information reflecting the category information (S604). As described above, the processing of this flowchart ends.

  As described above, the database management device 100A according to the second embodiment has the same effects as the first embodiment, and further performs identification by adding category information to the close information by the hierarchy definition unit 106A. An easy hierarchical structure can be formed, and utilization and safety of user data can be improved in security and smoothness.

  As described above, the embodiments for carrying out the present invention have been described using the embodiments. However, the present invention is not limited to such embodiments at all, and various modifications and substitutions may be made without departing from the gist of the present invention. Can be added.

10 terminal devices,
100, 100A database management device,
102 communication unit,
104 interpreter,
106, 106A hierarchy definition part,
108, 108A hierarchy definition information,
110 Level 1 request processing unit,
112 Level 2 request processing unit,
114 Level 3 request processing unit,
118 usage status analysis section,
120, 120A access management unit,
122 access authority information,
124 Audit Department,
200 user database,
500 service server

Claims (8)

A database having a hierarchical logical structure including first-tier user data referenced by a plurality of reference entities and second-tier user data referenced by a more limited reference entity than the first hierarchy. A database management device for managing,
at least,
A first layer processing unit that receives a read request from a reference subject corresponding to the first layer, reads user data from the database, and returns the user data to the reference subject;
A second-layer processing unit that receives a read request and a write request from the reference subject corresponding to the second hierarchy, reads user data from the database and returns it to the reference subject, or updates user data in the database;
A database management device comprising: The reference subject is a service provider that provides a service via a network, and the user data stored in the lowest layer of the hierarchical logical structure is data of a user managed by the service provider of the writing source. is there,
The database management device according to claim 1. At least further comprising an inter-layer processing unit for extracting user data that can be the first-layer user data from the second-layer user data, and aggregating the extracted user data as the first-layer user data.
The database management device according to claim 1. A hierarchy definition unit that defines the hierarchical logical structure including the first hierarchy user data and the second hierarchy user data;
The database management device according to claim 1. The information processing apparatus further includes an auditing unit that stores a reception status of a request for the first-layer user data or the second-layer user data by the reference subject, and audits a use status by the reference subject.
The database management device according to claim 1. The hierarchy definition unit includes:
Assigning the category information to the first-tier user data based on category information for classifying services provided via a network;
The database management device according to claim 4. On the computer,
A database having a hierarchical logical structure including first-tier user data referenced by a plurality of reference entities and second-tier user data referenced by a more limited reference entity than the first hierarchy. Database management method to manage,
at least,
Accepting a read request from a reference subject corresponding to the first hierarchy, reading user data from the database and returning it to the reference subject,
Receiving a read request and a write request from the reference subject corresponding to the second hierarchy, reading user data from the database and returning it to the reference subject, or updating user data in the database;
Database management method. On the computer,
A database having a hierarchical logical structure including first-tier user data referenced by a plurality of reference entities and second-tier user data referenced by a more limited reference entity than the first hierarchy. A program to be managed,
at least,
Receiving a read request from a reference subject corresponding to the first hierarchy, reading user data from the database, and returning the user data to the reference subject,
Accepting a read request and a write request from the reference subject corresponding to the second hierarchy, reading user data from the database and returning it to the reference subject, or updating user data in the database;
program.

Images