JP2009146350A - Service management device, data access controller, and data retrieval method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To raise processing efficiency when a certain tenant executes drill through from data tabulation results of the whole system to individual data about each tenant when each tenant has a DB and a DWH individually in a multi-tenant SaaS system. <P>SOLUTION: A service management device 117 tabulates detail data collected from a plurality of SaaS servers 101 for store to generate the whole tabulation result 115, and generates an ACL subset 116 indicating an SaaS server 101 for store for accumulating the detail data in which permission of access is indicated from a request source of the whole tabulation result 115 by a common ACL 126 among the detail data. The SaaS server 101 for store at the request source of the whole tabulation result 115 executes the drill through from a part of the whole tabulation result 115 to the detail data accumulated in the SaaS server 101 for store indicated by the ACL subset 116. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a service management device, a data access control device, a data search system, and a data search method.

  As an alternative to the conventional package S / W (software), SaaS (Software as a Service) that provides all functions via the Internet with a Web browser-based UI (user interface) has attracted attention. In a multi-tenant SaaS system (a multi-tenant refers to a state where multiple services coexist in the same system, and a tenant refers to an individual service), each tenant individually has a DB (database) or DWH (dataware May have a house).

In a bulletin board system, which is a type of DB, for each user and at least one level of hierarchy group to which the user belongs, access rights to the database and at least one level of the database group to which the database belongs are set to access the database. In response to a request, there is one that checks access right based on the hierarchical structure of the user who is the request source, the hierarchical structure of the database to be accessed, and the setting contents of the access right (for example, Patent Document 1). reference).
JP-A-7-64844

  As an example of multi-tenant SaaS (Software as a Service) system where each tenant individually has a DB (database) and DWH (data warehouse), a franchise chain (FC) consisting of multiple stores Consider using SaaS in In general, in FC, since the business content differs for each store, a separate SaaS contract is made for each store. On the other hand, FC parent companies and regional FC store management supervisors access SaaS at multiple stores to search and aggregate sales information across tenants in order to grasp the business details of the stores under their control. There is a request to do. At this time, in the business intelligence (BI) world where data analysis is utilized for management, individual detail data is searched from the aggregate data reference screen in order to pursue the cause of the phenomenon found from the aggregate results of the entire FC across tenants. It is common to provide a drill-through function to be referred to (individual item data search function). While each store has a request to refer to the aggregated results such as the sales of the entire FC, when other stores drill through the aggregated results of the entire FC, the details that are the detailed information of their stores are in the same management district There is a need not to be referred to other stores that do not belong.

  However, in SaaS having a DB or DWH for each tenant, it is necessary to set access control information for each DB or DWH, and management is complicated. FIG. 1 shows the configuration of the SaaS system 991 in this case. In FIG. 1, ACL (access control list) corresponds to access control information. ACL1, ACL2, and ACL3 show how the SaaS server for store 1, the SaaS server for store 2, and the SaaS server for store 3 manage the ACL individually.

  On the other hand, master information necessary for data search / aggregation across tenants and hierarchical structure information between elements of the master information can be shared in the FC. At this time, access right information can be set for each element and each layer. FIG. 2 shows the configuration of the SaaS system 992 in this case. In FIG. 2, the common ACL corresponds to a combination of master information, hierarchical structure information between elements of the master information, and access right information for the master information. Stores A1, A2, A3,... Belonging to the same FC have contracted SaaS provided by the SaaS system 992. This SaaS system 992 prepares SaaS servers corresponding to the stores A1, A2, A3,... And provides services (the SaaS servers only need to be logically separated and are physically the same). It may be realized by logically dividing the server by a virtual machine (VM) or the like). The DB that manages the information of each store is generally realized physically or logically for each SaaS server. The SaaS system 992 monitors and manages the SaaS server corresponding to each user using the SaaS monitoring management server.

  In this way, with the configuration using the common ACL, in order to drill through the cross-sectional results of the entire FC, it is necessary to manage access control information for each store DB and DWH individually for each SaaS server. Thus, the access control information in the FC can be aggregated in the common ACL, and management can be simplified. In the SaaS system 992, the user or manager of each store requests aggregation of the sales of the entire FC from the terminal to the SaaS monitoring and management server having the right to access the DB on the SaaS server of each store. To do. After making an inquiry to the SaaS server of each store, the SaaS monitoring management server receives the total result of each store and executes total tabulation. Then, the SaaS monitoring management server sends the aggregation result of the entire FC to the SaaS server for each store of the total aggregation request source, and the user of each store refers to the aggregation result of the entire FC on the SaaS server for each store.

  In the BI, when drilling through to the DB of a plurality of stores based on the aggregated results of the entire FC, there is a desire to return the results from each store to the drill-through request source as soon as they are acquired with emphasis on real-time performance. However, in the SaaS system 992, there is a problem that the results are collected in the SaaS monitoring management server, and the real-time performance is deteriorated. For example, in FIG. 2, if the store A1 issues a drill-through request based on the total result of the FC, the store A1 issues a drill-through request to the SaaS monitoring management server that stores the common ACL. . Here, in order to improve the real time property of drill-through, the search result for the DB on each store SaaS server is directly returned to the drill-through request source (store A1), but the search request for each store SaaS server is Since it is issued from the SaaS monitoring management server, a response is also returned to the SaaS monitoring management server, and the SaaS monitoring management server collectively returns the results of all stores to the drill-through request source.

On the other hand, the store A1 issues a drill-through request to each store SaaS server, and the common ACL is confirmed by the store SaaS server that has received the drill-through request. As soon as the through result is acquired, it can be displayed on the drill-through request source (store A1). At this time, a result receiving thread is generated in the SaaS server that is the source of the drill-through request, and the result can be asynchronously received and displayed from each store SaaS server. FIG. 3 shows an outline of processing in this case. The processing flow of FIG. 3 is as follows.
(1) The drill-through request source (store A1) requests drill-through from each store.
(2) Each store refers to the common ACL on the SaaS monitoring management server, and confirms whether or not the drill-through request source (store A1) may be permitted to access its own DB.
(3) The SaaS monitoring management server notifies each store whether or not the drill-through request source (store A1) can access the DB of each store.
(4) The store that can be accessed in (3) sends the drill-through result to the drill-through request source (store A1).

  In FIG. 3, since the drill-through request source (store A1) does not have a common ACL, the drill-through request is made to the SaaS servers of all stores, and there is a problem that unnecessary communication traffic occurs. If a duplicate of the common ACL is arranged at the drill-through request source in order to cope with this problem, a problem of management cost of the common ACL occurs.

  In the SaaS system as described above, there may be cases where it is necessary to limit drill-through according to usage conditions, such as whether there is a charge delinquency for the service contract of the drill-through request source or whether usage time / data amount limit is exceeded. is there.

  In the present invention, for example, in a multi-tenant SaaS system, when each tenant individually has a DB or DWH, a certain tenant performs a drill-through from the data aggregation result of the entire system to individual data of each tenant. The purpose is to improve the processing efficiency. Specifically, the present invention enables a tenant executing drill-through to receive the result of drill-through from another tenant through asynchronous communication, while transmitting the result of drill-through to another tenant that does not have access rights. The purpose is to prevent unnecessary inquiries. It is another object of the present invention to place a restriction according to the usage status of a service contract when a tenant executing drill-through requests a drill-through result from another tenant.

A service management apparatus according to one aspect of the present invention includes:
From one of a plurality of servers that store a plurality of types of detailed data (hereinafter referred to as “first server”), a totaling request specifying a type of detailed data to be totaled is received via the network, A totalization execution unit that collects detailed data of the type stored in each server from the server via the network, and generates totalized data by counting the detailed data by a processing device;
A common ACL management database that stores, in a storage device, a common ACL (access control list) that indicates whether or not access to detailed data stored in other servers from each server is permitted;
Of the detailed data aggregated by the aggregation execution unit, a server that accumulates detailed data indicated to permit access from the first server in the common ACL stored in the common ACL management database (hereinafter referred to as “the first item”). An ACL subset generating unit for generating an ACL subset indicating a “two server”) by a processing device,
The aggregation execution unit transmits the generated aggregation data and the ACL subset generated by the drill-through ACL subset generation unit to the first server via a network, and the ACL subset is generated from a part of the aggregation data. The first server is caused to execute drill-through to detailed data stored in the indicated second server.

  According to one aspect of the present invention, the service management apparatus receives a totaling request specifying the type of detailed data to be totaled from the first server via the network, and is accumulated in each server from a plurality of servers. The detailed data of the type is collected via the network, and the detailed data is aggregated to generate aggregate data. Among the detailed data, the common ACL stored in the common ACL management database accesses the first server. And generating the ACL subset indicating the second server that stores the detailed data indicated to be permitted, and transmitting the generated aggregate data and the ACL subset to the first server, from a part of the aggregate data By causing the first server to drill through to the detailed data stored in the second server indicated by the ACL subset, For example, in a multi-tenant SaaS (Software as a Service) system, if each tenant has a DB (database) or DWH (data warehouse) individually, a certain tenant is Processing efficiency when executing drill-through to individual data of each tenant is improved.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

