Source: https://patents.google.com/patent/US9600548B2/en
Timestamp: 2019-08-18 05:58:56
Document Index: 782124231

Matched Legal Cases: ['arts 142', 'arts 142', 'arts 142', 'art 604', 'art 604', 'art 604', 'art 604', 'art 604', 'art 604', 'art 604', 'art 604', 'art 608', 'art 608', 'art 608', 'art 608', 'art 608', 'art 608', 'art 608', 'art 608', 'art 624', 'art 624', 'art 624', 'art 800']

US9600548B2 - Row level security integration of analytical data store with cloud architecture - Google Patents
Row level security integration of analytical data store with cloud architecture Download PDF
US9600548B2
US9600548B2 US14/512,230 US201414512230A US9600548B2 US 9600548 B2 US9600548 B2 US 9600548B2 US 201414512230 A US201414512230 A US 201414512230A US 9600548 B2 US9600548 B2 US 9600548B2
US14/512,230
US20160104002A1 (en
2014-10-10 Priority to US14/512,230 priority Critical patent/US9600548B2/en
2014-11-03 Assigned to SALESFORCE.COM, INC. reassignment SALESFORCE.COM, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHAKRAVARTHY, VIJAYASARATHY, IM, FRED, SCHNEIDER, DONOVAN A., SILVER, DANIEL C.
2016-04-14 Publication of US20160104002A1 publication Critical patent/US20160104002A1/en
2017-03-21 Publication of US9600548B2 publication Critical patent/US9600548B2/en
This application is one of several U.S. Nonprovisional Patent Applications filed contemporaneously. The related applications are (i) U.S. application Ser. No. 14/512,240, titled LOW LATENCY ARCHITECTURE WITH DIRECTORY SERVICE FOR INTEGRATION OF TRANSACTIONAL DATA SYSTEM WITH ANALYTICAL DATA STRUCTURES, filed 10 Oct. 2014, now U.S. Pat. No. 9,396,018, issued 19 Jul. 2016 (ii) U.S. application Ser. No. 14/512,249 titled INTEGRATION USER FOR ANALYTICAL ACCESS TO READ ONLY DATA STORES GENERATED FROM TRANSACTIONAL SYSTEMS, filed 10 Oct. 2014, now U.S. Pat. No. 9,449,188, issued 20 Sep. 2016, (iii) U.S. application Ser. No. 14/512,258, titled VISUAL DATA ANALYSIS WITH ANIMATED INFORMATION MORPHING REPLAY, filed 10 Oct. 2014, (iv) U.S. application Ser. No. 14/512,263 titled DECLARATIVE SPECIFICATION OF VISUALIZATION QUERIES DISPLAY FORMATS AND BINDINGS, filed 10 Oct. 2016, (v) U.S. application Ser. No. 14/512,267 titled DASHBOARD BUILDER WITH LIVE DATA UPDATING WITHOUT EXITING AN EDIT MODE, filed 10 Oct. 2014 and (vi) U.S. application Ser. No. 14/512,274, titled OFFLOADING SEARCH PROCESSING AGAINST ANALYTIC DATA STORES, filed 10 Oct. 2014. The related applications are hereby incorporated by reference for all purposes.
FIG. 6 demonstrates one implementation of applying security predicates to an edgemart.
FIG. 7 shows one implementation of a role-based security model.
FIG. 8 is a representative method of building a secure read only analytic data structure.
FIG. 9 shows a high-level block diagram of a computer system that can be used to implement some features of the technology disclosed.
Application of the multiplicity of messaging queues solves the technical problem of queue blockage in the integration environment 200. Contention is created when multiple worker threads use a single queue to perform their tasks. Contention in multi-threaded applications of queues can slow down processing in the integration environment 200 up to three orders, thus resulting in high latency. The condition is worsened when there are multiple writers adding to a queue and readers consuming. As a result, every time a request is written or added to a particular queue, there is contention between multiple worker threads since a reader concurrently attempts to read or remove from the same queue. In some implementations, integration environment 200 uses a pool of worker threads for reading or writing requests from or to clients in the network(s) 225. Worker threads are hosted on resources referred to as “workers.” Once request is read into the “named key-value task start queue,” it is dispatched for execution in the workers. The resulting data generated after the request is executed by the workers is referred is stored as edgemarts 142. In some implementations, the edgemarts 142 are portioned into multiple smaller edgemarts called shards 216. In one implementation, edgemarts 142 are partitioned based on specified dimensions such as a range or a hash.
FIG. 6 demonstrates one implementation of applying 600 security predicates to an edgemart. In this example, an initial edgemart 604 a-n is a first edgemart created by the edgemart engine 152 from one or more transaction database systems 232 a-n. In one implementation, all users of an organization, which is a tenant at least one of the database systems 232 a-n and for which the initial edgemart 604 a-n is created, have access to all the records in the initial edgemart 604 a-n as part of an initial transformation. In other implementations, a row-level security is applied to the initial edgemart 604 a-n as some records can include sensitive data that is supposed to be inaccessible to at least some users of the tenant or organization. The row-level security restricts access of the initial edgemart 604 a-n to a subset of users of the tenant, depending upon one or more security models employed by the tenant.
To implement row-level security on the initial edgemart 604 a-n, a predicate 602 a-n is appended to the initial edgemart 604 a-n. Predicate 602 a-n serves as a filter condition based on the user who runs the query. In particular, the initial transformation includes a purpose-built row-level security transformation 605 that combines predicate-based rules 602 a-n for translating security attributes of an initial edgemart 604 a-n into a subsequent edgemart 608 a-n. In one implementation, the predicate-based rules are stored in security rules database 242. Subsequent edgemart 608 a-n further includes predicate-based rules 606 a-n that store user and session authentication and authorization attributes. Advancing further, predicate-based rules 606 a-n are leveraged to implement security at a row or object level of the data structure 610.
In some implementations, the predicates are embedded within the edgemarts. This makes the edgemarts portable to any device, including other servers, workstations or mobile devices, which in turn facilitate efficient execution of queries on a local store 252 of such devices. In other implementations, the predicates are stored as separate data structures that map to data stored in the edgemarts. In one implementation, the predicates are defined as VAD (view-all-data), which allows all users to see all rows in the edgemart. In another implementation, the predicates restrict access of specific users to certain rows within dimensions and measures for read only purposes. Such implementation simplifies the security model to handle only read only permissions as opposed to more complex Create, Read, Update and Delete (CRUD) permissions.
A design criterion for the security predicates is to create a security method that is unassociated with other security mechanisms. As a result, a security method is developed that is flexible enough to address conflicting security configurations from a plurality of transaction data sources. In one implementation, a first edgemart 608 a is generated based a first transactional database 232 a and a second edgemart 608 b is generated from a second transactional database 232 b. In such a case, the first edgemart 608 a is combined with the second edgemart 608 b using a predicated definition that can process the security policies of both the first and second transactional databases 232 a-b and generate a combined set of predicates 606 a-b.
In one implementation, a predicate definition depends upon the type of transaction data from which the result edgemart is created. For instance, to define a predicate for an edgemart that is based on transaction data “native” to the client, the predicate expression is specified in the appropriate field of the register transformation described above. In contrast, defining a predicate for an edgemart that is based on external data not native to the client, the predicate expression is defined in the appropriate field in a schema file associated with the external data. One example of nativity is that if a client is a tenant of a service provider such as Salesforce.com on which the insights analytics application 158 is built, then standard and custom objects provided by Salesforce.com® are native to the client, unlike the same of other service providers like SAP® that, even though host transaction data accessible to the client, do not host the insights analytics application 158.
Analytics environment 100 comprises a user interface and other programming interfaces allowing users and systems to interact with the transactional database management system 232. It enables users to explore the transaction data stored by creating analytics data structures i.e. edgemarts. For instance, a user can issue a request to generate reports, derive measures, or compute sets from the transaction data 232 using the analytics environment 100. Based on the parameters of the request, edgemarts are created using the ELT workflow described above. The resulting edgemarts are then made available in for the user to consume and interactively explore.
Row-level security enables the subsequent edgemart 608 a-n and associated security predicates 606 a-n to be subsequently split or cleaved into smaller, faster operating substructures 622, 624, based on the authentication of a user making the splitting request and dimensions and measures within the corresponding edgemart. In one implementation, when a request, that requires edgemart creation from transaction data, is made by the web based user 255 via the insights analytics application 158, the user making the request is first authenticated by the security engine 245. A security token created in response to this authentication is matched to a predicate token specified in the predicates 606 a-n for the web based user 255. This predicate token is then used to authorize the request to split the second edgemart 608 a-n into a third edgemart 624 a-n. This predicate token persists into the security token 630 associated with multiple predicates 622 a-n of the third edgemart 624 a-n. The security token 630 includes only the rows that the web based user 255 is authorized to leverage.
In the example shown in FIG. 6, a query slits edgemart 624 that has predicates for two users; User #1 626 and User #2 628, into security tokens TU1 630 and TU2 631, respectively. Further in this example, the web based user 255 receives a security token TU1 630. This gives the web based user 255 access to dimension row D1 and measures rows M2 and M3 632 of the dimensions table 642 and measures table 644. It also gives the user, which receives security token TU2 631, access to row D2 in the dimensions table 642 and rows M1, M4, and M5 in the measures 644 table.
In some implementations, task requests that apply to an edgemart include a request to spit an edgemart, a request to index an edgemart and a request to perform analytics on an edgemart, amongst others. When a web based user 255 initiates a task request against an edgemart, the insights analytics application 158 checks the predicate to determine which records the user has access to. If the user doesn't have access to the requested records, the insights analytics application 158 does not return those records. Instead, in one implementation, the insights analytics application 158 communicates to the web based user 255 an authentication error to indicate his or her lack of required authorization.
Row-level security can be used to answer a question like—can user X see row Y in edgemart Z? According to one implementation, the initial application of security predicates configures role-hierarchy to the ‘owner’ field of the finest grain entity in the edgemart. If a user has access to the row he or she is requesting, or is above the owner in the role hierarchy of a row-based security model or a team-based security model, then the user can access the row. In another implementation, row-level security can extend a user's access by applying a security model that provides the user access to a previously inaccessible record to its merged version in the edgemart. In some implementations, this occurs when multiple entities are denormalized into a single edgemart. For example, if an account table is denormalized into an opportunity table, then the account-related fields can be seen by a user that is authorized to see any opportunity that is linked to the account.
Different types of security policies can be implemented within a security predicate of an edgemart. The type of security policy depends on the degree of access restriction desired by a tenant and on the type of information in the edgemart to be made available to the tenant users that they can use in the predicate expression. For instance, if a particular organization's application is deployed, a security policy based on that organization's role hierarchy can be used to enable organization users to view records owned or shared by their respective subordinates. In other implementations, a team-based security policy can be applied to enable a user to view records owned or shared by other members on their team.
In this implementation, the following security methods are available for each edgemart:
A role-based security model 700 depicted in FIG. 7 enables each user to access records shared and owned by their subordinates according to the role hierarchy. In example, role-based security can be applied to the Opportunity EdgeMart to restrict access to opportunity records. This is achieved by defining the following predicate for an Opportunity EdgeMart:
‘Opp_Owner’==$User.Id∥‘Opp_Role’==$User.userRoleId
Predicate expression ‘Opp_Owner’==$User.Id determines whether a user who initiated a task request is an opportunity owner. For example, when the user named “Anita” initiates the task request, the task request returns OppC because another user named “Chris” owns the opportunity and Chris is a subordinate to Anita in the role hierarchy depicted in FIG. 7.
Predicate expression “Opp_Role’==$User.userRoleId determines whether a user who initiated a task request is a parent of the opportunity owner based on the role hierarchy. For instance, when the user named “Bill” initiates the task request, the task request returns OppA and OppB because both opportunities are owned by employees below Bill in the role hierarchy.
LDAP based security enables each user to view records owned or shared by users of their organization (O) or organization unit (OU) as defined in the associated LDAP directory. This is achieved by defining the following predicate for an Opportunity EdgeMart:
‘User_Id’==$User.Id∥‘Organization Unit’==$User.OrgUnit_c∥‘Organization’==$User.organizaiton_c
Agent based security enables each user to view accounts to which they have a relationship with. Some accounts can have relationships with multiple agents, according to one implementation. This is achieved by defining the following predicate for an Account EdgeMart:
‘User_Id’==$User.Id∥‘User_Role’==$User.UserRoleId|
Team based security enables each user to view records owned or shared by all users on their team. This is achieved by defining the following predicate for an Opportunity EdgeMart:
‘User_Team_Id’==$User.teamId_c∥‘User_Role’==$User.UserRoleId∥‘User_Product_Id’==$User.productId_c
Account-Hierarchy-Based Security
Account hierarchy based security enables the owner of a parent account to view all child accounts. This is achieved by defining the following predicate for an Opportunity EdgeMart:
‘Opp_FlattenParentAccounts_Owner’==$User.Id∥‘Opp_FlattenParentAccounts_Owner_flattenParentRoles’==$User.RoleId
Group based security enables each user to view records owned or shared by all users in their group. This is achieved by defining the following predicate for an Opportunity EdgeMart:
‘Opp_Account_Owner’==$User.id∥‘Account_Owner_FlattenParentRoles’==$User.UserRoleId∥‘Opp_Account_Group_Id’==$User.groupId_c∥‘Opp_Account_Group_Id_Users_FlattenParentRoles’==$User.UserRoleId
Sharing-Descriptor-Based Security
Sharing descriptor based security enables security based on any type of sharing. In some implementations, a sharing descriptor lists combinations of people that have access to each record. This is achieved by defining the following predicate for an Opportunity EdgeMart:
‘User_SD’=Opp_SD
‘User_SD’ can be a large multivalue field.
Secure Read Only Analytic Structure Construction
FIG. 8 is a representative method 800 of building a secure read only analytic data structure. Flowchart 800 can be implemented at least partially with a database system, e.g., by one or more processors configured to receive or retrieve information, process the information, store results, and transmit the results. For convenience, this flowchart is described with reference to the system that carries out a method. The system is not necessarily part of the method. Other implementations may perform the steps in different orders and/or with different, fewer or additional steps than the ones illustrated in FIG. 8. The actions described below can be subdivided into more steps or combined into fewer steps to carry out the method described using a different number or arrangement of steps.
At action 802, a data set is accessed from at least one transactional data management system. In one implementation, the data in the data set has security attributes managed by the transactional data management system. In other implementations, a plurality of heterogeneous transactional data management systems that have divergent security models are accessed. In such implementations, data in the plurality of transactional data management systems is accessed and objects that merge the data from two or more of the transactional data management systems are created. In some other implementations, a data set from at least one transactional data management system is accessed that lacks a security model. In such implementations, the data set is accessed to create a new read only analytic data structure that merges the data in the data set with the read only analytic data structure.
The security attributes are based on one or more security models used to manage access to the transactional data management system. The security models include at least one of row-based security, LDAP-based security, agent-based security, team-based security, account-hierarchy-based security, group-based security and sharing-descriptor-based security.
At action 812, first security translation rules that accept the security attributes as predicates are processed to generate one or more security tokens for each object in the data set. The one or more security tokens define accessibility of respective dimensions and measures of the secured object. In other implementations, the first security translation rules that accept the security attributes from the two or more transactional data management systems as predicates are processed and one or more security tokens are generated to associate with each secured object that merges the data. In yet other implementations, the one or more security tokens associated with the read only analytic data structure are associated to the new read only analytic data structure.
At action 822, the one or more security tokens are stored by association with each secured object in a read only analytic data structure generated from the data set. In one implementation, the stored security tokens govern access to the each secured object.
At action 832, an authenticated and authorized command is received to build an analytic sub structure from the analytic data structure that satisfies a subset query. In one implementation, the subset query requests particular dimensions and measures of one or more secured objects.
At action 842, second security translation rules are applied to construct at least one query security token based on the authentication and authorization accompanying the command. In one implementation, the query security token qualifies the command to access one or more secured objects in the analytic data structure.
At action 852, the subset query and the query security token are supplied to a query engine. Also, the secured objects from the analytic data structure are received, which satisfy the subset query and that have an associated security token that matches the query security token.
In some implementations, a view-all-data initial instance of the read only analytic data structure is generated before the processing first security translation rules.
This method and other implementations of the technology disclosed can include one or more of the following features and/or features described in connection with additional methods disclosed. In the interest of conciseness, the combinations of features disclosed in this application are not individually enumerated and are not repeated with each base set of features. The reader will understand how features identified in this section can readily be combined with sets of base features identified as implementations in sections of this application such as analytics environment, integration environment, ELT workflow, integration components, row-level security, etc.
FIG. 9 shows a high-level block diagram 900 of a computer system that can used to implement some features of the technology disclosed. Computer system 910 typically includes at least one processor 914 that communicates with a number of peripheral devices via bus subsystem 912. These peripheral devices can include a storage subsystem 924 including, for example, memory devices and a file storage subsystem, user interface input devices 922, user interface output devices 918, and a network interface subsystem 916. The input and output devices allow user interaction with computer system 910. Network interface subsystem 916 provides an interface to outside networks, including an interface to corresponding interface devices in other computer systems.
Memory 926 used in the storage subsystem can include a number of memories including a main random access memory (RAM) 930 for storage of instructions and data during program execution and a read only memory (ROM) 932 in which fixed instructions are stored. A file storage subsystem 928 can provide persistent storage for program and data files, and can include a hard disk drive, a floppy disk drive along with associated removable media, a CD-ROM drive, an optical drive, or removable media cartridges. The modules implementing the functionality of certain implementations can be stored by file storage subsystem 928 in the storage subsystem 924, or in other machines accessible by the processor.
Bus subsystem 912 provides a mechanism for letting the various components and subsystems of computer system 910 communicate with each other as intended. Although bus subsystem 912 is shown schematically as a single bus, alternative implementations of the bus subsystem can use multiple busses. Application server 920 can be a framework that allows the applications of computer system 910 to run, such as the hardware and/or software, e.g., the operating system.
1. A method of building a secure read-only analytic data structure, the method including:
accessing a data set from at least one transactional data management system, wherein data in the data set has security attributes managed by the at least one transactional data management system;
processing first security translation rules that accept the security attributes as predicates and generating one or more security tokens for each object in the data set; and
storing the one or more security tokens by association with each secured object in the read-only analytic data structure generated from the data set, wherein the stored one or more security tokens govern access to each secured object.
accessing a plurality of heterogeneous transactional data management systems that have divergent security models;
accessing data in the plurality of heterogeneous transactional data management systems and creating objects that merge the accessed data from two or more heterogeneous transactional data management systems of the plurality of heterogeneous transactional data management systems; and
processing first security translation rules that accept the security attributes from the two or more heterogeneous transactional data management systems of the plurality of heterogeneous transactional data management systems as predicates and generating one or more security tokens to associate with each secured object that merges the accessed data.
accessing a data set from at least one transactional data management system, wherein data in the data set lacks a security model;
accessing the data set and creating a new read-only analytic data structure that merges the data lacking the security model with the read-only analytic data structure; and
associating the one or more security tokens associated with the read-only analytic data structure to the new read-only analytic data structure.
receiving an authenticated and authorized command to build an analytic sub-structure from the read-only analytic data structure that satisfies a subset query;
applying second security translation rules to construct at least one query security token based on the authenticated and authorized command, wherein the at least one query security token qualifies the command to access one or more secured objects in the read-only analytic data structure; and
supplying the subset query and the at least one query security token to a query engine and receiving the one or more secured objects from the read-only analytic data structure that satisfy the subset query and that have an associated security token that matches the at least one query security token.
5. The method of claim 4, further including mobilizing the analytic sub-structure from a secure server based platform to a browser based user client platform, the mobilizing of the analytic sub-structure including:
receiving a subset query to receive a subset of data in the analytic sub-structure; and
supplying the subset of data to the browser based user client platform that satisfies the subset query with a reduced bandwidth and processing time.
receiving an authenticated and authorized command to receive a subset of data in the read-only analytic data structure that satisfies a subset query;
applying second security translation rules to construct at least one query security token based on the authenticated and authorized command, wherein the at least one query security token qualifies the command to access the subset of data in the read-only analytic data structure; and
supplying the subset query and the at least one query security token to a query engine and receiving the subset of data from the read-only analytic data structure that satisfies the subset query and that has an associated security token that matches the at least one query security token.
7. The method of claim 6, further including mobilizing the subset of data from a secure server based platform to a browser based user client platform, the mobilizing of the subset of data including:
receiving a subset query to receive the subset of data; and
8. The method of claim 1, wherein the security attributes are based on one or more security models used to manage access to the at least one transactional data management system.
9. The method of claim 8, wherein the one or more security models include at least one of:
row-based security;
LDAP-based security;
agent-based security;
team-based security;
account-hierarchy-based security;
group-based security; and
sharing-descriptor-based security.
10. The method of claim 1, further including generating a view-all-data initial instance of the read-only analytic data structure before the processing of the first security translation rules.
11. The method of claim 1, wherein the one or more security tokens define accessibility of respective dimensions and measures of each secured object.
12. A non-transitory computer-readable storage medium impressed with computer program instructions for building a secure read-only analytic data structure, the instructions, when executed on a hardware processor implement a method comprising:
process first security translation rules that accept the security attributes from the two or more heterogeneous transactional data management systems of the plurality of heterogeneous transactional data management systems as predicates and generating one or more security tokens to associate with each secured object that merges the accessed data.
14. The non-transitory computer-readable storage medium of claim 12, wherein the method further comprises:
16. The non-transitory computer-readable storage medium of claim 15, wherein the method further comprises mobilizing the analytic sub-structure from a secure server based platform to a browser based user client platform, the mobilizing of the analytic sub-structure including:
18. The non-transitory computer-readable storage medium of claim 17, wherein the method further comprises mobilizing the subset of data from a secure server based platform to a browser based user client platform, the mobilizing of the subset of data including:
19. The non-transitory computer-readable storage medium of claim 12, wherein the security attributes are based on one or more security models used to manage access to the at least one transactional data management system.
20. The non-transitory computer-readable storage medium of claim 19, wherein the one or more security models include at least one of:
21. The non-transitory computer-readable storage medium of claim 12, wherein the method further comprises generating a view-all-data initial instance of the read-only analytic data structure before the processing of the first security translation rules.
22. The non-transitory computer-readable storage medium of claim 12, wherein the one or more security tokens define accessibility of respective dimensions and measures of each secured object.
23. An apparatus for building a secure read-only analytic data structure, the apparatus comprising:
a processor configured to execute the stored computer instructions to:
access a data set from at least one transactional data management system, wherein data in the data set has security attributes managed by the at least one transactional data management system;
process first security translation rules that accept the security attributes as predicates and generating one or more security tokens for each object in the data set; and
store the one or more security tokens by association with each secured object in the read-only analytic data structure generated from the data set, wherein the stored one or more security tokens govern access to each secured object.
US14/512,230 2014-10-10 2014-10-10 Row level security integration of analytical data store with cloud architecture Active 2035-01-06 US9600548B2 (en)
US14/512,230 US9600548B2 (en) 2014-10-10 2014-10-10 Row level security integration of analytical data store with cloud architecture
US15/439,637 US20170161515A1 (en) 2014-10-10 2017-02-22 Row level security integration of analytical data store with cloud architecture
US15/439,637 Continuation US20170161515A1 (en) 2014-10-10 2017-02-22 Row level security integration of analytical data store with cloud architecture
US20160104002A1 US20160104002A1 (en) 2016-04-14
US9600548B2 true US9600548B2 (en) 2017-03-21
ID=55655638
US14/512,230 Active 2035-01-06 US9600548B2 (en) 2014-10-10 2014-10-10 Row level security integration of analytical data store with cloud architecture
US15/439,637 Pending US20170161515A1 (en) 2014-10-10 2017-02-22 Row level security integration of analytical data store with cloud architecture
US (2) US9600548B2 (en)
US7840518B1 (en) * 2007-09-04 2010-11-23 The United States Of America As Represented By The Secretary Of The Navy System and method for object recognition utilizing fusion of multi-system probabalistic output
2014-10-10 US US14/512,230 patent/US9600548B2/en active Active
2017-02-22 US US15/439,637 patent/US20170161515A1/en active Pending
Rao et al, "Spatial Hierarchy and OLAP-Favored Search in Spatial Data Warehouse", ACM, New Orleans, LA., Nov. 7, 2003, pp. 48-55.
Salesforce.com, "Salesforce Security Guide" @ http://resources.docs.salesforce.com/200/17/en-us/sfdc/pdf/salesforce-security-impl-guide.pdf. *
Salesforce.com, "SOAP API Developer's Guide" @ https://resources.docs.salesforce.com/200/latest/en-us/sfdc/pdf/apex-api.pdf. *
Salesforce.com, Salesforce Analytics Cloud Implementation and Data Integration Guide @ https://jira.talendforge.org/secure/attachment/74327/Analytics%20Cloud%20Implementation%20Guide.pdf. *
Salesfore.com, "Row-Level Security for Datasets" @ https://help.salesforce.com/apex/HTViewHelpDoc?id=bi-security-datasets-row-level.htm. *
U.S. 14/512,249-Notice of Allowance dated May 11, 2016, 14 pages.
US20170161515A1 (en) 2017-06-08
US20160104002A1 (en) 2016-04-14
CN103177059B (en) 2017-10-31 The path calculation processing for separating database engine
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHNEIDER, DONOVAN A.;SILVER, DANIEL C.;IM, FRED;AND OTHERS;SIGNING DATES FROM 20141022 TO 20141023;REEL/FRAME:034094/0142