Patent Publication Number: US-11048695-B2

Title: Context-aware data commenting system

Description:
BACKGROUND 
     Enterprise software systems receive, generate, and store data related to many aspects of an enterprise. Users operate reporting tools to access such data and display the data in useful formats, such as in graphic visualizations. For example, some conventional reporting tools receive user-submitted queries (e.g., Sales by Country), and present a visualization (e.g., a bar graph, a pie chart, a geomap) of a corresponding result set. 
     A user may wish to annotate a visualization by associating a comment with particular data of the result set. In some systems, a comment created by User A with respect to particular data may be presented to User B upon viewing the particular data. However, the comment may be presented to User B only if the viewing context of User B is determined to be the same as the viewing context of User A at the time the comment was created. Current systems for making this determination require execution of backend queries involving validating a user&#39;s data access and complex and time-consuming joins between fact and dimension tables, and may therefore consume an unsuitable amount of time and resources. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is an outward view of a user interface presenting a visualization according to some embodiments. 
         FIG. 2  is a block diagram of a system architecture according to some embodiments. 
         FIG. 3  comprises a flow diagram of a process to create a comment according to some embodiments. 
         FIG. 4  is an outward view of an interface illustrating a data model according to some embodiments. 
         FIG. 5  is an outward view of an interface illustrating role restrictions according to some embodiments. 
         FIG. 6  comprises a flow diagram of a process to present query results according to some embodiments. 
         FIG. 7  is an outward view of a user interface presenting a visualization according to some embodiments. 
         FIG. 8  comprises a flow diagram of a process to determine whether to present a comment according to some embodiments. 
         FIG. 9  comprises a flow diagram of a process to determine whether to present a comment according to some embodiments. 
         FIG. 10  a block diagram of an apparatus according to some embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily apparent to those in the art. 
       FIG. 1  illustrates interface  10  presenting visualization  12  according to some embodiments. As will be described below, interface  10  may comprise a Web page provided by a server in response to a request from a Web browser application executing on a client device. 
     Visualization  12  comprises a cross-tab showing measure values aggregated over various combinations of dimension members of a ProfitAndLoss data source (e.g., an Online Analytical Processing (OLAP) cube). Each measure value is associated with a displayed dimension member of “Actual” or “Forecast”, however the aggregations may also be performed over background dimension members and in view of data and role access authoriations associated with the user who is viewing interface  10 , as is known in the art. 
     Interface  10  also includes comment window  14  presenting a comment “Revenue looks good!” created by the current user (i.e., ADMIN). The comment is associated with a particular data cell of visualization  12  which includes a particular aggregation (i.e., aggregating to the measure value 205.63. The comment may be created using any suitable user interface metaphor, for example by right-clicking on the data cell and selecting “Create Comment” from a subsequently-displayed context menu. 
     As mentioned above, it may be desired to present the created comment to another user in a case that the other user views a visualization including the same aggregated measure value. According to some embodiments, and in response to the creation of a comment with respect to a particular data cell, the context associated with the cell is determined and stored in association with the comment. If the visualization is viewed by another user, the comment is displayed to the other user if the viewed visualization includes a data cell having the same context as the context stored with the comment. 
     The context includes the intersection of the multi-dimensional data that aggregates up to the data value (i.e., 205.63). The aggregation is subject to any filters that have been applied to the visualization, to the visible (e.g. Version and Account) dimensions and background (e.g., Region) dimensions, and to any data access restrictions on the dimensions which are associated with the user. In contrast to conventional systems, some embodiments compare the contexts and authorize viewing of a comment without re-executing the analytical queries underlying the data cell with which the comment is associated. 
       FIG. 2  is a block diagram of architecture  100  according to some embodiments. Embodiments are not limited to architecture  100  or to a database architecture. 
     Architecture  100  includes data store  110 , database management system (DBMS)  120 , server  130 , services  135 , metadata  137 , clients  140 ,  142 ,  144  and respective applications  145 ,  147  and  149 . Generally, services  135  executing within server  130  receive requests from applications  145 ,  147 ,  149  executing on clients  140 ,  142 ,  144  and provide results thereto based on metadata  137  and data stored within data store  110 . 
     Server  130  may execute and provide services  135  to applications  145 ,  147 ,  149 . Services  135  may comprise server-side executable program code (e.g., compiled code, scripts, etc.) which provide functionality to applications by providing user interfaces to clients, receiving requests from the applications, retrieving data from or storing data within data store  110  based on the requests, and providing responses to the applications. Services  135  may be made available for execution by server  130  via registration and/or other procedures which are known in the art. 
     In one specific example, client  140  executes an application  145  (e.g., a Web browser) to present a user interface to a user on a display of the client  140 . The user enters a query into the user interface and the application  145  passes a request based on the query to one of services  135 . An SQL script is generated based on the request and forwarded to DBMS  120 . DBMS  120  executes the SQL script to return a result set based on data of data store  110 , and the application  145  creates and presents a visualization based on the result set. 
     As described above, the visualization may include one or more user comments which are associated with data depicted in the visualization. A user may interact with application  145  to submit new comments associated with depicted data. The comments may be stored in data store  110  in association with their contexts as will be described below. 
     Server  130  provides any suitable protocol interfaces through which applications executing on clients may communicate with services  135  executing on application server  130 . For example, server  130  may include a HyperText Transfer Protocol (HTTP) interface supporting a transient request/response protocol over Transmission Control Protocol (TCP), and/or a WebSocket interface supporting non-transient full-duplex communications between server  130  and any clients which implement the WebSocket protocol over a single TCP connection. 
     One or more services  135  executing on server  130  may communicate with DBMS  120  using database management interfaces such as, but not limited to, Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC) interfaces. These types of services  135  may use Structured Query Language (SQL) to manage and query data stored in data store  110 . 
     DBMS  120  serves requests to query, retrieve, create, modify (update), and/or delete data of data store  110 , and also performs administrative and management functions. Such functions may include snapshot and backup management, indexing, optimization, garbage collection, and/or any other database functions that are or become known. DBMS  120  may also provide application logic, such as database procedures and/or calculations, according to some embodiments. This application logic may comprise scripts, functional libraries and/or compiled program code. 
     Server  130  may be separated from or closely integrated with DBMS  120 . A closely-integrated server  130  may enable execution of services  135  completely on the database platform, without the need for an additional server. For example, according to some embodiments, server  130  provides a comprehensive set of embedded services which provide end-to-end support for Web-based applications. The services may include a lightweight web server, configurable support for Open Data Protocol, server-side JavaScript execution and access to SQL and SQLScript. 
     Data store  110  may implement an “in-memory” database, in which a full database stored in volatile (e.g., non-disk-based) memory (e.g., Random Access Memory). The full database may be persisted in and/or backed up to fixed disks (not shown). Embodiments are not limited to an in-memory implementation. For example, data may be stored in Random Access Memory (e.g., cache memory for storing recently-used data) and one or more fixed disks (e.g., persistent memory for storing their respective portions of the full database). 
     Metadata  137  may store metadata defining objects which are mapped to logical entities of data store  110 . Each object associates one or more physical entities (e.g., a physical database table, associated columns of one or more database tables, etc.) of one or more enterprise data sources with user-friendly names. These objects may be classified as dimensions, along which one may want to perform an analysis or report (e.g., Year, Country, Product) or measures (e.g., Sales, Profit), whose values can be determined for a given combination of dimension values. Accordingly, a query received from one of clients  140  may comprise a combination of one or more measures, dimensions, dimension values and/or filters. 
     In some embodiments, the data of data store  110  may comprise one or more of conventional tabular data, row-based data, column-based data, and object-based data. Moreover, the data may be indexed and/or selectively replicated in an index to allow fast searching and retrieval thereof. Data store  110  may support multi-tenancy to separately support multiple unrelated clients by providing multiple logical database systems which are programmatically isolated from one another. 
     Each of clients  140 ,  142 ,  144  may comprise one or more devices executing program code of an application  145 ,  147 ,  149  for presenting user interfaces to allow interaction with application server  130 . The user interfaces may comprise user interfaces suited for reporting, data analysis, and/or any other functions based on the data of data store  110 . 
     Presentation of a user interface as described herein may comprise any degree or type of rendering, depending on the type of user interface code generated by server  130 . For example, a client may execute a Web Browser to request and receive a Web page (e.g., in HTML format) from application server  130  via HTTP, HTTPS, and/or WebSocket, and may render and present the Web page according to known protocols. One or more clients may also or alternatively present user interfaces by executing a standalone executable file (e.g., an .exe file) or code (e.g., a JAVA applet) within a virtual machine. In another method, one of more clients execute applications loaded from server  130 , that receive data and metadata by requests to services  135  executed on the server  130 . Data and metadata are processed by the applications to render the user interface on the client  140 . 
       FIG. 3  comprises a flow diagram of process  300  according to some embodiments. Process  300  may be executed to retrieve comments associated with a data point presented in a visualization. In some embodiments, various hardware elements of system  100  execute program code to perform process  300 . 
     Process  300  and all other processes mentioned herein may be embodied in computer-executable program code read from one or more of non-transitory computer-readable media, such as a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, and a magnetic tape, and then stored in a compressed, uncompiled and/or encrypted format. In some embodiments, hard-wired circuitry may be used in place of, or in combination with, program code for implementation of processes according to some embodiments. Embodiments are therefore not limited to any specific combination of hardware and software. 
     Prior to process  300 , a user submits an analytic query against a transaction, or fact, table in order to request a visualization of a result set of data. The result set consists of aggregated values determined from individual values stored within individual records of the transaction table, while taking the user&#39;s data access permissions into account. The query may comprise at least one measure or dimension. 
     The query is executed against the transaction table at S 310 . As described above, and according to some embodiments, server  130  may receive the query, generate an SQL script based on the query and on the metadata defining the dimensions and measures of the query, and forward the script to DBMS  120 . DBMS  120  executes the SQL script to return a corresponding result set to an application executing on a client based on data of data store  110 . The application renders and presents a visualization of the result set at S 320 , for example in a crosstab format. 
     A comment is received at S 330 . The comment is associated with a displayed data cell and may be input by a user as described above with respect to  FIG. 1  or in any other suitable manner which associates the input comment with a data cell. Next, at S 340 , a context of the comment is determined. 
     As described above, the context may comprise the intersection of the multi-dimensional data that aggregates up to the data value associated with the comment, subject to any filters that have been applied to the visualization, to the visible (e.g. Version and Account) dimensions and background (e.g., Region) dimensions, and to any data access restrictions on the dimensions which are associated with the user. In other words, the context is a representation of the aggregation which resulted in the value displayed within the data cell at the time the comment was created. 
     In this regard, the returned result set may be subject to data restrictions associated with the requesting user. These restrictions may comprise data access restrictions and/or role level restrictions according to some embodiments. Data restrictions may be defined via the data model, which acts as an interface to the data and includes semantics as to how the data should be queried. 
       FIG. 4  illustrates a “Profit and Loss” model according to some embodiments, which is composed of six key dimensions (i.e., Time, Version, Account, Region, Product, and Currency). Data access control allows a user to set restrictions on specific dimension members. For example, an administrator can restrict John to only see the United States data under the North America hierarchy. 
     An administrator may also configure similar data access through role-level restrictions. For example, as illustrated in  FIG. 5 , an administrator can create a new role and restrict any users having that role to only see data associated with City: Los Angeles and Marital Status: single. 
     Accordingly, determination of the context at S 340  according to some embodiments includes determining the current user and any filters currently applied to the visualization. The current user is associated with data access control settings (see, e.g.,  FIG. 4 ) and role level security settings (see, e.g.,  FIG. 5 ). Accordingly, determination of the current user may be a proxy for determination of the data access control settings and role level security settings. Alternatively, the data access control settings and role level security settings may be determined at S 340  explicitly. 
     The comment and context are stored at S 350 . According to some embodiments, the context (e.g., User Identifier and filters) is stored in association with the comment, for example, among comments of data store  110 . The comment and context may be stored in any manner which facilitates identification of the comment and its corresponding context. 
     Process  600  of  FIG. 6  may be executed to identify previously-stored comments and determine whether or not to display the identified comments to another user. Initially, at S 610 , a query of a transaction table is received from a client system operated by a viewing user. As described above, the query may comprise a request to view a visualization of a result set composed of aggregations at the intersection of one or more dimensions and/or measures of a transaction table. The result set is subject to any applied filters and the security constraints (e.g., data access control settings and role level security settings) associated with the viewing user. A result set of the query is generated and returned to the client system at S 620  as is known in the art (e.g., by executing the query, formatting the result set, and returning the formatted result set to the querying client system). 
     As is also known in the art, the client system renders and presents a visualization of the received result set. The visualization may reflect various view selections (e.g., particular dimensions) and filters applied by the viewing user. For example, the returned result set may include many columns, but the viewing user may only be interested in viewing a much smaller subset of the columns. Moreover, the viewing user may apply filters to exclude certain rows of the result set from the visualization based on the filter criteria. 
     A subset of the result set is received from the client system at S 630 . The subset reflects the aggregated values which are actually viewed by the viewing user, in view of the current view selections of the viewing user. 
     Authorized comments are determined at S 640  based on the result set subset. For example, as described above, the backend system may store one or more comments in association with a respective context. The stored comments may be associated with different data cells of a result set, and may have been received from different users. Each of the stored comments may therefore be associated with a different context. 
     At S 640 , the result set subset is used to determine whether any of the stored comments is associated with a context that is equivalent to a current context of the viewing user. By using the result set subset, and as will be described in more detail with respect to  FIGS. 8 and 9 , some embodiments may identify authorized comments without executing joins between the transaction table and related dimension tables. 
     According to some embodiments, S 640  is performed by filtering the transaction data based on the viewing user&#39;s data selection and data access, or by comparing dimension members. Process  800 , described below, represents one implementation of the former approach while process  900  describes one implementation of the latter. 
     Any comments determined to be authorized at S 640  are transmitted to the client system at S 650 . The client system generates a visualization including an indicator of each received comment. The visualization may be generated using any suitable system for producing a visualization of a result set of data based on a query, and may include indicators of all stored comments which were determined at S 640  to be associated with a context that is equivalent to a current context. For example, if the context of a stored comment is determined to match a context of a particular data cell of the result set, an indicator of the stored comment is presented in conjunction with (e.g., adjacent to) the particular data cell of the result set. 
       FIG. 7  illustrates result set  710  presented at S 660  according to some embodiments. Result set  710  is presented along with an indicator of comment  720 , which was previously created and stored by user ADMIN as depicted in  FIG. 1 . In contrast, and as shown in the upper-right of interface  700 , result set  710  has been requested by User 123 . Although only one comment indicator is shown in  FIG. 7 , more than one comment indicator may be presented, depending on the result of determinations performed at S 640 . Any suitable indicators of comments may be utilized by some embodiments. For example, an indicator may comprise a graphical icon located adjacent to the data cell or value associated with the comment, and which is selectable to cause display of the comment. 
     As mentioned above,  FIG. 8  is a flow diagram of process  800  to determine the equivalency of a current context and a stored context of a stored comment at S 640  according to some embodiments. The equivalency determination may also be considered a determination of whether the current user is authorized to view a stored comment. According to some embodiments, process  800  provides generation of WHERE clauses which may be used to directly select rows from the transaction table in order to compare the two contexts. 
     Initially, at S 810 , data access control security information associated with the viewing user is determined, for each data access control-enabled dimension of the current context. Similarly, data access control security information associated with the writing user (i.e., the user who created and stored the comment) is determined, for each data access control-enabled dimension of the current context. According to some embodiments, this information may be obtained from the data access control table of each data access control-enabled dimension. The data access control security information is converted into an SQL predicate for the transaction table associated with the query, to limit the determination of process  800  to those rows of the transaction table which the viewing user and the writing user are authorized to view per the data access control security information. For example: 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                   
                 “Version.ID” IN (‘public.Actual’) AND “Account.ID” IN (‘NETREV’) AND “Region.ID” IN 
               
               
                   
                 (‘REG0002’) AND “Product.ID” IN (‘PRD0001’,‘PRD0002’). 
               
               
                   
               
            
           
         
       
     
     Next, the role security information associated with the viewing user and the writing user is determined at S 820 . For example, based on the viewing user&#39;s current role(s), the following role security information may be determined at S 820 : (“Product.ID”=‘PRD0001’) AND (“Region.ID”=‘REG0001’). 
     S 830  includes determination of any filters that were applied to the table when the comment was created and stored. These filters may be determined from the stored context of the comment. In SQL, the following is an example of filters determined at S 830  according to some embodiments: ((“Version.ID” IN (‘public.Actual’)) AND (NOT (“Account.ID” IN (‘COGS’))) AND (“Region.ID” IN (&#39;REG0002′))). Also at S 830 . any filters applied by the viewing user are determined, for example based on the result set subset received from the client system. 
     At S 840 , first rows are selected from the transaction table based on the data access control security information, the role security information, and on any filters of the comment. At S 850 , second rows are selected from the transaction table based on the data access control security information, the role security information, and on any filters applied by the viewing user. The first and second rows are compared to determine whether a 1:1 correspondence exists at S 860 . If such a correspondence exists, it is determined that the contexts are equivalent and the viewing user is authorized to view the comment. 
     According to some embodiments, S 840 -S 860  may comprise executing SQL statements, including the SQL predicates determined at S 810 -S 830 , which select the first rows and the second rows, perform a full join of the first and second rows, and count the number of null-value rows that result. If the count equals 0, the viewing user is authorized to view the comment. According to one non-exhaustive example of S 840 -S 860 : 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                   
                 WITH TRNS 
               
               
                   
                 AS (SELECT DISTINCT D0.*, D1.*, D2.*, D3.*, D4.* 
               
               
                   
                 FROM “TENANT_TEST”.“t.TEST.CommentingModel::TRNS_CommentingModel” T 
               
               
                   
                 JOIN “_SYS_BIC”.“t.TEST.t.TEST.CommentingModel/Version” D0 
               
               
                   
                 ON D0.“Version.ID” = T.“Version.ID” 
               
               
                   
                 JOIN “_SYS_BIC”.“t.TEST.t.TEST.CommentingModel/Account” D1 
               
               
                   
                 ON D1.“Account.ID” = T.“Account.ID” 
               
               
                   
                 JOIN “_SYS_BIC”.“t.TEST.t.TEST.CommentingModel/Region” D2 
               
               
                   
                 ON D2.“Region.ID” = T.“Region.ID” 
               
               
                   
                 JOIN “_SYS_BIC”.“t.TEST.t.TEST.CommentingModel/Product” D3 
               
               
                   
                 ON D3.“Product.ID” = T.“Product.ID” 
               
               
                   
                 JOIN “_SYS_BIC”.“t.TEST.t.TEST.CommentingModel/Time” D4 
               
               
                   
                 ON D4.“Time.CALMONTH” = T.“Time.CALMONTH”), 
               
               
                   
                 TRNS_FULL 
               
               
                   
                 AS (SELECT DISTINCT “Version.ID”, 
               
               
                   
                 “Account.ID”, 
               
               
                   
                 “Region.ID”, 
               
               
                   
                 “Product.ID”, 
               
               
                   
                 “Time.CALMONTH” 
               
               
                   
                 FROM TRNS 
               
               
                   
                 WHERE ((“Version.ID” IN ( ‘public.Actual’ ) ))), 
               
               
                   
                 CTE0 
               
               
                   
                 AS (SELECT “Version.ID”, 
               
               
                   
                 “Account.ID”, 
               
               
                   
                 “Region.ID”, 
               
               
                   
                 “Product.ID”, 
               
               
                   
                 “Time.CALMONTH” 
               
               
                   
                 FROM TRNS 
               
               
                   
                 WHERE “Account.ID” IN ( ‘COGS’, ‘NETREV’ ) 
               
               
                   
                 AND “Product.ID” IN ( ‘PRD0001’ ) 
               
               
                   
                 AND (( “Version.ID” IN ( ‘public.Actual’ ) ))) 
               
               
                   
                 SELECT Count(*) 
               
               
                   
                 FROM (SELECT * 
               
               
                   
                 FROM TRNS_FULL 
               
               
                   
                 WHERE “Account ID” IN ( ‘COGS’, ‘NETREV’ ) 
               
               
                   
                 AND “Product.ID” IN ( ‘PRD0001’ )) CTE_CURRENT 
               
               
                   
                 FULL JOIN CTE0 
               
               
                   
                 ON CTE0.“Version.ID” = CTE_CURRENT.“Version.ID” 
               
               
                   
                 AND CTE0.“Account.ID” = CTE_CURRENT.“Account.ID” 
               
               
                   
                 AND CTE0.“Region.ID” = CTE_CURRENT.“Region.ID” 
               
               
                   
                 AND CTE0.“Product.ID” = CTE_CURRENT.“Product.ID” 
               
               
                   
                 AND CTE0.“Time.CALMONTH” = CTE_CURRENT.“Time.CALMONTH” 
               
               
                   
                 WHERE ( CTE_CURRENT.“Version.ID” IS NULL ) 
               
               
                   
                 OR ( CTE0.“Version.ID” IS NULL ) 
               
               
                   
               
            
           
         
       
     
     Although significantly more efficient than existing systems, process  800  filtering the transaction data based on the user&#39;s data selection and data access, which may require more processing in the backend server to compute the result than desired. Process  900  may implement S 640  of process  600  differently by assuming that if the comment author (Writer) and the viewing user (Reader) have access to the same set of dimension members that are in the comment context, the contexts are equivalent and the comment should be presented to viewing user. Accordingly, process  900  includes running queries against the relevant dimension tables, rather than against the transaction table. 
     A context of the comment is determined at S 910 . The comment context includes a set of visible dimensions and selected members, filters, and the data access control and role level security information mentioned above. Similarly, at S 920 , a viewer context is determined consisting of visible dimensions and selected members, filters, and the data access control and role level security information. Data access and role level security information is obtained in the server side. This information is combined with the visible dimensions, and selected members, filters on the client side to form the full context. The visible dimensions and selected members, filters may be determined from the result set subset received from the client system at S 630 . 
     Next, at S 930 , it is determined whether the comment context (i.e., the Writer&#39;s Context) is equal to the viewer context (i.e., the Reader&#39;s Context). For each Dimension i , the Writer&#39;s Context is denoted as Context w =Tuple w  ∩ Filter w  ∩ DAC w  ∩ Role w =T w  ∩ F w  ∩ D w  ∩ R w =T w  ∩ C w , and the Reader&#39;s Context is denoted as Context r =Tuple w  ∩ Filter r  ∩ DAC r  ∩ Role r =T w  ∩ F r  ∩ D r  ∩ R r =T w  ∩ C r . 
     T w  represents leaf nodes on which the comment was placed at the time of writing the comment. T w  does not consider any data access control information or filters, only the leaf nodes that exist in the hierarchy. Therefore, T w  is the same for the Reader&#39;s Context and the Writer&#39;s Context. 
     If Dimension i  is a background dimension and T w  is unavailable but C w  is available, then U w  (the set of all dimension members) is stored as T w . If Context w  is to be updated when the dimension changes, it may not be necessary to store U w . The tuple dimension hierarchy view (default hierarchy for U w ) is used to acquire the leaf nodes. The query to acquire T w  is run once per dimension at the time of writing the comment, for example: 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                   
                 SELECT “RESULT_NODE_NAME” 
               
               
                   
                 FROM “_SYS_BIC”.“t.TEST.sap.epm/Account/hier/parentId”(‘expression’=‘leaves(nodes( ))’) 
               
               
                   
                 -- Dimension hierarchy view 
               
               
                   
                 WHERE “QUERY_NODE_NAME” = ? 
               
               
                   
               
            
           
         
       
     
     F w  represents leaf nodes of the filter on the data region at write time. Multiple filters may be expressed as F w1  ∩ F w2  ∩ . . . . In a case that a dimension is filtered by multiple filters (e.g., story filter, page filter, dimension filter), the leaf nodes for each such filter are acquired and combined. Each filter hierarchy view is queried to acquire the leaf nodes. The query to acquire F w  is similar to the query used to acquire T w , for example: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 SELECT “RESULT_NODE_NAME” 
               
               
                 FROM “_SYS_BIC”.“t.TEST.sap.epm/Account/hier/parentId”(‘expression’=‘leaves(nodes( ))’) 
               
               
                 -- Dimension hierarchy view 
               
               
                 WHERE “QUERY_NODE_NAME” = ? 
               
               
                   
               
            
           
         
       
     
     If the filter is an exclude filter, it is converted to an include filter by running: T w −F w . For example, include filter: T w  ∩ F w  ∩ D w  ∩ R w =T w  ∩ C w ; and exclude filter: T w −F w  ∩ D w  ∩ R w =T w  ∩ T w −F w  ∩ D w  ∩ R w =T w  ∩ (T w −F w ) ∩ D w  ∩ R w =T w  ∩ C w    
     D w  represents the leaf nodes of data access control for the writer at comment write time. For example, the following query may be used to acquire D w  for the Account dimension: 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                   
                 SELECT DAC.“MEMBER” 
               
               
                   
                 FROM “TENANT_TEST”.“sap.epm::DAC_Account” DAC 
               
               
                   
                 JOIN “TENANT_TEST”.“sap.epm/Account/parentId” HIER ON DAC.“MEMBER” = 
               
               
                   
                 HIER.“QUERY_NODE_NAME” 
               
               
                   
                 WHERE HIER.“IS_LEAF” = 1 
               
               
                   
                 AND DAC.“USER” = ? 
               
               
                   
               
            
           
         
       
     
     R w  represents the leaf nodes of the role for Dimension i  for the writer at comment write time. The query to acquire R w  may be as follows, and the result of this query is parsed to extract the members for each dimension: 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                   
                 SELECT “DEFINITION” 
               
               
                   
                 FROM “TENANT_TEST”.“sap.fpa.services.security::T_EffectiveDataAccess_” 
               
               
                   
                 \WHERE “CUBE_NAME” = ? 
               
               
                   
                 \AND “USER_NAME” = ? 
               
               
                   
                 [ 
               
               
                   
                  { 
               
               
                   
                  “dimension”: “sap.epm:Account”, 
               
               
                   
                  “property”: “ID”, 
               
               
                   
                  “key”: “sap.epm:Account\tID\tsap.epm”, 
               
               
                   
                  “packageName”: “sap.epm”, 
               
               
                   
                  “operator”: “=”, 
               
               
                   
                  “value”: “500000; 400000; 410110; 410120”, 
               
               
                   
                  “dimMd”: { 
               
               
                   
                  “idField”: “ID”, 
               
               
                   
                  “masterDataTableNoSchema”: “sap.epm::MSTR_Account”, 
               
               
                   
                  “schema”: “TENANT_TEST” 
               
               
                   
                  } 
               
               
                   
                  }, 
               
               
                   
                  { 
               
               
                   
                  “dimension”: “sap.epm:Region”, 
               
               
                   
                  “property”: “ID”, 
               
               
                   
                  “key”: “sap.epm:Region\tID\tsap.epm”, 
               
               
                   
                  “packageName”: “sap.epm”, 
               
               
                   
                  “operator”: “=”, 
               
               
                   
                  “value”: “REG0001;REG0002;REG0004”, 
               
               
                   
                  “high”: 
               
               
                   
                  “dimMd”: { 
               
               
                   
                   “idField”: “ID”, 
               
               
                   
                   “masterDataTableNoSchema”: “sap.epms::MSTR_Region”, 
               
               
                   
                   “schema”: “TENANT_TEST” 
               
               
                   
                  } 
               
               
                   
                   } 
               
               
                   
                  ] 
               
               
                   
               
            
           
         
       
     
     C w  may equal F w  ∩ D w  ∩ R w . To save time and space, F w  ∩ D w  ∩ R w  may be stored together as C w . F r  represents leaf nodes of the filter on data region at read time. The query to acquire F r  may be similar to the same query to acquire F w . The query may be executed once per data region during comment read time to determine whether the comment is authorized. 
     D r  represents leaf nodes of DAC for the reader at read time. The query to acquire D r  is similar to that for D w , and may be run once per model. R r  represents leaf nodes of the role for Dimension i  for the reader at read time. The query to acquire R r  is similar to that for R w  and may be run once per model. 
     C r  may equal F r  ∩ D r  ∩ R r , and calculation of C r  is similar to calculation of C w . C r  may be calculated once per data region. 
     S 930  may therefore comprise an evaluation of whether, for each Dimension i  in the thread context: Context w =Context r , or, using the notation above, T w  ∩ C w =T w  ∩ C r . 
       FIG. 10  is a block diagram of apparatus  1000  according to some embodiments. Apparatus  1000  may comprise a general-purpose computing apparatus and may execute program code to perform any of the functions described herein. Apparatus  1000  may comprise an implementation of server  130 , DBMS  120  and data store  110  of  FIG. 2  in some embodiments. Apparatus  1000  may include other unshown elements according to some embodiments. 
     Apparatus  1000  includes processing unit(s)  1010  operatively coupled to communication device  1020 , data storage device  1030 , one or more input devices  1040 , one or more output devices  1050  and memory  1060 . Communication device  1020  may facilitate communication with external devices, such as a reporting client, or a data storage device. Input device(s)  1040  may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s)  1040  may be used, for example, to enter information into apparatus  1000 . Output device(s)  1050  may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer. 
     Data storage device  1030  may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory  1060  may comprise Random Access Memory (RAM), Storage Class Memory (SCM) or any other fast-access memory. 
     Services  1031 , server  1032  and DBMS  1033  may comprise program code executed by processor  1010  to cause apparatus  1000  to perform any one or more of the processes described herein. Embodiments are not limited to execution of these processes by a single apparatus. 
     Data  1034 , comments  1035  and metadata  1036  (either cached or a full database) may be stored in volatile memory such as memory  1060 . Comments  1035  may include comment contexts as described herein. Metadata  1035  may include dimension names, dimension hierarchies, data access control information, and role level security information. Data storage device  1030  may also store data and other program code for providing additional functionality and/or which are necessary for operation of apparatus  1000 , such as device drivers, operating system files, etc. 
     The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each component or device described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each component or device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of a system according to some embodiments may include a processor to execute program code such that the computing device operates as described herein. 
     All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software. 
     Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.