Embodiment 1 FIG.
FIG. 4 is a block diagram showing a configuration of the SaaS system 100 (data search system according to the present embodiment). As described above, SaaS is an abbreviation for Software as a Service.

  4, the SaaS system 100 includes a plurality of store SaaS servers 101 (a plurality of servers in the present embodiment), at least one SaaS monitoring management server 102, and a plurality of user terminals 127. These servers and terminals perform data communication with each other via the network 200.

  The store SaaS server 101 is a service server including a data access control device 103 having a store SaaS function. The data access control device 103 includes a working storage area 104, a service content DB 105 (database), a cross-tabulation requesting unit 106 (counting request unit in the present embodiment), and a cross-sectional tabulation response unit 107 (counting in the present embodiment). A response unit), a drill-through request unit 108, an ACL subset management unit 109 (ACL is an access control list as described above), and a drill-through response unit 110. The drill-through request unit 108 includes a condition extraction unit 111, an ACL subset interpretation unit 112, a result reception unit 113, and a result display unit 114. The operation of each part will be described later.

  Although not shown, the store SaaS server 101 includes hardware resources such as a storage device, a processing device, an input device, and an output device. The work storage area 104 of the data access control device 103 is mounted on a storage device (for example, a volatile memory) of the store SaaS server 101, and is used to store an overall count result 115 and an ACL subset 116, which will be described later. The service content DB 105 of the data access control device 103 is mounted on a storage device (for example, a hard disk) of the store SaaS server 101 and stores a plurality of types of detailed data. The detail data is data relating to an individual service provided by each store SaaS server 101. In the present embodiment, one type of detailed data is recorded for one table in the service content DB 105.

  The SaaS monitoring management server 102 is a service monitoring management server including a service management device 117 having a SaaS monitoring management function. The service management apparatus 117 includes a common ACL management DB 119 (database), a cross-sectional aggregation execution unit 120 (aggregation execution unit in the present embodiment), a common ACL management unit 121, and a drill-through ACL subset generation unit 122. The operation of each part will be described later.

  Although not shown, the SaaS monitoring management server 102 includes hardware resources such as a storage device, a processing device, an input device, and an output device. The common ACL management DB 119 of the service management apparatus 117 is mounted on a storage device (for example, a hard disk) of the SaaS monitoring management server 102 and stores the common ACL 126. The common ACL management DB 119 of the service management device 117 may store a plurality of types of common ACLs 126. The common ACL 126 is data indicating, for each store SaaS server 101, permission / refusal (common access control information) of detailed data stored in the service content DB 105 of each store SaaS server 101 from each store SaaS server 101. It is. In the present embodiment, it is assumed that a plurality of tables in the common ACL management DB 119 record one type of common ACL 126.

  In the SaaS system 100, the service management apparatus 117 included in the SaaS monitoring management server 102 is directed to the total count request source of the total count result 115 (the data access control apparatus 103 included in any one of the plurality of store SaaS servers 101). Of the common access control information defined in the common ACL 126, and the subset (the store SaaS server 101) of the elements in the common access control information that are narrowed down according to the aggregation condition (drill-through data is drilled) A list of store SaaS servers 101 that are permitted to be returned to the through request source is also sent. Thereby, the data access control device 103 of the total aggregation request source stores the subset of the common ACL 126 received together with the total aggregation result 115 (in the data access control device 103 of the total aggregation request source, it is stored as the ACL subset 116 in the work storage area 104. The number of store SaaS servers 101 (stores) to which a drill-through request is sent can be narrowed down. Since the data access control device 103 of the total aggregation request source (which is also the drill-through request source) does not have the common ACL 126, if the same method as the SaaS system 992 of FIG. 3 is used, the data access control device 103 of FIG. As such, drill-through requests had to be sent to all stores. On the other hand, in the SaaS system 100 according to the present embodiment, as described above, the data access control device 103 that is the total aggregation request source uses the ACL subset 116 that is partial information (subset) of the common ACL 126 to make a drill-through request. It is possible to narrow down the stores to send. By adopting such a configuration, it is possible to receive the drill-through result by the asynchronous communication as described above, and reduce the number of requests that the drill-through request source sends wastefully to a store that does not have the access right. be able to. Further, by adopting a configuration in which the minimum access control information is copied to the store SaaS server 101, the management cost can be reduced as compared with a configuration in which a copy of the common ACL 126 is arranged in each store SaaS server 101.

  FIG. 5 is a diagram illustrating an example of hardware resources of the store SaaS server 101 and the SaaS monitoring management server 102.

  In FIG. 5, the store SaaS server 101 and the SaaS monitoring management server 102 are both computers, a display device 901 having a CRT (Cathode / Ray / Tube) or LCD (Liquid Crystal Display) display screen, a keyboard 902 (K / B), hardware resources such as a mouse 903, an FDD904 (Flexible Disk Drive), a CDD905 (Compact Disk Drive), and a printer device 906, which are connected by cables and signal lines.

  The store SaaS server 101 and the SaaS monitoring management server 102 include a CPU 911 (Central Processing Unit) that executes a program. The CPU 911 is an example of a processing device. The CPU 911 includes a ROM 913 (Read / Only / Memory), a RAM 914 (Random / Access / Memory), a communication board 915, a display device 901, a keyboard 902, a mouse 903, an FDD904, a CDD905, a printer device 906, and a magnetic disk. It is connected to the device 920 and controls these hardware devices. Instead of the magnetic disk device 920, a storage medium such as an optical disk device or a memory card reader / writer may be used.

  The RAM 914 is an example of a volatile memory. The storage media of the ROM 913, the FDD 904, the CDD 905, and the magnetic disk device 920 are an example of a nonvolatile memory. These are examples of the storage device. A communication board 915, a keyboard 902, a mouse 903, an FDD 904, a CDD 905, and the like are examples of input devices. The communication board 915, the display device 901, the printer device 906, and the like are examples of output devices.

  The communication board 915 is connected to a LAN (local area network) or the like. The communication board 915 is not limited to a LAN, but is the Internet, or an IP-VPN (Internet, Protocol, Private, Network), a wide area LAN, a WAN (Wide Area Network) such as an ATM (Asynchronous, Transfer, Mode) network, or the like. It does not matter if it is connected to. LAN, the Internet, and WAN are examples of the network 200.

  The magnetic disk device 920 stores an operating system 921 (OS), a window system 922, a program group 923, and a file group 924. The programs in the program group 923 are executed by the CPU 911, the operating system 921, and the window system 922. The program group 923 stores a program for executing a function described as “˜unit” in the description of the present embodiment. The program is read and executed by the CPU 911. The file group 924 includes data and information described as “˜data”, “˜information”, “˜ID (identifier)”, “˜flag”, and “˜result” in the description of this embodiment. Signal values, variable values, and parameters are stored as items of “˜file”, “˜database”, and “˜table”. The “˜file”, “˜database”, and “˜table” are stored in a storage medium such as a disk or a memory. Data, information, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for processing (operation) of the CPU 911 such as calculation / control / output / printing / display. Data, information, signal values, variable values, and parameters are temporarily stored in the main memory, cache memory, and buffer memory during processing of the CPU 911 such as extraction, search, reference, comparison, calculation, control, output, printing, and display. Is remembered.

  In addition, the arrows in the block diagrams and flowcharts used in the description of this embodiment mainly indicate input / output of data and signals, and the data and signals are the memory such as the RAM 914, the flexible disk (FD) of the FDD 904, and the compact of the CDD 905. Recording is performed on a recording medium such as a disk (CD), a magnetic disk of the magnetic disk device 920, another optical disk, a mini disk (MD), or a DVD (Digital Versatile Disc). Data and signals are transmitted by a bus 912, a signal line, a cable, and other transmission media.

  In addition, what is described as “˜unit” in the description of this embodiment may be “˜circuit”, “˜device”, “˜device”, and “˜step”, “˜process”. , “˜procedure”, and “˜processing”. That is, what is described as “˜unit” may be realized by firmware stored in the ROM 913. Alternatively, it may be realized only by software, or only by hardware such as an element, a device, a board, and wiring, or a combination of software and hardware, and further by a combination of firmware. Firmware and software are stored as programs in a recording medium such as a magnetic disk, flexible disk, optical disk, compact disk, minidisk, or DVD. This program is read by the CPU 911 and executed by the CPU 911. That is, the program causes the computer to function as “to part” described in the description of the present embodiment. Alternatively, it causes the computer to execute the procedures and methods described in the description of the present embodiment.

  In the following, in order to make the description more specific, it is assumed that the store SaaS server 101 and the SaaS monitoring management server 102 are realized by the computer and hardware resources illustrated in FIG.

  FIG. 6 shows a processing sequence at the time of executing the cross tabulation in the present embodiment.

  In FIG. 6, one of the plurality of store SaaS servers 101 is a store SaaS server 101 (which becomes a drill-through request source based on the total count result 115 after execution of cross-sectional count). First server in this embodiment). Here, the store where the store SaaS server 101 is installed is called a request source store 128. A store in which one or more other SaaS servers 101 for stores are respectively installed is referred to as another store 129.

  (1) In the store SaaS server 101 of the request source store 128, the cross-tabulation requesting unit 106 of the data access control device 103 sends to the service management device 117 of the SaaS monitoring management server 102 the type of detailed data to be tabulated A totaling request (total totaling request) specifying (totaling target and totaling condition) is transmitted via the network 200. In the SaaS monitoring management server 102, the cross-sectional tabulation execution unit 120 of the service management device 117 receives a tabulation request from the store SaaS server 101 of the request source store 128 via the network 200. That is, the cross-sectional tabulation requesting unit 106 requests the cross-sectional tabulation execution unit 120 of the SaaS monitoring management server 102 to perform cross-tabulation (total tabulation).

  (2) In the SaaS monitoring management server 102, the cross-sectional tabulation execution unit 120 of the service management device 117 performs the data access control device 103 of the store SaaS server 101 of each store (request source store 128 and other store 129). A detail request for requesting detailed data of the type specified in the aggregation request in (1) is transmitted via the network 200. In the store SaaS server 101 of each store, the cross tabulation response unit 107 of the data access control device 103 receives a detail request from the SaaS monitoring management server 102 via the network 200. That is, the cross-tabulation execution unit 120 that has received the total tabulation request from the request source store 128 in (1) receives all stores including the request source store 128 (in FIG. The cross-counting total response unit 107 (showing another store 129 responding to the totaling request) is requested to execute totaling (may be the totaling result already possessed).

  (3) In the store SaaS server 101 of each store, the cross-sectional tabulation response unit 107 of the data access control device 103 acquires the detailed data of the type specified in the detailed request in (2) from the service content DB 105, and SaaS The data is transmitted to the service management apparatus 117 of the monitoring management server 102 via the network 200. In the SaaS monitoring management server 102, the cross tabulation execution unit 120 of the service management device 117 collects detailed data from the store SaaS server 101 of each store via the network 200. In other words, the cross-counting response unit 107 of the request source store 128 and the other store 129 returns a count result (detail data) in response to the detail request (2).

  (4) In the SaaS monitoring management server 102, the cross-sectional tabulation execution unit 120 of the service management device 117 tabulates the detailed data collected in (3) by the CPU 911 (processing device) and obtains the total tabulation result 115 (tabulation data). Generate. In other words, the cross tabulation execution unit 120 of the SaaS monitoring management server 102 generates the total tabulation result 115 from the result obtained in (3).

  (5) In the SaaS monitoring management server 102, the cross-counting execution unit 120 of the service management device 117 requests the ACL subset generation unit 122 to generate the ACL subset 116.

  (6) In the SaaS monitoring management server 102, the drill-through ACL subset generation unit 122 of the service management device 117 requests the common ACL management unit 121 for information on the common ACL 126 related to the overall count result 115 of (4). To do. Specifically, the common ACL 126 information related to the total count result 115 in (4) is the common data stored in the common ACL management DB 119 among the detailed data tabulated by the cross-sectional count execution unit 120 in (4). This is information indicating the store SaaS server 101 (second server in the present embodiment) that stores detailed data indicated by the ACL 126 to permit access from the store SaaS server 101 of the request source store 128.

  (7) In the SaaS monitoring management server 102, the common ACL management unit 121 of the service management device 117 returns information on the common ACL 126 related to the total count result 115 of (4) to the drill-through ACL subset generation unit 122. .

  (8) In the SaaS monitoring management server 102, the drill-through ACL subset generation unit 122 of the service management device 117 uses the information of (7) to store the detailed data collected by the cross-tabulation execution unit 120 in (4). Among them, the ACL subset 116 indicating the store SaaS server 101 that stores the detailed data indicated to permit the access from the store SaaS server 101 of the request source store 128 by the common ACL 126 stored in the common ACL management DB 119. It is generated by the CPU 911. That is, the drill-through ACL subset generation unit 122 of the SaaS monitoring management server 102 generates the ACL subset 116 based on the information of the common ACL 126 received in (7).

  (9) In the SaaS monitoring management server 102, the drill-through ACL subset generation unit 122 of the service management device 117 returns the ACL subset 116 generated in (8) to the cross-tabulation execution unit 120.

  (10) In the SaaS monitoring management server 102, the cross-counting execution unit 120 of the service management apparatus 117 merges the total counting result 115 of (4) and the ACL subset 116 received in (9).

  (11) In the SaaS monitoring management server 102, the cross-sectional tabulation execution unit 120 of the service management device 117 performs the total tabulation result 115 generated in (4) and (8) for the store SaaS server 101 of the request source store 128. The ACL subset 116 generated by the drill-through ACL subset generator 122 is transmitted via the network 200. In the store SaaS server 101 of the request source store 128, the cross tabulation request unit 106 of the data access control device 103 receives the total count result 115 and the ACL subset 116 from the SaaS monitoring management server 102 via the network 200. That is, the cross tabulation execution unit 120 of the SaaS monitoring management server 102 returns the data generated in (10) to the cross tabulation request unit 106 of the request source store 128.

  (12) In the store SaaS server 101 of the request source store 128, the cross tabulation requesting unit 106 of the data access control apparatus 103 extracts the ACL subset 116 from the data received in (11), and passes it to the ACL subset management unit 109. .

  (13) In the store SaaS server 101 of the request source store 128, the ACL subset management unit 109 of the data access control device 103 stores the ACL subset 116 of (12) in the work storage area 104, and the cross-tabulation request unit A response is returned to 106. Upon receiving this response, the cross tabulation request unit 106 may display the total tabulation result 115 on a unique screen by the display device 901 (output device), for example, “Microsoft Excel (registered trademark)”. The total tabulation result 115 may be displayed on the screen of the spreadsheet software by outputting the total tabulation result 115 to the spreadsheet software.

  Hereinafter, the structure of the common ACL 126 will be described.

  In the present embodiment, in the SaaS monitoring management server 102, the common ACL management DB 119 of the service management device 117 includes a plurality of groups (specifically, a store SaaS in a hierarchical structure) in which a plurality of store SaaS servers 101 are classified. The common ACL 126 indicating the group to which the store SaaS server 101 belongs among the elements in the hierarchy higher than the server 101 is stored for each store SaaS server 101. Then, the drill-through ACL subset generation unit 122 of the service management device 117 performs common ACL management among the SaaS servers 101 for stores in which the detailed data aggregated by the cross-sectional aggregation execution unit 120 in (4) of FIG. 6 is accumulated. The ACL subset 116 indicating the store SaaS server 101 indicated to belong to the same group as the store SaaS server 101 of the request source store 128 is generated by the common ACL 126 stored in the DB 119.

  An example of the logical structure of the common ACL 126 is shown in FIG. In FIG. 7, the common ACL 130 for tabulation by region / district is a common ACL 126 having three logical layers of regions / districts / stores. The common ACL 130 for tabulation by region / district indicates that, for example, the store A1 and the store A2 can access information on the Kanagawa district. Such a common ACL 126 can be realized by using, for example, a table of a normal relational DB. FIG. 8 shows an example in which the common ACL 130 for each region / district shown in FIG. 7 is realized by a relational DB. In FIG. 8, a local table 131, a district table 132, and a store table 133 are tables corresponding to the respective hierarchies of the regional / district total common ACL 130 shown in FIG.

  Details of the ACL subset 116 generation processing by the service management apparatus 117 of the SaaS monitoring management server 102 will be described below.

  In the SaaS monitoring management server 102, the drill-through ACL subset generation unit 122 of the service management device 117 is a service that can be a target of a drill-through request among a plurality of stores (store SaaS server 101) that are elements of the common ACL 126. Only information on stores that can be accessed by the requesting store SaaS server 101 with respect to the table in the content DB 105 is extracted as the ACL subset 116. Then, the transverse tabulation execution unit 120 of the service management device 117 attaches this ACL subset 116 to the total tabulation result 115. The information extracted as the ACL subset 116 is obtained by associating the hierarchy of the common ACL 126 (in the example of FIG. 7, the region / district / store) with the aggregation condition in the overall aggregation request, and the common ACL 126 appearing in the aggregation condition at the time of the overall aggregation execution. It is obtained by evaluating only an element in the hierarchy or an element in the hierarchy lower than the element. In the present embodiment, when a hierarchy is specified by the aggregation condition, the numerical value of the detailed data is aggregated for each element in the hierarchy, and the result becomes the overall aggregation result 115. If the hierarchy specified by the aggregation condition is a hierarchy having a store as an element, the requesting store can drill through from the total aggregation result 115 only on its own detailed data. If the hierarchy specified in the aggregation condition is higher than the hierarchy having the store as an element, the requesting store performs drill-through from the overall aggregation result 115 on the detailed data of the store belonging to the same element as the self and itself. Is possible.

  For example, in the example of FIG. 7, if “district” is specified as the totaling condition and the store A1 requests drill-through, the level specified in the totaling condition is higher than the level having the store as an element. Therefore, only the store belonging to “Kanagawa”, which is the district to which the store A1 belongs, can return the drill-through target data to the store A1 as the drill-through request source. Therefore, information of only the store A1 and the store A2 is extracted as the ACL subset 116. Further, for example, in the example of FIG. 7, when “Region” is specified in the aggregation condition, if the store A1 requests drill-through, the hierarchy specified in the aggregation condition is higher than the hierarchy having the store as an element. Therefore, only the stores belonging to “Kanto”, which is the region to which the store A1 belongs, can return the drill-through target data to the store A1 that is the drill-through request source. Therefore, information of only the store A1, the store A2, and the store A3 is extracted as the ACL subset 116. However, in this example, there is a difference in the range that can be drilled through when “region” is specified as the totaling condition and when “district” is specified as the totaling condition. In order to eliminate such a difference, for example, in the example of FIG. 7, when “Region” is specified as the aggregation condition, if the store A1 requests drill-through, among the districts belonging to “Kanto” Only stores belonging to “Kanagawa”, which is the district to which A1 belongs, may be able to return the drill-through target data to the store A1 that is the source of the drill-through request. In this case, as in the case where “district” is designated as the aggregation condition, information on only the store A1 and the store A2 is extracted as the ACL subset 116.

  Here, for example, the total aggregation request can be realized as an SQL (Structured / Query / Language) query, and at this time, the above-described aggregation condition can be realized as an SQL “GROUP BY” phrase. In this case, if the hierarchical name of the common ACL 126 can be used as the total condition for the total total request (the key of the “GROUP BY” clause), the total total result 115 for the request is determined based on the total condition for the total total request. As described above, a list of stores that can be accessed to the maximum extent by the drill-through request source (also the total aggregation request source) can be retrieved as the ACL subset 116.

  In addition, the association between the table in the service content DB 105 and the common ACL 126 is, for example, the association information between each type of the common ACL 126 and each table in the service content DB 105 is one of the tables in the common ACL 126 or the service content DB 105. This can be realized by managing as a department. Alternatively, information indicating the association between the table in the service content DB 105 and the common ACL 126 may be managed as in the analysis service master 124 illustrated in FIG. On the other hand, for example, it is possible to apply only the common ACL 126 corresponding to the aggregation condition specified by the total aggregation request source without associating a part or all of the table in the service content DB 105 with the common ACL 126. However, in this case, if a certain aggregation condition is specified, data that could not be searched by drill-through can be searched by drill-through if another aggregation condition is specified, which may be inconvenient for data access control. . For this reason, for example, the common ACL 126 that needs to be applied to a certain table as a minimum may be associated with the table, and the common ACL 126 for special data may be associated only with the aggregation condition.

  Further, when a plurality of common ACLs 126 are applied to a certain table, for example, only common elements included in each common ACL 126 applied to the table can be handled as accessible. Alternatively, for example, it is possible to give priority to the application of the common ACL 126 to the table and to apply only the common ACL 126 having a high priority. The following description is based on the premise of the former configuration.

  In the case where drill-through is requested simultaneously for a plurality of tables, the maximum range of stores that can access each table can be handled as the ACL subset 116. This is because the ACL subset 116 only needs to be able to transmit information within a range in which the drill-through request source can access the aggregation condition of the overall aggregation request to the maximum extent.

  FIG. 9 is a flowchart showing the operation of the drill-through ACL subset generation unit 122 of the service management apparatus 117.

  In FIG. 9, first, the drill-through ACL subset generation unit 122 is included in the request of the store of the total aggregation request source (hereinafter, the drill-through request source based on the total aggregation result). The table in the service content DB 105 is extracted (step S101). For example, this request can be realized as an SQL query, and the table to be aggregated can be realized by extracting a table specified by the “FROM” phrase from the query. Subsequently, the drill-through ACL subset generation unit 122 executes the processing from step S103 onward for all the tables extracted in step S101 (step S102).

  The drill-through ACL subset generation unit 122 determines whether there is a common ACL 126 to be applied to the target table in the processing after step S102 (step S103). When there is a common ACL 126 to be applied to the table to be processed in step S103, the drill-through ACL subset generation unit 122 executes the processes in steps S105 and S106 for the hierarchy and lower hierarchy of the common ACL 126. (Step S104). For example, if the common ACL 130 for aggregation by region / district shown in FIG. 7 is applied to the table to be processed, steps S105 and S106 are performed in the order of “region”, “district”, and “store”. The process is executed.

  The drill-through ACL subset generation unit 122 checks whether or not the aggregation condition specified by the total aggregation request source corresponds to the hierarchy of the common ACL 126 that is the processing target in Step S104 (Step S105). If there is something to do, the element of the lowest layer of the element of the hierarchy including the drill-through request source is added to the temporary list generated from the common ACL 126 (step S106). For example, the “district” of the common ACL 130 for tabulation by region / district shown in FIG. 7 is the processing target, “district” is specified in the tabulation condition, and the total tabulation request source is the store A1. For example, the store A1 and the store A2 which are the lowest layer elements of “Kanagawa” are added to the temporary list. Here, the aggregation condition designated by the overall aggregation request source can be realized, for example, as an SQL “GROUP BY” phrase, and the determination in step S105 is performed by the common ACL 126 whose key is the “GROUP BY” phrase. This can be realized by determining whether or not it matches the hierarchical name. The drill-through ACL subset generation unit 122 generates the ACL subset 116 by generating the temporary list described above for each table and for each common ACL 126 applied to the table, and merging in steps S107 and S108 described later.

  In step S105, the drill-through ACL subset generation unit 122 determines that the aggregation condition specified by the total aggregation request source does not correspond to the hierarchy of the common ACL 126 to be processed in step S104. Proceed to processing. If there is no common ACL 126 to be applied to the table to be processed in step S103, the drill-through ACL subset generation unit 122 proceeds to the processing of the next table included in the overall aggregation request in step S102.

  When the loop of steps S104 to S106 is completed, the drill-through ACL subset generation unit 122 generates, from the table, an element group common to the temporary list group generated from each common ACL 126 applied to the table to be processed. The temporary list is stored (step S107). For example, store A1 and store A2 are included in the temporary list generated from the common ACL 130 for aggregation by region / district shown in FIG. 7, and store A1, store A2, and store A3 are included in the temporary list generated from the other common ACL 126. If it is included, only the store A1 and the store A2 are stored in the temporary list generated from the table.

  When the loop from step S102 to S107 is completed, the drill-through ACL subset generation unit 122 sets the set of elements included in any of the temporary lists generated from the tables as the ACL subset 116 (step S108). . For example, if store A1 and store A2 are included in the temporary list generated from a certain table and store A2 and store A3 are included in the temporary list generated from another table in the example of FIG. Will include store A1, store A2, and store A3.

  Although FIG. 9 shows a flow of processing for generating a list of stores that can be accessed to the maximum extent by the drill-through request source store as a procedure for generating the ACL subset 116, a cache of the ACL subset 116 generated in the past is used. The ACL subset 116 can be generated by a simpler method. Further, the ACL subset 116 may take any form as long as it indicates information including a store that the drill-through request source store can access to the maximum.

  FIG. 10 shows a processing sequence during drill-through execution in the present embodiment.

  In FIG. 10, one of the plurality of store SaaS servers 101 is a store SaaS server 101 (first server in the present embodiment) that is a drill-through request source based on the total count result 115. Here, as in FIG. 6, the store in which the store SaaS server 101 is installed is called a request source store 134. Further, the store where the store SaaS server 101 (second server in the present embodiment) indicated in the ACL subset 116 received by the cross-sectional tabulation unit 106 in (11) of FIG. Call.

  (1) In the store SaaS server 101 of the request source store 134, the drill-through request unit 108 of the data access control device 103 includes the total count result 115 received by the cross tabulation request unit 106 in (11) of FIG. Then, an input designating a portion to be drilled through is received from the user terminal 127 via the network 200 by the communication board 915 (input device). Specifically, the condition extraction unit 111 of the drill-through request unit 108 extracts the drill-through condition (selection condition) from the input of the user terminal 127 and sends it to the ACL subset interpretation unit 112.

  (2) In the store SaaS server 101 of the request source store 134, the ACL subset interpretation unit 112 of the drill-through request unit 108 of the data access control device 103 requests the ACL subset management unit 109 to retrieve the ACL subset 116. .

  (3) In the store SaaS server 101 of the request source store 134, the ACL subset management unit 109 of the data access control device 103 applies the ACL to the total count result 115 that is the basis of drill-through in response to the request of (2). The subset 116 is taken out and sent to the ACL subset interpretation unit 112 of the drill-through request unit 108.

  (4) In the store SaaS server 101 of the request source store 134, the ACL subset interpretation unit 112 of the drill-through request unit 108 of the data access control device 103 has the same number of drill-through request units 108 as the number of stores to which the drill-through request is sent. The result receiving unit 113 is called. This can be realized by executing the result receiving unit 113 for each thread, for example.

  (5) In the store SaaS server 101 of the request source store 134, the drill-through request unit 108 of the data access control device 103 is the part designated by the input (1) to the store SaaS server 101 of the other store 135 A drill-through request designating detailed data corresponding to is transmitted via the network 200. In the store SaaS server 101 of the other store 135, the drill-through response unit 110 of the data access control device 103 receives the drill-through request from the store SaaS server 101 of the request source store 134 via the network 200. Specifically, the result receiving unit 113 of the drill-through request unit 108 of the request source store 134 sends a drill-through request to the drill-through response unit 110 of another store 135 that responds to the drill-through request from the request source store 134. Send.

  (6) In the store SaaS server 101 of the other store 135, the drill-through response unit 110 of the data access control device 103 is designated by the drill-through request of (5) to the service management device 117 of the SaaS monitoring management server 102. The confirmation request designating the detailed data is transmitted via the network 200. In the SaaS monitoring management server 102, the common ACL management unit 121 of the service management device 117 receives a confirmation request from the store SaaS server 101 of another store 135 via the network 200. That is, the drill-through response unit 110 of the other store 135 confirms whether the access to the request source store 134 may be permitted to the common ACL management unit 121 of the SaaS monitoring management server 102.

  (7) In the SaaS monitoring management server 102, whether or not the common ACL management unit 121 of the service management device 117 is permitted to access the detailed data designated by the confirmation request in (6) in the common ACL 126. This is confirmed by the CPU 911 (processing device), and the confirmation result is transmitted to the store SaaS server 101 of the other store 135 via the network 200. In the store SaaS server 101 of another store 135, the drill-through response unit 110 of the data access control device 103 receives the confirmation result from the SaaS monitoring management server 102 via the network 200. That is, the common ACL management unit 121 of the SaaS monitoring management server 102 confirms the common ACL 126 referred to in the confirmation request in (6), and notifies the drill-through response unit 110 of the other store 135 of whether the request source store 134 is accessible. To do.

  (8) In the store SaaS server 101 of the other store 135, the drill-through response unit 110 of the data access control device 103 specifies the detailed data specified in the drill-through request of (5) based on the confirmation result of (7). Is acquired from the service content DB 105. That is, when access becomes possible in (7), the drill-through response unit 110 of the other store 135 issues a drill-through query to the service content DB 105 of the other store 135.

  (9) In the store SaaS server 101 of the other store 135, the drill-through response unit 110 of the data access control device 103 sends the detailed data of (8) to the store SaaS server 101 of the request source store 134 via the network 200. Send with. In the store SaaS server 101 of the request source store 134, the drill-through request unit 108 of the data access control device 103 receives the detailed data from the store SaaS server 101 of the other store 135 via the network 200 by asynchronous communication. Specifically, when the drill-through response unit 110 of the other store 135 obtains the query result for each record in (8), it calls the result receiving unit 113 of the request source store 134 and passes the query result. Here, in order to deliver one record at a time asynchronously, for example, the processing of (9) can be configured as an HTTP (HyperText / Transfer / Protocol) request.

  (10) When the call from the drill-through response unit 110 of the other store 135 to the result receiving unit 113 of the request source store 134 is realized by a call request like an HTTP request in (9), the store of the request source store 134 In the SaaS server 101, the result receiving unit 113 of the drill-through request unit 108 of the data access control device 103 can realize reception of an asynchronous drill-through result by returning a dummy response (for example, an HTTP response).

  (11) In the store SaaS server 101 of the request source store 134, when the result receiving unit 113 of the drill-through request unit 108 of the data access control device 103 acquires the query result for each record in (9), the drill-through request The result display unit 114 of the unit 108 is called.

  (12) In the store SaaS server 101 of the request source store 134, the result display unit 114 of the drill-through request unit 108 of the data access control device 103 displays the drill-through result. At this time, the result display unit 114 of the drill-through request unit 108 may display the drill-through result, for example, on a unique screen by the display device 901 (output device), as in (13) of FIG. For example, the drill-through result may be displayed on the screen of the spreadsheet software by outputting the drill-through result to spreadsheet software such as “Microsoft Excel (registered trademark)”.

  FIG. 11 shows an example of the total count result 115. In FIG. 6 (13), when the cross tabulation requesting unit 106 of the store SaaS server 101 of the request source store 128 outputs the total tabulation result 115 to, for example, “Microsoft Excel (registered trademark)”, FIG. In (1), the condition extraction unit 111 of the store SaaS server 101 of the request source store 134 extracts a drill-through condition designated by the user using, for example, a macro or add-in of “Microsoft Excel (registered trademark)”. can do. For example, when the user selects a cell indicated by a thick frame in FIG. 11, the condition extraction unit 111 reads “the value of the row to which the cell belongs”, and as a drill-through condition “Kanto district Kanagawa in September 2007” It can be extracted that “sales of snack food in the district” is designated.

  FIG. 12 is a flowchart showing the operation of the condition extraction unit 111 of the drill-through request unit 108.

  In FIG. 12, the condition extraction unit 111 extracts a drill-through condition specified by the user (step S201). For example, a condition of “sales of snack foods in Kanagawa district in September 2007” corresponding to the cells indicated by thick frames in FIG. 11 is extracted. Next, the condition extraction unit 111 converts the drill-through condition into an SQL “FROM” phrase and a “WHERE” phrase (step S202). In the example of FIG. 11, the character string “FROM sales”, “WHERE year = 2007 & month = 9 & region = Kanto & district = Kanagawa” is generated. Here, in normal drill-through, since all columns of the table of the service content DB 105 to be subjected to detailed analysis are selected and displayed, it is not necessary to generate the “SELECT” phrase, but the condition extraction unit 111 displays A process of selecting a column may be performed. Finally, the condition extraction unit 111 sends the character string generated in step S202 to the ACL subset interpretation unit 112 (step S203). This character string is received by the result receiving unit 113 of the drill-through request unit 108 as a part of the drill-through request for the store in the ACL subset 116 associated with the total tabulation result 115 that the condition extraction unit 111 is currently referring to. Send it.

  As described above, according to the present embodiment, for example, in a multi-tenant SaaS system, when each tenant individually has a DB or DWH (data warehouse), a certain tenant obtains the data total result of the entire system. To improve the processing efficiency when executing drill-through (inquiry of detailed data based on the total aggregation result) to individual data of each tenant. Specifically, when drill-through is performed, it is possible to receive asynchronous drill-through results and prevent the drill-through requester from sending useless inquiries to tenants who do not have access rights. Become.

As described above, the data search system according to the present embodiment is
A service server that provides individual services, a service monitoring management server for monitoring and managing a plurality of service servers,
As a service management device used by the service monitoring management server,
The master information of data held by each of the multiple service servers, hierarchical structure information between elements of the master information, and information that integrates access right information for the master information (common access control information) is consolidated on the service monitoring management server. When a service user requests access to the data on the service server, the service server used by the service user has a service server belonging to a lower level in the common access control information corresponding to the aggregation condition. It has a service management device characterized by copying partial information consisting of a list.

The data search system is
As a data access control device used by the service server,
Using the partial information of the common access control information received from the service monitoring management server using the service management apparatus in the system, sending an access request to the service server itself or another service server constituting the system. A data access control device.

The data search system is
The service server uses the data access control device, and the service monitoring management server uses the data access control device. Based on the result of crossing the data held by each of the service servers, A subset of the common access control information accompanying the result is used to narrow down the number of service servers to which the individual detailed data search request is sent.

The data search system is
The result for the detailed individual detail data search request is displayed without being synchronized with the service server to which the search request source service server sends the search result.

Embodiment 2. FIG.
In the present embodiment, differences from the first embodiment will be mainly described.

  FIG. 13 is a block diagram showing the configuration of the SaaS system 100. As shown in FIG.

  In FIG. 13, the service management apparatus 117 of the SaaS monitoring management server 102 includes a service management DB 118 (database) in addition to the components shown in FIG. 4 in the first embodiment. The service management DB 118 of the service management device 117 is mounted on a storage device (for example, a hard disk) of the SaaS monitoring management server 102, and has at least three tables of an analysis service contract 123, an analysis service master 124, and a usage status 125.

  The processing sequence at the time of execution of cross-tabulation in the present embodiment is the same as that shown in FIG. 6 in the first embodiment.

  In the present embodiment, in the SaaS monitoring management server 102, the common ACL management DB 119 of the service management device 117 is stored in the common ACL 129 from each store SaaS server 101 to another store SaaS server 101. The storage device stores an exception list indicating whether or not the detailed data is permitted for each combination of the store SaaS server 101 and the detailed data. Then, the drill-through ACL subset generation unit 122 of the service management device 117 performs common ACL management among the SaaS servers 101 for stores in which the detailed data aggregated by the cross-sectional aggregation execution unit 120 in (4) of FIG. 6 is accumulated. Requested by the common ACL 129 stored in the common ACL management DB 119 in addition to the store SaaS server 101 indicated to belong to the same group as the store SaaS server 101 of the request source store 128 in the common ACL 129 stored in the DB 119 The store SaaS server 101 that is shown to belong to a different group from the store SaaS server 101 of the original store 128, and the store SaaS server 101 of the request source store 128 in the exception list stored in the common ACL management DB 119. In Fig. 6 (indicated to allow access from ) Cross-tabulation execution unit 120 generates an ACL subset 116 showing a SaaS server 101 for shop to accumulate the same kind of detailed data and detailed data aggregated in.

  FIG. 14 shows an example in which the regional / division total common ACL 130 shown in FIG. 7 in the first embodiment is realized by a relational DB. In FIG. 14, the regional table 131, the district table 132, and the store table 133 are tables corresponding to the respective hierarchies of the common ACL 130 for tabulation by region and district shown in FIG. 7, as in FIG. 8 of the first embodiment. It is. In the present embodiment, each common ACL 126 has an exception list, and each region / division-specific common ACL 130 also has one exception list.

  The exception list is evaluated only when the requesting store can drill through depending on the usage status, such as whether there is a charge overdue for the service contract of the store that is the drill-through request source or whether the usage time / data amount limit is exceeded. For example, each store can refer to the DB managed by other stores only when contracting “sales analysis by region / district” with the service of SaaS, in which case the SaaS monitoring management server 102 In the access control during drill-through, an exception list that is a part of the store table 133 is evaluated. The exception list includes a list 136 of table names in the service content DB 105 (a table list in the present embodiment) and a list 137 of other stores that can be accessed by each store in association with each table (in the present embodiment). Element list).

  Information regarding the service contract of each store is managed by the service management DB 118 of the SaaS monitoring management server 102.

  FIG. 15 shows an example of the analysis service contract 123 and the analysis service master 124 which are tables of the service management DB 118.

  In FIG. 15, the analysis service contract 123 has information on the analysis service contracted by each store. In the example of FIG. 15, the analysis service contract 123 indicates that the store A1 has contracted with each of the analysis services “sales analysis” and “inventory analysis”. Further, it is indicated that the store A2 does not contract any analysis service. The analysis service master 24 has information indicating which table in the service content DB 105 each analysis service permits, and which common ACL 126 performs access control at the time of drill-through. In the example of FIG. 15, the analysis service master 24 permits the “sales analysis” service to be aggregated with respect to the sales table 138 of the service content DB 105 illustrated in FIG. 16, and “region”, “product”, “organization” as the common ACL 126. ”And“ date and time ”are applied. In addition, regarding the “stock analysis” service, it is permitted to count the stock table 139 of the service content DB 105 illustrated in FIG. 16 and apply “region”, “product”, “organization”, and “date / time” as the common ACL 126. Show. Further, the analysis service master 24 permits the “store detail analysis” service to be aggregated with respect to the store detail table 140 of the service content DB 105 illustrated in FIG. 16, and sets “region”, “organization”, and “date / time” as the common ACL 126. It shows that it applies.

  Hereinafter, an example of access control in each analysis service will be described with reference to FIGS.

  FIG. 16 shows an example of a sales table 138, an inventory table 139, and a store detail table 140, which are tables of the service content DB 105. In this example, the sales table 138 is configured to hold a store name, sales date and time, merchandise, unit price, quantity, and amount. In addition, the inventory table 139 is configured to hold a store name, a product, a purchase date, a purchase source, a number, and a retention period. The store detail table 140 is configured to hold a store name, a sales floor area, the number of employees, the number of part-time jobs, and an address.

  FIG. 17 shows a common ACL 141 for product-based aggregation as an example of the common ACL 126. In this example, the product-specific tabulation common ACL 141 includes three levels of major classification, minor classification, and handling stores. For example, the product-specific tabulation common ACL 141 is applied to the sales table 138 shown in FIG. 16, and in principle, a product that is not handled by the drill-through request source store is not permitted to be drill-through to another store. be able to. In FIG. 17, it is assumed that the store A1 handles confectionery, bread, and alcohol, but does not handle writing instruments. Store A2 handles confectionery and bread, but does not handle alcohol or writing instruments. Store A3 handles confectionery and writing instruments, but does not handle bread or alcohol. By applying the product-specific tabulation common ACL 141 to the sales table 138 shown in FIG. 16, the store A1 can access the confectionery and bread sales information of the store A2 and the confectionery sales information of the store A3. Further, when the common ACL for product totalization 141 is applied to the sales table 138 shown in FIG. 16 together with the common ACL for totaling by region / district shown in FIG. Although the sales information can be accessed, the sales information of the store A3 cannot be accessed.

  FIG. 18 shows a common ACL 142 for organization-specific aggregation as an example of the common ACL 126. In this example, the organization-specific common ACL 142 is composed of three levels of division, store form, and store. For example, the organization-specific common ACL 142 is applied to the sales table 138 and the inventory table 139 shown in FIG. 16, and access is not permitted for drill-through requests from different stores of the business division to which the organization belongs. Can take. In FIG. 18, store A1 and store A2 can drill through to each other's sales information and inventory information, but store A1, store A2, and store A3 are prevented from drilling through to each other's data. it can.

  FIG. 19 shows an example of the usage status 125 that is a table of the service management DB 118.

  In FIG. 19, the usage status 125 includes “contractor name” (store or district / regional manager), “fee payment date”, “current usage time”, “last usage start date”, “last usage”. It is composed of columns of “end date and time”. When a certain store is a request source for the total aggregation, the SaaS monitoring management server 102 relates to the service contracted in the analysis service contract 123 shown in FIG. 15 by the use status 125 shown in FIG. Access to the target included in the exception list shown in FIG. 14 only when the service is available under the contract conditions by confirming whether there is a charge delinquency for the service contract of the store, whether the usage time / data amount limit is exceeded, etc. Allow. As a modified example, when a certain store has a pay-per-use contract based on service use time, the use restriction can be confirmed by referring to the information related to the pay-per-use contract type stored in the service management DB 118. .

  FIG. 20 is a flowchart showing the operation of the drill-through ACL subset generation unit 122 of the service management apparatus 117.

  20, steps S301 to S306 are the same as steps S101 to S106 in FIG. 9 of the first embodiment. In FIG. 20, steps S309 and S310 are the same as steps S107 and S108 in FIG. 9 of the first embodiment.

  After step S306, the drill-through ACL subset generation unit 122 determines whether or not the user can refer to the exception list according to the service contract status of the store (user) of the total aggregation request source (step S307). When the drill-through ACL subset generation unit 122 determines that the user can refer to the exception list, the drill-through ACL subset generation unit 122 executes an exception list reference process (step S308). If the drill-through ACL subset generation unit 122 determines in step S307 that the user cannot refer to the exception list, the drill-through ACL subset generation unit 122 proceeds to the process of the next table included in the overall aggregation request in step S302.

  FIG. 21 is a flowchart showing a detailed operation of step S307 in FIG.

  In FIG. 21, the drill-through ACL subset generation unit 122 refers to the analysis service contract 123 of the service management DB 118 (step S401), and determines whether the store (user) of the total aggregation request source has contracted for the analysis service. (Step S402). When the user subscribes to the analysis service, the drill-through ACL subset generation unit 122 refers to the usage state 125 of the service management DB 118 (step S403), and there is no charge delinquency or usage time excess according to the content of the contract. Whether or not (step S404). This determination may be made by adding / deleting conditions depending on individual circumstances of SaaS.

  When both the conditions in steps S402 and S404 are true (YES), the drill-through ACL subset generation unit 122 performs the processes in steps S406 to S410 for all analysis services contracted by the user (step S405). ).

  The drill-through ACL subset generation unit 122 refers to the analysis service master 124 of the service management DB 118 (step S406), and determines whether the column “table” includes an object of total aggregation (step S407). When the column “table” includes a table to be subjected to total aggregation (to be a drill-through request target based on the total aggregation result 115), the drill-through ACL subset generation unit 122 performs steps S304 to S308 in FIG. 20 is confirmed whether there is a contracted analysis service including the common ACL 126 to be processed (step S408). If the confirmation result in step S408 is true (YES), steps S304 to S304 in FIG. It is determined that the exception list of the common ACL 126 that is the processing target of S308 can be referred to (step S409).

  If the drill-through ACL subset generation unit 122 determines in step S402 that the user has not contracted for the analysis service, the user has caused problems such as arrears in charges and excess usage time in step S404. If the column “table” of the analysis service master 124 of the service management DB 118 does not contain an object of total tabulation in step S407, the user determines that the user has steps S304 to S304 in FIG. When it is determined that the analysis service including the common ACL 126 that is the processing target in S308 is not contracted, it is determined that the exception list of the common ACL 126 is not referable or reference is not required in any case ( Step S410).

  For example, the store SaaS server 101 of the store A1 designates the sales table 138 shown in FIG. 16 as an aggregation target, and the aggregation ACL for each region / district in FIG. 7 as the aggregation condition (the analysis service shown in FIG. 15). When the “total” is requested by designating “district” of the common ACL 126 “region” of the master 124, the drill-through ACL subset generation unit 122, unless the usage status of the store A 1 violates the service contract, It is determined that the exception list of the common ACL 130 for aggregation by region / division can be referred to. This indicates that the analysis service contract 123 shown in FIG. 15 indicates that the store A1 has a contract for the “sales analysis” service. In the analysis service master 124, the sales table 138 indicates the “sales analysis” service. This is because the common ACL 130 for aggregation by region and by region is set as the common ACL 126 applied to the sales table 138. On the other hand, for example, when the store SaaS server 101 of the store A2 requests the same total tabulation, the drill-through ACL subset generation unit 122 is common for tabulation by region and district regardless of the usage status of the store A2. It is determined that the ACL 130 exception list cannot be referenced. This is because the analysis service contract 123 shown in FIG. 15 indicates that the store A2 has not contracted the “sales analysis” service. Further, for example, in the usage state 125 shown in FIG. 19, the current month usage time of the store A1 is 100 hours. When this store A1 has a service contract that “the accumulated usage time of one month is within 50 hours”, the drill-through ACL subset generation unit 122 proceeds from step S404 to step S410, and the exception list of the common ACL 126 is referred to. Judge that it is impossible. Further, for example, when the store A1 requests total aggregation regarding a borrowing table or the like not in the column “table” of the analysis service master 124 shown in FIG. 15, the drill-through ACL subset generation unit 122 proceeds from step S407 to step S410. Then, it is determined that the exception list of the common ACL 126 is not referable. Further, for example, when the store A1 requests the total aggregation to apply the common ACL 126 “business hours” not existing in the analysis service master 124 shown in FIG. The unit 122 proceeds from step S408 to step S410, and determines that the exception list of the common ACL 126 is not referable.

  FIG. 22 is a flowchart showing the detailed operation of step S308 in FIG.

  In FIG. 22, the drill-through ACL subset generation unit 122 applies a total count request (the target of the total count is based on the total count result 115) to each table included in the table list of the exception list (step S <b> 501). It is determined whether the table is included in the drill-through request (step S502). When the drill-through ACL subset generation unit 122 determines that the target table is a table included in the overall aggregation request, the drill-through ACL subset generation unit 122 executes the processes of steps S502 to S505.

  The drill-through ACL subset generation unit 122 confirms whether or not the element in the element list corresponding to the target table is already included in the temporary list in step S306 of FIG. 20 (step S503). (Step S504). If the target element is not included in the temporary list, the drill-through ACL subset generation unit 122 adds the element to the temporary list in step S306 of FIG. 20 (step S505). When the drill-through ACL subset generation unit 122 determines in step S502 that the target table is not included in the total aggregation request, or in step S504, the target element is already included in the temporary list. If it is determined that it is, the process proceeds to the next table in step S501. In FIG. 22, for example, in the hierarchy of the common ACL 126 determined to correspond to the aggregation condition in step S305 of FIG. 20, the configuration is applied to the exception list attached to the element including the total aggregation request source below it. it can. Or you may comprise, for example with respect to the exception list | wrist accompanying the said element and a lower-order element.

  For example, the store SaaS server 101 of the store A1 designates the sales table 138 shown in FIG. 16 as an aggregation target, and includes the exception list shown in FIG. When the total count is requested by designating “district”, as described above, the drill-through ACL subset generation unit 122 does not violate the service contract as long as the usage status of the store A1 does not violate the service contract. It is determined that the exception list of can be referred to. At this time, if the exception list is not referred to, the store SaaS server 101 of the store A1 can access only the detailed data of the store A1 itself and the store A2. However, when the exception list is referred to, since the sales table 138 is a target of the total aggregation in step S502, the drill-through ACL subset generation unit 122 lists the table name of the exception list shown in FIG. From this, a list 137 of other stores corresponding to the sales table 138 is acquired, and the processes of steps S503 to S505 are executed. This list 137 of other stores includes store A2 and store A4. For store A2, the drill-through ACL subset generation unit 122 is already included in the temporary list in step S306 of FIG. 20 in step S504. In order to determine that the store is a store, the process of step S505 is not executed. On the other hand, for the store A4, the drill-through ACL subset generation unit 122 determines in step S503 that the store is not included in the temporary list in step S306 of FIG. Add to As described above, when the exception list is referred to, the store SaaS server 101 of the store A1 accesses not only the detailed data of the store A1 and the store A2 but also the detailed data of the store A4 (drill-through). It becomes possible.

  As described above, according to the present embodiment, for example, in a multi-tenant SaaS system, when each tenant individually has a DB or a DWH (data warehouse), a service for a drill-through request of each tenant It is possible to apply restrictions according to the usage status for the contract.

As described above, the data search system according to the present embodiment is
A service server that provides individual services, a service monitoring management server for monitoring and managing a plurality of service servers,
As a service management device used by the service monitoring management server,
The master information of data held by each of the multiple service servers, hierarchical structure information between elements of the master information, and information that integrates access right information for the master information (common access control information) is consolidated on the service monitoring management server. When a service user requests access to the data on the service server, the service server used by the service user has a service server belonging to a lower level in the common access control information corresponding to the aggregation condition. Copy the partial information consisting of the list,
In addition, in the common access control information, exceptions of access control are managed by an exception list. The exception list has a service contract related to the use of the exception list by the user, and the service usage status of the user is a service. The service management apparatus is characterized in that the evaluation is performed only in accordance with the usage rule defined in the usage contract.

The data search system is
The service monitoring management server uses the above-mentioned service management device, and when using the subset of the common access control information attached to the aggregation result, when narrowing down the number of service servers to which the individual detailed data search request is sent, Control exceptions can be made only when the user has a service contract related to the use of the exception, and the service usage status of the user complies with the usage rules stipulated in the service usage contract.

The data search system is
The result for the detailed individual detail data search request is displayed without being synchronized with the service server to which the search request source service server sends the search result.

  As mentioned above, although embodiment of this invention was described, you may implement combining 2 or more embodiment among these. Alternatively, one of these embodiments may be partially implemented. Or you may implement combining two or more embodiment among these partially.

It is a block diagram which shows the structure of a SaaS system. It is a block diagram which shows the structure of a SaaS system. It is a figure which shows the drill through process procedure in a SaaS system. 1 is a block diagram illustrating a configuration of a SaaS system according to a first embodiment. It is a figure which shows an example of the hardware resource of the SaaS server for stores which concerns on Embodiment 1, and a SaaS monitoring management server. FIG. 6 is a diagram showing a processing sequence at the time of execution of cross-sectional aggregation in the first embodiment. 3 is a diagram illustrating an example of a common ACL in Embodiment 1. FIG. 6 is a diagram illustrating an implementation example of a common ACL using a relational DB according to Embodiment 1. FIG. 6 is a flowchart showing an operation of a drill-through ACL subset generation unit according to the first embodiment. FIG. 10 is a diagram showing a processing sequence at the time of drill-through execution in the first embodiment. FIG. 10 is a diagram showing an example of a total count result in the first embodiment. 6 is a flowchart showing an operation of a drill-through request unit in the first embodiment. 10 is a table showing an example of an analysis service contract and an analysis service master in the second embodiment. FIG. 11 is a diagram illustrating an implementation example using a relational DB of a common ACL in the second embodiment. It is a figure which shows the example of the analysis service contract in Embodiment 2, and an analysis service master. 10 is a table showing an example of detailed data in the second embodiment. FIG. 10 is a diagram illustrating an example of a common ACL in the second embodiment. FIG. 10 is a diagram illustrating an example of a common ACL in the second embodiment. 10 is a table illustrating an example of a usage situation in the second embodiment. 10 is a flowchart showing an operation of an ACL subset generation unit for drill-through in the second embodiment. 10 is a flowchart showing an operation of an ACL subset generation unit for drill-through in the second embodiment. 10 is a flowchart showing an operation of an ACL subset generation unit for drill-through in the second embodiment.

Explanation of symbols

  100 SaaS system, 101 Store SaaS server, 102 SaaS monitoring management server, 103 data access control device, 104 work storage area, 105 service content DB, 106 cross-tabulation request section, 107 cross-tabulation response section, 108 drill-through Request section, 109 ACL subset management section, 110 Drill-through response section, 111 Condition extraction section, 112 ACL subset interpretation section, 113 Result reception section, 114 Result display section, 115 Total count result, 116 ACL subset, 117 Service management device, 118 service management DB, 119 common ACL management DB, 120 cross-sectional aggregation execution unit, 121 common ACL management unit, 122 drill-through ACL subset generation unit, 123 analysis service contract, 124 analysis service manager 125, usage status, 126 common ACL, 127 user terminal, 128 request source store, 129 other store, 130 common ACL for aggregation by region / district, 131 district table, 132 district table, 133 store table, 134 request source store , 135 Other stores, 136 List of table names, 137 List of other stores, 138 Sales table, 139 Inventory table, 140 Store details table, 141 Common ACL for totaling by product, 142 Common ACL for totaling by organization, 200 network, 901 Display device, 902 keyboard, 903 mouse, 904 FDD, 905 CDD, 906 printer device, 911 CPU, 912 bus, 913 ROM, 914 RAM, 915 communication board, 920 magnetic disk device, 921 operating system Beam, 922 window system, 923 programs, 924 files, 991 SaaS system, 992 SaaS system.

Claims (7)

From one of a plurality of servers that store a plurality of types of detailed data (hereinafter referred to as “first server”), a totaling request specifying a type of detailed data to be totaled is received via the network, A totalization execution unit that collects detailed data of the type stored in each server from the server via the network, and generates totalized data by counting the detailed data by a processing device;
A common ACL management database that stores, in a storage device, a common ACL (access control list) that indicates whether or not access to detailed data stored in other servers from each server is permitted;
Of the detailed data aggregated by the aggregation execution unit, a server that accumulates detailed data indicated to permit access from the first server in the common ACL stored in the common ACL management database (hereinafter referred to as “the first item”). An ACL subset generating unit for generating an ACL subset indicating a “two server”) by a processing device,
The aggregation execution unit transmits the generated aggregation data and the ACL subset generated by the drill-through ACL subset generation unit to the first server via a network, and the ACL subset is generated from a part of the aggregation data. A service management apparatus that causes the first server to execute drill-through to detailed data stored in the indicated second server. The common ACL management database stores a common ACL indicating, for each server, a group to which each server belongs among a plurality of groups in which the plurality of servers are classified.
The drill-through ACL subset generator belongs to the same group as the first server in the common ACL stored in the common ACL management database among the servers storing the detailed data tabulated by the tabulation execution unit. The service management apparatus according to claim 1, wherein an ACL subset indicating the server indicated by the URL as the second server is generated. The service management device further includes:
The common ACL management database further stores, in a storage device, an exception list indicating permission / refusal of each type of detailed data stored in other servers from each server for each combination of the server and the detailed data type. ,
The drill-through ACL subset generation unit belongs to the same group as the first server in the common ACL stored in the common ACL management database among the servers storing the detailed data tabulated by the tabulation execution unit. In addition to the server indicated, the common ACL stored in the common ACL management database indicates that it belongs to a group different from the first server, and is stored in the common ACL management database. Generate an ACL subset indicating, as the second server, a server that stores detailed data of the same type as the detailed data aggregated by the aggregation execution unit, which is indicated in the exception list to permit access from the first server. The service management apparatus according to claim 2. In a data access control device provided in one of a plurality of servers that accumulate a plurality of types of detailed data (hereinafter referred to as “first server”),
A service that collects detailed data stored in each server from the plurality of servers and stores a common ACL (access control list) that indicates whether each server has access to detailed data stored in other servers. Aggregated data generated by sending a summary request specifying the type of detail data to be aggregated to the management device via the network and aggregating the type of detail data stored in each server from the service management device And an ACL subset indicating a server (hereinafter referred to as “second server”) that stores the detailed data indicated to permit access from the first server in the common ACL among the detailed data via the network. The aggregation request part received at
The input device receives an input designating a portion to be drilled out of the total data received by the total request unit, and the input to the second server indicated in the ACL subset received by the total request unit A data comprising: a drill-through request unit which transmits a drill-through request designating detailed data corresponding to a designated part via a network, and receives the detailed data from the second server via the network. Access control device.   The drill-through request unit receives asynchronous specification data corresponding to a part specified by the input from a second server indicated in the ACL subset received by the aggregation request unit. 4. The data access control device according to 4. A common one of a plurality of servers that store a plurality of types of detailed data (hereinafter referred to as a “first server”) indicates whether each server is permitted to access detailed data stored in other servers. To the service management device that stores the ACL (access control list), a totaling request specifying the type of detailed data to be totaled is sent,
The service management device collects detailed data of the type specified in the totaling request from the multiple servers stored in each server from the plurality of servers, and totalizes the detailed data by a processing device. Produces
The service management device indicates a server (hereinafter referred to as a “second server”) that stores the detailed data indicated by the common ACL that access from the first server is permitted, among the detailed data collected. An ACL subset is generated by the processing unit;
The service management device transmits the generated aggregate data and ACL subset to the first server,
The first server receives an input designating a portion to be drilled out of the aggregated data by the input device, and corresponds to the portion designated by the input to the second server indicated in the ACL subset Send a drill-through request with the line item data
The second server sends the detailed data specified in the drill-through request to the first server,
The data search method, wherein the first server displays the detailed data on a display device. The data search method further includes:
The second server sends a confirmation request specifying the detailed data specified in the drill-through request to the service management device;
The service management device confirms by the processing device whether or not it is shown that the access to the detailed data designated by the confirmation request transmitted from the second server is permitted by the common ACL, and the confirmation result Send
The data search method according to claim 6, wherein the second server transmits detailed data designated by the drill-through request to the first server based on the confirmation result.

Images